@cat-factory/server 0.49.2 → 0.49.6

package/dist/agents/ContainerAgentExecutor.js

@@ -1,10 +1,11 @@
 import {} from '@cat-factory/kernel';
 import { CONTEXT_BUDGET, CredentialRequiredError, renderTaskContext, SUBSCRIPTION_VENDORS, isIndividualVendor, } from '@cat-factory/kernel';
 import { resolveInstanceTypeId } from '@cat-factory/contracts';
-import { agentTuningFor, composeBlockSystemPrompt, FINAL_ANSWER_IN_REPLY, FOLLOW_UP_GUIDANCE, isContainerBackedCompanion, isProxyableProvider, isReadOnlyAgentKind, registeredAgentStep, systemPromptFor, userPromptFor, webResearchGuidanceFor, } from '@cat-factory/agents';
+import { agentTuningFor, isProxyableProvider, isReadOnlyAgentKind, webResearchGuidanceFor, } from '@cat-factory/agents';
 import { ModelRouter } from './ModelRouter.js';
 import { toRunResult } from './containerAgentResult.js';
-import { BLUEPRINTS_AGENT_KIND, CI_FIXER_AGENT_KIND, CONFLICT_RESOLVER_AGENT_KIND, FIXER_AGENT_KIND, MERGER_AGENT_KIND, ON_CALL_AGENT_KIND, SPEC_WRITER_AGENT_KIND, TESTER_AGENT_KIND, UI_TESTER_AGENT_KIND, } from '@cat-factory/orchestration';
+import { buildKindBody } from './jobBody.js';
+import { UI_TESTER_AGENT_KIND } from '@cat-factory/orchestration';
 import { RunnerJobClient } from './RunnerJobClient.js';
 /**
  * The repo spec every container job body carries: clone coordinates plus, for a
@@ -202,122 +203,6 @@ function buildContextFiles(context) {
 }
 /** Poll cadence for the non-durable `run()` fallback (the durable driver sleeps between polls itself). */
 const RUN_POLL_INTERVAL_MS = 5_000;
-/** Role prompt the Blueprinter step's agent runs under (returns the tree as JSON). */
-const BLUEPRINT_SYSTEM_PROMPT = 'You are a Domain-Driven Design architect mapping this repository. Decompose it ' +
-    'into ONE top-level service and the modules inside it, where each module is a ' +
-    'DOMAIN — a cohesive area of the BUSINESS, in the language of the problem space ' +
-    '(a DDD bounded context / aggregate / subdomain). Name modules after business ' +
-    'concepts, not technical layers. ' +
-    'A module MUST represent a business capability or domain model (e.g. Billing, ' +
-    'Catalog, Ordering, Identity), NOT a technical layer or shape: "api", "routes", ' +
-    '"controllers", "utils", "helpers", "lib", "common", "config", "types", "models", ' +
-    '"db" and the like are NOT domains and MUST NOT be modules. ' +
-    'Group the genuinely non-business, technical/cross-cutting plumbing (persistence ' +
-    'wiring, HTTP/transport, logging, configuration, auth middleware, build/deploy, ' +
-    'shared utilities) into a SINGLE module named "infrastructure" rather than ' +
-    'scattering it into many technical modules. ' +
-    'Prefer organising code by domain (the ubiquitous language) over organising by ' +
-    'file type. Anchor every node to the codebase with explicit repo-relative ' +
-    'file/directory references. Keep names short and descriptive. ' +
-    'Respond with ONLY a JSON object of shape {"type","name","summary","references":[],' +
-    '"modules":[{"name","summary","references":[]}]} — no prose, no code fences. ' +
-    FINAL_ANSWER_IN_REPLY;
-/** Role prompt the spec-writer step runs under (returns the spec doc as JSON). */
-const SPEC_WRITER_SYSTEM_PROMPT = 'You maintain the PRESCRIPTIVE specification for a service. READ the specification ' +
-    'already committed to the repository under `spec/` (the baseline): start with ' +
-    '`spec/overview.md` for the module → feature index, then open the relevant ' +
-    '`spec/modules/<module>/<feature>.json` shards for the detail you need. You are also ' +
-    'given the ' +
-    'requirements of ONE task. Apply that task as an INCREMENT onto the baseline: add ' +
-    'requirements for what the task introduces, and adjust existing requirements ONLY ' +
-    'where the task changes their expected behaviour. Leave every other part of the ' +
-    'baseline spec untouched. Translate ONLY what the task requirements state — do NOT ' +
-    'invent requirements, fill gaps, or design beyond them (missing requirements are the ' +
-    'requirements step’s job, not yours). ' +
-    'The spec captures ONLY BUSINESS requirements — externally-observable behaviour, ' +
-    'product rules and acceptance criteria. PURELY TECHNICAL work (a refactor, a ' +
-    'dependency bump, internal restructuring, build/infra or other non-functional change ' +
-    'that does NOT alter what the system does for its users) introduces no business ' +
-    'requirements, and "NO NEW SPECS" is a valid, correct outcome for it: do NOT invent ' +
-    'requirements to justify a change, and do NOT re-document technical/architecture ' +
-    'detail here. When this task is purely technical, leave the baseline spec untouched ' +
-    'and respond with ONLY {"noBusinessSpecs": true} (no other fields, no prose, no code ' +
-    'fences). Otherwise return the full document as below. ' +
-    'The spec is a two-level taxonomy: MODULES ' +
-    '(domains, e.g. "Auth") each containing GROUPS (features, e.g. "Login"). Every ' +
-    'requirement AND every domain rule lives inside a specific feature group: a group ' +
-    'carries both its `requirements` and the `rules` scoped to it. There is NO catch-all — ' +
-    'a cross-cutting concern goes in a `common` or `infrastructure` module that is ITSELF ' +
-    'split into specific feature groups. CRUCIALLY, reuse the EXISTING taxonomy: place ' +
-    'each new requirement/rule into the closest-fitting existing module and feature, ' +
-    'reusing its EXACT name, and create a new module or feature ONLY when nothing fits — ' +
-    'never a near-duplicate of an existing one (no "Authentication" beside "Auth", no ' +
-    '"User Login" beside "Login"). Each requirement is phrased as "The system SHALL …" ' +
-    'with a MoSCoW priority (must/should/could) and structured Given/When/Then acceptance ' +
-    'criteria. Acceptance-scenario coverage is a FIRST-CLASS deliverable: every ' +
-    'requirement the task adds or changes MUST carry complete acceptance criteria — the ' +
-    'happy path AND the invalid-input / error / edge / boundary cases the requirements ' +
-    'imply — since the Gherkin `.feature` files and the runnable tests are derived ' +
-    'mechanically from them. Preserve the baseline’s existing `sourceBlockIds`; tag the ' +
-    'requirements this task adds or changes with this task’s block id. Return the ' +
-    'COMPLETE updated specification (baseline plus this increment), not a diff. You have ' +
-    'NO repository write access and MUST NOT write, edit, or commit any file: the platform ' +
-    'persists the specification you return, so returning it IS the whole job. Respond ' +
-    'with ONLY a JSON object of ' +
-    'shape {"service","summary","modules":[{"name","summary","groups":[{"name","summary",' +
-    '"requirements":[{"id","title","statement","kind","priority","sourceBlockIds":[],' +
-    '"acceptance":[{"id","given","when","outcome"}]}],"rules":[{"id","rule","rationale",' +
-    '"sourceBlockIds":[]}]}]}]} ' +
-    '(each acceptance criterion is a Given/When/Then, with the Then clause in `outcome`) — ' +
-    'no prose, no code fences. ' +
-    FINAL_ANSWER_IN_REPLY;
-/** Role prompt the `merger` step runs under (scores the PR; returns JSON only). */
-const MERGER_SYSTEM_PROMPT = 'You are a release manager assessing a pull request before merge. Inspect the ' +
-    'diff between the PR head branch and the base branch and judge three axes, each ' +
-    'as a number from 0 (trivial/safe) to 1 (severe): complexity (how intricate the ' +
-    'change is), risk (how likely it is to break something), and impact (blast radius ' +
-    'if it does). Be conservative. Respond with ONLY a JSON object of shape ' +
-    '{"complexity":0.0,"risk":0.0,"impact":0.0,"rationale":"…"} — no prose, no code fences. ' +
-    FINAL_ANSWER_IN_REPLY;
-/** Compact shape hint fed to the structured-output repair call for the blueprint tree. */
-const BLUEPRINT_SHAPE_HINT = 'Expected a service tree: {"type": string, "name": string, "summary": string, ' +
-    '"references": string[], "modules": [{"name": string, "summary": string, ' +
-    '"references": string[]}]}.';
-/** Compact shape hint fed to the structured-output repair call for the spec doc. */
-const SPEC_SHAPE_HINT = 'Expected a requirements document with a two-level taxonomy — module (domain) → ' +
-    'group (feature) — where each group carries BOTH its requirements and the domain ' +
-    'rules scoped to it: {"service": string, "summary": string, "modules": [{"name": ' +
-    'string, "summary": string, "groups": [{"name": string, "summary": string, ' +
-    '"requirements": [{"id": string, "title": string, "statement": string, "kind": ' +
-    'string, "priority": string, "sourceBlockIds": string[], "acceptance": [{"given": ' +
-    'string, "when": string, "outcome": string}]}], "rules": [{"id": string, "rule": ' +
-    'string, "rationale": string, "sourceBlockIds": string[]}]}]}]}. For a purely ' +
-    'technical task with no business requirements, the document is instead just ' +
-    '{"noBusinessSpecs": true}.';
-/** Compact shape hint fed to the structured-output repair call for the merger assessment. */
-const MERGE_ASSESSMENT_SHAPE_HINT = 'Expected a merge assessment: {"complexity": number 0..1, "risk": number 0..1, ' +
-    '"impact": number 0..1, "rationale": string}.';
-/** Compact shape hint fed to the structured-output repair call for the on-call assessment. */
-const ON_CALL_ASSESSMENT_SHAPE_HINT = 'Expected an on-call assessment: {"culpritConfidence": number 0..1, "recommendation": ' +
-    '"revert"|"hold"|"monitor", "rationale": string, "evidence": string[]}.';
-/** Compact shape hint fed to the structured-output repair call for the tester report. */
-const TEST_REPORT_SHAPE_HINT = 'Expected a test report: {"greenlight": boolean, "summary": string, "tested": string[], ' +
-    '"outcomes": [{"name": string, "status": "passed"|"failed"|"skipped", "detail"?: string}], ' +
-    '"concerns": [{"title": string, "detail": string, "severity": "low"|"medium"|"high"|"critical"}]}.';
-/** Shape hint for the UI tester: a test report that also lists captured screenshots. */
-const UI_TEST_REPORT_SHAPE_HINT = TEST_REPORT_SHAPE_HINT.replace(/\}\.$/, '') +
-    ', "screenshots": [{"view": string, "artifactId": string, "hash"?: string}]}. Each ' +
-    'screenshot must be a distinct view you captured and uploaded to the artifact store.';
-const ON_CALL_SYSTEM_PROMPT = 'You are an on-call engineer investigating a possible post-release regression. A ' +
-    'recently merged pull request shipped, and the evidence below (alerting Datadog ' +
-    'monitors/SLOs and recent error logs) suggests the service regressed afterward. Read ' +
-    'the PR diff on the head branch and weigh whether THIS change is the likely cause — ' +
-    'beware correlation vs causation; a coincident deploy is not proof. You may read and ' +
-    'inspect any file, but you MUST NOT modify, commit or revert anything; a human decides ' +
-    'whether to revert. Respond with ONLY a JSON object of shape ' +
-    '{"culpritConfidence":0.0,"recommendation":"revert"|"hold"|"monitor","rationale":"…",' +
-    '"evidence":["…"]} — no prose, no code fences. ' +
-    FINAL_ANSWER_IN_REPLY;
 /**
  * An {@link AgentExecutor} that performs implementation work in a real sandbox:
  * it dispatches a per-run container running the Pi coding agent (a per-run
@@ -672,7 +557,7 @@ export class ContainerAgentExecutor {
             webToolsGuidance: webResearchGuidanceFor(context.agentKind, { fetch: true }),
             ...(webSearchEnabled ? { webSearch: true } : {}),
         };
-        const { body, kind } = this.buildKindBody(promptContext, {
+        const { body, kind } = buildKindBody(promptContext, {
             common,
             webTools,
             repo,
@@ -764,450 +649,5 @@ export class ContainerAgentExecutor {
             ...(subscriptionTokenId ? { subscriptionTokenId } : {}),
         };
     }
-    /**
-     * Build the per-kind harness job body: the shared `common` fields plus ONLY the delta
-     * specific to this kind's harness endpoint (its prompts, the branch it runs on, and
-     * any per-kind extras), and the matching dispatch `kind`. The web-search fields live
-     * in `webTools` (shared by the kinds that allow web access). The dispatch precedence
-     * matches the original if-ladder exactly: the specific kinds first, then any read-only
-     * kind, then the default coder body.
-     */
-    buildKindBody(context, parts) {
-        // `parts` (common/webTools/workBranch/workBranchReady) is consumed by
-        // `buildRegisteredAgentBody`/`buildMigratedBuiltInBody`, not directly here.
-        const baseRoleSystemPrompt = composeBlockSystemPrompt(systemPromptFor(context.agentKind), context.block);
-        // When the future-looking Follow-up companion is enabled for this (coder) step, append
-        // the guidance that tells the Coder to stream loose-ends / side-tasks / questions to the
-        // sentinel file the harness tails. Only when enabled, so a disabled companion (or any
-        // other kind) never writes the file.
-        const roleSystemPrompt = context.followUpCompanion
-            ? `${baseRoleSystemPrompt}\n\n${FOLLOW_UP_GUIDANCE}`
-            : baseRoleSystemPrompt;
-        // A registered (custom or migrated) kind that declares an `agent` step dispatches
-        // through the generic, manifest-driven `agent` harness kind — no per-kind case here.
-        // Built-in kinds (below) still carry their bespoke bodies until they are migrated.
-        const registeredStep = registeredAgentStep(context.agentKind);
-        if (registeredStep) {
-            return this.buildRegisteredAgentBody(context, parts, registeredStep, roleSystemPrompt);
-        }
-        // Built-in container kinds migrated onto the generic, manifest-driven `agent` harness
-        // kind (they dispatch `kind:'agent'` through `buildRegisteredAgentBody`, exactly like a
-        // registered custom kind, with NO bespoke per-kind harness handler) — the Task-5
-        // strangler. Today: blueprints/spec-writer (structured explore + render post-op), the
-        // in-place fixers (`ci-fixer` / `fixer`, coding-on-PR), the JSON-assessment producers
-        // (`merger` / `on-call`, read-only structured explore whose assessment is coerced
-        // backend-side in `toRunResult`), the `tester` (read-only structured explore with
-        // docker-compose infra stand-up), and the conflict-resolver (coding with a `mergeBase`).
-        // The default coder dispatches the generic coding agent at the end of this method.
-        const migrated = this.buildMigratedBuiltInBody(context, parts, roleSystemPrompt);
-        if (migrated)
-            return migrated;
-        // Container-backed companions (reviewer / doc-reviewer): a read-only explore that clones
-        // the producer's PR branch and reads the ACTUAL repository (changed files / committed
-        // document) before rating it, returning the verdict as structured JSON. Surfaced to the
-        // engine as `result.custom` (the default `toRunResult` branch) and parsed back into a
-        // CompanionAssessment by `CompanionController.resolveContainerVerdict`. The companion
-        // review system prompt (which already instructs the JSON shape and, for these kinds, to
-        // read the checkout) wins in `systemPromptFor`, so no per-kind prompt wiring is needed.
-        if (isContainerBackedCompanion(context.agentKind)) {
-            return this.buildRegisteredAgentBody(context, parts, { surface: 'container-explore', clone: { branch: 'pr' }, output: { kind: 'structured' } }, roleSystemPrompt);
-        }
-        // Read-only agents (architect, analysis) explore a real checkout but never edit it:
-        // they clone a branch, produce a prose report/proposal and return it as `output`,
-        // making no commit and opening no PR (and — unlike a coding run — an edit-free run is
-        // the expected, correct outcome, not a failure). They dispatch through the generic,
-        // manifest-driven `agent` kind in `explore` mode — the SAME path a registered
-        // `container-explore` kind takes — instead of a bespoke per-kind harness handler. A
-        // synthesized read-only step (no clone target ⇒ the shared work-branch fallback, so
-        // e.g. the architect reads the spec-writer's committed `spec/` and any in-progress
-        // implementation, falling back to base when no work/PR branch exists) yields a body
-        // byte-identical to the old `/explore` job, minus only the harness-internal temp-dir
-        // label. This is the first built-in migrated onto the generic agent surface (the
-        // Task-5 strangler); the now-dead `/explore` harness handler is deleted in a
-        // follow-up once parity is confirmed on CI.
-        if (isReadOnlyAgentKind(context.agentKind)) {
-            return this.buildRegisteredAgentBody(context, parts, { surface: 'container-explore' }, roleSystemPrompt);
-        }
-        // The default coder (and any other write-and-PR kind): the build-phase role plus the
-        // block's selected best-practice fragments. Dispatches the generic `container-coding`
-        // agent onto the deterministic per-task work branch (`clone: 'work'` ⇒ branch off base,
-        // push the work branch, open a PR). The work-branch name is deterministic per task
-        // (block), NOT per dispatch — a retry mints a fresh executionId but keeps the blockId —
-        // so every re-dispatch targets the SAME branch; `runCodingAgent` checkpoints commits to
-        // it and RESUMES on it if it already exists, so an evicted/failed run's work survives.
-        // This is behaviour-equivalent to the old bespoke `/run` body (handleAgent coding mode
-        // is built on the same `runCodingAgent` primitive); the dead `/run` handler is removed
-        // in the harness-cleanup step.
-        return this.buildRegisteredAgentBody(context, parts, { surface: 'container-coding', clone: { branch: 'work' } }, roleSystemPrompt);
-    }
-    /**
-     * Build the generic `agent` job body for a registered kind from its declarative
-     * {@link AgentStepSpec} — the single dispatch path that replaces the per-kind cases as
-     * built-ins migrate. `container-explore` clones a branch read-only and returns prose
-     * (or, for `output.kind==='structured'`, a parsed `custom` JSON object the kind's
-     * post-op renders from); `container-coding` clones, edits, pushes and (off the work
-     * branch) opens a PR. The clone target maps `base`/`pr`/`work` to a concrete branch
-     * exactly as the built-in bodies do.
-     */
-    buildRegisteredAgentBody(context, parts, step, roleSystemPrompt, 
-    /**
-     * The concrete task prompt. Defaults to the generic `userPromptFor` (block context +
-     * prior outputs) — the same prompt a registered custom kind gets. A migrated built-in
-     * (merger / on-call) overrides it with its bespoke, JSON-instructing prompt so its
-     * body matches the old per-kind handler's.
-     */
-    userPrompt = userPromptFor(context, { materialized: true })) {
-        const { common, webTools, repo, workBranch, workBranchReady } = parts;
-        const prBranch = context.block.pullRequest?.branch;
-        const onPr = step.clone?.branch === 'pr';
-        const exploreBranch = step.clone?.branch === 'base'
-            ? repo.baseBranch
-            : onPr
-                ? (prBranch ?? repo.baseBranch)
-                : workBranchReady
-                    ? workBranch
-                    : (prBranch ?? repo.baseBranch);
-        if (step.surface === 'container-coding') {
-            // `pr` clone ⇒ work in place on the PR branch and push back (fixer-like, no new PR);
-            // otherwise branch off base onto the work branch, push it and open a PR (coder-like).
-            return {
-                kind: 'agent',
-                body: {
-                    ...common,
-                    mode: 'coding',
-                    systemPrompt: roleSystemPrompt,
-                    userPrompt,
-                    branch: onPr ? (prBranch ?? repo.baseBranch) : repo.baseBranch,
-                    ...(onPr ? {} : { newBranch: workBranch }),
-                    pushBranch: onPr ? (prBranch ?? workBranch) : workBranch,
-                    ...(onPr
-                        ? { noChangesIsError: false }
-                        : {
-                            pr: {
-                                title: `${context.block.title} (${context.pipelineName})`,
-                                body: prBody(context),
-                            },
-                        }),
-                    ...(step.clone?.full ? { full: true } : {}),
-                    // The Coder (follow-up companion enabled) streams forward-looking items out via
-                    // the sentinel file; tell the harness to tail it. Only on the implementer path.
-                    ...(context.followUpCompanion && !onPr ? { streamFollowUps: true } : {}),
-                    ...webTools,
-                },
-            };
-        }
-        // container-explore (read-only): prose, or a structured JSON object as `custom`.
-        return {
-            kind: 'agent',
-            body: {
-                ...common,
-                mode: 'explore',
-                systemPrompt: roleSystemPrompt,
-                userPrompt,
-                branch: exploreBranch,
-                ...(step.clone?.full ? { full: true } : {}),
-                ...(step.output?.kind === 'structured'
-                    ? {
-                        output: {
-                            kind: 'structured',
-                            ...(step.output.shapeHint ? { shapeHint: step.output.shapeHint } : {}),
-                            ...(step.output.repair === false ? { repair: false } : {}),
-                            ...(step.output.failOnUnusableFinal ? { failOnUnusableFinal: true } : {}),
-                        },
-                    }
-                    : {}),
-                ...webTools,
-            },
-        };
-    }
-    /**
-     * Build the generic `agent` body for a BUILT-IN container kind being migrated onto the
-     * manifest-driven path (the Task-5 strangler), or undefined when `context.agentKind` is
-     * not a migrated built-in (the caller falls through to the remaining bespoke switch). Each
-     * migrated kind is expressed as a synthesized {@link AgentStepSpec} routed through
-     * {@link buildRegisteredAgentBody} — the SAME dispatch a registered custom kind takes — so
-     * there is no bespoke harness handler:
-     *   - `ci-fixer` / `fixer`: coding-on-PR (clone the PR branch, push back, no new PR; a
-     *     no-op is non-fatal). Requires the implementation PR branch.
-     *   - `merger` / `on-call`: read-only structured explore (full clone) that returns ONLY a
-     *     JSON assessment; the conservative coercion that used to live in the harness runs
-     *     backend-side in {@link toRunResult}.
-     *   - `conflict-resolver`: coding (full clone of the PR branch) with a `mergeBase` — the
-     *     harness merges the base in to surface the conflicts, the agent resolves them, and the
-     *     harness completes the merge commit + pushes back onto the same branch (no new PR).
-     */
-    buildMigratedBuiltInBody(context, parts, roleSystemPrompt) {
-        const { repo } = parts;
-        const prBranch = context.block.pullRequest?.branch;
-        switch (context.agentKind) {
-            // The Blueprinter maps the repo into the service → modules tree. It now runs as a
-            // read-only structured explore (clone the PR branch when present, else the default
-            // branch — exactly its old `prBranch ?? baseBranch` clone), returning ONLY the tree
-            // as JSON; the deterministic render + commit of the `blueprints/` artifact that used
-            // to live in the harness `/blueprint` handler is the backend `blueprintPostOp` (run
-            // from ExecutionService), and `toRunResult` coerces the JSON into `blueprintService`
-            // for the board reconcile + that post-op.
-            case BLUEPRINTS_AGENT_KIND:
-                return this.buildRegisteredAgentBody(context, parts, {
-                    surface: 'container-explore',
-                    clone: { branch: 'pr' },
-                    output: { kind: 'structured', shapeHint: BLUEPRINT_SHAPE_HINT },
-                }, BLUEPRINT_SYSTEM_PROMPT, blueprintUserPrompt());
-            // The spec-writer maintains the prescriptive `spec/` document. It now runs as a
-            // read-only structured explore on the per-block WORK branch (clone `work` — the
-            // deterministic `cat-factory/<blockId>` the coder resumes, created from base when
-            // absent; it runs BEFORE the coder, so it SEEDS that branch). The agent READS the
-            // baseline spec from its own checkout (`spec/`), applies this ONE task as an increment,
-            // and returns the COMPLETE tree as JSON; the deterministic SHARD + commit of the
-            // `spec/` artifact that used to live in the harness `/spec` handler is the backend
-            // `specPostOp` (run from ExecutionService), and `toRunResult` coerces the JSON into the
-            // `spec` channel the engine strict-validates + that post-op renders/commits from. It
-            // NEVER targets base: the spec is prescriptive for not-yet-landed work, so it merges
-            // WITH the feature, never reaching `main` ahead of it.
-            case SPEC_WRITER_AGENT_KIND:
-                return this.buildRegisteredAgentBody(context, parts, {
-                    surface: 'container-explore',
-                    clone: { branch: 'work' },
-                    // The spec doc is handed onward to be sharded + committed by `specPostOp`, so a
-                    // final answer cut off at the output ceiling must FAIL LOUDLY (the bespoke `/spec`
-                    // handler's `unusableFinalAnswerCause` gate) rather than be laundered into a
-                    // half-baked spec by the structured repair — exactly what drove the old
-                    // spec-writer ⇄ companion rework loop.
-                    output: { kind: 'structured', shapeHint: SPEC_SHAPE_HINT, failOnUnusableFinal: true },
-                }, SPEC_WRITER_SYSTEM_PROMPT, specWriterUserPrompt(context));
-            // In-place fixers: clone the PR head branch, push fixes back onto it (no new PR);
-            // a no-op run is a clean non-event (the gate/loop re-checks the real signal).
-            case CI_FIXER_AGENT_KIND:
-                if (!prBranch)
-                    throw new Error('CI-fixer needs the implementation PR branch to push fixes to');
-                return this.buildRegisteredAgentBody(context, parts, { surface: 'container-coding', clone: { branch: 'pr' } }, roleSystemPrompt);
-            case FIXER_AGENT_KIND:
-                if (!prBranch)
-                    throw new Error('Fixer needs the implementation PR branch to push fixes to');
-                return this.buildRegisteredAgentBody(context, parts, { surface: 'container-coding', clone: { branch: 'pr' } }, roleSystemPrompt);
-            // The conflict-resolver clones the PR head branch (full history), merges the base in
-            // to surface the conflicts, resolves them and pushes back onto the SAME branch (no new
-            // branch / PR) so the PR becomes mergeable and CI re-runs. It dispatches the generic
-            // coding agent with a `mergeBase` (the harness merges `origin/<mergeBase>` in before the
-            // agent runs); the harness leads the prompt with the actual conflict hunks it discovers.
-            //
-            // Unlike the CI-fixer it is deliberately NOT given `userPromptFor(context)`: that renders
-            // the full task brief + every prior agent's output (the spec-writer's whole spec, etc.),
-            // which buries the one-line "resolve a conflict" role and drifts the model onto
-            // re-implementing the feature (observed in prod: a resolver that returned a "test report
-            // is ready" answer and never touched the markers). The backend supplies only a compact
-            // task reference for intent.
-            case CONFLICT_RESOLVER_AGENT_KIND: {
-                if (!prBranch) {
-                    throw new Error('Conflict-resolver needs the implementation PR branch to resolve conflicts on');
-                }
-                const description = context.block.description?.trim();
-                const built = this.buildRegisteredAgentBody(context, parts, { surface: 'container-coding', clone: { branch: 'pr', full: true } }, roleSystemPrompt, `Task: ${context.block.title}${description ? `\n\n${description}` : ''}`);
-                return { kind: built.kind, body: { ...built.body, mergeBase: repo.baseBranch } };
-            }
-            // The merger clones the PR head (full, to diff vs base) and returns ONLY the
-            // complexity/risk/impact assessment JSON; the engine performs the real merge.
-            case MERGER_AGENT_KIND:
-                return this.buildRegisteredAgentBody(context, parts, {
-                    surface: 'container-explore',
-                    clone: { branch: 'pr', full: true },
-                    output: { kind: 'structured', shapeHint: MERGE_ASSESSMENT_SHAPE_HINT },
-                }, MERGER_SYSTEM_PROMPT, mergerUserPrompt(context, repo));
-            // The on-call agent clones the BASE branch (full, to locate + diff the merged
-            // release commit) and returns ONLY the regression assessment JSON.
-            case ON_CALL_AGENT_KIND:
-                return this.buildRegisteredAgentBody(context, parts, {
-                    surface: 'container-explore',
-                    clone: { branch: 'base', full: true },
-                    output: { kind: 'structured', shapeHint: ON_CALL_ASSESSMENT_SHAPE_HINT },
-                }, ON_CALL_SYSTEM_PROMPT, onCallUserPrompt(context, repo));
-            // The tester clones the PR head branch (read-only — it makes NO commits), stands up
-            // its dependencies (locally via the service's docker-compose, or against the
-            // provisioned ephemeral env — the task's `tester.environment` config picks which) and
-            // returns ONLY a structured JSON report. It runs as a generic structured explore with
-            // an `infra` spec the harness uses to stand the docker-compose dependencies up for the
-            // run; `toRunResult` coerces the JSON into `testReport` (the conservative greenlight /
-            // blocking-concern rule the harness applied now runs backend-side, and the engine's
-            // TesterController re-applies it). The role prompt + the run-mode/ephemeral-URL guidance
-            // come from the standard `roleSystemPrompt` + `userPromptFor` (which already carry them),
-            // so the harness adds none. The engine loops the `fixer` on a withheld greenlight.
-            case TESTER_AGENT_KIND: {
-                const built = this.buildRegisteredAgentBody(context, parts, {
-                    surface: 'container-explore',
-                    clone: { branch: 'pr' },
-                    output: { kind: 'structured', shapeHint: TEST_REPORT_SHAPE_HINT },
-                }, roleSystemPrompt);
-                return { kind: built.kind, body: { ...built.body, infra: testerInfraSpec(context) } };
-            }
-            // The UI tester is the Tester's browser-driven sibling: same read-only structured
-            // explore + infra stand-up, but it drives Playwright (supplied by the UI-tester
-            // image, routed via the `image:'ui'` dispatch option) to capture a non-redundant
-            // screenshot of each distinct view, uploads them to the artifact store, and reports
-            // them under `screenshots[]`. The role prompt carries the capture guidance.
-            case UI_TESTER_AGENT_KIND: {
-                const built = this.buildRegisteredAgentBody(context, parts, {
-                    surface: 'container-explore',
-                    clone: { branch: 'pr' },
-                    output: { kind: 'structured', shapeHint: UI_TEST_REPORT_SHAPE_HINT },
-                }, roleSystemPrompt);
-                return { kind: built.kind, body: { ...built.body, infra: testerInfraSpec(context) } };
-            }
-        }
-        return undefined;
-    }
-}
-/**
- * The Blueprinter's task prompt. The agent now reads any existing blueprint from its own
- * read-only checkout (the harness no longer pre-injects the baseline tree), so the prompt
- * tells it to read `blueprints/` and update-or-create, then return the complete tree as
- * JSON. The backend `blueprintPostOp` renders + commits the artifact from that tree.
- */
-function blueprintUserPrompt() {
-    return [
-        'Map this repository into the canonical service → modules blueprint, anchored to real ' +
-            'file/directory references.',
-        '',
-        'If a blueprint already exists in the repository (read `blueprints/blueprint.json` and ' +
-            '`blueprints/overview.md`), UPDATE it to reflect the current code: keep accurate ' +
-            'modules, add new ones, and refine summaries + references. Otherwise create it from ' +
-            'scratch. Return the COMPLETE tree (not a diff).',
-        '',
-        'Respond with ONLY the JSON object for the service tree — no prose, no code fences.',
-    ].join('\n');
-}
-/**
- * The spec-writer's task prompt — the instructions + baseline-read + taxonomy-reuse guidance
- * the bespoke harness `/spec` handler used to build (`buildUserPrompt`/`renderTaxonomyInventory`,
- * which used to inject the baseline doc + its module→feature inventory). The agent now reads
- * the baseline from its own read-only checkout under `spec/`, so the prompt tells it to read +
- * reuse the existing taxonomy rather than pre-injecting it. Carries ONLY this task's
- * requirements (the block description IS the task's reworked/incorporated requirements), so an
- * unmerged sibling task's work never bleeds in. The backend `specPostOp` shards + commits the
- * returned tree.
- */
-function specWriterUserPrompt(context) {
-    const block = context.block;
-    const header = `### ${block.title || '(untitled task)'}${block.id ? ` (block ${block.id})` : ''}`;
-    // Honour an explicit human-set BUSINESS/TECHNICAL label: a task pinned business HAS
-    // business requirements, so the "no new specs" escape hatch is withdrawn; a task pinned
-    // technical is told the empty outcome is expected. Left unset, the writer self-determines.
-    const technicalGuidance = block.technical === false
-        ? 'This task is explicitly flagged BUSINESS: it HAS business requirements, so you MUST ' +
-            'return the full updated specification. Do NOT respond with {"noBusinessSpecs": true}.'
-        : block.technical === true
-            ? 'This task is explicitly flagged TECHNICAL (a refactor / dependency bump / internal ' +
-                'or non-functional change with NO new externally-observable behaviour): "no business ' +
-                'requirements" is the expected outcome — respond with ONLY {"noBusinessSpecs": true} ' +
-                'and change nothing, unless you find genuine externally-observable behaviour to spec.'
-            : 'If this task is purely TECHNICAL (a refactor / dependency bump / internal or ' +
-                'non-functional change that introduces NO new externally-observable behaviour), it ' +
-                'has no business requirements: respond with ONLY {"noBusinessSpecs": true} and ' +
-                'change nothing.';
-    return [
-        'Apply this ONE task as an INCREMENT onto the service specification.',
-        '',
-        'First READ the specification already committed to the repository under `spec/` (the ' +
-            'baseline as merged before this task): open `spec/overview.md` for the module → feature ' +
-            'index, then the relevant `spec/modules/<module>/<feature>.json` shards. Keep every part ' +
-            'of the baseline this task does not touch exactly as-is, preserving its `sourceBlockIds`; ' +
-            'adjust an existing requirement only where this task changes its behaviour. Map each new ' +
-            'requirement/rule into the closest-fitting EXISTING module and feature, reusing its EXACT ' +
-            'name — create a new module or feature ONLY when nothing fits (never a near-duplicate). ' +
-            'If no spec exists yet, start one as a module (domain) → feature (group) taxonomy.',
-        '',
-        'Requirements for the ONE task to apply (its clarified description). Translate ONLY what ' +
-            'these state into BUSINESS requirements (externally-observable behaviour, product rules, ' +
-            'acceptance criteria) with COMPLETE acceptance-scenario coverage — do NOT invent ' +
-            'requirements or fill gaps they leave:',
-        '',
-        `${header}\n\n${block.description?.trim() || '(no description)'}`,
-        '',
-        technicalGuidance +
-            ' Otherwise return the COMPLETE updated document (baseline plus this task’s ' +
-            'increment), not a diff. Respond with ONLY the JSON object — no prose, no code fences.',
-    ].join('\n');
-}
-/**
- * The merger's task prompt — the instructions + diff guidance the bespoke harness `/merge`
- * handler used to build. Kept backend-side now that the merger dispatches the generic
- * explore agent. Names the PR/branches so the agent diffs against the right base.
- */
-function mergerUserPrompt(context, repo) {
-    const prNumber = context.block.pullRequest?.number;
-    const branch = context.block.pullRequest?.branch ?? repo.baseBranch;
-    const pr = prNumber !== undefined ? ` (PR #${prNumber})` : '';
-    return [
-        'Assess the pull request on the head branch against the base branch and return the ' +
-            'complexity / risk / impact scores + rationale as JSON.',
-        '',
-        `The pull request${pr} is on branch \`${branch}\`; the base branch is ` +
-            `\`${repo.baseBranch}\`. Inspect the change (e.g. \`git fetch origin ${repo.baseBranch}\` ` +
-            `then \`git diff origin/${repo.baseBranch}...HEAD\`) and score complexity, risk and impact.`,
-        '',
-        'Respond with ONLY a JSON object {"complexity":0.0,"risk":0.0,"impact":0.0,"rationale":"…"}.',
-    ].join('\n');
-}
-/**
- * The on-call agent's task prompt — the regression evidence (the generic block/prior-output
- * prompt) plus the locate-the-merged-commit guidance the bespoke harness `/on-call` handler
- * used to build. The released PR already merged into the base branch (its work branch is
- * gone), so the agent is on the base branch and is told how to find the merged commit.
- */
-function onCallUserPrompt(context, repo) {
-    const prNumber = context.block.pullRequest?.number;
-    const headBranch = context.block.pullRequest?.branch;
-    const pr = prNumber !== undefined ? `#${prNumber}` : '';
-    const locate = prNumber
-        ? `It merged as a commit referencing ${pr} — find it with \`git log --oneline -n 50\` ` +
-            `(squash/merge commits include \`(${pr})\`; a merge commit mentions \`#${prNumber}\`), then ` +
-            `inspect it with \`git show <sha>\`.`
-        : headBranch
-            ? `Its work branch was \`${headBranch}\` (now deleted) — find the merged commit in ` +
-                `\`git log --oneline -n 50\` and inspect it with \`git show <sha>\`.`
-            : `Find the most recent merge/feature commit with \`git log --oneline -n 50\` and inspect ` +
-                `it with \`git show <sha>\`.`;
-    return [
-        userPromptFor(context, { materialized: true }),
-        '',
-        `You are on the base branch \`${repo.baseBranch}\`, which already contains the released ` +
-            `pull request ${pr}. ${locate} Correlate that change with the regression evidence above. ` +
-            `Beware correlation vs causation.`,
-        '',
-        'Respond with ONLY a JSON object {"culpritConfidence":0.0,"recommendation":"revert"|"hold"|"monitor","rationale":"…","evidence":["…"]}.',
-    ].join('\n');
-}
-/**
- * The tester's infra stand-up spec for the generic agent job, from the block's
- * `tester.environment` config + the resolved service: a `local` run carries the
- * docker-compose path (or the explicit no-infra flag) for the harness to stand the
- * dependencies up + tear them down around the run; an `ephemeral` run carries the
- * provisioned environment URL. Byte-identical to the old bespoke `/test` body's `test`
- * object — only the field name changed (`test` → `infra`).
- */
-function testerInfraSpec(context) {
-    const env = context.block.agentConfig?.['tester.environment'] === 'local' ? 'local' : 'ephemeral';
-    const service = context.service;
-    return {
-        environment: env,
-        ...(env === 'local'
-            ? {
-                noInfraDependencies: service?.noInfraDependencies === true,
-                ...(service?.testComposePath ? { composePath: service.testComposePath } : {}),
-            }
-            : {}),
-        ...(env === 'ephemeral' && context.environment?.url
-            ? { environmentUrl: context.environment.url }
-            : {}),
-    };
-}
-function prBody(context) {
-    const lines = [
-        `Automated implementation for block **${context.block.title}** (${context.block.type}).`,
-        '',
-        context.block.description || '(no description)',
-        '',
-        `Pipeline: ${context.pipelineName}`,
-    ];
-    return lines.join('\n');
 }
 //# sourceMappingURL=ContainerAgentExecutor.js.map