spec-conformance-audit · git:20260820.32cf61b · 2026-08-20 · sha256 72f5461d86750f67
spec-conformance-audit git:20260820.32cf61bA
Immutable. This exact content is served forever at /api/v1/blob/72f5461d86750f67.
--- name: spec-conformance-audit description: Audit an implementation against its originating specification, issue, plan, or explicit decisions. Use to find missing requirements, partial compliance, contradicted constraints, and unauthorized scope expansion. Read-only; not a general code-quality review. --- # Spec Conformance Audit Determine whether the implementation matches what was authorized. Audit only. Do not edit files, apply fixes, commit, publish, or mutate external systems unless the user separately asks for implementation. ## Goal Trace every material requirement and protected constraint to observable implementation evidence, while identifying work that changed behavior beyond the agreed scope. ## Establish the Contract Use the smallest authoritative source set that defines the work: - the user's latest explicit decisions and corrections - the named specification, issue, plan, or selected review feedback - repository instructions and established contracts that the work did not authorize changing Later explicit decisions override earlier proposals. A suggestion is not a requirement merely because it appears in a plan or prior model response. Current implementation behavior is evidence, not automatically the intended contract. Extract only what affects the verdict: - required outcomes and acceptance criteria - behavior, data, interfaces, and user flows that must remain unchanged - explicit exclusions and protected surfaces - unresolved decisions that were not authorized for implementation If sources materially conflict and their precedence cannot be established, report the conflict instead of inventing a merged requirement. ## Inspect the Implementation Inspect the relevant diff, current code, affected callers and consumers, and verification evidence. Read surrounding code only when needed to understand a contract, behavior boundary, or possible spillover. For each material requirement, classify it as: - `satisfied`: implemented with adequate evidence - `partial`: some required behavior exists, but the contract is incomplete - `missing`: no implementation evidence - `contradicted`: implementation does the opposite of the contract - `unverified`: implementation may exist, but available evidence cannot establish it Report **unauthorized expansion** separately when the work changes behavior outside the contract, such as unrelated product surfaces, schemas, export formats, business rules, external records, dependencies, or compatibility policy. Extra code is not automatically unauthorized: require a concrete behavioral, operational, or maintenance consequence beyond the approved scope. ## Evidence Standard - Cite the exact contract source and implementation location for every material finding. - Separate observed facts from inference. - Do not credit a requirement based only on naming, comments, or a test that does not exercise the promised behavior. - Do not fail conformance for style, architecture, complexity, test quantity, or personal preference unless the contract explicitly governs it. - When acceptance depends on a user-visible path or generated artifact, state that conformance remains unverified until that path is exercised. ## Output Lead with a direct verdict: conforming, partially conforming, or non-conforming. Then provide the smallest useful traceability table: | Requirement or constraint | Source | Implementation evidence | Status | | --- | --- | --- | --- | After the table, include only applicable sections: - **Unauthorized expansion**: changed surfaces that were not approved - **Evidence gaps**: claims that cannot yet be verified and the exact proof needed - **Scope-safe next step**: the smallest correction or verification step, without implementing it If every material requirement is satisfied and no unauthorized expansion exists, say so directly without inventing findings. ## Stop Rules Stop when every material requirement and protected constraint has a classification, unauthorized expansion has been checked, and the remaining evidence gaps are explicit.