IMPLEMENTAUDIT
On this page
  1. Valid completion
  2. Audit gaps
  3. Invalid completion
  4. Evidence type taxonomy
  5. What complete does not mean
  6. Source surfaces
  7. Marker ordering
  8. Final audit checks
  9. Completion checklist
  10. Final state checklist
  11. Phase outcomes
Closure

Completion semantics

What AUDIT_COMPLETE means and why run completion cannot come before it.

Done means final checkable evidence, not a stopped chat.

AUDIT_COMPLETE is the review record that every in-scope item closed with checkable evidence.
If a real blocker remains, the run emits AUDIT_HANDOFF instead, and IMPLEMENTAUDIT_RUN_COMPLETE must not appear.

Valid completion

AUDIT_COMPLETE is the final audit verdict over the live work record.
Maintainer formal name: tdqyq-audit-object.

It means:

  • every in-scope item has final checkable evidence
  • every claim is bounded by its evidence type
  • every unresolved item is explicitly classified

Only then can IMPLEMENTAUDIT_RUN_COMPLETE appear.

Audit gaps

If the final audit finds a gap, the run writes AUDIT_GAPS, fixes with new evidence or a changed approach, and audits again.
There is no arbitrary retry cap; closure depends on evidence, not on the number of attempts.

Invalid completion

A stopped chat, failed check, hidden retry, unresolved owner decision, handoff marker, or missing evidence is not completion.

Evidence type taxonomy

Every behavioral claim should name the evidence type that supports it:

  • live runtime
  • local generated-runtime
  • package-bound
  • unit test
  • integration test
  • static checker
  • manual inspection
  • visual/browser
  • unverified

Static evidence is never upgraded to live proof.

What complete does not mean

  • Marketplace verification, listing, or publication.
  • Universal install proof across hosts.
  • Provenance, signing, attestation, SBOM, or checksum chain.
  • Graphify proof; Graphify remains orientation evidence.
  • ActiveGraph correctness or lifecycle proof; it may assist fork/diff checkpoints or mirror already-recorded run-root events.
  • A felt sense of completion. Evidence determines closure state.

Source surfaces

skills/implementaudit/templates/PROTOCOL.md final audit and skills/implementaudit/references/transcript-contract.md.

Marker ordering

AUDIT_COMPLETE must precede IMPLEMENTAUDIT_RUN_COMPLETE.
AUDIT_HANDOFF must not appear with IMPLEMENTAUDIT_RUN_COMPLETE.

Final audit checks

Final audit should inspect the relevant evidence surfaces, not a one-size-fits-all folder checklist.

Bound work record

When it applies
Every run
What reviewer checks
Request, scope, owner/source, claims, changed files, checks, and closure state.

Run folder (run root)

When it applies
Phased or larger work
What reviewer checks
Roadmap, state, phase checklists/specs, thinking/protocol files, sidecars, and final fix-and-verify notes.

Baseline and deliverables

When it applies
Every mutation claim
What reviewer checks
Baseline reference, deliverable comparison, generated-artifact freshness, and audit coverage math.

Closure markers

When it applies
Every completion or handoff
What reviewer checks
Marker order, handoff exclusivity, unresolved risk, and sidecar boundaries.

Completion checklist

  • The bound work record exists; for phased work, the run folder, STATE.md, roadmap, and phase checklist exist for the in-scope work.
  • Each edited scope has before/after evidence or a named reason that evidence is impossible.
  • Every failed check has a class, cause, countermeasure, rerun evidence, and outcome.
  • Each phase verification includes a Cleanliness: section tied to the baseline reference.
  • The final audit includes a Deliverables: block from repo-state comparison.
  • The final audit includes Audit coverage: so reviewers can see what was rerun, skipped, or trusted from prior evidence.
  • Generated artifacts are either verified against source or explicitly excluded from claims.
  • Owner/source, scope, and authorization decisions are recorded where they affected the run.
  • Any trusted earlier evidence is named; if accepted earlier evidence (trust-prior) exceeds 30% of rerun-plus-trusted checks, the run must print AUDIT_WARNING: trust-prior > 30% instead of hiding that reliance.
  • Deliverables are non-empty when the request expected an artifact.

Final state checklist

All ledger items final

Every item is done, changed, blocked, deferred, or unverified; nothing is orphaned.

Evidence type is named

Each claim cites the right evidence class: file diff, command output, generated artifact readback, release readback, checksum integrity, or explicit handoff.

Generated artifacts checked

Generated output is regenerated from source or intentionally excluded from claims. Hand-edited generated output is not silently accepted.

Release and publication gates separated

Commit, push, tag, release, publication, host install, and provenance are not implied by local checks.

Marker order valid

AUDIT_VERIFY precedes AUDIT_COMPLETE; AUDIT_COMPLETE precedes IMPLEMENTAUDIT_RUN_COMPLETE.

Handoff is honest

If blocked, the run leaves AUDIT_HANDOFF or ANDON_HANDOFF, blocker, remaining risk, and smallest next owner action.

Phase outcomes

A phase can:

  • complete
  • defer with an owner decision
  • escalate with new evidence
  • hand off when blocked

It cannot disappear because the final audit found the phase inconvenient.