Capabilities

Epics and their declared refinement, from the capability map.

Each rollup counts distinct descendants of that epic. Scopes may overlap; epic rows are not added together.

Sessions that must message each other leave a record and a place in a chain

spec:cc-agents.coordination

6 distinct descendants · No examples · 1 decision.

Other model families run as real Claude Code agents

spec:cc-agents.runner

14 distinct descendants · No examples · No decisions.

HQ plans and designs across every project, and starts the engineering work

spec:hq.headquarters

21 distinct descendants · No examples · 9 decisions.

Sessions that must message each other leave a record and a place in a chain

Epic's own evidence

Sessions that must message each other leave a record and a place in a chain · spec:cc-agents.coordination · behavior · epic · stated defined · floor ready · implementation binding none · verifier binding none · 1 open question · No blocking questions

non-blocking: Should messages that cross an operating system boundary by a route outside the host's own messaging be recorded and joined to a chain, and how does a lead on another operating system reach its parent's tree?

Distinct descendants, excluding this epic: 6 Specs · No examples · 1 decision.

Stated rungs: idea 0 · scoped 0 · defined 6 · ready 0
Floors reached: none 0 · idea 0 · scoped 0 · defined 0 · ready 6
Kinds: behavior 5 · workflow 0 · example 0 · rule 0 · constraint 0 · model 0 · decision 1 · contract 0
Altitudes: epic 0 · feature 6 · story 0
Binding evidence: No Specs with implementation binding present · No Specs with verifier binding present
Questions: 5 open questions · No blocking questions

Show these Specs

Refinement · parent to child reading order

Arrows: refines (declared). Later visits repeat a Spec and link to its first occurrence.

The diagram as text

7 unique Specs; 7 rendered boxes.

spec:cc-agents.coordination: Sessions that must message each other leave a record and a place in a chain · epic
spec:cc-agents.coordination.adoption: Coordination switches on alone, and a project takes it up with one setting and its own boundaries · feature
spec:cc-agents.coordination.boundary-only: A second session exists only across a boundary one session cannot cross · feature
spec:cc-agents.coordination.chain: A lead states its parent once, and the chain is read from what leads stated · feature
spec:cc-agents.coordination.record: Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of them · feature
spec:cc-agents.coordination.session-scanning: A scan reads a project's sessions and traces each direction to its outcome · feature
spec:cc-agents.coordination.view: The person sees the chain and the traffic without asking a model · feature
spec:cc-agents.coordination.adoption refines spec:cc-agents.coordination · declared — how coordination is switched on alone and taken up by a project
spec:cc-agents.coordination.boundary-only refines spec:cc-agents.coordination · declared — settles what a chain still has to be when agents and Workflows carry most work
spec:cc-agents.coordination.chain refines spec:cc-agents.coordination · declared — the second thing the plugin adds to the host's messaging
spec:cc-agents.coordination.record refines spec:cc-agents.coordination · declared — the first thing the plugin adds to the host's messaging
spec:cc-agents.coordination.session-scanning refines spec:cc-agents.coordination · declared — reads what sessions leave behind, so that work is not lost between them
spec:cc-agents.coordination.view refines spec:cc-agents.coordination · declared — what the person sees of coordination

Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: mindmap. Chosen syntax: mindmap.

Mermaid source for Refinement · parent to child reading order

mindmap
  n0["Sessions that must message each other leave a record and a place in a chain · epic · spec:cc-agents.coordination"]
    n1["Coordination switches on alone, and a project takes it up with one setting and its own boundaries · feature · spec:cc-agents.coordination.adoption"]
    n2["A second session exists only across a boundary one session cannot cross · feature · spec:cc-agents.coordination.boundary-only"]
    n3["A lead states its parent once, and the chain is read from what leads stated · feature · spec:cc-agents.coordination.chain"]
    n4["Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of them · feature · spec:cc-agents.coordination.record"]
    n5["A scan reads a project's sessions and traces each direction to its outcome · feature · spec:cc-agents.coordination.session-scanning"]
    n6["The person sees the chain and the traffic without asking a model · feature · spec:cc-agents.coordination.view"]

Complete refinement text

Root
Sessions that must message each other leave a record and a place in a chain · spec:cc-agents.coordination · behavior · epic · stated defined · floor ready · implementation binding none · verifier binding none · 1 open question · No blocking questions
- non-blocking: Should messages that cross an operating system boundary by a route outside the host's own messaging be recorded and joined to a chain, and how does a lead on another operating system reach its parent's tree?
Parent: spec:cc-agents.coordination
Coordination switches on alone, and a project takes it up with one setting and its own boundaries · spec:cc-agents.coordination.adoption · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:cc-agents.coordination
Decision · A second session exists only across a boundary one session cannot cross
A second session exists only across a boundary one session cannot cross · spec:cc-agents.coordination.boundary-only · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:cc-agents.coordination
A lead states its parent once, and the chain is read from what leads stated · spec:cc-agents.coordination.chain · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:cc-agents.coordination
Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of them · spec:cc-agents.coordination.record · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · 3 open questions · No blocking questions
- non-blocking: Should the record hold the full text of messages in a project whose material is confidential?
- non-blocking: Can a received entry be joined to the sender's sent entry?
- non-blocking: Does the owner need crash-proof durability, an audit-grade log?
Parent: spec:cc-agents.coordination
A scan reads a project's sessions and traces each direction to its outcome · spec:cc-agents.coordination.session-scanning · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · 1 open question · No blocking questions
- non-blocking: Should the scan's scripts stay in Python or move to the plugin's Node?
Parent: spec:cc-agents.coordination
The person sees the chain and the traffic without asking a model · spec:cc-agents.coordination.view · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · 1 open question · No blocking questions
- non-blocking: Does the chain need a pane beside the chat?

Other model families run as real Claude Code agents

Epic's own evidence

Other model families run as real Claude Code agents · spec:cc-agents.runner · behavior · epic · stated defined · floor ready · implementation binding none · verifier binding none · 2 open questions · No blocking questions

non-blocking: Agent-team teammates are refused by design for now, and the question of whether they should ever be supported is deferred.
non-blocking: Grok runs through OpenCode only; a native adapter for it was left for later.

Distinct descendants, excluding this epic: 14 Specs · No examples · No decisions.

Stated rungs: idea 0 · scoped 0 · defined 1 · ready 13
Floors reached: none 0 · idea 0 · scoped 0 · defined 0 · ready 14
Kinds: behavior 13 · workflow 0 · example 0 · rule 0 · constraint 0 · model 0 · decision 0 · contract 1
Altitudes: epic 0 · feature 14 · story 0
Binding evidence: 13 Specs with implementation binding present · 13 Specs with verifier binding present
Questions: 24 open questions · No blocking questions

Show these Specs

Refinement · parent to child reading order

Arrows: refines (declared). Later visits repeat a Spec and link to its first occurrence.

Scroll horizontally to read the whole drawing.

The diagram as text

15 unique Specs; 15 rendered boxes.

spec:cc-agents.runner: Other model families run as real Claude Code agents · epic
spec:cc-agents.adapter-contract: One adapter module per harness, behind one contract · feature
spec:cc-agents.codex-adapter: GPT runs through the user's Codex, one app-server per turn · feature
spec:cc-agents.cross-session-slots: A cap on concurrent turns holds across every Claude session on the machine · feature
spec:cc-agents.exact-answer: The agent's last message is exactly the harness's final answer · feature
spec:cc-agents.installation: The plugin installs from a marketplace, updates by version and changes nothing global · feature
spec:cc-agents.machine-guard: A critically loaded machine refuses new agents and stops none · feature
spec:cc-agents.mod-layer: The mod answers an agent's steps from the sidecar and never calls a model · feature
spec:cc-agents.model-templates: Claude reads a model guide that fits the harnesses installed here · feature
spec:cc-agents.opencode-adapter: Every other family runs through the user's OpenCode service · feature
spec:cc-agents.pane: The session's agents, their caps and the machine are always in view · feature
spec:cc-agents.relay-job-type: The job agent takes Relay's header and returns Relay's state block · feature
spec:cc-agents.sidecar: One sidecar per Claude session owns the session's harness turns · feature
spec:cc-agents.steering-and-stop: A message reaches the running turn at once, and a stop ends the harness turn · feature
spec:cc-agents.work-containment: A guard ends the groups a harness turn started and it has seen, even when the sidecar is killed · feature
spec:cc-agents.adapter-contract refines spec:cc-agents.runner · declared
spec:cc-agents.codex-adapter refines spec:cc-agents.runner · declared
spec:cc-agents.cross-session-slots refines spec:cc-agents.runner · declared
spec:cc-agents.exact-answer refines spec:cc-agents.runner · declared
spec:cc-agents.installation refines spec:cc-agents.runner · declared
spec:cc-agents.machine-guard refines spec:cc-agents.runner · declared
spec:cc-agents.mod-layer refines spec:cc-agents.runner · declared
spec:cc-agents.model-templates refines spec:cc-agents.runner · declared
spec:cc-agents.opencode-adapter refines spec:cc-agents.runner · declared
spec:cc-agents.pane refines spec:cc-agents.runner · declared
spec:cc-agents.relay-job-type refines spec:cc-agents.runner · declared
spec:cc-agents.sidecar refines spec:cc-agents.runner · declared
spec:cc-agents.steering-and-stop refines spec:cc-agents.runner · declared
spec:cc-agents.work-containment refines spec:cc-agents.runner · declared

Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: mindmap. Chosen syntax: mindmap.

Mermaid source for Refinement · parent to child reading order

mindmap
  n0["Other model families run as real Claude Code agents · epic · spec:cc-agents.runner"]
    n1["One adapter module per harness, behind one contract · feature · spec:cc-agents.adapter-contract"]
    n2["GPT runs through the user's Codex, one app-server per turn · feature · spec:cc-agents.codex-adapter"]
    n3["A cap on concurrent turns holds across every Claude session on the machine · feature · spec:cc-agents.cross-session-slots"]
    n4["The agent's last message is exactly the harness's final answer · feature · spec:cc-agents.exact-answer"]
    n5["The plugin installs from a marketplace, updates by version and changes nothing global · feature · spec:cc-agents.installation"]
    n6["A critically loaded machine refuses new agents and stops none · feature · spec:cc-agents.machine-guard"]
    n7["The mod answers an agent's steps from the sidecar and never calls a model · feature · spec:cc-agents.mod-layer"]
    n8["Claude reads a model guide that fits the harnesses installed here · feature · spec:cc-agents.model-templates"]
    n9["Every other family runs through the user's OpenCode service · feature · spec:cc-agents.opencode-adapter"]
    n10["The session's agents, their caps and the machine are always in view · feature · spec:cc-agents.pane"]
    n11["The job agent takes Relay's header and returns Relay's state block · feature · spec:cc-agents.relay-job-type"]
    n12["One sidecar per Claude session owns the session's harness turns · feature · spec:cc-agents.sidecar"]
    n13["A message reaches the running turn at once, and a stop ends the harness turn · feature · spec:cc-agents.steering-and-stop"]
    n14["A guard ends the groups a harness turn started and it has seen, even when the sidecar is killed · feature · spec:cc-agents.work-containment"]

Complete refinement text

Root
Other model families run as real Claude Code agents · spec:cc-agents.runner · behavior · epic · stated defined · floor ready · implementation binding none · verifier binding none · 2 open questions · No blocking questions
- non-blocking: Agent-team teammates are refused by design for now, and the question of whether they should ever be supported is deferred.
- non-blocking: Grok runs through OpenCode only; a native adapter for it was left for later.
Parent: spec:cc-agents.runner
One adapter module per harness, behind one contract · spec:cc-agents.adapter-contract · contract · feature · stated ready · floor ready · implementation binding present · verifier binding present · 3 open questions · No blocking questions
- non-blocking: CONTRACT.md says the cap key names the account a turn spends, while the code keys Codex by one machine-wide bucket named codex and OpenCode by opencode:<provider>, which does not identify distinct accounts.
- non-blocking: The sidecar also passes options to check for a job and options and log to the turn constructor, which CONTRACT.md does not list; OpenCode ignores them.
- non-blocking: Early reports describe a four-method adapter without preparation and reaping; the current contract and code add both.
Parent: spec:cc-agents.runner
GPT runs through the user's Codex, one app-server per turn · spec:cc-agents.codex-adapter · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 2 open questions · No blocking questions
- non-blocking: These behaviours are exercised against a fake app-server that speaks Codex's protocol; a real Codex is exercised only by the live suite under tests/live, which runs outside the graph and outside the gate.
- non-blocking: The README calls the Codex cap per account, while the adapter keeps a single machine-wide bucket named codex whose default is the machine's share.
Parent: spec:cc-agents.runner
A cap on concurrent turns holds across every Claude session on the machine · spec:cc-agents.cross-session-slots · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 1 open question · No blocking questions
- non-blocking: The caps option also accepts a bare harness name, which the code applies to every key of that harness not named itself; no test pins that fallback.
Parent: spec:cc-agents.runner
The agent's last message is exactly the harness's final answer · spec:cc-agents.exact-answer · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 1 open question · No blocking questions
- non-blocking: An interrupted turn ends with a note that it was interrupted, and a completed turn that returned no text ends with a note saying so; both are built and no test pins their wording.
Parent: spec:cc-agents.runner
The plugin installs from a marketplace, updates by version and changes nothing global · spec:cc-agents.installation · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · 2 open questions · No blocking questions
- non-blocking: The marketplace, the manifest and the install script are JSON and shell, so no anchor binds them and the graph derives neither implemented nor has-verifier here; the install test run is npm run test:install.
- non-blocking: The README says Linux was not tried live, while a smoke run proved basic execution there; the sentence is broader than the evidence.
Parent: spec:cc-agents.runner
A critically loaded machine refuses new agents and stops none · spec:cc-agents.machine-guard · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · No open questions · No blocking questions
Parent: spec:cc-agents.runner
The mod answers an agent's steps from the sidecar and never calls a model · spec:cc-agents.mod-layer · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 2 open questions · No blocking questions
- non-blocking: Built but not exercised by any test: a spawn that asks to be a team teammate is denied; the agent.spawn catch handler denies an agent the hook could not prepare; the internal progress tool answers "Still working." and is denied to agents that are not ours; a follow-up message to an ended agent starts a new run on the same thread; a step aborted mid-stream interrupts the turn; the turn-complete hook of an agent stopped before its first step asks the sidecar to interrupt it.
- non-blocking: The steps hand over through an internal progress tool call, so a step shows its progress only when it ends, every 20 seconds by default, never token by token.
Parent: spec:cc-agents.runner
Claude reads a model guide that fits the harnesses installed here · spec:cc-agents.model-templates · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 2 open questions · No blocking questions
- non-blocking: The README says the templates refuse nothing, while two quality templates still say never to use Opus on search; the correction waits with the source the templates are generated from.
- non-blocking: The sync script copies only the cost and quality variations, refuses a file that names a private word before it writes anything, and stamps each copy with its source; no test exercises it.
Parent: spec:cc-agents.runner
Every other family runs through the user's OpenCode service · spec:cc-agents.opencode-adapter · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 3 open questions · No blocking questions
- non-blocking: Reading the transcript once a second means text arrives a paragraph at a time and each read is a process; a streaming transport that needs a stored pairing credential was not adopted.
- non-blocking: These behaviours are exercised against a fake OpenCode service; a real service is exercised only by the live scripts under tests/live, outside the graph and the gate.
- non-blocking: OpenCode refuses the mode yolo, which the Relay-compatible job header accepts for every backend, so a Kimi, Grok or ZCode job that states yolo is refused by the check; no test pins that pairing.
Parent: spec:cc-agents.runner
The session's agents, their caps and the machine are always in view · spec:cc-agents.pane · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 1 open question · No blocking questions
- non-blocking: The Desktop band, the VS Code extension and Linux were not tried in a real session; the pane is verified against scripted status answers and mod mounts only.
Parent: spec:cc-agents.runner
The job agent takes Relay's header and returns Relay's state block · spec:cc-agents.relay-job-type · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 4 open questions · No blocking questions
- non-blocking: The block of a job that was cancelled or failed, with state cancelled or failed and an error line, and a relative add-dir refused, are built and no test pins them.
- non-blocking: Relay's job defaulted to a sandbox-free mode, while this agent defaults to write and runs without a sandbox only when the header states yolo.
- non-blocking: The keys fast, grok-home and kimi-home are accepted and ignored with a note, and the notes' wording is not pinned by a test.
- non-blocking: Backends kimi, grok and zcode run on OpenCode, which refuses yolo, so a job that states yolo on those backends is refused by the check; no test pins that.
Parent: spec:cc-agents.runner
One sidecar per Claude session owns the session's harness turns · spec:cc-agents.sidecar · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 2 open questions · No blocking questions
- non-blocking: The sidecar also exits two minutes after its last turn and its last waiting spawn, refuses a second concurrent turn for the same agent, and fails a turn whose preparation fails without running it; no test pins any of the three.
- non-blocking: The README says the agents run inside the Claude Code process, while the code runs them in a detached sidecar and separate harness processes whose lifetime is tied to the host.
Parent: spec:cc-agents.runner
A message reaches the running turn at once, and a stop ends the harness turn · spec:cc-agents.steering-and-stop · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · No open questions · No blocking questions
Parent: spec:cc-agents.runner
A guard ends the groups a harness turn started and it has seen, even when the sidecar is killed · spec:cc-agents.work-containment · behavior · feature · stated ready · floor ready · implementation binding present · verifier binding present · 1 open question · No blocking questions
- non-blocking: A process that leaves the guard's group and is reparented to the system between two scans is in no record, so the guard neither ends it nor counts it. Should the guarantee grow to cover it?

HQ plans and designs across every project, and starts the engineering work

Epic's own evidence

HQ plans and designs across every project, and starts the engineering work · spec:hq.headquarters · behavior · epic · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions

Distinct descendants, excluding this epic: 21 Specs · No examples · 9 decisions.

Stated rungs: idea 0 · scoped 4 · defined 17 · ready 0
Floors reached: none 0 · idea 0 · scoped 1 · defined 2 · ready 18
Kinds: behavior 10 · workflow 1 · example 0 · rule 0 · constraint 0 · model 1 · decision 9 · contract 0
Altitudes: epic 0 · feature 21 · story 0
Binding evidence: No Specs with implementation binding present · No Specs with verifier binding present
Questions: 4 open questions · 1 blocking question

Show these Specs

Refinement · parent to child reading order

Arrows: refines (declared). Later visits repeat a Spec and link to its first occurrence.

The diagram as text

22 unique Specs; 11 rendered boxes.

spec:hq.headquarters: HQ plans and designs across every project, and starts the engineering work · epic
spec:architecture.cc-agents: cc-agents · feature
spec:cc-agents.hq-links: The one tie between this repository's Specs and HQ's design · feature
spec:architecture.inbox: The inbox · feature
spec:architecture.relay: Relay · feature
spec:decisions.hq-starts-engineering: HQ does the core design and starts detailed work in the engineering environment · feature
spec:decisions.recovery-closed: The recovery chain stops and this corpus replaces its master plan · feature
spec:decisions.separate-repositories: Repositories stay separate, and the plan names work in them in prose · feature
spec:hq.context: HQ's private context stays in one place and stays clean · feature
spec:decisions.client-material-deferred: HQ holds everything until a per-project review screens client material · feature
spec:hq.delivery-planning: SDP carries delivery planning across projects · feature
spec:decisions.sdp-holds-the-plan: HQ's plan for all software delivery is an SDP corpus in a small repository of its own · feature
spec:hq.engineering-environment: The engineering environment runs apart from HQ · feature
spec:hq.environment: HQ runs in an isolated environment that infra manages · feature
spec:hq.infra: Infra delivers configuration by projection, under HQ's plan · feature
spec:decisions.isolated-infra-manages-hq: Infra is super isolated and manages the isolated HQ · feature
spec:hq.model: HQ's vocabulary · feature
spec:hq.orchestration: Orchestration lives in one plugin, apart from infra and HQ · feature
spec:cc-agents.hq-links: The one tie between this repository's Specs and HQ's design · feature · repeat
spec:decisions.coordination-native-first: Coordination is built on Claude Code's own messaging, and cc-agents adds only what that lacks · feature
spec:decisions.orchestration-leaves-infra: Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trust · feature
spec:hq.session-handoff: HQ hands a settled piece to a detailed session · feature
spec:decisions.design-locked-by-projection: An approved part of the graph reaches engineering as a read-only projection · feature
spec:architecture.cc-agents refines spec:hq.headquarters · declared — one of the systems HQ's design names
spec:architecture.inbox refines spec:hq.headquarters · declared — one of the systems HQ's design names
spec:architecture.relay refines spec:hq.headquarters · declared — one of the systems HQ's design names
spec:cc-agents.hq-links refines spec:architecture.cc-agents · declared — the job runner and the coordination design are the parts of this component that exist in this repository
spec:cc-agents.hq-links refines spec:hq.orchestration · declared — this repository's coordination design answers the rules that HQ's orchestration states
spec:decisions.client-material-deferred refines spec:hq.context · declared — settles what HQ holds until per-project review
spec:decisions.coordination-native-first refines spec:hq.orchestration · declared — settles what coordination is built from once it leaves infra
spec:decisions.design-locked-by-projection refines spec:hq.session-handoff · declared — settles how a settled design reaches the engineering repository and stays locked
spec:decisions.hq-starts-engineering refines spec:hq.headquarters · declared — settles HQ's altitude and where detailed work happens
spec:decisions.isolated-infra-manages-hq refines spec:hq.infra · declared — records how infra and HQ stand towards each other
spec:decisions.orchestration-leaves-infra refines spec:hq.orchestration · declared — settles where generic orchestration lives and what runs jobs until then
spec:decisions.recovery-closed refines spec:hq.headquarters · declared — settles what of the recovery's master plan HQ's plan keeps
spec:decisions.sdp-holds-the-plan refines spec:hq.delivery-planning · declared — settles what carries HQ's plan and where it sits
spec:decisions.separate-repositories refines spec:hq.headquarters · declared — settles how HQ's plan touches other repositories
spec:hq.context refines spec:hq.headquarters · declared — names where HQ's context lives and how it stays clean
spec:hq.delivery-planning refines spec:hq.headquarters · declared — one of the aspects the owner names
spec:hq.engineering-environment refines spec:hq.headquarters · declared — the place HQ's work goes to be executed
spec:hq.environment refines spec:hq.headquarters · declared — gives HQ's isolation its home
spec:hq.infra refines spec:hq.headquarters · declared — one of the aspects the owner names
spec:hq.model refines spec:hq.headquarters · declared — names what the HQ design speaks of
spec:hq.orchestration refines spec:hq.headquarters · declared — names how work moves between harnesses, models and machines
spec:hq.session-handoff refines spec:hq.headquarters · declared — realizes how HQ starts the work it does not do itself

Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: mindmap. Chosen syntax: flowchart BT because the drawing has repeated parentage, a fold.

Mermaid source for Refinement · parent to child reading order

flowchart BT
  n0["HQ plans and designs across every project, and starts the engineering work · epic · spec:hq.headquarters"]
  n1["cc-agents · feature · spec:architecture.cc-agents"]
  n2["The inbox · feature · spec:architecture.inbox"]
  n3["Relay · feature · spec:architecture.relay"]
  n4["HQ does the core design and starts detailed work in the engineering environment · feature · spec:decisions.hq-starts-engineering"]
  n5["The recovery chain stops and this corpus replaces its master plan · feature · spec:decisions.recovery-closed"]
  n6["Repositories stay separate, and the plan names work in them in prose · feature · spec:decisions.separate-repositories"]
  n7["HQ's private context stays in one place and stays clean · feature · spec:hq.context"]
  n8["folded · 13 unique Specs · branch of spec:hq.headquarters"]
  %% folded diagram.spec:hq.headquarters.capability.branch.spec#37;3Ahq.headquarters.folded: spec:hq.delivery-planning, spec:decisions.sdp-holds-the-plan, spec:hq.engineering-environment, spec:hq.environment, spec:hq.infra, spec:decisions.isolated-infra-manages-hq, spec:hq.model, spec:hq.orchestration, spec:cc-agents.hq-links, spec:decisions.coordination-native-first, spec:decisions.orchestration-leaves-infra, spec:hq.session-handoff, spec:decisions.design-locked-by-projection
  n9["The one tie between this repository's Specs and HQ's design · feature · spec:cc-agents.hq-links"]
  n10["HQ holds everything until a per-project review screens client material · feature · spec:decisions.client-material-deferred"]
  n1 -->|"refines · declared"| n0
  n2 -->|"refines · declared"| n0
  n3 -->|"refines · declared"| n0
  n9 -->|"refines · declared"| n1
  n10 -->|"refines · declared"| n7
  n4 -->|"refines · declared"| n0
  n5 -->|"refines · declared"| n0
  n6 -->|"refines · declared"| n0
  n7 -->|"refines · declared"| n0
  n8 -->|"refines · declared"| n0

Complete refinement text

Root
HQ plans and designs across every project, and starts the engineering work · spec:hq.headquarters · behavior · epic · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
cc-agents · spec:architecture.cc-agents · behavior · feature · stated scoped · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:architecture.cc-agents
The one tie between this repository's Specs and HQ's design · spec:cc-agents.hq-links · behavior · feature · stated defined · floor defined · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
The inbox · spec:architecture.inbox · behavior · feature · stated scoped · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
Relay · spec:architecture.relay · behavior · feature · stated scoped · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
Decision · HQ does the core design and starts detailed work in the engineering environment
HQ does the core design and starts detailed work in the engineering environment · spec:decisions.hq-starts-engineering · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
Decision · The recovery chain stops and this corpus replaces its master plan
The recovery chain stops and this corpus replaces its master plan · spec:decisions.recovery-closed · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
Decision · Repositories stay separate, and the plan names work in them in prose
Repositories stay separate, and the plan names work in them in prose · spec:decisions.separate-repositories · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
HQ's private context stays in one place and stays clean · spec:hq.context · behavior · feature · stated scoped · floor scoped · implementation binding none · verifier binding none · 1 open question · 1 blocking question
- blocking: How is client material handled, project by project: what is screened, and where?
Parent: spec:hq.context
Decision · HQ holds everything until a per-project review screens client material
HQ holds everything until a per-project review screens client material · spec:decisions.client-material-deferred · decision · feature · stated defined · floor defined · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
SDP carries delivery planning across projects · spec:hq.delivery-planning · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.delivery-planning
Decision · HQ's plan for all software delivery is an SDP corpus in a small repository of its own
HQ's plan for all software delivery is an SDP corpus in a small repository of its own · spec:decisions.sdp-holds-the-plan · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
The engineering environment runs apart from HQ · spec:hq.engineering-environment · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
HQ runs in an isolated environment that infra manages · spec:hq.environment · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
Infra delivers configuration by projection, under HQ's plan · spec:hq.infra · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · 2 open questions · No blocking questions
- non-blocking: Where did infra's orchestration trouble start, at the takeover of PR #13 where Kimi K3.1 replaced Opus 5.5 or earlier, and which earlier delivery does infra's tooling roll back to?
- non-blocking: Is HQ ready to take over infra, and what must hold first?
Parent: spec:hq.infra
Decision · Infra is super isolated and manages the isolated HQ
Infra is super isolated and manages the isolated HQ · spec:decisions.isolated-infra-manages-hq · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
HQ's vocabulary · spec:hq.model · model · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
Orchestration lives in one plugin, apart from infra and HQ · spec:hq.orchestration · behavior · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.orchestration
The one tie between this repository's Specs and HQ's design · spec:cc-agents.hq-links · behavior · feature · stated defined · floor defined · implementation binding none · verifier binding none · No open questions · No blocking questions · Repeat of first occurrence
Parent: spec:hq.orchestration
Decision · Coordination is built on Claude Code's own messaging, and cc-agents adds only what that lacks
Coordination is built on Claude Code's own messaging, and cc-agents adds only what that lacks · spec:decisions.coordination-native-first · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.orchestration
Decision · Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trust
Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trust · spec:decisions.orchestration-leaves-infra · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions
Parent: spec:hq.headquarters
HQ hands a settled piece to a detailed session · spec:hq.session-handoff · workflow · feature · stated defined · floor ready · implementation binding none · verifier binding none · 1 open question · No blocking questions
- non-blocking: Which harness and models does a detailed session run on?
Parent: spec:hq.session-handoff
Decision · An approved part of the graph reaches engineering as a read-only projection
An approved part of the graph reaches engineering as a read-only projection · spec:decisions.design-locked-by-projection · decision · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions

No epic reaches these Specs

Show these Specs

Refinement · parent to child reading order

Arrows: refines (declared). Later visits repeat a Spec and link to its first occurrence.

The diagram as text

1 unique Specs; 1 rendered boxes.

spec:hq.isolation: HQ works apart from detailed work, and infra manages its environment · feature
Unreached ids: spec:hq.isolation

Mermaid source

Copyable source; the Studio draws static SVG.

Preferred syntax: mindmap. Chosen syntax: flowchart BT because the drawing has an unreached band.

Mermaid source for Refinement · parent to child reading order

flowchart BT
  n0["HQ works apart from detailed work, and infra manages its environment · feature · spec:hq.isolation"]

Complete refinement text

Root
HQ works apart from detailed work, and infra manages its environment · spec:hq.isolation · constraint · feature · stated defined · floor ready · implementation binding none · verifier binding none · No open questions · No blocking questions

Composing (0)

Composing needs the script.