| name | architect-propose-plan |
| description | Create PROPOSAL-N task with full technical plan |
Architect: Propose Plan
Command: pasture:architect:propose-plan — Create PROPOSAL-N task with full technical plan
-> Full workflow in PROCESS.md <- Phase 3
[arch-propose-bdd-format]
- Given: feature request
- When: proposing
- Then: use BDD Given/When/Then format with acceptance criteria
- Should not: write vague requirements
[arch-propose-checklist-required]
- Given: plan
- When: creating task
- Then: include validation_checklist and tradeoffs in design field
- Should not: leave checklist empty
[arch-propose-revision-history]
- Given: existing plan
- When: revising
- Then: create PROPOSAL-N+1 task and mark old as
pasture:superseded
- Should not: lose history
When to Use
Starting new feature design; creating formal plan for review.
PROPOSAL-N Naming
Proposals are numbered incrementally: PROPOSAL-1, PROPOSAL-2, etc. Each revision increments N. Old proposals are marked pasture:superseded with a comment explaining why.
Beads Task Creation
bd create --type=feature \
--labels="pasture:p3-plan:s3-propose" \
--title="PROPOSAL-1: <feature name>" \
--description="$(cat <<'EOF'
---
references:
request: <request-id>
urd: <urd-id>
---
## Problem Space
**Axes of the problem:**
- Parallelism: ...
- Distribution: ...
**Has-a / Is-a:**
- X HAS-A Y
- Z IS-A W
## Engineering Tradeoffs
| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| A | ... | ... | Selected |
| B | ... | ... | Rejected |
## MVP Milestone
<scope with tradeoff rationale>
## Public Interfaces
\`\`\`go
type Example interface { /* ... */ }
\`\`\`
## Types & Enums
\`\`\`go
type ExampleType int
const (
ExampleTypeA ExampleType = iota
ExampleTypeB
)
\`\`\`
## Validation Checklist
### Phase 1
- [ ] Item 1
- [ ] Item 2
### Phase 2
- [ ] Item 3
## BDD Acceptance Criteria
**Given** precondition
**When** action
**Then** outcome
**Should Not** negative case
## Files Affected
- pkg/path/file1.go (create)
- pkg/path/file2.go (modify)
EOF
)" \
--design='{"validation_checklist":["Item 1","Item 2","Item 3"],"tradeoffs":[{"decision":"Use A","rationale":"Because..."}],"acceptance_criteria":[{"given":"X","when":"Y","then":"Z","should_not":"W"}]}'
bd dep add <request-id> --blocked-by <proposal-id>
Before Creating the Proposal
Read the URD and Phase 1 outputs to understand full context before drafting:
bd show <urd-id>
bd show <request-id>
The URD contains the structured requirements, priorities, design choices, and MVP goals from the URE survey. The REQUEST task comments contain Phase 1 outputs: classification (4 axes), domain research findings (prior art, standards), and codebase exploration findings (entry points, related types, dependencies). Your proposal must:
- Trace back to URD requirements
- Incorporate research findings (prior art, domain standards) into engineering tradeoffs
- Reference explore findings (entry points, existing patterns) in the files affected section
Plan Structure
- Requirements Traceability: URD:
<urd-id>
- Problem Space (axes, has-a/is-a)
- Engineering Tradeoffs (table with decisions)
- MVP Milestone (scope with tradeoff rationale)
- Public Interfaces (Go)
- Types & Enums
- Validation Checklist (per phase)
- BDD Acceptance Criteria
- Files Affected
Next Steps
After creating PROPOSAL-N task:
- Run
/pasture:architect-request-review to spawn 3 reviewers
- Wait for all 3 reviewers to vote ACCEPT
- Run
/pasture:architect-ratify to add ratify label to PROPOSAL-N
Follow-up Proposals (FOLLOWUP_PROPOSAL-N)
When creating proposals for a follow-up epic (received via h6 from supervisor):
- Title prefix:
FOLLOWUP_PROPOSAL-N: (e.g., FOLLOWUP_PROPOSAL-1: Add request-id correlation)
- References: Include both
original_urd: <id> and followup_urd: <id> in frontmatter
- Content: Address specific IMPORTANT/MINOR findings scoped in FOLLOWUP_URE/URD
- Same review/ratify/UAT lifecycle applies (3 reviewers, ACCEPT/REVISE, UAT, ratify, handoff)