@specforge/canary-cli 0.1.9 → 0.1.11

package/dist/cli/commands/scaffold/agent-types.js

@@ -1,6 +1,6 @@
 const AGENT_CATEGORIES = {
   Orchestration: ["sfag-orchestrator"],
-  SpecForge: ["sfag-spec-creator", "sfag-ticket-implementer"],
+  SpecForge: ["sfag-spec-creator", "sfag-ticket-implementer", "sfag-work-resolver"],
   Research: ["sfag-package-researcher"]
 };
 function getAgentCategoryNames() {

package/dist/cli/commands/scaffold/agent-types.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../../../../src/cli/commands/scaffold/agent-types.ts"],"sourcesContent":["/**\n * Agent Scaffolding Types & Interfaces\n *\n * Type definitions for AI agent scaffolding in Claude Code and other AI tools.\n */\n\nexport type AgentCategory =\n  | 'Orchestration'\n  | 'SpecForge'\n  | 'Research';\n\n/**\n * Agent model options\n */\nexport type AgentModel = 'opus' | 'sonnet' | 'haiku';\n\n/**\n * Supported colors for agent display\n */\nexport type AgentColor =\n  | 'red'\n  | 'yellow'\n  | 'green'\n  | 'cyan'\n  | 'blue'\n  | 'magenta'\n  | 'white'\n  | 'gray';\n\n/**\n * Persistent memory scope for the agent. Maps to Claude Code's `memory:`\n * frontmatter field, which triggers Claude Code to inject the persistent\n * memory system prompt and create the matching agent-memory directory:\n *   - `project` → `.claude/agent-memory/<name>/`\n *   - `user`    → `~/.claude/agent-memory/<name>/`\n *   - `local`   → `.claude/agent-memory-local/<name>/`\n */\nexport type AgentMemory = 'project' | 'user' | 'local';\n\n/**\n * Agent template definition\n */\nexport interface AgentTemplate {\n  /** Agent name (e.g., 'sfag-orchestrator') */\n  name: string;\n  /** Short description for agent list */\n  description: string;\n  /** Full description with trigger examples for frontmatter */\n  triggerDescription: string;\n  /** AI model to use for this agent */\n  model: AgentModel;\n  /** Color for agent display */\n  color: AgentColor;\n  /** Full markdown content of the agent */\n  content: string;\n  /** Agent category for grouping */\n  category: AgentCategory;\n  /** Persistent memory scope (Claude Code only) */\n  memory?: AgentMemory;\n}\n\nexport const AGENT_CATEGORIES: Record<AgentCategory, string[]> = {\n  Orchestration: ['sfag-orchestrator'],\n  SpecForge: ['sfag-spec-creator', 'sfag-ticket-implementer'],\n  Research: ['sfag-package-researcher'],\n};\n\n/**\n * Get all agent category names\n */\nexport function getAgentCategoryNames(): AgentCategory[] {\n  return Object.keys(AGENT_CATEGORIES) as AgentCategory[];\n}\n\n/**\n * Model display badges for CLI output\n */\nexport const MODEL_BADGES: Record<AgentModel, string> = {\n  opus: '◆',    // Diamond for opus (powerful)\n  sonnet: '●',  // Circle for sonnet (balanced)\n  haiku: '○',   // Empty circle for haiku (fast)\n};\n"],"mappings":"AA6DO,MAAM,mBAAoD;AAAA,EAC/D,eAAe,CAAC,mBAAmB;AAAA,EACnC,WAAW,CAAC,qBAAqB,yBAAyB;AAAA,EAC1D,UAAU,CAAC,yBAAyB;AACtC;AAKO,SAAS,wBAAyC;AACvD,SAAO,OAAO,KAAK,gBAAgB;AACrC;AAKO,MAAM,eAA2C;AAAA,EACtD,MAAM;AAAA;AAAA,EACN,QAAQ;AAAA;AAAA,EACR,OAAO;AAAA;AACT;","names":[]}
+{"version":3,"sources":["../../../../src/cli/commands/scaffold/agent-types.ts"],"sourcesContent":["/**\n * Agent Scaffolding Types & Interfaces\n *\n * Type definitions for AI agent scaffolding in Claude Code and other AI tools.\n */\n\nexport type AgentCategory =\n  | 'Orchestration'\n  | 'SpecForge'\n  | 'Research';\n\n/**\n * Agent model options\n */\nexport type AgentModel = 'opus' | 'sonnet' | 'haiku';\n\n/**\n * Supported colors for agent display\n */\nexport type AgentColor =\n  | 'red'\n  | 'yellow'\n  | 'green'\n  | 'cyan'\n  | 'blue'\n  | 'magenta'\n  | 'white'\n  | 'gray';\n\n/**\n * Persistent memory scope for the agent. Maps to Claude Code's `memory:`\n * frontmatter field, which triggers Claude Code to inject the persistent\n * memory system prompt and create the matching agent-memory directory:\n *   - `project` → `.claude/agent-memory/<name>/`\n *   - `user`    → `~/.claude/agent-memory/<name>/`\n *   - `local`   → `.claude/agent-memory-local/<name>/`\n */\nexport type AgentMemory = 'project' | 'user' | 'local';\n\n/**\n * Agent template definition\n */\nexport interface AgentTemplate {\n  /** Agent name (e.g., 'sfag-orchestrator') */\n  name: string;\n  /** Short description for agent list */\n  description: string;\n  /** Full description with trigger examples for frontmatter */\n  triggerDescription: string;\n  /** AI model to use for this agent */\n  model: AgentModel;\n  /** Color for agent display */\n  color: AgentColor;\n  /** Full markdown content of the agent */\n  content: string;\n  /** Agent category for grouping */\n  category: AgentCategory;\n  /** Persistent memory scope (Claude Code only) */\n  memory?: AgentMemory;\n}\n\nexport const AGENT_CATEGORIES: Record<AgentCategory, string[]> = {\n  Orchestration: ['sfag-orchestrator'],\n  SpecForge: ['sfag-spec-creator', 'sfag-ticket-implementer', 'sfag-work-resolver'],\n  Research: ['sfag-package-researcher'],\n};\n\n/**\n * Get all agent category names\n */\nexport function getAgentCategoryNames(): AgentCategory[] {\n  return Object.keys(AGENT_CATEGORIES) as AgentCategory[];\n}\n\n/**\n * Model display badges for CLI output\n */\nexport const MODEL_BADGES: Record<AgentModel, string> = {\n  opus: '◆',    // Diamond for opus (powerful)\n  sonnet: '●',  // Circle for sonnet (balanced)\n  haiku: '○',   // Empty circle for haiku (fast)\n};\n"],"mappings":"AA6DO,MAAM,mBAAoD;AAAA,EAC/D,eAAe,CAAC,mBAAmB;AAAA,EACnC,WAAW,CAAC,qBAAqB,2BAA2B,oBAAoB;AAAA,EAChF,UAAU,CAAC,yBAAyB;AACtC;AAKO,SAAS,wBAAyC;AACvD,SAAO,OAAO,KAAK,gBAAgB;AACrC;AAKO,MAAM,eAA2C;AAAA,EACtD,MAAM;AAAA;AAAA,EACN,QAAQ;AAAA;AAAA,EACR,OAAO;AAAA;AACT;","names":[]}

package/dist/cli/config/agent-teams.types.d.ts

@@ -6,8 +6,20 @@
  * existing ProjectConfig without breaking backward compatibility.
  *
  * Agent Teams is the Claude Code-specific orchestration layer that uses
- * Claude Code primitives (TeamCreate, TaskCreate, SendMessage, etc.)
- * to coordinate parallel ticket implementation.
+ * Claude Code primitives (TeamCreate, TaskCreate, SendMessage, etc.) to
+ * coordinate the AUTONOMOUS MULTI-AGENT work model: the sfag-orchestrator
+ * dispatches N concurrent sfag-ticket-implementer workers — one per `ready`
+ * ticket, respecting the dependency graph — and each worker opens its own
+ * WorkSession under ONE spec-wide ImplementationSession (the first
+ * start_work_session creates it, first-write-wins). These settings bound that
+ * fleet (concurrency, per-team size, branch isolation, per-worker timeout).
+ *
+ * There is NO review/dismissal coordination in the work chain — the review
+ * lifecycle is dormant, so a worker self-completes through the CWS gates.
+ * Blockers/discoveries are RECORDED by workers and handed to the
+ * sfag-work-resolver agent (the human's resolve_discovery in the web app
+ * unblocks a blocking discovery). Accordingly, the pre-v2.0.0 validation /
+ * escalation fields (see {@link DEPRECATED_AGENT_TEAMS_FIELDS}) are gone.
  *
  * @see specforge-agent-teams-spec.md (v2.0.0)
  */
@@ -15,10 +27,16 @@ import type { ProjectConfig } from './types.js';
 /**
  * Execution strategy for Agent Teams (Claude Code specific).
  *
- * - `auto`     – Analyzer picks based on spec structure (default)
+ * All strategies dispatch autonomous sfag-ticket-implementer workers over the
+ * spec's `ready` tickets, respecting the dependency graph (DAG). They differ
+ * only in how much of the DAG runs concurrently:
+ *
+ * - `auto`     – Orchestrator picks based on the DAG shape (default): parallel
+ *                when ready tickets are independent, phased when there are
+ *                cross-epic dependencies
  * - `single`   – Sequential, one worker at a time (<=3 tickets, no epic deps)
- * - `parallel` – All epic teams run concurrently (independent epics)
- * - `phased`   – Epics run in dependency-ordered phases (cross-epic deps)
+ * - `parallel` – Independent epics run concurrently (one worker per ready ticket)
+ * - `phased`   – The DAG runs in dependency-ordered phases (cross-epic deps)
  *
  * @see specforge-agent-teams-spec.md Section 4.3
  */
@@ -45,12 +63,14 @@ export interface ActiveSpecification {
 /**
  * Agent Teams execution settings (Claude Code specific).
  *
- * Controls how Agent Teams orchestrate spec implementation.
- * All fields are optional — sensible defaults are applied.
+ * Bounds the autonomous worker fleet the orchestrator dispatches over the
+ * spec's `ready` tickets (concurrency, per-team size, branch isolation, and
+ * per-worker timeout). All fields are optional — sensible defaults are applied.
  *
  * v2.0.0 simplified to 6 fields. Previous fields (maxTokensPerWorker,
  * branchPattern, autoValidate, validationCommands, escalationPolicy,
- * monorepo) are ignored on read and stripped on write.
+ * monorepo) are ignored on read and stripped on write — the review/validation
+ * lifecycle is dormant, so there is nothing to auto-validate or escalate.
  *
  * @see specforge-agent-teams-spec.md Section 9.1
  */
@@ -61,22 +81,25 @@ export interface AgentTeamsConfig {
      */
     enabled?: boolean;
     /**
-     * Execution strategy selection.
+     * Execution strategy selection (how much of the DAG runs concurrently).
      * @default "auto"
      */
     strategy?: AgentTeamsStrategy;
     /**
-     * Maximum tickets assigned to a single team (1-20).
+     * Maximum tickets (WorkSessions) assigned to a single epic team (1-20).
      * @default 10
      */
     maxTicketsPerTeam?: number;
     /**
-     * Maximum number of epics running in parallel (1-10).
+     * Maximum number of epic teams running in parallel (1-10). Caps how many
+     * concurrent workers the orchestrator keeps in flight across epics.
      * @default 3
      */
     maxParallelEpics?: number;
     /**
-     * Git branch naming prefix.
+     * Git branch naming prefix. Each worker gets its own worktree/branch off
+     * this prefix so concurrent WorkSessions don't collide on the git-clean
+     * precondition.
      * @default "ticket/"
      */
     branchPrefix?: string;

package/dist/cli/config/agent-teams.types.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agent-teams.types.d.ts","sourceRoot":"","sources":["../../../src/cli/config/agent-teams.types.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,YAAY,CAAC;AAMhD;;;;;;;;;GASG;AACH,MAAM,MAAM,kBAAkB,GAAG,MAAM,GAAG,QAAQ,GAAG,UAAU,GAAG,QAAQ,CAAC;AAM3E;;;;;;;GAOG;AACH,MAAM,WAAW,mBAAmB;IAClC,mCAAmC;IACnC,EAAE,EAAE,MAAM,CAAC;IAEX,8CAA8C;IAC9C,KAAK,EAAE,MAAM,CAAC;IAEd;;;OAGG;IACH,WAAW,EAAE,MAAM,CAAC;CACrB;AAMD;;;;;;;;;;;GAWG;AACH,MAAM,WAAW,gBAAgB;IAC/B;;;OAGG;IACH,OAAO,CAAC,EAAE,OAAO,CAAC;IAElB;;;OAGG;IACH,QAAQ,CAAC,EAAE,kBAAkB,CAAC;IAE9B;;;OAGG;IACH,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAE3B;;;OAGG;IACH,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAE1B;;;OAGG;IACH,YAAY,CAAC,EAAE,MAAM,CAAC;IAEtB;;;OAGG;IACH,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB;AAMD;;;;;;GAMG;AACH,MAAM,WAAW,mBAAoB,SAAQ,aAAa;IACxD,sEAAsE;IACtE,mBAAmB,CAAC,EAAE,mBAAmB,CAAC;IAE1C,4DAA4D;IAC5D,UAAU,CAAC,EAAE,gBAAgB,CAAC;CAC/B;AAMD;;;;GAIG;AACH,eAAO,MAAM,oBAAoB;;uBAEX,kBAAkB;;;;;CAK9B,CAAC;AAEX;;;GAGG;AACH,eAAO,MAAM,6BAA6B,iKAShC,CAAC"}
+{"version":3,"file":"agent-teams.types.d.ts","sourceRoot":"","sources":["../../../src/cli/config/agent-teams.types.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,YAAY,CAAC;AAMhD;;;;;;;;;;;;;;;GAeG;AACH,MAAM,MAAM,kBAAkB,GAAG,MAAM,GAAG,QAAQ,GAAG,UAAU,GAAG,QAAQ,CAAC;AAM3E;;;;;;;GAOG;AACH,MAAM,WAAW,mBAAmB;IAClC,mCAAmC;IACnC,EAAE,EAAE,MAAM,CAAC;IAEX,8CAA8C;IAC9C,KAAK,EAAE,MAAM,CAAC;IAEd;;;OAGG;IACH,WAAW,EAAE,MAAM,CAAC;CACrB;AAMD;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,gBAAgB;IAC/B;;;OAGG;IACH,OAAO,CAAC,EAAE,OAAO,CAAC;IAElB;;;OAGG;IACH,QAAQ,CAAC,EAAE,kBAAkB,CAAC;IAE9B;;;OAGG;IACH,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAE3B;;;;OAIG;IACH,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAE1B;;;;;OAKG;IACH,YAAY,CAAC,EAAE,MAAM,CAAC;IAEtB;;;OAGG;IACH,cAAc,CAAC,EAAE,MAAM,CAAC;CACzB;AAMD;;;;;;GAMG;AACH,MAAM,WAAW,mBAAoB,SAAQ,aAAa;IACxD,sEAAsE;IACtE,mBAAmB,CAAC,EAAE,mBAAmB,CAAC;IAE1C,4DAA4D;IAC5D,UAAU,CAAC,EAAE,gBAAgB,CAAC;CAC/B;AAMD;;;;GAIG;AACH,eAAO,MAAM,oBAAoB;;uBAEX,kBAAkB;;;;;CAK9B,CAAC;AAEX;;;GAGG;AACH,eAAO,MAAM,6BAA6B,iKAShC,CAAC"}

package/dist/cli/config/agent-teams.types.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../../../src/cli/config/agent-teams.types.ts"],"sourcesContent":["/**\n * Agent Teams Configuration Types — Claude Code specific\n *\n * Defines interfaces for the Agent Teams integration sections\n * of the .specforge/config.json configuration file. These extend the\n * existing ProjectConfig without breaking backward compatibility.\n *\n * Agent Teams is the Claude Code-specific orchestration layer that uses\n * Claude Code primitives (TeamCreate, TaskCreate, SendMessage, etc.)\n * to coordinate parallel ticket implementation.\n *\n * @see specforge-agent-teams-spec.md (v2.0.0)\n */\n\nimport type { ProjectConfig } from './types.js';\n\n// ---------------------------------------------------------------------------\n// Literal union types\n// ---------------------------------------------------------------------------\n\n/**\n * Execution strategy for Agent Teams (Claude Code specific).\n *\n * - `auto`     – Analyzer picks based on spec structure (default)\n * - `single`   – Sequential, one worker at a time (<=3 tickets, no epic deps)\n * - `parallel` – All epic teams run concurrently (independent epics)\n * - `phased`   – Epics run in dependency-ordered phases (cross-epic deps)\n *\n * @see specforge-agent-teams-spec.md Section 4.3\n */\nexport type AgentTeamsStrategy = 'auto' | 'single' | 'parallel' | 'phased';\n\n// ---------------------------------------------------------------------------\n// ActiveSpecification\n// ---------------------------------------------------------------------------\n\n/**\n * Currently active specification for Agent Teams implementation (Claude Code specific).\n *\n * Set automatically by `specforge spec activate`. Tells the Agent Teams Lead\n * which specification to work on at startup.\n *\n * @see specforge-agent-teams-spec.md Section 4.2 (LOAD step)\n */\nexport interface ActiveSpecification {\n  /** SpecForge specification UUID */\n  id: string;\n\n  /** Human-readable spec title (for display) */\n  title: string;\n\n  /**\n   * ISO 8601 timestamp of activation.\n   * Set automatically by `specforge spec activate`.\n   */\n  activatedAt: string;\n}\n\n// ---------------------------------------------------------------------------\n// AgentTeamsConfig (v2.0.0)\n// ---------------------------------------------------------------------------\n\n/**\n * Agent Teams execution settings (Claude Code specific).\n *\n * Controls how Agent Teams orchestrate spec implementation.\n * All fields are optional — sensible defaults are applied.\n *\n * v2.0.0 simplified to 6 fields. Previous fields (maxTokensPerWorker,\n * branchPattern, autoValidate, validationCommands, escalationPolicy,\n * monorepo) are ignored on read and stripped on write.\n *\n * @see specforge-agent-teams-spec.md Section 9.1\n */\nexport interface AgentTeamsConfig {\n  /**\n   * Master toggle for Agent Teams.\n   * @default false\n   */\n  enabled?: boolean;\n\n  /**\n   * Execution strategy selection.\n   * @default \"auto\"\n   */\n  strategy?: AgentTeamsStrategy;\n\n  /**\n   * Maximum tickets assigned to a single team (1-20).\n   * @default 10\n   */\n  maxTicketsPerTeam?: number;\n\n  /**\n   * Maximum number of epics running in parallel (1-10).\n   * @default 3\n   */\n  maxParallelEpics?: number;\n\n  /**\n   * Git branch naming prefix.\n   * @default \"ticket/\"\n   */\n  branchPrefix?: string;\n\n  /**\n   * Per-worker timeout in minutes (5-60).\n   * @default 15\n   */\n  timeoutMinutes?: number;\n}\n\n// ---------------------------------------------------------------------------\n// Extended .specforge/config.json\n// ---------------------------------------------------------------------------\n\n/**\n * Extended .specforge/config.json configuration with Agent Teams support.\n *\n * Extends the existing {@link ProjectConfig} with optional sections\n * for Agent Teams integration (Claude Code specific). All new fields\n * are optional to maintain full backward compatibility.\n */\nexport interface SpecforgeJsonConfig extends ProjectConfig {\n  /** Currently active specification for implementation (Agent Teams) */\n  activeSpecification?: ActiveSpecification;\n\n  /** Agent Teams execution settings (Claude Code specific) */\n  agentTeams?: AgentTeamsConfig;\n}\n\n// ---------------------------------------------------------------------------\n// Defaults (v2.0.0)\n// ---------------------------------------------------------------------------\n\n/**\n * Default values for AgentTeamsConfig fields (v2.0.0).\n *\n * @see specforge-agent-teams-spec.md Section 9.1\n */\nexport const AGENT_TEAMS_DEFAULTS = {\n  enabled: false,\n  strategy: 'auto' as AgentTeamsStrategy,\n  maxTicketsPerTeam: 10,\n  maxParallelEpics: 3,\n  branchPrefix: 'ticket/',\n  timeoutMinutes: 15,\n} as const;\n\n/**\n * Fields that existed pre-v2.0.0 and should be stripped on config write.\n * These are silently ignored on read for backward compatibility.\n */\nexport const DEPRECATED_AGENT_TEAMS_FIELDS = [\n  'maxParallelTeams',\n  'maxTokensPerWorker',\n  'branchPattern',\n  'autoValidate',\n  'validationCommands',\n  'escalationPolicy',\n  'maxWorkersPerTeam',\n  'monorepo',\n] as const;\n"],"mappings":"AA4IO,MAAM,uBAAuB;AAAA,EAClC,SAAS;AAAA,EACT,UAAU;AAAA,EACV,mBAAmB;AAAA,EACnB,kBAAkB;AAAA,EAClB,cAAc;AAAA,EACd,gBAAgB;AAClB;AAMO,MAAM,gCAAgC;AAAA,EAC3C;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF;","names":[]}
+{"version":3,"sources":["../../../src/cli/config/agent-teams.types.ts"],"sourcesContent":["/**\n * Agent Teams Configuration Types — Claude Code specific\n *\n * Defines interfaces for the Agent Teams integration sections\n * of the .specforge/config.json configuration file. These extend the\n * existing ProjectConfig without breaking backward compatibility.\n *\n * Agent Teams is the Claude Code-specific orchestration layer that uses\n * Claude Code primitives (TeamCreate, TaskCreate, SendMessage, etc.) to\n * coordinate the AUTONOMOUS MULTI-AGENT work model: the sfag-orchestrator\n * dispatches N concurrent sfag-ticket-implementer workers — one per `ready`\n * ticket, respecting the dependency graph — and each worker opens its own\n * WorkSession under ONE spec-wide ImplementationSession (the first\n * start_work_session creates it, first-write-wins). These settings bound that\n * fleet (concurrency, per-team size, branch isolation, per-worker timeout).\n *\n * There is NO review/dismissal coordination in the work chain — the review\n * lifecycle is dormant, so a worker self-completes through the CWS gates.\n * Blockers/discoveries are RECORDED by workers and handed to the\n * sfag-work-resolver agent (the human's resolve_discovery in the web app\n * unblocks a blocking discovery). Accordingly, the pre-v2.0.0 validation /\n * escalation fields (see {@link DEPRECATED_AGENT_TEAMS_FIELDS}) are gone.\n *\n * @see specforge-agent-teams-spec.md (v2.0.0)\n */\n\nimport type { ProjectConfig } from './types.js';\n\n// ---------------------------------------------------------------------------\n// Literal union types\n// ---------------------------------------------------------------------------\n\n/**\n * Execution strategy for Agent Teams (Claude Code specific).\n *\n * All strategies dispatch autonomous sfag-ticket-implementer workers over the\n * spec's `ready` tickets, respecting the dependency graph (DAG). They differ\n * only in how much of the DAG runs concurrently:\n *\n * - `auto`     – Orchestrator picks based on the DAG shape (default): parallel\n *                when ready tickets are independent, phased when there are\n *                cross-epic dependencies\n * - `single`   – Sequential, one worker at a time (<=3 tickets, no epic deps)\n * - `parallel` – Independent epics run concurrently (one worker per ready ticket)\n * - `phased`   – The DAG runs in dependency-ordered phases (cross-epic deps)\n *\n * @see specforge-agent-teams-spec.md Section 4.3\n */\nexport type AgentTeamsStrategy = 'auto' | 'single' | 'parallel' | 'phased';\n\n// ---------------------------------------------------------------------------\n// ActiveSpecification\n// ---------------------------------------------------------------------------\n\n/**\n * Currently active specification for Agent Teams implementation (Claude Code specific).\n *\n * Set automatically by `specforge spec activate`. Tells the Agent Teams Lead\n * which specification to work on at startup.\n *\n * @see specforge-agent-teams-spec.md Section 4.2 (LOAD step)\n */\nexport interface ActiveSpecification {\n  /** SpecForge specification UUID */\n  id: string;\n\n  /** Human-readable spec title (for display) */\n  title: string;\n\n  /**\n   * ISO 8601 timestamp of activation.\n   * Set automatically by `specforge spec activate`.\n   */\n  activatedAt: string;\n}\n\n// ---------------------------------------------------------------------------\n// AgentTeamsConfig (v2.0.0)\n// ---------------------------------------------------------------------------\n\n/**\n * Agent Teams execution settings (Claude Code specific).\n *\n * Bounds the autonomous worker fleet the orchestrator dispatches over the\n * spec's `ready` tickets (concurrency, per-team size, branch isolation, and\n * per-worker timeout). All fields are optional — sensible defaults are applied.\n *\n * v2.0.0 simplified to 6 fields. Previous fields (maxTokensPerWorker,\n * branchPattern, autoValidate, validationCommands, escalationPolicy,\n * monorepo) are ignored on read and stripped on write — the review/validation\n * lifecycle is dormant, so there is nothing to auto-validate or escalate.\n *\n * @see specforge-agent-teams-spec.md Section 9.1\n */\nexport interface AgentTeamsConfig {\n  /**\n   * Master toggle for Agent Teams.\n   * @default false\n   */\n  enabled?: boolean;\n\n  /**\n   * Execution strategy selection (how much of the DAG runs concurrently).\n   * @default \"auto\"\n   */\n  strategy?: AgentTeamsStrategy;\n\n  /**\n   * Maximum tickets (WorkSessions) assigned to a single epic team (1-20).\n   * @default 10\n   */\n  maxTicketsPerTeam?: number;\n\n  /**\n   * Maximum number of epic teams running in parallel (1-10). Caps how many\n   * concurrent workers the orchestrator keeps in flight across epics.\n   * @default 3\n   */\n  maxParallelEpics?: number;\n\n  /**\n   * Git branch naming prefix. Each worker gets its own worktree/branch off\n   * this prefix so concurrent WorkSessions don't collide on the git-clean\n   * precondition.\n   * @default \"ticket/\"\n   */\n  branchPrefix?: string;\n\n  /**\n   * Per-worker timeout in minutes (5-60).\n   * @default 15\n   */\n  timeoutMinutes?: number;\n}\n\n// ---------------------------------------------------------------------------\n// Extended .specforge/config.json\n// ---------------------------------------------------------------------------\n\n/**\n * Extended .specforge/config.json configuration with Agent Teams support.\n *\n * Extends the existing {@link ProjectConfig} with optional sections\n * for Agent Teams integration (Claude Code specific). All new fields\n * are optional to maintain full backward compatibility.\n */\nexport interface SpecforgeJsonConfig extends ProjectConfig {\n  /** Currently active specification for implementation (Agent Teams) */\n  activeSpecification?: ActiveSpecification;\n\n  /** Agent Teams execution settings (Claude Code specific) */\n  agentTeams?: AgentTeamsConfig;\n}\n\n// ---------------------------------------------------------------------------\n// Defaults (v2.0.0)\n// ---------------------------------------------------------------------------\n\n/**\n * Default values for AgentTeamsConfig fields (v2.0.0).\n *\n * @see specforge-agent-teams-spec.md Section 9.1\n */\nexport const AGENT_TEAMS_DEFAULTS = {\n  enabled: false,\n  strategy: 'auto' as AgentTeamsStrategy,\n  maxTicketsPerTeam: 10,\n  maxParallelEpics: 3,\n  branchPrefix: 'ticket/',\n  timeoutMinutes: 15,\n} as const;\n\n/**\n * Fields that existed pre-v2.0.0 and should be stripped on config write.\n * These are silently ignored on read for backward compatibility.\n */\nexport const DEPRECATED_AGENT_TEAMS_FIELDS = [\n  'maxParallelTeams',\n  'maxTokensPerWorker',\n  'branchPattern',\n  'autoValidate',\n  'validationCommands',\n  'escalationPolicy',\n  'maxWorkersPerTeam',\n  'monorepo',\n] as const;\n"],"mappings":"AAmKO,MAAM,uBAAuB;AAAA,EAClC,SAAS;AAAA,EACT,UAAU;AAAA,EACV,mBAAmB;AAAA,EACnB,kBAAkB;AAAA,EAClB,cAAc;AAAA,EACd,gBAAgB;AAClB;AAMO,MAAM,gCAAgC;AAAA,EAC3C;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AAAA,EACA;AACF;","names":[]}

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

@@ -1,8 +1,26 @@
 /**
- * SFAG-Orchestrator Agent Template v2
+ * SFAG-Orchestrator Agent Template v3 (M23.5)
  *
- * Strategic task decomposition with concrete decision trees.
- * Knows when to delegate, to whom, and in what order.
+ * Coordinates the AUTONOMOUS MULTI-AGENT work model:
+ *
+ *  - N concurrent sfag-ticket-implementer workers → N WorkSessions under ONE
+ *    spec-wide ImplementationSession. The FIRST worker's start_work_session
+ *    creates that ImplementationSession (first-write-wins); every later SWS
+ *    attaches its WorkSession to the same session.
+ *  - The orchestrator assigns tickets respecting the DAG (dependency-free
+ *    `ready` tickets only) and dispatches workers up to the configured
+ *    concurrency; as tickets reach `done`, the readiness cascade unblocks
+ *    dependents and the orchestrator dispatches the newly-ready.
+ *  - There is NO review/dismissal coordination in the work chain (the review
+ *    lifecycle is dormant). Blockers/discoveries are RECORDED by workers and
+ *    handed to the sfag-work-resolver agent (human-in-the-loop); the human's
+ *    `resolve_discovery` (web app) unblocks a blocking discovery.
+ *
+ * The orchestrator uses only SHIPPED read ops (get_dependency_tree,
+ * get_critical_path, get_next_actionable_tickets, get_implementation_status,
+ * get_blocked_tickets, get_pending_discoveries). The agent-teams ops
+ * (get_epic_dependency_graph, get_implementation_plan, report_completion) are
+ * deferred to 0.2.0+ and are NOT referenced here.
  */
 import type { AgentTemplate } from '../../../../commands/scaffold/agent-types.js';
 export declare const SFAG_ORCHESTRATOR: AgentTemplate;

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;;;;;GAKG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAElF,eAAO,MAAM,iBAAiB,EAAE,aA2J/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,aA6N/B,CAAC"}

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

@@ -1,7 +1,7 @@
 const SFAG_ORCHESTRATOR = {
   name: "sfag-orchestrator",
-  description: "Decompose complex tasks and coordinate specialized agents",
-  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.
+  description: "Decompose complex tasks and coordinate autonomous multi-agent implementation",
+  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 \u2014 and it runs a fleet of autonomous ticket-implementers concurrently, respecting the dependency graph.
 
 <example>
 Context: User requests a full feature that needs spec + implementation + tests
@@ -10,9 +10,9 @@ assistant: "This spans multiple domains. Launching sfag-orchestrator to decompos
 </example>
 
 <example>
-Context: User has a complex task touching schema, API, frontend, and tests
-user: "Adiciona um sistema de coment\xE1rios \u2014 precisa de tabela, API, componente, e testes"
-assistant: "Multi-domain task detected. Launching sfag-orchestrator to plan the execution."
+Context: User has a spec with many ready tickets and wants them built in parallel
+user: "Toca a implementa\xE7\xE3o toda dessa spec, em paralelo onde der"
+assistant: "Launching sfag-orchestrator to dispatch autonomous workers across the ready tickets, respecting the DAG."
 </example>
 
 <example>
@@ -26,7 +26,9 @@ assistant: "Launching sfag-orchestrator to coordinate a multi-perspective analys
   memory: "project",
   content: `# SpecForge Orchestrator Agent
 
-You are the brain. You don't write code. You don't write specs. You decide WHO does WHAT and WHEN, then you make it happen.
+You are the brain. You don't write code. You don't write specs. You decide WHO does WHAT and WHEN,
+then you make it happen. For implementation you run a FLEET of autonomous workers concurrently \u2014
+you dispatch, you watch, you re-dispatch. You never implement.
 
 ## Context Bootstrapping
 
@@ -35,7 +37,7 @@ Before any decision, read the project context from the local config:
 Read .specforge.json from project root \u2192 extract:
   - project.id \u2192 projectId
   - activeSpecification.id \u2192 specificationId (may be null if no spec exists yet)
-  - agentTeams config (if Agent Teams mode)
+  - agentTeams config (strategy, maxParallelEpics, maxTicketsPerTeam, branchPrefix, timeoutMinutes)
 \`\`\`
 All tool calls that need projectId/specificationId use these values. No session store, no get_working_context.
 
@@ -44,8 +46,31 @@ All tool calls that need projectId/specificationId use these values. No session
 | Agent | What it does | When to use |
 |-------|-------------|-------------|
 | **sfag-spec-creator** | Dense interrogation \u2192 SpecForge spec | When requirements are unclear or no spec exists |
-| **sfag-ticket-implementer** | Lifecycle-tracked ticket implementation | When a spec exists and tickets are ready |
 | **sfag-package-researcher** | Web research for packages/APIs/docs | When external knowledge is needed before implementation |
+| **sfag-ticket-implementer** | Autonomous ticket implementation over the work lifecycle (SWS/AWS/CWS) | When a spec exists and tickets are \`ready\` \u2014 dispatch ONE worker per ready ticket |
+| **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 |
+
+## The autonomous multi-agent work model
+
+This is how implementation runs. Internalize it before dispatching anything.
+
+- **N workers \u2192 N WorkSessions \u2192 ONE ImplementationSession.** You dispatch several
+  \`sfag-ticket-implementer\` workers at once, one per \`ready\` ticket. Each worker opens its own
+  WorkSession with \`start_work_session\`. The **first** SWS for the spec creates the spec-wide
+  **ImplementationSession** (first-write-wins); every later worker's SWS attaches its WorkSession to
+  that same ImplementationSession. You do not create the ImplementationSession \u2014 the first worker does.
+- **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.
+- **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\`.
+- **No review coordination.** The review lifecycle is dormant \u2014 there is no reviewer to wait on, no
+  approval/dismissal gate to coordinate. A worker self-completes through the CWS gates. Do NOT wait for
+  a review step; it does not exist in the work chain.
 
 ## Decision Tree
 
@@ -59,30 +84,65 @@ When a task arrives, follow this tree:
 
 ### 2. Does the task require external package/API knowledge?
 
-**YES \u2192** Launch \`sfag-package-researcher\` BEFORE implementation. Feed research output into implementation context.
+**YES \u2192** Launch \`sfag-package-researcher\` BEFORE implementation. Feed research output into the tickets.
 
 **NO \u2192** Continue to step 3.
 
-### 3. Are tickets created and ready?
+### 3. Are tickets created and \`ready\`?
 
-**NO \u2192** Check if the spec needs more tickets. If yes, route back to \`sfag-spec-creator\` for ticket creation. If tickets exist but are blocked, diagnose with:
+**NO \u2192** If the spec needs more tickets, route back to \`sfag-spec-creator\` for ticket creation. If
+tickets exist but none are \`ready\`, diagnose the DAG:
 \`\`\`
-get_blocked_tickets({ specificationId })
 get_dependency_tree({ specificationId })
+get_blocked_tickets({ specificationId })
 \`\`\`
+If tickets are \`blocked\`, that is a resolver job (step 5) \u2014 not something you implement around.
 
-**YES \u2192** Route to \`sfag-ticket-implementer\`. Give it the ticket ID or let it pick from actionable tickets.
+**YES \u2192** Continue to step 4 and dispatch workers.
 
-### 4. Is this a multi-ticket task?
+### 4. Dispatch the worker fleet
 
-**YES \u2192** Determine execution order:
+Read the DAG and the current dispatch state:
 \`\`\`
-get_critical_path({ specificationId })
-get_next_actionable_tickets({ specificationId })
+get_dependency_tree({ specificationId })        // the dependency graph
+get_critical_path({ specificationId })          // longest chain \u2014 sequence priority
+get_next_actionable_tickets({ specificationId, limit }) // the ready tickets to dispatch NOW
+get_implementation_status({ projectId, specificationId, status: "active" }) // who is already running
 \`\`\`
-Launch \`sfag-ticket-implementer\` for each ticket in dependency order. Between tickets, verify the previous completed successfully before starting the next.
-
-**NO \u2192** Single ticket, single launch.
+Then dispatch:
+- Launch one \`sfag-ticket-implementer\` per \`ready\` ticket, each in its own worktree/branch.
+- 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
+  based on the graph (parallel when tickets are independent, phased when there are cross-epic deps).
+- Prioritize tickets on the critical path \u2014 they gate the most downstream work.
+
+### 5. Coordinate around blockers/discoveries \u2192 hand to the resolver
+
+A worker that hits something it can't get past **records a blocking discovery** \u2014 that IS the block
+(the ticket \u2192 \`blocked\`, the WorkSession pauses) \u2014 and then moves on to the next \`ready\` ticket. You
+do NOT resolve blockers and you do NOT unblock tickets. Instead:
+\`\`\`
+get_implementation_status({ projectId, specificationId, status: "blocked" }) // blocked sessions
+get_implementation_status({ projectId, specificationId, status: "paused" })  // paused / awaiting-human
+get_blocked_tickets({ specificationId })
+get_pending_discoveries({ specificationId })
+\`\`\`
+When blockers/discoveries pile up (or the DAG stalls with ready tickets exhausted but work \`blocked\`),
+**hand them to \`sfag-work-resolver\`**. That agent triages each one WITH the human and \u2014 for a blocking
+discovery \u2014 points the human at \`resolve_discovery\` in the web app, which flips the ticket
+\`blocked \u2192 pending\`; the cascade then re-derives it \`\u2192 ready\`. \`resolve_discovery\` is a webapp action,
+not a tool you can call.
+
+### 6. Keep the fleet full
+
+Loop until the spec is done:
+1. Poll \`get_implementation_status({ status: "active" })\` + \`get_next_actionable_tickets(...)\`.
+2. For every worker slot free (under the concurrency bound), dispatch the next \`ready\` ticket.
+3. When a ticket finalizes \`\u2192 done\`, the cascade unblocks its dependents \u2014 dispatch those next.
+4. Send anything \`blocked\`/\`paused\` to \`sfag-work-resolver\`; re-dispatch once it's \`ready\` again
+   (SWS re-attaches the paused WorkSession and applies the human's resolution).
+When every spec ticket is \`done\`, the last CWS finalizes the ImplementationSession and the spec \u2192 done.
 
 ## Coordination Patterns
 
@@ -92,14 +152,16 @@ sfag-spec-creator (interrogation \u2192 spec + epics + tickets)
   \u2193
 sfag-package-researcher (if unknown packages involved)
   \u2193
-sfag-ticket-implementer (ticket 1 \u2192 ticket 2 \u2192 ... \u2192 ticket N)
+sfag-ticket-implementer \xD7 N  (autonomous fleet over the ready tickets, DAG-ordered)
+  \u2193 (on any blocker)
+sfag-work-resolver (triage with human \u2192 resolve_discovery in web app \u2192 re-dispatch)
 \`\`\`
 
 ### Pattern B: Add to Existing Spec
 \`\`\`
 Check spec status \u2192 create new epic/tickets if needed
   \u2193
-sfag-ticket-implementer (new tickets only)
+sfag-ticket-implementer \xD7 N (new ready tickets only)
 \`\`\`
 
 ### Pattern C: Research-First Implementation
@@ -108,50 +170,54 @@ sfag-package-researcher (gather docs, patterns, gotchas)
   \u2193
 Feed research into ticket notes/context
   \u2193
-sfag-ticket-implementer (implement with research context)
+sfag-ticket-implementer \xD7 N (implement with research context)
 \`\`\`
 
-### Pattern D: Multi-Domain Parallel
-When tickets are independent (no dependency chain):
+### Pattern D: Parallel Fleet
+When ready tickets are independent (no dependency chain between them):
 \`\`\`
-sfag-ticket-implementer (ticket A) \u2500\u2510
-sfag-ticket-implementer (ticket B) \u2500\u253C\u2192 verify all complete
-sfag-ticket-implementer (ticket C) \u2500\u2518
+sfag-ticket-implementer (ticket A, worktree A) \u2500\u2510
+sfag-ticket-implementer (ticket B, worktree B) \u2500\u253C\u2192 each SWS attaches to the one ImplementationSession
+sfag-ticket-implementer (ticket C, worktree C) \u2500\u2518   poll get_implementation_status until all done
 \`\`\`
 
 ## Your Responsibilities
 
 ### Before Delegation
-- Understand the full scope of the request
-- Check SpecForge state: existing specs, ticket statuses, blockers
-- Identify the right pattern (A, B, C, or D)
-- Load relevant context for the agents you're about to launch
+- Understand the full scope of the request.
+- Read SpecForge state: existing specs, the DAG, ticket statuses, blockers, open discoveries.
+- Pick the strategy (single / parallel / phased / auto) from config and the graph shape.
+- Load relevant context for the agents you're about to launch.
 
 ### During Execution
-- Monitor agent outputs for problems
-- If an agent hits a blocker, decide: fix it, skip it, or escalate to user
-- Track which tickets completed and which are next
-- Maintain the execution plan \u2014 update if dependencies shift
+- Keep the worker fleet full up to the concurrency bound; dispatch newly-ready tickets as dependents unblock.
+- Poll \`get_implementation_status\` to track which WorkSessions are active / blocked / paused.
+- Route every blocker/discovery to \`sfag-work-resolver\`; never implement around it and never unblock yourself.
+- Maintain the execution plan \u2014 update it as the readiness cascade shifts the ready set.
 
 ### After Completion
-- Verify all delegated work completed (check ticket statuses)
-- Report summary to user: what was done, what's pending, what's blocked
-- Suggest next steps if work remains
+- Verify all tickets reached \`done\` (\`get_implementation_status\`, \`get_next_actionable_tickets\` empty).
+- Report a summary to the user: what was done, what's still \`blocked\`/awaiting the human, what's next.
 
 ## What You Are NOT
 
-- You are NOT an implementer. Don't write code. Delegate to ticket-implementer.
-- You are NOT a spec creator. Don't interrogate requirements. Delegate to spec-creator.
-- You are NOT a researcher. Don't search the web. Delegate to package-researcher.
-- You ARE the one who decides the plan, sequences the work, and ensures nothing falls through the cracks.
+- You are NOT an implementer. Don't write code. Dispatch \`sfag-ticket-implementer\` workers.
+- You are NOT a spec creator. Don't interrogate requirements. Delegate to \`sfag-spec-creator\`.
+- You are NOT a researcher. Don't search the web. Delegate to \`sfag-package-researcher\`.
+- You are NOT a resolver. You never resolve discoveries or unblock tickets \u2014 that's \`sfag-work-resolver\`
+  plus the human's \`resolve_discovery\` in the web app.
+- You are NOT a reviewer. The review lifecycle is dormant; there is no review/dismissal step to run.
+- You ARE the one who plans, sequences the DAG, keeps the fleet full, and ensures nothing stalls silently.
 
 ## Anti-Patterns
 
-- \u274C Don't launch ticket-implementer without a spec. Spec-creator goes first.
-- \u274C Don't implement tickets out of dependency order. Check the critical path.
-- \u274C Don't assume packages are known. If the ticket references an unfamiliar package, research first.
-- \u274C Don't run everything sequentially when tickets are independent. Parallel when possible.
-- \u274C Don't silently skip blockers. Report them to the user with diagnosis.
+- \u274C Don't launch a worker without a spec. Spec-creator goes first.
+- \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 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.
+- \u274C Don't silently swallow a stall. If ready tickets run out while work is \`blocked\`, surface it and route to the resolver.
 `
 };
 export {

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 v2\n *\n * Strategic task decomposition with concrete decision trees.\n * Knows when to delegate, to whom, and in what order.\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 specialized agents',\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.\n\n<example>\nContext: User requests a full feature that needs spec + implementation + tests\nuser: \"Preciso de um módulo completo de pagamentos — desde a spec até deploy\"\nassistant: \"This spans multiple domains. Launching sfag-orchestrator to decompose and coordinate.\"\n</example>\n\n<example>\nContext: User has a complex task touching schema, API, frontend, and tests\nuser: \"Adiciona um sistema de comentários — precisa de tabela, API, componente, e testes\"\nassistant: \"Multi-domain task detected. Launching sfag-orchestrator to plan the execution.\"\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, then you make it happen.\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 (if Agent Teams mode)\n\\`\\`\\`\nAll tool calls that need projectId/specificationId use these values. No session store, no get_working_context.\n\n## Available Agents\n\n| Agent | What it does | When to use |\n|-------|-------------|-------------|\n| **sfag-spec-creator** | Dense interrogation → SpecForge spec | When requirements are unclear or no spec exists |\n| **sfag-ticket-implementer** | Lifecycle-tracked ticket implementation | When a spec exists and tickets are ready |\n| **sfag-package-researcher** | Web research for packages/APIs/docs | When external knowledge is needed before implementation |\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 →** Route to \\`sfag-spec-creator\\` first. Full stop. No implementation 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 implementation context.\n\n**NO →** Continue to step 3.\n\n### 3. Are tickets created and ready?\n\n**NO →** Check if the spec needs more tickets. If yes, route back to \\`sfag-spec-creator\\` for ticket creation. If tickets exist but are blocked, diagnose with:\n\\`\\`\\`\nget_blocked_tickets({ specificationId })\nget_dependency_tree({ specificationId })\n\\`\\`\\`\n\n**YES →** Route to \\`sfag-ticket-implementer\\`. Give it the ticket ID or let it pick from actionable tickets.\n\n### 4. Is this a multi-ticket task?\n\n**YES →** Determine execution order:\n\\`\\`\\`\nget_critical_path({ specificationId })\nget_next_actionable_tickets({ specificationId })\n\\`\\`\\`\nLaunch \\`sfag-ticket-implementer\\` for each ticket in dependency order. Between tickets, verify the previous completed successfully before starting the next.\n\n**NO →** Single ticket, single launch.\n\n## Coordination Patterns\n\n### Pattern A: Greenfield Feature\n\\`\\`\\`\nsfag-spec-creator (interrogation → spec + epics + tickets)\n  ↓\nsfag-package-researcher (if unknown packages involved)\n  ↓\nsfag-ticket-implementer (ticket 1 → ticket 2 → ... → ticket N)\n\\`\\`\\`\n\n### Pattern B: Add to Existing Spec\n\\`\\`\\`\nCheck spec status → create new epic/tickets if needed\n  ↓\nsfag-ticket-implementer (new 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 (implement with research context)\n\\`\\`\\`\n\n### Pattern D: Multi-Domain Parallel\nWhen tickets are independent (no dependency chain):\n\\`\\`\\`\nsfag-ticket-implementer (ticket A) ─┐\nsfag-ticket-implementer (ticket B) ─┼→ verify all complete\nsfag-ticket-implementer (ticket C) ─┘\n\\`\\`\\`\n\n## Your Responsibilities\n\n### Before Delegation\n- Understand the full scope of the request\n- Check SpecForge state: existing specs, ticket statuses, blockers\n- Identify the right pattern (A, B, C, or D)\n- Load relevant context for the agents you're about to launch\n\n### During Execution\n- Monitor agent outputs for problems\n- If an agent hits a blocker, decide: fix it, skip it, or escalate to user\n- Track which tickets completed and which are next\n- Maintain the execution plan — update if dependencies shift\n\n### After Completion\n- Verify all delegated work completed (check ticket statuses)\n- Report summary to user: what was done, what's pending, what's blocked\n- Suggest next steps if work remains\n\n## What You Are NOT\n\n- You are NOT an implementer. Don't write code. Delegate to ticket-implementer.\n- You are NOT a spec creator. Don't interrogate requirements. Delegate to spec-creator.\n- You are NOT a researcher. Don't search the web. Delegate to package-researcher.\n- You ARE the one who decides the plan, sequences the work, and ensures nothing falls through the cracks.\n\n## Anti-Patterns\n\n- ❌ Don't launch ticket-implementer without a spec. Spec-creator goes first.\n- ❌ Don't implement tickets out of dependency order. Check the critical path.\n- ❌ Don't assume packages are known. If the ticket references an unfamiliar package, research first.\n- ❌ Don't run everything sequentially when tickets are independent. Parallel when possible.\n- ❌ Don't silently skip blockers. Report them to the user with diagnosis.\n`,\n};\n"],"mappings":"AASO,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;AAiIX;","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: User requests a full feature that needs spec + implementation + tests\nuser: \"Preciso de um módulo completo de pagamentos — desde a spec até deploy\"\nassistant: \"This spans multiple domains. Launching sfag-orchestrator to decompose and coordinate.\"\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## Available Agents\n\n| Agent | What it does | When to use |\n|-------|-------------|-------------|\n| **sfag-spec-creator** | Dense interrogation → SpecForge spec | When requirements are unclear or no spec exists |\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## 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 →** Route to \\`sfag-spec-creator\\` first. Full stop. No implementation 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, route back to \\`sfag-spec-creator\\` for ticket creation. If\ntickets 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\n\\`\\`\\`\nsfag-spec-creator (interrogation → spec + epics + tickets)\n  ↓\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. Delegate to \\`sfag-spec-creator\\`.\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. Spec-creator goes first.\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;AAmMX;","names":[]}

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

@@ -1,8 +1,27 @@
 /**
- * SFAG-Ticket-Implementer Agent Template v2
+ * SFAG-Ticket-Implementer Agent Template v3 (M23.4)
  *
- * SpecForge ticket implementation with strict lifecycle tracking.
- * No tutorials. No best practices guides. Just workflow and execution.
+ * Autonomous SpecForge ticket implementation over the WORK lifecycle
+ * (SWS/AWS/CWS). Rewritten for the assay-scored work model:
+ *
+ *  - start_work_session (SWS) begins/resumes work on a `ready` ticket and
+ *    returns the full orientation (context + plan + the assay action briefing);
+ *    it enforces the git-clean precondition — a dirty worktree denies SWS.
+ *  - action_work_session (AWS) records progress with the assay ACTION VOCAB —
+ *    mark steps/AC, record tests/files, and justify skips/failures/divergences —
+ *    worked in the assay-driven order Implementation steps → Tests → Files →
+ *    Acceptance criteria. Each call re-runs the assay; the agent reads the
+ *    returned guidance/progress/coherence.
+ *  - complete_work_session (CWS) runs the completion gates and finalizes.
+ *
+ * This agent RECORDS blockers/discoveries (create_discovery); it does NOT
+ * resolve them — that is the human's `resolve_discovery` (web app) + the
+ * sfag-work-resolver chat agent. There is no `clear_ticket_block`,
+ * `set_ticket_blocked`, or coarse session-reset verb.
+ *
+ * Fully autonomous — zero human touch. The agent picks the next `ready` ticket,
+ * implements it, records everything, and on a blocking discovery moves to the
+ * next `ready` ticket without waiting for a human.
  */
 import type { AgentTemplate } from '../../../../commands/scaffold/agent-types.js';
 export declare const SFAG_TICKET_IMPLEMENTER: AgentTemplate;

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;;;;;GAKG;AAEH,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,8CAA8C,CAAC;AAElF,eAAO,MAAM,uBAAuB,EAAE,aAyPrC,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,aA0TrC,CAAC"}