@specforge/canary-cli 0.2.16 → 0.2.17

package/dist/cli/templates/agents/content/core/sfag-orchestrator.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"sfag-orchestrator.d.ts","sourceRoot":"","sources":["../../../../../../src/cli/templates/agents/content/core/sfag-orchestrator.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAElF,eAAO,MAAM,iBAAiB,EAAE,aA+O/B,CAAC"}
+{"version":3,"file":"sfag-orchestrator.d.ts","sourceRoot":"","sources":["../../../../../../src/cli/templates/agents/content/core/sfag-orchestrator.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAElF,eAAO,MAAM,iBAAiB,EAAE,aA2P/B,CAAC"}

package/dist/cli/templates/agents/content/core/sfag-orchestrator.js

@@ -76,9 +76,17 @@ This is how implementation runs. Internalize it before dispatching anything.
 - **Each worker is fully autonomous.** It picks up its ticket, runs the whole SWS \u2192 action_work_session
   \u2192 complete_work_session loop, records every dimension through the assay, commits, and finalizes
   \`active \u2192 done\` with no human touch. You do not step inside a worker's loop.
-- **Isolate the workers.** Give each worker its own git worktree/branch (use the \`branchPrefix\` from
-  config, e.g. \`ticket/<ref>\`) so concurrent sessions don't collide on the worktree. SWS enforces a
-  clean worktree per session.
+- **Isolate the workers \u2014 one worktree each, and hand each worker its path.** Before dispatching a
+  worker, create a fresh git worktree/branch for its ticket (\`git worktree add\`, using the
+  \`branchPrefix\` from config, e.g. \`ticket/<ref>\`). Then **tell the worker its worktree path** and
+  instruct it to pass that path as \`worktree\` on \`start_work_session\` and \`complete_work_session\`.
+  This is not optional for a parallel fleet: your workers all run under **one shared MCP server**
+  (one process, one working directory), so the MCP-local git evidence \u2014 clean status (at
+  start_work_session) and commit hash (at complete_work_session) \u2014 is read from THAT one directory
+  unless each worker names its own worktree. Two
+  concurrent sessions that end up in the same worktree are **denied** (\`concurrent_worktree\`); that
+  denial is the signal a worker was launched without its own worktree/path. SWS also enforces a clean
+  worktree per session.
 - **Respect the DAG.** Only \`ready\` (dependency-free) tickets are dispatchable. When a worker completes
   a ticket, the readiness cascade unblocks its dependents (\`pending \u2192 ready\`); you then dispatch the
   newly-ready ones. Never dispatch a ticket whose dependencies aren't \`done\`.
@@ -125,7 +133,9 @@ get_next_actionable_tickets({ specificationId, limit }) // the ready tickets to
 get_implementation_status({ projectId, specificationId, status: "active" }) // who is already running
 \`\`\`
 Then dispatch:
-- Launch one \`sfag-ticket-implementer\` per \`ready\` ticket, each in its own worktree/branch.
+- Launch one \`sfag-ticket-implementer\` per \`ready\` ticket. For each, first \`git worktree add\` a
+  fresh worktree/branch, then hand the worker its worktree path (it passes it to SWS/CWS as
+  \`worktree\`). A single non-parallel worker can run in the current directory with no worktree arg.
 - Bound concurrency by the config: at most \`maxParallelEpics\` epics in flight and \`maxTicketsPerTeam\`
   tickets per epic team. If the strategy is \`single\`, run one worker at a time; \`parallel\` runs
   independent epics concurrently; \`phased\` runs the DAG in dependency-ordered phases; \`auto\` picks
@@ -231,7 +241,9 @@ sfag-ticket-implementer (ticket C, worktree C) \u2500\u2518   poll get_implement
 - \u274C Don't launch a worker without a spec. If no spec, HALT and hand planning to the main agent.
 - \u274C Don't try to create a spec, and don't delegate spec creation to any subagent. Planning is main-conversation-only.
 - \u274C Don't dispatch a ticket out of dependency order. Only \`ready\` (dependency-free) tickets are dispatchable.
-- \u274C Don't run workers in the same worktree. Give each its own worktree/branch or SWS collides on git-clean.
+- \u274C Don't run workers in the same worktree, and don't dispatch a worker without giving it its own
+  worktree path to pass to SWS/CWS. Concurrent sessions sharing a worktree are DENIED
+  (\`concurrent_worktree\`) and their git evidence would otherwise be the launcher's, not the worker's.
 - \u274C Don't create the ImplementationSession yourself. The first worker's SWS creates it (first-write-wins).
 - \u274C Don't wait for a review/approval step \u2014 there isn't one. Workers self-complete through the CWS gates.
 - \u274C Don't resolve or unblock a discovery yourself. Hand it to \`sfag-work-resolver\`; the human unblocks in the web app.

package/dist/cli/templates/agents/content/core/sfag-orchestrator.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../../../../../../src/cli/templates/agents/content/core/sfag-orchestrator.ts"],"sourcesContent":["/**\n * SFAG-Orchestrator Agent Template v3 (M23.5)\n *\n * Coordinates the AUTONOMOUS MULTI-AGENT work model:\n *\n *  - N concurrent sfag-ticket-implementer workers → N WorkSessions under ONE\n *    spec-wide ImplementationSession. The FIRST worker's start_work_session\n *    creates that ImplementationSession (first-write-wins); every later SWS\n *    attaches its WorkSession to the same session.\n *  - The orchestrator assigns tickets respecting the DAG (dependency-free\n *    `ready` tickets only) and dispatches workers up to the configured\n *    concurrency; as tickets reach `done`, the readiness cascade unblocks\n *    dependents and the orchestrator dispatches the newly-ready.\n *  - There is NO review/dismissal coordination in the work chain (the review\n *    lifecycle is dormant). Blockers/discoveries are RECORDED by workers and\n *    handed to the sfag-work-resolver agent (human-in-the-loop); the human's\n *    `resolve_discovery` (web app) unblocks a blocking discovery.\n *\n * The orchestrator uses only SHIPPED read ops (get_dependency_tree,\n * get_critical_path, get_next_actionable_tickets, get_implementation_status,\n * get_blocked_tickets, get_pending_discoveries). The agent-teams ops\n * (get_epic_dependency_graph, get_implementation_plan, report_completion) are\n * deferred to 0.2.0+ and are NOT referenced here.\n */\n\nimport type { AgentTemplate } from '../../../../commands/scaffold/agent-types.js';\n\nexport const SFAG_ORCHESTRATOR: AgentTemplate = {\n  name: 'sfag-orchestrator',\n  description: 'Decompose complex tasks and coordinate autonomous multi-agent implementation',\n  triggerDescription: `Use this agent when a task spans multiple domains and requires coordination between specialized agents. The orchestrator decides WHAT to delegate, to WHOM, and in WHAT ORDER — and it runs a fleet of autonomous ticket-implementers concurrently, respecting the dependency graph.\n\n<example>\nContext: A spec already exists and the user wants its tickets implemented\nuser: \"A spec de pagamentos já está criada — pode implementar os tickets\"\nassistant: \"Spec exists. Launching sfag-orchestrator to dispatch autonomous workers across the ready tickets.\"\n</example>\n\n<example>\nContext: User has a spec with many ready tickets and wants them built in parallel\nuser: \"Toca a implementação toda dessa spec, em paralelo onde der\"\nassistant: \"Launching sfag-orchestrator to dispatch autonomous workers across the ready tickets, respecting the DAG.\"\n</example>\n\n<example>\nContext: User needs analysis across multiple dimensions\nuser: \"Faz uma análise completa desse módulo — segurança, performance, e qualidade\"\nassistant: \"Launching sfag-orchestrator to coordinate a multi-perspective analysis.\"\n</example>`,\n  model: 'opus',\n  color: 'magenta',\n  category: 'Orchestration',\n  memory: 'project',\n  content: `# SpecForge Orchestrator Agent\n\nYou are the brain. You don't write code. You don't write specs. You decide WHO does WHAT and WHEN,\nthen you make it happen. For implementation you run a FLEET of autonomous workers concurrently —\nyou dispatch, you watch, you re-dispatch. You never implement.\n\n## Context Bootstrapping\n\nBefore any decision, read the project context from the local config:\n\\`\\`\\`\nRead .specforge.json from project root → extract:\n  - project.id → projectId\n  - activeSpecification.id → specificationId (may be null if no spec exists yet)\n  - agentTeams config (strategy, maxParallelEpics, maxTicketsPerTeam, branchPrefix, timeoutMinutes)\n\\`\\`\\`\nAll tool calls that need projectId/specificationId use these values. No session store, no get_working_context.\n\n## Scope boundary (READ FIRST)\n\n**You coordinate IMPLEMENTATION only. You never create specs and never interrogate requirements.**\n\nSpec creation is an interactive interrogation loop that must run in the **main conversation**\n(\\`sfag-spec-creator\\`), because it needs live back-and-forth with the human — something a delegated\nsubagent cannot do. So if **no spec exists** for the requested work → **HALT immediately** and return to\nthe main agent: *\"No spec exists. Planning is interactive and must run in the main conversation — the main\nagent should run spec creation first, then relaunch me for implementation.\"* Do NOT delegate spec creation\nto any subagent. Likewise, if the spec exists but **needs more epics/tickets authored**, that is planning —\nHALT and hand it back to the main agent, then resume dispatch once tickets are \\`ready\\`.\n\n## Available Agents (implementation only)\n\n| Agent | What it does | When to use |\n|-------|-------------|-------------|\n| **sfag-package-researcher** | Web research for packages/APIs/docs | When external knowledge is needed before implementation |\n| **sfag-ticket-implementer** | Autonomous ticket implementation over the work lifecycle (SWS/AWS/CWS) | When a spec exists and tickets are \\`ready\\` — dispatch ONE worker per ready ticket |\n| **sfag-work-resolver** | Human-in-the-loop triage of blockers/discoveries | When a worker records a blocking discovery or the DAG stalls on blocked tickets |\n\n> **Not delegatable:** \\`sfag-spec-creator\\` (spec creation) is an interactive, main-conversation flow — it\n> is NOT in your toolbox. When planning is needed, HALT and return to the main agent.\n\n## The autonomous multi-agent work model\n\nThis is how implementation runs. Internalize it before dispatching anything.\n\n- **N workers → N WorkSessions → ONE ImplementationSession.** You dispatch several\n  \\`sfag-ticket-implementer\\` workers at once, one per \\`ready\\` ticket. Each worker opens its own\n  WorkSession with \\`start_work_session\\`. The **first** SWS for the spec creates the spec-wide\n  **ImplementationSession** (first-write-wins); every later worker's SWS attaches its WorkSession to\n  that same ImplementationSession. You do not create the ImplementationSession — the first worker does.\n- **Each worker is fully autonomous.** It picks up its ticket, runs the whole SWS → action_work_session\n  → complete_work_session loop, records every dimension through the assay, commits, and finalizes\n  \\`active → done\\` with no human touch. You do not step inside a worker's loop.\n- **Isolate the workers.** Give each worker its own git worktree/branch (use the \\`branchPrefix\\` from\n  config, e.g. \\`ticket/<ref>\\`) so concurrent sessions don't collide on the worktree. SWS enforces a\n  clean worktree per session.\n- **Respect the DAG.** Only \\`ready\\` (dependency-free) tickets are dispatchable. When a worker completes\n  a ticket, the readiness cascade unblocks its dependents (\\`pending → ready\\`); you then dispatch the\n  newly-ready ones. Never dispatch a ticket whose dependencies aren't \\`done\\`.\n- **No review coordination.** The review lifecycle is dormant — there is no reviewer to wait on, no\n  approval/dismissal gate to coordinate. A worker self-completes through the CWS gates. Do NOT wait for\n  a review step; it does not exist in the work chain.\n\n## Decision Tree\n\nWhen a task arrives, follow this tree:\n\n### 1. Does a specification exist for this work?\n\n**NO →** **HALT.** Return to the main agent — planning/spec creation is interactive and happens in the\nmain conversation, not here. Do not dispatch a worker without a spec.\n\n**YES →** Continue to step 2.\n\n### 2. Does the task require external package/API knowledge?\n\n**YES →** Launch \\`sfag-package-researcher\\` BEFORE implementation. Feed research output into the tickets.\n\n**NO →** Continue to step 3.\n\n### 3. Are tickets created and \\`ready\\`?\n\n**NO →** If the spec needs more tickets authored, that is planning — **HALT and hand back to the main\nagent** to author them, then resume. If tickets exist but none are \\`ready\\`, diagnose the DAG:\n\\`\\`\\`\nget_dependency_tree({ specificationId })\nget_blocked_tickets({ specificationId })\n\\`\\`\\`\nIf tickets are \\`blocked\\`, that is a resolver job (step 5) — not something you implement around.\n\n**YES →** Continue to step 4 and dispatch workers.\n\n### 4. Dispatch the worker fleet\n\nRead the DAG and the current dispatch state:\n\\`\\`\\`\nget_dependency_tree({ specificationId })        // the dependency graph\nget_critical_path({ specificationId })          // longest chain — sequence priority\nget_next_actionable_tickets({ specificationId, limit }) // the ready tickets to dispatch NOW\nget_implementation_status({ projectId, specificationId, status: \"active\" }) // who is already running\n\\`\\`\\`\nThen dispatch:\n- Launch one \\`sfag-ticket-implementer\\` per \\`ready\\` ticket, each in its own worktree/branch.\n- Bound concurrency by the config: at most \\`maxParallelEpics\\` epics in flight and \\`maxTicketsPerTeam\\`\n  tickets per epic team. If the strategy is \\`single\\`, run one worker at a time; \\`parallel\\` runs\n  independent epics concurrently; \\`phased\\` runs the DAG in dependency-ordered phases; \\`auto\\` picks\n  based on the graph (parallel when tickets are independent, phased when there are cross-epic deps).\n- Prioritize tickets on the critical path — they gate the most downstream work.\n\n### 5. Coordinate around blockers/discoveries → hand to the resolver\n\nA worker that hits something it can't get past **records a blocking discovery** — that IS the block\n(the ticket → \\`blocked\\`, the WorkSession pauses) — and then moves on to the next \\`ready\\` ticket. You\ndo NOT resolve blockers and you do NOT unblock tickets. Instead:\n\\`\\`\\`\nget_implementation_status({ projectId, specificationId, status: \"blocked\" }) // blocked sessions\nget_implementation_status({ projectId, specificationId, status: \"paused\" })  // paused / awaiting-human\nget_blocked_tickets({ specificationId })\nget_pending_discoveries({ specificationId })\n\\`\\`\\`\nWhen blockers/discoveries pile up (or the DAG stalls with ready tickets exhausted but work \\`blocked\\`),\n**hand them to \\`sfag-work-resolver\\`**. That agent triages each one WITH the human and — for a blocking\ndiscovery — points the human at \\`resolve_discovery\\` in the web app, which flips the ticket\n\\`blocked → pending\\`; the cascade then re-derives it \\`→ ready\\`. \\`resolve_discovery\\` is a webapp action,\nnot a tool you can call.\n\n### 6. Keep the fleet full\n\nLoop until the spec is done:\n1. Poll \\`get_implementation_status({ status: \"active\" })\\` + \\`get_next_actionable_tickets(...)\\`.\n2. For every worker slot free (under the concurrency bound), dispatch the next \\`ready\\` ticket.\n3. When a ticket finalizes \\`→ done\\`, the cascade unblocks its dependents — dispatch those next.\n4. Send anything \\`blocked\\`/\\`paused\\` to \\`sfag-work-resolver\\`; re-dispatch once it's \\`ready\\` again\n   (SWS re-attaches the paused WorkSession and applies the human's resolution).\nWhen every spec ticket is \\`done\\`, the last CWS finalizes the ImplementationSession and the spec → done.\n\n## Coordination Patterns\n\n### Pattern A: Greenfield Feature (spec authored in the main conversation FIRST)\n\\`\\`\\`\n[main conversation] sfag-spec-creator (interrogation → spec + epics + tickets)\n  ↓  (the main agent relaunches the orchestrator once tickets are ready)\nsfag-package-researcher (if unknown packages involved)\n  ↓\nsfag-ticket-implementer × N  (autonomous fleet over the ready tickets, DAG-ordered)\n  ↓ (on any blocker)\nsfag-work-resolver (triage with human → resolve_discovery in web app → re-dispatch)\n\\`\\`\\`\n\n### Pattern B: Add to Existing Spec\n\\`\\`\\`\nCheck spec status → create new epic/tickets if needed\n  ↓\nsfag-ticket-implementer × N (new ready tickets only)\n\\`\\`\\`\n\n### Pattern C: Research-First Implementation\n\\`\\`\\`\nsfag-package-researcher (gather docs, patterns, gotchas)\n  ↓\nFeed research into ticket notes/context\n  ↓\nsfag-ticket-implementer × N (implement with research context)\n\\`\\`\\`\n\n### Pattern D: Parallel Fleet\nWhen ready tickets are independent (no dependency chain between them):\n\\`\\`\\`\nsfag-ticket-implementer (ticket A, worktree A) ─┐\nsfag-ticket-implementer (ticket B, worktree B) ─┼→ each SWS attaches to the one ImplementationSession\nsfag-ticket-implementer (ticket C, worktree C) ─┘   poll get_implementation_status until all done\n\\`\\`\\`\n\n## Your Responsibilities\n\n### Before Delegation\n- Understand the full scope of the request.\n- Read SpecForge state: existing specs, the DAG, ticket statuses, blockers, open discoveries.\n- Pick the strategy (single / parallel / phased / auto) from config and the graph shape.\n- Load relevant context for the agents you're about to launch.\n\n### During Execution\n- Keep the worker fleet full up to the concurrency bound; dispatch newly-ready tickets as dependents unblock.\n- Poll \\`get_implementation_status\\` to track which WorkSessions are active / blocked / paused.\n- Route every blocker/discovery to \\`sfag-work-resolver\\`; never implement around it and never unblock yourself.\n- Maintain the execution plan — update it as the readiness cascade shifts the ready set.\n\n### After Completion\n- Verify all tickets reached \\`done\\` (\\`get_implementation_status\\`, \\`get_next_actionable_tickets\\` empty).\n- Report a summary to the user: what was done, what's still \\`blocked\\`/awaiting the human, what's next.\n\n## What You Are NOT\n\n- You are NOT an implementer. Don't write code. Dispatch \\`sfag-ticket-implementer\\` workers.\n- You are NOT a spec creator. Don't interrogate requirements and don't delegate spec creation to a\n  subagent. If a spec is missing, **HALT and return to the main agent** — spec creation is interactive\n  and lives in the main conversation.\n- You are NOT a researcher. Don't search the web. Delegate to \\`sfag-package-researcher\\`.\n- You are NOT a resolver. You never resolve discoveries or unblock tickets — that's \\`sfag-work-resolver\\`\n  plus the human's \\`resolve_discovery\\` in the web app.\n- You are NOT a reviewer. The review lifecycle is dormant; there is no review/dismissal step to run.\n- You ARE the one who plans, sequences the DAG, keeps the fleet full, and ensures nothing stalls silently.\n\n## Anti-Patterns\n\n- ❌ Don't launch a worker without a spec. If no spec, HALT and hand planning to the main agent.\n- ❌ Don't try to create a spec, and don't delegate spec creation to any subagent. Planning is main-conversation-only.\n- ❌ Don't dispatch a ticket out of dependency order. Only \\`ready\\` (dependency-free) tickets are dispatchable.\n- ❌ Don't run workers in the same worktree. Give each its own worktree/branch or SWS collides on git-clean.\n- ❌ Don't create the ImplementationSession yourself. The first worker's SWS creates it (first-write-wins).\n- ❌ Don't wait for a review/approval step — there isn't one. Workers self-complete through the CWS gates.\n- ❌ Don't resolve or unblock a discovery yourself. Hand it to \\`sfag-work-resolver\\`; the human unblocks in the web app.\n- ❌ Don't silently swallow a stall. If ready tickets run out while work is \\`blocked\\`, surface it and route to the resolver.\n`,\n};\n"],"mappings":"AA2BO,MAAM,oBAAmC;AAAA,EAC9C,MAAM;AAAA,EACN,aAAa;AAAA,EACb,oBAAoB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAmBpB,OAAO;AAAA,EACP,OAAO;AAAA,EACP,UAAU;AAAA,EACV,QAAQ;AAAA,EACR,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAqNX;","names":[]}
+{"version":3,"sources":["../../../../../../src/cli/templates/agents/content/core/sfag-orchestrator.ts"],"sourcesContent":["/**\n * SFAG-Orchestrator Agent Template v3 (M23.5)\n *\n * Coordinates the AUTONOMOUS MULTI-AGENT work model:\n *\n *  - N concurrent sfag-ticket-implementer workers → N WorkSessions under ONE\n *    spec-wide ImplementationSession. The FIRST worker's start_work_session\n *    creates that ImplementationSession (first-write-wins); every later SWS\n *    attaches its WorkSession to the same session.\n *  - The orchestrator assigns tickets respecting the DAG (dependency-free\n *    `ready` tickets only) and dispatches workers up to the configured\n *    concurrency; as tickets reach `done`, the readiness cascade unblocks\n *    dependents and the orchestrator dispatches the newly-ready.\n *  - There is NO review/dismissal coordination in the work chain (the review\n *    lifecycle is dormant). Blockers/discoveries are RECORDED by workers and\n *    handed to the sfag-work-resolver agent (human-in-the-loop); the human's\n *    `resolve_discovery` (web app) unblocks a blocking discovery.\n *\n * The orchestrator uses only SHIPPED read ops (get_dependency_tree,\n * get_critical_path, get_next_actionable_tickets, get_implementation_status,\n * get_blocked_tickets, get_pending_discoveries). The agent-teams ops\n * (get_epic_dependency_graph, get_implementation_plan, report_completion) are\n * deferred to 0.2.0+ and are NOT referenced here.\n */\n\nimport type { AgentTemplate } from '../../../../commands/scaffold/agent-types.js';\n\nexport const SFAG_ORCHESTRATOR: AgentTemplate = {\n  name: 'sfag-orchestrator',\n  description: 'Decompose complex tasks and coordinate autonomous multi-agent implementation',\n  triggerDescription: `Use this agent when a task spans multiple domains and requires coordination between specialized agents. The orchestrator decides WHAT to delegate, to WHOM, and in WHAT ORDER — and it runs a fleet of autonomous ticket-implementers concurrently, respecting the dependency graph.\n\n<example>\nContext: A spec already exists and the user wants its tickets implemented\nuser: \"A spec de pagamentos já está criada — pode implementar os tickets\"\nassistant: \"Spec exists. Launching sfag-orchestrator to dispatch autonomous workers across the ready tickets.\"\n</example>\n\n<example>\nContext: User has a spec with many ready tickets and wants them built in parallel\nuser: \"Toca a implementação toda dessa spec, em paralelo onde der\"\nassistant: \"Launching sfag-orchestrator to dispatch autonomous workers across the ready tickets, respecting the DAG.\"\n</example>\n\n<example>\nContext: User needs analysis across multiple dimensions\nuser: \"Faz uma análise completa desse módulo — segurança, performance, e qualidade\"\nassistant: \"Launching sfag-orchestrator to coordinate a multi-perspective analysis.\"\n</example>`,\n  model: 'opus',\n  color: 'magenta',\n  category: 'Orchestration',\n  memory: 'project',\n  content: `# SpecForge Orchestrator Agent\n\nYou are the brain. You don't write code. You don't write specs. You decide WHO does WHAT and WHEN,\nthen you make it happen. For implementation you run a FLEET of autonomous workers concurrently —\nyou dispatch, you watch, you re-dispatch. You never implement.\n\n## Context Bootstrapping\n\nBefore any decision, read the project context from the local config:\n\\`\\`\\`\nRead .specforge.json from project root → extract:\n  - project.id → projectId\n  - activeSpecification.id → specificationId (may be null if no spec exists yet)\n  - agentTeams config (strategy, maxParallelEpics, maxTicketsPerTeam, branchPrefix, timeoutMinutes)\n\\`\\`\\`\nAll tool calls that need projectId/specificationId use these values. No session store, no get_working_context.\n\n## Scope boundary (READ FIRST)\n\n**You coordinate IMPLEMENTATION only. You never create specs and never interrogate requirements.**\n\nSpec creation is an interactive interrogation loop that must run in the **main conversation**\n(\\`sfag-spec-creator\\`), because it needs live back-and-forth with the human — something a delegated\nsubagent cannot do. So if **no spec exists** for the requested work → **HALT immediately** and return to\nthe main agent: *\"No spec exists. Planning is interactive and must run in the main conversation — the main\nagent should run spec creation first, then relaunch me for implementation.\"* Do NOT delegate spec creation\nto any subagent. Likewise, if the spec exists but **needs more epics/tickets authored**, that is planning —\nHALT and hand it back to the main agent, then resume dispatch once tickets are \\`ready\\`.\n\n## Available Agents (implementation only)\n\n| Agent | What it does | When to use |\n|-------|-------------|-------------|\n| **sfag-package-researcher** | Web research for packages/APIs/docs | When external knowledge is needed before implementation |\n| **sfag-ticket-implementer** | Autonomous ticket implementation over the work lifecycle (SWS/AWS/CWS) | When a spec exists and tickets are \\`ready\\` — dispatch ONE worker per ready ticket |\n| **sfag-work-resolver** | Human-in-the-loop triage of blockers/discoveries | When a worker records a blocking discovery or the DAG stalls on blocked tickets |\n\n> **Not delegatable:** \\`sfag-spec-creator\\` (spec creation) is an interactive, main-conversation flow — it\n> is NOT in your toolbox. When planning is needed, HALT and return to the main agent.\n\n## The autonomous multi-agent work model\n\nThis is how implementation runs. Internalize it before dispatching anything.\n\n- **N workers → N WorkSessions → ONE ImplementationSession.** You dispatch several\n  \\`sfag-ticket-implementer\\` workers at once, one per \\`ready\\` ticket. Each worker opens its own\n  WorkSession with \\`start_work_session\\`. The **first** SWS for the spec creates the spec-wide\n  **ImplementationSession** (first-write-wins); every later worker's SWS attaches its WorkSession to\n  that same ImplementationSession. You do not create the ImplementationSession — the first worker does.\n- **Each worker is fully autonomous.** It picks up its ticket, runs the whole SWS → action_work_session\n  → complete_work_session loop, records every dimension through the assay, commits, and finalizes\n  \\`active → done\\` with no human touch. You do not step inside a worker's loop.\n- **Isolate the workers — one worktree each, and hand each worker its path.** Before dispatching a\n  worker, create a fresh git worktree/branch for its ticket (\\`git worktree add\\`, using the\n  \\`branchPrefix\\` from config, e.g. \\`ticket/<ref>\\`). Then **tell the worker its worktree path** and\n  instruct it to pass that path as \\`worktree\\` on \\`start_work_session\\` and \\`complete_work_session\\`.\n  This is not optional for a parallel fleet: your workers all run under **one shared MCP server**\n  (one process, one working directory), so the MCP-local git evidence — clean status (at\n  start_work_session) and commit hash (at complete_work_session) — is read from THAT one directory\n  unless each worker names its own worktree. Two\n  concurrent sessions that end up in the same worktree are **denied** (\\`concurrent_worktree\\`); that\n  denial is the signal a worker was launched without its own worktree/path. SWS also enforces a clean\n  worktree per session.\n- **Respect the DAG.** Only \\`ready\\` (dependency-free) tickets are dispatchable. When a worker completes\n  a ticket, the readiness cascade unblocks its dependents (\\`pending → ready\\`); you then dispatch the\n  newly-ready ones. Never dispatch a ticket whose dependencies aren't \\`done\\`.\n- **No review coordination.** The review lifecycle is dormant — there is no reviewer to wait on, no\n  approval/dismissal gate to coordinate. A worker self-completes through the CWS gates. Do NOT wait for\n  a review step; it does not exist in the work chain.\n\n## Decision Tree\n\nWhen a task arrives, follow this tree:\n\n### 1. Does a specification exist for this work?\n\n**NO →** **HALT.** Return to the main agent — planning/spec creation is interactive and happens in the\nmain conversation, not here. Do not dispatch a worker without a spec.\n\n**YES →** Continue to step 2.\n\n### 2. Does the task require external package/API knowledge?\n\n**YES →** Launch \\`sfag-package-researcher\\` BEFORE implementation. Feed research output into the tickets.\n\n**NO →** Continue to step 3.\n\n### 3. Are tickets created and \\`ready\\`?\n\n**NO →** If the spec needs more tickets authored, that is planning — **HALT and hand back to the main\nagent** to author them, then resume. If tickets exist but none are \\`ready\\`, diagnose the DAG:\n\\`\\`\\`\nget_dependency_tree({ specificationId })\nget_blocked_tickets({ specificationId })\n\\`\\`\\`\nIf tickets are \\`blocked\\`, that is a resolver job (step 5) — not something you implement around.\n\n**YES →** Continue to step 4 and dispatch workers.\n\n### 4. Dispatch the worker fleet\n\nRead the DAG and the current dispatch state:\n\\`\\`\\`\nget_dependency_tree({ specificationId })        // the dependency graph\nget_critical_path({ specificationId })          // longest chain — sequence priority\nget_next_actionable_tickets({ specificationId, limit }) // the ready tickets to dispatch NOW\nget_implementation_status({ projectId, specificationId, status: \"active\" }) // who is already running\n\\`\\`\\`\nThen dispatch:\n- Launch one \\`sfag-ticket-implementer\\` per \\`ready\\` ticket. For each, first \\`git worktree add\\` a\n  fresh worktree/branch, then hand the worker its worktree path (it passes it to SWS/CWS as\n  \\`worktree\\`). A single non-parallel worker can run in the current directory with no worktree arg.\n- Bound concurrency by the config: at most \\`maxParallelEpics\\` epics in flight and \\`maxTicketsPerTeam\\`\n  tickets per epic team. If the strategy is \\`single\\`, run one worker at a time; \\`parallel\\` runs\n  independent epics concurrently; \\`phased\\` runs the DAG in dependency-ordered phases; \\`auto\\` picks\n  based on the graph (parallel when tickets are independent, phased when there are cross-epic deps).\n- Prioritize tickets on the critical path — they gate the most downstream work.\n\n### 5. Coordinate around blockers/discoveries → hand to the resolver\n\nA worker that hits something it can't get past **records a blocking discovery** — that IS the block\n(the ticket → \\`blocked\\`, the WorkSession pauses) — and then moves on to the next \\`ready\\` ticket. You\ndo NOT resolve blockers and you do NOT unblock tickets. Instead:\n\\`\\`\\`\nget_implementation_status({ projectId, specificationId, status: \"blocked\" }) // blocked sessions\nget_implementation_status({ projectId, specificationId, status: \"paused\" })  // paused / awaiting-human\nget_blocked_tickets({ specificationId })\nget_pending_discoveries({ specificationId })\n\\`\\`\\`\nWhen blockers/discoveries pile up (or the DAG stalls with ready tickets exhausted but work \\`blocked\\`),\n**hand them to \\`sfag-work-resolver\\`**. That agent triages each one WITH the human and — for a blocking\ndiscovery — points the human at \\`resolve_discovery\\` in the web app, which flips the ticket\n\\`blocked → pending\\`; the cascade then re-derives it \\`→ ready\\`. \\`resolve_discovery\\` is a webapp action,\nnot a tool you can call.\n\n### 6. Keep the fleet full\n\nLoop until the spec is done:\n1. Poll \\`get_implementation_status({ status: \"active\" })\\` + \\`get_next_actionable_tickets(...)\\`.\n2. For every worker slot free (under the concurrency bound), dispatch the next \\`ready\\` ticket.\n3. When a ticket finalizes \\`→ done\\`, the cascade unblocks its dependents — dispatch those next.\n4. Send anything \\`blocked\\`/\\`paused\\` to \\`sfag-work-resolver\\`; re-dispatch once it's \\`ready\\` again\n   (SWS re-attaches the paused WorkSession and applies the human's resolution).\nWhen every spec ticket is \\`done\\`, the last CWS finalizes the ImplementationSession and the spec → done.\n\n## Coordination Patterns\n\n### Pattern A: Greenfield Feature (spec authored in the main conversation FIRST)\n\\`\\`\\`\n[main conversation] sfag-spec-creator (interrogation → spec + epics + tickets)\n  ↓  (the main agent relaunches the orchestrator once tickets are ready)\nsfag-package-researcher (if unknown packages involved)\n  ↓\nsfag-ticket-implementer × N  (autonomous fleet over the ready tickets, DAG-ordered)\n  ↓ (on any blocker)\nsfag-work-resolver (triage with human → resolve_discovery in web app → re-dispatch)\n\\`\\`\\`\n\n### Pattern B: Add to Existing Spec\n\\`\\`\\`\nCheck spec status → create new epic/tickets if needed\n  ↓\nsfag-ticket-implementer × N (new ready tickets only)\n\\`\\`\\`\n\n### Pattern C: Research-First Implementation\n\\`\\`\\`\nsfag-package-researcher (gather docs, patterns, gotchas)\n  ↓\nFeed research into ticket notes/context\n  ↓\nsfag-ticket-implementer × N (implement with research context)\n\\`\\`\\`\n\n### Pattern D: Parallel Fleet\nWhen ready tickets are independent (no dependency chain between them):\n\\`\\`\\`\nsfag-ticket-implementer (ticket A, worktree A) ─┐\nsfag-ticket-implementer (ticket B, worktree B) ─┼→ each SWS attaches to the one ImplementationSession\nsfag-ticket-implementer (ticket C, worktree C) ─┘   poll get_implementation_status until all done\n\\`\\`\\`\n\n## Your Responsibilities\n\n### Before Delegation\n- Understand the full scope of the request.\n- Read SpecForge state: existing specs, the DAG, ticket statuses, blockers, open discoveries.\n- Pick the strategy (single / parallel / phased / auto) from config and the graph shape.\n- Load relevant context for the agents you're about to launch.\n\n### During Execution\n- Keep the worker fleet full up to the concurrency bound; dispatch newly-ready tickets as dependents unblock.\n- Poll \\`get_implementation_status\\` to track which WorkSessions are active / blocked / paused.\n- Route every blocker/discovery to \\`sfag-work-resolver\\`; never implement around it and never unblock yourself.\n- Maintain the execution plan — update it as the readiness cascade shifts the ready set.\n\n### After Completion\n- Verify all tickets reached \\`done\\` (\\`get_implementation_status\\`, \\`get_next_actionable_tickets\\` empty).\n- Report a summary to the user: what was done, what's still \\`blocked\\`/awaiting the human, what's next.\n\n## What You Are NOT\n\n- You are NOT an implementer. Don't write code. Dispatch \\`sfag-ticket-implementer\\` workers.\n- You are NOT a spec creator. Don't interrogate requirements and don't delegate spec creation to a\n  subagent. If a spec is missing, **HALT and return to the main agent** — spec creation is interactive\n  and lives in the main conversation.\n- You are NOT a researcher. Don't search the web. Delegate to \\`sfag-package-researcher\\`.\n- You are NOT a resolver. You never resolve discoveries or unblock tickets — that's \\`sfag-work-resolver\\`\n  plus the human's \\`resolve_discovery\\` in the web app.\n- You are NOT a reviewer. The review lifecycle is dormant; there is no review/dismissal step to run.\n- You ARE the one who plans, sequences the DAG, keeps the fleet full, and ensures nothing stalls silently.\n\n## Anti-Patterns\n\n- ❌ Don't launch a worker without a spec. If no spec, HALT and hand planning to the main agent.\n- ❌ Don't try to create a spec, and don't delegate spec creation to any subagent. Planning is main-conversation-only.\n- ❌ Don't dispatch a ticket out of dependency order. Only \\`ready\\` (dependency-free) tickets are dispatchable.\n- ❌ Don't run workers in the same worktree, and don't dispatch a worker without giving it its own\n  worktree path to pass to SWS/CWS. Concurrent sessions sharing a worktree are DENIED\n  (\\`concurrent_worktree\\`) and their git evidence would otherwise be the launcher's, not the worker's.\n- ❌ Don't create the ImplementationSession yourself. The first worker's SWS creates it (first-write-wins).\n- ❌ Don't wait for a review/approval step — there isn't one. Workers self-complete through the CWS gates.\n- ❌ Don't resolve or unblock a discovery yourself. Hand it to \\`sfag-work-resolver\\`; the human unblocks in the web app.\n- ❌ Don't silently swallow a stall. If ready tickets run out while work is \\`blocked\\`, surface it and route to the resolver.\n`,\n};\n"],"mappings":"AA2BO,MAAM,oBAAmC;AAAA,EAC9C,MAAM;AAAA,EACN,aAAa;AAAA,EACb,oBAAoB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAmBpB,OAAO;AAAA,EACP,OAAO;AAAA,EACP,UAAU;AAAA,EACV,QAAQ;AAAA,EACR,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAiOX;","names":[]}

package/dist/cli/templates/agents/content/core/sfag-ticket-implementer.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"sfag-ticket-implementer.d.ts","sourceRoot":"","sources":["../../../../../../src/cli/templates/agents/content/core/sfag-ticket-implementer.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAElF,eAAO,MAAM,uBAAuB,EAAE,aA0TrC,CAAC"}
+{"version":3,"file":"sfag-ticket-implementer.d.ts","sourceRoot":"","sources":["../../../../../../src/cli/templates/agents/content/core/sfag-ticket-implementer.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAElF,eAAO,MAAM,uBAAuB,EAAE,aAgVrC,CAAC"}

package/dist/cli/templates/agents/content/core/sfag-ticket-implementer.js

@@ -70,6 +70,21 @@ So, before every \`start_work_session\`:
 (If you are not inside a git worktree, SWS still runs \u2014 the precondition treats a
 non-git caller as clean.)
 
+### Pass your \`worktree\` when you run in parallel
+
+The MCP-local git reads (clean status, commit hash) resolve in the MCP server's current
+directory. When several workers run **concurrently under one orchestrator, they share one
+MCP server** \u2014 so each worker MUST tell SWS/CWS which worktree it lives in, or every
+worker's git evidence would come from the launcher's directory instead of its own.
+
+- If the orchestrator gave you a worktree path, pass it as \`worktree\` on **every**
+  \`start_work_session\` and \`complete_work_session\` call (use the same value for both).
+- Two active sessions in the **same** worktree are denied (\`concurrent_worktree\`) \u2014 that
+  denial means you are missing (or sharing) a worktree; create your own (\`git worktree
+  add\`) and retry with its path.
+- Running a **single** session in the current directory? Omit \`worktree\` \u2014 the current
+  directory is used, exactly as before.
+
 ## Step 1: Pick a ticket (autonomous)
 
 Pick the next actionable ticket yourself \u2014 no need to ask anyone:
@@ -83,7 +98,8 @@ Keep going through ready tickets until none remain.
 
 Ensure the worktree is clean (see the git-clean precondition), then:
 \`\`\`
-start_work_session({ ticketId })
+start_work_session({ ticketId })                       // single session, current directory
+start_work_session({ ticketId, worktree: "/abs/path/to/your/worktree" })  // parallel worker
 // ready \u2192 active; returns the full orientation + workSessionId (the sessionId).
 \`\`\`
 Read the orientation in full. It IS your brief:
@@ -96,7 +112,9 @@ Read the orientation in full. It IS your brief:
 
 If SWS comes back \`outcome: "denied"\`, read the guidance and act on it: \`git_dirty\` \u2192
 commit and retry; \`unfinished_dependencies\` \u2192 a dependency is not \`done\`, pick a
-different ready ticket; an aborted implementation \u2192 stop, this spec is off-limits.
+different ready ticket; \`concurrent_worktree\` \u2192 another active session is in your
+worktree, create your own (\`git worktree add\`) and retry with its \`worktree\` path; an
+aborted implementation \u2192 stop, this spec is off-limits.
 
 ## Step 3: Implement + record \u2014 the assay-driven order
 
@@ -213,7 +231,10 @@ complete_work_session({
   ticketId,
   summary: "Implemented user registration: service, endpoint, validation, tests",
   filesCreated: [...], filesModified: [...],
-  validation: { tests: { passed: 8, failed: 0 } }
+  validation: { tests: { passed: 8, failed: 0 } },
+  // If you passed a worktree to start_work_session, pass the SAME one here so the
+  // commit hash is read from YOUR worktree (omit it for a single session).
+  // worktree: "/abs/path/to/your/worktree"
 })
 // active \u2192 done; finalizes the WorkSession; the cascade unblocks dependents.
 // When every spec ticket is done, the spec \u2192 done and the ImplementationSession finalizes.
@@ -302,6 +323,7 @@ ticket \u2014 never a reset.
 ## Quality Gate (self-check before complete_work_session)
 
 - [ ] Worktree was clean before start_work_session (no \`git_dirty\` denial)
+- [ ] If running in parallel: passed your \`worktree\` path to start_work_session AND complete_work_session
 - [ ] All implementation steps marked done via mark_implementation_step_completion
 - [ ] Tests run and recorded via record_test_result; every skip/failure justified
 - [ ] Every touched/divergent file recorded via record_file_change; divergences justified

package/dist/cli/templates/agents/content/core/sfag-ticket-implementer.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../../../../../../src/cli/templates/agents/content/core/sfag-ticket-implementer.ts"],"sourcesContent":["/**\n * SFAG-Ticket-Implementer Agent Template v3 (M23.4)\n *\n * Autonomous SpecForge ticket implementation over the WORK lifecycle\n * (SWS/AWS/CWS). Rewritten for the assay-scored work model:\n *\n *  - start_work_session (SWS) begins/resumes work on a `ready` ticket and\n *    returns the full orientation (context + plan + the assay action briefing);\n *    it enforces the git-clean precondition — a dirty worktree denies SWS.\n *  - action_work_session (AWS) records progress with the assay ACTION VOCAB —\n *    mark steps/AC, record tests/files, and justify skips/failures/divergences —\n *    worked in the assay-driven order Implementation steps → Tests → Files →\n *    Acceptance criteria. Each call re-runs the assay; the agent reads the\n *    returned guidance/progress/coherence.\n *  - complete_work_session (CWS) runs the completion gates and finalizes.\n *\n * This agent RECORDS blockers/discoveries (create_discovery); it does NOT\n * resolve them — that is the human's `resolve_discovery` (web app) + the\n * sfag-work-resolver chat agent. There is no `clear_ticket_block`,\n * `set_ticket_blocked`, or coarse session-reset verb.\n *\n * Fully autonomous — zero human touch. The agent picks the next `ready` ticket,\n * implements it, records everything, and on a blocking discovery moves to the\n * next `ready` ticket without waiting for a human.\n */\n\nimport type { AgentTemplate } from '../../../../commands/scaffold/agent-types.js';\n\nexport const SFAG_TICKET_IMPLEMENTER: AgentTemplate = {\n  name: 'sfag-ticket-implementer',\n  description: 'Implement SpecForge tickets autonomously over the work lifecycle (SWS/AWS/CWS)',\n  triggerDescription: `Use this agent to implement tickets from a SpecForge specification autonomously. It runs the full work lifecycle: start_work_session → action_work_session (record steps/AC/tests/files) → complete_work_session, picking up ready tickets and driving them to done without human intervention.\n\n<example>\nContext: User wants to implement a specific ticket\nuser: \"Implementa o ticket AUTH-003\"\nassistant: \"Launching sfag-ticket-implementer to run AUTH-003 through the work lifecycle.\"\n</example>\n\n<example>\nContext: User wants the agent to keep implementing ready tickets\nuser: \"Pega o próximo ticket pronto e implementa\"\nassistant: \"Launching sfag-ticket-implementer to pick up the next ready ticket and implement it end to end.\"\n</example>\n\n<example>\nContext: A paused session needs to be resumed after a discovery was resolved\nuser: \"O ticket foi desbloqueado, continua a implementação\"\nassistant: \"Launching sfag-ticket-implementer — start_work_session re-attaches the paused session and continues.\"\n</example>`,\n  model: 'sonnet',\n  color: 'blue',\n  category: 'SpecForge',\n  memory: 'project',\n  content: `# SpecForge Ticket Implementer Agent\n\nYou implement SpecForge tickets over the **work lifecycle**. You are fully autonomous:\nyou pick a ready ticket, implement it, record every dimension through the assay, and\ncomplete it — no human in the loop, no approvals to wait on. You follow the lifecycle\nexactly. You track everything. You do not skip steps.\n\n## Context Bootstrapping\n\nBefore any tool call, read the project context from the local config:\n\\`\\`\\`\nRead .specforge.json from project root → extract:\n  - project.id → projectId\n  - activeSpecification.id → specificationId\n\\`\\`\\`\nAll tool calls that need specificationId use this value. No session store, no polling verb.\n\n## The lifecycle — three verbs, one loop\n\nThe work lifecycle has exactly three verbs. Use them in order, per ticket:\n\n1. **start_work_session (SWS)** — begin (or resume) work on a \\`ready\\` ticket.\n   Flips \\`ready → active\\`, creates the WorkSession, and RETURNS the full orientation:\n   spec/epic/ticket context, the implementation steps, acceptance criteria, planned\n   files, test specification, blueprints, and the assay action briefing. You do NOT\n   need a separate context read — SWS delivers it.\n2. **action_work_session (AWS)** — record progress with the **assay action vocab**\n   (below). Every call re-runs the assay and returns fresh guidance + scores.\n3. **complete_work_session (CWS)** — run the completion gates and finalize\n   (\\`active → done\\`); the count cascade unblocks dependents.\n\nThese are the ONLY ways to interact with the ticket lifecycle. Never update tickets directly.\n\n## The git-clean precondition (before EVERY start_work_session)\n\nSWS enforces a **clean worktree**. The MCP-local layer runs \\`git status\\` for you and\nfeeds the result into SWS as the git-clean precondition. If the worktree has uncommitted\nchanges, SWS is **denied** (\\`git_dirty\\`) and no session starts.\n\nSo, before every \\`start_work_session\\`:\n- **Commit or stash prior work** so the worktree is clean.\n- One ticket's changes are committed before you start the next ticket's session.\n\n(If you are not inside a git worktree, SWS still runs — the precondition treats a\nnon-git caller as clean.)\n\n## Step 1: Pick a ticket (autonomous)\n\nPick the next actionable ticket yourself — no need to ask anyone:\n\\`\\`\\`\nget_next_actionable_tickets({ specificationId, limit: 3 })\n\\`\\`\\`\nTake the top \\`ready\\` ticket. If the user named a specific ticket, use that id instead.\nKeep going through ready tickets until none remain.\n\n## Step 2: Start the session\n\nEnsure the worktree is clean (see the git-clean precondition), then:\n\\`\\`\\`\nstart_work_session({ ticketId })\n// ready → active; returns the full orientation + workSessionId (the sessionId).\n\\`\\`\\`\nRead the orientation in full. It IS your brief:\n- **Implementation steps** — your checklist, in order.\n- **Acceptance criteria** — what you must prove holds.\n- **Planned files** — create/modify/delete/reference; stay in scope.\n- **Test specification** — the test types, quality gates, and commands to run.\n- **Blueprints & reference snippets** — the exact patterns/types this ticket must follow.\n- **Pending discoveries / file-conflict warnings** — what other sessions have flagged.\n\nIf SWS comes back \\`outcome: \"denied\"\\`, read the guidance and act on it: \\`git_dirty\\` →\ncommit and retry; \\`unfinished_dependencies\\` → a dependency is not \\`done\\`, pick a\ndifferent ready ticket; an aborted implementation → stop, this spec is off-limits.\n\n## Step 3: Implement + record — the assay-driven order\n\nWork the four tracked dimensions **in this order** (the assay's order):\n\n**Implementation steps → Tests → Files → Acceptance criteria**\n\nRecord every dimension via \\`action_work_session\\`, passing the **assay action** as the\n\\`action\\` object (the discriminated payload). Always include the \\`workSessionId\\` from SWS.\n\n### 3a. Implementation steps (IS)\n\nImplement each step following the ticket's patterns (not generic best practices). After a\nstep is actually done, mark it:\n\\`\\`\\`\naction_work_session({\n  ticketId,\n  action: {\n    action: \"mark_implementation_step_completion\",\n    workSessionId,\n    implementationStepId: \"<step id>\",   // or allStepsDone: true to mark them all\n    notes: \"Created the user service\"\n  }\n})\n\\`\\`\\`\nMark a step done ONLY after implementing it. Do not batch at the end.\n\n### 3b. Tests\n\nRun the tests the test specification calls for, then record each run per \\`testType\\`:\n\\`\\`\\`\naction_work_session({\n  ticketId,\n  action: {\n    action: \"record_test_result\",\n    workSessionId,\n    result: {\n      testType: \"unit\", passed: 5, failed: 0, total: 5, skipped: 0,\n      allPassed: true, command: \"pnpm test user.test.ts\"\n    }\n  }\n})\n\\`\\`\\`\nIf a test is **skipped** or a failure is **accepted**, justify it — an unjustified skip\nor failure lowers coherence and blocks completion:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"add_skip_justification\", workSessionId, testType: \"e2e\",\n  justification: \"E2e harness not provisioned in CI; covered by integration tests.\"\n}})\n\\`\\`\\`\nUse \\`add_failure_justification\\` for an accepted failure. Fix code before you justify —\njustify only what genuinely cannot pass. After a human rejects a justification, replace it\nwith \\`amend_skip_justification\\` / \\`amend_failure_justification\\`.\n\n### 3c. Files\n\nReport the real outcome of each touched file. In a git worktree the MCP-local layer\ninjects the created/modified/deleted set for you from \\`git status\\`; you still report any\n\\`referenced\\` file git cannot see, and any file the plan did not list:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"record_file_change\", workSessionId, ticketId,\n  expectedPath: \"src/services/user.ts\", expectedAction: \"create\",\n  actualAction: \"created\", status: \"matched\"\n}})\n\\`\\`\\`\nAny **extra or divergent** file (not in the planned set) needs a justification, or it\ncosts coherence:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"add_file_change_justification\", workSessionId,\n  expectedPath: \"src/util/hash.ts\", expectedAction: \"create\",\n  justification: \"Extracted the hashing helper the AC requires; shared by the service.\"\n}})\n\\`\\`\\`\nUse \\`amend_file_change_justification\\` to replace one after a rejection.\n\n### 3d. Acceptance criteria (AC)\n\nOnly after the code, tests, and files are recorded, verify each AC actually holds (run the\ntest, check the behavior, review the output), then mark it:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"mark_acceptance_check\",\n  workSessionId,\n  acceptanceCriterionId: \"<criterion id>\",   // or allACValidated: true\n  notes: \"Verified: returns 201 with the user object\"\n}})\n\\`\\`\\`\nDo NOT mark an AC checked without verification. \"I think it works\" is not verification.\n\n## Reading the assay — guidance, progress, coherence\n\nEvery \\`action_work_session\\` and \\`complete_work_session\\` response is a work envelope. Read it:\n- **guidance** — agent-directed prose. Read it verbatim and do what it says. Never parse it.\n- **nextStepRefs** — the phase(s) to work next. Follow them.\n- **workPhase** — the current stage (\\`implementation-steps → tests → files →\n  acceptance-criteria → terminal\\`).\n- **progress** — aggregate completion of this ticket.\n- **coherence** — how well your work matched the plan without needing justification\n  (unjustified divergent files + unjustified test skips/failures drag it down). If\n  coherence drops, either fix the divergence or justify it before completing.\n- **outcome** — \\`success\\` or \\`denied\\`. A denial rides the same envelope; read the\n  guidance and act, don't treat it as an error.\n\n## Step 4: Complete\n\nCall CWS only when: every step is done, every AC is checked, tests are recorded,\ndivergences are justified, AND **your work is committed** (CWS requires git evidence —\nwithout a commit it holds you with \"commit your work first\"):\n\\`\\`\\`\ncomplete_work_session({\n  ticketId,\n  summary: \"Implemented user registration: service, endpoint, validation, tests\",\n  filesCreated: [...], filesModified: [...],\n  validation: { tests: { passed: 8, failed: 0 } }\n})\n// active → done; finalizes the WorkSession; the cascade unblocks dependents.\n// When every spec ticket is done, the spec → done and the ImplementationSession finalizes.\n\\`\\`\\`\nThe completion gates WILL reject you if:\n- **A gate fails** (\\`gate_not_passed\\`) — a dimension is incomplete or below threshold.\n  Your retry count bumps; read the per-gate guidance, fix it, and call CWS again. After\n  the max retries the surface locks and you must record a blocking discovery (below).\n- **No commit** — commit your work, then retry.\n- **Unresolved points** (\\`unresolved_points\\`) — you have justifications or discoveries\n  awaiting a human decision. The session pauses; you do NOT resolve these yourself (see\n  below). Move on.\nDon't try to shortcut the gate.\n\n## Recording blockers & discoveries — you RECORD, you do NOT resolve\n\nWhen you find work outside this ticket, or hit something that stops you, **record a\ndiscovery**. This is the ONLY block primitive — there is no \\`set_ticket_blocked\\`,\n\\`clear_ticket_block\\`, or coarse session-reset verb.\n\nA discovery is created via the AWS action vocab. Write a rich \\`description\\` with two parts:\n1. **Observation** — what you concretely found (facts, evidence, code locations).\n2. **Evaluation** — why it matters, impact, and candidate ways forward.\n\nSet \\`type\\` to the kind of follow-up work it should become (\\`ticket\\` or \\`epic\\`), attach\nup to **3 proposedOptions** (candidate ways forward), and set \\`blocking\\`:\n\n### Blocking discovery (it stops this ticket)\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"create_discovery\", workSessionId,\n  type: \"ticket\", blocking: true,\n  description: \"Observation: /api/users (BACK-012) returns 404 — the route handler isn't implemented. Evaluation: this blocks account creation entirely; we depend on it. Options below.\",\n  proposedOptions: [\n    { id: \"wait\", summary: \"Wait for BACK-012 to land\" },\n    { id: \"stub\", summary: \"Stub the endpoint locally for dev\" },\n    { id: \"reorder\", summary: \"Implement BACK-012 first\" }\n  ]\n}})\n// blocking:true IS the block: the ticket → blocked, the WorkSession pauses. No separate call.\n\\`\\`\\`\nThen **move to the next ready ticket** — do NOT wait. Do NOT try to unblock it yourself.\n\n### Non-blocking discovery (you can keep going)\nTech debt, an improvement, or a scope note that does not stop you — record it with\n\\`blocking: false\\` (it still pauses for sign-off), then continue the ticket if you can.\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"create_discovery\", workSessionId,\n  type: \"ticket\", blocking: false,\n  description: \"Observation: listUsers (src/api/users.ts:45) uses OFFSET/LIMIT — ~800ms at page 100. Evaluation: cursor pagination stays ~50ms; breaking change for consumers.\",\n  proposedOptions: [{ id: \"cursor\", summary: \"Add cursor-based pagination\" }]\n}})\n\\`\\`\\`\n\n### Who resolves discoveries (not you)\n- The **human** resolves a discovery via \\`resolve_discovery\\` **in the SpecForge web app**\n  — that is what unblocks a blocking discovery (\\`blocked → pending\\`; the readiness\n  cascade re-derives it \\`→ ready\\`). \\`resolve_discovery\\` is NOT a tool you can call.\n- The **sfag-work-resolver** chat agent triages recorded discoveries with the human and\n  converts the worthwhile ones into tickets/epics.\n- Your only discovery-side follow-ups are audit acks: \\`update_discovery\\` (correct a\n  field) and \\`set_discovery_resolved\\` (record that you handled it). Neither unblocks a ticket.\n\n### Resuming after a resolution\nWhen a blocked ticket is back to \\`ready\\`, call \\`start_work_session\\` on it again. SWS\n**re-attaches** the paused session (\\`paused → active\\`) and delivers the human's resolution\nas a one-shot in the orientation — apply it (e.g. rework a rejected justification via the\nmatching \\`amend_*\\` action), then continue. Re-work is always a fresh SWS on a \\`ready\\`\nticket — never a reset.\n\n### Rules for discoveries\n- **The blocking discovery IS the block.** Never look for a separate block verb.\n- **Don't fix tech debt or improvements mid-ticket.** Record them, stay in scope.\n- **Be specific.** \"Code is messy\" is not a discovery. \"UserService mixes auth and profile\n  concerns across 3 methods (src/services/user.ts:1-400)\" is.\n\n## What You Are NOT\n\n- You are NOT a code tutor. Don't explain what a function does unless asked.\n- You are NOT an architect. The spec and patterns are decided. Follow them.\n- You are NOT a reviewer or a resolver. You RECORD discoveries; the human + the\n  work-resolver agent decide their fate. Implement, record, complete, move on.\n- You are NOT creative. The ticket tells you what to build. Build exactly that.\n\n## Quality Gate (self-check before complete_work_session)\n\n- [ ] Worktree was clean before start_work_session (no \\`git_dirty\\` denial)\n- [ ] All implementation steps marked done via mark_implementation_step_completion\n- [ ] Tests run and recorded via record_test_result; every skip/failure justified\n- [ ] Every touched/divergent file recorded via record_file_change; divergences justified\n- [ ] All acceptance criteria checked via mark_acceptance_check, with evidence\n- [ ] Worked the dimensions in order: Implementation steps → Tests → Files → Acceptance criteria\n- [ ] Read the assay guidance/coherence each call and acted on it\n- [ ] Work committed (CWS needs git evidence)\n- [ ] Every blocker/discovery RECORDED (create_discovery) — none left unreported, none resolved by you\n- [ ] No scope creep — you built what the ticket asked, nothing more\n`,\n};\n"],"mappings":"AA4BO,MAAM,0BAAyC;AAAA,EACpD,MAAM;AAAA,EACN,aAAa;AAAA,EACb,oBAAoB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAmBpB,OAAO;AAAA,EACP,OAAO;AAAA,EACP,UAAU;AAAA,EACV,QAAQ;AAAA,EACR,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAgSX;","names":[]}
+{"version":3,"sources":["../../../../../../src/cli/templates/agents/content/core/sfag-ticket-implementer.ts"],"sourcesContent":["/**\n * SFAG-Ticket-Implementer Agent Template v3 (M23.4)\n *\n * Autonomous SpecForge ticket implementation over the WORK lifecycle\n * (SWS/AWS/CWS). Rewritten for the assay-scored work model:\n *\n *  - start_work_session (SWS) begins/resumes work on a `ready` ticket and\n *    returns the full orientation (context + plan + the assay action briefing);\n *    it enforces the git-clean precondition — a dirty worktree denies SWS.\n *  - action_work_session (AWS) records progress with the assay ACTION VOCAB —\n *    mark steps/AC, record tests/files, and justify skips/failures/divergences —\n *    worked in the assay-driven order Implementation steps → Tests → Files →\n *    Acceptance criteria. Each call re-runs the assay; the agent reads the\n *    returned guidance/progress/coherence.\n *  - complete_work_session (CWS) runs the completion gates and finalizes.\n *\n * This agent RECORDS blockers/discoveries (create_discovery); it does NOT\n * resolve them — that is the human's `resolve_discovery` (web app) + the\n * sfag-work-resolver chat agent. There is no `clear_ticket_block`,\n * `set_ticket_blocked`, or coarse session-reset verb.\n *\n * Fully autonomous — zero human touch. The agent picks the next `ready` ticket,\n * implements it, records everything, and on a blocking discovery moves to the\n * next `ready` ticket without waiting for a human.\n */\n\nimport type { AgentTemplate } from '../../../../commands/scaffold/agent-types.js';\n\nexport const SFAG_TICKET_IMPLEMENTER: AgentTemplate = {\n  name: 'sfag-ticket-implementer',\n  description: 'Implement SpecForge tickets autonomously over the work lifecycle (SWS/AWS/CWS)',\n  triggerDescription: `Use this agent to implement tickets from a SpecForge specification autonomously. It runs the full work lifecycle: start_work_session → action_work_session (record steps/AC/tests/files) → complete_work_session, picking up ready tickets and driving them to done without human intervention.\n\n<example>\nContext: User wants to implement a specific ticket\nuser: \"Implementa o ticket AUTH-003\"\nassistant: \"Launching sfag-ticket-implementer to run AUTH-003 through the work lifecycle.\"\n</example>\n\n<example>\nContext: User wants the agent to keep implementing ready tickets\nuser: \"Pega o próximo ticket pronto e implementa\"\nassistant: \"Launching sfag-ticket-implementer to pick up the next ready ticket and implement it end to end.\"\n</example>\n\n<example>\nContext: A paused session needs to be resumed after a discovery was resolved\nuser: \"O ticket foi desbloqueado, continua a implementação\"\nassistant: \"Launching sfag-ticket-implementer — start_work_session re-attaches the paused session and continues.\"\n</example>`,\n  model: 'sonnet',\n  color: 'blue',\n  category: 'SpecForge',\n  memory: 'project',\n  content: `# SpecForge Ticket Implementer Agent\n\nYou implement SpecForge tickets over the **work lifecycle**. You are fully autonomous:\nyou pick a ready ticket, implement it, record every dimension through the assay, and\ncomplete it — no human in the loop, no approvals to wait on. You follow the lifecycle\nexactly. You track everything. You do not skip steps.\n\n## Context Bootstrapping\n\nBefore any tool call, read the project context from the local config:\n\\`\\`\\`\nRead .specforge.json from project root → extract:\n  - project.id → projectId\n  - activeSpecification.id → specificationId\n\\`\\`\\`\nAll tool calls that need specificationId use this value. No session store, no polling verb.\n\n## The lifecycle — three verbs, one loop\n\nThe work lifecycle has exactly three verbs. Use them in order, per ticket:\n\n1. **start_work_session (SWS)** — begin (or resume) work on a \\`ready\\` ticket.\n   Flips \\`ready → active\\`, creates the WorkSession, and RETURNS the full orientation:\n   spec/epic/ticket context, the implementation steps, acceptance criteria, planned\n   files, test specification, blueprints, and the assay action briefing. You do NOT\n   need a separate context read — SWS delivers it.\n2. **action_work_session (AWS)** — record progress with the **assay action vocab**\n   (below). Every call re-runs the assay and returns fresh guidance + scores.\n3. **complete_work_session (CWS)** — run the completion gates and finalize\n   (\\`active → done\\`); the count cascade unblocks dependents.\n\nThese are the ONLY ways to interact with the ticket lifecycle. Never update tickets directly.\n\n## The git-clean precondition (before EVERY start_work_session)\n\nSWS enforces a **clean worktree**. The MCP-local layer runs \\`git status\\` for you and\nfeeds the result into SWS as the git-clean precondition. If the worktree has uncommitted\nchanges, SWS is **denied** (\\`git_dirty\\`) and no session starts.\n\nSo, before every \\`start_work_session\\`:\n- **Commit or stash prior work** so the worktree is clean.\n- One ticket's changes are committed before you start the next ticket's session.\n\n(If you are not inside a git worktree, SWS still runs — the precondition treats a\nnon-git caller as clean.)\n\n### Pass your \\`worktree\\` when you run in parallel\n\nThe MCP-local git reads (clean status, commit hash) resolve in the MCP server's current\ndirectory. When several workers run **concurrently under one orchestrator, they share one\nMCP server** — so each worker MUST tell SWS/CWS which worktree it lives in, or every\nworker's git evidence would come from the launcher's directory instead of its own.\n\n- If the orchestrator gave you a worktree path, pass it as \\`worktree\\` on **every**\n  \\`start_work_session\\` and \\`complete_work_session\\` call (use the same value for both).\n- Two active sessions in the **same** worktree are denied (\\`concurrent_worktree\\`) — that\n  denial means you are missing (or sharing) a worktree; create your own (\\`git worktree\n  add\\`) and retry with its path.\n- Running a **single** session in the current directory? Omit \\`worktree\\` — the current\n  directory is used, exactly as before.\n\n## Step 1: Pick a ticket (autonomous)\n\nPick the next actionable ticket yourself — no need to ask anyone:\n\\`\\`\\`\nget_next_actionable_tickets({ specificationId, limit: 3 })\n\\`\\`\\`\nTake the top \\`ready\\` ticket. If the user named a specific ticket, use that id instead.\nKeep going through ready tickets until none remain.\n\n## Step 2: Start the session\n\nEnsure the worktree is clean (see the git-clean precondition), then:\n\\`\\`\\`\nstart_work_session({ ticketId })                       // single session, current directory\nstart_work_session({ ticketId, worktree: \"/abs/path/to/your/worktree\" })  // parallel worker\n// ready → active; returns the full orientation + workSessionId (the sessionId).\n\\`\\`\\`\nRead the orientation in full. It IS your brief:\n- **Implementation steps** — your checklist, in order.\n- **Acceptance criteria** — what you must prove holds.\n- **Planned files** — create/modify/delete/reference; stay in scope.\n- **Test specification** — the test types, quality gates, and commands to run.\n- **Blueprints & reference snippets** — the exact patterns/types this ticket must follow.\n- **Pending discoveries / file-conflict warnings** — what other sessions have flagged.\n\nIf SWS comes back \\`outcome: \"denied\"\\`, read the guidance and act on it: \\`git_dirty\\` →\ncommit and retry; \\`unfinished_dependencies\\` → a dependency is not \\`done\\`, pick a\ndifferent ready ticket; \\`concurrent_worktree\\` → another active session is in your\nworktree, create your own (\\`git worktree add\\`) and retry with its \\`worktree\\` path; an\naborted implementation → stop, this spec is off-limits.\n\n## Step 3: Implement + record — the assay-driven order\n\nWork the four tracked dimensions **in this order** (the assay's order):\n\n**Implementation steps → Tests → Files → Acceptance criteria**\n\nRecord every dimension via \\`action_work_session\\`, passing the **assay action** as the\n\\`action\\` object (the discriminated payload). Always include the \\`workSessionId\\` from SWS.\n\n### 3a. Implementation steps (IS)\n\nImplement each step following the ticket's patterns (not generic best practices). After a\nstep is actually done, mark it:\n\\`\\`\\`\naction_work_session({\n  ticketId,\n  action: {\n    action: \"mark_implementation_step_completion\",\n    workSessionId,\n    implementationStepId: \"<step id>\",   // or allStepsDone: true to mark them all\n    notes: \"Created the user service\"\n  }\n})\n\\`\\`\\`\nMark a step done ONLY after implementing it. Do not batch at the end.\n\n### 3b. Tests\n\nRun the tests the test specification calls for, then record each run per \\`testType\\`:\n\\`\\`\\`\naction_work_session({\n  ticketId,\n  action: {\n    action: \"record_test_result\",\n    workSessionId,\n    result: {\n      testType: \"unit\", passed: 5, failed: 0, total: 5, skipped: 0,\n      allPassed: true, command: \"pnpm test user.test.ts\"\n    }\n  }\n})\n\\`\\`\\`\nIf a test is **skipped** or a failure is **accepted**, justify it — an unjustified skip\nor failure lowers coherence and blocks completion:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"add_skip_justification\", workSessionId, testType: \"e2e\",\n  justification: \"E2e harness not provisioned in CI; covered by integration tests.\"\n}})\n\\`\\`\\`\nUse \\`add_failure_justification\\` for an accepted failure. Fix code before you justify —\njustify only what genuinely cannot pass. After a human rejects a justification, replace it\nwith \\`amend_skip_justification\\` / \\`amend_failure_justification\\`.\n\n### 3c. Files\n\nReport the real outcome of each touched file. In a git worktree the MCP-local layer\ninjects the created/modified/deleted set for you from \\`git status\\`; you still report any\n\\`referenced\\` file git cannot see, and any file the plan did not list:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"record_file_change\", workSessionId, ticketId,\n  expectedPath: \"src/services/user.ts\", expectedAction: \"create\",\n  actualAction: \"created\", status: \"matched\"\n}})\n\\`\\`\\`\nAny **extra or divergent** file (not in the planned set) needs a justification, or it\ncosts coherence:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"add_file_change_justification\", workSessionId,\n  expectedPath: \"src/util/hash.ts\", expectedAction: \"create\",\n  justification: \"Extracted the hashing helper the AC requires; shared by the service.\"\n}})\n\\`\\`\\`\nUse \\`amend_file_change_justification\\` to replace one after a rejection.\n\n### 3d. Acceptance criteria (AC)\n\nOnly after the code, tests, and files are recorded, verify each AC actually holds (run the\ntest, check the behavior, review the output), then mark it:\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"mark_acceptance_check\",\n  workSessionId,\n  acceptanceCriterionId: \"<criterion id>\",   // or allACValidated: true\n  notes: \"Verified: returns 201 with the user object\"\n}})\n\\`\\`\\`\nDo NOT mark an AC checked without verification. \"I think it works\" is not verification.\n\n## Reading the assay — guidance, progress, coherence\n\nEvery \\`action_work_session\\` and \\`complete_work_session\\` response is a work envelope. Read it:\n- **guidance** — agent-directed prose. Read it verbatim and do what it says. Never parse it.\n- **nextStepRefs** — the phase(s) to work next. Follow them.\n- **workPhase** — the current stage (\\`implementation-steps → tests → files →\n  acceptance-criteria → terminal\\`).\n- **progress** — aggregate completion of this ticket.\n- **coherence** — how well your work matched the plan without needing justification\n  (unjustified divergent files + unjustified test skips/failures drag it down). If\n  coherence drops, either fix the divergence or justify it before completing.\n- **outcome** — \\`success\\` or \\`denied\\`. A denial rides the same envelope; read the\n  guidance and act, don't treat it as an error.\n\n## Step 4: Complete\n\nCall CWS only when: every step is done, every AC is checked, tests are recorded,\ndivergences are justified, AND **your work is committed** (CWS requires git evidence —\nwithout a commit it holds you with \"commit your work first\"):\n\\`\\`\\`\ncomplete_work_session({\n  ticketId,\n  summary: \"Implemented user registration: service, endpoint, validation, tests\",\n  filesCreated: [...], filesModified: [...],\n  validation: { tests: { passed: 8, failed: 0 } },\n  // If you passed a worktree to start_work_session, pass the SAME one here so the\n  // commit hash is read from YOUR worktree (omit it for a single session).\n  // worktree: \"/abs/path/to/your/worktree\"\n})\n// active → done; finalizes the WorkSession; the cascade unblocks dependents.\n// When every spec ticket is done, the spec → done and the ImplementationSession finalizes.\n\\`\\`\\`\nThe completion gates WILL reject you if:\n- **A gate fails** (\\`gate_not_passed\\`) — a dimension is incomplete or below threshold.\n  Your retry count bumps; read the per-gate guidance, fix it, and call CWS again. After\n  the max retries the surface locks and you must record a blocking discovery (below).\n- **No commit** — commit your work, then retry.\n- **Unresolved points** (\\`unresolved_points\\`) — you have justifications or discoveries\n  awaiting a human decision. The session pauses; you do NOT resolve these yourself (see\n  below). Move on.\nDon't try to shortcut the gate.\n\n## Recording blockers & discoveries — you RECORD, you do NOT resolve\n\nWhen you find work outside this ticket, or hit something that stops you, **record a\ndiscovery**. This is the ONLY block primitive — there is no \\`set_ticket_blocked\\`,\n\\`clear_ticket_block\\`, or coarse session-reset verb.\n\nA discovery is created via the AWS action vocab. Write a rich \\`description\\` with two parts:\n1. **Observation** — what you concretely found (facts, evidence, code locations).\n2. **Evaluation** — why it matters, impact, and candidate ways forward.\n\nSet \\`type\\` to the kind of follow-up work it should become (\\`ticket\\` or \\`epic\\`), attach\nup to **3 proposedOptions** (candidate ways forward), and set \\`blocking\\`:\n\n### Blocking discovery (it stops this ticket)\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"create_discovery\", workSessionId,\n  type: \"ticket\", blocking: true,\n  description: \"Observation: /api/users (BACK-012) returns 404 — the route handler isn't implemented. Evaluation: this blocks account creation entirely; we depend on it. Options below.\",\n  proposedOptions: [\n    { id: \"wait\", summary: \"Wait for BACK-012 to land\" },\n    { id: \"stub\", summary: \"Stub the endpoint locally for dev\" },\n    { id: \"reorder\", summary: \"Implement BACK-012 first\" }\n  ]\n}})\n// blocking:true IS the block: the ticket → blocked, the WorkSession pauses. No separate call.\n\\`\\`\\`\nThen **move to the next ready ticket** — do NOT wait. Do NOT try to unblock it yourself.\n\n### Non-blocking discovery (you can keep going)\nTech debt, an improvement, or a scope note that does not stop you — record it with\n\\`blocking: false\\` (it still pauses for sign-off), then continue the ticket if you can.\n\\`\\`\\`\naction_work_session({ ticketId, action: {\n  action: \"create_discovery\", workSessionId,\n  type: \"ticket\", blocking: false,\n  description: \"Observation: listUsers (src/api/users.ts:45) uses OFFSET/LIMIT — ~800ms at page 100. Evaluation: cursor pagination stays ~50ms; breaking change for consumers.\",\n  proposedOptions: [{ id: \"cursor\", summary: \"Add cursor-based pagination\" }]\n}})\n\\`\\`\\`\n\n### Who resolves discoveries (not you)\n- The **human** resolves a discovery via \\`resolve_discovery\\` **in the SpecForge web app**\n  — that is what unblocks a blocking discovery (\\`blocked → pending\\`; the readiness\n  cascade re-derives it \\`→ ready\\`). \\`resolve_discovery\\` is NOT a tool you can call.\n- The **sfag-work-resolver** chat agent triages recorded discoveries with the human and\n  converts the worthwhile ones into tickets/epics.\n- Your only discovery-side follow-ups are audit acks: \\`update_discovery\\` (correct a\n  field) and \\`set_discovery_resolved\\` (record that you handled it). Neither unblocks a ticket.\n\n### Resuming after a resolution\nWhen a blocked ticket is back to \\`ready\\`, call \\`start_work_session\\` on it again. SWS\n**re-attaches** the paused session (\\`paused → active\\`) and delivers the human's resolution\nas a one-shot in the orientation — apply it (e.g. rework a rejected justification via the\nmatching \\`amend_*\\` action), then continue. Re-work is always a fresh SWS on a \\`ready\\`\nticket — never a reset.\n\n### Rules for discoveries\n- **The blocking discovery IS the block.** Never look for a separate block verb.\n- **Don't fix tech debt or improvements mid-ticket.** Record them, stay in scope.\n- **Be specific.** \"Code is messy\" is not a discovery. \"UserService mixes auth and profile\n  concerns across 3 methods (src/services/user.ts:1-400)\" is.\n\n## What You Are NOT\n\n- You are NOT a code tutor. Don't explain what a function does unless asked.\n- You are NOT an architect. The spec and patterns are decided. Follow them.\n- You are NOT a reviewer or a resolver. You RECORD discoveries; the human + the\n  work-resolver agent decide their fate. Implement, record, complete, move on.\n- You are NOT creative. The ticket tells you what to build. Build exactly that.\n\n## Quality Gate (self-check before complete_work_session)\n\n- [ ] Worktree was clean before start_work_session (no \\`git_dirty\\` denial)\n- [ ] If running in parallel: passed your \\`worktree\\` path to start_work_session AND complete_work_session\n- [ ] All implementation steps marked done via mark_implementation_step_completion\n- [ ] Tests run and recorded via record_test_result; every skip/failure justified\n- [ ] Every touched/divergent file recorded via record_file_change; divergences justified\n- [ ] All acceptance criteria checked via mark_acceptance_check, with evidence\n- [ ] Worked the dimensions in order: Implementation steps → Tests → Files → Acceptance criteria\n- [ ] Read the assay guidance/coherence each call and acted on it\n- [ ] Work committed (CWS needs git evidence)\n- [ ] Every blocker/discovery RECORDED (create_discovery) — none left unreported, none resolved by you\n- [ ] No scope creep — you built what the ticket asked, nothing more\n`,\n};\n"],"mappings":"AA4BO,MAAM,0BAAyC;AAAA,EACpD,MAAM;AAAA,EACN,aAAa;AAAA,EACb,oBAAoB;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAmBpB,OAAO;AAAA,EACP,OAAO;AAAA,EACP,UAAU;AAAA,EACV,QAAQ;AAAA,EACR,SAAS;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAsTX;","names":[]}

package/dist/tools/core/git-injection.d.ts

@@ -1,7 +1,21 @@
-/** Runs a `git` sub-command; returns trimmed stdout, or `null` on any failure. */
-export type GitRunner = (args: string[]) => string | null;
-/** Default runner: spawn `git`, return trimmed stdout, `null` on any failure. */
+/**
+ * Runs a `git` sub-command; returns trimmed stdout, or `null` on any failure.
+ * `cwd` (MB.45) selects the worktree the command resolves against — omitted, git
+ * runs in the MCP server's `process.cwd()`. An in-process worker fleet shares ONE
+ * server (ONE cwd), so a per-call `cwd` is the only way each worker's git-evidence
+ * binds to ITS worktree rather than the launcher's (feedback c1537bdc).
+ */
+export type GitRunner = (args: string[], cwd?: string) => string | null;
+/** Default runner: spawn `git` (optionally in `cwd`), trimmed stdout, `null` on any failure. */
 export declare const defaultGitRunner: GitRunner;
+/**
+ * Bind a `GitRunner` to a worktree `cwd` (MB.45). The SWS/CWS tool handlers pass the
+ * worker's `worktree` arg here so every git read (`readWorktreeGitEvidence`,
+ * `readHeadCommitSha`) resolves in THAT worktree, not the shared server cwd. Returns
+ * `base` UNCHANGED when `cwd` is absent (the historical process.cwd() behavior), so a
+ * non-fleet / repo-less caller is unaffected. `base` is injectable for tests.
+ */
+export declare function makeGitRunner(cwd?: string, base?: GitRunner): GitRunner;
 export interface WorktreeGitEvidence {
     /**
      * `true` when the worktree has no uncommitted changes — OR when the caller is

package/dist/tools/core/git-injection.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"git-injection.d.ts","sourceRoot":"","sources":["../../../src/tools/core/git-injection.ts"],"names":[],"mappings":"AA2BA,kFAAkF;AAClF,MAAM,MAAM,SAAS,GAAG,CAAC,IAAI,EAAE,MAAM,EAAE,KAAK,MAAM,GAAG,IAAI,CAAC;AAE1D,iFAAiF;AACjF,eAAO,MAAM,gBAAgB,EAAE,SAU9B,CAAC;AAEF,MAAM,WAAW,mBAAmB;IAClC;;;OAGG;IACH,QAAQ,EAAE,OAAO,CAAC;IAClB,sFAAsF;IACtF,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,yFAAyF;IACzF,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;CACvB;AAED;;;;GAIG;AACH,wBAAgB,uBAAuB,CAAC,GAAG,GAAE,SAA4B,GAAG,mBAAmB,CAc9F;AAED;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAAC,GAAG,GAAE,SAA4B,GAAG,MAAM,GAAG,IAAI,CAGlF;AAED,0FAA0F;AAC1F,MAAM,WAAW,qBAAqB;IACpC,MAAM,EAAE,oBAAoB,CAAC;IAC7B,aAAa,EAAE,MAAM,CAAC;IACtB,QAAQ,EAAE,MAAM,CAAC;IACjB,YAAY,EAAE,MAAM,CAAC;IACrB,cAAc,EAAE,QAAQ,GAAG,QAAQ,GAAG,QAAQ,CAAC;IAC/C,YAAY,EAAE,SAAS,GAAG,UAAU,GAAG,SAAS,CAAC;IACjD,MAAM,EAAE,SAAS,CAAC;CACnB;AAED,UAAU,SAAS;IACjB,aAAa,EAAE,MAAM,CAAC;IACtB,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED;;;;;GAKG;AACH,wBAAgB,sBAAsB,CACpC,eAAe,EAAE,MAAM,GAAG,IAAI,EAC9B,GAAG,EAAE,SAAS,GACb,qBAAqB,EAAE,CA4BzB;AAED;;;;GAIG;AACH,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,SAAS,EAAE,GAAG,GAAE,SAA4B,GAAG,qBAAqB,EAAE,CAE/G"}
+{"version":3,"file":"git-injection.d.ts","sourceRoot":"","sources":["../../../src/tools/core/git-injection.ts"],"names":[],"mappings":"AA2BA;;;;;;GAMG;AACH,MAAM,MAAM,SAAS,GAAG,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,GAAG,CAAC,EAAE,MAAM,KAAK,MAAM,GAAG,IAAI,CAAC;AAExE,gGAAgG;AAChG,eAAO,MAAM,gBAAgB,EAAE,SAc9B,CAAC;AAEF;;;;;;GAMG;AACH,wBAAgB,aAAa,CAAC,GAAG,CAAC,EAAE,MAAM,EAAE,IAAI,GAAE,SAA4B,GAAG,SAAS,CAGzF;AAED,MAAM,WAAW,mBAAmB;IAClC;;;OAGG;IACH,QAAQ,EAAE,OAAO,CAAC;IAClB,sFAAsF;IACtF,YAAY,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,yFAAyF;IACzF,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;CACvB;AAED;;;;GAIG;AACH,wBAAgB,uBAAuB,CAAC,GAAG,GAAE,SAA4B,GAAG,mBAAmB,CAc9F;AAED;;;;;;GAMG;AACH,wBAAgB,iBAAiB,CAAC,GAAG,GAAE,SAA4B,GAAG,MAAM,GAAG,IAAI,CAGlF;AAED,0FAA0F;AAC1F,MAAM,WAAW,qBAAqB;IACpC,MAAM,EAAE,oBAAoB,CAAC;IAC7B,aAAa,EAAE,MAAM,CAAC;IACtB,QAAQ,EAAE,MAAM,CAAC;IACjB,YAAY,EAAE,MAAM,CAAC;IACrB,cAAc,EAAE,QAAQ,GAAG,QAAQ,GAAG,QAAQ,CAAC;IAC/C,YAAY,EAAE,SAAS,GAAG,UAAU,GAAG,SAAS,CAAC;IACjD,MAAM,EAAE,SAAS,CAAC;CACnB;AAED,UAAU,SAAS;IACjB,aAAa,EAAE,MAAM,CAAC;IACtB,QAAQ,EAAE,MAAM,CAAC;CAClB;AAED;;;;;GAKG;AACH,wBAAgB,sBAAsB,CACpC,eAAe,EAAE,MAAM,GAAG,IAAI,EAC9B,GAAG,EAAE,SAAS,GACb,qBAAqB,EAAE,CA4BzB;AAED;;;;GAIG;AACH,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,SAAS,EAAE,GAAG,GAAE,SAA4B,GAAG,qBAAqB,EAAE,CAE/G"}

package/dist/tools/core/git-injection.js

@@ -1,15 +1,23 @@
 import { execFileSync } from "node:child_process";
-const defaultGitRunner = (args) => {
+const defaultGitRunner = (args, cwd) => {
   try {
     const out = execFileSync("git", args, {
       encoding: "utf8",
-      stdio: ["ignore", "pipe", "ignore"]
+      stdio: ["ignore", "pipe", "ignore"],
+      // A non-existent `cwd` makes execFileSync throw (ENOENT) → caught → null, which
+      // the readers treat as "not in a worktree". Omit the key entirely when unset so
+      // the default process.cwd() behavior is byte-identical to before MB.45.
+      ...cwd !== void 0 && cwd !== "" && { cwd }
     });
     return out.trim();
   } catch {
     return null;
   }
 };
+function makeGitRunner(cwd, base = defaultGitRunner) {
+  if (cwd === void 0 || cwd === "") return base;
+  return (args) => base(args, cwd);
+}
 function readWorktreeGitEvidence(run = defaultGitRunner) {
   const worktreePath = run(["rev-parse", "--show-toplevel"]);
   if (worktreePath === null || worktreePath === "") {
@@ -72,6 +80,7 @@ function classifyPorcelain(xy) {
 export {
   defaultGitRunner,
   deriveLocalFileChanges,
+  makeGitRunner,
   readHeadCommitSha,
   readLocalFileChanges,
   readWorktreeGitEvidence

package/dist/tools/core/git-injection.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../../../src/tools/core/git-injection.ts"],"sourcesContent":["/**\n * MCP-local git-evidence injection (M23.2).\n *\n * The work lifecycle's SWS/AWS verbs need worktree git evidence that only the\n * MCP-LOCAL (this CLI, running on the agent's machine — the deployed Lambda has\n * NO worktree) can observe. Per `docs/architecture/work-lifecycle-flow.md` §0 +\n * [[project_coherence_score]]:\n *\n *  - **SWS** (`start_work_session`): runs `git status` for the clean-workspace\n *    precondition (`gitClean`) and reports the worktree provenance —\n *    `worktreePath` via `git rev-parse --show-toplevel` + `branch` via\n *    `git rev-parse --abbrev-ref HEAD` — so SWS persists\n *    `WorkSession.worktreePath`/`branch` (M16.2). When the agent is NOT inside a\n *    git worktree (\"caso esteja em uma\") the provenance is `null` (SWS still\n *    records the WorkSession) and `gitClean` defaults to `true` (a non-git caller\n *    is never \"dirty\" — it must not be blocked by the precondition).\n *  - **AWS** (`action_work_session`, `validateFiles: 'local'`): runs\n *    `git status --porcelain` and injects one `record_file_change` action per\n *    created/modified/deleted file (the agent only reports the `referenced`\n *    files git cannot see).\n *\n * The git commands run through an injectable `GitRunner` (defaults to a real,\n * non-throwing `git` spawn) so the layer is unit-testable without a live repo and\n * never throws inside a tool handler.\n */\nimport { execFileSync } from 'node:child_process';\n\n/** Runs a `git` sub-command; returns trimmed stdout, or `null` on any failure. */\nexport type GitRunner = (args: string[]) => string | null;\n\n/** Default runner: spawn `git`, return trimmed stdout, `null` on any failure. */\nexport const defaultGitRunner: GitRunner = (args) => {\n  try {\n    const out = execFileSync('git', args, {\n      encoding: 'utf8',\n      stdio: ['ignore', 'pipe', 'ignore'],\n    });\n    return out.trim();\n  } catch {\n    return null;\n  }\n};\n\nexport interface WorktreeGitEvidence {\n  /**\n   * `true` when the worktree has no uncommitted changes — OR when the caller is\n   * not inside a git repo (a non-git caller is never \"dirty\", so SWS still runs).\n   */\n  gitClean: boolean;\n  /** Worktree root (`git rev-parse --show-toplevel`); `null` when not in a worktree. */\n  worktreePath: string | null;\n  /** Current branch (`git rev-parse --abbrev-ref HEAD`); `null` when not in a worktree. */\n  branch: string | null;\n}\n\n/**\n * SWS git evidence — the clean-status precondition input + the worktree\n * provenance (M23.2). Emits `null` provenance (and `gitClean: true`) when the\n * agent is not inside a git worktree, so SWS still records the WorkSession.\n */\nexport function readWorktreeGitEvidence(run: GitRunner = defaultGitRunner): WorktreeGitEvidence {\n  const worktreePath = run(['rev-parse', '--show-toplevel']);\n  if (worktreePath === null || worktreePath === '') {\n    // Not inside a git worktree — SWS still records the WorkSession.\n    return { gitClean: true, worktreePath: null, branch: null };\n  }\n  const branch = run(['rev-parse', '--abbrev-ref', 'HEAD']);\n  const status = run(['status', '--porcelain']);\n  return {\n    // A failed `git status` (null) must not block SWS → treat as clean.\n    gitClean: status === null ? true : status.trim() === '',\n    worktreePath,\n    branch: branch === null || branch === '' ? null : branch,\n  };\n}\n\n/**\n * The worktree HEAD commit hash (`git rev-parse HEAD`), or `null` when not inside a\n * git worktree or the repo has no commit yet. The MCP-local reads this on\n * `complete_work_session` and binds it as `WorkSession.commitSha` — the per-session\n * commit proof the CWS git-evidence gate requires to finalize (M23.2). The deployed\n * Lambda has no worktree, so only this CLI can observe it.\n */\nexport function readHeadCommitSha(run: GitRunner = defaultGitRunner): string | null {\n  const sha = run(['rev-parse', 'HEAD']);\n  return sha === null || sha === '' ? null : sha;\n}\n\n/** One injected file-change action (a subset of the AWS `record_file_change` payload). */\nexport interface LocalFileChangeAction {\n  action: 'record_file_change';\n  workSessionId: string;\n  ticketId: string;\n  expectedPath: string;\n  expectedAction: 'create' | 'modify' | 'delete';\n  actualAction: 'created' | 'modified' | 'deleted';\n  status: 'matched';\n}\n\ninterface DeriveCtx {\n  workSessionId: string;\n  ticketId: string;\n}\n\n/**\n * Parse `git status --porcelain` into the `record_file_change` set the MCP-local\n * injects in `validateFiles: 'local'` mode — one action per created/modified/\n * deleted path (the agent reports the `referenced` files itself). A rename (`R`)\n * surfaces as a create of the new path.\n */\nexport function deriveLocalFileChanges(\n  statusPorcelain: string | null,\n  ctx: DeriveCtx,\n): LocalFileChangeAction[] {\n  if (!statusPorcelain) return [];\n  const actions: LocalFileChangeAction[] = [];\n  for (const raw of statusPorcelain.split('\\n')) {\n    const line = raw.replace(/\\r$/, '');\n    if (line.trim() === '') continue;\n    // porcelain v1: `XY<space>path` — XY is the 2-char status, path starts at col 3.\n    const xy = line.slice(0, 2);\n    let path = line.slice(3).trim();\n    // Rename/copy renders as `old -> new`; record the new path.\n    const arrow = path.indexOf(' -> ');\n    if (arrow >= 0) path = path.slice(arrow + 4).trim();\n    // git quotes paths with special chars.\n    if (path.startsWith('\"') && path.endsWith('\"')) path = path.slice(1, -1);\n    if (path === '') continue;\n    const kind = classifyPorcelain(xy);\n    if (!kind) continue;\n    actions.push({\n      action: 'record_file_change',\n      workSessionId: ctx.workSessionId,\n      ticketId: ctx.ticketId,\n      expectedPath: path,\n      expectedAction: kind.expected,\n      actualAction: kind.actual,\n      status: 'matched',\n    });\n  }\n  return actions;\n}\n\n/**\n * Read the worktree's changed-file set (`git status --porcelain`) and map it to\n * the `record_file_change` actions the MCP-local injects (AWS `validateFiles:\n * 'local'`). Empty when not inside a git worktree.\n */\nexport function readLocalFileChanges(ctx: DeriveCtx, run: GitRunner = defaultGitRunner): LocalFileChangeAction[] {\n  return deriveLocalFileChanges(run(['status', '--porcelain']), ctx);\n}\n\nfunction classifyPorcelain(\n  xy: string,\n): { expected: 'create' | 'modify' | 'delete'; actual: 'created' | 'modified' | 'deleted' } | null {\n  const s = xy.trim();\n  if (s === '') return null;\n  // Untracked / added / renamed / copied → a new (created) file.\n  if (s === '??' || s.includes('A') || s.includes('R') || s.includes('C')) {\n    return { expected: 'create', actual: 'created' };\n  }\n  if (s.includes('D')) return { expected: 'delete', actual: 'deleted' };\n  if (s.includes('M') || s.includes('T') || s.includes('U')) {\n    return { expected: 'modify', actual: 'modified' };\n  }\n  return null;\n}\n"],"mappings":"AAyBA,SAAS,oBAAoB;AAMtB,MAAM,mBAA8B,CAAC,SAAS;AACnD,MAAI;AACF,UAAM,MAAM,aAAa,OAAO,MAAM;AAAA,MACpC,UAAU;AAAA,MACV,OAAO,CAAC,UAAU,QAAQ,QAAQ;AAAA,IACpC,CAAC;AACD,WAAO,IAAI,KAAK;AAAA,EAClB,QAAQ;AACN,WAAO;AAAA,EACT;AACF;AAmBO,SAAS,wBAAwB,MAAiB,kBAAuC;AAC9F,QAAM,eAAe,IAAI,CAAC,aAAa,iBAAiB,CAAC;AACzD,MAAI,iBAAiB,QAAQ,iBAAiB,IAAI;AAEhD,WAAO,EAAE,UAAU,MAAM,cAAc,MAAM,QAAQ,KAAK;AAAA,EAC5D;AACA,QAAM,SAAS,IAAI,CAAC,aAAa,gBAAgB,MAAM,CAAC;AACxD,QAAM,SAAS,IAAI,CAAC,UAAU,aAAa,CAAC;AAC5C,SAAO;AAAA;AAAA,IAEL,UAAU,WAAW,OAAO,OAAO,OAAO,KAAK,MAAM;AAAA,IACrD;AAAA,IACA,QAAQ,WAAW,QAAQ,WAAW,KAAK,OAAO;AAAA,EACpD;AACF;AASO,SAAS,kBAAkB,MAAiB,kBAAiC;AAClF,QAAM,MAAM,IAAI,CAAC,aAAa,MAAM,CAAC;AACrC,SAAO,QAAQ,QAAQ,QAAQ,KAAK,OAAO;AAC7C;AAwBO,SAAS,uBACd,iBACA,KACyB;AACzB,MAAI,CAAC,gBAAiB,QAAO,CAAC;AAC9B,QAAM,UAAmC,CAAC;AAC1C,aAAW,OAAO,gBAAgB,MAAM,IAAI,GAAG;AAC7C,UAAM,OAAO,IAAI,QAAQ,OAAO,EAAE;AAClC,QAAI,KAAK,KAAK,MAAM,GAAI;AAExB,UAAM,KAAK,KAAK,MAAM,GAAG,CAAC;AAC1B,QAAI,OAAO,KAAK,MAAM,CAAC,EAAE,KAAK;AAE9B,UAAM,QAAQ,KAAK,QAAQ,MAAM;AACjC,QAAI,SAAS,EAAG,QAAO,KAAK,MAAM,QAAQ,CAAC,EAAE,KAAK;AAElD,QAAI,KAAK,WAAW,GAAG,KAAK,KAAK,SAAS,GAAG,EAAG,QAAO,KAAK,MAAM,GAAG,EAAE;AACvE,QAAI,SAAS,GAAI;AACjB,UAAM,OAAO,kBAAkB,EAAE;AACjC,QAAI,CAAC,KAAM;AACX,YAAQ,KAAK;AAAA,MACX,QAAQ;AAAA,MACR,eAAe,IAAI;AAAA,MACnB,UAAU,IAAI;AAAA,MACd,cAAc;AAAA,MACd,gBAAgB,KAAK;AAAA,MACrB,cAAc,KAAK;AAAA,MACnB,QAAQ;AAAA,IACV,CAAC;AAAA,EACH;AACA,SAAO;AACT;AAOO,SAAS,qBAAqB,KAAgB,MAAiB,kBAA2C;AAC/G,SAAO,uBAAuB,IAAI,CAAC,UAAU,aAAa,CAAC,GAAG,GAAG;AACnE;AAEA,SAAS,kBACP,IACiG;AACjG,QAAM,IAAI,GAAG,KAAK;AAClB,MAAI,MAAM,GAAI,QAAO;AAErB,MAAI,MAAM,QAAQ,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,GAAG;AACvE,WAAO,EAAE,UAAU,UAAU,QAAQ,UAAU;AAAA,EACjD;AACA,MAAI,EAAE,SAAS,GAAG,EAAG,QAAO,EAAE,UAAU,UAAU,QAAQ,UAAU;AACpE,MAAI,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,GAAG;AACzD,WAAO,EAAE,UAAU,UAAU,QAAQ,WAAW;AAAA,EAClD;AACA,SAAO;AACT;","names":[]}
+{"version":3,"sources":["../../../src/tools/core/git-injection.ts"],"sourcesContent":["/**\n * MCP-local git-evidence injection (M23.2).\n *\n * The work lifecycle's SWS/AWS verbs need worktree git evidence that only the\n * MCP-LOCAL (this CLI, running on the agent's machine — the deployed Lambda has\n * NO worktree) can observe. Per `docs/architecture/work-lifecycle-flow.md` §0 +\n * [[project_coherence_score]]:\n *\n *  - **SWS** (`start_work_session`): runs `git status` for the clean-workspace\n *    precondition (`gitClean`) and reports the worktree provenance —\n *    `worktreePath` via `git rev-parse --show-toplevel` + `branch` via\n *    `git rev-parse --abbrev-ref HEAD` — so SWS persists\n *    `WorkSession.worktreePath`/`branch` (M16.2). When the agent is NOT inside a\n *    git worktree (\"caso esteja em uma\") the provenance is `null` (SWS still\n *    records the WorkSession) and `gitClean` defaults to `true` (a non-git caller\n *    is never \"dirty\" — it must not be blocked by the precondition).\n *  - **AWS** (`action_work_session`, `validateFiles: 'local'`): runs\n *    `git status --porcelain` and injects one `record_file_change` action per\n *    created/modified/deleted file (the agent only reports the `referenced`\n *    files git cannot see).\n *\n * The git commands run through an injectable `GitRunner` (defaults to a real,\n * non-throwing `git` spawn) so the layer is unit-testable without a live repo and\n * never throws inside a tool handler.\n */\nimport { execFileSync } from 'node:child_process';\n\n/**\n * Runs a `git` sub-command; returns trimmed stdout, or `null` on any failure.\n * `cwd` (MB.45) selects the worktree the command resolves against — omitted, git\n * runs in the MCP server's `process.cwd()`. An in-process worker fleet shares ONE\n * server (ONE cwd), so a per-call `cwd` is the only way each worker's git-evidence\n * binds to ITS worktree rather than the launcher's (feedback c1537bdc).\n */\nexport type GitRunner = (args: string[], cwd?: string) => string | null;\n\n/** Default runner: spawn `git` (optionally in `cwd`), trimmed stdout, `null` on any failure. */\nexport const defaultGitRunner: GitRunner = (args, cwd) => {\n  try {\n    const out = execFileSync('git', args, {\n      encoding: 'utf8',\n      stdio: ['ignore', 'pipe', 'ignore'],\n      // A non-existent `cwd` makes execFileSync throw (ENOENT) → caught → null, which\n      // the readers treat as \"not in a worktree\". Omit the key entirely when unset so\n      // the default process.cwd() behavior is byte-identical to before MB.45.\n      ...(cwd !== undefined && cwd !== '' && { cwd }),\n    });\n    return out.trim();\n  } catch {\n    return null;\n  }\n};\n\n/**\n * Bind a `GitRunner` to a worktree `cwd` (MB.45). The SWS/CWS tool handlers pass the\n * worker's `worktree` arg here so every git read (`readWorktreeGitEvidence`,\n * `readHeadCommitSha`) resolves in THAT worktree, not the shared server cwd. Returns\n * `base` UNCHANGED when `cwd` is absent (the historical process.cwd() behavior), so a\n * non-fleet / repo-less caller is unaffected. `base` is injectable for tests.\n */\nexport function makeGitRunner(cwd?: string, base: GitRunner = defaultGitRunner): GitRunner {\n  if (cwd === undefined || cwd === '') return base;\n  return (args) => base(args, cwd);\n}\n\nexport interface WorktreeGitEvidence {\n  /**\n   * `true` when the worktree has no uncommitted changes — OR when the caller is\n   * not inside a git repo (a non-git caller is never \"dirty\", so SWS still runs).\n   */\n  gitClean: boolean;\n  /** Worktree root (`git rev-parse --show-toplevel`); `null` when not in a worktree. */\n  worktreePath: string | null;\n  /** Current branch (`git rev-parse --abbrev-ref HEAD`); `null` when not in a worktree. */\n  branch: string | null;\n}\n\n/**\n * SWS git evidence — the clean-status precondition input + the worktree\n * provenance (M23.2). Emits `null` provenance (and `gitClean: true`) when the\n * agent is not inside a git worktree, so SWS still records the WorkSession.\n */\nexport function readWorktreeGitEvidence(run: GitRunner = defaultGitRunner): WorktreeGitEvidence {\n  const worktreePath = run(['rev-parse', '--show-toplevel']);\n  if (worktreePath === null || worktreePath === '') {\n    // Not inside a git worktree — SWS still records the WorkSession.\n    return { gitClean: true, worktreePath: null, branch: null };\n  }\n  const branch = run(['rev-parse', '--abbrev-ref', 'HEAD']);\n  const status = run(['status', '--porcelain']);\n  return {\n    // A failed `git status` (null) must not block SWS → treat as clean.\n    gitClean: status === null ? true : status.trim() === '',\n    worktreePath,\n    branch: branch === null || branch === '' ? null : branch,\n  };\n}\n\n/**\n * The worktree HEAD commit hash (`git rev-parse HEAD`), or `null` when not inside a\n * git worktree or the repo has no commit yet. The MCP-local reads this on\n * `complete_work_session` and binds it as `WorkSession.commitSha` — the per-session\n * commit proof the CWS git-evidence gate requires to finalize (M23.2). The deployed\n * Lambda has no worktree, so only this CLI can observe it.\n */\nexport function readHeadCommitSha(run: GitRunner = defaultGitRunner): string | null {\n  const sha = run(['rev-parse', 'HEAD']);\n  return sha === null || sha === '' ? null : sha;\n}\n\n/** One injected file-change action (a subset of the AWS `record_file_change` payload). */\nexport interface LocalFileChangeAction {\n  action: 'record_file_change';\n  workSessionId: string;\n  ticketId: string;\n  expectedPath: string;\n  expectedAction: 'create' | 'modify' | 'delete';\n  actualAction: 'created' | 'modified' | 'deleted';\n  status: 'matched';\n}\n\ninterface DeriveCtx {\n  workSessionId: string;\n  ticketId: string;\n}\n\n/**\n * Parse `git status --porcelain` into the `record_file_change` set the MCP-local\n * injects in `validateFiles: 'local'` mode — one action per created/modified/\n * deleted path (the agent reports the `referenced` files itself). A rename (`R`)\n * surfaces as a create of the new path.\n */\nexport function deriveLocalFileChanges(\n  statusPorcelain: string | null,\n  ctx: DeriveCtx,\n): LocalFileChangeAction[] {\n  if (!statusPorcelain) return [];\n  const actions: LocalFileChangeAction[] = [];\n  for (const raw of statusPorcelain.split('\\n')) {\n    const line = raw.replace(/\\r$/, '');\n    if (line.trim() === '') continue;\n    // porcelain v1: `XY<space>path` — XY is the 2-char status, path starts at col 3.\n    const xy = line.slice(0, 2);\n    let path = line.slice(3).trim();\n    // Rename/copy renders as `old -> new`; record the new path.\n    const arrow = path.indexOf(' -> ');\n    if (arrow >= 0) path = path.slice(arrow + 4).trim();\n    // git quotes paths with special chars.\n    if (path.startsWith('\"') && path.endsWith('\"')) path = path.slice(1, -1);\n    if (path === '') continue;\n    const kind = classifyPorcelain(xy);\n    if (!kind) continue;\n    actions.push({\n      action: 'record_file_change',\n      workSessionId: ctx.workSessionId,\n      ticketId: ctx.ticketId,\n      expectedPath: path,\n      expectedAction: kind.expected,\n      actualAction: kind.actual,\n      status: 'matched',\n    });\n  }\n  return actions;\n}\n\n/**\n * Read the worktree's changed-file set (`git status --porcelain`) and map it to\n * the `record_file_change` actions the MCP-local injects (AWS `validateFiles:\n * 'local'`). Empty when not inside a git worktree.\n */\nexport function readLocalFileChanges(ctx: DeriveCtx, run: GitRunner = defaultGitRunner): LocalFileChangeAction[] {\n  return deriveLocalFileChanges(run(['status', '--porcelain']), ctx);\n}\n\nfunction classifyPorcelain(\n  xy: string,\n): { expected: 'create' | 'modify' | 'delete'; actual: 'created' | 'modified' | 'deleted' } | null {\n  const s = xy.trim();\n  if (s === '') return null;\n  // Untracked / added / renamed / copied → a new (created) file.\n  if (s === '??' || s.includes('A') || s.includes('R') || s.includes('C')) {\n    return { expected: 'create', actual: 'created' };\n  }\n  if (s.includes('D')) return { expected: 'delete', actual: 'deleted' };\n  if (s.includes('M') || s.includes('T') || s.includes('U')) {\n    return { expected: 'modify', actual: 'modified' };\n  }\n  return null;\n}\n"],"mappings":"AAyBA,SAAS,oBAAoB;AAYtB,MAAM,mBAA8B,CAAC,MAAM,QAAQ;AACxD,MAAI;AACF,UAAM,MAAM,aAAa,OAAO,MAAM;AAAA,MACpC,UAAU;AAAA,MACV,OAAO,CAAC,UAAU,QAAQ,QAAQ;AAAA;AAAA;AAAA;AAAA,MAIlC,GAAI,QAAQ,UAAa,QAAQ,MAAM,EAAE,IAAI;AAAA,IAC/C,CAAC;AACD,WAAO,IAAI,KAAK;AAAA,EAClB,QAAQ;AACN,WAAO;AAAA,EACT;AACF;AASO,SAAS,cAAc,KAAc,OAAkB,kBAA6B;AACzF,MAAI,QAAQ,UAAa,QAAQ,GAAI,QAAO;AAC5C,SAAO,CAAC,SAAS,KAAK,MAAM,GAAG;AACjC;AAmBO,SAAS,wBAAwB,MAAiB,kBAAuC;AAC9F,QAAM,eAAe,IAAI,CAAC,aAAa,iBAAiB,CAAC;AACzD,MAAI,iBAAiB,QAAQ,iBAAiB,IAAI;AAEhD,WAAO,EAAE,UAAU,MAAM,cAAc,MAAM,QAAQ,KAAK;AAAA,EAC5D;AACA,QAAM,SAAS,IAAI,CAAC,aAAa,gBAAgB,MAAM,CAAC;AACxD,QAAM,SAAS,IAAI,CAAC,UAAU,aAAa,CAAC;AAC5C,SAAO;AAAA;AAAA,IAEL,UAAU,WAAW,OAAO,OAAO,OAAO,KAAK,MAAM;AAAA,IACrD;AAAA,IACA,QAAQ,WAAW,QAAQ,WAAW,KAAK,OAAO;AAAA,EACpD;AACF;AASO,SAAS,kBAAkB,MAAiB,kBAAiC;AAClF,QAAM,MAAM,IAAI,CAAC,aAAa,MAAM,CAAC;AACrC,SAAO,QAAQ,QAAQ,QAAQ,KAAK,OAAO;AAC7C;AAwBO,SAAS,uBACd,iBACA,KACyB;AACzB,MAAI,CAAC,gBAAiB,QAAO,CAAC;AAC9B,QAAM,UAAmC,CAAC;AAC1C,aAAW,OAAO,gBAAgB,MAAM,IAAI,GAAG;AAC7C,UAAM,OAAO,IAAI,QAAQ,OAAO,EAAE;AAClC,QAAI,KAAK,KAAK,MAAM,GAAI;AAExB,UAAM,KAAK,KAAK,MAAM,GAAG,CAAC;AAC1B,QAAI,OAAO,KAAK,MAAM,CAAC,EAAE,KAAK;AAE9B,UAAM,QAAQ,KAAK,QAAQ,MAAM;AACjC,QAAI,SAAS,EAAG,QAAO,KAAK,MAAM,QAAQ,CAAC,EAAE,KAAK;AAElD,QAAI,KAAK,WAAW,GAAG,KAAK,KAAK,SAAS,GAAG,EAAG,QAAO,KAAK,MAAM,GAAG,EAAE;AACvE,QAAI,SAAS,GAAI;AACjB,UAAM,OAAO,kBAAkB,EAAE;AACjC,QAAI,CAAC,KAAM;AACX,YAAQ,KAAK;AAAA,MACX,QAAQ;AAAA,MACR,eAAe,IAAI;AAAA,MACnB,UAAU,IAAI;AAAA,MACd,cAAc;AAAA,MACd,gBAAgB,KAAK;AAAA,MACrB,cAAc,KAAK;AAAA,MACnB,QAAQ;AAAA,IACV,CAAC;AAAA,EACH;AACA,SAAO;AACT;AAOO,SAAS,qBAAqB,KAAgB,MAAiB,kBAA2C;AAC/G,SAAO,uBAAuB,IAAI,CAAC,UAAU,aAAa,CAAC,GAAG,GAAG;AACnE;AAEA,SAAS,kBACP,IACiG;AACjG,QAAM,IAAI,GAAG,KAAK;AAClB,MAAI,MAAM,GAAI,QAAO;AAErB,MAAI,MAAM,QAAQ,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,GAAG;AACvE,WAAO,EAAE,UAAU,UAAU,QAAQ,UAAU;AAAA,EACjD;AACA,MAAI,EAAE,SAAS,GAAG,EAAG,QAAO,EAAE,UAAU,UAAU,QAAQ,UAAU;AACpE,MAAI,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,KAAK,EAAE,SAAS,GAAG,GAAG;AACzD,WAAO,EAAE,UAAU,UAAU,QAAQ,WAAW;AAAA,EAClD;AACA,SAAO;AACT;","names":[]}

package/dist/tools/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/tools/index.ts"],"names":[],"mappings":"AACA;;;;;GAKG;AAEH,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AACpD,OAAO,EAML,gBAAgB,EACjB,MAAM,wBAAwB,CAAC;AAUhC;;GAEG;AACH,MAAM,WAAW,IAAI;IACnB,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,WAAW,EAAE;QACX,IAAI,EAAE,QAAQ,CAAC;QACf,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;QACpC,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;KACrB,CAAC;CACH;AAED;;;;GAIG;AACH,wBAAgB,QAAQ,IAAI,IAAI,EAAE,CAiiCjC;AAED;;GAEG;AACH,KAAK,WAAW,GAAG,CACjB,SAAS,EAAE,SAAS,EACpB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,KAC1B,OAAO,CAAC,OAAO,CAAC,CAAC;AA6EtB;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAChC,SAAS,EAAE,SAAS,GACnB,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,CAqU7B;AAiBD;;GAEG;AACH,wBAAgB,iBAAiB,IAAI,IAAI,CAExC;AAED;;;;;;;;GAQG;AACH,wBAAsB,cAAc,CAClC,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,MAAM,EAChB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC7B,KAAK,GAAE,OAAe,GACrB,OAAO,CAAC,OAAO,CAAC,CA4DlB;AAED;;;GAGG;AACH,wBAAsB,kBAAkB,CACtC,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,MAAM,EAChB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC7B,KAAK,GAAE,OAAe,GACrB,OAAO,CAAC,OAAO,GAAG,gBAAgB,CAAC,CAOrC;AAGD,OAAO,EACL,eAAe,EACf,QAAQ,EACR,gBAAgB,EAChB,cAAc,EACd,cAAc,EACd,KAAK,gBAAgB,GACtB,MAAM,wBAAwB,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/tools/index.ts"],"names":[],"mappings":"AACA;;;;;GAKG;AAEH,OAAO,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AACpD,OAAO,EAML,gBAAgB,EACjB,MAAM,wBAAwB,CAAC;AAUhC;;GAEG;AACH,MAAM,WAAW,IAAI;IACnB,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;IACpB,WAAW,EAAE;QACX,IAAI,EAAE,QAAQ,CAAC;QACf,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;QACpC,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;KACrB,CAAC;CACH;AAED;;;;GAIG;AACH,wBAAgB,QAAQ,IAAI,IAAI,EAAE,CA2iCjC;AAED;;GAEG;AACH,KAAK,WAAW,GAAG,CACjB,SAAS,EAAE,SAAS,EACpB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,KAC1B,OAAO,CAAC,OAAO,CAAC,CAAC;AA6EtB;;;;;GAKG;AACH,wBAAgB,kBAAkB,CAChC,SAAS,EAAE,SAAS,GACnB,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,CAkV7B;AAiBD;;GAEG;AACH,wBAAgB,iBAAiB,IAAI,IAAI,CAExC;AAED;;;;;;;;GAQG;AACH,wBAAsB,cAAc,CAClC,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,MAAM,EAChB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC7B,KAAK,GAAE,OAAe,GACrB,OAAO,CAAC,OAAO,CAAC,CA4DlB;AAED;;;GAGG;AACH,wBAAsB,kBAAkB,CACtC,SAAS,EAAE,SAAS,EACpB,QAAQ,EAAE,MAAM,EAChB,IAAI,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC7B,KAAK,GAAE,OAAe,GACrB,OAAO,CAAC,OAAO,GAAG,gBAAgB,CAAC,CAOrC;AAGD,OAAO,EACL,eAAe,EACf,QAAQ,EACR,gBAAgB,EAChB,cAAc,EACd,cAAc,EACd,KAAK,gBAAgB,GACtB,MAAM,wBAAwB,CAAC"}

package/dist/tools/index.js

@@ -8,7 +8,7 @@ import {
 } from "../validation/index.js";
 import { injectContext, injectContextRequired } from "./core/context-helper.js";
 import { probeExistingFiles } from "./core/file-existence-injection.js";
-import { readWorktreeGitEvidence, readHeadCommitSha } from "./core/git-injection.js";
+import { readWorktreeGitEvidence, readHeadCommitSha, makeGitRunner } from "./core/git-injection.js";
 import { tryLoadProjectConfig, saveProjectConfig } from "../cli/config/index.js";
 import {
   appendPlanningSessionRegistry,
@@ -684,6 +684,10 @@ Format options:
           ticketId: {
             type: "string",
             description: "The ID of the ticket to start"
+          },
+          worktree: {
+            type: "string",
+            description: "Absolute path to THIS worker's git worktree. Pass it when running as one of several concurrent workers so the git evidence (clean status, branch, commit) is read from your worktree \u2014 not the shared MCP server directory. Each concurrent worker needs its OWN worktree; two active sessions in the same worktree are denied (concurrent_worktree). Omit when you run a single session in the current directory."
           }
         },
         required: ["ticketId"]
@@ -810,6 +814,10 @@ Set getTicket: true to fetch full ticket details in the response \u2014 useful f
             type: "string",
             description: "The ID of the ticket"
           },
+          worktree: {
+            type: "string",
+            description: "Absolute path to THIS worker's git worktree \u2014 pass the SAME value you passed to start_work_session so the commit hash is read from your worktree, not the shared MCP server directory. Omit for a single session in the current directory."
+          },
           summary: {
             type: "string",
             description: "Summary of work completed"
@@ -1265,7 +1273,8 @@ function createToolHandlers(apiClient) {
     },
     start_work_session: async (_client, args) => {
       validateRequired(args, "ticketId");
-      const git = readWorktreeGitEvidence();
+      const worktree = typeof args.worktree === "string" ? args.worktree : void 0;
+      const git = readWorktreeGitEvidence(makeGitRunner(worktree));
       return await callLocal("start_work_session", {
         ticketId: args.ticketId,
         gitClean: git.gitClean,
@@ -1282,7 +1291,8 @@ function createToolHandlers(apiClient) {
     },
     complete_work_session: async (_client, args) => {
       validateRequired(args, "ticketId", "summary");
-      const commitSha = readHeadCommitSha();
+      const worktree = typeof args.worktree === "string" ? args.worktree : void 0;
+      const commitSha = readHeadCommitSha(makeGitRunner(worktree));
       return await callLocal("complete_work_session", {
         ticketId: args.ticketId,
         summary: args.summary,