@telora/daemon 0.16.42 → 0.17.1

package/dist/team-prompt-base.js

@@ -1,1095 +1,26 @@
 /**
  * Core prompt building infrastructure for focus team prompts.
  *
- * Contains shared section builders used across multiple prompt variants,
- * plus the main buildFocusTeamPrompt function which composes them.
- *
- * Extracted from focus-prompt-builder.ts for maintainability.
- */
-import { isStatusAgentActionable } from './stage-classifier.js';
-import { buildIssueCountLine, buildContextGroupLine, buildStandaloneIssueLine } from './prompt-listing.js';
-function orchestrationVocabulary(engineId) {
-    if (engineId === 'codex') {
-        return {
-            spawnStep: '3. Spawn worker subagents (delegate via the Codex agent tool) for parallelizable work',
-            workerMechanism: 'You manage worker execution by spawning worker subagents. Workers are subagents\n' +
-                'that execute individual issues.',
-            caveat: [
-                '',
-                '**Codex subagent spawns -- spawn cleanly:**',
-                '- Do NOT pass `agent_type`, `model`, or `reasoning_effort` when delegating a',
-                '  full-history fork: forked agents inherit the parent\'s type/model/effort and',
-                '  the router rejects the call otherwise. Omit those fields (or spawn without a',
-                '  full-history fork).',
-            ],
-        };
-    }
-    // Default: Claude Code (in-process teammates via the Task tool).
-    return {
-        spawnStep: '3. Spawn workers (using the Task tool) for parallelizable work',
-        workerMechanism: 'You manage worker execution using the Task tool. Workers are subagents\n' +
-            'that execute individual issues.',
-        caveat: [],
-    };
-}
-// ---------------------------------------------------------------------------
-// Section builders -- each produces a string[] of prompt lines for one section
-// ---------------------------------------------------------------------------
-/**
- * Build the role context section from the agent role's system prompt template.
- */
-export function buildRoleSection(role) {
-    const lines = [];
-    if (role.system_prompt_template) {
-        lines.push(role.system_prompt_template);
-        lines.push('');
-    }
-    return lines;
-}
-/**
- * Build the domain boundaries section from allowed file patterns.
- */
-export function buildDomainBoundariesSection(role) {
-    const lines = [];
-    if (role.allowed_file_patterns.length > 0) {
-        lines.push('## Domain Boundaries');
-        lines.push('You are authorized to work on files matching these patterns:');
-        for (const pattern of role.allowed_file_patterns) {
-            lines.push(`- ${pattern}`);
-        }
-        lines.push('');
-    }
-    return lines;
-}
-/**
- * Build the team lead role description section.
- */
-export function buildTeamLeadRoleSection(engineId) {
-    const vocab = orchestrationVocabulary(engineId);
-    return [
-        '## Your Role: Focus Team Lead',
-        '',
-        'You are the team lead for this focus. You coordinate all deliveries',
-        'and their issues, spawning workers for parallel execution where possible.',
-        '',
-        '**Core responsibilities:**',
-        '1. Read all deliveries and issues for the focus',
-        '2. Build a task execution plan respecting delivery priority and file overlap',
-        vocab.spawnStep,
-        '4. Track issue completion and advance delivery stages',
-        '5. Poll for new deliveries added during execution',
-        '6. Handle errors, escalate blockers, and report progress',
-        '',
-    ];
-}
-/**
- * Build the read-only audit mode notice section.
- * Returns empty array if not in read-only mode.
- */
-export function buildReadOnlyAuditSection(readOnly) {
-    if (!readOnly)
-        return [];
-    return [
-        '## READ-ONLY AUDIT MODE',
-        '',
-        'This is a read-only audit session. The filesystem allows reading but commits',
-        'are blocked by a pre-commit hook. Your job is DISCOVERY ONLY:',
-        '',
-        '- Identify and document problems by creating issues via MCP tools',
-        '- Create exactly ONE remediation delivery per audit delivery via',
-        '  telora_product_delivery_create (execution_status: "planning")',
-        '- Use Context Groups to organize findings within remediation deliveries',
-        '- Do NOT modify, fix, or commit any code changes',
-        '- Do NOT attempt to bypass the pre-commit hook',
-        '',
-        'If you try to commit, the hook will reject it with a reminder of these rules.',
-        '',
-    ];
-}
-/**
- * Build the focus context section (focus ID, name, product ID).
- */
-export function buildFocusContextSection(context) {
-    return [
-        '## Focus',
-        `**Focus ID:** ${context.focusId}`,
-        `**Focus:** ${context.focusName}`,
-        `**Product ID:** ${context.productId}`,
-        '',
-    ];
-}
-/**
- * Build the product context documents section.
- * Deduplicates documents by title. Returns empty array if no docs.
- */
-export function buildProductContextSection(docs) {
-    if (!docs || docs.length === 0)
-        return [];
-    const seen = new Set();
-    const uniqueDocs = [];
-    for (const doc of docs) {
-        if (!seen.has(doc.title)) {
-            seen.add(doc.title);
-            uniqueDocs.push(doc);
-        }
-    }
-    const lines = [];
-    lines.push('## Product Context');
-    lines.push('');
-    for (const doc of uniqueDocs) {
-        lines.push(`### ${doc.title}`);
-        lines.push(doc.content);
-        lines.push('');
-    }
-    return lines;
-}
-/**
- * Build the deployment profile section (inception prompt + guidelines).
- * Returns empty array if no snapshot provided.
- */
-export function buildDeploymentProfileSection(snapshot) {
-    if (!snapshot)
-        return [];
-    const lines = [];
-    const { inceptionPrompt, guidelines } = snapshot;
-    if (inceptionPrompt) {
-        lines.push('## Deployment Profile: Operational Context');
-        lines.push('');
-        lines.push(inceptionPrompt);
-        lines.push('');
-    }
-    if (guidelines) {
-        lines.push('## Deployment Constraints');
-        lines.push('');
-        lines.push(guidelines);
-        lines.push('');
-    }
-    return lines;
-}
-/**
- * Build the loop context section (persona + documents + Q&A).
- * Returns pre-formatted markdown from the loop.context resolver, or empty array if none.
- */
-export function buildLoopContextSection(loopContext) {
-    if (!loopContext?.trim())
-        return [];
-    return [loopContext, ''];
-}
-/**
- * Build the execution config section (max workers, poll interval).
- */
-export function buildExecutionConfigSection(config) {
-    return [
-        '## Execution Config',
-        `- Max parallel workers: ${config.maxWorkers}`,
-        `- Idle poll interval: ${config.idlePollIntervalMs / 1000}s`,
-        '',
-    ];
-}
-/**
- * Build the planning section -- emitted only when the focus has no
- * deliveries and the team's first act is to scope them.
- *
- * The team uses telora_product_delivery_create and telora_product_issue_create
- * (the same MCP tools used for mid-flight rescoping) to write the plan to the
- * database. After writing, the team continues into normal execution -- no
- * separate planning daemon step.
- *
- * Returns an empty array when deliveries exist (already-scoped focuses
- * behave exactly as today).
- */
-export function buildPlanningSection(context) {
-    if (context.deliveries.length > 0)
-        return [];
-    const lines = [];
-    lines.push('## Planning Is Your First Act');
-    lines.push('');
-    lines.push('This focus has NO deliveries yet. Before you write any code,');
-    lines.push('your job is to scope the work: decompose the focus intent into');
-    lines.push('deliveries, Context Groups, and issues using the MCP tools below.');
-    lines.push('');
-    lines.push('Once you have written deliveries to the database, the daemon picks');
-    lines.push('them up on its next poll cycle and you continue into normal execution.');
-    lines.push('Do NOT emit a JSON plan -- write directly to Telora via MCP.');
-    lines.push('');
-    lines.push('### Scale Calibration');
-    lines.push('');
-    lines.push('Keep your decomposition at the right granularity:');
-    lines.push('');
-    lines.push('- **Delivery** = a meaningful product increment that is shippable on its');
-    lines.push('  own. Each delivery should contain 3-5 Context Groups.');
-    lines.push('- **Context Group** = one coherent capability or concern. Typically');
-    lines.push('  carries 8-12 implementable issues. A CG earns its existence by');
-    lines.push('  carrying shared context (relevant files, architectural notes) that');
-    lines.push('  would otherwise be repeated across its issues.');
-    lines.push('- **Issue** = one implementable task that fits in a focused session and');
-    lines.push('  touches a bounded set of files (add a migration, build a component,');
-    lines.push('  write tests for a module). If a description has multiple "and" clauses');
-    lines.push('  covering different concerns, split it.');
-    lines.push('');
-    lines.push('Sizing pressure check: if a CG would produce fewer than 6 issues, merge');
-    lines.push('it with a related CG. If it would exceed 15 issues, split it. If a');
-    lines.push('natural delivery grouping has only 1-2 CGs, merge with an adjacent');
-    lines.push('delivery unless independence justifies the small delivery.');
-    lines.push('');
-    lines.push('### Dependency Rules');
-    lines.push('');
-    lines.push('When you set CG `depends_on` (via the `dependsOn` field on');
-    lines.push('telora_product_issue_create), follow these conventions:');
-    lines.push('');
-    lines.push('- **Schema / data-model CGs** have no dependencies (they come first).');
-    lines.push('- **API / backend CGs** depend on the schema CGs they consume.');
-    lines.push('- **Frontend CGs** depend on the API CGs they call.');
-    lines.push('- **Test CGs** depend on the implementation CGs they cover.');
-    lines.push('- **Infrastructure CGs** (CI, config, tooling) are independent unless');
-    lines.push('  they require a schema or API contract first.');
-    lines.push('');
-    lines.push('List only direct dependencies. If C depends on B which depends on A,');
-    lines.push('C should list only B (not A).');
-    lines.push('');
-    lines.push('### Ordering Heuristics (priorityRank)');
-    lines.push('');
-    lines.push('Lower `priorityRank` = higher priority = built first. Use these rules');
-    lines.push('when assigning ranks via telora_product_delivery_create or');
-    lines.push('telora_product_delivery_reorder:');
-    lines.push('');
-    lines.push('1. **Schema before readers/writers.** Migrations and data models go in');
-    lines.push('   earlier deliveries than CGs that query or mutate that data.');
-    lines.push('2. **Shared utilities before consumers.** Helper libraries and shared');
-    lines.push('   types precede CGs that import them.');
-    lines.push('3. **Backend / API before frontend.** Edge functions and server logic');
-    lines.push('   come before UI components that call them.');
-    lines.push('4. **Infrastructure before application.** CI, config, and tooling');
-    lines.push('   precede CGs that rely on them.');
-    lines.push('5. **Independent work parallelized.** Deliveries with no dependency');
-    lines.push('   relationship can share the same priorityRank so the daemon executes');
-    lines.push('   them in parallel. Only impose ordering when there is a genuine');
-    lines.push('   dependency reason.');
-    lines.push('');
-    lines.push('### How to Write the Plan via MCP');
-    lines.push('');
-    lines.push(`1. Read the focus intent (Focus ID: ${context.focusId}).`);
-    lines.push('2. Identify every coherent capability or concern. Group them into');
-    lines.push('   deliveries by cohesion (shared dependencies, overlapping files,');
-    lines.push('   same architectural layer).');
-    lines.push('3. For each delivery, call `telora_product_delivery_create` with:');
-    lines.push(`   - productId: "${context.productId}"`);
-    lines.push(`   - focusId: "${context.focusId}"`);
-    lines.push('   - name, description, acceptanceCriteria, techContext, priorityRank');
-    lines.push('   - executionStatus is optional. When omitted, the default tracks the');
-    lines.push('     parent focus stage (past planning -> "queued"; planning/draft -> "planning").');
-    lines.push('     Pass it explicitly only when you need to override that default.');
-    lines.push('4. For each Context Group inside a delivery, call');
-    lines.push('   `telora_product_issue_create` with:');
-    lines.push('   - issueType: "Context Group"');
-    lines.push('   - deliveryId: <new delivery id>');
-    lines.push('   - title, context (markdown), relevantFiles');
-    lines.push('   - dependsOn: array of other CG issue IDs (when applicable)');
-    lines.push('5. For each issue inside a CG, call `telora_product_issue_create` with:');
-    lines.push('   - issueType: "Task" (or "Bug" when fixing existing behavior)');
-    lines.push('   - deliveryId: <delivery id>');
-    lines.push('   - parentIssueId: <CG issue id>');
-    lines.push('   - title, description, priority');
-    lines.push('6. Once your plan is written, you can begin implementation immediately');
-    lines.push('   on the highest-priority delivery using the same Status Update Rules');
-    lines.push('   below. The daemon does NOT need to re-spawn you -- planning is part');
-    lines.push('   of the same execution.');
-    lines.push('');
-    lines.push('Do not ask for permission. The focus intent above is the ask;');
-    lines.push('your plan is the answer.');
-    lines.push('');
-    return lines;
-}
-/**
- * Build the delivery listing sections: other deliveries (brief) + team deliveries (detailed).
- *
- * Partitions deliveries into team work (queued/coding) and other (human-owned).
- * Renders issue counts, context groups, and standalone issues for team deliveries.
- */
-export function buildDeliveryListingSection(deliveries, issues) {
-    const lines = [];
-    const sortedDeliveries = [...deliveries].sort((a, b) => a.priorityRank - b.priorityRank);
-    // In-progress (coding) deliveries first -- resume interrupted work before pulling new
-    const codingDeliveries = sortedDeliveries.filter(d => d.executionStatus === 'coding');
-    const queuedDeliveries = sortedDeliveries.filter(d => d.executionStatus === 'queued');
-    const teamDeliveries = [...codingDeliveries, ...queuedDeliveries];
-    const otherDeliveries = sortedDeliveries.filter(d => !isStatusAgentActionable(d.executionStatus ?? ''));
-    // Other deliveries summary (brief -- saves context window)
-    if (otherDeliveries.length > 0) {
-        lines.push('## Other Deliveries (NOT your work)');
-        lines.push('');
-        lines.push('These deliveries are in human-owned states. Do NOT work on them.');
-        lines.push('');
-        for (const delivery of otherDeliveries) {
-            lines.push(`- **${delivery.name}** [${delivery.executionStatus}]`);
-        }
-        lines.push('');
-    }
-    // Team deliveries with full detail
-    lines.push('## Your Deliveries');
-    lines.push('');
-    if (teamDeliveries.length === 0) {
-        lines.push('No queued or in-progress deliveries. Poll for new queued deliveries.');
-        lines.push('');
-    }
-    else {
-        if (codingDeliveries.length > 0) {
-            lines.push(`**${codingDeliveries.length} in-progress delivery(ies) \u2014 resume these first.**`);
-            lines.push('These were interrupted (daemon restart). Complete them before pulling from the queue.');
-            lines.push('');
-        }
-        if (queuedDeliveries.length > 0) {
-            lines.push(`${queuedDeliveries.length} queued delivery(ies) waiting.`);
-        }
-        lines.push('Within each group, deliveries are in priority order (first = highest priority).');
-        lines.push('');
-    }
-    for (const delivery of teamDeliveries) {
-        const status = delivery.executionStatus ?? 'draft';
-        lines.push(`### ${delivery.name} [${status}]`);
-        lines.push(`**Delivery ID:** ${delivery.id}`);
-        if (delivery.stageDescription) {
-            lines.push(`**Stage directive:** ${delivery.stageDescription}`);
-        }
-        // Compact issue summary -- counts by status + one-liner per issue
-        const deliveryIssues = issues.filter(i => i.deliveryId === delivery.id);
-        const actionableIssues = deliveryIssues.filter(i => i.issueType !== 'Context Group');
-        const contextGroups = deliveryIssues.filter(i => i.issueType === 'Context Group');
-        const standalone = deliveryIssues.filter(i => i.issueType !== 'Context Group' && !i.parentIssueId);
-        // Issue count summary
-        if (actionableIssues.length > 0) {
-            lines.push(buildIssueCountLine(actionableIssues));
-        }
-        // Context groups with children as one-liners (include dependency info)
-        for (const group of contextGroups) {
-            lines.push(buildContextGroupLine(group, deliveryIssues, contextGroups));
-        }
-        // Standalone issues as one-liners
-        for (const issue of standalone) {
-            lines.push(buildStandaloneIssueLine(issue));
-        }
-        lines.push('');
-    }
-    return lines;
-}
-/**
- * Build the mandatory status update rules section.
- */
-export function buildStatusUpdateRulesSection() {
-    return [
-        '## Status Update Rules (MANDATORY)',
-        '',
-        'These rules apply to ALL work -- whether you do it directly or via spawned workers.',
-        '',
-        '**Focus status:**',
-        '- NEVER move a focus to "done" or "complete" status. Only the product owner decides when a focus is finished.',
-        '- You MAY update focus status to operational states like "building" or "verify".',
-        '',
-        '**Delivery status (HANDS OFF):**',
-        '- NEVER call `telora_product_delivery_update` to change `executionStatus`.',
-        '- The daemon manages ALL delivery stage transitions automatically:',
-        '  - queued -> coding: database trigger when first issue moves to "In Progress"',
-        '  - coding -> verify: daemon advances when all issues are Done / Verified / In Review',
-        '  - verify -> done: daemon advances after verification passes',
-        '- The API will REJECT invalid transitions with a 400 error.',
-        '- Your only job is to keep issue statuses accurate. Delivery status follows.',
-        '',
-        '**Issue status transitions:**',
-        '- Every issue MUST follow: To Do -> In Progress -> Done',
-        '- NEVER skip "In Progress". An issue MUST be set to "In Progress" BEFORE any',
-        '  work begins on it.',
-        '- NEVER move an issue directly from "To Do" to "Done".',
-        '- Use `telora_product_issue_update` with `issueId` and `status`:',
-        '  - Start work: `{ "issueId": "<id>", "status": "In Progress" }`',
-        '  - Finish work: `{ "issueId": "<id>", "status": "Done" }`',
-        '  - Blocked: `{ "issueId": "<id>", "status": "Blocked" }`',
-        '  - Hand off for review: `{ "issueId": "<id>", "status": "In Review" }` (optional verify gate)',
-        '',
-        '**Optional verify gate (In Review):**',
-        '- When the delivery pipeline includes a review agent, you can signal issue-level',
-        '  completion by moving issues to "In Review" instead of directly to "Done".',
-        '- "In Review" means: dev-complete, awaiting review-agent confirmation.',
-        '- The review agent\'s working set is all "In Review" issues on the delivery.',
-        '- The review agent moves issues from "In Review" to "Done" when confirmed.',
-        '- "In Review" is treated as terminal for delivery advancement: a delivery whose',
-        '  issues are all Done / Verified / In Review advances to the next stage.',
-        '- If the delivery closes before review runs, remaining "In Review" issues are',
-        '  automatically swept to "Done" -- no manual cleanup needed.',
-        '',
-        '**When working directly on an issue** (not spawning a worker):',
-        '1. Call `telora_product_issue_update` to set status to "In Progress"',
-        '2. Do the work',
-        '3. Call `telora_product_issue_update` to set status to "Done"',
-        '',
-        '**When spawning a worker for an issue:**',
-        '1. Set issue to "In Progress" BEFORE spawning the worker',
-        '2. When the worker completes, verify its output',
-        '3. Set issue to "Done" after verification',
-        '',
-        '**Completion artifacts (MANDATORY on close):**',
-        '- When you set an issue to "Done" or "In Review", you MUST also supply',
-        '  `completionArtifacts` listing the primary files the work produced or',
-        '  modified. Shape: `{ "files": ["src/foo.ts", "src/foo.test.ts"], "tests": [...] }`.',
-        '- Drift detection compares these references against the worktree on a',
-        '  schedule. Without them, drift cannot surface for this issue and the',
-        '  Done-work signal is unreliable.',
-        '- Use repo-relative paths (no leading slash, no `./`). Include test files',
-        '  under `files` or `tests` -- both are checked.',
-        '- Workers spawned via Task: when reporting completion, return the list of',
-        '  files you modified so the team lead can pass them through in the',
-        '  `issue_update` call.',
-        '- Example close call:',
-        '  `{ "issueId": "<id>", "status": "Done", "completionArtifacts": { "files": ["src/foo.ts"] } }`',
-        '',
-    ];
-}
-/**
- * Build the execution instructions section (Phase 1: Setup).
- */
-export function buildExecutionInstructionsSection(productId) {
-    return [
-        '## Execution Instructions',
-        '',
-        '### Phase 1: Setup',
-        '1. **Verify MCP tools are available**: Call `telora_product_issue_list` with',
-        `   productId "${productId}" to confirm Telora MCP tools are loaded.`,
-        '   If the tool is not found, STOP and report this as an escalation — you cannot',
-        '   update issue statuses without MCP tools, which breaks the execution contract.',
-        '2. Read the CLAUDE.md file at the repo root for repository conventions',
-        '3. Review all deliveries and issues above to understand the full scope',
-        `4. Before starting work on each delivery, fetch its full details: use \`telora_product_delivery_list\` with productId "${productId}" and look for the delivery by ID to read its description, acceptance criteria, and technical context.`,
-        `5. Before working on a context group's issues, fetch the group's full context and relevant files using \`telora_product_issue_list\` with the delivery's ID.`,
-        `6. Use \`telora_product_issue_list\` with productId "${productId}" to get the latest issue states`,
-        '7. Plan your execution order:',
-        '   - Higher priority deliveries first (lower priorityRank number)',
-        '   - Within a delivery, issues under the same Context Group can be parallelized',
-        '   - Issues that share relevant files MUST be done sequentially',
-        '   - Context Groups with `depends on` annotations MUST execute in order:',
-        '     all issues under dependency CGs must complete before starting issues',
-        '     under the dependent CG. Independent CGs (no depends_on) can run in parallel.',
-        '   - Issues across different independent Context Groups with no file overlap can run in parallel',
-        '   - **Between deliveries**: After committing a delivery, run the full build and',
-        '     test suite (`npm run build && npm test`) before starting the next delivery.',
-        '     Fix any cross-delivery breakage immediately. This catches integration issues',
-        '     (e.g. renamed symbols, shifted phases) before they compound.',
-        '',
-    ];
-}
-/**
- * Build the worker management section (Phase 2 / TEL-4).
- */
-/**
- * Constraints on tool usage specific to a daemon-spawned team lead session.
- *
- * Background: ScheduleWakeup is documented for /loop dynamic mode (interactive
- * self-paced sessions). Daemon-spawned teams are stream-json sessions; calling
- * ScheduleWakeup produces no wake-up callback, the session idles, and the
- * daemon sees no progress -- the team stalls indefinitely. Sleep loops have
- * the same failure mode. The fix is at the prompt layer: tell the lead these
- * tools do not apply here.
- */
-export function buildSessionConstraintsSection() {
-    return [
-        '### Session Constraints',
-        '',
-        'You are a daemon-spawned team lead session, NOT an interactive `/loop` session.',
-        'Several tools available to interactive sessions DO NOT apply here and will',
-        'silently stall your team if you call them:',
-        '',
-        '- **DO NOT use `ScheduleWakeup`.** It is for `/loop` dynamic-mode sessions',
-        '  only. From a daemon-spawned session it produces no wake-up callback --',
-        '  the session idles, the daemon thinks the team is working, and your work',
-        '  halts indefinitely.',
-        '- **DO NOT use Sleep tools or sleep loops to wait for sub-agents.** The',
-        '  `Task` tool blocks synchronously and returns when the sub-agent completes.',
-        '  There is nothing to wait for explicitly -- when `Task` returns, the work',
-        '  is done. Calling Sleep between spawning and reading results is wrong and',
-        '  buys nothing.',
-        '- **DO NOT add narrated "sleeping ~X min" delays.** If you have nothing to',
-        '  do, simply finish the turn -- the daemon will reissue your prompt when',
-        '  there is more work, and your worktree state persists across that gap.',
-        '',
-        'If a `Task` call is taking longer than expected, that is a signal to',
-        'escalate via `telora_agent_escalate`, not to sleep. Sleep is never the',
-        'answer in this session.',
-        '',
-        '#### Long-running shell commands (tests, builds, installs)',
-        '',
-        'When you spawn a long-running bash command via `TaskCreate` / `Bash`,',
-        '`TaskOutput(block: true)` returns when the task produces new stdout, NOT',
-        'when files written by the task change. If you redirect output to a file',
-        '(e.g. `npm test > /tmp/log 2>&1`), the bash command itself emits zero',
-        'stdout until it exits -- so `TaskOutput` will time out indefinitely',
-        'against a healthy, working run. You cannot tell hung from working.',
-        '',
-        'For `npm test`, `npm run build`, `vitest run`, `tsc`, and similar long',
-        'commands, do ONE of the following:',
-        '',
-        '- **Stream to stdout (preferred):** `npm test` -- no redirect. TaskOutput',
-        '  will return per-file progress as it streams.',
-        '- **Stream AND log:** `npm test 2>&1 | tee /tmp/test.log` -- stdout streams,',
-        '  full transcript is saved.',
-        '',
-        'NEVER redirect long-running stdout to a file with `>` alone. If you find',
-        'yourself calling `TaskOutput` repeatedly and getting `<status>running</status>`',
-        'with no diff in retrieved output, that is the signal you redirected stdout',
-        'away from the task. Cancel via `TaskStop`, re-spawn without `>`, and try again.',
-        '',
-    ];
-}
-export function buildWorkerManagementSection(maxWorkers, engineId) {
-    const vocab = orchestrationVocabulary(engineId);
-    return [
-        '### Phase 2: Worker Management',
-        '',
-        ...vocab.workerMechanism.split('\n'),
-        ...vocab.caveat,
-        '',
-        '**Spawning workers:**',
-        `- Spawn up to ${maxWorkers} workers at a time`,
-        '- Only spawn workers for issues that are currently unblocked (all dependencies complete)',
-        '- Each worker receives a clear prompt with:',
-        '  - The issue key, title, and description',
-        '  - Context from the parent Context Group (if any)',
-        '  - Relevant files to focus on',
-        "  - The delivery's Now->Target differential (see below)",
-        '  - Instructions to update issue status via `telora_product_issue_update`',
-        '  - Instructions to commit work and report completion',
-        '',
-        '**Equip each worker with its delivery\'s Now->Target at spawn:**',
-        'You hold the focus Coordination Map and the Per-Delivery Index. The daemon',
-        'does NOT push each delivery\'s full differential into your context, and it',
-        'cannot inject a worker directly -- only you can author a worker\'s prompt. So',
-        'when you spawn a worker for a delivery, equipping it is YOUR job:',
-        '1. Find that delivery\'s line in the Per-Delivery Index. The line names its',
-        '   pull handle: `telora_reality_tree_injection_context(seq=<injection seq>)`.',
-        '2. Call that pull handle to fetch the delivery\'s full Now->Target differential',
-        '   (the targeted UDEs and the desired effects they become).',
-        '3. Embed that differential in the worker\'s task prompt, so the worker begins',
-        '   its delivery holding its start->end context -- where the work starts (the',
-        '   current UDEs) and where it ends (the FRT desired effects).',
-        'A worker must never begin a delivery without its Now->Target. The Index is the',
-        'source of the pull handle; the differential is delivered at spawn, once, to the',
-        'worker actually doing the work.',
-        '',
-        '**Worker lifecycle:**',
-        '- Before spawning: set issue status to "In Progress" via `telora_product_issue_update`',
-        '- When worker completes: verify its work, then set issue status to "Done"',
-        '- When worker fails: assess the failure, either retry or set issue to "Blocked"',
-        '  and create an escalation via `telora_agent_escalate`',
-        '- After each worker completion, check if new issues are now unblocked',
-        '',
-        '**Scaling rules:**',
-        '- Count unblocked issues (status "To Do" with no blocking dependencies)',
-        `- Active workers = min(unblocked count, ${maxWorkers})`,
-        '- As workers complete tasks and new tasks become unblocked, spawn more workers',
-        '- When no unblocked work remains, wait for in-progress workers to finish',
-        '',
-        '**Simple issues (no parallelism needed):**',
-        '- If a delivery has only 1-2 small issues, you can work on them directly',
-        '  instead of spawning workers. Use your judgment.',
-        '- IMPORTANT: Even when working directly, you MUST still update issue status.',
-        '  Set to "In Progress" before starting, then "Done" when complete.',
-        '',
-    ];
-}
-/**
- * Build the delivery stage progression section (Phase 3 / TEL-5).
- */
-export function buildDeliveryStageProgressionSection() {
-    return [
-        '### Phase 3: Delivery Stage Progression',
-        '',
-        'Delivery stages advance **automatically** based on issue activity:',
-        '',
-        '- When an issue moves to "In Progress", the parent delivery auto-advances',
-        '  from "queued" to "coding" via a database trigger. You do NOT need to',
-        '  update delivery status manually for this transition.',
-        '- Track issue completion per delivery using `telora_product_issue_list`.',
-        '',
-        '**When ALL issues in a delivery are Done:**',
-        '1. Commit all changes for the delivery',
-        '2. The daemon will automatically advance the delivery from coding to verify',
-        '3. Do NOT attempt to update the delivery executionStatus yourself',
-        '',
-        '**Delivery status reporting:**',
-        '- The daemon manages ALL delivery stage transitions. Do NOT update them.',
-        '- queued -> coding: handled automatically by database trigger (no action needed).',
-        '- coding -> verify -> done: handled automatically by the daemon.',
-        '- Focus on keeping issue statuses accurate -- the delivery status follows from them.',
-        '',
-    ];
-}
-/**
- * Build the review-defect remediation directive.
- *
- * Emitted when the team is being respawned to address issues filed by a
- * review pass (see review-defect-detector.ts). The directive orients the
- * team to "fix defects, not expand scope" -- the open issues on this
- * focus are review-filed defects, not net-new product work.
- *
- * Returns an empty array when no review-filed defects are pending. The
- * caller decides when to include the section based on detector state.
- */
-export function buildRemediationDirectiveSection(reviewFiledOpenCount) {
-    if (reviewFiledOpenCount <= 0)
-        return [];
-    return [
-        '### Review-Defect Remediation',
-        '',
-        `These deliveries contain ${reviewFiledOpenCount} open issue(s) filed by the`,
-        'review team after auditing your prior work. Address them as defects to',
-        'fix, not new scope to expand. Specifically:',
-        '',
-        '- Do NOT create additional deliveries unless directly required to fix a',
-        '  flagged defect.',
-        '- Do NOT widen scope. The review identified specific gaps -- close them.',
-        '- Issues filed during this review pass are tagged with `created_by_role_id`;',
-        '  treat them as the work plan for this remediation cycle.',
-        '- When all review-filed issues are Done, the daemon will automatically',
-        '  return the focus to verify so the next review pass can run.',
-        '',
-        'You are in a remediation cycle. The bound is small (default 3 cycles)',
-        'before escalation -- finish the defects efficiently and accurately.',
-        '',
-    ];
-}
-/**
- * The marker we look for in the assembled stage-directive context to know a
- * review report is being rendered into the prompt. The focus.last_review_report
- * resolver in assembly-resolvers.ts emits this exact heading.
- */
-export const LAST_REVIEW_REPORT_HEADING = '## Last Review Report';
-/**
- * Build the remediation framing line for a review-driven dev session.
- *
- * Detection signal: the assembled stage-directive context contains a
- * non-empty `## Last Review Report` section. When present, emit a single
- * framing line that orients the agent toward "you previously shipped this --
- * address the gaps, do not redo correct work". When absent, emit nothing.
- *
- * Reads ONLY from the assembled context string. No DB calls -- the
- * focus.last_review_report resolver is the source of truth for whether a
- * report exists; this section is a renderer of that signal.
- *
- * The caller's responsibility is to render this section BEFORE the
- * assembled context, so the framing line appears above the report content
- * in the final prompt.
- */
-export function buildRemediationFramingSection(assembledContext) {
-    if (!assembledContext.includes(LAST_REVIEW_REPORT_HEADING))
-        return [];
-    return [
-        '## Remediation Mode',
-        '',
-        "You previously delivered this focus. Review identified the following gaps. Address them; don't redo already-correct work.",
-        '',
-    ];
-}
-/**
- * Build the scoping mandate section.
- *
- * A delivery in queued status cannot transition to coding without at least
- * one Task or Bug issue. The DB trigger blocks the transition outright; this
- * section makes the requirement visible to the team lead so it does not waste
- * a turn discovering it through a 400 response.
- */
-export function buildScopingMandateSection() {
-    return [
-        '### Scoping Mandate',
-        '',
-        'When you start work on a queued delivery, your first act is to read its',
-        'acceptance criteria and create issues for it via',
-        '`telora_product_issue_create` (issueType: "Task" or "Bug"). Do not begin',
-        'code work without at least one Task or Bug issue scoped on the delivery --',
-        'the daemon will reject the queued -> coding transition if no Task/Bug',
-        'issues exist (a Context Group alone does NOT satisfy the requirement).',
-        '',
-        'If you receive an error like "Delivery <id> cannot transition to coding:',
-        'requires at least one Task or Bug issue", create the missing issues for',
-        'that delivery, then move the first issue to "In Progress" -- the database',
-        'trigger will advance the delivery from queued to coding automatically.',
-        '',
-    ];
-}
-/**
- * Build the rescoping and splitting deliveries section.
- */
-export function buildRescopingSection(focusId, productId) {
-    return [
-        '### Rescoping and Splitting Deliveries',
-        '',
-        'You are encouraged to restructure work as you learn more about the codebase. If a delivery is larger than expected, split it. If an issue is unnecessary, close it. If you discover new work, create issues for it.',
-        '',
-        '**Splitting a delivery:**',
-        `1. Create new deliveries via telora_product_delivery_create (same focusId: "${focusId}", productId: "${productId}")`,
-        '2. Create issues under the new deliveries via telora_product_issue_create',
-        "3. Mark the original delivery's remaining issues as Done (if moved) or close as won't-do",
-        '4. The daemon will automatically pick up new deliveries',
-        '',
-        '**Adding issues:**',
-        '- Create new issues on any delivery you are working on via telora_product_issue_create',
-        "- Set status to 'To Do' -- they will be picked up in your current execution",
-        '',
-        '**Descoping issues:**',
-        "- Mark issues as Done with a description note explaining why they were descoped (e.g., 'Descoped: not needed because X')",
-        '- Do not leave orphan issues -- always update status',
-        "- Known limitation: there is no 'Won't Do' status. Using Done with a note is the convention for now. The description note is important for audit trail.",
-        '',
-        '**Do not ask for permission to rescope.** Restructure autonomously based on what you learn.',
-        '',
-        '**Acceptance criteria you write must be agent-satisfiable.** Whenever you',
-        'create or rescope a delivery -- and whenever you create or update an issue --',
-        'every acceptance / completion criterion must be checkable purely by',
-        'inspecting the worktree: files exist, code matches a pattern, tests pass,',
-        'lint clean. Criteria are NEVER allowed to require:',
-        '',
-        '- Runtime observation in production ("loop has run for N cycles", "no errors in 24h")',
-        '- Deployment access or external system state ("flag flipped in production")',
-        '- Operator judgment ("approved by stakeholder", "operators have seen X")',
-        '- Third-party live signals ("API returns expected shape live")',
-        '- Human verification of any kind that is not a code/test artifact',
-        '',
-        'If a delivery legitimately requires runtime/operator observation, **split it**:',
-        'the code-completable half stays as the agent delivery; the observation half',
-        'goes to a separate delivery with no agent role assigned, OR becomes a step in',
-        'a runbook that the operator follows after deployment. Your job is to author',
-        'the runbook, not perform the observation.',
-        '',
-        'Why this matters: a team given an unsatisfiable criterion tries, fails, and',
-        "the daemon's scope-coverage guard trips after 3 cycles of no progress. The",
-        'daemon escalates and respawns; the new team hits the same wall. The loop',
-        'burns cycles and cost forever until the criterion is rewritten. Prevent this',
-        'by checking, before you save: "can a worker prove this from `git status`,',
-        '`npm run lint`, and `npm test` alone?" If no, split.',
-        '',
-    ];
-}
-/**
- * Build the new work delivery section (Phase 5 -- daemon-push model).
- */
-export function buildNewWorkDeliverySection() {
-    return [
-        '### Phase 5: New Work Delivery',
-        '',
-        'You do NOT need to poll for new work. The daemon monitors for new deliveries',
-        'and will send them to you directly via a "New Work Available" message.',
-        '',
-        'When you receive a "New Work Available" message:',
-        '1. Read the new deliveries and their issues listed in the message',
-        '2. Integrate them into your execution plan respecting priority ordering',
-        '3. Higher priority deliveries go next, but do not preempt in-progress work',
-        '4. Stop any pending work for cancelled deliveries',
-        '',
-        'Do NOT call `telora_product_delivery_list` to poll for new deliveries.',
-        'The daemon is the sole control plane and will push work to you when available.',
-        '',
-    ];
-}
-/**
- * Build the error handling and escalation section (TEL-6).
- */
-export function buildErrorHandlingSection() {
-    return [
-        '### Error Handling',
-        '',
-        '- **Worker failure**: If a worker fails on an issue, assess whether to retry',
-        '  or escalate. Set the issue to "Blocked" and use `telora_agent_escalate`',
-        '  if the issue requires human intervention.',
-        '- **Build/test failures**: Fix them before moving on. If you cannot fix them,',
-        '  escalate with details about what failed.',
-        '- **Merge conflicts**: If you encounter merge conflicts during commits,',
-        '  resolve them and continue. If resolution is unclear, escalate.',
-        '- **Discovered work**: If you find work not covered by existing issues,',
-        '  create new issues using `telora_product_issue_create` under the relevant delivery.',
-        '',
-    ];
-}
-/**
- * Build the merge conflict resolution protocol section.
- */
-export function buildMergeConflictSection() {
-    return [
-        '### Merge Conflict Resolution',
-        '',
-        'During your session, you may receive a message asking you to resolve merge',
-        'conflicts. This means the integration branch has changes that conflict with',
-        'your focus branch. When you receive this:',
-        '',
-        '1. Open each conflicted file listed in the message',
-        '2. Resolve all conflict markers (<<<<<<< / ======= / >>>>>>>)',
-        '3. Stage each resolved file with `git add <file>`',
-        '4. Commit the merge resolution: `git commit --no-edit`',
-        '5. Run: `npm run build && npm test`',
-        '6. If build+test fails, fix the issues, commit, and re-run',
-        '',
-        'Do NOT run `git merge --abort`. Your goal is to produce a clean merge',
-        'commit that passes build and tests. The daemon will detect resolution',
-        'automatically when the merge commit is created and no unmerged files remain.',
-        '',
-    ];
-}
-/**
- * Build the loop maintenance directive section.
- * Instructs the agent to proactively maintain loop data as it works,
- * making its thinking visible to humans for review and correction.
- */
-export function buildLoopMaintenanceSection() {
-    return [
-        '### Loop Data Maintenance',
-        '',
-        'As you work, proactively maintain loop data to make your thinking visible.',
-        'Loop data is how humans review and correct your understanding. Treat it',
-        'as a mirror of your current mental model, not a report to write at the end.',
-        '',
-        '**When to update loop documents** (`telora_loop_document`):',
-        '- When your understanding of the focus or delivery shifts during work',
-        '- When you discover architectural constraints or tradeoffs not yet captured',
-        '- When a human correction reveals something about intent you did not have',
-        '- Re-rank documents when priorities shift (higher rank = more important)',
-        '',
-        '**When to generate questions** (`telora_loop_question`):',
-        '- When you encounter uncertainty or ambiguity in requirements',
-        '- When you see tradeoffs that may need human judgment',
-        '- When something seems inconsistent between layers (focus vs delivery)',
-        '- Use type "generated" and rank by importance (lower sort_order = higher priority)',
-        '',
-        '**When to answer questions** (`telora_loop_answer`):',
-        '- Answer fixed questions when you have a position based on your work',
-        '- Update answers when your position changes due to new information',
-        '- Answer your own generated questions when you reach conclusions',
-        '',
-        '**Cadence**: Update loop data at natural work boundaries -- after completing',
-        'an issue, when switching between deliveries, or when a significant insight',
-        'emerges. Do not batch all updates to the end of the session.',
-        '',
-    ];
-}
-/**
- * Build the close_loop bookkeeper persona.
- *
- * The close_loop stage runs a different kind of agent: a "bookkeeper" whose
- * single mandate is to drive every anchored injection to a terminal state
- * (verified or escalated) and emit the residual tree-drift / incomplete-
- * planning signals. The persona is intentionally narrow and asymmetric --
- * the only outcomes for an anchored injection are:
- *
- *   - verified  -> evidence in the worktree supports the FRT overlay flip;
- *                   call telora_reality_tree_injection_verify(...).
- *   - escalated -> evidence is absent or ambiguous; file an
- *                   `injection_unverified` escalation. There is NO third
- *                   option. The bookkeeper does not write code, does not
- *                   propose new injections, and does not silently lower
- *                   the bar by leaving an injection in `proposed` or
- *                   `in_progress` indefinitely.
- *
- * Asymmetric bias: the system moves reality toward intent (verifying
- * injections, retiring closed UDEs) but NEVER lowers intent toward the
- * shipped reality (a delivery that did not actually flip its target UDE
- * must escalate, not have its FRT overlay edited to match what shipped).
- *
- * The literal tokens "verified", "escalated", "no third option", "evidence",
- * and "asymmetric" all appear verbatim so the persona is grep-verifiable
- * by the close_loop directive tests and reviewers.
- *
- * Dispatched per stage `close_loop` -- the `loop.persona` resolver picks
- * this variant when invoked with `variant=close_loop`, and the close_loop
- * stage assembly recipe in the dispatcher uses `loop.persona(variant=close_loop)`.
- */
-export function buildCloseLoopBookkeeperPersona() {
-    return [
-        '## Persona: Close-Loop Bookkeeper',
-        '',
-        'You are the focus bookkeeper. The focus has reached the `close_loop` stage,',
-        'which means all deliveries are settled and review has converged. Your job',
-        'is NOT to write code, NOT to widen scope, NOT to propose new injections.',
-        'Your job is to drive every anchored injection on this focus to a terminal',
-        'state.',
-        '',
-        '**Per-injection sweep (asymmetric outcomes):**',
-        '',
-        'For each injection anchored to a delivery in this focus, there are exactly',
-        'two outcomes -- no third option:',
-        '',
-        '1. **verified** -- the worktree evidence supports the FRT overlay flip.',
-        '   The target UDE is genuinely retired; downstream effects flipped as',
-        '   the injection promised. Call',
-        '   `telora_reality_tree_injection_verify(injectionId, evidence)` so the',
-        '   injection node is marked verified, its targets edges are deleted, and',
-        '   the FRT overlays on targeted UDEs promote to CRT reality.',
-        '',
-        '2. **escalated** -- evidence is absent, ambiguous, or contradicts the',
-        '   expected reality change. File an `injection_unverified` escalation',
-        '   with the specific gap: which UDE did not flip, which evidence was',
-        '   sought and not found, which delivery shipped without realizing the',
-        '   injection. The escalation surfaces to a human; the focus stays at',
-        '   `close_loop` until every anchored injection is verified or escalated.',
-        '',
-        '**Evidence rules.** Evidence MUST be worktree-checkable: files exist,',
-        'tests pass, code matches a pattern, migrations applied, lint clean.',
-        'Evidence is NEVER "the team said they did it" or "an agent narration',
-        'claimed it shipped". If evidence is not in the worktree, it does not',
-        'exist for the purposes of this sweep -- escalate.',
-        '',
-        '**Asymmetric correction.** The control loop moves reality toward intent,',
-        'never the reverse. If a delivery shipped code that does not actually',
-        'flip its target UDE, you ESCALATE (the intent was missed); you do NOT',
-        'silently rewrite the FRT overlay statement to match what shipped. The',
-        'asymmetric bias is the whole reason the bookkeeper exists.',
-        '',
-        '**Other checks the dispatcher delegates to you:**',
-        '',
-        '- `incomplete_planning` -- any deliveries that shipped without anchoring',
-        '  an injection, or any "injection-shaped" residual work the focus did',
-        '  not declare. File one `incomplete_planning` escalation per gap.',
-        '- `tree_drift` -- residual UDEs in the focus tree that no longer relate',
-        '  to the focus statement (the implicit apex). See the drift-check',
-        '  section below for the procedure.',
-        '',
-        'You do not advance the focus to `done` yourself. The daemon advances',
-        '`close_loop -> done` automatically once every anchored injection is',
-        'terminal (verified or escalated) and the residual checks are clean.',
-        '',
-    ].join('\n');
-}
-/**
- * Build the close_loop drift-check section.
- *
- * The close_loop stage agent (the focus "bookkeeper") propagates verified
- * injection effects back into the CRT and checks the residual tree for drift
- * against the focus statement. There is no stored apex node in the tree --
- * `focus.description` is the implicit apex of the reality tree; UDEs
- * articulate the gap between current reality and that statement.
- *
- * This section renders the focus statement verbatim and instructs the
- * agent to compare residual UDEs against it. It MUST contain both the
- * focus.description text and the literal token `tree_drift` so the
- * directive-executor can confirm the close_loop prompt was assembled
- * correctly (and so reviewers can grep for it).
- *
- * If `focusDescription` is null/empty, the section emits a notice that
- * no apex statement is available and the drift check cannot be performed
- * -- the agent should escalate.
- *
- * See:
- * - Design principle "Tree-Focus Apex" in memory/design-principles.md
- * - Wiki page "reality-trees-crt-frt-planning-layer", section
- *   "Tree-Focus Apex Convention"
- */
-export function buildCloseLoopDriftCheckSection(focusDescription) {
-    const lines = [];
-    lines.push('### Tree-Focus Apex Drift Check (tree_drift)');
-    lines.push('');
-    lines.push('Telora reality trees do NOT have a stored apex/root node.');
-    lines.push('The focus statement -- `focus.description` -- IS the implicit');
-    lines.push('apex. UDEs articulate the gap between current reality and that');
-    lines.push('statement. Classical Goldratt single-apex CRT structure is not');
-    lines.push('used here; the focus is the alignment target.');
-    lines.push('');
-    lines.push('**Focus statement (apex):**');
-    lines.push('');
-    if (focusDescription && focusDescription.trim()) {
-        lines.push('> ' + focusDescription.trim().split('\n').join('\n> '));
-    }
-    else {
-        lines.push('> _(no focus.description set -- escalate; drift check cannot run)_');
-    }
-    lines.push('');
-    lines.push('**tree_drift check:**');
-    lines.push('');
-    lines.push('1. Enumerate residual UDEs in the CRT (nodeType=undesired_effect,');
-    lines.push('   status=active) for this focus.');
-    lines.push('2. For each UDE, ask: does it describe a gap that the focus');
-    lines.push('   statement above commits to closing?');
-    lines.push('3. UDEs that no longer relate to the focus statement are DRIFT.');
-    lines.push('   Mark them inactive or escalate for human triage -- do not');
-    lines.push('   leave drift in an "active" focus tree.');
-    lines.push('4. UDEs that DO relate but remain unaddressed after all anchored');
-    lines.push('   injections are verified are the unresolved gap -- file them');
-    lines.push('   as escalations so the next focus / human review picks them up.');
-    lines.push('');
-    lines.push('Reminder: there is no apex node to verify or close. Closing the');
-    lines.push('loop means: every anchored injection is terminal, residual UDEs');
-    lines.push('have been classified (resolved / drift / escalated), and the');
-    lines.push('focus statement is the only thing the tree is judged against.');
-    lines.push('');
-    return lines;
-}
-/**
- * Build the completion section.
- */
-export function buildCompletionSection() {
-    return [
-        '### Completion',
-        '',
-        'When ALL issues across ALL deliveries are Done:',
-        '1. Run a final build and test to verify everything works together',
-        '2. Commit any final changes',
-        '3. Summarize the changes made across all deliveries',
-        '4. Wait for further instructions. The daemon manages your lifecycle.',
-        '',
-        'Do NOT exit on your own. The daemon will send new work or terminate you.',
-        '',
-    ];
-}
-/**
- * Build the incremental delta message sent when a lineage's session is RESUMED
- * (INJ-D). A resumed Claude session already holds its role framework, tools,
- * status rules, and accumulated context -- re-sending the full prompt wastes
- * tokens and re-anchors. The delta carries only what changed since the last
- * cycle (the diff) plus the prior findings, deliberately omitting the
- * role-framework sections.
- *
- * Anti-anchoring: for the review lineage the prior findings are framed as "to
- * VERIFY, not trust" -- the diff and acceptance criteria remain ground truth
- * each cycle, so a resumed reviewer re-examines rather than rubber-stamping.
- */
-export function buildResumeDeltaMessage(ctx) {
-    const isReview = ctx.lineage === 'review';
-    const lines = [];
-    lines.push(`## Resuming Your ${isReview ? 'Review' : 'Work'} Session (Incremental Update)`);
-    lines.push('');
-    lines.push(`You are resuming your prior \`${ctx.lineage}\` session on focus "${ctx.focusName}".`);
-    lines.push('Your role, tools, status-update rules, and the context you accumulated in');
-    lines.push('earlier cycles are intact -- this message is ONLY what changed since your last');
-    lines.push('cycle. Do not restart from scratch and do not re-read the full role framework.');
-    lines.push('The diff below and the acceptance criteria (re-read via MCP if needed) are the');
-    lines.push('ground truth for this cycle.');
-    lines.push('');
-    if (ctx.priorFindings.length > 0) {
-        if (isReview) {
-            lines.push('### Prior findings to VERIFY (do not trust)');
-            lines.push('');
-            lines.push('Last cycle you filed the issues below. Do NOT assume they were fixed.');
-            lines.push('For each, check the diff and the current code to confirm it was actually');
-            lines.push('addressed. If it was genuinely resolved, leave it; if not, keep or refile');
-            lines.push('the issue with the specific remaining gap. Your memory is not evidence --');
-            lines.push('the diff is.');
-        }
-        else {
-            lines.push('### Open items from review to address');
-            lines.push('');
-            lines.push('Review filed the issues below against your prior work. Address each as a');
-            lines.push('defect to fix and confirm the fix in the diff. Do not widen scope.');
-        }
-        lines.push('');
-        for (const f of ctx.priorFindings) {
-            lines.push(`- ${f.key}: ${f.title} (${f.status})`);
-        }
-        lines.push('');
-    }
-    lines.push('### What changed since your last cycle (diff against base)');
-    lines.push('');
-    if (ctx.gitDiff.trim()) {
-        lines.push(ctx.gitDiff.trim());
-    }
-    else {
-        lines.push('_The diff resolver returned no content. Run `git diff` against the');
-        lines.push('integration base yourself to see the current state of the worktree._');
-    }
-    lines.push('');
-    return lines.join('\n');
-}
+ * Thin aggregator: the section builders now live in ./prompt-sections/*. This
+ * file re-exports the full public surface (so every existing importer of
+ * './team-prompt-base.js' keeps working unchanged) and keeps the two prompt
+ * composition entry points -- buildRoleFrameworkPrompt and buildFocusTeamPrompt.
+ *
+ * Extracted from focus-prompt-builder.ts for maintainability; split into
+ * prompt-sections/ for navigability.
+ */
+// Role-framework sections.
+export { buildRoleSection, buildDomainBoundariesSection, buildTeamLeadRoleSection, buildReadOnlyAuditSection, } from './prompt-sections/role-sections.js';
+import { buildRoleSection, buildDomainBoundariesSection, buildTeamLeadRoleSection, buildReadOnlyAuditSection, } from './prompt-sections/role-sections.js';
+// Context sections.
+export { buildFocusContextSection, buildProductContextSection, buildDeploymentProfileSection, buildLoopContextSection, buildExecutionConfigSection, } from './prompt-sections/context-sections.js';
+import { buildFocusContextSection, buildProductContextSection, buildDeploymentProfileSection, buildLoopContextSection, buildExecutionConfigSection, } from './prompt-sections/context-sections.js';
+// Execution sections.
+export { buildPlanningSection, buildDeliveryListingSection, buildStatusUpdateRulesSection, buildExecutionInstructionsSection, buildSessionConstraintsSection, buildWorkerManagementSection, buildDeliveryStageProgressionSection, buildScopingMandateSection, buildRescopingSection, buildNewWorkDeliverySection, buildErrorHandlingSection, buildMergeConflictSection, buildCompletionSection, } from './prompt-sections/execution-sections.js';
+import { buildPlanningSection, buildDeliveryListingSection, buildStatusUpdateRulesSection, buildExecutionInstructionsSection, buildSessionConstraintsSection, buildWorkerManagementSection, buildDeliveryStageProgressionSection, buildScopingMandateSection, buildRescopingSection, buildNewWorkDeliverySection, buildErrorHandlingSection, buildMergeConflictSection, buildCompletionSection, } from './prompt-sections/execution-sections.js';
+// Persona / framing sections + resume-delta message.
+export { buildRemediationDirectiveSection, LAST_REVIEW_REPORT_HEADING, buildRemediationFramingSection, buildLoopMaintenanceSection, buildCloseLoopBookkeeperPersona, buildCloseLoopDriftCheckSection, buildResumeDeltaMessage, } from './prompt-sections/persona-sections.js';
+import { buildRemediationDirectiveSection, buildLoopMaintenanceSection, buildCloseLoopDriftCheckSection, } from './prompt-sections/persona-sections.js';
 // ---------------------------------------------------------------------------
 // Role framework prompt (stage-agnostic)
 // ---------------------------------------------------------------------------