None.

None.

actor

HQ, starting work; the agent leading a detailed session.

problem

A session that starts from copied context builds on stale status and misses how the target repository works, and its result does not come back to the plan.

outcome

A settled piece of the plan reaches the engineering environment as a session that names its Specs and its target, works by the target's own rules, and comes back as a pull request HQ can read.

Open questions

• non-blocking · question.sessionModels line 36 · specs/hq/session-handoff.sdp.md:36 · Which harness and models does a detailed session run on?Decider: delegatedProvisional: The session's lead chooses per task, under the orchestration aspect's rules.

rule.selects line 42 · specs/hq/session-handoff.sdp.md:42

HQ selects a settled entry from the roadmap and names the target repository, the Specs it rests on and what the session must return.

no example exercises it

rule.starts line 43 · specs/hq/session-handoff.sdp.md:43

HQ starts a project session in the target repository's checkout in the engineering environment through T3's MCP.

no example exercises it

rule.works line 44 · specs/hq/session-handoff.sdp.md:44

The session does the detailed planning, design and execution there, under that repository's own instructions, skills, tests and gate.

no example exercises it

rule.returns line 45 · specs/hq/session-handoff.sdp.md:45

The session returns the pull request's URL, head commit, and checks and reviews, plus any new standing directions, decision points and cross-project context, which HQ routes to their one home.

no example exercises it

rule.updates line 46 · specs/hq/session-handoff.sdp.md:46

HQ reviews the pull request against the named Specs and the target's gate, and names the work delivered only after it merges.

no example exercises it

rule.targetOwnsDetail line 47 · specs/hq/session-handoff.sdp.md:47

Detailed design lands in the target repository, in its own SDP corpus where it has one; this corpus names it and copies none of it.

no example exercises it

rule.targetGate line 48 · specs/hq/session-handoff.sdp.md:48

A session answers to the target repository's own tests and gate, and HQ's plan never stands in for them.

no example exercises it

rule.briefNamesSpecs line 49 · specs/hq/session-handoff.sdp.md:49

A session's brief names Specs, a Pack and the target, and carries a read-only projection of them, the context bundle (recipe 36); it copies no status and no other plan text.

no example exercises it

rule.lockedDesign line 50 · specs/hq/session-handoff.sdp.md:50

An approved part of the graph reaches the target repository as a read-only projection, regenerated from this corpus and refused by the target's gate if edited.

no example exercises it

0 unkeyed rules.

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

• spec:decisions.design-locked-by-projection

  When a part of the graph reaches an agreed status, it is delivered to the target repository as a read-only projection: the selected Specs with their ancestors, the decisions behind them and every Spec their text mentions. The repository refines and implements against it, and its own gate refuses any edit to it.

• spec:decisions.hq-starts-engineering

  HQ does long-term planning, high-level design and cross-project context. When a piece settles, HQ starts detailed planning and execution as sessions in the engineering environment, and does not do that work itself.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

Agents that delegate work, and the owner who watches them.

problem

Generic coordination sits in infra because a bootstrap needed it, so every project's orchestration depends on the repository that should know least about it.

outcome

The inbox, the chain and the other generic orchestration live in cc-agents, Relay's rewrite, which infra deploys to projects as an extension.

value

Models with complementary characteristics, each with its own taste and approach, work together on one task.

rule.genericInPlugin line 31 · specs/hq/orchestration.sdp.md:31

The inbox, the chain and similar generic orchestration live in cc-agents, not in infra and not in HQ.

no example exercises it

rule.relayUntilTrusted line 32 · specs/hq/orchestration.sdp.md:32

Relay runs the harness jobs until cc-agents' job runner earns the owner's trust, and that runner stays off on every machine until then.

no example exercises it

rule.coordinationSwitchesAlone line 33 · specs/hq/orchestration.sdp.md:33

Coordination in cc-agents can be on where its job runner is off, because infra gives up the inbox before the runner has earned trust.

no example exercises it

rule.nativeMessaging line 34 · specs/hq/orchestration.sdp.md:34

Inside one operating system, sessions message each other through Claude Code's own cross-session messaging, and cc-agents adds only a lasting record and each session's role and parent.

no example exercises it

rule.boundaryCrossing line 35 · specs/hq/orchestration.sdp.md:35

A message between operating systems crosses through the T3 MCP route, and nothing inside one operating system depends on that route.

no example exercises it

rule.complementaryModels line 36 · specs/hq/orchestration.sdp.md:36

Complex scope runs as workflows that mix Claude with other providers' models through Relay.

no example exercises it

rule.infraDeploysExtension line 37 · specs/hq/orchestration.sdp.md:37

Infra deploys the orchestration extension and its templates to projects.

no example exercises it

rule.sessionScanning line 38 · specs/hq/orchestration.sdp.md:38

Session scanning moves into cc-agents before the current vault is deleted, with the extraction of the owner's words it depends on, because that record is what lets a scan trace each direction to its outcome.

no example exercises it

rule.scanFilters line 39 · specs/hq/orchestration.sdp.md:39

A scan's prompt names the context it filters out, so that it reads pure context from the repositories and not the orchestration noise that vault sessions repeat.

no example exercises it

rule.templates line 40 · specs/hq/orchestration.sdp.md:40

Templates for end users, private templates and project-specific templates are scope for cc-agents.

no example exercises it

rule.skillsPerSession line 41 · specs/hq/orchestration.sdp.md:41

Infra prepares the list of skills for each session, so that a session loads only what its task needs.

no example exercises it

rule.contextForPeers line 42 · specs/hq/orchestration.sdp.md:42

A lane on another provider receives the Claude Code skills and documentation its task needs.

no example exercises it

0 unkeyed rules.

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

• spec:decisions.coordination-native-first

  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.

• spec:decisions.orchestration-leaves-infra

  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.

• spec:decisions.recovery-closed

  The recovery chain stops and this SDP corpus replaces its master plan. The scan items' purpose, recovering valid owner directions and sufficient evidence for rollback and takeover, remains with the context and infra Specs. Existing evidence is used first; any remaining investigation is bounded detailed work, not a revival of the recovery chain.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

The owner, and the agents changing what the fleet runs.

problem

Facts that change, such as addresses and project names, spread through skills and briefs, and the repository that can change every machine sits outside any plan.

outcome

Infra is isolated, delivers configuration, skills and services to every machine as projections of one source, manages the isolated HQ, and takes its direction from HQ's plan.

Open questions

• non-blocking · question.rollbackPoint line 36 · specs/hq/infra.sdp.md:36 · 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?Decider: owner
• non-blocking · question.takeover line 38 · specs/hq/infra.sdp.md:38 · Is HQ ready to take over infra, and what must hold first?Decider: owner

rule.projectionDelivery line 43 · specs/hq/infra.sdp.md:43

Infra delivers configuration to machines as projections of one source.

no example exercises it

rule.changingFacts line 44 · specs/hq/infra.sdp.md:44

A fact that changes, such as an address, a project name or a version pin, lives once in infra's configuration and reaches skills and sessions from there.

no example exercises it

rule.managesHq line 45 · specs/hq/infra.sdp.md:45

Infra provisions and manages the isolated HQ.

no example exercises it

rule.hqPlansInfra line 46 · specs/hq/infra.sdp.md:46

HQ plans infra's work, with access designed in infra.

no example exercises it

rule.noDependencyCalls line 47 · specs/hq/infra.sdp.md:47

HQ imports nothing from infra and calls none of its dependencies; it names infra's work in prose by repository and pull request.

no example exercises it

rule.ownTests line 48 · specs/hq/infra.sdp.md:48

Infra's own tests, fuzzer-based tests among them, are the bar for any change to it.

no example exercises it

rule.deliversToProjects line 49 · specs/hq/infra.sdp.md:49

Once HQ has taken infra over, infra deploys to each project with that project's own settings.

no example exercises it

0 unkeyed rules.

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

• spec:decisions.isolated-infra-manages-hq

  HQ is isolated in the owner's sense: it keeps long-term planning, high-level design and cross-project context apart from detailed planning and execution, which it initiates as sessions in the engineering environment. Infra is super isolated and manages the isolated HQ. Deployment and access boundaries are designed in infra, and the owner's use of 'isolated' does not itself select a machine, kernel or network policy.

• spec:decisions.orchestration-leaves-infra

  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.

• spec:decisions.recovery-closed

  The recovery chain stops and this SDP corpus replaces its master plan. The scan items' purpose, recovering valid owner directions and sufficient evidence for rollback and takeover, remains with the context and infra Specs. Existing evidence is used first; any remaining investigation is bounded detailed work, not a revival of the recovery chain.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

The owner, and the HQ sessions that need context.

problem

Context imported from sessions and scans is scattered across files, dashboards, inboxes and copies, and some of it is wrong.

outcome

Each fact has one home, private context stays in Kontrapunkt, and client material is handled project by project once infra deploys to projects.

Open questions

• blocking · question.clientMaterial line 31 · specs/hq/context.sdp.md:31 · How is client material handled, project by project: what is screened, and where?Decider: ownerTrigger: infra deploys per-project settings

rule.privateInKontrapunkt line 37 · specs/hq/context.sdp.md:37

Private context and client facts live in Kontrapunkt, and this corpus names a client by its slug only.

no example exercises it

rule.holdsEverything line 38 · specs/hq/context.sdp.md:38

Until the per-project review, HQ holds all of the owner's context, clients included, and nothing in HQ's tooling changes for client material.

no example exercises it

rule.oneHome line 39 · specs/hq/context.sdp.md:39

A fact has one home, in the graph, in the configuration infra delivers or in Kontrapunkt, and skills and briefs point to it and never copy it.

no example exercises it

rule.directionsLand line 40 · specs/hq/context.sdp.md:40

A standing direction the owner gives lands as a Spec edit here, or in Kontrapunkt when it is private, so that it does not have to be rediscovered from sessions.

no example exercises it

rule.inboxIsProposal line 41 · specs/hq/context.sdp.md:41

An inbox item is a proposal and never scope until it lands as a Spec edit.

no example exercises it

rule.vaultProjection line 42 · specs/hq/context.sdp.md:42

This corpus projects into Kontrapunkt with sdp vault.

no example exercises it

0 unkeyed rules.

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

• spec:decisions.client-material-deferred

  Until infra starts deploying to projects, HQ holds everything and nothing in HQ's tooling changes for client material. A security review then decides, project by project, what is screened and where. The screening the scan tooling does by default stays as it is until then.

• spec:decisions.recovery-closed

  The recovery chain stops and this SDP corpus replaces its master plan. The scan items' purpose, recovering valid owner directions and sufficient evidence for rollback and takeover, remains with the context and infra Specs. Existing evidence is used first; any remaining investigation is bounded detailed work, not a revival of the recovery chain.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

The owner, reading across projects from HQ.

problem

About fifty projects each hold their own plan, or none, and nothing shows them together.

outcome

Every project that needs it manages its delivery in its own SDP corpus, and HQ reads across them through projections.

rule.sdpPerProject line 29 · specs/hq/delivery-planning.sdp.md:29

Any project can adopt SDP to manage its own delivery, from idea to implemented.

no example exercises it

rule.crossProjectProjections line 30 · specs/hq/delivery-planning.sdp.md:30

The cross-project view is a read-time projection over each corpus's graph, heuristic first, with LLM-powered projections on top.

no example exercises it

rule.sdpInSdp line 31 · specs/hq/delivery-planning.sdp.md:31

SDP's own development stays in SDP's repository, and this corpus names that work in prose.

no example exercises it

rule.readByScript line 32 · specs/hq/delivery-planning.sdp.md:32

Agents read the graph by scripting it, beside grep and their other tools, and the plan asks SDP for no fixed set of verbs.

no example exercises it

0 unkeyed rules.

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

• spec:decisions.sdp-holds-the-plan

  HQ's plan for all software delivery is the SDP corpus of this repository, a small plain adopter that pins SDP and holds Specs and nothing else. It sits outside the system being bootstrapped, and it is not part of Kontrapunkt.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

The owner, and the people who receive what the assistant sends.

problem

Recurring accounting, correspondence and context-gathering work takes the owner's time.

outcome

An assistant capability handles the owner's recurring non-engineering work.

risks

• The assistant speaks to clients and accountants in the owner's name, with the owner's context behind it.

Open questions

• non-blocking · question.runtime line 27 · specs/hq/assistant.sdp.md:27 · Which runtime carries the assistant?Decider: delegatedProvisional: Something like Hermes Agent, the kind the owner named.
• blocking · question.agentPlacement line 30 · specs/hq/assistant.sdp.md:30 · Where does the assistant run, given that it needs HQ's context and faces outward?Decider: delegatedTrigger: the assistant is taken up
• blocking · question.sendsAlone line 33 · specs/hq/assistant.sdp.md:33 · What may the assistant send without the owner reading it first?Decider: ownerTrigger: the assistant is taken up

rule.scheduled line 39 · specs/hq/assistant.sdp.md:39

The assistant runs the owner's recurring work on schedules.

no example exercises it

rule.accounting line 40 · specs/hq/assistant.sdp.md:40

The assistant prepares the owner's accounting reports and emails the owner's accountants.

no example exercises it

rule.bookmarks line 41 · specs/hq/assistant.sdp.md:41

The assistant checks the owner's Twitter bookmarks, where the owner stores context for projects and research threads, and passes what it finds to HQ's context.

no example exercises it

rule.groupChats line 42 · specs/hq/assistant.sdp.md:42

The assistant answers clients in group chats with the team.

no example exercises it

0 unkeyed rules.

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

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.