Roadmap
What comes next, from the graph. A place is advisory priority: never a date, a deadline or permission to start.
The Protocol's roadmap
The Protocol's next work, first entry first. The order is a preference: it dates, gates and sequences nothing, and what each entry still needs is read from the graph each time.
First the cleanup that removes the frozen plans, review reports and superseded concept material, as the roadmap and the pull request record make possible. Then the two steps a reader of the Studio's pages could not take, the words of a test line that checks a declaration and an outside register's entries, and then the composed-intent model the build backlog holds. What the first adopter's mass update asks for joins when the owner selects it; a capture landing adds nothing here. An entry leaves by an edit to this manifest once its selected work is complete or no longer belongs among the next work.
- 4 entries in priority order: 2 to design, 1 to state, 1 to build, 0 built, 0 listed apart.
- 1 blocking and 0 non-blocking questions wait on the owner; 0 name no decider, 0 of them blocking.
- 2 statements wait for a person; the owner queue lists them all.
To design 2
To state 1
To build 1
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
1. The Protocol removes its frozen plans, review reports and superseded concept materialbehavior · feature · idea floor scoped · 1 Spec: 1 to design
3. An outside register is a named Studio input, so a cited token links to its entrybehavior · story · scoped floor scoped · 1 Spec: 1 to design
Next: scoped → defined · held byno-blocking-open-questionsBlocked by:Also in: pack:self-hosting-v1
To state
2. A pinned declaration shows the words of each test line that cites itbehavior · story · scoped floor ready · 1 Spec: 1 to state
Next: scoped → defined · nothing blocksAlso in: pack:self-hosting-v1
To build
4. Views compose scoped intent instead of patching canonical sourcebehavior · feature · ready floor ready · 5 Specs: 2 to build, 3 built
Parts:- itself · to build · ready floor ready
- spec:consumers.intent-composition · to build · ready floor ready
3 other parts
- spec:consumers.intent-composition.proposal · built · ready floor ready
- spec:consumers.intent-composition.proposal.memo · built · ready floor ready
- spec:consumers.spec-studio.intent-panel · built · ready floor ready
Build now: Views compose scoped intent instead of patching canonical source, Composed intent hands off on one proposal shapeAlso in: pack:self-hosting-v1
Built
No entry has the need built.
Waiting on the owner
blocking · spec:protocol.delivery-record-cleanup#question.durableContent
Which content in
plans/,reviews/and the concept documents does no Spec, test, decision or recipe carry yet, and where does each piece belong?Provisional: the owner accepted the whole-repository review's measured inventory, with its row rulings, as the answer; the question leaves the Spec when the cleanup arc lands that inventory in its first commit
Touches entry 1
Statement · spec:consumers.spec-studio.cited-line-text states scoped, floor allows ready · entry 2
Statement · spec:protocol.delivery-record-cleanup states idea, floor allows scoped · entry 1
The forward section, as Markdown
## The next work, from the roadmap Roadmap: The Protocol's roadmap `pack: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. The Protocol's next work, first entry first. The order is a preference: it dates, gates and sequences nothing, and what each entry still needs is read from the graph each time. First the cleanup that removes the frozen plans, review reports and superseded concept material, as the roadmap and the pull request record make possible. Then the two steps a reader of the Studio's pages could not take, the words of a test line that checks a declaration and an outside register's entries, and then the composed-intent model the build backlog holds. What the first adopter's mass update asks for joins when the owner selects it; a capture landing adds nothing here. 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 | | --- | --- | --- | --- | | 1 | The Protocol removes its frozen plans, review reports and superseded concept material `spec:protocol.delivery-record-cleanup` | itself `idea` → `scoped`, nothing holds it; blocked by `spec:protocol.delivery-record-cleanup#question.durableContent` | Remove `plans/`, `reviews/` and the superseded concept material from the tree, after moving into the graph the durable content they still hold, so the repository keeps one delivery record: the graph, git and the pull requests. | | 3 | An outside register is a named Studio input, so a cited token links to its entry `spec:consumers.spec-studio.register-input` | itself `scoped` → `defined`, held by no-blocking-open-questions; blocked by `spec:consumers.spec-studio.register-input#question.registerEntry`, `spec:consumers.spec-studio.register-input#question.inputForm` | A cited token reads as bare text on every page, and the register that defines it is neither linked nor shown. | ### To state | Place | Entry | Earlier waiting statements | Purpose and reach | | --- | --- | --- | --- | | 2 | A pinned declaration shows the words of each test line that cites it `spec:consumers.spec-studio.cited-line-text` | No preceding waiting statement in the statement queue. | The declarations page names each citing line by file and line only, so the reader leaves the page to read it, and has no route at all when the page set carries no source link. | ### To build | Place | Entry | Purpose and reach | Rests on | | --- | --- | --- | --- | | 4 | Views compose scoped intent instead of patching canonical source `spec:consumers.edit-model` | Let a view frame a requested change without giving derived surfaces a direct write path to canonical source. | nothing unbuilt | ### Waiting on the owner - `spec:protocol.delivery-record-cleanup#question.durableContent` (blocking), place 1: Which content in `plans/`, `reviews/` and the concept documents does no Spec, test, decision or recipe carry yet, and where does each piece belong? - State `spec:consumers.spec-studio.cited-line-text`: it states `scoped` and its floor allows `ready`; place 2 - State `spec:protocol.delivery-record-cleanup`: it states `idea` and its floor allows `scoped`; place 1 ### Deferred, with their triggers - `spec:carrier.sdp-import.feature-adapter#question.featureAdapter`: Which bare .feature constructs can an import adapter preserve honestly? Trigger: an adopter migrates a gen-1 `.feature` corpus into the Protocol - `spec:consumers.agent-surface.combination-coverage#question.combinationCoverage`: Which combinations of slot values should coverage enumerate and report? Trigger: a design pass asks which combinations no example exercises - `spec:consumers.ai-assisted-reading#question.aiPresentationBoundary`: If an assistant generates explanations or arrangements beyond selecting deterministic readings, what contract keeps its output distinct from graph claims and makes the exact reading reviewable, including how the exact output is retained with its model, prompt and inputs? Trigger: the UX design pass measures that assistant selection or a generated explanation helps a named review task - `spec:consumers.impact-graph.symbol-reach#question.symbolIdentity`: Which language-neutral identity and extraction boundary can support exhaustive symbol reach without freezing a single compiler's representation into the Protocol? Trigger: a reader needs symbol-level reach that file-level imports and curated anchors cannot give - `spec:consumers.projections-model.roadmap-views#question.releaseReader`: Does a reader need release or baseline views that the roadmap, the recipes and git tags do not serve? Trigger: the first published release - `spec:consumers.reference-projection#question.namedOutsideReader`: Does a human reader outside the repository need a reference projection the four shipped roots do not serve? The taxonomy row is not that reader. Trigger: a named consumer outside the repository, with a way to measure that demand inside the arc that builds the projection - `spec:consumers.structural-mermaid#question.namedStructuralReader`: Does a reader need diagrams rooted at code units, which census tables and Spec-rooted one-hop Mermaid do not serve? Trigger: a named reader with that need, plus a decision that refines `spec:decisions.shipped-projections-frozen` for the affected Mermaid rendering or supersedes that ruling whole - `spec:observation.run-evidence.bound-file-freshness#question.freshness`: When should changes to bound files make recorded run evidence stale? Trigger: a reader cannot tell whether a run at another commit still applies, because nothing says whether its bound files changed since - `spec:observation.runtime-overlay#question.observationIdentity`: Which external observation identity and freshness boundary is small enough for the graph while still supporting an honest `observed` delivery fact? Trigger: An adopter needs runtime measurements linked to measurable Spec targets and can supply an observation identity and freshness policy for review.
Composing (0)
Composing needs the script.