Graph Execution

---
name: graph-execution
description: Decompose approved context, dispatch ready graph nodes, or execute an owned task through the shared core.
---

# 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, require the active adapter to apply its resolved model/effort on the actual delegated context and persist `harness.model-dispatch/v1`; a tier label or silent host default is not effective routing.

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 select the relevant neutral playbook: discovery-to-graph, task-dispatch, context-routing, model-routing, or parallel-execution. Load only pinned context, pending-work authority, the 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 subagents only when current capability evidence permits it. Preserve dependency readiness, exclusive ownership, isolation evidence, routing escalation triggers, reviewer independence, and orchestrator-only graph mutation. Enforce `../../../docs/EXECUTION-BUDGET.md`: reconcile goal-lineage counters before another cycle or context expansion, never reset them by changing model/agent/task/review/decomposition/session, and persist evidence plus `stop-and-replan` at a ceiling. 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.