AI-enabled ops — Ascend operating system

A version-controlled operating system for how Ascend works with AI: shared standards, shared knowledge, and shared change-tracking on a remote plane, paired with per-person tool surfaces on a local plane. Every contributor inherits the same baseline intelligence and contributes discoveries back through a deliberate, PR-reviewed promotion path.

Rollout scope 4-phase Bootstrap done · single-player core proven (two real specs shipped through the OS) · onboarding is the current phase

Planes 2 remote & local

Local tiers 3 Cowork · Code (Desktop) · CLI

Phases 4 bootstrap to autonomous

Phase 0 target 5 working days

The thesis

The operating system I am envisioning has a remote and a local plane. On the remote plane we sync via GitHub (version control of the shared workspace) and project-manage via Linear (source of truth) and Slack (two-way sync). The remote plane is also where we sync team-level config: CLAUDE.md, settings, shared MCP servers, shared skill definitions, shared hooks. The local plane is two-fold: human setup (Claude Code CLI, Desktop, Cowork — inherits remote, configurable with local overrides) and autonomous setup.
— Manny E. Reimi to Marcelo, 2026-05-12

Two planes

Remote plane — shared, versioned

GitHubshared config · /knowledge/

LinearOKRs · projects · issues

Slackephemeral · 2-way sync

→ inherits ← PR back

Local plane — per person, inherits remote

Tier 1 · CoworkWarren · Paul · Simon

Tier 2 · Code in DesktopMarcelo

Tier 3 · Code CLIManny · Renée · Dennis

System of intelligence

Shared quality

Lifts the floor on how every team member operates with AI. The shared layer means no contributor starts from zero, and local overrides are always permitted.

Shared artifacts: CLAUDE.md · skills · hooks · MCP server configs · plugin definitions

System of record

Shared accuracy

Grounds every decision in the same canonical surfaces. No archaeology required when tracing why something was built the way it was.

Canonical surfaces: Linear · GitHub PRs · /knowledge/ ADRs · */specs/ (SHA-pinned behavior evidence, v2.2) · Slack (ephemeral, 2-way sync)

Both raise the team

System of intelligence

System of record

↓

Ascend teamraised baseline · grounded decisions

Architecture

Two planes connected by directory nesting. The hub physically nests the spokes as subdirectories; each spoke mounts its code repos under work/ via a manifest. The remote plane is shared and versioned; the local plane is per-person and inherits the remote by composing CLAUDE.md down the directory tree.

Remote plane — shared, versioned

ascend-os (hub — nests the spokes)

CLAUDE.md hub resolver, at the repo root
.claude/ shared skills · hooks · rules · settings
.mcp.json shared MCP server declarations
knowledge/ ADRs · primers · conventions · people · backbone
repos.yaml code-repo → spoke-mount manifest
OWNERS root + per-subdir ownership

nests as subdirectories

product/

stream-aligned

protocol/

complicated subsystem

compliance/

permanent specialist

Because the spokes nest physically, each inherits the hub CLAUDE.md and .claude/ by directory position — no per-spoke replication. Each spoke mounts its @AscendFi code repos under work/ per repos.yaml.

Nesting + manifest is chosen over submodule (pinned-commit indirection that confuses non-technical contributors) and over a monorepo-of-everything (entangled release cadence, fights the engineering team's standalone workflow). Subtree is retained only for the graduation case — when a spoke moves to its own repo.

Local plane — per person, inherits remote

Tier 1 — Cowork

Cowork, in the Claude Desktop app

Warren · Paul · Simon

Reads /knowledge/ and CLAUDE.md via connectors. Applies shared skills within its hosted VM. No terminal, no MCP CLI.

Tier 2 — Claude Code in Desktop

Claude Code via the Claude Desktop app

Marcelo

Claude Code through the Desktop app (not the standalone CLI). Adds shared MCP servers and skill invocation on top of Tier 1. Transition path toward Tier 3.

Tier 3 — CLI

Claude Code CLI + full toolchain

Manny · Renée · Dennis

Full toolchain: git ops, hooks, MCP, skills, agents. The full-toolchain surface, for those who maintain the shared layer day to day. A tooling surface, not a rank.

<hub-or-spoke>/.obsidian/ ← capture · GITIGNORED daily/ _inbox/ _thinking/

Access: Cowork reads via GitHub connector · Code-in-Desktop and CLI read+write via MCP + git. The gitignored capture lives under .obsidian/ in the workspace (contributor / spoke / hub level), promoted into knowledge/ via /promote-to-knowledge.

Pull discipline — pull the hub once, the shared layer composes in

ascend-os Release tag Contributor /sync-ai-ops

A meaningful change is merged into the hub (new skill · CLAUDE.md edit)
os→Release tagtag v1.4.0
tag→Contributor (via Slack)notification posted by GitHub Action
contributor→/sync-ai-opsat their own pace: git pull the hub — the shared layer composes in immediately
sync→code-repo mountsrefresh each mount per repos.yaml; skill surfaces diff, applies on confirm
When a contributor needs a hub change first
contributor→ascend-osPR with new shared need → review · merge → tag

No per-spoke replication to sync: the layering is the directory tree. No bespoke release tooling needed in Phase 0–1.

Hub & spokes — one hub nesting one spoke per team as subdirectories

ascend-oshub · CLAUDE.md + .claude/ + knowledge/

nests as subdirs →

← PR back to the hub

product/stream-aligned

protocol/complicated subsystem

compliance/permanent specialist

Nesting over submodule (pinned-commit indirection confuses non-builders) and over a monorepo-of-everything (couples release cadence, fights the standalone clone). CLAUDE.md composes by directory position; a spoke contributor sees a normal directory.

Team Topologies — each spoke is a team of one of four shapes

Stream-aligned

Owns end-to-end flow of value for a product surface. Self-contained: strategy + technical + marketing in one team (Product++). Marketing is a discipline inside the team, not a separate spoke.

product/

Complicated subsystem

Owns a system needing specialist depth — Solidity, the on-chain reserve/loss stack, oracle integration.

protocol/

Platform

Provides the shared substrate the others consume X-as-a-Service. Today that is the hub itself plus its owners; the off-chain service layer graduates to its own platform spoke when it becomes a distinct team.

ascend-os + owners

Enabling

Uplifts other teams over a capability gap. The team is permanent (a standing security- or compliance-enablement function that gets a spoke); only its facilitating interaction with any one team is time-boxed.

e.g. compliance/

All four are standing teams, and each gets a spoke — the team is the durable unit; the ephemeral unit is the workstream (a dated specs/ entry inside a spoke). The spoke shape is uniform across all four types — what changes is the team's domain, its OWNERS, and the contents of work/. Phase 1 stands up product, protocol, and compliance; platform and quant graduate as those teams form.

Shared layer breakdown

ascend-os/ (hub · nests the spokes · ships as a Claude Code plugin) ├─ CLAUDE.md ← hub resolver · ROOT (CC also allows .claude/CLAUDE.md — use root) ├─ .mcp.json ← project-scoped MCP servers (team-shared) ├─ .lsp.json ← code-intelligence (LSP) servers · PLUGIN-ROOT ├─ .claude-plugin/ ← plugin package dir · PLUGIN-ROOT │ └─ plugin.json ← plugin manifest · packages the shared layer ├─ .claude/ ← project config · composes DOWN by position (see note) │ ├─ settings.json ← settings · HOOKS live here (the "hooks" key) │ ├─ settings.local.json ← personal/local settings · GITIGNORED │ ├─ skills/ ← shared skills (/sync-ai-ops · /promote-to-knowledge · /gbrain) │ ├─ agents/ ← shared subagent definitions │ ├─ commands/ ← legacy slash commands (merged into skills; still work) │ └─ rules/ ← path-scoped resolver rules (*.md · native feature) │ ├─ knowledge/ ← shared canon; readable by ALL tiers │ ├─ README.md ← entry point │ ├─ conventions/ ← naming · voice · tone · code style │ ├─ decisions/ ← cross-team ADRs │ ├─ primers/ ← onboarding primers │ ├─ references/ ← whitepaper · GTM · models │ ├─ backbone/ ← product-backbone everything-doc │ ├─ glossary.md │ └─ people/ ← who does what │ ├─ repos.yaml + Makefile ← mount manifest + bootstrap ├─ product/ protocol/ compliance/ ← the spokes ├─ .obsidian/ ← unstructured capture · GITIGNORED │ └─ daily/ _inbox/ _thinking/ ├─ docs/ ← CE scratch · GITIGNORED └─ OWNERS ← root + per-subdir ownership

ascend-os/<spoke>/ (one shape, every team) ├─ CLAUDE.md ← spoke charter · ROOT; composes │ UNDER the hub CLAUDE.md ├─ .claude/ ← OPTIONAL: spoke-specific rules/ │ hooks/skills; composes with hub's │ ├─ specs/ ← SDD artifacts (per spec, dated) │ └─ 2026-MM-DD-name/ │ ├─ spec.md │ ├─ acceptance/ ← Gherkin, one Feature per file │ ├─ evals.md ← quantitative gate (oracle + LLM) │ └─ coverage-matrix.md ← preservation specs │ ├─ decisions/ ← team-local ADRs │ ├─ work/ ← the team's output (uniform name) │ code teams → @AscendFi repos MOUNTED here (gitignored; │ each keeps its own lean CLAUDE.md) │ non-code → tracked artifacts directly │ ├─ .obsidian/ ← unstructured capture · GITIGNORED │ └─ daily/ _inbox/ _thinking/ ├─ .github/workflows/ ← CI where the spoke itself needs it ├─ docs/ ← CE scratch · GITIGNORED └─ OWNERS ← team owner + reviewers

Config accuracy (per the Claude Code docs)

Hooks are configured in .claude/settings.json (the hooks key) — not a .claude/hooks/ directory; plugins are consumed via enabledPlugins in settings. .lsp.json and .claude-plugin/plugin.json are plugin-root artifacts — they appear at the hub root only because the hub publishes its shared layer as a plugin (an ordinary project would not carry them). .claude/rules/ is a native feature (path-scoped *.md). CLAUDE.md may live at the root or in .claude/CLAUDE.md — we standardize on the root.

Nested .claude/ composes per artifact, not uniformly: CLAUDE.md concatenates root-down; skills/ compose up to the repo root; but settings.json resolves by precedence (nearest/higher wins per key), not union. So a spoke .claude/ adds spoke-specific rules/skills on top of the hub's, while spoke settings override hub settings key-by-key.

One spoke, one shape — no code/non-code distinction. What flexes is only work/: a code team mounts its @AscendFi repos there; a non-code team tracks its artifacts there directly. The structure — CLAUDE.md, specs/, decisions/, work/, OWNERS — is identical. Treating a React app, Solidity, regulatory procedures, and product strategy as the same kind of work — versioned, spec-driven, decision-traceable, reviewable — is what makes the Product++ triad coherent at the filesystem level. The three are disciplines inside one stream-aligned team, not three separate teams.

Hub vs spoke — the placement rule is ownership, not readership

A thing read by every team still belongs to one spoke if one team authors and owns it: the written-supervisory-procedures are read firm-wide but owned by compliance, so they live in the compliance spoke. Only genuinely shared substrate with no single owning team lives in the hub — conventions, glossary, the people directory, cross-team ADRs, and the product-backbone everything-doc. Readership is broad for both; ownership is the discriminator.

Session data → knowledge

Two kinds of session data accumulate locally, both gitignored, neither shared as-is. /promote-to-knowledge is the single path that distills both into durable, tracked knowledge/:

Source 1 — unstructured capture

.obsidian/{daily, _inbox, _thinking} — gitignored, per-contributor. daily/ is the running log (human + Claude); _inbox/ is Claude-generated captures to triage; _thinking/ is human-authored reflection. The capture lives under .obsidian/ — this is simply where unstructured notes live (Obsidian can still open it, incidentally). The vault-"overlay" framing is dropped: on GitHub it doesn't earn its keep.

Source 2 — noisy CE output

docs/ — gitignored. The compound-engineering plugin auto-generates plans · solutions · brainstorms · todos per session: signal-bearing noise, useful to the person who ran the session but not curated for sharing.

Two sources, one sink. /promote-to-knowledge reads both, proposes what's durable, and lifts it (via PR) into knowledge/ — the only path either takes into the shared repo. Everything in the capture is gitignored and never shared until promoted. (This replaces the v1.x per-user vault concept; capture now lives in the workspace.)

/gbrain — querying the knowledge base

knowledge/ is the durable record; /gbrain (gstack's cross-instance context layer) is how a contributor queries it — semantic recall across every promoted learning, ADR, primer, and convention, without hunting the folder tree.

Phase 1

Per-user local. Each Tier-3 contributor runs /gbrain over their local clone of knowledge/; no shared backend. Proves the retrieval is useful before any infra spend.

Phase 2 · deferred

Shared backend. Evaluate a shared store (Supabase or equivalent) so a query hits the team's knowledge and Cowork/Tier-1 users reach it without a local index. Gate: only once cross-spoke retrieval is a real, felt need.

Boundary. /gbrain indexes the promoted, tracked knowledge/ — NOT the gitignored capture (.obsidian/, docs/). Capture becomes queryable only after /promote-to-knowledge lifts it.

The three tiers

Tier 1

Cowork

Cowork in the Claude Desktop app, with GitHub, Drive, and Slack connectors

Lowest-friction entry point. Reads shared knowledge and follows shared CLAUDE.md rules via its hosted VM. Stays a valid endpoint — not all roles need to escalate.

Connector-limited

Tier 2

Claude Code in Desktop

Claude Code via the Claude Desktop app (not the standalone CLI)

Runs Claude Code through the Desktop app. Adds shared MCP servers and skill invocation on top of Tier 1. Natural transition toward the full CLI.

MCP-enabled

Tier 3

CLI

Claude Code CLI with full local toolchain

Full capability surface: git ops, event-driven hooks, MCP, skills, agents, and the compound-engineering plugin. The full-toolchain surface, for those who maintain the shared layer day to day.

Full capability

Tier 1 → Tier 2 → Tier 3 · upgrade path — each tier stays a valid endpoint, escalate by preference, not by rank

Tier is a tooling surface, not a rank

Which tier you operate reflects how you prefer to work, not your authority. Authority lives in your OWNERS entries, independent of tier — a Tier-1 user can own a domain outright. Warren operates in Cowork and owns the compliance spoke.

Tier portability — what each tier inherits

Inherited by ALL tiers

CLAUDE.md + rules + resolvers · knowledge/ (markdown) · .claude/skills/ (read + invoke) · agent definitions · settings the VM can honor.

Tier 2/3 only · Code-in-Desktop & CLI

Hooks via settings.json (event-driven) · env vars + local config · MCP servers requiring a local process · developer-environment-specific config.

Authors of shared knowledge can assume Cowork users benefit, not degrade. The portability rule is permissive by default.

Knowledge flow

Session noise stays noisy. Two gitignored session-data sources — unstructured .obsidian/ and noisy CE docs/ — both feed /promote-to-knowledge, which lifts the durable signal into shared knowledge/ through a deliberate, human-reviewed PR path.

User (any tier) Local session .obsidian/ (gitignored) docs/ (gitignored) /promote-to-knowledge GitHub PR Owner knowledge/

User→Local sessionrun an AI-assisted task
Local→.obsidian/unstructured capture: daily/ · _inbox/ · _thinking/
Local→docs/CE writes docs/solutions/<entry>.md — noisy per-session output
User→/promote-to-knowledgetrigger promotion — reads BOTH sources
skill→Userproposes which entries to promote + suggests target knowledge/ folder
User→GitHub PRapprove · create PR
PR→Ownerauto-route per OWNERS
Owner→PRreview · request changes · approve
PR→knowledge/merge — shared truth; next session everyone inherits

Auto-update

Because the shared layer lives once at the hub and composes by directory position, there is no per-spoke replication to sync — a hub change reaches everyone on their next git pull of ascend-os. The mechanism narrows to two things: refreshing the code-repo mounts and notifying people a change landed. Pull-based, not push-based.

Manny / Dennis ascend-os Release tag GitHub Action Slack #ai-ops Contributor /sync-ai-ops

Manny→ascend-osPR with shared-config change → review · merge
Manny→Release tagtag v1.5.0
tag→GitHub Actiontrigger workflow on tag event
Action→Slack #ai-opspost "ascend-os v1.5.0 released — changelog · diff"
— each contributor, at their own pace —
Contributor→/sync-ai-opsrun the skill
sync→hub + mountsgit pull the hub (shared layer composes in); refresh code-repo mounts per repos.yaml; surfaces diff
Contributor→/sync-ai-opsconfirm → apply; now on latest hub + mounts

Cowork (Tier 1) users receive updates for free: they read GitHub canonical, so every merged change is visible immediately without any manual pull. Graduated spokes (any spoke moved to its own repo) are the one case that still pulls the shared .claude/ via subtree, exactly as a detached repo would.

Ownership

Phase 1 ownership split. OWNERS files at the hub root and per-subdirectory enforce routing. Owners are assigned by expertise domain, not seniority — and ownership is independent of tooling tier. Cross-cutting changes require all three.

Domain	Owner	Notes
Strategy · operating-model · narrative/voice canon · org adoption	Marcelo (lead) · Manny	strategy + narrative; co-owned as AI partners
AI-Ops architecture · skills · technical CLAUDE.md	Manny	architect of the operating system
Engineering · code · specs/ · workflows (per spoke)	Dennis	scoped to engineering execution
Compliance · WSP · regulatory	Warren	owns the compliance spoke
Cross-cutting config (root CLAUDE.md, .mcp.json, settings) + cross-team ADRs	Marcelo · Manny · Dennis	the three co-sign

OWNERS routing (Phase 1)

ascend-os/OWNERS * @manny ├─ .claude/OWNERS @manny ├─ knowledge/OWNERS strategy · voice @marcelo @manny │ conventions @manny │ cross-team ADRs @marcelo @manny @dennis ├─ cross-cutting config @marcelo @manny @dennis └─ spokes/ ├─ product/ protocol/ specs/ @dennis (+ @manny on specs) └─ compliance/ @warren

Named OWNERS (not CODEOWNERS) because it routes non-code paths too. The split is by what kind of change it is, not by seniority. Cross-cutting config + cross-team ADRs need all three.

Phase 2+ — tiered CI-gated optimistic merge

PR opened

→

Auto-routeper OWNERS

→

CI gates run

→

gates pass?
change typical?

yes → optimistic mergeowner notified async

no → blocking owner review

Owners' incentive is built in: invest in CI gates to stop being a manual bottleneck for your domain.

Canonical surfaces

Linear is the single source of record for what the team is doing. Slack and GitHub PRs sync two-way against it; PRs reference Linear IDs. The deliberate negatives matter as much as the positives.

Surface	Role	Sync
Linear	Source of record — OKRs, projects, issues	↔ Slack ↔ GitHub
GitHub PRs	Code and config change-management; reference Linear IDs	↔ Linear
Slack	Ephemeral coordination	↔ Linear
/knowledge/decisions/	ADRs — durable architectural decisions, in-repo	git
*/specs/	Canonical behavior evidence — SHA-pinned, provenance-tagged acceptance baselines (forward + preservation genres, §08)	git

Deliberate negatives

GitHub Projects — not used. Project tracking lives in Linear.
GitHub Issues — only when two-way synced from Linear. Default: do not use.

One place to ask "what are we doing" (Linear) and one place to ask "why was it built this way" (ADRs in /knowledge/decisions/). No competing trackers.

Sync topology

Slackephemeral

↔

Linearsource of record

↔

GitHub PRsreference Linear IDs

/knowledge/decisions/ ADRscited by Linear & GitHub

Spec-driven development

Code-bearing spokes use SDD for any new feature or behavior change. Two spec genres, one dated folder shape: forward specs (net-new behavior) and preservation specs (pin current behavior before a rework, so nothing is silently unshipped). v2.2 patches this section to proven reality — the semantics below are the ones the two shipped specs actually exercised; canonical wording lives in the OS at knowledge/conventions/sdd-preservation-specs.md.

specs/<date-name>/
spec.md Framing · SHA-pinned system-of-record sources · the pass definition

→

acceptance/ Gherkin, one Feature per file (runner-parseable). Every criterion carries a provenance tag

→

evals.md The quantitative gate: deterministic oracle / tolerance cases, plus LLM evals when an AI surface is in scope

→

coverage-matrix.md
(preservation specs) Every current feature → covered · intentionally-removed · deferred — never silently absent

→

verification ladder Agent-QA walkthrough → deterministic validators → optional playwright-bdd runner (replaces the never-built cloud eval bot)

acceptance/ — provenance-tagged Gherkin

One Feature per file, parseable by a real runner. Every criterion is tagged — current behavior vs on-chain rule vs design intent vs a decided rework change — so inherited behavior and new product decisions never blur. Stakeholder-signable: "Given X, When Y, Then Z."

Runner-parseable · provenance-tagged

evals.md — the quantitative gate

Deterministic oracle and tolerance cases — numbers read from the running system, never copied from source constants (the live oracle catches what the constants hide) — and/or statistical LLM evals when an AI surface is in scope. Every claim carries a verify status: verified-live > code-traced > pending.

Oracle-verified, not source-copied

Test code and harnesses. Test code defaults to the mounted code repo, next to the implementation it exercises. Spec-local verification harnesses are permitted when they enforce the spec rather than restate it — the design-system spec's harness/ (deterministic layout checker + calibrated judge council) is the proven precedent.

ADRs in knowledge/decisions/ cross-reference specs by date-name, so the rationale survives even when the spec itself evolves. Coverage-gate CI + the spec-pin staleness tripwire landed 2026-07-06 (ASC-61 items 1–2, capture mode; --enforce flips at rework-merge); the scripted oracle pass + the runner remain tracked in Linear as ASC-61.

Roadmap

Rollout — re-dated 2026-07-07 · Phase 0 DONE (Jun 19–22, de facto) · single-player core proven · onboarding next (Dennis-first)

wk 1wk 2wk 3wk 4

Phase 0 · Bootstrap (wk 1)

Hub + manifest + OWNERS

knowledge/ seed + skills

Pilot spoke + dry-runs

Phase 1 · Onboarding (wk 2)

Claude tiers + Slack + Linear + Granola

Phase 2 · Maturity (wk 3)

Auto-update + CI gates

Slack + Linear cloud agents

Phase 3+ · Autonomous (wk 4)

Local autonomous agents

Shared cloud agents

Phases run sequentially — each starts as the prior completes; within a phase, bars run in parallel. Actual history diverged productively: Phase 0 landed 2026-06-19–22 and the OS then proved out single-player (the design-system spec + harness, then the borrow/onboarding preservation spec) before any onboarding — so Phase 1 is now Dennis-first, and Phase 2 flips the capture-mode gates (coverage-gate + spec-pin staleness, landed 2026-07-06) to --enforce and adds the remaining ASC-61 items. Phase-0 day-by-day detail (historical plan) is in section 10.

Phase 0

Bootstrap

Done · Jun 19–22

Proven 2026-06-19..22: hub (ascend-os) + three spokes with code repos mounted + manifest + skills, single-operator. Exit criteria gated per §9 (ticked or waived).

Phase 1

Onboarding

Pending

Each person onboarded across Claude tiers + Slack + Linear + Granola: Dennis first, then Marcelo, then Warren, Paul, Simon (Tier 1). Existing docs migrated into knowledge/.

Phase 2

Maturity

Planned

Auto-update tooling stable. Slack and Linear cloud agents introduced. CI gates and optimistic merge enabled.

Phase 3+

Autonomous

Planned

Per-user local autonomous agents (OpenClaw/Hermes) for Tier 3 builders. Shared cloud agents debate for cross-spoke coordination.

Phase 0 bootstrap — detail

Exit criteria

Phase 1 does not begin until every item below is confirmed.

ascend-os hub repo exists with knowledge/ skeleton, root CLAUDE.md, .claude/, and repos.yaml
OWNERS files at root and key subdirectories
product spoke exists as a hub subdir; its code repos mount via repos.yaml + bootstrap, working
/sync-ai-ops skill installed locally on Manny and Dennis
/promote-to-knowledge v1 installed locally on Manny and Dennis
One round-trip dry-run: Manny edits the hub CLAUDE.md → Dennis pulls the hub → composed context picks it up inside the spoke (no per-spoke sync step)
One promotion dry-run: CE session → /promote-to-knowledge → PR → merge
OWNERS file ratified by Marcelo, Manny and Dennis (Phase 0 exit sign-off)
Slack channel #ai-ops created; GitHub Action wired to post release tags

Day	Workstream	Owner	Output
D1	Hub repo + repos.yaml/bootstrap + root & per-subdir OWNERS	Manny	Hub skeleton + manifest + OWNERS
D2	Seed knowledge/ (conventions, glossary, people, 2 primers, first ADR)	Manny	knowledge/ skeleton
D3	/sync-ai-ops v1 + Slack #ai-ops + release-tag GitHub Action	Manny / Marcelo	Sync skill + channel + action
D4	Pilot spoke (product) + mounts + /promote-to-knowledge v1	Manny	Working spoke + promote skill
D5	Round-trip + promotion dry-runs + exit review (ratify OWNERS)	Dry-runs: Manny + Dennis · exit sign-off: Marcelo + Manny + Dennis	Phase 1 unblocked

Phase 0 risks & mitigations

Risk	Mitigation
Mount/bootstrap easy to trip on first try	Pair on the first bootstrap; document the steps in a mounting-spokes primer
/sync-ai-ops harder to build than expected	v1 is a thin wrapper around the bootstrap (clone/update per repos.yaml) + git diff; intelligence in v2
/promote-to-knowledge confused by CE noise	v1 lists unstaged docs/solutions/ entries and asks the human to select
Mounted repo paths drift from repos.yaml	/sync-ai-ops reconciles mounts against the manifest; bootstrap is idempotent
5-day Phase 0 is tight	Day breakdown is parallelizable (D2/D3 don't block each other); the D5 dry-runs can slip a day without blocking onboarding prep
OWNERS too restrictive before CI gates exist	Cross-cutting changes require multi-owner approval; routine changes auto-route to a single owner

Central architectural decision

Central architectural move · Uniform spoke structure

Every spoke — whether its output is Solidity contracts, a React app, regulatory procedures, or product strategy — shares the same directory shape: a CLAUDE.md that composes under the hub's by directory position, plus specs/, decisions/, work/, and OWNERS. What flexes is only work/: code teams mount their @AscendFi repos there; non-code teams track artifacts there directly. No code/non-code distinction.

This is the move that makes the Product++ "strategy + technical + marketing" triad coherent at the filesystem level — the three are disciplines inside one stream-aligned team, not three separate teams. Code and non-code output receive the same first-class treatment: versioned, spec-driven, decision-traceable, reviewable. The spoke type (stream-aligned, complicated subsystem, platform, enabling) informs ownership and cadence; the structure is identical.

Reference

Open implementation items (post-Phase 0)

/promote-to-knowledge v2 — intelligent selection (read frontmatter, score for promotion-worthiness, suggest target folder)
/sync-ai-ops v2 — smarter diff handling (collapse trivial diffs, surface semantic changes)
Cowork connector validation — verify Cowork (Claude Desktop app) GitHub + Drive connectors read knowledge/ end-to-end
Linear two-way sync validation — Slack ↔ Linear ↔ GitHub triangulate cleanly with PR + issue IDs
Billing to unblock Claude Team — Claude Team is blocked without a company card. Suggest opening a Mercury or Brex account; once billing exists, evaluate Team per-seat + personal Max stacking. (No PSG pitch needed.)
CI gates roadmap — skill-lint, dry-run runner, hook-safety, frontmatter validation (Phase 2+)
Slack agent + Linear agent integration (Phase 2)
/gbrain shared backend (Supabase) — Phase 2, once cross-spoke retrieval is a real need
product-backbone-web → hub migration — move the everything-doc into knowledge/backbone/
Nested-composition smoke-test — confirm CLAUDE.md + .claude/ compose across the nested-repo boundary into a mounted code repo (the leaf-lean assumption)
ascend-mcp build — Ascend MCP, mounts into the product spoke once it exists

Out of scope

Cloud-hosted OpenClaw/Hermes. Phase 3+ debate, not now.
Shared G-Brain backend (Supabase or otherwise). Defer to Phase 2; per-user local-only for now.
Migration of existing Ascend docs into /knowledge/. Phase 0 seeds a skeleton + 1–2 primers; migration is a Phase 1 deliverable.

Glossary

Remote plane	Shared, versioned layer — GitHub, Linear, Slack, /knowledge/
Local plane	Each person's tool surface (their tier)
Hub	ascend-os — the hub repo holding shared .claude/ + knowledge/ and nesting the spokes as subdirectories. (ascend-core is reserved for a future microservices architecture.)
Spoke	A team's working surface: a subdirectory of the hub holding CLAUDE.md + specs/ + decisions/ + work/ + OWNERS. One per team, uniform shape. Phase 1: product (stream-aligned), protocol (complicated subsystem), compliance (permanent specialist)
Mount	A code repo (canonical in @AscendFi) cloned into a spoke's work/ per repos.yaml, gitignored from the hub; keeps its own CLAUDE.md
Manifest (repos.yaml)	Declarative map of code-repo → spoke-mount path; a bootstrap step reconstructs the workspace from it
Team Topologies	Skelton/Pais framework: stream-aligned, complicated subsystem, platform, enabling (the team is permanent; only the facilitating interaction is time-boxed). All four are standing teams that each get a spoke; team type informs ownership + cadence
Subtree	Native git subtree — retained only for the spoke-graduation case; the default topology nests instead of replicating
SoI	System of Intelligence — shared quality (CLAUDE.md, skills, hooks, MCP)
SoR	System of Record — shared accuracy (Linear, GitHub PRs, knowledge/, Slack)
Tier 1 / Cowork	Cowork in the Claude Desktop app, with connectors — no terminal, no MCP CLI
Tier 2 / Claude Code in Desktop	Claude Code via the Claude Desktop app — adds MCP servers + skills; not the standalone CLI
Tier 3 / CLI	Claude Code CLI + full toolchain. A tooling surface, not a rank
OWNERS	Per-directory ownership file (renamed from CODEOWNERS for non-code paths)
SDD	Spec-Driven Development — spec.md → acceptance/ (one Gherkin Feature per file) → evals.md (the quantitative gate) → coverage-matrix.md on preservation specs → the verification ladder. Two genres: forward + preservation. Test code defaults to the mounted repo; spec-local harnesses permitted when they enforce the spec
ADR	Architecture Decision Record — durable decision in knowledge/decisions/
/gbrain (G-Brain)	Gstack's cross-instance context layer that queries the durable knowledge/ — per-user local for Tier 3 in Phase 1; shared backend (Supabase) deferred to Phase 2. Indexes promoted knowledge/, not the gitignored capture
OpenClaw · Hermes	Local autonomous agents (Phase 3+)
Claude Managed Agents	Cloud autonomous agents (Phase 2+)

Manny E. Reimi

CPO, Ascend · [email protected]

HLD v2.2.0 · revised 2026-07-07

Internal operating-model proposal. v2.2 (2026-07-07): §8 SDD patched to proven reality — two spec genres (forward + preservation), acceptance/ one-Feature-per-file, evals.md as the quantitative gate, coverage-matrix gate, verification ladder replacing the never-built eval bot; specs added as canonical behavior evidence; spec-pin staleness tripwire (ASC-61); roadmap re-dated (Phase 0 done Jun 19–22; Dennis-first onboarding). v2.1 (2026-06-14): session data → knowledge; /gbrain plan; config accuracy; roadmap compacted. v2.1.1: Marcelo added to the Phase 0 exit sign-off.