post-plan-workflow

# 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 ho...