Design management, closer to the original design: the Pack design page, entry lines, recipe parameters, design recipes, and v0 captured and ruled

.agents/skills/sdp-agent-surface/SKILL.md

@@ -14,7 +14,9 @@ evaluation sink. There is no verb wall — you script the graph.
 ## The shape of the graph
 
 The graph is flat: one array of nodes, one array of edges, nothing nested. Hierarchy is edges, so
-every question is a filter or a join, never a tree walk. Four node types exist:
+every question is a filter or a join, never a tree walk. Beside them, `graph.locations` is the
+location table: the source line of every keyed Design and UI entry and every open question. Nodes
+carry no lines, and a location is never an identity or a binding target. Four node types exist:
 
 - `Primitive` — one authored Spec, positioned by `specKind` × `altitude` × `readiness`, carrying
   its title, narrative, reified section content, and the derived `deliveryFacts`. Use case, NFR,
@@ -96,12 +98,22 @@ The public projection publishers are `sdp view`, `sdp census`, `sdp mermaid`, an
 In this source checkout, use `npm run generate:self-hosting` or `npm run check:self-hosting` when
 all four roots must be published or certified together.
 
-The catalog contains twenty-eight ready-made bodies in `docs/agent-surface/recipes.md` in the
+The catalog contains thirty-two ready-made bodies in `docs/agent-surface/recipes.md` in the
 Protocol repository and
 `node_modules/@libar-dev/software-delivery-protocol/docs/agent-surface/recipes.md` in an adopter.
-Recipes 1-28 each open under a numbered heading that names the recipe. Every body there runs
+Recipes 1-32 each open under a numbered heading that names the recipe. Every body there runs
 verbatim and a test proves it. Start from a recipe; adapt it in place.
 
+A recipe that takes a subject (a Spec id, a Pack id, changed files, addresses, a term) reads it
+from `params.<name>`, and the catalog names the parameter. Pass it as JSON data with `--params`,
+never by editing the body; `--params @PATH` reads the JSON from a file. The build also ships each
+body as `dist/recipes/<NN>-<slug>.js`, so run it as shipped:
+
+```sh
+pnpm --silent sdp:q "$(cat dist/recipes/03-what-does-this-spec-guarantee-and-who-verifies-it.js)" --params '{"spec":"spec:consumers.reader"}' --json
+pnpm exec sdp q "$(cat node_modules/@libar-dev/software-delivery-protocol/dist/recipes/04-what-breaks-if-i-change-these-files.js)" --params @changed-files.json --json
+```
+
 For structural questions, use component membership, uses fan-in and fan-out, structural
 neighborhood, census structural coverage, and the projection-coverage upper bound (recipes 12-16).
 For architecture questions, use the architecture map to see components and their shaping decisions
@@ -124,9 +136,11 @@ keyed entry of a Spec's Design or UI section, and `spec:<id>#question.<key>` nam
 question whose marker carries that key; it belongs in prose, and `sdp validate` reports an address
 whose Spec or key does not exist as an error. When you hold addresses written outside the
 Specs, in a register, a test, or a page, address resolution (recipe 25) gives one row per
-address: whether it resolves and, when it does not, why. When you hold a key or a term and need
-the entry that carries it, use entry search (recipe 23): it matches whole tokens and names the
-entry, where concept search stops at the section. It also gives the entry's address when the entry is a
+address: whether it resolves and, when it does not, why; a resolving row carries the entry's
+value, file, and line. When you hold a key or a term and need the entry that carries it, use entry
+search (recipe 23): it matches whole tokens and names the entry and its line, where concept search
+stops at the section. Both read lines from the location table, and a null line means not located,
+never absent. Entry search also gives the entry's address when the entry is a
 top-level Design or UI key that starts with a lowercase ASCII letter and goes on in ASCII letters
 and digits, other than `description`, and when the entry is the text of an open question that
 carries a key. Every other entry, a lawful `"01"` key included, gets `address: null`. When a
@@ -136,14 +150,27 @@ the key and the span content as authored. To see where Specs rest on each other
 through `dependsOn`, run dependency cycles (recipe 26): it lists each such set with one closed
 path through it, and reports without refusing.
 
+For design work, run Pack design (recipe 29): per member, the stated next rung with the clauses
+that hold the member below it, the design columns, open questions with addresses and lines,
+decisions, and the realizing and referencing units with their components, plus the Pack's
+boundary. The Design Review's Pack page renders the same assembly. Before changing a Spec,
+design-change impact (recipe 30) lists every Spec that rests on it, transitively, with the units,
+verifiers, and Packs to follow. The decision register (recipe 31) lists every decision with its
+rung, its supersession both ways, the decisions it narrows and those that narrow it through
+`refines`, the Specs it shapes, and its keyed questions. Architecture
+crossings (recipe 32) lists the `uses` edges whose components differ in context or layer, tallied
+by direction, and refuses nothing.
+
 Reach for the files only when you need the authored prose itself — the exact words to edit.
 
 ## The entry adapters
 
 `g.specContext(id)` lists the units that realize the Spec under `implementations` and the units
-that answer to it under `references`, each with its file and line. `g.byFile(path)` returns every
-node recorded at a path and the Specs reachable from it. A comment-form anchor is recorded at its
-own site, so a source file with no Protocol import still answers. A node may come back with an
+that answer to it under `references`, each with its file, line, and component, and its rows of the
+location table under `entryLocations`. `g.packContext(id)` carries the Pack design: each member's
+stated next rung, design columns, and bindings, and the Pack's boundary. `g.byFile(path)` returns
+every node recorded at a path and the Specs reachable from it. A comment-form anchor is recorded
+at its own site, so a source file with no Protocol import still answers. A node may come back with an
 empty Spec list: an identity-only anchor, with no `satisfies` and no `references`, is lawful and
 binds no Spec, and the empty list is its honest answer, not a failed lookup.
 `g.blastRadius(files)` follows `satisfies`, `references`, `verifies`, and oracle `models` from the
@@ -153,13 +180,15 @@ list implies coverage.
 
 ## The contract
 
-`sdp q ['<body>'] [--root PATH] [--exclude PATH]... [--json]`
+`sdp q ['<body>'] [--root PATH] [--exclude PATH]... [--params JSON | --params @PATH] [--json]`
 
-Three bindings are injected:
+Four bindings are injected:
 
 - `g` — the reader over the derived graph (the same `createReader` the package exports)
 - `graph` — the raw graph schema (nodes, edges, claims)
 - `report` — the validation report, so findings are queryable data, never a gate
+- `params` — the JSON object `--params` supplies, or `{}` without it; a value that is not a JSON
+  object, or a file that cannot be read, is refused before the body runs
 
 Body rules: a plain JavaScript **async function body**. No `import`/`export`, no TypeScript-only
 syntax; `await` is fine. `return` is the machine output contract, but `sdp q` does not suppress

.agents/skills/sdp-authoring/SKILL.md

@@ -17,10 +17,12 @@ with `sdp q 'return g.specContext("<id>")' --root node_modules/@libar-dev/softwa
 or open its carrier under that directory.
 
 At this repository root, the `sdp:q` wrapper supplies the exact self-hosting exclusions. Paste each
-recipe body between the quotes:
+recipe body between the quotes, or run the file the build ships for it under `dist/recipes/`, and
+pass a recipe's parameter as data with `--params`:
 
 ```sh
 pnpm --silent sdp:q '<body>'
+pnpm --silent sdp:q "$(cat dist/recipes/09-promotion-preflight.js)" --params '{"spec":"spec:<id>"}'
 ```
 
 For an adopter, select its root and exclusions explicitly:

.agents/skills/sdp-sessions/SKILL.md

@@ -33,8 +33,10 @@ pnpm exec sdp q '<body>' --root PATH
 pnpm exec sdp q '<body>' --root PATH --exclude PATH --exclude PATH
 ```
 
-Open the catalog and substitute only the parameter line of a parameterized recipe. The recipe
-result informs the session; it never grants permission or records a verdict.
+Pass a parameterized recipe its subject as JSON data with `--params` (or `--params @PATH` for a
+file), never by editing the body; each recipe names its parameter, and the build ships every body
+as `dist/recipes/<NN>-<slug>.js`. The recipe result informs the session; it never grants
+permission or records a verdict.
 
 ## Choose an advisory work shape
 
@@ -56,7 +58,11 @@ Resolve the target's blocking open questions and review the carrying Specs. The
 register (recipe 20) lists every open question in the corpus when the neighbors matter too. A
 clear floor is evidence, not an automatic `ready` statement. Use pinned declarations (recipe 24)
 to list every signature, type, validator or table the target and its neighbors pin as a code span
-opening a keyed Design entry, so a test author and a builder working apart read one list.
+opening a keyed Design entry, so a test author and a builder working apart read one list. When the
+design is a Pack, read it with Pack design (recipe 29): per member, the stated next rung and what
+holds the member below it, the design columns, open questions with their lines, and the code that
+answers to it. Before changing a Spec, run design-change impact (recipe 30) for every Spec that
+rests on it and the units, verifiers, and Packs the change asks to follow.
 
 ### Implement
 
@@ -79,15 +85,19 @@ existing code, the design's own `dependsOn` or `refines` says so, never a refere
 For a Pack, use the Pack review backbone (recipe 5) and warn-level signals (recipe 8). Without a
 Pack, use the target Spec context (recipe 3) with warn-level signals (recipe 8). To review a
 change, take the scope from changed-file blast radius (recipe 4) over the diff, then run the
-mention audit (recipe 22) with that scope as its parameter. Use address resolution (recipe 25) on
+mention audit (recipe 22) with that scope as `params.scope`. Use address resolution (recipe 25) on
 the entry addresses a register, a test, or a page cites outside the Specs. When reviewing
 component, architecture, or projection questions, use structural neighborhood (recipe 14), census
 structural coverage (recipe 15), the projection-coverage upper bound (recipe 16), the architecture
 map (recipe 17), and the decision map (recipe 18). For a Pack reviewed from the code side, use
 references into a design (recipe 27): per member, the referencing units, the realizing units, and
 whether a verifier is bound, with an empty column read as unbound. Use roles, layers and contexts
 (recipe 28) to review the architecture vocabulary the anchors state and to spot two spellings of
-one value. Review findings and gaps as data; the review never becomes a workflow gate.
+one value. To review a Pack's design as it stands, use Pack design (recipe 29); to review decisions,
+the decision register (recipe 31), with each decision's rung, supersession, narrowing through `refines` both ways,
+and the Specs it shapes; to review dependency direction, architecture crossings (recipe 32), which reports the
+`uses` edges that cross a context or layer and refuses nothing. Review findings and gaps as data;
+the review never becomes a workflow gate.
 
 ### Close / slim
 

.omo/evidence/plan-41/mentions.md

@@ -0,0 +1,24 @@
+# Plan 41: unbacked mentions and honesty gaps (lane c2-repairs)
+
+Measured on `lane/c2-repairs` from `28dcbdd`. Each line names the pair or the Spec, what the lane
+did, and why. Re-run `sdp validate` and recipes 9 and 22 rather than trusting these lines.
+
+## Prose mentions
+
+1. `spec:carrier.markdown-body-grammar` → `spec:validation.authored-honesty`: declared `constrainedBy`. The grammar refuses delivery-fact and edge names as keys "under" that rule-kind Spec, so the rule bounds the grammar; recipe 9 finds no floor failure.
+2. `spec:carrier.markdown-parser` → `spec:carrier.inline-code-spans`: declared `constrainedBy`. The parser keeps matched code spans literal at its raw-HTML guards under that rule, so the rule bounds the parser; the target states `defined`, which the `ready` floor accepts, and recipe 9 finds no failure.
+3. `spec:consumers.adopter-on-ramp` → `spec:carrier.markdown-body-grammar`: declared `dependsOn`. The on-ramp ships a table of the body grammar that points at that Spec, so the on-ramp needs the grammar to hold; recipe 26 finds no dependency cycle after the edge.
+4. `spec:consumers.delivery-session-on-ramp` → `spec:decisions.planning-truths-placement`: declared `decidedBy`. The decision places session law on the on-ramp's handoff rule, so it shapes this Spec.
+5. `spec:consumers.delivery-session-on-ramp` → `spec:decisions.shipped-projections-frozen`: left as prose. The handoff rule names the freeze only as one example of a register carrier the next session re-measures; the on-ramp neither rests on the freeze nor is shaped by it.
+6. `spec:decisions.architectural-significance-rides-primitives` → `spec:model.structural-patterns`: left as prose. The mentioning record is superseded by `spec:decisions.architectural-annotation`, a superseded record gains no relation, and the target already names the superseding ruling by `decidedBy`.
+7. `spec:decisions.carrier-ruling` → `spec:decisions.carrier-universality`: left as prose. The earlier ruling points forward to a later one that refines it through `spec:decisions.gherkin-carrier-option`; no relation runs from an earlier decision to its later refinement, and `supersedes` would misstate a refinement as a replacement.
+8. `spec:decisions.jsdoc-graph-extraction-refused` → `spec:model.spec-sections`: left as prose. The mentioning record is superseded by `spec:decisions.anchor-comment-form`, and it names the promotion law only as the place promoted rules go.
+9. `spec:decisions.planning-truths-placement` → `spec:consumers.impact-graph`: left as prose. The decision names the Spec that holds the impact-graph deferral; a decision does not rest on the Spec it places a hold on. If the owner wants the pair backed, the honest edge runs the other way, `decidedBy` from `spec:consumers.impact-graph`; the lane did not add it, because its scope was the mentioning Spec.
+
+## Honesty gaps
+
+1. `spec:carrier.markdown-authoring`: bound, `test:protocol.markdown-authoring` in `test/import-round-trip.test.ts`. The suite builds a TypeScript corpus of all eight kinds with anchors, emits its Markdown twin, asserts both derive the same nodes, edges and delivery facts, and catches a corrupted twin: the Spec's one rule, that both carriers feed one derivation path.
+2. `spec:extraction.claim-taxonomy`: gap left. No test takes the taxonomy as its subject. Edge claims are asserted as part of graph derivation (`test/extract.test.ts`, verifying `spec:extraction.derive-graph`), the never-collapsed rule by the claim-separation validator tests and examples (`spec:validation.claim-separation`), and claim inheritance (`belongsTo` carries `declared`) only in passing, in the Pack carrier parity example and the self-hosting oracle suite. `graphClaims` is missing from `test/graph-schema.test.ts`'s schema-contract test; a pin there plus an extraction test of inherited claims would make an honest verifier.
+3. `spec:model.pack-aggregate`: bound, `test:protocol.pack-builder` in `test/builders.test.ts`. "Builds packs as plain manifests with no authored truth fields" checks the realizing unit, `src/model/pack.ts`, yields id, title, framing, specs and modelRefs and nothing truth-bearing; `test/builders.typecheck.ts` is the compile-time twin that refuses intent, readiness and constraints on a Pack.
+4. `spec:model.relations`: bound, `test:protocol.relation-builders` in `test/builders.test.ts`. "Builds plain serializable specs with declared relations" checks the realizing unit, `src/model/relations.ts`, yields each of the six relations as a declared, directed edge to its target. The kind-typed endpoints are checked under the claim-separation validator in `test/validators.test.ts`.
+5. `spec:model.spec-sections`: gap left. The Spec composes laws other Specs carry, and each is checked there: the typing law at compile time in `test/builders.typecheck.ts` (`spec:decisions.typing-law`), content-only sections in the extraction corpora (`spec:decisions.content-only-sections`), direct `verifies` under `spec:extraction.delivery-facts`, and question keys under `spec:model.open-question-keys`. The one test of the section model itself lists the eight section names (`test/descriptors.test.ts`), too thin to call a verifier.