β Task Pipeline — Algorithm Extraction

⚠ HERITAGE EXTRACTION — donor AMS β Task Pipeline (Wave 8 quarantine)

This file extracts the donor AMS β pipeline from src/domains/tasks/ and src/gsd/ (both deleted in R53). The donor 7-state machine described below is genealogy. Phase 0 Colibri β is an 8-state FSM (INIT → GATHER → ANALYZE → PLAN → APPLY → VERIFY → DONE + CANCELLED) defined in ../../concepts/β-task-pipeline.md. There is no src/gsd/ directory and no donor RETRY edge in Phase 0 — failure handling is via CANCELLED and re-enqueue.

Read this file as donor genealogy only.

Algorithmic content extracted from AMS src/domains/tasks/ and src/gsd/ for Colibri implementation reference.

GSD State Machine

GSD (Gather-Sync-Dispatch) is the 7-state pipeline through which every task flows:

INIT → GATHER → ANALYZE → PLAN → APPLY → VERIFY → DONE
  ↑                                                  │
  └──────────────── RETRY ───────────────────────────┘

State Transition Conditions

From	To	Condition
INIT	GATHER	Workspace validated, resources allocated, task definition valid
GATHER	ANALYZE	All input dependencies collected, context snapshots taken
ANALYZE	PLAN	Complexity assessed, risks identified, preconditions met
PLAN	APPLY	Execution plan created, dependency order resolved, acceptance criteria defined
APPLY	VERIFY	All phase work complete, agent writebacks received
VERIFY	DONE	Acceptance criteria passed, tests green, proof generated
VERIFY	RETRY	Acceptance criteria failed AND retry budget remaining
APPLY	RETRY	Phase execution failed AND error classified as transient
RETRY	GATHER	After backoff delay, re-enter at appropriate state
Any	BLOCKED	Fallback exhausted OR permanent error classified

State Descriptions

State	What happens
`INIT`	Initialize: set up workspace, validate task definition, allocate resources, check dependencies
`GATHER`	Collect inputs: dependency outputs, context snapshots, relevant memory, prior thought chains
`ANALYZE`	Examine: assess complexity, identify risks, check preconditions, estimate effort
`PLAN`	Design: create execution plan, resolve dependency order, set acceptance criteria, assign agent types
`APPLY`	Execute: assign to agent pool, run phase work, track progress, write checkpoints
`VERIFY`	Check: run acceptance criteria, lint, tests, proof generation
`DONE`	Close: writeback results, update task status, seal audit trail, release agents
`RETRY`	On failure: classify error → backoff → re-enter appropriate state

Checkpointing

Long-running tasks write checkpoints at every phase boundary. On server restart, tasks resume from the last checkpoint instead of restarting from scratch. Checkpoint payload: { current_phase, intermediate_results, agent_assignments, elapsed_time }.

Eisenhower Matrix Priority

Tasks carry a 2×2 urgency/importance priority code:

Priority value	Grid position	Execution policy
`urgent_important`	Urgent + Important	Execute immediately, block other work if necessary
`not_urgent_important`	Not Urgent + Important	Execute in current cycle, normal queue
`urgent_not_important`	Urgent + Not Important	Execute soon, but do not block important work
`not_urgent_not_important`	Not Urgent + Not Important	Backlog — execute only when promoted by PM

Priority influences agent pool allocation strategy and position in execution queues.

Agent Pool Allocation Strategies

Five distribution strategies for assigning tasks to agent pools:

Strategy	Algorithm	Use case
`FIFO`	First-in, first-out queue; arrival order determines execution order	Batch processing, equal-priority work
`PRIORITY_QUEUE`	Min-heap on priority score; highest priority dequeued first	Mixed-priority task sets
`ROUND_ROBIN`	Rotate through available agent slots in circular order	Load balancing, throughput
`LEAST_LOADED`	Assign to agent with fewest active tasks at assignment time	Heterogeneous agent capacities
`CAPACITY_AWARE`	Factor in agent type capabilities + current load + history	Complex multi-type pools

Auto-scaling: pool size adjusts upward when queue depth exceeds threshold; scales down when queue empties and idle timeout expires.

Writeback Contract Enforcement

Every completed task must produce (by convention):

Required:
  task_update(task_id, { status: "done", progress: 100, summary: "..." })
  thought_record({ task_id, type: "reflection", content: "...", branch, commit_sha, tests_run, blockers })

Optional but recommended:
  memory_pack(session_id)    — compress working memory into proof store

Enforcement level: convention, not runtime block.

The task_update and thought_record tools are available in the MCP surface. Agents that skip writeback are NOT blocked at execution time. A post-execution orphan scan detects agents that terminated without writeback and logs warnings. No automatic rollback is applied. Treat writeback as a required professional norm, not a system invariant enforced by a runtime gate.

Task Lifecycle: Create → Assign → Execute → Writeback → Close

1. CREATE
   tool: task_create(title, description, priority, project_id, dependencies)
   → Validates dependencies exist
   → Assigns initial status: "todo"
   → Records creation in audit_log

2. ASSIGN
   tool: gsd_agent_spawn(task_id, agent_type, pool)
   → Allocates agent ID (planning-level; no OS process started yet)
   → Records pool assignment
   → Parent creates sub-agent process with: agent_id, worktree, writeback contract, skill refs

3. EXECUTE
   → Sub-agent runs assigned skill workflow
   → GSD state machine advances: INIT → GATHER → ANALYZE → PLAN → APPLY
   → Checkpoints written at phase boundaries
   → Phase results passed between phases

4. WRITEBACK
   → Sub-agent calls task_update (status, progress, summary)
   → Sub-agent calls thought_record (reflection with task_id, branch, commit SHA, tests, blockers)
   → Optional: memory_pack to compress session into proof store

5. CLOSE
   → GSD advances: VERIFY → DONE
   → Audit trail sealed (merkle_finalize)
   → Agent ID released
   → Parent workflow notified of completion
   → Task status set to "done" in DB

Multi-Phase Workflow Structure

A task can spawn a multi-phase workflow with specialized agents per phase:

Workflow
  ├── Phase 1: audit     → research agent
  ├── Phase 2: contract  → roadmap agent
  ├── Phase 3: execution packet → planning agent
  ├── Phase 4: implementation  → coder agent
  └── Phase 5: verification    → reviewer agent

Each phase: gets agent pool allocation → runs via sub-agent spawning → reports results to workflow → triggers next phase on success.

Error Recovery

4-step failure recovery:

1. CLASSIFY
   Transient:  timeout, rate-limit exceeded, network reset, ECONNRESET
   Permanent:  invalid input, missing dependency, auth failure, disk full

2. RETRY (transient only)
   Exponential backoff: base 100ms, multiplier 2×, max 3 attempts
   Jitter: ±20% of delay to prevent thundering herd

3. FALLBACK (retries exhausted)
   Try simpler execution path or partial completion
   e.g., skip optional phases, reduce scope of APPLY

4. ESCALATE (fallback failed)
   Mark task as BLOCKED
   Record error details in thought_record
   Notify parent workflow
   Emit task.blocked event (triggers webhooks/notifications)