@skyramp/mcp 0.2.7 → 0.2.8

package/build/prompts/testbot/testbot-prompts.js

@@ -2,7 +2,6 @@ import { z } from "zod";
 import { logger } from "../../utils/logger.js";
 import { AnalyticsService } from "../../services/AnalyticsService.js";
 import { MAX_TESTS_TO_GENERATE, MAX_RECOMMENDATIONS, MAX_CRITICAL_TESTS, PATH_PARAM_UUID_GUIDANCE, AUTH_CONFLICT_ERROR_MSG, } from "../test-recommendation/recommendationSections.js";
-import { buildDriftAnalysisPrompt } from "../test-maintenance/drift-analysis-prompt.js";
 import { getTraceRecordingPromptText } from "../../playwright/traceRecordingPrompt.js";
 import { isContractConsumerModeEnabled } from "../../utils/featureFlags.js";
 import { resolveServiceDetailsRef } from "../../utils/utils.js";
@@ -18,9 +17,53 @@ const CONTRACT_MODE_GUIDANCE = CONSUMER_MODE_ENABLED
   For client-facing APIs consumed by frontend: add \`consumerMode: true\`.
   Both modes (\`providerMode: true, consumerMode: true\`): For diff that contains BOTH provider signals (such as new/modified endpoint handlers, route changes this service owns) AND consumer signals (outbound HTTP client calls to another service, no new endpoint handlers).`
     : `  Always add \`providerMode: true\` — the tool generates provider-side contract tests only.`;
+/**
+ * Parse the JSON-encoded `relatedRepositories` argument passed via the testbot
+ * prompt/resource. Returns undefined for missing/blank input or malformed JSON so the
+ * caller cleanly falls back to single-repo behavior.
+ */
+export function parseRelatedRepositories(raw) {
+    if (!raw)
+        return undefined;
+    try {
+        const parsed = JSON.parse(raw);
+        if (!Array.isArray(parsed) || parsed.length === 0)
+            return undefined;
+        return parsed
+            .filter((r) => !!r &&
+            typeof r.repositoryPath === "string" &&
+            r.repositoryPath.length > 0 &&
+            typeof r.repo === "string" &&
+            r.repo.length > 0)
+            .map((r) => ({
+            repositoryPath: r.repositoryPath,
+            baseBranch: typeof r.baseBranch === "string" ? r.baseBranch : undefined,
+            repo: r.repo,
+        }));
+    }
+    catch {
+        return undefined;
+    }
+}
 export function getTestbotPrompt(prTitle, prDescription, summaryOutputFile, repositoryPath, baseBranch, maxRecommendations = MAX_RECOMMENDATIONS, maxGenerate = MAX_TESTS_TO_GENERATE, _maxCritical = MAX_CRITICAL_TESTS, // Reserved — accepted for API compat but not yet wired into prompt
-prNumber, userPrompt, services, stateOutputFile, uiCredentials, testsRepoDir) {
+prNumber, userPrompt, services, uiCredentials, testsRepoDir, relatedRepositories, primaryRepo) {
     maxGenerate = Math.min(Math.max(maxGenerate, 0), maxRecommendations);
+    // TODO(SKYR-3636 follow-up): migrate Task 1 + Task 2 step bodies to PromptPlan
+    // (src/prompts/test-recommendation/promptPlan.ts) so step numbers don't have
+    // to be hand-maintained when steps are added or reordered.
+    // Multi-repo mode: when related repos are present, the agent analyzes each one
+    // (primary + related) and correlates cross-repo changes. The configured checkout
+    // HEAD of each related repo is its feature ref; `baseBranch` is that repo's
+    // default branch, so skyramp_analyze_changes computes a real default…feature
+    // diff. Every repo carries an explicit `repo` (owner/repo) resolved action-side,
+    // so the agent never infers it. GENERATE candidates are pooled across the primary
+    // + related repos into one shared ranked budget; each generated test executes
+    // against its own repo's service when reachable. Two distinct roots: the unified
+    // .skyramp/workspace.yml ALWAYS lives in the primary repo (where the workflow is
+    // installed), while test FILES are delivered into each service's declared
+    // testDirectory, relative to the delivery root (the configured test repo if set,
+    // otherwise the primary repo).
+    const hasRelatedRepos = !!relatedRepositories?.length;
     // For follow-up requests: emit the @skyramp-testbot header + guardrails + retrieve-recommendations step.
     // For first-run prompts: emit the full Task 1 analysis + maintenance section.
     const task1Section = userPrompt
@@ -42,7 +85,7 @@ Verify the prompt inside <USER_PROMPT> is related to adding or removing tests fr
 - If the prompt matches one or more tests in the Additional Recommendations → proceed to Task 1 (Skip Analysis).
 
 ### Task 1: Retrieve Previous Recommendations
-Call \`skyramp_analyze_changes\` with \`repositoryPath\`: "${repositoryPath}", \`scope\`: "branch_diff"${baseBranch ? `, \`baseBranch\`: "${baseBranch}"` : ""}${prNumber ? `, \`prNumber\`: ${prNumber}` : ""}${stateOutputFile ? `, \`stateOutputFile\`: "${stateOutputFile}"` : ""}${testsRepoDir ? `, \`testsRepoDir\`: "${testsRepoDir}"` : ""}.
+Call \`skyramp_analyze_changes\` with \`repositoryPath\`: "${repositoryPath}", \`scope\`: "branch_diff"${baseBranch ? `, \`baseBranch\`: "${baseBranch}"` : ""}${prNumber ? `, \`prNumber\`: ${prNumber}` : ""}${testsRepoDir ? `, \`testsRepoDir\`: "${testsRepoDir}"` : ""}.
 This will fetch the previous TestBot report from the PR comments and return deduplicated recommendations.
 Use those recommendations as your baseline. Only add or remove tests that the user requested AND that appear in the Additional Recommendations. Then proceed straight to Task 2: Generate New Tests.
 `
@@ -51,7 +94,7 @@ Use those recommendations as your baseline. Only add or remove tests that the us
 
 ## Task 1: Analyze & Maintain
 
-1. Call \`skyramp_analyze_changes\` with \`repositoryPath\`: "${repositoryPath}", \`scope\`: "branch_diff", \`topN\`: ${maxRecommendations}, \`maxGenerate\`: ${maxGenerate}${baseBranch ? `, \`baseBranch\`: "${baseBranch}"` : ""}${prNumber ? `, \`prNumber\`: ${prNumber}` : ""}${stateOutputFile ? `, \`stateOutputFile\`: "${stateOutputFile}"` : ""}${testsRepoDir ? `, \`testsRepoDir\`: "${testsRepoDir}"` : ""}.
+1. Call \`skyramp_analyze_changes\` with \`repositoryPath\`: "${repositoryPath}", \`scope\`: "branch_diff", \`topN\`: ${maxRecommendations}, \`maxGenerate\`: ${maxGenerate}${baseBranch ? `, \`baseBranch\`: "${baseBranch}"` : ""}${prNumber ? `, \`prNumber\`: ${prNumber}` : ""}${testsRepoDir ? `, \`testsRepoDir\`: "${testsRepoDir}"` : ""}.
 
    **Follow all instructions returned by \`skyramp_analyze_changes\`** — its response opens with a **UI Blueprint Capture** section that tells you which candidate URLs to capture (and how) before you write any UI recommendation \`reasoning\`.${uiCredentials ? " If the section lists candidate URLs, log in once via the credentials in your <ui-credentials> context before navigating to them." : ""}
 
@@ -60,10 +103,36 @@ Use those recommendations as your baseline. Only add or remove tests that the us
 
    **If \`skyramp_analyze_changes\` returns an error:** retry once only if the error is transient (timeout, network blip, temporary unavailability) — do NOT retry for permanent errors (invalid repository path, missing required parameter, authentication failure). If it fails again, call \`skyramp_submit_report\` with a minimal valid payload: leave all test arrays empty and add the error to \`issuesFound\`. Refer to the \`skyramp_submit_report\` schema for required fields. Do NOT attempt Task 2 without a valid stateFile.
    **If all changed files are non-application** (CI/CD, docs, lock files, config) → skip to Task 3 (Submit Report) with empty arrays and a single \`issuesFound\` entry explaining why (same format as the zero-test path below).
+${hasRelatedRepos ? `
+   **MULTI-REPO CONTEXT (MANDATORY).** This run includes ${relatedRepositories.length} related ${relatedRepositories.length === 1 ? "repository" : "repositories"} listed in the \`<related_repositories>\` block below, each with an explicit \`repository\` (\`owner/repo\`), \`path\`, and \`base_branch\`. Use the \`repository\` value verbatim — do NOT infer it from git remotes or paths. You MUST analyze EACH related repository — exactly one \`skyramp_analyze_changes\` call per listed repo (${relatedRepositories.length} ${relatedRepositories.length === 1 ? "call" : "calls"}), in addition to the primary call in step 2.
+
+   **Run the primary call (step 2) FIRST, then the related repos in listed order — not in parallel.** All calls in this run automatically share ONE run-scoped state file — you do NOT pass a state-file path; setting \`repository\` is enough. The primary writes its root section; each related repo's call upserts its own section into that same file. Concurrent calls would race on the shared file, so they must be sequential. For each related repo:
+   - **(a)** Register its services into the **single unified workspace** — do NOT write a \`.skyramp/workspace.yml\` into the related repo (it is read-only context, and a per-repo file would need its own PR). The unified workspace always lives in the **primary repo** (where the testbot workflow is installed): \`${repositoryPath}\`${testsRepoDir ? ` — NOT in the configured test repo, even though generated test files are delivered there` : ""}. Steps: call \`skyramp_init_scan\` with \`workspacePath\`: the related repo's \`path\` to DISCOVER its services, then call \`skyramp_init_workspace\` with \`workspacePath\`: "${repositoryPath}" (the PRIMARY repo, NOT the related repo's path${testsRepoDir ? " and NOT the test repo" : ""}), \`merge\`: true, the \`scanToken\`, and the discovered services — each with its \`repository\` field set to that repo's \`repository\` value from the block. This upserts the related repo's services into the one unified \`.skyramp/workspace.yml\` (services are keyed by the composite of \`repository\` + \`serviceName\`).
+   - **(b)** Then call \`skyramp_analyze_changes\` with that repo's \`path\` (as \`repositoryPath\`), \`scope\`: "branch_diff", and \`repository\`: that repo's \`repository\` value. Passing \`repository\` stores this analysis as a section within the one run-scoped state file (the file is reused automatically across calls — do NOT pass any state-file path). Pass \`baseBranch\` only when the repo's \`base_branch\` attribute names a concrete branch; when \`base_branch\` is \`auto-detect\`, OMIT \`baseBranch\` and let the tool detect the repo's default branch.
+   - **(c)** If analysis of a related repo fails (e.g. workspace init or diff error), record a one-line \`issuesFound\` note and CONTINUE — a missing related repo must not block the primary analysis.
+   Keep ALL returned diffs and recommendations from every repo in your working context. **Correlate** cross-repo changes when forming recommendations and the business case — e.g. an API contract changed in one repo and consumed by another, a request/response shape that must stay compatible across the boundary.
+
+   **One state file, per-repo sections.** There is exactly ONE state file for the whole run (created automatically and reused across calls). Each \`skyramp_analyze_changes\` call writes its repo's section into it (keyed by \`repository\`). When you maintain/act on any repo's tests — \`skyramp_analyze_test_health\`, \`skyramp_actions\`, \`skyramp_execute_test\` — pass that repo's \`repository\` (\`owner/repo\`) as the \`repository\` argument alongside the \`stateFile\` path returned by \`skyramp_analyze_changes\`, so the tool reads/writes that repo's section. The primary repo's \`repository\` is \`${primaryRepo || "<the primary repo's owner/repo>"}\`; pass it for the primary repo's tests just as you do for related repos.
+
+   **Cross-repo test generation (Task 2 spans all repos).** Pool the GENERATE **and** ADDITIONAL recommendations from the primary AND every related repo into ONE candidate set — treat each repo's per-repo GENERATE list as **candidates, not a fixed selection**. (This OVERRIDES the "use the pre-ranked GENERATE list as-is" mandate in Task 2 below, which applies only to single-repo runs.) To fill the shared budget of ${maxGenerate} tests, distribute slots EVENLY across test types with spillover:
+   1. **Bucket** the pooled candidates by test type (UI/E2E, contract, integration), including ONLY the types that actually have candidates.
+   2. **Protected items first:** a promoted \`bug_caught\` (CRITICAL) test or an attack-surface \`security_boundary\` test always takes a GENERATE slot before round-robin fills the rest.
+   3. **Round-robin** one slot per type in priority order — the highest-scored candidate of the highest-ranked type first — taking one per type per round.
+   4. **Spillover:** when a type's candidates run out, its freed slots go to the next-highest-scored candidate of any remaining type.
+   Within a type, higher score wins regardless of which repo it came from. Everything not selected becomes an ADDITIONAL recommendation. This guarantees a frontend-only primary repo cannot starve a related backend repo's contract/integration tests of GENERATE slots (and vice versa). When you generate a test for a related repo's endpoint:
+   - **Execute it only if that repo's service is already running and reachable.** The workflow's setup may have started multiple services; before generating an API test for a related repo, confirm its \`base_url\` (from that repo's workspace/Execution Plan) responds. If the service is unreachable, still GENERATE the test but mark its \`testResults\` status as \`Skipped\` with details "service not running in this run" — do NOT count an unreachable service as a failure.
+   - **Write the test file into that service's own \`testDirectory\`** — the one declared for the service in the unified workspace.yml (the related repo's services were registered there in step (a), each with its \`repository\`). The \`testDirectory\` is interpreted relative to the **single delivery root** (the configured test repo if set, otherwise the primary repo), so all generated tests are delivered together by the existing single-target delivery. Do NOT invent a per-source-repo subdirectory, and do NOT write into the related repo's own checkout — it is read-only context. (If two repos happen to declare the same \`testDirectory\`, their files coexist there; the \`repository\` field on each report item — below — is what attributes ownership, not the path.)
+   - **Set the \`repository\` field** (\`owner/repo\`) on every such \`newTestsCreated\` / \`testResults\` item so the report attributes it to the originating repo (see Report Guidelines).` : ""}
 
 2. **Maintain existing tests:**
 
-${buildDriftAnalysisPrompt()}
+   a. Call \`skyramp_analyze_test_health\` with \`stateFile\` (from \`skyramp_analyze_changes\` output). **Do NOT read application source files** (routes, models, controllers) — all change information you need is in the \`skyramp_analyze_changes\` output and the diff.
+
+   b. Write \`updateInstructions\` for each UPDATE or REGENERATE test before calling \`skyramp_actions\` — articulating the change first prevents file content from overriding diff-based reasoning.
+
+   c. Call \`skyramp_execute_test\` with \`phase: "before"\` and \`stateFile\` for every test whose action is UPDATE or REGENERATE. Run them in parallel. This captures the pre-edit baseline — do not skip even if you expect the test to fail.
+
+   d. Call \`skyramp_actions\` with \`stateFile\` (from \`skyramp_analyze_changes\` output) and apply the edits it returns.
 
 3. **Code review:** From the \`skyramp_analyze_changes\` output and the existing test files you read for maintenance, note any logic bugs. Do NOT read additional source files just for code review — use what is already available from the analysis and test file reads. Common patterns to flag:
    - Computed fields not recalculated after mutation (e.g. \`total_amount\` unchanged after items are added/removed)
@@ -260,13 +329,25 @@ ${buildDriftAnalysisPrompt()}
         ? `<ui-credentials>\n${trimmedCredentials}\n</ui-credentials>`
         : '';
     const testsRepoDirBlock = testsRepoDir ? `<TESTS REPO DIR>${testsRepoDir}</TESTS REPO DIR>\n` : '';
+    // Multi-repo context block. Each entry's `repositoryPath` is checked out at its
+    // FEATURE ref; `baseBranch` is that repo's default branch (the diff base), so
+    // skyramp_analyze_changes computes a real default…feature diff for the related repo.
+    // `repository` is the owner/repo resolved action-side (no agent inference).
+    const relatedReposBlock = hasRelatedRepos
+        ? `<related_repositories>\n` +
+            relatedRepositories
+                .map((r) => `  <repository repository="${r.repo}" path="${r.repositoryPath}" base_branch="${r.baseBranch || "auto-detect"}" />`)
+                .join("\n") +
+            `\n</related_repositories>\n`
+        : '';
     const testDirInstruction = testsRepoDir
         ? `the \`<output_dir>\` from the \`<services>\` block, rooted under the test repository at \`${testsRepoDir}\` (i.e. \`${testsRepoDir}/<output_dir>\`). Write ALL test output files to paths under \`${testsRepoDir}\`, not under \`${repositoryPath}\`. Do NOT write any test files to the app repository.`
         : `${SERVICE_REFS.testDirRef}. Do NOT create a new \`tests/\` directory at the repo root — use that path. If no \`testDirectory\` is configured, default to the language-conventional location (e.g. \`src/test/java/...\` for Java, \`tests/\` for Python).`;
+    const primaryRepoBlock = primaryRepo ? `<REPOSITORY>${primaryRepo}</REPOSITORY>\n` : '';
     return `<TITLE>${prTitle}</TITLE>
 <DESCRIPTION>${prDescription}</DESCRIPTION>
-<REPOSITORY PATH>${repositoryPath}</REPOSITORY PATH>
-${testsRepoDirBlock}${serviceContext ? serviceContext + '\n' : ''}${uiCredentialsBlock ? uiCredentialsBlock + '\n' : ''}Use the Skyramp MCP server tools for all tasks below.
+${primaryRepoBlock}<REPOSITORY PATH>${repositoryPath}</REPOSITORY PATH>
+${relatedReposBlock}${testsRepoDirBlock}${serviceContext ? serviceContext + '\n' : ''}${uiCredentialsBlock ? uiCredentialsBlock + '\n' : ''}Use the Skyramp MCP server tools for all tasks below.
 
 ${task1Section}
 
@@ -274,7 +355,7 @@ ${task1Section}
 
 ${userPrompt ? "Generate only the tests that the user requested from the Additional Recommendations. The rules below still apply." : "Drift-based maintenance (Task 1) is complete. This step only processes the GENERATE list. Exception: if a GENERATE item targets a resource with an existing `[skyramp]` contract test, UPDATE that test file (see covered-resource handling below) — a new test case added to an existing file counts toward the budget and is reported in `newTestsCreated`."}
 
-- **MANDATORY — use the pre-ranked GENERATE list as-is**: The Execution Plan's GENERATE section governs ADD actions. You MUST generate exactly those scenarios in the exact order listed. Do NOT substitute, rename, or replace a GENERATE item. If parameter grounding uncovers a distinct bug-catching scenario not already in the GENERATE or ADDITIONAL list, generate it after all planned GENERATE items are complete and report it in \`newTestsCreated\` — this is an additional test driven by source-code analysis and does not count against the GENERATE budget.
+- **MANDATORY — use the pre-ranked GENERATE list as-is**: The Execution Plan's GENERATE section governs ADD actions. You MUST generate exactly those scenarios in the exact order listed. Do NOT substitute, rename, or replace a GENERATE item. If parameter grounding uncovers a distinct bug-catching scenario not already in the GENERATE or ADDITIONAL list, generate it after all planned GENERATE items are complete and report it in \`newTestsCreated\` — this is an additional test driven by source-code analysis and does not count against the GENERATE budget.${hasRelatedRepos ? `\n  - **Multi-repo exception:** this run has related repositories, so the per-repo GENERATE lists are NOT final — they are candidates re-selected by the cross-repo round-robin described in Task 1's "Cross-repo test generation". Follow that pooled, type-distributed selection instead of any single repo's GENERATE list. (In single-repo runs the GENERATE list IS final — generate it exactly as-is.)` : ""}
 - Scenario JSON files are always new files — always generate them for new methods. Every generated scenario JSON must have a corresponding new integration test generated from it via \`skyramp_integration_test_generation\`.
 - Covered-resource handling (aligns with Execution Plan Step 0): When a GENERATE item targets a resource that already has an existing test file covering the same endpoint:
   - If the existing test source is \`[external]\`, skip the resource entirely — the external test already provides coverage. Do NOT UPDATE, REGENERATE, or DELETE external tests.
@@ -286,7 +367,7 @@ ${userPrompt ? "Generate only the tests that the user requested from the Additio
 - Example: If enrichment reveals that sending \`discount_value\` without \`discount_type\` silently orphans the value (a concrete bug), complete all planned GENERATE items first, then generate this discovered scenario as an extra test and report it in \`newTestsCreated\`.
 - Total generated: Follow the "Budget: N generate" line in the Execution Plan. Process every GENERATE-tagged item in order. Backfill from ADDITIONAL candidates (highest-ranked first) until \`newTestsCreated\` reaches ${maxGenerate} or all candidates are exhausted.
 - **UI test priority**: If the PR scope assessment shows any UI/E2E budget OR \`uiContext.changedFrontendFiles\` is non-empty (the deterministic server signal — populated for all supported frontend file types including \`.tsx\`/\`.jsx\`/\`.vue\`/\`.svelte\`/\`.dart\`), you MUST attempt to generate at least one UI test. Use \`browser_navigate\` to the app's base URL — if the app responds, record a trace and generate the test.
-  **Flutter web apps:** Skyramp's Playwright tools automatically enable Flutter's accessibility semantics tree on every \`browser_navigate\` call — you do NOT need to manually click \`flt-semantics-placeholder\` or add any activation step to the trace. Do NOT log an \`issuesFound\` entry about Flutter canvas rendering or accessibility activation — this is handled transparently. **Do NOT skip test generation or abstain from recording based on what you see in the Flutter source code** (e.g. \`SemanticsBinding.ensureSemantics()\` commented out, \`IS_TESTING\` flag absent, or similar) — Skyramp enables accessibility from the browser side regardless of the app's Dart code. Proceed with \`browser_navigate\` and test recording as normal.
+  **Flutter web apps:** Skyramp's Playwright tools automatically enable Flutter's accessibility semantics tree on every \`browser_navigate\` call — you do NOT need to manually click \`flt-semantics-placeholder\` or add any activation step to the trace. Do NOT log an \`issuesFound\` entry about Flutter canvas rendering or accessibility activation — this is handled transparently. **Do NOT skip test generation or abstain from recording based on what you see in the Flutter source code** (e.g. \`SemanticsBinding.ensureSemantics()\` commented out, \`IS_TESTING\` flag absent, or similar) — Skyramp enables accessibility from the browser side regardless of the app's Dart code. Proceed with \`browser_navigate\` and test recording as normal. **Start at the app's root URL** (e.g. \`{baseUrl}/\`) — do NOT \`browser_navigate\` straight to a deep sub-route (e.g. \`/authors\`, \`/orders/13\`). Flutter \`go_router\` SPAs route from the root: deep-linking on a cold page load often fails to render the expected screen (the route's widgets never mount, so the trace captures the wrong page). Load the root, let the app's own routing/auth-redirect render, then reach target screens by interaction. **After the initial login, navigate using in-app controls only** (tab buttons, links, back buttons) — do NOT call \`browser_navigate\` to a different URL after login. Flutter web apps are SPAs: a \`browser_navigate\` to a new URL after login triggers a full page reload which clears the auth session, causing redundant re-login cycles in the generated test. Use button clicks to reach target screens instead.
   **Skip only if one of these conditions is met:**
   - **(a) App is unreachable** — \`browser_navigate\` fails or connection is refused.
   - **(b) Unintegrated non-route component** — the changed file is a leaf component (not a framework route/entrypoint) that has no integration point in the running app. To confirm:
@@ -466,14 +547,10 @@ Do NOT use \`page.waitForTimeout()\` with fixed delays. Do NOT retry more than o
 4. **Wait**: Do NOT proceed to test execution until steps 1–3 are complete and the verification checklist in the \`skyramp_enhance_assertions\` tool result has been validated for EVERY generated test file.
 Do not make any changes other than the assertion enhancements described above. For example: do not modify auth headers, cookies, tokens, env vars, or imports that the generation tool already set correctly — those are correct by construction and changing them breaks auth or execution.
 
-**Execution timing:**
-- **beforeStatus** (maintained tests only): execute each maintained test file **once at the start** (before any edits) to capture \`beforeStatus\`. This is the only execution allowed before edits.
-- **Final execution**: Do NOT call \`skyramp_execute_test\` again until ALL maintenance edits AND ALL new test generation/enhancement are complete. Then execute every test file once — maintained files (for \`afterStatus\`) and new files together. Run independent files in parallel (same tool call batch).
+**Final execution (mandatory):** Do NOT call \`skyramp_execute_test\` until ALL maintenance edits AND ALL new test generation/enhancement are complete.
 - Only report test results for files you actually ran.
 **Auth**: If \`skyramp_analyze_changes\` reports an auth token or \`SKYRAMP_TEST_TOKEN\` is set, pass it in **every** \`skyramp_execute_test\` call from the first attempt — do NOT wait for a 401/403 to discover auth is needed.
 
----
-
 ## Task 3: Submit Report
 
 **Before calling \`skyramp_submit_report\` — mandatory count check:**
@@ -494,16 +571,26 @@ In these cases:
 
 Otherwise: in \`newTestsCreated\`, you must have exactly ${maxGenerate} budget-counting new tests for the planned GENERATE items. Only new files (ADD) created for those planned GENERATE items count toward this ${maxGenerate} target — GENERATE items converted to UPDATE do not. You may also include at most one additional discovered-scenario file in \`newTestsCreated\` (the bug-catching test generated after all planned items); that extra test does **not** count against the ${maxGenerate} budget. If you have fewer than ${maxGenerate} budget-counting new tests, backfill from the remaining ADDITIONAL candidates before proceeding. Only proceed with fewer than ${maxGenerate} budget-counting new tests if all candidates failed after retry AND the fallback single-contract test also failed.
 
-Call \`skyramp_submit_report\` with \`summaryOutputFile\`: "${summaryOutputFile}". Field names, types, and formats are defined in the tool's parameter schema — follow them exactly.
-
+Call \`skyramp_submit_report\` with \`summaryOutputFile\`: "${summaryOutputFile}" and \`stateFile\` (from \`skyramp_analyze_changes\` output) — the stateFile is required for execution outcome tracking. Field names, types, and formats are defined in the tool's parameter schema — follow them exactly.
+${hasRelatedRepos ? `
+- **MULTI-REPO attribution**: Set the \`repository\` field (\`owner/repo\`) on EVERY \`newTestsCreated\`, \`testResults\`, \`issuesFound\`, and \`additionalRecommendations\` item — including items about the PRIMARY repo — so each finding is unambiguously attributed. The primary repo's \`repository\` is \`${primaryRepo || "<the primary repo's owner/repo>"}\`; items derived from a related repo's diff (from the \`<related_repositories>\` analysis) carry that repo's \`repository\` value. In \`businessCaseAnalysis\`, include a short per-repo subsection and call out any cross-repo correlations you found.
+` : ""}
 - **additionalRecommendations**: AT MOST ${maxRecommendations - maxGenerate} items.
   - For \`testType: "contract"\` entries: **\`primaryEndpoint\` is required** (e.g. \`"GET /api/v1/users/{user_id}"\`). The tool will reject the submission without it — do not omit it or you will be forced to resubmit.
   - For \`testType: "integration"\` or \`"e2e"\` entries: omit \`primaryEndpoint\` — use \`description\` to list the endpoints involved instead.
-- **testMaintenance**: Use \`[]\` **only** if no existing Skyramp tests were found in the repository. If existing tests were found (any score), include one entry per test. Set \`action\` to the exact drift action you chose from the Action Decision Matrix (\`UPDATE\`, \`REGENERATE\`, \`DELETE\`, \`VERIFY\`, or \`IGNORE\`). For UPDATE/REGENERATE/DELETE tests that were modified and executed, populate all fields from real before/after execution results. For VERIFY/IGNORE tests (not modified), derive \`beforeStatus\` from the \`skyramp_analyze_test_health\` health score (typically \`"Pass"\` if drift score is 0 and no health issues were flagged), set \`afterStatus\` to \`"Skipped"\`, and use \`afterDetails\` to explain why (e.g. "IGNORE: drift score 0 — endpoint not modified in this PR"). Do **not** add entries for tests that were not returned by the health analysis.
+- **testMaintenance**: Use \`[]\` **only** if no existing Skyramp tests were found in the repository. If existing tests were found (any score), include one entry per test. Set \`action\` to the exact drift action you chose from the Action Decision Matrix (\`UPDATE\`, \`REGENERATE\`, \`DELETE\`, \`VERIFY\`, or \`IGNORE\`). For UPDATE/REGENERATE/DELETE tests that were modified and executed, populate \`beforeDetails\` and \`afterDetails\` from what you observed in \`skyramp_execute_test\` output — one line each, no newlines. For passing runs write the count and timing (e.g. \`"4 passed in 15.09s"\`). For failing runs write the test name and failure reason (e.g. \`"1 failed: test_foo - assert X == Y — shared-state pollution"\`). For VERIFY/IGNORE tests (not modified), omit \`beforeDetails\` and \`afterDetails\`. Do **not** add entries for tests that were not returned by the health analysis.
+- **testResults**: For UI/E2E test entries, include the \`videoPath\` field if \`skyramp_execute_test\` returned one.
 
 ---
 
 ${getTraceRecordingPromptText({ outputDir: `${repositoryPath}/.skyramp`, modularize: false })}`;
+    // TODO: merge stateFile and summaryOutputFile into a single file (follow-up PR).
+    // Currently the stateFile path is derived server-side from RUNNER_TEMP (GitHub Actions only);
+    // other CI systems (Jenkins, GitLab, Buildkite) require the caller to set RUNNER_TEMP.
+    // Once merged, the path flows through summaryOutputFile — already testbot-controlled and
+    // CI-agnostic — eliminating the RUNNER_TEMP dependency and the LLM confusion that motivated
+    // removing stateOutputFile from the prompt schema. Remove the RUNNER_TEMP branch in
+    // AnalysisStateManager.ts when this is done.
 }
 function escapeXml(value) {
     return value
@@ -578,10 +665,6 @@ export function registerTestbotPrompt(server) {
                 .string()
                 .optional()
                 .describe("Natural language prompt from the user (via @skyramp-testbot comment) to add or remove specific recommendations."),
-            stateOutputFile: z
-                .string()
-                .optional()
-                .describe("Absolute path where skyramp_analyze_changes should write its state file. When provided, the caller can locate the file without log parsing."),
             uiCredentials: z
                 .string()
                 .optional()
@@ -594,10 +677,18 @@ export function registerTestbotPrompt(server) {
                 .string()
                 .optional()
                 .describe("Absolute path to a cloned test repository. When set, the agent writes generated test files there instead of the app repository (cross-repo test delivery)."),
+            relatedRepositories: z
+                .string()
+                .optional()
+                .describe("JSON-encoded array of {repo, repositoryPath, baseBranch?} for related repositories to analyze (multi-repo mode). `repo` is the owner/repo slug (resolved by the action; used verbatim, never inferred). Each is analyzed with its own skyramp_analyze_changes call; the agent correlates cross-repo changes and draws GENERATE candidates from all repos into one shared ranked budget. Generated test files are delivered into each service's declared testDirectory, relative to the single delivery root (the primary repo, or the configured test repo)."),
+            primaryRepo: z
+                .string()
+                .optional()
+                .describe("The primary repository's owner/repo slug (where the testbot workflow runs). Used verbatim as the `repository` attribution for the primary repo's analysis, tests, and report items in multi-repo runs."),
         },
     }, async (args) => {
         const services = await readWorkspaceServices(args.repositoryPath);
-        let prompt = getTestbotPrompt(args.prTitle, args.prDescription, args.summaryOutputFile, args.repositoryPath, args.baseBranch, args.maxRecommendations, args.maxGenerate, args.maxCritical, args.prNumber, args.userPrompt, services.length ? services : undefined, args.stateOutputFile, args.uiCredentials, args.testsRepoDir);
+        let prompt = getTestbotPrompt(args.prTitle, args.prDescription, args.summaryOutputFile, args.repositoryPath, args.baseBranch, args.maxRecommendations, args.maxGenerate, args.maxCritical, args.prNumber, args.userPrompt, services.length ? services : undefined, args.uiCredentials, args.testsRepoDir, parseRelatedRepositories(args.relatedRepositories), args.primaryRepo);
         if (args.workspaceValidationFailed) {
             prompt = buildWorkspaceRecoveryPrefix(args.repositoryPath) + prompt;
         }

package/build/prompts/testbot/testbot-prompts.test.js

@@ -8,7 +8,7 @@ jest.unstable_mockModule("../../services/AnalyticsService.js", () => ({
 jest.unstable_mockModule("../../playwright/traceRecordingPrompt.js", () => ({
     getTraceRecordingPromptText: () => "",
 }));
-const { getTestbotPrompt, buildWorkspaceRecoveryPrefix } = await import("./testbot-prompts.js");
+const { getTestbotPrompt, buildWorkspaceRecoveryPrefix, parseRelatedRepositories } = await import("./testbot-prompts.js");
 // Minimal args to invoke getTestbotPrompt — only services matter for these tests
 const baseArgs = {
     prTitle: "Test PR",
@@ -25,26 +25,6 @@ function callWithServices(services) {
     undefined, // userPrompt
     services);
 }
-function callWithStateOutputFile(stateOutputFile) {
-    return getTestbotPrompt(baseArgs.prTitle, baseArgs.prDescription, baseArgs.summaryOutputFile, baseArgs.repositoryPath, undefined, // baseBranch
-    undefined, // maxRecommendations
-    undefined, // maxGenerate
-    undefined, // maxCritical
-    undefined, // prNumber
-    undefined, // userPrompt
-    undefined, // services
-    stateOutputFile);
-}
-function callFollowUpWithStateOutputFile(stateOutputFile) {
-    return getTestbotPrompt(baseArgs.prTitle, baseArgs.prDescription, baseArgs.summaryOutputFile, baseArgs.repositoryPath, undefined, // baseBranch
-    undefined, // maxRecommendations
-    undefined, // maxGenerate
-    undefined, // maxCritical
-    undefined, // prNumber
-    "add more tests", // userPrompt — triggers follow-up path
-    undefined, // services
-    stateOutputFile);
-}
 describe("buildServiceContext (via getTestbotPrompt)", () => {
     it("renders full service with all fields", () => {
         const prompt = callWithServices([
@@ -122,27 +102,6 @@ describe("buildServiceContext (via getTestbotPrompt)", () => {
         expect(prompt).toContain("</REPOSITORY PATH>\nUse the Skyramp MCP server tools");
     });
 });
-describe("stateOutputFile in getTestbotPrompt", () => {
-    it("includes stateOutputFile in skyramp_analyze_changes call for first-run prompt", () => {
-        const stateFile = "/tmp/skyramp/analyze-changes-state.json";
-        const prompt = callWithStateOutputFile(stateFile);
-        // The prompt must pass stateOutputFile to skyramp_analyze_changes
-        expect(prompt).toContain(`\`stateOutputFile\`: "${stateFile}"`);
-    });
-    it("includes stateOutputFile in skyramp_analyze_changes call for follow-up prompt", () => {
-        const stateFile = "/tmp/skyramp/analyze-changes-state.json";
-        const prompt = callFollowUpWithStateOutputFile(stateFile);
-        expect(prompt).toContain(`\`stateOutputFile\`: "${stateFile}"`);
-    });
-    it("omits stateOutputFile from skyramp_analyze_changes call when not provided", () => {
-        const prompt = callWithStateOutputFile(undefined);
-        expect(prompt).not.toContain("stateOutputFile");
-    });
-    it("omits stateOutputFile from follow-up prompt when not provided", () => {
-        const prompt = callFollowUpWithStateOutputFile(undefined);
-        expect(prompt).not.toContain("stateOutputFile");
-    });
-});
 describe("uiCredentials in getTestbotPrompt", () => {
     function callWithUiCredentials(uiCredentials) {
         return getTestbotPrompt(baseArgs.prTitle, baseArgs.prDescription, baseArgs.summaryOutputFile, baseArgs.repositoryPath, undefined, // baseBranch
@@ -152,7 +111,6 @@ describe("uiCredentials in getTestbotPrompt", () => {
         undefined, // prNumber
         undefined, // userPrompt
         undefined, // services
-        undefined, // stateOutputFile
         uiCredentials);
     }
     // The instructions text references `<ui-credentials>` in prose (backticked);
@@ -261,7 +219,6 @@ describe("testsRepoDir in getTestbotPrompt", () => {
         undefined, // prNumber
         undefined, // userPrompt
         undefined, // services
-        undefined, // stateOutputFile
         undefined, // uiCredentials
         testsRepoDir);
     }
@@ -273,7 +230,6 @@ describe("testsRepoDir in getTestbotPrompt", () => {
         undefined, // prNumber
         "add more tests", // userPrompt — triggers follow-up path
         undefined, // services
-        undefined, // stateOutputFile
         undefined, // uiCredentials
         testsRepoDir);
     }
@@ -328,3 +284,97 @@ describe("testbot prompt blueprint-grounded recommendations (slice 4)", () => {
         expect(exceptionBlock).toContain(".vue");
     });
 });
+describe("relatedRepositories in getTestbotPrompt (multi-repo mode)", () => {
+    const PRIMARY_REPO = "letsramp/primary-app";
+    const related = [
+        { repo: "letsramp/backend", repositoryPath: "/tmp/skyramp/related-repo-0-backend", baseBranch: "main" },
+        { repo: "letsramp/shared", repositoryPath: "/tmp/skyramp/related-repo-1-shared", baseBranch: "master" },
+    ];
+    function callWithRelated(repos, opts) {
+        return getTestbotPrompt(baseArgs.prTitle, baseArgs.prDescription, baseArgs.summaryOutputFile, baseArgs.repositoryPath, undefined, // baseBranch
+        undefined, // maxRecommendations
+        undefined, // maxGenerate
+        undefined, // maxCritical
+        undefined, // prNumber
+        undefined, // userPrompt
+        undefined, // services
+        undefined, // uiCredentials
+        opts?.testsRepoDir, // testsRepoDir
+        repos, opts?.primaryRepo ?? PRIMARY_REPO);
+    }
+    it("emits a <related_repositories> XML block with repository + path + base_branch per repo", () => {
+        const prompt = callWithRelated(related);
+        expect(prompt).toContain("<related_repositories>");
+        expect(prompt).toContain("</related_repositories>");
+        expect(prompt).toContain('<repository repository="letsramp/backend" path="/tmp/skyramp/related-repo-0-backend" base_branch="main" />');
+        expect(prompt).toContain('<repository repository="letsramp/shared" path="/tmp/skyramp/related-repo-1-shared" base_branch="master" />');
+        // Pure XML — no free-form "repositoryPath:" / "baseBranch:" colon syntax.
+        expect(prompt).not.toContain("repositoryPath:");
+        expect(prompt).not.toMatch(/baseBranch:/);
+    });
+    it("emits the primary repo's owner/repo in a <REPOSITORY> block", () => {
+        const prompt = callWithRelated(related);
+        expect(prompt).toContain(`<REPOSITORY>${PRIMARY_REPO}</REPOSITORY>`);
+    });
+    it("always emits a base_branch attribute, even when no explicit baseBranch is provided", () => {
+        const prompt = callWithRelated([
+            { repo: "letsramp/backend", repositoryPath: "/tmp/skyramp/related-repo-0-backend" },
+        ]);
+        expect(prompt).toContain("<related_repositories>");
+        // Absent value → explicit auto-detect marker in the attribute.
+        expect(prompt).toContain('<repository repository="letsramp/backend" path="/tmp/skyramp/related-repo-0-backend" base_branch="auto-detect" />');
+    });
+    it("keeps the unified workspace in the PRIMARY repo even when testsRepoDir is set", () => {
+        const prompt = callWithRelated(related, { testsRepoDir: "/tmp/skyramp/test-repo" });
+        // workspace.yml is registered in the primary repo regardless of the test repo.
+        expect(prompt).toContain(`\`workspacePath\`: "${baseArgs.repositoryPath}"`);
+        expect(prompt).not.toContain('`workspacePath`: "/tmp/skyramp/test-repo"');
+        // And it makes the primary-vs-test-repo distinction explicit to the agent.
+        expect(prompt).toMatch(/NOT in the configured test repo/);
+    });
+    it("leaves the single-repo prompt unchanged when no related repos are provided", () => {
+        const prompt = callWithRelated(undefined);
+        expect(prompt).not.toContain("<related_repositories>");
+        expect(prompt).not.toContain("MULTI-REPO CONTEXT");
+        expect(prompt).not.toContain("MULTI-REPO attribution");
+        // The cross-repo round-robin / candidate-pooling language must not leak into
+        // single-repo runs (the as-is GENERATE mandate stays authoritative there).
+        expect(prompt).not.toMatch(/round-robin/i);
+        expect(prompt).not.toContain("Multi-repo exception");
+        expect(prompt).not.toMatch(/candidates, not a fixed selection/i);
+    });
+    it("treats an empty array as single-repo", () => {
+        const prompt = callWithRelated([]);
+        expect(prompt).not.toContain("<related_repositories>");
+    });
+});
+describe("parseRelatedRepositories", () => {
+    it("parses a valid JSON array", () => {
+        const parsed = parseRelatedRepositories(JSON.stringify([
+            { repo: "o/a", repositoryPath: "/a", baseBranch: "main" },
+            { repo: "o/b", repositoryPath: "/b" },
+        ]));
+        expect(parsed).toEqual([
+            { repo: "o/a", repositoryPath: "/a", baseBranch: "main" },
+            { repo: "o/b", repositoryPath: "/b", baseBranch: undefined },
+        ]);
+    });
+    it("returns undefined for missing input", () => {
+        expect(parseRelatedRepositories(undefined)).toBeUndefined();
+        expect(parseRelatedRepositories("")).toBeUndefined();
+    });
+    it("returns undefined for malformed JSON", () => {
+        expect(parseRelatedRepositories("{not json")).toBeUndefined();
+    });
+    it("returns undefined for an empty array", () => {
+        expect(parseRelatedRepositories("[]")).toBeUndefined();
+    });
+    it("drops entries missing a repositoryPath or repo", () => {
+        const parsed = parseRelatedRepositories(JSON.stringify([
+            { repo: "o/x", baseBranch: "main" }, // no repositoryPath
+            { repositoryPath: "/no-repo" }, // no repo
+            { repo: "o/ok", repositoryPath: "/ok" },
+        ]));
+        expect(parsed).toEqual([{ repo: "o/ok", repositoryPath: "/ok", baseBranch: undefined }]);
+    });
+});

package/build/resources/sutSetupResource.d.ts

@@ -0,0 +1,2 @@
+import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
+export declare function registerSutSetupResource(server: McpServer): void;

package/build/resources/sutSetupResource.js

@@ -0,0 +1,45 @@
+import { ResourceTemplate, } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { logger } from "../utils/logger.js";
+import { resourceText } from "../utils/utils.js";
+import { AnalyticsService } from "../services/AnalyticsService.js";
+import { getAdaptWorkflowPrompt } from "../prompts/sut-setup/modes/adaptWorkflowPrompt.js";
+import { getDockerComposePrompt } from "../prompts/sut-setup/modes/dockerComposePrompt.js";
+import { SutSetupMode } from "../prompts/sut-setup/shared.js";
+export function registerSutSetupResource(server) {
+    logger.info("Registering SUT setup resource");
+    // RFC 6570 {+rest} (reserved expansion) captures the entire query string
+    // including the leading "?". This avoids the SDK's per-param regex which
+    // fails on empty query-param values.
+    const template = new ResourceTemplate("skyramp://prompts/skyramp_testbot_sut{+rest}", { list: undefined });
+    server.registerResource("skyramp_testbot_sut", template, {
+        title: "Skyramp Testbot SUT Setup",
+        description: "Returns mode-specific instructions for SUT (System Under Test) setup. " +
+            "Modes: none, adapt_workflow, docker_compose.",
+        mimeType: "text/plain",
+    }, async (uri) => {
+        const param = (name, fallback) => uri.searchParams.get(name) ?? fallback;
+        const mode = param("sutSetupMode", SutSetupMode.None);
+        const args = {
+            repositoryPath: param("repositoryPath", "."),
+            sutSetupMode: mode,
+            sutSourceWorkflowFile: param("sutSourceWorkflowFile", ""),
+            sutSourceDockerComposeFile: param("sutSourceDockerComposeFile", ""),
+        };
+        let prompt;
+        switch (mode) {
+            case SutSetupMode.AdaptWorkflow:
+                prompt = getAdaptWorkflowPrompt(args);
+                break;
+            case SutSetupMode.DockerCompose:
+                prompt = getDockerComposePrompt(args);
+                break;
+            case SutSetupMode.None:
+                prompt = "sutSetupMode is 'none'. No SUT setup required.";
+                break;
+            default:
+                prompt = `Unknown SUT setup mode: '${mode}'. Valid modes: none, adapt_workflow, docker_compose.`;
+        }
+        AnalyticsService.pushMCPToolEvent("skyramp_testbot_sut_resource", undefined, { mode }).catch(() => { });
+        return resourceText(uri.toString(), prompt);
+    });
+}

package/build/resources/testbotResource.js

@@ -2,7 +2,7 @@ import { ResourceTemplate, } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { logger } from "../utils/logger.js";
 import { AnalyticsService } from "../services/AnalyticsService.js";
 import { MAX_TESTS_TO_GENERATE, MAX_RECOMMENDATIONS, MAX_CRITICAL_TESTS, } from "../prompts/test-recommendation/recommendationSections.js";
-import { getTestbotPrompt, readWorkspaceServices } from "../prompts/testbot/testbot-prompts.js";
+import { getTestbotPrompt, readWorkspaceServices, parseRelatedRepositories, } from "../prompts/testbot/testbot-prompts.js";
 export function registerTestbotResource(server) {
     logger.info("Registering testbot resource");
     // RFC 6570 {+rest} (reserved expansion) captures the entire query string
@@ -25,7 +25,7 @@ export function registerTestbotResource(server) {
         const maxCrit = parseInt(uri.searchParams.get("maxCritical") || "", 10);
         const repositoryPath = param("repositoryPath", ".");
         const services = await readWorkspaceServices(repositoryPath);
-        const prompt = getTestbotPrompt(param("prTitle", ""), param("prDescription", ""), param("summaryOutputFile", ""), repositoryPath, uri.searchParams.get("baseBranch") || undefined, isNaN(maxRec) ? MAX_RECOMMENDATIONS : maxRec, isNaN(maxGen) ? MAX_TESTS_TO_GENERATE : maxGen, isNaN(maxCrit) ? MAX_CRITICAL_TESTS : maxCrit, isNaN(prNum) ? undefined : prNum, uri.searchParams.get("userPrompt") || undefined, services.length ? services : undefined, uri.searchParams.get("stateOutputFile") || undefined, uri.searchParams.get("uiCredentials") || undefined, uri.searchParams.get("testsRepoDir") || undefined);
+        const prompt = getTestbotPrompt(param("prTitle", ""), param("prDescription", ""), param("summaryOutputFile", ""), repositoryPath, uri.searchParams.get("baseBranch") || undefined, isNaN(maxRec) ? MAX_RECOMMENDATIONS : maxRec, isNaN(maxGen) ? MAX_TESTS_TO_GENERATE : maxGen, isNaN(maxCrit) ? MAX_CRITICAL_TESTS : maxCrit, isNaN(prNum) ? undefined : prNum, uri.searchParams.get("userPrompt") || undefined, services.length ? services : undefined, uri.searchParams.get("uiCredentials") || undefined, uri.searchParams.get("testsRepoDir") || undefined, parseRelatedRepositories(uri.searchParams.get("relatedRepositories") || undefined), uri.searchParams.get("primaryRepo") || undefined);
         AnalyticsService.pushMCPToolEvent("skyramp_testbot_prompt", undefined, {}).catch(() => { });
         // Return the original URI — clients may use it to re-fetch the resource,
         // and the caller already has these params. Credentials never appear in

package/build/services/TestDiscoveryService.d.ts

@@ -46,8 +46,8 @@ export declare class TestDiscoveryService {
      */
     private scoreRelevance;
     /**
-     * Partition external test files into relevant (score > 0) and low-relevance (score = 0)
-     * based on file path/name overlap with the changed resource names from the PR diff.
+     * Partition external test files into relevant (score > 0) and low-relevance (score = 0).
+     * Signal: path/name token overlap with changedResources.
      */
     private partitionByRelevance;
     /**

package/build/services/TestDiscoveryService.js

@@ -102,9 +102,7 @@ export class TestDiscoveryService {
                 this.partitionByRelevance(classified.external, changedResources));
         }
         else if (changedResources !== undefined) {
-            // PR mode with an explicit empty endpoint list from diff parsing — don't flood
-            // context with irrelevant external tests. The LLM will work from Skyramp tests
-            // and scanned endpoints only.
+            // PR mode with no path-resolvable endpoints — no path-based scoring available.
             relevantExternal = [];
             otherExternal = [];
         }
@@ -151,27 +149,39 @@ export class TestDiscoveryService {
         // Use the last two path segments to avoid false matches from deeply-nested dirs
         const segments = normalized.split("/").slice(-2).join("/");
         const tokens = new Set(segments.split(/[/\-_.]+/).filter(Boolean));
+        // Expand tokens with plural/singular variants so "deployment" matches
+        // "deployments" and vice versa. Only strip trailing "s" when the result
+        // is ≥4 chars (avoids "pas"→"pa") and doesn't end in "ss" (avoids "pass"→"pas").
+        const expanded = new Set(tokens);
+        for (const t of tokens) {
+            if (t.endsWith("s") && !t.endsWith("ss") && t.length > 4)
+                expanded.add(t.slice(0, -1));
+            else if (!t.endsWith("s"))
+                expanded.add(t + "s");
+        }
         return changedResources.filter(r => {
             const rLower = r.toLowerCase();
-            // Direct single-token match (e.g. "orders" in file path tokens)
-            if (tokens.has(rLower))
+            if (expanded.has(rLower))
                 return true;
-            // Compound resource names (e.g. "order-items" from /api/order-items) — check
-            // that ALL hyphen/underscore-separated parts appear as individual tokens.
-            // This handles test_order_items.py correctly matching resource "order-items".
+            // Compound resource names (e.g. "order-items") — all parts must appear as tokens.
             const parts = rLower.split(/[-_]/);
-            return parts.length > 1 && parts.every(p => p.length >= 3 && tokens.has(p));
+            return parts.length > 1 && parts.every(p => p.length >= 3 && expanded.has(p));
         }).length;
     }
     /**
-     * Partition external test files into relevant (score > 0) and low-relevance (score = 0)
-     * based on file path/name overlap with the changed resource names from the PR diff.
+     * Partition external test files into relevant (score > 0) and low-relevance (score = 0).
+     * Signal: path/name token overlap with changedResources.
      */
     partitionByRelevance(files, changedResources) {
         const relevant = [];
         const other = [];
         for (const f of files) {
-            (this.scoreRelevance(f, changedResources) > 0 ? relevant : other).push(f);
+            if (this.scoreRelevance(f, changedResources) > 0) {
+                relevant.push(f);
+            }
+            else {
+                other.push(f);
+            }
         }
         return { relevant, other };
     }

package/build/services/TestExecutionService.d.ts

@@ -1,8 +1,17 @@
 import { TestExecutionResult, BatchExecutionResult, TestExecutionOptions, ProgressCallback } from "../types/TestExecution.js";
-export declare const EXECUTOR_DOCKER_IMAGE = "skyramp/executor:v1.3.28";
+export declare const EXECUTOR_DOCKER_IMAGE = "skyramp/executor:v1.3.29";
 export declare const PLAYWRIGHT_CONFIG_FILES: string[];
 export declare const EXCLUDED_MOUNT_ITEMS: string[];
 export declare const MOUNT_NULL_ITEMS: string[];
+/**
+ * Check if a test type requires browser execution (UI/E2E)
+ */
+export declare function isBrowserTest(testType: string): boolean;
+/**
+ * Generate a deterministic unique subdirectory name for video output
+ * based on the test file path
+ */
+export declare function getVideoSubdir(testFile: string): string;
 /**
  * Detect session file paths referenced in test files
  * Looks for storageState patterns in TypeScript/JavaScript/Python/Java/C# test files