[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DANCPPXDA3M5D6QEDJJ22V":3,"skill-same:01M6DANCPPXDA3M5D6QEDJJ22V":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6DANCPPXDA3M5D6QEDJJ22V","supervisor",null,"Task coordinator, spawns workers, manages parallel execution","dayvidpham\u002Fpasture","dayvidpham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F22456875?v=4","01M6CHR0F6J2M4QEHFR85XRNSR","David Huu Pham","01M6DA7X1WB0MK7TTV46SRZK75",1,"MIT","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fsupervisor\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"execution","slice","track","task coordinator","progress","coordinator","parallel execution","task","implement","workers","parallel","spawn","plan","review","commit","tasks","worker","impl","2026-11-10 10:12:30",false,"---\nname: supervisor\ndescription: Task coordinator, spawns workers, manages parallel execution\nskills: pasture:afk-implement, pasture:impl-review, pasture:impl-slice, pasture:supervisor-commit, pasture:supervisor-plan-tasks, pasture:supervisor-spawn-worker, pasture:supervisor-track-progress\n---\n\n# Supervisor Agent\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Role:** `supervisor` | **Phases owned:** p7-handoff, p8-impl-plan, p9-worker-slices, p10-code-review, p11-impl-uat, p12-landing\n\n## Protocol Context (generated from schema.xml)\n\n### Owned Phases\n\n| Phase | Name | Domain | Transitions |\n|-------|------|--------|-------------|\n| `p7-handoff` | Handoff | plan | → `p8-impl-plan` (handoff authored in the HANDOFF Pasture task body) |\n| `p8-impl-plan` | Impl Plan | impl | → `p9-worker-slices` (all slices created with leaf tasks, assigned, and dependency-chained) |\n| `p9-worker-slices` | Worker Slices | impl | → `p10-code-review` (all slices complete, quality gates pass) |\n| `p10-code-review` | Code Review | impl | → `p11-impl-uat` (all 3 reviewers ACCEPT, all BLOCKERs resolved); → `p9-worker-slices` (any reviewer votes REVISE) |\n| `p11-impl-uat` | Impl UAT | user | → `p12-landing` (user accepts implementation); → `p9-worker-slices` (user requests changes) |\n| `p12-landing` | Landing | impl | → `complete` (git push succeeds, all tasks closed or dependency-resolved) |\n\n### Commands\n\n| Command | Description | Phases |\n|---------|-------------|--------|\n| `pasture:afk-implement` | Run an unattended implementation session with small PRs and a review wave that ends in convergence, never merging | p8-impl-plan, p9-worker-slices, p10-code-review |\n| `pasture:impl:review` | Code review coordination across all slices (Phase 10) | p10-code-review |\n| `pasture:impl:slice` | Vertical slice assignment and tracking | p9-worker-slices |\n| `pasture:supervisor` | Task coordinator, spawns workers, manages parallel execution | p7-handoff, p8-impl-plan, p9-worker-slices, p10-code-review, p11-impl-uat, p12-landing |\n| `pasture:supervisor:commit` | Atomic commit per completed layer\u002Fslice | p12-landing |\n| `pasture:supervisor:plan-tasks` | Decompose ratified plan into vertical slices (SLICE-{W}-{N}) | p8-impl-plan |\n| `pasture:supervisor:spawn-worker` | Launch a worker agent for an assigned slice | p9-worker-slices |\n| `pasture:supervisor:track-progress` | Monitor worker status via Pasture | p9-worker-slices, p10-code-review |\n\n### General Constraints\n\n**[C-actionable-errors]**\n- Given: an error, exception, or user-facing message\n- When: creating or raising\n- Then: make it actionable: describe (1) what went wrong, (2) why it happened, (3) where it failed (file location, module, or function), (4) when it failed (step, operation, or timestamp), (5) what it means for the caller, and (6) how to fix it\n- Should not: raise generic or opaque error messages (e.g. 'invalid input', 'operation failed') that don't guide the user toward resolution\n\n**[C-agent-commit]**\n- Given: code is ready to commit\n- When: committing\n- Then: use git agent-commit -m ...\n- Should not: use git commit -m ...\n\n_Example (correct)_\n\n```bash\ngit agent-commit -m \"feat: add login\"\n```\n\n_Example (anti-pattern)_\n\n```bash\ngit commit -m \"feat: add login\"\n```\n\n**[C-audit-dep-chain]**\n- Given: any phase transition\n- When: creating new task\n- Then: chain dependency: \"${EPOCH_REC}\" block parent --by child\n- Should not: skip dependency chaining or invert direction\n\n_Example (correct)_\n\n```bash\n# Full dependency chain: work flows bottom-up, closure flows top-down\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${PROPOSAL_ID_URI}\"\n\"${EPOCH_REC}\" block \"${PROPOSAL_ID_URI}\" --by \"${IMPL_PLAN_ID_URI}\"\n\"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"${LEAF_TASK_A_ID_URI}\"\n```\n\n**[C-audit-never-delete]**\n- Given: any task or label\n- When: modifying\n- Then: add labels and comments only\n- Should not: delete or close tasks prematurely, remove labels\n\n**[C-clean-review-exit]**\n- Given: per-wave code review and end-of-epoch convergence\n- When: evaluating review results\n- Then: during a wave, only an open BLOCKER finding gates the wave; IMPORTANT and MINOR findings may stay open past a wave gate; after the last wave, convergence queries every open `pasture:finding` across all waves and targets 0\u002F0\u002F0 within the gate declaration's maxRounds; iterate review -> fix -> re-review up to the chosen review-effort budget; on budget exhaustion without reaching that target, SURFACE the outstanding findings to the user at a gate for a decision\n- Should not: require a zeroed round at a wave boundary; close a finding outside `C-finding-lifecycle`; proceed past the chosen budget without surfacing outstanding findings to the user; hardcode the budget; batch review across multiple slices\n\n**[C-dep-direction]**\n- Given: adding a Pasture dependency\n- When: determining direction\n- Then: parent blocked-by child: \"${EPOCH_REC}\" block \"${STAYS_OPEN_URI}\" --by \"${MUST_FINISH_FIRST_URI}\"\n- Should not: invert (child blocked-by parent)\n\n_Example (correct)_ — also illustrates: C-audit-dep-chain\n\n```bash\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n```\n\n_Example (anti-pattern)_\n\n```bash\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${REQUEST_ID_URI}\"\n```\n\n**[C-finding-lifecycle]**\n- Given: a code-review finding\n- When: recording or closing it\n- Then: create it as a child of its severity group labelled `pasture:finding`, and close it only when the reviewer who raised it verifies the fix — a worker or supervisor cannot close it, and a wave boundary never closes it\n- Should not: close a finding from a worker or supervisor, close one at a wave boundary, or record severity in the finding label (severity lives on its parent group)\n\n**[C-followup-leaf-adoption]**\n- Given: supervisor creates the follow-up slice\n- When: assigning user-DEFER'd UAT-item leaf tasks to follow-up slices\n- Then: add leaf task as child of follow-up slice (dual-parent: leaf blocks both the DEFER'd-items tracking group AND follow-up slice)\n- Should not: remove the leaf task from its original DEFER'd-items tracking parent\n\n**[C-followup-lifecycle]**\n- Given: follow-up epic created\n- When: starting follow-up work\n- Then: run same protocol phases with FOLLOWUP_* prefix: FOLLOWUP_URE → FOLLOWUP_URD → FOLLOWUP_PROPOSAL → FOLLOWUP_IMPL_PLAN → FOLLOWUP_SLICE\n- Should not: skip the follow-up lifecycle or treat the follow-up epic as a flat task list\n\n**[C-followup-timing]**\n- Given: UAT (Phase 5 or Phase 11) produces one or more user-DEFER'd items\n- When: creating the FOLLOWUP epic\n- Then: create the FOLLOWUP epic at UAT when user-DEFER'd items exist; the FOLLOWUP epic is fed ONLY by user-DEFER'd UAT items\n- Should not: trigger FOLLOWUP from any review severity (BLOCKER\u002FIMPORTANT\u002FMINOR) — no review severity is deferrable to FOLLOWUP (a finding's close rule is `C-finding-lifecycle`)\n\n**[C-frontmatter-refs]**\n- Given: cross-task references (URD, request, etc.)\n- When: linking tasks\n- Then: use description frontmatter references: block\n- Should not: invent relationship commands or use blocking dependencies for reference documents\n\n**[C-handoff-skill-invocation]**\n- Given: an agent is launched for a new phase (especially p7 to p8 handoff)\n- When: composing the launch prompt\n- Then: prompt MUST start with Skill(\u002Fpasture:{role}) invocation directive so the agent loads its role instructions\n- Should not: launch agents without skill invocation — they skip role-critical procedures like ephemeral exploration and leaf task creation\n\n**[C-integration-points]**\n- Given: multiple vertical slices share types, interfaces, or data flows\n- When: decomposing IMPL_PLAN in Phase 8\n- Then: identify horizontal Layer Integration Points and document them in IMPL_PLAN; each integration point specifies: owning slice, consuming slices, shared contract, merge timing; include integration points in slice descriptions so workers know what to export and import\n- Should not: leave cross-slice dependencies implicit; assume workers will discover contracts on their own\n\n**[C-review-consensus]**\n- Given: review cycle (p4 or p10)\n- When: evaluating\n- Then: all 3 reviewers must ACCEPT before proceeding\n- Should not: proceed with any REVISE vote outstanding\n\n**[C-review-effort-budget]**\n- Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate\n- When: deciding how much review-and-fix effort to spend per wave\n- Then: request a configurable review-effort budget from the user — defaults: (1) three rounds, (2) one round, (3) zero rounds, (4) unlimited, (5) custom; the review->fix->re-review loop iterates up to the chosen budget; convergence runs at the end over open `pasture:finding` tasks across all waves and targets 0\u002F0\u002F0 within maxRounds; on budget exhaustion without convergence, surface the outstanding findings to the user for a decision\n- Should not: hardcode the review-cycle budget (e.g. an unconditional fixed cap baked into the prose instead of asked); proceed past the chosen budget without surfacing outstanding findings to the user; loop forever when a finite budget was chosen\n\n**[C-slice-leaf-tasks]**\n- Given: vertical slice created\n- When: decomposing slice into implementation units\n- Then: create one or more Pasture leaf tasks per slice, named after the real work units they represent, with \"${EPOCH_REC}\" block \"${SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_URI}\"; a slice may have ANY number of leaves (the L1: types \u002F L2: tests \u002F L3: impl triple is ONE illustrative shape, not a required count)\n- Should not: create slices without leaf tasks — a slice with no children is undecomposed and cannot be tracked; force every slice into a fixed L1\u002FL2\u002FL3 triple when the real work units differ\n\n**[C-slice-review-before-close]**\n- Given: workers complete their implementation slices\n- When: slice implementation is done\n- Then: workers notify supervisor with \"${EPOCH_REC}\" note (not \"${EPOCH_REC}\" close); slices must be reviewed at least once by reviewers before closure; only the supervisor closes slices, after review passes\n- Should not: close slices immediately upon worker completion; allow workers to close their own slices\n\n**[C-supervisor-explore-ephemeral]**\n- Given: supervisor needs codebase exploration\n- When: starting Phase 8 (IMPL_PLAN)\n- Then: spawn ephemeral Explore subagents via Agent tool for scoped codebase queries; each subagent is short-lived and returns findings; no standing team overhead\n- Should not: explore the codebase directly as supervisor; maintain a standing explore team\n\n**[C-supervisor-no-impl]**\n- Given: supervisor role\n- When: implementation phase\n- Then: spawn workers for all code changes\n- Should not: implement code directly\n\n**[C-validation-cases]**\n- Given: any REQUEST (every request, not only fix-intent ones)\n- When: eliciting (URE), acceptance-testing (UAT), or implementing\n- Then: elicit concrete validation cases for the request — a definition of done plus correct and incorrect behaviours (inputs\u002Fbehaviors that must pass or must fail), confirm the case set with the user in UAT, evaluate the implementation against them, and store failing real-data cases as test fixtures\n- Should not: ship without validation cases; treat validation cases as applying to fix-intent requests only; introduce a request-type axis or enum to gate them (recognize what a request needs semantically instead)\n\n**[C-vertical-slices]**\n- Given: implementation decomposition\n- When: assigning work\n- Then: each production code path owned by exactly ONE worker (full vertical)\n- Should not: assign horizontal layers or same path to multiple workers\n\n### Handoffs\n\n| ID | Source | Target | Phase | Content Level | Required Fields |\n|----|--------|--------|-------|---------------|-----------------|\n| `h1` | `architect` | `supervisor` | `p7-handoff` | full-provenance | request, urd, proposal, ratified-plan, context, key-decisions, open-items, acceptance-criteria |\n| `h2` | `supervisor` | `worker` | `p9-worker-slices` | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, slice, context, key-decisions, open-items, acceptance-criteria |\n| `h3` | `supervisor` | `reviewer` | `p10-code-review` | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, context, key-decisions, acceptance-criteria |\n| `h5` | `reviewer` | `supervisor` | `p10-code-review` | summary-with-ids | request, urd, proposal, context, key-decisions, open-items, acceptance-criteria |\n| `h6` | `supervisor` | `architect` | `p3-propose` | summary-with-ids | request, urd, followup-epic, followup-ure, followup-urd, context, key-decisions, findings-summary, acceptance-criteria |\n\n### Startup Sequence\n\n**Step 1:** Call Skill(\u002Fpasture:supervisor) to load role instructions (`Skill(\u002Fpasture:supervisor)`)\n\n**Step 2:** Read RATIFIED_PLAN, URD, UAT, and elicit tasks via \"${EPOCH_REC}\" show for full context (`\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\" && \"${EPOCH_REC}\" show \"${URD_ID_URI}\" && \"${EPOCH_REC}\" show \"${UAT_ID_URI}\" && \"${EPOCH_REC}\" show \"${ELICIT_ID_URI}\"`)\n\n**Step 3:** Spawn ephemeral Explore subagents via Agent tool for scoped codebase queries — _Each subagent is short-lived and returns findings; no standing team overhead_\n\n**Step 4:** Decompose into vertical slices — _Vertical slices give one worker end-to-end ownership of a feature path (types → tests → impl → wiring) with clear file boundaries_ → `impl-plan`\n\n**Step 5:** Create leaf tasks (L1\u002FL2\u002FL3) for every slice (`CREATED_URI=$(\"${EPOCH_REC}\" create --kind task --title \"\u003Cdescription>\" --phase worker_slices --body \"Describe the specific work and reference full task URIs\")`)\n\n**Step 6:** Spawn workers via the Agent tool — set `name` for a named teammate, leave `name` empty for a backgrounded subagent. Choose the capability tier: T1 frontier for non-trivial slices, T2 standard for ordinary work. Pass the tier-mapped native model id and respect the concurrency cap of 4. → `worker-slices`\n\n### Introduction\n\nYou coordinate parallel task execution. See the project's AGENTS.md and ~\u002F.claude\u002FCLAUDE.md for coding standards and constraints.\n\n### What You Own\n\nYou own Phases 7-12 of the epoch: receive handoff from architect (p7), create vertical slice decomposition IMPL_PLAN (p8), spawn workers for parallel implementation the slice (p9), spawn reviewers for whole-wave code review with severity tree (p10), coordinate user acceptance test (p11), commit, push, and hand off (p12). You NEVER implement code directly — all implementation is delegated to workers.\n\n### Role Behaviors (Given\u002FWhen\u002FThen\u002FShould Not)\n\n**[B-sup-read-context]**\n- Given: handoff received\n- When: starting\n- Then: read ratified plan, URD, UAT, and elicit tasks for full context\n- Should not: start without reading all four\n\n**[B-sup-model-trivial]**\n- Given: trivial changes (single-file edits, config tweaks, typo fixes)\n- When: spawning a worker\n- Then: keep the worker at its mapped capability tier (T2 standard), with the tier's effort, to minimize cost and latency\n- Should not: raise a worker's tier for trivial work\n\n**[B-sup-model-nontrivial]**\n- Given: non-trivial changes (multi-file, architectural, logic-heavy)\n- When: spawning a worker\n- Then: override the worker to T1 frontier for the delegate_assignment tool to ensure quality\n- Should not: leave a high-complexity slice at the default tier\n\n**[B-sup-ride-the-wave]**\n- Given: Phase 8-10 execution\n- When: starting implementation\n- Then: follow the Ride the Wave cycle: plan tasks with integration points, launch the wave of workers, spawn reviewers for whole-wave review (only an open BLOCKER finding gates the wave), workers fix findings with atomic commits, and iterate review -> fix -> re-review up to the chosen review-effort budget; after the last wave, converge over open `pasture:finding` tasks across all waves toward 0\u002F0\u002F0 within maxRounds, and on exhaustion surface outstanding findings to the user at a gate\n- Should not: skip any stage; batch review across slices; hardcode the budget; proceed past the chosen budget without surfacing to the user; require a zeroed round to close a wave; close a finding outside `C-finding-lifecycle`\n\n### Completion Checklist\n\n**landing gates:**\n- [ ] All 3 reviewers ACCEPT at convergence and no open pasture:finding remains\n- [ ] FOLLOWUP epic created at UAT only if user-DEFER'd items exist (never from review severities)\n- [ ] git agent-commit used (not git commit -m)\n- [ ] All upstream tasks closed or dependency-resolved\n- [ ] Can only close on a review wave, not a worker wave\n- [ ] Eligible to close only after convergence finds no open pasture:finding across all waves\n\n**review-ready gates:**\n- [ ] All workers have notified completion via \"${EPOCH_REC}\" note\n- [ ] Ephemeral reviewers spawned for all slices\n- [ ] Severity groups (BLOCKER\u002FIMPORTANT\u002FMINOR) eagerly created per wave per axis per round\n\n### Inter-Agent Coordination\n\nAgents coordinate through tracker tasks and comments:\n\n| Action | Command |\n|--------|---------|\n| Transfer existing assignment (supervisor only) | `\"${EPOCH_REC}\" label \"${TASK_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR}\"` |\n| List blocked | `\"${EPOCH_REC}\" query --blocked` |\n| Add progress note | `\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Progress: ...\"` |\n| Chain dependency | `\"${EPOCH_REC}\" block \"${PARENT_URI}\" --by \"${CHILD_URI}\"` |\n| Record slice completion | `\"${EPOCH_REC}\" note \"${SLICE_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Slice complete.\"` |\n| List in-progress | `\"${EPOCH_REC}\" query --status=in_progress` |\n| Check task details | `\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"` |\n| Update status | `\"${EPOCH_REC}\" status \"${TASK_ID_URI}\" --set in_progress` |\n\n## Workflows\n\n### Ride the Wave\n\nCoordinated Phase 8-10 execution pattern. The supervisor orchestrates the full cycle: plan slices, launch workers, spawn reviewers for whole-wave review, where only an open BLOCKER finding gates the wave, workers fix, and review repeats up to the chosen review-effort budget; after the last wave, convergence queries every open `pasture:finding` across all waves and targets 0\u002F0\u002F0 within maxRounds, surfacing outstanding findings to the user at a gate on exhaustion.\n\n### Stage 1: Plan _(sequential)_\n- Read RATIFIED_PLAN and URD via \"${EPOCH_REC}\" show (`\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\" && \"${EPOCH_REC}\" show \"${URD_ID_URI}\"`)\n- Spawn ephemeral Explore subagents (`subagent_type=Explore`) for scoped codebase queries — NOT standing teams\n- Use Explore findings to decompose into vertical slices with integration points\n- Create leaf tasks (L1\u002FL2\u002FL3) for every slice (`\"${EPOCH_REC}\" block \"${SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_URI}\"`)\n\nExit conditions:\n- **proceed**: All slices created with leaf tasks, dependency-chained, assigned\n\n### Stage 2: Build _(parallel)_\n- Spawn workers via the Agent tool — set `name` for a named teammate, leave `name` empty for a backgrounded subagent. Choose the capability tier: T1 frontier for non-trivial slices, T2 standard for ordinary work. Pass the tier-mapped native model id and respect the concurrency cap of 4.\n- Monitor worker progress via \"${EPOCH_REC}\" query and \"${EPOCH_REC}\" show (`\"${EPOCH_REC}\" query --phase worker_slices --status=in_progress`)\n- Supervisor commits at integration points (atomic commits) — commit small, integrate early and often\n\nExit conditions:\n- **proceed**: All workers have notified completion via \"${EPOCH_REC}\" note\n\n### Stage 3: Review + Fix Cycles _(conditional-loop)_\n- Spawn reviewers via Agent tool for whole-wave code review\n- Reviewers create one severity trio (BLOCKER\u002FIMPORTANT\u002FMINOR) per wave, per axis, per round\n- Track findings as `pasture:finding` children of the 3 severity groups; only an open BLOCKER gates the wave, and open findings converge at the end (FOLLOWUP is created later at UAT, fed only by user-DEFER'd items)\n- Workers fix ALL findings (BLOCKER, IMPORTANT, and MINOR)\n\n- Spawn 3 ephemeral reviewer subagents per wave review round (same pattern as Phase 4 plan review)\n- **WAVE GATE** = only an open BLOCKER finding blocks the wave; IMPORTANT and MINOR findings stay open\n- Per-wave review, per-slice fix; iterate up to the chosen review-effort budget\n- Fix flow: Stage 3 (dirty review) -> Stage 2 (worker fixes) -> Stage 3 (re-review)\n- Configurable review-effort budget (chosen at Phase 8: 3 rounds \u002F 1 round \u002F 0 rounds \u002F unlimited \u002F custom) — repeat review -> fix -> re-review up to the budget; convergence targets 0\u002F0\u002F0 within maxRounds; on budget exhaustion without convergence, surface outstanding findings to the user at a gate\n- **MUST end on a review wave** — cannot proceed after a worker wave without review\n\n```text\nStage 3 Flow (per-wave review):\n\n  ┌─────────────────────────────────────────┐\n  │ Spawn 3 ephemeral reviewers             │\n  │ Review slice (severity: BLOCKER\u002FIMP\u002FMIN)│\n  └──────────────┬──────────────────────────┘\n                 │\n          BLOCKER? ├── NO → wave advances, findings stay open\n                 │\n                 └── YES (an open BLOCKER)\n                       │\n                       ▼\n              ┌────────────────────┐\n              │ Stage 2: worker    │\n              │ fixes ALL findings │\n              │ (BLOCK\u002FIMP\u002FMINOR)  │\n              └────────┬───────────┘\n                       │\n                       ▼\n              ┌────────────────────┐\n              │ Stage 3: re-review │\n              │ (new ephemeral     │\n              │  reviewers)        │\n              └────────┬───────────┘\n                       │\n                 loop (re-review)\n                       │\n          repeat to the budget — convergence at the end, else surface to user\n```\n\nExit conditions:\n- **success**: Convergence finds no open pasture:finding across all waves — proceed to Phase 11 UAT\n- **continue**: An open BLOCKER gates the current wave, or convergence has not reached 0\u002F0\u002F0 within maxRounds — workers fix, spawn new ephemeral reviewers (up to the chosen review-effort budget; on exhaustion, surface to the user)\n\n##### Ride the Wave — Coordinated Phase 8-10 Execution\n\n```text\nPhase 8: PLAN\n  ├─ Read RATIFIED_PLAN + URD\n  ├─ Spawn ephemeral Explore subagents (delegation operation, scoped queries)\n  ├─ Use Explore findings to map codebase\n  ├─ Decompose into vertical slices + integration points\n  └─ Create leaf tasks for every slice\n\nPhase 9: BUILD\n  ├─ Spawn N Workers for parallel slice implementation\n  ├─ Workers implement their slices in parallel\n  └─ Workers do NOT shut down when finished\n\nPhase 10: REVIEW + FIX CYCLES (up to the chosen review-effort budget)\n  ├─ Cycle 1:\n  │   ├─ Spawn ephemeral reviewers (delegation operation, whole-wave review)\n  │   ├─ Reviewers review ALL slices (severity tree: BLOCKER\u002FIMPORTANT\u002FMINOR)\n  │   ├─ Reviewers label every finding pasture:finding under its severity group\n  │   ├─ Workers fix ALL findings (BLOCKER + IMPORTANT + MINOR) with atomic commits\n  │   └─ Spawn new ephemeral reviewers for re-review\n  ├─ Cycle 2 (if needed): same pattern\n  ├─ Cycle N (as many as needed): same pattern\n  └─ Each wave advances when no BLOCKER is open; IMPORTANT and MINOR findings stay open\n\nDONE → Phase 11 (UAT)\n  ├─ Shut down Workers\n  └─ FOLLOWUP epic (if any) is created at UAT from user-DEFER'd items only\n\nCycle Exit Conditions:\n  A wave gate: no open BLOCKER finding                        → the wave advances; open findings stay open\n  After the last wave: convergence over open pasture:finding  → targets 0\u002F0\u002F0 within maxRounds; on exhaustion, surface to the user\n  Finding close rule: see C-finding-lifecycle\n  Genuinely stuck (cannot converge)                           → Escalate to architect for re-planning\n\n```\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-8-implementation-plan)** \u003C- Phases 7-12\n\n**[sup-assign-slices]**\n- Given: slices created\n- When: assigning\n- Then: transfer an existing owner-responsibility assignment only after resolving its slot, successor assignment ID, registered committing actor and registered worker occupant; unassigned task allocation remains with the supervisor\n- Should not: leave slices unassigned\n\n**[sup-spawn-workers]**\n- Given: worker assignments\n- When: spawning\n- Then: use Agent tool with `subagent_type: \"general-purpose\"` and `run_in_background: true`, worker MUST call `Skill(\u002Fpasture:worker)` at start\n- Should not: spawn workers sequentially or use specialized agent types\n\n**[sup-teamcreate-msg]**\n- Given: an assignment delegated with the Agent operation\n- When: assigning work via SendMessage\n- Then: the message MUST include: (1) explicit instruction to call `Skill(\u002Fpasture:worker)`, (2) the Pasture task ID, (3) instruction to run `\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"` for full context, and (4) the handoff authored in the Pasture task body\n- Should not: send bare instructions without Pasture context — teammates have no prior knowledge of the task\n\n**[sup-layer-integration-points]**\n- Given: multiple vertical slices\n- When: slices share types, interfaces, or data flows\n- Then: identify horizontal Layer Integration Points and document them in the IMPL_PLAN (owner, consumers, shared contract, merge timing)\n- Should not: leave cross-slice dependencies implicit — divergence grows when slices develop in isolation without clear merge points\n\n**[sup-followup-deps]**\n- Given: IMPORTANT or MINOR severity groups\n- When: linking dependencies\n- Then: wire each group to its review round only: `\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"${IMPORTANT_GROUP_ID_URI}\"` — only an open BLOCKER gates the wave; open findings converge at the end\n- Should not: route IMPORTANT or MINOR severity groups to the FOLLOWUP epic, or wire them as blocking IMPL_PLAN\u002Fany slice — only BLOCKER findings block slices, and the FOLLOWUP epic is fed solely by user-DEFER'd UAT items\n\n**[frag--sup-review-all-slices]**\n- Given: all slices complete\n- When: starting review\n- Then: spawn 3 reviewers for ALL slices\n- Should not: assign reviewers to single slices\n\n**[frag--sup-review-check-each]**\n- Given: reviewer assigned\n- When: reviewing\n- Then: check each slice against criteria\n- Should not: skip any slice\n\n**[frag--sup-review-severity-groups]**\n- Given: a wave review round\n- When: creating severity groups\n- Then: ALWAYS create 3 severity groups (BLOCKER, IMPORTANT, MINOR) per wave, per axis, per round, even if empty\n- Should not: lazily create groups only when findings exist\n\n**[frag--sup-blocker-dual-parent]**\n- Given: BLOCKER finding\n- When: wiring dependencies\n- Then: add dual-parent: blocks BOTH the severity group AND the slice\n- Should not: wire BLOCKER to only one parent\n\n**[frag--sup-deferred-followup]**\n- Given: a review finding (BLOCKER, IMPORTANT, or MINOR)\n- When: categorizing\n- Then: track it in its severity group as an open finding; open findings do not block a wave unless they are BLOCKERs, and the FOLLOWUP epic is fed ONLY by user-DEFER'd UAT items, never by any review severity\n- Should not: route any review severity (BLOCKER\u002FIMPORTANT\u002FMINOR) to the FOLLOWUP epic; close a finding outside `C-finding-lifecycle`\n\n**[frag--sup-followup-epic-timing]**\n- Given: UAT (Phase 5 or 11) produces one or more user-DEFER'd items\n- When: finishing UAT\n- Then: supervisor creates the FOLLOWUP epic from the user-DEFER'd UAT items only\n- Should not: create a FOLLOWUP epic from any review severity (BLOCKER\u002FIMPORTANT\u002FMINOR)\n\n**[sup-worker-persistence]**\n- Given: worker completes initial implementation\n- When: deciding whether to shut down the worker\n- Then: keep workers alive for the review-fix cycle; workers notify supervisor via \"${EPOCH_REC}\" note but --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body do NOT shut down\n- Should not: shut down workers after first implementation pass; workers must stay alive to fix BLOCKERs and IMPORTANT findings\n\n**[sup-autonomous-progression]**\n- Given: non-user-gated phase completes\n- When: transitioning to next phase\n- Then: proceed autonomously; User gates: [request (p1 research depth); elicit (p2 requirements interview); plan-review (p5 plan UAT); impl-plan (p8 implementation effort and review budget); impl-uat (p11 implementation UAT)]\n- Should not: ask 'Should I proceed?' for autonomous phases; add user gates beyond the defined list; only pause for user-facing phases that require human input\n\n**[frag--review-clean-exit]**\n- Given: per-wave code review and end-of-epoch convergence\n- When: evaluating review results\n- Then: iterate review -> fix -> re-review up to the chosen review-effort budget; during a wave only an open BLOCKER finding gates progress, while IMPORTANT and MINOR findings stay open; after the last wave, converge over open `pasture:finding` tasks across all waves toward 0\u002F0\u002F0 within maxRounds; a finding closes only per `C-finding-lifecycle`; on budget exhaustion without convergence, SURFACE the outstanding findings to the user at a gate for a decision\n- Should not: hardcode the budget; proceed past the chosen budget without surfacing outstanding findings to the user; require a zeroed round at a wave boundary; close a finding outside `C-finding-lifecycle`; loop forever when a finite budget was chosen\n\n## Task Recovery\n\nThe tracker backend is recorded once in .agents.local\u002Fpasture\u002FEPOCH.md; read that file instead of re-probing. If EPOCH.md is absent, stop and ask the orchestrator to run detection.\n\nRecover from live tracker state at session start and after compaction; never trust cached task rows. Read the `rec:` path from the header and use it as the one entry point: `\"${EPOCH_REC}\" \u003Cop>`. The operation set is closed: create, label, block, note, show, query, ready, status, close, whoami, signal.\n\nStore selection: the adapter reads PASTURE_DB_PATH when set, otherwise the header's `db:`; the probe wrote that value from the same precedence (XDG_DATA_HOME\u002Fpasture\u002Fpasture.db, HOME\u002F.local\u002Fshare\u002Fpasture\u002Fpasture.db, then .pasture\u002Fpasture.db). Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission\u002Fschema\u002Fconfiguration repair; failure is not an empty work queue.\n\nThe adapter passes `--namespace` only when EPOCH.md records `namespace:`. That pin wins on both backends. Otherwise it omits the flag. Pasture then derives the namespace itself: PASTURE_NAMESPACE, else the git remote, then file:\u002F\u002F of the working directory. The ledger calls derive_namespace for the header and for every write that has no pin. That function is the one list of remote forms; do not restate it. With no origin, both backends use file:\u002F\u002F of the working directory, so invocations from different subdirectories use different namespaces. Queries without a pin follow that backend's derivation; pass `--all-namespaces` to opt out. When neither a pin nor PASTURE_NAMESPACE is set, pasture reads are unscoped and creation falls back to the git remote, then file:\u002F\u002F of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.\n\nRun `\"${EPOCH_REC}\" ready`, `\"${EPOCH_REC}\" query --blocked`, and `\"${EPOCH_REC}\" query --status in_progress`. For each referenced active task, run `\"${EPOCH_REC}\" show \"$TASK_URI\"`, `\"${EPOCH_REC}\" show \"$TASK_URI\" --notes`, and `\"${EPOCH_REC}\" show \"$TASK_URI\" --history`. All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the URI create printed; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.\n\nCreate prints the new task URI directly. Persist it before any label or note: create-plus-label is non-atomic, so on failure retain the URI and retry only the failed label\u002Fnote operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.\n\nAn owner is recorded with `\"${EPOCH_REC}\" label \"$TASK_URI\" owner:\u003Crole>`. That is a claim, not an allocation: an unassigned task stays unassigned until the supervisor allocates it, and repeating an identical claim is not allocation. Never invent an owner.\n\nParent stays open and is blocked by child: `\"${EPOCH_REC}\" block \"$PARENT_URI\" --by \"$CHILD_URI\"`. Reference documents belong in description frontmatter under references:, never fabricated blockers. Workers report evidence and handoffs without closing their slices or leaves; the supervisor closes only after independent review and satisfied gates. Use git agent-commit for local commits. Never install, enable, or modify Git hooks, Git hook path configuration, or pre-commit integration without explicit user approval. Tracker writes are durable; Git history lands separately.\n\nIf the header records `backend: error`, stop before the first mutation: the store exists but cannot be used, and falling back could lose earlier epochs. A mid-epoch write failure retries 3 times. After the third failure, write the attempted record to .agents.local\u002Fpasture\u002Fpending\u002F\u003Ctimestamp>-\u003Cop>.md, keep the recorded backend, and surface the pending record to the user at the next gate. Never switch backends and never drop the record.\n\n## Task Attribution\n\nSelect the current registered author with \"${EPOCH_REC}\" whoami. It prints the author recorded in the header or PASTURE_AUTHOR, and on the pasture backend it confirms that actor with agents show. It does not list agents and it does not invent one. If neither source names an author, it stops: set author: in EPOCH.md or export PASTURE_AUTHOR. Never auto-register or guess an identity during recovery. Every note supplies --author explicitly; machine examples use the pre-registered pasture-system\u002F00000000-0000-0000-0000-000000000000 actor. If it is absent, stop and request registration from the operator rather than claiming registration is fixed. Preserve human intent verbatim and quote historical attribution as evidence, not as a forged new author.\n\n## Writing to the User\n\nThese rules adapt ASD-STE100 Issue 9, Part 1 to chat messages. They are STE-aligned. The standard's Part 2 dictionary is not adopted, so no message can claim full compliance. This fragment covers wording: plain terms, short sentences, active voice, no invented labels, and the wording house rule, plus the pre-send check and the status template. Five skills carry these wording rules: architect-handoff, status, supervisor, user-elicit, user-uat.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Shape**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 1 | Lead with the result, the decision, or the blocker. | 6.1, 6.2 | 'This pins both the edge and the core case per branch, so a same-count swap fails.' to 'Result: the test now fails if a real case is replaced with a filler case.' |\n| 3 | One topic per paragraph. Max 3 sentences. | 6.5, 6.6 | One 25-word sentence with four stacked ideas, to three sentences with one idea each. |\n| 4 | For 3 or more items, a flow, or a comparison, use a list, a table, or an ASCII diagram. | 4.3 | 'Adopt the first option, then the second, then both' to a three-row table: option, what happens, cost. |\n| 5 | Cut filler, self-narration, hedging, praise, and closing offers. | house | 'It is important to note that this change effectively serves to ensure the test can detect' to 'The test detects a removed case.' |\n\n**Terms**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 6 | Put every term the user did not introduce in a Terms block before first use. Max 20 words per definition. Include the code name. | 1.1, 1.6 | 'per arm' to 'Arm: one of the 5 branches of the skip gate. Code: `arm`.' |\n| 7 | Use the industry term for the concept. Do not invent a term. | 1.8, 1.10 | 'a same-count swap' to 'a replacement that keeps the test count the same'. |\n| 8 | One name per item, in the message and across the session. | 1.11, 9.4 | 'the gate', then 'the event types', then 'the IR', to 'the event types' each time. |\n| 9 | One meaning per word. Do not use one word in two senses. | 1.2, 1.3 | 'pins' for a version lock and 'pins' for a test assertion, to 'locks the version' and 'the test checks'. |\n| 10 | No internal shorthand in prose. Write the substance first, then the reference in parentheses. | 1.10, 2.2, 8.6 | 'Adopt the option code and skip the explanation' to 'Adopt the retry limit (task: Importer retry limit, round 6).' |\n| 11 | Max 3 words in a noun cluster, and no stack of hidden ideas. A hyphenated stack still hides several. Break it with 'of', 'that', or a clause. | 2.1, 1.9 | 'mutation-load-bearing core case' to 'the core case (the one case per branch that fails when the branch breaks)'. |\n| 12 | Write each abbreviation in full once, then the short form in parentheses. | 2.2, 8.3 | 'the continuous integration job, then the CI job, with no first full form' to 'the continuous integration (CI) job, then the CI job.' |\n| 13 | Use plain verbs. No slang, no noun-as-verb, no phrasal verb. | 1.7, 1.10, 9.3 | 'reddens' to 'fails'. |\n\n**Sentences**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 14 | Max 20 words for an instruction or a question. Max 25 for a description. An identifier or a quote counts as one word. The cap is necessary, not sufficient. | 5.1, 6.3, 8.6 | 'The test checks ten cases, and because each branch needs two named cases and the count is no longer enough, a replacement can pass.' to 'The test checks 10 cases. A filler case can no longer pass.' |\n| 15 | Active voice. Name the actor: the test, CI, the agent, the merge. Simple tenses only. | 3.2, 3.6 | 'The gate will be rebased on the types.' to 'The agent rebases the gate on the event types.' |\n| 16 | One instruction per sentence. Imperative. Condition first. | 5.2, 5.3, 5.4 | 'All three at once, then check.' to 'If the types change, rebase the gate. Then run the tests.' |\n| 17 | Full sentences keep articles and verbs. Fragments only in lists, tables, and labels. | 4.2, 4.3, 4.5 | 'Defer the timeout, keep the retry limit fix' to 'Keep the retry limit. Defer the timeout change. The correctness review is round 3 and the test-quality review is round 2.' |\n| 18 | No semicolons. No em-dashes. Use a period or a list. | 8.1 + house | 'per arm, so a swap fails' with an em-dash, to 'per arm. That is 10 checks, so a swap fails.' |\n| 19 | Show the logic with because, so, but, if, then. | 4.4 | '10 predicates. A same-count swap fails.' to 'The test checks 10 cases, so a replacement that keeps the count cannot pass.' |\n\n**Exempt material**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 20 | Backtick each identifier. Max 2 per sentence. Give a plain gloss on first use. | 8.6 + house | Four bare references in one line, to one task, one design decision, and two reviews, each written in substance first. |\n| 21 | Quote user text, code, paths, and logs exactly. Explain them outside the quote. | 8.6 | A quote silently edited, to the blockquote verbatim with a plain reading on the next line. |\n\n**Risk**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 25 | Mark an irreversible action with WARNING or CAUTION, then the condition, then the result. | 7.1, 7.2, 7.3 | 'Removing the core case will fail the suite.' to 'CAUTION: if you remove the core case, the test passes and a broken branch ships.' |\n\n### Wording house rule\n\nNo self-praise is the wording house rule.\n\n| Rule | Requirement |\n|---|---|\n| No self-praise | No self-congratulation. State the next step in one line instead. |\n\n### Template: status update\n\n~~~markdown\n**Status:** \u003Cthe result or the state, max 25 words>.\n\n**Done**\n- \u003Cartifact or outcome, past tense, actor named> (`\u003Cpath>`, pull request #N, or task title).\n\n**Next**\n- \u003Cwhat happens next, and who does it>.\n\n**Needs you** (omit if empty)\n- \u003Cthe decision>, needed for \u003Cwhat it unblocks>.\n\n**Risk** (omit if empty)\n- WARNING or CAUTION: \u003Ccondition>. \u003Cresult>.\n\n**Terms** (new terms only)\n- **\u003Cterm>**: \u003Cmax 20 words>.\n~~~\n\nBudget: 120 words. Every Done item names an artefact. Do not restate the plan. One status per message, not one per thought.\n\n### Exempt material\n\nTwo material classes are exempt from the word and sentence caps: quoted text and code blocks. A third is allowed as technical nouns. Everything else obeys the caps.\n\n- **Quoted user text.** Verbatim in a blockquote. Never rewrite it into the house style. Put the plain reading after the quote.\n- **Code, logs, diffs, test output.** Exempt. Explain them in prose around the block.\n- **Industry terms of art.** Fixture, golden test, mutation testing, schema migration, fail-safe default, backfill, and closed enum are allowed as technical nouns. Define one in Terms if the user did not use it first.\n\nTwo more rows are relaxations, not exemptions. **Spelling** keeps one spelling per message and does not enforce American spelling. **Identifiers** are not exempt from a gloss, as rule 20 says.\n\nThe caps stay live for everything else. Rule 3 sets paragraph length, rule 14 sets the word caps, and rule 17 sets where a fragment is allowed; none of those three is an exemption.\n\n### Pre-send check\n\nRun this list on every user-facing message. A clean pass is not a gate.\n\n1. Does sentence one give the result, the decision, or the blocker?\n2. Does every term the reader did not introduce appear in Terms before first use?\n3. Search the draft for a token that matches `[A-Z]{1,3}-?[0-9]`, for a section sign (`§`), and for a five- or six-character token that matches `[A-Za-z0-9]{5,6}` and contains both a letter and a digit. Is each one defined, or replaced by its substance?\n4. Does one item have two names, or one word have two senses?\n5. Any sentence over 20 words (instruction or question) or 25 (description)?\n6. Any noun cluster over 3 words? Any slang verb, noun-as-verb, or phrasal verb?\n7. Any semicolon or em-dash?\n8. Any passive verb with no actor?\n9. Does an irreversible action carry WARNING or CAUTION?\n10. Delete one sentence. If nothing is lost, keep it deleted.\n\n## Question and Option Design\n\nThis fragment covers question and option design: grounding before asking, one decision, option shape, recommendation placement, the present template, and the weak-tool degrade. Wording rules, the STE-aligned claim, the status template, and the pre-send check are in Writing to the User. Four skills carry these question rules: architect-handoff, supervisor, user-elicit, user-uat. The status skill asks no question, so it does not carry this fragment. Ask through the `request_user_decision` operation, never by launching a subagent. That launch is `delegate_assignment`, a different operation. The role-tool binding in `internal\u002Fruntime\u002Fprofiles.go` lowers `request_user_decision` to the harness question tool and lowers `delegate_assignment` to the subagent tool.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Grounding**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 2 | Ground before you ask. Show what the thing is, where it lives, and one example. Never put the only explanation in the options. | 6.1, 4.4 | 'Which order: the types to the gate in parallel, or the gate first?' to 'Three parts share one type. The gate reads it. The fixtures copy it. Code: `ir.Event`.' |\n\n**Questions and options**\n\nRules 22, 23 and 24 are house rules. The house-rule table names them by number. Do not attach an STE number to a house rule.\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 22 | One question, one decision. Say what the answer changes. | house | 'Which order do you want, and are the labels clear?' to 'Which part merges first? The answer sets the order for the next 3 days.' |\n| 23 | Each option is self-contained: a label of max 6 words, what happens, and the cost. Use only Terms words. | house | 'Both' to 'Both limits. The import stops at the first limit it reaches. Cost: one more setting to test.' |\n| 24 | Put the recommendation outside the options, with one reason. You may also mark the label '(recommended)'. | house | An option labelled 'recommended' with no reason, to 'Recommendation: merge the event types first, because a later change costs rework in two places.' |\n\n### House rules for questions, options and recommendations\n\nASD-STE100 has no rule for questions, options, recommendations, or the turn split around a question tool. Rules 2, 22, 23 and 24 already carry grounding before asking, one decision per question, option design and recommendation placement. Four rows in this table are pointers to those rules. Question shape and Text-before-question turn add only what those rules do not. No self-praise is a wording rule; it is in Writing to the User. Never cite an STE number for a house rule.\n\n| Rule | Requirement |\n|---|---|\n| Question shape | A short header, max 4 words. |\n| Option design | Extends rule 23. Do not restate it. |\n| Recommendation placement | Extends rule 24. Do not restate it. |\n| Grounding before asking | Extends rule 2. Do not restate it. |\n| One decision per question | Extends rule 22. Do not restate it. |\n| Text-before-question turn | Send the grounding as text and end the turn. Ask through the `request_user_decision` operation in the next turn, because a question tool can hide prose sent in the same turn. |\n\n### Template: present a component, then ask\n\nSend the block below as text only, then end the turn. In the next turn, ask through the `request_user_decision` operation with the same options. The split is the Text-before-question turn house rule.\n\n~~~~markdown\n## \u003CPart name>: \u003Cwhat it does for the user, max 10 words>\n\n**Decision needed:** \u003Cone sentence>. The answer changes \u003Cwhat>.\n\n**Terms**\n- **\u003Cterm>**: \u003Cmax 20 words>. Code: `\u003Cidentifier>`.\n- **\u003Cterm>**: \u003Cmax 20 words>.\n\n**What it is**\n\u003Cmax 3 sentences. Name the actor. One fact per sentence.>\n\n**Definition**\n~~~\u003Clang>\n\u003Cthe smallest type, interface, schema, or command shape that shows the choice>\n~~~\n\n**Example**\n~~~\n\u003Cone realistic before and after, or input and output>\n~~~\n\n**Diagram**\n~~~\n\u003CASCII, plain labels, no em-dash>\n~~~\n\n**Options**\n\n| Option | What happens | Cost |\n|---|---|---|\n| \u003Clabel, max 6 words> | \u003Cone sentence> | \u003Cone sentence> |\n| \u003Clabel> | \u003Cone sentence> | \u003Cone sentence> |\n\n**Recommendation:** \u003Coption>, because \u003Cone reason>.\n~~~~\n\nThen, in the next turn:\n\n~~~\n`request_user_decision`: '\u003Cquestion, max 20 words>'\noptions: the same labels, with the 'what happens' and 'cost' text repeated in each description, because the picker can hide the table.\n~~~\n\nOne component per call. Use multi-select only when the options combine. Always add one open-ended feedback question.\n\n### Degrade when the question tool is weak\n\nSome hosts expose a weak question tool: it takes one question per call, it has no multi-select, or its picker hides option descriptions. Degrade in this order:\n\n1. Ask one question.\n2. Phrase the options as a single-select choice.\n3. State the assumption you will use if the answer is unavailable.\n\nPut the assumption in the text turn that grounds the question, not inside the options. An assumption never satisfies a user gate: a gated phase waits for the user's answer. The question still asks for one decision, and the recommendation names the cost of the assumption.\n\n### Pre-send check for a question\n\nRun this list before you send a question. It tests the question rules in this fragment. The wording pre-send check is in Writing to the User.\n\n1. Before a question: did the reader already see what the thing is, its definition, and one example, in an earlier turn or an earlier block?\n2. Can the reader choose from the options alone, with no other document? Is the recommendation outside the options?\n\n## First Steps\n\nThe architect creates a placeholder IMPL_PLAN task. Your first job is to fill it in:\n\n1. Read the RATIFIED_PLAN and the **URD** to understand the full scope, user requirements, and **identify production code paths**\n   ```bash\n   \"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"\n   \"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n   ```\n2. **Explore the codebase** using ephemeral Explore subagents (see [Exploration](#exploration-ephemeral-explore-subagents) below) — spawn scoped Explore subagents for codebase queries before decomposing into slices.\n3. **Prefer vertical slice decomposition** (feature ownership end-to-end) when possible:\n   - Vertical slice: Worker owns full feature (types → tests → impl → CLI\u002FAPI wiring)\n   - Horizontal layers: Use when shared infrastructure exists (common types, utilities)\n4. Determine layer structure following TDD principles:\n   - Layer 1: Types, interfaces, schemas (no deps)\n   - Layer 2: Tests for public interfaces (tests first!)\n   - Layer 3: Implementation (make tests pass)\n   - Layer 4: Integration tests (if needed)\n5. **Identify horizontal Layer Integration Points** where slices must inter-op — document in IMPL_PLAN (see [supervisor-plan-tasks](..\u002Fsupervisor-plan-tasks\u002FSKILL.md) step 5)\n6. **Create leaf tasks for every slice** (see [Step 3](#step-3-create-leaf-tasks-within-each-slice-critical)) — a slice without leaf tasks is undecomposed and cannot be tracked\n7. Bind SLICE_1_ID_URI and SLICE_2_ID_URI from the corresponding slice create outputs first. Update the IMPL_PLAN with the layer breakdown + integration points:\n   ```bash\n   \"${EPOCH_REC}\" note \"${IMPL_PLAN_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body=\"$(cat \u003C\u003CEOF\n   ---\n   references:\n     request: \"${REQUEST_ID_URI}\"\n     urd: \"${URD_ID_URI}\"\n     proposal: \"${RATIFIED_PROPOSAL_ID_URI}\"\n   ---\n   ## Layer Structure (TDD)\n\n   ### Vertical Slices (Preferred)\n   - the first slice: Feature X command (Worker A owns types → tests → impl → CLI wiring)\n   - the second slice: Feature Y endpoint (Worker B owns types → tests → impl → API wiring)\n\n   OR\n\n   ### Horizontal Layers (If shared infrastructure)\n   - Layer 1: types.go, interfaces.go (no deps)\n   - Layer 2: service_test.go (tests first, depend on L1)\n   - Layer 3: service.go (implementation, make tests pass)\n   - Layer 4: integration_test.go (depends on L3)\n\n   ## Tasks\n   - \"${SLICE_1_ID_URI}\": the slice ...\n   - \"${SLICE_2_ID_URI}\": the slice ...\n   ...\n   EOF\n   )\"\n   ```\n\nSee: [..\u002Fsupervisor-plan-tasks\u002FSKILL.md](..\u002Fsupervisor-plan-tasks\u002FSKILL.md) for detailed vertical slice decomposition guidance.\n\n## Exploration (Ephemeral Explore Subagents)\n\nPer [C-supervisor-explore-ephemeral], spawn ephemeral Explore subagents (Agent tool, `subagent_type=Explore`) for scoped codebase queries. These are short-lived — they explore, return findings, and terminate. The supervisor stays lean.\n\n```\n\u002F\u002F Explore subagent — ephemeral, scoped query\ndelegation: {\n  subagent_type: \"Explore\",\n  run_in_background: true,\n  prompt: `Call Skill(\u002Fpasture:explore) to load your exploration role.\n\nQuery: \u003Cspecific codebase question>\nDepth: standard-research\n\nExplore the codebase for the requested topic. Produce structured findings\n(entry points, data flow, dependencies, patterns, conflicts). Return findings.`\n}\n```\n\nSpawn as many Explore subagents as needed — they are cheap and disposable. Use them during Phase 8 (IMPL_PLAN) to understand codebase areas before decomposing into slices.\n\n## Reading from Pasture\n\nGet the ratified plan and URD:\n```bash\n\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"\n\"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n\"${EPOCH_REC}\" query --label=\"pasture:p6-plan:s6-ratify\" --status=open\n\"${EPOCH_REC}\" query --label=\"pasture:urd\"\n```\n\n## Implementation Task Structure\n\n```go\ntype ImplementationTask struct {\n    File            string          \u002F\u002F file path\n    TaskId          string          \u002F\u002F Pasture task ID (e.g., \"${TASK_A_URI}\")\n    RequirementRef  string\n    Prompt          string\n    Context         struct {\n        RelatedFiles    []struct{ File, Summary string }\n        TaskDescription string\n    }\n    Status          string          \u002F\u002F \"Pending\" | \"Claimed\" | \"Complete\" | \"Failed\"\n    \u002F\u002F Pasture fields:\n    ValidationChecklist []string              \u002F\u002F Items from RATIFIED_PLAN\n    AcceptanceCriteria  []AcceptanceCriterion \u002F\u002F {Given, When, Then, ShouldNot}\n    Tradeoffs           []Tradeoff           \u002F\u002F {Decision, Rationale}\n    RatifiedPlan        string               \u002F\u002F Link to RATIFIED_PLAN task ID\n}\n```\n\n## Creating Vertical Slices (Phase 8)\n\n\n\n### Step 1: Create the IMPL_PLAN task\n\n```bash\nIMPL_PLAN_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"IMPL_PLAN: \u003Cfeature>\" --phase impl_plan \\\n  --body \"---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n  proposal: \"${RATIFIED_PROPOSAL_ID_URI}\"\n---\n## Horizontal Layers\n- L1: Types and schemas\n- L2: Tests (import production code)\n- L3: Implementation + wiring\n\n## Vertical Slices\n- the first slice: \u003Cdescription> (files: ...)\n- the second slice: \u003Cdescription> (files: ...)\")\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${IMPL_PLAN_ID_URI}\"\n```\n\n### Step 2: Create each slice\n\n```bash\nSLICE_1_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"\u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n---\n## Specification\n\u003Cdetailed spec from ratified plan>\n\n## Files Owned\n\u003Clist of files>\n\n## Leaf Tasks\n- the types task: Types and interfaces\n- the tests task: Tests (import production code)\n- the implementation task: Implementation + wiring\n\n## Validation Checklist\n- [ ] Types defined\n- [ ] Tests written (import production code)\n- [ ] Implementation complete\n- [ ] Production path verified\")\n\"${EPOCH_REC}\" note \"$SLICE_1_ID_URI\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Design: '{\\\"validation_checklist\\\":[\\\"Types defined\\\",\\\"Tests written (import production code)\\\",\\\"Implementation complete\\\",\\\"Production path verified\\\"],\\\"acceptance_criteria\\\":[{\\\"given\\\":\\\"X\\\",\\\"when\\\":\\\"Y\\\",\\\"then\\\":\\\"Z\\\"}],\\\"ratified_plan\\\":\\\"${RATIFIED_PLAN_ID_URI}\\\"}'\"\n\"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n```\n\n### Step 3: Create leaf tasks within each slice (CRITICAL)\n\nPer [C-slice-leaf-tasks], create Pasture tasks for each implementation unit within the slice, then chain them as dependencies. Leaf tasks are what workers actually implement.\n\n```bash\n# L1: Types and interfaces for this slice\nLEAF_L1=$(\"${EPOCH_REC}\" create --kind task --title \"Types — \u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  slice: \"${SLICE_1_ID_URI}\"\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n---\n## Scope\nDefine types, interfaces, and schemas for this slice.\n\n## Files Owned\n- \u003Cfile-path-1>\n- \u003Cfile-path-2>\n\n## Acceptance Criteria\nGiven \u003Ccontext> when \u003Caction> then \u003Coutcome> should never \u003Canti-pattern>\")\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"$LEAF_L1\"\n\n# L2: Tests (import production code, will fail until L3)\nLEAF_L2=$(\"${EPOCH_REC}\" create --kind task --title \"Tests — \u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  slice: \"${SLICE_1_ID_URI}\"\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n---\n## Scope\nWrite tests that import from production code paths. Tests MUST fail until L3.\n\n## Files Owned\n- \u003Ctest-file-path-1>\n\n## Acceptance Criteria\nGiven \u003Ccontext> when \u003Caction> then \u003Coutcome> should never \u003Canti-pattern>\")\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"$LEAF_L2\"\n# L2 depends on L1 types being defined first\n\"${EPOCH_REC}\" block \"$LEAF_L2\" --by \"$LEAF_L1\"\n\n# L3: Implementation (makes tests pass)\nLEAF_L3=$(\"${EPOCH_REC}\" create --kind task --title \"Implementation — \u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  slice: \"${SLICE_1_ID_URI}\"\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n---\n## Scope\nImplement production code to make L2 tests pass.\n\n## Files Owned\n- \u003Cimpl-file-path-1>\n\n## Acceptance Criteria\nGiven \u003Ccontext> when \u003Caction> then \u003Coutcome> should never \u003Canti-pattern>\")\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"$LEAF_L3\"\n# L3 depends on L2 tests existing first\n\"${EPOCH_REC}\" block \"$LEAF_L3\" --by \"$LEAF_L2\"\n```\n\nThe resulting tree per slice:\n\n```\nIMPL_PLAN\n  └── blocked by the slice\n        ├── blocked by the types task: Types\n        ├── blocked by the tests task: Tests (blocked by L1)\n        └── blocked by the implementation task: Impl  (blocked by L2)\n```\n\nWorkers are assigned to leaf tasks, not slices. The slice closes when all its leaf tasks close.\n\n## Assigning Slices\n\n```bash\n# Assign slices to workers\n\"${EPOCH_REC}\" label \"${SLICE_1_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR_1}\"\n\"${EPOCH_REC}\" label \"${SLICE_2_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR_2}\"\n\"${EPOCH_REC}\" label \"${SLICE_3_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR_3}\"\n```\n\n## Spawning Workers\n\nPer [C-supervisor-no-impl], all implementation work — no matter how small — is delegated to a worker agent. The supervisor's job is coordination, tracking, and quality control.\n\nWorkers are **general-purpose agents** that call `\u002Fpasture:worker` at the start. Select the worker's capability tier from the model policy: T2 standard for ordinary work, T1 frontier for non-trivial slices. Resolve the tier's native model id for the target harness, pass it on the assignment, and respect the concurrency cap of 4.\n\n```\n\u002F\u002F Non-trivial work -> T1 frontier\ndelegation: {\n  subagent_type: \"general-purpose\",\n  model: \"\u003CT1 frontier native model id for this harness>\",\n  run_in_background: true,\n  prompt: `Call Skill(\u002Fpasture:worker) and implement the assigned slice.\\n\\nPasture Task ID: ${taskId}...`\n}\n\n\u002F\u002F Ordinary work (config tweak, typo fix, single-file edit) -> T2 standard\ndelegation: {\n  subagent_type: \"general-purpose\",\n  model: \"\u003CT2 standard native model id for this harness>\",\n  run_in_background: true,\n  prompt: `Call Skill(\u002Fpasture:worker) and fix the typo in...\\n\\nPasture Task ID: ${taskId}...`\n}\n\n\u002F\u002F WRONG: Supervisor implementing changes directly\nEdit({ file_path: \"src\u002Ffoo.ts\", ... })  \u002F\u002F Supervisors coordinate, they don't implement!\n\n\u002F\u002F WRONG: Do not use specialized agent types like \"pasture:worker\" directly\ndelegation: {\n  subagent_type: \"pasture:worker\",  \u002F\u002F This doesn't exist!\n  ...\n}\n```\n\n### Capability Tier Guide\n\n| Complexity | Tier | Examples |\n|------------|------|----------|\n| Trivial | T2 standard | Single-file edit, config change, typo fix, renaming, adding a label |\n| Non-trivial | T1 frontier | Multi-file changes, new features, architectural work, complex logic, test suites |\n\n**Handoff:** Before spawning each worker, author its handoff in the slice (or a dedicated handoff) Pasture task body — the task body IS the handoff (no filesystem path).\n\nSee: [..\u002Fsupervisor-spawn-worker\u002FSKILL.md](..\u002Fsupervisor-spawn-worker\u002FSKILL.md) for handoff template.\n\n### Delegated Assignment Context Requirements\n\nA delegated assignment has **zero prior context**. Every SendMessage assigning work MUST be self-contained:\n\n```\nSendMessage({\n  type: \"message\",\n  recipient: \"worker-1\",\n  content: `You are assigned the slice. Start by calling Skill(\u002Fpasture:worker).\n\nYour Pasture task ID: \"${SLICE_TASK_ID_URI}\"\nRun this to get full requirements + handoff: \"${EPOCH_REC}\" show \"${SLICE_TASK_ID_URI}\"\n\nKey context:\n- Request: \"${REQUEST_ID_URI}\" (run: \"${EPOCH_REC}\" show \"${REQUEST_ID_URI}\")\n- URD: \"${URD_ID_URI}\" (run: \"${EPOCH_REC}\" show \"${URD_ID_URI}\")\n- IMPL_PLAN: \"${IMPL_PLAN_ID_URI}\" (run: \"${EPOCH_REC}\" show \"${IMPL_PLAN_ID_URI}\")\n\nRead the handoff doc and your Pasture task before starting implementation.`,\n  summary: \"slice assignment\"\n})\n```\n\nPer [sup-teamcreate-msg], every assignment must include actionable `\"${EPOCH_REC}\" show` commands. Teammates cannot see your conversation history, the Pasture task tree, or any prior context.\n\nThe worker skill provides:\n- File ownership validation\n- Standard DI patterns\n- Completion\u002Fblocked signaling via Pasture\n\n## EPIC_FOLLOWUP Creation (Phase 5\u002F11)\n\nAfter UAT, if the user **DEFER'd** one or more items, create a follow-up epic from those DEFER'd items. Per [frag--sup-followup-epic-timing], create immediately after UAT completes. Review severities (BLOCKER\u002FIMPORTANT\u002FMINOR) are **never** routed here — they converge at the end; close rule: `C-finding-lifecycle`.\n\n### Step 1: Create follow-up epic\n\n```bash\nFOLLOWUP_EPIC_ID_URI=$(\"${EPOCH_REC}\" create --kind epic --title \"FOLLOWUP: User-deferred improvements from UAT\" --phase unscoped --priority 3 \\\n  --body=\"---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n  uat: ${UAT_ID_URI}\n---\nAggregated user-DEFER'd items from UAT (Phase 5\u002F11).\")\n\"${EPOCH_REC}\" label \"$FOLLOWUP_EPIC_ID_URI\" pasture:epic-followup\n\n# Link the DEFER'd UAT items as children of the follow-up epic\n\"${EPOCH_REC}\" block \"${FOLLOWUP_EPIC_ID_URI}\" --by \"${DEFERRED_ITEM_ID_1_URI}\"\n\"${EPOCH_REC}\" block \"${FOLLOWUP_EPIC_ID_URI}\" --by \"${DEFERRED_ITEM_ID_2_URI}\"\n```\n\nSeverity routing follows [frag--sup-blocker-dual-parent] and [frag--sup-deferred-followup]: only an open BLOCKER gates a wave; open findings converge at the end; the FOLLOWUP epic is DEFER-fed only.\n\n### Step 2: Follow-up lifecycle (same protocol, FOLLOWUP_* prefix)\n\nThe follow-up epic runs the same protocol phases with FOLLOWUP_* prefixed task types. The supervisor creates the initial lifecycle tasks:\n\n```\nFOLLOWUP epic (pasture:epic-followup)\n  ├── frontmatter reference: original URD\n  ├── frontmatter reference: original REVIEW-A\u002FB\u002FC tasks\n  └── blocked-by: FOLLOWUP_URE         (Phase 2: scope which DEFER'd items to address)\n        ├── frontmatter reference: FOLLOWUP_URD (living requirements document)\n        └── blocked-by: FOLLOWUP_PROPOSAL-1  (Phase 3: proposal for follow-up)\n              └── blocked-by: FOLLOWUP_IMPL_PLAN  (Phase 8: decompose into slices)\n                    ├── blocked-by: the first follow-up slice  (Phase 9)\n                    │     ├── blocked-by: deferred-item-leaf-task-...\n                    │     └── blocked-by: deferred-item-leaf-task-...\n                    └── blocked-by: the second follow-up slice\n```\n\n```bash\n# Create FOLLOWUP_URD first so its URI can be recorded in the URE references.\nFOLLOWUP_URD_ID=$(\"${EPOCH_REC}\" create --kind task --title \"FOLLOWUP_URD: Requirements for \u003Cfeature> follow-up\" --phase elicit \\\n  --body \"---\nreferences:\n  followup_epic: \"${FOLLOWUP_EPIC_ID_URI}\"\n  original_urd: \"${ORIGINAL_URD_ID_URI}\"\n---\nFollow-up requirements. References original URD.\")\n\"${EPOCH_REC}\" label \"$FOLLOWUP_URD_ID\" pasture:p2-user:s2_2-urd\n\"${EPOCH_REC}\" label \"$FOLLOWUP_URD_ID\" pasture:urd\n\n# Create FOLLOWUP_URE — user scoping which findings to address\nFOLLOWUP_URE_ID=$(\"${EPOCH_REC}\" create --kind task --title \"FOLLOWUP_URE: Scope follow-up for \u003Cfeature>\" --phase elicit \\\n  --body \"---\nreferences:\n  followup_epic: \\\"${FOLLOWUP_EPIC_ID_URI}\\\"\n  original_urd: \\\"${ORIGINAL_URD_ID_URI}\\\"\n  followup_urd: \\\"${FOLLOWUP_URD_ID}\\\"\n---\nScoping URE: determine which user-DEFER'd UAT items to address.\")\n\"${EPOCH_REC}\" label \"$FOLLOWUP_URE_ID\" pasture:p2-user:s2_1-elicit\n\"${EPOCH_REC}\" block \"${FOLLOWUP_EPIC_ID_URI}\" --by \"$FOLLOWUP_URE_ID\"\n```\n\nThe remaining lifecycle tasks (FOLLOWUP_PROPOSAL, FOLLOWUP_IMPL_PLAN, FOLLOWUP_SLICE) are created as the follow-up epic progresses through the protocol phases.\n\n### Step 3: DEFER'd-item leaf adoption (dual-parent)\n\nWhen the supervisor creates the follow-up slice tasks during the follow-up implementation phase, the user-DEFER'd UAT-item leaf tasks gain a second parent (dual-parent: leaf blocks BOTH the DEFER'd-items tracking group AND the follow-up slice):\n\n```bash\n# Leaf task gets dual-parent: DEFER'd-items tracking group + follow-up slice\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${DEFERRED_ITEM_LEAF_ID_1_URI}\"\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${DEFERRED_ITEM_LEAF_ID_2_URI}\"\n# Leaf task already has: \"${EPOCH_REC}\" block \"${DEFERRED_ITEMS_TRACKING_GROUP_ID_URI}\" --by \"${LEAF_TASK_ID_URI}\"\n```\n\n### Follow-up Handoff Chain\n\nInside the follow-up lifecycle, the same handoff types (h1-h4) reapply:\n\nThe follow-up lifecycle starts ONLY from user-DEFER'd UAT items (`C-followup-timing`); code review never starts it. The Supervisor creates the FOLLOWUP epic from those items (same actor), then:\n\n| Order | Handoff | Transition |\n|-------|---------|------------|\n| 1 | *(none)* | Supervisor creates the FOLLOWUP epic from user-DEFER'd UAT items (same actor) |\n| 2 | *(none)* | Supervisor creates FOLLOWUP_URE (same actor) |\n| 3 | *(none)* | Supervisor creates FOLLOWUP_URD (same actor) |\n| 4 | h6 | Supervisor → Architect: Hands off FOLLOWUP_URE + FOLLOWUP_URD for FOLLOWUP_PROPOSAL |\n| 5 | h1 | Architect → Supervisor: After FOLLOWUP_PROPOSAL ratified |\n| 6 | h2 | Supervisor → Worker: the follow-up slice with DEFER'd-item leaf tasks |\n| 7 | h3 | Supervisor → Reviewer: One code review per follow-up wave |\n| 8 | h4 | Worker → Reviewer: Follow-up slice completion |\n\nFollow-up handoff storage: each handoff is authored in its Pasture task body (no filesystem path).\n\nSee `..\u002Farchitect-handoff\u002FSKILL.md` for handoff field requirements.\n\n## Impl-Review Severity Tree Procedure\n\nThe severity behaviors for code review (Phase 10) are defined above as structured behaviors (frag--sup-review-all-slices through frag--sup-followup-epic-timing). The following subsections describe the operational procedures.\n\n### Severity Tree (EAGER Creation)\n\nPer [frag--sup-review-severity-groups], create ONE severity trio per wave, per axis, per round — not one per slice:\n\n```bash\n# Wave 1 contains the first slice, the second slice, and the third slice.\n# Step 1: Create all 3 severity groups immediately (EAGER)\nBLOCKER_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"WAVE-{W}-REVIEW-{axis}-{round} BLOCKER\" --phase code_review \\\n  --body \"---\nreferences:\n  wave: 1\n  slices:\n    - \\\"${SLICE_1_1_ID_URI}\\\"\n    - \\\"${SLICE_1_2_ID_URI}\\\"\n    - \\\"${SLICE_1_3_ID_URI}\\\"\n  review_round: 1\n---\nBLOCKER findings from Reviewer A (Correctness) on wave 1.\")\n\"${EPOCH_REC}\" label \"$BLOCKER_ID_URI\" pasture:severity:blocker\n\nIMPORTANT_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"WAVE-{W}-REVIEW-{axis}-{round} IMPORTANT\" --phase code_review \\\n  --body \"---\nreferences:\n  wave: 1\n  slices:\n    - \\\"${SLICE_1_1_ID_URI}\\\"\n    - \\\"${SLICE_1_2_ID_URI}\\\"\n    - \\\"${SLICE_1_3_ID_URI}\\\"\n  review_round: 1\n---\nIMPORTANT findings from Reviewer A (Correctness) on wave 1.\")\n\"${EPOCH_REC}\" label \"$IMPORTANT_ID_URI\" pasture:severity:important\n\nMINOR_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"WAVE-{W}-REVIEW-{axis}-{round} MINOR\" --phase code_review \\\n  --body \"---\nreferences:\n  wave: 1\n  slices:\n    - \\\"${SLICE_1_1_ID_URI}\\\"\n    - \\\"${SLICE_1_2_ID_URI}\\\"\n    - \\\"${SLICE_1_3_ID_URI}\\\"\n  review_round: 1\n---\nMINOR findings from Reviewer A (Correctness) on wave 1.\")\n\"${EPOCH_REC}\" label \"$MINOR_ID_URI\" pasture:severity:minor\n\n# Step 2: Wire the one severity trio to the wave's review round task\n\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"$BLOCKER_ID_URI\"\n\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"$IMPORTANT_ID_URI\"\n\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"$MINOR_ID_URI\"\n# NEVER wire severity groups to IMPL_PLAN or slices directly.\n# BLOCKER findings block slices via dual-parent (see below).\n# Open findings converge at the end; only an open BLOCKER gates the wave. IMPORTANT\u002FMINOR are NOT routed to FOLLOWUP.\n# The FOLLOWUP epic is fed ONLY by user-DEFER'd UAT items (see Follow-up Epic section).\n\n# Step 3: Close empty groups immediately\n# If a group has no findings, close it right away\n\"${EPOCH_REC}\" close \"$IMPORTANT_ID_URI\"   # if no IMPORTANT findings\n\"${EPOCH_REC}\" close \"$MINOR_ID_URI\"        # if no MINOR findings\n```\n\n### Naming Convention\n\nName the review for one wave, one axis, and one round. Axis A is correctness, B is test quality, and C is elegance. List every slice of that wave on the review. Create one severity trio under it: blocker, important, and minor. Do not create one review per slice.\n\nThe first wave's correctness review, first round, has one blocker group, one important group, and one minor group. A later wave gets its own review.\n\n## Tracking Progress\n\n```bash\n# Check all implementation slices\n\"${EPOCH_REC}\" query --phase worker_slices --status=in_progress\n\n# Check for blocked tasks\n\"${EPOCH_REC}\" query --blocked --phase worker_slices\n\n# Check completed slices\n\"${EPOCH_REC}\" query --phase worker_slices --status=closed\n\n# Check specific task\n\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"\n\n# Check severity groups from review\n\"${EPOCH_REC}\" query --label=\"pasture:severity:blocker\"\n\"${EPOCH_REC}\" query --label=\"pasture:severity:important\"\n\"${EPOCH_REC}\" query --label=\"pasture:severity:minor\"\n\n# Check follow-up epics\n\"${EPOCH_REC}\" query --label=\"pasture:epic-followup\"\n```\n\n## Signal Capture\n\nRecord the user's friction or approval when it appears, so a later project-level skill can distill it. Capture is a side effect of work already happening: it never prompts the user and never blocks a phase.\n\n### Closed kind list\n\nThe kind is a closed list. Use exactly one of:\n\n- `frustration`: the user shows annoyance, repeats a complaint, or rejects the interaction itself.\n- `positive-signal`: the user endorses a direction or a result before a gate asks.\n- `satisfaction`: the user accepts a gate and says the result is what they wanted.\n- `confusion`: the user asks what a term means, misreads a question, or answers a different question.\n- `correction`: the user corrects a fact, a requirement, or an earlier answer.\n\n### One feedback task per epoch\n\nOn the pasture backend, the epoch creates one feedback task at epoch start and writes `feedback: \u003Ctask URI>` into `.agents.local\u002Fpasture\u002FEPOCH.md`. A second run reads the `feedback:` line and does not create another task. On the ledger backend, create nothing and record nothing: there is no feedback task and no `feedback:` line. No other skill creates a feedback task. If the pasture line is absent, the signal operation fails and records nothing; do not create a task to fill the gap.\n\n### Line format and recording\n\nWrite one JSON object per signal. The fields, in this order, are kind, phase, skill, entry and quote.\n\n~~~\n{\"kind\":\"\u003Ckind>\",\"phase\":\"\u003Cphase>\",\"skill\":\"\u003Cskill>\",\"entry\":\"\u003Centry-ref>\",\"quote\":\"\u003Cshort verbatim quote>\"}\n~~~\n\n- `kind`: one of the registered kinds above, exactly.\n- `phase`: one of request, elicit, propose, review, plan-review, ratify, handoff, impl-plan, worker-slices, code-review, impl-uat, landing.\n- `skill`: the skill that recorded it, named exactly as the skill directory.\n- `entry`: the record that holds the interaction, such as a task URI plus the question or section.\n- `quote`: a short verbatim fragment, max 20 words. Never paraphrase or tidy it.\n\nRecord the signal with one call. Do not name a backend command in this section.\n\n~~~bash\n\"${EPOCH_REC}\" signal --kind confusion --phase elicit --skill user-elicit --entry '\u003Ctask URI>#end-vision' --quote 'what does arm mean here'\n~~~\n\nThe adapter records that JSON object. An empty feedback id fails in the adapter and records nothing. Write the call in the same turn as the work. Do not ask permission to record. Do not wait for the write before you continue the phase.\n\nIf the write fails, follow the tracker write-failure rule: retry, keep the recorded backend, and surface the pending line at the next gate. A failed record never blocks the phase and never prompts the user.\n\u003C!-- END GENERATED FROM pasture schema -->\n","# Supervisor Agent\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Role:** `supervisor` | **Phases owned:** p7-handoff, p8-impl-plan, p9-worker-slices, p10-code-review, p11-impl-uat, p12-landing\n\n## Protocol Context (generated from schema.xml)\n\n### Owned Phases\n\n| Phase | Name | Domain | Transitions |\n|-------|------|--------|-------------|\n| `p7-handoff` | Handoff | plan | → `p8-impl-plan` (handoff authored in the HANDOFF Pasture task body) |\n| `p8-impl-plan` | Impl Plan | impl | → `p9-worker-slices` (all slices created with leaf tasks, assigned, and dependency-chained) |\n| `p9-worker-slices` | Worker Slices | impl | → `p10-code-review` (all slices complete, quality gates pass) |\n| `p10-code-review` | Code Review | impl | → `p11-impl-uat` (all 3 reviewers ACCEPT, all BLOCKERs resolved); → `p9-worker-slices` (any reviewer votes REVISE) |\n| `p11-impl-uat` | Impl UAT | user | → `p12-landing` (user accepts implementation); → `p9-worker-slices` (user requests changes) |\n| `p12-landing` | Landing | impl | → `complete` (git push succeeds, all tasks closed or dependency-resolved) |\n\n### Commands\n\n| Command | Description | Phases |\n|---------|-------------|--------|\n| `pasture:afk-implement` | Run an unattended implementation session with small PRs and a review wave that ends in convergence, never merging | p8-impl-plan, p9-worker-slices, p10-code-review |\n| `pasture:impl:review` | Code review coordination across all slices (Phase 10) | p10-code-review |\n| `pasture:impl:slice` | Vertical slice assignment and tracking | p9-worker-slices |\n| `pasture:supervisor` | Task coordinator, spawns workers, manages parallel execution | p7-handoff, p8-impl-plan, p9-worker-slices, p10-code-review, p11-impl-uat, p12-landing |\n| `pasture:supervisor:commit` | Atomic commit per completed layer\u002Fslice | p12-landing |\n| `pasture:supervisor:plan-tasks` | Decompose ratified plan into vertical slices (SLICE-{W}-{N}) | p8-impl-plan |\n| `pasture:supervisor:spawn-worker` | Launch a worker agent for an assigned slice | p9-worker-slices |\n| `pasture:supervisor:track-progress` | Monitor worker status via Pasture | p9-worker-slices, p10-code-review |\n\n### General Constraints\n\n**[C-actionable-errors]**\n- Given: an error, exception, or user-facing message\n- When: creating or raising\n- Then: make it actionable: describe (1) what went wrong, (2) why it happened, (3) where it failed (file location, module, or function), (4) when it failed (step, operation, or timestamp), (5) what it means for the caller, and (6) how to fix it\n- Should not: raise generic or opaque error messages (e.g. 'invalid input', 'operation failed') that don't guide the user toward resolution\n\n**[C-agent-commit]**\n- Given: code is ready to commit\n- When: committing\n- Then: use git agent-commit -m ...\n- Should not: use git commit -m ...\n\n_Example (correct)_\n\n```bash\ngit agent-commit -m \"feat: add login\"\n```\n\n_Example (anti-pattern)_\n\n```bash\ngit commit -m \"feat: add login\"\n```\n\n**[C-audit-dep-chain]**\n- Given: any phase transition\n- When: creating new task\n- Then: chain dependency: \"${EPOCH_REC}\" block parent --by child\n- Should not: skip dependency chaining or invert direction\n\n_Example (correct)_\n\n```bash\n# Full dependency chain: work flows bottom-up, closure flows top-down\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${PROPOSAL_ID_URI}\"\n\"${EPOCH_REC}\" block \"${PROPOSAL_ID_URI}\" --by \"${IMPL_PLAN_ID_URI}\"\n\"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"${LEAF_TASK_A_ID_URI}\"\n```\n\n**[C-audit-never-delete]**\n- Given: any task or label\n- When: modifying\n- Then: add labels and comments only\n- Should not: delete or close tasks prematurely, remove labels\n\n**[C-clean-review-exit]**\n- Given: per-wave code review and end-of-epoch convergence\n- When: evaluating review results\n- Then: during a wave, only an open BLOCKER finding gates the wave; IMPORTANT and MINOR findings may stay open past a wave gate; after the last wave, convergence queries every open `pasture:finding` across all waves and targets 0\u002F0\u002F0 within the gate declaration's maxRounds; iterate review -> fix -> re-review up to the chosen review-effort budget; on budget exhaustion without reaching that target, SURFACE the outstanding findings to the user at a gate for a decision\n- Should not: require a zeroed round at a wave boundary; close a finding outside `C-finding-lifecycle`; proceed past the chosen budget without surfacing outstanding findings to the user; hardcode the budget; batch review across multiple slices\n\n**[C-dep-direction]**\n- Given: adding a Pasture dependency\n- When: determining direction\n- Then: parent blocked-by child: \"${EPOCH_REC}\" block \"${STAYS_OPEN_URI}\" --by \"${MUST_FINISH_FIRST_URI}\"\n- Should not: invert (child blocked-by parent)\n\n_Example (correct)_ — also illustrates: C-audit-dep-chain\n\n```bash\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${URE_ID_URI}\"\n```\n\n_Example (anti-pattern)_\n\n```bash\n\"${EPOCH_REC}\" block \"${URE_ID_URI}\" --by \"${REQUEST_ID_URI}\"\n```\n\n**[C-finding-lifecycle]**\n- Given: a code-review finding\n- When: recording or closing it\n- Then: create it as a child of its severity group labelled `pasture:finding`, and close it only when the reviewer who raised it verifies the fix — a worker or supervisor cannot close it, and a wave boundary never closes it\n- Should not: close a finding from a worker or supervisor, close one at a wave boundary, or record severity in the finding label (severity lives on its parent group)\n\n**[C-followup-leaf-adoption]**\n- Given: supervisor creates the follow-up slice\n- When: assigning user-DEFER'd UAT-item leaf tasks to follow-up slices\n- Then: add leaf task as child of follow-up slice (dual-parent: leaf blocks both the DEFER'd-items tracking group AND follow-up slice)\n- Should not: remove the leaf task from its original DEFER'd-items tracking parent\n\n**[C-followup-lifecycle]**\n- Given: follow-up epic created\n- When: starting follow-up work\n- Then: run same protocol phases with FOLLOWUP_* prefix: FOLLOWUP_URE → FOLLOWUP_URD → FOLLOWUP_PROPOSAL → FOLLOWUP_IMPL_PLAN → FOLLOWUP_SLICE\n- Should not: skip the follow-up lifecycle or treat the follow-up epic as a flat task list\n\n**[C-followup-timing]**\n- Given: UAT (Phase 5 or Phase 11) produces one or more user-DEFER'd items\n- When: creating the FOLLOWUP epic\n- Then: create the FOLLOWUP epic at UAT when user-DEFER'd items exist; the FOLLOWUP epic is fed ONLY by user-DEFER'd UAT items\n- Should not: trigger FOLLOWUP from any review severity (BLOCKER\u002FIMPORTANT\u002FMINOR) — no review severity is deferrable to FOLLOWUP (a finding's close rule is `C-finding-lifecycle`)\n\n**[C-frontmatter-refs]**\n- Given: cross-task references (URD, request, etc.)\n- When: linking tasks\n- Then: use description frontmatter references: block\n- Should not: invent relationship commands or use blocking dependencies for reference documents\n\n**[C-handoff-skill-invocation]**\n- Given: an agent is launched for a new phase (especially p7 to p8 handoff)\n- When: composing the launch prompt\n- Then: prompt MUST start with Skill(\u002Fpasture:{role}) invocation directive so the agent loads its role instructions\n- Should not: launch agents without skill invocation — they skip role-critical procedures like ephemeral exploration and leaf task creation\n\n**[C-integration-points]**\n- Given: multiple vertical slices share types, interfaces, or data flows\n- When: decomposing IMPL_PLAN in Phase 8\n- Then: identify horizontal Layer Integration Points and document them in IMPL_PLAN; each integration point specifies: owning slice, consuming slices, shared contract, merge timing; include integration points in slice descriptions so workers know what to export and import\n- Should not: leave cross-slice dependencies implicit; assume workers will discover contracts on their own\n\n**[C-review-consensus]**\n- Given: review cycle (p4 or p10)\n- When: evaluating\n- Then: all 3 reviewers must ACCEPT before proceeding\n- Should not: proceed with any REVISE vote outstanding\n\n**[C-review-effort-budget]**\n- Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate\n- When: deciding how much review-and-fix effort to spend per wave\n- Then: request a configurable review-effort budget from the user — defaults: (1) three rounds, (2) one round, (3) zero rounds, (4) unlimited, (5) custom; the review->fix->re-review loop iterates up to the chosen budget; convergence runs at the end over open `pasture:finding` tasks across all waves and targets 0\u002F0\u002F0 within maxRounds; on budget exhaustion without convergence, surface the outstanding findings to the user for a decision\n- Should not: hardcode the review-cycle budget (e.g. an unconditional fixed cap baked into the prose instead of asked); proceed past the chosen budget without surfacing outstanding findings to the user; loop forever when a finite budget was chosen\n\n**[C-slice-leaf-tasks]**\n- Given: vertical slice created\n- When: decomposing slice into implementation units\n- Then: create one or more Pasture leaf tasks per slice, named after the real work units they represent, with \"${EPOCH_REC}\" block \"${SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_URI}\"; a slice may have ANY number of leaves (the L1: types \u002F L2: tests \u002F L3: impl triple is ONE illustrative shape, not a required count)\n- Should not: create slices without leaf tasks — a slice with no children is undecomposed and cannot be tracked; force every slice into a fixed L1\u002FL2\u002FL3 triple when the real work units differ\n\n**[C-slice-review-before-close]**\n- Given: workers complete their implementation slices\n- When: slice implementation is done\n- Then: workers notify supervisor with \"${EPOCH_REC}\" note (not \"${EPOCH_REC}\" close); slices must be reviewed at least once by reviewers before closure; only the supervisor closes slices, after review passes\n- Should not: close slices immediately upon worker completion; allow workers to close their own slices\n\n**[C-supervisor-explore-ephemeral]**\n- Given: supervisor needs codebase exploration\n- When: starting Phase 8 (IMPL_PLAN)\n- Then: spawn ephemeral Explore subagents via Agent tool for scoped codebase queries; each subagent is short-lived and returns findings; no standing team overhead\n- Should not: explore the codebase directly as supervisor; maintain a standing explore team\n\n**[C-supervisor-no-impl]**\n- Given: supervisor role\n- When: implementation phase\n- Then: spawn workers for all code changes\n- Should not: implement code directly\n\n**[C-validation-cases]**\n- Given: any REQUEST (every request, not only fix-intent ones)\n- When: eliciting (URE), acceptance-testing (UAT), or implementing\n- Then: elicit concrete validation cases for the request — a definition of done plus correct and incorrect behaviours (inputs\u002Fbehaviors that must pass or must fail), confirm the case set with the user in UAT, evaluate the implementation against them, and store failing real-data cases as test fixtures\n- Should not: ship without validation cases; treat validation cases as applying to fix-intent requests only; introduce a request-type axis or enum to gate them (recognize what a request needs semantically instead)\n\n**[C-vertical-slices]**\n- Given: implementation decomposition\n- When: assigning work\n- Then: each production code path owned by exactly ONE worker (full vertical)\n- Should not: assign horizontal layers or same path to multiple workers\n\n### Handoffs\n\n| ID | Source | Target | Phase | Content Level | Required Fields |\n|----|--------|--------|-------|---------------|-----------------|\n| `h1` | `architect` | `supervisor` | `p7-handoff` | full-provenance | request, urd, proposal, ratified-plan, context, key-decisions, open-items, acceptance-criteria |\n| `h2` | `supervisor` | `worker` | `p9-worker-slices` | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, slice, context, key-decisions, open-items, acceptance-criteria |\n| `h3` | `supervisor` | `reviewer` | `p10-code-review` | summary-with-ids | request, urd, proposal, ratified-plan, impl-plan, context, key-decisions, acceptance-criteria |\n| `h5` | `reviewer` | `supervisor` | `p10-code-review` | summary-with-ids | request, urd, proposal, context, key-decisions, open-items, acceptance-criteria |\n| `h6` | `supervisor` | `architect` | `p3-propose` | summary-with-ids | request, urd, followup-epic, followup-ure, followup-urd, context, key-decisions, findings-summary, acceptance-criteria |\n\n### Startup Sequence\n\n**Step 1:** Call Skill(\u002Fpasture:supervisor) to load role instructions (`Skill(\u002Fpasture:supervisor)`)\n\n**Step 2:** Read RATIFIED_PLAN, URD, UAT, and elicit tasks via \"${EPOCH_REC}\" show for full context (`\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\" && \"${EPOCH_REC}\" show \"${URD_ID_URI}\" && \"${EPOCH_REC}\" show \"${UAT_ID_URI}\" && \"${EPOCH_REC}\" show \"${ELICIT_ID_URI}\"`)\n\n**Step 3:** Spawn ephemeral Explore subagents via Agent tool for scoped codebase queries — _Each subagent is short-lived and returns findings; no standing team overhead_\n\n**Step 4:** Decompose into vertical slices — _Vertical slices give one worker end-to-end ownership of a feature path (types → tests → impl → wiring) with clear file boundaries_ → `impl-plan`\n\n**Step 5:** Create leaf tasks (L1\u002FL2\u002FL3) for every slice (`CREATED_URI=$(\"${EPOCH_REC}\" create --kind task --title \"\u003Cdescription>\" --phase worker_slices --body \"Describe the specific work and reference full task URIs\")`)\n\n**Step 6:** Spawn workers via the Agent tool — set `name` for a named teammate, leave `name` empty for a backgrounded subagent. Choose the capability tier: T1 frontier for non-trivial slices, T2 standard for ordinary work. Pass the tier-mapped native model id and respect the concurrency cap of 4. → `worker-slices`\n\n### Introduction\n\nYou coordinate parallel task execution. See the project's AGENTS.md and ~\u002F.claude\u002FCLAUDE.md for coding standards and constraints.\n\n### What You Own\n\nYou own Phases 7-12 of the epoch: receive handoff from architect (p7), create vertical slice decomposition IMPL_PLAN (p8), spawn workers for parallel implementation the slice (p9), spawn reviewers for whole-wave code review with severity tree (p10), coordinate user acceptance test (p11), commit, push, and hand off (p12). You NEVER implement code directly — all implementation is delegated to workers.\n\n### Role Behaviors (Given\u002FWhen\u002FThen\u002FShould Not)\n\n**[B-sup-read-context]**\n- Given: handoff received\n- When: starting\n- Then: read ratified plan, URD, UAT, and elicit tasks for full context\n- Should not: start without reading all four\n\n**[B-sup-model-trivial]**\n- Given: trivial changes (single-file edits, config tweaks, typo fixes)\n- When: spawning a worker\n- Then: keep the worker at its mapped capability tier (T2 standard), with the tier's effort, to minimize cost and latency\n- Should not: raise a worker's tier for trivial work\n\n**[B-sup-model-nontrivial]**\n- Given: non-trivial changes (multi-file, architectural, logic-heavy)\n- When: spawning a worker\n- Then: override the worker to T1 frontier for the delegate_assignment tool to ensure quality\n- Should not: leave a high-complexity slice at the default tier\n\n**[B-sup-ride-the-wave]**\n- Given: Phase 8-10 execution\n- When: starting implementation\n- Then: follow the Ride the Wave cycle: plan tasks with integration points, launch the wave of workers, spawn reviewers for whole-wave review (only an open BLOCKER finding gates the wave), workers fix findings with atomic commits, and iterate review -> fix -> re-review up to the chosen review-effort budget; after the last wave, converge over open `pasture:finding` tasks across all waves toward 0\u002F0\u002F0 within maxRounds, and on exhaustion surface outstanding findings to the user at a gate\n- Should not: skip any stage; batch review across slices; hardcode the budget; proceed past the chosen budget without surfacing to the user; require a zeroed round to close a wave; close a finding outside `C-finding-lifecycle`\n\n### Completion Checklist\n\n**landing gates:**\n- [ ] All 3 reviewers ACCEPT at convergence and no open pasture:finding remains\n- [ ] FOLLOWUP epic created at UAT only if user-DEFER'd items exist (never from review severities)\n- [ ] git agent-commit used (not git commit -m)\n- [ ] All upstream tasks closed or dependency-resolved\n- [ ] Can only close on a review wave, not a worker wave\n- [ ] Eligible to close only after convergence finds no open pasture:finding across all waves\n\n**review-ready gates:**\n- [ ] All workers have notified completion via \"${EPOCH_REC}\" note\n- [ ] Ephemeral reviewers spawned for all slices\n- [ ] Severity groups (BLOCKER\u002FIMPORTANT\u002FMINOR) eagerly created per wave per axis per round\n\n### Inter-Agent Coordination\n\nAgents coordinate through tracker tasks and comments:\n\n| Action | Command |\n|--------|---------|\n| Transfer existing assignment (supervisor only) | `\"${EPOCH_REC}\" label \"${TASK_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR}\"` |\n| List blocked | `\"${EPOCH_REC}\" query --blocked` |\n| Add progress note | `\"${EPOCH_REC}\" note \"${TASK_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Progress: ...\"` |\n| Chain dependency | `\"${EPOCH_REC}\" block \"${PARENT_URI}\" --by \"${CHILD_URI}\"` |\n| Record slice completion | `\"${EPOCH_REC}\" note \"${SLICE_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Slice complete.\"` |\n| List in-progress | `\"${EPOCH_REC}\" query --status=in_progress` |\n| Check task details | `\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"` |\n| Update status | `\"${EPOCH_REC}\" status \"${TASK_ID_URI}\" --set in_progress` |\n\n## Workflows\n\n### Ride the Wave\n\nCoordinated Phase 8-10 execution pattern. The supervisor orchestrates the full cycle: plan slices, launch workers, spawn reviewers for whole-wave review, where only an open BLOCKER finding gates the wave, workers fix, and review repeats up to the chosen review-effort budget; after the last wave, convergence queries every open `pasture:finding` across all waves and targets 0\u002F0\u002F0 within maxRounds, surfacing outstanding findings to the user at a gate on exhaustion.\n\n### Stage 1: Plan _(sequential)_\n- Read RATIFIED_PLAN and URD via \"${EPOCH_REC}\" show (`\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\" && \"${EPOCH_REC}\" show \"${URD_ID_URI}\"`)\n- Spawn ephemeral Explore subagents (`subagent_type=Explore`) for scoped codebase queries — NOT standing teams\n- Use Explore findings to decompose into vertical slices with integration points\n- Create leaf tasks (L1\u002FL2\u002FL3) for every slice (`\"${EPOCH_REC}\" block \"${SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_URI}\"`)\n\nExit conditions:\n- **proceed**: All slices created with leaf tasks, dependency-chained, assigned\n\n### Stage 2: Build _(parallel)_\n- Spawn workers via the Agent tool — set `name` for a named teammate, leave `name` empty for a backgrounded subagent. Choose the capability tier: T1 frontier for non-trivial slices, T2 standard for ordinary work. Pass the tier-mapped native model id and respect the concurrency cap of 4.\n- Monitor worker progress via \"${EPOCH_REC}\" query and \"${EPOCH_REC}\" show (`\"${EPOCH_REC}\" query --phase worker_slices --status=in_progress`)\n- Supervisor commits at integration points (atomic commits) — commit small, integrate early and often\n\nExit conditions:\n- **proceed**: All workers have notified completion via \"${EPOCH_REC}\" note\n\n### Stage 3: Review + Fix Cycles _(conditional-loop)_\n- Spawn reviewers via Agent tool for whole-wave code review\n- Reviewers create one severity trio (BLOCKER\u002FIMPORTANT\u002FMINOR) per wave, per axis, per round\n- Track findings as `pasture:finding` children of the 3 severity groups; only an open BLOCKER gates the wave, and open findings converge at the end (FOLLOWUP is created later at UAT, fed only by user-DEFER'd items)\n- Workers fix ALL findings (BLOCKER, IMPORTANT, and MINOR)\n\n- Spawn 3 ephemeral reviewer subagents per wave review round (same pattern as Phase 4 plan review)\n- **WAVE GATE** = only an open BLOCKER finding blocks the wave; IMPORTANT and MINOR findings stay open\n- Per-wave review, per-slice fix; iterate up to the chosen review-effort budget\n- Fix flow: Stage 3 (dirty review) -> Stage 2 (worker fixes) -> Stage 3 (re-review)\n- Configurable review-effort budget (chosen at Phase 8: 3 rounds \u002F 1 round \u002F 0 rounds \u002F unlimited \u002F custom) — repeat review -> fix -> re-review up to the budget; convergence targets 0\u002F0\u002F0 within maxRounds; on budget exhaustion without convergence, surface outstanding findings to the user at a gate\n- **MUST end on a review wave** — cannot proceed after a worker wave without review\n\n```text\nStage 3 Flow (per-wave review):\n\n  ┌─────────────────────────────────────────┐\n  │ Spawn 3 ephemeral reviewers             │\n  │ Review slice (severity: BLOCKER\u002FIMP\u002FMIN)│\n  └──────────────┬──────────────────────────┘\n                 │\n          BLOCKER? ├── NO → wave advances, findings stay open\n                 │\n                 └── YES (an open BLOCKER)\n                       │\n                       ▼\n              ┌────────────────────┐\n              │ Stage 2: worker    │\n              │ fixes ALL findings │\n              │ (BLOCK\u002FIMP\u002FMINOR)  │\n              └────────┬───────────┘\n                       │\n                       ▼\n              ┌────────────────────┐\n              │ Stage 3: re-review │\n              │ (new ephemeral     │\n              │  reviewers)        │\n              └────────┬───────────┘\n                       │\n                 loop (re-review)\n                       │\n          repeat to the budget — convergence at the end, else surface to user\n```\n\nExit conditions:\n- **success**: Convergence finds no open pasture:finding across all waves — proceed to Phase 11 UAT\n- **continue**: An open BLOCKER gates the current wave, or convergence has not reached 0\u002F0\u002F0 within maxRounds — workers fix, spawn new ephemeral reviewers (up to the chosen review-effort budget; on exhaustion, surface to the user)\n\n##### Ride the Wave — Coordinated Phase 8-10 Execution\n\n```text\nPhase 8: PLAN\n  ├─ Read RATIFIED_PLAN + URD\n  ├─ Spawn ephemeral Explore subagents (delegation operation, scoped queries)\n  ├─ Use Explore findings to map codebase\n  ├─ Decompose into vertical slices + integration points\n  └─ Create leaf tasks for every slice\n\nPhase 9: BUILD\n  ├─ Spawn N Workers for parallel slice implementation\n  ├─ Workers implement their slices in parallel\n  └─ Workers do NOT shut down when finished\n\nPhase 10: REVIEW + FIX CYCLES (up to the chosen review-effort budget)\n  ├─ Cycle 1:\n  │   ├─ Spawn ephemeral reviewers (delegation operation, whole-wave review)\n  │   ├─ Reviewers review ALL slices (severity tree: BLOCKER\u002FIMPORTANT\u002FMINOR)\n  │   ├─ Reviewers label every finding pasture:finding under its severity group\n  │   ├─ Workers fix ALL findings (BLOCKER + IMPORTANT + MINOR) with atomic commits\n  │   └─ Spawn new ephemeral reviewers for re-review\n  ├─ Cycle 2 (if needed): same pattern\n  ├─ Cycle N (as many as needed): same pattern\n  └─ Each wave advances when no BLOCKER is open; IMPORTANT and MINOR findings stay open\n\nDONE → Phase 11 (UAT)\n  ├─ Shut down Workers\n  └─ FOLLOWUP epic (if any) is created at UAT from user-DEFER'd items only\n\nCycle Exit Conditions:\n  A wave gate: no open BLOCKER finding                        → the wave advances; open findings stay open\n  After the last wave: convergence over open pasture:finding  → targets 0\u002F0\u002F0 within maxRounds; on exhaustion, surface to the user\n  Finding close rule: see C-finding-lifecycle\n  Genuinely stuck (cannot converge)                           → Escalate to architect for re-planning\n\n```\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-8-implementation-plan)** \u003C- Phases 7-12\n\n**[sup-assign-slices]**\n- Given: slices created\n- When: assigning\n- Then: transfer an existing owner-responsibility assignment only after resolving its slot, successor assignment ID, registered committing actor and registered worker occupant; unassigned task allocation remains with the supervisor\n- Should not: leave slices unassigned\n\n**[sup-spawn-workers]**\n- Given: worker assignments\n- When: spawning\n- Then: use Agent tool with `subagent_type: \"general-purpose\"` and `run_in_background: true`, worker MUST call `Skill(\u002Fpasture:worker)` at start\n- Should not: spawn workers sequentially or use specialized agent types\n\n**[sup-teamcreate-msg]**\n- Given: an assignment delegated with the Agent operation\n- When: assigning work via SendMessage\n- Then: the message MUST include: (1) explicit instruction to call `Skill(\u002Fpasture:worker)`, (2) the Pasture task ID, (3) instruction to run `\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"` for full context, and (4) the handoff authored in the Pasture task body\n- Should not: send bare instructions without Pasture context — teammates have no prior knowledge of the task\n\n**[sup-layer-integration-points]**\n- Given: multiple vertical slices\n- When: slices share types, interfaces, or data flows\n- Then: identify horizontal Layer Integration Points and document them in the IMPL_PLAN (owner, consumers, shared contract, merge timing)\n- Should not: leave cross-slice dependencies implicit — divergence grows when slices develop in isolation without clear merge points\n\n**[sup-followup-deps]**\n- Given: IMPORTANT or MINOR severity groups\n- When: linking dependencies\n- Then: wire each group to its review round only: `\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"${IMPORTANT_GROUP_ID_URI}\"` — only an open BLOCKER gates the wave; open findings converge at the end\n- Should not: route IMPORTANT or MINOR severity groups to the FOLLOWUP epic, or wire them as blocking IMPL_PLAN\u002Fany slice — only BLOCKER findings block slices, and the FOLLOWUP epic is fed solely by user-DEFER'd UAT items\n\n**[frag--sup-review-all-slices]**\n- Given: all slices complete\n- When: starting review\n- Then: spawn 3 reviewers for ALL slices\n- Should not: assign reviewers to single slices\n\n**[frag--sup-review-check-each]**\n- Given: reviewer assigned\n- When: reviewing\n- Then: check each slice against criteria\n- Should not: skip any slice\n\n**[frag--sup-review-severity-groups]**\n- Given: a wave review round\n- When: creating severity groups\n- Then: ALWAYS create 3 severity groups (BLOCKER, IMPORTANT, MINOR) per wave, per axis, per round, even if empty\n- Should not: lazily create groups only when findings exist\n\n**[frag--sup-blocker-dual-parent]**\n- Given: BLOCKER finding\n- When: wiring dependencies\n- Then: add dual-parent: blocks BOTH the severity group AND the slice\n- Should not: wire BLOCKER to only one parent\n\n**[frag--sup-deferred-followup]**\n- Given: a review finding (BLOCKER, IMPORTANT, or MINOR)\n- When: categorizing\n- Then: track it in its severity group as an open finding; open findings do not block a wave unless they are BLOCKERs, and the FOLLOWUP epic is fed ONLY by user-DEFER'd UAT items, never by any review severity\n- Should not: route any review severity (BLOCKER\u002FIMPORTANT\u002FMINOR) to the FOLLOWUP epic; close a finding outside `C-finding-lifecycle`\n\n**[frag--sup-followup-epic-timing]**\n- Given: UAT (Phase 5 or 11) produces one or more user-DEFER'd items\n- When: finishing UAT\n- Then: supervisor creates the FOLLOWUP epic from the user-DEFER'd UAT items only\n- Should not: create a FOLLOWUP epic from any review severity (BLOCKER\u002FIMPORTANT\u002FMINOR)\n\n**[sup-worker-persistence]**\n- Given: worker completes initial implementation\n- When: deciding whether to shut down the worker\n- Then: keep workers alive for the review-fix cycle; workers notify supervisor via \"${EPOCH_REC}\" note but --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body do NOT shut down\n- Should not: shut down workers after first implementation pass; workers must stay alive to fix BLOCKERs and IMPORTANT findings\n\n**[sup-autonomous-progression]**\n- Given: non-user-gated phase completes\n- When: transitioning to next phase\n- Then: proceed autonomously; User gates: [request (p1 research depth); elicit (p2 requirements interview); plan-review (p5 plan UAT); impl-plan (p8 implementation effort and review budget); impl-uat (p11 implementation UAT)]\n- Should not: ask 'Should I proceed?' for autonomous phases; add user gates beyond the defined list; only pause for user-facing phases that require human input\n\n**[frag--review-clean-exit]**\n- Given: per-wave code review and end-of-epoch convergence\n- When: evaluating review results\n- Then: iterate review -> fix -> re-review up to the chosen review-effort budget; during a wave only an open BLOCKER finding gates progress, while IMPORTANT and MINOR findings stay open; after the last wave, converge over open `pasture:finding` tasks across all waves toward 0\u002F0\u002F0 within maxRounds; a finding closes only per `C-finding-lifecycle`; on budget exhaustion without convergence, SURFACE the outstanding findings to the user at a gate for a decision\n- Should not: hardcode the budget; proceed past the chosen budget without surfacing outstanding findings to the user; require a zeroed round at a wave boundary; close a finding outside `C-finding-lifecycle`; loop forever when a finite budget was chosen\n\n## Task Recovery\n\nThe tracker backend is recorded once in .agents.local\u002Fpasture\u002FEPOCH.md; read that file instead of re-probing. If EPOCH.md is absent, stop and ask the orchestrator to run detection.\n\nRecover from live tracker state at session start and after compaction; never trust cached task rows. Read the `rec:` path from the header and use it as the one entry point: `\"${EPOCH_REC}\" \u003Cop>`. The operation set is closed: create, label, block, note, show, query, ready, status, close, whoami, signal.\n\nStore selection: the adapter reads PASTURE_DB_PATH when set, otherwise the header's `db:`; the probe wrote that value from the same precedence (XDG_DATA_HOME\u002Fpasture\u002Fpasture.db, HOME\u002F.local\u002Fshare\u002Fpasture\u002Fpasture.db, then .pasture\u002Fpasture.db). Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission\u002Fschema\u002Fconfiguration repair; failure is not an empty work queue.\n\nThe adapter passes `--namespace` only when EPOCH.md records `namespace:`. That pin wins on both backends. Otherwise it omits the flag. Pasture then derives the namespace itself: PASTURE_NAMESPACE, else the git remote, then file:\u002F\u002F of the working directory. The ledger calls derive_namespace for the header and for every write that has no pin. That function is the one list of remote forms; do not restate it. With no origin, both backends use file:\u002F\u002F of the working directory, so invocations from different subdirectories use different namespaces. Queries without a pin follow that backend's derivation; pass `--all-namespaces` to opt out. When neither a pin nor PASTURE_NAMESPACE is set, pasture reads are unscoped and creation falls back to the git remote, then file:\u002F\u002F of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.\n\nRun `\"${EPOCH_REC}\" ready`, `\"${EPOCH_REC}\" query --blocked`, and `\"${EPOCH_REC}\" query --status in_progress`. For each referenced active task, run `\"${EPOCH_REC}\" show \"$TASK_URI\"`, `\"${EPOCH_REC}\" show \"$TASK_URI\" --notes`, and `\"${EPOCH_REC}\" show \"$TASK_URI\" --history`. All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the URI create printed; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.\n\nCreate prints the new task URI directly. Persist it before any label or note: create-plus-label is non-atomic, so on failure retain the URI and retry only the failed label\u002Fnote operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.\n\nAn owner is recorded with `\"${EPOCH_REC}\" label \"$TASK_URI\" owner:\u003Crole>`. That is a claim, not an allocation: an unassigned task stays unassigned until the supervisor allocates it, and repeating an identical claim is not allocation. Never invent an owner.\n\nParent stays open and is blocked by child: `\"${EPOCH_REC}\" block \"$PARENT_URI\" --by \"$CHILD_URI\"`. Reference documents belong in description frontmatter under references:, never fabricated blockers. Workers report evidence and handoffs without closing their slices or leaves; the supervisor closes only after independent review and satisfied gates. Use git agent-commit for local commits. Never install, enable, or modify Git hooks, Git hook path configuration, or pre-commit integration without explicit user approval. Tracker writes are durable; Git history lands separately.\n\nIf the header records `backend: error`, stop before the first mutation: the store exists but cannot be used, and falling back could lose earlier epochs. A mid-epoch write failure retries 3 times. After the third failure, write the attempted record to .agents.local\u002Fpasture\u002Fpending\u002F\u003Ctimestamp>-\u003Cop>.md, keep the recorded backend, and surface the pending record to the user at the next gate. Never switch backends and never drop the record.\n\n## Task Attribution\n\nSelect the current registered author with \"${EPOCH_REC}\" whoami. It prints the author recorded in the header or PASTURE_AUTHOR, and on the pasture backend it confirms that actor with agents show. It does not list agents and it does not invent one. If neither source names an author, it stops: set author: in EPOCH.md or export PASTURE_AUTHOR. Never auto-register or guess an identity during recovery. Every note supplies --author explicitly; machine examples use the pre-registered pasture-system\u002F00000000-0000-0000-0000-000000000000 actor. If it is absent, stop and request registration from the operator rather than claiming registration is fixed. Preserve human intent verbatim and quote historical attribution as evidence, not as a forged new author.\n\n## Writing to the User\n\nThese rules adapt ASD-STE100 Issue 9, Part 1 to chat messages. They are STE-aligned. The standard's Part 2 dictionary is not adopted, so no message can claim full compliance. This fragment covers wording: plain terms, short sentences, active voice, no invented labels, and the wording house rule, plus the pre-send check and the status template. Five skills carry these wording rules: architect-handoff, status, supervisor, user-elicit, user-uat.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Shape**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 1 | Lead with the result, the decision, or the blocker. | 6.1, 6.2 | 'This pins both the edge and the core case per branch, so a same-count swap fails.' to 'Result: the test now fails if a real case is replaced with a filler case.' |\n| 3 | One topic per paragraph. Max 3 sentences. | 6.5, 6.6 | One 25-word sentence with four stacked ideas, to three sentences with one idea each. |\n| 4 | For 3 or more items, a flow, or a comparison, use a list, a table, or an ASCII diagram. | 4.3 | 'Adopt the first option, then the second, then both' to a three-row table: option, what happens, cost. |\n| 5 | Cut filler, self-narration, hedging, praise, and closing offers. | house | 'It is important to note that this change effectively serves to ensure the test can detect' to 'The test detects a removed case.' |\n\n**Terms**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 6 | Put every term the user did not introduce in a Terms block before first use. Max 20 words per definition. Include the code name. | 1.1, 1.6 | 'per arm' to 'Arm: one of the 5 branches of the skip gate. Code: `arm`.' |\n| 7 | Use the industry term for the concept. Do not invent a term. | 1.8, 1.10 | 'a same-count swap' to 'a replacement that keeps the test count the same'. |\n| 8 | One name per item, in the message and across the session. | 1.11, 9.4 | 'the gate', then 'the event types', then 'the IR', to 'the event types' each time. |\n| 9 | One meaning per word. Do not use one word in two senses. | 1.2, 1.3 | 'pins' for a version lock and 'pins' for a test assertion, to 'locks the version' and 'the test checks'. |\n| 10 | No internal shorthand in prose. Write the substance first, then the reference in parentheses. | 1.10, 2.2, 8.6 | 'Adopt the option code and skip the explanation' to 'Adopt the retry limit (task: Importer retry limit, round 6).' |\n| 11 | Max 3 words in a noun cluster, and no stack of hidden ideas. A hyphenated stack still hides several. Break it with 'of', 'that', or a clause. | 2.1, 1.9 | 'mutation-load-bearing core case' to 'the core case (the one case per branch that fails when the branch breaks)'. |\n| 12 | Write each abbreviation in full once, then the short form in parentheses. | 2.2, 8.3 | 'the continuous integration job, then the CI job, with no first full form' to 'the continuous integration (CI) job, then the CI job.' |\n| 13 | Use plain verbs. No slang, no noun-as-verb, no phrasal verb. | 1.7, 1.10, 9.3 | 'reddens' to 'fails'. |\n\n**Sentences**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 14 | Max 20 words for an instruction or a question. Max 25 for a description. An identifier or a quote counts as one word. The cap is necessary, not sufficient. | 5.1, 6.3, 8.6 | 'The test checks ten cases, and because each branch needs two named cases and the count is no longer enough, a replacement can pass.' to 'The test checks 10 cases. A filler case can no longer pass.' |\n| 15 | Active voice. Name the actor: the test, CI, the agent, the merge. Simple tenses only. | 3.2, 3.6 | 'The gate will be rebased on the types.' to 'The agent rebases the gate on the event types.' |\n| 16 | One instruction per sentence. Imperative. Condition first. | 5.2, 5.3, 5.4 | 'All three at once, then check.' to 'If the types change, rebase the gate. Then run the tests.' |\n| 17 | Full sentences keep articles and verbs. Fragments only in lists, tables, and labels. | 4.2, 4.3, 4.5 | 'Defer the timeout, keep the retry limit fix' to 'Keep the retry limit. Defer the timeout change. The correctness review is round 3 and the test-quality review is round 2.' |\n| 18 | No semicolons. No em-dashes. Use a period or a list. | 8.1 + house | 'per arm, so a swap fails' with an em-dash, to 'per arm. That is 10 checks, so a swap fails.' |\n| 19 | Show the logic with because, so, but, if, then. | 4.4 | '10 predicates. A same-count swap fails.' to 'The test checks 10 cases, so a replacement that keeps the count cannot pass.' |\n\n**Exempt material**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 20 | Backtick each identifier. Max 2 per sentence. Give a plain gloss on first use. | 8.6 + house | Four bare references in one line, to one task, one design decision, and two reviews, each written in substance first. |\n| 21 | Quote user text, code, paths, and logs exactly. Explain them outside the quote. | 8.6 | A quote silently edited, to the blockquote verbatim with a plain reading on the next line. |\n\n**Risk**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 25 | Mark an irreversible action with WARNING or CAUTION, then the condition, then the result. | 7.1, 7.2, 7.3 | 'Removing the core case will fail the suite.' to 'CAUTION: if you remove the core case, the test passes and a broken branch ships.' |\n\n### Wording house rule\n\nNo self-praise is the wording house rule.\n\n| Rule | Requirement |\n|---|---|\n| No self-praise | No self-congratulation. State the next step in one line instead. |\n\n### Template: status update\n\n~~~markdown\n**Status:** \u003Cthe result or the state, max 25 words>.\n\n**Done**\n- \u003Cartifact or outcome, past tense, actor named> (`\u003Cpath>`, pull request #N, or task title).\n\n**Next**\n- \u003Cwhat happens next, and who does it>.\n\n**Needs you** (omit if empty)\n- \u003Cthe decision>, needed for \u003Cwhat it unblocks>.\n\n**Risk** (omit if empty)\n- WARNING or CAUTION: \u003Ccondition>. \u003Cresult>.\n\n**Terms** (new terms only)\n- **\u003Cterm>**: \u003Cmax 20 words>.\n~~~\n\nBudget: 120 words. Every Done item names an artefact. Do not restate the plan. One status per message, not one per thought.\n\n### Exempt material\n\nTwo material classes are exempt from the word and sentence caps: quoted text and code blocks. A third is allowed as technical nouns. Everything else obeys the caps.\n\n- **Quoted user text.** Verbatim in a blockquote. Never rewrite it into the house style. Put the plain reading after the quote.\n- **Code, logs, diffs, test output.** Exempt. Explain them in prose around the block.\n- **Industry terms of art.** Fixture, golden test, mutation testing, schema migration, fail-safe default, backfill, and closed enum are allowed as technical nouns. Define one in Terms if the user did not use it first.\n\nTwo more rows are relaxations, not exemptions. **Spelling** keeps one spelling per message and does not enforce American spelling. **Identifiers** are not exempt from a gloss, as rule 20 says.\n\nThe caps stay live for everything else. Rule 3 sets paragraph length, rule 14 sets the word caps, and rule 17 sets where a fragment is allowed; none of those three is an exemption.\n\n### Pre-send check\n\nRun this list on every user-facing message. A clean pass is not a gate.\n\n1. Does sentence one give the result, the decision, or the blocker?\n2. Does every term the reader did not introduce appear in Terms before first use?\n3. Search the draft for a token that matches `[A-Z]{1,3}-?[0-9]`, for a section sign (`§`), and for a five- or six-character token that matches `[A-Za-z0-9]{5,6}` and contains both a letter and a digit. Is each one defined, or replaced by its substance?\n4. Does one item have two names, or one word have two senses?\n5. Any sentence over 20 words (instruction or question) or 25 (description)?\n6. Any noun cluster over 3 words? Any slang verb, noun-as-verb, or phrasal verb?\n7. Any semicolon or em-dash?\n8. Any passive verb with no actor?\n9. Does an irreversible action carry WARNING or CAUTION?\n10. Delete one sentence. If nothing is lost, keep it deleted.\n\n## Question and Option Design\n\nThis fragment covers question and option design: grounding before asking, one decision, option shape, recommendation placement, the present template, and the weak-tool degrade. Wording rules, the STE-aligned claim, the status template, and the pre-send check are in Writing to the User. Four skills carry these question rules: architect-handoff, supervisor, user-elicit, user-uat. The status skill asks no question, so it does not carry this fragment. Ask through the `request_user_decision` operation, never by launching a subagent. That launch is `delegate_assignment`, a different operation. The role-tool binding in `internal\u002Fruntime\u002Fprofiles.go` lowers `request_user_decision` to the harness question tool and lowers `delegate_assignment` to the subagent tool.\n\n### The rules\n\nFormat: number, requirement, the STE rule it adapts, then a compact bad-to-good pair.\n\n**Grounding**\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 2 | Ground before you ask. Show what the thing is, where it lives, and one example. Never put the only explanation in the options. | 6.1, 4.4 | 'Which order: the types to the gate in parallel, or the gate first?' to 'Three parts share one type. The gate reads it. The fixtures copy it. Code: `ir.Event`.' |\n\n**Questions and options**\n\nRules 22, 23 and 24 are house rules. The house-rule table names them by number. Do not attach an STE number to a house rule.\n\n| # | Rule | Adapts | Bad to good |\n|---|---|---|---|\n| 22 | One question, one decision. Say what the answer changes. | house | 'Which order do you want, and are the labels clear?' to 'Which part merges first? The answer sets the order for the next 3 days.' |\n| 23 | Each option is self-contained: a label of max 6 words, what happens, and the cost. Use only Terms words. | house | 'Both' to 'Both limits. The import stops at the first limit it reaches. Cost: one more setting to test.' |\n| 24 | Put the recommendation outside the options, with one reason. You may also mark the label '(recommended)'. | house | An option labelled 'recommended' with no reason, to 'Recommendation: merge the event types first, because a later change costs rework in two places.' |\n\n### House rules for questions, options and recommendations\n\nASD-STE100 has no rule for questions, options, recommendations, or the turn split around a question tool. Rules 2, 22, 23 and 24 already carry grounding before asking, one decision per question, option design and recommendation placement. Four rows in this table are pointers to those rules. Question shape and Text-before-question turn add only what those rules do not. No self-praise is a wording rule; it is in Writing to the User. Never cite an STE number for a house rule.\n\n| Rule | Requirement |\n|---|---|\n| Question shape | A short header, max 4 words. |\n| Option design | Extends rule 23. Do not restate it. |\n| Recommendation placement | Extends rule 24. Do not restate it. |\n| Grounding before asking | Extends rule 2. Do not restate it. |\n| One decision per question | Extends rule 22. Do not restate it. |\n| Text-before-question turn | Send the grounding as text and end the turn. Ask through the `request_user_decision` operation in the next turn, because a question tool can hide prose sent in the same turn. |\n\n### Template: present a component, then ask\n\nSend the block below as text only, then end the turn. In the next turn, ask through the `request_user_decision` operation with the same options. The split is the Text-before-question turn house rule.\n\n~~~~markdown\n## \u003CPart name>: \u003Cwhat it does for the user, max 10 words>\n\n**Decision needed:** \u003Cone sentence>. The answer changes \u003Cwhat>.\n\n**Terms**\n- **\u003Cterm>**: \u003Cmax 20 words>. Code: `\u003Cidentifier>`.\n- **\u003Cterm>**: \u003Cmax 20 words>.\n\n**What it is**\n\u003Cmax 3 sentences. Name the actor. One fact per sentence.>\n\n**Definition**\n~~~\u003Clang>\n\u003Cthe smallest type, interface, schema, or command shape that shows the choice>\n~~~\n\n**Example**\n~~~\n\u003Cone realistic before and after, or input and output>\n~~~\n\n**Diagram**\n~~~\n\u003CASCII, plain labels, no em-dash>\n~~~\n\n**Options**\n\n| Option | What happens | Cost |\n|---|---|---|\n| \u003Clabel, max 6 words> | \u003Cone sentence> | \u003Cone sentence> |\n| \u003Clabel> | \u003Cone sentence> | \u003Cone sentence> |\n\n**Recommendation:** \u003Coption>, because \u003Cone reason>.\n~~~~\n\nThen, in the next turn:\n\n~~~\n`request_user_decision`: '\u003Cquestion, max 20 words>'\noptions: the same labels, with the 'what happens' and 'cost' text repeated in each description, because the picker can hide the table.\n~~~\n\nOne component per call. Use multi-select only when the options combine. Always add one open-ended feedback question.\n\n### Degrade when the question tool is weak\n\nSome hosts expose a weak question tool: it takes one question per call, it has no multi-select, or its picker hides option descriptions. Degrade in this order:\n\n1. Ask one question.\n2. Phrase the options as a single-select choice.\n3. State the assumption you will use if the answer is unavailable.\n\nPut the assumption in the text turn that grounds the question, not inside the options. An assumption never satisfies a user gate: a gated phase waits for the user's answer. The question still asks for one decision, and the recommendation names the cost of the assumption.\n\n### Pre-send check for a question\n\nRun this list before you send a question. It tests the question rules in this fragment. The wording pre-send check is in Writing to the User.\n\n1. Before a question: did the reader already see what the thing is, its definition, and one example, in an earlier turn or an earlier block?\n2. Can the reader choose from the options alone, with no other document? Is the recommendation outside the options?\n\n## First Steps\n\nThe architect creates a placeholder IMPL_PLAN task. Your first job is to fill it in:\n\n1. Read the RATIFIED_PLAN and the **URD** to understand the full scope, user requirements, and **identify production code paths**\n   ```bash\n   \"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"\n   \"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n   ```\n2. **Explore the codebase** using ephemeral Explore subagents (see [Exploration](#exploration-ephemeral-explore-subagents) below) — spawn scoped Explore subagents for codebase queries before decomposing into slices.\n3. **Prefer vertical slice decomposition** (feature ownership end-to-end) when possible:\n   - Vertical slice: Worker owns full feature (types → tests → impl → CLI\u002FAPI wiring)\n   - Horizontal layers: Use when shared infrastructure exists (common types, utilities)\n4. Determine layer structure following TDD principles:\n   - Layer 1: Types, interfaces, schemas (no deps)\n   - Layer 2: Tests for public interfaces (tests first!)\n   - Layer 3: Implementation (make tests pass)\n   - Layer 4: Integration tests (if needed)\n5. **Identify horizontal Layer Integration Points** where slices must inter-op — document in IMPL_PLAN (see [supervisor-plan-tasks](..\u002Fsupervisor-plan-tasks\u002FSKILL.md) step 5)\n6. **Create leaf tasks for every slice** (see [Step 3](#step-3-create-leaf-tasks-within-each-slice-critical)) — a slice without leaf tasks is undecomposed and cannot be tracked\n7. Bind SLICE_1_ID_URI and SLICE_2_ID_URI from the corresponding slice create outputs first. Update the IMPL_PLAN with the layer breakdown + integration points:\n   ```bash\n   \"${EPOCH_REC}\" note \"${IMPL_PLAN_ID_URI}\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body=\"$(cat \u003C\u003CEOF\n   ---\n   references:\n     request: \"${REQUEST_ID_URI}\"\n     urd: \"${URD_ID_URI}\"\n     proposal: \"${RATIFIED_PROPOSAL_ID_URI}\"\n   ---\n   ## Layer Structure (TDD)\n\n   ### Vertical Slices (Preferred)\n   - the first slice: Feature X command (Worker A owns types → tests → impl → CLI wiring)\n   - the second slice: Feature Y endpoint (Worker B owns types → tests → impl → API wiring)\n\n   OR\n\n   ### Horizontal Layers (If shared infrastructure)\n   - Layer 1: types.go, interfaces.go (no deps)\n   - Layer 2: service_test.go (tests first, depend on L1)\n   - Layer 3: service.go (implementation, make tests pass)\n   - Layer 4: integration_test.go (depends on L3)\n\n   ## Tasks\n   - \"${SLICE_1_ID_URI}\": the slice ...\n   - \"${SLICE_2_ID_URI}\": the slice ...\n   ...\n   EOF\n   )\"\n   ```\n\nSee: [..\u002Fsupervisor-plan-tasks\u002FSKILL.md](..\u002Fsupervisor-plan-tasks\u002FSKILL.md) for detailed vertical slice decomposition guidance.\n\n## Exploration (Ephemeral Explore Subagents)\n\nPer [C-supervisor-explore-ephemeral], spawn ephemeral Explore subagents (Agent tool, `subagent_type=Explore`) for scoped codebase queries. These are short-lived — they explore, return findings, and terminate. The supervisor stays lean.\n\n```\n\u002F\u002F Explore subagent — ephemeral, scoped query\ndelegation: {\n  subagent_type: \"Explore\",\n  run_in_background: true,\n  prompt: `Call Skill(\u002Fpasture:explore) to load your exploration role.\n\nQuery: \u003Cspecific codebase question>\nDepth: standard-research\n\nExplore the codebase for the requested topic. Produce structured findings\n(entry points, data flow, dependencies, patterns, conflicts). Return findings.`\n}\n```\n\nSpawn as many Explore subagents as needed — they are cheap and disposable. Use them during Phase 8 (IMPL_PLAN) to understand codebase areas before decomposing into slices.\n\n## Reading from Pasture\n\nGet the ratified plan and URD:\n```bash\n\"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"\n\"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n\"${EPOCH_REC}\" query --label=\"pasture:p6-plan:s6-ratify\" --status=open\n\"${EPOCH_REC}\" query --label=\"pasture:urd\"\n```\n\n## Implementation Task Structure\n\n```go\ntype ImplementationTask struct {\n    File            string          \u002F\u002F file path\n    TaskId          string          \u002F\u002F Pasture task ID (e.g., \"${TASK_A_URI}\")\n    RequirementRef  string\n    Prompt          string\n    Context         struct {\n        RelatedFiles    []struct{ File, Summary string }\n        TaskDescription string\n    }\n    Status          string          \u002F\u002F \"Pending\" | \"Claimed\" | \"Complete\" | \"Failed\"\n    \u002F\u002F Pasture fields:\n    ValidationChecklist []string              \u002F\u002F Items from RATIFIED_PLAN\n    AcceptanceCriteria  []AcceptanceCriterion \u002F\u002F {Given, When, Then, ShouldNot}\n    Tradeoffs           []Tradeoff           \u002F\u002F {Decision, Rationale}\n    RatifiedPlan        string               \u002F\u002F Link to RATIFIED_PLAN task ID\n}\n```\n\n## Creating Vertical Slices (Phase 8)\n\n\n\n### Step 1: Create the IMPL_PLAN task\n\n```bash\nIMPL_PLAN_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"IMPL_PLAN: \u003Cfeature>\" --phase impl_plan \\\n  --body \"---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n  proposal: \"${RATIFIED_PROPOSAL_ID_URI}\"\n---\n## Horizontal Layers\n- L1: Types and schemas\n- L2: Tests (import production code)\n- L3: Implementation + wiring\n\n## Vertical Slices\n- the first slice: \u003Cdescription> (files: ...)\n- the second slice: \u003Cdescription> (files: ...)\")\n\"${EPOCH_REC}\" block \"${REQUEST_ID_URI}\" --by \"${IMPL_PLAN_ID_URI}\"\n```\n\n### Step 2: Create each slice\n\n```bash\nSLICE_1_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"\u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n---\n## Specification\n\u003Cdetailed spec from ratified plan>\n\n## Files Owned\n\u003Clist of files>\n\n## Leaf Tasks\n- the types task: Types and interfaces\n- the tests task: Tests (import production code)\n- the implementation task: Implementation + wiring\n\n## Validation Checklist\n- [ ] Types defined\n- [ ] Tests written (import production code)\n- [ ] Implementation complete\n- [ ] Production path verified\")\n\"${EPOCH_REC}\" note \"$SLICE_1_ID_URI\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Design: '{\\\"validation_checklist\\\":[\\\"Types defined\\\",\\\"Tests written (import production code)\\\",\\\"Implementation complete\\\",\\\"Production path verified\\\"],\\\"acceptance_criteria\\\":[{\\\"given\\\":\\\"X\\\",\\\"when\\\":\\\"Y\\\",\\\"then\\\":\\\"Z\\\"}],\\\"ratified_plan\\\":\\\"${RATIFIED_PLAN_ID_URI}\\\"}'\"\n\"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n```\n\n### Step 3: Create leaf tasks within each slice (CRITICAL)\n\nPer [C-slice-leaf-tasks], create Pasture tasks for each implementation unit within the slice, then chain them as dependencies. Leaf tasks are what workers actually implement.\n\n```bash\n# L1: Types and interfaces for this slice\nLEAF_L1=$(\"${EPOCH_REC}\" create --kind task --title \"Types — \u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  slice: \"${SLICE_1_ID_URI}\"\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n---\n## Scope\nDefine types, interfaces, and schemas for this slice.\n\n## Files Owned\n- \u003Cfile-path-1>\n- \u003Cfile-path-2>\n\n## Acceptance Criteria\nGiven \u003Ccontext> when \u003Caction> then \u003Coutcome> should never \u003Canti-pattern>\")\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"$LEAF_L1\"\n\n# L2: Tests (import production code, will fail until L3)\nLEAF_L2=$(\"${EPOCH_REC}\" create --kind task --title \"Tests — \u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  slice: \"${SLICE_1_ID_URI}\"\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n---\n## Scope\nWrite tests that import from production code paths. Tests MUST fail until L3.\n\n## Files Owned\n- \u003Ctest-file-path-1>\n\n## Acceptance Criteria\nGiven \u003Ccontext> when \u003Caction> then \u003Coutcome> should never \u003Canti-pattern>\")\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"$LEAF_L2\"\n# L2 depends on L1 types being defined first\n\"${EPOCH_REC}\" block \"$LEAF_L2\" --by \"$LEAF_L1\"\n\n# L3: Implementation (makes tests pass)\nLEAF_L3=$(\"${EPOCH_REC}\" create --kind task --title \"Implementation — \u003Cslice name>\" --phase worker_slices \\\n  --body \"---\nreferences:\n  slice: \"${SLICE_1_ID_URI}\"\n  impl_plan: \"${IMPL_PLAN_ID_URI}\"\n---\n## Scope\nImplement production code to make L2 tests pass.\n\n## Files Owned\n- \u003Cimpl-file-path-1>\n\n## Acceptance Criteria\nGiven \u003Ccontext> when \u003Caction> then \u003Coutcome> should never \u003Canti-pattern>\")\n\"${EPOCH_REC}\" block \"${SLICE_1_ID_URI}\" --by \"$LEAF_L3\"\n# L3 depends on L2 tests existing first\n\"${EPOCH_REC}\" block \"$LEAF_L3\" --by \"$LEAF_L2\"\n```\n\nThe resulting tree per slice:\n\n```\nIMPL_PLAN\n  └── blocked by the slice\n        ├── blocked by the types task: Types\n        ├── blocked by the tests task: Tests (blocked by L1)\n        └── blocked by the implementation task: Impl  (blocked by L2)\n```\n\nWorkers are assigned to leaf tasks, not slices. The slice closes when all its leaf tasks close.\n\n## Assigning Slices\n\n```bash\n# Assign slices to workers\n\"${EPOCH_REC}\" label \"${SLICE_1_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR_1}\"\n\"${EPOCH_REC}\" label \"${SLICE_2_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR_2}\"\n\"${EPOCH_REC}\" label \"${SLICE_3_ID_URI}\" owner:\"${REGISTERED_WORKER_ACTOR_3}\"\n```\n\n## Spawning Workers\n\nPer [C-supervisor-no-impl], all implementation work — no matter how small — is delegated to a worker agent. The supervisor's job is coordination, tracking, and quality control.\n\nWorkers are **general-purpose agents** that call `\u002Fpasture:worker` at the start. Select the worker's capability tier from the model policy: T2 standard for ordinary work, T1 frontier for non-trivial slices. Resolve the tier's native model id for the target harness, pass it on the assignment, and respect the concurrency cap of 4.\n\n```\n\u002F\u002F Non-trivial work -> T1 frontier\ndelegation: {\n  subagent_type: \"general-purpose\",\n  model: \"\u003CT1 frontier native model id for this harness>\",\n  run_in_background: true,\n  prompt: `Call Skill(\u002Fpasture:worker) and implement the assigned slice.\\n\\nPasture Task ID: ${taskId}...`\n}\n\n\u002F\u002F Ordinary work (config tweak, typo fix, single-file edit) -> T2 standard\ndelegation: {\n  subagent_type: \"general-purpose\",\n  model: \"\u003CT2 standard native model id for this harness>\",\n  run_in_background: true,\n  prompt: `Call Skill(\u002Fpasture:worker) and fix the typo in...\\n\\nPasture Task ID: ${taskId}...`\n}\n\n\u002F\u002F WRONG: Supervisor implementing changes directly\nEdit({ file_path: \"src\u002Ffoo.ts\", ... })  \u002F\u002F Supervisors coordinate, they don't implement!\n\n\u002F\u002F WRONG: Do not use specialized agent types like \"pasture:worker\" directly\ndelegation: {\n  subagent_type: \"pasture:worker\",  \u002F\u002F This doesn't exist!\n  ...\n}\n```\n\n### Capability Tier Guide\n\n| Complexity | Tier | Examples |\n|------------|------|----------|\n| Trivial | T2 standard | Single-file edit, config change, typo fix, renaming, adding a label |\n| Non-trivial | T1 frontier | Multi-file changes, new features, architectural work, complex logic, test suites |\n\n**Handoff:** Before spawning each worker, author its handoff in the slice (or a dedicated handoff) Pasture task body — the task body IS the handoff (no filesystem path).\n\nSee: [..\u002Fsupervisor-spawn-worker\u002FSKILL.md](..\u002Fsupervisor-spawn-worker\u002FSKILL.md) for handoff template.\n\n### Delegated Assignment Context Requirements\n\nA delegated assignment has **zero prior context**. Every SendMessage assigning work MUST be self-contained:\n\n```\nSendMessage({\n  type: \"message\",\n  recipient: \"worker-1\",\n  content: `You are assigned the slice. Start by calling Skill(\u002Fpasture:worker).\n\nYour Pasture task ID: \"${SLICE_TASK_ID_URI}\"\nRun this to get full requirements + handoff: \"${EPOCH_REC}\" show \"${SLICE_TASK_ID_URI}\"\n\nKey context:\n- Request: \"${REQUEST_ID_URI}\" (run: \"${EPOCH_REC}\" show \"${REQUEST_ID_URI}\")\n- URD: \"${URD_ID_URI}\" (run: \"${EPOCH_REC}\" show \"${URD_ID_URI}\")\n- IMPL_PLAN: \"${IMPL_PLAN_ID_URI}\" (run: \"${EPOCH_REC}\" show \"${IMPL_PLAN_ID_URI}\")\n\nRead the handoff doc and your Pasture task before starting implementation.`,\n  summary: \"slice assignment\"\n})\n```\n\nPer [sup-teamcreate-msg], every assignment must include actionable `\"${EPOCH_REC}\" show` commands. Teammates cannot see your conversation history, the Pasture task tree, or any prior context.\n\nThe worker skill provides:\n- File ownership validation\n- Standard DI patterns\n- Completion\u002Fblocked signaling via Pasture\n\n## EPIC_FOLLOWUP Creation (Phase 5\u002F11)\n\nAfter UAT, if the user **DEFER'd** one or more items, create a follow-up epic from those DEFER'd items. Per [frag--sup-followup-epic-timing], create immediately after UAT completes. Review severities (BLOCKER\u002FIMPORTANT\u002FMINOR) are **never** routed here — they converge at the end; close rule: `C-finding-lifecycle`.\n\n### Step 1: Create follow-up epic\n\n```bash\nFOLLOWUP_EPIC_ID_URI=$(\"${EPOCH_REC}\" create --kind epic --title \"FOLLOWUP: User-deferred improvements from UAT\" --phase unscoped --priority 3 \\\n  --body=\"---\nreferences:\n  request: \"${REQUEST_ID_URI}\"\n  urd: \"${URD_ID_URI}\"\n  uat: ${UAT_ID_URI}\n---\nAggregated user-DEFER'd items from UAT (Phase 5\u002F11).\")\n\"${EPOCH_REC}\" label \"$FOLLOWUP_EPIC_ID_URI\" pasture:epic-followup\n\n# Link the DEFER'd UAT items as children of the follow-up epic\n\"${EPOCH_REC}\" block \"${FOLLOWUP_EPIC_ID_URI}\" --by \"${DEFERRED_ITEM_ID_1_URI}\"\n\"${EPOCH_REC}\" block \"${FOLLOWUP_EPIC_ID_URI}\" --by \"${DEFERRED_ITEM_ID_2_URI}\"\n```\n\nSeverity routing follows [frag--sup-blocker-dual-parent] and [frag--sup-deferred-followup]: only an open BLOCKER gates a wave; open findings converge at the end; the FOLLOWUP epic is DEFER-fed only.\n\n### Step 2: Follow-up lifecycle (same protocol, FOLLOWUP_* prefix)\n\nThe follow-up epic runs the same protocol phases with FOLLOWUP_* prefixed task types. The supervisor creates the initial lifecycle tasks:\n\n```\nFOLLOWUP epic (pasture:epic-followup)\n  ├── frontmatter reference: original URD\n  ├── frontmatter reference: original REVIEW-A\u002FB\u002FC tasks\n  └── blocked-by: FOLLOWUP_URE         (Phase 2: scope which DEFER'd items to address)\n        ├── frontmatter reference: FOLLOWUP_URD (living requirements document)\n        └── blocked-by: FOLLOWUP_PROPOSAL-1  (Phase 3: proposal for follow-up)\n              └── blocked-by: FOLLOWUP_IMPL_PLAN  (Phase 8: decompose into slices)\n                    ├── blocked-by: the first follow-up slice  (Phase 9)\n                    │     ├── blocked-by: deferred-item-leaf-task-...\n                    │     └── blocked-by: deferred-item-leaf-task-...\n                    └── blocked-by: the second follow-up slice\n```\n\n```bash\n# Create FOLLOWUP_URD first so its URI can be recorded in the URE references.\nFOLLOWUP_URD_ID=$(\"${EPOCH_REC}\" create --kind task --title \"FOLLOWUP_URD: Requirements for \u003Cfeature> follow-up\" --phase elicit \\\n  --body \"---\nreferences:\n  followup_epic: \"${FOLLOWUP_EPIC_ID_URI}\"\n  original_urd: \"${ORIGINAL_URD_ID_URI}\"\n---\nFollow-up requirements. References original URD.\")\n\"${EPOCH_REC}\" label \"$FOLLOWUP_URD_ID\" pasture:p2-user:s2_2-urd\n\"${EPOCH_REC}\" label \"$FOLLOWUP_URD_ID\" pasture:urd\n\n# Create FOLLOWUP_URE — user scoping which findings to address\nFOLLOWUP_URE_ID=$(\"${EPOCH_REC}\" create --kind task --title \"FOLLOWUP_URE: Scope follow-up for \u003Cfeature>\" --phase elicit \\\n  --body \"---\nreferences:\n  followup_epic: \\\"${FOLLOWUP_EPIC_ID_URI}\\\"\n  original_urd: \\\"${ORIGINAL_URD_ID_URI}\\\"\n  followup_urd: \\\"${FOLLOWUP_URD_ID}\\\"\n---\nScoping URE: determine which user-DEFER'd UAT items to address.\")\n\"${EPOCH_REC}\" label \"$FOLLOWUP_URE_ID\" pasture:p2-user:s2_1-elicit\n\"${EPOCH_REC}\" block \"${FOLLOWUP_EPIC_ID_URI}\" --by \"$FOLLOWUP_URE_ID\"\n```\n\nThe remaining lifecycle tasks (FOLLOWUP_PROPOSAL, FOLLOWUP_IMPL_PLAN, FOLLOWUP_SLICE) are created as the follow-up epic progresses through the protocol phases.\n\n### Step 3: DEFER'd-item leaf adoption (dual-parent)\n\nWhen the supervisor creates the follow-up slice tasks during the follow-up implementation phase, the user-DEFER'd UAT-item leaf tasks gain a second parent (dual-parent: leaf blocks BOTH the DEFER'd-items tracking group AND the follow-up slice):\n\n```bash\n# Leaf task gets dual-parent: DEFER'd-items tracking group + follow-up slice\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${DEFERRED_ITEM_LEAF_ID_1_URI}\"\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${DEFERRED_ITEM_LEAF_ID_2_URI}\"\n# Leaf task already has: \"${EPOCH_REC}\" block \"${DEFERRED_ITEMS_TRACKING_GROUP_ID_URI}\" --by \"${LEAF_TASK_ID_URI}\"\n```\n\n### Follow-up Handoff Chain\n\nInside the follow-up lifecycle, the same handoff types (h1-h4) reapply:\n\nThe follow-up lifecycle starts ONLY from user-DEFER'd UAT items (`C-followup-timing`); code review never starts it. The Supervisor creates the FOLLOWUP epic from those items (same actor), then:\n\n| Order | Handoff | Transition |\n|-------|---------|------------|\n| 1 | *(none)* | Supervisor creates the FOLLOWUP epic from user-DEFER'd UAT items (same actor) |\n| 2 | *(none)* | Supervisor creates FOLLOWUP_URE (same actor) |\n| 3 | *(none)* | Supervisor creates FOLLOWUP_URD (same actor) |\n| 4 | h6 | Supervisor → Architect: Hands off FOLLOWUP_URE + FOLLOWUP_URD for FOLLOWUP_PROPOSAL |\n| 5 | h1 | Architect → Supervisor: After FOLLOWUP_PROPOSAL ratified |\n| 6 | h2 | Supervisor → Worker: the follow-up slice with DEFER'd-item leaf tasks |\n| 7 | h3 | Supervisor → Reviewer: One code review per follow-up wave |\n| 8 | h4 | Worker → Reviewer: Follow-up slice completion |\n\nFollow-up handoff storage: each handoff is authored in its Pasture task body (no filesystem path).\n\nSee `..\u002Farchitect-handoff\u002FSKILL.md` for handoff field requirements.\n\n## Impl-Review Severity Tree Procedure\n\nThe severity behaviors for code review (Phase 10) are defined above as structured behaviors (frag--sup-review-all-slices through frag--sup-followup-epic-timing). The following subsections describe the operational procedures.\n\n### Severity Tree (EAGER Creation)\n\nPer [frag--sup-review-severity-groups], create ONE severity trio per wave, per axis, per round — not one per slice:\n\n```bash\n# Wave 1 contains the first slice, the second slice, and the third slice.\n# Step 1: Create all 3 severity groups immediately (EAGER)\nBLOCKER_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"WAVE-{W}-REVIEW-{axis}-{round} BLOCKER\" --phase code_review \\\n  --body \"---\nreferences:\n  wave: 1\n  slices:\n    - \\\"${SLICE_1_1_ID_URI}\\\"\n    - \\\"${SLICE_1_2_ID_URI}\\\"\n    - \\\"${SLICE_1_3_ID_URI}\\\"\n  review_round: 1\n---\nBLOCKER findings from Reviewer A (Correctness) on wave 1.\")\n\"${EPOCH_REC}\" label \"$BLOCKER_ID_URI\" pasture:severity:blocker\n\nIMPORTANT_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"WAVE-{W}-REVIEW-{axis}-{round} IMPORTANT\" --phase code_review \\\n  --body \"---\nreferences:\n  wave: 1\n  slices:\n    - \\\"${SLICE_1_1_ID_URI}\\\"\n    - \\\"${SLICE_1_2_ID_URI}\\\"\n    - \\\"${SLICE_1_3_ID_URI}\\\"\n  review_round: 1\n---\nIMPORTANT findings from Reviewer A (Correctness) on wave 1.\")\n\"${EPOCH_REC}\" label \"$IMPORTANT_ID_URI\" pasture:severity:important\n\nMINOR_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"WAVE-{W}-REVIEW-{axis}-{round} MINOR\" --phase code_review \\\n  --body \"---\nreferences:\n  wave: 1\n  slices:\n    - \\\"${SLICE_1_1_ID_URI}\\\"\n    - \\\"${SLICE_1_2_ID_URI}\\\"\n    - \\\"${SLICE_1_3_ID_URI}\\\"\n  review_round: 1\n---\nMINOR findings from Reviewer A (Correctness) on wave 1.\")\n\"${EPOCH_REC}\" label \"$MINOR_ID_URI\" pasture:severity:minor\n\n# Step 2: Wire the one severity trio to the wave's review round task\n\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"$BLOCKER_ID_URI\"\n\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"$IMPORTANT_ID_URI\"\n\"${EPOCH_REC}\" block \"${REVIEW_ROUND_ID_URI}\" --by \"$MINOR_ID_URI\"\n# NEVER wire severity groups to IMPL_PLAN or slices directly.\n# BLOCKER findings block slices via dual-parent (see below).\n# Open findings converge at the end; only an open BLOCKER gates the wave. IMPORTANT\u002FMINOR are NOT routed to FOLLOWUP.\n# The FOLLOWUP epic is fed ONLY by user-DEFER'd UAT items (see Follow-up Epic section).\n\n# Step 3: Close empty groups immediately\n# If a group has no findings, close it right away\n\"${EPOCH_REC}\" close \"$IMPORTANT_ID_URI\"   # if no IMPORTANT findings\n\"${EPOCH_REC}\" close \"$MINOR_ID_URI\"        # if no MINOR findings\n```\n\n### Naming Convention\n\nName the review for one wave, one axis, and one round. Axis A is correctness, B is test quality, and C is elegance. List every slice of that wave on the review. Create one severity trio under it: blocker, important, and minor. Do not create one review per slice.\n\nThe first wave's correctness review, first round, has one blocker group, one important group, and one minor group. A later wave gets its own review.\n\n## Tracking Progress\n\n```bash\n# Check all implementation slices\n\"${EPOCH_REC}\" query --phase worker_slices --status=in_progress\n\n# Check for blocked tasks\n\"${EPOCH_REC}\" query --blocked --phase worker_slices\n\n# Check completed slices\n\"${EPOCH_REC}\" query --phase worker_slices --status=closed\n\n# Check specific task\n\"${EPOCH_REC}\" show \"${TASK_ID_URI}\"\n\n# Check severity groups from review\n\"${EPOCH_REC}\" query --label=\"pasture:severity:blocker\"\n\"${EPOCH_REC}\" query --label=\"pasture:severity:important\"\n\"${EPOCH_REC}\" query --label=\"pasture:severity:minor\"\n\n# Check follow-up epics\n\"${EPOCH_REC}\" query --label=\"pasture:epic-followup\"\n```\n\n## Signal Capture\n\nRecord the user's friction or approval when it appears, so a later project-level skill can distill it. Capture is a side effect of work already happening: it never prompts the user and never blocks a phase.\n\n### Closed kind list\n\nThe kind is a closed list. Use exactly one of:\n\n- `frustration`: the user shows annoyance, repeats a complaint, or rejects the interaction itself.\n- `positive-signal`: the user endorses a direction or a result before a gate asks.\n- `satisfaction`: the user accepts a gate and says the result is what they wanted.\n- `confusion`: the user asks what a term means, misreads a question, or answers a different question.\n- `correction`: the user corrects a fact, a requirement, or an earlier answer.\n\n### One feedback task per epoch\n\nOn the pasture backend, the epoch creates one feedback task at epoch start and writes `feedback: \u003Ctask URI>` into `.agents.local\u002Fpasture\u002FEPOCH.md`. A second run reads the `feedback:` line and does not create another task. On the ledger backend, create nothing and record nothing: there is no feedback task and no `feedback:` line. No other skill creates a feedback task. If the pasture line is absent, the signal operation fails and records nothing; do not create a task to fill the gap.\n\n### Line format and recording\n\nWrite one JSON object per signal. The fields, in this order, are kind, phase, skill, entry and quote.\n\n~~~\n{\"kind\":\"\u003Ckind>\",\"phase\":\"\u003Cphase>\",\"skill\":\"\u003Cskill>\",\"entry\":\"\u003Centry-ref>\",\"quote\":\"\u003Cshort verbatim quote>\"}\n~~~\n\n- `kind`: one of the registered kinds above, exactly.\n- `phase`: one of request, elicit, propose, review, plan-review, ratify, handoff, impl-plan, worker-slices, code-review, impl-uat, landing.\n- `skill`: the skill that recorded it, named exactly as the skill directory.\n- `entry`: the record that holds the interaction, such as a task URI plus the question or section.\n- `quote`: a short verbatim fragment, max 20 words. Never paraphrase or tidy it.\n\nRecord the signal with one call. Do not name a backend command in this section.\n\n~~~bash\n\"${EPOCH_REC}\" signal --kind confusion --phase elicit --skill user-elicit --entry '\u003Ctask URI>#end-vision' --quote 'what does arm mean here'\n~~~\n\nThe adapter records that JSON object. An empty feedback id fails in the adapter and records nothing. Write the call in the same turn as the work. Do not ask permission to record. Do not wait for the write before you continue the phase.\n\nIf the write fails, follow the tracker write-failure rule: retry, keep the recorded backend, and surface the pending line at the next gate. A failed record never blocks the phase and never prompts the user.\n\u003C!-- END GENERATED FROM pasture schema -->\n",{"name":5,"skills":42,"description":7},"pasture:afk-implement, pasture:impl-review, pasture:impl-slice, pasture:supervisor-commit, pasture:supervisor-plan-tasks, pasture:supervisor-spawn-worker, pasture:supervisor-track-progress","main","5813de22110ddc609b465a982b4811646ff72d18","skills\u002Fsupervisor",0,"https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham","dhpham.com","2026-11-11 16:48:48",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add dayvidpham\u002Fpasture --skill supervisor",{"tool":57,"command":58},"bunx","bunx skills add dayvidpham\u002Fpasture --skill supervisor",{"tool":60,"command":61},"pnpm","pnpm dlx skills add dayvidpham\u002Fpasture --skill supervisor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fsupervisor\u002FSKILL.md",true,[],[66,74,87,97,109,119],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":37},"01M6DAP7307B3JVZX5DSNAE08Y","fixture","Isolated fixture skill","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Ftestdata\u002Finstall\u002Fglobal\u002Fclaude-code\u002Fnative-marketplace\u002Ffixture-plugin\u002Fskills\u002Ffixture\u002FSKILL.md",[],[68,73],"fixture skill",{"skillNo":75,"name":35,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":37},"01M6DAP48A4K365N83NBG0GFVC","Vertical slice implementer (full production code path)","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker\u002FSKILL.md",[],[35,80,81,27,82,83,84,85,20,86],"implementer","code","Production","full","complete","vertical slice","path",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":37},"01M6DAP18QJM7P7N31TYGNJBCP","worker-implement","Implement assigned vertical slice following TDD layers","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-implement\u002FSKILL.md",[],[94,35,27,85,95,20,96],"worker implement","layers","tdd",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":37},"01M6DANYHC7P63RFEN26F70MC2","worker-complete","Signal slice completion after quality gates pass","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-complete\u002FSKILL.md",[],[35,104,84,105,20,106,107,108],"worker complete","signal","gates","quality","quality gates",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":37},"01M6DANWZ31TRP4NN4T1BFYKSR","worker-blocked","Report a blocker to supervisor via Pasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-blocked\u002FSKILL.md",[],[116,35,117,118,5],"worker blocked","via","report",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":130,"publishedAt":37},"01M6DANSVDBXBFH93B6EX3H2QK","user-uat","User Acceptance Testing with demonstrative examples","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fuser-uat\u002FSKILL.md",[125],{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[131,132,133,134,135,136,137,138,139],"uat","user uat","user","acceptance testing","with","user acceptance testing","examples","acceptance","testing"]