valent-pipeline 0.19.60 → 0.19.62

package/package.json

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

package/pipeline/prompts/pmcp.md

@@ -63,7 +63,25 @@ Follow the on-missing-MCP behavior the orchestrator passed in your trigger:
   `mcpAvailable: false`, and return — the story proceeds without visual evidence.
 
 ### Step 3: Execute checkpoints (MCP available)
-Start the dev server. For each checkpoint: navigate to its route, establish the required state (seed
+Start the dev server.
+
+**Pre-flight — assert an INTEGER `devicePixelRatio` before driving any interaction.** Once the server
+is up and you have navigated to the app, evaluate `window.devicePixelRatio`. If it is NOT an integer
+(commonly `1.5` when the host display runs Windows/macOS scaling at 150%), the browser's
+coordinate-based `click()`/`fill()` land OFF-TARGET: Playwright reports the click succeeded but the
+app's `onClick`/`onInput` handlers never fire, so you can screenshot STATIC renders yet can NEVER
+drive an interaction or a multi-step / WS flow. **Do NOT misread this as "the browser MCP cannot drive
+WS events," and do NOT FAIL or `na` the interaction checkpoints** — it is an infrastructure config
+bug, not an app or reachability defect (the e2e test runner pins the scale factor, which is why an
+acceptance e2e can drive the same flow the MCP cannot). STOP and record an **infrastructure blocker**
+in `pmcp-evidence.md` (`verdict: fail`, `mcpAvailable: true`) naming the cause and the fix: the
+browser MCP must launch with **`deviceScaleFactor: 1`** (passing a fixed `--viewport-size` defaults
+the scale factor to 1), a project `.mcp.json` / browser-MCP-config change that needs an MCP/session
+**RESTART** to take effect. Static render-only checkpoints may still be captured; mark every
+interaction-dependent checkpoint blocked-by-DPR, not FAIL. A non-integer DPR is the single most common
+cause of "PMCP can render but can't drive."
+
+For each checkpoint: navigate to its route, establish the required state (seed
 data, auth, form values), wait for the expected state using element/network conditions — **never hard
 waits** — capture a screenshot into `{story_output_dir}` using the checklist's filename convention,
 and evaluate it against the pass criteria. Record PASS or FAIL per checkpoint. Stop the server when done.

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)