70 lines
4.0 KiB
Markdown
70 lines
4.0 KiB
Markdown
# Scope decision-readiness pattern
|
|
|
|
Use this pattern when Epics or Features in `IN_DESIGN` have open product questions and need an approval decision under the active authority contract.
|
|
|
|
## Decision-readiness matrix
|
|
|
|
| Item | Scope-owned open dependencies | Decision implication |
|
|
|---|---|---|
|
|
| `<EPIC-ID>` | `<QUESTION-IDS>` | Review Epic direction independently from child Features. Epic approval does not authorize Feature solution work. |
|
|
| `<FEATURE-ID>` | `<QUESTION-IDS>` | Unconditional approval is not ready. A conditional approval must preserve these questions as named conditions and unresolved Architecture risks. |
|
|
|
|
Keep dependency lists consistent with the canonical Epic and Feature pages. Other channels may propose additional risks, but they must not silently rewrite Scope dependencies.
|
|
|
|
## Epic-page readiness block
|
|
|
|
Do not leave the Epic decision boundary only in the aggregate Roadmap. On each unapproved Epic page, place a readiness block beside the approval record:
|
|
|
|
```md
|
|
No **Approved for Solution** gate is recorded for `<EPIC-ID>`. Its delivery status remains **IN_DESIGN** and unconditional approval is blocked while `<EXACT-QUESTION-IDS>` remain open.
|
|
|
|
An actor permitted by the active authority contract may approve `<EPIC-ID>` conditionally, but the decision must name every unresolved question it carries forward—or an equally explicit scope condition—and Architecture must preserve those conditions as unresolved risks.
|
|
|
|
The first proposed decision package is `<QUESTION-IDS>`: `<SHORT DECISION SUMMARY>`. This ordering is a proposal, not approval. Approval of this Epic would not approve any child Feature; each Feature requires its own explicit authorized decision.
|
|
```
|
|
|
|
The Epic's exact question IDs must match the Roadmap matrix and canonical question register. When no first package is justified by dependency order, omit that paragraph rather than inventing one.
|
|
|
|
## Feature-page readiness block
|
|
|
|
Do not leave the exact decision boundary only in the aggregate Roadmap. On each unapproved Feature page, place a short readiness block beside the approval record:
|
|
|
|
```md
|
|
No **Approved for Solution** gate is recorded. The Feature remains **IN_DESIGN** and unconditional approval is blocked while `<EXACT-QUESTION-IDS>` remain open.
|
|
|
|
An actor permitted by the active authority contract may approve `<FEATURE-ID>` conditionally, but the decision must name every unresolved question it carries forward—or an equally explicit scope condition—and Architecture must preserve those conditions as unresolved risks.
|
|
```
|
|
|
|
The exact question IDs must match both the Feature's canonical dependencies and its Roadmap matrix row. A generic phrase such as "open questions remain" is insufficient for a reviewable conditional decision.
|
|
|
|
## Approval evidence
|
|
|
|
A valid `Approved for Solution` gate decision records:
|
|
|
|
- actor identity and authority basis;
|
|
- decision date;
|
|
- exact stable Epic or Feature ID;
|
|
- explicit `Approved for Solution` wording;
|
|
- scope conditions and unresolved questions;
|
|
- source Discord message or reviewed documentation evidence.
|
|
|
|
Do not infer approval from an Epic decision, question closure, silence, documentation merge, CI result, delivery status, delivery activity, or release planning.
|
|
|
|
## Conditional approval
|
|
|
|
Open questions prevent unconditional readiness, but they do not prohibit an authorized actor from granting conditional solution approval. If that happens:
|
|
|
|
1. Preserve every named condition in the Scope approval record.
|
|
2. Hand the open questions to Architecture as unresolved risks.
|
|
3. Require Architecture requirements and decisions to reference those conditions.
|
|
4. Keep implementation, Focus admission, version, release, and deployment gates separate.
|
|
|
|
## Review ordering
|
|
|
|
When Scope, Architecture, Kanban, and release-readiness PRs depend on one another:
|
|
|
|
1. Review the correction to the earliest authoritative layer first.
|
|
2. Refresh downstream branches if the merge changes their base or evidence.
|
|
3. Validate and cite CI at each new exact head SHA.
|
|
4. Treat independent PRs independently; do not manufacture ordering where no content dependency exists.
|