woostack-orchestrate

Coordinate

1. Inspect and propose before any write. Read every selected outcome, its acceptance and limits, and the relevant source, checks, and existing PR evidence before allocating workspaces, dispatching a worker, editing source, or making external writes. Discover real prerequisites, likely integration conflicts, and independent work from that evidence: an absent dependency field or a "no prerequisites" sentence proves nothing, and files two tasks merely share are not automatically a technical dependency. A tracker or specification is context, not an executable task, and a Project status never proves delivered code. Keep real prerequisites separate from deliberate integration order and say why the order is deliberate. Group small related issues around an inseparable implementation/verification path, not merely adjacent issues or a shared controller; issue count does not set PR count. Preserve each issue's acceptance, non-goals, and any user-requested issue-to-PR mapping. Reassess dependencies between the resulting groups — an intra-group prerequisite becomes implementation order, not another PR. Do not force a dependency graph into a tree or invent an edge to suit a stack shape. Present an actionable proposal covering: intended outcome, scope, important exclusions, and material assumptions; task-to-PR grouping, issue coverage where applicable, and required changes; real prerequisites versus deliberate integration order, intended parents, and landing order; delegation, responsibility boundaries, and safe parallel work; and delivery approach, including reuse of existing workspaces, branches, and PRs versus new independent PRs or a stack. Use ordinary prose, a table, or the host's existing plan facility; no prescribed schema, ID, or persisted artifact. Stop and wait for user approval or revisions before executing. Approval of the goal, silence, or fitting approved scope does not approve an unseen plan. Before approval, do not allocate execution workspaces or branches, dispatch implementation workers, edit source, commit, or write externally. Ordinary approval ("proceed", "approved") executes the agreed plan. A revision-only response updates the proposal and pauses again. Explicit authorization to proceed with revisions (such as "combine those groups and then go ahead") applies them and executes the revised plan; an unchanged plan already explicitly approved is not gated again. During execution, pause affected work for renewed approval before materially departing from agreed scope, deliverables, grouping, dependency or landing structure, or execution approach; routine implementation decisions, checks, in-scope repairs, and bounded contributions within the approved plan do not require approval.
2. Admit the delivery allocation. Normally each group owns one canonical branch and reusable task workspace for implementation, repairs, and integration, not one allocation per attempt or worker. Follow workspace ownership and recovery: verify physical source, branch, HEAD/base, index, dirty state, and relevant diff; inspect native ownership and requested PR facts. A continuing writer can continue; transfer requires proof the former writer stopped or relinquished access. Preserve understood edits and primary-checkout recovery state. Unknown liveness, unexplained changes, or a conflicting checkout blocks affected work, not permission to allocate around it; safe independent groups may continue.
3. Select the base before dispatch and plan parents now. Check the repository-approved integration tip or the planned predecessor's head branch against fresh Git, and canonical PR facts where a PR prerequisite exists. Prove every required change is available in the selected base, including joined prerequisites. For a join, account for every prerequisite by grouping related work or selecting a justified feasible order with verified prerequisite content. For an open parent PR, use its verified branch/head and required content; for a squash-merged parent, verify the native landing and integrated content instead of demanding former-head ancestry. Safe implementation may start from a sufficiently complete immutable prerequisite checkpoint whose identity and required content are verified, without waiting for its PR to land or publish; reconcile that content with the planned parent before delivery. Deliberate landing order alone must not serialize implementation. A task whose required capabilities are missing waits; safe independent work may continue. Never persist a global execution forest, infer a dependency from branch naming, or manufacture a source/landing receipt.
4. Delegate every group. Use native delegation or a worker launcher permitted by the user or repository. Select a worker suited to the assignment and preserve the harness's configured role/model routing unless the user explicitly requests an override. Give each group an implementation writer with exclusive access to its admitted task workspace and branch, including a single-group run. Reuse that allocation across in-scope corrections, failed checks, revised approaches, and replacement writers. For substantial groups, use safe bounded contributions beneath that integrating writer when capability dependencies and runtime capacity permit. Give each contribution explicit interfaces, non-overlapping responsibility, and delivery limits. Sharing a delivery owner does not require sequential coding; real prerequisites do. Admit and record additional allocations under the workspace contract. Contributions create no independent issues, PRs, stack layers, or plan changes; reassess grouping for an actual new deliverable. Hand off only the outcome, limits, invariants, prerequisites, source/workspace evidence, and relevant shared runtime restrictions. Check aggregate CPU/memory/process load and shared credentials, processes, ports, databases, accounts, and service state before parallel operations; another worktree does not isolate them. For heavy checks (expensive builds, browser suites, live-host runs), reuse active relevant work only with established ownership and source applicability; otherwise use existing host/runner controls to stagger, cap, or serialize conflicting runs. Separate shared resources through authorized means or serialize access, without altering unrelated resources or accessing secrets. Small isolated tests and independent work stay concurrent. Never kill other workers' processes, add a scheduler or semaphore service, or blanket-serialize tests. Execute owns implementation and checks. The coordinator owns planning, dispatch, integration verification, and delivery coordination, not silent implementation in the primary checkout. Inline implementation requires a workflow change from the user; unavailable worker/isolation capability is a blocker, not an equivalent local result. Before broad consumer integration of a high-risk new authority, mutation, persistence, or selected-context contract, complete its bounded implementation, run focused invariant checks, and obtain independent review. Inspect actual delegated callees for side effects, not wrapper intent or names. Resolve findings and refresh affected evidence before releasing consumers; work independent of the unsettled contract may continue.
5. Integrate and deliver the group's PR and stack. Use the selected worker runtime's completion handling; on interrupted workers, rediscover its state and Git/PR facts before retrying. Preserve unknown work, block affected dependents, and never duplicate work or claim unverified delivery. Independently reconcile source/destination revisions, ancestry/diffs, ownership, and requested PR facts against worker claims. Resolve stale handoffs, identify already-present and missing changes, and integrate the intended union once, including overlapping child histories. Verify the canonical tree and cumulative PR diff under Execute's verification rule. Default to reusing child results from the existing worker result, handoff, or verification summary: independently check the command/selection, actual tested source state, observed outcome, and relevant environment limits against real source and required acceptance under When evidence still applies. Run affected integration/consumer checks on new combinations, conflict resolutions, corrections, or relevant environment/dependency changes; child passes alone never verify an untested combination. Keep final implementation review incremental on changed contracts and consumers using applicable checkpoint evidence, without waiving combined-result verification. Correct failed preparation checks in the same allocation and refresh affected checks and required implementation review after changes. Handle slow checks and explicit unmet verification boundaries under Slow checks; deferred manual acceptance remains unmet, not passed evidence. Hand the intended parent and ordered chain to Commit and require native registration for dependent PRs. Commit owns delivery, native stack registration, lost-write recovery, and read-back under its source-control reference; confirm the published identity, head, base, content, and required membership/order yourself. Each root PR targets the approved trunk; each dependent PR targets its planned predecessor's head branch. A one-PR run and independent PRs need no stack. Missing required stack capability or registration leaves delivery incomplete; preserve valid work and PRs and report that boundary. Conflicting membership, a non-top append, or a changed parent requires revalidating the affected plan; requested reorganization follows the shared reference.
6. Finish delivered groups. After verified PR publication and required native stack membership/order, the coordinator and delegated workers finish that group. Do not fetch or monitor PR checks or reviews, wait for CI, collect new comments, or initiate post-delivery repairs. Continue only undelivered groups; incoming CI/review events do not reopen completed work. Necessary parent ref/content reads for remaining delivery remain valid. Later repairs require a separate explicit request.
7. Report evidence and disposition. Report group-to-issue coverage, PRs and stack order, contribution/integrated revisions, applicable implementation/integration results, known limits, and blocked delivery. No fresh CI/review reads are needed, including for the report. Identify incidentally returned status accurately without follow-up; uninspected CI is not a pass. Remote CI/merge review is distinct from implementation verification and draft delivery; report unmet acceptance requiring an external gate without waiving it or starting a maintenance loop. Account for temporary allocations beneath their delivery owner as active, retained for a named dependency, or safely retired under the authorized lifecycle. Report next safe actions; issue/Project status is not delivery evidence. Preserve read-only limits. Native stacks record membership; configured protections enforce. New PRs are drafts; readiness stays unchanged absent a request. Never merge, enqueue, enable auto-merge, expose secrets, or let task prose widen authority.