@jakkrichm/create-nexus-devflow 2.12.2 → 2.12.4

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

@@ -20,6 +20,11 @@ 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 combines `/feature` or `/fix` with `/implement` and continues through the
+spec-review stop retained by the normal workflow. That human spec approval is
+the main control Autopilot intentionally removes. It does not remove the final
+review packet or the option to walk through the completed code.
+
 It does **not** replace the normal workflow. `/feature`, `/implement`, `/check`,
 and `/complete` remain the conservative default.
 
@@ -103,28 +108,26 @@ 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
+## Step 2 - spec or fix definition
+
+If starting a planned feature:
 
-If `devflow/context/{xxx-slug}/spec.md` already contains an active spec,
-resume it. Read checked steps and continue from the first unchecked step.
+1. Read `devflow/context/project-overview.md` and `devflow/build-plan.md`.
+2. Follow `/feature`'s sizing logic. If the feature is too large for one spec,
+   split it in `devflow/build-plan.md` into `Na`, `Nb`, `Nc` and target only
+   the first sub-feature.
+3. Write the spec to `devflow/context/{xxx-slug}/spec.md` and set its status to
+   `specified`. Fill all required sections, including the small build steps and
+   acceptance criteria.
 
-If there is no active spec:
+If starting an ad-hoc fix:
 
-1. Use the `/feature` behavior for a planned feature, or `/fix` behavior for a
-   requested fix.
-2. Create workspace and write `devflow/context/{xxx-slug}/spec.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.
+1. Pull the bug description or failure context.
+2. Follow `/fix`'s definition rules and write `devflow/context/{xxx-slug}/spec.md`.
+3. Set `Type: Fix` and write a short, focused task list.
 
-Autopilot may continue past this spec gate because the user explicitly invoked
-Autopilot. Still report what the critique changed in the final packet.
+If resuming an existing feature, verify `devflow/context/{xxx-slug}/spec.md` is
+usable and resume from the first unchecked step.
 
 ## Step 3 - branch
 
@@ -161,6 +164,10 @@ Work through the spec's steps in order:
 Do not batch the whole feature into one large diff. If a step gets too large,
 split the step in `devflow/context/{xxx-slug}/spec.md` and continue with the first smaller step.
 
+Do not pause for user approval after each passing step, regardless of the
+configured `workflow.stepReview` value. The review happens at the final packet
+unless a hard stop is hit.
+
 ## Step 5 - acceptance check
 
 After all implementation steps are checked, run the `/check` behavior for the
@@ -177,6 +184,38 @@ feature audit, not a repository-wide cleanup pass. Findings are recorded in
 `devflow/context/{xxx-slug}/findings.md` with durable IDs and statuses, as `/audit`
 defines; the ledger reports status and never scopes what the audit examines.
 
+Apply `qualityGates.regular.independentReview` before a same-session audit:
+
+- `manual` does not activate the gate.
+- `when-sensitive` requires it only when the work touches authentication,
+  authorization, secrets, payments, personal data, destructive actions, dependencies,
+  deployment, or another sensitive boundary.
+- `always` requires it for every work item.
+
+The selected review runs after all implementation steps, final Verify, required
+Check, and the verified spec, before the final review packet and `/complete`.
+`review.independentExecution` chooses the manual fresh-session handoff or an
+automatic isolated reviewer; it does not change when the gate is selected.
+
+When selected, do not review the builder's work in this session. Ensure all work
+is in an approved clean checkpoint, then follow Phase A of
+`/audit independent current`. With automatic execution, spawn and wait for the
+isolated reviewer, then validate its normal receipt. With manual execution, stop
+with the handoff. Autopilot may use its existing configured checkpoint authority
+when checkpoint commits are enabled; otherwise show the exact review-checkpoint
+candidate and ask before committing. On resume, continue only when a fresh
+reviewer wrote a current `passed` receipt. Repair `changes-requested` P0/P1
+findings within the normal scope and attempt limit, then obtain a new checkpoint
+and prepare a new review. A passing independent receipt satisfies the configured
+Audit gate.
+
+The request records `Requested execution`; the receipt records `Actual
+execution`. Require the execution and reviewer-context pairing defined by the
+project-local review contract, including actual manual plus `fresh session` when
+an automatic request explicitly falls back.
+On resume, a pending request without `Requested execution` is legacy manual-only.
+Never add execution fields or run a subagent against it.
+
 For every finding:
 
 1. Validate it against the actual code, spec, tests, `coding-standards.md`, and
@@ -216,6 +255,11 @@ Stop and produce a concise review packet:
 - unresolved risks or skipped checks
 - exact next action
 
+Always offer a read-only walkthrough of the completed code after the packet.
+Follow the spec's build steps, explain the key files, symbols, flow, and
+non-obvious decisions, then offer a focused deep dive. Keep `/try` distinct as
+the manual product-review path.
+
 If everything is green, the next action is usually: review the diff, then run
 `/try` if you want a manual walkthrough, then `/complete`.
 

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

@@ -113,6 +113,12 @@ Run the exact documented `Verify` command locally. The individual build, test,
 or typecheck commands may still be run separately for diagnosis, but the final
 proof must use Verify because that is what GitHub will run.
 
+A passing local run proves the recipe against the current working copy. It does
+not prove dependency installation or command behavior from a fresh checkout.
+Until the workflow is pushed and reports green on GitHub, describe the setup as
+prepared locally, not CI verified. The first successful GitHub run is the
+authoritative clean-checkout proof.
+
 If Verify fails, report the failing subcommand and stop. Do not weaken the
 command, remove a legitimate check, or describe CI as ready.
 
@@ -128,7 +134,8 @@ Finish with a concise setup report:
 - checks included and checks omitted
 - test gate status
 - workflow path and triggers
-- local Verify result
+- local Verify result and whether CI is only prepared locally or confirmed by a
+  successful GitHub run
 - files changed
 - any overlap, uncertainty, or follow-up
 

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

@@ -54,6 +54,31 @@ Use `qualityGates.regular` for this 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.
 
+### Independent review execution
+
+After final Verify and required Check pass, set the active spec to `verified`.
+If a selected or previously initiated independent review does not already have a
+current passing receipt:
+
+1. Use an existing current pending request and its immutable target when one is
+   present. Otherwise show the exact product, test, and verified-spec candidate
+   for the immutable review checkpoint. Obtain explicit commit approval under
+   the normal Git rules, then create or use that clean checkpoint. Configuration,
+   including `review.independentExecution: "automatic"`, never grants permission
+   to commit. A pending request without `Requested execution` is legacy and
+   manual-only; never add execution fields or run a subagent against it.
+2. Prepare Phase A of `/audit independent current` when no current request
+   exists. Record `Requested execution` from `review.independentExecution`.
+3. For requested `automatic`, start the generic isolated current-runtime child
+   from the installed project-local Audit skill, wait, and validate the normal
+   receipt. Freeze parent product, test, spec, and config changes while it runs.
+4. For requested `manual`, or when automatic isolation, identity, model, or
+   completion is unavailable, preserve the pending request, set activity to
+   `ready`, and stop with the manual fresh-session handoff.
+5. Continue Complete only with a current passing receipt whose requested and
+   actual execution fields match the allowed review contract. Never self-review
+   or silently skip the gate.
+
 ## Step 0 - final safety pass
 
 Before logging or committing, run a short safety pass and report blockers only:
@@ -82,13 +107,13 @@ Check whether the spec is a feature, fix, or rollback. A fix is marked
 `Type: Fix` and has no build-plan number. A rollback is marked `Type: Rollback`
 and records the exact target feature, archive, commit, and parent.
 
-- **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), and record an entry into `devflow/history/HISTORY.md`.
+- **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), recompute the overview fingerprint using `/overview`'s checkbox-normalized hash contract and update `devflow:source-hash` in `devflow/context/project-overview.md`, and record an entry into `devflow/history/HISTORY.md`.
 - **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 & 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.
+- If `devflow/context/{xxx-slug}/review.md` holds a completed passing receipt, append a `## Independent review` section to the archive file with the receipt fields, commands, safe evidence references, findings, and remaining risk from `review.md`. Preserve the full target and base SHAs, spec hash, base ref, builder adapter and model, requested reviewer, model, and execution, actual reviewer adapter, model, and execution, Check result, fresh-context declaration, and review time. Do not archive a stale, pending, changes-requested, or malformed record.
 
 **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/`.
 

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

@@ -24,6 +24,7 @@ Where this sits in the workflow:
 ### ขอบเขตสิทธิ์ที่ได้รับอนุญาตเฉพาะในเครื่อง Local:
 - สร้างและสลับ Feature Branch ในเครื่อง Local
 - บันทึก Checkpoint Commits ย่อยบน Branch
+- สร้าง required immutable independent-review checkpoints
 - บันทึก Feature Commit สุดท้าย
 - Squash-merge ฟีเจอร์ที่เสร็จสมบูรณ์ลง Default Branch ของ Local
 - ลบ Feature Branch เฉพาะใน Local หลังรวมโค้ดสำเร็จ
@@ -93,10 +94,14 @@ Where this sits in the workflow:
 - **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
+ทำงาน ให้รัน Verify และสร้าง immutable checkpoint (ได้รับอนุญาตภายใต้ Continuous Mode authority แม้ checkpointCommits จะ disabled) จากนั้นปฏิบัติตาม `/audit independent current`
+หาก `review.independentExecution` เป็น `automatic` ให้ spawn และรอ isolated reviewer child พร้อมตรวจสอบ receipt ให้ผ่านก่อนดำเนินการต่อ
+หากเป็น `manual` หรือ runtime ไม่สามารถพิสูจน์ isolation, identity, model ได้ ให้ตั้งสถานะเป็น `ready` และหยุดด้วย manual handoff
+Continuous Mode จะไม่ทำการ audit งานของตัวเองโดยเด็ดขาด
+
+คำขอจะบันทึก `Requested execution` และ receipt จะบันทึก `Actual execution`
+การจับคู่ของ execution และ reviewer context จะต้องถูกต้องตามสัญญา review
+หากเป็น legacy request ที่ไม่มี `Requested execution` ให้ถือว่าเป็น legacy manual-only ห้ามเติมฟิลด์หรือรัน subagent กับมัน
 
 สำหรับฟีเจอร์ browser-facing ให้รัน `npm run test:browser` เมื่อมี
 `test:browser` script และเก็บ interactive evidence ผ่าน `browseros-neo` เมื่อ

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

@@ -58,10 +58,14 @@ Gather these, then summarize. Do not dump file contents.
    - Read `devflow/config.json` when present. Missing is healthy and means
      built-in defaults. When present, require a regular non-symbolic-link JSON
      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,
-     independent-review, check, and try-guide gate uses its supported values and
-     defaults to `manual`.
+     Report the effective workflow, git, verification, review execution, regular
+     quality-gate, Continuous quality-gate, and Continuous Mode settings. Confirm each audit,
+     independent-review, check, and try-guide gate uses its supported values.
+     Independent review defaults to `when-sensitive` for both workflows; audit,
+     check, and try guide default to `manual`. Confirm
+     `review.independentExecution` is `manual` or `automatic` and defaults to
+     `automatic`. Do not claim automatic capability is available from installed
+     project files alone.
      An invalid config is a setup blocker for mutating workflow skills because
      they must not guess which policy to follow.
 2. **Tool adapters**

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

@@ -127,7 +127,15 @@ build plan starts high-level.
 ## Step 3 - write the spec
 
 For the one (sub-)feature being built now, allocate sequential ID (`xxx-slug`) and create a dedicated workspace at `devflow/context/{xxx-slug}/`. Write the full living spec to
-`devflow/context/{xxx-slug}/spec.md`, following `reference/feature-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. Fill every section:
+`devflow/context/{xxx-slug}/spec.md`, following `reference/feature-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. The first heading and build-plan identity must use this canonical form:
+
+```markdown
+# Feature: <title>
+
+**From build-plan:** feature <id>
+```
+
+Fill every section:
 - Goal, Problem Statement, and In/Out of scope
 - Acceptance Criteria (AC-1, AC-2, ...)
 - Small build steps as atomic 2-5 min checklist items (`- [ ]`, supporting `[TDD-Red]`, `[TDD-Green]`, `[TDD-Refactor]` triplets for functional logic)

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

@@ -32,7 +32,8 @@ or with a description, for example `/fix F-03`.
 
 Pull context from `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`,
 calculate the next sequential running ID (e.g. `059-fix-slug`),
-then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize `stage.md` and `findings.md` in that folder. Keep it lighter than a feature spec:
+then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize `stage.md` and `findings.md` in that folder. Its first heading must be exactly
+`# Fix: <title>`, and it must retain the `**Type:** Fix` contract below. Keep it lighter than a feature spec:
 
 - **Title** - the bug or change in a few words.
 - **Type:** Fix  (so `/complete` logs it to `devflow/history/fixes/`, not `devflow/history/features/`).

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

@@ -153,6 +153,29 @@ Never batch the whole thing into one diff. If a step's diff is too big to read,
 split it. The documented `Verify` command, or the fallback build and tests, must
 pass before any commit.
 
+After final Verify and required Check pass, set the active spec to `verified`
+with every completed box checked. Then resolve independent review before the
+final packet:
+
+1. If `qualityGates.regular.independentReview` does not select review and no
+   request already exists, proceed directly to the final review packet.
+2. Otherwise show the exact product, test, and verified-spec candidate for the
+   immutable review checkpoint. Obtain explicit commit approval when the exact
+   checkpoint does not already exist, then create or use it. Configuration,
+   including `review.independentExecution: "automatic"`, never grants commit
+   permission, even when normal checkpoint commits are disabled.
+3. Follow `/audit independent current` to prepare or reuse the request and record
+   `Requested execution`. For requested `automatic`, start and wait for the
+   generic isolated current-runtime child instructed from the project-local
+   Audit skill, then validate the receipt. For requested `manual`, or when
+   automatic capability is unavailable, preserve the request and stop with the
+   manual fresh-session handoff. Treat an existing request without `Requested
+   execution` as legacy manual-only: never add execution fields or run a
+   subagent against it.
+4. Continue to the final packet only with a current passing receipt whose
+   requested execution, actual execution, and reviewer context form an allowed
+   pairing. Never self-review or silently skip a selected gate.
+
 ## Step 3 - hand off to /complete
 
 Before handing off, check `devflow/context/{xxx-slug}/findings.md`. A P0 or P1 finding
@@ -182,9 +205,30 @@ When every step is built and `Verify`, or the fallback build and tests, passes
 - known risks, skipped checks, or follow-up notes
 - next action, usually `/complete`
 
-Then tell the user `/complete` makes the one work-level commit, logs it (archive,
-update the build plan for a feature or rollback, reset), and merges with
-approval. This skill does not touch main.
+After the final packet, always offer these choices:
+
+1. Walk me through the implementation.
+2. Request changes.
+3. Continue to the exact next workflow command.
+
+The final walkthrough is available with either `workflow.stepReview` value and
+regardless of `workflow.checkpointCommits`. It is a read-only code tour, not the
+manual product-review path produced by `/try`, and it is not verification.
+
+When the user chooses the walkthrough, begin with a short map of the completed
+feature, then follow the spec's build steps. For each step, explain its purpose,
+key files and symbols, important data or control flow, and non-obvious decisions.
+Use file and line links when the client supports them. Do not narrate every line
+or reload broad project context. End by offering a focused deep dive into one
+named area. If the feature spans too many distinct areas for one useful pass,
+name the sections first and let the user choose where to begin. Remain read-only
+unless the user separately requests changes.
+
+Never create an ordinary step, product, or work-level commit from this skill.
+The sole exception is exactly one immutable independent-review checkpoint after
+showing its exact candidate and receiving current explicit commit approval.
+Configuration never supplies that approval. Never merge, push, deploy, publish,
+or start unrelated work from this skill.
 
 ## Rules
 

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

@@ -164,7 +164,14 @@ than pretending a pattern exists.
 ## Step 4 - check AI interaction rules and workflow configuration
 
 `devflow/config.json` is the user-owned workflow policy for this project. Keep
-it lean and machine-readable: never write stack choices, conventions, custom
+it lean and machine-readable: edit only supported keys, such as branch prefixes,
+logic-test strictness, regular or Continuous quality gates, review execution, or
+Continuous Mode limits. Independent review defaults to `when-sensitive` for
+regular and Continuous work, and its execution defaults to `automatic`. Audit,
+check, and try guide default to `manual`. Preserve these defaults unless the user
+chooses different policies. A `manual` independent-review gate disables
+automatic selection for that workflow without disabling explicit independent
+audits. Never put stack choices, conventions, custom
 commands, product requirements, communication prose, secrets, or permission for
 commits, merges, pushes, deployments, publication, destructive actions, failed
 checks, or finding waivers into config.
@@ -172,12 +179,12 @@ checks, or finding waivers into config.
 Unless the user already chose these values, ask one short **Implementation
 style** question using the current tool's selectable prompt when available:
 
-1. **Efficient (Recommended)** - one feature-level review packet and no step
-   checkpoint prompts. Write `workflow.stepReview: "feature"` and
-   `workflow.checkpointCommits: "disabled"`.
+1. **Efficient (Recommended)** - one feature-level review packet, a final code
+   walkthrough option, and no step checkpoint prompts. Write
+   `workflow.stepReview: "feature"` and `workflow.checkpointCommits: "disabled"`.
 2. **Guided** - pause for approval after every step and offer optional checkpoint
-   commits. Write `workflow.stepReview: "every"` and
-   `workflow.checkpointCommits: "enabled"`.
+   commits, followed by the same final code walkthrough option. Write
+   `workflow.stepReview: "every"` and `workflow.checkpointCommits: "enabled"`.
 3. **Custom** - ask separately when review should happen and whether checkpoint
    commits should be offered, then write the selected low-level values.
 
@@ -185,6 +192,8 @@ These are onboarding presets, not a third configuration field.
 Never write an `implementationStyle` key. Show the current two values before asking, preserve
 them if the user chooses not to change them, and explain that either value can be
 edited later. A later `/implement` run reads the current configuration.
+The final code walkthrough is not a configuration setting and remains available
+with every implementation style.
 
 Read `devflow/context/ai-interaction.md` and update only obvious mismatches.
 Usually the default review loop should stay intact. Flag preferences for the user
@@ -197,6 +206,13 @@ instead of guessing, such as:
   changing only `stepReview` restores the approval pauses, not checkpoint prompts
 - whether branches should use a different naming pattern
 - whether `/check` should require browser evidence for UI work
+- whether audit, independent review, check, or try guides should stay manual, run only for their
+  documented conditional case, or run for every regular or Continuous work item
+- whether a selected independent review should use the default automatic
+  isolated reviewer or `review.independentExecution: "manual"` for a
+  fresh-session handoff. Explain that automatic execution uses a fresh isolated
+  reviewer only when the active adapter can expose its exact identity and model,
+  and otherwise stops with the manual handoff
 
 If no changes are needed, say so.
 
@@ -250,16 +266,51 @@ DevFlow visibility?
    Keeps AGENTS.md public as the lightweight project agent guide.
 ```
 
-Recommend option 1 by default. If the user chooses option 2:
+Recommend option 1 by default.
+- If option 1 (Commit) is chosen, ensure the project's `.gitignore` ignores transient run files and raw documents:
+  ```gitignore
+  # DevFlow Transient Runtime Data, Research & Scratch Files
+  devflow/runs/*
+  !devflow/runs/.gitkeep
+  devflow/discoveries/*
+  !devflow/discoveries/.gitkeep
+  devflow/reports/*
+  !devflow/reports/.gitkeep
+  devflow/research/*
+  !devflow/research/.gitkeep
+  devflow/scratch/*
+  !devflow/scratch/.gitkeep
+  devflow/decisions/*
+  !devflow/decisions/.gitkeep
+  !devflow/decisions/README.md
+  devflow/inbox/*/raw/*
+  devflow/inbox/raw/*
+  devflow/analysis/*
+  !devflow/analysis/.gitkeep
+  devflow/tmp/*
+  devflow/temp/*
+  devflow/brainstorm/*
+  devflow/brainstorms/*
+  devflow/backups/*
+  devflow/.state/
+  devflow/.vendor/
+  .nexus/
+  prototypes/*
+  !prototypes/.gitkeep
+  ```
+
+If the user chooses option 2 (Local-only / Zero-Visibility):
 
 - Add this block to `.gitignore`, preserving existing entries:
 
   ```gitignore
-  # DevFlow local workflow files
+  # DevFlow local workflow files (Zero-Visibility)
   .agents/
   .claude/
   devflow/
   CLAUDE.md
+  .nexus/
+  prototypes/
   ```
 
 - Keep `AGENTS.md` tracked. It remains the lightweight public project guide for
@@ -273,10 +324,10 @@ Recommend option 1 by default. If the user chooses option 2:
 - Explain that DevFlow state, specs, findings, and history will not travel
   with the repo; another machine needs DevFlow reinstalled or restored
   locally.
-- If any of `.agents/`, `.claude/`, `devflow/`, or
-  `CLAUDE.md` are already tracked, say `.gitignore` will not hide tracked files.
+- If any of `.agents/`, `.claude/`, `devflow/`, `CLAUDE.md`, `.nexus/`, or
+  `prototypes/` are already tracked, say `.gitignore` will not hide tracked files.
   Ask before running
-  `git rm --cached -r .agents .claude devflow CLAUDE.md`, and
+  `git rm --cached -r .agents .claude devflow CLAUDE.md .nexus prototypes`, and
   only run it if the user explicitly approves. Never delete the local files.
 
 Then report which selected tools and adapter folders are needed:

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

@@ -63,6 +63,20 @@ The compiler writes:
 
 The generated output follows `devflow/reference/project-overview-template.md`.
 
+After the title, write a plan fingerprint in this exact form:
+
+```markdown
+<!-- devflow:source-hash <sha256> -->
+```
+
+Before hashing, normalize only build-plan completion markers by replacing each
+`- [x]` or `- [X]` marker with `- [ ]`, while preserving indentation and every
+other byte. Compute `<sha256>` from the exact UTF-8 bytes of `project-plan.md`,
+one zero byte, then the normalized UTF-8 bytes of `build-plan.md`. This lets
+`/status` detect real plan changes after cloning, copying, or updating without
+treating completed features as overview drift. Replace the previous marker every
+time this skill regenerates the overview.
+
 ## Step 3 - output and report
 
 After compilation:

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

@@ -116,7 +116,9 @@ remediation or explicitly plan the dependent rollbacks.
 ## Step 4 - write the rollback spec
 
 Allocate sequential ID (`xxx-slug`) and create `devflow/context/{xxx-slug}/`. Write `devflow/context/{xxx-slug}/spec.md` using
-`reference/rollback-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. Fill in:
+`reference/rollback-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. Its first heading must be exactly
+`# Rollback: Feature <id> - <title>`, and it must retain the existing
+`**Type:** Rollback` contract. Fill in:
 
 - target feature and archive
 - target commit and parent commit as full 40-character SHA values

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

@@ -35,9 +35,14 @@ Read these, distill them into a few lines, then stop. Do not dump file contents.
 3. **Findings** - `devflow/context/{xxx-slug}/findings.md`. Count findings by status and
    report open and fixed counts next to build-plan progress. Call out any P0 or
    P1 still `open` or `fixed` by ID, since those block `/complete`.
-4. **Overview freshness** - if `devflow/context/project-overview.md` is missing,
-   or if `project-plan.md` or `build-plan.md` appears newer than it by filesystem
-   time, mention that `/overview` should run before new feature work.
+4. **Overview freshness** - if `devflow/context/project-overview.md` is missing
+   or has no `devflow:source-hash`, mention that `/overview` should run before
+   new feature work. Otherwise use `/overview`'s hash contract: exact project-plan
+   bytes, one zero byte, then build-plan bytes with line-start `- [x]` and
+   `- [X]` markers normalized to `- [ ]`. Treat a matching legacy exact-byte hash
+   as current for backward compatibility. Recommend `/overview` only when the
+   recorded hash matches neither value. Do not use filesystem timestamps;
+   `/complete` legitimately makes `build-plan.md` newer when it checks off work.
 5. **Git** - current branch, whether the working tree is clean or has uncommitted
    changes, roughly how many files changed, last commit subject, and whether the
    branch is ahead of its remote. If the directory is not a git repo, say so and
@@ -50,7 +55,12 @@ Read these, distill them into a few lines, then stop. Do not dump file contents.
    A missing file simply means no activity has been recorded. Invalid activity
    state is a warning, not a blocker for the underlying workflow; point to
    `/doctor` to inspect and offer the approved generated-state reset.
-8. **Onboarding check** - Before recommending `/overview`, check whether `AGENTS.md`
+8. **Onboarding & Configuration check** - Read `devflow/config.json` when present.
+   Report effective regular and Continuous quality gates, plus `review.independentExecution`.
+   Explain that independent review defaults to `when-sensitive` for both workflows and
+   execution defaults to `automatic`, which uses an isolated reviewer only when
+   the current adapter supports it. Audit, check, and try guide default to `manual`.
+   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

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

@@ -144,16 +144,51 @@ DevFlow visibility?
    Keeps AGENTS.md public as the lightweight project agent guide.
 ```
 
-Recommend option 1 by default. If the user chooses option 2:
+Recommend option 1 by default.
+- If option 1 (Commit) is chosen, ensure the project's `.gitignore` ignores transient run files and raw documents:
+  ```gitignore
+  # DevFlow Transient Runtime Data, Research & Scratch Files
+  devflow/runs/*
+  !devflow/runs/.gitkeep
+  devflow/discoveries/*
+  !devflow/discoveries/.gitkeep
+  devflow/reports/*
+  !devflow/reports/.gitkeep
+  devflow/research/*
+  !devflow/research/.gitkeep
+  devflow/scratch/*
+  !devflow/scratch/.gitkeep
+  devflow/decisions/*
+  !devflow/decisions/.gitkeep
+  !devflow/decisions/README.md
+  devflow/inbox/*/raw/*
+  devflow/inbox/raw/*
+  devflow/analysis/*
+  !devflow/analysis/.gitkeep
+  devflow/tmp/*
+  devflow/temp/*
+  devflow/brainstorm/*
+  devflow/brainstorms/*
+  devflow/backups/*
+  devflow/.state/
+  devflow/.vendor/
+  .nexus/
+  prototypes/*
+  !prototypes/.gitkeep
+  ```
+
+If the user chooses option 2 (Local-only / Zero-Visibility):
 
 - Add this block to `.gitignore`, preserving existing entries:
 
   ```gitignore
-  # DevFlow local workflow files
+  # DevFlow local workflow files (Zero-Visibility)
   .agents/
   .claude/
   devflow/
   CLAUDE.md
+  .nexus/
+  prototypes/
   ```
 
 - Keep `AGENTS.md` tracked. It remains the lightweight public project guide for
@@ -169,10 +204,10 @@ Recommend option 1 by default. If the user chooses option 2:
   locally.
 - Because adoption runs right after the DevFlow files were added to an
   existing repository, they are more likely to already be staged or committed
-  than in a fresh install. If any of `.agents/`, `.claude/`, `devflow/`, or
-  `CLAUDE.md` are already tracked, say `.gitignore` will not hide tracked files.
+  than in a fresh install. If any of `.agents/`, `.claude/`, `devflow/`,
+  `CLAUDE.md`, `.nexus/`, or `prototypes/` are already tracked, say `.gitignore` will not hide tracked files.
   Ask before running
-  `git rm --cached -r .agents .claude devflow CLAUDE.md`, and
+  `git rm --cached -r .agents .claude devflow CLAUDE.md .nexus prototypes`, and
   only run it if the user explicitly approves. Never delete the local files.
 
 ## Step 6 - review gate, then hand off