@jakkrichm/create-nexus-devflow 2.0.25 → 2.0.27

package/template/.agents/skills/audit/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: audit
+description: "[devflow][B] Read-only code audit for a Blueprint project, except for the findings ledger it maintains at devflow/context/findings.md. Reviews the active feature, changed files, a selected path, or the full project through all concerns or a focused quality, security, performance, or tests lens. Use when the user runs /audit, invokes $audit, asks for a code or quality audit, security review, performance review, test quality review, dead-code or duplication check, vibe-coded project cleanup, or standards review."
+---
+
+# audit - review code quality against the project standards
+
+Where this sits in the workflow:
+
+    /implement or /autopilot  ->  [audit]  ->  fixes or /complete
+    (code exists)                 (review +    (repair quality issues
+                                   ledger)      or close the feature)
+
+`/check` proves behavior against the spec. `/doctor` checks Blueprint setup and
+workflow health. This skill checks the code itself through either a broad review
+or one focused lens: quality, security, performance, or tests.
+
+It reviews code without changing it: it never edits source files, installs
+dependencies, commits, merges, pushes, or starts product work. Its one write is
+the findings ledger at `devflow/context/findings.md` (Step 4), the durable
+record of findings and their status.
+
+## Input
+
+Treat scope and lens as separate controls. Arguments may appear in either order,
+such as `/audit security current` or `/audit src/auth tests`.
+
+Optional scope:
+
+- no scope argument: use `current` when an active feature exists, otherwise use
+  `changed` when local changes exist, otherwise use `full`
+- `current`: audit the active `current-feature.md`, every committed feature-branch
+  change from its merge base through `HEAD`, staged and unstaged changes,
+  untracked source files, and nearby code affected by the feature
+- `changed`: audit staged, unstaged, and untracked source files plus nearby code
+- `full`: audit all project-owned source, tests, and configuration while excluding
+  dependencies, generated files, build output, coverage output, caches, vendored
+  code, and minified assets unless the user explicitly includes them
+- path or directory: audit that area and the tests or callers needed to understand it
+
+Optional lens:
+
+- no lens: review all four lenses
+- `quality`: maintainability, duplication, dead code, consistency, complexity,
+  and standards drift
+- `security`: authorization, input trust, injection, data exposure, secret
+  handling, and unsafe configuration
+- `performance`: query, network, rendering, memory, payload, concurrency, and
+  unbounded-work risks
+- `tests`: missing coverage for important logic, weak assertions, skipped or
+  focused tests, poor isolation, brittle mocks, and likely flakiness
+
+`full` is always the full-project scope, not a lens. `/audit full` therefore runs
+all lenses across the full project. When only a lens is supplied, select scope
+with the normal no-scope rules. A focused pass may name one or more lenses. If
+the request names multiple lenses, review their union and report them separately.
+
+If the requested scope is unclear, pick the smallest useful scope and state it.
+If the lens is unclear, use all lenses and state that choice.
+
+## Step 1 - gather context
+
+Read:
+
+- `AGENTS.md`
+- `devflow/context/project-overview.md`
+- `devflow/context/coding-standards.md`
+- `devflow/context/current-feature.md`
+- `devflow/context/findings.md`, for existing IDs and statuses
+- `devflow/context/ai-interaction.md`
+- `devflow/build-plan.md`, when feature order matters
+- git branch and working tree status
+- relevant source files, tests, and configs for the chosen scope
+
+For `current`, resolve the comparison base without network access:
+
+1. Use a base branch declared by the active spec or project instructions.
+2. Otherwise use the locally recorded remote default branch when available.
+3. Otherwise use an existing local `main`, then `master`.
+4. Find the merge base and inspect the committed delta through `HEAD`, then add
+   staged, unstaged, and untracked work.
+5. If no reliable base exists, say so and use the active spec plus local changes.
+   Never claim that committed feature work was fully covered in that case.
+
+Do not fetch or pull to discover the base. For `full`, state the excluded paths
+before reviewing so generated or third-party code does not consume the audit.
+
+Prefer `rg` and targeted file reads. Do not dump large files into the response.
+
+## Step 2 - run available signals
+
+Use existing commands only. Do not install tools.
+
+Run or inspect only the signals relevant to the selected lens and scope:
+
+- lint and typecheck commands when declared and relevant
+- test command for the tests lens or when it directly validates a suspected risk
+- build command when the selected lens needs compilation or bundle evidence
+- existing security command for the security lens, when declared and locally runnable
+- existing performance command for the performance lens, when declared and locally runnable
+- targeted lightweight searches for the chosen lens, such as unused exports and
+  copied logic for quality, unsafe trust boundaries for security, repeated or
+  unbounded work for performance, and skipped or weak tests for tests
+
+Do not run broad checks unrelated to a focused lens. If a useful command is
+missing, report that as a gap. Do not invent a pass or claim that a focused
+review covered the other lenses.
+
+## Step 3 - review the code
+
+For all lenses, ground findings in reachable code and project-specific
+expectations. Apply only the selected lens or lenses:
+
+- **Quality:** duplicated logic, dead or unused code, unreachable paths,
+  oversized modules, abstractions that do not pay for themselves, risky missing
+  abstractions, inconsistent patterns, and drift from the standards or spec.
+- **Security:** missing authentication or authorization, client-controlled
+  ownership, injection, unsafe parsing or deserialization, sensitive-data
+  exposure, secret handling, insecure defaults, and trust-boundary mistakes.
+  Inspect existing dependency or scanner output when available, but never imply
+  that local manifest inspection is a current vulnerability scan.
+- **Performance:** N+1 queries, repeated network or database work, unnecessary
+  rendering, blocking work on hot paths, unbounded loops or collections, memory
+  growth, oversized payloads, missing pagination, and unsafe concurrency. Mark
+  hypotheses as unverified when runtime or profiling evidence is missing.
+- **Tests:** important logic without coverage when a test command exists, weak
+  assertions, tests that only mirror implementation, excessive mocking, shared
+  state, time or order dependence, skipped or focused tests, placeholder tests,
+  swallowed failures, and missing browser or integration evidence where behavior
+  crosses a real boundary. Never invent a coverage percentage.
+
+Do not nitpick harmless style differences unless they signal drift from the local
+patterns. Prefer a short list of real findings over a broad list of guesses.
+
+Do not broaden a focused pass because another category might be interesting.
+Do not report or call out non-critical concerns from omitted lenses, even as
+suggestions for a later audit. If an obvious P0 is directly encountered outside
+the selected lens, report and record it as an out-of-lens critical risk, but do
+not continue searching that other lens.
+
+If a possible secret is found, never quote its value, paste the matching source
+line, or include raw command output containing it. Report only the redacted secret
+category, file, line, risk, and remediation. Redact sensitive values from all
+audit evidence before responding.
+
+## Step 4 - update the findings ledger
+
+`devflow/context/findings.md` is the durable record of findings. Chat reports
+do not survive a context clear; the ledger does. It is the only file this skill
+writes. If it is missing (an older install), create it with a `# Findings`
+heading first.
+
+**The ledger never scopes the review.** Review the code fresh in Step 3, then
+record what the review found. Working from the open findings as a checklist and
+verifying only those is the exact failure this file exists to prevent: a repair
+can introduce a new defect that no existing entry points at.
+
+One block per finding. The header line is the machine-readable contract and must
+keep this exact shape; the prose below it is for humans and may vary:
+
+    ### F-03 [P0] open - Retained auth volumes carry the run label
+
+    **File:** ops/agent-proof/compose.yaml:86
+    **Found:** 2026-07-21 by /audit (scope: current; lens: security)
+    **Why it matters:** ...
+    **Suggested fix:** ...
+    **Resolution:**
+
+IDs are sequential within the ledger (`F-01`, `F-02`, ...), never reused and
+never renumbered while their entries live here, even after a finding closes.
+Bare IDs are scoped to the live ledger: `/complete` archives resolved entries
+under a work-item prefix (feature 12's `F-03` becomes `12/F-03`), and that
+prefixed form is the permanent reference. A later ledger that has emptied and
+reset starts at `F-01` again without colliding. Severity reuses the P0-P3
+scheme from Step 5; only P0 and P1 block `/complete`. Status is one of:
+
+| Status | Meaning | Blocks P0/P1 at /complete |
+|---|---|---|
+| `unverified` | Suspected, no confirming evidence yet | No |
+| `open` | Confirmed, not yet repaired | Yes |
+| `fixed` | Repaired, not yet re-reviewed | Yes |
+| `closed` | Repaired and re-reviewed against the new code | No |
+| `accepted` | Not fixing, by the user's explicit decision; reason recorded in Resolution | No |
+| `invalid` | Re-examination proved the finding wrong; evidence recorded in Resolution | No |
+
+After the review:
+
+- Append each new confirmed finding as `open` with the next sequential ID, one
+  past the highest ID present in the ledger (entries carried forward from
+  earlier work count; a fresh ledger starts at `F-01`).
+- Record an unverified risk worth tracking as `unverified`. It is a lead, not a
+  defect, and never gates a merge.
+- Update the entries this pass re-examined: correct the status or severity and
+  note the evidence in **Resolution**.
+- Move a `fixed` finding to `closed` only when all three hold: this pass's
+  reviewed set included the finding's file, re-examining the repaired code
+  confirmed the original defect is gone and the repair introduced no new one,
+  and the report names the finding as closed. An unrelated new finding in the
+  same file gets its own entry and does not keep the repaired one open. Never
+  close a finding implicitly.
+- Set `accepted` only on the user's explicit decision in the current session,
+  and record their reason. Never accept a finding on their behalf.
+- Set `invalid` only when re-examination shows the finding was wrong, and
+  record that evidence in **Resolution**. It is a review verdict (or the
+  user's explicit call), never a shortcut past the gate for blocked work.
+
+`fixed` blocking `/complete` is deliberate: a repair is not done when the code
+changes, it is done when a review has looked at the result. `/implement` marks
+repairs `fixed`; only a review pass moves them to `closed`.
+
+## Step 5 - report findings
+
+Lead with findings, ordered by severity, using the IDs the ledger assigned:
+
+    F-04 [P1] Title
+    File: path:line
+    Why it matters: ...
+    Suggested fix: ...
+
+Severity:
+
+- `P0` - data loss, security break, or code that cannot ship
+- `P1` - likely bug, broken contract, missing guard, or high-risk duplication
+- `P2` - maintainability issue worth fixing before the feature closes
+- `P3` - small cleanup, consistency issue, or follow-up candidate
+
+Use P0 or P1 only when a concrete code path, violated contract or security
+boundary, failing command or test, or reproducible behavior confirms the risk. If
+the evidence is incomplete, list it under `Unverified risks` with the missing
+validation instead of presenting it as a confirmed high-severity finding.
+
+If there are no findings, say that clearly for the selected lens and name any
+remaining risk or missing signal, such as "no test command declared" or
+"browser flow not audited."
+
+Then include:
+
+- ledger changes: findings added, updated, or closed this pass, by ID
+- commands run and results
+- selected scope
+- selected lens or lenses
+- base branch, merge base, and commit range for `current`, when available
+- files or directories reviewed
+- generated, third-party, or otherwise excluded paths
+- applicable standards checked
+- browser or runtime evidence inspected, when relevant
+- skipped, focused, or placeholder tests found, when the tests lens was selected
+- checks that were unavailable or could not run
+- suggested repair order
+
+For `full`, say whether coverage was complete or partial. Never label a partial
+review as a full-project audit.
+
+## Rules
+
+- The findings ledger is the only file this skill writes. Never edit, format,
+  install, commit, merge, push, or delete anything else.
+- A focused lens is not a broad audit. State what was not reviewed and never
+  imply that omitted lenses passed.
+- The ledger reports status; it never defines what the review looks at. Do not
+  turn open findings into the review checklist.
+- Never fetch, pull, or run network-backed audit tools without explicit approval.
+- Never reproduce secrets or sensitive values in findings or command output.
+- Findings first. Keep summaries short.
+- Ground every finding in a file path and line number when possible.
+- Avoid speculative rewrites. Recommend the smallest fix that removes the risk.
+- Respect existing project patterns over generic advice.
+- Do not require perfection. The goal is code that is understandable, consistent,
+  testable where it matters, and safe to keep building on.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.

package/template/.agents/skills/autopilot/SKILL.md

@@ -1,175 +1,256 @@
 ---
 name: autopilot
-description: "[Devflow] Optional explicit mode for one bounded spec/plan/implement/verify/report pass with checkpoint commits and review packet."
+description: "[devflow][B] Optional explicit Blueprint mode for one bounded spec/build/check/audit pass. It can pick or resume the current feature, write the spec when needed, create or reuse the branch, implement small steps, run build/tests/checks, create checkpoint commits after passing steps, audit changed code, repair confirmed high-severity findings, and stop with a review packet. It never completes, merges, pushes, deploys, publishes, sends, or performs destructive actions without explicit approval. Use only when the user explicitly runs /autopilot, invokes $autopilot, or directly asks for Autopilot."
 ---
 
-# autopilot - Autonomous Bounded DevFlow Loop
+# autopilot - optional Blueprint loop
 
 Where this sits in the workflow:
 
-```text
-devflow  ->  [autopilot]  ->  review packet  ->  70-release
-(where        (spec, plan,     (human review,     (package, PR,
- are we?)      build, verify,   walkthrough)       merge with approval)
-               report)
-```
+    /status  ->  [autopilot]  ->  review packet  ->  /complete
+    (where       (spec, build,      (human review,    (log, commit,
+     are we?)     check, audit)      fixes if needed)  merge with approval)
 
-Autopilot is an explicit opt-in execution skill for Nexus-DevFlow 2.0. It runs a single bounded loop across the delivery lifecycle (**`20-spec` -> `30-plan` -> `40-execute` -> `50-verify` -> `60-report`**) without requiring human confirmation between every sub-step.
+Autopilot is an explicit opt-in path. It uses the same Blueprint files and the
+same quality gates, but it does not stop after every normal review point. A
+single user request is permission to run one bounded loop until the feature is
+ready for review, blocked, or unsafe to continue.
 
-It does **not** replace the normal step-by-step workflow. Mainline commands (`20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`) remain the conservative default.
+It does **not** replace the normal workflow. `/feature`, `/implement`, `/check`,
+and `/complete` remain the conservative default.
 
-Do not suggest Autopilot as the default next action. Use it only when the user explicitly asks for it.
+Do not suggest Autopilot as the default next action. Use it only when the user
+explicitly asks for it.
 
-The explicit Autopilot request is permission to create checkpoint commits on the feature or fix branch after passing implementation steps. It is **not** permission to merge into `main`, push to remote, deploy, publish, delete data, or run destructive actions.
+The explicit Autopilot request is permission to create checkpoint commits on the
+feature or fix branch after passing implementation steps. It is not permission to
+merge, push, deploy, publish, send, delete data, or run destructive actions.
 
 ## Input
 
 Common forms:
 
-- **No argument**: resume the active run in `devflow/context/current-stage.md`, or target the next planned run/feature in `devflow/context/project-overview.md`.
-- **Running ID or feature name**: target that run, e.g. `autopilot RUN-004` or `autopilot "add user authentication"`.
-- **`fix "<issue>"`**: write and execute an ad-hoc fix run.
-- **`resume`**: continue the current active run on its existing branch.
+- No argument: resume the current feature if one exists, otherwise target the next
+  unchecked build-plan item.
+- A number or name: target that build-plan feature, for example `/autopilot 3` or
+  `$autopilot "directory listing"`.
+- `fix "<issue>"`: write and build an ad-hoc fix spec.
+- `resume`: continue the current feature on its existing branch.
 
-If the requested target conflicts with a run already in progress, stop and ask which one should win. Do not overwrite active stage artifacts silently.
+If the requested target conflicts with a feature already in progress, stop and
+ask which one should win. Do not overwrite `devflow/context/current-feature.md`
+silently.
 
-> [!IMPORTANT]
-> Rollback is intentionally excluded from Autopilot. If the request is a rollback or the stage is marked Rollback, stop and direct the user to `rollback` and reviewed `40-execute`. Reversing completed work requires explicit dependency and human review gates.
+Rollback is intentionally excluded from Autopilot. If the request is a rollback
+or `current-feature.md` is marked `Type: Rollback`, stop and direct the user to
+the reviewed `/implement` path. Reversing completed work requires the explicit
+dependency and conflict gates in `/rollback` and `/implement`.
 
----
-
-## Step 1 - Preflight & Safety Check
+## Step 1 - preflight like /status
 
-Read the project state:
+Read the same state `/status` reads:
 
-- `AGENTS.md` & `CLAUDE.md`
+- `AGENTS.md`
+- `devflow/project-plan.md`
+- `devflow/build-plan.md`
 - `devflow/context/project-overview.md`
-- `devflow/context/current-stage.md`
+- `devflow/context/current-feature.md`
+- `devflow/context/findings.md`
 - `devflow/context/coding-standards.md`
 - `devflow/context/ai-interaction.md`
-- `devflow/context/findings.md`
 - git branch, status, and recent log
 
-Stop before changing files when:
-
-1. The repo is not a git repository.
-2. The working tree is dirty with uncommitted changes unrelated to this run.
-3. `current-stage.md` has an active run and the user requested a different target without resolving conflict.
-4. The task requires architectural, financial, auth, billing, or destructive decisions not documented in the context.
-
----
-
-## Step 2 - Choose or Write Specification (`20-spec`)
-
-1. If `devflow/runs/{running-id}-{slug}20-spec.md` already exists, resume it.
-2. If no spec exists:
-   - Ensure `10-define.md` exists with locked scope and allocated Running ID.
-   - Write `20-spec.md` following the DevFlow specification schema.
-   - Critique and red-team the spec (edge cases, unhappy paths, testable criteria).
-   - Apply fixes to the spec.
-
----
-
-## Step 3 - Branch Setup & Implementation Plan (`30-plan`)
-
-1. **Branch Management**:
-   - Feature: `feature/{slug}-{running-id}`
-   - Fix: `fix/{slug}-{running-id}`
-   - Switch to or create the working branch. Never run Autopilot directly on `main` or `master`.
-2. **Planning**:
-   - Write `devflow/runs/{running-id}-{slug}30-plan.md`.
-   - Seed `checklists/implementation-checklist.md` and `checklists/verification-checklist.md`.
-
----
-
-## Step 4 - Implement in Small Increments (`40-execute`)
-
-Work through the implementation checklist in order. Each step must remain reviewable.
-
-For every subtask:
-
-1. Implement only that scoped unit.
-2. Run relevant verification (unit tests, typecheck, lint, build).
-3. If UI is involved, inspect behavior, verify console errors and network calls.
-4. Self-review diff against `coding-standards.md`.
-5. Fix issues and rerun failed checks.
-6. Mark the task checked `[x]` in `checklists/implementation-checklist.md`.
-7. **Create a Checkpoint Commit** on the feature/fix branch for the passing step:
-   ```bash
-   git add <modified-files> devflow/runs/{running-id}-{slug}/checklists/implementation-checklist.md
-   git commit -m "feat({running-id}): checkpoint <concise step description>"
-   ```
-8. Write `devflow/runs/{running-id}-{slug}40-execute.md`.
-
----
-
-## Step 5 - Senior QA Verification (`50-verify`)
+Then decide whether it is safe to run.
 
-1. Execute full project verification commands:
-   - Framework integrity (`npm run check` or equivalent)
-   - Static contracts (`npm run check:static` when applicable)
-   - Project test suite (Unit tests, integration tests)
-   - Build / Package smoke tests
-2. Update `checklists/verification-checklist.md` with concrete evidence.
-3. Write `devflow/runs/{running-id}-{slug}50-verify.md` with QA verdict (`PASS` / `FAIL`).
-
----
-
-## Step 6 - Targeted Quality Audit & Repair
-
-Review diffs and inspect `devflow/context/findings.md`:
-
-1. **Repair confirmed P0 and P1 findings** within the current run scope.
-2. Update finding status in `devflow/context/findings.md`.
-3. Rerun verification tests after repairs.
-4. Create a checkpoint commit for the fix.
-5. If a P0/P1 finding cannot be repaired within scope or fails twice consecutively, stop immediately and report.
-
----
-
-## Step 7 - Delivery Digest & Review Packet (`60-report`)
-
-1. Write `devflow/runs/{running-id}-{slug}60-report.md`.
-2. Render standalone HTML dashboard `devflow/runs/{running-id}-{slug}60-report.html` (via `md2html` or report generator).
-3. Update `devflow/context/current-stage.md` to indicate ready for `70-release`.
-4. Stop with a concise **Review Packet Dashboard** for human approval.
-
----
-
-## 🛑 Strict Hard Stops (Never Exceed)
-
-Stop immediately and report to the user instead of continuing when Autopilot would need to:
-
-- Commit directly to `main` or `master`, merge branches, delete branches, or force push.
-- Run `git push` to remote repositories.
-- Deploy to staging/production or publish packages to npm/registries.
-- Delete data, drop databases, or run irreversible destructive migrations.
-- Make product, business, or architecture decisions not specified in the context.
-- Continue after two failed attempts to fix the same issue (Two-attempt hard stop).
-
----
-
-## Output Review Packet Format
-
-When Autopilot finishes successfully, output a scannable review packet:
-
-```markdown
-### 🛸 Autopilot Execution Summary: [{running-id}]
-
-- **Branch**: `{branch-name}`
-- **Target Run**: `{running-id} - {title}`
-- **Artifacts Generated**:
-  - Spec: `devflow/runs/{id}20-spec.md`
-  - Plan: `devflow/runs/{id}30-plan.md`
-  - Implement Evidence: `devflow/runs/{id}40-execute.md`
-  - QA Verify Report: `devflow/runs/{id}50-verify.md`
-  - Digest Report: `devflow/runs/{id}60-report.md`
-  - HTML Dashboard: `devflow/runs/{id}60-report.html`
-- **Validation & Tests**: `All Passed (Green)`
-- **Checkpoint Commits**: `{count} commits created on {branch-name}`
-- **Manual QA Walkthrough**: Run `try {running-id}` for human review guide
+Stop before changing files when:
 
----
-👉 **Next Recommended Action**:
-Inspect diffs and `try` walkthrough, then run `70-release {running-id}` to package, merge, or create PR.
-```
+- The repo is not a git repo.
+- The working tree is dirty and there is no current feature tying those changes
+  to this run.
+- `current-feature.md` has real work and the user requested a different target.
+- `project-overview.md` is missing or stale and the planning docs are not clear
+  enough to regenerate it.
+- The next feature is visual or replication-heavy and no design reference exists.
+- The task needs product, data, auth, billing, or destructive decisions the docs
+  do not answer.
+
+If the only issue is that `project-overview.md` is stale and the plans are clear,
+regenerate it using the `/overview` behavior and continue. Include that in the
+final packet.
+
+## Step 2 - choose or write the spec
+
+If `devflow/context/current-feature.md` already contains an active spec,
+resume it. Read checked steps and continue from the first unchecked step.
+
+If there is no active spec:
+
+1. Use the `/feature` behavior for a planned feature, or `/fix` behavior for a
+   requested fix.
+2. Write `devflow/context/current-feature.md`.
+3. Red-team the spec before building:
+   - missing unhappy paths
+   - oversized steps
+   - undefined contracts
+   - missing design reference
+   - scope creep
+   - vague done-whens
+   - missing testing plan when `AGENTS.md` declares a test command
+4. Apply the spec fixes.
+
+Autopilot may continue past this spec gate because the user explicitly invoked
+Autopilot. Still report what the critique changed in the final packet.
+
+## Step 3 - create or reuse the branch
+
+Use the same branch rules as `/implement`:
+
+- Feature: `feature/<name>`
+- Fix: `fix/<name>`
+
+If the branch already exists, switch to it only if it matches the active spec.
+If switching branches would strand unrelated dirty work, stop and report the
+problem.
+
+## Step 4 - implement in small steps
+
+Work through the spec's build steps in order. Each step must remain reviewable.
+Unlike `/implement`, do not pause for user approval after each passing step. The
+review happens at the final packet unless a hard stop is hit.
+
+For every step:
+
+1. Implement only that step.
+2. Run the relevant verification:
+   - the exact `Verify` command from `AGENTS.md`, when declared
+   - otherwise the build, relevant test, lint, and typecheck commands already
+     documented by the project
+   - browser, CLI, API, or app-level evidence for behavioral done-whens
+3. If UI is involved, inspect the running app when possible. Prefer Playwright if
+   it is already installed or declared. Capture screenshots when they add useful
+   evidence. Check for console errors and failed requests.
+4. Self-review the diff for the step:
+   - does it match the spec?
+   - did it add scope?
+   - is the error path handled?
+   - did it follow `coding-standards.md`?
+   - are tests present for new in-scope logic when the test gate is on?
+5. Fix obvious issues and rerun the failed checks.
+6. Mark the step checked in `current-feature.md` only after the step passes.
+7. Create a checkpoint commit on the feature or fix branch for the passing step.
+   Include the code, tests, and the updated `current-feature.md` checkbox. Use a
+   conventional message such as `feat: checkpoint mock snapshot route` or
+   `fix: checkpoint stale service filter`. Keep the message about the step, not
+   about Autopilot.
+
+Do not batch the whole feature into one large diff. If a step gets too large,
+split the step in `current-feature.md` and continue with the first smaller step.
+
+## Step 5 - acceptance check
+
+After all implementation steps are checked, run the `/check` behavior for the
+feature when any done-when is behavioral, visual, or integration-facing.
+
+For pure library or CLI work, build plus tests and representative command output
+may be enough. Be explicit about the evidence used.
+
+## Step 6 - targeted quality audit and repair
+
+After the acceptance check, apply the `/audit current` behavior to the active
+feature, its diff, and the nearby code affected by the change. This is a targeted
+feature audit, not a repository-wide cleanup pass. Findings are recorded in
+`devflow/context/findings.md` with durable IDs and statuses, as `/audit`
+defines; the ledger reports status and never scopes what the audit examines.
+
+For every finding:
+
+1. Validate it against the actual code, spec, tests, `coding-standards.md`, and
+   local project patterns. An audit finding is evidence to investigate, not an
+   automatic instruction to edit.
+2. Repair confirmed P0 and P1 findings when the fix stays inside the approved
+   feature scope and does not require a product or architecture decision. Set
+   the repaired finding to `fixed` in the ledger, never `closed`.
+3. Report P2 and P3 findings in the final packet. Fix them only when the change
+   is small, directly caused by the current feature, and clearly required by the
+   project standards.
+4. If a confirmed P0 or P1 finding cannot be repaired safely within scope, stop
+   and report it. Do not present the feature as ready for `/complete`.
+
+After any audit repair:
+
+1. Rerun the documented `Verify` command when present; otherwise rerun the
+   affected build, lint, typecheck, and test commands.
+2. Rerun the acceptance evidence affected by the repair.
+3. Recheck the repaired area using the same targeted audit criteria. When that
+   recheck confirms the original defect is gone and the repair introduced no
+   new one, move the `fixed` finding to `closed` under the `/audit` close
+   conditions and name it in the packet. An unrelated new finding gets its own
+   ledger entry and does not keep the repaired one open.
+4. Create a checkpoint commit only after the repair and its checks pass.
+
+Use the existing two-attempt hard stop for repeated repair failures. Do not widen
+the feature into a general refactor, silently suppress a finding, or turn this
+step into a full-project hardening pass. A broader cleanup remains a separate
+`/audit` followed by planned `/fix` work.
+
+## Step 7 - final review packet
+
+Stop with a concise review packet. Keep it useful enough for `/complete` but not
+a full audit report:
+
+- branch name
+- target feature or fix
+- whether the spec was created or resumed
+- what the spec critique changed
+- changed files and why each changed
+- build/test/check commands run, with pass or fail
+- screenshots or output paths, when relevant
+- how to try it manually, or a pointer to `/try` for the full walkthrough
+- checkpoint commits created
+- self-review findings
+- targeted audit scope and findings
+- audit repairs made and checks rerun
+- P0/P1 findings still `open` or `fixed` in `devflow/context/findings.md`,
+  which block `/complete`
+- unresolved risks or skipped checks
+- exact next action
+
+If everything is green, the next action is usually: review the diff, then run
+`/try` if you want a manual walkthrough, then `/complete`.
+
+If something failed, name the failing check and the next fix target.
+
+## Hard Stops
+
+Stop immediately and report instead of continuing when Autopilot would need to:
+
+- commit on `main`, merge, delete a branch, push, deploy, publish, or send
+  anything
+- delete data, reset a database, run irreversible migrations, kill processes, or
+  change system settings
+- install dependencies or use network access without the current tool's approval
+  flow
+- make a product decision not covered by the docs
+- continue after two failed fix attempts on the same issue
+- hide, skip, or hand-wave a failing check
+
+## Rules
+
+- One Autopilot run handles one feature or one fix.
+- Autopilot creates checkpoint commits on the feature or fix branch after passing
+  steps.
+- Autopilot audits the active feature and affected code, not the entire project.
+- A P0 or P1 finding left `open` or `fixed` in `devflow/context/findings.md`
+  blocks readiness for `/complete`. The ledger is what makes this enforceable.
+- Autopilot stops before `/complete`. It never merges.
+- The Blueprint files remain the state machine. Keep
+  `current-feature.md` accurate as steps complete.
+- Follow `coding-standards.md`, `ai-interaction.md`, and `AGENTS.md`.
+- Prefer fewer, higher-quality changes over broad coverage.
+- Report uncertainty plainly. A blocked run is useful if it tells the truth.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.