[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAFEHS4TWQ87137WDPP7QV":3,"skill-same:01M6DAFEHS4TWQ87137WDPP7QV":53},{"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":26,"linkOnly":27,"markdownContent":28,"markdownBody":29,"frontMatter":30,"refName":31,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6DAFEHS4TWQ87137WDPP7QV","supervisor-plan-tasks",null,"Decompose ratified plan into vertical slices (SLICE-{W}-{N})","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\u002Finternal\u002Ftarget\u002Fclaudecode\u002Fassets\u002Fpasture-skills\u002Fskills\u002Fsupervisor-plan-tasks\u002FSKILL.md",[],[19,20,21,22,23,24,25],"plan","supervisor plan tasks","supervisor","tasks","plan tasks","decompose","slice","2026-11-10 10:12:30",false,"---\nname: supervisor-plan-tasks\ndescription: Decompose ratified plan into vertical slices (SLICE-{W}-{N})\n---\n\n# Supervisor Plan Tasks\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Command:** `pasture:supervisor:plan-tasks` — Decompose ratified plan into vertical slices (SLICE-{W}-{N})\n\nBreak RATIFIED_PLAN into vertical slice Implementation tasks for workers.\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-8-implementation-plan)** \u003C- Phase 8\n\n### Layer Cake — TDD Parallelism Within Vertical Slices\n\n```text\nLayer 0: Shared infrastructure (common types, enums — optional, parallel)\n   │\nVertical Slices (parallel, each worker owns one slice):\n   │\n   ├─ Layer 1: Types for this slice (e.g. enums, dataclasses, schemas)\n   │\n   ├─ Layer 2: Tests importing production code (will FAIL — expected!)\n   │\n   ├─ ...  (additional layers as needed)\n   │\n   └─ Layer M: Implementation + wiring (makes tests PASS)\n   │\nIMPLEMENTATION COMPLETE\n\nEach layer completes before the next begins.\nWithin a layer, all tasks run in parallel.\n\nKey TDD principle:\n  Layer 2 tests will fail initially — this is expected.\n  Layer M workers implement code to make those tests pass.\n\nL2 Test File Requirements:\n  1. Import from actual source files — never define mock implementations inline\n  2. Fail until later-layer implementation exists — if tests pass immediately, something is wrong\n  3. Test behavior via DI mocks — mock dependencies, not the code under test\n  4. Define expected API contracts — tests specify what the implementation should do\n\n```\n\n**[sup-plan-impl-plan-decompose]**\n- Given: IMPL_PLAN placeholder\n- When: planning\n- Then: decompose into vertical slices (production code paths)\n- Should not: decompose into horizontal layers (files)\n\n**[sup-plan-ratified-plan-tasks]**\n- Given: RATIFIED_PLAN features\u002Fcommands\n- When: creating tasks\n- Then: assign one vertical slice per worker (full end-to-end)\n- Should not: assign horizontal layers (types worker, tests worker, impl worker)\n\n**[sup-plan-vertical-slice-define]**\n- Given: vertical slice\n- When: defining\n- Then: specify production code path and backward planning approach\n- Should not: leave workers guessing what end users will run\n\n**[sup-plan-validation-checklist]**\n- Given: validation_checklist\n- When: distributing\n- Then: include production code verification\n- Should not: allow test-only validation\n\n**[sup-plan-integration-points-identify]**\n- Given: multiple vertical slices\n- When: slices share types, interfaces, or data flows\n- Then: identify horizontal Layer Integration Points where slices must inter-op and document them in the IMPL_PLAN with owning slice, consuming slices, and the shared contract (type, interface, or protocol)\n- Should not: leave cross-slice dependencies implicit — divergence grows when slices develop in isolation without clear merge points\n\n**[sup-plan-integration-points-include]**\n- Given: integration points identified\n- When: creating slice tasks\n- Then: include each integration point in the relevant slice descriptions so workers know what they must export and what they may import\n- Should not: assume workers will discover cross-slice contracts on their own\n\n**[sup-plan-interface-first]**\n- Given: slices that share types, interfaces, or contracts (R3, per C-interface-first-slices)\n- When: deciding decomposition order\n- Then: prefer extracting a horizontal interface-first FOUNDATION slice (all public types\u002Finterfaces\u002Fcontracts) that lands first, so the dependent implementation slices can compile against the contracts and run in PARALLEL\n- Should not: force a linear slice chain (A->B->C) when the runtime dependency is only on interfaces that could be exported up front\n\n**[sup-plan-review-effort-budget]**\n- Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate (per C-review-effort-budget)\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: 3 rounds, 1 round, 0 rounds, unlimited, custom); the Phase-10 review->fix->re-review loop iterates up to the chosen budget, only an open BLOCKER gates a wave, and convergence at the end 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; proceed past the chosen budget without surfacing outstanding findings to the user; 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## Model Policy and Fallback Chain\n\nA role names a capability tier. A tier carries a neutral default model nickname, an effort level, and its default roles.\n\n\u003C!-- pasture:model-chain-ask -->\n\n| Tier | Name | Default model | Effort | Effective roles |\n|------|------|---------------|--------|----------------|\n| T1 | frontier | frontier | high | architect, epoch, supervisor |\n| T2 | standard | standard | medium | reviewer, worker |\n| T3 | mini | mini | low | (runtime choice only) |\n\nThe reviewer's effective default is T2 standard, so the table lists reviewer under T2, not under T3. T3 mini has no effective default role; it is a phase-8 runtime choice. Record that choice as `reviewer_tier: T3` in `.agents.local\u002Fpasture\u002FEPOCH.md` and pass that tier's native model id when reviewers are spawned. Each harness publishes every tier's native id in its emitted agent files (`capability-tier` lines). On a harness with no smaller model than T2, T3's id equals T2's; Codex is that harness, so a cheap review there uses the standard profile.\n\n**Ask here, and at the matching gate in the other phase.** At phase 1 and again at phase 8, ask the user for three models: a primary, a secondary, and a tertiary. One gate, two asks, not five. The three form one fallback chain: when a provider is exhausted, use the next model in the chain; never fail the epoch. Record the chain on the request or IMPL_PLAN task and repeat it in every handoff. Advance the chain in the architect and supervisor surfaces too: they spawn the reviewers and workers, so a provider exhaustion reaches them first.\n\n**Reviewer override.** The reviewer tier is the reviewer role's TierOverride, not a separate review-budget type. The default is T2 standard (full review); treat T3 mini as an epoch-recorded runtime choice, never a compile-time one.\n\n**Concurrency cap.** Run at most 4 delegated agents at once in one stage. Phase 9 spawns one worker per slice and has no slice bound; when a plan has more slices than the cap, start them in batches of that size. The cap is a batching policy, not a protocol maximum. It bounds concurrency only; maxRounds remains the only bound on review rounds.\n\n## When to Use\n\nReceived handoff from architect with RATIFIED_PLAN task ID and placeholder IMPL_PLAN task.\n\n## Request the Review-Effort Budget (Phase 8 user gate)\n\nAt the **start of Phase 8** — like the Phase-1 research-depth gate — request a **configurable review-effort budget** from the user (per `C-review-effort-budget`). This is one of the user-gated phases. Present the default choices:\n\n| Option | Meaning |\n|--------|---------|\n| **3 rounds** | Up to three review -> fix -> re-review cycles per wave |\n| **1 round** | A single review + one fix pass |\n| **0 rounds** | No review-fix iteration (review once, surface anything found) |\n| **unlimited** | Iterate until convergence (no upper bound) |\n| **custom** | A user-specified number of rounds |\n\nThe Phase-10 review->fix->re-review loop iterates **up to the chosen budget**. Only an open BLOCKER gates a wave; IMPORTANT and MINOR findings stay open, and convergence at the end queries every open `pasture:finding` toward 0\u002F0\u002F0 within **maxRounds**. On **budget exhaustion without convergence**, SURFACE the outstanding findings to the user for a decision — never proceed dirty, never loop forever, and never hardcode the budget. Record the chosen budget in the IMPL_PLAN so workers and reviewers know the bound.\n\n## Critical: Vertical Slices, Not Horizontal Layers\n\n**ANTI-PATTERN (causes dual-export problem):**\n```\nTask A: Layer 1 - types.go (all types)\nTask B: Layer 2 - service_test.go (all tests)\nTask C: Layer 3 - service.go (all implementation)\nTask D: Layer 4 - CLI wiring\n```\n\n**Problem:** No worker owns full production code path → dual-export anti-pattern\n\n**CORRECT PATTERN:**\n```\nfeature list command (one worker owns the full vertical)\n  - ListOptions, ListEntry types (L1)\n  - Tests importing `cli-tool feature list` CLI (L2)\n  - service.ListItems() implementation (L3)\n  - listCmd (cobra) RunE handler wiring (L3)\n\nfeature detail command (another worker owns the full vertical)\n  - DetailView types (L1)\n  - Tests importing `cli-tool feature detail` CLI (L2)\n  - service.GetItemDetail() implementation (L3)\n  - detailCmd (cobra) RunE handler wiring (L3)\n```\n\n## Steps\n\n1. **Read RATIFIED_PLAN and URD tasks:**\n   ```bash\n   \"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"\n   \"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n   ```\n\n2. **Identify production code paths** (what end users will actually run):\n   - CLI commands: `cli-tool feature`, `cli-tool feature list`, `cli-tool feature detail`\n   - API endpoints: `POST \u002Fapi\u002Fitems`, `GET \u002Fapi\u002Fitems\u002F:id`\n   - Background jobs: `sync-daemon`, `backup-daemon`\n\n3. **Decompose into vertical slices** (one per production code path):\n   - Each slice = one command\u002Fendpoint\u002Fjob\n   - Each slice owned by ONE worker\n   - Each slice goes from types → tests → implementation → wiring\n\n4. **Identify shared infrastructure** (optional Layer 0):\n   - Common types used across ALL slices (e.g., base error enums)\n   - Shared utilities (not specific to one slice)\n   - If significant, create Layer 0 tasks (parallel, no deps)\n\n5. **Identify horizontal Layer Integration Points** (where slices must inter-op):\n   - For each pair of slices, ask: \"Does slice A need to import\u002Fcall\u002Fconsume anything from slice B?\"\n   - If yes, document the integration point: owning slice, consuming slice(s), and the shared contract\n   - Integration points should merge **sooner rather than later** — delaying inter-op causes divergence\n   - Common integration points: shared type definitions, event interfaces, registry patterns, DI bindings\n   - Each integration point gets an explicit owner (the slice that defines\u002Fexports it)\n\n   ```\n   ## Integration Points (example)\n\n   | ID | Contract | Owner (exports) | Consumer(s) (imports) | Merge Timing |\n   |----|----------|-----------------|-----------------------|--------------|\n   | IP-1 | PhaseEnum type | foundation slice | schema slice, skill slice, injection slice | types |\n   | IP-2 | ConstraintContext interface | foundation slice | schema slice | types |\n   | IP-3 | SkillRegistry protocol | skill slice | injection slice | implementation |\n   ```\n\n   **Interface-first decomposition (R3, Strong SHOULD — see `C-interface-first-slices`):** when slices share contracts, prefer extracting a horizontal **interface-first FOUNDATION slice** that exports ALL public types\u002Finterfaces\u002Fcontracts and lands FIRST (a barrier). The dependent implementation slices then compile against those contracts and run in **parallel**, instead of being forced into a linear `A → B → C` chain whose only real coupling is at the interface boundary. Reserve a linear chain for cases where the runtime dependency genuinely exceeds the interface.\n\n6. **Create vertical slice tasks:**\n   ```bash\n   SLICE_1_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"Implement the feature list command\" --phase worker_slices \\\n     --body=\"$(cat \u003C\u003CEOF\n   ---\n   references:\n     impl_plan: \"${IMPL_PLAN_ID_URI}\"\n     urd: \"${URD_ID_URI}\"\n   ---\n   ## Production Code Path\n\n   **End user runs:** \\`.\u002Fbin\u002Fcli-tool feature list\\`\n\n   ## Worker Owns (Full Vertical Slice)\n\n   Plan backwards from production code path:\n   1. End: CLI entry point \\`listCmd (cobra.Command) RunE handler\\`\n   2. Back: Service call \\`feature.NewService(deps).ListItems(opts)\\`\n   3. Back: Service method \\`ListItems(opts ListOptions) ([]ListEntry, error)\\`\n   4. Back: Types \\`ListOptions\\`, \\`ListEntry\\`\n\n   ## Files You Own (Within These Files)\n\n   - pkg\u002Ffeature\u002Ftypes.go (ListOptions, ListEntry ONLY)\n   - cmd\u002Ffeature\u002Flist_test.go (import actual CLI)\n   - pkg\u002Ffeature\u002Fservice.go (ListItems method ONLY)\n   - cmd\u002Ffeature\u002Flist.go (list subcommand wiring ONLY)\n\n   ## Implementation Order (Layers Within Your Slice)\n\n   **Layer 1: Types** (your slice only)\n   - Create ListOptions, ListEntry\n   - Do NOT add types for other slices (e.g., DetailView)\n\n   **Layer 2: Tests** (importing production code)\n   - Import actual CLI: \\`import \"myproject\u002Fcmd\u002Ffeature\"\\`\n   - Test the actual command users will run\n   - Tests will FAIL - expected, no implementation yet\n\n   **Layer 3: Implementation + Wiring**\n   - Implement service.ListItems() method\n   - Wire cobra command with feature.NewService(realDeps)\n   - No TODO placeholders\n   - Tests should now PASS\n\n   ## Validation\n\n   Before marking complete:\n   - [ ] Production code verified via code inspection (no TODOs, real deps wired)\n   - [ ] Tests import actual CLI (not test-only export)\n   - [ ] No dual-export anti-pattern\n   - [ ] No TODO placeholders\n   - [ ] Service wired with real dependencies\n   EOF\n   )\")\n   \"${EPOCH_REC}\" note \"$SLICE_1_ID_URI\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Design: '{\n       \\\"productionCodePath\\\": \\\"cli-tool feature list\\\",\n       \\\"validation_checklist\\\": [\n         \\\"Type checking passes\\\",\n         \\\"Tests pass\\\",\n         \\\"Production code verified via code inspection\\\",\n         \\\"Tests import production CLI package\\\",\n         \\\"No TODO placeholders in CLI action\\\",\n         \\\"Service wired with real dependencies\\\"\n       ],\n       \\\"acceptance_criteria\\\": [{\n         \\\"given\\\": \\\"user runs cli-tool feature list\\\",\n         \\\"when\\\": \\\"command executes\\\",\n         \\\"then\\\": \\\"shows list from actual service\\\",\n         \\\"should_not\\\": \\\"have dual-export (test vs production paths)\\\"\n       }],\n       \\\"ratified_plan\\\": \\\"${RATIFIED_PLAN_ID_URI}\\\"\n     }'\"\n\n   \"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n   ```\n\n7. **Update IMPL_PLAN with vertical slice breakdown + integration points:** First create each remaining slice using the Step 6 pattern and bind SLICE_2_ID_URI, SLICE_3_ID_URI and SLICE_4_ID_URI from their respective create outputs.\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   ## Vertical Slice Decomposition\n\n   Each worker owns ONE production code path (full vertical slice from CLI → service → types).\n\n   ### Shared Infrastructure (Layer 0 - optional)\n   - Common types: SortOrder, OutputFormat, ErrorCode enums\n   - Implemented first, parallel\n\n   ### Vertical Slices (parallel, after Layer 0)\n\n   **default command: \"cli-tool feature\"**\n   - Worker: A\n   - Production path: \\`.\u002Fbin\u002Fcli-tool feature\\`\n   - Owns: default action, recent items logic\n    - Task: \"${SLICE_1_ID_URI}\"\n\n   **list command: \"cli-tool feature list\"**\n   - Worker: B\n   - Production path: \\`.\u002Fbin\u002Fcli-tool feature list\\`\n   - Owns: ListOptions types, list tests, listItems() method, list CLI wiring\n    - Task: \"${SLICE_2_ID_URI}\"\n\n   **detail command: \"cli-tool feature detail\"**\n   - Worker: C\n    - Production path: \\`.\u002Fbin\u002Fcli-tool feature detail FEATURE_ID\\`\n   - Owns: DetailView types, detail tests, getItemDetail() method, detail CLI wiring\n    - Task: ${SLICE_3_ID_URI}\n\n   **search command: \"cli-tool feature search\"**\n   - Worker: D\n   - Production path: \\`.\u002Fbin\u002Fcli-tool feature search\\`\n   - Owns: SearchQuery types, search tests, searchItems() method, search CLI wiring\n    - Task: ${SLICE_4_ID_URI}\n\n   ## Horizontal Layer Integration Points\n\n   Where slices must inter-op. Merge sooner, not later — divergence grows with delay.\n\n   | ID | Contract | Owner (exports) | Consumer(s) (imports) | Merge Timing |\n   |----|----------|-----------------|-----------------------|--------------|\n   | IP-1 | FeatureError enum | the default command | the list command, the detail command, the search command | L1 (types) |\n   | IP-2 | BaseService interface | the default command | the list command, the detail command | L1 (types) |\n\n   ## Execution Order\n\n   1. Layer 0 (if needed): Shared infrastructure (parallel)\n   2. the default command through the search command: Each worker implements their vertical slice (parallel)\n      - Within each slice: Types (L1) → Tests (L2) → Impl+Wiring (L3)\n   3. Integration points merge at documented timing (L1 contracts first, L3 wiring last)\n\n   ## Validation\n\n   All production code paths verified via code inspection:\n   - .\u002Fbin\u002Fcli-tool feature\n   - .\u002Fbin\u002Fcli-tool feature list\n   - .\u002Fbin\u002Fcli-tool feature detail \"${SLICE_1_ID_URI}\"\n   - .\u002Fbin\u002Fcli-tool feature search\n   - All integration points verified: contracts match between owner and consumers\n   EOF\n   )\"\n   ```\n\n## Vertical Slice Task Structure\n\n```json\n{\n  \"slice\": \"feature-list\",\n  \"productionCodePath\": \"cli-tool feature list\",\n  \"taskId\": \"${TASK_A_URI}\",\n  \"workerOwns\": {\n    \"endPoint\": \"listCmd (cobra.Command) RunE handler\",\n    \"types\": [\"ListOptions\", \"ListEntry\"],\n    \"tests\": [\"cmd\u002Ffeature\u002Flist_test.go\"],\n    \"implementation\": [\n      \"(*FeatureService).ListItems() method\",\n      \"listCmd wired with feature.NewService(realDeps)\"\n    ]\n  },\n  \"planningApproach\": \"Backwards from production code path\",\n  \"validation_checklist\": [\n    \"Type checking passes\",\n    \"Tests pass\",\n    \"Production code works: .\u002Fbin\u002Faura sessions list\",\n    \"Tests import production CLI (not test-only export)\",\n    \"No TODO placeholders\",\n    \"Service wired with real dependencies\"\n  ],\n  \"acceptance_criteria\": [{\n    \"given\": \"user runs aura sessions list\",\n    \"when\": \"command executes\",\n    \"then\": \"shows session list from actual service\",\n    \"should_not\": \"have dual-export or TODO placeholders\"\n  }],\n  \"ratified_plan\": \"${RATIFIED_PLAN_ID_URI}\",\n  \"urd\": \"\u003Curd-id>\"\n}\n```\n\n## Layer Cake Within Each Vertical Slice\n\nEach worker implements their slice in layers (TDD approach):\n\n```\nWorker A's Slice: \"aura sessions list\"\n  Layer 1: Types (ListOptions, SessionListEntry only)\n  Layer 2: Tests (import sessions package, test list action)\n           → Tests will FAIL (expected - no impl yet)\n  Layer 3: Implementation + Wiring\n           - (*SessionsService).ListSessions() method\n           - listCmd wired with sessions.NewService(deps)\n           - Wire action to call service\n           → Tests should now PASS\n```\n\n**Important:** Layer 2 tests failing is expected. Worker knows tests define the contract, implementation comes in Layer 3.\n\n## Red Flags vs Green Flags\n\n**Red flags (horizontal layer decomposition):**\n- Tasks organized by layer: \"Layer 1 all types\", \"Layer 2 all tests\"\n- Worker assigned \"all types\" or \"all tests\" instead of feature slice\n- No production code path specified per task\n- Tasks describe \"file to modify\" not \"production code path to deliver\"\n\n**Green flags (vertical slice decomposition):**\n- Each task specifies production code path (e.g., \"aura sessions list\")\n- Worker owns full vertical (types → tests → impl → wiring)\n- Task description says \"plan backwards from end point\"\n- Validation checklist includes \"production code works: .\u002Fbin\u002Faura \u003Ccommand>\"\n- Workers can execute independently (parallel slices)\n\n## Shared Infrastructure (Layer 0)\n\nIf multiple slices share common infrastructure:\n\n```\nLayer 0 Tasks (parallel, implemented first):\n- Common enums: SortOrder, OutputFormat, SessionsErrorCode\n- Common types: ParseHealth (used by all slices)\n- Shared utilities: isSidechainSession(), getGitBranch()\n```\n\nThen vertical slices proceed in parallel, depending on Layer 0.\n\n**Key insight:** Shared infrastructure is the exception, not the rule. Most types\u002Flogic belong to specific slices.\n\n## Follow-up Implementation Plan (FOLLOWUP_IMPL_PLAN)\n\nWhen planning for a follow-up epic (after receiving h1 from architect post-FOLLOWUP_PROPOSAL ratification), the same vertical slice decomposition applies:\n\n```bash\n# Create FOLLOWUP_IMPL_PLAN\nFOLLOWUP_IMPL_PLAN_ID_URI=$(\"${EPOCH_REC}\" create --kind epic --title \"FOLLOWUP_IMPL_PLAN: \u003Cfollow-up feature>\" --phase impl_plan --priority 2 \\\n  --body=\"---\nreferences:\n  followup_epic: \"${FOLLOWUP_EPIC_ID_URI}\"\n  original_request: \"${REQUEST_ID_URI}\"\n  original_urd: \"${URD_ID_URI}\"\n  followup_urd: \"${FOLLOWUP_URD_ID_URI}\"\n  followup_proposal: \"${FOLLOWUP_PROPOSAL_ID_URI}\"\n---\nVertical slice decomposition for follow-up epic.\")\n\n# Create the follow-up slice with DEFER'd-item leaf tasks\nFOLLOWUP_SLICE_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"Follow-up: \u003Cdescription>\" --phase worker_slices \\\n  --body=\"---\nreferences:\n  followup_impl_plan: \"${FOLLOWUP_IMPL_PLAN_ID_URI}\"\n  followup_urd: \"${FOLLOWUP_URD_ID_URI}\"\n---\n## DEFER'd-Item Leaf Tasks\n| Leaf Task ID | Source UAT | DEFER'd Item | Description |\n|---|---|---|---|\n| \"${LEAF_ID_1_URI}\" | \"${UAT_ID_URI}\" | \"${DEFERRED_ITEM_ID_URI}\" | \u003Cdescription> |\n| \"${LEAF_ID_2_URI}\" | \"${UAT_ID_URI}\" | \"${DEFERRED_ITEM_ID_URI}\" | \u003Cdescription> |\n\n## Specification\n\u003Cdetailed spec>\n\n## Validation Checklist\n- [ ] All DEFER'd-item leaf tasks resolved\n- [ ] Tests pass\n- [ ] Production code path verified\")\n\n# Wire dual-parent: leaf blocks BOTH the DEFER'd-items tracking group AND the follow-up slice\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_1_URI}\"\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_2_URI}\"\n```\n\u003C!-- END GENERATED FROM pasture schema -->\n","# Supervisor Plan Tasks\n\n\u003C!-- BEGIN GENERATED FROM pasture schema -->\n\u003C!-- GENERATED FROM pasture v0.0.33 artifact v1 -->\n**Command:** `pasture:supervisor:plan-tasks` — Decompose ratified plan into vertical slices (SLICE-{W}-{N})\n\nBreak RATIFIED_PLAN into vertical slice Implementation tasks for workers.\n\n**-> [Full workflow in PROCESS.md](..\u002Fprotocol\u002FPROCESS.md#phase-8-implementation-plan)** \u003C- Phase 8\n\n### Layer Cake — TDD Parallelism Within Vertical Slices\n\n```text\nLayer 0: Shared infrastructure (common types, enums — optional, parallel)\n   │\nVertical Slices (parallel, each worker owns one slice):\n   │\n   ├─ Layer 1: Types for this slice (e.g. enums, dataclasses, schemas)\n   │\n   ├─ Layer 2: Tests importing production code (will FAIL — expected!)\n   │\n   ├─ ...  (additional layers as needed)\n   │\n   └─ Layer M: Implementation + wiring (makes tests PASS)\n   │\nIMPLEMENTATION COMPLETE\n\nEach layer completes before the next begins.\nWithin a layer, all tasks run in parallel.\n\nKey TDD principle:\n  Layer 2 tests will fail initially — this is expected.\n  Layer M workers implement code to make those tests pass.\n\nL2 Test File Requirements:\n  1. Import from actual source files — never define mock implementations inline\n  2. Fail until later-layer implementation exists — if tests pass immediately, something is wrong\n  3. Test behavior via DI mocks — mock dependencies, not the code under test\n  4. Define expected API contracts — tests specify what the implementation should do\n\n```\n\n**[sup-plan-impl-plan-decompose]**\n- Given: IMPL_PLAN placeholder\n- When: planning\n- Then: decompose into vertical slices (production code paths)\n- Should not: decompose into horizontal layers (files)\n\n**[sup-plan-ratified-plan-tasks]**\n- Given: RATIFIED_PLAN features\u002Fcommands\n- When: creating tasks\n- Then: assign one vertical slice per worker (full end-to-end)\n- Should not: assign horizontal layers (types worker, tests worker, impl worker)\n\n**[sup-plan-vertical-slice-define]**\n- Given: vertical slice\n- When: defining\n- Then: specify production code path and backward planning approach\n- Should not: leave workers guessing what end users will run\n\n**[sup-plan-validation-checklist]**\n- Given: validation_checklist\n- When: distributing\n- Then: include production code verification\n- Should not: allow test-only validation\n\n**[sup-plan-integration-points-identify]**\n- Given: multiple vertical slices\n- When: slices share types, interfaces, or data flows\n- Then: identify horizontal Layer Integration Points where slices must inter-op and document them in the IMPL_PLAN with owning slice, consuming slices, and the shared contract (type, interface, or protocol)\n- Should not: leave cross-slice dependencies implicit — divergence grows when slices develop in isolation without clear merge points\n\n**[sup-plan-integration-points-include]**\n- Given: integration points identified\n- When: creating slice tasks\n- Then: include each integration point in the relevant slice descriptions so workers know what they must export and what they may import\n- Should not: assume workers will discover cross-slice contracts on their own\n\n**[sup-plan-interface-first]**\n- Given: slices that share types, interfaces, or contracts (R3, per C-interface-first-slices)\n- When: deciding decomposition order\n- Then: prefer extracting a horizontal interface-first FOUNDATION slice (all public types\u002Finterfaces\u002Fcontracts) that lands first, so the dependent implementation slices can compile against the contracts and run in PARALLEL\n- Should not: force a linear slice chain (A->B->C) when the runtime dependency is only on interfaces that could be exported up front\n\n**[sup-plan-review-effort-budget]**\n- Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate (per C-review-effort-budget)\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: 3 rounds, 1 round, 0 rounds, unlimited, custom); the Phase-10 review->fix->re-review loop iterates up to the chosen budget, only an open BLOCKER gates a wave, and convergence at the end 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; proceed past the chosen budget without surfacing outstanding findings to the user; 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## Model Policy and Fallback Chain\n\nA role names a capability tier. A tier carries a neutral default model nickname, an effort level, and its default roles.\n\n\u003C!-- pasture:model-chain-ask -->\n\n| Tier | Name | Default model | Effort | Effective roles |\n|------|------|---------------|--------|----------------|\n| T1 | frontier | frontier | high | architect, epoch, supervisor |\n| T2 | standard | standard | medium | reviewer, worker |\n| T3 | mini | mini | low | (runtime choice only) |\n\nThe reviewer's effective default is T2 standard, so the table lists reviewer under T2, not under T3. T3 mini has no effective default role; it is a phase-8 runtime choice. Record that choice as `reviewer_tier: T3` in `.agents.local\u002Fpasture\u002FEPOCH.md` and pass that tier's native model id when reviewers are spawned. Each harness publishes every tier's native id in its emitted agent files (`capability-tier` lines). On a harness with no smaller model than T2, T3's id equals T2's; Codex is that harness, so a cheap review there uses the standard profile.\n\n**Ask here, and at the matching gate in the other phase.** At phase 1 and again at phase 8, ask the user for three models: a primary, a secondary, and a tertiary. One gate, two asks, not five. The three form one fallback chain: when a provider is exhausted, use the next model in the chain; never fail the epoch. Record the chain on the request or IMPL_PLAN task and repeat it in every handoff. Advance the chain in the architect and supervisor surfaces too: they spawn the reviewers and workers, so a provider exhaustion reaches them first.\n\n**Reviewer override.** The reviewer tier is the reviewer role's TierOverride, not a separate review-budget type. The default is T2 standard (full review); treat T3 mini as an epoch-recorded runtime choice, never a compile-time one.\n\n**Concurrency cap.** Run at most 4 delegated agents at once in one stage. Phase 9 spawns one worker per slice and has no slice bound; when a plan has more slices than the cap, start them in batches of that size. The cap is a batching policy, not a protocol maximum. It bounds concurrency only; maxRounds remains the only bound on review rounds.\n\n## When to Use\n\nReceived handoff from architect with RATIFIED_PLAN task ID and placeholder IMPL_PLAN task.\n\n## Request the Review-Effort Budget (Phase 8 user gate)\n\nAt the **start of Phase 8** — like the Phase-1 research-depth gate — request a **configurable review-effort budget** from the user (per `C-review-effort-budget`). This is one of the user-gated phases. Present the default choices:\n\n| Option | Meaning |\n|--------|---------|\n| **3 rounds** | Up to three review -> fix -> re-review cycles per wave |\n| **1 round** | A single review + one fix pass |\n| **0 rounds** | No review-fix iteration (review once, surface anything found) |\n| **unlimited** | Iterate until convergence (no upper bound) |\n| **custom** | A user-specified number of rounds |\n\nThe Phase-10 review->fix->re-review loop iterates **up to the chosen budget**. Only an open BLOCKER gates a wave; IMPORTANT and MINOR findings stay open, and convergence at the end queries every open `pasture:finding` toward 0\u002F0\u002F0 within **maxRounds**. On **budget exhaustion without convergence**, SURFACE the outstanding findings to the user for a decision — never proceed dirty, never loop forever, and never hardcode the budget. Record the chosen budget in the IMPL_PLAN so workers and reviewers know the bound.\n\n## Critical: Vertical Slices, Not Horizontal Layers\n\n**ANTI-PATTERN (causes dual-export problem):**\n```\nTask A: Layer 1 - types.go (all types)\nTask B: Layer 2 - service_test.go (all tests)\nTask C: Layer 3 - service.go (all implementation)\nTask D: Layer 4 - CLI wiring\n```\n\n**Problem:** No worker owns full production code path → dual-export anti-pattern\n\n**CORRECT PATTERN:**\n```\nfeature list command (one worker owns the full vertical)\n  - ListOptions, ListEntry types (L1)\n  - Tests importing `cli-tool feature list` CLI (L2)\n  - service.ListItems() implementation (L3)\n  - listCmd (cobra) RunE handler wiring (L3)\n\nfeature detail command (another worker owns the full vertical)\n  - DetailView types (L1)\n  - Tests importing `cli-tool feature detail` CLI (L2)\n  - service.GetItemDetail() implementation (L3)\n  - detailCmd (cobra) RunE handler wiring (L3)\n```\n\n## Steps\n\n1. **Read RATIFIED_PLAN and URD tasks:**\n   ```bash\n   \"${EPOCH_REC}\" show \"${RATIFIED_PLAN_ID_URI}\"\n   \"${EPOCH_REC}\" show \"${URD_ID_URI}\"\n   ```\n\n2. **Identify production code paths** (what end users will actually run):\n   - CLI commands: `cli-tool feature`, `cli-tool feature list`, `cli-tool feature detail`\n   - API endpoints: `POST \u002Fapi\u002Fitems`, `GET \u002Fapi\u002Fitems\u002F:id`\n   - Background jobs: `sync-daemon`, `backup-daemon`\n\n3. **Decompose into vertical slices** (one per production code path):\n   - Each slice = one command\u002Fendpoint\u002Fjob\n   - Each slice owned by ONE worker\n   - Each slice goes from types → tests → implementation → wiring\n\n4. **Identify shared infrastructure** (optional Layer 0):\n   - Common types used across ALL slices (e.g., base error enums)\n   - Shared utilities (not specific to one slice)\n   - If significant, create Layer 0 tasks (parallel, no deps)\n\n5. **Identify horizontal Layer Integration Points** (where slices must inter-op):\n   - For each pair of slices, ask: \"Does slice A need to import\u002Fcall\u002Fconsume anything from slice B?\"\n   - If yes, document the integration point: owning slice, consuming slice(s), and the shared contract\n   - Integration points should merge **sooner rather than later** — delaying inter-op causes divergence\n   - Common integration points: shared type definitions, event interfaces, registry patterns, DI bindings\n   - Each integration point gets an explicit owner (the slice that defines\u002Fexports it)\n\n   ```\n   ## Integration Points (example)\n\n   | ID | Contract | Owner (exports) | Consumer(s) (imports) | Merge Timing |\n   |----|----------|-----------------|-----------------------|--------------|\n   | IP-1 | PhaseEnum type | foundation slice | schema slice, skill slice, injection slice | types |\n   | IP-2 | ConstraintContext interface | foundation slice | schema slice | types |\n   | IP-3 | SkillRegistry protocol | skill slice | injection slice | implementation |\n   ```\n\n   **Interface-first decomposition (R3, Strong SHOULD — see `C-interface-first-slices`):** when slices share contracts, prefer extracting a horizontal **interface-first FOUNDATION slice** that exports ALL public types\u002Finterfaces\u002Fcontracts and lands FIRST (a barrier). The dependent implementation slices then compile against those contracts and run in **parallel**, instead of being forced into a linear `A → B → C` chain whose only real coupling is at the interface boundary. Reserve a linear chain for cases where the runtime dependency genuinely exceeds the interface.\n\n6. **Create vertical slice tasks:**\n   ```bash\n   SLICE_1_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"Implement the feature list command\" --phase worker_slices \\\n     --body=\"$(cat \u003C\u003CEOF\n   ---\n   references:\n     impl_plan: \"${IMPL_PLAN_ID_URI}\"\n     urd: \"${URD_ID_URI}\"\n   ---\n   ## Production Code Path\n\n   **End user runs:** \\`.\u002Fbin\u002Fcli-tool feature list\\`\n\n   ## Worker Owns (Full Vertical Slice)\n\n   Plan backwards from production code path:\n   1. End: CLI entry point \\`listCmd (cobra.Command) RunE handler\\`\n   2. Back: Service call \\`feature.NewService(deps).ListItems(opts)\\`\n   3. Back: Service method \\`ListItems(opts ListOptions) ([]ListEntry, error)\\`\n   4. Back: Types \\`ListOptions\\`, \\`ListEntry\\`\n\n   ## Files You Own (Within These Files)\n\n   - pkg\u002Ffeature\u002Ftypes.go (ListOptions, ListEntry ONLY)\n   - cmd\u002Ffeature\u002Flist_test.go (import actual CLI)\n   - pkg\u002Ffeature\u002Fservice.go (ListItems method ONLY)\n   - cmd\u002Ffeature\u002Flist.go (list subcommand wiring ONLY)\n\n   ## Implementation Order (Layers Within Your Slice)\n\n   **Layer 1: Types** (your slice only)\n   - Create ListOptions, ListEntry\n   - Do NOT add types for other slices (e.g., DetailView)\n\n   **Layer 2: Tests** (importing production code)\n   - Import actual CLI: \\`import \"myproject\u002Fcmd\u002Ffeature\"\\`\n   - Test the actual command users will run\n   - Tests will FAIL - expected, no implementation yet\n\n   **Layer 3: Implementation + Wiring**\n   - Implement service.ListItems() method\n   - Wire cobra command with feature.NewService(realDeps)\n   - No TODO placeholders\n   - Tests should now PASS\n\n   ## Validation\n\n   Before marking complete:\n   - [ ] Production code verified via code inspection (no TODOs, real deps wired)\n   - [ ] Tests import actual CLI (not test-only export)\n   - [ ] No dual-export anti-pattern\n   - [ ] No TODO placeholders\n   - [ ] Service wired with real dependencies\n   EOF\n   )\")\n   \"${EPOCH_REC}\" note \"$SLICE_1_ID_URI\" --author pasture-system\u002F00000000-0000-0000-0000-000000000000 --body \"Design: '{\n       \\\"productionCodePath\\\": \\\"cli-tool feature list\\\",\n       \\\"validation_checklist\\\": [\n         \\\"Type checking passes\\\",\n         \\\"Tests pass\\\",\n         \\\"Production code verified via code inspection\\\",\n         \\\"Tests import production CLI package\\\",\n         \\\"No TODO placeholders in CLI action\\\",\n         \\\"Service wired with real dependencies\\\"\n       ],\n       \\\"acceptance_criteria\\\": [{\n         \\\"given\\\": \\\"user runs cli-tool feature list\\\",\n         \\\"when\\\": \\\"command executes\\\",\n         \\\"then\\\": \\\"shows list from actual service\\\",\n         \\\"should_not\\\": \\\"have dual-export (test vs production paths)\\\"\n       }],\n       \\\"ratified_plan\\\": \\\"${RATIFIED_PLAN_ID_URI}\\\"\n     }'\"\n\n   \"${EPOCH_REC}\" block \"${IMPL_PLAN_ID_URI}\" --by \"${SLICE_1_ID_URI}\"\n   ```\n\n7. **Update IMPL_PLAN with vertical slice breakdown + integration points:** First create each remaining slice using the Step 6 pattern and bind SLICE_2_ID_URI, SLICE_3_ID_URI and SLICE_4_ID_URI from their respective create outputs.\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   ## Vertical Slice Decomposition\n\n   Each worker owns ONE production code path (full vertical slice from CLI → service → types).\n\n   ### Shared Infrastructure (Layer 0 - optional)\n   - Common types: SortOrder, OutputFormat, ErrorCode enums\n   - Implemented first, parallel\n\n   ### Vertical Slices (parallel, after Layer 0)\n\n   **default command: \"cli-tool feature\"**\n   - Worker: A\n   - Production path: \\`.\u002Fbin\u002Fcli-tool feature\\`\n   - Owns: default action, recent items logic\n    - Task: \"${SLICE_1_ID_URI}\"\n\n   **list command: \"cli-tool feature list\"**\n   - Worker: B\n   - Production path: \\`.\u002Fbin\u002Fcli-tool feature list\\`\n   - Owns: ListOptions types, list tests, listItems() method, list CLI wiring\n    - Task: \"${SLICE_2_ID_URI}\"\n\n   **detail command: \"cli-tool feature detail\"**\n   - Worker: C\n    - Production path: \\`.\u002Fbin\u002Fcli-tool feature detail FEATURE_ID\\`\n   - Owns: DetailView types, detail tests, getItemDetail() method, detail CLI wiring\n    - Task: ${SLICE_3_ID_URI}\n\n   **search command: \"cli-tool feature search\"**\n   - Worker: D\n   - Production path: \\`.\u002Fbin\u002Fcli-tool feature search\\`\n   - Owns: SearchQuery types, search tests, searchItems() method, search CLI wiring\n    - Task: ${SLICE_4_ID_URI}\n\n   ## Horizontal Layer Integration Points\n\n   Where slices must inter-op. Merge sooner, not later — divergence grows with delay.\n\n   | ID | Contract | Owner (exports) | Consumer(s) (imports) | Merge Timing |\n   |----|----------|-----------------|-----------------------|--------------|\n   | IP-1 | FeatureError enum | the default command | the list command, the detail command, the search command | L1 (types) |\n   | IP-2 | BaseService interface | the default command | the list command, the detail command | L1 (types) |\n\n   ## Execution Order\n\n   1. Layer 0 (if needed): Shared infrastructure (parallel)\n   2. the default command through the search command: Each worker implements their vertical slice (parallel)\n      - Within each slice: Types (L1) → Tests (L2) → Impl+Wiring (L3)\n   3. Integration points merge at documented timing (L1 contracts first, L3 wiring last)\n\n   ## Validation\n\n   All production code paths verified via code inspection:\n   - .\u002Fbin\u002Fcli-tool feature\n   - .\u002Fbin\u002Fcli-tool feature list\n   - .\u002Fbin\u002Fcli-tool feature detail \"${SLICE_1_ID_URI}\"\n   - .\u002Fbin\u002Fcli-tool feature search\n   - All integration points verified: contracts match between owner and consumers\n   EOF\n   )\"\n   ```\n\n## Vertical Slice Task Structure\n\n```json\n{\n  \"slice\": \"feature-list\",\n  \"productionCodePath\": \"cli-tool feature list\",\n  \"taskId\": \"${TASK_A_URI}\",\n  \"workerOwns\": {\n    \"endPoint\": \"listCmd (cobra.Command) RunE handler\",\n    \"types\": [\"ListOptions\", \"ListEntry\"],\n    \"tests\": [\"cmd\u002Ffeature\u002Flist_test.go\"],\n    \"implementation\": [\n      \"(*FeatureService).ListItems() method\",\n      \"listCmd wired with feature.NewService(realDeps)\"\n    ]\n  },\n  \"planningApproach\": \"Backwards from production code path\",\n  \"validation_checklist\": [\n    \"Type checking passes\",\n    \"Tests pass\",\n    \"Production code works: .\u002Fbin\u002Faura sessions list\",\n    \"Tests import production CLI (not test-only export)\",\n    \"No TODO placeholders\",\n    \"Service wired with real dependencies\"\n  ],\n  \"acceptance_criteria\": [{\n    \"given\": \"user runs aura sessions list\",\n    \"when\": \"command executes\",\n    \"then\": \"shows session list from actual service\",\n    \"should_not\": \"have dual-export or TODO placeholders\"\n  }],\n  \"ratified_plan\": \"${RATIFIED_PLAN_ID_URI}\",\n  \"urd\": \"\u003Curd-id>\"\n}\n```\n\n## Layer Cake Within Each Vertical Slice\n\nEach worker implements their slice in layers (TDD approach):\n\n```\nWorker A's Slice: \"aura sessions list\"\n  Layer 1: Types (ListOptions, SessionListEntry only)\n  Layer 2: Tests (import sessions package, test list action)\n           → Tests will FAIL (expected - no impl yet)\n  Layer 3: Implementation + Wiring\n           - (*SessionsService).ListSessions() method\n           - listCmd wired with sessions.NewService(deps)\n           - Wire action to call service\n           → Tests should now PASS\n```\n\n**Important:** Layer 2 tests failing is expected. Worker knows tests define the contract, implementation comes in Layer 3.\n\n## Red Flags vs Green Flags\n\n**Red flags (horizontal layer decomposition):**\n- Tasks organized by layer: \"Layer 1 all types\", \"Layer 2 all tests\"\n- Worker assigned \"all types\" or \"all tests\" instead of feature slice\n- No production code path specified per task\n- Tasks describe \"file to modify\" not \"production code path to deliver\"\n\n**Green flags (vertical slice decomposition):**\n- Each task specifies production code path (e.g., \"aura sessions list\")\n- Worker owns full vertical (types → tests → impl → wiring)\n- Task description says \"plan backwards from end point\"\n- Validation checklist includes \"production code works: .\u002Fbin\u002Faura \u003Ccommand>\"\n- Workers can execute independently (parallel slices)\n\n## Shared Infrastructure (Layer 0)\n\nIf multiple slices share common infrastructure:\n\n```\nLayer 0 Tasks (parallel, implemented first):\n- Common enums: SortOrder, OutputFormat, SessionsErrorCode\n- Common types: ParseHealth (used by all slices)\n- Shared utilities: isSidechainSession(), getGitBranch()\n```\n\nThen vertical slices proceed in parallel, depending on Layer 0.\n\n**Key insight:** Shared infrastructure is the exception, not the rule. Most types\u002Flogic belong to specific slices.\n\n## Follow-up Implementation Plan (FOLLOWUP_IMPL_PLAN)\n\nWhen planning for a follow-up epic (after receiving h1 from architect post-FOLLOWUP_PROPOSAL ratification), the same vertical slice decomposition applies:\n\n```bash\n# Create FOLLOWUP_IMPL_PLAN\nFOLLOWUP_IMPL_PLAN_ID_URI=$(\"${EPOCH_REC}\" create --kind epic --title \"FOLLOWUP_IMPL_PLAN: \u003Cfollow-up feature>\" --phase impl_plan --priority 2 \\\n  --body=\"---\nreferences:\n  followup_epic: \"${FOLLOWUP_EPIC_ID_URI}\"\n  original_request: \"${REQUEST_ID_URI}\"\n  original_urd: \"${URD_ID_URI}\"\n  followup_urd: \"${FOLLOWUP_URD_ID_URI}\"\n  followup_proposal: \"${FOLLOWUP_PROPOSAL_ID_URI}\"\n---\nVertical slice decomposition for follow-up epic.\")\n\n# Create the follow-up slice with DEFER'd-item leaf tasks\nFOLLOWUP_SLICE_ID_URI=$(\"${EPOCH_REC}\" create --kind task --title \"Follow-up: \u003Cdescription>\" --phase worker_slices \\\n  --body=\"---\nreferences:\n  followup_impl_plan: \"${FOLLOWUP_IMPL_PLAN_ID_URI}\"\n  followup_urd: \"${FOLLOWUP_URD_ID_URI}\"\n---\n## DEFER'd-Item Leaf Tasks\n| Leaf Task ID | Source UAT | DEFER'd Item | Description |\n|---|---|---|---|\n| \"${LEAF_ID_1_URI}\" | \"${UAT_ID_URI}\" | \"${DEFERRED_ITEM_ID_URI}\" | \u003Cdescription> |\n| \"${LEAF_ID_2_URI}\" | \"${UAT_ID_URI}\" | \"${DEFERRED_ITEM_ID_URI}\" | \u003Cdescription> |\n\n## Specification\n\u003Cdetailed spec>\n\n## Validation Checklist\n- [ ] All DEFER'd-item leaf tasks resolved\n- [ ] Tests pass\n- [ ] Production code path verified\")\n\n# Wire dual-parent: leaf blocks BOTH the DEFER'd-items tracking group AND the follow-up slice\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_1_URI}\"\n\"${EPOCH_REC}\" block \"${FOLLOWUP_SLICE_ID_URI}\" --by \"${LEAF_TASK_ID_2_URI}\"\n```\n\u003C!-- END GENERATED FROM pasture schema -->\n",{"name":5,"description":7},"main","5813de22110ddc609b465a982b4811646ff72d18","internal\u002Ftarget\u002Fclaudecode\u002Fassets\u002Fpasture-skills\u002Fskills\u002Fsupervisor-plan-tasks",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":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add dayvidpham\u002Fpasture --skill supervisor-plan-tasks",{"tool":45,"command":46},"bunx","bunx skills add dayvidpham\u002Fpasture --skill supervisor-plan-tasks",{"tool":48,"command":49},"pnpm","pnpm dlx skills add dayvidpham\u002Fpasture --skill supervisor-plan-tasks","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Finternal\u002Ftarget\u002Fclaudecode\u002Fassets\u002Fpasture-skills\u002Fskills\u002Fsupervisor-plan-tasks\u002FSKILL.md",true,[],[54,62,77,87,99,109],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":26},"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",[],[56,61],"fixture skill",{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":26},"01M6DAP48A4K365N83NBG0GFVC","worker","Vertical slice implementer (full production code path)","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker\u002FSKILL.md",[],[64,69,70,71,72,73,74,75,25,76],"implementer","code","implement","Production","full","complete","vertical slice","path",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":26},"01M6DAP18QJM7P7N31TYGNJBCP","worker-implement","Implement assigned vertical slice following TDD layers","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-implement\u002FSKILL.md",[],[84,64,71,75,85,25,86],"worker implement","layers","tdd",{"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":26},"01M6DANYHC7P63RFEN26F70MC2","worker-complete","Signal slice completion after quality gates pass","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-complete\u002FSKILL.md",[],[64,94,74,95,25,96,97,98],"worker complete","signal","gates","quality","quality gates",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":26},"01M6DANWZ31TRP4NN4T1BFYKSR","worker-blocked","Report a blocker to supervisor via Pasture","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fworker-blocked\u002FSKILL.md",[],[106,64,107,108,21],"worker blocked","via","report",{"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":120,"publishedAt":26},"01M6DANSVDBXBFH93B6EX3H2QK","user-uat","User Acceptance Testing with demonstrative examples","https:\u002F\u002Fgithub.com\u002Fdayvidpham\u002Fpasture\u002Fblob\u002Fmain\u002Fskills\u002Fuser-uat\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[121,122,123,124,125,126,127,128,129],"uat","user uat","user","acceptance testing","with","user acceptance testing","examples","acceptance","testing"]