@jakkrichm/create-nexus-devflow 2.9.5 → 2.10.1

package/template/.agents/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/.agents/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.

package/template/.agents/skills/browser-tests/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: browser-tests
+description: "[devflow] Add or normalize an optional repository-owned browser test harness (preferring Playwright) and connect with MCP browserOS neo (http://127.0.0.1:9010/mcp) when available for live visual inspection and repeatable E2E automation."
+argument-hint: "[{runner or surface}]"
+---
+
+# browser-tests - set up repeatable browser verification
+
+$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`.
+
+This is an explicit optional setup command. It creates a project-owned browser
+test path that later Feature, Implement, Check, and Continuous runs can reuse. It
+does not replace live browser inspection, install during another workflow
+command, or make browser testing mandatory for every DevFlow project.
+
+---
+
+## Hybrid Browser Verification Architecture
+
+Nexus-DevFlow uses a **Dual-Layer Browser Verification Hierarchy**:
+
+```text
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                    🌐 Hybrid Browser Verification Engine                    │
+├──────────────────────────────────────┬──────────────────────────────────────┤
+│ 1. Code-Driven Test Automation (CI)  │ 2. Interactive AI Visual QA (MCP)    │
+│    • Framework: Playwright           │    • Server: MCP browseros-neo       │
+│    • Command: npm run test:browser   │    • URL: http://127.0.0.1:9010/mcp  │
+│    • Purpose: Assertions, Headless,  │    • Purpose: Live DOM Inspection,   │
+│      Regression Suite & Pre-commit   │      Real Screenshot Proofs, /try    │
+└──────────────────────────────────────┴──────────────────────────────────────┘
+```
+
+1. **Layer 1: Code-Driven Repeatable Tests (Playwright)**:
+   - Sets up `@playwright/test` for headless, deterministic assertions.
+   - Documents command in `AGENTS.md` as `Browser tests: npm run test:browser` (or equivalent).
+   - Executed automatically during `/check` and Continuous mode.
+
+2. **Layer 2: Live Interactive QA (MCP browseros-neo)**:
+   - When the `browseros-neo` MCP server (`http://127.0.0.1:9010/mcp`) is active in IDE config (`mcp_config.json`), the AI Agent connects to it for live interactive inspection.
+   - Used during `/check` and `/try` to capture visual evidence, inspect rendered styles, and verify complex user interactions directly in a live browser.
+
+---
+
+## Input
+
+No argument is required. A named runner, browser, application surface, or flow is
+a preference to verify against the real project.
+
+## Step 1 - inspect the project
+
+Read enough files to identify the actual browser surface and existing setup:
+
+- `AGENTS.md`, especially Commands and any Verify command
+- package or language manifests, lockfiles, workspaces, and runtime versions
+- existing browser, integration, and end-to-end test configs and files
+- build, dev, preview, extension-build, and test commands
+- relevant CI workflows and ignore rules
+- `devflow/context/coding-standards.md`
+- Git branch and worktree state
+
+Do not assume Node.js, npm, a web server, or a blank test setup. Do not install
+dependencies or edit files during inspection.
+
+## Step 2 - choose the smallest useful harness
+
+Reuse a working browser runner already established by the project. For a
+compatible JavaScript or TypeScript web app or browser extension with no runner,
+prefer Playwright Test (`@playwright/test`). If the stack or executable surface is unclear, stop and
+ask instead of inventing a framework.
+
+Choose one representative smoke path through a real project surface. It must
+prove the harness can launch the app and observe behavior, not merely assert that
+a static fixture exists. Keep authentication state, profiles, secrets, generated
+reports, traces, videos, and screenshots out of Git unless the project already
+has a deliberate safe convention.
+
+For browser extensions, use a persistent test browser context and load the built
+unpacked extension. Test an extension-owned page or content-script flow that the
+runner can reach. Browser toolbar UI, permission prompts, and other browser
+chrome may still require Check or Try evidence; do not claim those surfaces are
+automated when they are not.
+
+## Step 3 - present the setup
+
+Before editing, state:
+
+- runner selected or reused
+- exact dependency install command, when needed
+- config, script, test, and ignore files to add or change
+- application or extension surface covered by the smoke test
+- exact browser-test command that will be documented
+- any server, build, authentication, or browser-chrome limitation
+- MCP `browseros-neo` availability for interactive checks
+
+Dependency installation and browser-binary downloads require the user's approval
+through the current tool's normal approval flow. Do not treat running this skill
+as permission to change CI, download unrelated browsers, or add a broad suite.
+
+## Step 4 - create or normalize the harness
+
+Make the smallest practical diff:
+
+1. Add only the required runner dependency and config (e.g. `playwright.config.ts`).
+2. Add one project-relevant smoke test (e.g. `e2e/smoke.spec.ts`).
+3. Add or reuse a conventional command such as `test:browser`.
+4. Document the exact invocation in the Commands section of `AGENTS.md` as
+   `Browser tests: <command>`. Include a working directory when a workspace
+   needs one.
+5. Configure runner-owned server lifecycle only when the project has a safe,
+   documented command and the runner can start and stop it reliably. Do not
+   create a duplicate server when the established harness reuses one.
+6. Ignore generated browser-test artifacts that should stay local (e.g. `test-results/`, `playwright-report/`).
+
+Do not add browser tests to the default Verify command or GitHub workflow unless
+the user separately asks for that slower gate or the project already requires
+it. Preserve existing CI and existing browser coverage.
+
+## Step 5 - verify the path
+
+Run the documented Browser tests command. Confirm that the smoke test exercises
+the intended real surface and that the runner exits cleanly. Inspect generated
+console, request, trace, screenshot, or report evidence only when relevant to
+the claim.
+
+A passing runner with no tests, a test against the wrong surface, or a skipped
+browser launch is not a successful setup. If credentials, an external service,
+browser chrome, or another unavailable dependency blocks the smoke path, report
+the harness as incomplete instead of weakening the test.
+
+## Step 6 - report
+
+Return a concise setup report:
+
+- runner and browser surface
+- command documented in `AGENTS.md`
+- smoke behavior proven
+- MCP `browseros-neo` connectivity status
+- files added or changed
+- verification result
+- remaining manual or environment-specific boundary
+
+Show the diff summary. Do not commit, merge, push, publish, or begin unrelated
+feature work.
+
+---
+
+## Integration contract
+
+Once `AGENTS.md` declares `Browser tests: <command>`:
+
+- **Feature** may include a focused browser-test expectation for stable behavioral done-whens.
+- **Implement** may add and run a focused browser test when it is proportionate to the current step.
+- **Check** runs the documented command as repeatable evidence, connects to MCP `browseros-neo` (if active) for live visual verification & screenshots, and directly observes any done-when the suite does not prove.
+- **Continuous** needs no separate browser mode. Its configured Check gate uses the same command.
+
+The harness supplements direct evidence. A green browser suite does not prove
+visual fidelity, authenticated real-profile behavior, browser chrome, or every
+done-when unless the test actually observes those claims.

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

@@ -1,11 +1,13 @@
 ---
 name: check
-description: "[devflow] Prove the current work actually does what its spec says and adheres to architectural standards through a Dual-Axis Independent Review. Supports Multi-Run: given an optional ID or name (/check 12), targets that spec and records proof to devflow/context/{xxx-slug}/findings.md. Drives the app, captures empirical evidence, checks Fowler smells, and reports pass/fail. Use when running /check, confirming work, or validating before /complete."
+description: "[devflow] Prove the current work actually does what its spec says and adheres to architectural standards through a Dual-Axis Independent Review. Supports Multi-Run: given an optional ID or name (/check 12), targets that spec and records proof to devflow/context/{xxx-slug}/findings.md. Drives the app, captures empirical evidence using Playwright and MCP browseros-neo, checks Fowler smells, and reports pass/fail. Use when running /check, confirming work, or validating before /complete."
 argument-hint: "[{run-id, number, or name}]"
 ---
 
 # check - Dual-Axis Independent Verification Engine
 
+$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`.
@@ -30,6 +32,29 @@ It changes no source and commits nothing — it executes, inspects, and reports
 
 ---
 
+## Hybrid Browser Verification Engine
+
+Nexus-DevFlow uses a **Dual-Layer Browser Verification Hierarchy**:
+
+```text
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                    🌐 Hybrid Browser Verification Engine                    │
+├──────────────────────────────────────┬──────────────────────────────────────┤
+│ 1. Code-Driven Test Automation (CI)  │ 2. Interactive AI Visual QA (MCP)    │
+│    • Framework: Playwright           │    • Server: MCP browseros-neo       │
+│    • Command: npm run test:browser   │    • URL: http://127.0.0.1:9010/mcp  │
+│    • Purpose: Assertions, Headless,  │    • Purpose: Live DOM Inspection,   │
+│      Regression Suite & Pre-commit   │      Real Screenshot Proofs, /try    │
+└──────────────────────────────────────┴──────────────────────────────────────┘
+```
+
+1. **Layer 1: Code-Driven Repeatable Tests (Playwright)**:
+   - If `AGENTS.md` declares `Browser tests: <command>`, run that exact command as repeatable automated evidence.
+2. **Layer 2: Interactive AI Visual QA (MCP browseros-neo)**:
+   - When the `browseros-neo` MCP server (`http://127.0.0.1:9010/mcp`) is active, use it to inspect the live running app, verify rendered CSS/layout, test click flows, and capture actual screenshot proofs.
+
+---
+
 ## Step 1 - Build the Dual-Axis Review Matrix
 
 Read the target spec from `devflow/context/{xxx-slug}/spec.md` and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
@@ -50,7 +75,7 @@ Read the target spec from `devflow/context/{xxx-slug}/spec.md` and `devflow/cont
 
 Use the project's real commands (from `AGENTS.md`):
 
-- **Web app**: Start (or reuse) the local dev server. Drive a real browser to relevant routes. Prefer Playwright when installed for screenshots, network errors, and console assertions.
+- **Web app**: Start (or reuse) the local dev server. Drive a real browser to relevant routes. If `Browser tests: <command>` is declared, run it. When MCP `browseros-neo` is active, connect to inspect live visual state.
 - **CLI**: Execute commands with representative input fixtures, asserting exit codes and output snapshots.
 - **Server / API**: Hit endpoints with real payloads and assert on HTTP response status and bodies.
 - **Library**: Exercise public interfaces through integration tests or sample scripts.
@@ -60,7 +85,7 @@ Use the project's real commands (from `AGENTS.md`):
 
 ---
 
-## Step 3 - Dual-Axis Independent Report
+## Step 3 - Dual-Axis Independent Report & State Update
 
 Format the report into two distinct, un-merged review axes:
 
@@ -72,6 +97,8 @@ Format the report into two distinct, un-merged review axes:
 - **Technical Lanes**:
   - [pass] Type Safety: `tsc --noEmit` (0 errors)
   - [pass] Automated Tests: `npm test` (All tests green)
+  - [pass] Browser Tests: `npm run test:browser` (Playwright passed)
+  - [pass] Visual Inspection: MCP browseros-neo verified UI layout & zero console errors
   - [pass] Security & Hygiene: Zero secrets, sanitized inputs
   - [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/{xxx-slug}/findings.md`
 - **Deep Modules & Architecture**:
@@ -93,25 +120,7 @@ Line-by-line verification against `devflow/context/{xxx-slug}/spec.md`:
 
 ## 🚦 Final Routing & Verdict
 
-- **ALL PASSED**: Both axes green. Ready for `/complete`.
+- **ALL PASSED**: Both axes green. Update `stage.md` (Passed -> Ready for `/complete`).
 - **ANY FAILURE**: Hand back to `/implement` with exact failure evidence and reproduction steps.
 - **UNVERIFIABLE**: Clearly document the gap and residual risk. Never fabricate a pass.
-```
-
----
-
-## Why Two Independent Axes?
-
-A code change can pass one axis and fail the other:
-- **Standards Pass, Spec Fail**: Code is beautifully architected and tested, but implements the wrong business behavior.
-- **Spec Pass, Standards Fail**: Feature works end-to-end, but violates encapsulation, introduces shallow modules, or leaks secrets.
-
-Reporting both axes side-by-side stops elegance from masking functional bugs, and stops functional completeness from excusing architectural rot.
-
----
-
-## Rules
-
-- **Observe, don't change**: `/check` runs the app and reports. It never edits source or commits. Fixing is `/implement`'s job.
-- **Honest over green**: "Failed" and "Could not verify" are valid, valuable outputs. Faking a pass destroys the gate.
-- **Check the spec, not vibes**: Verify against documented ACs, not subjective feelings.
+```

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

@@ -1,11 +1,13 @@
 ---
 name: complete
-description: "[devflow] Wrap up a finished feature, fix, or rollback. Supports Multi-Run: given an optional ID (/complete 12), archives that run from devflow/context/{xxx-slug}/ to devflow/history/, cleans up the run workspace, updates build-plan and HISTORY.md, and makes the work commit. Enforces mandatory user gate (Squash-merge vs MR/PR)."
+description: "[devflow] Wrap up a finished feature, fix, or rollback. Supports Multi-Run: given an optional ID (/complete 12), archives that run from devflow/context/{xxx-slug}/ to devflow/history/, verifies independent review receipt and findings ledger, cleans up the run workspace, updates build-plan and HISTORY.md, and makes the work commit. Enforces mandatory user gate (Squash-merge vs MR/PR)."
 argument-hint: "[{run-id, number, or name}]"
 ---
 
 # complete - log the finished work, make the work commit, and deliver
 
+$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`.
@@ -28,6 +30,9 @@ passes.
 
 ## Before you start
 
+Read `devflow/config.json`. A missing file means the built-in defaults apply.
+If the file exists but is invalid, stop and point the user to `/doctor`.
+
 Confirm the target work is actually finished: `devflow/context/{xxx-slug}/spec.md`
 holds a real spec, its steps are built on a branch, and `Verify`, or the fallback
 build and tests, passes. If any of the
@@ -36,6 +41,19 @@ running app first - don't merge or complete on an unverified claim. Uncommitted
 expected (per-step checkpoints are optional); this skill commits it. Don't require
 the steps to be pre-committed.
 
+Read `devflow/context/{xxx-slug}/review.md` (or `devflow/context/review.md`) when present. A pending,
+changes-requested, malformed, or stale record is always a blocker because the
+user already initiated that gate, even when its configured policy is `manual`.
+
+## Configured regular quality gates
+
+Use `qualityGates.regular` for this work item:
+
+- **Audit:** `manual` runs only when the user explicitly requests `/audit`; `when-sensitive` runs for sensitive categories; `always` runs for every work item.
+- **Independent review:** `manual` runs only when explicitly requested (`/audit independent current`); `when-sensitive` requires it for sensitive domains; `always` requires it for every work item.
+- **Check:** `manual` runs only when explicitly requested; `when-behavioral` runs when done-whens need observed runtime behavior; `always` runs for every work item.
+- **Try guide:** `manual` runs only when explicitly requested; `when-user-facing` generates guide when change affects UI/UX; `always` generates one for every work item.
+
 ## Step 0 - final safety pass
 
 Before logging or committing, run a short safety pass and report blockers only:
@@ -47,15 +65,12 @@ Before logging or committing, run a short safety pass and report blockers only:
   declared test command and the change touched logic
 - behavioral done-whens have `/check` evidence or equivalent proof, and there is
   a clear manual try path
-- if workflow files changed, `.agents` and `.claude` stayed in sync where both
-  adapters exist
+- any check required by `qualityGates.regular` has evidence, and there is a clear manual try path
+- a selected independent-review gate has a `passed` receipt in `review.md` whose target equals `HEAD`, whose spec hash matches, and whose receipt is current. Any mismatch is stale and blocks completion.
+- if workflow files changed, `.agents` and `.claude` stayed in sync where both adapters exist
 - no P0 or P1 finding in `devflow/context/{xxx-slug}/findings.md` is `open` or `fixed`.
   `fixed` still blocks on purpose: the repair exists but no review has looked at
-  it - run `/audit` to close it. The only waivers are `accepted` (the user's
-  explicit decision in the current chat, reason recorded; never set it for
-  them) or `invalid` (an `/audit` re-examination verdict with recorded
-  evidence, or the user's explicit call). A missing ledger file means no
-  findings.
+  it - run `/audit` to close it. The only waivers are `accepted` or `invalid`.
 
 Do not claim "passed", "verified", or "working" without naming the command,
 route, screenshot, or output that proves it. Stop before Step 1 if required
@@ -71,20 +86,14 @@ and records the exact target feature, archive, commit, and parent.
 - **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md`, and record an entry into `devflow/history/HISTORY.md`.
 - **Rollback** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/rollbacks/YYYY-MM-DD-{xxx-slug}.md`, preserving the original completed feature archive. Uncheck the target item in `devflow/build-plan.md` and record in `devflow/history/HISTORY.md`.
 
-**Archive resolved findings.** If `devflow/context/{xxx-slug}/findings.md` holds any
-findings, append a `## Findings` section to the archive file just written with
-every `closed`, `accepted`, or `invalid` entry at its final status (`accepted`
-entries keep their recorded reason). Do not archive or remove a `fixed` finding
-at any severity; repaired findings must remain in the ledger until an `/audit`
-re-review closes them.
+**Archive resolved findings & review receipts.**
+- If `devflow/context/{xxx-slug}/findings.md` holds findings, append `## Findings` to the archive file with resolved entries.
+- If `devflow/context/{xxx-slug}/review.md` holds a completed passing receipt, append `## Independent Review` to the archive file with the receipt summary.
 
 **Clean up run workspace.** Delete the task directory `devflow/context/{xxx-slug}/`. In Pure Multi-Run architecture, completed work leaves zero residual stubs in `devflow/context/`.
 
 **Discard consumed prototypes.** If this feature built the look from `prototypes/`
-- its Design reference pointed there and an early step ported `prototypes/theme.css`
-into the app - delete the `prototypes/` folder now. The tokens live in the real
-stylesheet and the HTML mockups were always throwaway; fold the deletion into this
-feature's commit. Skip this if the feature didn't consume prototypes.
+delete the `prototypes/` folder now.
 
 ## Step 2 - make the work commit on feature branch
 
@@ -127,24 +136,4 @@ Present the user with two clear delivery options:
 ## Step 4 - Finish & Try Path
 
 Point the user at `/feature`, `/fix`, or `/rollback` for the next task.
-
-Finish with a concise **How to try it** note for the completed work. For a
-rollback, explain how to confirm the removed behavior is gone and name one
-unaffected regression path. If the
-manual path is more than a couple of steps, tell the user to run `/try latest`;
-that command can read the archived feature from history.
-
-## Rules
-
-- **Mandatory User Confirmation Gate**: Always ask before choosing between Team MR/PR Push vs Direct Squash-Merge.
-- **Never auto-merge into main/master**: The decision to merge into `main` or `master` belongs strictly to the user.
-- The work item is the unit of history: one squashed feature, fix, or rollback
-  commit, even if the branch carried several checkpoint commits.
-- A rollback preserves the original feature archive and adds a separate rollback
-  archive. Never rewrite history to make the feature look as if it never existed.
-- Don't merge or push unfinished or failing work. The documented `Verify` command, or
-  the fallback build and tests, must pass first.
-- Never merge or push while a P0 or P1 finding is `open` or `fixed` in the ledger.
-- Pushing to remote is always explicit: confirm before running `git push`.
-- One item per completion. If a parent feature still has unchecked sub-features,
-  leave the parent unchecked.
+Finish with a concise **How to try it** note for the completed work.

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

@@ -88,9 +88,21 @@ Where this sits in the workflow:
 ### 2.4 Apply Continuous Quality Gates
 ตรวจสอบตามการตั้งค่า `qualityGates.continuous` ใน `devflow/config.json`:
 - **Audit**: `manual` (ข้ามอัตโนมัติ), `when-sensitive` (รันเมื่อแตะ Auth/Security/Database/Secrets), `always` (รันทุกฟีเจอร์)
+- **Independent Review**: อ่าน `qualityGates.continuous.independentReview`; `manual` คือ opt-in, `always` บังคับทุกฟีเจอร์, และ `when-sensitive` บังคับเมื่อฟีเจอร์แตะ authentication, authorization, secrets, payments, personal data, destructive operations, dependencies, deployment หรือ security boundary อื่น บันทึกคำตัดสินและหลักฐานต่อฟีเจอร์ใน spec
 - **Check**: `manual` (ข้ามอัตโนมัติ), `when-behavioral` (รันเมื่อมี Runtime Behavior เช่น UI/CLI/API), `always` (รันทุกฟีเจอร์)
 - **Try Guide**: `manual` (ข้ามอัตโนมัติ), `when-user-facing` (สร้าง Try Guide เมื่อเป็น UI/CLI), `always` (สร้างทุกฟีเจอร์)
 
+ทุก product/spec edit ทำให้ receipt เดิมหมดอายุ เมื่อ Independent Review gate
+ทำงาน ให้รัน Verify และซ่อม audit findings ให้เสร็จก่อนส่ง
+`audit independent current` ไปยัง fresh reviewer context หากไม่สามารถรับ
+receipt ที่ verdict เป็น `passed` และ freshness เป็น `current` ให้หยุด Continuous
+Mode โดยคง workspace/branch ไว้ ห้ามข้ามไป archive หรือ local squash-merge
+
+สำหรับฟีเจอร์ browser-facing ให้รัน `npm run test:browser` เมื่อมี
+`test:browser` script และเก็บ interactive evidence ผ่าน `browseros-neo` เมื่อ
+พร้อมใช้งาน หาก script หรือ MCP ไม่มี ให้บันทึก limitation และหยุดเมื่อ evidence
+นั้นเป็น gate ที่จำเป็น ห้ามติดตั้งหรืออ้างผลโดยปริยาย
+
 ### 2.5 Repair Findings
 - ซ่อมแซม Finding ระดับ P0/P1 ที่เกิดขึ้นจากฟีเจอร์นี้โดยอัตโนมัติ (ไม่เกิน `continuous.maxRepairAttempts` ครั้ง)
 - หากไม่สามารถซ่อมแซมได้ หรือมี P0/P1 ค้างอยู่ ให้หยุดการทำงานทันที

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

@@ -39,12 +39,16 @@ Gather these, then summarize. Do not dump file contents.
      `devflow/history/rollbacks/`. A missing rollback folder on a legacy
      installation is a warning, not a blocker; `/complete` creates it on the
      first rollback.
-   - Check `devflow/context/findings.md`. Missing on a legacy installation is
-     a warning, not a blocker; `/audit` and `/complete` create it on first use.
+   - Check `devflow/context/findings.md` and `devflow/context/{xxx-slug}/findings.md`.
+     Missing on a legacy installation is a warning, not a blocker; `/audit` and `/complete` create it on first use.
      When present, confirm its entry headers still match
      `### <id> [<severity>] <status> - <title>` and warn on a malformed ledger.
      Report any P0 or P1 finding still `open` or `fixed` by ID, since it will
      block `/complete`. Never block on the ledger yourself.
+   - Check `devflow/context/review.md` and `devflow/context/{xxx-slug}/review.md`. Missing is a
+     warning, not a blocker; `/audit independent current` and `/complete` create
+     it on first use. When present, validate the required request or receipt
+     fields and report pending, changes-requested, malformed, or stale state.
    - If `.gitignore` marks DevFlow workflow files as local-only, still require
      the files to exist on disk. Ignored but present is healthy; ignored and
      missing means the local workflow needs to be restored.
@@ -53,7 +57,8 @@ Gather these, then summarize. Do not dump file contents.
      file with `schemaVersion: 1`. Reject unknown keys and unsupported values.
      Report the effective workflow, git, verification, regular quality-gate,
      Continuous quality-gate, and Continuous Mode settings. Confirm each audit,
-     check, and try-guide gate uses its supported values and defaults to `manual`.
+     independent-review, check, and try-guide gate uses its supported values and
+     defaults to `manual`.
      An invalid config is a setup blocker for mutating workflow skills because
      they must not guess which policy to follow.
 2. **Tool adapters**
@@ -61,7 +66,6 @@ Gather these, then summarize. Do not dump file contents.
      logical adapters: Codex, Claude Code, GitHub Copilot, Antigravity, and OpenCode.
    - Confirm at least one compatible skill tree exists. Codex, Antigravity, and
      GitHub Copilot use `.agents/skills/`. Claude Code uses `.claude/skills/`.
-     OpenCode can use either tree.
    - If both skill trees are present, say that is healthy when the selected
      tools require both. Compare their skill folder names and warn about missing
      skills on either side.

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

@@ -151,6 +151,27 @@ discarded at `/complete`.
 
 This is a draft. Don't present it yet - critique it first.
 
+### Quality-gate and browser-evidence plan
+
+Before finishing the draft, read `devflow/config.json` and record the effective
+`qualityGates.regular.independentReview` policy in the spec. `manual` does not
+activate an automatic gate, `always` does, and `when-sensitive` activates it
+only when the feature touches authentication, authorization, secrets, payments,
+personal data, destructive operations, dependencies, deployment, or another
+security-sensitive boundary. Record the sensitivity decision and its evidence;
+do not silently choose the conditional result later.
+
+When the gate is active, add an explicit post-implementation handoff to
+`audit independent current`. The receipt must be produced from a fresh reviewer
+context after the final product/spec change; `/feature` only plans this handoff
+and never fabricates or pre-approves a receipt.
+
+Also inspect the repository's declared scripts and the feature behavior. If the
+feature is browser-facing and `test:browser` exists, put `npm run test:browser`
+in the verification matrix. Record an interactive `browseros-neo` handoff for
+observable UI behavior when that MCP is available. If either capability is
+absent, record it as unavailable instead of installing or claiming evidence.
+
 ## Step 4 - red-team the draft, then tighten
 
 Before the user reads it, turn on the spec yourself and try to break it. The
@@ -211,4 +232,4 @@ checked), archive the finished `devflow/context/{xxx-slug}/spec.md` 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.