58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
# Epic feature-set completeness review
|
|
|
|
Use this pattern when a human asks whether an Epic includes every Feature needed for its stated outcome, or whether its unresolved questions are documented.
|
|
|
|
## Evidence boundary
|
|
|
|
Assess completeness against the Epic's current intended outcome, user journey, explicit exclusions, and cited human request. Do not invent a Feature to satisfy cadence. Label the result as a Scope assessment or proposal, never approval.
|
|
|
|
## Epic-page pattern
|
|
|
|
Add a durable section at the point of review:
|
|
|
|
```md
|
|
## Feature-set completeness review
|
|
|
|
The proposed Features form the minimum complete set for the current Epic outcome. This is a Scope assessment, not approval.
|
|
|
|
| User journey outcome | Owning Feature | Why it is required |
|
|
|---|---|---|
|
|
| `<OUTCOME>` | [`<FEATURE-ID>`](<LINK>) | `<UNIQUE VALUE OR COVERAGE>` |
|
|
```
|
|
|
|
Then state:
|
|
|
|
- which shared capabilities are acceptance expectations inside existing Features rather than standalone Features;
|
|
- which adjacent outcomes remain explicitly outside the Epic;
|
|
- whether evidence supports another Feature;
|
|
- that expanding an excluded outcome requires a new or revised Scope proposal;
|
|
- that Epic approval does not approve child Features.
|
|
|
|
A completeness review should detect both gaps and duplication. Do not create separate Features for shared technical components or cross-cutting behavior unless they independently deliver user value within the Epic outcome.
|
|
|
|
## Canonical-question confirmation
|
|
|
|
Answer “are the questions documented?” at the decision point, not only in an aggregate registry:
|
|
|
|
```md
|
|
## Canonical product questions
|
|
|
|
The unresolved product questions are recorded in the [question register](<REGISTER-LINK>). It records each stable question ID, affected items, owner, destination, status, blocker, and evidence.
|
|
```
|
|
|
|
Link the dependency-ordered resolution sequence when one exists. Reiterate that question resolution and lifecycle approval are separate records, and that conditional approval must name every unresolved question or equivalent scope condition carried into Architecture as an unresolved risk.
|
|
|
|
## Validation
|
|
|
|
When the repository has structural validators, add a RED-first assertion for:
|
|
|
|
- the completeness-review heading;
|
|
- the journey-to-Feature coverage table;
|
|
- the canonical-question heading and register link.
|
|
|
|
Run the targeted validator and observe the expected missing-marker failure before adding content. Then run the targeted validator, full documentation validator, type checking, link/build checks, and production build. This prevents a later edit from silently removing the human decision package while leaving the site build green.
|
|
|
|
## Publication evidence
|
|
|
|
Refresh the existing authoritative Scope PR rather than opening a competing change. After pushing, verify branch equality, PR head equality, authenticated artifact readback, and the newest exact-head CI task. Re-read only the authorized project channels at the end to ensure no human decision arrived during publication.
|