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: 3 to design, 0 to state, 1 to build, 0 built, 0 listed apart.
- 2 blocking and 0 non-blocking questions wait on the owner; 0 name no decider, 0 of them blocking.
- 0 statements wait for a person; the owner queue lists them all.
To design 3
To state 0
none
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 idea · 1 Spec: 1 to design
2. A pinned declaration shows the words of each test line that cites itbehavior · story · scoped floor scoped · 1 Spec: 1 to design
Next: scoped → defined · held byno-blocking-open-questionsBlocked by:Also in: pack:self-hosting-v13. 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
No entry has the need to state.
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: a measured inventory by the arc that removes them, reviewed before anything is deleted
Touches entry 1
blocking · spec:consumers.spec-studio.cited-line-text#question.lineText
May the Studio show source text the graph does not hold, and if so is it recorded in the graph beside the citation or read as a named input?
Provisional: the extractor records the citing line's text, trimmed and bounded, on the citation row it already writes, as inferred data that confers nothing, and the Studio reads no source
Touches entry 2
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`, held by kind-evidence-present; 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. | | 2 | A pinned declaration shows the words of each test line that cites it `spec:consumers.spec-studio.cited-line-text` | itself `scoped` → `defined`, held by no-blocking-open-questions; blocked by `spec:consumers.spec-studio.cited-line-text#question.lineText` | 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. | | 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 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? - `spec:consumers.spec-studio.cited-line-text#question.lineText` (blocking), place 2: May the Studio show source text the graph does not hold, and if so is it recorded in the graph beside the citation or read as a named input? ### 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.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.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.