feat: mine reusable AeroSim channel lessons

2026-09-10 11:41:24 +00:00
parent ef46b74bb0
commit 3fad2179c4
7 changed files with 484 additions and 1 deletions
@@ -0,0 +1,69 @@
+# 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.