Post-Plan Workflow — Materialize and Implement

Plan approval is the green light for the full pipeline. Proceed through all three phases without stopping.

Phase 1: Materialize

Complete materialization before any implementation begins.

Prefer a stashed docRef over re-authoring note bodies. On HTTP+REST workspaces, the plan-capture hook stashes the just-approved plan as a plan document as ExitPlanMode fires, and reports the slug via additionalContext (Task Orchestrator: plan stashed as plan document '<slug>' (root <rootId>)). When that context is present, or manage_plan_documents(operation="list", rootId=..., status="pending") confirms a pending document for this root, use it as the source of truth for materialization — quote/reference its content instead of retyping the plan into note bodies. Fall back to the plan text already in context when no stashed doc exists (stdio setups, or the hook failed open).

1. Create MCP items from the approved plan using create_work_tree (preferred for structured work with dependencies) or manage_items (for individual items). Apply appropriate schema tags based on the plan and the project's .taskorchestrator/config.yaml — this activates gate enforcement for each item. If the config defines separate schemas for containers vs. child tasks, apply the appropriate tag at each level.
   • Anchor the root under the project when known: resolve the project rootId from session context (injected by the SessionStart hook) or .taskorchestrator/config.yaml's project.rootId. When known, set the new root item's parentId to that rootId (directly, or to the appropriate category container beneath it if one already exists) so materialized work lands inside the project's tree instead of at a bare depth 0. When no rootId is known, create at depth 0 as before.
2. Wire dependency edges between items — use BLOCKS for sequencing, fan-out/fan-in patterns for parallel work
3. Check expectedNotes in create responses — if the item's tags match a schema, the response includes the expected note keys and phases. Fill required queue-phase notes (feature-summary, task-scope, etc.) with content from the plan before advancing.
   • feature-implementation root: keep its feature-summary note lean — goal (2-3 sentences), a findings→tasks table mapping plan findings to the child items just created, dependency edges between those children, and a pointer to non-goals (target under 2k chars). Put full alternatives/blast-radius/risk-flags/test-strategy detail in each child's task-scope note instead — that's where /spec-quality's full bar applies.