Disclosure

Residual coverage the gates do not reach

Each gate names what it does and does not decide. The residuals below cover both the standard and the reference tooling:

• Changelog freeze compares a published entry's LF-normalized UTF-8 digest with its recorded digest. Line-ending-only changes do not alter that digest; the check does not judge whether the prose is accurate or complete.
• Range coverage checks that changelog entries tile every released version with no gap or overlap; it does not judge the quality of what they say.
• The unreleased worklog tail is reviewed rather than machine-frozen: before a release cut, entries are correctable in place, so review and version-control history, not a digest, are the control there.
• Store resolution confirms one declared store resolves; it cannot detect a second, unnamed store a project might also keep.
• The tracked-store check confirms the store is a tracked git repository whose pointer, recorded sync target, and actual remote agree; it does not verify that the repository is backed up, accessible, or hosted anywhere in particular.
• The single-writer lease has a propagation window in the standard's cross-system contract: a second system may begin before observing the held lease. The contract requires a divergence check to detect that collision afterward. These are specified controls, not complete CLI coverage: opf sync is planned, and the operation lock opf init takes, with the lease it holds while it writes, excludes other OPF runs on the same store only, not runs on another store in the same repository and not writers on another system.
• Reference-tooling residuals: doctor reports per-record view drift and the content schemas of module-tier and importer records, including legacy_fragment, as cannot-evaluate. A declared view outside the baseline set, such as a module-type index mirror, makes the whole drift check cannot-evaluate. The reference renderer does not render or drift-check per-record views. For a store with module-tier or importer records, or a per-record store that declares views, doctor's overall verdict is cannot-evaluate (exit 2). Ordinary import is retired and refuses with exit 2, and nothing in the reference CLI creates legacy_fragment records; the type remains only for stores that already hold such records from the reference CLI's retired import path. In such a store, as in a store with module-tier records, doctor reports cannot-evaluate and opf render --write refuses, because the baseline validator does not validate those records' content schemas. Transition checks also report cannot-evaluate when legality depends on an unidentified last-transition actor or a rejection requires unavailable pre-proposal state. Doctor does not check behind, ahead, or divergence against a sync target.
• Adoption and the prompt pack: the reference CLI runs adoption investigation and opf adopt plan read-only. opf adopt approve, apply, complete, and reconcile refuse with exit 2, so no approval, receipt, completion check, or retirement is recorded, and adoption cannot install the enforcement pack. A frozen plan is an inert proposal, not permission to apply. Investigation covers only its detection roots, the declared deliverable and view destinations, and the paths the adopter names, detects by path rather than content, and does not read git history. The planner checks the shape of the release identity, prompt-pack binding, enforcement member digests, and planned postimage digests a worksheet supplies, not the bytes they name; the one exception is the planned manifest a kept file registers into when the plan creates the store, whose digest must be the default manifest's real digest. The prompt pack's adoption procedure and clean-start guidance are instructions an assistant is asked to follow; they do not control what the assistant does. The pack's digest gate checks that its manifest matches the member bytes; it does not authenticate them or review what they say. The interim clean-start route initializes a store with opf init; it is not an adoption, and a later opf adopt run reads that store as re-adoption. That reading is the reference tooling's 1.2.0 behaviour and diverges from the specification, whose section 9.2 validation refusals refuse a 1.2.0 manifest as a store.
• A base tool enforces only the base standard and the profiles it supports; a profile it does not support is recorded as present-but-unevaluated rather than failing base validation.
• The discovery token is a single exact string. A mistyped or altered token is a cannot-evaluate that stops the tool, never a silent empty store. A rename would be a store-breaking change the specification gives no path: every base-schema version bump stays additive and keeps the exact token, so no bump the specification permits renames it (specification sections 4.5 and 9.2).
• Implementations (specification section 16.1): the specification defines one implementation model, with no conformance classes, and base 2.0.0, with homes = 2, is the only base version it defines. The reference tooling does not yet implement base 2.0.0: it still initializes and validates stores at base 1.2.0, and it makes no claim of conformance to the specification. The reference tooling's opf doctor grades a manifest declaring spec_version = "2.0.0" with homes = 2 under its 1.2.0 rules, so its VALID verdict on such a store says nothing about conformance to the specification; opf upgrade and opf record refuse such a store. The reference tooling defines no store upgrade: opf upgrade refuses every invocation with exit 2, reading and writing nothing.
• A host provider's conveniences call the external API of the host the target names. The egress bound is that named host and nothing else; the standard cannot vouch for the host's own behaviour beyond that bound.
• Public deliverables reach the product repository through opf render under that repository's normal review flow; the quality of that review flow is the adopter's own discipline, which the standard requires to exist but does not itself gate.