audit

name	audit
description	Independent acceptance audit of a completed DevFlow plan — zero trust, re-measures every metric itself, audits without fixing. Produces a PASS / PASS WITH FINDINGS / FAIL report. Must run in a fresh session (no executor history) and only after all sprints claim completion.
argument-hint	[plan folder path]

request-devflow-plan:audit

Independent acceptance audit. Run in a fresh session only — never in the same session as any execution. $ARGUMENTS optionally names the plan folder.

Flow

Step 1 — Locate and read

Locate the plan folder (as in kickoff), then read every plan document in README order — including audit-log.md for the round history (it informs; it never substitutes for your own re-measurement). Cross-agent auditing is encouraged: a different agent than the last round's is a feature, and the log is your shared memory.

Step 2 — Core audit

Per the plan's final-audit doc and 00-iron-rules:

Part 1 — Independent re-run

• Re-measure every metric in the final-audit table yourself; trust nothing recorded in PROGRESS
• Run the full gate suite twice back to back (any mismatch between runs = major defect)
• Every conclusion carries its command, exit code, and output

Part 2 — Anti-cheat (the plan's final-audit doc is authoritative when its list differs)

1. Changed expectations: scan git log -p over the test tree for assertion changes; check each against its sprint-doc authorization
2. Scope shrink: every sprint's acceptance criteria against PROGRESS evidence, row by row
3. Skip audit: integration skips = 0 unless each new skip has a recorded reason
4. Commit discipline: sample 15 commits and check their diffs against the declared concern
5. Report honesty: do the phase reports cover every deviation in implementation-notes §4?

Part 3 — Out-of-plan scan ≥30 minutes of your own judgment. Answer: "where will the person inheriting this in six months still hurt?" Then run EVERY finding (from all three parts) through the plan's blocking test (final-audit §3b — the five fixed tests): record the first test it hits plus evidence, or "none of the five". A finding without this record is an incomplete audit, not a non-blocking finding.

Step 3 — Report

Write the audit report to the location the plan's final-audit doc names (default docs/phase-reports/final-acceptance-audit.html). Re-audits never overwrite earlier reports — suffix subsequent runs (-r2, -r3, …):

1. Verdict: PASS / PASS WITH FINDINGS / FAIL (+ the shortest repair path)
2. Metric table, one row per metric: measured value / command / verdict
3. Defect list: severity / location / suggested owning sprint
4. Out-of-plan findings
5. The three most important conclusions for the maintainer

Step 4 — Summarize and route

Verdict + defect summary in the conversation. Append this round to audit-log.md (verdict, defect counts, route, consecutive-FAIL count, your identity, a note to the next auditor) and record the verdict entry in the acceptance unit's PROGRESS section — these two appends are the only plan-folder writes an auditor makes. The verdict is computed from the blocking-test records, never felt:

• PASS → all metrics green, zero findings → suggest handoff.
• PASS WITH FINDINGS → all metrics green AND every finding recorded as hitting none of the five blocking tests → ask the maintainer where to record the findings: GitHub issues (when the repo uses them) or the plan's issue-handoff.md (IH-entry format in the plan templates). Then suggest handoff. Never loop on non-blocking findings.
• FAIL → any metric miss, or any finding hitting a blocking test → hand the defect list to remediation planning (plan skill, remediation mode): all blocking defects — regardless of size — become one remediation unit (full lifecycle) plus a paired re-acceptance unit. From the 2nd consecutive FAIL, remediation mode opens with a root-cause interview. Loop until a round passes; no defect is fixed off the books.

End with the Next steps block — full copy-paste command lines with actual values (shorthand and unfilled placeholders are violations), recommended line first. Commands that need a fresh context get the advisory line "Run /clear (or open a new session) first" printed before them:

• PASS → /request-devflow-plan:handoff
• PASS WITH FINDINGS → offer to file the findings right now (issues or issue-handoff.md), then print /request-devflow-plan:handoff
• FAIL → print all three, in order, computing the remediation unit number as the plan's last unit + 1: /request-devflow-plan:plan — remediation mode picks this report up automatically /request-devflow-plan:kickoff sprint <computed number> — fresh session, after the plan lands /request-devflow-plan:audit — fresh session, after the remediation unit is signed off

Principles

• Zero trust, audit only, evidence first
• The audit session and any execution session must be fully separate
• On FAIL, fix nothing (environment repairs excepted)

Never

• Fix anything (environment excepted)
• Pass because "most of it passed" — one miss is FAIL
• Treat "the ledger says done" as done