spec-conformance-audit git:20260906.ccd7eadA

Immutable. This exact content is served forever at /api/v1/blob/750392c869313a46.

---
name: spec-conformance-audit
description: Check whether an implementation matches its source specification and agreed decisions.
---

# 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 or protected constraint, classify it as:

- `satisfied`: implemented with adequate evidence
- `partial`: evidence confirms that some required behavior exists and another required part is absent
- `missing`: evidence from the relevant implementation establishes that the required behavior is absent
- `contradicted`: implementation does the opposite of the contract
- `unverified`: available evidence cannot establish satisfaction, including when implementation appears present but necessary execution evidence is missing

Missing execution evidence, inaccessible code, or an inconclusive search does not establish missing implementation. Record what the code does demonstrate and the exact proof still needed. Do not mark a requirement `partial` merely because only part of its verification has run.

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, require evidence from that path to claim satisfaction. Its absence is a verification gap; retain any deviation independently established by code or observed behavior.

## Coordinate journey evidence

Reuse relevant results from `user-journey-verifier` when they cover the same implementation or artifact version, entry point, inputs, and conditions. When a material acceptance gap remains, use [user-journey-verifier](../user-journey-verifier/SKILL.md) within the request's verification scope to obtain the missing evidence. Pass the requirement, expected outcome, actual user or consumer path, and relevant environment rather than requesting another general verification pass.

Journey verification may run before the audit or close a gap found during it; a conforming verdict is not a prerequisite. Credit a passing result only for the requirements it directly proves. Classify a failure from its observed mismatch and available implementation evidence, without assuming failed behavior means absent code. An unavailable or inconclusive journey remains a verification gap, not an implementation defect.

## Output

Lead with a direct verdict: `conforming`, `partially conforming`, `non-conforming`, or `unverified`.

Use `conforming` only when every material requirement and protected constraint is satisfied and no unauthorized expansion remains. Use `unverified` when material evidence gaps prevent establishing conformance and no confirmed deviation determines the verdict. Reserve `partially conforming` and `non-conforming` for demonstrated implementation gaps or contract violations, not checks that were never run.

When confirmed deviations coexist with verification gaps, report the supported partial or non-conformance verdict and list the unverified requirements separately. Missing evidence must not hide a known defect or be presented as one.

Then provide the smallest useful traceability table:

| Requirement or constraint | Source | Implementation and verification 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 and protected constraint 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.