@skyramp/mcp 0.2.1 → 0.2.150-rc.sut

package/build/index.js

@@ -26,6 +26,8 @@ import { registerBatchScenarioTestTool } from "./tools/generate-tests/generateBa
 import { registerMockTool } from "./tools/generate-tests/generateMockRestTool.js";
 import { registerAnalyzeChangesTool, registerUiAnalyzeChangesTool, registerAnalyzeTestHealthTool, registerActionsTool, } from "./tools/test-management/index.js";
 import { registerTestbotPrompt } from "./prompts/testbot/testbot-prompts.js";
+import { registerSetupSutPrompt } from "./prompts/sut-setup/registerSetupSutPrompt.js";
+import { registerSutSetupResource } from "./resources/sutSetupResource.js";
 import { registerTestbotResource } from "./resources/testbotResource.js";
 import { registerSubmitReportTool } from "./tools/submitReportTool.js";
 import { registerInitializeWorkspaceTool } from "./tools/workspace/initializeWorkspaceTool.js";
@@ -123,7 +125,10 @@ const prompts = [
 if (isTestbotEnabled()) {
     prompts.push(registerTestbotPrompt);
     registerTestbotResource(server);
-    logger.info("TestBot prompt enabled via SKYRAMP_FEATURE_TESTBOT");
+    logger.info("Testbot prompt enabled via SKYRAMP_FEATURE_TESTBOT");
+    prompts.push(registerSetupSutPrompt);
+    registerSutSetupResource(server);
+    logger.info("Testbot SUT setup prompt and resource enabled via SKYRAMP_FEATURE_TESTBOT");
 }
 prompts.forEach((registerPrompt) => registerPrompt(server));
 logger.info("All prompts registered successfully");
@@ -174,7 +179,7 @@ const infrastructureTools = [
 ];
 if (isTestbotEnabled()) {
     infrastructureTools.push(registerSubmitReportTool);
-    logger.info("TestBot tools enabled via SKYRAMP_FEATURE_TESTBOT");
+    logger.info("Testbot tools enabled via SKYRAMP_FEATURE_TESTBOT");
 }
 infrastructureTools.forEach((registerTool) => registerTool(server));
 // Register Playwright browser tools (trace recording via browser automation)

package/build/prompts/sut-setup/modes/adaptWorkflowPrompt.js

@@ -0,0 +1,82 @@
+import { TESTBOT_WORKFLOW_PATH, buildContextBlock, buildCommonSutErrorsSection, buildLocalValidationSection, buildTestbotLifecycleInputsSection, getPersonaPrefix, } from "../shared.js";
+export function getAdaptWorkflowPrompt(args) {
+    const sourceLine = args.sutSourceWorkflowFile
+        ? `The user pointed at \`${args.sutSourceWorkflowFile}\` as the source workflow whose setup/teardown steps should be copied into the Testbot workflow. Use it as your primary source of setup steps — but still read the rest of the repo (other workflows, docker-compose, Kubernetes, Helm) to understand the full SUT shape.`
+        : `No specific source workflow was provided. Read ALL available GitHub workflows in this repository to learn how services are built, started, and authenticated, and pick the source workflow whose setup steps best match a SUT for testing (typically an e2e/integration workflow, not lint/release/security workflows).`;
+    const scanReadStep = args.sutSourceWorkflowFile
+        ? `Read the given source GitHub workflow file \`${args.sutSourceWorkflowFile}\` (the user's hint about which steps to lift), then ALSO read the rest of \`.github/workflows/\` and all infrastructure files (docker-compose, Kubernetes manifests, Helm charts) — the full SUT shape often lives across multiple files, so do NOT tunnel into the source workflow alone. Workflows show *how* the SUT is started; infrastructure files show *what* the SUT is. When a workflow step references an infra file (e.g., \`docker compose -f infra/compose.yml up\`, \`helm upgrade <chart>\`, \`kubectl apply -f k8s/\`), open that file too — services, ports, env vars, and dependencies live there.`
+        : `Read all GitHub workflow files in \`.github/workflows/\` AND all infrastructure files (docker-compose, Kubernetes manifests, Helm charts). Workflows show *how* the SUT is started; infrastructure files show *what* the SUT is. When a workflow step references an infra file (e.g., \`docker compose -f infra/compose.yml up\`, \`helm upgrade <chart>\`, \`kubectl apply -f k8s/\`), open that file too — services, ports, env vars, and dependencies live there. Pick the source workflow (the one whose SETUP/TEST/TEARDOWN steps will be lifted) once you have the full picture.`;
+    const thinkingSourceClause = args.sutSourceWorkflowFile
+        ? `confirms you are using \`${args.sutSourceWorkflowFile}\` as the source of setup steps (or explains why a different workflow is a better fit)`
+        : `names the workflow you selected as the source of setup steps and explains why`;
+    return `${getPersonaPrefix()}
+### Goal
+1. Generate working System Under Test (SUT) files that enable the Skyramp Testbot workflow (\`${TESTBOT_WORKFLOW_PATH}\`) to test any PR-specific code in this repository end-to-end for the services supported (REST or gRPC service APIs, queues, frontend UIs).
+2. Source workflow: ${sourceLine}
+3. Required output:
+   a. Output a <thinking> block that: (i) ${thinkingSourceClause}, (ii) summarizes what you learned about the SUT — services, secrets, auth, runner size — pulling from ALL workflows and infrastructure files, and (iii) decides how the SUT will be brought up — prefer Testbot lifecycle commands alone (targetSetupCommand, targetReadyCheckCommand, targetTeardownCommand) when the setup can be expressed as a single shell command; add GHA pre-steps only for tooling that cannot run in a shell (Buildx, cache, registry login) while still using lifecycle commands for service start; escalate to full GHA steps replacing service startup only when a single command cannot express it; use fully wrapped GHA steps for both setup and teardown only as a last resort. State clearly which approach was chosen and why.
+   b. Adapt the Testbot workflow file (\`${TESTBOT_WORKFLOW_PATH}\`) for bringing up the system under test.
+${buildContextBlock(args)}
+
+### Scan repo and understand the SUT
+1. ${scanReadStep}
+2. From the source workflow, classify each step by its *purpose* — not by its name or surface mechanism (\`env:\`, \`with:\`, and \`\${{ secrets.* }}\` can appear on any category and do not determine it):
+   a. SETUP — prepares the SUT (install, build, start services, migrate, seed, configure env or inject secrets for the SUT). Common attributes: \`env:\` blocks (e.g. \`DATABASE_URL\`, build flags), \`with:\` parameters (e.g. \`actions/cache\`, \`actions/setup-node\`), \`\${{ secrets.* }}\` references (e.g. registry login, deploy keys), dependency installs (e.g. \`npm ci\` before build).
+   b. TEST — runs the test suite (will be replaced by \`skyramp/testbot\`). Common attributes: \`env:\` blocks (e.g. \`API_BASE_URL\`, \`AUTH_TOKEN\`), \`with:\` parameters (e.g. \`actions/cache\`, custom test-runner actions), \`\${{ secrets.* }}\` references (e.g. test credentials, live-integration keys), dependency installs (e.g. \`npm ci\` right before \`npm test\` in the same step).
+   c. TEARDOWN — stops or cleans up.
+   d. UNRELATED — does none of those (lint, format, notifications, badges).
+
+   Output as:
+   \`\`\`
+   Step: "<step name>"  →  SETUP | TEST | TEARDOWN | UNRELATED
+   \`\`\`
+3. Summarize the SUT, pulling from all sources:
+   a. Setup commands needed to bring up all services (may come from multiple workflows / infra files).
+   b. Required secrets and env vars (with their \`\${{ secrets.* }}\` references and pass-through style — \`env:\` blocks vs. \`secrets: inherit\`).
+   c. Runner needed (\`runs-on\` value; large-ubuntu for heavy builds).
+   d. How an auth token is obtained (script, step output, or secret).
+
+### Decide SUT pattern
+The SUT must always be built from the PR's source code — Testbot reuses this workflow for every future PR, so it must validate the code in the PR being tested, not a stale snapshot. Use build: blocks in compose files (or docker build against the PR checkout) so images come from PR source. Pull-only image references and pinned upstream tags are fine for sidecars (databases, queues, caches), but the application services under test must be built locally.
+Evaluate the four patterns in strict priority order — always start with Pattern A and only escalate when it genuinely cannot express the setup. Full semantics for each lifecycle input are in the reference section below.
+1. Pattern A — Testbot lifecycle commands only (try this first, always)
+   Use when the entire setup — build, start, seed — can be expressed as one or two shell commands (e.g., docker compose up -d --build, make start, ./scripts/start.sh). Do NOT add any GHA steps. Set targetSetupCommand, targetReadyCheckCommand, targetReadyCheckTimeout, and targetTeardownCommand on the Testbot action; leave skipTargetSetup unset.
+2. Pattern B — Hybrid: GHA pre-steps for tool/env setup + Testbot lifecycle commands for service start
+   Use when the source workflow requires GHA-specific steps purely for environment or tooling (e.g., docker/setup-buildx-action, actions/cache, private registry login) but the actual service start can still be expressed as a single command. Copy only those tool/env pre-steps BEFORE the Testbot action. Set targetSetupCommand, targetReadyCheckCommand, targetReadyCheckTimeout, and targetTeardownCommand on the Testbot action; leave skipTargetSetup unset. Preserve every env:, with:, and \${{ secrets.* }} reference from the pre-steps exactly as written.
+3. Pattern C — GHA steps replace service startup + Testbot lifecycle validation
+   Use when the service startup itself requires multiple GHA steps that cannot be collapsed into a single command. Copy the source workflow's SETUP steps verbatim BEFORE the Testbot action. Set skipTargetSetup: 'true' and do not set targetSetupCommand. Set targetReadyCheckCommand and targetReadyCheckTimeout on the Testbot action. Add TEARDOWN steps AFTER the Testbot action with if: always(), or set targetTeardownCommand if a single command suffices — pick one, not both. Preserve every env:, with:, and \${{ secrets.* }} reference exactly as written.
+4. Pattern D — Fully wrapped by GHA steps
+   Use when teardown is also too complex for a single command. Copy the SETUP steps BEFORE and TEARDOWN steps AFTER the Testbot action (with if: always()). Set skipTargetSetup: 'true'. Do not set targetSetupCommand or targetTeardownCommand. Preserve every env:, with:, and \${{ secrets.* }} reference exactly as written.
+
+${buildTestbotLifecycleInputsSection()}
+
+### Adapt Testbot workflow
+#### What to do
+1. Edit \`${TESTBOT_WORKFLOW_PATH}\` (already created by the Testbot installer):
+   a. Apply the chosen pattern:
+      - Pattern A: set lifecycle inputs on the Testbot action, no GHA steps.
+      - Pattern B: add GHA tool/env pre-steps BEFORE the Testbot action, set lifecycle inputs (\`targetSetupCommand\`, \`targetReadyCheckCommand\`, \`targetTeardownCommand\`), leave \`skipTargetSetup\` unset.
+      - Pattern C: add GHA SETUP steps BEFORE the Testbot action, set \`skipTargetSetup: 'true'\`, set \`targetReadyCheckCommand\`, add TEARDOWN steps AFTER or set \`targetTeardownCommand\` — do NOT set \`targetSetupCommand\`.
+      - Pattern D: add GHA SETUP steps BEFORE and TEARDOWN steps AFTER the Testbot action, set \`skipTargetSetup: 'true'\`, do NOT set \`targetSetupCommand\` or \`targetTeardownCommand\`.
+   b. Update \`runs-on\` to match the runner needed by the source workflow's setup (some repos need large-ubuntu).
+   c. Pass all required secrets through — reuse the same \`\${{ secrets.* }}\` references or \`secrets: inherit\`. For GHA steps (Patterns B, C, D), set secrets via \`env:\` on the individual steps that need them; for lifecycle inputs (Patterns A, B), set them on the Testbot action or at the job level.
+   d. The basic file already contains the \`skyramp/testbot\` action — REPLACE the original workflow's test-run step with it, do NOT add a duplicate test runner step.
+2. Configure auth — use the lifecycle input reference above for full semantics of \`authTokenCommand\` and \`uiCredentials\`:
+   a. If the source workflow exports or seeds an auth token, set \`authTokenCommand\` on the Testbot action (or create \`.skyramp/sut/get-auth-token.sh\`).
+   b. If any service requires browser login, set \`uiCredentials\` on the Testbot action.
+   c. Omit both when the SUT is unauthenticated.
+3. Handle source-workflow shape:
+   a. If the original workflow uses \`matrix\` builds, pick ONE configuration for the Testbot workflow (matrix runs would multiply Testbot invocations).
+   b. If the original workflow uses \`needs:\` (job dependencies), inline the dependent job's steps into the Testbot job — Testbot runs as a single job.
+
+#### What not to do
+1. Do not modify any other GitHub workflow files referenced. The only github workflow file you may edit is \`${TESTBOT_WORKFLOW_PATH}\`; every other workflow under \`.github/workflows/\` (including the source workflow) is read-only reference material.
+2. Do not change the \`sutSetupMode\` input in \`${TESTBOT_WORKFLOW_PATH}\`. Testbot manages this value automatically — it must stay as provided so the next CI run knows to validate the adapted workflow rather than run tests. Changing it to \`none\` or any other value will break the bootstrap cycle.
+3. Do not point the SUT at a prebuilt upstream image (e.g. \`image: org/app:latest\` or a fixed commit SHA from \`main\`) for any application service under test. The image will lag the PR and Testbot will validate stale code.
+4. Do not point the SUT at a remote staging or production environment for application services under test. Staging code drifts from PR source and turns Testbot's results into noise. External infra is acceptable only for sidecar dependencies the PR does not change (e.g. a managed test database).
+
+### Verify
+${buildCommonSutErrorsSection()}
+${buildLocalValidationSection()}
+`;
+}

package/build/prompts/sut-setup/registerSetupSutPrompt.js

@@ -0,0 +1,49 @@
+import { z } from "zod";
+import { logger } from "../../utils/logger.js";
+import { AnalyticsService } from "../../services/AnalyticsService.js";
+import { getAdaptWorkflowPrompt } from "./modes/adaptWorkflowPrompt.js";
+export var SutSetupMode;
+(function (SutSetupMode) {
+    SutSetupMode["None"] = "none";
+    SutSetupMode["AdaptWorkflow"] = "adapt_workflow";
+})(SutSetupMode || (SutSetupMode = {}));
+export function registerSetupSutPrompt(server) {
+    logger.info("Registering SUT setup prompt");
+    server.registerPrompt("skyramp_testbot_sut", {
+        description: "Scan a repository and generate SUT (System Under Test) setup files for Skyramp Testbot. " +
+            "First milestone: adapts an existing CI/e2e workflow into the Testbot workflow.",
+        argsSchema: {
+            repositoryPath: z
+                .string()
+                .describe("Absolute path to the repository root"),
+            sutSetupMode: z
+                .nativeEnum(SutSetupMode)
+                .default(SutSetupMode.None)
+                .describe("SUT setup mode: none | adapt_workflow"),
+            sutSourceWorkflowFile: z
+                .string()
+                .default("")
+                .describe("Path to an existing workflow file to adapt. Example: .github/workflows/e2e-tests.yml"),
+        },
+    }, async (args) => {
+        const prompt = buildSutPrompt(args);
+        AnalyticsService.pushMCPToolEvent("skyramp_testbot_sut_prompt", undefined, { mode: args.sutSetupMode }).catch(() => { });
+        return {
+            messages: [
+                {
+                    role: "user",
+                    content: { type: "text", text: prompt },
+                },
+            ],
+        };
+    });
+}
+function buildSutPrompt(args) {
+    switch (args.sutSetupMode) {
+        case SutSetupMode.AdaptWorkflow:
+            return getAdaptWorkflowPrompt(args);
+        case SutSetupMode.None:
+        default:
+            return "sutSetupMode is 'none'. No SUT setup required.";
+    }
+}

package/build/prompts/sut-setup/shared.js

@@ -0,0 +1,80 @@
+import { getPersonaPrefix } from "../personas.js";
+/**
+ * Path of the Testbot workflow file relative to the repo root. Created by the
+ * Testbot installer and edited in-place by every SUT setup mode.
+ */
+export const TESTBOT_WORKFLOW_PATH = ".github/workflows/skyramp-testbot.yml";
+export function buildContextBlock(args) {
+    const lines = [];
+    lines.push(`<context>`);
+    lines.push(`Repository path: ${args.repositoryPath}`);
+    lines.push(`Setup mode: ${args.sutSetupMode}`);
+    if (args.sutSourceWorkflowFile)
+        lines.push(`Source workflow file: ${args.sutSourceWorkflowFile}`);
+    lines.push(`</context>`);
+    return lines.join("\n");
+}
+export function buildLocalValidationSection() {
+    return `Before reporting success, exercise the adapted workflow locally. Testbot's external fix loop only retries when SUT lifecycle commands are set on the Testbot action. When the SUT is brought up by surrounding GHA steps (skipTargetSetup: 'true'), the fix loop is skipped — so the local check below is the only safety net before the workflow is committed.
+Run commands one at a time in your shell — individual execution pinpoints failures far faster than running the whole workflow at once. Any non-zero exit is a fix-needed signal: adjust the workflow, re-run the failing command, and do not proceed until it passes.
+1. Validate build scripts and helper programs first — run these before anything else so build and auth failures surface cheaply:
+   a. Every helper script the workflow calls (e.g., \`./scripts/*.sh\`, \`make <target>\`, \`./gradlew <task>\`) — run each and confirm exit 0.
+   b. \`.skyramp/sut/get-auth-token.sh\` if present — run it and confirm it prints a non-empty token to stdout.
+   c. Every Dockerfile referenced by build steps — run \`docker build\` against each.
+   d. Every docker-compose file the workflow references — run \`docker compose -f <path> config\` to validate the YAML, then \`docker compose -f <path> build\`.
+2. Validate the SUT lifecycle — choose the branch that matches the chosen pattern:
+   a. If lifecycle commands are set on the Testbot action (skipTargetSetup is unset):
+      i. Run \`targetSetupCommand\` — confirm exit 0.
+      ii. Poll \`targetReadyCheckCommand\` until it exits 0 within \`targetReadyCheckTimeout\` seconds.
+      iii. Run \`targetTeardownCommand\` — confirm cleanup and exit 0.
+   b. If GHA steps wrap the Testbot action (skipTargetSetup: 'true'):
+      i. Extract the shell body of each SETUP step and run them in order. If a step depends entirely on a \${{ secrets.* }} value your shell cannot resolve, note it in <thinking> and skip — do not fabricate a value.
+      ii. Poll \`targetReadyCheckCommand\` until it exits 0.
+      iii. Extract and run each TEARDOWN step's body in order so the next iteration starts clean.
+Only proceed to the success report once setup → health check → teardown all pass.`;
+}
+/**
+ * Returns a reference block describing every Testbot action input that controls
+ * the SUT lifecycle and auth.  Embed this wherever a prompt needs the LLM to
+ * understand what knobs are available before choosing how to wire up the SUT.
+ */
+export function buildTestbotLifecycleInputsSection() {
+    return `#### Testbot action inputs — target lifecycle and auth
+Target lifecycle inputs (control how Testbot starts, validates, and stops the SUT):
+1. \`targetSetupCommand\` — shell command that builds and starts all SUT services. Testbot runs this before tests.
+   a. Default when unset: \`docker compose up -d\` (starts existing images, does NOT build).
+   b. For PR-source builds use \`docker compose up -d --build\` or the equivalent for helm/script-based SUTs.
+   c. Override whenever the source workflow's start sequence differs from the default.
+2. \`targetReadyCheckCommand\` — polling command (e.g., \`curl -sf http://localhost:8080/health\`) that Testbot runs repeatedly after setup until it exits 0 (service is ready) or the timeout is reached.
+   a. Always set this — without it Testbot proceeds immediately and tests may hit a not-yet-ready service.
+3. \`targetReadyCheckTimeout\` — seconds to wait for \`targetReadyCheckCommand\` to succeed.
+   a. Default: \`30\`. Cold Docker builds routinely take 60–180 s; always set this to \`'120'\` or higher for compose-based SUTs.
+4. \`targetTeardownCommand\` — shell command that stops and cleans up the SUT after tests (e.g., \`docker compose down -v\`).
+   a. Always set this so each run starts from a clean state.
+   b. Omit only when teardown is handled by surrounding GHA steps with \`if: always()\`.
+5. \`skipTargetSetup\` — when \`'true'\`, Testbot skips running \`targetSetupCommand\` entirely.
+   a. Set this only when GHA steps surrounding the Testbot action already bring the SUT up.
+   b. Leave it unset (or \`'false'\`) when Testbot should run the full lifecycle via the inputs above.
+Auth inputs (used by Testbot to authenticate against the running SUT during test recording and execution):
+6. \`authTokenCommand\` — shell command whose stdout is the auth credential for REST/gRPC API testing (e.g., a Bearer token, API key, or session cookie). Testbot captures the output and injects it as the \`Authorization\` header.
+   a. Set this when the SUT requires authentication for API calls.
+   b. If the source workflow exports a token via a step output or script, wire that same script here (e.g., \`bash .skyramp/sut/get-auth-token.sh\`).
+   c. If the workflow seeds a test user during setup, create \`.skyramp/sut/get-auth-token.sh\` that logs in with those credentials and prints the token.
+   d. Omit when the SUT APIs are unauthenticated.
+7. \`uiCredentials\` — \`username:password\` pair typed into the browser login form during UI test recording (format: \`myuser:mypassword\`).
+   a. Set for any frontend service that requires browser-based login.
+   b. Use \`\${{ secrets.SKYRAMP_UI_CREDENTIALS }}\` if the secret exists, otherwise use credentials seeded during SUT setup.`;
+}
+export function buildCommonSutErrorsSection() {
+    return `Before finishing, verify the adapted Testbot workflow setup against common errors seen during SUT setup:
+1. port_conflict — another container is already using the port. Pick a free host port or stop the conflicting container.
+2. image_not_found / build_failed — the referenced image does not exist for this SHA, or the build step has the wrong context/Dockerfile path. Build from PR source, do not rely on upstream commit-SHA tags.
+3. healthcheck_timeout — the service is slow to come up. Use \`targetReadyCheckTimeout >= 120\` and ensure the health endpoint actually exists.
+4. connection_refused — the service is not listening on the expected host/port (often binding to 127.0.0.1 inside the container; bind to 0.0.0.0).
+5. dependency_error — required service (DB, cache, queue) is missing from compose or not healthy before the app starts. Add \`depends_on\` with \`condition: service_healthy\`.
+6. permission_denied — script is not executable (\`chmod +x\`) or volume mount has wrong ownership.
+7. auth_endpoint_404 / auth_credentials_invalid — the auth script hits a wrong path, or the database has no seeded user. The auth script must create the user before login when starting from a fresh DB.
+8. missing env vars / secrets — required env vars are unset on the runner. Either default them in the script or pass them through workflow \`env:\`.
+Do not add an in-prompt fix loop — Testbot's external validator will retry with concrete error context if any of these occur.`;
+}
+export { getPersonaPrefix };

package/build/resources/sutSetupResource.js

@@ -0,0 +1,47 @@
+import { ResourceTemplate, } from "@modelcontextprotocol/sdk/server/mcp.js";
+import { logger } from "../utils/logger.js";
+import { AnalyticsService } from "../services/AnalyticsService.js";
+import { getAdaptWorkflowPrompt } from "../prompts/sut-setup/modes/adaptWorkflowPrompt.js";
+import { SutSetupMode } from "../prompts/sut-setup/registerSetupSutPrompt.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.",
+        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", ""),
+        };
+        let prompt;
+        switch (mode) {
+            case SutSetupMode.AdaptWorkflow:
+                prompt = getAdaptWorkflowPrompt(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.`;
+        }
+        AnalyticsService.pushMCPToolEvent("skyramp_testbot_sut_resource", undefined, { mode }).catch(() => { });
+        return {
+            contents: [
+                {
+                    uri: uri.toString(),
+                    mimeType: "text/plain",
+                    text: prompt,
+                },
+            ],
+        };
+    });
+}

package/build/utils/docker.test.js

@@ -54,7 +54,7 @@ describe("dockerImageExistsLocally", () => {
     });
 });
 describe("pullDockerImage", () => {
-    const IMAGE = "skyramp/executor:v1.3.26";
+    const IMAGE = "skyramp/executor:v1.3.25";
     beforeEach(() => jest.clearAllMocks());
     describe("on amd64 host", () => {
         const originalArch = process.arch;

package/build/utils/versions.js

@@ -1,3 +1,3 @@
-export const SKYRAMP_IMAGE_VERSION = "v1.3.26";
+export const SKYRAMP_IMAGE_VERSION = "v1.3.25";
 export const EXECUTOR_DOCKER_IMAGE = `skyramp/executor:${SKYRAMP_IMAGE_VERSION}`;
 export const WORKER_DOCKER_IMAGE = `skyramp/worker:${SKYRAMP_IMAGE_VERSION}`;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/mcp",
-  "version": "0.2.1",
+  "version": "0.2.150-rc.sut",
   "main": "build/index.js",
   "exports": {
     ".": "./build/index.js",
@@ -55,7 +55,7 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.24.3",
     "@playwright/test": "^1.55.0",
-    "@skyramp/skyramp": "1.3.26",
+    "@skyramp/skyramp": "1.3.25",
     "dockerode": "^5.0.0",
     "fast-glob": "^3.3.3",
     "js-yaml": "^4.1.1",