The one tie between this repository's Specs and HQ's design

actor

A reviewer who approves this repository's coordination design against HQ's delivered design.

problem

HQ's design is locked and private, this repository's design must read without it, and a reviewer needs to see which of HQ's rules each Spec answers and where it narrows them.

outcome

Every rule of HQ's orchestration that concerns coordination has its answering Spec named in one place, and every difference is stated.

rule.inPlugin line 57 · design/links.sdp.md:57

spec:hq.orchestration#rule.genericInPlugin is answered by spec:cc-agents.coordination as a whole, and spec:architecture.cc-agents is the component that carries it.

no example exercises it

rule.nativeMessaging line 58 · design/links.sdp.md:58

spec:hq.orchestration#rule.nativeMessaging is answered by spec:cc-agents.coordination.record, which adds the lasting record, and spec:cc-agents.coordination.chain, which adds each session's parent. The plugin delivers nothing itself.

no example exercises it

rule.switchesAlone line 59 · design/links.sdp.md:59

spec:hq.orchestration#rule.coordinationSwitchesAlone and spec:hq.orchestration#rule.relayUntilTrusted are answered by spec:cc-agents.coordination.adoption: coordination is on while the job runner is off.

no example exercises it

rule.boundaryCrossing line 60 · design/links.sdp.md:60

spec:hq.orchestration#rule.boundaryCrossing, which specifies delivery over the T3 bridge, is not answered: spec:decisions.coordination-native-first leaves that boundary unmeasured, and this design scopes its tree to records on the local machine and shows an external parent as an unresolved boundary. spec:cc-agents.coordination#question.bridge keeps the question open for the owner.

no example exercises it

rule.roleAndParent line 61 · design/links.sdp.md:61

spec:architecture.inbox, which says cc-agents keeps each session's role and parent, is narrowed by spec:cc-agents.coordination.boundary-only: the only roles are top and lead, and both follow from the parent.

no example exercises it

rule.acceptInbound line 62 · design/links.sdp.md:62

spec:decisions.coordination-native-first makes every session accept inbound messages a fleet setting that infra owns. spec:cc-agents.coordination.adoption reads that setting and reports which state holds, accept, hold, refuse or the host default, and never writes it.

no example exercises it

rule.boundaryOnly line 63 · design/links.sdp.md:63

spec:decisions.coordination-native-first says most work stays in one session and needs no messaging, and spec:cc-agents.coordination.boundary-only states when a second session is needed.

no example exercises it

rule.scanNeeds line 64 · design/links.sdp.md:64

spec:cc-agents.coordination.record carries what the vault's session scan needs to tell a peer's message from the owner's words: its own full session id, the peer as the host named it, UTC time, verbatim text, the sender's own id as authority on its own entry, the queue result and the receive outcome, and the working directory that assigns an entry to a project.

no example exercises it

rule.complementaryModels line 65 · design/links.sdp.md:65

spec:hq.orchestration#rule.complementaryModels is answered by spec:cc-agents.runner: GPT through spec:cc-agents.codex-adapter and every other family through spec:cc-agents.opencode-adapter occupy agent and Workflow roles beside Claude, with no Claude model working on their tasks.

no example exercises it

rule.runnerMovesRelayScripts line 66 · design/links.sdp.md:66

spec:hq.orchestration#rule.relayUntilTrusted names the job runner as the successor that must earn trust. spec:cc-agents.relay-job-type is the part that lets Relay's Workflow scripts move over by changing only the agent type, and whether the runner is on or off is a deployment matter that no Spec here states.

no example exercises it

rule.templatesForEndUsers line 67 · design/links.sdp.md:67

spec:hq.orchestration#rule.templates is answered for end users by spec:cc-agents.model-templates, and a user's own guide is a path in an option. Private and project-specific templates are not answered here.

no example exercises it

rule.contextForPeersUnanswered line 68 · design/links.sdp.md:68

spec:hq.orchestration#rule.contextForPeers is not answered: the job runner passes a lane its task only, and each harness loads its own skills and instructions as the user configured it.

no example exercises it

rule.sessionScanning line 69 · design/links.sdp.md:69

spec:hq.orchestration#rule.sessionScanning and spec:hq.orchestration#rule.scanFilters are answered by spec:cc-agents.coordination.session-scanning. The port takes the vault's whole skill scan-sessions, and from its skill catch-up what extraction needs: owner-extract.py, codex_reader.py, t3_reader.py, generated-text.json, t3-dump.py, and test_extract.py, test_readers.py and fixtures/. feed.mjs and compact.mjs stay out. The vault must not be deleted before this entry is delivered.

no example exercises it

rule.notHere line 70 · design/links.sdp.md:70

The inventory of the earlier orchestration found other generic capabilities that this design does not take up: restart and resume, pull request watching, insight capture, orphan job recovery, transcript digests and model templates. Each needs its own Spec, and none of them is coordination.

no example exercises it

0 unkeyed rules.

criteria

• A reviewer reads each rule against the HQ Spec it names and confirms the answering Spec states it.
• A search of specs/, plugin/ and tests/ finds no HQ Spec id, organisation, machine, client or person.

mode

reviewed

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Satisfying or referencing units: no recorded binding.
• Test or oracle bindings: no recorded binding.

Decisions

• Coordination is built on Claude Code's own messaging, and cc-agents adds only what that lacks

  Most work stays in one session with its agents and Workflows, and needs no messaging. Where work must cross a boundary inside one operating system, sessions find and message each other through Claude Code's own cross-session messaging, with every session accepting inbound messages. cc-agents adds only what that lacks: a lasting record of every message, and each session's place in a chain. Between operating systems, a message crosses through the T3 MCP route.

• Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trust

  The inbox, the chain and similar generic orchestration move from infra to cc-agents. Until cc-agents' job runner earns trust it stays off on every machine and Relay runs the harness jobs, while its coordination can already be on. Infra deploys the result to projects as an extension.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.