@ngockhoale/ukit 3.4.49 → 3.4.51

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 All notable changes to UKit are documented here.
 
+## 3.4.51 - 2026-10-21
+
+**Handoff orchestration integrity (CKit/OMP 18.12.5 incident audit).**
+- OMP `Task` preflight (block-only): an ordinary agent carrying `sourceSession`/`model` (any value, even empty) or batch-root `sourceSession`/`model` is blocked with exact remove-field guidance; args are never rewritten, seance stays native-owned. Retries are counted per session + task instance + fingerprint (prose/name/status excluded), hashed, bounded and persisted; STOP guidance after two identical blocks.
+- Stop-gate continuation provenance: only positively native/system-origin continuations (OMP branch `session-stop-continuation` match) reuse the task contract; a user paste of the gate text mints a fresh task. Pending-continuation marker is session/task/reason-hash scoped and lock-serialized.
+- Resumable records now require exact stored task-id equality (lossy filename normalization could collide).
+- Classifier: diagnostic "which config changed" reports are READ_ONLY; forward configuration orders and mixed source mutation + report stay CONFIGURATION / CODE_IMPLEMENTATION.
+- Review-panel aggregation: FAIL/NOT_RUN dominate, underscore verdict aliases normalized, executable N/A becomes NOT_RUN; explicit product / integration-evidence / status-only review kinds. Handoff commands carry retry-fingerprint and pending-review continuity rules.
+- Audit: `docs/analysis/HANDOFF-INTENT-DISPATCH-AUDIT.md`. Historical CKit wrapper/contract origin remains unknown; verified offline on macOS/Node 22 only; no live host proof, no CI dispatch.
+
+## 3.4.50 - 2026-10-21
+
+**Verification exit-proof integrity (long-run OMP field audit).**
+- Fix execution-ledger false PASS receipts: a bare `pipefail`/`PIPESTATUS` word (e.g. `echo pipefail`) no longer exempts a masked pipe; only real `set -o pipefail` before the pipe or an immediate `exit ${PIPESTATUS[n]}` with the correct index proves the runner status.
+- A runner followed by `|| …`, backgrounded with `&`, inside a `for`/`while`/`case` flow, behind `bash -c` hiding a masked pipe, or followed by `exit 0`/`true`/`:`/leading `!` is recorded as `exitStatusUnproven` (not passing). Claude `tool_response.interrupted:true` now counts as failure.
+- Bare runners, `cd repo; runner`, `&&` chains, real pipefail and terminal subshell/group runners stay accepted. Sequential consumers (including `; echo "exit=$?"`) and `if runner; then echo ok; fi` no longer receive PASS credit: recognizing a runner attempt does not prove its exit. Loop keywords as runner arguments (`vitest -t case`) are not loops.
+- Audit report: `UKIT_LONG_RUN_ORCHESTRATION_AUDIT.md`. Verified locally on macOS/Node 22 only; OMP live host-ordering attribution remains UNVERIFIED. No CI dispatch.
+
 ## 3.4.49 - 2026-10-19
 
 **Conditional consumer verification intent closure.**

package/manifests/documentation.yaml

@@ -71,6 +71,17 @@ entries:
     validation: [manual]
     archive_policy: never
     notes: release record
+  - id: root-long-run-orchestration-audit
+    path: UKIT_LONG_RUN_ORCHESTRATION_AUDIT.md
+    class: canonical
+    audience: [owner, maintainer]
+    owner: runtime
+    source_of_truth: UKIT_LONG_RUN_ORCHESTRATION_AUDIT.md
+    merge_strategy: none
+    load_policy: on-demand
+    validation: [manual, test:tests/hooks/executionLedger.test.js, test:tests/hooks/verificationExitProof.test.js]
+    archive_policy: replace-with-snapshot
+    notes: evidence-based long-run field audit; current reproductions are distinct from incident attribution
   - id: registry-self
     path: manifests/documentation.yaml
     class: canonical
@@ -517,6 +528,17 @@ entries:
     validation: [none]
     archive_policy: immutable
     notes: 2026-10-10 orchestration regression test inventory
+  - id: docs-analysis-handoff-intent-dispatch-audit
+    path: docs/analysis/HANDOFF-INTENT-DISPATCH-AUDIT.md
+    class: archive
+    audience: [maintainer]
+    owner: product
+    source_of_truth: docs/analysis/HANDOFF-INTENT-DISPATCH-AUDIT.md
+    merge_strategy: none
+    load_policy: never
+    validation: [none]
+    archive_policy: immutable
+    notes: 2026-10-21 retained CKit intent/dispatch evidence, repair verification and recovery limits
   - id: docs-analysis-completion-task-ownership
     path: docs/analysis/COMPLETION-TASK-OWNERSHIP.md
     class: archive

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ngockhoale/ukit",
-  "version": "3.4.49",
+  "version": "3.4.51",
   "description": "Install/update an index-first AI workspace for Claude Code, OpenAI Codex and omp (Oh My Pi).",
   "license": "MIT",
   "type": "module",

package/src/core/executionContracts.js

@@ -305,14 +305,46 @@ export function classifyTaskSemantics({ promptText = '', targetFile = '' } = {})
   if (!releasePolicy && !operation && isVerificationOnlyRequest(promptText)) return { taskKind: 'READ_ONLY', verificationOnly: true };
   // A config MENTION is not a config change: the same clause needs a mutation verb, and a
   // request that also changes source/code is a coding task (config is part of its tests/fixtures).
-  const config = !sourceOrder && actionable.some((clause) => /\b(?:configuration|config|toggle|cau hinh)\b/.test(clause)
-    && /\b(?:set|change|toggle|enable|disable|switch|turn|configure|modify|update|edit|doi|bat|tat|chinh)\b/.test(clause));
+  // A DIAGNOSTIC report of past changes ("which parameters/configuration has changed, if any" /
+  // "tham so/cau hinh nao da thay doi, neu co") is a question about history, never an authorization
+  // to mutate: only a forward order ("change X to Y") stays a config mutation.
+  const CONFIG_CHANGE_REPORT_CLAUSE = /\b(?:da|has|have|had|already)\s+(?:doi|thay doi|changed?|updated?)\b|\b(?:nao|gi|which|what|report|bao cao)\b[^.;]*?\b(?:doi|thay doi|changed?|updated?)\b/;
+  // A relative past-change clause inside a FORWARD imperative ("Set the config that
+  // has changed to dark mode") names WHICH config — it does not make the sentence a
+  // report. The override holds only when the clause's FIRST mutation word precedes
+  // the config noun AND no reporting/question frame opens the clause or precedes
+  // that word: in "Report what change was made to the config" the mutation word is
+  // a question's noun, never an order.
+  const CONFIG_MUTATION_VERB = /\b(?:set|change|toggle|enable|disable|switch|turn|configure|modify|update|edit|doi|bat|tat|chinh)\b/;
+  const CONFIG_NOUN = /\b(?:configuration|config|toggle|cau hinh)\b/;
+  const CONFIG_REPORT_FRAME = /^\s*(?:report|show|tell|list|describe|explain|summari[sz]e|bao cao|cho biet|liet ke|mo ta)\b/;
+  const CONFIG_QUESTION_FRAME_PREFIX = /\b(?:what|which|how|report|bao cao|nao|gi)\b/;
+  const config = !sourceOrder && actionable.some((clause) => {
+    if (!CONFIG_NOUN.test(clause) || !CONFIG_MUTATION_VERB.test(clause)) return false;
+    if (CONFIG_REPORT_FRAME.test(clause)) return false;
+    const verb = CONFIG_MUTATION_VERB.exec(clause);
+    if (CONFIG_QUESTION_FRAME_PREFIX.test(clause.slice(0, verb.index))) return false;
+    const noun = CONFIG_NOUN.exec(clause);
+    return !CONFIG_CHANGE_REPORT_CLAUSE.test(clause) || Boolean(noun && noun.index > verb.index);
+  });
   const repository = Boolean(targetFile) || /[\w.-]+\.(?:json|ya?ml|toml|ini)\b/.test(text);
   // A status/result lookup ("check the suite output and report") orders no change: it needs a
   // lookup verb AND no mutation vocabulary anywhere in the request (fail-closed otherwise).
   const mutationWord = /\b(?:implement|fix|refactor|modify|edit|write|update|add|create|build|make|install|deploy|remove|delete|rename|replace|change|sua|viet|chinh|them|tao|xoa|doi|cai|cap nhat)\b/.test(text);
-  const statusReport = !mutationWord && !operation && !config
-    && /\b(?:check|status|report|show|summari[sz]e|result|results|kiem tra|bao cao|trang thai|ket qua|da len chua)\b/.test(text);
+  // A bounded, recognizable reporting QUESTION about what changed ("Tham số/cấu hình
+  // nào đã thay đổi, nếu có." / "which configuration has changed, if any") is a
+  // status report even without a lookup verb — but ONLY when no actionable clause
+  // actually orders a mutation: a mixed request ("Add a dark-mode button; report
+  // which configuration changed") keeps its implementation contract and evidence.
+  // The two lookbehinds keep a question's noun ("what change was made") and the
+  // Vietnamese past-tense verb "thay đổi" from counting as mutation orders.
+  const ACTIONABLE_MUTATION_ORDER = /(?<!\b(?:what|which|how|nao|gi)\s)(?<!thay )\b(?:implement|fix(?:es)?|refactor|modify|edit|write|update|add|create|build|make|install|deploy|remove|delete|rename|replace|change|sua|viet|chinh|them|tao|xoa|doi|cai|cap nhat)\b/;
+  const configReportQuestion = !actionable.some((clause) => ACTIONABLE_MUTATION_ORDER.test(clause))
+    && actionable.some((clause) => /\b(?:configuration|config|toggle|cau hinh|tham so)\b/.test(clause)
+      && CONFIG_CHANGE_REPORT_CLAUSE.test(clause));
+  const statusReport = (configReportQuestion || (!mutationWord
+      && /\b(?:check|status|report|show|summari[sz]e|result|results|kiem tra|bao cao|trang thai|ket qua|da len chua)\b/.test(text)))
+    && !operation && !config;
   const readOnly = (/\b(?:audit|inspect|review|analyze|analyse|explain|read|investigate|debug|forensic|root cause|kiem tra|phan tich|dieu tra|doc log|tim hieu)\b/.test(text.replace(/\bread[\s-]*only\b/g, ' ')) || statusReport)
     && !sourceOrder && !codeChangeVerb && !operation && !config;
   const taskKind = operation ? (sourceOrder || (nativeDomain !== 'scheduled-job' && codeChangeVerb) ? 'MIXED' : 'OPERATIONAL')

package/src/core/reviewPanelAggregate.js

@@ -37,12 +37,73 @@ const SEVERITIES = ['critical', 'important', 'minor'];
 // counted as absent and named in `unparsed`.
 export function parseVerdictBlock(text) {
   const src = String(text ?? '');
-  const verdictMatch = src.match(/^VERDICT\s*:\s*(APPROVED-WITH-MINOR|APPROVED|CHANGES-REQUESTED|CRITICAL)\s*$/im);
+  // `-` and `_` are one vocabulary: the handoff commands and some reviewers
+  // write `changes_requested` / `critical_block` while others write the hyphen
+  // forms — both spellings parse to the same canonical verdict so a blocking
+  // reviewer can never be dropped as unparsed while the panel approves.
+  // `[ \t]` (not `\s`) around the colon: `\s` would swallow the newline and
+  // let a stray word on the next line fabricate a verdict.
+  const verdictMatch = src.match(
+    /^VERDICT[ \t]*:[ \t]*(APPROVED[-_]WITH[-_]MINOR|APPROVED|CHANGES[-_]REQUESTED|CRITICAL[-_]BLOCK|CRITICAL)[ \t]*\r?$/im,
+  );
   if (!verdictMatch) return null;
+  const rawVerdict = verdictMatch[1].toUpperCase().replace(/_/g, '-');
+  const verdict = rawVerdict === 'CRITICAL-BLOCK' ? 'CRITICAL' : rawVerdict;
 
   const memberMatch = src.match(/^PANEL_MEMBER\s*:\s*(\S+)\s*$/im);
   const member = memberMatch && memberMatch[1] !== '-' ? memberMatch[1] : null;
 
+  // VERIFICATION_RERUN status (PASS | FAIL | NOT_RUN | N/A). The status may
+  // sit inline on the heading line AND/OR under the indented `result:` line —
+  // both positions are read, and an explicit FAIL or NOT_RUN in either wins
+  // over a PASS elsewhere (fail closed on contradiction). Bare prose
+  // (`N pass / M fail`) and a literal template echo (`VERIFICATION_RERUN:
+  // PASS | FAIL | …` — still carrying the `|` vocabulary) parse as no status,
+  // leaving the field null (= no required metadata → pre-existing behavior).
+  // FAIL = the re-run executed and failed; NOT_RUN = the required verification
+  // never executed — either blocks approval.
+  //
+  // Layout is read exhaustively and conservatively: `[ \t]` (not `\s`) after
+  // the heading colon so the match cannot swallow the newline before an
+  // indented child (a `result:` FIRST child used to be hidden this way), the
+  // global match reads REPEATED VERIFICATION_RERUN headers, and every
+  // `result:` child line of each header is collected so a contradictory
+  // second line cannot hide behind the first. FAIL/NOT_RUN dominate.
+  const STATUS_RANK = { FAIL: 3, NOT_RUN: 2, PASS: 1, 'N/A': 0 };
+  const statuses = [];
+  const commands = [];
+  const vrRe = /^VERIFICATION_RERUN[ \t]*:[ \t]*(.*)$/img;
+  let vr;
+  while ((vr = vrRe.exec(src)) !== null) {
+    const inline = vr[1].trim();
+    const inlineStatus = inline.includes('|') ? null : inline.match(/^(PASS|FAIL|NOT_RUN|N\/A)\b/i);
+    if (inlineStatus) statuses.push(inlineStatus[1].toUpperCase());
+    for (const line of src.slice(vr.index + vr[0].length).split('\n')) {
+      if (/^\S/.test(line)) break; // next top-level field ends this header's children
+      const result = line.match(/^[ \t]*result[ \t]*:[ \t]*(.*)$/i);
+      if (result) {
+        const status = result[1].trim().match(/^(PASS|FAIL|NOT_RUN|N\/A)\b/i);
+        if (status) statuses.push(status[1].toUpperCase());
+        continue; // keep reading — a contradictory later `result:` must still block
+      }
+      const command = line.match(/^[ \t]*command[ \t]*:[ \t]*(.*)$/i);
+      if (command) commands.push(command[1].trim());
+    }
+  }
+  const dominant = statuses.length > 0
+    ? [...statuses].sort((a, b) => STATUS_RANK[b] - STATUS_RANK[a])[0]
+    : null;
+  // Fail closed on applicability: an N/A claim beside a DECLARED executable
+  // command contradicts the block's own evidence — the required check exists,
+  // so the N/A counts as NOT_RUN (the check was not run). A placeholder
+  // command (`-`, `none`, `(none …)`, `n/a …`) or no command line keeps N/A
+  // legitimate for genuinely check-free reviews.
+  const hasExecutableCommand = commands.some((c) => {
+    const t = c.trim().toLowerCase();
+    return t !== '' && t !== '-' && t !== 'none' && !t.startsWith('(none') && !t.startsWith('n/a');
+  });
+  const verificationRerun = dominant === 'N/A' && hasExecutableCommand ? 'NOT_RUN' : dominant;
+
   const findings = { critical: [], important: [], minor: [] };
   const findingsMatch = src.match(/^FINDINGS:\s*$/im);
   if (findingsMatch) {
@@ -77,7 +138,7 @@ export function parseVerdictBlock(text) {
     }
   }
 
-  return { member, verdict: verdictMatch[1].toUpperCase(), findings };
+  return { member, verdict, findings, verificationRerun };
 }
 
 // Normalize a finding bullet for identity comparison: two members report the
@@ -127,8 +188,15 @@ export function aggregatePanelVerdicts(verdicts) {
   const hasCritical =
     parsed.some((p) => p.verdict === 'CRITICAL') || parsed.some((p) => p.findings.critical.length > 0);
 
+  // Fail closed on explicit verification evidence: a re-run that FAILED, or
+  // one never executed (NOT_RUN), cannot sit behind an approving prose
+  // verdict — the block stops counting toward approval entirely.
+  const hasBlockingVerification = parsed.some(
+    (p) => p.verificationRerun === 'FAIL' || p.verificationRerun === 'NOT_RUN',
+  );
+
   let verdict;
-  if (hasCritical || changeRequests >= 1 || parsed.length === 0) verdict = 'changes_requested';
+  if (hasCritical || changeRequests >= 1 || hasBlockingVerification || parsed.length === 0) verdict = 'changes_requested';
   else if (approvals >= 2) verdict = 'approved';
   else verdict = 'approved_minor';
 

package/template_project/.claude/agents/code-reviewer.md

@@ -16,6 +16,38 @@ You are the independent reviewer for UKit's handoff Quality Gate. Your model is
 - `code` (default, if not specified) — reviewing a handoff task diff. Follow **Code Review** below, unchanged.
 - `spec` | `plan` — reviewing a document (e.g. `docs/plans/*.md`), no diff/task file/executor report involved. Skip straight to **Spec/Plan Review** at the end of this file instead.
 
+## REVIEW_KIND (code reviews only)
+
+Set one kind per review — from the task's own classification when the spawning
+command names one, else from what the diff shows:
+
+- `product` (default when the diff changes source or tests) — the full Code
+  Review rubric below applies unchanged, including Test Plan adherence and
+  RED_OUTPUT evidence.
+- `integration-evidence` — the diff verifies or mirrors behavior already
+  accepted elsewhere (template mirrors, parity copies, runtime/docs evidence).
+  The new-tests + RED_OUTPUT TDD requirements are inapplicable when the task
+  introduces no new behavior under test; review the evidence chain instead and
+  never fabricate tests or edits to satisfy them.
+- `status-only` — the task only records status/evidence; an empty diff is
+  legitimate. Review the executor report and verification output on disk.
+
+The review kind scopes only the implementation-TDD evidence (new tests +
+RED_OUTPUT). It never waives the required executable checks — the task's
+Verification Commands still re-run in your session (fresh PASS or the severity
+ladder applies; `NOT_RUN` on a required command blocks in every kind) — and it
+never lowers the task's original acceptance criteria.
+
+**Verdict ≠ acceptance.** The review verdict and the task's original acceptance
+are separate judgments. An `integration-evidence` review may legitimately be
+`APPROVED` as a review (the evidence chain is sound and complete) while the
+verdict's NOTES/BLOCKING explicitly report that product acceptance remains
+unmet or pending external observation — that report flows through
+`NEXT_STATUS_FOR_INDEX`/the task discussion and must not flip the product task
+to `done` or close a pending parent item. A `status-only` recording is
+bookkeeping, not an independent review pass: it never counts as evidence that
+independent review approved the underlying work.
+
 ## Code Review (REVIEW_TARGET_TYPE=code)
 
 ### Inputs you expect
@@ -29,7 +61,7 @@ If any input is missing, return `CHANGES-REQUESTED` with reason "incomplete hand
 ### Review order
 
 0. **Verification package completeness** — Check whether the project has a lint or typecheck script (`package.json` scripts, or the stack's equivalent). If it does and the task's Verification Commands don't run it, that is `CHANGES-REQUESTED`: "verification commands missing lint/typecheck — re-run planner or add the command and re-verify" — do this before anything else below.
-1. **Test Plan adherence** — Were all tests in §4 actually implemented, including the ≥2 edge cases required by `handoff.plan.minTestsEdgeCase`? Check the Executor Report's `RED_OUTPUT` field: it must contain actual failing-test output (assertion failure, stack trace, non-zero exit), not a bare claim like "confirmed" or "yes". Missing or vague `RED_OUTPUT` → `CHANGES-REQUESTED`: "no evidence tests were RED before implementation — re-run TDD cycle and paste real output". Then run the tests yourself: `<task Verification Commands>`. Fresh PASS required, no trusting executor's output blindly.
+1. **Test Plan adherence (REVIEW_KIND=product)** — Were all tests in §4 actually implemented, including the ≥2 edge cases required by `handoff.plan.minTestsEdgeCase`? Check the Executor Report's `RED_OUTPUT` field: it must contain actual failing-test output (assertion failure, stack trace, non-zero exit), not a bare claim like "confirmed" or "yes". Missing or vague `RED_OUTPUT` → `CHANGES-REQUESTED`: "no evidence tests were RED before implementation — re-run TDD cycle and paste real output". For `integration-evidence`/`status-only` reviews that TDD evidence is inapplicable — grade the task's own evidence chain instead of demanding new tests or RED_OUTPUT. Either way, run the required checks yourself: `<task Verification Commands>`. Fresh PASS required, no trusting executor's output blindly.
 2. **Correctness** — Does the diff implement the requested behavior? Any obvious wrong assumptions, stale refs, missing cases?
 3. **Regression risk** — What existing behavior could this break? Are shared paths/tests/contracts still aligned? Run the wider suite only when the diff touched shared code; otherwise the task's own targeted commands are the gate and the wave-boundary full `yarn test` (see docs/AI_HANDOFF/RULES.md "Test selection") is the regression net.
 4. **Safety / security / data loss** — Destructive actions, auth/permission, path handling, unsafe shell/DB/file ops.
@@ -76,13 +108,14 @@ model, so reviewer ≠ executor still stands.
 ## Reviewer Verdict
 
 VERDICT: APPROVED | APPROVED-WITH-MINOR | CHANGES-REQUESTED | CRITICAL
+REVIEW_KIND: product | integration-evidence | status-only
 REVIEWER_MODEL: [model name actually used]
 EXECUTOR_MODEL: [from executor report]
 PANEL_MEMBER: [panel tier — `smart`/`code`/`lite`, or `solo` when the panel degenerates; `-` outside panel runs]
 AGREEMENT_MAP: [lead member only — finding → panel members reporting it, from review-panel-aggregate.mjs output; `-` otherwise]
-VERIFICATION_RERUN:
-  command: [exact command]
-  result: [N pass / M fail]
+VERIFICATION_RERUN: PASS | FAIL | NOT_RUN | N/A
+  command: [exact command, or `-` when N/A]
+  result: [N pass / M fail — or NOT_RUN — <reason>, or N/A — <reason>]
 TEST_PLAN_COVERAGE: [all-followed | partial — list gaps | missing — list]
 FINDINGS:
   critical:
@@ -103,7 +136,7 @@ After writing the verdict, update `docs/AI_HANDOFF/INDEX.md` row for this task:
 TASK: TASK-xxx
 VERDICT: approved | approved_minor | changes_requested | critical_block
 REVIEWER_MODEL: <exact model ID>
-VERIFICATION_RERUN: PASS | FAIL
+VERIFICATION_RERUN: PASS | FAIL | NOT_RUN | N/A (+ one-line reason for NOT_RUN/N/A)
 BLOCKING: <one line per critical/important finding, or "none">
 ```
 
@@ -139,7 +172,9 @@ Same model is the most common silent failure. Do not skip this check.
 ### Rules
 
 - **Always re-run** the task's Verification Commands. If they fail, VERDICT = CRITICAL regardless of executor claims.
-- If executor said `TEST_PLAN_FOLLOWED: N/A` without a real justification, downgrade to at minimum CHANGES-REQUESTED.
+- **VERIFICATION_RERUN is evidence, not prose.** `NOT_RUN` = the required verification never executed in your session (blocked, timed out, environment unavailable); `FAIL` = the re-run executed and did not pass. Either one must never accompany APPROVED or APPROVED-WITH-MINOR — with `NOT_RUN` the verdict is at most CHANGES-REQUESTED, and with `FAIL` it is CRITICAL per the ladder above. State the blocking status once, with the reason — a contradicting second line (e.g. header `PASS` next to `result: NOT_RUN`) is read fail-closed: the blocking status wins. `N/A` is only legitimate when this review has no executable required checks (e.g. a read-only spec/plan review, with `command: -` or no command line); when the task package defines Verification Commands, the re-run is required, so an `N/A` claim there counts as `NOT_RUN`. An `N/A` result that sits beside a declared executable `command:` (e.g. `command: yarn test`) contradicts its own evidence and counts as `NOT_RUN` — the aggregator fails it closed too. Never fabricate a PASS — a fabricated rerun is a fake test → CRITICAL.
+- If executor said `TEST_PLAN_FOLLOWED: N/A` without a real justification, downgrade to at minimum CHANGES-REQUESTED (REVIEW_KIND=product; a check-free `integration-evidence`/`status-only` review may declare N/A legitimately when no Test Plan applies — the required Verification Commands still re-run).
+- Verdict spelling is `-`/`_`-insensitive at the aggregator: `CHANGES_REQUESTED`, `CRITICAL_BLOCK`, `APPROVED_WITH_MINOR` parse to the same canonical verdicts as the hyphen forms, so write either spelling — a blocking verdict is never dropped as unparsed.
 - Never approve when test file has no real `expect`/`assert` - that is a fake test -> CRITICAL.
 - Keep the verdict block <= 30 lines. Findings are bullet points, not essays.
 - The same-model refusal above is non-negotiable: bypassing it defeats the entire Quality Gate.

package/template_project/.claude/commands/ukit/handoff-fullstack.md

@@ -59,8 +59,8 @@ resumable. If compaction does happen, the run resumes from the cursor automatica
 
 ### Run cursor — write after every step
 
-Maintain `docs/AI_HANDOFF/RUN.md`. Rewrite it (whole file, 7 lines) immediately after every
-numbered step completes:
+Maintain `docs/AI_HANDOFF/RUN.md`. Rewrite it (whole file — the fixed field block below,
+exactly as many lines as the fields in play) immediately after every numbered step completes:
 
 ```
 Command: handoff-fullstack
@@ -71,8 +71,21 @@ Cursor: wave <N> batch <M> — <what just finished>
 Next: <the exact next step to run>
 ExitPredicate: all(<term>[,<term>...])   # written once at P2; never relaxed
 QuietScans: <n>/<required>   # only while sweeping for stragglers near the end
+Acceptance: <the acceptance line the CurrentTask must satisfy>   # optional
+CurrentTask: <TASK-xxx>   # optional; the single task mid-flight right now
+RetryFingerprint: <stable id of the failing step>   # optional; retry-loop identity
+RetryCount: <n>   # optional; consecutive attempts of that fingerprint
 ```
 
+**Compact-carry fields.** `Acceptance`, `CurrentTask`, `RetryFingerprint` and `RetryCount`
+are what a compacted session carries forward — these four lines plus `Goal`/`Next:`, never
+the full subagent prompts. The SessionStart resume hook prints them verbatim after a
+compact. On resume, work from the cursor: read `RUN.md` + `INDEX.md` and make a bounded
+read of only the section for the active phase in this file — never a full re-read of the
+whole command. Retry rule: a `RetryFingerprint` whose `RetryCount` has reached
+`orchestration.maxAttemptsPerFailure` (2) must continue with a changed strategy, never the
+same edit again.
+
 `ExitPredicate` grammar: `all(<term>[,<term>...])` or a single term; terms are
 `index:all-done`, `git:clean`, `file-exists:<relpath>`; goal-level runs add
 `agents:none-running` and `verify:pass` (an unprovable term reads as unmet, never
@@ -126,8 +139,10 @@ Wherever a step below says **verify the write**, it means this rule.
 If `docs/AI_HANDOFF/RUN.md` exists with `Phase:` not `done` or `blocked`, this is a
 **continuation, not a new cycle**. Do NOT re-plan, do NOT overwrite `PLAN.md`, do NOT ask
 the human whether to continue. Read the cursor, then jump straight to `Next:` and carry on.
-Tasks already `done` or `pending_review` are skipped; only `ready`, `in_progress`,
-`changes_requested` and `blocked` tasks are picked up.
+Tasks already `done` are skipped. `pending_review` tasks are NOT re-implemented — they go to
+the R-phase review (R2–R4). `ready`, `in_progress`, `changes_requested` and `blocked` tasks
+are routed to implementation/fix (I-phase). Any nonterminal state gets a branch; none is
+skipped silently.
 
 `Phase: blocked` is terminal for the run — the machinery (Stop gate, hooks, stop-coordinator)
 all treats it as closed. It is *paused*, not abandoned: an explicit `/ukit:handoff-fullstack`
@@ -387,7 +402,15 @@ If the lite agent reports it has no shell/Bash tool (or its shell call is reject
 - `docs/AI_HANDOFF/ACTIVE.md` → get `Base: <BASE>`
 - `docs/AI_HANDOFF/INDEX.md` → collect all `ready` tasks
 
-If no ready tasks → report and stop.
+Branch on the nonterminal states — never report-and-stop while work is nonterminal:
+- `pending_review` tasks exist → route to R1/R2 (review), do not implement them.
+- `changes_requested` tasks exist → route to the I-phase fix round for those tasks.
+- `in_progress` / stale `blocked` tasks exist → apply the Recovery rule below (finish in place
+  or supersede with `-R1`).
+- No `ready` task but any of the above exists → continue the independent authorized work
+  in the other branches; a blocked branch does not block unrelated tasks.
+- Only when every task is `done`/`cancelled_superseded` (or dependency-blocked with a recorded
+  reason) does this step end the wave with nothing to implement, and the run moves to R/F.
 
 Verify working tree is clean after the plan commit:
 ```bash
@@ -625,7 +648,12 @@ PLAN_COMMIT=$(git log --format=%H --grep='^handoff: plan' -n 1)
 git diff $PLAN_COMMIT   # all handoff changes: committed waves + anything uncommitted
 ```
 
-If that diff is empty → implement was not completed. Do not stop: re-enter Phase 3 from the run cursor with the remaining `ready` tasks.
+Classify the review by what the diff can show — an empty diff is NOT automatically "implement incomplete":
+- **Product review** (the tasks change source/tests): an empty diff means implementation did not land. Re-enter Phase 3 from the run cursor with the remaining `ready` tasks.
+- **Integration-evidence review** (the tasks verify behaviour, docs or runtime evidence without source edits): an empty diff is expected. Review the executor reports and the verification output on disk; a read-only evidence verdict is legitimate.
+- **Status-only recording** (the task only moves status / records a verdict): an empty diff is expected. Write the status through the verify-the-write rule; do not edit source to make the diff non-empty.
+
+Never make fake edits or fake tests to satisfy an empty diff, and never lower acceptance criteria to pass a review. Declaring P00 complete is not implied by any of the above. The review verdict and the original task acceptance are separate judgments: an integration-evidence review may approve the evidence chain while explicitly reporting product acceptance unmet or pending external observation — that report must not flip the product task to done — and a status-only recording is bookkeeping, never an independent review pass.
 
 > Orchestrator (this session) handles the R1 guard check directly.
 
@@ -650,7 +678,7 @@ The spawned reviewer agent reads `EXECUTOR_MODEL` from each task file `## Execut
 <each command from §Verification Commands across all pending_review tasks>
 ```
 
-If any command fails → verdict `critical_block`. Stop. Do NOT proceed to R4.
+If any command fails → `VERDICT: CRITICAL` (`NEXT_STATUS_FOR_INDEX: critical_block`) for this task. This task's R4 write-up stops here — task-local, not run-local: the task enters the R4.5 auto-fix loop and the remaining batch tasks continue. Do NOT proceed to R4 for this task.
 
 ### R4 — Review unified diff + append verdict (strong model)
 
@@ -666,25 +694,29 @@ Stage gate (unic-decision): reviewers still generate findings; when `decisionPla
 Append verdict to each task file:
 ```
 ## Reviewer Verdict
-VERDICT: approved | approved_minor | changes_requested | critical_block
+VERDICT: APPROVED | APPROVED-WITH-MINOR | CHANGES-REQUESTED | CRITICAL
 REVIEWER_MODEL: <your exact model ID>
 EXECUTOR_MODEL: <from Executor Report>
-VERIFICATION_RERUN: PASS | FAIL
+REVIEW_KIND: product | integration-evidence | status-only
+VERIFICATION_RERUN: PASS | FAIL | NOT_RUN | N/A
 FINDINGS:
   critical: <file:line — what fails> | none
   important: <file:line — risk> | none
   minor: <style/naming> | none
-NEXT_STATUS_FOR_INDEX: <status>
+NEXT_STATUS_FOR_INDEX: approved | approved_minor | changes_requested | critical_block
 ```
 
+`VERDICT:` uses the aggregator's canonical hyphen vocabulary — underscore spellings (`changes_requested`, `critical_block`, `approved_with_minor`) parse to the same verdicts, so a blocking reviewer is never dropped as unparsed. `NOT_RUN` = the required re-run never executed in your session; `FAIL` = it executed and failed; either blocks approval. `N/A` is legitimate only when this review has no executable required checks (`command: -` or none) — an `N/A` beside a declared executable `command:` counts as `NOT_RUN`. `REVIEW_KIND` comes from the R1 classification; it scopes only the implementation-TDD evidence (new tests + RED_OUTPUT) — required executable checks and the task's original acceptance criteria are never waived, and approving an evidence review never marks product acceptance met.
+
 Then return to the orchestrator **at most 6 lines** — the full verdict is already on disk:
 ```
 TASK: TASK-xxx
 VERDICT: approved | approved_minor | changes_requested | critical_block
 REVIEWER_MODEL: <exact model ID>
-VERIFICATION_RERUN: PASS | FAIL
+VERIFICATION_RERUN: PASS | FAIL | NOT_RUN | N/A (+ one-line reason)
 BLOCKING: <one line per critical/important finding, or "none">
 ```
+The return `VERDICT:` carries the NEXT_STATUS_FOR_INDEX vocabulary; the on-disk block's `VERDICT:` field uses the canonical hyphen vocabulary above.
 Do not paste the diff, the findings prose, or verification logs back into the orchestrator.
 
 ### R4.5 — Auto-fix loop (max 2 rounds)

package/template_project/.claude/commands/ukit/handoff-review.md

@@ -47,8 +47,9 @@ git diff --stat $PLAN_COMMIT   # every handoff change: wave commits + working tr
 git status                     # no handoff branches/worktrees should remain
 ```
 
-If that diff is empty → handoff-implement was not completed. Report which tasks are still
-`ready` and stop; there is nothing to review yet.
+Classify by what the diff can show. An empty diff is NOT automatically "implement incomplete":
+- If `pending_review` tasks exist and the diff is empty, check the task kind first. A product task (changes source/tests) with an empty diff means implementation did not land — report those tasks as still `ready`, do not review them. An evidence-only or status-only task with an empty diff is a legitimate read-only review: review the executor report and verification output on disk, never create fake edits or fake tests to make the diff non-empty, and never lower acceptance criteria.
+- If there are no `pending_review` tasks at all, report which tasks are still `ready` and stop; there is nothing to review yet.
 
 ## Step 2 — Review the diff
 
@@ -58,6 +59,20 @@ If that diff is empty → handoff-implement was not completed. Report which task
 
 Degenerate panel: if `modelRoles['review-panel']` is empty or has one entry, spawn a single reviewer and require `PANEL_MEMBER: solo` in its verdict.
 
+**omp `tasks[]` dispatch — ordinary entries only.** When batching reviewers through the omp `task` tool, every `tasks[]` entry carries only the fields ordinary dispatch supports — `agent`, `name`, `task` — and nothing else:
+
+```yaml
+tasks:
+  - agent: "code-reviewer"
+    name: "TASK-001-smart"
+    task: "Review docs/AI_HANDOFF/tasks/TASK-001.md per /ukit:handoff-review Step 2a-2d. PANEL_MEMBER: smart. Return at most 6 lines."
+  - agent: "code-reviewer"
+    name: "TASK-001-code"
+    task: "Review docs/AI_HANDOFF/tasks/TASK-001.md per /ukit:handoff-review Step 2a-2d. PANEL_MEMBER: code. Return at most 6 lines."
+```
+
+Never add fields ordinary dispatch does not support: `sourceSession` and a per-task `model` are not supported there — omp 18.12.5 batch validation rejects them deterministically (confirmed in the installed binary's validator; not advertised as a live-probe pass) — and model binding comes from agent frontmatter via `modelRoles`, never from a task field. There is no seance workaround for reviewer dispatch. A deterministic validation rejection is never retried with identical args. A retry is allowed only after a relevant argument changes — `agent`, or the `tasks[]` entry's unsupported-field set (removing `sourceSession`/`model`). Prompt reword, `read`, and `status` text are NOT relevant changes: they never make a retry legitimate and never reset the failure budget, which stays the existing `maxAttemptsPerFailure: 2`. When that budget is spent, preserve across resume — in the task's `## Discussion` or the `RUN.md` cursor — a compact normalized error (prose stripped) plus the relevant key fingerprint and the attempt count, mark that task's verification `NOT_RUN` (never `PASS` — unverified work is not verified), and continue with independent tasks. Host pre-hook rejection behavior is unknown: never assume a hook will or will not catch the same call.
+
 Each spawned reviewer agent performs 2a–2d below per task:
 
 ### 2a — Model isolation check (always first)
@@ -77,7 +92,7 @@ Read `EXECUTOR_MODEL` from each task file `## Executor Report`.
 <each command from §Verification Commands across all tasks>
 ```
 
-If any command fails → verdict: `critical_block` for this task. That ends **this task's**
+If any command fails → `VERDICT: CRITICAL` with `NEXT_STATUS_FOR_INDEX: critical_block` for this task. That ends **this task's**
 review, not the run — the orchestrator picks it up in Step 3's auto-fix loop.
 
 ### 2c — Review unified diff
@@ -97,26 +112,30 @@ matches the task file's wording.
 
 ```
 ## Reviewer Verdict
-VERDICT: approved | approved_minor | changes_requested | critical_block
+VERDICT: APPROVED | APPROVED-WITH-MINOR | CHANGES-REQUESTED | CRITICAL
 REVIEWER_MODEL: <your exact model ID>
 EXECUTOR_MODEL: <from Executor Report>
+REVIEW_KIND: product | integration-evidence | status-only
 PANEL_MEMBER: <panel tier | solo | ->
-VERIFICATION_RERUN: PASS | FAIL
+VERIFICATION_RERUN: PASS | FAIL | NOT_RUN | N/A
 FINDINGS:
   critical: <file:line — what fails> | none
   important: <file:line — risk> | none
   minor: <style/naming> | none
-NEXT_STATUS_FOR_INDEX: <status>
+NEXT_STATUS_FOR_INDEX: approved | approved_minor | changes_requested | critical_block
 ```
 
+`VERDICT:` uses the aggregator's canonical hyphen vocabulary — underscore spellings (`changes_requested`, `critical_block`, `approved_with_minor`) parse to the same verdicts, so a blocking reviewer is never dropped as unparsed. `NOT_RUN` = the required re-run never executed in your session; `FAIL` = it executed and failed; either blocks approval. `N/A` is legitimate only when this review has no executable required checks (`command: -` or none) — an `N/A` beside a declared executable `command:` counts as `NOT_RUN`. `REVIEW_KIND` comes from the Step 1 classification; it scopes only the implementation-TDD evidence (new tests + RED_OUTPUT) — required executable checks and the task's original acceptance criteria are never waived, and approving an evidence review never marks product acceptance met.
+
 Then return to the orchestrator **at most 6 lines** — the full verdict is already on disk:
 ```
 TASK: TASK-xxx
 VERDICT: approved | approved_minor | changes_requested | critical_block
 REVIEWER_MODEL: <exact model ID>
-VERIFICATION_RERUN: PASS | FAIL
+VERIFICATION_RERUN: PASS | FAIL | NOT_RUN | N/A (+ one-line reason)
 BLOCKING: <one line per critical/important finding, or "none">
 ```
+The return `VERDICT:` carries the NEXT_STATUS_FOR_INDEX vocabulary; the on-disk block's `VERDICT:` field uses the canonical hyphen vocabulary above.
 Do not paste the diff, the findings prose, or verification logs back into the orchestrator.
 
 ### 2e — Aggregate the panel + lead bucketing
@@ -135,7 +154,14 @@ changes, or zero parseable verdict blocks — it fails closed; else
 (round N)` blocks supersede earlier rounds.
 `consensus≥2 identical findings = high signal` — a finding reported by two or more
 members is high-signal. The consensus verdict, not any single member's vote, drives
-`NEXT_STATUS_FOR_INDEX`.
+`NEXT_STATUS_FOR_INDEX`. The aggregate reads every `VERIFICATION_RERUN` header and
+`result:` line in a block and fails closed: `FAIL`/`NOT_RUN` in any position —
+including repeated or contradicting headers — block approval, and an `N/A` beside a
+declared executable command counts as `NOT_RUN` (a placeholder `command: -` or no
+command line keeps a genuine no-check review legitimate). Underscore verdict aliases
+parse to the canonical hyphen verdicts, so a member following the template always
+votes; a genuinely unparsable block never votes (named in `UNPARSED`), and zero
+parseable blocks fail closed to `changes_requested`.
 
 Then the **lead member** (first entry in `modelRoles['review-panel']` = the judgment
 tier) applies the lead-judgment buckets to every finding — **Act on** / **Consider** /

package/template_project/.claude/hooks/handoff-resume.sh

@@ -216,6 +216,13 @@ async function emitOrdinaryResume(payload, source) {
   const base = field('Base');
   const cursor = field('Cursor');
   const next = field('Next');
+  // Compact-resume carry (bounded): the goal/acceptance, current task and retry
+  // fingerprint+count survive compaction without re-reading the full prompt or the
+  // whole command file. Absent fields are simply omitted.
+  const acceptance = field('Acceptance');
+  const currentTask = field('CurrentTask');
+  const retryFingerprint = field('RetryFingerprint');
+  const retryCount = field('RetryCount');
 
   // The session's CURRENT handoff intent — structured transcript evidence, the
   // same shared module the Stop gate uses. A session whose latest request is
@@ -287,15 +294,22 @@ async function emitOrdinaryResume(payload, source) {
     `  Phase:  ${phase}`,
     `  Cursor: ${cursor || '(not recorded)'}`,
     `  Next:   ${next || '(not recorded)'}`,
+    ...(acceptance ? [`  Acceptance: ${acceptance}`] : []),
+    ...(currentTask ? [`  CurrentTask: ${currentTask}`] : []),
+    ...(retryFingerprint ? [`  RetryFingerprint: ${retryFingerprint} (RetryCount: ${retryCount || '0'})`] : []),
     '',
     'This is a CONTINUATION, not a new cycle. Do not re-plan, do not overwrite PLAN.md or the',
     'task files, and do not ask the user whether to continue — they already asked for a',
     'one-shot run and the pipeline was interrupted, not cancelled.',
     '',
     'Read docs/AI_HANDOFF/RUN.md and docs/AI_HANDOFF/INDEX.md, then execute the `Next:` step',
-    'above using .claude/commands/ukit/handoff-fullstack.md as the procedure. Skip tasks',
-    'already `done` or `pending_review`; pick up `ready`, `in_progress`, `changes_requested`',
-    'and `blocked` ones. Keep writing the cursor after every step.',
+    'above with a bounded read of only the section for the active phase in',
+    '.claude/commands/ukit/handoff-fullstack.md — never a full re-read of the file. Route',
+    'tasks by status: `done` is skipped; `pending_review` goes to the R-phase review (it is',
+    'reviewed there, not re-implemented); `ready`, `in_progress`, `changes_requested` and',
+    '`blocked` are picked up for implementation/fix. Keep writing the cursor after every step.',
+    'If a retry loop was live (RetryFingerprint + RetryCount above), continue it: same',
+    'fingerprint at/over two attempts requires a changed strategy, never the same edit again.',
   ];
 
   if (source === 'compact') {