@jakkrichm/create-nexus-devflow 2.12.2 → 2.12.3

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.
 

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/audit/SKILL.md

@@ -85,10 +85,15 @@ Optional review mode:
 
 ## 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.
+`/audit independent current` is a two-context workflow. The builder prepares a
+request. With `review.independentExecution: "manual"`, the selected fresh
+reviewer session runs the same command to complete it. With `automatic`, the
+current adapter may start a fresh isolated reviewer subagent after preparing the
+request. DevFlow verifies the exact target and later staleness. The adapter,
+model, and fresh-context identity remain declared metadata.
+An explicit invocation uses this execution setting even when the active
+workflow's `independentReview` gate is `manual`; that gate value disables only
+automatic selection by the workflow.
 
 Read `reference/independent-review.md` before either phase.
 
@@ -97,6 +102,11 @@ Read `reference/independent-review.md` before either phase.
 Use this phase when `devflow/context/{xxx-slug}/review.md` has no current `pending`
 request for `HEAD` and the current spec hash.
 
+A current pending request without `Requested execution` is legacy and manual
+only. Never add execution fields to it or run a subagent against it. Stop with
+the fresh-session handoff; Phase B must omit `Actual execution` so the legacy
+request and receipt keep both execution fields absent.
+
 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,
@@ -109,22 +119,52 @@ request for `HEAD` and the current spec hash.
 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.
+3. Resolve the review executor from `review.independentExecution`:
+   - For `manual`, 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. Do not invent available models or
+     offer an adapter that is not installed in the project.
+   - For `automatic`, use only a live child-agent capability in the current
+     adapter that can start with no builder transcript, disclose the exact
+     reviewer adapter and model, and wait for completion. Spawn a generic fresh
+     isolated child through the current runtime. Do not discover, select, or
+     depend on a globally installed role, skill, prompt, or another workflow
+     such as TraversyFlow. If the runtime cannot start that generic child from
+     project-local instructions, or capability, isolation, identity, model, or
+     completion cannot be confirmed, use the manual path.
 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
+   requested reviewer adapter and model, requested execution from
+   `review.independentExecution`, 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.
+5. Execute the configured path:
+   - For `manual`, 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`;
+     Copilot and OpenCode receive the equivalent plain-language instruction.
+     Tell the user to open a fresh session with only the handoff, not the builder
+     chat.
+   - For `automatic`, freeze all parent product, test, spec, and config changes.
+     Start one generic isolated child without the builder transcript. Instruct
+     it to read the project-local Audit skill and
+     `reference/independent-review.md` from the current adapter tree, then
+     execute Phase B against the prepared request. All review instructions come
+     from that installed DevFlow project. The reviewer may write only
+     `devflow/context/{xxx-slug}/findings.md` and `devflow/context/{xxx-slug}/review.md`; it must
+     not repair code, change the spec, commit, or perform external actions. Wait
+     for completion, then reread and validate the normal receipt before
+     continuing. Record `fresh subagent` as its reviewer context.
+
+If automatic execution fails or any required property becomes uncertain, keep
+the pending request intact, set activity to `ready`, and stop with the existing
+manual fresh-session handoff. Never let the builder review its own work or skip
+a selected independent-review gate.
+
+The builder never performs Phase B itself. It may continue only after a manual
+reviewer session or automatic isolated reviewer produced a valid current receipt.
 
 ### Phase B - perform the review
 
@@ -136,8 +176,12 @@ Use this phase when a current pending request exists in `devflow/context/{xxx-sl
    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.
+2. Proceed only from the fresh reviewer handoff. Record `fresh session` for a
+   manual reviewer or `fresh subagent` for an automatic isolated reviewer. This
+   is a declaration, never cryptographic proof. If the reviewer has the builder
+   conversation or is the builder continuing in place, stop and request a fresh
+   context. For a legacy request with no `Requested execution`, require a fresh
+   reviewer session, record `fresh session`, and omit `Actual execution`.
 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
@@ -150,6 +194,9 @@ Use this phase when a current pending request exists in `devflow/context/{xxx-sl
    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`.
+   Record actual `automatic` with `fresh subagent`, or actual `manual` with
+   `fresh session`, including an explicit manual fallback from an automatic
+   request.
 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.

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

@@ -11,7 +11,7 @@ work, archived by `/complete`, and then reset.
 
 > **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,
+> handoff against an approved checkpoint, a fresh reviewer context completes it,
 > and `/complete` refuses stale, pending, or changes-requested review state.
 
 _No independent review requested. Run `/audit independent current` to prepare one._
@@ -30,6 +30,11 @@ 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.
 
+A pending request without `Requested execution` is a legacy manual request.
+Never auto-upgrade it or send it to a subagent. Complete it only from a fresh
+reviewer session, keep `Reviewer context: fresh session`, and omit `Actual
+execution` so both execution fields remain absent.
+
 ```markdown
 # Independent Review
 
@@ -42,6 +47,7 @@ model and record the exact runtime model in the completed receipt.
 **Builder model:** <exact model reported by the builder runtime>
 **Requested reviewer:** <adapter>
 **Requested model:** <exact model or user-selected runtime default>
+**Requested execution:** <manual or automatic>
 **Requested at:** <ISO-8601 timestamp>
 **Workflow:** <regular or continuous>
 **Check required:** <yes or no>
@@ -49,7 +55,7 @@ model and record the exact runtime model in the completed receipt.
 ## 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.
+session or isolated subagent 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.
 ```
@@ -68,7 +74,8 @@ Keep the request fields unchanged and replace `pending` with `passed` or
 ```markdown
 **Reviewer adapter:** <adapter>
 **Reviewer model:** <exact model reported by the reviewer runtime>
-**Reviewer context:** fresh session
+**Reviewer context:** <fresh session or fresh subagent>
+**Actual execution:** <manual or automatic>
 **Reviewed at:** <ISO-8601 timestamp>
 **Scope:** current
 **Lenses:** quality, security, performance, tests
@@ -104,7 +111,14 @@ 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.
+scope, adapter mismatch, or missing a valid fresh-context declaration.
+
+Execution and context must agree. A manual request completes only as actual
+`manual` with `fresh session`. An automatic request normally completes as
+actual `automatic` with `fresh subagent`; when automatic capability falls back,
+it may complete as actual `manual` with `fresh session`. Reject every other
+pairing. Legacy receipts with neither execution field remain valid only with
+`fresh session`; a legacy receipt can never claim `fresh subagent`.
 
 ## Freshness
 
@@ -122,7 +136,20 @@ A receipt is current only when all of these hold:
   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.
+- `Reviewer context` is exactly `fresh session` or `fresh subagent`. A subagent
+  receipt is valid only when the runtime started it without the builder
+  transcript and exposed its exact adapter and model. The automatic child is a
+  generic current-runtime child instructed from the project-local Audit skill
+  and this project-local contract. It never depends on a global role, skill,
+  prompt, or another workflow.
+- `Requested execution` and `Actual execution` form one of the allowed pairings
+  above. New requests always record the requested value, and new receipts always
+  record the actual value.
 
 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.
+
+The adapter, model, and context fields are declared metadata. DevFlow proves
+the target and staleness, but it cannot cryptographically prove that a separate
+agent or fresh context performed the review.