valent-pipeline 0.19.59 → 0.19.61

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "valent-pipeline",
-  "version": "0.19.59",
+  "version": "0.19.61",
   "description": "v3 multi-agent AI pipeline for software development lifecycle",
   "type": "module",
   "bin": {

package/pipeline/steps/qa-a/write-spec.md

@@ -89,6 +89,10 @@ For each NFR-sensitive path: `[NFR-PERF]` response time + load patterns; `[NFR-S
 
 **The validating test a WS-driven sanction names MUST be a true end-to-end reachability case — never a service-layer test that bypasses the live event path.** When the UXA spec carries a Step 6b reachability contract for a WS-driven screen, author a REQUIRED `e2e` acceptance case that **drives the real triggering event over the actual connection** (register/login → issue the WS command → assert the screen leaves loading and renders), then sanction the matching visual checkpoint to it. A test that calls the service/handler layer directly (e.g. asserts `POST /api/careers` or the service method) can pass green while the **live WS command path is structurally broken** — a missing initial-state push, or a bootstrap command that violates a pre-event invariant (writing an FK row keyed on an id that does not exist until the event lands). That gap stays invisible until the visual gate a full attempt later. The reachability case is what forces the live path; the service-layer test is necessary but NOT sufficient to back a sanction.
 
+**`na` is for genuinely browser-UNDRIVABLE events — NOT a fallback for a screen the MCP merely failed to reach.** Eligible: a WS event NO browser action can trigger on a correctly-built app — a server-INITIATED push (a phase that advances on a timer, a cross-session/another-player event, a connection severed mid-session). NOT eligible: a WS event a USER ACTION triggers — clicking "Start Career" → `career.create` → the in-career screen mounts — is browser-drivable and MUST be verified for real (a real screenshot), never sanctioned. If the MCP "can't drive" such a user-triggered flow, the cause is almost always the APP, not the gate — an unstyled / zero-layout / zero-CSS shell where clicks and fills don't land on the handlers (class-presence passing is not pixel-rendering). The fix is to make the app render and be drivable (a styling/build story), then verify for real — not to `na` the checkpoint away and permanently forfeit its pixel verification. When in doubt between "undrivable" and "app is broken", assume app-is-broken and do NOT sanction.
+
+**Sanction a shared prerequisite as a SET — never a subset.** When several checkpoints depend on the SAME genuinely-undrivable WS prerequisite (e.g. every in-career VV checkpoint needs the same `career.created` push), sanction them ALL `N/A (sanction)`, each naming its validating e2e case — or sanction NONE. A partial sanction (some `na`, some left BLOCKED under the identical prerequisite) is itself the defect: the gate runs, the un-sanctioned siblings come back BLOCKED, and JUDGE rejects on them while the `na` ones pass. The Step 6b reachability contract (UXA) enumerates exactly which VV-IDs a prerequisite blocks — sanction precisely that set.
+
 ## Step 9b: Test Quality Bar — make every case implementable AND falsifiable
 
 The dev agents implement exactly what you specify, and CRITIC rejects tests that are weak, unfalsifiable, or bound to the wrong artifact. Spec the bar IN so it is built right the first time (each rule below traces to a real rework cycle):

package/pipeline/steps/uxa/translate-spec.md

@@ -49,8 +49,10 @@ For EACH WS-driven screen, document its **reachability contract**:
 | **Initial-state-push payload** | The exact state fields the event MUST push so the screen's loading state resolves to active — name them (e.g. `school_name`, `season`, `current_phase`); "sends state" is not enough |
 | **Pre-event session state** | What exists BEFORE the event (e.g. session keyed on a player/user id, no record yet) — flags bootstrap commands that must NOT assume post-event invariants (FK rows, ids that do not exist until the event lands) |
 | **Unreachable-if** | The concrete failure: which screen hangs in which state if the push (or the bootstrap command) is missing/broken |
+| **Trigger kind** | USER-ACTION (a click/submit sends the WS command, e.g. "Start Career" → `career.create`) or SERVER-INITIATED (a timed phase advance, a cross-session/another-player event, a mid-session disconnect). Decides visual coverage below |
+| **Blocked visual checkpoints** | The exact VV-IDs whose setup needs this prerequisite — so QA-A sanctions precisely that SET, never a subset (Step 9) |
 
-Each contract becomes a REQUIRED end-to-end reachability acceptance case in QA-A (drive the real event → assert the screen renders), and the matching PMCP visual checkpoint is sanctioned `N/A` (the stateless browser MCP cannot drive a persistent WS event — see QA-A Step 9). A screen reachable via a plain HTTP load only is out of scope — this is for event-driven reachability.
+Each contract becomes a REQUIRED end-to-end reachability acceptance case in QA-A (drive the real event → assert the screen renders). **Visual coverage depends on Trigger kind, NOT on "it's WS":** a USER-ACTION-triggered screen IS browser-drivable (the MCP performs the click/fill that sends the command) and MUST be visually verified FOR REAL — do NOT sanction it `N/A`; if the MCP can't drive it the cause is usually an unstyled/zero-layout app, which is a styling/build fix, not a sanction. Only a SERVER-INITIATED event the browser genuinely cannot trigger is `N/A`-eligible (QA-A Step 9), and then the whole blocked-VV set is sanctioned together, each naming its e2e case. A screen reachable via a plain HTTP load only is out of scope — this is for event-driven reachability.
 
 ## Step 7: Accessibility Checklist (WCAG AA)
 

package/src/commands/crosscheck.js

@@ -12,7 +12,7 @@ import { join } from 'path';
 import { randomBytes } from 'crypto';
 import { crosscheckVerdict, formatCrosscheck } from '../lib/crosscheck.js';
 import { extractFencedBlock } from '../lib/handoff.js';
-import { evidenceDir, latestPins, resolveRoot, utcCompact, latestAssert, authenticateBaseline } from '../lib/evidence.js';
+import { evidenceDir, latestPins, resolveRoot, utcCompact, latestAssert, assertPassedCountsForLabel, authenticateBaseline } from '../lib/evidence.js';
 
 const GATE_ARTIFACTS = {
   judge: 'judge-decision.md',
@@ -67,6 +67,11 @@ export async function crosscheckCmd(options) {
   // verify — the bare "newest assert" let a later red/acceptance assert shadow the qa-b green one.
   const expect = options.expect === 'red' ? 'red' : 'green';
   const got = latestAssert(evDir, { label: options.label || null, expect });
+  // Multi-suite label-multiplexing (2026-06-25): passed-counts of every green assert UNDER THE GATE'S
+  // LABEL, so the crosscheck can tell a real sibling-suite count (a run JUDGE legitimately counted)
+  // from a fabricated testsPassed. Gated on a label being bound — the unbound/legacy recount stays
+  // strict (it must not tolerate a count from an unrelated label). Single-run stories are unaffected.
+  const siblingPassedCounts = options.label ? assertPassedCountsForLabel(evDir, { label: options.label, expect }) : [];
   // Baseline authentication feeds the preExistingExcluded rule (review pass-3 #5).
   let baselineAuth = null;
   const baselineCandidates = [join(evDir, 'baseline.json'), join(root, '.valent-pipeline', 'evidence-baseline.json')];
@@ -89,6 +94,7 @@ export async function crosscheckCmd(options) {
     baselineAuth,
     assertRequired: options.requireAssert === true,
     expectedLabel: options.label || null,
+    siblingPassedCounts,
   });
   if (malformedInputs.length) {
     result.mismatches.push(...malformedInputs);

package/src/lib/crosscheck.js

@@ -35,7 +35,7 @@ const OPEN_STATUSES = new Set(['open', 'fix-in-progress']);
  * @returns {{ok:boolean, skipped:boolean, mismatches:Array<{field:string, claimed:*, actual:*}>,
  *            warnings:string[], recounted:object}}
  */
-export function crosscheckVerdict({ reported = null, bugsBlock = null, assertVerdict = null, pin = null, diskVerdict = null, baselineAuth = null, assertRequired = false, expectedLabel = null }) {
+export function crosscheckVerdict({ reported = null, bugsBlock = null, assertVerdict = null, pin = null, diskVerdict = null, baselineAuth = null, assertRequired = false, expectedLabel = null, siblingPassedCounts = [] }) {
   const mismatches = [];
   const warnings = [];
   const recounted = {};
@@ -87,6 +87,18 @@ export function crosscheckVerdict({ reported = null, bugsBlock = null, assertVer
       warnings.push(`${field}: self-reported ${reported[field]} but artifacts show ${actual} — under-report (safe direction: under-stating passes cannot sneak a ship), reconciled to the recount`);
       return;
     }
+    // Multi-suite label-multiplexing (2026-06-25): when several DISTINCT green suites run under ONE
+    // label at one gate (e.g. acceptance + server-project, case sets the record-time auto-namespace
+    // did not split), the label-bound recount picks the LATEST assert, which may not be the suite
+    // JUDGE counted. A testsPassed OVER-claim that EXACTLY equals some OTHER green same-label
+    // assert's passed count is a real machine recount of a sibling run JUDGE counted — not padded
+    // green — so reconcile with a warning. A value matching NO real same-label assert stays a hard
+    // mismatch (the fabrication case the crosscheck exists to catch). Strictly safer than binding
+    // the recount to the run JUDGE *cites* (which would let the gate choose its own recount source).
+    if (field === 'testsPassed' && numeric && reported[field] > actual && Array.isArray(siblingPassedCounts) && siblingPassedCounts.includes(reported[field])) {
+      warnings.push(`testsPassed: self-reported ${reported[field]} but the label-bound assert shows ${actual} — matches a sibling green run under the same label (multi-suite label-multiplexing); reconciled to a real recount, not a fabrication`);
+      return;
+    }
     mismatches.push({ field, claimed: reported[field], actual });
   };