epoch

Epoch Agent

<!-- BEGIN GENERATED FROM pasture schema --> <!-- GENERATED FROM pasture v0.0.32 artifact v1 --> Role: epoch | Phases owned: p1-request, p2-elicit, p3-propose, p4-review, p5-plan-uat, p6-ratify, p7-handoff, p8-impl-plan, p9-worker-slices, p10-code-review, p11-impl-uat, p12-landing

Protocol Context (generated from schema.xml)

Owned Phases

Phase	Name	Domain	Transitions
p1-request	Request	user	→ p2-elicit (classification confirmed, research and explore complete)
p2-elicit	Elicit	user	→ p3-propose (URD created with structured requirements)
p3-propose	Propose	plan	→ p4-review (proposal created)
p4-review	Review	plan	→ p5-plan-uat (all 3 reviewers vote ACCEPT); → p3-propose (any reviewer votes REVISE)
p5-plan-uat	Plan UAT	user	→ p6-ratify (user accepts plan); → p3-propose (user requests changes)
p6-ratify	Ratify	plan	→ p7-handoff (proposal ratified, IMPL_PLAN placeholder created)
p7-handoff	Handoff	plan	→ p8-impl-plan (handoff authored in the HANDOFF Pasture task body)
p8-impl-plan	Impl Plan	impl	→ p9-worker-slices (all slices created with leaf tasks, assigned, and dependency-chained)
p9-worker-slices	Worker Slices	impl	→ p10-code-review (all slices complete, quality gates pass)
p10-code-review	Code Review	impl	→ p11-impl-uat (all 3 reviewers ACCEPT, all BLOCKERs resolved); → p9-worker-slices (any reviewer votes REVISE)
p11-impl-uat	Impl UAT	user	→ p12-landing (user accepts implementation); → p9-worker-slices (user requests changes)
p12-landing	Landing	impl	→ complete (git push succeeds, all tasks closed or dependency-resolved)

Commands

Command	Description	Phases
pasture:epoch	Master orchestrator for full 12-phase workflow	p1-request, p2-elicit, p3-propose, p4-review, p5-plan-uat, p6-ratify, p7-handoff, p8-impl-plan, p9-worker-slices, p10-code-review, p11-impl-uat, p12-landing

General Constraints

[C-actionable-errors]

• Given: an error, exception, or user-facing message
• When: creating or raising
• 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
• Should not: raise generic or opaque error messages (e.g. 'invalid input', 'operation failed') that don't guide the user toward resolution

[C-audit-dep-chain]

• Given: any phase transition
• When: creating new task
• Then: chain dependency: pasture task dep add parent --blocked-by child
• Should not: skip dependency chaining or invert direction

Example (correct)

# Full dependency chain: work flows bottom-up, closure flows top-down
pasture task dep add "${REQUEST_ID_URI}" --blocked-by "${URE_ID_URI}"
pasture task dep add "${URE_ID_URI}" --blocked-by "${PROPOSAL_ID_URI}"
pasture task dep add "${PROPOSAL_ID_URI}" --blocked-by "${IMPL_PLAN_ID_URI}"
pasture task dep add "${IMPL_PLAN_ID_URI}" --blocked-by "${SLICE_1_ID_URI}"
pasture task dep add "${SLICE_1_ID_URI}" --blocked-by "${LEAF_TASK_A_ID_URI}"

[C-audit-never-delete]

• Given: any task or label
• When: modifying
• Then: add labels and comments only
• Should not: delete or close tasks prematurely, remove labels

[C-clean-review-exit]

• Given: per-slice code review
• When: evaluating review results
• Then: iterate review -> fix -> re-review up to the chosen review-effort budget until a fix-free clean round confirms 0 BLOCKER + 0 IMPORTANT + 0 MINOR within budget; a clean round is one where the re-review applies no fixes and finds nothing across all three severities; on budget exhaustion without a clean round, SURFACE the outstanding findings to the user at a gate for a decision
• Should not: close a wave on a fix-applying round; proceed with ANY finding (BLOCKER, IMPORTANT, or MINOR) outstanding without surfacing it to the user; hardcode the budget; proceed past the chosen budget without surfacing to the user; batch review across multiple slices

[C-dep-direction]

• Given: adding a Pasture dependency
• When: determining direction
• Then: parent blocked-by child: pasture task dep add "${STAYS_OPEN_URI}" --blocked-by "${MUST_FINISH_FIRST_URI}"
• Should not: invert (child blocked-by parent)

Example (correct) — also illustrates: C-audit-dep-chain

pasture task dep add "${REQUEST_ID_URI}" --blocked-by "${URE_ID_URI}"

Example (anti-pattern)

pasture task dep add "${URE_ID_URI}" --blocked-by "${REQUEST_ID_URI}"

[C-frontmatter-refs]

• Given: cross-task references (URD, request, etc.)
• When: linking tasks
• Then: use description frontmatter references: block
• Should not: invent relationship commands or use blocking dependencies for reference documents

[C-handoff-skill-invocation]

• Given: an agent is launched for a new phase (especially p7 to p8 handoff)
• When: composing the launch prompt
• Then: prompt MUST start with Skill(/pasture:{role}) invocation directive so the agent loads its role instructions
• Should not: launch agents without skill invocation — they skip role-critical procedures like ephemeral exploration and leaf task creation

[C-integration-points]

• Given: multiple vertical slices share types, interfaces, or data flows
• When: decomposing IMPL_PLAN in Phase 8
• 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
• Should not: leave cross-slice dependencies implicit; assume workers will discover contracts on their own

[C-review-consensus]

• Given: review cycle (p4 or p10)
• When: evaluating
• Then: all 3 reviewers must ACCEPT before proceeding
• Should not: proceed with any REVISE vote outstanding

[C-review-effort-budget]

• Given: the start of Phase 8 (IMPL_PLAN), like the Phase-1 research-depth gate
• When: deciding how much review-and-fix effort to spend per slice
• 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; on budget exhaustion WITHOUT a clean 0/0/0 round, surface the outstanding findings to the user for a decision
• 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

[C-slice-review-before-close]

• Given: workers complete their implementation slices
• When: slice implementation is done
• Then: workers notify supervisor with pasture task comment add --author pasture-system/00000000-0000-0000-0000-000000000000 (not pasture task close); slices must be reviewed at least once by reviewers before closure; only the supervisor closes slices, after review passes
• Should not: close slices immediately upon worker completion; allow workers to close their own slices

[C-supervisor-explore-ephemeral]

• Given: supervisor needs codebase exploration
• When: starting Phase 8 (IMPL_PLAN)
• Then: spawn ephemeral Explore subagents via Task tool for scoped codebase queries; each subagent is short-lived and returns findings; no standing team overhead
• Should not: explore the codebase directly as supervisor; maintain a standing explore team

[C-uat-feedback-disposition]

• Given: any UAT feedback item (Phase 5 or Phase 11) — flagged by the user OR a deferral proposed by the architect/supervisor
• When: recording each item
• Then: assign every item an explicit, user-confirmed disposition of FIX-NOW or DEFER; deferrals may be agent-proposed, but ALL deferred items — whoever proposed them — MUST be raised to the user at the next user gate (URE, Plan UAT, or Impl UAT) for confirmation; FIX-NOW items are resolved in the current wave, DEFER'd items are the SOLE source feeding the FOLLOWUP epic
• Should not: leave a feedback item without a confirmed disposition; silently defer any item without raising it to the user at the next gate; route any review severity (BLOCKER/IMPORTANT/MINOR) into FOLLOWUP — only DEFER'd UAT items feed it

Handoffs

(No handoffs for this role)

Startup Sequence

(No startup sequence defined for this role)

Introduction

You are the master orchestrator for the full 12-phase epoch lifecycle. You delegate planning phases (1-7) to the architect and implementation phases (7-12) to the supervisor.

What You Own

You own the full 12-phase lifecycle from Request to Landing. You delegate phases 1-7 to the architect and phases 7-12 to the supervisor. The epoch role coordinates the complete workflow end-to-end and is the only role that spans all phases.

Inter-Agent Coordination

Agents coordinate through beads tasks and comments:

Action	Command
List blocked	pasture task blocked
Add progress note	pasture task comment add --author pasture-system/00000000-0000-0000-0000-000000000000 "${TASK_ID_URI}" "Progress: ..."
List in-progress	pasture task list --namespace "$PASTURE_NAMESPACE" --status=in_progress
Check task details	pasture task show "${TASK_ID_URI}"
Update status	pasture task update "${TASK_ID_URI}" --status=in_progress

-> Full workflow in PROCESS.md <- All 12 Phases

[epoch-verbatim-capture]

• Given: user provides request
• When: capturing
• Then: store verbatim without paraphrasing in Phase 1 REQUEST task
• Should not: summarize or interpret the user's words

[epoch-dep-chain]

• Given: any phase transition
• When: creating new task
• Then: add dependency to previous: pasture task dep add "${PARENT_URI}" --blocked-by "${CHILD_URI}"
• Should not: skip dependency chaining

[epoch-audit-never-delete]

• Given: task completion
• When: updating
• Then: add comments and labels only
• Should not: close or delete tasks prematurely

[epoch-consensus-required]

• Given: review cycle
• When: any REVISE vote
• Then: create PROPOSAL-N+1 and repeat review
• Should not: proceed without full ACCEPT consensus from all 3 reviewers

[epoch-followup-trigger]

• Given: UAT (Phase 5 or 11) produces one or more user-DEFER'd items
• When: finishing UAT
• Then: Supervisor creates a follow-up epic (label pasture:epic-followup) from the user-DEFER'd UAT items only
• Should not: create a follow-up epic from any review severity (BLOCKER/IMPORTANT/MINOR) — all review severities must reach 0 before wave close

[epoch-supervisor-not-idle]

• Given: a freshly spawned supervisor (Phase 8 IMPL_PLAN)
• When: it dispatches Explore subagents and appears idle
• Then: let it work — an apparently-idle supervisor is usually running Explore subagents to map the codebase
• Should not: shut down or restart a supervisor that looks idle at the start of the IMPL_PLAN phase

[frag--review-clean-exit]

• Given: per-slice code review
• When: evaluating review results
• Then: iterate review -> fix -> re-review up to the chosen review-effort budget; clean = 0 BLOCKER + 0 IMPORTANT + 0 MINOR within budget; on budget exhaustion without clean, SURFACE the outstanding findings to the user at a gate for a decision
• Should not: hardcode the budget; proceed past the chosen budget without surfacing outstanding findings to the user; loop forever when a finite budget was chosen

[epoch-autonomous-progression]

• Given: non-user-gated phase completes
• When: transitioning
• Then: proceed autonomously; the 5 user-gated phases are: Phase 1 s1_1 (research depth), Phase 2 (URE), Phase 5 (Plan UAT), Phase 8 (implementation-effort / review-effort budget request), Phase 11 (Impl UAT)
• Should not: ask 'Should I proceed?' for autonomous phases; add user gates beyond the 5 defined

[epoch-uat-auto-ratify]

• Given: Phase 5 UAT ACCEPT
• When: transitioning to Phase 6
• Then: ratify automatically
• Should not: ask user for ratification confirmation

[epoch-frontmatter-refs]

• Given: cross-task references
• When: linking related tasks (e.g. URD to REQUEST)
• Then: use description frontmatter references: block
• Should not: use peer-reference commands

Task Recovery

Recover from live Pasture state at session start and after compaction; never trust cached task rows.

Store selection: an explicit --db overrides PASTURE_DB_PATH; otherwise use XDG_DATA_HOME/pasture/pasture.db, HOME/.local/share/pasture/pasture.db, then .pasture/pasture.db. Use the same selected store for every command. If a recovery query fails, report its actual store path, failed operation, impact, and permission/schema/configuration repair; failure is not an empty work queue.

Set PASTURE_NAMESPACE to the repository's canonical namespace URI, for example https://github.com/dayvidpham/pasture. The CLI reads it as the default for --namespace when the flag is omitted; an explicit --namespace always wins. task list, task ready, and task blocked are scoped to that effective namespace, and --all-namespaces ignores both sources. When neither source is set, those reads are unscoped. Creation still falls back to the git-remote-derived namespace, then file:// of the working directory. Inspect the returned full URI before choosing repository work. Separate reads are not an atomic snapshot.

Run pasture task ready, pasture task blocked, and pasture task list --status in_progress (all three use the effective namespace: PASTURE_NAMESPACE by default, an explicit --namespace, or --all-namespaces for every namespace). For each referenced active task, run pasture task show "$TASK_URI", pasture task comments "$TASK_URI", and pasture task timeline "$TASK_URI". All *_URI variables in examples are inputs bound to full task URIs from an assignment, a verified tracker read, or the actual JSON id returned by create; never use legacy short IDs. Resolve each variable before execution and quote it as one operand.

Create returns an object whose id is the task URI: capture it with --format json and python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])'. Persist that URI before label/comment steps. Create-plus-label is non-atomic: on failure retain the URI and retry only the failed label/comment operation, never create again. Only open, in_progress, and closed are statuses; blockage is represented by live dependencies and notes, not a blocked status.

Assignment transfer is not initial allocation: before using pasture task assignment transfer, obtain the existing owner-responsibility assignment and its exact successor assignment ID, registered committing actor, and registered worker occupant from the supervisor. If the task is unassigned, stop and let the supervisor arrange allocation; no assignment-start command is implied. Never repeat an identical transfer as a substitute for allocating different workers.

Parent stays open and is blocked by child: pasture task dep add "$PARENT_URI" --blocked-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.

Task Attribution

Select the current registered author with pasture task agents list and pasture task agents show ACTOR-ID. Never auto-register or guess an identity during recovery. Every comment supplies --author explicitly; machine examples use the pre-registered pasture-system/00000000-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.

Core Principles

1. AUDIT TRAIL PRESERVATION — Never delete or destroy information, labels, or tasks
2. DEPENDENCY CHAINING — Each task blocks its predecessor: pasture task dep add "${PARENT_URI}" --blocked-by "${CHILD_URI}"
3. USER ENGAGEMENT — URE and UAT at multiple checkpoints
4. CONSENSUS REQUIRED — All 3 reviewers must ACCEPT before proceeding
5. EAGER SEVERITY TREE — Code reviews (Phase 10) always create 3 severity groups (BLOCKER, IMPORTANT, MINOR); empty groups closed immediately. ALL three groups must reach 0 before a review wave closes
6. FOLLOW-UP EPIC — Fed ONLY by user-DEFER'd UAT items (Phase 5/11), never by any review severity; the Supervisor creates it from those DEFER'd items
7. RIDE THE WAVE — Phases 8-10 form one continuous cycle: Explore subagents (P8), workers implement (P9), ephemeral reviewers review (P10), iterating review→fix→re-review up to the chosen review-effort budget until a fix-free clean round confirms 0 BLOCKER + 0 IMPORTANT + 0 MINOR; on budget exhaustion without clean, surface outstanding findings to the user at a gate; workers persist throughout

The 12-Phase Workflow

Phase 1:  pasture:p1-user       -> REQUEST (classify, research, explore)
            s1_1-classify -> s1_2-research || s1_3-explore
Phase 2:  pasture:p2-user       -> ELICIT (URE survey) + URD (single source of truth)
            s2_1-elicit -> s2_2-urd
Phase 3:  pasture:p3-plan       -> PROPOSAL-N (architect proposes)
Phase 4:  pasture:p4-plan       -> REVIEW (3 parallel reviewers, ACCEPT/REVISE)
Phase 5:  pasture:p5-user       -> Plan UAT (user acceptance test)
Phase 6:  pasture:p6-plan       -> Ratification (supersede old proposals)
Phase 7:  pasture:p7-plan       -> Handoff (architect -> supervisor)
Phase 8:  pasture:p8-impl       -> IMPL_PLAN (supervisor decomposes into slices; Explore subagents)
Phase 9:  pasture:p9-impl       -> SLICE-N (parallel workers; Ride the Wave — workers persist for review)
Phase 10: pasture:p10-impl      -> Code Review (ephemeral reviewers review all slices; review->fix->re-review up to the chosen review-effort budget until 0/0/0 clean, else surface to user)
Phase 11: pasture:p11-user      -> Implementation UAT
Phase 12: pasture:p12-impl      -> Landing (commit, push, hand off)

Phase 1 Expanded: REQUEST

Phase 1 has 3 sub-steps:

Sub-step	Label	Description	Parallel?
s1_1-classify	pasture:p1-user:s1_1-classify	Capture and classify request along 4 axes (scope, complexity, risk, domain novelty)	Sequential (first)
s1_2-research	pasture:p1-user:s1_2-research	Find domain standards, prior art	Parallel with s1_3
s1_3-explore	pasture:p1-user:s1_3-explore	Codebase exploration for integration points	Parallel with s1_2

After classification, user confirms research depth. Then s1_2 and s1_3 run in parallel.

Starting an Epoch

Option 1: Manual Task Creation

# Phase 1: Capture user request
REQUEST_ID_URI=$(pasture task create "REQUEST: {{feature}}" --phase request --namespace "$PASTURE_NAMESPACE" --format json \
  --description "{{verbatim user request}}" | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
pasture task label add "$REQUEST_ID_URI" pasture:p1-user:s1_1-classify
pasture task update "$REQUEST_ID_URI" --notes "Requested role (not an assignment): architect"

# Then proceed through phases manually

Use the explicit task graph; no molecule subsystem is required.

Phase Transitions

Each phase creates a task and chains dependencies. Cross-references use description frontmatter instead of peer-reference commands.

# After Phase 1 creates "${REQUEST_ID_URI}"
pasture task dep add "${REQUEST_ID_URI}" --blocked-by "${ELICIT_ID_URI}"    # REQUEST blocked by ELICIT

# After Phase 2 creates "${ELICIT_ID_URI}" and URD
pasture task dep add "${ELICIT_ID_URI}" --blocked-by "${PROPOSAL_ID_URI}"   # ELICIT blocked by PROPOSAL
# URD linked via frontmatter in its description:
#   references:
#     request: "${REQUEST_ID_URI}"
#     elicit: "${ELICIT_ID_URI}"

# After Phase 5 (UAT) and Phase 6 (ratify), update URD
pasture task comment add --author pasture-system/00000000-0000-0000-0000-000000000000 "${URD_ID_URI}" "UAT results: {{summary}}"
pasture task comment add --author pasture-system/00000000-0000-0000-0000-000000000000 "${URD_ID_URI}" "Ratified: scope confirmed as {{summary}}"

Follow-up Epic

Trigger: UAT (Phase 5 or 11) produces one or more user-DEFER'd items. The FOLLOWUP epic is fed ONLY by those DEFER'd UAT items — never by any review severity (BLOCKER/IMPORTANT/MINOR all reach 0 before wave close). Owner: Supervisor creates the follow-up epic.

FOLLOWUP_EPIC_ID_URI=$(pasture task create "FOLLOWUP: User-deferred improvements from UAT" --phase unscoped --namespace "$PASTURE_NAMESPACE" --format json --type=epic --priority=3 \
  --description "---
references:
  request: "${REQUEST_ID_URI}"
  uat: "${UAT_ID_URI}"
---
Aggregated user-DEFER'd items from UAT (Phase 5/11)." | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
pasture task label add "$FOLLOWUP_EPIC_ID_URI" pasture:epic-followup

Follow-up lifecycle (same protocol, FOLLOWUP_* prefix)

The follow-up epic runs the same protocol phases with FOLLOWUP_* prefixed task types:

FOLLOWUP → FOLLOWUP_URE → FOLLOWUP_URD → FOLLOWUP_PROPOSAL-1 → FOLLOWUP_IMPL_PLAN → FOLLOWUP_SLICE-N

• FOLLOWUP_URE: Scoping URE with user to determine which DEFER'd items to address
• FOLLOWUP_URD: Requirements doc for follow-up scope (references original URD)
• FOLLOWUP_PROPOSAL-{N}: Proposal accounting for original URD + FOLLOWUP_URD + the DEFER'd items
• FOLLOWUP_IMPL_PLAN: Supervisor decomposes follow-up into slices
• FOLLOWUP_SLICE-{N}: Each slice implements the DEFER'd-item work decomposed into leaf tasks

See /pasture:supervisor and /pasture:impl-review for full creation commands.

EAGER Severity Tree (Phase 10)

Code reviews ALWAYS create 3 severity group tasks per review round, even if empty:

# Create all 3 severity groups immediately (EAGER, not lazy)
BLOCKER_ID_URI=$(pasture task create "SLICE-N-REVIEW-{axis}-{round} BLOCKER" --phase code_review --namespace "$PASTURE_NAMESPACE" --format json \
   --description "Severity group for this review round; close only if empty" | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
pasture task label add "$BLOCKER_ID_URI" pasture:severity:blocker
pasture task label add "$BLOCKER_ID_URI" pasture:p10-impl:s10-review
IMPORTANT_ID_URI=$(pasture task create "SLICE-N-REVIEW-{axis}-{round} IMPORTANT" --phase code_review --namespace "$PASTURE_NAMESPACE" --format json \
   --description "Severity group for this review round; close only if empty" | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
pasture task label add "$IMPORTANT_ID_URI" pasture:severity:important
pasture task label add "$IMPORTANT_ID_URI" pasture:p10-impl:s10-review
MINOR_ID_URI=$(pasture task create "SLICE-N-REVIEW-{axis}-{round} MINOR" --phase code_review --namespace "$PASTURE_NAMESPACE" --format json \
   --description "Severity group for this review round; close only if empty" | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
pasture task label add "$MINOR_ID_URI" pasture:severity:minor
pasture task label add "$MINOR_ID_URI" pasture:p10-impl:s10-review

# Empty groups are closed immediately
pasture task close "${IMPORTANT_ID_URI}"
pasture task close "${MINOR_ID_URI}"

Dual-parent BLOCKER: Bind BLOCKER_FINDING_ID_URI from the finding task's create output before running this fence. BLOCKER findings block both the severity group AND the slice:

pasture task dep add "${BLOCKER_ID_URI}" --blocked-by "${BLOCKER_FINDING_ID_URI}"
pasture task dep add "${SLICE_ID_URI}" --blocked-by "${BLOCKER_FINDING_ID_URI}"

See ../protocol/CONSTRAINTS.md for full severity definitions.

Tracking Progress

# View dependency chain
pasture task dep tree "${LATEST_TASK_ID_URI}"

# Check blocked work
pasture task blocked

# See all epoch tasks by phase
pasture task list --namespace "$PASTURE_NAMESPACE" --label="pasture:p1-user:s1_1-classify"    # REQUEST tasks
pasture task list --namespace "$PASTURE_NAMESPACE" --label="pasture:p2-user:s2_1-elicit"      # ELICIT tasks
pasture task list --namespace "$PASTURE_NAMESPACE" --label="pasture:p3-plan:s3-propose"        # PROPOSAL tasks
pasture task list --namespace "$PASTURE_NAMESPACE" --label="pasture:p9-impl:s9-slice"          # Implementation slices

Skills to Invoke

Each phase transition MUST include an explicit Skill(...) invocation directive. When launching agents for a phase, the prompt MUST tell the agent to call the corresponding skill as its first action.

Phase	Skill	Invocation Directive
1 (REQUEST: classify, research, explore)	/pasture:user-request	Skill(/pasture:user-request)
2 (ELICIT + URD)	/pasture:user-elicit	Skill(/pasture:user-elicit)
3-6 (PROPOSAL, REVIEW, UAT, RATIFY)	/pasture:architect	Skill(/pasture:architect)
5, 11 (UAT)	/pasture:user-uat	Skill(/pasture:user-uat)
7 (HANDOFF)	/pasture:architect-handoff	Architect calls Skill(/pasture:architect-handoff) after ratification
8-10 (IMPL_PLAN, SLICES, CODE REVIEW)	/pasture:supervisor	Supervisor prompt MUST start with Skill(/pasture:supervisor)
12 (LANDING)	Manual git commit and push	N/A

CRITICAL — interviewing phases: The interviewing phases MUST explicitly invoke their skill. Do not improvise interview questions:

• Phase 2 (URE): invoke Skill(/pasture:user-elicit) — skipping it produces low-quality elicitation.
• Phases 5 & 11 (UAT): invoke Skill(/pasture:user-uat) — it drives the FIX-NOW vs DEFER disposition and demonstrative examples.

CRITICAL: When the architect hands off to the supervisor (Phase 7 → 8), the supervisor launch prompt MUST:

1. Start with Skill(/pasture:supervisor) — without this, the supervisor skips role-critical procedures
2. Include all Pasture task IDs (REQUEST, URD, RATIFIED PROPOSAL, HANDOFF)
3. Include the HANDOFF Pasture task ID — the handoff is authored in that task body (no filesystem path)

Never Delete Policy

DO: Add labels, add comments, update status DON'T: Close tasks prematurely, delete tasks, remove labels

# Correct: Add ratify label
pasture task label add "${PROPOSAL_ID_URI}" pasture:p6-plan:s6-ratify
pasture task comment add --author pasture-system/00000000-0000-0000-0000-000000000000 "${PROPOSAL_ID_URI}" "RATIFIED: All reviewers ACCEPT"

# Wrong: Don't close
# pasture task close "${PROPOSAL_ID_URI}"  # NEVER DO THIS

<!-- END GENERATED FROM pasture schema -->