Workflow maps

Every repository-changing workflow starts from an explicit user goal. Bounded work uses its active approved contract; project-backed work retains a local specification and plan, with optional provider mirroring. Git and GitHub prove implementation and delivery.

Routing by work shape

Routing is not an approval gate. When scope expands after work begins, the workflow preserves repository state and reports the handoff. The work then moves through the workflow that matches its new shape instead of silently changing the contract.

Bootstrap

read-only target preflight → gather requirements → research and present complete design →
approve design → refresh collision check → scaffold → run and verify

Bootstrap is greenfield-only. No target write occurs before explicit design approval and a clean collision check. An exact Linear, Plane, or GitHub project may persist the approved design/plan after approval, but is not a write barrier or repository authority.

Validate a user-specified stack directly. Compare alternatives when an unresolved material tradeoff requires a choice; a stack preference is not approval of the complete design.

Build

allocate/resume local run and admit baseline (if mirroring) → local Ideate/Harden →
write `project-spec.md` (and optional bounded mirror sync) → local Plan/Harden →
write `execution-plan.md` (and optional bounded mirror sync) → retain run artifacts →
verified `Stop here`/`Execute`/`Abandon` handoff

The complete specification, including technical details, remains explicitly user-verified through Ideate and Harden. The plan records outcomes, scope, acceptance, verification, material risks, and sequential dependency/parent bindings. Increments remain independently reviewable PRs.

The artifact contract owns local run storage and optional provider profiles. Run IDs remain exact, artifacts are retained, and mirror failures do not replace or invalidate local authority.

Fix

reproduce → prove cause → admit writable target → choose bounded or project-backed delivery

For an understood one-PR fix, present the complete diagnosis, correction, technical consequences, and verification for explicit approval. Then implement, verify, independently review, and submit the PR through bounded delivery. No project manifest or artifact-provider call is needed.

Multi-increment or materially uncertain fixes, exact --run, --project, or --issue selections, and requested coordinated persistence use the project-backed Build sequence. A configured provider alone does not force that route. Source issues remain context, not plans or permission.

Project-backed handoff

Build and project-backed Fix display the complete verified artifacts, run and task identities, dependencies, parent branch/tip, optional mirror status, and exact Execute command. The user may stop, execute, or abandon in natural language. Ambiguous responses ask again; material scope changes return to explicit verification. The Build handoff owns the detailed transition and recovery rules.

Change

classify → scope → repository preflight → execute → verify → review → hand back

Change handles one bounded non-bug enhancement/refactor and has no hard approval gate. It still requires an explicit goal, one coherent PR boundary, verification, smoke testing, and review. It never reads or writes an artifact provider.

Shared execution boundary

Build and project-backed Fix hand approved work to woostack-execute:

1. resolve canonical repository/base and one collision-safe worktree per task;
2. implement inline or delegate where isolation or independent work benefits;
3. run focused verification and the real changed-path smoke test;
4. obtain independent bounded specification validation on the complete uncommitted diff;
5. use woostack-commit only after the diff passes; and
6. independently read the PR/head/base/check/review result back.

Execution stays sequential within a run. Separate runs may proceed concurrently only with disjoint worktrees, branches, and responsibility surfaces. Delegation does not grant a worker provider, commit, posting, or acceptance authority.

Review and corrections

Local Review selects a holistic reviewer for bounded low-risk changes and specialists for risk-bearing or broad changes. One independent adjudicator verifies the candidates. CI and audit retain their specialist coverage, receipt checks, and exact source bindings.

Address-comments investigates every thread, batches coherent corrections and verification, then replies and resolves each thread independently. Unsafe decisions stay open without discarding independent safe work.

Terminal outcomes

Every route returns one of:

• verified reviewed PR or reviewed stack;
• approved handoff before implementation;
• truthful blocker with exact safe resume boundary; or
• explicit abandonment preserving recoverable work and any retained run artifacts.

No woostack development workflow merges.