valent-pipeline 0.19.50 → 0.19.52

package/package.json

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

package/pipeline/orchestrators/claude-code/sprint.workflow.js

@@ -83,7 +83,10 @@
  * PRODUCES the evidence and JUDGE remains the single ship gate that rejects a bad/missing visual result.
  * `onMissingMcp` controls the no-browser-MCP case — `block` (default) records a failing/blocked evidence
  * file so JUDGE rejects the UI story; `na` records the checkpoints N/A (loudly) and proceeds. The
- * installer registers playwright-mcp for UI projects, so `block` is normally never hit. Non-ui stories
+ * installer registers the browser MCP as `playwright` (committed to .mcp.json); PMCP matches it by
+ * browser-tool CAPABILITY (`mcp__<server>__browser_navigate`), NOT the exact configured name, so a
+ * `playwright` vs `playwright-mcp` label difference is harmless. `block` is hit only when no browser MCP
+ * is available at all — e.g. a session predating the .mcp.json server (restart to register it). Non-ui stories
  * have no checklist => the stage is a no-op (N/A), exactly mirroring QA-A's checklist-production trigger.
  *
  * `preCriticGate` (from pipeline-config.yaml `pre_critic_gate`) is the deterministic pre-CRITIC
@@ -2796,17 +2799,22 @@ async function runStory(story) {
         schema: PMCP_SCHEMA,
         model: modelFor('PMCP'),
         trigger:
-          `Read \`stories/${sid}/output/visual-validation-checklist.md\`. FIRST confirm the browser-` +
-          `automation MCP (\`${visualBrowserMcp}\`) is actually available to you in this session.\n` +
+          `Read \`stories/${sid}/output/visual-validation-checklist.md\`. FIRST confirm a browser-` +
+          `automation MCP is actually available to you in THIS session. Match by CAPABILITY, not the ` +
+          `exact server name: you have it if your tools include a \`mcp__<server>__browser_navigate\` ` +
+          `(and \`browser_snapshot\`). The server is configured as \`${visualBrowserMcp}\` but may be ` +
+          `registered under another name (commonly \`playwright\`) — check the tool SHAPE, not the label.\n` +
           (naMode
-            ? `• If it is NOT available: do NOT block. Write pmcp-evidence.md marking every checkpoint ` +
-              `N/A with a LOUD note that visual validation was SKIPPED because \`${visualBrowserMcp}\` is ` +
-              `not installed, set verdict "na", mcpAvailable:false, and return.\n`
-            : `• If it is NOT available: this is a BLOCKER (the project requires visual evidence for UI ` +
-              `stories). Write pmcp-evidence.md recording that visual validation COULD NOT RUN because ` +
-              `\`${visualBrowserMcp}\` is not installed, set verdict "fail", mcpAvailable:false, and return ` +
-              `— JUDGE will reject on the missing visual evidence. Install it with \`node ` +
-              `.valent-pipeline/bin/cli.js init --force\` (or \`claude mcp add --scope project playwright -- npx -y @playwright/mcp\`).\n`) +
+            ? `• If NO such browser tool is available: do NOT block. Write pmcp-evidence.md marking every ` +
+              `checkpoint N/A with a LOUD note that visual validation was SKIPPED because no browser-` +
+              `automation MCP (\`${visualBrowserMcp}\`) is available, set verdict "na", mcpAvailable:false, and return.\n`
+            : `• If NO such browser tool is available: this is a BLOCKER (the project requires visual ` +
+              `evidence for UI stories). Write pmcp-evidence.md recording that visual validation COULD NOT ` +
+              `RUN because no browser-automation MCP (\`${visualBrowserMcp}\`) is available, set verdict ` +
+              `"fail", mcpAvailable:false, and return — JUDGE will reject on the missing visual evidence. ` +
+              `If it IS installed (\`claude mcp list\` shows it Connected) but its tools are absent here, the ` +
+              `session likely PREDATES the \`.mcp.json\` server and must be RESTARTED to register it. Install/` +
+              `repair with \`node .valent-pipeline/bin/cli.js init --force\` (or \`claude mcp add --scope project playwright -- npx -y @playwright/mcp\`).\n`) +
           `• If it IS available (mcpAvailable:true): start the dev server yourself, then for EACH ` +
           `checkpoint navigate to its route, establish the required state, wait for the expected state ` +
           `(element/network conditions — never hard waits), capture a screenshot into the story output ` +

package/pipeline/prompts/pmcp.md

@@ -40,7 +40,8 @@ browser MCP is available, **start the dev server yourself**, run every checkpoin
 
 - `{story_id}`, `{story_output_dir}`
 - `{tech_stack.browser_automation_mcp}` — the browser-automation MCP to use (default: `playwright-mcp`).
-  The orchestrator passes the exact name to look for in your task trigger.
+  The orchestrator passes this as a **hint**; confirm availability by tool **capability**
+  (`mcp__<server>__browser_navigate`), since the server is often registered under a different name (e.g. `playwright`).
 
 ## Execution Steps
 
@@ -50,7 +51,11 @@ state, AC reference, expected visual elements, setup instructions, and pass crit
 is missing, set a blocker in your output and STOP (a `ui`-profile story should always have one from QA-A).
 
 ### Step 2: Confirm MCP availability and branch
-Confirm the browser-automation MCP named in your trigger is actually available to you in this session.
+Confirm a browser-automation MCP is actually available to you in this session — match by **capability,
+not the exact server name**: you have it if your tools include `mcp__<server>__browser_navigate` /
+`browser_snapshot`. The configured name in your trigger is a hint; the server is commonly registered as
+`playwright`, so check the tool **shape**, not the label. If `claude mcp list` shows it Connected but the
+tools are absent here, the session predates the `.mcp.json` server and must be **restarted** to register it.
 Follow the on-missing-MCP behavior the orchestrator passed in your trigger:
 - **`block`:** if the MCP is absent, write `pmcp-evidence.md` recording that visual validation could not
   run, set `verdict: fail`, `mcpAvailable: false`, and return — JUDGE rejects on the missing evidence.

package/src/lib/config-schema.js

@@ -492,8 +492,10 @@ export const defaults = {
   // visual-validation-checklist.md and writes pmcp-evidence.md — the artifact JUDGE's evidence pass
   // REQUIRES for UI stories. `on_missing_mcp` controls what happens when that MCP is not installed:
   //   block — record a failing/blocked evidence file so JUDGE rejects the UI story (visual evidence
-  //           is mandatory). This is the default; the installer registers playwright-mcp for UI
-  //           projects, so it is normally never hit.
+  //           is mandatory). This is the default; the installer registers the browser MCP as
+  //           `playwright` and PMCP matches it by tool capability (mcp__*__browser_navigate), NOT the
+  //           exact configured name, so it is hit only when no browser MCP is available at all (e.g. a
+  //           session predating the .mcp.json server — restart to register it).
   //   na    — record the checkpoints as N/A (loudly) and let the story ship without visual evidence.
   visual: {
     on_missing_mcp: 'block',

package/src/lib/git-flow.js

@@ -370,6 +370,19 @@ export function readFlowRecord(root, story) {
   }
 }
 
+// When the flow record isn't in the run context's working tree, read it from a git ref. A --from-story
+// bug's git-flow.json is committed only on its own branch (evidence-on-branch — the class the .50 fixed
+// for the backlog entry), so story-status run from a context that lacks it (the post-ship verify on
+// build/v1) would otherwise read None. Returns null on any failure (missing path/ref) — callers fall
+// back to their prior behavior.
+function readFlowRecordFromRef(root, ref, story) {
+  try {
+    return JSON.parse(git(root, ['show', `${ref}:stories/${story}/evidence/git-flow.json`]));
+  } catch {
+    return null;
+  }
+}
+
 function writeFlowRecord(root, story, record) {
   const dir = join(root, 'stories', story, 'evidence');
   mkdirSync(dir, { recursive: true });
@@ -629,7 +642,13 @@ export function storyStatus({ root, story, targetBranch = '', prefix = 'story/'
   if (!isRepoWithCommits(root)) return NOT_REPO;
   const branch = storyBranchName(prefix, story);
   const exists = branchExists(root, branch);
-  const record = readFlowRecord(root, story);
+  // Evidence-on-branch (M-90/M-91): a --from-story bug's git-flow.json is committed on its OWN branch,
+  // so a story-status run from a context lacking it (the post-ship verify on build/v1) reads None and
+  // defaults the target to build/v1 — a bug merged --into its SOURCE then reads merged:false (a FALSE
+  // git-ship-failed that strands the parent's revalidation). Fall back to the branch ref so basedOnStory
+  // still resolves (the .49 authority can only fire if the record is readable). Mirrors the .50 backlog
+  // branch-resolution. The record CONTENT is identical to the local copy — only the read source differs.
+  const record = readFlowRecord(root, story) || (exists ? readFlowRecordFromRef(root, branch, story) : null);
   // A `--from-story` item (an inline bug fix) ships `--into` its SOURCE story branch (recorded as
   // basedOnStory), NOT the sprint target — so "did it land" is ancestry against basedOnStory. The sprint
   // `--target` that the post-ship verify passes globally (gitFlags `--target`) is the wrong base for such