@jakkrichm/create-nexus-devflow 2.9.5 → 2.10.1

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

@@ -44,6 +44,26 @@ the visual target - build components to match them, and treat `prototypes/theme.
 as the token source (the spec's first step ports it into the app's global
 stylesheet before the components are built).
 
+### Quality-gate and browser preflight
+
+Read `devflow/config.json` and the target spec's recorded decision for
+`qualityGates.regular.independentReview`. `manual` does not activate an
+automatic gate, `always` does, and `when-sensitive` follows the sensitivity
+decision and evidence captured by `/feature` or `/fix`. Stop for a spec repair
+instead of guessing when a conditional decision is missing.
+
+Treat any product or living-spec edit in this build as invalidating an earlier
+receipt. After the final Verify pass, an active gate routes to
+`audit independent current`; only a fresh receipt with `passed` verdict and
+`current` freshness may proceed toward `/complete`. This skill never approves
+its own work or rewrites receipt evidence.
+
+For a browser-facing step, run `npm run test:browser` when the script exists and
+record the result in the step evidence. Use `browseros-neo` for the interactive
+handoff when it is available and the done-when is visual or behavioral. When the
+script or MCP is absent, report that exact limitation; do not silently install a
+runner or claim browser evidence.
+
 **Resuming?** If the spec already has some build steps checked off (`- [x]`), this
 feature was started earlier and interrupted (often a cleared context). The spec and
 its ticked steps are files, so pick up where it left off: read which steps are done,
@@ -217,4 +237,4 @@ approval. This skill does not touch main.
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -133,6 +133,22 @@ If no changes are needed, say so.
 
 ## Step 5 - point to optional CI setup
 
+Before the CI handoff, read `devflow/config.json` and report the effective
+`qualityGates.regular.independentReview` onboarding default. Preserve an
+existing valid user choice. Explain that `manual` is opt-in, `always` requires a
+fresh receipt for every regular run, and `when-sensitive` activates for work
+touching authentication, authorization, secrets, payments, personal data,
+destructive operations, dependencies, deployment, or another security boundary.
+Onboarding has no active task to review, so it must not create `review.md` or
+claim a verdict; when the future gate activates, the handoff is
+`audit independent current` after final implementation and verification.
+
+Detect browser capability without installing anything. If the project already
+declares `test:browser`, record `npm run test:browser` in the onboarding report.
+Also report whether `browseros-neo` is available for interactive UI evidence.
+When a browser-facing project lacks either capability, point to `/browser-tests`
+as an optional setup route and describe the gap honestly.
+
 Do not create or change Verify commands or GitHub workflows during onboarding.
 Report any verification command or CI already present. When equivalent automatic
 pull-request checks are absent, mention the optional standalone setup:
@@ -261,4 +277,4 @@ $overview
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

package/template/.agents/skills/{tests → setup-tests}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: tests
-description: "[devflow] Add or normalize unit testing for a Blueprint project. Detects the stack, reuses an existing test runner when present, or installs the stack-native unit test runner when missing, then adds one small example test, updates AGENTS.md commands, runs build and tests, and reports the diff. Use when the user runs /tests, invokes $tests, asks to add unit tests, set up unit testing, configure tests, or make tests part of the Blueprint workflow."
+name: setup-tests
+description: "[devflow] Add or normalize unit testing for a Blueprint project. Detects the stack, reuses an existing test runner when present, or installs the stack-native unit test runner when missing, then adds one small example test, updates AGENTS.md commands, runs build and tests, and reports the diff. Use when the user runs /setup-tests, invokes $setup-tests, asks to add unit tests, set up unit testing, configure tests, or make tests part of the Blueprint workflow."
 ---
 
-# tests - add unit testing to the project
+# setup-tests - add unit testing to the project
 
 **First action:** Before project inspection, preflight, or any other tool call,
 publish `running` to `devflow/.state/run.json` using the dashboard activity
@@ -11,13 +11,13 @@ contract in `AGENTS.md`.
 
 Where this sits in the workflow:
 
-    any time  ->  [tests]  ->  test command in AGENTS.md  ->  /feature + /implement use it
-                  (setup)     (the opt-in testing gate)      (logic steps get tests)
+    any time  ->  [setup-tests]  ->  test command in AGENTS.md  ->  /feature + /implement use it
+                  (setup)            (the opt-in testing gate)      (logic steps get tests)
 
 Testing is optional in the Blueprint until the project declares a real test
 command in `AGENTS.md`. This skill is the explicit setup path. It adds or
 normalizes **unit testing** only; browser automation and end-to-end testing are
-separate setup work.
+separate optional setup through `/browser-tests`.
 
 ## Input
 
@@ -71,7 +71,7 @@ Apply the smallest practical diff:
    when available, the test watch command.
 5. If a `Verify` command already exists, add the real test command to it between
    typecheck and build while preserving any established project checks. Do not
-   create verification or CI only because `/tests` was invoked.
+   create verification or CI only because `/setup-tests` was invoked.
 6. Update `devflow/context/coding-standards.md` only if the project needs a
    stack-specific testing note different from the default.
 
@@ -127,4 +127,4 @@ Show the diff summary. Do not commit, merge, push, or start product feature work
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -58,6 +58,17 @@ state.
 8. **Onboarding check** - Before recommending `/overview`, check whether `AGENTS.md`
    still contains the `<!-- devflow:onboarding-required -->` marker or standard template commands.
    When it does, onboarding is incomplete and `/onboard` is the next action.
+9. **Independent review and browser evidence** - read
+   `qualityGates.regular.independentReview` from `devflow/config.json` and the
+   recorded sensitivity decision for `when-sensitive`. For every active run,
+   report the `review.md` state, verdict, freshness, check result, warnings, and
+   whether the effective gate is satisfied. An active gate with a missing,
+   pending, malformed, changes-requested, or stale receipt routes to
+   `audit independent current`, never `/complete`. Also report whether the spec
+   requires browser proof, whether `npm run test:browser` is declared and has
+   recorded evidence, and whether an interactive `browseros-neo` handoff is
+   available or explicitly unavailable. This remains read-only: do not execute
+   either browser path from `/status`.
 
 ## Output
 
@@ -106,4 +117,4 @@ drift is half the value of the command.
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -1,10 +1,13 @@
 ---
 name: try
-description: "[devflow] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
+description: "[devflow] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, connects with MCP browseros-neo when available for interactive previews, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
+argument-hint: "[{latest|step-id|path}]"
 ---
 
 # try - manual review guide
 
+$ARGUMENTS
+
 Where this sits in the workflow:
 
     /implement or /complete  ->  [try]  ->  human review
@@ -58,7 +61,7 @@ include one unaffected regression path from the rollback spec.
 
 Use the Commands section in `AGENTS.md`. Match the project type:
 
-- **Web app** - dev server command, URL, and the route or screen to open.
+- **Web app** - dev server command, URL, and the route or screen to open. If `browseros-neo` MCP server is active (`http://127.0.0.1:9010/mcp`), you can also offer to inspect or navigate in the live browser.
 - **Server/API** - server command, base URL, endpoint, method, and expected
   response shape.
 - **CLI** - exact command(s), arguments, and expected output.
@@ -77,9 +80,9 @@ Produce a short guide with these sections:
 2. **Open** - URLs, screens, tabs, API endpoints, or CLI commands.
 3. **Do** - clicks, inputs, selections, or command arguments.
 4. **Expect** - visible result, output, response, state change, file, or lack of
-   error.
+    error.
 5. **Watch For** - common wrong outcomes, console or network errors, stale data,
-   missing fields, bad empty states, layout issues, or safety warnings.
+    missing fields, bad empty states, layout issues, or safety warnings.
 
 Keep it concrete. Prefer:
 
@@ -97,23 +100,5 @@ End with:
 
 - **Best signal** - the one thing the user should try first.
 - **Optional deeper checks** - only if useful.
-- **Gaps** - anything the guide cannot know from the docs, such as missing route
-  names, seed data, credentials, or external services.
-
-If the feature is not user-visible, say so and provide the closest manual signal,
-such as an API response, CLI output, log line, or unit test command.
-
-## Rules
-
-- Read-only only. Do not edit, commit, merge, push, install, or delete.
-- Do not run the app unless the user explicitly asks you to try it for them.
-- Do not pretend a path is known when the spec does not say it. Give the best
-  likely path and label uncertainty.
-- Keep the guide short enough to follow while the app is open.
-- Match the project's commands from `AGENTS.md`.
-
-## Formatting
-
-Format the output to match the project's conventions in
-`devflow/context/ai-interaction.md`: concise, scannable markdown, with numbered
-steps for the manual path and short bullets for warnings.
+- **MCP Visual Preview** - mention live browser inspection via MCP `browseros-neo` if active.
+- **Gaps** - anything the guide cannot know from the docs, such as missing route or seed data.

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

@@ -1,10 +1,13 @@
 ---
 name: audit
-description: "[devflow] Read-only code audit for a Blueprint project, except for the findings ledger it maintains at devflow/context/{xxx-slug}/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."
+description: "[devflow] Read-only code audit for a Blueprint project, except for the findings ledger it maintains at devflow/context/{xxx-slug}/findings.md and the optional independent-review request or receipt at devflow/context/{xxx-slug}/review.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. Independent mode hands an immutable checkpoint to a selected fresh reviewer session and records a freshness-bound receipt. Use when the user runs /audit, invokes $audit, asks for an independent review, code or quality audit, security review, performance review, test quality review, dead-code or duplication check, vibe-coded project cleanup, or standards review."
+argument-hint: "[{current|changed|full|path}] [{quality|security|performance|tests}] [independent]"
 ---
 
 # audit - review code quality against the project standards
 
+$ARGUMENTS
+
 **First action:** Before project inspection, preflight, or any other tool call,
 publish `running` to `devflow/.state/run.json` using the dashboard activity
 contract in `AGENTS.md`.
@@ -20,9 +23,20 @@ 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/{xxx-slug}/findings.md` (Step 4), the durable
-record of findings and their status.
+dependencies, commits, merges, pushes, or starts product work. A normal audit's
+one write is the findings ledger at `devflow/context/{xxx-slug}/findings.md` (Step 4),
+the durable record of findings and their status. Independent mode may also
+write `devflow/context/{xxx-slug}/review.md` using the exact record contract in
+`reference/independent-review.md`.
+
+The quality-gate config controls when another workflow invokes this skill
+automatically. An explicit `/audit` or `$audit` request always selects the audit
+regardless of whether the applicable gate is `manual`, conditional, or `always`.
+A selected `independentReview` gate invokes independent mode instead of letting
+the builder satisfy its own review. When both audit and independent review are
+selected, one passing independent review satisfies the audit gate.
+A missing config means built-in defaults. If it exists but is invalid, stop and
+point to `/doctor` before writing the findings ledger.
 
 ## Input
 
@@ -62,15 +76,99 @@ 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.
 
+Optional review mode:
+
+- `independent`: prepare or complete an independent review of `current` across
+  all four lenses. It cannot be combined with `changed`, `full`, a path scope,
+  or a focused lens because a completion receipt must cover the whole active
+  work item.
+
+## Independent mode
+
+`/audit independent current` is a two-session workflow. The builder session
+prepares a request. The selected fresh reviewer session runs the same command
+to complete it. DevFlow verifies the exact target and later staleness. The
+adapter, model, and fresh-session identity remain declared metadata.
+
+Read `reference/independent-review.md` before either phase.
+
+### Phase A - prepare the handoff
+
+Use this phase when `devflow/context/{xxx-slug}/review.md` has no current `pending`
+request for `HEAD` and the current spec hash.
+
+1. Require an active spec with every build step checked and status `verified`, a
+   non-default work branch, a reliable merge base, and a clean working tree.
+   Independent mode accepts only a locally recorded remote default branch,
+   local `main`, or local `master` as its enforceable base ref. Stop when none
+   reliably covers the active work.
+   The current full `HEAD` must be the approved review checkpoint, including the
+   verified spec. Never create that commit inside Audit. If work is dirty, stop
+   and ask the user to approve a review checkpoint through `/implement`, even
+   when normal checkpoint commits are disabled.
+2. Read installed adapters from `.nexus/nexus-devflow.json` or manifest when valid.
+   Detect `.agents/skills` as `antigravity`/`codex`/`copilot` and `.claude/skills`
+   as `claude`.
+3. Ask which detected adapter and available model should review. Recommend an
+   equal-or-stronger coding model, a different model family when practical, and
+   high reasoning for sensitive work. Offer a fresh session in the current
+   adapter as the fallback.
+4. Record the full target SHA, full merge-base SHA, the exact local base ref
+   used to calculate it, exact spec SHA-256, current adapter and model,
+   requested reviewer adapter and model, workflow, and
+   whether the configured Check gate is required. Write the pending template
+   into `devflow/context/{xxx-slug}/review.md`.
+5. Set dashboard activity to `ready` and give the exact handoff command for the
+   selected adapter. Claude Code uses `/audit independent current`; Google Antigravity uses
+   `/audit independent current`; Codex uses `$audit independent current`. Tell
+   the user to open a fresh session with only the handoff, not the builder chat.
+
+Stop after the handoff. The builder never continues into Phase B in the same
+session.
+
+### Phase B - perform the review
+
+Use this phase when a current pending request exists in `devflow/context/{xxx-slug}/review.md`.
+
+1. Confirm the current adapter matches `Requested reviewer`, the current model
+   matches `Requested model` unless the runtime-default sentinel was selected,
+   `HEAD` matches `Target commit`, the recorded base ref still produces the
+   recorded merge base, the exact spec hash matches, and no path differs from
+   the target except `devflow/context/{xxx-slug}/review.md` and
+   `devflow/context/{xxx-slug}/findings.md`. Stop on any mismatch or stale state.
+2. Proceed only from the fresh reviewer handoff. Record `fresh session` as a
+   declaration. If the reviewer has the builder conversation, stop and request a fresh session.
+3. Run Steps 1 through 3 across `current` with quality, security, performance,
+   and tests together. Review the code fresh against the recorded
+   `Base commit` and `Target commit`; exclude the request and findings files
+   from the code scope. Existing findings are context, never the review
+   checklist.
+4. Run `/check` from the reviewer session when the request says Check is
+   required. Follow Check's server and evidence boundaries. A required check
+   that cannot run prevents a passing receipt.
+5. Update the findings ledger through Step 4, then replace the pending request
+   with a completed receipt in `devflow/context/{xxx-slug}/review.md`. Use `passed` only when the whole target was
+   reviewed, required checks passed, and no P0 or P1 finding is `open` or
+   `fixed`.
+6. Report the receipt target, reviewer adapter and model, commands, evidence,
+   findings, remaining risk, and whether the receipt passed. Never repair code
+   from the reviewer session.
+
+After changes are requested, the builder repairs through `/implement`, obtains
+approval for a new checkpoint, and prepares a new request. The next reviewer
+pass reviews the complete new delta, not only the old findings.
+
 ## Step 1 - gather context
 
 Read:
 
 - `AGENTS.md`
+- `devflow/config.json`
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
 - `devflow/context/{xxx-slug}/spec.md` (when a task is active)
 - `devflow/context/{xxx-slug}/findings.md` (or existing ledger), for existing IDs and statuses
+- `devflow/context/{xxx-slug}/review.md`, for independent request and receipt state
 - `devflow/context/ai-interaction.md`
 - `devflow/build-plan.md`, when feature order matters
 - git branch and working tree status
@@ -137,143 +235,20 @@ Do not nitpick harmless style differences unless they signal drift from the loca
 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/{xxx-slug}/findings.md` is the durable record of findings for the active task. Chat reports
-do not survive a context clear; the ledger does. It is the only file this skill
-writes. If it is missing, 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.
+If a critical security or data-loss issue surfaces during a quality, performance,
+or test review, report that one blocker plainly under Security and continue with
+the chosen lens.
+
+## Step 4 - record and report findings
+
+Maintain the durable record in `devflow/context/{xxx-slug}/findings.md` (or `devflow/context/findings.md`):
+
+1. Read existing IDs to avoid collisions.
+2. Use sequential IDs with the lens prefix: `Q-001`, `S-001`, `P-001`, `T-001`.
+3. Set severity honestly:
+   - `P0`: critical blocking bug, data corruption, severe vulnerability, complete outage.
+   - `P1`: serious defect, missing critical test, unhandled core error.
+   - `P2`: moderate debt, performance degradation, missing edge cases.
+   - `P3`: minor improvement, code cleanup, cosmetic tweak.
+4. Set status: `open`, `fixed`, `closed`, `accepted`, or `invalid`.
+5. Display concise findings summary and next actions.

package/template/.claude/skills/audit/reference/independent-review.md

@@ -0,0 +1,128 @@
+# Independent review record
+
+`devflow/context/{xxx-slug}/review.md` holds one active request or latest receipt for the
+current work item. It is generated workflow state that is committed with the
+work, archived by `/complete`, and then reset.
+
+## Reset stub
+
+```markdown
+# Independent Review
+
+> **Generated file.** Holds the active independent-review request or latest
+> receipt for the current work item. `/audit independent current` prepares a
+> handoff against an approved checkpoint, a fresh reviewer session completes it,
+> and `/complete` refuses stale, pending, or changes-requested review state.
+
+_No independent review requested. Run `/audit independent current` to prepare one._
+```
+
+## Pending request
+
+Use full commit SHAs, the exact permitted base ref used to calculate the merge base,
+a lowercase SHA-256 hash of the exact
+`devflow/context/{xxx-slug}/spec.md` bytes, an ISO-8601 timestamp, and one of
+`antigravity`, `claude`, `codex`, `copilot`, or `opencode` for each adapter field.
+Model fields use the full identifier exposed by runtime or session metadata,
+not a generic family label. When unavailable, record
+`unknown (runtime did not expose exact model)` instead of guessing. When the
+review runtime cannot select a specific model before the session starts, use
+`runtime default (exact model not known until reviewer starts)` for Requested
+model and record the exact runtime model in the completed receipt.
+
+```markdown
+# Independent Review
+
+**Status:** pending
+**Target commit:** <full 40-character checkpoint SHA>
+**Base commit:** <full 40-character merge-base SHA>
+**Base ref:** <local branch or remote-tracking ref used for the merge base>
+**Spec hash:** <64-character SHA-256>
+**Prepared by:** <adapter>
+**Builder model:** <exact model reported by the builder runtime>
+**Requested reviewer:** <adapter>
+**Requested model:** <exact model or user-selected runtime default>
+**Requested at:** <ISO-8601 timestamp>
+**Workflow:** <regular or continuous>
+**Check required:** <yes or no>
+
+## Handoff
+
+Review the active spec and the complete `<base>..<target>` delta in a fresh
+session without the builder conversation. Run all Audit lenses from scratch.
+Run Check when required above. Do not edit product code, accept findings, or
+reuse the existing findings as the review scope.
+```
+
+For an independently enforceable receipt, `Base ref` must be a locally recorded
+remote default branch, local `main`, or local `master`. It cannot be the current
+work branch, and `Base commit` cannot equal `Target commit`. If none of those
+base refs reliably covers the active work, stop instead of creating a receipt
+whose review range cannot be re-derived.
+
+## Completed receipt
+
+Keep the request fields unchanged and replace `pending` with `passed` or
+`changes-requested`. Add these fields and sections:
+
+```markdown
+**Reviewer adapter:** <adapter>
+**Reviewer model:** <exact model reported by the reviewer runtime>
+**Reviewer context:** fresh session
+**Reviewed at:** <ISO-8601 timestamp>
+**Scope:** current
+**Lenses:** quality, security, performance, tests
+**Verdict:** <passed or changes-requested>
+**Check result:** <passed, failed, unavailable, or not-required>
+
+## Commands
+
+- `<command>`: <pass, fail, or unavailable>
+
+## Evidence
+
+- <safe concise evidence reference>
+
+## Findings
+
+- <finding IDs, or `None`>
+
+## Remaining risk
+
+- <risk or unavailable signal, or `None identified`>
+```
+
+Every unavailable verification command must appear under Remaining risk, even
+when Check was not required and the receipt may still pass.
+
+All four completed-receipt sections must contain at least one entry. Use
+`- None`, `- None identified`, or `- No commands run` when that is the truthful
+result. When Check is required, `Check result` must be `passed` before the
+receipt can pass. Use `not-required` only when Check was not required.
+
+Use `passed` only when all four lenses covered the complete target delta, every
+required check passed, and no P0 or P1 finding is `open` or `fixed`.
+P2 and P3 findings may remain with their normal ledger status. Use
+`changes-requested` for a blocking finding, failed required check, incomplete
+scope, adapter mismatch, or missing fresh-session declaration.
+
+## Freshness
+
+A receipt is current only when all of these hold:
+
+- `HEAD` exactly equals `Target commit`.
+- `Base ref` still resolves and its merge base with `Target commit` exactly
+  equals `Base commit`, and it remains a locally recorded remote default branch,
+  local `main`, or local `master`.
+- The exact task spec bytes still match `Spec hash`.
+- No tracked, staged, unstaged, or untracked path differs from the target except
+  `devflow/context/{xxx-slug}/review.md` and `devflow/context/{xxx-slug}/findings.md`.
+- The completed reviewer adapter matches `Requested reviewer`.
+- The completed reviewer model exactly matches `Requested model`, unless the
+  request explicitly selected the runtime-default sentinel above. In that case,
+  `Reviewer model` must still contain the exact model exposed after the reviewer
+  session starts, never the sentinel itself.
+
+Any other code, test, configuration, spec, or acceptance-criteria change makes
+the receipt stale. A stale receipt never proves the new state. Prepare a new
+request against a new approved checkpoint and review the whole delta again.

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

@@ -82,6 +82,27 @@ 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.
 
+### Quality-gate and browser preflight
+
+Read `qualityGates.regular.independentReview` from `devflow/config.json`.
+`manual` is opt-in, `always` activates the gate, and `when-sensitive` activates
+when the task touches authentication, authorization, secrets, payments,
+personal data, destructive operations, dependencies, deployment, or another
+security boundary. Reuse the target spec's recorded sensitivity decision; if it
+is missing, record the evidence-backed decision before implementation.
+
+Any product or living-spec edit invalidates an earlier receipt. After the final
+Verify and targeted audit repairs, an active gate requires the
+`audit independent current` handoff in a fresh reviewer context. Autopilot must
+stop rather than self-approve when it cannot obtain a receipt with `passed`
+verdict and `current` freshness; it never continues toward `/complete` on a
+pending, malformed, changes-requested, stale, or missing receipt.
+
+For browser-visible behavior, run `npm run test:browser` when `test:browser` is
+declared and capture interactive evidence with `browseros-neo` when available.
+If either path is unavailable, record the limitation in the review packet and do
+not install a runner or claim browser proof implicitly.
+
 ## Step 2 - choose or write the spec
 
 If `devflow/context/{xxx-slug}/spec.md` already contains an active spec,
@@ -233,4 +254,4 @@ Stop immediately and report instead of continuing when Autopilot would need to:
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.