Audit

Source of truth: the registry row in _processes/_shared/request-types.md, the preset _processes/_shared/presets/audit.md, and the action prompt _processes/03_action/audit/audit.prompt.md.

The flow

The orchestrator runs the audit prompt inline (a non-dispatch instruction library, like the doc_upkeep orchestrator). It first reads JOB.md → ## Action to resolve Kind / Scope / Agents / Depth / UpdateMode, then resolves the per-kind phase matrix — which of the three investigation phases this Kind runs (see below). For each enabled phase it runs one read-only instance of the shared managed sub-agent loop (_processes/_shared/managed-subagent-loop.md): a shallow Level-1 orientation pass enumerates the sections for that phase, then one read-only Level-2 sub-agent per section reads its area and returns a capped, evidence-cited per-section report, which the Consolidator folds into a compact per-phase report under 09_action/phases/. The orchestrator then writes the verified roll-up 09_action/action-report.md (section inventory across phases, findings grouped by severity, explicit skipped-surface list). It verifies the report, records completion in PROGRESS.md, and lands the job in 4_done/. When UpdateMode: report_fix, the audit additionally emits one contract-valid Type: feature intake into jobs/0_new/ referencing the reports, then stops (drop-and-tell).

The per-kind phase matrix

The audit decomposes into three investigation phases, and each Kind declares which of them it runs — there is no single fixed pipeline. The matrix is an inline authority the runtime applies directly (no separate recipe file — the Kind set is small and closed).

1. Phase 1 — current-code investigation. What the real code is; a deep, evidence-cited report of the current situation.
2. Phase 2 — global-app impact. How the audited part is used across the app — its callers/consumers, its job, its blast radius.
3. Phase 3 — best-practice / web validation. Revalidate against current libraries, idioms, and standards via WebFetch / WebSearch (cited URLs, untrusted content, degrade to low confidence when offline).

revalidate is the whole-app/scoped soundness sweep: it runs all three phases across all concern-types — structure, coding standard, find issues, validate docs, security — composed as one unified enumerator (the sections are enumerated once and tagged with their concern groups, not N sequential single-Kind runs), bounded by Depth + per-phase section caps + explicit skipped-surface reporting.

What it is for

An audit is a deep, evidence-backed review of the whole application — or a confined folder when you set a Scope. It exists to find and report, never to change inline: it produces per-phase reports under 09_action/phases/ plus a roll-up 09_action/action-report.md and writes no code.

• Read-only. Every sub-agent runs in read-only mode; the only artifacts written are the reports (and, in report_fix mode, one follow-up intake — never code).
• Whole-app or scoped. A blank Scope sweeps the whole application; a repo-relative folder confines the sweep.
• Multi-phase, per-kind. Each Kind runs the subset of the three investigation phases its matrix row enables (see the phase matrix).
• No clarify step. Unlike pipeline types, an audit has no mandate to pressure-test — its scope and objective come from the ## Action config, so it drops clarify entirely.
• Distinct from validate / review. Those check a single diff; an audit is a standalone, section-by-section sweep of the codebase as it stands.

The logic

An audit sits in the action layer with shape orchestrator (its own per-kind multi-phase mini-orchestrator; reshaped from a singlet in 0.13, D-61). The orchestrator routes it via orchestrator.prompt.md → §C.route — by layer / shape, not by the stage pipeline. An audit JOB.md therefore carries no stage machinery at all.

• Kind — the audit family, a closed vocabulary: security (default), find_issues, doc_drift, revalidate, or custom. One parameterised audit type covers the whole family; an unrecognised kind is a blocker. operation_record is not an audit kind.
• UpdateMode — audit-scoped report (default) | report_fix; governs only the post-report behaviour, disjoint from doc_upkeep's apply | report_only (same field name, different vocabulary — never conflated).
• Scope — blank sweeps the whole application; a repo-relative folder confines the sweep to that path.
• Routed, not staged — the route hands the job to the action orchestrator and does not run clarify → … → validate; the main orchestrator stays the sole PROGRESS.md writer and sole 4_done mover.

The fields

An audit JOB.md carries only the header, ## Git, ## Action, and an optional mandate. There is no ## Stages, no ## Approval gates, and no ## Per-stage config — action types are routed by layer/shape, not by enabled stages.

How to run it

There are two copy-path ways to run an audit. Both produce the same 09_action/action-report.md.

_processes/02_orchestrator/orchestrator.prompt.md

_processes/03_action/audit/audit.prompt.md

See also