No open questions and no blocking questions; implementation binding present, verifier binding present, and expected-outcome oracle present.
The Protocol's planning reads the graph: the build backlog lists ready work no code realizes, the design backlog lists defined work, and the statement queue orders what a person can state. None of them says which capability comes first. A roadmap is that one authored choice, the order of the next few bodies of work. Everything else about an entry, whether it still needs design, waits only for a person's statement, is ready to build, or is built, is read from the graph each time, so a roadmap never goes stale in what it says about state. It goes stale only in its order, which its owner edits.
An entry stands for its whole refinement subtree: an epic for its features and stories, a feature for its stories. The reading counts the subtree's work by what each part needs, so a large entry shows how much of it is designed and built, and the parts that could be built now.
Intent
actor
The owner choosing what the next pull requests take up, and an agent opening the next body of work.
problem
Priority lives in prose, in each pull request's forward section and in the plan files, which the graph cannot read and which go stale as work lands.
outcome
Read a roadmap as an ordered list of upcoming capabilities, each placed by the graph in what it needs next, to design, to state, to build or built, with the design it lacks and the work it rests on.
A roadmap's entries are its Pack's members in authored order, each numbered by its place from 1; an entry may be an epic, a feature or a story, and its place states its owner's preference and nothing else.
An entry's scope is the entry and every Spec that reaches it through one or more refines edges, each counted once whichever parent it reaches through; its work is the Specs of its scope whose kind is neither example nor decision, the build backlog's exclusions.
Each Spec in a scope has a need read from the graph: to design when it states a rung below ready and its floor does not reach ready; to state when it states a rung below ready and its floor reaches ready, so only a person's statement stands before it; to build when it states ready, is neither an example nor a decision, and is not implemented; built when it states ready and is implemented; settled when it is an example or a decision that states ready.
An entry needs the first of to design, to state and to build that any Spec of its work needs, and is built when every Spec of its work is built; an entry reads built only when every Spec of its work states ready and is implemented.
An entry that is itself an example or a decision, whose scope holds no work, takes no need: it is listed apart with its place and its own need, and it is read through the entries it verifies or shapes.
Each entry shows its stated rung, the rung its floor reaches, its stated next rung with the floor clauses that hold it, its work counted by need with the parts to build now, every blocking open question in its scope, and every decision below ready that its scope holds or names by decidedBy, with that decision's blocking questions, keyed or not.
Each entry lists every Spec of its work once, with its need, its stated rung, the rung its floor reaches, its stated next rung with the floor clauses and the dependency targets that hold it, and whether it is drift; the parts with the entry's need are the ones that set it, so a descendant that holds an entry back is named with what holds it, and the entry's own readiness stays labelled apart.
An entry rests on each resolving Spec outside its scope that any Spec of its scope names by dependsOn, constrainedBy or refines, while that Spec is to design, to state or to build, so a descendant's second parent outside the entry counts as the entry's own parent does; shaping decisions stay in the decision rows. Each row names the relation, the Specs of the scope that name it, the Spec's need and stated rung, whether it holds a ready statement in the scope because it states below defined, and the place of the first entry whose scope holds it, or none when it lies outside the roadmap.
An entry is rested on by each Spec outside its scope, to design, to state or to build, that names a Spec of its scope by dependsOn, constrainedBy or decidedBy, so a reader sees what waits on it.
Apart from the entries, the reading lists what waits on the person the caller names, the owner by default: each open question whose decider names that person, on a Spec of any entry's scope or on a decision a scope names by decidedBy; and each such Spec or decision whose floor reaches a rung above the rung it states, a statement only a person makes, which for a decision is its ratification. Each row carries the places of the entries it touches. Questions follow their first place; statements keep their relative order in the statement queue across the whole roadmap, so a Spec others rest on comes first whatever its place, and their places never reorder them.
The open questions over the same Specs that name no decider are listed apart and counted, blocking and not, so a question nobody is named to settle never reads as an empty workload; the reading never infers a decider from a question's prose.
Each entry lists the waiting statements the statement queue puts before its own: every Spec that the queue says one of the entry's waiting statements rests on, its work's and its shaping decisions' alike, each once, in the queue's order, marked as inside the entry, at the first place of another entry whose scope or shaping decisions it is among, or outside the roadmap. The list advises the order of statements and is never a readiness requirement.
Two entries may share Specs, as an epic and a feature beneath it do; each reads its own scope and names the places of the entries it shares a Spec with.
A Pack whose manifest does not state order: priority reads the same way when it is named, and the answer says its order is reading order, so no view presents it as a priority.
The reading states, records and gates nothing: it moves no rung, authors no fact and reports no finding, and work taken up out of its place is never a finding.
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has a ready root and one descendant held by a blocking question"}
When the roadmap recipe reads the probe roadmap
Then the entry names {part: "spec:probe.part"} among the parts with its need, held by {clause: "no-blocking-open-questions"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has a ready root and one descendant held by a blocking question"}
When
the roadmap recipe reads the probe roadmap
Then
the entry names {part: "spec:probe.part"} among the parts with its need, held by {clause: "no-blocking-open-questions"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has one part ready and not implemented"}
When the roadmap recipe reads the probe roadmap
Then the entry's need reads {need: "to build"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has one part ready and not implemented"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "is ready and implemented throughout"}
When the roadmap recipe reads the probe roadmap
Then the entry's need reads {need: "built"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "is ready and implemented throughout"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has one part below ready whose floor stops short"}
When the roadmap recipe reads the probe roadmap
Then the entry's need reads {need: "to design"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has one part below ready whose floor stops short"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has one part implemented below ready"}
When the roadmap recipe reads the probe roadmap
Then the entry counts {drift: 1} parts as drift
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has one part implemented below ready"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has a ready root and one descendant without its kind's evidence"}
When the roadmap recipe reads the probe roadmap
Then the entry names {part: "spec:probe.part"} among the parts with its need, held by {clause: "kind-evidence-present"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has a ready root and one descendant without its kind's evidence"}
When
the roadmap recipe reads the probe roadmap
Then
the entry names {part: "spec:probe.part"} among the parts with its need, held by {clause: "kind-evidence-present"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has one descendant that also refines a Spec outside the roadmap"}
When the roadmap recipe reads the probe roadmap
Then the entry rests on {target: "spec:probe.outside"} through {origin: "spec:probe.part"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has one descendant that also refines a Spec outside the roadmap"}
When
the roadmap recipe reads the probe roadmap
Then
the entry rests on {target: "spec:probe.outside"} through {origin: "spec:probe.part"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.dependent"}
Given that work {state: "has one part below ready whose floor reaches ready"}
Given a probe roadmap whose first entry rests on a Spec of its second entry, both waiting for a statement
When the roadmap recipe reads the probe roadmap
Then the waiting statements list {earlier: "spec:probe.base"} before {later: "spec:probe.dependent"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.dependent"}
that work {state: "has one part below ready whose floor reaches ready"}
a probe roadmap whose first entry rests on a Spec of its second entry, both waiting for a statement
When
the roadmap recipe reads the probe roadmap
Then
the waiting statements list {earlier: "spec:probe.base"} before {later: "spec:probe.dependent"}
Given a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
Given that work {state: "has one part below ready whose floor reaches ready"}
When the roadmap recipe reads the probe roadmap
Then the entry's need reads {need: "to state"}
Given
a probe roadmap whose entry holds the work {work: "spec:probe.root, spec:probe.part"}
that work {state: "has one part below ready whose floor reaches ready"}
Given a probe roadmap whose entry holds the work {work:string}
Given that work {state:"is ready and implemented throughout"|"has one part ready and not implemented"|"has one part below ready whose floor reaches ready"|"has one part below ready whose floor stops short"|"has one part implemented below ready"|"has a ready root and one descendant without its kind's evidence"|"has a ready root and one descendant held by a blocking question"|"has one descendant that also refines a Spec outside the roadmap"}
Given a probe roadmap whose first entry rests on a Spec of its second entry, both waiting for a statement
When the roadmap recipe reads the probe roadmap
Then the entry's need reads {need:"to design"|"to state"|"to build"|"built"}
Then the entry counts {drift:number} parts as drift
Then the entry names {part:string} among the parts with its need, held by {clause:string}
Then the entry rests on {target:string} through {origin:string}
Then the waiting statements list {earlier:string} before {later:string}
recipe 53, the roadmap, takes params.pack, one Pack id, and params.decider, a token on the decider field's grammar, "owner" by default; without pack it reads every Pack whose manifest states order: priority, in id order; a pack that names no Pack, or a decider off the grammar, returns { diagnostics: [{ parameter, problem }] } and no roadmaps.
{ decider, roadmaps }, one roadmap per Pack read: { pack, title, framing, order, totals, entries, apart, unresolved, waiting }, where order is "priority" or "reading" and totals is { entries, toDesign, toState, toBuild, built, apart, unresolved, questions, blockingQuestions, withoutDecider, blockingWithoutDecider, statements }, the entries with each need and the rows waiting. entries in totals counts every manifest member, including unresolved ones, and totals.unresolved counts the unresolved members; unresolved lists { place, id } in manifest order for members that do not resolve, and every place is the original manifest position, never renumbered.
{ place, id, title, specKind, altitude, need, statedReadiness, floorReached, statedNextRung, holdsNextRung, work, workRows, buildNow, blockingQuestions, decisions, restsOn, restedOnBy, earlierStatements, packs, sharesScopeWith } in place order, where statedNextRung is null at ready, holdsNextRung lists the holding rows that keep the floor from the stated next rung, work is { specs, toDesign, toState, toBuild, built, drift } counted over the entry's work, buildNow lists the ids of its work to build, packs lists the entry's Packs other than the roadmap, and sharesScopeWith lists places.
workRows lists every Spec counted in work once, in Spec-id order, as { id, need, statedReadiness, floorReached, statedNextRung, holdsNextRung, drift }, with statedNextRung and holdsNextRung read as on the entry row and drift a boolean; the rows whose need equals the entry's are the ones that set it.
a holding row is { clause, targets }, clause the id of a floor clause that fails at the stated next rung, in the floor evaluator's order, and targets the ids that the typed-dependency clause names, in its order, empty for any other clause.
{ address, spec, index, question, blocking, decider, provisional } for each blocking question in the entry's scope, address null when the question carries no key, index its authored position from 0, and decider and provisional null when absent, sorted by Spec id and authored position.
{ id, title, statedReadiness, blockingQuestions } for each decision below ready the entry's scope holds or names by decidedBy, sorted by id, blockingQuestions listing a question row for each of its blocking questions, keyed or not.
{ id, via, from, need, statedReadiness, holdsReady, onRoadmap }, where via is "dependsOn", "constrainedBy" or "refines", from lists in id order the Specs of the scope that name it by that relation, holdsReady is true when the Spec states below defined, and onRoadmap is the place of the first entry whose scope holds it or null; rows sort by id, then via.
earlierStatements lists { id, where, onRoadmap } in the statement queue's order, where where is "entry" for a Spec of the entry's scope or one of its shaping decisions, "roadmap" for a waiting statement another entry touches through its scope or its shaping decisions, and "outside" otherwise, and onRoadmap is the first place of the entries that statement touches, null unless where is "roadmap".
waiting is { questions, withoutDecider, statements }: a question in either list is a question row with places; a statement is { id, statedReadiness, floorReached, places }. Questions sort by their first place, then blocking ones first, then by Spec id and authored position. Statements keep their relative order in the statement queue, recipe 46, across the whole roadmap; their places name the entries they touch and never reorder them.
no citation recorded
Verification
Verifier bindings
spec:consumers.roadmap.blocking-part · A descendant question holds the entry for design · declared · example enabled · specs/consumers/roadmap.blocking-part.sdp.md
External run evidence from test/roadmap-examples.test.ts
rejects a statement-order point with a different bound state
not recorded
passed
2.38 ms
checks the bound work against the observed scope
not recorded
passed
35.82 ms
executes the bound example against a fresh world
Built work stays on the roadmap (spec:consumers.roadmap.built-work)
passed
8.17 ms
executes the bound example against a fresh world
A ready unbound part needs building (spec:consumers.roadmap.buildable-part)
passed
6.64 ms
executes the bound example against a fresh world
A complete part waits for a statement (spec:consumers.roadmap.statement-part)
passed
6.31 ms
executes the bound example against a fresh world
An unfinished part needs design (spec:consumers.roadmap.design-part)
passed
9.78 ms
executes the bound example against a fresh world
A binding below ready remains drift (spec:consumers.roadmap.drifting-part)
passed
13.87 ms
executes the bound example against a fresh world
A descendant without evidence names its holding clause (spec:consumers.roadmap.missing-evidence)
passed
4.62 ms
executes the bound example against a fresh world
A descendant question holds the entry for design (spec:consumers.roadmap.blocking-part)
passed
4.81 ms
executes the bound example against a fresh world
A descendant names its outside parent (spec:consumers.roadmap.outside-parent)
passed
8.57 ms
executes the bound example against a fresh world
Waiting statements keep dependency order against roadmap places (spec:consumers.roadmap.statement-order)
passed
4.83 ms
spec:consumers.roadmap.buildable-part · A ready unbound part needs building · declared · example enabled · specs/consumers/roadmap.buildable-part.sdp.md
spec:consumers.roadmap.built-work · Built work stays on the roadmap · declared · example enabled · specs/consumers/roadmap.built-work.sdp.md
spec:consumers.roadmap.design-part · An unfinished part needs design · declared · example enabled · specs/consumers/roadmap.design-part.sdp.md
spec:consumers.roadmap.drifting-part · A binding below ready remains drift · declared · example enabled · specs/consumers/roadmap.drifting-part.sdp.md
spec:consumers.roadmap.missing-evidence · A descendant without evidence names its holding clause · declared · example enabled · specs/consumers/roadmap.missing-evidence.sdp.md
spec:consumers.roadmap.outside-parent · A descendant names its outside parent · declared · example enabled · specs/consumers/roadmap.outside-parent.sdp.md
spec:consumers.roadmap.statement-order · Waiting statements keep dependency order against roadmap places · declared · example enabled · specs/consumers/roadmap.statement-order.sdp.md
spec:consumers.roadmap.statement-part · A complete part waits for a statement · declared · example enabled · specs/consumers/roadmap.statement-part.sdp.md
test:protocol.roadmap-recipe · anchored · test anchor binding present · test/roadmap.test.ts:34
keeps manifest places and reports an unresolved middle member
the roadmap recipes
passed
38.1 ms
escapes HTML outside code spans in memo titles and framing
the roadmap recipes
passed
5.44 ms
reads the work's need: 'is ready and implemented throughout'
the roadmap recipes
passed
20.1 ms
reads the work's need: 'has one part ready and not implemented'
the roadmap recipes
passed
9.72 ms
reads the work's need: 'has one part below ready whose floor …'
the roadmap recipes
passed
7.15 ms
reads the work's need: 'has one part below ready whose floor …'
the roadmap recipes
passed
14.65 ms
reads the work's need: 'has one part implemented below ready'
the roadmap recipes
passed
13 ms
reads the work's need: 'has a ready root and one descendant w…'
the roadmap recipes
passed
6.1 ms
reads the work's need: 'has a ready root and one descendant h…'
the roadmap recipes
passed
9.38 ms
reads the work's need: 'has one descendant that also refines …'
the roadmap recipes
passed
8.17 ms
selects priority Packs in id order and reads an explicitly named ordinary Pack
the roadmap recipes
passed
17.93 ms
names holding parts and a descendant's outside parent
the roadmap recipes
passed
24.05 ms
renders each unbuilt dependency once when two relations reach it
the roadmap recipes
passed
9.95 ms
lists sorted incoming relations, Pack memberships and dependency places
the roadmap recipes
passed
13.87 ms
includes keyed and unkeyed blocking questions on shaping decisions
the roadmap recipes
passed
9.19 ms
finds earlier statements through a shaping decision's own waiting statement
the roadmap recipes
passed
4.22 ms
ends the intent line with a full stop: A purpose?
the roadmap recipes
passed
3.05 ms
ends the intent line with a full stop: A purpose!
the roadmap recipes
passed
2.43 ms
ends the intent line with a full stop: A purpose
the roadmap recipes
passed
2.45 ms
ends the intent line with a full stop: A purpose.
the roadmap recipes
passed
2.65 ms
keeps queue order across places, including earlier statements inside, elsewhere and outside
the roadmap recipes
passed
7.51 ms
deduplicates shared descendants, preserves places, and lists decision entries apart
the roadmap recipes
passed
6.16 ms
lists every unassigned question apart, including unkeyed and shared shaping decisions
the roadmap recipes
passed
7.14 ms
pins memo bytes, intent fallback, line breaks and table escaping
the roadmap recipes
passed
8.9 ms
pins every populated memo section byte for byte
the roadmap recipes
passed
23.61 ms
pins empty design and build sections byte for byte
the roadmap recipes
passed
5.75 ms
reads purpose from intent and counts distinct waiting Specs and buildable parts
the roadmap recipes
passed
22.83 ms
Example space
work · string · declared by a probe roadmap whose entry holds the work {work}
state · "is ready and implemented throughout" | "has one part ready and not implemented" | "has one part below ready whose floor reaches ready" | "has one part below ready whose floor stops short" | "has one part implemented below ready" | "has a ready root and one descendant without its kind's evidence" | "has a ready root and one descendant held by a blocking question" | "has one descendant that also refines a Spec outside the roadmap" · declared by that work {state}
a probe roadmap whose entry holds the work {work:string}
that work {state:"is ready and implemented throughout"|"has one part ready and not implemented"|"has one part below ready whose floor reaches ready"|"has one part below ready whose floor stops short"|"has one part implemented below ready"|"has a ready root and one descendant without its kind's evidence"|"has a ready root and one descendant held by a blocking question"|"has one descendant that also refines a Spec outside the roadmap"}
a probe roadmap whose first entry rests on a Spec of its second entry, both waiting for a statement
When
the roadmap recipe reads the probe roadmap
Then
the entry's need reads {need:"to design"|"to state"|"to build"|"built"}
the entry counts {drift:number} parts as drift
the entry names {part:string} among the parts with its need, held by {clause:string}
the entry rests on {target:string} through {origin:string}
the waiting statements list {earlier:string} before {later:string}
Composing needs the script.
Design view
Requirement drawing
Requirement drawing for spec:consumers.roadmapThe diagram as text
spec:consumers.roadmap: A roadmap orders the next bodies of work, and the graph says what each still needs · declared Spec
spec:consumers.roadmap.blocking-part: A descendant question holds the entry for design · declared Spec
spec:consumers.roadmap.buildable-part: A ready unbound part needs building · declared Spec
spec:consumers.roadmap.built-work: Built work stays on the roadmap · declared Spec
spec:consumers.roadmap.design-part: An unfinished part needs design · declared Spec
spec:consumers.roadmap.drifting-part: A binding below ready remains drift · declared Spec
spec:consumers.roadmap.memo: A roadmap renders as the forward section of a pull request description · declared Spec
spec:consumers.roadmap.missing-evidence: A descendant without evidence names its holding clause · declared Spec
spec:consumers.roadmap.outside-parent: A descendant names its outside parent · declared Spec
spec:consumers.roadmap.statement-order: Waiting statements keep dependency order against roadmap places · declared Spec
spec:consumers.roadmap.statement-part: A complete part waits for a statement · declared Spec
spec:consumers.spec-studio.roadmap-page: The roadmap page shows the upcoming work in priority order, split by what it needs · declared Spec
spec:consumers.graph-first-planning: The next body of work is planned from the graph, not from a prose index · declared Spec
spec:consumers.spec-studio: The Spec Studio is a static HTML workbench over the one graph · declared Spec
impl:protocol.roadmap-memo-recipe: realizes the roadmap memo in the shipped recipe catalog · anchored code · test/roadmap.test.ts:27
impl:protocol.roadmap-recipe: realizes the roadmap in the shipped recipe catalog · anchored code · test/roadmap.test.ts:20
impl:protocol.studio-roadmap-page: renders roadmap needs, holding parts and the shared Markdown memo · anchored code · src/projections/studio/pages/roadmap-page.ts:168
A roadmap is a Pack whose manifest states order: priority; its members' authored order is the corpus's advisory priority, first entry first. order is an optional manifest field whose one lawful value is priority, and a Pack without it keeps the reading order every Pack has. Priority is preference among bodies of work and nothing more: it carries no date, no dependency, no status and no gate, and no check, recipe or page treats a place on a roadmap as permission, obligation or sequence. Everything a roadmap shows about an entry, what it still needs and what holds it, is read from the graph each time. A corpus may keep several roadmaps, and a Spec may be listed on any number of them.
Runtime
impl:protocol.roadmap-recipe · realizes the roadmap in the shipped recipe catalog · test/roadmap.test.ts:20
Uses
None.
Runtime observation: not tracked.
Evidence
Runtime observation: not tracked.
Build attestations: not tracked.
Deployments: not tracked.
Bills of materials: not tracked.
Impact
Relations of spec:consumers.roadmap
E7: verifies · declared (9 unit edges)
The diagram as text
spec:consumers.graph-first-planning: The next body of work is planned from the graph, not from a prose index
spec:consumers.projections-model.roadmap-views: Roadmap views read releases, baselines and phases from git and the graph
spec:consumers.readiness-planner: The readiness planner orders the statements a person can make
spec:consumers.roadmap: A roadmap orders the next bodies of work, and the graph says what each still needs
spec:consumers.roadmap.blocking-part: A descendant question holds the entry for design
spec:consumers.roadmap.buildable-part: A ready unbound part needs building
spec:consumers.roadmap.built-work: Built work stays on the roadmap
spec:consumers.roadmap.design-part: An unfinished part needs design
spec:consumers.roadmap.drifting-part: A binding below ready remains drift
spec:consumers.roadmap.memo: A roadmap renders as the forward section of a pull request description
spec:consumers.roadmap.missing-evidence: A descendant without evidence names its holding clause
spec:consumers.roadmap.outside-parent: A descendant names its outside parent
spec:consumers.roadmap.statement-order: Waiting statements keep dependency order against roadmap places
spec:consumers.roadmap.statement-part: A complete part waits for a statement
spec:consumers.spec-studio.roadmap-page: The roadmap page shows the upcoming work in priority order, split by what it needs
spec:consumers.upgrade-kit: The upgrade kit shows a corpus what it could adopt
spec:decisions.roadmap-priority: A roadmap states advisory priority in the graph
spec:model.open-question-fields: An open question may name who decides it, its links, a provisional reading and a re-entry trigger
spec:protocol.roadmap-replaces-plans: The Protocol reads its next work from its roadmap and keeps its delivery record in git and its pull requests
spec:validation.next-rung-floor: The floor names what blocks the floor's next rung
spec:validation.typed-dependency-floor: A ready Spec rests only on settled dependencies
spec:consumers.roadmap dependsOn spec:consumers.readiness-planner · declared — the statements waiting on a person follow the statement queue's order
spec:consumers.roadmap dependsOn spec:model.open-question-fields · declared — the questions waiting on a person are selected by their decider field
spec:consumers.roadmap dependsOn spec:validation.next-rung-floor · declared — an entry's stated next rung and the clauses that hold it come from the one floor evaluator
spec:consumers.roadmap dependsOn spec:validation.typed-dependency-floor · declared — what an entry rests on is read through the relations the ready floor reads
spec:consumers.roadmap refines spec:consumers.graph-first-planning · declared — a roadmap is advisory reading of the graph for choosing the next work
spec:consumers.projections-model.roadmap-views dependsOn spec:consumers.roadmap · declared — the roadmap view the owner asked for is the roadmap reading, its page and its memo
spec:consumers.spec-studio.roadmap-page dependsOn spec:consumers.roadmap · declared — the page renders the roadmap reading
spec:consumers.upgrade-kit dependsOn spec:consumers.roadmap · declared — the guide teaches advisory priority and the roadmap memo as planning records
spec:protocol.roadmap-replaces-plans dependsOn spec:consumers.roadmap · declared — the Protocol reads its own next work from its roadmap
impl:protocol.roadmap-recipe · realizes the roadmap in the shipped recipe catalog · test/roadmap.test.ts:20 · role projection
Design reference: none
Verifier binding: present
spec:consumers.roadmap.blocking-part · A descendant question holds the entry for design · declared · specs/consumers/roadmap.blocking-part.sdp.md · example enabled
spec:consumers.roadmap.buildable-part · A ready unbound part needs building · declared · specs/consumers/roadmap.buildable-part.sdp.md · example enabled
spec:consumers.roadmap.built-work · Built work stays on the roadmap · declared · specs/consumers/roadmap.built-work.sdp.md · example enabled
spec:consumers.roadmap.design-part · An unfinished part needs design · declared · specs/consumers/roadmap.design-part.sdp.md · example enabled
spec:consumers.roadmap.drifting-part · A binding below ready remains drift · declared · specs/consumers/roadmap.drifting-part.sdp.md · example enabled
spec:consumers.roadmap.missing-evidence · A descendant without evidence names its holding clause · declared · specs/consumers/roadmap.missing-evidence.sdp.md · example enabled
spec:consumers.roadmap.outside-parent · A descendant names its outside parent · declared · specs/consumers/roadmap.outside-parent.sdp.md · example enabled
spec:consumers.roadmap.statement-order · Waiting statements keep dependency order against roadmap places · declared · specs/consumers/roadmap.statement-order.sdp.md · example enabled
spec:consumers.roadmap.statement-part · A complete part waits for a statement · declared · specs/consumers/roadmap.statement-part.sdp.md · example enabled
test:protocol.roadmap-recipe · anchored · test/roadmap.test.ts:34 · test anchor