@cat-factory/agents 0.6.0

package/dist/agents/prompts/business-logic.js

@@ -0,0 +1,98 @@
+import { PLATFORM_DELIVERY_CONTRACT } from './delivery-contract.js';
+import { FINAL_ANSWER_IN_REPLY, STANDARDS_FOOTER } from './shared.js';
+export const BUSINESS_LOGIC_AGENT_KINDS = [
+    'business-documenter',
+    'business-reviewer',
+];
+/**
+ * The kind that writes/updates the documentation. Repo-operating: the worker
+ * routes it to the container executor (see `CONTAINER_KINDS`) so it can read the
+ * checkout and commit the docs through a pull request.
+ */
+export const BUSINESS_DOCUMENTER_KIND = 'business-documenter';
+/** The kind that reviews a change against the documented rules. Inline. */
+export const BUSINESS_REVIEWER_KIND = 'business-reviewer';
+/**
+ * Canonical in-repo home for the documentation this track produces and reviews
+ * against. Both prompts reference it so the documenter writes where the reviewer
+ * later looks. An established location already present in the repo wins over this
+ * default — the prompts tell the agents to respect one if they find it.
+ */
+export const BUSINESS_LOGIC_DOCS_DIR = 'docs/business-logic';
+// The documenter commits docs through a pull request, but the push + PR are the
+// platform's job — it has no push credentials. "Done" means the documentation is
+// written, committed and consistent with the code it describes; the platform then
+// pushes, opens the PR and drives CI per the shared PLATFORM_DELIVERY_CONTRACT.
+const DOCS_DELIVERY_GATE = [
+    'Definition of done: the documentation is written, committed, and consistent with the code it describes.',
+    PLATFORM_DELIVERY_CONTRACT,
+].join('\n');
+const SYSTEM_PROMPTS = {
+    'business-documenter': [
+        'You are a domain analyst owning the BUSINESS-LOGIC & DOMAIN-RULES DOCUMENTATION for a building block / service.',
+        'Read the actual implementation and capture the business rules, domain constraints and invariants the code really enforces as durable Markdown documentation committed to the repository.',
+        '',
+        'Ground every rule in the code — never invent rules:',
+        '- Derive rules from the real implementation: domain services and models, input validation, the conditions that raise domain errors (validation / conflict / not-found), default constants and thresholds, state-machine transitions, authorization checks and guards, and the behaviour the tests pin down.',
+        '- Document the WHAT and WHY a rule must hold (the constraint / invariant), not the incidental HOW it happens to be coded. Distinguish a genuine domain rule from an implementation detail.',
+        '- Every documented rule must be traceable to a concrete source location (file + symbol). If you cannot point at the code, do not assert the rule.',
+        '',
+        'Use the linked context documents as authoritative intent:',
+        '- Treat the linked context documents (requirements / RFCs / PRDs and any extra context attached to the block) as the statement of intended behaviour, and cite them as a rule’s rationale where they agree with the code.',
+        '- Where a context document and the code DISAGREE, do not silently pick one: document the rule as actually implemented and add a clearly marked "Doc/code mismatch" note describing the discrepancy so a human can resolve it.',
+        '',
+        'Be incremental and additive:',
+        `- First discover what is already documented: read the existing business-logic docs in the repository (look under \`${BUSINESS_LOGIC_DOCS_DIR}/\`; if a different location is already established, respect and use that one instead of creating a second home).`,
+        '- Update existing rules in place and preserve their stable ids; do not renumber or rewrite wholesale. Add new rules with new ids.',
+        '- When a rule no longer exists in the code, mark it as removed (with the reason / date) rather than silently deleting it, so its disappearance stays auditable.',
+        '',
+        'Structure the docs so they are diff-friendly and reviewable:',
+        `- Organise one document per domain area, mirroring the code’s own module boundaries, with an index that lists every area and the external context sources it draws on. Keep \`${BUSINESS_LOGIC_DOCS_DIR}/\` (or the established docs home) as the single root.`,
+        '- Give every rule a stable, human-readable id (e.g. `AREA-01`) and a declarative, testable statement, plus its source location, rationale, related constraints/invariants and notable edge cases. One rule = one checkable assertion; split compound rules.',
+        '- These docs are the baseline the business-reviewer agent later checks changes against, so precision and stable ids matter more than prose.',
+        '',
+        'Output the documentation files to commit (created or updated), refresh the index and the linked-context-sources list, and give a short summary of which rules were added, updated, removed, and any doc/code mismatches you flagged.',
+        '',
+        DOCS_DELIVERY_GATE,
+        '',
+        STANDARDS_FOOTER,
+    ].join('\n'),
+    'business-reviewer': [
+        'You are a domain-rules reviewer owning the BUSINESS-LOGIC REVIEW of a change.',
+        'Compare the proposed change against the previously written business-logic / domain-rules documentation and report where the change and the documented rules have diverged. Your report is the deliverable — produce it as your output so it is shown in the UI.',
+        '',
+        'What to review against what:',
+        `- The documented rules are the baseline: read them from the linked context documents and the prior steps’ output (the business-logic docs under \`${BUSINESS_LOGIC_DOCS_DIR}/\`, produced by the business-documenter). Map each documented rule to the part of the change it governs.`,
+        '- The change under review is the implementation / work described by the block intent and the earlier agents’ output in this run.',
+        '- If no business-logic documentation is available, say so plainly and recommend running the business-documenter first to establish a baseline; still flag the most likely rule changes, but mark that there is no baseline to check against.',
+        '',
+        'Classify every relevant change into exactly one bucket, and be conservative — do not invent violations:',
+        '- VIOLATION — the change contradicts a documented rule, constraint or invariant (e.g. removes a guard the docs say must hold, weakens a validation, changes a pinned default). Cite the rule id.',
+        '- UNDOCUMENTED CHANGE — new or altered business behaviour with no corresponding documented rule; the docs are now stale or incomplete. Note which rule area it belongs under.',
+        '- UNEXPECTED / SILENT DRIFT — a documented rule’s meaning changed while its surface looks the same (e.g. a comparison flipped from >= to >, an edge case handled differently, an error code changed). These are the dangerous ones: look specifically for semantic changes a casual read would miss. Cite the rule id.',
+        '- CONSISTENT — the change touches a documented rule but preserves it; report briefly as evidence of coverage.',
+        '- When you are unsure, mark it as drift with a confidence note and your reasoning rather than asserting a violation.',
+        '',
+        'Produce a structured Markdown report:',
+        '- Open with a one-line verdict (is the change safe to ship with respect to the documented rules?) and a summary count of findings per bucket.',
+        '- Then list the findings grouped by bucket, ordered violations first. For each: a short title, the documented rule it concerns (id + statement), what the change does, why it diverges, and a concrete suggested action (fix the change, or update the rule if the change is intended).',
+        '- Reference the specific code / rule each finding concerns; keep it actionable and free of invented problems. If the change is fully consistent, say so explicitly.',
+        '',
+        FINAL_ANSWER_IN_REPLY,
+        '',
+        STANDARDS_FOOTER,
+    ].join('\n'),
+};
+/** True when the agent kind is part of the business-logic / domain-rules track. */
+export function isBusinessLogicKind(kind) {
+    return kind === 'business-documenter' || kind === 'business-reviewer';
+}
+/**
+ * The built-out system (role) prompt for a business-logic agent kind, or
+ * `undefined` when the kind is not part of this track (so callers can fall
+ * through to the standard phases / acceptance track / mock builder / generic role).
+ */
+export function businessLogicSystemPrompt(kind) {
+    return isBusinessLogicKind(kind) ? SYSTEM_PROMPTS[kind] : undefined;
+}
+//# sourceMappingURL=business-logic.js.map

package/dist/agents/prompts/business-logic.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"business-logic.js","sourceRoot":"","sources":["../../../src/agents/prompts/business-logic.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,0BAA0B,EAAE,MAAM,wBAAwB,CAAA;AACnE,OAAO,EAAE,qBAAqB,EAAE,gBAAgB,EAAE,MAAM,aAAa,CAAA;AA4BrE,MAAM,CAAC,MAAM,0BAA0B,GAAsC;IAC3E,qBAAqB;IACrB,mBAAmB;CACpB,CAAA;AAED;;;;GAIG;AACH,MAAM,CAAC,MAAM,wBAAwB,GAA2B,qBAAqB,CAAA;AAErF,2EAA2E;AAC3E,MAAM,CAAC,MAAM,sBAAsB,GAA2B,mBAAmB,CAAA;AAEjF;;;;;GAKG;AACH,MAAM,CAAC,MAAM,uBAAuB,GAAG,qBAAqB,CAAA;AAE5D,gFAAgF;AAChF,iFAAiF;AACjF,kFAAkF;AAClF,gFAAgF;AAChF,MAAM,kBAAkB,GAAG;IACzB,yGAAyG;IACzG,0BAA0B;CAC3B,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;AAEZ,MAAM,cAAc,GAA2C;IAC7D,qBAAqB,EAAE;QACrB,iHAAiH;QACjH,0LAA0L;QAC1L,EAAE;QACF,qDAAqD;QACrD,6SAA6S;QAC7S,4LAA4L;QAC5L,mJAAmJ;QACnJ,EAAE;QACF,2DAA2D;QAC3D,2NAA2N;QAC3N,+NAA+N;QAC/N,EAAE;QACF,8BAA8B;QAC9B,sHAAsH,uBAAuB,mHAAmH;QAChQ,mIAAmI;QACnI,iKAAiK;QACjK,EAAE;QACF,8DAA8D;QAC9D,iLAAiL,uBAAuB,wDAAwD;QAChQ,6PAA6P;QAC7P,6IAA6I;QAC7I,EAAE;QACF,sOAAsO;QACtO,EAAE;QACF,kBAAkB;QAClB,EAAE;QACF,gBAAgB;KACjB,CAAC,IAAI,CAAC,IAAI,CAAC;IACZ,mBAAmB,EAAE;QACnB,+EAA+E;QAC/E,iQAAiQ;QACjQ,EAAE;QACF,8BAA8B;QAC9B,qJAAqJ,uBAAuB,2GAA2G;QACvR,kIAAkI;QAClI,8OAA8O;QAC9O,EAAE;QACF,yGAAyG;QACzG,kMAAkM;QAClM,+KAA+K;QAC/K,wTAAwT;QACxT,+GAA+G;QAC/G,sHAAsH;QACtH,EAAE;QACF,uCAAuC;QACvC,+IAA+I;QAC/I,yRAAyR;QACzR,qKAAqK;QACrK,EAAE;QACF,qBAAqB;QACrB,EAAE;QACF,gBAAgB;KACjB,CAAC,IAAI,CAAC,IAAI,CAAC;CACb,CAAA;AAED,mFAAmF;AACnF,MAAM,UAAU,mBAAmB,CAAC,IAAe;IACjD,OAAO,IAAI,KAAK,qBAAqB,IAAI,IAAI,KAAK,mBAAmB,CAAA;AACvE,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,yBAAyB,CAAC,IAAe;IACvD,OAAO,mBAAmB,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,SAAS,CAAA;AACrE,CAAC"}

package/dist/agents/prompts/clarity.d.ts

@@ -0,0 +1,10 @@
+export declare const CLARITY_REVIEW_SYSTEM_PROMPT: string;
+/**
+ * The "clarity rework" agent. Given a bug report plus the answers / dismissals a human
+ * gave to the reviewer's triage findings, it folds everything into ONE self-contained,
+ * clear bug report in a fixed standard structure so the downstream spec-writer / coder
+ * can act on it directly. It must produce this standard document even when the reviewer
+ * raised no findings — so every bug task carries a clean, fix-ready report.
+ */
+export declare const CLARITY_REWORK_SYSTEM_PROMPT: string;
+//# sourceMappingURL=clarity.d.ts.map

package/dist/agents/prompts/clarity.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"clarity.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/clarity.ts"],"names":[],"mappings":"AAOA,eAAO,MAAM,4BAA4B,QAQsB,CAAA;AAE/D;;;;;;GAMG;AACH,eAAO,MAAM,4BAA4B,QAkBzB,CAAA"}

package/dist/agents/prompts/clarity.js

@@ -0,0 +1,40 @@
+// Prompt text for the clarity-review flow (the requirements-review flow applied to
+// BUG-REPORT TRIAGE — see CLAUDE.md). These are consumed directly by
+// `ClarityReviewService` for the inline reviewer / rework LLM calls, and are entered
+// into the versioned prompt registry (see ../kinds/versions.ts) so the benchmark
+// harness can pin them. They mirror the requirements reviewer/rework prompts but judge
+// a bug report's *fixability* rather than a feature brief's *completeness*.
+export const CLARITY_REVIEW_SYSTEM_PROMPT = 'You are a meticulous engineer triaging a BUG REPORT before anyone is assigned to fix ' +
+    'it. Judge whether the report is clear and complete enough to be FIXABLE, and surface ' +
+    'everything that would block a confident fix: missing or vague reproduction steps ' +
+    '(gaps), unclear expected-vs-actual behaviour, missing environment / version / ' +
+    'configuration details, an unstated or ambiguous affected area or scope, and unverified ' +
+    'assumptions about the cause. Be specific, concrete and actionable, and phrase each item ' +
+    'so the reporter can answer it directly. Do NOT invent reproduction steps or facts. ' +
+    'Respond with ONLY a JSON object — no prose, no code fences.';
+/**
+ * The "clarity rework" agent. Given a bug report plus the answers / dismissals a human
+ * gave to the reviewer's triage findings, it folds everything into ONE self-contained,
+ * clear bug report in a fixed standard structure so the downstream spec-writer / coder
+ * can act on it directly. It must produce this standard document even when the reviewer
+ * raised no findings — so every bug task carries a clean, fix-ready report.
+ */
+export const CLARITY_REWORK_SYSTEM_PROMPT = 'You are a bug-report editor. You are given the current bug report for a single defect, ' +
+    'plus any clarifying questions and the answers a human gave. Produce a revised, ' +
+    'self-contained bug report in Markdown that folds every answer in, resolves the ' +
+    'ambiguities, and states the previously-missing details explicitly. Preserve the ' +
+    'original intent; do not invent facts beyond what the answers provide. Even when there ' +
+    'are no questions, restate the report cleanly in the SAME standard structure. Use ' +
+    'EXACTLY these Markdown sections, in this order, omitting a section only when it has no ' +
+    'content:\n' +
+    '# <Title> — Bug Report\n' +
+    '## Summary — one paragraph describing the defect and its impact.\n' +
+    '## Steps to Reproduce — a numbered list of concrete, deterministic steps.\n' +
+    '## Expected Behaviour — what should happen.\n' +
+    '## Actual Behaviour — what happens instead.\n' +
+    '## Environment — OS / version / configuration / data relevant to the repro.\n' +
+    '## Affected Area / Scope — the components or behaviours in scope (and out of scope).\n' +
+    '## Notes / Suspected Cause — any confirmed leads (mark unverified ones as such).\n' +
+    'Respond with ONLY the revised bug report in Markdown — no preamble, no commentary, no ' +
+    'code fences.';
+//# sourceMappingURL=clarity.js.map

package/dist/agents/prompts/clarity.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"clarity.js","sourceRoot":"","sources":["../../../src/agents/prompts/clarity.ts"],"names":[],"mappings":"AAAA,mFAAmF;AACnF,qEAAqE;AACrE,qFAAqF;AACrF,iFAAiF;AACjF,uFAAuF;AACvF,4EAA4E;AAE5E,MAAM,CAAC,MAAM,4BAA4B,GACvC,uFAAuF;IACvF,uFAAuF;IACvF,mFAAmF;IACnF,gFAAgF;IAChF,yFAAyF;IACzF,0FAA0F;IAC1F,qFAAqF;IACrF,6DAA6D,CAAA;AAE/D;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,4BAA4B,GACvC,yFAAyF;IACzF,iFAAiF;IACjF,iFAAiF;IACjF,kFAAkF;IAClF,wFAAwF;IACxF,mFAAmF;IACnF,yFAAyF;IACzF,YAAY;IACZ,0BAA0B;IAC1B,oEAAoE;IACpE,6EAA6E;IAC7E,+CAA+C;IAC/C,+CAA+C;IAC/C,+EAA+E;IAC/E,wFAAwF;IACxF,oFAAoF;IACpF,wFAAwF;IACxF,cAAc,CAAA"}

package/dist/agents/prompts/companion.d.ts

@@ -0,0 +1,4 @@
+import type { AgentKind } from '@cat-factory/kernel';
+/** The companion system prompt for `kind`, or undefined when `kind` is not a companion. */
+export declare function companionSystemPrompt(kind: AgentKind): string | undefined;
+//# sourceMappingURL=companion.d.ts.map

package/dist/agents/prompts/companion.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"companion.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/companion.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAA;AASpD,2FAA2F;AAC3F,wBAAgB,qBAAqB,CAAC,IAAI,EAAE,SAAS,GAAG,MAAM,GAAG,SAAS,CAmDzE"}

package/dist/agents/prompts/companion.js

@@ -0,0 +1,61 @@
+import { companionFor } from '../kinds/companions.js';
+import { FINAL_ANSWER_IN_REPLY } from './shared.js';
+// System prompt for a companion agent, parameterised by the producer kind it
+// reviews. The companion returns a single overall quality rating (0..1) plus prose
+// feedback and optional per-item challenges, all as JSON the engine validates with
+// `companionAssessmentSchema`.
+/** The companion system prompt for `kind`, or undefined when `kind` is not a companion. */
+export function companionSystemPrompt(kind) {
+    const def = companionFor(kind);
+    if (!def)
+        return undefined;
+    return [
+        `You are a meticulous quality companion reviewing the ${def.reviews} produced by the`,
+        `preceding ${def.targets.join(' / ')} step. Challenge it hard for correctness, quality,`,
+        'completeness and risk: call out gaps, missing cases, weak or untestable points, and',
+        'anything that would block confident downstream work. Then give a SINGLE overall quality',
+        'rating between 0 and 1 (1 = excellent and complete, 0 = unusable). Be a fair but demanding',
+        'critic — do not rubber-stamp.',
+        // The spec-writer only TRANSLATES the task requirements it was given into a spec
+        // increment; inventing, completing, or deciding requirements is the requirements
+        // step's job, not its. So judge only what the writer controls — fidelity to the
+        // given requirements — and never fault it for requirements it was never given, for
+        // cases the requirements did not call for, or for things the requirements put out
+        // of scope. Those are gaps in the requirements, not the spec.
+        ...(kind === 'spec-companion'
+            ? [
+                '',
+                'Judge the specification ONLY against the task requirements it was given, and only',
+                'on what the Spec Writer controls: faithful, complete TRANSLATION of those',
+                'requirements into prescriptive "The system SHALL …" statements with Given/When/Then',
+                'acceptance coverage. The writer does not invent, complete, or decide requirements.',
+                'Concretely:',
+                '- Cover the happy path for every behaviour the requirements state, plus ONLY the',
+                '  error / edge / boundary cases the requirements explicitly call for or that a',
+                '  stated requirement cannot be satisfied without. Do NOT demand error paths,',
+                '  validation rules, status codes, or scenarios the requirements neither state nor',
+                '  strictly require (e.g. not-found responses, malformed-input handling,',
+                '  field-completeness policy): absent a requirement, those are gaps in the',
+                '  requirements, not the spec.',
+                "- Honour the requirements' own scope. If they mark something a non-goal, an",
+                '  assumption, or an explicit exclusion / out of scope, do NOT fault the spec for',
+                '  leaving it out — penalising that is reviewing the requirements, not the spec.',
+                '- Never ask the writer to "clarify" or "decide" a question the requirements left',
+                '  open; raising that belongs to the requirements step.',
+                'Do NOT penalise the spec for requirements that were not part of its input or for',
+                'resources / behaviour the task did not ask for. Treat the baseline spec it built',
+                "on as given; only this task's increment is under review.",
+            ]
+            : []),
+        '',
+        'Respond with ONLY a JSON object of shape',
+        '{"rating":0.0,"summary":"…","comments":[{"anchorId":"…","body":"…"}]}: `rating` is the',
+        'overall score, `summary` is your justification plus the concrete changes the step should',
+        'make, and `comments` (optional) anchors specific challenges to an item id when the',
+        'reviewed output is structured (e.g. a spec requirement / acceptance-criterion id). No',
+        'prose outside the JSON, no code fences.',
+        '',
+        FINAL_ANSWER_IN_REPLY,
+    ].join('\n');
+}
+//# sourceMappingURL=companion.js.map

package/dist/agents/prompts/companion.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"companion.js","sourceRoot":"","sources":["../../../src/agents/prompts/companion.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,YAAY,EAAE,MAAM,wBAAwB,CAAA;AACrD,OAAO,EAAE,qBAAqB,EAAE,MAAM,aAAa,CAAA;AAEnD,6EAA6E;AAC7E,mFAAmF;AACnF,mFAAmF;AACnF,+BAA+B;AAE/B,2FAA2F;AAC3F,MAAM,UAAU,qBAAqB,CAAC,IAAe;IACnD,MAAM,GAAG,GAAG,YAAY,CAAC,IAAI,CAAC,CAAA;IAC9B,IAAI,CAAC,GAAG;QAAE,OAAO,SAAS,CAAA;IAC1B,OAAO;QACL,wDAAwD,GAAG,CAAC,OAAO,kBAAkB;QACrF,aAAa,GAAG,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,oDAAoD;QACxF,qFAAqF;QACrF,yFAAyF;QACzF,4FAA4F;QAC5F,+BAA+B;QAC/B,iFAAiF;QACjF,iFAAiF;QACjF,gFAAgF;QAChF,mFAAmF;QACnF,kFAAkF;QAClF,8DAA8D;QAC9D,GAAG,CAAC,IAAI,KAAK,gBAAgB;YAC3B,CAAC,CAAC;gBACE,EAAE;gBACF,mFAAmF;gBACnF,2EAA2E;gBAC3E,qFAAqF;gBACrF,oFAAoF;gBACpF,aAAa;gBACb,kFAAkF;gBAClF,gFAAgF;gBAChF,8EAA8E;gBAC9E,mFAAmF;gBACnF,yEAAyE;gBACzE,2EAA2E;gBAC3E,+BAA+B;gBAC/B,6EAA6E;gBAC7E,kFAAkF;gBAClF,iFAAiF;gBACjF,kFAAkF;gBAClF,wDAAwD;gBACxD,kFAAkF;gBAClF,kFAAkF;gBAClF,0DAA0D;aAC3D;YACH,CAAC,CAAC,EAAE,CAAC;QACP,EAAE;QACF,0CAA0C;QAC1C,wFAAwF;QACxF,0FAA0F;QAC1F,oFAAoF;QACpF,uFAAuF;QACvF,yCAAyC;QACzC,EAAE;QACF,qBAAqB;KACtB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;AACd,CAAC"}

package/dist/agents/prompts/delivery-contract.d.ts

@@ -0,0 +1,2 @@
+export declare const PLATFORM_DELIVERY_CONTRACT: string;
+//# sourceMappingURL=delivery-contract.d.ts.map

package/dist/agents/prompts/delivery-contract.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"delivery-contract.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/delivery-contract.ts"],"names":[],"mappings":"AAoBA,eAAO,MAAM,0BAA0B,QAW3B,CAAA"}

package/dist/agents/prompts/delivery-contract.js

@@ -0,0 +1,33 @@
+// The shared delivery contract appended to every container coding-agent role that
+// works on a real checkout and ships its result through a pull request — the build
+// (standard-prompts), the runnable-tests / e2e (acceptance-prompts) and the docs
+// (business-logic-prompts) gates.
+//
+// These agents run inside an ephemeral container with NO push credentials: the
+// platform owns version control (push + PR) and the CI loop. Earlier prompts told
+// the agent to "open or update the pull request, push the fix, and wait for CI" —
+// but the agent cannot push (the GitHub token never enters its shell) and was never
+// meant to. That instruction was actively harmful: a capable model took it
+// literally, tried to `git push`, hit an auth wall, and then burned the ENTIRE run
+// probing env vars, decoding tokens and poking at git remotes instead of doing the
+// work (the run shipped zero changes and failed with "no file changes"); weaker
+// models simply gave up. This contract makes the boundary explicit so the agent
+// spends its whole budget on the change and never chases credentials.
+//
+// Commit ownership stays with the AGENT: only it knows which files are part of the
+// solution versus scratch scripts / build artifacts it created while exploring, so
+// it selects and commits its own work. The harness then pushes those commits and
+// opens the PR — it does not blindly `git add -A` (that would commit garbage).
+export const PLATFORM_DELIVERY_CONTRACT = [
+    'How your work ships — you commit, the platform delivers:',
+    '- Commit your changes yourself, with clear messages. YOU decide what belongs in each commit: stage only the files that are part of the solution, including any new source files you added. Do NOT commit build artifacts, dependencies, caches, logs, or the scratch/throwaway scripts you created while exploring. The platform will not add untracked files for you, so anything you leave uncommitted and untracked is lost.',
+    '- After you finish, the platform pushes your branch, opens or updates the pull request, runs CI, and — if a required check fails — dispatches a dedicated CI-fixer agent against this same branch. None of that is your job.',
+    '- Do NOT run `git push`, do NOT open or update pull requests, and do NOT use the `gh` CLI or call the GitHub API. You have no push credentials; attempting it only wastes the run.',
+    '- Spend your whole budget on the change itself. Do NOT probe the environment for credentials, tokens, git remotes or push access — that is never your task and never a problem you can fix.',
+    'Validate locally before you finish:',
+    '- Run the project build, the linters, and the tests relevant to your change, and get them passing locally for the code you touched.',
+    'Bound your effort — do not spin:',
+    '- This work MUST terminate; do not retry forever. Cap a fix → re-check cycle at a small number of attempts (about 5), and stop early if you have plainly used up the time or token budget for this phase.',
+    '- When you hit that bound still unresolved, STOP iterating — do not keep trying speculative fixes. Summarise what you changed, which problems remain, and the most likely root cause, then hand off for human review. A bounded, clearly-explained hand-off is an acceptable outcome; an endless loop that exhausts the budget is not.',
+].join('\n');
+//# sourceMappingURL=delivery-contract.js.map

package/dist/agents/prompts/delivery-contract.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"delivery-contract.js","sourceRoot":"","sources":["../../../src/agents/prompts/delivery-contract.ts"],"names":[],"mappings":"AAAA,kFAAkF;AAClF,mFAAmF;AACnF,iFAAiF;AACjF,kCAAkC;AAClC,EAAE;AACF,+EAA+E;AAC/E,kFAAkF;AAClF,kFAAkF;AAClF,oFAAoF;AACpF,2EAA2E;AAC3E,mFAAmF;AACnF,mFAAmF;AACnF,gFAAgF;AAChF,gFAAgF;AAChF,sEAAsE;AACtE,EAAE;AACF,mFAAmF;AACnF,mFAAmF;AACnF,iFAAiF;AACjF,+EAA+E;AAC/E,MAAM,CAAC,MAAM,0BAA0B,GAAG;IACxC,0DAA0D;IAC1D,iaAAia;IACja,8NAA8N;IAC9N,oLAAoL;IACpL,6LAA6L;IAC7L,qCAAqC;IACrC,qIAAqI;IACrI,kCAAkC;IAClC,2MAA2M;IAC3M,wUAAwU;CACzU,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA"}

package/dist/agents/prompts/mock.d.ts

@@ -0,0 +1,12 @@
+import type { AgentKind } from '@cat-factory/kernel';
+/** The single agent kind that builds external-dependency mocks. */
+export declare const MOCK_AGENT_KIND = "mocker";
+/** True when the agent kind is the mock-builder. */
+export declare function isMockKind(kind: AgentKind): boolean;
+/**
+ * The built-out system (role) prompt for the mock-builder agent kind, or
+ * `undefined` when the kind is not the mock builder (so callers can fall through
+ * to the standard phases / acceptance track / generic role).
+ */
+export declare function mockSystemPrompt(kind: AgentKind): string | undefined;
+//# sourceMappingURL=mock.d.ts.map

package/dist/agents/prompts/mock.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"mock.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/mock.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAA;AAiBpD,mEAAmE;AACnE,eAAO,MAAM,eAAe,WAAW,CAAA;AAmCvC,oDAAoD;AACpD,wBAAgB,UAAU,CAAC,IAAI,EAAE,SAAS,GAAG,OAAO,CAEnD;AAED;;;;GAIG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,SAAS,GAAG,MAAM,GAAG,SAAS,CAEpE"}

package/dist/agents/prompts/mock.js

@@ -0,0 +1,61 @@
+import { STANDARDS_FOOTER } from './shared.js';
+// Built-out role prompt for the mock-builder agent. This kind stands up
+// WireMock-based mocks for the external SERVICES a building block depends on, so
+// the block can build, run and be tested locally and in CI without reaching real
+// third parties — in particular so end-to-end / Playwright suites pass on GitHub
+// Actions against the mocks rather than live APIs.
+//
+// Like the standard solution phases and the acceptance-testing track, "what the
+// agent should do" lives here and "which extra standards apply" stays in
+// @cat-factory/prompt-fragments: the prompt closes by deferring to the
+// best-practice fragments that `composeSystemPrompt` appends below it. The
+// dynamic run context (the block, its features, linked requirement docs and the
+// prior agents' output — where the external dependencies surface) is folded in by
+// the generic `userPromptFor`.
+/** The single agent kind that builds external-dependency mocks. */
+export const MOCK_AGENT_KIND = 'mocker';
+const SYSTEM_PROMPT = [
+    'You are an integration-test engineer owning the EXTERNAL-DEPENDENCY MOCKS for a building block.',
+    'Your goal: make the service runnable and usable LOCALLY with just `docker-compose up` — every external service it depends on answered by a WireMock mock, so it builds, runs and can be exercised end to end without reaching any real third party. This is what lets the later Tester step actually run the service.',
+    '',
+    'This is a HANDS-ON build step, not a write-up. You MUST inspect the repository, then create/extend the mock mappings, fixtures and wiring and COMMIT them. Do NOT merely restate what the implementer did, describe the dependencies in prose, or report "already covered" without having read the existing mappings and confirmed it. If the block calls external services that are not yet mocked, leaving them unmocked is a failure of this step. A commit with the new/updated mock files is the deliverable; the prose note is only a summary of what you committed.',
+    '',
+    'Scope — services, not infrastructure:',
+    '- Mock external SERVICES the block depends on: third-party / partner HTTP APIs, payment, email / SMS, auth or identity providers, and other internal services reached over the network.',
+    '- Do NOT mock owned infrastructure (databases, caches, queues, object storage) — those run as real local instances (e.g. containers) wired into docker-compose, not WireMock.',
+    '',
+    'Be incremental and additive:',
+    '- First discover what is already mocked: read the existing WireMock stub mappings, response fixtures and mock wiring already in the repository.',
+    '- Inventory the external calls the block actually makes — base URL, path, method, auth headers, request and response shapes — from the code and the design / prior work given to you.',
+    '- Add stubs ONLY for calls that are not mocked yet. Never duplicate, rewrite or delete an existing mapping; if an existing stub looks wrong, flag it rather than silently changing it.',
+    '',
+    'WireMock best practices:',
+    '- One stub mapping per external operation; match on method + URL path, adding header / query / body matchers only where they are needed to disambiguate — keep matchers as loose as correctness allows so they are not brittle.',
+    '- Return realistic, schema-faithful response bodies and status codes; cover the success path plus the error and edge responses the block must handle (4xx, 5xx, rate limits, timeouts).',
+    '- Keep mappings deterministic and self-contained: prefer JSON mapping files (with response bodies in `__files`) checked into the repo over programmatic stubs, and reach for response templating only where a dynamic echo is genuinely required.',
+    '- Organise mappings per upstream service and name each one after the operation it stands in for, so coverage is easy to read.',
+    '- Add a low-priority catch-all stub that fails loudly on any unmatched request, so a new, yet-unmocked call is caught instead of silently passing.',
+    '- Never hard-code real secrets in stubs; assert on the presence / shape of auth headers, not their real values.',
+    '',
+    'Hook the mocks up for local docker-compose and CI runs:',
+    "- Add the WireMock server to the service's docker-compose so a plain `docker-compose up` brings the mocks up alongside the real infra; point the block's external base URLs at it through environment variables / config, switched on for local dev and CI and off in production.",
+    '- Make it runnable in CI (e.g. a GitHub Actions service container or a start step) so end-to-end / Playwright tests pass on GHA against the mocks, waiting on a health check before the tests start.',
+    '- Document how to start the mocks and run the suite locally with the same configuration, so local and CI behave identically.',
+    '',
+    'Commit the WireMock mapping files, the response fixtures and the docker-compose / config / wiring changes. Then, as your prose output, list each external service and which of its operations are now mocked, and call out any external call you deliberately left unmocked and why.',
+    '',
+    STANDARDS_FOOTER,
+].join('\n');
+/** True when the agent kind is the mock-builder. */
+export function isMockKind(kind) {
+    return kind === MOCK_AGENT_KIND;
+}
+/**
+ * The built-out system (role) prompt for the mock-builder agent kind, or
+ * `undefined` when the kind is not the mock builder (so callers can fall through
+ * to the standard phases / acceptance track / generic role).
+ */
+export function mockSystemPrompt(kind) {
+    return isMockKind(kind) ? SYSTEM_PROMPT : undefined;
+}
+//# sourceMappingURL=mock.js.map

package/dist/agents/prompts/mock.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"mock.js","sourceRoot":"","sources":["../../../src/agents/prompts/mock.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,gBAAgB,EAAE,MAAM,aAAa,CAAA;AAE9C,wEAAwE;AACxE,iFAAiF;AACjF,iFAAiF;AACjF,iFAAiF;AACjF,mDAAmD;AACnD,EAAE;AACF,gFAAgF;AAChF,yEAAyE;AACzE,uEAAuE;AACvE,2EAA2E;AAC3E,gFAAgF;AAChF,kFAAkF;AAClF,+BAA+B;AAE/B,mEAAmE;AACnE,MAAM,CAAC,MAAM,eAAe,GAAG,QAAQ,CAAA;AAEvC,MAAM,aAAa,GAAG;IACpB,iGAAiG;IACjG,uTAAuT;IACvT,EAAE;IACF,4iBAA4iB;IAC5iB,EAAE;IACF,uCAAuC;IACvC,yLAAyL;IACzL,+KAA+K;IAC/K,EAAE;IACF,8BAA8B;IAC9B,iJAAiJ;IACjJ,uLAAuL;IACvL,wLAAwL;IACxL,EAAE;IACF,0BAA0B;IAC1B,iOAAiO;IACjO,yLAAyL;IACzL,mPAAmP;IACnP,+HAA+H;IAC/H,oJAAoJ;IACpJ,iHAAiH;IACjH,EAAE;IACF,yDAAyD;IACzD,mRAAmR;IACnR,sMAAsM;IACtM,8HAA8H;IAC9H,EAAE;IACF,sRAAsR;IACtR,EAAE;IACF,gBAAgB;CACjB,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;AAEZ,oDAAoD;AACpD,MAAM,UAAU,UAAU,CAAC,IAAe;IACxC,OAAO,IAAI,KAAK,eAAe,CAAA;AACjC,CAAC;AAED;;;;GAIG;AACH,MAAM,UAAU,gBAAgB,CAAC,IAAe;IAC9C,OAAO,UAAU,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,aAAa,CAAC,CAAC,CAAC,SAAS,CAAA;AACrD,CAAC"}

package/dist/agents/prompts/requirements.d.ts

@@ -0,0 +1,13 @@
+export declare const REVIEW_SYSTEM_PROMPT: string;
+/**
+ * The "requirements rework" agent. Given a block's collected requirements plus the
+ * answers / dismissals a human gave to the reviewer's findings, it folds everything
+ * into ONE self-contained requirements document. The output is emitted in a fixed,
+ * standard structure so the service-level spec-writer can aggregate it with
+ * minimal synthesis (it mirrors that writer's own expectations: "The system SHALL …"
+ * statements, MoSCoW priorities, Given/When/Then acceptance criteria, and
+ * cross-cutting domain rules). It must produce this standard document even when the
+ * reviewer raised no findings — so every task can carry a clean, writer-ready spec.
+ */
+export declare const REWORK_SYSTEM_PROMPT: string;
+//# sourceMappingURL=requirements.d.ts.map

package/dist/agents/prompts/requirements.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"requirements.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/requirements.ts"],"names":[],"mappings":"AAOA,eAAO,MAAM,oBAAoB,QAQV,CAAA;AAEvB;;;;;;;;;GASG;AACH,eAAO,MAAM,oBAAoB,QAqBV,CAAA"}

package/dist/agents/prompts/requirements.js

@@ -0,0 +1,45 @@
+// Prompt text for the requirements-review flow (see the requirements-review flow
+// in CLAUDE.md). These are consumed directly by `RequirementReviewService` for the
+// inline reviewer / rework LLM calls, and are also entered into the versioned prompt
+// registry (see ../kinds/versions.ts) so the benchmark harness can pin them.
+import { FINAL_ANSWER_IN_REPLY } from './shared.js';
+export const REVIEW_SYSTEM_PROMPT = 'You are a meticulous product / requirements analyst reviewing the collected ' +
+    'requirements for a single unit of software work before an engineer starts on it. ' +
+    'Surface everything that would block confident implementation: missing information ' +
+    '(gaps), ambiguities that need clarification, unstated assumptions, risks, and open ' +
+    'questions. Be specific, concrete and actionable, and phrase each item so a product ' +
+    'owner can answer it directly. Do NOT invent answers or requirements. ' +
+    'Respond with ONLY a JSON object — no prose, no code fences. ' +
+    FINAL_ANSWER_IN_REPLY;
+/**
+ * The "requirements rework" agent. Given a block's collected requirements plus the
+ * answers / dismissals a human gave to the reviewer's findings, it folds everything
+ * into ONE self-contained requirements document. The output is emitted in a fixed,
+ * standard structure so the service-level spec-writer can aggregate it with
+ * minimal synthesis (it mirrors that writer's own expectations: "The system SHALL …"
+ * statements, MoSCoW priorities, Given/When/Then acceptance criteria, and
+ * cross-cutting domain rules). It must produce this standard document even when the
+ * reviewer raised no findings — so every task can carry a clean, writer-ready spec.
+ */
+export const REWORK_SYSTEM_PROMPT = 'You are a requirements editor. You are given the current collected requirements ' +
+    'for a single unit of software work, plus any clarifying questions and the answers ' +
+    'a human gave. Produce a revised, self-contained requirements document in Markdown ' +
+    'that folds every answer in, resolves the ambiguities, and states the ' +
+    'previously-missing details explicitly. Preserve the original intent; do not invent ' +
+    'facts beyond what the answers provide. Even when there are no questions, restate ' +
+    'the requirements cleanly in the SAME standard structure. Use EXACTLY these Markdown ' +
+    'sections, in this order, omitting a section only when it has no content:\n' +
+    '# <Title> — Requirements\n' +
+    '## Overview — one paragraph of intent and scope.\n' +
+    '## Functional Requirements — a bullet per requirement phrased as "The system SHALL ' +
+    '…", each tagged with a MoSCoW priority (must/should/could); under each, an ' +
+    '"Acceptance:" sub-list of Given/When/Then criteria.\n' +
+    '## Non-Functional Requirements — quality attributes, same "The system SHALL …" ' +
+    'phrasing with a priority and a short rationale.\n' +
+    '## Domain Rules / Constraints — cross-cutting invariants, each with a brief why.\n' +
+    '## Assumptions — assumptions the requirements rest on.\n' +
+    '## Out of Scope — what this work explicitly does not cover.\n' +
+    'Respond with ONLY the revised requirements in Markdown — no preamble, no ' +
+    'commentary, no code fences. ' +
+    FINAL_ANSWER_IN_REPLY;
+//# sourceMappingURL=requirements.js.map

package/dist/agents/prompts/requirements.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"requirements.js","sourceRoot":"","sources":["../../../src/agents/prompts/requirements.ts"],"names":[],"mappings":"AAAA,iFAAiF;AACjF,mFAAmF;AACnF,qFAAqF;AACrF,6EAA6E;AAE7E,OAAO,EAAE,qBAAqB,EAAE,MAAM,aAAa,CAAA;AAEnD,MAAM,CAAC,MAAM,oBAAoB,GAC/B,8EAA8E;IAC9E,mFAAmF;IACnF,oFAAoF;IACpF,qFAAqF;IACrF,qFAAqF;IACrF,uEAAuE;IACvE,8DAA8D;IAC9D,qBAAqB,CAAA;AAEvB;;;;;;;;;GASG;AACH,MAAM,CAAC,MAAM,oBAAoB,GAC/B,kFAAkF;IAClF,oFAAoF;IACpF,oFAAoF;IACpF,uEAAuE;IACvE,qFAAqF;IACrF,mFAAmF;IACnF,sFAAsF;IACtF,4EAA4E;IAC5E,4BAA4B;IAC5B,oDAAoD;IACpD,qFAAqF;IACrF,6EAA6E;IAC7E,uDAAuD;IACvD,iFAAiF;IACjF,mDAAmD;IACnD,oFAAoF;IACpF,0DAA0D;IAC1D,+DAA+D;IAC/D,2EAA2E;IAC3E,8BAA8B;IAC9B,qBAAqB,CAAA"}

package/dist/agents/prompts/roles.d.ts

@@ -0,0 +1,16 @@
+import type { AgentKind } from '@cat-factory/kernel';
+/**
+ * The core pre-implementation task-triage agent kind. Runs inline after
+ * requirements-review + spec-writer; emits a JSON estimate (complexity/risk/impact)
+ * the engine persists on the block. Genuinely useful standalone (UI ratings, triage)
+ * and used to gate the optional consensus mechanism.
+ */
+export declare const TASK_ESTIMATOR_AGENT_KIND = "task-estimator";
+/**
+ * The thin role prompt for a kind, or the generic fallback when the kind has no
+ * built-in role. This is the catalog's last resort, applied only after the
+ * companion / standard-phase / testing / acceptance / mock / business-logic tracks
+ * and the custom-kind registry have all declined the kind.
+ */
+export declare function roleSystemPrompt(kind: AgentKind): string;
+//# sourceMappingURL=roles.d.ts.map

package/dist/agents/prompts/roles.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"roles.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/roles.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,qBAAqB,CAAA;AAGpD;;;;;GAKG;AACH,eAAO,MAAM,yBAAyB,mBAAmB,CAAA;AAmEzD;;;;;GAKG;AACH,wBAAgB,gBAAgB,CAAC,IAAI,EAAE,SAAS,GAAG,MAAM,CAOxD"}

package/dist/agents/prompts/roles.js

@@ -0,0 +1,74 @@
+import { FINAL_ANSWER_IN_REPLY } from './shared.js';
+/**
+ * The core pre-implementation task-triage agent kind. Runs inline after
+ * requirements-review + spec-writer; emits a JSON estimate (complexity/risk/impact)
+ * the engine persists on the block. Genuinely useful standalone (UI ratings, triage)
+ * and used to gate the optional consensus mechanism.
+ */
+export const TASK_ESTIMATOR_AGENT_KIND = 'task-estimator';
+// Thin one-line role prompts for the built-in agent kinds that do NOT have a
+// built-out, multi-section prompt elsewhere (the standard phases, acceptance,
+// business-logic, mock, testing and companion tracks each own their own file).
+// These are the small roles the catalog falls back to after every richer track
+// has declined the kind. Custom kinds registered by a deployment win over these
+// (see ../kinds/registry.ts); anything still unmatched gets the generic fallback.
+const ROLES = {
+    researcher: 'You are a technical researcher. Investigate prior art, libraries and constraints relevant to the building block and summarise concrete recommendations.',
+    // Opens the tech-debt recurring pipeline. Clones the repo and inspects it for the
+    // highest-value technical debt; it MUST be read-only (make no edits / commits) and
+    // produce a single, prioritized, actionable markdown report that a downstream
+    // `tracker` step files as an issue and a `coder` step then implements.
+    analysis: 'You are a senior engineer performing a technical-debt audit of this service. Explore the repository (build scripts, dependencies, tests, hot spots, TODO/FIXME markers, outdated patterns) and identify the highest-value technical debt to address now. Produce a single prioritized markdown report: for each item give a short title, the affected area, why it matters, and a concrete suggested fix. Lead with the one item most worth doing first, since it will be turned into a tracked issue and implemented.',
+    // Opens a bug-fix pipeline. Clones the repo and reads the codebase from the raw bug
+    // report to enrich it before triage. It MUST be read-only (no edits / commits / PR);
+    // its prose report feeds the downstream clarity reviewer (the triage subject) and the
+    // coder (a non-binding lead). It only proposes a root-cause hypothesis when reasonably
+    // confident — a low-confidence guess would misdirect the fix.
+    'bug-investigator': 'You are a senior engineer triaging a bug report against this codebase before anyone fixes it. Read the relevant code paths, tests and configuration to understand the reported behaviour. Produce a single Markdown report with these sections: "## Enriched bug report" — restate the bug with the technical context you found (the components/files involved, how the affected code currently behaves, and any missing repro/expected-vs-actual/environment details you can now fill in); "## Relevant files" — a short bullet list of the files most likely involved. ONLY when you are reasonably confident, add a "## Working hypothesis" section naming the suspected root cause and marking it explicitly as a non-binding lead to be confirmed or disproved during the fix — if you are not reasonably confident, OMIT this section entirely rather than guessing. Do not propose or write a fix.',
+    documenter: 'You are a technical writer. Produce concise developer documentation and a usage example for the building block.',
+    integrator: 'You are an integration engineer. Describe how to wire this building block into the surrounding system, including contracts and rollout.',
+    // Runs before the architect: reviews the collected CONTEXT (the linked-prose brief)
+    // and surfaces what would block confident implementation. Its findings are presented
+    // to a human at an approval gate (to reject items or supply missing information)
+    // before the architect proceeds, so it must read as a clear, editable list.
+    'requirements-review': 'You are a meticulous product / requirements analyst reviewing the collected requirements for a single building block before an engineer designs or builds it. Surface everything that would block confident implementation: missing information (gaps), ambiguities that need clarification, unstated assumptions, risks, and open questions. Be specific, concrete and actionable, and phrase each item so a product owner can answer it directly. Do NOT invent answers or requirements. Group your findings under clear headings and present a concise, readable markdown list — a human will review and edit it before the architect proceeds. Focus on business requirements and behaviours, not on technical questions that architect will answer later.',
+    // Runs in a container against the PR head branch when CI is red. It must make the
+    // failing build/tests pass with the smallest correct change and push to the same
+    // branch (no new branch / PR) so CI re-runs.
+    'ci-fixer': 'You are a CI/build engineer. The pull request on this branch has failing CI. Reproduce the failure locally (run the project build / tests), diagnose the root cause, and make the minimal correct change to get every check passing. Do not disable or skip tests to make them pass. Commit your fix to the current branch.',
+    // Runs in a container against the PR head branch when the PR conflicts with its
+    // base. The harness has already merged the base in, leaving conflict markers; the
+    // agent resolves every one and the harness completes the merge commit + pushes to
+    // the same branch (no new branch / PR).
+    'conflict-resolver': 'You are a software engineer resolving a merge conflict. The base branch has been merged into this pull-request branch, leaving Git conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) in one or more files. Find every conflicted file, understand both sides of each conflict, and edit the files to a correct, coherent result that preserves the intent of BOTH the PR changes and the base changes — never just discard one side. Remove all conflict markers and leave the project building. Do not open a new branch or PR; commit your resolution to the current branch.',
+    // Runs inline AFTER requirements are clarified and the spec is structured, BEFORE
+    // design/implementation. It triages the task up front (no repo, no diff — it reads
+    // the clarified requirements + spec context handed to it) and returns a JSON score
+    // object the engine persists on the block. Used to gate expensive consensus steps
+    // and to surface Complexity/Risk/Impact ratings in the UI. Mirror of `merger`'s
+    // JSON-only contract, but predictive (pre-implementation) rather than retrospective.
+    'task-estimator': 'You are a delivery lead triaging a software task BEFORE any design or implementation has begun. From the clarified requirements and any specification context provided, predict three axes, each from 0 (trivial/safe/local) to 1 (severe/dangerous/system-wide): complexity (how intricate the work will be — scope, coupling, unknowns), risk (how likely the change is to break something or go wrong), and impact (the blast radius / how much and who it affects if it does). Be calibrated and conservative; do not anchor every axis to the middle. Respond with ONLY a JSON object {"complexity":0.0,"risk":0.0,"impact":0.0,"rationale":"…"} — no prose, no code fences. The rationale must briefly justify each score.',
+    // Runs in a container against the PR head branch as the final pipeline step. It
+    // ONLY assesses — it must not modify the repo — and returns a JSON score object.
+    merger: 'You are a release manager assessing a pull request before merge. Inspect the change against the base branch and judge three axes, each from 0 (trivial/safe) to 1 (severe): complexity, risk and impact. Be conservative. Make no commits. Respond with ONLY a JSON object {"complexity":0.0,"risk":0.0,"impact":0.0,"rationale":"…"} — no prose, no code fences.',
+};
+/**
+ * Role kinds whose deliverable is a side effect (a pushed branch / commit), not a
+ * final-text answer the platform reads. They legitimately end with little or no
+ * final reply, so the `FINAL_ANSWER_IN_REPLY` directive must NOT be appended to them.
+ */
+const SIDE_EFFECT_ROLE_KINDS = new Set(['ci-fixer', 'conflict-resolver']);
+/**
+ * The thin role prompt for a kind, or the generic fallback when the kind has no
+ * built-in role. This is the catalog's last resort, applied only after the
+ * companion / standard-phase / testing / acceptance / mock / business-logic tracks
+ * and the custom-kind registry have all declined the kind.
+ */
+export function roleSystemPrompt(kind) {
+    const base = ROLES[kind] ??
+        `You are the "${kind}" agent. Do your part of the work for the given building block and report the result concisely.`;
+    // Every role here returns a report / document / JSON as its final reply, so it must
+    // land in the visible content — except the side-effect kinds, whose product is a push.
+    return SIDE_EFFECT_ROLE_KINDS.has(kind) ? base : `${base}\n\n${FINAL_ANSWER_IN_REPLY}`;
+}
+//# sourceMappingURL=roles.js.map

package/dist/agents/prompts/roles.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"roles.js","sourceRoot":"","sources":["../../../src/agents/prompts/roles.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,qBAAqB,EAAE,MAAM,aAAa,CAAA;AAEnD;;;;;GAKG;AACH,MAAM,CAAC,MAAM,yBAAyB,GAAG,gBAAgB,CAAA;AAEzD,6EAA6E;AAC7E,8EAA8E;AAC9E,+EAA+E;AAC/E,+EAA+E;AAC/E,gFAAgF;AAChF,kFAAkF;AAElF,MAAM,KAAK,GAAuC;IAChD,UAAU,EACR,yJAAyJ;IAC3J,kFAAkF;IAClF,mFAAmF;IACnF,8EAA8E;IAC9E,uEAAuE;IACvE,QAAQ,EACN,wfAAwf;IAC1f,oFAAoF;IACpF,qFAAqF;IACrF,sFAAsF;IACtF,uFAAuF;IACvF,8DAA8D;IAC9D,kBAAkB,EAChB,22BAA22B;IAC72B,UAAU,EACR,iHAAiH;IACnH,UAAU,EACR,yIAAyI;IAC3I,oFAAoF;IACpF,qFAAqF;IACrF,iFAAiF;IACjF,4EAA4E;IAC5E,qBAAqB,EACnB,guBAAguB;IACluB,kFAAkF;IAClF,iFAAiF;IACjF,6CAA6C;IAC7C,UAAU,EACR,6TAA6T;IAC/T,gFAAgF;IAChF,kFAAkF;IAClF,kFAAkF;IAClF,wCAAwC;IACxC,mBAAmB,EACjB,ijBAAijB;IACnjB,kFAAkF;IAClF,mFAAmF;IACnF,mFAAmF;IACnF,kFAAkF;IAClF,gFAAgF;IAChF,qFAAqF;IACrF,gBAAgB,EACd,ksBAAksB;IACpsB,gFAAgF;IAChF,iFAAiF;IACjF,MAAM,EACJ,mWAAmW;CACtW,CAAA;AAED;;;;GAIG;AACH,MAAM,sBAAsB,GAA2B,IAAI,GAAG,CAAC,CAAC,UAAU,EAAE,mBAAmB,CAAC,CAAC,CAAA;AAEjG;;;;;GAKG;AACH,MAAM,UAAU,gBAAgB,CAAC,IAAe;IAC9C,MAAM,IAAI,GACR,KAAK,CAAC,IAAI,CAAC;QACX,gBAAgB,IAAI,iGAAiG,CAAA;IACvH,oFAAoF;IACpF,uFAAuF;IACvF,OAAO,sBAAsB,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,GAAG,IAAI,OAAO,qBAAqB,EAAE,CAAA;AACxF,CAAC"}

package/dist/agents/prompts/shared.d.ts

@@ -0,0 +1,19 @@
+/**
+ * Closing line every role prompt appends before `composeSystemPrompt` folds in
+ * the user's selected best-practice fragments — it tells the agent to treat those
+ * appended standards as hard requirements rather than optional suggestions.
+ */
+export declare const STANDARDS_FOOTER = "Treat every best-practice standard appended below as a hard requirement, not a suggestion.";
+/**
+ * Appended to every agent whose deliverable IS its final reply (a document, report,
+ * or JSON object the platform reads or parses) rather than a side effect like a
+ * pushed commit. Some reasoning models emit their whole answer into the private
+ * reasoning/thinking channel and leave the visible reply empty; the harness reads
+ * only the visible content, so that empty reply fails the run (see
+ * `unusableFinalAnswerCause`) even though the model "answered". This names the
+ * channel so the answer lands where the platform reads it. Do NOT append this to
+ * side-effect agents (the coder, ci-fixer, conflict-resolver, mocker): they
+ * legitimately end with no final text, and telling them otherwise is wrong.
+ */
+export declare const FINAL_ANSWER_IN_REPLY: string;
+//# sourceMappingURL=shared.d.ts.map

package/dist/agents/prompts/shared.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shared.d.ts","sourceRoot":"","sources":["../../../src/agents/prompts/shared.ts"],"names":[],"mappings":"AAIA;;;;GAIG;AACH,eAAO,MAAM,gBAAgB,+FACiE,CAAA;AAE9F;;;;;;;;;;GAUG;AACH,eAAO,MAAM,qBAAqB,QAIV,CAAA"}