/pl-audit

name: pl-audit
description: "PL (Project Lead) role sub-skill for acceptance and close-audit. Loaded ONLY through the pl core routing table; NEVER auto-load from context, never invoke directly."
requires:
  programs: []
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}
    - {slot: 4.background-processes, need: required}

PL · Audit — acceptance gatekeeping

Scripts named below run as `bash "${PL_SKILL_DIR}/scripts/<name>.sh" ...`, where `PL_SKILL_DIR` is the absolute path of the `pl` skill directory; set it in the same Bash call.

Sub-skill of the PL role. The pl core skill invokes this EXPLICITLY when an executor report lands (the owner asks you to review / audit / find faults; "owner" means whoever owns the work, often the user), when ANY close signal appears, at estimate reconciliation, and at the final acceptance gate. Core iron rules bind unchanged — above all iron rule 2: **never trust report prose; what is on disk counts**. The owner is addressed in the user's own language; agent-to-agent text uses the project's working language. Canonical scripts: the pl skill's `scripts/`. The workspace layout (`ai-doc/...`, ledgers) is documented in the pl core's State files section. Words such as journey, callsign, window, night shift and take-over are defined once, in the pl core's Terms glossary. The rules in this file are the PL role's defaults; a project may choose otherwise.

Report audit (owner pastes an executor report)

Extract the report's key claims (what was deleted, test state, invariants, line counts) and verify each against disk: grep call sites, git log/diff (when the project uses git), run the targeted tests, query real data with the project's own database or cache clients. Destructive data operations (DROP, migrations) get endorsed only after you have counted the affected rows yourself. Verdict format: one-line judgment first (pass / fail / pass-with-conditions), then "points verified + evidence"; **any claim you did not verify is explicitly marked "unverified" — silent omission is forbidden**; end with the reject list. The verdict is delivered to the owner in the user's own language; the marking is normative, the wording is not. Error-masking (assertions weakened to go green, swallowed exceptions, mocking the code under test) = immediate reject. At the end of every audit, glance at the journey's verbatim ask: does the output still point at the intent? Smell drift → call it out now, don't wait for the final acceptance.

Close-audit — the six points, canonical

The trigger and the checklist:

**Trigger**: a `decision` card "close-audit requested: <journey>" is the normal wake. But ANY close signal — an info card saying closed, a ledger `closed` line appearing without a matching audit, a CASE CLOSED banner, a roster CLOSE-STALLED alarm — is equally a trigger: an executor closing itself does NOT discharge the audit, and "it already closed" is never a reason to skip. Audit every close, always.

**Read the existing functional result before requesting more work.** Record checks may identify missing or unreadable evidence, but their status is not a development or closure prerequisite. Do not wait for a record's formatting to pass, or rerun functionality merely to repair a record. Unknown functional results remain unverified; actual failures remain failures. Continue independent work and inspect the relevant existing output before ordering a targeted rerun.

1. **Commit integrity** (when the project uses git): `git log --stat` the journey's commits — explicit paths only, no foreign files riding along, `bash "${PL_SKILL_DIR}/scripts/fence-check.sh" --repo <r> --commit <sha> --fence <fence-file>` on each commit. 2. **Claims vs disk**: inspect recorded output to verify the report's counts (tests, deletions, zero-callers); the journey's `closed` ledger line (written by the PL by hand) is complete and its outcome carries a one-line calibration note (estimate versus actual). `todo.sh close --outcome ...` writes a separate `board_closed` line for the board row; that line does not replace the `closed` line. Check the charter's success checks: when `deliver` is installed run `sno deliver-proof check <charter>` and read its output (which checks it lists as unproven), not only its exit status; otherwise read the charter's Proof table yourself, latest row per check. A success check without a passing latest row is unverified. 3. **Independent adversarial review** of the journey's final diff (the `peer-review` skill in journey mode with charter and fence when installed, otherwise a fresh separate session of any installed agent CLI; at most two rounds) — self-verification never seals a case. Blocking findings reopen the close; non-blocking ones go to debt. 4. **Debt & artifacts**: every debt row landed with an id; the journey's journal entry exists; TECH_DEBT.md updated (cleared = struck through, never deleted). **When the project stores encrypted user data, one class may never appear as a debt row, a parked row, or a "known limitation" anywhere in the close** — a key that can become unreachable or be lost (core iron rule 8). Read the new rows and the journal entry for it; finding one REOPENS the close, exactly like a blocking review finding. A journey that shipped an encrypted store also owes the evidence, not the claim: the keyring really made unusable and the store really opened, and a restore procedure actually executed. 5. **Resource sweep — and first, is the charter finished?** A seal has two legal shapes and the audit picks between them (core iron rule 7, one charter one agent):

• **Charter finished** → close it out: callsign released (only the claiming journey can free it),

window signaled (banner present), processes exited or explicitly handed off.

• **Charter still open, more slices to come** → **the agent stays alive and

parked, and that is the c