Adopter round 2: Pack order, question keys, the next rung, recipes 25 and 26, and the Studio captured ahead of its code

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

@@ -85,10 +85,10 @@ 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-four ready-made bodies in `docs/agent-surface/recipes.md` in the
+The catalog contains twenty-six 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-24 each open under a numbered heading that names the recipe. Every body there runs
+Recipes 1-26 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.
 
 For structural questions, use component membership, uses fan-in and fan-out, structural
@@ -99,18 +99,24 @@ dependsOn and refines), or the planning slice to see refinement and dependency n
 decisions, bound components, and entry points before editing.
 
 For a table you would otherwise keep by hand, run a register recipe each time you need it: the
-open-question register (recipe 20) for every open question and its blocking flag, dependency
-footing (recipe 21) for what one Spec rests on, and the mention audit (recipe 22) for Spec ids in
-prose. An entry address, `spec:<id>#design.<key>` or `spec:<id>#ui.<key>`, names one keyed entry
-of a Spec's Design or UI section; it belongs in prose, and `sdp validate` reports an address whose
-Spec or key does not exist as an error. 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
+open-question register (recipe 20) for every open question with its blocking flag and its key,
+dependency footing (recipe 21) for what one Spec rests on, and the mention audit (recipe 22) for
+Spec ids in prose. An entry address, `spec:<id>#design.<key>` or `spec:<id>#ui.<key>`, names one
+keyed entry of a Spec's Design or UI section, and `spec:<id>#question.<key>` names the open
+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
 top-level Design or UI key that starts with a lowercase ASCII letter and goes on in ASCII letters
-and digits, other than `description`. Every other entry, a lawful `"01"` key included, gets
-`address: null`. When a Design Review or a test author needs every signature a corpus has pinned,
-use pinned declarations (recipe 24): it lists each keyed Design entry whose value opens with a
-code span, with the Spec, the key and the span content as authored.
+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
+Design Review or a test author needs every signature a corpus has pinned, use pinned declarations
+(recipe 24): it lists each keyed Design entry whose value opens with a code span, with the Spec,
+the key and the span content as authored. To see where Specs rest on each other or on themselves
+through `dependsOn`, run dependency cycles (recipe 26): it lists each such set with one closed
+path through it, and reports without refusing.
 
 Reach for the files only when you need the authored prose itself — the exact words to edit.
 

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

@@ -121,7 +121,9 @@ takes its entries only. Prose after a section's first entry, fence, or H3 is ref
 | `## Verification — <mode>` | plain entries, one criterion each; the mode is `manual`, `reviewed`, `contract`, or `executable`, after an em dash |
 
 Intent may end with an optional `### Open questions`, the only H3 the body accepts. Each of its
-entries opens with `[blocking]` or `[non-blocking]`. On an example, one `gwt` fence closes Intent.
+entries opens with `[blocking]` or `[non-blocking]`. To cite a question from prose, give it a
+lower-camel key, unique in the Spec, after `#` inside the marker: `[blocking #aggregateReach]` is
+addressed as `spec:<id>#question.aggregateReach`. On an example, one `gwt` fence closes Intent.
 
 A Spec carries at most one of Behavior, Rule, Workflow, and Contract. Leading prose may stand under
 that owner or under Example space, not both. In Rule, Contract, Workflow, and Verification, open

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

@@ -50,12 +50,13 @@ carrier, `sdp new spec`, the `validate --watch` loop, and the one-kind rule.
 
 Use promotion preflight (recipe 9) on the target, the planning slice (recipe 19) for neighborhood
 and shaping decisions, dependency footing (recipe 21) for the stated and derived readiness of
-every Spec the target rests on, and readiness divergence (recipe 7) across the corpus. Resolve the
-target's blocking open questions and review the carrying Specs. The open-question 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.
+every Spec the target rests on, and readiness divergence (recipe 7) across the corpus. Use
+dependency cycles (recipe 26) to see whether the target rests on itself through `dependsOn`.
+Resolve the target's blocking open questions and review the carrying Specs. The open-question
+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.
 
 ### Implement
 
@@ -73,8 +74,9 @@ a binding, not a passing or live system.
 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. When reviewing component,
-architecture, or projection questions, use structural neighborhood (recipe 14), census
+mention audit (recipe 22) with that scope as its parameter. 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). Review findings and gaps as data; the review
 never becomes a workflow gate.

AGENTS.md

@@ -84,7 +84,7 @@ Progressive disclosure — start at the top, follow the pointers down.
 | Look here | What you get | Read |
 |---|---|---|
 | `CONTEXT.md` (repo root) | **the vocabulary** — the ratified lean glossary (terms · relations · a worked dialogue · flagged ambiguities); sole source of truth for terminology; the model exposition lives in the Specs under `specs/` and in the surviving concept docs | **first, always** |
-| `.agents/skills/` + `docs/agent-surface/recipes.md` | **the agent on-ramps** — three repository-owned skills: `sdp-agent-surface` (reading the graph), `sdp-authoring` (authoring intent), `sdp-sessions` (advisory delivery-session routing), also exposed to Claude through the `.claude/skills` symlink; plus the twenty-four runnable `sdp q` bodies | **mandatory** — after `CONTEXT.md`, load the matching skill before any corpus question, Spec authoring, or delivery-session routing; see "Query the graph first" |
+| `.agents/skills/` + `docs/agent-surface/recipes.md` | **the agent on-ramps** — three repository-owned skills: `sdp-agent-surface` (reading the graph), `sdp-authoring` (authoring intent), `sdp-sessions` (advisory delivery-session routing), also exposed to Claude through the `.claude/skills` symlink; plus the twenty-six runnable `sdp q` bodies | **mandatory** — after `CONTEXT.md`, load the matching skill before any corpus question, Spec authoring, or delivery-session routing; see "Query the graph first" |
 | `specs/` | **the self-hosted corpus** — the Protocol's own Specs in its own carrier (families: `model` · `extraction` · `validation` · `carrier` · `consumers` · `protocol` · `observation` · `decisions`, plus the self-hosting Pack); the primary carrier of intended truth | when design truth is in question — but query it through `sdp q` first, then read the carrying Spec |
 | `jtbd-stories/` | **the jobs (functional spec)** — stable `When / I want / so I can` stories (themes A–H); no personas, because consumers are heterogeneous (humans, CI, CLIs, **AI agents**) | to know *what* we serve |
 | `docs/concept/` (+ README) | **the technical design** — the surviving principle-led docs: vision & MVP boundary, founding principles (P1–P10), authoring & binding, consumers, roadmap; the core model, the one graph, and validation & honesty dissolved into the `model.*`, `extraction.*`, and `validation.*` Spec families — locate any of them with concept search (recipe 6) | to know *how* it is designed |
@@ -132,7 +132,7 @@ The full CLI surface is `sdp build · validate · view · census · mermaid · g
 and stays alive after findings; operator stop exits 0. `--watch` is validate-only and cannot combine
 with `--check-clean`. The four projection publishers remain independent public verbs; repository
 generation/check scripts certify all four roots through the private projection-suite driver. The
-twenty-four runnable recipe bodies live in `docs/agent-surface/recipes.md` (each executed as written by
+twenty-six runnable recipe bodies live in `docs/agent-surface/recipes.md` (each executed as written by
 `test/recipes.test.ts`), and the repository-owned skills (`sdp-agent-surface` for reading,
 `sdp-authoring` for writing intent, `sdp-sessions` for advisory work-shape routing) are the
 on-ramps. In this checkout, always go through

CONTEXT.md

@@ -225,10 +225,11 @@ delivery fact, workflow state, or graph state.
   locked ledger when the record states `ready`). **mention**: a `spec:` id written in a Spec's
   narrative or section text, outside the `gwt` and `gwt-vocabulary` fences; checked for resolution
   and for a backing declared relation in either direction, and it mints no edge (aliases to avoid:
-  "reference" · "citation" · "link"). **entry address**: a Spec id followed by `#`, the open section's
-  name (`design` or `ui`), a dot, and the entry's lower-camel ASCII key, naming one keyed entry of
-  that Spec; admitted in prose and by `parseId` and refused in every id slot, so a Spec's own id
-  never carries `#`, and checked in prose by `spec:validation.prose-mentions`, which is implemented
+  "reference" · "citation" · "link"). **entry address**: a Spec id followed by `#`, a section name
+  (`design`, `ui`, or `question`), a dot, and the entry's lower-camel ASCII key, naming one keyed
+  entry of that Spec's open section, or one of its open questions that carries that key; admitted
+  in prose and by `parseId` and refused in every id slot, so a Spec's own id never carries `#`,
+  and checked in prose by `spec:validation.prose-mentions`, which is implemented
   and still states `defined` (aliases to avoid: "anchor", reserved for the in-code binding ·
   "fragment" · "sub-id").
 - ~~Candidate vocabulary from the executable-spec exploration: *notation* · *carrier*~~ — **ratified

README.md

@@ -28,7 +28,7 @@ pnpm --silent sdp:q 'return g.specs().length'
 ```
 
 The `sdp:q` script supplies this repository's required fixture exclusions. Use the
-[twenty-four graph-first recipes](docs/agent-surface/recipes.md) for backlog, drift, verifier, impact,
+[twenty-six graph-first recipes](docs/agent-surface/recipes.md) for backlog, drift, verifier, impact,
 Pack, readiness, promotion, open-question, dependency, mention, and entry-search queries.
 
 The [architecture walkthrough](docs/agent-surface/architecture.md) follows shared policy,
@@ -147,4 +147,4 @@ for carrier support.
 The package installs three agent on-ramps as `SKILL.md` files under
 `node_modules/@libar-dev/software-delivery-protocol/.agents/skills/`. Use `sdp-agent-surface` to read
 the graph, `sdp-authoring` to author intent, and `sdp-sessions` for advisory delivery-session
-routing. The same package includes the twenty-four recipe bodies at `docs/agent-surface/recipes.md`.
+routing. The same package includes the twenty-six recipe bodies at `docs/agent-surface/recipes.md`.

check-prose-schema.mjs

@@ -23,7 +23,7 @@ for (const section of [
 ]) {
   expectContains("src/model/sections.ts", section, "missing section description owner");
 }
-expectContains("src/graph/schema.ts", 'schemaVersion = "0.6.0"', "missing 0.6.0 schema literal");
+expectContains("src/graph/schema.ts", 'schemaVersion = "0.7.0"', "missing 0.7.0 schema literal");
 expectContains("src/graph/schema.ts", "readonly narrative?: string;", "missing graph narrative");
 expectContains("src/reader/reader.ts", "readonly narrative?: string;", "missing Reader narrative");
 expectContains(
@@ -47,7 +47,7 @@ expectContains(
 );
 expectContains(
   "specs/extraction/schema-versioning.declared-version.sdp.md",
-  '{schemaVersion: "0.6.0"}',
+  '{schemaVersion: "0.7.0"}',
   "missing declared-version example literal",
 );
 expectContains(
@@ -62,7 +62,7 @@ expectContains(
 );
 expectContains(
   "docs/concept/06-consumers-and-projections.md",
-  "Design Review now renders `Spec.narrative` and the seven approved section descriptions from those Reader/graph values (schema `0.6.0`), with no source reparse and stable omission when prose is absent.",
+  "Design Review now renders `Spec.narrative` and the seven approved section descriptions from those Reader/graph values (schema `0.7.0`), with no source reparse and stable omission when prose is absent.",
   "missing landed prose projection claim",
 );
 

contract-dependent-suites.mjs

@@ -24,6 +24,15 @@ export const contractDependentSuites = [
     contracts: "generated/contracts",
     generation: "npm run generate:self-hosting",
     testPaths: [
+      "test/self-hosting-next-rung-floor.test.ts",
+      "test/validation.next-rung-floor.blocking-question.test.generated.ts",
+      "test/validation.next-rung-floor.typed-dependency-targets.test.generated.ts",
+      "test/self-hosting-open-question-keys.test.ts",
+      "test/model.open-question-keys.keyed-question-resolves.test.generated.ts",
+      "test/model.open-question-keys.renamed-key-breaks.test.generated.ts",
+      "test/model.open-question-keys.repeated-key-refused.test.generated.ts",
+      "test/self-hosting-pack-member-order.test.ts",
+      "test/extraction.pack-member-order.manifest-order-kept.test.generated.ts",
       "test/carrier.gherkin-authoring.authored-fact-refused.test.generated.ts",
       "test/carrier.gherkin-authoring.description-location-refused.test.generated.ts",
       "test/carrier.gherkin-authoring.duplicate-surface-refused.test.generated.ts",