@ngockhoale/ukit 3.4.49 → 3.4.51

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

@@ -15,6 +15,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
@@ -28,7 +60,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.
@@ -75,13 +107,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 — `@slow`/`@default`/`@smol`, 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:
@@ -102,7 +135,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">
 ```
 
@@ -138,7 +171,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/.omp/hooks/pre/ukit-bridge.js

@@ -29,6 +29,7 @@ import {
 // drift apart (a configured 60-120s chain used to be killed here at 14-20s, which
 // for Edit|Write is a fail-closed transport failure = every edit blocked).
 import { resolveChainExecTimeoutMs } from '../../../.claude/ukit/runtime/hook-chain-budget.mjs';
+import { preflightOmpTaskDispatch } from '../../../.claude/ukit/runtime/omp-task-dispatch-guard.mjs';
 
 // OMP-3 (TASK-002): pi.exec forwards only {cwd, signal, timeout} to its spawn —
 // an environment option is dropped (verified against the bundled omp exec), and the host's
@@ -276,6 +277,27 @@ function runtimeMetadata(event = {}, context = {}) {
   };
 }
 
+// OMP 18.12.5 before_agent_start has no origin field. Recover only the nearest
+// native prompt-bearing branch entry, never a prefix claimed by prompt text.
+export function promptOriginFromBranch(prompt, context = {}) {
+  try {
+    const branch = context?.sessionManager?.getBranch?.();
+    if (!Array.isArray(branch)) return 'user';
+    for (let i = branch.length - 1; i >= Math.max(0, branch.length - 64); i -= 1) {
+      const entry = branch[i];
+      if (entry?.type === 'message' && entry.message?.role === 'user') return 'user';
+      const custom = entry?.type === 'custom_message' ? entry
+        : entry?.type === 'message' && entry.message?.role === 'custom' ? entry.message : null;
+      if (!custom || custom.customType !== 'session-stop-continuation') continue;
+      return custom.attribution === 'agent' && typeof custom.content === 'string'
+        && custom.content.trim() === String(prompt ?? '').trim() ? 'system' : 'user';
+    }
+  } catch {
+    // Older hosts or a closed session may not expose branch metadata.
+  }
+  return 'user';
+}
+
 function buildHookPayload(hookEventName, fields = {}) {
   const payload = { hook_event_name: hookEventName, ukit_harness: 'omp' };
   const mappings = [
@@ -290,6 +312,7 @@ function buildHookPayload(hookEventName, fields = {}) {
     ['prompt', 'prompt'],
     ['transcriptPath', 'transcript_path'],
     ['source', 'source'],
+    ['promptOrigin', 'ukit_prompt_origin'],
     ['subagentSession', 'ukit_subagent_session'],
   ];
   for (const [field, payloadField] of mappings) {
@@ -892,6 +915,20 @@ export async function runToolCall(pi, event, { projectRoot, context: extensionCo
     : [];
 
   const metadata = runtimeMetadata(event, extensionContext);
+  // Only the native OMP task tool uses this schema. Block, never rewrite: ordinary
+  // agents must omit seance-only fields, including empty/null placeholders. Some
+  // host versions may reject arguments before tool_call; that remains native-owned.
+  if (String(rawToolName ?? '').trim().toLowerCase() === 'task') {
+    const state = await readRouteState(projectRoot, { session_id: metadata.sessionId });
+    const dispatch = await preflightOmpTaskDispatch({
+      projectRoot, sessionId: metadata.sessionId, taskInstanceId: state?.taskInstanceId,
+      args: event.input,
+    });
+    if (dispatch.action === 'block') {
+      return { block: true, toolName: 'Task', invoked: [], context: [],
+        reason: `UKit OMP task preflight: ${dispatch.guidance}` };
+    }
+  }
   const payload = buildHookPayload('PreToolUse', {
     toolName,
     toolInput: normalizeToolInput(toolName, event.input),
@@ -981,6 +1018,7 @@ export async function runBeforeAgentStart(pi, event, { projectRoot, context: ext
   const metadata = runtimeMetadata(event, extensionContext);
   const payload = buildHookPayload('UserPromptSubmit', {
     prompt: event.prompt,
+    promptOrigin: promptOriginFromBranch(event.prompt, extensionContext),
     ...metadata,
   });
   const result = await runScriptChain(pi, HOOK_EVENT_MAP.before_agent_start, payload, { projectRoot });