Spec Studio

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 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.

6 of 6 shown

To design

  1. 4. HQ's private context stays in one place and stays cleanbehavior · feature · scoped floor scoped · 1 Spec: 1 to design
    Next: scoped → defined · held by no-blocking-open-questions
    Rests on:
    1 more dependency
    Waited on by:
  2. 6. An assistant capability handles the owner's recurring workbehavior · feature · scoped floor scoped · 1 Spec: 1 to design
    Next: scoped → defined · held by no-blocking-open-questions
    Rests on:
    1 more dependency

To state

  1. 1. HQ hands a settled piece to a detailed sessionworkflow · feature · defined floor ready · 1 Spec: 1 to state
    Next: defined → ready · nothing blocks
    Rests on:
    4 more dependencies
    Waited on by:
    Earlier statements:
  2. 2. Orchestration lives in one plugin, apart from infra and HQbehavior · feature · defined floor ready · 1 Spec: 1 to state
    Next: defined → ready · nothing blocks
    Rests on:
    1 more dependency
    Waited on by:
    Earlier statements:
  3. 3. Infra delivers configuration by projection, under HQ's planbehavior · feature · defined floor ready · 1 Spec: 1 to state
    Next: defined → ready · nothing blocks
    Rests on:
    2 more dependencies
    Waited on by:
    Earlier statements:
  4. 5. SDP carries delivery planning across projectsbehavior · feature · defined floor ready · 1 Spec: 1 to state
    Next: defined → ready · nothing blocks
    Rests on:
    1 more dependency
    Waited on by:
    Earlier statements:

To build

No entry has the need to build.

Built

No entry has the need built.

Waiting on the owner

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.