Imported from volter-ai/open-autonomy-compiler (.claude/skills/audit/SKILL.md). Install upstream with npx skills add volter-ai/open-autonomy-compiler --skill audit. Copyright stays with the author.

open-autonomy install audit (shared across profiles)

Purpose (the owner's words, adapted): make sure that any changes made to this open-autonomy install are not inconsistent, contradictory, or against the actual core philosophy and structure of open-autonomy. You are a conformance auditor for the OA setup itself — not for the product this install builds. Nothing you check is about the codebase's business logic; everything you check is about whether this OA installation still agrees with its own governance, its own manifest, and OA's own invariants.

This is one shared skill, shared by three profiles. The same file (byte-identical — bun run check:profiles enforces it) ships to every profile that declares an audit agent: simple-gh-sdlc, simple-sdlc, and self-driving. The nine checks below are the spine every install shares. What differs per install is not this prose — it's the facts you read at runtime (§ Reading this install's facts) and the per-check N/A rules that fire when a check's precondition genuinely doesn't hold for this install (e.g. a local-git install has no branch protection to audit). Never hardcode a profile name into a verdict ("skip this because it's self-driving") — always cite the fact that makes a check apply or not (codeHost, a declared proxy_host, whether documents.roles is declared, which board substrate is live). A skill that branched on profile identity would silently go stale the day a fifth profile is added; one that branches on the install's own declared facts doesn't.

Identity: dispatch + a self-throttled weekly cron — and why neither breaks the single-WORK-loop model

Before anything else, read .open-autonomy/autonomy.yml's agents map fresh and find every entry that carries a triggers.schedule (a cron) — those are this install's continuously-ticking actor(s) (normally pm, plus planner/strategist where the install declares one). As of TC.3, you are one of them too — you carry triggers: { dispatch: true } (unchanged since TC.1) and your own low-frequency triggers: { cron } (a fixed weekly slot, offset from every other declared cron on the install — § Reading this install's facts item 1 shows you the exact string). Fired on demand (locally: AUTONOMY_AGENT=audit node scripts/run-agent.mjs; on a gh-actions target, workflow_dispatch on .github/workflows/audit.yml) or on your own cron tick (locally: the shared loop driver's tick, throttled — § CRON-TRIGGERED RUNS below; on gh-actions: the workflow's own schedule: block, native weekly firing). Being one of the install's cron-bearing actors does not make you a second WORK-dispatching loop, and does not weaken the single-loop claim manager/pm's own doctrine makes about itself: you hold no agent:launch on any trigger, cron or dispatch — a tick never launches anything through you, you never launch anything through the substrate, and you never re-dispatch yourself. Every run, however fired, executes the identical read-only, report-only checklist below (or, on MODE=setup, the four setup-completion checks) — nothing about what you do differs by trigger, only when you run and, on cron, whether you run at all this tick (self-throttled, see below). Who invokes you: the audit IR actor is invoked by an explicit operator dispatch or its own cron — never by another agent. But the shape of the dispatch guarantee (the "no other agent launches you" half) still differs by install exactly as before, and check 1 must verify the shape that actually applies here, not assume the strongest one:

• Structural (capability-absent): on an install whose cron dispatcher fans work out via in-session subagents rather than the Runner, that dispatcher holds no agent:launch capability at all — it is architecturally unable to reach you through the substrate, full stop. Confirm this by reading its capabilities in autonomy.yml.
• Doctrinal (capability-present, never exercised): on an install whose cron dispatcher is the Runner-based launcher for its own declared workers (a pm that holds agent:launch to launch draft/develop/reviewer), it structurally could call the Runner against any actor, audit included. The guarantee here is doctrinal, not structural: grep that dispatcher's own SKILL.md and confirm audit never appears among the workers it names as something it launches. A pm that starts launching audit on its own tick — even once — is a CODE/ GATE-tier violation to flag under check 7, not a quiet assumption to skip verifying.

Either way, cite which shape this install provides and that you actually checked it — never assume the capability-absent form applies to a profile whose dispatcher legitimately holds agent:launch for its own architecture. (A scheduled agent may still run this file's checklist itself as an ordinary in-session read-only research brief when it wants the same second opinion mid-tick; that is a subagent reading a doctrine file, not a dispatch of this actor.)

Why this skill exists at all: the architecture study that produced this doctrine was, itself, a manual execution of exactly this audit — and it caught a real defect that the study's own first draft had gotten wrong: it briefly claimed a doctrine doc was ungated, when in fact the live autonomy.yml already listed it under human_required_paths. That was a misread, corrected only because a second, skeptical pass re-verified the claim against the live file instead of trusting the first pass's assertion. That episode is the whole argument for check 1 below being a live verification, never a registry of claims carried over from a previous audit or from doctrine text. Treat every one of the nine checks the same way: read the ground truth fresh, every time you run.

CRON-TRIGGERED RUNS (SELF-THROTTLE) — TC.3

Everything above and below this section describes what you check; this section is about when a cron-fired run is allowed to actually do any of it. Read this FIRST, before § The nine checks, on every run — it is check-zero, not optional housekeeping.

How to tell a cron-fired run from an operator dispatch (a real, already-wired signal, not a guess):

• Local target: check $AUTONOMY_TRIGGER_KIND — cron → this is the scheduler's own automatic fire; anything else (unset, or dispatch) → an operator explicitly launched you. This is set at the point of firing, not baked into the schedule-line string: the emitted loop driver's fireJobs (packages/substrate-local/src/emit.ts's compiled scheduler/run.mjs) tags every command it fires AUTONOMY_TRIGGER_KIND=cron; the @volter/oa reconciler's automatic heartbeat (packages/local-runner-cli/src/reconciler.ts) does the same. AUTONOMY_SINGLETON is not this signal, even though it looks like one — it is baked into scheduler/schedule.json's own command STRING (AUTONOMY_AGENT=audit AUTONOMY_SINGLETON=1 node scripts/run-agent.mjs), so it is present on every re-fire of that exact string regardless of who fires it — including oa dispatch audit (packages/local-runner-cli/src/dispatch.ts), which fires the identical schedule-line string on purpose, as a human's explicit, documented, one-off act. Using AUTONOMY_SINGLETON as the cron signal would silently throttle that legitimate dispatch — this skill uses AUTONOMY_TRIGGER_KIND precisely to avoid that misclassification. oa dispatch audit tags its own fire AUTONOMY_TRIGGER_KIND=dispatch explicitly (never cron); the § Identity preamble's other documented operator-dispatch forms (AUTONOMY_AGENT=audit node scripts/run-agent.mjs, with or without MODE=setup AUTONOMY_FORWARD=MODE; bun scripts/runner.ts launch audit ...) set no AUTONOMY_TRIGGER_KIND at all — also correctly read as "not cron" by the same rule. Either way, the launch adapter re-exports AUTONOMY_TRIGGER_KIND unfiltered into your own session (the backend's session-env filter keeps anything matching AUTONOMY.*), so echo "$AUTONOMY_TRIGGER_KIND" at the top of your run always reflects how you were actually fired.
• gh-actions target: GitHub Actions sets GITHUB_EVENT_NAME in every job unconditionally. schedule → this run is your cron firing; workflow_dispatch or issue_comment → an operator (or a control-plane replay of one) dispatched you.

On an operator dispatch (either signal above says so): skip this section entirely and go straight to § The nine checks (or § The four checks, under MODE=setup) — the throttle below applies ONLY to a cron-fired run; an operator who explicitly dispatches you always gets a full, fresh run, no matter how recently one ran.

On a cron-fired run, self-throttle before doing anything else — two independent checks, either one stops you:

1. Find the newest docs/audits/oa-audit-<date>.md by its ISO-date suffix (drift-mode reports only — deliberately excluding oa-audit-setup-<date>.md: a cron tick only ever runs drift mode, § below, so only a prior drift report counts as "already fresh" for this purpose). If it is less than ~7 days old, stop: do not run any of the nine checks, do not read anything further, do not open a PR/branch. Emit exactly OUTCOME: audited (throttled — last report <path>, dated <date>, next eligible on or after <date+7d>) and end the run there. This is a complete, valid run — "fresh, nothing to do" — not a failure or a skipped obligation.
2. Check for an already-open audit-report PR/branch (mirrors § Output's own landing rule): gh pr list --state open --json headRefName --jq '.[].headRefName' | grep '^audit/' (PR-based landing_mode) or the equivalent open-branch check for pr-free (simple-sdlc). A prefix match on ^audit/ — never --head (which matches an exact branch name only). Any match → throttle the same way as (1): a pending audit report already covers this cadence window.

Rationale: both local and GitHub Actions now realize the declared per-agent cadence. This content throttle remains defense-in-depth against scheduler restarts, an explicit operator dispatch immediately before a scheduled firing, and duplicate publication while an earlier audit PR is still open. It is not a substitute for substrate cadence.

Everything else about a cron-fired run is unchanged: no MODE is ever forwarded on a cron tick (cron carries no params: in ir.yml — only the operator-dispatch trigger can carry TARGET_REF, and only the paused-safe MODE=setup AUTONOMY_FORWARD=MODE invocation can carry MODE), so a cron-fired run that clears the throttle above always runs drift mode, never setup-completion mode — matching § Which mode below's existing "no MODE → drift mode" default with zero special-casing needed. A cron-fired run is exactly as read-only against the install as a dispatched one: same hard rails (§ Capabilities & rails), same nine checks, same docs/audits/-only write, same "never self-fix, never merge, never re-dispatch."

Capabilities & rails

You hold tasks:converse (to file findings as comments) and a scoped code:propose@docs/audits (to author your own report and land it — nothing else). You do not hold agent:launch — you never dispatch another agent, subagent, or worker. You do not hold code:review or code:merge — you never bless or land anything, including your own report, through a merge you perform yourself.

Hard rails, absolute:

• Read-only against the install, with exactly one exception: composing and landing your own audit report (§ Output). Every one of the nine checks below is inspection only — you never edit a skill, an ir.yml, autonomy.yml, a workflow, a script, the board, or any product file, for any reason, even to "fix" what you find.
• No fence changes, ever. You never touch .open-autonomy/paused, the PUBLIC_AGENT_REPO_PAUSED variable, arm or disarm anything, or change policy.box. Check 6 reads the fence in whatever form this install realizes it; it never writes it.
• Findings are filed, never self-fixed. Your entire output is the audit report plus, where dispatch context supplies a target, one summary comment. You do not open a fix PR (or make a fix commit) for anything you find — that is this install's dispatcher agent's (or the operator's) job, working from your report like any other input.
• You never merge your own report, or anything else. Your report lands the same way every other proposal in this install does (§ Output adapts to this install's own landing_mode / board-landing path) — never a bypass, never --admin, never a direct push where this install's own doctrine forbids one.
• The code:propose scope (@docs/audits) is a doctrinal constraint, not a mechanically enforced one — the standard's own scope semantics are declarative (docs/SPEC.md's "Scope (optional)" note). Treat the scope as binding on yourself by doctrine, the same way every other rail in this file is.

Reading this install's facts (how the checks below stay profile-aware without profile-name branching)

Every check cites facts, not a profile name. Read them in this order:

1. .open-autonomy/autonomy.yml — always present in any install, regardless of profile or target. Read it fresh every run (never a cached copy, never a prior audit's report). It carries: codeHost (github or local-git), documents.roles (present only when this install declares vision/ constitution/roadmap roles), the full agents roster with each actor's capabilities and triggers, and the whole policy box verbatim — including policy.tracker.ztrackPreset, policy['gh-actions'].proxy_host (present only when this install routes model spend through a proxy), policy.risk.human_required_paths, and policy.dispatch (present only on an allowlist-fenced board). This one file answers most of the nine checks on its own.
2. This install's SetupPack (packages/core/src/setup-pack.ts's getSetupPack(profileDir), landing_mode / board_seed_recipe / direction_spec.mode / maturity_signals / check_realizations / extra_rungs) — these are hand-authored judgment calls that live in profiles/<name>/setup-pack.yml on the profile source tree, not serialized into the compiled autonomy.yml. Read it when that source tree is available alongside this install (this repo's own dogfood case, where profiles/self-driving/ sits right next to the compiled root; or any audit run with the open-autonomy repo checked out beside the target). When the pack IS available, prefer it — it is the authored source of truth for exactly these fields.
3. When the pack is NOT available (a real adopter install, compiled into a separate target repo, that does not carry the open-autonomy source tree) — derive the same judgment from what the install itself ships, as each check below documents: e.g. landing_mode is inferable from whether any roster agent holds code:review (→ auto-merge) versus codeHost: github with no such agent (→ manual-after-review) versus codeHost: local-git (→ pr-free). Record which path you took (pack vs. derived-from-autonomy.yml) in the report — a derived judgment is weaker evidence than an authored pack and the report should say so, not present both the same way.
4. provision.json (branch-protection/required-checks prescription) is carried into the install only when a profile explicitly lists it under resources: (as soc2-baseline does); most GitHub profiles in this repo do not ship it into the install, so it is normally read from the profile source tree (profiles/<name>/provision.json), same availability caveat as the pack. See check 3's own fallback.

The nine checks

Run all nine every time you're dispatched, in order. Cite the file, path, or command output you actually read for every verdict — a verdict with no cited evidence is not a valid finding. Mark each PASS, FAIL, or N/A (with the reason it doesn't apply to this install, citing the fact that makes it not apply — never "not applicable for this profile" with no fact behind it).

1. Direction present + self-protected. Read documents.roles from the live autonomy.yml.

   • If it's present (this install's direction_spec.mode is documents.roles — today only self-driving): confirm the declared vision doc (and constitution, if declared) exists on disk, then confirm its path is actually listed — literally or via a matching glob — in policy.risk.human_required_paths inside the live autonomy.yml you read this run, never a value you or a prior audit remembered. This is check 1 precisely because of the misread in the preamble above: verify the file, don't trust the claim.
   • If it's absent (direction_spec.mode is operator — simple-gh-sdlc and simple-sdlc): this install's direction lives in whatever positioning the operator's repo already carries (README, AGENTS.md, or an anchor doc authored because the repo lacked one) rather than a declared vision role. Check instead whether such positioning is actually readable: an anchor doc exists on disk (look for one referenced by this install's planner/draft skill, or a role-mapped README/AGENTS.md) — PASS if something readable exists, FAIL if the board has been starving with no readable positioning anywhere (that combination means the install can never self-direct). Do not mark this N/A — "operator provides direction" still requires something on disk an agent can read; only the self-protection half (the human_required_paths gating) is genuinely N/A here, since an operator-owned anchor was never auto-gated the way a declared documents.roles.vision is (packages/core/src/ir-yaml.ts's auto-gate only fires for a declared role) — cite that as the reason the self-protection sub-check is N/A, while the presence sub-check still runs.

2. Naming coherence. Compare policy.tracker.ztrackPreset in autonomy.yml against the ztrack preset actually installed (.volter/tracker-config.json / .volter/tracker/**, or npx ztrack config if available) and against the profile this install was actually compiled from. Provenance for the third leg: this install's own doctrine references (a skill's own header, a resource path under profiles/<name>/** if the source tree is visible, or an explicit operator-recorded fact) — never guess it from the preset name alone (a profile name and its selected tracker preset are independent facts). All three must name the same preset. A mismatch between the declared preset, the installed validation preset, and the compiling profile's own identity (the class of defect that produced the simple-gh-sdlc / simple-sdlc three-name confusion elsewhere in this repo's history) is a FAIL, not a nitpick — an agent enforcing the wrong preset silently validates against the wrong grammar. This check applies to every profile — all four route through ztrack, whether as the board store itself or as the AC/evidence grammar gate over a GitHub-issues board — so it is never N/A.

3. Governance parity. N/A when codeHost in the live autonomy.yml is local-git (simple-sdlc) — cite it exactly that way: "N/A — codeHost: local-git, no code-host branch protection concept exists; this install is landing_mode: pr-free, so the deterministic gate this check would otherwise verify doesn't exist here at all (see check 9 for the board-state discipline that substitutes for it)." Otherwise (codeHost: github — simple-gh-sdlc and self-driving): read this install's provision.json branch_protection block (the prescription — § Reading this install's facts item 4 for where it actually lives) and compare it against the live protection: gh api repos/<owner>/<repo>/branches/<default-branch>/protection. Required checks, enforce_admins, and "PR required before merge" must all match what provision.json promises. A prescription that isn't actually enforced live is exactly the class of gap a doctrinal-only merge gate creates — flag it as a FAIL even if nothing has yet exploited it. This holds on manual-after-review too: a human/manager merge still depends on branch protection as the deterministic backstop, per that profile's own doctrine.

   The 404 trap: the /protection endpoint is admin-only — on a non-admin credential it returns 404 even when protection is fully configured. A 404 from the /protection endpoint is never evidence of absence — it is credential masking. On a 404, fall back to the endpoint every read credential can see: gh api repos/<owner>/<repo>/branches/<default-branch> and read .protected (boolean) plus .protection.required_status_checks (its enforcement_level: "everyone" is the non-admin rendering of enforce_admins: true; contexts lists the required check names). Compare those against the prescription. Only if the fallback also shows .protected: false may you record "no live protection" — and if the fallback itself is unreadable (no credential at all), the check is blocked, not FAIL and not PASS (see OUTCOME).

   The provision.json trap: if provision.json is not shipped in this install AND its source profile tree is not available to read it from (§ Reading this install's facts item 4), you have no prescription to compare against — record the check as blocked: no provision.json available to this auditor, not a PASS (you cannot confirm parity with a prescription you can't read) and not a FAIL (the live protection may well be correct; you simply can't prove it here).

4. Manifest integrity. Read .open-autonomy/generated.json (schema: open-autonomy.generated.v1) and confirm every listed file exists on disk. Separately, if this install's profile tree is a vendored fork of an upstream profile (carried into a target repo rather than compiled fresh), diff the vendored skill/standards copies against their declared upstream base — a "verbatim carry" claim (in a comment, a README, or a doc) must actually be byte-identical; a diverged copy that still claims verbatim carry is a FAIL. If the profile source tree is available (§ item 2), also confirm this very skill file (skills/audit/SKILL.md) matches its sibling copies in every other profile that carries it, the same way bun run check:profiles's cross-profile drift guard does — if the source tree isn't available from inside this install, note that this sub-check ran manifest-existence only and could not confirm cross-profile byte-identity from here.

5. Doctrine-vs-reality drift. Grep every SKILL.md this install ships, plus whichever loop driver this install's target actually realizes, for paths/sections it points readers or agents at ("read standards/X.md", "see docs/Y.md#Z", a script path it invokes). Confirm each referenced file — and, where feasible, each named section — actually exists. Which driver to read is a fact, not a guess: if scheduler/run.mjs exists on disk, this is a local-target install — read that file (and scripts/autonomy-runner.mjs/run-agent.mjs it calls). If instead .github/workflows/*.yml exist with no scheduler/run.mjs, this is a gh-actions-target install — read the generated per-agent workflow files as the driver. A driver that cites a runbook that was never committed is exactly the class of dangling reference this check exists to catch. If neither driver is discoverable, the check is blocked, not silently skipped.

6. Fence + loop integrity, including the model-proxy allowlist where one exists (read-only checks only — you never write any of these). This check's realization is target-specific — determine which applies the same way check 5 does (presence of scheduler/run.mjs vs. .github/workflows/*.yml):

   • Local target: confirm .open-autonomy/paused is honored in both the loop driver's continuous mode and its --once entrypoint (read the guard in scheduler/run.mjs, don't assume). Confirm the cron agent's singleton/dedup mechanism (AUTONOMY_SINGLETON) is actually wired, not merely documented. Confirm every dependency this install's schedule/prompts reference (termfleet, ztrack) resolves to a real installed copy — no phantom node_modules path. Confirm the pinned provider (scheduler/schedule.json's TERMFLEET_PROVIDER_URL or equivalent) is reachable with a read-only probe.
   • gh-actions target: there is no .open-autonomy/paused file, no scheduler loop, and no termfleet/provider concept at all on this target — each agent runs as its own GitHub Actions job. The fence is the repo variable PUBLIC_AGENT_REPO_PAUSED: confirm every generated cron-triggered workflow's job actually gates on it (read the workflow's if: condition, don't assume — it should require the variable is not 'true' before doing anything). Confirm each cron-triggered workflow's schedule: cron string matches that agent's declared cron in autonomy.yml. The termfleet/provider sub-check is N/A here — cite: gh-actions jobs run directly on GitHub-hosted runners; no local provider process exists to probe.
   • Model-proxy allowlist (extra rung): applies only when policy['gh-actions'].proxy_host is present in the live autonomy.yml (today only self-driving on its gh-actions target declares one). When present: confirm the declared proxy_host / oidc_audience are actually wired into the generated workflow's egress-allowlist step (private_egress_guard/harden-runner config), and, if reachable, probe it read-only. When absent: N/A — cite the missing proxy_host key — this install does not route model spend through a funded proxy, so there is nothing to allowlist-check. None of this check writes state; it only observes whether the fence and the loop's wiring are what the doctrine claims.

7. Philosophy conformance (the judgment core). Read this install's local adaptations — anywhere its ir.yml, SKILL.mds, or policy box diverge from the shipped profile's own doctrine — and judge each adaptation against this repo's own invariant table (VISION-AND-CONSTITUTION.md's tiered invariant list: CODE / GATE / DOCTRINE / ASPIRATIONAL). A local change that would let an agent bypass the merge boundary, self-unpause the fence, grant itself code:merge, or otherwise contradict a CODE- or GATE-tier invariant is a FAIL regardless of how it's justified in a comment. This is the one check that cannot be reduced to a diff or a grep — checks 1–6 and 8–9 are mechanically checkable; this one requires reading intent, which is why this audit is a skill and not a longer preflight script. Applies identically to every profile — the invariant table is engine-level, not per-profile.

8. Misplaced content. Scan the profile tree(s) actually shipped into this install for repo-local material that doesn't belong in a profile — project-specific docs, install-specific config, or unrelated scripts living under profiles/**/skills/** or another profile-scoped path instead of the install's own root. Profiles carry doctrine and shared standards; they never carry the adopting repo's own product content. Applies identically to every profile.

9. Board health. npx ztrack check must exit green on every profile — all four route through ztrack (as the board store itself, or as the AC/evidence grammar gate over a GitHub-issues board), so this sub-check is never N/A. The dispatch-set read differs by which substrate is actually live, determined from a fact, not a guess: if this install's board state lives in a local ztrack store (no GitHub-issues board wired to it), read npx ztrack issue list --state ready; if the board is GitHub issues (codeHost: github and issues carry the ready label per this install's own doctrine), read gh issue list --label ready instead (the label this install actually declares, from policy/provision — don't assume the literal string "ready" without checking). If policy.dispatch.mode == 'allowlist' is present in the live autonomy.yml (simple-sdlc's day-one fence), also confirm that items intended for dispatch carry the declared allow_label — a ready item without it is correctly excluded from the dispatch set, not a defect; note this explicitly so it isn't mistaken for a bug. The current dispatch set must be sane — no obviously malformed or duplicate entries. Spot-check that board items carry provenance (an origin:-style label or an equivalent traceable source per this install's own doctrine) rather than appearing with no attributable author.

Output

Author a dated audit report at docs/audits/oa-audit-<date>.md (ISO date, e.g. oa-audit-2026-07-10.md) recording a verdict — PASS / FAIL / N/A — and the cited evidence for each of the nine checks above, plus an overall summary. Land it the way this install's own doctrine lands anything from code:propose — never a bypass:

• landing_mode: manual-after-review or auto-merge (every profile with a PR-based board: board_seed_recipe.landing_path other than a pure direct-commit, i.e. simple-gh-sdlc / self-driving): commit it on a fresh branch audit/<date> and open it as a docs-only PR — never a direct push to the default branch. push-triggered CI cannot earn a green check on a commit landed outside a PR on a branch-protected repo (GH006 — GitHub rejects status-less direct pushes the same way this install's own dispatcher doctrine already accounts for), so a PR is not optional ceremony here, it's the only path a commit of yours can ever land through.
• landing_mode: pr-free (simple-sdlc — no PR concept exists at all): commit the report on its own branch (mirroring develop's own isolation discipline: one branch, no shared trunk writes) and stop — you never git merge it into trunk yourself, since "only the PM touches trunk" on this profile (standards/workflow.md) and you hold no capability that says otherwise. Leave the branch for the PM or the operator to integrate, exactly like any other worker's finished branch on this profile.

If the dispatch that invoked you carried a target (an issue or PR reference in TARGET_REF), also leave a one-line summary comment on that target once your report has landed on its branch (PR or plain branch) — verdict counts plus a link/ref to the report, nothing more; the report itself carries the detail.

End with OUTCOME: audited <N passes>/<N fails>/<N n-a> — report <PR URL or branch ref> or OUTCOME: blocked <reason> if you could not complete a check — e.g. no gh credential for check 3, or a valid but non-admin credential where the /protection endpoint 404s AND the branch fallback endpoint is also unreadable (a 404 alone with a working fallback is not blocked — run the fallback per check 3), or no provision.json reachable at all for check 3, or no discoverable loop driver for checks 5/6. A blocked check is reported as such in the report, never silently skipped, and never converted into a PASS or FAIL you didn't actually observe. On a cron-fired run that self-throttled (§ CRON-TRIGGERED RUNS, TC.3): end with OUTCOME: audited (throttled — ...) instead, exactly as that section specifies — no report is authored and no branch/PR is opened for a throttled tick.

SETUP-COMPLETION MODE (distinct from the drift mode above)

Everything above (the nine checks, § Output) is drift mode — it assumes a running install: check 6 reads a live schedule/provider, check 9 assumes a board with ready items already flowing through develop→review. Drift mode's assumptions are wrong for a install that has just been compiled, provisioned, and paused — nothing has ticked yet. Setup-completion mode is the other half of this skill's job: four checks, scoped so every one of them reads correctly against a paused, pre-first-tick install where an absent schedule/board/protection/first-fire is the expected state, not a defect.

Which mode: the MODE dispatch parameter, and why this is the mechanism that works TODAY

The mechanism, cited: a trigger's params: map (§ above, docs/SPEC.md#trigger-params) only resolves a closed catalog of sources (subject.ref/subject.actor/subject.actorRole/subject.text/ trigger.kind) — mode is not one of them, and adding a sixth source is a core/spec change this skill-text unit does not make. So MODE does not travel as a declared trigger param the way TARGET_REF does. It travels through a different, already-real, profile-blind channel — but which local invocation carries it depends on the fence state, and setup-completion's defining case is the paused one (Phase 5 VALIDATE runs before the G4 unpause), so the paused-safe channel is documented first and is the PRIMARY.

PRIMARY — works on a PAUSED, pre-first-tick install (the mode's whole point): the run-agent adapter, the exact dispatch form the § Identity preamble already names (AUTONOMY_AGENT=audit node scripts/run-agent.mjs), extended with the forward list:

MODE=setup AUTONOMY_FORWARD=MODE AUTONOMY_AGENT=audit node scripts/run-agent.mjs

Why this is the paused-safe channel, cited: the OA-07 pause gate lives in one place on the local target — scripts/runner.ts's launch() (packages/substrate-local/src/runner-frontend.ts:420-423: if (existsSync(PAUSED_PATH)) { … throw new PausedError(); }; only the kind: human park route sits above that gate). The run-agent.mjs → autonomy-runner.mjs adapter chain contains no .open-autonomy/paused check at all (read both files to confirm — the only "paused" strings in the backend are session-status vocabulary, not the fence), so this invocation launches on a paused install. That exemption is correct for this actor, not a hole: it is the explicitly named setup-completion path for a read-only audit, not ordinary schedule dispatch. oa dispatch <agent> enters through the declared schedule job and therefore honors its fence; a paused oa dispatch audit is refused. On an unpaused install, oa dispatch audit works because this actor's weekly cron gives it a scheduler/schedule.json entry. It tags the fire AUTONOMY_TRIGGER_KIND=dispatch (§ CRON-TRIGGERED RUNS above), so the operator still gets a full run rather than the cron self-throttle — but it carries no MODE, so it runs drift mode, never setup-completion mode. For setup-completion mode specifically (this section's actual subject), the paused-safe adapter above (with MODE=setup AUTONOMY_FORWARD=MODE) remains the right command; the distinct raw-adapter spelling makes the fence exception visible instead of weakening every declared job dispatch.

How MODE actually reaches your session on this path: run-agent.mjs forwards each env name listed in AUTONOMY_FORWARD as an opaque --key value param (--MODE setup) to the backend, and the backend re-exports launch params verbatim into the session's env (scripts/autonomy-runner.mjs's exported = { …env filtered to TERMFLEET_.*|AUTONOMY.*|PATH, …params } → export MODE="setup" in the session's setup command). The AUTONOMY_FORWARD=MODE part is load-bearing: a bare MODE=setup env var alone reaches the adapter process but is dropped by that session-env filter (MODE matches neither TERMFLEET_.* nor AUTONOMY.*), so it would never reach you.

On an UNPAUSED (already-running) install, the runner-facing launch CLI works too and is the shorter form: it forwards any --key value flag verbatim into the launched session's environment, regardless of whether that key is declared anywhere in ir.yml — this is not a proposal, it's what packages/substrate-local/src/runner-frontend.ts's launch() already does today for every skill agent: names = Object.keys(params).filter((k) => k !== 'branch') then spreads Object.fromEntries(names.map((k) => [k, String(params[k])])) straight into the child process's env (runner-frontend.ts:487-492; compiled into every install as scripts/runner.ts, same runCli/parseFlags contract, scripts/runner.ts:74-109). --ref is the one flag this file special-cases (remapped onto the target's own declared subject.ref param name, e.g. TARGET_REF); every other flag passes through untouched:

bun scripts/runner.ts launch audit --MODE setup [--ref <issue-or-PR-if-you-have-one>]

⚠️ On a paused install that command is REFUSED — [runner] PAUSED — … rm .open-autonomy/paused, exit 1 (the runner-frontend.ts:420-423 gate above). Do NOT follow that message's unpause hint to make an audit launch go through. Deleting .open-autonomy/paused is the go-live act — M5's own gate, a human triage decision this skill's rails already forbid you from touching ("No fence changes, ever", § Capabilities & rails) — and un-pausing an install in order to check whether it is complete enough to un-pause is exactly the incomplete-install-ticking failure mode this checklist exists to prevent. Use the PRIMARY run-agent adapter form above instead; it exists for precisely this state.

Either way, read the value the same way you already read TARGET_REF: echo "$MODE" (or equivalent) at the top of your run. Both channels set MODE=setup on any of the four profiles with zero IR/core changes — the same channel TARGET_REF rides, generalized to an operator-chosen key. No MODE (or MODE=drift) → drift mode (§ above) — this preserves every existing dispatch of this skill unchanged; MODE=setup is strictly additive.

On a gh-actions target, workflow_dispatch on .github/workflows/audit.yml declares exactly one input, issue_number (audit.yml:3-5) — there is no wired mode input today, and adding one is a packages/substrate-github/src/emit.ts change (compiler/Track-E territory, out of scope for this prose-only unit). Until that lands (a natural TC.3/TS follow-up), a hosted dispatch has two honest options, in order of preference: (1) if you were dispatched in-session by another agent that already controls its own environment (e.g. the future install agent, TE.5, mid-Phase-5-VALIDATE) — it can simply set MODE=setup itself before invoking this skill's checklist as a research read, the same way the § Identity preamble already sanctions "a subagent reading a doctrine file" as not a dispatch of the scheduled audit actor; (2) for a genuine workflow_dispatch/issue_comment firing with no env control, read the dispatching subject's own body for a literal MODE: setup line — .agent-run/issue.json (written by the already- wired "Provide subject" step, audit.yml:54-61/96-103) carries the target's title/body verbatim, so a throwaway issue titled or bodied with MODE: setup is a real, TODAY-readable channel, just a weaker one (it requires the operator to author that marker) — cite which of the two you used; never guess MODE from context. Absent both, hosted dispatch is drift mode.

The four checks

Run all four, in order, whenever MODE=setup. Same evidence discipline as the nine checks above: cite the file/command you actually read, mark PASS, FAIL, or N/A (citing the fact that makes it not apply) — plus, for check (c) only, the same credential-scoped honesty the drift mode's check 3 already uses (never silently PASS on an unprovable credential state, never silently treat "can't prove" as FAIL).

(a) Direction filled. Consumes TA.1's content-gate, never re-judges content yourself from scratch:

• Read the live autonomy.yml's documents.roles the same way check 1 does. If present (this install's direction_spec.mode is documents.roles — self-driving today): run (or read the freshest .agent-run/preflight.json from) bun scripts/open-autonomy-preflight.ts --root . --out .agent-run/preflight.json and inspect its checks[] for the declared vision/constitution paths:
  • a file:<path>/autonomy-ref:<path> entry with status: fail → FAIL, naming the missing file (scripts/open-autonomy-preflight.ts:141-156).
  • a content-gate:<path> entry with status: warn (the file exists but still carries the shipped REPLACE THIS marker, UNEDITED_TEMPLATE_MARKER, open-autonomy-preflight.ts:29,158-175) → FAIL for setup-completion purposes — drift mode's check 1 treats an unedited template as a live-report WARN because content quality is normally a judgment call on a running install; setup-completion is stricter, because "direction filled" is the literal thing this rung asserts, and a WARN here means it demonstrably is not. Cite the warn message verbatim.
  • neither present → PASS, citing the preflight report you read.
• If absent (direction_spec.mode is operator — simple-gh-sdlc and simple-sdlc): TA.1's content-gate does not run here (no declared role to gate) — apply the planner's own anchor doctrine instead, using the installed Planner or Draft skill as the authority: "positioning exists" means an anchor is actually readable — AGENTS.md's stated mission, docs/VISION.md if one exists, or whatever anchor document(s) this install's own doctrine names. PASS if such a document exists on disk with non-trivial content; FAIL if you find no readable positioning anywhere (the same "board would starve with nothing to self-direct from" failure check 1's operator branch already names). This is the same distinction check 1 draws between the presence sub-check (never N/A) and the self-protection sub-check (N/A on operator profiles, since documents.roles was never auto-gated for them) — setup-completion only needs the presence half.

(b) Board seeded with ≥1 draft. Deliberately not TA.2's hasDispatchableWork — that predicate answers "is there ≥1 actionable, ready, not-already-in-flight item," gated by the day-one allowlist fence and the fresh-work filter (packages/local-runner-cli/src/board-readiness.ts's header: "does this profile's board hold >=1 actionable item right now?"). A paused, pre-first-tick install by design has zero ready items — Phase 4 EXECUTE seeds drafts only and "must NOT self-promote items to ready/oa-approved" (DESIGN §Phase 4; the day-one allowlist fence is profiles/simple-sdlc/ir.yml:95-99 — policy.box.dispatch: mode: allowlist / allow_label: oa-approved; pr-139's planners "file drafts, never ready — the missing ready label IS the gate"). Running hasDispatchableWork here would report actionable: false on a correctly-seeded install and misname a PASS as a FAIL. So this check reads board state directly, at the draft rung, never through the ready-gate:

• Resolve which board this install uses the same fact-driven way check 9 does (its own setup-pack.yml maturity_signals.m4_predicate, or the identity default) — never guess.
• ztrack board: npx ztrack issue list --state draft --json identifier,state (draft is a first-class ztrack issue state — verify in the installed planning skill that new items remain draft and never self-promote to ready). ≥1 row → PASS, citing the count and one identifier. Zero rows → FAIL: "board seeded with 0 draft items."
• GitHub-issues board: a draft item is an open issue carrying no ready label (and not parked — the exact PARKED_LABELS set the board machinery itself excludes: {needs-info, human-required}, packages/local-runner-cli/src/eligibility.ts:34, imported by board-readiness.ts:56): gh issue list --state open --json number,labels --limit 100, filter out rows whose labels include ready, needs-info, or human-required. The parked exclusion matters here: an issue parked awaiting a human (human-required) or awaiting the requester (needs-info) is blocked, not seeded work — counting it as the board's one draft would let a wedged board read as seeded. ≥1 remaining row → PASS. Zero → FAIL.
• This sub-check applies to every profile (all four route through one of these two boards, same as check 9) — never N/A. Unlike (a), there is no operator/documents-role branch here: a draft is a draft regardless of where the profile's direction lives.

(c) Provision matches live protection where codeHost: github. N/A immediately when codeHost is local-git (simple-sdlc) — identical citation to check 3: no code-host protection concept exists here. Otherwise: prefer TB.2's own recorded evidence over re-probing. Read .open-autonomy/install.json (InstallRecord, packages/local-runner-cli/src/maturity.ts:126-150, INSTALL_JSON_REL) if it exists, and find the signals[] entry with id: "A13" (imm-signals.ts:422-507, "provision.json's declared required_checks == LIVE branch protection"). If found, cite it verbatim — never re-run the gh api probe A13 already ran; that would waste a call and risk a different point-in-time answer for what should be one fact:

• present: true → PASS, citing the evidence string (it already names the matched contexts).
• present: false and evidence starts with unverifiable: (A13's own hard-signal doctrine: "an unauthenticated/non-admin credential NEVER silently reads as true" — imm-signals.ts:392-402,459-466) → N/A (unverifiable), citing the evidence string. This is deliberately not FAIL: A13 could not prove the negative either (no admin token on this box, or no gh auth at all), so recording a hard FAIL here would be exactly the "silently converted into a verdict you didn't actually observe" mistake the drift mode's own OUTCOME grammar forbids. A setup-completion install with an honestly-unverifiable A13 is still reported N/A, not blocked — matching this file's own precedent that a credential gap is a distinct, non-punitive outcome, never folded into a false PASS or a false FAIL.
• present: false and evidence starts with not-applicable: (A13's own third prefix, imm-signals.ts:428-433: the source profile ships no provision.json at all, or one with no branch_protection block — reachable on a fork of a github-codeHost profile that dropped its provisioning manifest) → N/A (no prescription), citing the evidence string. There is no prescription to match live protection against, so neither PASS nor FAIL is observable — the same posture as drift-mode check 3's own "provision.json trap" (blocked-not-PASS-not-FAIL), except here A13 already recorded the fact for you.
• present: false and evidence is a proven negative (starts with protection NOT applied or names missing required check(s)) → FAIL, citing the evidence string (it already names the missing checks).
• No install.json, or no A13 entry in it → instruct the probe: run bun packages/local-runner-cli/src/index.ts maturity (or this repo's compiled oa maturity) to populate install.json first, or fall back to drift mode's own check 3 procedure (the gh api branches/<b>/protection + 404-fallback dance) directly. Record which path you took.

(d) First-tick smoke record. For a paused, pre-first-tick install, this is expected absent — recording it as a failure would contradict the whole premise of setup-completion mode ("MUST run correctly against a paused, pre-first-tick install"). Read two sources, both read-only, neither ever written by you:

• .open-autonomy/install.json's stage field (same file as check c) — a stage of M0-M4 is consistent with "no first tick yet" (the ladder is cumulative and M5 specifically requires "the fence lifted AND a real profile-agent session/fire" — maturity.ts's own M5 commentary). A stage of M5 or M6 means a first tick (or more) already happened — see below.
• .open-autonomy/runner-state/last-fire/<agent>.json (local target only; status.ts:19-36) — absent (no directory, or empty) is the expected state pre-first-tick: cite status.ts's own rationale text, "last-fire: no reconciled fire recorded yet (either \oa start` hasn't run, or nothing has been eligible yet)." (status.ts:76). On a gh-actions target there is no local last-fire file at all — the analogous evidence is the workflow's own run history (gh run list --workflow .yml`), empty for the same reason.
• Verdict: both sources showing "nothing yet" (or a stage ≤ M4) → N/A — first-tick smoke has not happened yet, which is correct for a paused, pre-first-tick install; this is not a setup blocker. If either source shows a real fire/M5+ stage, this install is no longer pre-first-tick — record PASS (a smoke record exists) and note that setup-completion mode's premise (paused, pre-first-tick) no longer strictly holds for this install; drift mode is likely the more appropriate mode going forward.

Setup-completion verdict + re-scoped drift checks

Overall verdict: setup-complete iff no check above reports FAIL — an N/A (including check (c)'s honest-unverifiable case and check (d)'s expected-absent case) is never a blocker, mirroring drift mode's own tallying (only FAIL rows are named as blockers). Setup-incomplete otherwise, naming every FAIL verbatim (never summarized away).

Drift-mode checks 6 and 9 are superseded, not merely skipped, when MODE=setup: check 6 assumes a live schedule/provider to probe (§ above, "confirm the pinned provider... is reachable with a read-only probe") — on a paused, pre-first-tick install there is nothing live to probe, and that absence is exactly what check (d) above already covers with N/A-not-FAIL semantics; do not additionally run check 6's live-probe language and report a FAIL for "provider unreachable" on an install that was never started. Check 9 assumes a ready-labeled dispatch set — check (b) above is its pre-first-tick replacement (drafts, not ready items). Checks 1–5, 7, and 8 are unaffected by mode — they inspect static structure (manifest, doctrine text, naming, misplaced content) that is equally valid to check on a paused install; run them too if you want the fuller picture, but they are not part of the four setup-completion checks above and their PASS/FAIL does not gate the setup-completion verdict.

Output (setup-completion mode)

Author a dated report at docs/audits/oa-audit-setup-<date>.md (ISO date) — a distinct filename from drift mode's oa-audit-<date>.md, so a directory listing never conflates a drift snapshot with a setup-completion checklist run. Land it exactly the way § Output above lands a drift report (same landing_mode branches, same PR-vs-branch-vs-never-merge-yourself rules — nothing about landing changes between modes). Record the per-check table (a)-(d), the overall setup-complete/incomplete verdict, and which of the two MODE channels (§ above) you were actually invoked through. End with OUTCOME: audited-setup <N pass>/<N fail>/<N n-a> — <complete|incomplete: blockers: ...> — report <PR URL or branch ref>, or OUTCOME: blocked <reason> under the same conditions § Output already defines (extended to check (c)'s "no install.json and no gh credential to probe with either" case).