Spec Studio

Roadmap

What comes next, from the graph. A place is advisory priority: never a date, a deadline or permission to start.

Coordination roadmap

The order of delivery, first entry first, smallest valuable piece first. Session scanning comes first because it needs nothing else here and exists today, so moving it is a port and not a build. After it, each entry rests on the ones before it. The switch and the inbound check come first because they let coordination be on while the job runner is off, and they report the session's real inbound state at start; the first piece is the separate plugin and that accurate diagnostic, and it keeps nothing, since the record comes later. The record comes next because it needs no chain and gives readers every message at once. The chain follows, then the view that shows it. Nothing here is built.

  • 5 entries in priority order: 0 to design, 5 to state, 0 to build, 0 built, 0 listed apart.
  • 0 blocking and 2 non-blocking questions wait on the owner; 0 name no decider, 0 of them blocking.
  • 6 statements wait for a person; the owner queue lists them all.

To design 0

none

To state 5

  1. 1A scan reads a project's sessions and traces each direction to its outcome
  2. 2Coordination switches on alone, and a project takes it up with one setting and its own boundaries
  3. 3Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of them
  4. 4A lead states its parent once, and the chain is read from what leads stated
  5. 5The person sees the chain and the traffic without asking a model

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.

5 of 5 shown

To design

No entry has the need to design.

To state

  1. 1. A scan reads a project's sessions and traces each direction to its outcomebehavior · feature · defined floor ready · 1 Spec: 1 to state
    Id: spec:cc-agents.coordination.session-scanning
    Next: defined → ready · nothing blocks
    Rests on:
    1 more dependency
    Waited on by:
    Earlier statements:
  2. 2. Coordination switches on alone, and a project takes it up with one setting and its own boundariesbehavior · feature · defined floor ready · 1 Spec: 1 to state
    Id: spec:cc-agents.coordination.adoption
    Next: defined → ready · nothing blocks
    Rests on:
    1 more dependency
    Waited on by:
    Earlier statements:
  3. 3. Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of thembehavior · feature · defined floor ready · 1 Spec: 1 to state
    Id: spec:cc-agents.coordination.record
    Next: defined → ready · nothing blocks
    Rests on:
    1 more dependency
    Waited on by:
    Earlier statements:
  4. 4. A lead states its parent once, and the chain is read from what leads statedbehavior · feature · defined floor ready · 1 Spec: 1 to state
    Id: spec:cc-agents.coordination.chain
    Next: defined → ready · nothing blocks
    Decided by:
    Rests on:
    1 more dependency
    Waited on by:
    Earlier statements:
  5. 5. The person sees the chain and the traffic without asking a modelbehavior · feature · defined floor ready · 1 Spec: 1 to state
    Id: spec:cc-agents.coordination.view
    Next: defined → ready · nothing blocks
    Rests on:
    1 more dependency
    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: Coordination roadmap `pack:cc-agents-coordination`

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 order of delivery, first entry first, smallest valuable piece first. Session scanning comes first because it needs nothing else here and exists today, so moving it is a port and not a build. After it, each entry rests on the ones before it. The switch and the inbound check come first because they let coordination be on while the job runner is off, and they report the session's real inbound state at start; the first piece is the separate plugin and that accurate diagnostic, and it keeps nothing, since the record comes later. The record comes next because it needs no chain and gives readers every message at once. The chain follows, then the view that shows it. Nothing here is built.

### To design

No entry needs design.

### To state

| Place | Entry | Earlier waiting statements | Purpose and reach |
| --- | --- | --- | --- |
| 1 | A scan reads a project's sessions and traces each direction to its outcome `spec:cc-agents.coordination.session-scanning` | 1 outside the roadmap | Directions are lost between sessions, and a transcript mixes the person's words with launcher prompts, peers' messages, tool output and summaries, so reading one naively attributes other sessions' words to the person. Waited on by 1. |
| 2 | Coordination switches on alone, and a project takes it up with one setting and its own boundaries `spec:cc-agents.coordination.adoption` | 1 outside the roadmap | Coordination is wanted before the job runner has earned trust, and a session whose host setting holds or refuses inbound messages gives its sender no sign of it. Waited on by 2. |
| 3 | Messages between sessions this session saw are kept whole, with what is known of who sent them and what came of them `spec:cc-agents.coordination.record` | on the roadmap `spec:cc-agents.coordination.adoption` (place 2); 1 outside the roadmap | A message between sessions survives only inside two transcripts, where it reads like typing. Nothing shows a message that was refused, and the host's key-value store holds 4 MiB in all while file writes are not atomic. Waited on by 3. |
| 4 | A lead states its parent once, and the chain is read from what leads stated `spec:cc-agents.coordination.chain` | in this entry `spec:cc-agents.coordination.boundary-only`; on the roadmap `spec:cc-agents.coordination.record` (place 3); 1 outside the roadmap | A session started across a boundary does not know whom to report to, its starter does not know what it left running, and a later reader cannot tell either. Waited on by 2. |
| 5 | The person sees the chain and the traffic without asking a model `spec:cc-agents.coordination.view` | on the roadmap `spec:cc-agents.coordination.record` (place 3), `spec:cc-agents.coordination.chain` (place 4); 1 outside the roadmap | Coordination is invisible: a lead goes quiet, a message is held or refused, and the person learns it only by asking Claude. |

### To build

No entry is ready to build.

### Waiting on the owner

- `spec:cc-agents.coordination.record#question.clientText`, place 3: Should the record hold the full text of messages in a project whose material is confidential?
- `spec:cc-agents.coordination.record#question.auditGrade`, place 3: Does the owner need crash-proof durability, an audit-grade log?
- State `spec:cc-agents.coordination.boundary-only`: it states `defined` and its floor allows `ready`; place 4
- State `spec:cc-agents.coordination.adoption`: it states `defined` and its floor allows `ready`; place 2
- State `spec:cc-agents.coordination.session-scanning`: it states `defined` and its floor allows `ready`; place 1
- State `spec:cc-agents.coordination.record`: it states `defined` and its floor allows `ready`; place 3
- State `spec:cc-agents.coordination.chain`: it states `defined` and its floor allows `ready`; place 4
- State `spec:cc-agents.coordination.view`: it states `defined` and its floor allows `ready`; place 5

### Deferred, with their triggers

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