[darko-mijic]

Consolidated into PR #40. This branch is merged there unchanged (merge commit 12246171), and PR #40 now targets main with the whole-repository review, its execution (PR #39) and a second review pass in one pull request. This description stays as the review's record; it was corrected for accuracy before the pull request closed.

A whole-repository review, and the inventory the cleanup needs

This pull request is a deep review of the whole repository at main b5e0a8be (PR #36). It changes no Spec and no engine code. It adds one evidence directory, evidence/pr38/, which is removed before merge, and one guard exemption that lets that directory cite the records it reviews.

The review answers four questions:

• Where do intent, code, tests and docs disagree today? Nine engineering lanes read the Specs against the engine, the code for defects, the tests as evidence, and the docs and vocabulary.
• What durable content in the frozen records does nothing carry yet? The roadmap's first entry, spec:protocol.delivery-record-cleanup, is held at idea by exactly that blocking question, #durableContent. The owner already accepted how it is answered: a measured inventory, checked by a cross-family review before anything is deleted. This review produces that inventory.
• How far has the product moved from its seed design, and what does the future AI direction still need? PR docs(articles): publish the product and projection narrative #34 asked that the review take its compact article packet (Parts 1, 2 and 5 with the generated Studio pages) and its seed / current / future distinctions as input. The seed design is a reference lens, not intended truth, so a seed capability the corpus lacks becomes a question for the owner, never a defect.
• Does the pull-request record hold anything the graph should? AGENTS.md makes descriptions the durable narrative record, and the cleanup will delete plans that hold some of the same content.

Every finding was checked by a verifier from the other model family (GPT checks Claude, Claude checks GPT), which tried to refute it against the tree.

Working record. Branch review/whole-repository; base main b5e0a8be. Owner's working rules: review the whole repository as one phase of the next work, doing as much as possible through the relay plugin (GPT and Claude reviewers) while the coordinating session keeps its context for coordination and execution. Commits, push and this draft are authorized; the owner reviews and merges. There is no arc Pack.

What it found

Across twelve lanes: 73 items, 55 confirmed (2 high, 26 medium, 27 low), 16 refuted, 2 unsettled. Severities are the verifier's.

• The corpus is consistent at the base, but the engine has two high-severity defects. sdp validate reports 0 errors, the drift alarm is empty, and the build backlog holds two Specs, spec:consumers.edit-model and spec:consumers.intent-composition. Yet a TypeScript carrier can author the delivery fact hasVerifier with no honesty error (L3-01), and sdp build writes through a planted symbolic link, overwriting a file outside the corpus (L4-01).
• Two ready Specs have drifted behind the agent surface they describe: the recipes binding (L2-2) and the reader's undocumented resolveEntryAddress (L2-1, L6-3). They travel as a change proposal.
• The frozen records are mostly carried. plans/ and reviews/ are largely carried by Specs, tests and recipes, or are history git and the descriptions already hold. Thirteen pieces of durable content are not yet carried, and a fourteenth, R12, was found after the owner's rulings. Four live dependencies must move before the folders go, and 23 Markdown links and the prose pointers in AGENTS.md and CONTEXT.md must be repointed or removed before their targets go.
• The seed's review experience mostly exists, in a different form. Each seed button that produced a patch now gathers scoped intent for an agent. The AI presentation direction in Part 5 has no carrying question (L11-01), and PR docs(articles): publish the product and projection narrative #34 already applies the eight confirmed article corrections in 2dc6a1a2.
• The PR record is sound, with two gaps. All 196 distinct pinned file links (blob and raw) in five descriptions resolve. The lane checked no other kind of link: the descriptions also hold 17 distinct pinned tree and commit links, 213 pinned links in all, and a later check found that those 17 resolve too. The owner's acceptance of three provisional answers lives only in PR Plan 47: roadmaps, capability maps and design slices #36's description (L12-01). Two deferral triggers live only in a plan the cleanup would delete (L12-02).

No human view shows this review: the evidence is Markdown and JSON. The Studio's pages are unchanged.

Lanes

Lane	Scope	Reader	Verifier	Findings	Confirmed	Refuted	Uncertain
L1	Core Spec families against the engine core	GPT	Claude	5	5	0	0
L2	consumers Specs against the reader, projections, CLI and recipes	Claude	GPT	8	5	3	0
L3	Engine core code: correctness, determinism, safety	Claude	GPT	5	3	2	0
L4	Engine surface code, root scripts and CI workflows	GPT	Claude	4	4	0	0
L5	Tests as evidence, with mutation spot checks	GPT	Claude	2	2	0	0
L6	Skills, recipe catalog, vocabulary and decision registry	Claude	GPT	8	6	2	0
L7	Inventory of plans/ and docs/concept/	Claude	GPT	13	11	2	0
L8	Inventory of reviews/	GPT	Claude	2	2	0	0
L9	Newcomer view: README, worked example, JTBD stories, PR #34 articles	Claude	GPT	9	7	2	0
L10	Seed to current: the seed's human review experience against today's Specs and Studio pages	Claude	GPT	11	6	5	0
L11	Current to future: what each of Part 5's three AI roles has, and what it still needs	GPT	Claude	2	2	0	0
L12	The PR record: descriptions #31, #32, #33, #35 and #36 against the graph	GPT	Claude	4	2	0	2
Total				73	55	16	2

GPT reads with gpt-6-astra at xhigh effort and verifies with gpt-6.1-sol at high, through the relay plugin on Codex; Claude runs natively as claude-opus-5-5 at high. L12's two uncertain items are ledger items no verifier ruled on. The dossier gives each lane's relay job, routes and what it did not cover.

The most severe confirmed findings

Id	Severity	Finding	Goes to
L3-01	high	The honesty check misses the hasVerifier spelling, so a TypeScript carrier can author a delivery fact the Markdown carrier refuses	code fix
L4-01	high	sdp build's staging files follow an existing link and overwrite the file it points to, outside the corpus	code fix
L1-02	medium	An authored unspecified Then can turn a coverage gap into a passing test	code fix
L1-01	medium	A Given and a When that share a step key silently skip the product call	code fix
L2-2	medium	A ready Spec still prescribes inlining a shipped recipe body, which the recipes binding replaced	proposal
L12-01	medium	The owner's acceptance of three provisional answers lives only in PR #36's description	proposal, inventory
L12-02	medium	Two deferral triggers from PR #35 live only in a plan the cleanup would delete	open questions, inventory
L11-01	medium	Model-written presentation has no carrying question, though Part 5 names its trust boundary	open question

Every finding, with its verdict and reproduction: findings.md (L1–L9), product-lens.md (L10–L11) and pr-record.md (L12). The 16 refutations sit beside them with their reasons.

The inventory: the answer to the cleanup's blocking question

inventory.md classifies every file in plans/, reviews/ and docs/concept/ as carried, history, or holding uncarried durable content. Its answer:

• Most of it is carried or history. Specs, decision Specs, open questions, tests and recipes carry the law; the rest is execution history that git and the pull requests already hold.
• Fourteen pieces of durable content need a home first. Six medium: the carrier ruling's grounds (R1), the TypeScript carrier's static-data grammar (R4), two permanent non-goals (R5), the deferred trajectory (R6), and from the PR record the accepted answers (L12-01) and two deferral triggers (L12-02). Eight low: R2, R7, R8, R9, R11, L8-01, L8-02, and R12, the deferred spec-ids union type in concept 01, which a later cross-family review of the inventory added after the owner's rulings. Each row names its proposed home.
• Four live dependencies must move or retire first: the self-hosting gate reads three plans, a test runs a script under reviews/assets/, two Specs cite prototypes there, and docs/concept/DECISIONS.md is the live registry, not cleanup material. Links and pointers must be repointed or removed before their targets go: 21 Markdown links from kept documents into the concept documents (17 in jtbd-stories/, one in README.md, three in the worked example's README), two exploration exhibits that link plans, and the prose pointers in AGENTS.md and CONTEXT.md.
• What L12-01 means for the cleanup entry. In PR Plan 47: roadmaps, capability maps and design slices #36 the owner settled how #durableContent is answered; the owner has since accepted this inventory as the answer, with row rulings (see Rulings). The inventory lives in removable evidence, so the cleanup arc opens with it, as the owner ruled it, in its first commit, and that commit closes the question. Its cross-family check is done: L7, L8 and L12 were each verified by the other model family. Proposal changes 4 and 5, which PR fix: execute the whole-repository review's findings #39 applies, record the accepted method in the graph, but change 5's provisional predates the acceptance, so an agent reading the graph would still ask the owner to review the inventory; PR review: the whole repository, its fixes, and the durable-content inventory #40 amends the provisional to name the acceptance and the closing commit.

Nothing is deleted before the cleanup arc lands the inventory, and no record goes before the durable content it holds has its home.

The change proposal

proposal.json is one change proposal on base b5e0a8be, seven changes, most severe first (memo):

1. spec:consumers.agent-surface.answer-shapes#design.wrapIdiom teaches await recipes(n, params) instead of inlining a shipped body (L2-2).
2. spec:consumers.reader lists resolveEntryAddress among the reader's methods (L2-1, L6-3).
3. spec:consumers.reader gains rule #entryAddressResolution, that method's contract (L2-1, L6-3).
4. spec:protocol.delivery-record-cleanup gains rule #inventoryFirst, the method the owner accepted (L12-01).
5. spec:protocol.delivery-record-cleanup#question.durableContent stays blocking; its provisional names the owner's review of the inventory as what settles it (L12-01). That closing sentence predates the owner's acceptance of the inventory: the question closes when the cleanup arc lands the inventory in its first commit.
6. spec:consumers.spec-studio.cited-line-text records the accepted #lineText answer as rule #lineRecorded, and the question leaves the Spec (L12-01).
7. The same Spec records the accepted #lineBound answer as Design entry lineBound, and the question leaves the Spec (L12-01).

Recipe 38 (proposal-check.json) against the base graph: no schema problem, no diagnostic, 7 changes, 0 moved, 0 unresolved, no incomparable scope. A trial application of all seven changes to a scratch copy, carriers and oracle pins, kept sdp validate at 0 errors and passed the self-hosting oracle, recipe, roadmap, readiness, census and gate suites (522 tests in 7 files). The trial caught one gap in change 3's request, now fixed: the oracle's rule-key indexes shift with the inserted rule.

What the proposal does not carry, and why, is in not-proposed.md. The three new Specs that L11-01 and L12-02 call for cannot travel in a proposal, whose scopes must resolve at the base; they are capture candidates for an authoring session. Changes 6 and 7 can wait for the start of the cited-line arc, as PR #36 planned.

Questions for the owner

open-questions.md holds six open questions ready to author and two unsettled items. Each question names its carrying Spec, flag, decider, provisional answer and links. The ones that matter most:

• The two deferral triggers (L12-02, questions 4 and 5). They must land as captures before the cleanup deletes the plan that holds them.
• Symbolic links in discovery (L3-02, question 1). Discovery silently skips them today. The policy blocks the code fix, and it bears on the high-severity L4-01 and on L4-04.
• A boundary for model-written presentation (L11-01, question 3). It decides whether Part 5's assistant can ever sit beside the deterministic projections, and on what terms.

The owner has ruled on all six questions and on U2 (see Rulings). PR #39 carries out the rulings. Three questions become decisions, not questions: discovery's link policy, the token budget, and the hand-off preview. The other three become idea captures.

The unsettled items are settled too: the owner ratified PR #32's delegated rulings as the graph carries them today (U1), and PR #35's refused-list phrase was the wrong wording (U2).

Rulings

The owner's rulings on this review's questions. Each was recommended after re-checking its citations against the tree at b5e0a8be; the owner took them all as rulings. PR #39 carries them out.

Ruling	One line	Carrying Spec or file
Discovery never follows a link	Discovery never follows a symbolic link below the root and warns once per link outside excluded or skipped paths; an explicitly named root resolves to its real directory first, which also fixes L4-04 (question 1, L3-02)	#canonicalDiscovery, src/extract/discover.ts
The panel hands off scope, not a budget	The job story changes, not the Spec: the receiving agent picks its own budget and reads the scope with the context bundle (question 2, L9-F3)	jtbd-stories/06-edit-through-the-lens.md
AI-written presentation is a capture	An idea capture with four declared relations and a one-line provisional: select existing deterministic readings only; generated text stays outside the Studio and the frozen projections (question 3, L11-01)	a new capture
Bound-file freshness is a capture	An idea capture with the owner as decider, its trigger reworded: a reader cannot tell whether a run at another commit still applies (question 4, L12-02)	a new capture
Slot-combination coverage is a capture	An idea capture as drafted, the owner as decider (question 5, L12-02)	a new capture
The hand-off preview splits	The missing action label is a code defect against #ui.gatheredIntents; a collapsed, read-only memo preview is ruled yes, with a UI entry and a rule (question 6, L10-9)	spec:consumers.spec-studio intent panel, src/studio-elements/intent-panel-element.ts
The Studio build computes joins	PR #35's refused-list wording was wrong: the build composes every join, and what is refused is a page that recomputes one, or a second graph (U2)	spec:consumers.spec-studio#rule.noSecondGraph
The proposal is accepted	All seven changes: 1 to 3 repair drift around resolveEntryAddress, 4 to 7 record the answers the owner accepted in PR #36; PR #39 applies them	proposal.json
PR #32's delegated rulings are ratified	As the graph carries them today; where a later ruling narrowed one, the later ruling wins; no Spec edit (U1)	the Specs that carry them
This PR's delegated choices	Seven ratified; "design findings stay open questions" is superseded by the Q1, Q2 and Q6 rulings	the table below
The article corrections are accepted	All eight, as PR #34 applies them in 2dc6a1a2	PR #34
The inventory answers #durableContent	Accepted with row rulings: R1, R5, R7, R9, R11, L8-01 and L8-02 take their proposed homes; R4 becomes a new spec:carrier.typescript-authoring; R2 goes to the cleanup PR's record, never a Spec, because a count inside a Spec is refused; DECISIONS.md stays, the plan-reading gate checks retire with the folders, and measure.mjs moves beside its test. The cleanup arc lands the inventory in its first commit and closes the question there	inventory.md, spec:protocol.delivery-record-cleanup
A Pack export leaves out the slice page	#exportCarriesSlice's provisional answer stands, and the question becomes a rule	spec:consumers.spec-studio.slice-page

Still open, on purpose:

• R6's re-entry conditions, or dropping R6;
• R8's home, decided when the cleanup settles docs/concept/06;
• where the plan-46 prototypes move, which is the cleanup arc's call;
• register-input's three questions, which belong to its design pass;
• designColumnsSufficiency, which waits for the first adopter's design passes;
• R12, added after these rulings: keep the deferred spec-ids union beside R6's deferrals, in the form R6 takes, or drop it.

None of these holds #durableContent open. R6, R8, R12 and the prototypes' new location are each settled before the record that holds it is removed.

The owner's earlier rulings. This PR also carries out two of PR #36's:

Ruling	One line	Carrying Spec
The cleanup comes first	A dedicated PR removes plans/ and reviews/; this review produces the inventory it needs	spec:protocol.delivery-record-cleanup
The provisional answers stand	#durableContent (with the first-commit inventory and the cross-family review), #lineText and #lineBound; proposal changes 4 to 7 record them	spec:protocol.delivery-record-cleanup, spec:consumers.spec-studio.cited-line-text

This review's delegated choices, as the owner ruled them:

Choice	One line	Status	Where
No arc Pack	The review feeds spec:protocol.delivery-record-cleanup and adds no corpus intent of its own	Ratified	—
Base at main, not PR #34	PR #34 changes no engine source (src/) and no Spec, so the engine under review is the same; its articles are read at 230b0d28. Its CI job "Check article evidence", its check:articles script and its later test/article-evidence.test.ts were outside the review	Ratified	b5e0a8be...230b0d28
Cross-family verification	Each lane is verified by the other model family, so no finding survives on one model's reading alone	Ratified	dossier
Evidence in evidence/pr38/	Follows PR #36's convention; removed before merge	Ratified	—
The temporal guard exempts evidence/	Commit 5f528a15 adds evidence/ beside the existing .omo/evidence/ exemption, so an inventory can cite the plan files it classifies; on main the directory is empty once each arc removes its evidence	Ratified	check-temporal.mjs, test/check-temporal.test.ts
Product-lens lanes L10 and L11, added mid-run at the owner's request	The seed design is read as a reference lens, never intended truth; article corrections went to PR #34 in 2dc6a1a2, not here	Ratified	product-lens.md
PR-record lane L12, added mid-run at the owner's request	It reads the five most recent merged descriptions; ledger items no verifier ruled on stay unsettled and uncounted	Ratified	pr-record.md
#durableContent stays blocking	The proposal records the accepted method as a rule and keeps the question open until the cleanup arc lands the accepted inventory in its first commit; removing it would let the floor allow ready first	Ruled: the owner's inventory ruling keeps it blocking until that commit	not-proposed.md
Design findings stay open questions	L3-02, L9-F3 and L10-9 are not proposal changes, so the owner rules on each flag and decider first	Superseded by the Q1, Q2 and Q6 rulings	open-questions.md

The owner ratified seven of these choices. "Design findings stay open questions" is superseded by the Q1, Q2 and Q6 rulings.

Delegated choices awaiting the owner's review:

Choice	One line	Where
Proposal change 5 stays as accepted	The proposal file stays as the owner accepted it. The dossier notes that change 5's closing sentence was written before the inventory ruling, and that the provisional applied from it must name the acceptance and the closing commit; PR #40 makes that amendment	dossier

Try it

git fetch origin review/whole-repository && git checkout review/whole-repository
npm ci && npm run build

# The corpus at the base: expect 0 errors and 3 honesty/gaps warnings
pnpm --silent sdp validate . --exclude explorations --exclude examples --exclude test/fixtures/import/parity

# The questions the inventory and the proposal answer (expect 16 questions, 10 blocking, 6 deferrals)
pnpm --silent sdp:q "$(cat dist/recipes/20-open-question-register.js)"

# L11-01: the AI direction has no home yet (expect total 0)
pnpm --silent sdp:q "$(cat dist/recipes/06-where-is-this-concept.js)" --params '{"term":"assistant"}'

# The proposal check, against a base graph built from b5e0a8be as the dossier shows
pnpm --silent sdp:q "$(cat dist/recipes/38-the-proposal-check.js)" --params proposal=@evidence/pr38/proposal.json --params base=@../base-graph.json --json
pnpm --silent sdp:q "$(cat dist/recipes/49-the-proposal-memo.js)" --params proposal=@evidence/pr38/proposal.json

# The next work
pnpm --silent sdp:q "$(cat dist/recipes/55-the-roadmap-memo.js)" --params '{"pack":"pack:roadmap"}'

Build the base graph with the base's own CLI, as the dossier shows. A CLI built in another checkout trusts only its own source's builder modules, so it drops 105 of the corpus's anchors with no warning from sdp build. The first check used such a graph; recipe 38's answer was the same against both.

Feedback wanted: the owner has answered the questions this call first asked. The inventory's line between "carried" and "history" stands, with row rulings; #durableContent stays blocking until the cleanup arc lands the inventory in its first commit; the two deferral captures (L12-02) and the AI-presentation capture (L11-01) are ruled in. Whether build should warn when it drops relative builder anchors was closed another way: the owner ruled that the extractor trusts the extracted root's own builders when that root is the Protocol package itself, so a CLI built in another checkout keeps this corpus's anchors. PR #40 carries that ruling. Pressure is still wanted on R12, keep or drop, and on the delegated choice above that awaits review.

Next

The owner's decisions:

1. Review the inventory. It answers the cleanup's blocking question; the cleanup arc then opens with it in its first commit. Accepted, with row rulings; see Rulings.
2. Accept or reject the change proposal, change by change. Applying it is an ordinary source edit with its oracle pins, and the applying commit names the proposal's reason and base. Accepted; PR fix: execute the whole-repository review's findings #39 applies it.
3. Answer the six open questions and settle the two unsettled items. Ruled; see Rulings.
4. Review the eight article corrections PR docs(articles): publish the product and projection narrative #34 applies in 2dc6a1a2: L10-4, L10-5, L10-7, L10-8, L10-11, L11-02, L9-F6 and L9-F7 (product-lens.md). Accepted.

Follow-up fix arcs this review implied. Each is a code arc against settled intent; none joins the roadmap except on the owner's word. PR #39 carries out all four in one pull request; the concept-document drift stays with the cleanup arc.

1. Writes that stay inside the root, led by the high-severity L4-01 (staging files follow links). It also takes L4-04 (watch refuses a linked root that other commands accept) and L4-02 (three publishers collide on case-insensitive filesystems), and L3-02's discovery policy, as question 1's ruling set it.
2. Honest extraction and verification, led by the high-severity L3-01 (hasVerifier slips past the honesty check). It also takes L1-01, L1-02, L1-03, L1-04 and L1-05 (contract generation, the test runtime, the Markdown carrier and the readiness floor), and L5-01 and L5-02 (verifier bindings that omit their regression tests).
3. CLI and package polish: L2-3 (a parse error reported at line 1), L2-5 (studio --help), L3-03 (a quadratic trim), L4-03 (a test pass that misses option values), L9-F2 (a CommonJS require export with no types) and C1 (the guard's stale DECISIONS.md exemption).
4. Docs and vocabulary: L6-1 (AGENTS.md describes prose-mention warnings that do not exist), L6-4, L6-6, L2-6, L9-F1, L9-F4 and L9-F5 (L9-F6 and L9-F7 are applied in PR docs(articles): publish the product and projection narrative #34). The concept-document drift (L6-2, D1, L6-5) belongs to the cleanup arc, which dissolves those documents.

The roadmap. This PR changes no roadmap entry. Recipe 55 over pack:roadmap, re-run at the head 3dedfaa4 (the same graph as b5e0a8be), keeps the order PR #36 set:

Place	Entry	Where it stands	The owner's reason (PR #36)
1	spec:protocol.delivery-record-cleanup	to design, blocked by #durableContent	A dedicated PR removes plans/ and reviews/ once PR #36's precedent lands
2	spec:consumers.spec-studio.cited-line-text	to design, blocked by #lineText	Closes a step a reader could not take in PR #35's reader tasks
3	spec:consumers.spec-studio.register-input	to design, blocked by #registerEntry and #inputForm	Closes the other such step
4	spec:consumers.edit-model	to build, resting on nothing unbuilt	The composed-intent model is the whole build backlog

In the trial application of the proposal, which PR #39 applies, recipe 55 moved place 2 to "to state" and kept place 1 blocked by #durableContent. The owner has since accepted the inventory; the question closes when the cleanup arc lands it in its first commit, so place 1 stays blocked until then.

Re-entry: met. The owner has accepted the inventory, the proposal and the corrections, and has ruled on the questions. Nothing further blocks opening the cleanup arc: it opens with the inventory in its first commit, which closes #durableContent. R6's re-entry conditions (or dropping R6), R8's home, R12's keep-or-drop ruling and the prototypes' new location are settled within that arc, each before the record that holds it is removed.

Refused, durably (unchanged from PR #36): a rung stated by tooling; priority as a date, a schedule, a gate or a new relation; a roadmap that lists every feature; a slice or a capability as a new grouping primitive; an "over-designed" check; a diagram derived from prose; an anchor added for coverage; a tool that edits a carrier itself; a count, date or plan number inside a Spec.

Recipe 55's memo at the head

The next work, from the roadmap

Roadmap: The Protocol's roadmap pack:roadmap

To state means the floor allows ready and a person still judges the statement. Built means every Spec of the entry's work states ready and has an implementation binding; it reports no passing test and no deployment.

The Protocol's next work, first entry first. The order is a preference: it dates, gates and sequences nothing, and what each entry still needs is read from the graph each time.

First the cleanup that removes the frozen plans, review reports and superseded concept material, as the roadmap and the pull request record make possible. Then the two steps a reader of the Studio's pages could not take, the words of a test line that checks a declaration and an outside register's entries, and then the composed-intent model the build backlog holds. What the first adopter's mass update asks for joins when the owner selects it; a capture landing adds nothing here. An entry leaves by an edit to this manifest once its selected work is complete or no longer belongs among the next work.

To design

Place	Entry	Next	Purpose and reach
1	The Protocol removes its frozen plans, review reports and superseded concept material spec:protocol.delivery-record-cleanup	itself idea → scoped, held by kind-evidence-present; blocked by spec:protocol.delivery-record-cleanup#question.durableContent	Remove plans/, reviews/ and the superseded concept material from the tree, after moving into the graph the durable content they still hold, so the repository keeps one delivery record: the graph, git and the pull requests.
2	A pinned declaration shows the words of each test line that cites it spec:consumers.spec-studio.cited-line-text	itself scoped → defined, held by no-blocking-open-questions; blocked by spec:consumers.spec-studio.cited-line-text#question.lineText	The declarations page names each citing line by file and line only, so the reader leaves the page to read it, and has no route at all when the page set carries no source link.
3	An outside register is a named Studio input, so a cited token links to its entry spec:consumers.spec-studio.register-input	itself scoped → defined, held by no-blocking-open-questions; blocked by spec:consumers.spec-studio.register-input#question.registerEntry, spec:consumers.spec-studio.register-input#question.inputForm	A cited token reads as bare text on every page, and the register that defines it is neither linked nor shown.

To build

Place	Entry	Purpose and reach	Rests on
4	Views compose scoped intent instead of patching canonical source spec:consumers.edit-model	Let a view frame a requested change without giving derived surfaces a direct write path to canonical source.	nothing unbuilt

Waiting on the owner

• spec:protocol.delivery-record-cleanup#question.durableContent (blocking), place 1: Which content in plans/, reviews/ and the concept documents does no Spec, test, decision or recipe carry yet, and where does each piece belong?
• spec:consumers.spec-studio.cited-line-text#question.lineText (blocking), place 2: May the Studio show source text the graph does not hold, and if so is it recorded in the graph beside the citation or read as a named input?

Deferred, with their triggers

• spec:carrier.sdp-import.feature-adapter#question.featureAdapter: Which bare .feature constructs can an import adapter preserve honestly? Trigger: an adopter migrates a gen-1 .feature corpus into the Protocol
• spec:consumers.impact-graph.symbol-reach#question.symbolIdentity: Which language-neutral identity and extraction boundary can support exhaustive symbol reach without freezing a single compiler's representation into the Protocol? Trigger: a reader needs symbol-level reach that file-level imports and curated anchors cannot give
• spec:consumers.projections-model.roadmap-views#question.releaseReader: Does a reader need release or baseline views that the roadmap, the recipes and git tags do not serve? Trigger: the first published release
• spec:consumers.reference-projection#question.namedOutsideReader: Does a human reader outside the repository need a reference projection the four shipped roots do not serve? The taxonomy row is not that reader. Trigger: a named consumer outside the repository, with a way to measure that demand inside the arc that builds the projection
• spec:consumers.structural-mermaid#question.namedStructuralReader: Does a reader need diagrams rooted at code units, which census tables and Spec-rooted one-hop Mermaid do not serve? Trigger: a named reader with that need, plus a decision that refines spec:decisions.shipped-projections-frozen for the affected Mermaid rendering or supersedes that ruling whole
• spec:observation.runtime-overlay#question.observationIdentity: Which external observation identity and freshness boundary is small enough for the graph while still supporting an honest observed delivery fact? Trigger: An adopter needs runtime measurements linked to measurable Spec targets and can supply an observation identity and freshness policy for review.

Numbers were measured at b5e0a8be, which the review tree matches outside evidence/ and the guard exemption: 456 Specs (447 stated ready), 9 Packs, a base graph of 1072 nodes and 2978 edges, 0 validation errors and 3 warnings, 0 drift alarms, 2 build-backlog entries, and 16 open questions (10 blocking, 6 deferrals). Re-run the recipes rather than inheriting these.

Second review pass

After the owner's rulings, a second cross-family review read this pull request again, with PRs #34 and #39. On this branch it changed the evidence and one test (684844eb...3dedfaa4):

• One closure condition. The inventory, the dossier and the not-proposed list now agree that the cleanup arc closes #durableContent when it lands the inventory in its first commit; R6, R8, R12 and the prototypes' new location do not hold it open.
• The rulings where they apply. The dossier gains a rulings table, each open question opens with its ruling, and the not-proposed list and the PR-record ledger note theirs. The verifiers' verdicts and counts stay as history.
• An exact inventory. It gains row R12 and the links and prose pointers in its live-dependency list, and it qualifies the PR record's link count as file links.
• The guard's exemptions stay at the root. A new case in test/check-temporal.test.ts writes a banned token at a nested or look-alike path for each exemption (evidence/, plans/, reviews/, explorations/, docs/lineage/, .omo/ and package-lock.json) and expects the guard to report every one.

This description now follows those files, and its evidence links are pinned to 3dedfaa4. The pass's engine and corpus fixes are in PR #40, one new draft pull request on top of PR #39's branch. Among them, the cleanup question's provisional records the owner's acceptance and the closing commit, and the extractor trusts the Protocol package's own builders when it extracts that package.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[darko-mijic]

Change proposal memo (recipe 49) for proposal.json, based on b5e0a8be. Recipe 38 found 7 changes, with 0 moved and 0 unresolved.

Change proposal

Base: b5e0a8bea1e3bedd48c616f96c9928e955792753
Reason: From the whole-repository review: two ready consumer Specs have drifted behind the realized agent surface, and three provisional answers the owner accepted in PR #36 are recorded only in its description.

Change 1

Scope: spec:consumers.agent-surface.answer-shapes#design.wrapIdiom, spec:consumers.agent-surface.evaluation-sink#rule.recipeCall
Request:

Replace the value of the design entry wrapIdiom in specs/consumers/agent-surface.answer-shapes.sdp.md with the text below, keeping the `- wrapIdiom: ` label. In the same change, update the pinned wrapIdiom value in test/self-hosting-oracle/consumers.ts to the same text so the self-hosting oracle stays green.

Replaces: spec:consumers.agent-surface.answer-shapes#design.wrapIdiom
Reason: The entry prescribes inlining the shipped body, which the catalog and the reading skill replaced with `await recipes(n, params)` after the fifth binding (#rule.recipeCall).

to filter a shipped answer, the caller calls the recipe through the `recipes` binding with only the recipe's own parameters, `const answer = await recipes(<number>, { <the recipe's own parameters> });`, inside its own body, and returns a filtered value, so the caller's own parameters never reach the recipe as names it does not take and the shipped body is never inlined into the caller's; the catalog shows the shell form and states that the caller's part must hold no shell expansion.

Change 2

Scope: spec:consumers.reader
Request:

Replace the text of rule[1] of spec:consumers.reader, at specs/consumers/reader.sdp.gherkin line 74 (the unkeyed rule beginning "The reader exposes `graph`"), with the text below, keeping its `Rule: ` label. In the same change, update the pinned rule text in test/self-hosting-oracle/consumers.ts (line 420 at the base) to the same text.

Reason: The realized Reader interface and createReader expose resolveEntryAddress, which recipe 51 and the vault projection call, yet the ready Spec's closed method list omits it.

The reader exposes `graph`, the raw graph it reads, and the methods `specs`, `packs`, `findings`, `findByConcept`, `byFile`, `blastRadius`, `resolveEntryAddress`, `specContext` and `packContext`; a join is added only when a second machine consumer needs it and hand-rolled attempts get it wrong.

Change 3

Scope: spec:consumers.reader, spec:consumers.reader#rule.conceptEntry, spec:extraction.entry-citations, spec:validation.prose-mentions
Request:

Add a new rule to spec:consumers.reader in specs/consumers/reader.sdp.gherkin, as `Rule: ` followed by the text below, placed directly after rule[1] (the reader-surface rule at line 74) and before the rule keyed #conceptEntry. In the same change, add the new rule, without its key marker, to the pinned rules list for spec:consumers.reader in test/self-hosting-oracle/consumers.ts as rules[2], and shift that entry's ruleKeys by one: entryAddressResolution rules[2], conceptEntry rules[3], fileEntry rules[4], blastRadius rules[5], reasonsAsData rules[6].

Reason: The public method has a shipped result shape (src/graph/entry-address.ts) but no stated contract, so an adopter cannot rely on it and a refactor could remove it unflagged.

[#entryAddressResolution] `resolveEntryAddress` resolves one entry address with the grammar and entry rules that prose validation and entry citations use, and returns `{ entry, resolves, reason }`: `entry` names the resolved entry, such as `rule[2]`, `question[0]` or `design.wrapIdiom`, or is null; `reason` is null when the address resolves and otherwise `malformed`, `spec`, `section` or `entry`; recipe 51 and the vault projection are its machine consumers.

Change 4

Scope: spec:protocol.delivery-record-cleanup, spec:protocol.delivery-record-cleanup#question.durableContent
Request:

Record the method the owner accepted for answering #durableContent, which only PR #36's description records ("Answered since the memo was rendered"): the provisional answer stands, and the inventory is the arc's first commit and is checked by a review from another model family. In specs/protocol/delivery-record-cleanup.sdp.md, add a `## Behavior` section after Intent holding one entry, `- rule: ` followed by the text below. Keep the question itself: change 5 amends it. In the same change, add to the pinned entry for spec:protocol.delivery-record-cleanup in test/self-hosting-oracle/protocol.ts a behavior section with this rule, without its key marker, as rules[0] and the ruleKeys entry inventoryFirst rules[0]. State no readiness change.

Reason: The owner accepted #durableContent's provisional answer in PR #36 with two details, the first-commit inventory and the cross-family review, that the graph does not hold.

[#inventoryFirst] The arc that removes them opens with a measured inventory, in its first commit, of what `plans/`, `reviews/` and the concept documents still carry that no Spec, test, decision or recipe carries, each piece with its home; a review by another model family checks the inventory before anything is deleted.

Change 5

Scope: spec:protocol.delivery-record-cleanup#question.durableContent
Request:

Replace the open question #durableContent in specs/protocol/delivery-record-cleanup.sdp.md, its line and its two field lines, with the text below, which keeps the question, its flag, key and decider and changes only its provisional line. The question stays blocking: the owner accepted how it is answered, while the answer, the inventory's content, still awaits the owner's review. Once the owner has reviewed the inventory and each piece has moved to its home, the question leaves the Spec. In the same change, update the pinned provisional for this question in test/self-hosting-oracle/protocol.ts to the new provisional line. State no readiness change.

Replaces: spec:protocol.delivery-record-cleanup#question.durableContent
Reason: The graph's provisional predates the owner's acceptance and does not say that the owner's review of the inventory is what settles the question.

- [blocking #durableContent] Which content in `plans/`, `reviews/` and the concept documents does no Spec, test, decision or recipe carry yet, and where does each piece belong?
  - decider: owner
  - provisional: the measured inventory this Spec's rule requires answers it once the owner has reviewed it; each piece then moves to its home and the question leaves the Spec

Change 6

Scope: spec:consumers.spec-studio.cited-line-text, spec:consumers.spec-studio.cited-line-text#question.lineText
Request:

Record the owner's acceptance of the provisional answer to #lineText, which only PR #36's description records. In specs/consumers/spec-studio.cited-line-text.sdp.md, add the rule below to Behavior directly after #withoutWords, as `- rule: ` followed by the text; remove the open question #lineText with its decider and provisional lines; and in the narrative paragraph replace "the choice is the owner's, because it puts source text in the graph for the first time" with "the owner chose it, though it puts source text in the graph for the first time". In the same change, update the pinned entry for spec:consumers.spec-studio.cited-line-text in test/self-hosting-oracle/consumers.ts: the narrative, the openQuestions list without lineText, the new rule, without its key marker, as rules[3] and the ruleKeys entry lineRecorded rules[3]. PR #36 planned to record this answer at the start of the cited-line arc (roadmap place 2): apply it then, or earlier at the owner's word. State no readiness change.

Follows: spec:consumers.spec-studio.cited-line-text#rule.withoutWords
Reason: The owner let #lineText's provisional answer stand in PR #36, yet the graph keeps it open and blocking, and the roadmap memo still lists it as waiting on the owner.

[#lineRecorded] The extractor records the citing line's text, trimmed and bounded, on the citation row it already writes, as inferred data that confers nothing; the Studio reads no source to show it.

Change 7

Scope: spec:consumers.spec-studio.cited-line-text, spec:consumers.spec-studio.cited-line-text#question.lineBound
Request:

Record the owner's acceptance of the provisional answer to #lineBound, which only PR #36's description records. In specs/consumers/spec-studio.cited-line-text.sdp.md, add a `## Design` section after Behavior holding one entry, `- ` followed by the text below, and remove the open question #lineBound with its decider and provisional lines. Apply it with the #lineText change: once both questions are gone, remove the empty `### Open questions` heading. In the same change, update the pinned entry in test/self-hosting-oracle/consumers.ts: drop the openQuestions list and add a design section holding lineBound with the value after its label. The exact bound stays the builder's choice within the stated range. State no readiness change.

Reason: The owner let #lineBound's delegated provisional answer stand in PR #36, yet the graph still shows the question open.

lineBound: a recorded line holds at most a few hundred code units; a longer line is cut at a word boundary and marked as cut, and the whole line stays one source link away

The proposal

{
  "schema": "sdp-proposal/1",
  "base": "b5e0a8bea1e3bedd48c616f96c9928e955792753",
  "reason": "From the whole-repository review: two ready consumer Specs have drifted behind the realized agent surface, and three provisional answers the owner accepted in PR #36 are recorded only in its description.",
  "changes": [
    {
      "scope": [
        "spec:consumers.agent-surface.answer-shapes#design.wrapIdiom",
        "spec:consumers.agent-surface.evaluation-sink#rule.recipeCall"
      ],
      "request": "Replace the value of the design entry wrapIdiom in specs/consumers/agent-surface.answer-shapes.sdp.md with the text below, keeping the `- wrapIdiom: ` label. In the same change, update the pinned wrapIdiom value in test/self-hosting-oracle/consumers.ts to the same text so the self-hosting oracle stays green.",
      "text": "to filter a shipped answer, the caller calls the recipe through the `recipes` binding with only the recipe's own parameters, `const answer = await recipes(<number>, { <the recipe's own parameters> });`, inside its own body, and returns a filtered value, so the caller's own parameters never reach the recipe as names it does not take and the shipped body is never inlined into the caller's; the catalog shows the shell form and states that the caller's part must hold no shell expansion.",
      "replaces": "spec:consumers.agent-surface.answer-shapes#design.wrapIdiom",
      "reason": "The entry prescribes inlining the shipped body, which the catalog and the reading skill replaced with `await recipes(n, params)` after the fifth binding (#rule.recipeCall)."
    },
    {
      "scope": ["spec:consumers.reader"],
      "request": "Replace the text of rule[1] of spec:consumers.reader, at specs/consumers/reader.sdp.gherkin line 74 (the unkeyed rule beginning \"The reader exposes `graph`\"), with the text below, keeping its `Rule: ` label. In the same change, update the pinned rule text in test/self-hosting-oracle/consumers.ts (line 420 at the base) to the same text.",
      "text": "The reader exposes `graph`, the raw graph it reads, and the methods `specs`, `packs`, `findings`, `findByConcept`, `byFile`, `blastRadius`, `resolveEntryAddress`, `specContext` and `packContext`; a join is added only when a second machine consumer needs it and hand-rolled attempts get it wrong.",
      "reason": "The realized Reader interface and createReader expose resolveEntryAddress, which recipe 51 and the vault projection call, yet the ready Spec's closed method list omits it."
    },
    {
      "scope": [
        "spec:consumers.reader",
        "spec:consumers.reader#rule.conceptEntry",
        "spec:extraction.entry-citations",
        "spec:validation.prose-mentions"
      ],
      "request": "Add a new rule to spec:consumers.reader in specs/consumers/reader.sdp.gherkin, as `Rule: ` followed by the text below, placed directly after rule[1] (the reader-surface rule at line 74) and before the rule keyed #conceptEntry. In the same change, add the new rule, without its key marker, to the pinned rules list for spec:consumers.reader in test/self-hosting-oracle/consumers.ts as rules[2], and shift that entry's ruleKeys by one: entryAddressResolution rules[2], conceptEntry rules[3], fileEntry rules[4], blastRadius rules[5], reasonsAsData rules[6].",
      "text": "[#entryAddressResolution] `resolveEntryAddress` resolves one entry address with the grammar and entry rules that prose validation and entry citations use, and returns `{ entry, resolves, reason }`: `entry` names the resolved entry, such as `rule[2]`, `question[0]` or `design.wrapIdiom`, or is null; `reason` is null when the address resolves and otherwise `malformed`, `spec`, `section` or `entry`; recipe 51 and the vault projection are its machine consumers.",
      "reason": "The public method has a shipped result shape (src/graph/entry-address.ts) but no stated contract, so an adopter cannot rely on it and a refactor could remove it unflagged."
    },
    {
      "scope": [
        "spec:protocol.delivery-record-cleanup",
        "spec:protocol.delivery-record-cleanup#question.durableContent"
      ],
      "request": "Record the method the owner accepted for answering #durableContent, which only PR #36's description records (\"Answered since the memo was rendered\"): the provisional answer stands, and the inventory is the arc's first commit and is checked by a review from another model family. In specs/protocol/delivery-record-cleanup.sdp.md, add a `## Behavior` section after Intent holding one entry, `- rule: ` followed by the text below. Keep the question itself: change 5 amends it. In the same change, add to the pinned entry for spec:protocol.delivery-record-cleanup in test/self-hosting-oracle/protocol.ts a behavior section with this rule, without its key marker, as rules[0] and the ruleKeys entry inventoryFirst rules[0]. State no readiness change.",
      "text": "[#inventoryFirst] The arc that removes them opens with a measured inventory, in its first commit, of what `plans/`, `reviews/` and the concept documents still carry that no Spec, test, decision or recipe carries, each piece with its home; a review by another model family checks the inventory before anything is deleted.",
      "reason": "The owner accepted #durableContent's provisional answer in PR #36 with two details, the first-commit inventory and the cross-family review, that the graph does not hold."
    },
    {
      "scope": ["spec:protocol.delivery-record-cleanup#question.durableContent"],
      "request": "Replace the open question #durableContent in specs/protocol/delivery-record-cleanup.sdp.md, its line and its two field lines, with the text below, which keeps the question, its flag, key and decider and changes only its provisional line. The question stays blocking: the owner accepted how it is answered, while the answer, the inventory's content, still awaits the owner's review. Once the owner has reviewed the inventory and each piece has moved to its home, the question leaves the Spec. In the same change, update the pinned provisional for this question in test/self-hosting-oracle/protocol.ts to the new provisional line. State no readiness change.",
      "text": "- [blocking #durableContent] Which content in `plans/`, `reviews/` and the concept documents does no Spec, test, decision or recipe carry yet, and where does each piece belong?\n  - decider: owner\n  - provisional: the measured inventory this Spec's rule requires answers it once the owner has reviewed it; each piece then moves to its home and the question leaves the Spec",
      "replaces": "spec:protocol.delivery-record-cleanup#question.durableContent",
      "reason": "The graph's provisional predates the owner's acceptance and does not say that the owner's review of the inventory is what settles the question."
    },
    {
      "scope": [
        "spec:consumers.spec-studio.cited-line-text",
        "spec:consumers.spec-studio.cited-line-text#question.lineText"
      ],
      "request": "Record the owner's acceptance of the provisional answer to #lineText, which only PR #36's description records. In specs/consumers/spec-studio.cited-line-text.sdp.md, add the rule below to Behavior directly after #withoutWords, as `- rule: ` followed by the text; remove the open question #lineText with its decider and provisional lines; and in the narrative paragraph replace \"the choice is the owner's, because it puts source text in the graph for the first time\" with \"the owner chose it, though it puts source text in the graph for the first time\". In the same change, update the pinned entry for spec:consumers.spec-studio.cited-line-text in test/self-hosting-oracle/consumers.ts: the narrative, the openQuestions list without lineText, the new rule, without its key marker, as rules[3] and the ruleKeys entry lineRecorded rules[3]. PR #36 planned to record this answer at the start of the cited-line arc (roadmap place 2): apply it then, or earlier at the owner's word. State no readiness change.",
      "text": "[#lineRecorded] The extractor records the citing line's text, trimmed and bounded, on the citation row it already writes, as inferred data that confers nothing; the Studio reads no source to show it.",
      "follows": "spec:consumers.spec-studio.cited-line-text#rule.withoutWords",
      "reason": "The owner let #lineText's provisional answer stand in PR #36, yet the graph keeps it open and blocking, and the roadmap memo still lists it as waiting on the owner."
    },
    {
      "scope": [
        "spec:consumers.spec-studio.cited-line-text",
        "spec:consumers.spec-studio.cited-line-text#question.lineBound"
      ],
      "request": "Record the owner's acceptance of the provisional answer to #lineBound, which only PR #36's description records. In specs/consumers/spec-studio.cited-line-text.sdp.md, add a `## Design` section after Behavior holding one entry, `- ` followed by the text below, and remove the open question #lineBound with its decider and provisional lines. Apply it with the #lineText change: once both questions are gone, remove the empty `### Open questions` heading. In the same change, update the pinned entry in test/self-hosting-oracle/consumers.ts: drop the openQuestions list and add a design section holding lineBound with the value after its label. The exact bound stays the builder's choice within the stated range. State no readiness change.",
      "text": "lineBound: a recorded line holds at most a few hundred code units; a longer line is cut at a word boundary and marked as cut, and the whole line stays one source link away",
      "reason": "The owner let #lineBound's delegated provisional answer stand in PR #36, yet the graph still shows the question open."
    }
  ]
}

[darko-mijic]

Note

🤖 Claude Opus 5.5 responding on behalf of darko-mijic

Closing in favour of #40. That pull request merges this branch unchanged at 3dedfaa4 (merge commit 12246171) and carries this review, its execution from #39 and a second review pass, for one review and one merge. The description above stays as this review's record; it was corrected for accuracy before closing.