HQ's roadmap
pack:hq-roadmapspecs/hq-roadmap.pack.sdp.mdDownload this Pack as one file
Where the design stands
- 6 members in priority order; no unresolved members.
- 2 members held below their stated next rung: HQ's private context stays in one place and stays clean (1 unmet clause), An assistant capability handles the owner's recurring work (1 unmet clause).
- 4 members waiting only for their author's statement: HQ hands a settled piece to a detailed session, Orchestration lives in one plugin, apart from infra and HQ, Infra delivers configuration by projection, under HQ's plan, SDP carries delivery planning across projects.
- No design entries and no pinned declarations.
- 7 open questions and 3 blocking questions.
- No members with an implementation binding.
- No members with a design reference.
- 12 outside Specs the Pack rests on; 6 outside Specs rest on the Pack; no outside Specs verify it; no outside Specs supersede it.
Maturity map
Outlined diagonal: matches. Right of diagonal: floor above statement. Left of diagonal: statement above floor.
Maturity map as text
stated scoped, floor scoped · 2 members
- HQ's private context stays in one place and stays clean ·
spec:hq.context· scoped floor scoped - An assistant capability handles the owner's recurring work ·
spec:hq.assistant· scoped floor scoped
stated defined, floor ready · 4 members
- HQ hands a settled piece to a detailed session ·
spec:hq.session-handoff· defined floor ready - Orchestration lives in one plugin, apart from infra and HQ ·
spec:hq.orchestration· defined floor ready - Infra delivers configuration by projection, under HQ's plan ·
spec:hq.infra· defined floor ready - SDP carries delivery planning across projects ·
spec:hq.delivery-planning· defined floor ready
Mermaid source
Preferred syntax: block. Fixed categorical cells; membership appears in comments.
Framing
HQ's next work, first entry first. The order is a preference and a reading of the owner's words: it dates, gates and sequences nothing, and what each entry needs is read from the graph each time.
The session handoff comes first, because it is the seam every delivery crosses. Orchestration then comes before infra because the owner's recorded order takes over Relay and cc-agents before infra, and the inbox leaves infra first. Client material follows infra's takeover, as it did in the owner's plan. Delivery planning across projects comes after the first external repository has shown that delivery works: if it cannot be done with an external repository, it cannot be done for any of the fifty. The assistant stands last, because it is not software delivery.
An entry leaves by an edit to this manifest once its selected work is complete or no longer belongs among the next work.
Members
1. HQ hands a settled piece to a detailed sessionworkflow · defined floor ready · next rung ready: nothing blocks · 1 open, 0 blocking questions · implementation binding none · verifier binding none
Next rung ready: nothing blocks; it waits only for the author's statement.
Design
No design entries · no pinned declarations
Decisions
- An approved part of the graph reaches engineering as a read-only projection · stated defined
- HQ does the core design and starts detailed work in the engineering environment · stated defined
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.
Implementation binding: none
Design reference: none
Verifier binding: none
2. Orchestration lives in one plugin, apart from infra and HQbehavior · defined floor ready · next rung ready: nothing blocks · 0 open, 0 blocking questions · implementation binding none · verifier binding none
Next rung ready: nothing blocks; it waits only for the author's statement.
Design
No design entries · no pinned declarations
Decisions
- Coordination is built on Claude Code's own messaging, and cc-agents adds only what that lacks · stated defined
- Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trust · stated defined
- The recovery chain stops and this corpus replaces its master plan · stated defined
Open questions
None.
Implementation binding: none
Design reference: none
Verifier binding: none
3. Infra delivers configuration by projection, under HQ's planbehavior · defined floor ready · next rung ready: nothing blocks · 2 open, 0 blocking questions · implementation binding none · verifier binding none
Next rung ready: nothing blocks; it waits only for the author's statement.
Design
No design entries · no pinned declarations
Decisions
- Infra is super isolated and manages the isolated HQ · stated defined
- Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trust · stated defined
- The recovery chain stops and this corpus replaces its master plan · stated defined
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
Implementation binding: none
Design reference: none
Verifier binding: none
4. HQ's private context stays in one place and stays cleanbehavior · scoped floor scoped · next rung defined: waits on 1 unmet clause · 1 open, 1 blocking questions · implementation binding none · verifier binding none
Next rung defined waits on 1 unmet clause:
no-blocking-open-questions· Spec has no blocking open question in intent.openQuestions.
Design
No design entries · no pinned declarations
Decisions
- HQ holds everything until a per-project review screens client material · stated defined
- The recovery chain stops and this corpus replaces its master plan · stated defined
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
Implementation binding: none
Design reference: none
Verifier binding: none
5. SDP carries delivery planning across projectsbehavior · defined floor ready · next rung ready: nothing blocks · 0 open, 0 blocking questions · implementation binding none · verifier binding none
Next rung ready: nothing blocks; it waits only for the author's statement.
Design
No design entries · no pinned declarations
Decisions
- HQ's plan for all software delivery is an SDP corpus in a small repository of its own · stated defined
Open questions
None.
Implementation binding: none
Design reference: none
Verifier binding: none
6. An assistant capability handles the owner's recurring workbehavior · scoped floor scoped · next rung defined: waits on 1 unmet clause · 3 open, 2 blocking questions · implementation binding none · verifier binding none
Next rung defined waits on 1 unmet clause:
no-blocking-open-questions· Spec has no blocking open question in intent.openQuestions.
Design
No design entries · no pinned declarations
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
Implementation binding: none
Design reference: none
Verifier binding: none
Boundary
Rests on (12)
Rested on by (6)
| Spec | Stated rung | Implementation binding | Joined members |
|---|---|---|---|
HQ holds everything until a per-project review screens client materialspec:decisions.client-material-deferred | defined | none | refines: spec:hq.context |
Coordination is built on Claude Code's own messaging, and cc-agents adds only what that lacksspec:decisions.coordination-native-first | defined | none | refines: spec:hq.orchestration |
An approved part of the graph reaches engineering as a read-only projectionspec:decisions.design-locked-by-projection | defined | none | refines: spec:hq.session-handoff |
Infra is super isolated and manages the isolated HQspec:decisions.isolated-infra-manages-hq | defined | none | refines: spec:hq.infra |
Generic orchestration moves from infra to cc-agents, and Relay runs jobs until cc-agents earns trustspec:decisions.orchestration-leaves-infra | defined | none | refines: spec:hq.orchestration |
HQ's plan for all software delivery is an SDP corpus in a small repository of its ownspec:decisions.sdp-holds-the-plan | defined | none | refines: spec:hq.delivery-planning |
Verified by (0)
None.
Superseded by (0)
None.
Members with no verifier binding
The graph records bindings and never runs, so no page shows a run result. Decision records are left out: a decision never needs a verifier binding.
- HQ hands a settled piece to a detailed session ·
spec:hq.session-handoff· stated defined - Orchestration lives in one plugin, apart from infra and HQ ·
spec:hq.orchestration· stated defined - Infra delivers configuration by projection, under HQ's plan ·
spec:hq.infra· stated defined - HQ's private context stays in one place and stays clean ·
spec:hq.context· stated scoped - SDP carries delivery planning across projects ·
spec:hq.delivery-planning· stated defined - An assistant capability handles the owner's recurring work ·
spec:hq.assistant· stated scoped
Findings
None.
Composing (0)
Composing needs the script.