Clarify specification context and scenario ownership

ADOPTION.md

@@ -435,6 +435,30 @@ and require an explicit consumer mapping when a selector or wrapper path is
 ambiguous. Proofkit's public structured graph preserves declared routes; it does
 not discover native tests or judge their assertions.
 
+Choose scenario storage by the meaning it must own, not by a mandatory extra
+document layer:
+
+| Candidate | Appropriate boundary | Cost or limitation to review |
+|---|---|---|
+| Separate scenario document | Independently meaningful portable conditions or examples with their own review lifecycle. | Another normative artifact, reference closure and freshness policy; do not repeat the same promise. |
+| Scenarios inside the specification | Portable scenario meaning owned with the requirement. | Public source v1 has no typed scenario-body field; do not add unadmitted keys or describe a private candidate as public. |
+| Structured native declarations | Stable references, parameter instances and executable expected observations near the native check. | Derive the inventory and require review when assertions or qualified links change; native expectations cannot silently redefine intent. |
+| Test-adjacent annotations | References attached to a framework-owned test declaration. | Parse the actual native declaration association; comments alone do not prove discovery, execution or assertion quality. |
+
+Prefer the existing source plus structured native declarations when it expresses
+the required workflow. A separately editable scenario store is not necessary
+just to connect IDs. Reconsider it when portable scenario meaning cannot be
+expressed without losing a required distinction. This is not a universal format
+or human-usability ranking; measure the complete input, edit and maintenance
+cost for the consuming repository.
+
+Use `requirement-context-compose --help` for the connected catalog/tree recipe
+and canonical source/binding snapshot. Before committing, a confirmation must
+cover the publication plane actually being approved. Checking working files
+does not approve different index bytes; `change plan --help` explains this
+consumer-owned precondition. Neither command installs a Git hook or grants
+approval authority.
+
 Reverse review is distinct from the forward execution route above:
 
 ```mermaid

BACKLOG.md

@@ -56,68 +56,3 @@ records, generated release manifests, or the owning docs named above.
 | BLOCKED | RELOCATION-01 | Add provenance-bounded witness relocation candidates without introducing a second binding path or trusting a caller-authored prior digest; detailed candidate contract is retained in [issue #66](https://github.com/research-engineering/agentic-proofkit/issues/66). | An owner-admitted content-addressed baseline binds witness id, prior path and digest, source revision, evidence class, authentication non-claims, and freshness non-claims; the scanner then proves the zero/one/many match partition while remaining non-current until fresh execution evidence exists. |
 | BLOCKED | RELEASE-01 | Prove signed protected-tag release policy as provider-side release governance, not source-only intent. | Repository tag protection/ruleset and release workflow variables require signed annotated release tags; the next public release records provider-side evidence or the row is explicitly retired as an accepted non-claim. |
 | DEFERRED | WEB-PUBLISH-DESIGN-01 | Investigate optional publication of the specification browser at a configurable domain with authentication. Preserve local loopback serving and local browser opening as the default workflow; remote publication must be explicit and opt-in. | After the current program, compare static export with external hosting, a bounded deployment adapter, and an authenticated hosted server. Decide whether any capability belongs in Proofkit or should remain external, using a concrete consumer need and maintenance/security costs. The decision must define URL and authentication configuration, hosting/TLS/access-control ownership, source-disclosure and secret boundaries, content freshness, and preservation of derived-view authority. Require a feasibility witness and negative cases for unauthorized access and unintended publication before accepting an implementation plan; otherwise retain local-only behavior and retire the candidate with rationale. This row authorizes investigation, not exposure of the current server or deployment. |
-| NEXT | TRACEABILITY-DESIGN-01 | Complete the specification, scenario, native-test and execution-evidence workflow, including source intake, change impact and explanatory diagrams; see the bounded questions below. Reuse current public contracts and retained evidence; lazy input guidance alone does not close the complete workflow. | An owner-reviewed design and implementation decision resolves every question below against current Proofkit, StrictDoc and OpenSpec capabilities; an executable example and adversarial controls justify the selected ownership, storage and invalidation model. Existing mechanisms are reused when sufficient; unsupported additions are explicitly rejected rather than assumed necessary. |
-
-## TRACEABILITY-DESIGN-01
-
-This is active design and validation work, not a claim that the following capabilities are
-implemented or absent. First establish the current behavior and reuse existing
-owners before proposing a new command, record, parser or workflow engine.
-
-### Questions And Acceptance Evidence
-
-- **Source intake.** Evaluate requirements derived from existing code, an
-  external specification, design and implementation-plan documents, tests and
-  test-coverage observations, or explicit product intent. Preserve provenance,
-  assumptions and unresolved contradictions. Distinguish an explicit
-  code-as-baseline mode from an audit-from-code mode. A bounded, explicitly
-  selected code scan and assisted specification authoring must not be confused
-  with the current recognized-file scan or with automatic owner acceptance.
-- **Normative authority.** Keep one editable owner of each behavioral promise.
-  Generated candidates require owner review before becoming specifications;
-  tests and observed implementation behavior cannot silently redefine them.
-- **Complete chain.** Evaluate stable requirement ID -> scenario ID -> native
-  witness/path/selector -> command/environment -> actual result -> coverage.
-  Check both directions, many-to-many relationships, discovered-but-unmapped
-  tests, dangling references, parametrized tests, explicit exclusions and
-  missing, skipped or stale execution. A link is not an adequate oracle.
-- **Change propagation.** For a semantic change anywhere in the chain, derive
-  the affected dependency closure and automatically require confirmation or
-  update of affected specifications, scenarios, tests, bindings and evidence.
-  Changes to tests must trigger upstream impact review, not automatic rewriting
-  of the specification. Distinguish semantic from presentation-only changes;
-  preserve unaffected approvals and bind confirmations to exact current
-  subjects. Exercise additions, removals, renames, changed assertions,
-  environment changes and stale confirmations without forcing cosmetic edits.
-- **Scenario storage decision.** Compare separate scenario documents, scenarios
-  in the specification, structured declarations in test files, and test-adjacent
-  comments or annotations parsed into a derived inventory. Justify whether an
-  intermediate scenario document has independent meaning worth maintaining.
-  Preserve stable IDs, machine readability, native discovery, browser rendering,
-  cross-language portability and one editable source. Measure authoring, token,
-  review, drift, parser and maintenance cost rather than selecting by aesthetics.
-- **Agent guidance and cookbook.** Check that the agent receives actionable,
-  bounded instructions and a template for repository-specific discovery,
-  bindings, executable checks and evidence admission. Add or repair a complete
-  cookbook example only where the current documentation is insufficient. Show
-  a positive control, a behavior-breaking near miss, an unmapped or missing
-  test, and stale evidence; do not fabricate test completeness.
-- **Diagrams and explanation.** Audit README, adoption guidance, reference and
-  cookbook coverage for two understandable visual routes: multiple candidate
-  sources -> invariant extraction -> owner review -> canonical specification;
-  and specification -> scenario -> native test -> command/environment -> result
-  and coverage. Explain reverse impact review separately from forward proof
-  flow. Link each explanation to its current contract owner and validate actual
-  rendering; diagram count alone is not a completeness metric.
-- **Migration and alternatives.** Compare the same workflow with StrictDoc,
-  including its DSL and test-report integration, and OpenSpec. Run a bounded
-  example in which the same externally observable scenarios exercise both a
-  TypeScript implementation and a Python/FastAPI replacement. Keep requirement
-  and scenario IDs while allowing native adapters to differ. Passing selected
-  scenarios does not prove equivalence for every possible behavior.
-- **Decision closure.** Document why the chosen structure is preferable to the
-  strongest lower-cost alternative, including retaining the current structure
-  when sufficient. Keep the durable rationale in the narrowest appropriate
-  explanation or contract owner. Implement only admitted gaps, with negative
-  whole-chain tests, honest non-claims and measured cost; do not create a second
-  normative scenario store or an unjustified universal test engine.

internal/app/change_input_guide_test.go

@@ -21,11 +21,25 @@ func TestChangeInputGuideIsLazyAndExecutable(t *testing.T) {
 	for _, boundary := range []string{
 		"does not read", "Do not hash only IDs", "source-qualified pairs",
 		"required consumer check", "not authenticated approval", "empty prefix reviews architecture",
+		"working tree, Git index, immutable", "different staged bytes", "executable modes",
+		"untracked inputs and filter effects", "neither Git inspection",
+		"requirement-context-compose --help", "excludes undeclared native dependencies",
 	} {
 		if !strings.Contains(help, boundary) {
 			t.Fatalf("guide lost boundary %q", boundary)
 		}
 	}
+	normalized := strings.Join(strings.Fields(help), " ")
+	for _, sentence := range []string{
+		"Read that exact plane; a working-tree check alone cannot approve different staged bytes.",
+		"If partial staging is unsupported, require exact index/worktree bytes and executable modes for the complete input scope, including untracked inputs and filter effects.",
+		"Otherwise materialize and check the selected index/commit separately.",
+		"Proofkit performs neither Git inspection nor this consumer precondition.",
+	} {
+		if !strings.Contains(normalized, sentence) {
+			t.Fatalf("publication-plane policy changed: %s", sentence)
+		}
+	}
 	code, output, diagnostic := executeAgentWorkflowCLI(t, []string{"change", "plan", "--input", "-"}, bytes.NewReader(adoptionHelpJSON(t, packet)), PresentationCapabilities{})
 	if code != 1 || output != "" || diagnostic == "" {
 		t.Fatal("unfilled template fabricated an admissible assessment")

internal/app/cli_contract_test.go

@@ -24,7 +24,7 @@ import (
 )
 
 const (
-	cliContractPublicABISHA256               = "31d82294be58a80cdef00a33a554cfeeb17a03903083ebf56a38a994d7f2def9"
+	cliContractPublicABISHA256               = "7ff77cfb782eba71fb581e04aa618052a860e430f5a2b3b5d23bccd6c97352eb"
 	maxAggregateFileReadBytesForContractTest = 64 << 20
 	maxPackageManifestBytesForContractTest   = 256 << 10
 	maxSourceFileBytesForContractTest        = 8 << 20