None.

None.

outcome

Keep the accepted set focused on the engine's significant contracts, decisions and stages, with meaningful roles and architectural uses, and exclude units anchored only for coverage.

rule.significantAbstractions line 27 · specs/protocol/significant-units-review.sdp.md:27

Apply the structural-patterns criterion to the public contract or cross-component responsibility a unit owns. Ports, shared data shapes, pipeline stages, decision tables, catalogs, layout policies and adapters qualify when changing them requires a designer or builder to understand that responsibility; being exported alone is insufficient.

no example exercises it

rule.curatedBoundary line 28 · specs/protocol/significant-units-review.sdp.md:28

Leave forwarding barrels, empty element registrations, mechanical wrappers, formatting helpers and generated files unanchored unless they own an independent contract or architectural responsibility. A coverage target, test expectation, file count or desired impact answer never establishes significance.

no example exercises it

rule.dependencyEvidence line 29 · specs/protocol/significant-units-review.sdp.md:29

Declare a component uses for a value or type import the importing file itself makes from another component's file. An import made only to author anchors, and a pair the imports adapter reports only through a re-export the importer does not use, confer no edge. Before calling a declared edge stale, inspect input omissions and every file the comparison leaves unassigned. Import evidence proposes an edit and never authors an edge.

no example exercises it

rule.rosterOracle line 30 · specs/protocol/significant-units-review.sdp.md:30

The self-hosting suite pins the reviewed component identities, unit ownership, roles, uses and deliberate membership exceptions independently of extraction. It compares the graph with those declarations and rejects unrostered membership. It never derives its expected roster from paths, exports, imports or the graph under test.

no example exercises it

rule.acceptedChanges line 31 · specs/protocol/significant-units-review.sdp.md:31

The accepted set is the annotation review's change table as the owner accepted it: its additions, merges, drop, role changes and component uses, each realization claim it names kept.

no example exercises it

rule.decoderBoundary line 32 · specs/protocol/significant-units-review.sdp.md:32

The example-space decoder joins the reader component, leaving notation a leaf codec, only when the architecture crossings recipe and the self-binding tests show that the move adds no layer crossing; otherwise it stays in notation, its real imports are declared, and the uses cycle they form stays lawful data.

no example exercises it

Cited at

• test/recipes.test.ts:5827

rule.roleMeaning line 33 · specs/protocol/significant-units-review.sdp.md:33

Read role meanings from the engine's role-vocabulary Model when reviewing its anchors. The vocabulary guides authors and reviewers; the Protocol never validates membership in it.

no example exercises it

0 unkeyed rules.

rosterSource line 37 · specs/protocol/significant-units-review.sdp.md:37

The self-hosting oracle holds the accepted roster: each row names an accepted unit's anchor, its component and its file, and its expectations for components, membership, uses, exceptions, coarse-grain coverage and roles sit beside it. A symbol suffix is a review locator, never extracted symbol identity.

criteria

• Compare the independently reviewed accepted roster with the source responsibilities it names, including dependencies that an imports comparison cannot assign to components.
• Check that every proposed merge or drop preserves the whole-Spec realization set it claims to preserve and that every architectural uses pair has supporting value or type imports beyond anchor authoring.
• Compare the extracted graph with the independently reviewed oracle roster after anchor changes; exercise a missing accepted member and an extra unrostered membership to show that the roster comparison detects both.

mode

reviewed

Verifier bindings

• test:protocol.structural-self-binding · checks the accepted membership and helper coverage, authored uses, and pinned anchor roles, layers and contexts · anchored · test anchor binding present · test/self-hosting-graph.test.ts:88

Requirement drawing

• Declared verifying examples: no declared verifying example.

Decisions

• spec:decisions.anchor-binding-grain

  On a code anchor, satisfies is optional and plural; on a test anchor, verifies is plural and non-empty. The constant form accepts one ref(…) or a fresh array literal of them. Each resolving target confers its fact, and implemented stays a whole-Spec fact. An anchored edge references runs from a CodeNode to a Spec, from references?: readonly SpecId[] on a code anchor; it may target any Spec, decisions included, confers no delivery fact, moves no readiness floor, and the drift alarm ignores it. It says this code answers to that design without claiming to realize it: the unit follows the design without realizing any of its promises, or realizes part of a Spec whose remaining promises no unit yet realizes, so a change to the design asks the code to follow. A design that builds on existing code states that by a typed relation to the Spec the code satisfies, never by a reference from the code. A target named in both satisfies and references is an error. An identity-only code anchor, with no satisfies and no references, is lawful: it mints a CodeNode for structure and for byFile, and nothing else.

• spec:decisions.architectural-annotation

  Architectural significance is annotated on the anchor of the unit that realizes it. A code anchor may carry role, the architectural pattern the unit plays; a component: anchor may additionally carry layer, one of edge, application, domain, adapter, or infrastructure, and context, its bounded context. The component: anchor is anchored architecture: it is the declared component, and there is no separate architecture file, because the anchor sits where the component is realized. It is not the original design's declared Component that could exist before code; an unrealized component lives in Specs and never as an invented CodeNode. A role is a free, corpus-owned vocabulary whose taxonomy the census renders with counts from the graph; service, decider, projection, read-model, codec, contract, barrel, and utility are the lineage set, not a closed list. layer is a closed set, and a value outside it is an envelope error; layer or context on a non-component anchor is an envelope error. All three attributes are optional, and omission is lawful.

• impl:protocol.structural-self-binding · realizes the declared significant-unit set and its structural self-binding · test/self-hosting-oracle/structural-edges.ts:76

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Define each architectural role the engine's anchors use, so the accepted set of significant units reads as a curated register of the engine's patterns and abstractions.

adapter · term.adapter line 22 · specs/protocol/role-vocabulary.sdp.md:22

Connects an external tool or runtime to an engine contract, such as a test runner or a TypeScript import reader.

codec · term.codec line 23 · specs/protocol/role-vocabulary.sdp.md:23

Parses, normalizes or encodes a representation while preserving the meaning owned by its contract, such as ids, carrier text, parameter input or source links.

contract · term.contract line 24 · specs/protocol/role-vocabulary.sdp.md:24

Owns a shared interface, data shape, closed vocabulary or public boundary that independently developed callers and providers must agree on.

decider · term.decider line 25 · specs/protocol/role-vocabulary.sdp.md:25

Computes a semantic answer from explicit inputs without reading or writing external state, such as delivery facts or example eligibility.

extractor · term.extractor line 26 · specs/protocol/role-vocabulary.sdp.md:26

Reads authored carriers or source bindings, or composes their reified results, into the graph and its located evidence.

interaction · term.interaction line 27 · specs/protocol/role-vocabulary.sdp.md:27

Adds browser controls and feedback to build-rendered content without owning its graph joins or layout. This is a corpus role for optional element behavior.

projection · term.projection line 28 · specs/protocol/role-vocabulary.sdp.md:28

Derives read-only presentation or generated contract content from the graph, the reader or an explicitly supplied answer. A page fragment and a complete page use the same role when both own presentation.

publisher · term.publisher line 29 · specs/protocol/role-vocabulary.sdp.md:29

Writes or synchronizes an owned artifact set, including its path checks, replacement, recovery and clean comparison.

index · term.index line 30 · specs/protocol/role-vocabulary.sdp.md:30

Builds a disposable lookup structure over the graph for the units that query it; it holds no authored state and is never a second read model.

reader · term.reader line 31 · specs/protocol/role-vocabulary.sdp.md:31

Answers queries over graph content, resolving or joining recorded identities and bindings without reading source files.

service · term.service line 32 · specs/protocol/role-vocabulary.sdp.md:32

Coordinates a use case or pipeline across collaborators, including execution and failure handling, while each collaborator owns its own contract.

validator · term.validator line 33 · specs/protocol/role-vocabulary.sdp.md:33

Evaluates a stated contract and reports its failures, including readiness clauses, import fidelity and corpus-selected checks. A role does not determine a Protocol validator family.

roleChoice line 37 · specs/protocol/role-vocabulary.sdp.md:37

Use the dominant responsibility of the anchored unit. A catalog of shared shapes is a contract, a table computing a semantic answer is a decider, and a failure-producing check is a validator. File size, caller count and naming style never select a role.

componentRole line 38 · specs/protocol/role-vocabulary.sdp.md:38

A component anchor's role names the dominant architectural responsibility its members serve together, read from their reviewed responsibilities rather than a count of role tokens. Omit the role when no responsibility dominates.

presentationWord line 39 · specs/protocol/role-vocabulary.sdp.md:39

Use projection for pure page, fragment and text-equivalent rendering. Use publisher for filesystem publication, codec for representation encoding and interaction for optional DOM behavior; a unit that presents uses projection, never renderer.

helperWord line 40 · specs/protocol/role-vocabulary.sdp.md:40

Choose a specific responsibility after reading the code. Graph indexes use index, concept queries use reader, parameter and path encoders use codec, browser controls use interaction and test-runtime integration uses adapter.

freeVocabulary line 41 · specs/protocol/role-vocabulary.sdp.md:41

These Model terms explain the engine's role values. Token grammar remains the only Protocol check on role, omission remains lawful, and this Model is not an adopter-wide allowlist; the self-hosting suite pins each accepted engine unit's role.

criteria

• Compare the graph's role taxonomy with these meanings and review every renamed unit against its implementation; keep an unfamiliar adopter role visible without reporting a Protocol finding.
• Check that pure presentation uses projection across the Markdown and Studio implementations, and that publication and optional browser interaction retain their distinct responsibilities.

mode

reviewed

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Test or oracle bindings: no recorded binding.

Decisions

• spec:decisions.architectural-annotation

  Architectural significance is annotated on the anchor of the unit that realizes it. A code anchor may carry role, the architectural pattern the unit plays; a component: anchor may additionally carry layer, one of edge, application, domain, adapter, or infrastructure, and context, its bounded context. The component: anchor is anchored architecture: it is the declared component, and there is no separate architecture file, because the anchor sits where the component is realized. It is not the original design's declared Component that could exist before code; an unrealized component lives in Specs and never as an invented CodeNode. A role is a free, corpus-owned vocabulary whose taxonomy the census renders with counts from the graph; service, decider, projection, read-model, codec, contract, barrel, and utility are the lineage set, not a closed list. layer is a closed set, and a value outside it is an envelope error; layer or context on a non-component anchor is an envelope error. All three attributes are optional, and omission is lawful.

• impl:protocol.role-vocabulary · asserts realization of the role vocabulary in the engine anchors' pinned roles · test/self-hosting-graph.test.ts:143

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Let a contributor find recorded units and their design bindings through their component and role, with omitted structure visible.

rule.recordedOnly line 19 · specs/consumers/spec-studio.lenses.architecture.unit-register.sdp.md:19

The architecture page groups recorded members by role within each recorded component, and shows a component's own source binding apart from its members. A row shows the recorded id, label, file and line and its satisfies and references targets separately. The page reads graph bindings only, never an annotation review or oracle source file.

no example exercises it

rule.omissions line 20 · specs/consumers/spec-studio.lenses.architecture.unit-register.sdp.md:20

Keep a not-stated role group and a no-component section. A binding confers no review approval or execution verdict, and the page shows no inferred accepted badge.

no example exercises it

rule.roleTokens line 21 · specs/consumers/spec-studio.lenses.architecture.unit-register.sdp.md:21

Show each recorded role token without interpreting it through a Protocol-corpus Spec id. An adopter's unfamiliar roles remain visible and produce no finding.

no example exercises it

rule.stableOrder line 22 · specs/consumers/spec-studio.lenses.architecture.unit-register.sdp.md:22

Sort components by id, role groups by token and members by id in code-unit order, with not-stated roles last and the no-component section after the components.

no example exercises it

rule.staticAccess line 23 · specs/consumers/spec-studio.lenses.architecture.unit-register.sdp.md:23

Every row is available without script through native disclosures. The component index links to the existing component section ids, and narrow screens retain readable source paths and separate realization and reference lists.

no example exercises it

0 unkeyed rules.

criteria

• Render the self-hosted corpus and an adopter with unfamiliar roles, omitted roles and omitted membership. Check ordering, component source rows, target separation, keyboard disclosures and narrow-screen overflow, with no inferred approval badge.

mode

reviewed

Verifier bindings

• test:protocol.studio-architecture-maturity-requirement · anchored · test anchor binding present · test/studio-panels.test.ts:35

Requirement drawing

• Declared verifying examples: no declared verifying example.

Decisions

No decision record named.

• component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  • component:protocol.extract · the carrier and source pipeline · src/extract/index.ts:192 · layer application · context protocol
  • component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol
  • component:protocol.model · the authored contracts and stable ids · src/model/anchors.ts:100 · layer domain · context protocol
  • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
  • component:protocol.reader · the typed graph contract and body evaluator · src/reader/reader.ts:671 · layer application · context protocol
  • component:protocol.validate · one finding currency and ordered checks · src/validate/validators.ts:72 · layer domain · context protocol
• impl:protocol.studio-unit-register · renders component source bindings and role-grouped recorded units · src/projections/studio/pages/architecture-register.ts:7

  Component: component:protocol.projections · read-only output, layout and owned publication · src/projections/design-review.ts:29 · layer edge · context protocol

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

A person or agent choosing which capability's design to read.

problem

An altitude filter gives a flat list and Pack membership does not explain refinement.

outcome

Read every epic with its refinement descendants, its design maturity and direct binding evidence, and expose every Spec no epic reaches.

rule.graphOnly line 29 · specs/consumers/capability-map.sdp.md:29

The map follows only declared refines edges between resolving Specs, from parent to child for reading. It reads every kind at every altitude, preserves intermediate Specs, and derives no parent from a title, path, Pack, dependency or binding.

no example exercises it

rule.epics line 30 · specs/consumers/capability-map.sdp.md:30

Every Spec at epic altitude is an entry, whatever its kind. An epic may itself refine another epic; both remain selectable, and a parent's descendant set includes the nested epic and its descendants.

no example exercises it

rule.nodeEvidence line 31 · specs/consumers/capability-map.sdp.md:31

Each Spec carries its own stated readiness, structural floor reached, delivery facts, and open questions with their blocking flags. A missing floor reads none. No value propagates from a child to its parent.

no example exercises it

rule.multipleParents line 32 · specs/consumers/capability-map.sdp.md:32

Every refining parent remains in the answer; a Spec appears once in nodes with all its parents, and a page decides where it expands.

no example exercises it

rule.rollup line 33 · specs/consumers/capability-map.sdp.md:33

An epic's rollup counts distinct descendants, excluding the epic itself, by stated rung, floor reached, kind and altitude; it counts those with implementation bindings and those with verifier bindings separately. Open and blocking question totals count the questions on those distinct descendants. Rollups for overlapping epics are never added to form a corpus total.

no example exercises it

rule.examplesAndDecisions line 34 · specs/consumers/capability-map.sdp.md:34

Examples and decisions participate in reach, counts and edges like every other kind. The page may fold them into labelled disclosures, but exposes their rows and any descendants they parent. A verifier count means a binding exists, never that a test passed; the map states no percent complete, inherited fact or work order.

no example exercises it

rule.unreached line 35 · specs/consumers/capability-map.sdp.md:35

A Spec is unreached when no epic reaches it, counting an epic as reaching itself. The answer lists every unreached id, including examples and decisions, and groups the unreached subgraph by its roots. A branch that is also reached remains outside that subgraph, with its cross-edge retained in the full answer.

no example exercises it

rule.damagedGraph line 36 · specs/consumers/capability-map.sdp.md:36

Unresolved or non-Spec refinement endpoints are reported in damage and excluded from traversal. Cyclic refinement is reported as sorted groups whose members all reach one another, including self-links. Traversal visits each id once per root. The map displays the damage without inventing ancestry or withholding the rest.

no example exercises it

rule.scope line 37 · specs/consumers/capability-map.sdp.md:37

With an epic selected, the answer contains that epic and its distinct descendants. Node parent and epic memberships still name their full-corpus memberships so narrowing never claims exclusive ownership. Without an epic the answer includes every Spec, including an empty corpus or a corpus with no epics.

no example exercises it

0 unkeyed rules.

mapRecipe line 41 · specs/consumers/capability-map.sdp.md:41

recipe 52 takes optional params.epic, a resolving epic Spec id, and params.detail, a boolean. Omitted epic means the whole corpus. An unknown parameter returns { unknownParams, accepts: ["epic", "detail"] }; a wrong type, absent id or non-epic returns { diagnostics: [{ parameter, problem }] } without a map, naming epic or detail as appropriate. There is no sample epic and no filtering by kind.

mapAnswer line 42 · specs/consumers/capability-map.sdp.md:42

the full answer is { input: { epic }, totals, nodes, edges, epics, unreached: { ids, roots }, cycles, damage }; epic is the selected id or null. The selected node set defines all totals; unselected nodes are never counted. Full-corpus memberships on a selected node are context, not extra selected nodes.

mapDetail line 43 · specs/consumers/capability-map.sdp.md:43

recipe 52 reads params.detail, absent or false for the summary and true for the full answer; the summary keeps input, totals, epics as { id, title, parentEpicIds, rollup }, unreached.ids, cycles and damage, and adds leftOut, one line for each omitted field. detail: true adds nodes, edges, each epic's descendantIds and unreached.roots, and omits leftOut.

nodeRow line 44 · specs/consumers/capability-map.sdp.md:44

{ id, title, specKind, altitude, statedReadiness, floorReached, deliveryFacts, questions, parents, children, epicIds }; parents and children are all resolving direct refinement neighbors in the corpus, and epicIds lists all epics that reach this node, including itself when epic. Questions preserve authored order as { index, address, question, blocking }, with a keyed question's entry address or null.

no citation recorded

edgeRow line 45 · specs/consumers/capability-map.sdp.md:45

{ from, to, claim: "declared", reason }, child to parent, for each resolving refinement whose ends are selected. An absent reason is null. Other relation types never enter this list.

no citation recorded

epicRow line 46 · specs/consumers/capability-map.sdp.md:46

{ id, title, parentEpicIds, descendantIds, rollup } for every selected epic, with its distinct descendants in the selected set. parentEpicIds lists resolving direct refinement parents at epic altitude in the full corpus, in id order. Selection by one epic includes every descendant of a nested epic, so its rollup stays complete.

no citation recorded

countShape line 47 · specs/consumers/capability-map.sdp.md:47

totals and each rollup carry { specs, byStatedReadiness, byFloorReached, byKind, byAltitude, withImplementationBinding, withVerifierBinding, openQuestions, blockingQuestions }; every descriptor value has a key including zero, floor counts add none, and totals additionally carry { epics, reached, unreached }. Reached and unreached partition selected nodes, using their full-corpus epic membership. The epic's own evidence stays on its node row, outside its rollup.

unreachedRoots line 48 · specs/consumers/capability-map.sdp.md:48

a root is an unreached Spec with no unreached parent; a group of unreached Specs that refine one another in a cycle, with no unreached parent outside the group, uses its smallest id as its root. Reach may overlap between roots; unreached.ids stays unique and complete. In an epic selection both lists are empty.

graphDamage line 49 · specs/consumers/capability-map.sdp.md:49

damage lists { code: "unresolved-refinement", from, to } for a missing or non-Spec endpoint touching the selected scope, or every such edge in whole-corpus scope. Cycles are separate { members } rows for cyclic groups in the selected graph, members sorted by id; they are graph damage, not parameter failures or a new validator.

no citation recorded

stableOrder line 50 · specs/consumers/capability-map.sdp.md:50

ids, nodes, epic rows, descendant ids, memberships and unreached roots use code-unit id order; edges and damage sort by from then to; cycles sort by first member. Question order stays authored. The answer has no clock, recorded work order or mutable state.

criteria

• A diamond retains both parent edges, lists the shared child once in nodes, and counts it once in that epic's descendants.
• A corpus with no epics still exposes every Spec; a cyclic unreached component has a root and finite traversal.
• An epic with a bound example and a ratified decision counts both descendants while retaining its own empty delivery facts.
• Summary and full answers have identical totals, epic rollups, cycles and damage; the summary names every omitted field.
• An epic selection includes its whole reachable set and no unrelated roots; invalid parameters return diagnostics without a plausible empty map.

mode

reviewed

Verifier bindings

• test:protocol.capability-map · anchored · test anchor binding present · test/recipes.test.ts:7610

Requirement drawing

• Declared verifying examples: no declared verifying example.

Decisions

• Capability epics keep kind independent of altitude

  Any Spec stated at epic altitude is an epic, whatever its kind, and keeps its kind: the capability map reads every epic and its refinement descendants, and the glossary row broadens from high-altitude behavior Specs to epic Specs of every kind.

• impl:protocol.capability-map-recipe · asserts realization of The capability map in docs/agent-surface/recipes.md · test/recipes.test.ts:7602

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Decide whether a capability map admits epics of every kind or only behavior epics.

context

The glossary row for capability and domain names a Capability Map over high-altitude behavior Specs, while kind and altitude are independent descriptors on the one primitive, and the hubs that already state the Protocol's capabilities include a domain model, a projection model and the rule that separates the two check families.

decision

Any Spec stated at epic altitude is an epic, whatever its kind, and keeps its kind: the capability map reads every epic and its refinement descendants, and the glossary row broadens from high-altitude behavior Specs to epic Specs of every kind.

rationale

• Hard to reverse: corpora organize their capabilities around which Specs may be epics, and the capability map, its page and the upgrade guide read that choice. Surprising without context: the ratified glossary row limited the map to behavior Specs, so a reader needs to know why a model or a rule now heads a capability. A real trade-off: an epic of any kind keeps the Spec that already owns a capability's outcome as its head, as the one-primitive decision's named coordinates already imply, against a map whose roots differ in kind and a glossary row that changes.

alternatives

• Keep behavior-only capability epics and introduce behavior wrappers over the model and rule hubs: each wrapper would restate an outcome another Spec already owns, a second owner that drifts, only so that a view can read it.

consequences

• The capability map draws epics of every kind, each labelled with its kind, and a Spec's kind never decides whether it heads a capability.
• The glossary row for capability and domain names a Capability Map over epic Specs of every kind and their refinement descendants.

Verifier bindings

No verifier binding recorded.

Requirement drawing

• Declared verifying examples: no declared verifying example.
• Test or oracle bindings: no recorded binding.

Decisions

No decision record named.

No implementation neighborhood recorded.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

outcome

Organize the Protocol's capabilities through explicit refinement so a reader can choose a capability and inspect its design and bindings.

rule.epicHome line 25 · specs/protocol/capability-epics.sdp.md:25

Enrich an existing hub to epic altitude when its intended outcome already names the capability. Keep its id, kind and truth; author a new epic only when no existing Spec owns that outcome. A model or rule can be an epic without becoming behavior merely to appear in the map.

no example exercises it

rule.refinement line 26 · specs/protocol/capability-epics.sdp.md:26

Each feature belongs under the epic whose intended outcome it makes more precise, directly or through intermediate Specs. Existing genuine refinement remains, including a nested epic and multiple parents. A Pack, path or dependency alone does not establish that relationship.

no example exercises it

rule.selfHosting line 27 · specs/protocol/capability-epics.sdp.md:27

The self-hosting epic keeps the Protocol's own use of the carrier, structural binding, roadmap and capability organization, and the decisions about that practice and the Protocol's identity. General model, derivation, validation and projection capabilities no longer refine self-hosting merely because the corpus exercises them.

no example exercises it

rule.preserveEvidence line 28 · specs/protocol/capability-epics.sdp.md:28

A re-altituded hub keeps its readiness statement when its content still supports it; reparenting confers no delivery fact and adds no anchor.

no example exercises it

0 unkeyed rules.

epicHome line 32 · specs/protocol/capability-epics.sdp.md:32

reuse an existing outcome owner so altitude changes do not duplicate intent; add an epic only for an outcome no hub already states. Design iteration has no epic: no Spec owns that outcome, its features are views and reader recipes that refine the projection and agent capabilities, and its Pack already groups them for review.

carrierHome line 33 · specs/protocol/capability-epics.sdp.md:33

the Markdown hub names the default authoring entry, while its rule puts Markdown and TypeScript on one graph path and its carrier ruling admits Gherkin. Its existing descendants refine that shared authoring outcome, so it keeps its identity and title.

executableHome line 34 · specs/protocol/capability-epics.sdp.md:34

the runner owns step dispatch and failure rendering, and contract generation owns typed contracts. Neither owns the whole outcome of executing an example against its authored intent, so a separate executable-examples epic joins those refinements. Their other genuine refinement and dependency relations remain.

nestedEpic line 35 · specs/protocol/capability-epics.sdp.md:35

the agent capability remains a refinement of the projection capability because scripted graph access is a consumer-specific view. Its descendants belong to both epic scopes, and the map reports that overlap explicitly.

corpusChecks line 36 · specs/protocol/capability-epics.sdp.md:36

corpus-selected rules refine the agent capability because their intended operation is scripting the graph; the validation command is their host, while their findings remain outside the Protocol's conformance and honesty families. A refinement states the narrower outcome and a dependency states what must hold: both relations intentionally connect the build pipeline to derivation, corpus rules to the agent capability, and architecture and external-register checks to corpus rules.

criteria

• Re-measure the corpus's refinement transitions, roots, overlapping parents and epic reach from the graph.
• Every previously ready Spec still states ready and reaches the ready floor after the edits; the drift alarm stays empty.
• Compare the capability map before and after authoring the epics, and read the same projection on an adopter with one broad epic without changing its intent.

mode

reviewed

Verifier bindings

• test:protocol.capability-epics · anchored · test anchor binding present · test/recipes.test.ts:8179

Requirement drawing

• Declared verifying examples: no declared verifying example.

Decisions

• Capability epics keep kind independent of altitude

  Any Spec stated at epic altitude is an epic, whatever its kind, and keeps its kind: the capability map reads every epic and its refinement descendants, and the glossary row broadens from high-altitude behavior Specs to epic Specs of every kind.

• impl:protocol.capability-epics · asserts realization of the capability epics in the shipped corpus's refinement · test/recipes.test.ts:8173

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

An author binding an example to a test of the intended behavior.

problem

A separately handwritten test can drift from the Spec's own steps and expected outcome.

outcome

Run an example against its authored intent through graph-derived contracts and report failures in the words of its steps.

rule.authoredSteps line 23 · specs/extraction/executable-examples.sdp.md:23

Execution reads the steps and bound values from contracts derived from the graph; it adds no second authored description of the example.

no example exercises it

rule.binding line 24 · specs/extraction/executable-examples.sdp.md:24

A bound test supplies the world and step handlers, and the runner executes the contract's steps in authored order. Contract generation and execution keep their separate responsibilities.

no example exercises it

rule.failure line 25 · specs/extraction/executable-examples.sdp.md:25

A failing step names the authored intent it exercised. An unspecified expected outcome remains explicit and cannot become a passing comparison by assumption.

no example exercises it

rule.facts line 26 · specs/extraction/executable-examples.sdp.md:26

A verifier binding says the example has a verifier. Execution results stay outside the graph and confer no readiness or delivery fact on this epic.

no example exercises it

0 unkeyed rules.

criteria

• Trace a bound example from its graph steps through generated contracts to runner dispatch, then change an expected outcome and check that its test fails in the example's words.
• Read the epic's own binding facts separately from the bindings on its contract-generation and runner descendants.

mode

reviewed

Verifier bindings

No verifier binding recorded.

Requirement drawing

Decisions

No decision record named.

• component:protocol.adapters · external runtime and source adapters · src/adapters/vitest.ts:23 · layer adapter · context protocol

  Uses

  • component:protocol.runner · provider-neutral example execution · src/runner/index.ts:99 · layer application · context protocol
• component:protocol.codegen · contracts and registrar output · src/codegen/contracts.ts:633 · layer application · context protocol

  Uses

  • component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol
  • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
  • component:protocol.reader · the typed graph contract and body evaluator · src/reader/reader.ts:671 · layer application · context protocol
  • component:protocol.validate · one finding currency and ordered checks · src/validate/validators.ts:72 · layer domain · context protocol
• component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol

  Uses

  • component:protocol.model · the authored contracts and stable ids · src/model/anchors.ts:100 · layer domain · context protocol
  • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
• component:protocol.runner · provider-neutral example execution · src/runner/index.ts:99 · layer application · context protocol

  Uses

  • component:protocol.notation · the leaf step codec · src/notation/slots.ts:261 · layer domain · context protocol
• component:protocol.testing · the generated registrar runtime · src/testing/index.ts:38 · layer adapter · context protocol

  Uses

  • component:protocol.adapters · external runtime and source adapters · src/adapters/vitest.ts:23 · layer adapter · context protocol
  • component:protocol.runner · provider-neutral example execution · src/runner/index.ts:99 · layer application · context protocol
• impl:protocol.delivery-facts · computes delivery facts from resolving binding edges · src/graph/delivery-facts.ts:65

  Component: component:protocol.graph · the one graph and its semantic decisions · src/graph/schema.ts:34 · layer domain · context protocol

  Uses

  None.

• impl:protocol.example-runner · plans and executes a bound example against the caller's world · src/runner/index.ts:108

  Component: component:protocol.runner · provider-neutral example execution · src/runner/index.ts:99 · layer application · context protocol

  Uses

  None.

• impl:protocol.example-runner-adapter · registers one test per example and owns the fresh world lifecycle · src/adapters/vitest.ts:32

  Component: component:protocol.adapters · external runtime and source adapters · src/adapters/vitest.ts:23 · layer adapter · context protocol

  Uses

  • impl:protocol.example-runner · plans and executes a bound example against the caller's world · src/runner/index.ts:108
• impl:protocol.example-testing-helpers · adapter-lifecycle and oracle-comparison helpers for bound examples · src/testing/index.ts:50

  Component: component:protocol.testing · the generated registrar runtime · src/testing/index.ts:38 · layer adapter · context protocol

  Uses

  None.

• impl:protocol.executable-contracts · derives step and example-space contracts from the graph · src/codegen/contracts.ts:647

  Component: component:protocol.codegen · contracts and registrar output · src/codegen/contracts.ts:633 · layer application · context protocol

  Uses

  None.

• impl:protocol.runnable-modules · derives and publishes runnable registrar modules from the graph · src/codegen/contracts.ts:658

  Component: component:protocol.codegen · contracts and registrar output · src/codegen/contracts.ts:633 · layer application · context protocol

  Uses

  None.

Runtime observation: not tracked.

Runtime observation: not tracked.

Build attestations: not tracked.

Deployments: not tracked.

Bills of materials: not tracked.

actor

A reviewer looking for a capability before choosing a Spec or Pack.

problem

A flat altitude filter hides how a capability is decomposed, and a large refinement drawing becomes unreadable when shrunk to the page width.

outcome

Read an epic overview, inspect its refinement structure and evidence, and narrow the index's Specs to its descendants.

rule.page line 32 · specs/consumers/spec-studio.capability-map-page.sdp.md:32

The Studio publishes capabilities.html on every build and links it as Capabilities immediately after Packs in the top navigation. The Packs lens keeps its membership order and the index remains the landing page.

no example exercises it

rule.recipeData line 33 · specs/consumers/spec-studio.capability-map-page.sdp.md:33

The page reads recipe 52 with { detail: true } and no epic parameter. It renders every epic's own evidence beside its descendant rollup and names the rollup's scope. Examples and decisions have separate counts and expandable rows. There is no combined total obtained by adding epic rows.

no example exercises it

rule.drawing line 34 · specs/consumers/spec-studio.capability-map-page.sdp.md:34

Each epic has a refinement drawing supplied by the shared diagram implementation. It keeps parent-to-child reading order while arrows, if drawn, point child to parent and the legend says refines. Repeated nodes link to their first occurrence within that epic section. A nested epic remains a labelled epic, not a new altitude.

no example exercises it

rule.bounded line 35 · specs/consumers/spec-studio.capability-map-page.sdp.md:35

A large branch folds at the shared diagram bound and links to its complete refinement text. At desktop width it never scales labels below the shared legibility size to fit an entire tree; below the responsive breakpoint it follows the shared legibility rule's narrow fit. The text includes every node and edge, repeats and cyclic links labelled in words, and stays readable without script.

no example exercises it

rule.links line 36 · specs/consumers/spec-studio.capability-map-page.sdp.md:36

Every node title links to that Spec's Studio page. A separate Show these Specs link goes to the index's Specs section with the epic selected. Keyed questions link to their entry on the Spec page; unkeyed questions link to the Spec page's section.intent. Unresolved endpoints are text with their diagnostics, never plausible Spec links.

no example exercises it

rule.filter line 37 · specs/consumers/spec-studio.capability-map-page.sdp.md:37

The index's Specs filter gains Epic, with Any, No epic and every epic by title and id. An epic selects its own Spec and every Spec whose full-corpus epicIds contains it. It intersects with the existing filters, resets with them, and never changes Pack membership or hides Pack cards.

no example exercises it

rule.withoutScript line 38 · specs/consumers/spec-studio.capability-map-page.sdp.md:38

Native links, disclosures, complete refinement text and all Spec rows work without script. Index filtering is an enhancement: before script applies a requested epic, the index says filtering needs script and shows all rows. A supplied id that is absent or not epic reports Unknown epic filter and leaves all rows visible.

no example exercises it

rule.emptyAndDamage line 39 · specs/consumers/spec-studio.capability-map-page.sdp.md:39

The page always has No epic reaches these Specs, including an explicit empty message. With no epics it explains that authors may organize Specs through refinement and still lists the whole corpus. Cycles and unresolved edges are visible diagnostics beside the complete text, without a new validation rule.

no example exercises it

0 unkeyed rules.

route line 43 · specs/consumers/spec-studio.capability-map-page.sdp.md:43

capabilities.html; an epic's section id is its Spec id. The filtered-index route is index.html?epic=<percent-encoded Spec id>#specs; epic=none selects unreached Specs, absence selects Any. An unknown or repeated epic parameter reports the unknown-filter message without applying it.

no citation recorded

diagramInput line 44 · specs/consumers/spec-studio.capability-map-page.sdp.md:44

recipe 52's node, edge, epic and unreached rows supply the drawing and its text; layout derives no reach, floor or delivery fact. The shared drawing implementation owns folding, label metrics and SVG or Mermaid representation. A capability drawing must support same-altitude edges, skipped altitudes, multiple parents, nested epics, and cycles without pretending to be a strict three-level tree.

disclosureOrder line 45 · specs/consumers/spec-studio.capability-map-page.sdp.md:45

epic overview cards and sections follow recipe order. Each section opens with the epic's own rung, floor, binding evidence and questions, then the rollup labelled Distinct descendants, excluding this epic. Refinement text expands a depth-first walk with children in id order and renders later visits as references; it follows the recipe's root order and uses per-section visited ids. Examples and decisions fold through native disclosures without pruning their descendants.

rowEvidence line 46 · specs/consumers/spec-studio.capability-map-page.sdp.md:46

each row names kind and altitude, stated <rung>, floor <rung>, the implementation binding and the verifier binding as present or none, and open and blocking question counts with their text available. Facts that are absent stay absent; a folded branch's counts never become the parent's badges.

nestedEpics line 47 · specs/consumers/spec-studio.capability-map-page.sdp.md:47

a card for an epic that refines another epic says Inside <title>, using parentEpicIds, and a card whose descendants include an epic names it, so overlapping counts read as overlap.

responsive line 48 · specs/consumers/spec-studio.capability-map-page.sdp.md:48

overview cards reflow to one column on a narrow viewport; refinement text wraps ids and titles, caps visual indentation, and names the parent in words so deep trees remain readable. At desktop width diagram labels use the shared readable size and bounded branches. Below the responsive breakpoint the drawing follows the legibility rule's narrow fit; the complete refinement text is the readable form. Print opens the disclosures and retains the complete text.

criteria

• Read the same page on a corpus with one broad epic, several epics, and no epics, with script disabled and at a narrow viewport.
• Follow a shared descendant from both parents and verify that the rollup counts it once and the index filter lists it once.
• Select an epic on the index, combine it with kind and readiness filters, reset it, and open the filtered URL directly; invalid and repeated epic parameters never show a false empty result.

mode

reviewed

Verifier bindings

• test:protocol.studio-capabilities · anchored · test anchor binding present · test/studio-capabilities.test.ts:89

Requirement drawing

• Declared verifying examples: no declared verifying example.