Graph Execution

---
name: graph-execution
description: Use to decompose approved context, dispatch ready task nodes, or execute a task under exclusive ownership.
---

# Graph execution

Apply `../../../docs/ADAPTIVE-EXECUTION.md`: lane and assurance are orthogonal; resume probes real state before artifacts; same-context nodes use inline spec/transition; packets exist only for actual separate consumers; planned units target 15–30 active minutes; tests climb the five-rung ladder; and in-scope technical recovery needs no fresh approval.

After verification, for `assurance: light|full` only, automatically launch the distinct reviewer in a fresh context—prefer a proven subagent—and send only the pinned SPEC-led packet, never prompt or conversation memory. Same-context review is invalid.

Every technical event is persisted in a new `TASK-GRAPH.md` revision before it is reported: dispatch/start, material progress, dependency changes, block/unblock, remediation, completion, lease/context changes, and newly ready nodes. Never record technical movement only in `PENDING.md`; revise pending state only for a related human action or macro outcome and backlink the new graph revision. Before graph creation or dispatch, follow `writing-plans`: non-simple work requires a ready implementation plan and every node requires a self-contained executable task spec. A specialist executes that spec; contradictions, missing decisions/dependencies/paths, unevaluable acceptance, or materially oversized work return `needs-replan` rather than improvisation. Code behavior and bug-fix tasks also load `test-driven-task`; completion requires meaningful RED before production code, GREEN with the same focused test, and proportional regression evidence. When automatic model routing is human-approved, do not stop at `model_tier`: resolve the current Codex model/effort, pass both into the actual task/message/subagent dispatch, and pin adapter confirmation through `harness.model-dispatch/v1` before activation. Same-context self-switch claims and silent host defaults are invalid.

For a first-call status or resume, follow `../../../harness/playbooks/status-resume.md` before any broad scan. `PENDING.md` owns human actions and macro incomplete areas; `TASK-GRAPH.md` owns technical order, dependencies, and execution. For user-pending questions, report human-owned items first and group human/technical pending items by workstream. Otherwise read only the relevant neutral playbook: `discovery-to-graph.md`, `task-dispatch.md`, `context-routing.md`, `model-routing.md`, or `parallel-execution.md`. Load the pinned context revision, pending-work authority, local graph neighborhood, task brief, scoped rules, approved capabilities, approved model-routing revision, and linked execution budget. Prefer the node's `read_set` over a broad scan, lease only its `write_set`, and use its `impact_set` for proportional regression checks. Verify derived relationships in source and record `context_provenance`; an approved, fresh Graphify index may enrich these fields but never becomes a second operational graph. Keep different workstreams in distinct execution contexts except a bounded integration node; create visible threads or internal subagents only when current capability evidence permits it. Respect dependency readiness, exclusive write sets, isolation evidence, routing escalation triggers, and orchestrator-only graph mutation. Enforce `../../../docs/EXECUTION-BUDGET.md`: reconcile the goal-lineage counters before another cycle or context expansion; never reset them by changing model, agent, task, review, decomposition, or session; at a ceiling persist evidence and `stop-and-replan`. Enforce `../../../docs/REVIEW-ROUNDS.md` for every dispatched reviewer: one initial review, at most one focused remediation review, and no third loop. Follow `../../../docs/STATUS-AND-COMPLETION.md` and `../../../docs/contracts/STATUS.md`: explicit status views and milestone closeouts label current stage, progress, continuing-without-user-action work, human and macro pending items from `PENDING.md`, active/ready/blocked nodes and technical pending work from `TASK-GRAPH.md`, blockers, next action, and inspectable paths. Routine progress updates may be concise result/evidence, human action, and next action; do not reread artifacts or create a full status form without a state/status need. Mark passing work `completed`, report it, release ownership, dispatch only nodes whose product and technical gates pass, and run declared assurance review automatically as non-blocking work. Follow `../../../docs/ACCOMPANIED-DELIVERY.md`: demonstrate client milestones and genuinely await approval before affected expansion. Every new spec has explicit completion conditions, mirrored in graph `acceptance_criteria`; current criterion-level, required TDD, and affected-flow evidence must pass before technical completion. Write durable results through shared templates; do not store state inside `.agents/`.