Roadmap
What comes next, from the graph. A place is advisory priority: never a date, a deadline or permission to start.
HQ's roadmap
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.
- 6 entries in priority order: 2 to design, 4 to state, 0 to build, 0 built, 0 listed apart.
- 2 blocking and 2 non-blocking questions wait on the owner; 0 name no decider, 0 of them blocking.
- 11 statements wait for a person; the owner queue lists them all.
To design 2
To state 4
To build 0
none
Built 0
none
To state means the floor allows ready and a person still judges the statement. Built means every Spec of the entry's work states ready and has an implementation binding; it reports no passing test and no deployment. The entry's own readiness is shown separately.
To design
4. HQ's private context stays in one place and stays cleanbehavior · feature · scoped floor scoped · 1 Spec: 1 to design
Id: spec:hq.contextNext: scoped → defined · held byno-blocking-open-questionsBlocked by:Decided by:Rests on:- spec:hq.infra · depends on · to state · entry 3
1 more dependency
- spec:hq.headquarters · refines · to state · outside the roadmap
Waited on by:- spec:hq.assistant · depends on · to design · entry 6
6. An assistant capability handles the owner's recurring workbehavior · feature · scoped floor scoped · 1 Spec: 1 to design
Next: scoped → defined · held byno-blocking-open-questionsBlocked by:- spec:hq.assistant#question.agentPlacement
· delegated - spec:hq.assistant#question.sendsAlone
· owner
Rests on:- spec:hq.context · depends on · to design · holds ready · entry 4
1 more dependency
- spec:hq.headquarters · refines · to state · outside the roadmap
- spec:hq.assistant#question.agentPlacement
To state
1. HQ hands a settled piece to a detailed sessionworkflow · feature · defined floor ready · 1 Spec: 1 to state
Next: defined → ready · nothing blocksDecided by:Rests on:4 more dependencies
- spec:hq.engineering-environment · depends on · to state · outside the roadmap
- spec:hq.environment · depends on · to state · outside the roadmap
- spec:hq.headquarters · refines · to state · outside the roadmap
- spec:hq.isolation · constrained by · to state · outside the roadmap
Waited on by:- spec:hq.delivery-planning · depends on · to state · entry 5
Earlier statements:- spec:decisions.design-locked-by-projection · in this entry
- spec:decisions.hq-starts-engineering · in this entry
- spec:hq.headquarters · outside the roadmap
- spec:hq.isolation · outside the roadmap
- spec:hq.engineering-environment · outside the roadmap
- spec:hq.environment · outside the roadmap
2. Orchestration lives in one plugin, apart from infra and HQbehavior · feature · defined floor ready · 1 Spec: 1 to state
Next: defined → ready · nothing blocksDecided by:Rests on:1 more dependency
- spec:hq.headquarters · refines · to state · outside the roadmap
Waited on by:- spec:hq.infra · decided by · to state · entry 3
- spec:hq.infra · depends on · to state · entry 3
Earlier statements:- spec:decisions.coordination-native-first · in this entry
- spec:decisions.orchestration-leaves-infra · in this entry
- spec:decisions.recovery-closed · in this entry
- spec:hq.headquarters · outside the roadmap
3. Infra delivers configuration by projection, under HQ's planbehavior · feature · defined floor ready · 1 Spec: 1 to state
Id: spec:hq.infraNext: defined → ready · nothing blocksDecided by:Rests on:- spec:hq.orchestration · depends on · to state · entry 2
2 more dependencies
- spec:hq.headquarters · refines · to state · outside the roadmap
- spec:hq.isolation · constrained by · to state · outside the roadmap
Waited on by:- spec:hq.context · depends on · to design · entry 4
- spec:hq.environment · decided by · to state
- spec:hq.isolation · decided by · to state
Earlier statements:- spec:decisions.isolated-infra-manages-hq · in this entry
- spec:decisions.orchestration-leaves-infra · in this entry
- spec:decisions.recovery-closed · in this entry
- spec:hq.headquarters · outside the roadmap
- spec:hq.orchestration · entry 2
- spec:hq.isolation · outside the roadmap
5. SDP carries delivery planning across projectsbehavior · feature · defined floor ready · 1 Spec: 1 to state
Next: defined → ready · nothing blocksDecided by:Rests on:- spec:hq.session-handoff · depends on · to state · entry 1
1 more dependency
- spec:hq.headquarters · refines · to state · outside the roadmap
Waited on by:- spec:hq.headquarters · decided by · to state
Earlier statements:- spec:decisions.sdp-holds-the-plan · in this entry
- spec:hq.headquarters · outside the roadmap
- spec:hq.session-handoff · entry 1
To build
No entry has the need to build.
Built
No entry has the need built.
Waiting on the owner
non-blocking · spec:hq.infra#question.rollbackPoint
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?
Touches entry 3
non-blocking · spec:hq.infra#question.takeover
Is HQ ready to take over infra, and what must hold first?
Touches entry 3
blocking · spec:hq.context#question.clientMaterial
How is client material handled, project by project: what is screened, and where?
Touches entry 4
blocking · spec:hq.assistant#question.sendsAlone
What may the assistant send without the owner reading it first?
Touches entry 6
Statement · spec:decisions.coordination-native-first states defined, floor allows ready · entry 2
Statement · spec:decisions.design-locked-by-projection states defined, floor allows ready · entry 1
Statement · spec:decisions.hq-starts-engineering states defined, floor allows ready · entry 1
Statement · spec:decisions.isolated-infra-manages-hq states defined, floor allows ready · entry 3
Statement · spec:decisions.orchestration-leaves-infra states defined, floor allows ready · entry 2, entry 3
Statement · spec:decisions.recovery-closed states defined, floor allows ready · entry 2, entry 3, entry 4
Statement · spec:decisions.sdp-holds-the-plan states defined, floor allows ready · entry 5
Statement · spec:hq.orchestration states defined, floor allows ready · entry 2
Statement · spec:hq.infra states defined, floor allows ready · entry 3
Statement · spec:hq.session-handoff states defined, floor allows ready · entry 1
Statement · spec:hq.delivery-planning states defined, floor allows ready · entry 5
The forward section, as Markdown
## The next work, from the roadmap Roadmap: HQ's roadmap `pack:hq-roadmap` To state means the floor allows ready and a person still judges the statement. Built means every Spec of the entry's work states ready and has an implementation binding; it reports no passing test and no deployment. 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. ### To design | Place | Entry | Next | Purpose and reach | | --- | --- | --- | --- | | 4 | HQ's private context stays in one place and stays clean `spec:hq.context` | itself `scoped` → `defined`, held by no-blocking-open-questions; blocked by `spec:hq.context#question.clientMaterial`; decided by `spec:decisions.client-material-deferred` (defined), `spec:decisions.recovery-closed` (defined) | Context imported from sessions and scans is scattered across files, dashboards, inboxes and copies, and some of it is wrong. Waited on by 1. | | 6 | An assistant capability handles the owner's recurring work `spec:hq.assistant` | itself `scoped` → `defined`, held by no-blocking-open-questions; blocked by `spec:hq.assistant#question.agentPlacement`, `spec:hq.assistant#question.sendsAlone` | Recurring accounting, correspondence and context-gathering work takes the owner's time. | ### To state | Place | Entry | Earlier waiting statements | Purpose and reach | | --- | --- | --- | --- | | 1 | HQ hands a settled piece to a detailed session `spec:hq.session-handoff` | in this entry `spec:decisions.design-locked-by-projection`, `spec:decisions.hq-starts-engineering`; 4 outside the roadmap | 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. Waited on by 1. | | 2 | Orchestration lives in one plugin, apart from infra and HQ `spec:hq.orchestration` | in this entry `spec:decisions.coordination-native-first`, `spec:decisions.orchestration-leaves-infra`, `spec:decisions.recovery-closed`; 1 outside the roadmap | 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. Waited on by 1. | | 3 | Infra delivers configuration by projection, under HQ's plan `spec:hq.infra` | in this entry `spec:decisions.isolated-infra-manages-hq`, `spec:decisions.orchestration-leaves-infra`, `spec:decisions.recovery-closed`; on the roadmap `spec:hq.orchestration` (place 2); 2 outside the roadmap | 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. Waited on by 3. | | 5 | SDP carries delivery planning across projects `spec:hq.delivery-planning` | in this entry `spec:decisions.sdp-holds-the-plan`; on the roadmap `spec:hq.session-handoff` (place 1); 1 outside the roadmap | About fifty projects each hold their own plan, or none, and nothing shows them together. Waited on by 1. | ### To build No entry is ready to build. ### Waiting on the owner - `spec:hq.infra#question.rollbackPoint`, place 3: 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? - `spec:hq.infra#question.takeover`, place 3: Is HQ ready to take over infra, and what must hold first? - `spec:hq.context#question.clientMaterial` (blocking), place 4: How is client material handled, project by project: what is screened, and where? - `spec:hq.assistant#question.sendsAlone` (blocking), place 6: What may the assistant send without the owner reading it first? - State `spec:decisions.coordination-native-first`: it states `defined` and its floor allows `ready`; place 2 - State `spec:decisions.design-locked-by-projection`: it states `defined` and its floor allows `ready`; place 1 - State `spec:decisions.hq-starts-engineering`: it states `defined` and its floor allows `ready`; place 1 - State `spec:decisions.isolated-infra-manages-hq`: it states `defined` and its floor allows `ready`; place 3 - State `spec:decisions.orchestration-leaves-infra`: it states `defined` and its floor allows `ready`; place 2, 3 - State `spec:decisions.recovery-closed`: it states `defined` and its floor allows `ready`; place 2, 3, 4 - State `spec:decisions.sdp-holds-the-plan`: it states `defined` and its floor allows `ready`; place 5 - State `spec:hq.orchestration`: it states `defined` and its floor allows `ready`; place 2 - State `spec:hq.infra`: it states `defined` and its floor allows `ready`; place 3 - State `spec:hq.session-handoff`: it states `defined` and its floor allows `ready`; place 1 - State `spec:hq.delivery-planning`: it states `defined` and its floor allows `ready`; place 5 ### Deferred, with their triggers - `spec:hq.assistant#question.agentPlacement`: Where does the assistant run, given that it needs HQ's context and faces outward? Trigger: the assistant is taken up - `spec:hq.assistant#question.sendsAlone`: What may the assistant send without the owner reading it first? Trigger: the assistant is taken up - `spec:hq.context#question.clientMaterial`: How is client material handled, project by project: what is screened, and where? Trigger: infra deploys per-project settings
Composing (0)
Composing needs the script.