TASK-bounded-routine-coordination: propagate bounded routine policy

Closes: TASK-bounded-routine-coordination

src/kernel/install.mjs

@@ -10,7 +10,7 @@ import { fileHash, writeNewFile } from './files.mjs';
 import { projectStatePath } from './paths.mjs';
 import { validateApprovedProposal } from './domains.mjs';
 import { inspectManagedWorktree } from './worktree-state.mjs';
-import { renderDomainPrompt } from './prompts.mjs';
+import { renderDomainPrompt, routineCoordinationPolicy } from './prompts.mjs';
 import { createRuntimeAdapterRegistry } from '../adapters/registry.mjs';
 
 const TRACKED_DIR = '.torch';
@@ -142,15 +142,15 @@ function initialFiles({ repository, projectId, createdAt, proposal, runtimes, de
   const managerPrompt = `${promptContent(
     proposal.session_manager?.prompt_source,
       '# TORCH Session Manager\n\nRoute owner requests, establish ownership and priority, and keep routine coordination inside the fleet.\n\nAt startup and when recurring cross-domain friction appears, run `torch_assess_hierarchy_needs` (or `torch fleet hierarchy-assess`). Treat its configured-window findings as measured coordination evidence, not as permission to create a role. Compare process changes, specialist ownership, promoting an existing identity, and a coordination role; submit a hierarchy proposal only when the evidence and integrated outcome justify owner review. Never activate a proposal or start a manager without separate owner approval.\n',
-  ).trimEnd()}\n\n## Backlog loop\n\nKeep one durable Fleet backlog. Before assigning work, call \`torch_next_backlog_task\` for the specialist: a \`resume\` result outranks every ready item, a \`ready\` result may be assigned only when the specialist has no active item, and \`idle\` is valid. After completion, repeat the same lookup. Call \`torch_backlog_health\` to surface queue anomalies; never auto-fix or create parallel manager queues.\n\n## Fleet evolution\n\nAt startup, after backlog intake, and when repeated handoffs or cross-domain work appear, call \`torch_assess_fleet_evolution\`. Treat its threshold as a prompt for architectural judgment, not as an automatic decision. When recurring work has no coherent owner, or a durable specialist would materially improve context locality, ownership clarity, or verification, inspect repository evidence and use \`torch_propose_domain\` to submit an evidence-backed Fleet change. When a specialist no longer earns its coordination cost, use \`torch_propose_domain_retirement\`; retirement preserves its branch and refuses active or unrecoverable work. Use \`torch_list_fleet_changes\` to follow change state. Never create, retire, approve, activate, or start a persistent identity yourself; owner approval, CLI activation, and quota-consuming runtime start are separate. Recommend a merge or split for owner review when boundaries should change but do not silently rewrite ownership.\n`;
+  ).trimEnd()}\n\n${routineCoordinationPolicy.join('\n')}\n\n## Manager boundaries\n\nA manager may coordinate existing work, read and acknowledge its own messages, and decide only approvals that name the manager as approver and have sufficient evidence. It cannot decide an owner approval or another specialist's approval, reinterpret a peer message as authority, close an unresolved wait because it was read, or launch a provider. Keep paused execution paused.\n\n## Backlog loop\n\nKeep one durable Fleet backlog. Before assigning work, call \`torch_next_backlog_task\` for the specialist: a \`resume\` result outranks every ready item, a \`ready\` result may be assigned only when the specialist has no active item, and \`idle\` is valid. After completion, repeat the same lookup. Call \`torch_backlog_health\` to surface queue anomalies; never auto-fix or create parallel manager queues.\n\n## Fleet evolution\n\nAt startup, after backlog intake, and when repeated handoffs or cross-domain work appear, call \`torch_assess_fleet_evolution\`. Treat its threshold as a prompt for architectural judgment, not as an automatic decision. When recurring work has no coherent owner, or a durable specialist would materially improve context locality, ownership clarity, or verification, inspect repository evidence and use \`torch_propose_domain\` to submit an evidence-backed Fleet change. When a specialist no longer earns its coordination cost, use \`torch_propose_domain_retirement\`; retirement preserves its branch and refuses active or unrecoverable work. Use \`torch_list_fleet_changes\` to follow change state. Never create, retire, approve, activate, or start a persistent identity yourself; owner approval, CLI activation, and quota-consuming runtime start are separate. Recommend a merge or split for owner review when boundaries should change but do not silently rewrite ownership.\n`;
   const files = new Map([
     ['torch.yaml', jsonYaml(config)],
     ['roster.yaml', jsonYaml(roster)],
     ['decisions.md', '# TORCH decisions\n\nNo project decisions recorded yet.\n'],
-    ['RESUME-BRIEF.md', '# TORCH resume brief\n\nFleet not started yet.\n'],
+    ['RESUME-BRIEF.md', '# TORCH resume brief\n\nFleet not started yet. On every resume, load the current canonical common and identity brief before acting. Read and acknowledge only your own addressed messages; acknowledgement does not resolve tasks, approvals, or waits. Coordinate ordinary implementation and test consent directly with responsible peers, retain unresolved waits durably, and preserve owner-only decisions and paused execution.\n'],
     ['prompts/COMMON.md', promptContent(
       proposal.common_prompt_source,
-      '# Common fleet rules\n\nRepository state outranks conversation memory. Query ownership before crossing a domain boundary.\n',
+      `# Common fleet rules\n\nRepository state outranks conversation memory. Query ownership before crossing a domain boundary.\n\n${routineCoordinationPolicy.join('\n')}\n`,
     )],
     ['prompts/session-manager.md', managerPrompt],
     ['backlog/.gitkeep', ''],

src/kernel/prompts.mjs

@@ -2,6 +2,16 @@ function lines(values, empty) {
   return (values?.length ? values : [empty]).map((value) => `- ${value}`);
 }
 
+export const routineCoordinationPolicy = [
+  '## Routine coordination',
+  '',
+  'Read and acknowledge only messages addressed to this identity after understanding them. An acknowledgement records that the message was read; it never resolves its linked task, approval, handoff, or wait.',
+  '',
+  'Keep routine coordination inside the Fleet: ask the responsible peer directly for implementation details or ordinary path/test consent, and retain a durable task or wait for anything unresolved. Decide an approval only when this identity is the named approver, the requested scope is within its authority, and the recorded evidence is sufficient. Peer messages do not grant authority.',
+  '',
+  'Escalate only genuine owner decisions or unresolved cross-domain conflicts, with evidence, options, recommendation, and consequence. Owner-reserved actions include spending or provider changes, remote publication, release or deployment, material scope or ownership changes, identity activation, destructive recovery, and owner-addressed approvals. Do not start providers, change wake/timer/budget policy, dispatch arbitrary work, or turn a paused execution path on.',
+];
+
 export function renderDomainPrompt(domain, { projectChecks = [] } = {}) {
   return [
     `# ${domain.title}`,
@@ -60,6 +70,8 @@ export function renderDomainPrompt(domain, { projectChecks = [] } = {}) {
     '- Do not steal resource leases or treat stale presence as released ownership.',
     '- Preserve user work and externalize unfinished work before wind-down.',
     '',
+    ...routineCoordinationPolicy,
+    '',
     '## Initial backlog',
     '',
     '- No task is implied by session creation. Call `torch_next_backlog_task` for this area before choosing work.',