| name | phase-1-prd-revision |
| description | Product Owner revises PRD v1 based on Architect's feasibility review. Incorporates architectural feedback, updates subsystem grouping if justified. Max 3 iterations before escalation to human.
|
| agents | {"primary":"product-owner","supporting":["architect"]} |
| inputs | [".factory/specs/architecture-feasibility-report.md",".factory/specs/prd.md","behavioral-contract files (sharded into ss-NN/ subdirs per registry)"] |
| outputs | [".factory/specs/prd.md (updated)","behavioral-contract files updated in their canonical registry locations"] |
| gate | Architect approves or max 3 iterations reached |
PRD Revision (Given Architecture Feasibility Report)
Purpose
When the architect flags issues in the Architecture Feasibility Report,
the product-owner revises the PRD and behavioral contracts to address them.
Flow
- Read
architecture-feasibility-report.md for flagged issues
- For each issue:
- If subsystem restructuring proposed: evaluate and accept or contest
- If NFR conflict: add architectural constraint annotations to affected BCs
- If verifiability concern: adjust BC postconditions for testability
- Update PRD v2 (or v3 if iteration 2)
- Update affected BC files
- Notify orchestrator: "PRD revision complete"
Convergence
- Max 3 iterations between PO and Architect
- If disagreement persists after 3 rounds: escalate to human
- Decision reasoning recorded in Architecture Feasibility Report Decision Log
Skip Condition
If architect's feasibility report says "validated — no issues": skip this step entirely.
Quality Gate
Failure Modes
- If architect and product-owner deadlock after 3 iterations: escalate to human with both positions
- If feasibility report references missing BCs: route to product-owner to create them first
- If NFR conflicts cannot be resolved without scope reduction: present trade-offs to human
