Repository navigation
Plan 47: roadmaps, capability maps and design slices - #36
Conversation
…n slices The owner asked for epics and a capability map, a roadmap with advisory priority tied to the PR descriptions, more diagram kinds with a curated annotation review, design slices, and the roadmap replacing the numbered plans. This commit states that intent in the graph before any design pass: - pack:roadmaps-and-slices-v1 with fourteen captures at idea, one per item, in the order the arc would build them; - two captures from PR 35's forward lanes, so the first roadmap has real upcoming work beyond this arc; - the two owner decisions as decision captures that refine the planning truths decision: priority in the graph, and retiring the plans; - plan 47 as a thin DRAFTED pointer, named by the handbook; - the self-hosting oracle transcribed for the sixteen new Specs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Lane S of plan 47's design wave. A design slice is a reading, not an artifact: a Pack read whole, narrowed to a perspective's members, or an ordered list of Specs, composed from the graph on each invocation. - spec:consumers.design-slice states defined: recipe 54's rules and answer shape, composing rule coverage, the architecture map, the realization comparison and the decision and open-question registers; members rest on each other as the statement queue reads them, with depth and cycles; the components touched through members' code, through the code that realizes what the slice rests on, and through planned component designs; decisions and questions in scope; summary by default, detail as Pack design reads it. - spec:consumers.spec-studio.slice-page states defined: one slice page per Pack beside the Pack page, its sections, tables and drawings; its ready waits on the diagram kinds lane G designs. - reviews/assets/plan47-prototypes/S-design-slice: the draft recipe body, the page builder, four slice pages over the Protocol's corpus and the platform copy, sample answers and screenshots. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drafts the roadmap priority decision (order: priority on a Pack manifest) and the plans-over-roadmap decision to defined for the owner; designs the roadmap reading (recipe 53, four lanes from each entry's refinement subtree), its Studio page and the forward-section memo (recipe 55) to defined; reshapes the roadmap views capture around the named reader; takes the cited-line and register-input captures to scoped; authors pack:roadmap as the first roadmap; prototypes the page and memo on the Protocol and a platform copy. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The waiting list keeps the statement queue's order across the roadmap; each entry lists its parts with what holds them, the waiting statements before its own, and rests on any outside parent of a descendant; questions with no decider are listed apart; entry ids carry their roadmap's name; the design diff reports a Pack becoming a roadmap; the roadmap is selected, not filled by captures; and an arc's record has a home before its first push. Probes check each fix. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…lded examples The design slice now marks each relation between members as ordering or not, folds an example only when its refines is its one typed relation, lists every member component design as its own row with recipe 43's rows attached, carries the unit edges behind each uses pair, planned uses and the outside neighbors, and pins its diagnostics. The slice page consumes the answer for both drawings, uses the drawing kinds' element ids, keeps folded examples readable in a disclosure and stacks member rows on a phone. The prototype adds a probe corpus for planned components and folded examples. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The five lanes merged above are reconciled into one design: - the dependency drawing carries the slice's `orders` mark and folds an example only when the slice does; the scoped architecture reads the slice's design rows apart from its anchored components; the slice page depends on the two drawing kinds it draws; - the epic-kind decision moves into the decisions family as spec:decisions.epics-of-any-kind; - the significant-units panel lane A proposed is authored at defined under the architecture lens; - the arc Pack, the Studio Pack and the self-hosting Pack list the new Specs; the self-hosting oracle is transcribed for every change; - plan 47 records what the wave added, dropped and reshaped, the delegated rulings, the owner's decisions and the proposed build waves; reviews/plan47-design/ keeps each lane's brief, design, reviews and answer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The page and memo now show this branch's own state: three entries to design, five to state and one to build, the capability map held by the epic-kind decision. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedToo many files! This PR contains 260 files, which is 160 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry. ⚙️ Run configuration
⛔ Files ignored due to path filters: 49
📒 Files selected for processing: 260
You can disable this status message by setting the
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The owner ruled the design checkpoint and gave the build go: - a roadmap states advisory priority as the member order of a Pack whose manifest says `order: priority` (MD-46); - the roadmap replaces the plans, frozen at plan 47; no check refuses a new plan file, which would police the workflow (MD-47); - epics of any kind keep their kind (MD-48), and the glossary row broadens; - the annotation review's change table is accepted, the decoder moving to the reader component only if it adds no layer crossing; - "need" names what a roadmap entry needs next; "roadmap" and "need" join the glossary; "design slice" is a guidance-only label. On the same delegation the arc's 22 Specs whose floor allowed it state ready; each reports an honest verifier gap until its build binds one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Advisory review: Opus 5.5 (extra-high effort), opinionOne of two independent advisors on plan 47's decision items; the other advisor's review is in its own comment. The executing thread rules after reading both. Read at Plan 47: the Opus advisory on the owner's decision itemsRead at
Note for the executing thread: while I read, the working tree carried uncommitted edits to 26 files: 1. Where priority lives: agree, confidence 4A Pack already keeps an authored member order and states no truth, so 2. The SDP-native alternatives to plans and reviews: agree with changes, confidence 4 (evidence placement 3)
What would change my mind: a requirement that review discussion be readable without GitHub, which would need a committed memo home; or the cleanup pull request slipping by more than one arc, which would justify the ceiling. 3. Epics of any kind: agree, confidence 5Kind and altitude are independent coordinates on the one primitive. Three of the hubs that already state capabilities are model or rule Specs ( 4. The nine epic boundaries: agree, confidence 4Re-measured: all 432 Specs reached. Projections has 185 descendants (the agent surface 47, the Studio 66, the vault 20). The Studio is a feature whose 63 story descendants make its altitude honest. Raising it to an epic would change a coordinate with no new outcome to state. The agent surface already refined projections on 5. The engine's accepted set: agree with one change, confidence 4 (decoder 3)The change table keeps every realization claim, and the merge ledger names each target transfer. Putting the decoder in the reader keeps the component graph acyclic: it adds codegen to reader and reader to notation. The other acyclic home, codegen, would make the reader depend on a generator, which is worse. The decoder's imports are type-only ( 6. The significance criterion: drift repair, with MD-38's sentence aligned; confidence 4If "exported public surface" were sufficient, every export would need an anchor. That is the coverage quota MD-38 refuses ("Anchors are curated, never a coverage quota"), and the model term already said "that warrants". The sharpening narrows nothing MD-38 decided, so it needs no refining decision and no registry row. It fails "hard to reverse" in any case. Still, MD-38's consequence, "The engine significance criterion stays exported public surface or cross-component reach", would then contradict the term it governs. Align that sentence in this arc under delegation, list it among the delegated rulings, and edit the term, 7. Words: agree with changes, confidence 4
What would change my mind: an outside reader test where "to state" reads as a state machine. In that case use "to state ready" as the board heading only. 8. Release and baseline views stay deferred: agree, confidence 4The package installs from a commit and has no published release. The trigger is concrete, and git tags with the roadmap serve until then. 9.
|
Advisory review: Opus 5.5, change proposalThe advisor's Spec edits as one change proposal ( Change proposalBase: Change 1Scope: Reason: Change 2Scope: Reason: Change 3Scope: Reason: Change 4Scope: Reason: Change 5Scope: Reason: Change 6Scope: Reason: Change 7Scope: Reason: Change 8Scope: Reason: Change 9Scope: Replaces: Change 10Scope: Replaces: Change 11Scope: Follows: Change 12Scope: Follows: Change 13Scope: Replaces: Change 14Scope: Reason: Change 15Scope: Reason: Change 16Scope: Replaces: Change 17Scope: Reason: Change 18Scope: Reason: Change 19Scope: Reason: Change 20Scope: Reason: Change 21Scope: Reason: Change 22Scope: Reason: Change 23Scope: Replaces: Change 24Scope: Reason: Change 25Scope: Reason: Change 26Scope: Reason: Change 27Scope: Relation: declare Change 28Scope: Relation: declare Change 29Scope: Relation: declare Change 30Scope: Relation: declare Change 31Scope: Relation: declare Change 32Scope: Reason: Change 33Scope: Replaces: Change 34Scope: Replaces: Change 35Scope: Reason: Change 36Scope: Replaces: Change 37Scope: Replaces: Change 38Scope: Replaces: Change 39Scope: Replaces: Change 40Scope: Replaces: Change 41Scope: Replaces: Change 42Scope: Replaces: Change 43Scope: Follows: Change 44Scope: Replaces: Change 45Scope: Follows: Change 46Scope: Replaces: Change 47Scope: Follows: The proposal{
"schema": "sdp-proposal/1",
"base": "2dc5c44cb4d6a162be6d8fb49c33451f5601a898",
"reason": "Opus advisory on plan 47: retire plans and reviews into git and the pull request, rename the roadmap's step, close the integration gaps before ready",
"changes": [
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the H1 title with this text, and extend the opening paragraph so it names committed review reports and their assets beside the plan file.",
"text": "# Plan and review files stop carrying the delivery record once the roadmap and the pull request do",
"reason": "The owner retired reviews/ as well as plans/; one decision carries both because the principle and the consequences are shared."
},
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the `decision:` entry of the Decision section with this text.",
"text": "- decision: The Protocol reads its forward planning from its roadmap and keeps its delivery record in git and its pull requests; it adds no plan file and no review file, and `plans/` and `reviews/` stand as frozen history until a later arc removes or archives them. An agent opening the next work runs the roadmap recipe over the roadmap Pack the handbook names and follows each entry to its Packs and carrying Specs. Before an arc's first authorized push its commits are its record: the first commit message names the arc's base, its Pack and the owner's instruction that opened it, each later message says what its unit did, and outstanding work is read from the arc's Pack, the backlogs and the open-question register. At the first authorized push the draft pull request description takes the record: its story, lanes, rulings with who made them, acceptance as measured, deferrals and refusals. A review's findings against Specs travel as a change proposal, checked against the base it names and posted to the pull request as its memo; a finding against code or another file is a review comment on its line; a finding left open becomes an open question with its decider, provisional reading and links. Evidence no test, recipe or preview carries is committed on the arc's branch, linked from the description pinned to that commit, and removed before the merge, which keeps the commit reachable. Briefs and prompts stay in the session. The handbook names the roadmap Pack and the roadmap recipe where it named the current plan, and the self-hosting gate checks that instead of a current plan.",
"reason": "Drops the short-lived reviews/ record file, which the owner's retirement of reviews/ leaves without a home, and states the review alternative."
},
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the rationale entry that opens `Hard to reverse` with this text.",
"text": "- rationale: Hard to reverse: the handbook, the skills, the description standard and a gate point every session at the newest plan and at committed review files, and every session's first read changes. Surprising without context: a reader finds two folders that stopped. A real trade-off: one forward-planning carrier in the graph and one record per arc in git and its pull request, with nothing to keep in step, against review findings and pre-push state living in commit messages and pull request threads rather than in files a person can search in the tree.",
"reason": "The trade-off now covers reviews and drops the record file."
},
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the alternative that opens `Keep each arc's whole execution record in a committed file under reviews/` with these three alternatives, one line each.",
"text": "- alternative: Keep an arc's record in a file under `reviews/` until its first push, then only its link: the file repeats what the commits already say, outlives the arc as a stub, and keeps `reviews/` growing after its retirement.\n- alternative: Keep review reports as committed files beside the change proposal: the proposal is the reviewable shape, an applied edit is git history and an open finding is an open question, so a report file repeats all three and goes stale with the next edit.\n- alternative: A gate check that refuses a numbered plan above the last frozen one: the cleanup arc removes the folder, so the check guards a window of one pull request, and refusing a kind of file is closer to policing the workflow than to checking the record.",
"reason": "Records the refused record file, the refused review reports and the refused plan ceiling."
},
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the consequence that opens `The handbook drops its stack of plan statuses` with this text.",
"text": "- consequence: The handbook drops its stack of plan statuses for a short pointer to the roadmap and its recipe. The self-hosting gate's current-record check refuses a handbook that does not name the roadmap Pack and recipe, and a roadmap Pack manifest that is missing or does not state priority order; its frozen historical checks, its green-gate legs and its ban on plan status in the registry and the glossary stay until the cleanup arc removes the folders they read.",
"reason": "No plan-number ceiling; the historical checks end with the folders."
},
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the consequence that opens `The commit strategy that authorizes commits` with this text.",
"text": "- consequence: The owner's instruction that opens an arc authorizes commits on its branch, as a plan's commit strategy did; the arc's first commit message records it and the draft description repeats it after the first push. A session that must stop with no clean boundary commits its work in progress on the arc's branch with a message saying what is incomplete, rather than accounting for it in a file.",
"reason": "Git is the event log before the first push."
},
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace the consequence that opens `The plan files stay as they are` with this text.",
"text": "- consequence: The plan and review files stay as they are until a dedicated cleanup arc removes or archives them; until then nothing is added to either, and a file in either changes only to correct the record it keeps.",
"reason": "The owner scheduled the removal for a separate pull request."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans"
],
"request": "Replace the H1 title with this text.",
"text": "# The Protocol reads its next work from its roadmap and keeps its delivery record in git and its pull requests",
"reason": "The behavior now covers reviews."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#rule.plansFrozen"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#plansFrozen] `plans/` and `reviews/` keep the plans and review records of the arcs that had them as history until a cleanup arc removes or archives them; no file is added to either, and a file in either changes only to correct the record it keeps.",
"replaces": "spec:protocol.roadmap-replaces-plans#rule.plansFrozen",
"reason": "Both folders freeze."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#rule.executionRecord"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#executionRecord] Before an arc's first authorized push its commits are its record: the first commit message names the arc's base, its Pack and the owner's instruction that opened it, each later message says what its unit did, and outstanding work is read from the arc's Pack, the backlogs and the open-question register. At the first authorized push the draft pull request description takes the record: its branch and base, working rules, lanes, the rulings with who made them, acceptance as measured, deferrals and refusals. Nothing here authorizes a push, and no check reads the record.",
"replaces": "spec:protocol.roadmap-replaces-plans#rule.executionRecord",
"reason": "Git replaces the proposed reviews/ record file."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#rule.executionRecord"
],
"request": "Add this rule after the execution-record rule.",
"text": "- rule: [#reviewFindings] A review's findings against Specs travel as one change proposal on the proposal schema, checked by the proposal check against the base it names and posted to the pull request as the proposal memo; a finding against code or another file is a review comment on its line; a finding left open becomes an open question with its `decider`, `provisional` reading and `links`; the commit that applies a proposal carries its reason line and base. No review file is committed, and a brief or prompt stays in the session that used it.",
"follows": "spec:protocol.roadmap-replaces-plans#rule.executionRecord",
"reason": "A proposal scopes Specs only, so code and file findings need their own home."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#rule.executionRecord"
],
"request": "Add this rule after the review-findings rule.",
"text": "- rule: [#evidence] Evidence no test, recipe or preview carries, such as a prototype of a view not yet built, an adopter measurement's raw output or a screenshot for the description, is committed on the arc's branch with the commands that made it, linked from the description pinned to that commit, and removed before the merge; the merge keeps the commit reachable, so the link lasts.",
"follows": "spec:protocol.roadmap-replaces-plans#rule.executionRecord",
"reason": "Answers where evidence lives once reviews/assets retires."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#rule.gateRecord"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#gateRecord] The self-hosting gate's current-record check refuses a handbook that does not name the roadmap Pack or the roadmap recipe, and a roadmap Pack manifest that is missing or does not state `order: priority`; it keeps the frozen historical checks, the documented green-gate legs, and the ban on plan status in the decision registry and the glossary until the cleanup arc removes the folders they read.",
"replaces": "spec:protocol.roadmap-replaces-plans#rule.gateRecord",
"reason": "No plan-number ceiling."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#design.recordFile"
],
"request": "Remove this Design entry; no record file exists.",
"reason": "The record file is dropped."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#design.frozenCeiling"
],
"request": "Remove this Design entry; the gate keeps no plan-number ceiling.",
"reason": "The ceiling check is dropped."
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans#design.gateMessages"
],
"request": "Replace the Design entry with this text.",
"text": "- gateMessages: `AGENTS.md — the handbook does not name the roadmap Pack`, `AGENTS.md — the handbook does not name the roadmap recipe`, `specs/roadmap.pack.sdp.md — the roadmap Pack's manifest is missing`, and `specs/roadmap.pack.sdp.md — the roadmap Pack's manifest does not state order: priority`.",
"replaces": "spec:protocol.roadmap-replaces-plans#design.gateMessages",
"reason": "Drops the ceiling message."
},
{
"scope": [
"spec:consumers.graph-first-planning"
],
"request": "Replace the unkeyed rule that opens `A plan file points to the Pack and carrying Specs` with this text, as the roadmap-over-plans decision's consequence requires.",
"text": "- rule: A corpus that keeps plan documents lets each point to its Packs and carrying Specs for intended truth and derived state; a plan document confers nothing, and plan numbering, recorded work order and staleness never become graph structure or workflow authority. Advisory priority over the next work lives in a roadmap Pack.",
"reason": "The decision says this rule narrows; no edit carries it yet."
},
{
"scope": [
"spec:consumers.roadmap"
],
"request": "Rename the derived step from lane to need throughout the Spec: the answer fields `lane` become `need`, the Design key `laneValues` becomes `needValues`, the rule keys `specLane` and `entryLane` become `specNeed` and `entryNeed`, and the rule key `needs` becomes `entryDetail` so the key no longer reads as the new word; prose `lane` becomes `need`, keeping the values to design, to state, to build, built and settled.",
"reason": "A PR description's lanes, a design wave's lanes and edge routing's lanes already use the word; the memo is pasted into the description."
},
{
"scope": [
"spec:consumers.roadmap.memo"
],
"request": "Rename lane to need in prose and in every field the memo reads from recipe 53, matching the roadmap Spec's rename.",
"reason": "Keeps the memo on the roadmap's word."
},
{
"scope": [
"spec:consumers.spec-studio.roadmap-page"
],
"request": "Rename lane to need in prose and fields, and the rule keys `laneLists` and `laneFilter` to `needLists` and `needFilter`; the board's column headings stay To design, To state, To build and Built.",
"reason": "Keeps the page on the roadmap's word."
},
{
"scope": [
"spec:decisions.epics-of-any-kind"
],
"request": "Remove the blocking question `epicKinds`, and replace the Decision section's entries with these, so the record states the ruling rather than a proposal.",
"text": "- context: The glossary's capability row names a Capability Map over high-altitude behavior Specs, while kind and altitude are independent coordinates on the one primitive and the hubs that already state the Protocol's capabilities include model and rule Specs.\n- decision: Any Spec stated at epic altitude is an epic and keeps its kind; the capability map reads every such Spec and its refinement descendants, and no view selects capabilities by kind.\n- rationale: Hard to reverse: once corpora state model and rule epics, narrowing to behavior would force wrappers across every corpus. Surprising without context: the ratified glossary row named behavior Specs. A real trade-off: one outcome owner per capability against a map whose entries share one kind.\n- alternative: Keep behavior-only capability epics and add behavior wrappers over the model and rule hubs: each wrapper restates an outcome another Spec owns, a second owner that drifts, only so a view can read it.\n- consequence: The glossary's capability row names a Capability Map over epic Specs of every kind and their declared refinement descendants.\n- consequence: A hub whose outcome already names a capability is enriched in place to epic altitude, keeping its id, kind and readiness.",
"reason": "The record still says Proposed for the owner and holds two Specs below ready."
},
{
"scope": [
"spec:model.structural-patterns"
],
"request": "Replace the definition of the Model term `architecturally significant unit` with this text.",
"text": "- **architecturally significant unit** — A code unit with exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand to change a system guarantee. Ports, shared data shapes, pipeline stages, decision tables, catalogs, layout policies and adapters may qualify; being exported, re-exporting other units or ranking high on imports is not enough by itself. Its anchor records component membership, a role and references to the designs it answers to. An architectural dependency is declared as `uses`, normally between components; a unit's own `uses` is optional.",
"reason": "Makes the existing `warrants` clause concrete; drift repair, since exported-as-sufficient would make anchoring a coverage quota the decision refuses."
},
{
"scope": [
"spec:protocol.structural-self-binding#rule.criterion"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#criterion] The engine applies the structural-patterns model's significance criterion: exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand; being exported alone is not enough.",
"replaces": "spec:protocol.structural-self-binding#rule.criterion",
"reason": "Aligns the ready rule with the model term."
},
{
"scope": [
"spec:decisions.architectural-annotation"
],
"request": "Replace the consequence that opens `The engine significance criterion stays exported public surface or cross-component reach` with this text, keeping the rest of the section unchanged; record it in the pull request's delegated-rulings table as an alignment of ratified wording.",
"text": "- consequence: The engine significance criterion requires exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand, as `spec:model.structural-patterns` defines it; being exported alone is not enough. Code never satisfies a decision Spec directly (the binding-grain ruling, MD-37), and an anchor is never pointed at an unfinished Spec to manufacture coverage.",
"reason": "Leaving the ratified text reading export as sufficient would contradict the model term it governs."
},
{
"scope": [
"spec:protocol.significant-units-review"
],
"request": "Remove the open questions `acceptedRoster` and `notationBoundary` once ruled, and add this sentence to the narrative after its first paragraph; the roster oracle carries the membership itself.",
"text": "The example-space decoder belongs to the reader component although its file sits under `src/notation/`: it reads graph shapes and emits findings, and as a notation member it would tie notation, graph and validate into one uses cycle, while as a reader member notation stays a leaf codec.",
"reason": "Keeps the why once, in the Spec, after the review file retires."
},
{
"scope": [
"spec:consumers.design-slice"
],
"request": "Remove the non-blocking question `sliceTerm` once the glossary lists design slice among its guidance-only labels.",
"reason": "The words ruling answers it."
},
{
"scope": [
"spec:consumers.spec-studio.capability-map-page"
],
"request": "Declare `refines` on spec:consumers.capability-map with the reason `the page is the capability map's reading for a person`, keeping the existing refinement and dependency.",
"relation": {
"action": "declare",
"from": "spec:consumers.spec-studio.capability-map-page",
"type": "refines",
"target": "spec:consumers.capability-map"
},
"reason": "Without it the roadmap entry reads built when recipe 52 ships and the page does not."
},
{
"scope": [
"spec:consumers.spec-studio.slice-page"
],
"request": "Declare `refines` on spec:consumers.design-slice with the reason `the page is the design slice's reading for a person`, keeping the existing refinement and dependency.",
"relation": {
"action": "declare",
"from": "spec:consumers.spec-studio.slice-page",
"type": "refines",
"target": "spec:consumers.design-slice"
},
"reason": "Puts the slice page in its roadmap entry's scope."
},
{
"scope": [
"spec:consumers.spec-studio.roadmap-page"
],
"request": "Declare `refines` on spec:consumers.roadmap with the reason `the page is the roadmap's reading for a person`, keeping the existing refinement and dependency.",
"relation": {
"action": "declare",
"from": "spec:consumers.spec-studio.roadmap-page",
"type": "refines",
"target": "spec:consumers.roadmap"
},
"reason": "Puts the roadmap page in its roadmap entry's scope."
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds.legibility"
],
"request": "Declare `refines` on spec:consumers.spec-studio.diagram-kinds with the reason `readable labels are part of the outcome the diagram kinds state`, keeping the refinement of the diagram contract.",
"relation": {
"action": "declare",
"from": "spec:consumers.spec-studio.diagram-kinds.legibility",
"type": "refines",
"target": "spec:consumers.spec-studio.diagram-kinds"
},
"reason": "The owner's legibility ask is outside the diagram-kinds entry's scope today."
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds.edge-routing"
],
"request": "Declare `refines` on spec:consumers.spec-studio.diagram-kinds with the reason `arrows that cover no label serve the readable drawings the diagram kinds state`, keeping the refinement of the diagram contract.",
"relation": {
"action": "declare",
"from": "spec:consumers.spec-studio.diagram-kinds.edge-routing",
"type": "refines",
"target": "spec:consumers.spec-studio.diagram-kinds"
},
"reason": "Same scope gap as legibility."
},
{
"scope": [
"spec:consumers.spec-studio.lenses"
],
"request": "Replace the title, the narrative paragraph and the Intent outcome with these three lines, in that order.",
"text": "# Five lenses read the graph as Packs, capabilities, architecture, tests and evidence\nEach lens is a page with a Spec of its own, so each builds on the graph it reads today: the Packs, capabilities, architecture and tests lenses read what the graph records, and the evidence lens reads not tracked until the graph records an observation. This Spec keeps what the five share.\n- outcome: Let a person see the graph five ways, by Pack, by capability, by architecture, by verification and by evidence, from one top navigation.",
"reason": "The shared lens contract is ready and still says four lenses."
},
{
"scope": [
"spec:consumers.spec-studio.lenses#rule.order"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#order] The lenses are pages of the page set, reached from the top navigation in the order Packs, capabilities, architecture, tests, evidence; the index page is the Packs lens and the default landing page.",
"replaces": "spec:consumers.spec-studio.lenses#rule.order",
"reason": "Integrates the Capabilities lens."
},
{
"scope": [
"spec:consumers.spec-studio.lenses#ui.lensPages"
],
"request": "Replace the UI entry with this text.",
"text": "- lensPages: `index.html` for the Packs lens, `capabilities.html` for the capabilities lens, `architecture.html`, `tests.html` and `evidence.html`, each opening with its name and one sentence saying what it reads.",
"replaces": "spec:consumers.spec-studio.lenses#ui.lensPages",
"reason": "Integrates the Capabilities lens."
},
{
"scope": [
"spec:consumers.spec-studio.lenses.packs"
],
"request": "Replace the narrative paragraph before Intent with this text.",
"text": "Packs collect Specs for review, while the separate Capabilities page reads authored refinement. The index remains the landing page and keeps each Pack's members in authored order.",
"reason": "The narrative says no view draws capabilities."
},
{
"scope": [
"spec:consumers.spec-studio.lenses.packs#rule.packGrouping"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#packGrouping] The Packs lens groups Specs by Pack, each Pack's members in authored order. The separate Capabilities page reads refinement; selecting an epic narrows the index's Specs section without changing any Pack.",
"replaces": "spec:consumers.spec-studio.lenses.packs#rule.packGrouping",
"reason": "The glossary cites this rule for draws no capability tree."
},
{
"scope": [
"spec:consumers.spec-studio.index-page#rule.filters"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#filters] Filters narrow the Specs section by kind, altitude, stated rung, floor reached, implementation binding, verifier binding, Pack and epic; each filter takes one value or any, the epic filter also takes no epic, the filters combine, and the section says how many of its rows it shows. Without script every row shows.",
"replaces": "spec:consumers.spec-studio.index-page#rule.filters",
"reason": "Integrates the epic filter."
},
{
"scope": [
"spec:consumers.spec-studio.data#rule.readerValues"
],
"request": "Replace the Contract entry with this text.",
"text": "- [#readerValues] The build renders the index from `specs()`, `packs()`, `findings()`, each Spec's design columns and the epic memberships recipe 52 answers, a Pack page from `packContext` and the Pack totals, a Spec page from `specContext`, and the search page from the search index; every page's rail renders the rail values. A page states no value the reader did not return or a named recipe did not answer, apart from counts the build takes of those values.",
"replaces": "spec:consumers.spec-studio.data#rule.readerValues",
"reason": "Integrates recipe 52 into the index."
},
{
"scope": [
"spec:consumers.spec-studio.data.recipe-answers#design.recipeEvaluations"
],
"request": "Replace the Design entry with this text.",
"text": "- recipeEvaluations: a build evaluates each of these once, with no parameter unless one is named: recipes 17, 20, 24, 31, 33, 43, 44, 46, 51 and 53; recipe 52 with `{ detail: true }`; recipe 29 with `{ pack: id }` and recipe 54 with `{ pack: id, detail: true }` for every Pack; recipe 55 with `{ pack: id }` for every Pack whose manifest states `order: priority`; recipe 21 with `{ spec: id }` and recipe 30 with `{ specs: [id] }` for every Spec; recipe 34 with `{ spec: id }` for every Spec that is not an example, Specs in no Pack included; given a base graph, recipe 35 with `{ base, detail: true }`, and with `{ base, pack: id, detail: true }` for every Pack; given run records, recipe 45 with `{ runs }`.",
"replaces": "spec:consumers.spec-studio.data.recipe-answers#design.recipeEvaluations",
"reason": "The new pages read recipes 52 to 55, which the ready data contract does not name."
},
{
"scope": [
"spec:consumers.spec-studio.data.recipe-answers#design.pageRecipes"
],
"request": "Replace the Design entry with this text.",
"text": "- pageRecipes: the index renders reader values and each Spec's `epicIds` from recipe 52; the glossary renders reader values only; the capabilities lens renders recipe 52; the architecture lens renders recipes 17 and 43; the tests lens renders every recipe 34 answer, recipe 44, and recipe 45 given run records; a Spec page renders its recipe 21, 30 and 34 answers, its own space from recipe 44, the recipe 51 rows that cite its entries, the recipe 45 files whose `specs` hold its id, and its own row of recipe 35's whole-corpus answer; a Pack page renders the totals of its recipe 29 answer and, given a base graph, its own recipe 35 answer; a slice page renders its Pack's recipe 54 answer; the roadmap page renders recipe 53 and each roadmap's recipe 55 memo; the registers render recipes 20, 31, 24 beside recipe 51's rows, and 33; the owner queue renders recipe 46; the diff page renders recipe 35's whole-corpus answer; the runs page renders recipe 45; an export renders the values of the pages it holds.",
"replaces": "spec:consumers.spec-studio.data.recipe-answers#design.pageRecipes",
"reason": "Names which page reads which new recipe."
},
{
"scope": [
"spec:consumers.spec-studio.navigation#rule.topEntries"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#topEntries] After the lens entries, the top navigation lists Roadmap, Queue, Questions, Decisions, Declarations, Backlog and Glossary, then Diff when the build was given a base graph and Runs when it was given run records, each linking its page; the search field follows them.",
"replaces": "spec:consumers.spec-studio.navigation#rule.topEntries",
"reason": "No Spec places the Roadmap entry; it leads the planning pages."
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds#rule.drawnKinds"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#drawnKinds] The Studio adds dependency depth, capability refinement, scoped architecture, a component uses matrix beside the architecture lens's drawing, and the maturity map as a grid of counts; requirement traceability replaces the realization drawing on a Spec page. Equivalent Mermaid forms share one Studio drawing.",
"replaces": "spec:consumers.spec-studio.diagram-kinds#rule.drawnKinds",
"reason": "Adds the matrix the dense architecture drawing needs."
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds#design.architecture"
],
"request": "Add this Design entry after `architecture`.",
"text": "- usesMatrix: Draw a component uses matrix, a design structure matrix, beside the architecture lens's drawing: one row and one column per realized component in one order, a mark where the row's component uses the column's. A table stays legible at any number of uses, where routed edges between a dozen components run in parallel bundles. It is an HTML table read from anchored uses, needs no layout, bound or fold, and offers no Mermaid source because Mermaid has no matrix form.",
"follows": "spec:consumers.spec-studio.diagram-kinds#design.architecture",
"reason": "Answers item 11 at the cost of one table."
},
{
"scope": [
"spec:consumers.spec-studio.lenses.architecture#ui.architecturePage"
],
"request": "Replace the UI entry with this text.",
"text": "- architecturePage: in order, the page title `Architecture`, the summary sentences, the architecture diagram or its fold with one section per context, the component uses matrix, the `Designed, not built` section, the component details in id order, and the `Unresolved structure` section when it has rows.",
"replaces": "spec:consumers.spec-studio.lenses.architecture#ui.architecturePage",
"reason": "Places the matrix."
},
{
"scope": [
"spec:consumers.spec-studio.lenses.architecture#ui.architecturePage"
],
"request": "Add this UI entry after `architecturePage`.",
"text": "- usesMatrix: a table captioned `Which components use which`, one row and one column per realized component, ordered by layer from `edge` to `infrastructure`, unlayered components last, then by id; the cell where a row's component uses a column's holds a mark linking that use in the row component's detail, every other cell is empty, and each header names the component's label with its id as code.",
"follows": "spec:consumers.spec-studio.lenses.architecture#ui.architecturePage",
"reason": "States the matrix's shape."
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds.dependency#rule.fold"
],
"request": "Replace the rule with this text.",
"text": "- rule: [#fold] The boundary band always folds into one box per relation type that names its count, keeping as its own box each outside Spec that holds a member's stated next rung or states below defined, and every folded Spec stays a row of the text equivalent; above the shared bound, whole depth bands fold in descending box count, ties by ascending depth; if the drawing still exceeds the bound, the SVG is omitted and the text equivalent opens.",
"replaces": "spec:consumers.spec-studio.diagram-kinds.dependency#rule.fold",
"reason": "Most of the arc drawing's crossings run to unfolded outside boxes the slice page already lists."
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds.maturity-picture#rule.fullMembership"
],
"request": "Add this rule after `fullMembership`.",
"text": "- rule: [#oneCell] When every member falls in one cell, a sentence naming that cell and its count, followed by the cell's member list, stands in place of the grid; the grid draws when two or more cells hold members.",
"follows": "spec:consumers.spec-studio.diagram-kinds.maturity-picture#rule.fullMembership",
"reason": "A settled Pack spends twenty cells on one number."
}
]
} |
Advisory review: GPT-6-Astra (extra-high effort), opinionOne of two independent advisors on plan 47's decision items; the other advisor's review is in its own comment. The executing thread rules after reading both. Read at I support the roadmap, the nine epic boundaries, and the separate Studio slice page.
Exact non-Spec text for the executing thread Apply these when switching to the built convention, reconciling the concurrent edits; these are proposed replacements, not edits I made to the repository. In > Work is read from the graph. The Protocol's next work is `pack:roadmap`, carried by
> `specs/roadmap.pack.sdp.md` with `order: priority`; run recipe 53 for each entry's
> derived need and what holds it. Read its arc Pack and carrying Specs for intent,
> decisions and open questions, and the draft pull request for the arc's narrative
> and review disposition. Before the first authorized push, substantive commits
> preserve changes and their reasons; unfinished session material stays in the session.
> Re-derive readiness, backlog and findings rather than inheriting a prior summary.
> Existing `plans/` and `reviews/` are historical evidence pending separate cleanup.Replace the live-work sentence under “The build path” with: Live work is read through recipe 53 over `pack:roadmap`; follow the selected entry to its arc Pack and carrying Specs.Replace the | `specs/roadmap.pack.sdp.md` and recipe 53 | the selected next work, its advisory priority and derived needs | before choosing or opening work |
| `plans/` and `reviews/` | historical evidence retained until dedicated cleanup | only for an earlier arc's record |Replace the “Tests are the evidence” bullet and the evidence-storage instruction in “Show it to a person” with this shared convention, stated once and referenced from the other location: Tests and recipes carry repeatable evidence. Commit only evidence they cannot carry under `docs/evidence/<arc>/`, named for the capability: prototype pages, rendered screenshots and adopter measurements with their corpus and engine commits, input scope and reproduction commands. Label a prototype as proposed. Link the assets from the pull request at an immutable commit. An asset index records provenance and reproduction, never tasks, rulings or review disposition. A preview is a current view; compare its stamp with each run report's recorded commit before citing that run as evidence for it.Replace the current-record advice inside “Commits are recovery boundaries” with: Commit authority comes from the owner's instruction for the arc. Record substantive changes, their reasons and relevant recovery facts in commits; open the draft pull request at the first authorized push. Keep unfinished session material in the session, preserve uncommitted work, and never claim git recorded it. Resume by reading the tree, diff, commits and current graph. This convention grants no authority to commit or push.In | **roadmap** | a Pack whose manifest states `order: priority`, giving its authored member order the meaning of advisory priority; each entry's need is derived from its refinement scope (`spec:consumers.roadmap`); membership grants no readiness, delivery fact or permission | schedule · workflow state |
| **capability / domain** | a Pack grouping and/or a Capability Map projection over epic Specs of every kind and their declared refinement descendants; Pack membership and refinement remain distinct (`spec:consumers.capability-map`) | a kind or an altitude |
| **architecturally significant unit** | a code unit with exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand to change a system guarantee; export status or import rank alone is insufficient; the owner-reviewed accepted set is curated, with component membership, role and design bindings on the realizing anchor and architectural dependencies declared as uses (`spec:model.structural-patterns`) | pattern, as a Protocol concept |
`design slice` names a per-invocation reading of selected Specs as one design (`spec:consumers.design-slice`); it names no saved grouping, primitive or workflow stage.In Use a Markdown `*.pack.sdp.md` manifest with `id`, `specs`, optional `modelRefs` and optional `order: priority`. The H1 is the Pack title and the remaining body prose is its framing. Preserve authored membership order: it is reading order unless the manifest explicitly states priority. Follow `spec:carrier.markdown-pack-authoring` for the carrier law and `spec:decisions.roadmap-priority` for its advisory meaning. A corpus chooses its own planning records; the Protocol's convention is carried by `spec:protocol.roadmap-replaces-plans`.Replace the first paragraph under “Curate the anchors” with the following, retaining the separate document-realization convention: Anchors are curated, never a coverage quota. Start with public contracts and cross-component responsibilities a designer or builder must understand, and read the code before adding an identity. An export, import ranking, test expectation or desired file-impact answer does not establish significance. Leave a wrapper, forwarding barrel, empty registration or formatting helper bare unless it owns an independent contract or responsibility. One identity has one file owner; one responsibility realizing several Specs normally uses plural targets. Independent responsibilities in one file may keep separate identities. Before merging or dropping an identity, account for every target promise and its surviving realizing units. A realizing unit documents its local how, never a paraphrase of the Spec's what or why.In Hand proposed Spec edits back as one change proposal against the commit read, with exact text and resolving Spec or entry scopes. Check it with recipe 38 against the graph derived at that base, and render the human memo with recipe 49. In the Protocol, post the memo, including its exact JSON, to the pull request; keep non-Spec findings as ordinary pull request comments, and write no empty proposal for a review with no Spec edits. An unresolved design question belongs on its carrying Spec with a decider, links and a provisional reading; a deferral is blocking and names its trigger. A code defect against settled intent remains a code finding. The carrying convention is `spec:protocol.roadmap-replaces-plans`.For the registry row currently assigned MD-47 in | MD-47 | graph intent and pull request records replace plan and review files | durable | The Protocol reads selected work from its roadmap, keeps intent in carrying Specs and changes in git, and presents delivery narrative, proposal memos and evidence through pull requests; existing plan and review files await separate cleanup. Narrows MD-33 for the Protocol's own practice. | [Spec](../../specs/decisions/roadmap-over-plans.sdp.md) (`spec:decisions.roadmap-over-plans`) |In const roadmapPath = 'specs/roadmap.pack.sdp.md';
expectContains(agentsPath, agents, 'pack:roadmap',
'the handbook does not name the roadmap Pack');
expectContains(agentsPath, agents, 'recipe 53',
'the handbook does not name the roadmap recipe');
if (!existsSync(join(rootDir, roadmapPath))) {
failures.push(`${roadmapPath} — the roadmap Pack's manifest is missing`);
} else {
const frontmatter = /^---\r?\n([\s\S]*?)\r?\n---(?:\r?\n|$)/u
.exec(read(roadmapPath))?.[1] ?? '';
if (!/^order:[ \t]+priority[ \t]*$/mu.test(frontmatter)) {
failures.push(`${roadmapPath} — the roadmap Pack's manifest does not state order: priority`);
}
}Replace // Current record: the handbook names the roadmap Pack and recipe, and the
// manifest explicitly states priority order. This checks repository pointers,
// never roadmap content, work order, freshness, review disposition or plan numbers.The gate snippet checks the explicit manifest line selected for this repository; it is not a new Protocol validator or a substitute for the carrier's conformance checks. Its test expectations must follow the new pointer and report fields when implemented. Evidence and proposal check I read PR 36 first, then the required repository documents and skills, queried the graph before judging Specs, read the annotation review and relevant lane material, inspected the supplied screenshots, and queried the read-only platform corpus. The recipe-35 base was derived without writing files from the clean existing plan-46 checkout, whose entire tracked tree equals The preview stamp named merge commit
|
Advisory review: GPT-6-Astra, change proposalThe advisor's Spec edits as one change proposal ( Change proposalBase: Change 1Scope: Change 2Scope: Change 3Scope: Relation: declare Change 4Scope: Relation: declare Change 5Scope: Relation: declare Change 6Scope: Change 7Scope: Replaces: Change 8Scope: Change 9Scope: Replaces: Change 10Scope: Replaces: Change 11Scope: Replaces: Change 12Scope: Follows: Change 13Scope: Replaces: Change 14Scope: Follows: Change 15Scope: Replaces: Change 16Scope: Change 17Scope: Follows: Change 18Scope: Change 19Scope: Replaces: Change 20Scope: Replaces: Change 21Scope: Replaces: Change 22Scope: Replaces: Change 23Scope: Replaces: Change 24Scope: Replaces: Change 25Scope: Replaces: The proposal{
"schema": "sdp-proposal/1",
"base": "2dc5c44cb4d6a162be6d8fb49c33451f5601a898",
"reason": "Make the retirement precedent usable, align significance and roadmap wording, and resolve drawing contracts before the delegated build.",
"changes": [
{
"scope": [
"spec:decisions.roadmap-over-plans"
],
"request": "Replace this Spec's body (after its existing frontmatter) with the exact text below; preserve its current envelope, readiness and relations, and reconcile the moved-scope report before applying.",
"text": "# The Protocol replaces plan and review files with graph intent and pull request records\n\nThe roadmap selects upcoming work, carrying Specs state its intent, and git keeps changes to that intent. A pull request explains the arc and presents its review and evidence. Retiring plan and review files removes competing records; it does not remove durable evidence.\n\n## Intent\n\n- outcome: Give the Protocol one home for each planning and review concern while keeping its delivery narrative and evidence recoverable.\n\n## Decision\n\n- context: The roadmap gives advisory priority a graph home, and the pull request description already carries an arc's narrative, rulings and measured acceptance. The owner has selected retirement of both plan and review files, with their removal or archival in a separate cleanup change.\n- decision: The Protocol stops using `plans/` and `reviews/` for new delivery records. Its roadmap Pack holds advisory priority; its arc Packs group the carrying Specs; those Specs own intent, rulings and open questions, with triggers on deferrals. Before the first authorized push, substantive git commits record changes and the reasons and recovery facts needed to understand them, while unfinished session material remains in the session. From the first authorized push, a draft pull request carries the arc's narrative, branch and base, working rules, lanes, rulings with their authority, measured acceptance and forward section. Reviews hand off proposed Spec edits as checked change proposals and their rendered memos on the pull request; findings outside that schema travel as ordinary pull request comments. No replacement plan file, review file or review-status primitive is introduced.\n- rationale: Hard to reverse: agents, the handbook and a repository check change their entry point from the current plan to the roadmap. Surprising without context: both historical folders cease receiving delivery records. A real trade-off: the graph and git supply durable intent and changes without a second working record, while the pull request supplies the human narrative and separately preserved evidence supplies what a live preview cannot retain.\n- alternative: Keep a record file until the first push: this recreates the review-file lane the owner has retired and leaves another record to reconcile.\n- alternative: Put execution history, review approval or priority rationale into new Spec fields: these are not system truth, and git and the pull request already carry the history and explanation.\n- alternative: Keep only links to the latest preview or expiring CI artifacts: a later run can replace the evidence a historical description cites.\n- consequence: The handbook names `pack:roadmap` and recipe 53. The repository's roadmap check checks that pointer and the manifest's explicit priority order, retaining frozen historical assertions until the separate cleanup change and retaining its green-gate and semantic-surface checks. It adds no plan-number ceiling or check of roadmap content, work order, freshness or review disposition.\n- consequence: The proposal schema continues to scope Specs only. A review finding that changes no Spec does not acquire an invented Spec scope, and a review with no proposed Spec changes needs no empty proposal.\n- consequence: Accepted design changes are ordinary carrier edits; an unresolved design question lives on its carrying Spec with a decider, links and a provisional reading, and a deferred question is blocking with a trigger. Acceptance and rejection of a proposal remain pull request discussion and git history, never proposal fields or graph facts.\n- consequence: Tests and recipes carry repeatable evidence. A preview is the current human view, with its stamp, diff and externally supplied runs; a preview URL is not an immutable acceptance record. Evidence no test or recipe can carry is committed under `docs/evidence/<arc>/`, named for the capability, with provenance and reproduction instructions and commit-pinned links from the pull request; it carries no task ledger, ruling table or review disposition.\n- consequence: Commit and push authority comes from the owner's instruction and is not created by this record convention. Git cannot preserve uncommitted session state; a later session reconstructs current work from the tree, diff, commits and graph rather than claiming a missing session was recovered.\n- consequence: Existing plans, reviews and their assets remain available until the dedicated cleanup change removes or archives them and updates their historical checks and links. This decision imposes no record convention on an adopter.\n"
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans"
],
"request": "Replace this Spec's body (after its existing frontmatter) with the exact text below; preserve its current envelope, readiness and relations, and reconcile the moved-scope report before applying.",
"text": "# The Protocol reads work from its roadmap and records delivery through git and pull requests\n\nAn arc's Pack groups its intent; its carrying Specs state the design and decisions. The roadmap selects upcoming work. Git preserves changes and the pull request explains them, with review handoffs and evidence beside the explanation.\n\n## Intent\n\n- actor: A person or agent opening, reviewing or resuming the Protocol's work.\n- problem: Plan and review files duplicate intent, narrative and evidence already carried elsewhere and make sessions reconcile competing records.\n- outcome: Make the roadmap, carrying Specs, git and pull request sufficient to choose, review and recover work without a new plan or review file.\n\n## Behavior\n\n- rule: [#readsRoadmap] An agent opening the Protocol's next work runs recipe 53 over the roadmap Pack the handbook names and follows each entry to its Packs and carrying Specs.\n- rule: [#oneRoadmap] The Protocol keeps one living roadmap Pack, edited in place. Its owner selects captured work for the upcoming pull requests; landing a capture does not add it. Entries leave by an ordinary manifest edit when the selected work is complete or no longer belongs among the next work, and move on the owner's word, with git as history.\n- rule: [#plansFrozen] The Protocol adds no delivery record under `plans/` or `reviews/`. Existing material remains historical evidence until a separate cleanup change removes or archives it and updates its links and historical checks.\n- rule: [#executionRecord] Before the first authorized push, substantive commits preserve the changes and their reasons and relevant recovery facts; unfinished briefs, prompts and session state remain in the session. From that push, a draft pull request carries the arc's narrative, branch and base, working rules, lanes, rulings with their authority, acceptance as measured, deferrals and refusals. Neither a commit message nor a pull request authorizes a commit or push. A session resuming without its predecessor's context reads the tree, diff, commits and graph and does not claim that git preserved uncommitted state.\n- rule: [#forwardSection] Each description's forward section is the roadmap memo rendered at the branch's head, with the re-entry condition, the owner's explanation of priority and the refused list in the author's words around it. The pull request that completes an entry's selected work removes it from the roadmap in the same change; entries join or move only on the owner's word, and nothing checks either.\n- rule: [#reviewHandoff] Proposed Spec edits travel as the change proposal of `spec:consumers.intent-composition.proposal`, checked by recipe 38 against a graph derived at its named base and rendered by recipe 49 under `spec:consumers.intent-composition.proposal.memo`; the memo, including its exact JSON, is posted to the pull request. Moved, unresolved or incomparable scopes are reviewed before application. Findings about code, tests, Packs or other files that request no Spec edit remain ordinary pull request comments, and a review with no proposed Spec edits has no proposal.\n- rule: [#openFindings] An unresolved question about intended design lives on its carrying Spec with `decider`, `provisional` and `links`; a deferral is a blocking question with its re-entry `trigger`. A code defect against settled intent remains a code finding until repaired and does not become an invented design question. Proposal disposition is kept in pull request discussion and git, never in the proposal or graph.\n- rule: [#acceptanceEvidence] Acceptance links bound examples and their run evidence, and re-derives recipe measurements for the description at the cited commit. The preview's runs page reports external test-file results, not individual verifier verdicts; each report's recorded commit is compared with the preview stamp before it is used as evidence for that preview. The diff page compares with its explicitly supplied base. The description names the measured commit and commands rather than inheriting prior results.\n- rule: [#evidenceAssets] Preserve evidence no test or recipe can carry under the evidence path, including prototypes for unbuilt views, rendered screenshots and adopter measurements that need external inputs. Its provenance names the corpus and engine commits, input scope, commands and whether it depicts a proposal or a built view. The pull request links to the assets at an immutable commit; the preview remains a current view, and no asset index carries an execution or review ledger.\n- rule: [#canonicalExample] The arc that introduces this convention demonstrates the complete chain with its own roadmap and arc Pack, a real addressed proposal rendered as a memo, a resulting carrier edit or an unresolved keyed question, a stamped preview and diff, and acceptance evidence. The pull request links each part so an adopter can follow the example without a plan or review file.\n- rule: [#handbookPointer] The handbook names the roadmap Pack and recipe 53 where it named the current plan, and keeps no stack of plan-status lines.\n- rule: [#gateRecord] The repository's roadmap check refuses a handbook that does not name the roadmap Pack or recipe 53 and a roadmap manifest that is missing or does not explicitly state `order: priority`. It retains frozen historical checks until the separate cleanup change, documented green-gate legs and the ban on plan status in the decision registry and glossary. It checks no plan-number ceiling, roadmap content, freshness, work order or review disposition.\n\n## Design\n\n- roadmapPack: `pack:roadmap`, carried by `specs/roadmap.pack.sdp.md`.\n- evidencePath: `docs/evidence/<arc>/`, with `<arc>` the capability name; an asset index names only evidence provenance and reproduction, never work status.\n- handbookTokens: the gate reads the handbook for `pack:roadmap` and `recipe 53`, and the roadmap manifest's frontmatter for the explicit `order: priority` declaration.\n- gateMessages: `AGENTS.md — the handbook does not name the roadmap Pack`, `AGENTS.md — the handbook does not name the roadmap recipe`, `specs/roadmap.pack.sdp.md — the roadmap Pack's manifest is missing`, and `specs/roadmap.pack.sdp.md — the roadmap Pack's manifest does not state order: priority`.\n\n## Verification — reviewed\n\n- Follow the introducing arc's linked example from roadmap entry to intent, proposal memo, disposition and commit-specific evidence without reading a plan or review file.\n- Resume from a branch without a draft pull request using its tree, diff, commits and current graph, and identify any context that existed only in the previous session.\n- Check the roadmap pointer and manifest refusals with a missing pointer and a missing priority declaration; an empty roadmap, a built entry and preference contrary to dependency create no new finding.\n"
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans"
],
"request": "Declare the dependency used by the review and acceptance convention.",
"relation": {
"action": "declare",
"from": "spec:protocol.roadmap-replaces-plans",
"type": "dependsOn",
"target": "spec:consumers.intent-composition.proposal"
},
"text": " - spec:consumers.intent-composition.proposal"
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans"
],
"request": "Declare the dependency used by the review and acceptance convention.",
"relation": {
"action": "declare",
"from": "spec:protocol.roadmap-replaces-plans",
"type": "dependsOn",
"target": "spec:consumers.intent-composition.proposal.memo"
},
"text": " - spec:consumers.intent-composition.proposal.memo"
},
{
"scope": [
"spec:protocol.roadmap-replaces-plans"
],
"request": "Declare the dependency used by the review and acceptance convention.",
"relation": {
"action": "declare",
"from": "spec:protocol.roadmap-replaces-plans",
"type": "dependsOn",
"target": "spec:observation.run-evidence"
},
"text": " - spec:observation.run-evidence"
},
{
"scope": [
"spec:model.structural-patterns"
],
"request": "Replace only the unkeyed architecturally significant unit Model term, clarifying the existing warrants-binding test without changing its public-surface or cross-component boundary.",
"text": "- **architecturally significant unit** — A code unit with exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand to change a system guarantee. Ports, shared data shapes, pipeline stages, decision tables, catalogs, layout policies and adapters may qualify; being exported, re-exporting other units or appearing in an import ranking is insufficient by itself. Its anchor records component membership, a role and references to the designs it answers to. An architectural dependency is declared as `uses`, normally between components; a unit's own `uses` is optional."
},
{
"scope": [
"spec:protocol.structural-self-binding#rule.criterion"
],
"request": "Replace this entry with the following text.",
"text": "- rule: [#criterion] The engine applies the structural-patterns model's significance criterion: exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand; being exported alone is insufficient.",
"replaces": "spec:protocol.structural-self-binding#rule.criterion"
},
{
"scope": [
"spec:decisions.architectural-annotation"
],
"request": "Align only the consequence beginning The engine significance criterion; retain the decision's curated-set boundary and all other consequences.",
"text": "- consequence: The engine significance criterion requires exported public surface or cross-component reach whose contract or responsibility a designer or builder must understand; being exported alone is insufficient. This clarifies which units warrant binding in the owner-reviewed accepted set, without requiring an anchor for every export or changing any validator. Code never satisfies a decision Spec directly (the binding-grain ruling, MD-37), and an anchor is never pointed at an unfinished Spec to manufacture coverage."
},
{
"scope": [
"spec:consumers.projections-model.roadmap-views#question.releaseReader"
],
"request": "Replace this entry with the following text.",
"text": "- [blocking #releaseReader] Does a reader need release or baseline views that the roadmap, the recipes and git tags do not serve?\n - decider: owner\n - provisional: Keep release and baseline views deferred; the trigger opens this question and does not authorize either view's build.\n - trigger: the first published release",
"replaces": "spec:consumers.projections-model.roadmap-views#question.releaseReader"
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds.scoped-architecture#rule.boundary"
],
"request": "Replace this entry with the following text.",
"text": "- rule: [#boundary] Draw only the uses boundary the supplied design-slice architecture answer includes; never traverse it in layout. Its `uses` includes anchored pairs between touched components and pairs with one immediate outside neighbour, marked `outside: true`, as `spec:consumers.design-slice#rule.outsideNeighbors` states. Fold supplied outside neighbours into one `outside scope` box per context and layer while keeping their identities and original unit edges in the text equivalent; never add pairs between two outside components. Planned uses remain separate and never increase an anchored count.",
"replaces": "spec:consumers.spec-studio.diagram-kinds.scoped-architecture#rule.boundary"
},
{
"scope": [
"spec:consumers.spec-studio.slice-page#ui.drawingIds"
],
"request": "Replace this entry with the following text.",
"text": "- drawingIds: Both drawings take the Pack id as their subject and use their drawing kind's element-id contract. The dependency text and arrow ids are `diagram.<pack id>.dependencies.text` and `diagram.<pack id>.dependencies.arrow`; scoped architecture uses `diagram.<pack id>.architecture.text` and `diagram.<pack id>.architecture.arrow`. The kinds also own viewport, source, fold and occurrence suffixes; the page invents no singular dependency or scoped-architecture alias.",
"replaces": "spec:consumers.spec-studio.slice-page#ui.drawingIds"
},
{
"scope": [
"spec:consumers.spec-studio.lenses.architecture#rule.membershipAndUses"
],
"request": "Add a static component-uses table as the inexpensive alternative to tracing a dense drawing.",
"text": "- rule: [#usesMatrix] Beside the architecture drawing, offer a native disclosure labelled `Component uses matrix`, built from recipe 17's resolved component rows and anchored component-pair counts. Rows are using components and columns are used components, both in component-id order; a nonzero cell shows the count of original anchored unit edges and links to the using component's Uses detail, while zero reads `0` with the legend `No anchored use recorded`. Use row and column headers with full identities available as text, keep the table in a named local scroll region, and retain it without script and in print. Planned uses, unresolved endpoints and same-component unit uses stay in their existing separate readings and never enter this matrix; the matrix is a table, not another SVG or Mermaid drawing.",
"follows": "spec:consumers.spec-studio.lenses.architecture#rule.membershipAndUses"
},
{
"scope": [
"spec:consumers.spec-studio.lenses.architecture#ui.architecturePage"
],
"request": "Replace this entry with the following text.",
"text": "- architecturePage: In order, the page title `Architecture`, the summary sentences, the architecture diagram or its fold with one section per context, the `Component uses matrix` disclosure, the `Designed, not built` section, the component details in id order, and the `Unresolved structure` section when it has rows.",
"replaces": "spec:consumers.spec-studio.lenses.architecture#ui.architecturePage"
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds.maturity-picture#design.bound"
],
"request": "Add a compact default presentation so a uniform distribution does not consume the whole first view.",
"text": "- presentation: The Pack page first shows a compact text summary of populated stated-rung and floor pairs, each with its exact count and a link to its complete member list. The full grid is in a native disclosure labelled `Stated readiness by floor reached`, closed initially; counts, lists and disclosure remain available without script, and print opens the grid. A uniform Pack reads in one line before the disclosure, with no quality or completion score.",
"follows": "spec:consumers.spec-studio.diagram-kinds.maturity-picture#design.bound"
},
{
"scope": [
"spec:consumers.spec-studio.diagram-kinds#design.kanban"
],
"request": "Align the catalog's roadmap terminology.",
"text": "- kanban: Defer a separate readiness board because the maturity map shows both stated and reached rungs; refuse workflow states or inferred work order. The roadmap page's HTML lists by need already provide the categorical board over explicit graph values. Re-enter for Mermaid kanban export when a reader needs to copy that board.",
"replaces": "spec:consumers.spec-studio.diagram-kinds#design.kanban"
},
{
"scope": [
"spec:protocol.significant-units-review"
],
"request": "Settle decoder membership by responsibility; replace the working tree's decoderBoundary rule if present, otherwise add this rule after roleMeaning. Do not condition the choice on an absence of layer crossings.",
"text": "- rule: [#decoderBoundary] Example-space decoding belongs to the reader component because it interprets graph-owned vocabulary and bound points for reader and code-generation consumers. Its file may stay under notation; membership follows the responsibility. Reader uses notation for the slot codec, and code generation uses reader for decoding while retaining its direct notation dependency. Review the resulting crossings against declared architecture constraints; neither a crossing nor a lawful uses cycle by itself selects a different membership."
},
{
"scope": [
"spec:consumers.spec-studio.roadmap-page#rule.board"
],
"request": "Add a concise explanation of the derived needs beside the board.",
"text": "- rule: [#readingLegend] Beside the board, explain: `To state means the structural floor permits ready; a person still decides whether to state it. Built means every work Spec in the entry's refinement scope states ready and has an implementation binding; it reports neither a passing test nor deployment. The entry's own readiness is shown separately.`",
"follows": "spec:consumers.spec-studio.roadmap-page#rule.board"
},
{
"scope": [
"spec:consumers.roadmap.memo"
],
"request": "Replace only the opening narrative paragraph; preserve current readiness, relations and need terminology.",
"text": "A pull request description ends with a forward section: the next work in priority order, what waits on the owner and what is deferred until its trigger. The roadmap memo renders that reading from the graph at the branch's head. It copies each entry's purpose from its intent and derives its dependency reach; the owner's reason for the priority, the next pull request's re-entry condition and the durable refused list stay the description author's words around it."
},
{
"scope": [
"spec:consumers.roadmap.memo#rule.whyNow"
],
"request": "Replace this entry with the following text.",
"text": "- rule: [#whyNow] The Purpose and reach cell copies the entry's intent problem, or its outcome when no problem is stated, and reports how many Specs outside its scope rest on it and how many of its parts are ready to build now. These values explain purpose and graph structure; they do not derive why the owner selected this entry or its priority. The description's author may state that reason around the memo, and the memo adds no date, estimate or assignment.",
"replaces": "spec:consumers.roadmap.memo#rule.whyNow"
},
{
"scope": [
"spec:consumers.roadmap.memo#rule.authorsOwn"
],
"request": "Replace this entry with the following text.",
"text": "- rule: [#authorsOwn] The memo derives no priority rationale and carries no re-entry condition or refused list; the description's author writes those around it.",
"replaces": "spec:consumers.roadmap.memo#rule.authorsOwn"
},
{
"scope": [
"spec:consumers.roadmap.memo#design.memoDesign"
],
"request": "Rename the derived column Purpose and reach without changing its source values or other formatting.",
"text": "- memoDesign: the section `### To design` holds a table with the columns `Place`, `Entry`, `Next` and `Purpose and reach`; `Next` reads, for at most three of the work rows with the entry's need, the entry's own first and the rest in Spec-id order, the row's id as a code span or `itself` for the entry's own, its stated rung and stated next rung as code spans joined by ` → `, then `held by` and each clause id followed by its targets as code spans in parentheses, or `nothing holds it`; then `and <n> more parts to design` when rows are left out; then `blocked by` and each blocking question's address as a code span, or its Spec id when unkeyed; then `decided by` and each decision below `ready` as a code span with its stated rung; the parts joined by `; `.",
"replaces": "spec:consumers.roadmap.memo#design.memoDesign"
},
{
"scope": [
"spec:consumers.roadmap.memo#design.memoState"
],
"request": "Rename the derived column Purpose and reach without changing its source values or other formatting.",
"text": "- memoState: the section `### To state` holds a table with the columns `Place`, `Entry`, `Earlier waiting statements` and `Purpose and reach`; the third column reads `No preceding waiting statement in the statement queue.` when the entry's `earlierStatements` is empty, and otherwise `in this entry` followed by those inside it as code spans, `on the roadmap` followed by those at another entry as code spans each with `(place <n>)`, and `<n> outside the roadmap`, each part present only when it holds a row and the parts joined by `; `.",
"replaces": "spec:consumers.roadmap.memo#design.memoState"
},
{
"scope": [
"spec:consumers.roadmap.memo#design.memoBuild"
],
"request": "Rename the derived column Purpose and reach without changing its source values or other formatting.",
"text": "- memoBuild: the section `### To build` holds a table with the columns `Place`, `Entry`, `Purpose and reach` and `Rests on`; `Rests on` lists each Spec the entry rests on as a code span with its need, or reads `nothing unbuilt`.",
"replaces": "spec:consumers.roadmap.memo#design.memoBuild"
},
{
"scope": [
"spec:consumers.roadmap.memo#design.memoEntry"
],
"request": "Rename the derived column Purpose and reach without changing its source values or other formatting.",
"text": "- memoEntry: an `Entry` cell is the entry's title followed by its id as a code span; the `Purpose and reach` cell is the intent line, ending with a full stop when it ends with none, then `Waited on by <n>.` when Specs wait on it and `<n> of its parts ready to build now.` for an entry not to build that has such parts.",
"replaces": "spec:consumers.roadmap.memo#design.memoEntry"
},
{
"scope": [
"spec:consumers.roadmap.memo#design.memoHead"
],
"request": "Add the same binding and human-statement explanation to a standalone memo.",
"text": "- memoHead: the memo opens with the line `## The next work, from the roadmap`, a blank line, the line `Roadmap: ` followed by the Pack's title and its id as a code span, a blank line, each paragraph of the framing as authored followed by a blank line, and for a reading-order Pack the line `This Pack's order is reading order, not a stated priority.` and a blank line. Before the framing, write `To state means the structural floor permits ready and a person still decides. Built reports readiness statements and implementation bindings across the entry's work, not passing tests or deployment.`, followed by a blank line.",
"replaces": "spec:consumers.roadmap.memo#design.memoHead"
}
]
} |
Rulings on the advisory reviewThe executing thread's rulings after reading both advisors, on the owner's delegation. The owner's
|
…ignificant-units panel, the maturity picture, the requirement drawing Conflicts resolved as the union of all four lanes. Two lanes added a text equivalent to the diagram contract with different shapes: the panels' original boxes and edges keep the name textEquivalent, and the capability page's pre-rendered refinement text is renamed textEquivalentHtml at its one producer. The Mermaid source disclosure takes a supplied source first, then an explanation, then the lane kinds. CSS keeps the print rule for maturity sources and every lane's block. The oracle keeps every lane's anchors, comment anchors and accepted units; frozen totals carry all four lanes' deltas and the pinned warnings are the five no lane binds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…t drawings - The dependency drawing exports Mermaid as `flowchart TB`, so each member points down at what it rests on, matching the deepest-first depth bands. - The scoped-architecture legend names uses (anchored), plans to use (declared) and realizes (anchored) when present. Uses and planned uses alone keep one relation family and no per-edge label; a realization link makes the families mixed, so each link carries its label and a supplied legend now keeps any edge-key list beside it. - The requirement drawing gives examples and decision records, which code never satisfies, no satisfying-binding label. - The perspectives narrative names the five lenses, and the Studio skill routes to the capabilities, roadmap and slice pages. Each carrier entry changes with its oracle transcription. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Pack: pack:roadmaps-and-slices-v1. Base: 08b59e2. Owner working rules: build this lane test-first, commit coherent units after their gates, never push or merge, never use git stash, leave .omo and plans alone. The executing thread owns arc closure. Replace current-plan selection with the handbook roadmap pointers and priority manifest check. Teach graph-based planning, review records, design rounds and epic organization. Targeted gate: 250 tests passed across self-hosting graph, handbook gate, skills and upgrade kit; touched TypeScript and script lint passed.
Add a priority Pack over order placement and the order vocabulary. Pin the complete roadmap answer and forward memo, and transcribe the additional Pack and membership edges in the checkout golden. Recipe and checkout suites: 392 tests passed. Mutation of the expected need failed as required and was restored.
The six shipped readings and shared static drawing core collectively realize the catalog. Move its core references to satisfies, bind its six drawing sites and a verifier for drawn, equivalent, deferred and refused families. Update the hand-transcribed oracle and remove the resolved gap. Diagram and graph suites: 108 tests passed; the catalog mutation failed as required and was restored.
Narrow the checkout lookup to a Pack and keep catalog choice keys in a tuple. Typecheck and the 10 checkout/catalog tests pass.
Review the golden changes for one additional Pack and its two membership edges. Keep reader summaries and per-Pack claim checks valid for both Packs. All 115 reader, schema, census, Design Review and Mermaid tests pass; typecheck passes.
Update checkout counts and page counts for its additional Pack, and assert the two resolved self-hosting gaps are absent. Consolidate the session recipe guidance and clarify when a review carries no proposal. The handbook and 168 skill tests pass, as do all 100 isolated CLI tests; the duplicate roadmap-pointer probe failed before the guidance was consolidated.
Align the upgrade guide's pinned section order with its epic and roadmap adoption guidance. Proposal base: a9e4c2b. Restore the curation exception and identity guidance, commit safeguards, and adopter wording. Replace captured recipe snapshots with transcribed expectations and strengthen scoped handbook and catalog checks. Validation: npm run check passed on this tree, including 3,253 tests, self-hosting and example projection checks, and preflight.
… entry point Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The pull request that completes an entry's selected work removes it from the roadmap in the same change (MD-47). Recipe 53 read all six of this arc's entries as built, so they leave pack:roadmap; the next PR's two captures and the composed-intent model the build backlog holds remain. PR 36's screenshots sit under evidence/pr36/ with the commands that made them; the description links them at this commit, and they are removed before merge. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner's dedicated cleanup removes plans/, reviews/ and superseded concept material after this PR, following MD-47's precedent, once the durable content they still hold has moved into the graph. It is captured at idea, with that inventory as its blocking question, and leads the roadmap ahead of the two Studio captures and the composed-intent model. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner's working rules: build lane F2 on p47/f2-roadmap from f9e3a10 for pack:roadmaps-and-slices-v1. Work only in this lane worktree, test first, keep the green gate green, commit coherent units, and never push, merge, stash or touch .omo/. Keep plans and reviews frozen. Preserve unresolved manifest members and all original roadmap places, carry advisory priority into Pack and vault views, read the roadmap gate from the generated graph, and escape memo HTML outside code spans. Align the upgrade, evidence, role and proposal guidance with the close rulings, updating carrying Specs and their independent oracle rows. Validation: npm run check passed; focused recipe and regression suites passed; an expected-place mutation failed and was restored.
Owner-authorized lane p47/f1-drawings from f9e3a10 for pack:roadmaps-and-slices-v1. Working rules: build the ready Specs test-first, keep npm run check green, update carrying intent and its oracle together, commit coherent work in this worktree, never push or merge, never stash, and leave .omo and the original platform checkout untouched. Keep examples and outside intent in honest requirement bands, combine parallel relations, fold dense drawings, escape Mermaid backticks, and render question prose. Reuse routing work, recipe answers and page lookups. Share heavy Studio fixtures through beforeAll, index fragment checks, and cancel native filter resets before browser defaults can undo them. Validation: npm run check; both-corpus build and drawing measurements; byte-identical performance comparison; offline Mermaid parser; native browser reset probe and inspected 1440-pixel captures.
Reason: align the roadmap decision with its rules, bind the Pack-page regression, and cover missing graph input and roadmap comparison cases. Review base: 1509db8. Lane base: f9e3a10. Arc: pack:roadmaps-and-slices-v1 on p47/f2-roadmap. Keep the lane isolated and gate each coherent unit. Do not push, merge, stash, or touch .omo/. The decision wording follows the lane brief's already-authorized proposal-base and evidence-retention corrections.
Answer the F1 review of 300de7e on the lane based at f9e3a10: preserve exact Mermaid relations and example bands, keep only useful measured folds, bind their tests, freeze recipe memo answers, and retain native form reset. The height and fold wording corrections travel with their hand-transcribed oracle rows.
…urfaces, gate and guidance Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> # Conflicts: # test/self-hosting-graph.test.ts
…d build time Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> # Conflicts: # test/self-hosting-graph.test.ts
The requirement drawing, the slice and architecture drawings, the trace graph and the capability pages, recaptured at the close fixes' head; head-protocol-roadmap-after.png shows the roadmap after this PR removed its six built entries and the cleanup joined first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Greptile's review of the src group found the Pack page drew its maturity map before the page's expander opened, so a cell link pointed at a closed member list the expander could not reach. The expander now opens before the map; the map's element keeps no behavior of its own, and the test that the map lies inside the expander failed first. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Its waves, the close review and its dispositions, and the acceptance measured at close; forward work now reads from pack:roadmap (recipe 53) and each arc's record is its branch and then its pull request (MD-47). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The roadmap over plan and review files (MD-47) keeps evidence that no test or recipe carries on the arc's branch only: the description links it at the commit that holds it, d02c406, and the branch removes it before merge. Removed: evidence/pr36/, reviews/plan47-design/, the annotation review, the epics integration proposals and reviews/assets/plan47-prototypes/. Plan 47 names that commit as their home. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
darko-mijic
changed the title
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
…, keep closed source out of print Greptile's hosted review of PR 36 at 4a3af0e left three findings, each fixed test-first; each new test failed before its fix. - A slice page now names each manifest member that resolves to no Spec beside its summary. Recipe 54 kept them in scope.unresolved, but the Studio's SliceAnswer dropped them, so an incomplete Pack read as complete. The slice page's summary rule states it (spec:consumers.spec-studio.slice-page). - sdp-filter clears its choices when a followed link or a fragment change targets a row it hides, says so in its output and scrolls to the target. Before, a roadmap card under the Need filter opened its disclosure inside a hidden row. Pages still read in full without script (spec:consumers.spec-studio.page-elements). - sdp-expander no longer opens Mermaid source for print. A source the reader opened stays open and prints; a closed one stays closed and hidden (spec:consumers.spec-studio.export, ...diagram-kinds.mermaid-source). The changed rules are transcribed in the self-hosting oracle, and three test stand-ins for the document gained the lookup and listeners the filter now uses. Both page behaviors were checked in headless Chrome on the Protocol's Studio. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner working rules: commit, push, update PR #34, and make article evidence regenerable and CI-checked. Source baseline: b5e0a8b (main, PR #36). Branch base: f9dfa0c. Arc Pack: none; docs/articles is the living editorial record. Expand the series to five full drafts and five outlined follow-ups. Add the Studio/UX and future-AI narratives, regenerate article evidence, and feature the series from the repository README. Condense the annotation context and archive the detailed scout.
The owner asked for one well-rounded PR on how a corpus reads where it stands and what comes next:
refinement.
next, in order.
significant patterns and abstractions, curated rather than generated. The labels were too small at
desktop width, and the maturity map read as a list.
detail, within limits.
PR setting the precedent for retiring
plans/andreviews/.This PR builds all five. Its intent is
pack:roadmaps-and-slices-v1(26 Specs and 23 executable examples), and the Protocol now plans from its own roadmap,
pack:roadmap. Plan 47is the last numbered plan.
What this PR introduces
The arc's behavior and contract Specs state
ready, and each is bound to the code that realizes itand the tests that verify it, except the executable-examples epic, which has no resolving verifier
yet. The validator reports that gap, and one more on the role vocabulary, a
readymodel. The threedecisions carry no delivery facts by design, and the release and baseline views stay
scoped. Recipe numbers are thecatalog's (
docs/agent-surface/recipes.md).Epics and the capability map
The Protocol's features now sit under nine epics. Seven hub Specs that already stated a capability
were enriched in place to
epic, executable examples gained an epic of its own, and self-hostingstays an epic. Every Spec is reached by an epic, and every
readySpec kept its floor. An epic may beany kind of Spec, since kind and altitude are independent coordinates on the one primitive (MD-48).
The capability map (recipe 52) reads each epic with its distinct refinement descendants: their rungs,
binding facts and open questions, and any Spec no epic reaches. The Studio gains a Capabilities
lens after Packs, a refinement drawing, and an epic filter on the index. Start at
consumers.capability-mapandprotocol.capability-epics.The roadmap
A roadmap is a Pack whose manifest states
order: priority. Its member order is the owner's advisorypriority, with no new relation, no date and no gate (MD-46). Everything else is read from the graph
each time. Each entry's refinement subtree gives its need, the part that holds it, and what it
rests on. The needs are:
readyand only a person's statement stands before it;Three surfaces read a roadmap:
the roadmap. This description's forward section below is that memo.
The roadmap ran its own cycle in this PR. Recipe 53 read this arc's six entries as built, so the
PR removed them, as MD-47 says the completing PR does. Start at
consumers.roadmapanddecisions.roadmap-priority.Diagrams the graph has data for
A catalog judges every Mermaid diagram type against the graph's data. Kept:
Refused, with the trigger that would bring each back: sequence (a flow is one prose line, so the graph
has no message order), state, Gantt (the graph holds no dates) and journey. Labels lead with the title
at 14 pixels, and ids shorten with a marked elision. A wide drawing keeps its size and scrolls inside
its figure, where it used to shrink its labels to 6 to 8 pixels. Edges route around boxes, and every
drawing offers its Mermaid source to copy. Start at
spec-studio.diagram-kinds.Design slices
A design slice reads a Pack, some of its members, or an ordered list of Specs as one design:
It is a reading composed on each run, never a new grouping. Recipe 54 answers it, and the Studio gains
a slice page per Pack. How much design each round adds is guidance in the authoring skill ("Design in
rounds"), because an "over-designed" check would police content quality. Start at
consumers.design-slice.The annotation review: a curated register
Every engine anchor and every bare source file was read against the significance criterion, now
clarified: a unit qualifies when a designer must understand its contract or responsibility, and being
exported is not enough. The owner accepted the change table, which keeps every realization claim:
uses;showed it adds no layer crossing.
Each unit's label now states its responsibility. A role vocabulary defines each role word, and the
architecture page lists each component's significant units by role. Start at
protocol.significant-units-review.Plans and reviews become the roadmap and the pull request
MD-47 replaces both:
plans/is frozen at this plan. The handbook namespack:roadmapand recipe 53, andthe gate checks the roadmap Pack in the graph rather than a current plan.
request.
with recipe 49's memo. Against code, they are line comments.
before merge.
The removal of
plans/andreviews/is the next PR, first on the roadmap. Three canonical exampleslive in this PR:
d02c4062and are removed in4a3af0e7.Start at
protocol.roadmap-replaces-plansand
decisions.roadmap-over-plans. An adoptergets the same path in the upgrade guide and a small
roadmap in the worked example.
See it
This PR's Studio: https://libar-dev.github.io/software-delivery-protocol/preview/36/, built from
each push's merge commit, with CI's runs and the diff from
main. The screenshots below were capturedin headless Chrome at 1440 pixels (390 for the phone view); the commands are in
evidence/pr36/README.md.main(da4b141)New pages:
b038bd4No human view shows the vault here. Its notes now say "Members, in advisory priority order" for a
roadmap.
The corpus, measured
Re-measured at the head; re-run the recipes rather than inheriting these.
mainreadyreadyfloorThe design diff from
main(recipe 35): 51 Specs added, 52 changed (the hubs enriched toepic, theStudio contracts aligned, the Pack carrier and model), none removed; 4 Packs changed; 88 binding changes.
Rulings
Made by the owner (2026-10-22, through the coordinating session):
order: prioritymakes member order an advisory priority (MD-46)decisions.roadmap-prioritydecisions.roadmap-over-plansdecisions.epics-of-any-kindprotocol.significant-units-reviewCONTEXT.mdprojections-model.roadmap-viewsreadystatements at the floor; the delivery-record cleanup first on the roadmapprotocol.capability-epics,pack:roadmapDelegated, then confirmed by the owner. The executing thread made these after two independent
advisors and the lane reviews; the owner confirmed all eight on 2026-10-22. Plan 47 lists the other
delegated rulings.
decisions.roadmap-over-plansmodel.structural-patternsconsumers.roadmapconsumers.roadmap.memospec-studio.diagram-kinds.legibilityspec-studio.diagram-kinds.mermaid-sourceconsumers.design-sliceconsumers.authoring-on-rampRegistry and glossary. In
DECISIONS.md: MD-46, a roadmapstates advisory priority; MD-47, the roadmap and the pull request over plan and review files; MD-48,
epics of any kind. In
CONTEXT.md: new rows roadmap and need; thecapability / domain row broadened to epics of every kind; architecturally significant unit
clarified; design slice added to the guidance-only labels.
How it was built and reviewed
Design. Five design lanes ran first. Each was designed by one model family, reviewed by another
and answered by the first, with prototypes on the Protocol's corpus and a copy of libar-platform.
The design records are at
reviews/plan47-design/and theannotation review. Two advisors (Opus 5.5 and
GPT-6-Astra) then reviewed the decisions as change proposals.
Build. Three build waves followed: 11 lanes, each built by GPT-6.1-Sol, reviewed by Opus 5.5 and
fixed test-first. Each wave was integrated in one pass and checked on CI's route (Node 20, npm 10,
a fresh clone) before its push.
Close review. Four independent reviews ran before this PR was marked ready:
mainthat each hold one directory group, since thewhole branch exceeds its limit. Findings that only the split produced were set aside.
Every remaining finding was fixed test-first. Among them:
main'stime on the same machine, and the Studio tests build their page set once.
After the PR was marked ready, Greptile's hosted review found three more issues, each fixed
test-first in
3d520678:as complete;
A flaky test. CI's push run once timed out a watch example at 5 s. The example already waited on
cycle events, so its file now carries the heavy-test timeout, and a test reads each watch example's
registered timeout. That test failed at 5,000 ms first.
Try it
Feedback wanted most:
vault and the agent surface);
without a plan file.
The next PR
Recipe 55's memo over
pack:roadmap, rendered at this head:The next work, from the roadmap
Roadmap: The Protocol's roadmap
pack:roadmapTo 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
spec:protocol.delivery-record-cleanupidea→scoped, held by kind-evidence-present; blocked byspec:protocol.delivery-record-cleanup#question.durableContentplans/,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.spec:consumers.spec-studio.cited-line-textscoped→defined, held by no-blocking-open-questions; blocked byspec:consumers.spec-studio.cited-line-text#question.lineTextspec:consumers.spec-studio.register-inputscoped→defined, held by no-blocking-open-questions; blocked byspec:consumers.spec-studio.register-input#question.registerEntry,spec:consumers.spec-studio.register-input#question.inputFormTo build
spec:consumers.edit-modelWaiting on the owner
spec:protocol.delivery-record-cleanup#question.durableContent(blocking), place 1: Which content inplans/,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.featurecorpus into the Protocolspec: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 givespec: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 releasespec: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 projectionspec: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 refinesspec:decisions.shipped-projections-frozenfor the affected Mermaid rendering or supersedes that ruling wholespec:observation.runtime-overlay#question.observationIdentity: Which external observation identity and freshness boundary is small enough for the graph while still supporting an honestobserveddelivery fact? Trigger: An adopter needs runtime measurements linked to measurable Spec targets and can supply an observation identity and freshness policy for review.Why this order (the owner's reasons, not the memo's):
plans/andreviews/once this precedent lands.What the platform's mass update asks for joins on the owner's word. Release readiness stays off the
roadmap until the owner names its items.
Answered since the memo was rendered. On 2026-10-22 the owner let the provisional answers of
both waiting questions stand. Each answer is recorded at the start of its own arc, not in this PR:
#durableContent(place 1): the cleanup arc's first commit is a measured inventory of whatplans/,reviews/and the concept documents still carry that no Spec, test, decision or recipedoes, each piece with its home. A cross-family review checks the inventory before anything is
deleted.
#lineText(place 2): the extractor records the citing line's text, trimmed and bounded, on thecitation row it already writes, as inferred data that confers nothing; the Studio reads no
source.
#lineBound's provisional answer stands too: a bound of a few hundred code units, cut ata word boundary and marked as cut, the whole line one source link away.
Re-entry: this PR merged. The cleanup arc opens with the inventory and records its answer.
Refused, durably:
🤖 Generated with Claude Code
The reported issues are non-blocking: they affect slice completeness, filtered roadmap navigation, and printed review readability rather than preventing the new readings from operating.
Findings
Summary
This PR adds graph-backed roadmaps, capability maps and design slices, plus Studio pages and richer diagrams.
The reported issues do not block merging. They affect completeness within the slice view, filtered roadmap navigation, and printed review readability.
Reviews (1) · Last reviewed commit: "evidence: remove PR 36's screenshots and..." · Reviewed by Greptile