This commit is contained in:
@@ -0,0 +1,56 @@
|
||||
# Multidimensional lifecycle presentation audit
|
||||
|
||||
Use this audit when canonical task execution or deployment evidence has advanced but Scope, Architecture, Kanban, or release pages may still show an earlier snapshot.
|
||||
|
||||
## Model the dimensions separately
|
||||
|
||||
For every affected Epic and Feature, record these as distinct fields rather than forcing them into one status:
|
||||
|
||||
1. **Scope lifecycle** — proposal and `Approved for Solution` state owned by Scope.
|
||||
2. **Solution package** — package completeness, requirements, ADRs, and C4 impact owned by Architecture.
|
||||
3. **Implementation approval** — exact Feature decision and conditions.
|
||||
4. **Execution** — task-derived `InBacklog`, `InProgress`, or `ToBeReleased` state. Mark parent Epic/Feature values as **derived** unless they have their own canonical flow event.
|
||||
5. **Publication/deployment** — application source, published artifact, selected GitOps revision, and verified runtime source.
|
||||
6. **Acceptance/release** — Feature acceptance and final release allocation; never infer these from execution or deployment.
|
||||
|
||||
## Evidence-first consistency matrix
|
||||
|
||||
Build an expected-versus-actual matrix from current remote default:
|
||||
|
||||
| Surface | Required comparison |
|
||||
|---|---|
|
||||
| Canonical Feature records | Scope state, package status, implementation decision, proposed/final version |
|
||||
| Canonical task records | `status`, `flow_state`, `delivery_started`, flow history, implementation evidence |
|
||||
| Scope Roadmap | All lifecycle dimensions visible; current prose agrees with canonical tasks |
|
||||
| Kanban Board/Focus | Exact tasks shown directly; parent execution clearly labelled as derived |
|
||||
| Architecture lifecycle/registers | Historical admission snapshots are dated or updated; no current claim that Delivery has not started when tasks are active |
|
||||
| Release readiness | Published source, selected GitOps revision, and runtime source kept distinct |
|
||||
| Task evidence prose | Deployment claims agree with Releases/runtime evidence without implying acceptance |
|
||||
| Public adapters and types | Verification fields are derived before private metadata is stripped |
|
||||
| Tests | Production-data assertions plus mutations for stale prose, missing derived fields, and forged cross-record evidence |
|
||||
|
||||
Do not accept a green build as semantic consistency. Search static prose for obsolete assertions such as `Delivery has not started`, `all tasks are InBacklog`, `not deployed`, or `no implementation evidence`, then compare each claim with canonical YAML and current immutable evidence.
|
||||
|
||||
## Parent-state derivation rules
|
||||
|
||||
- Derive Feature execution only from verifier-admitted child tasks.
|
||||
- Derive Epic execution only from verified child Feature/task execution.
|
||||
- Label every derived parent state `(derived)` in visual nodes, tables, and accessibility text.
|
||||
- Preserve Scope status as Scope status; do not rewrite `Approved for Solution` to `InProgress`.
|
||||
- Define deterministic aggregation precedence and test mixed child states.
|
||||
- A parent-derived `InProgress` value is presentation evidence, not a new lifecycle decision.
|
||||
|
||||
## Coordinated remediation
|
||||
|
||||
1. Freeze six-channel high-watermarks and current remote default SHA.
|
||||
2. Confirm the contradiction using canonical records and exact immutable implementation/deployment evidence.
|
||||
3. Inventory every sibling surface and adapter that presents the affected records.
|
||||
4. Update data derivation, types, visual nodes, semantic tables, accessibility text, static prose, and tests together.
|
||||
5. Include negative assertions rejecting superseded current-state wording.
|
||||
6. Run production-data derivation tests, all domain validators, TypeScript, strict build, browser QA, generated-output drift checks, and `git diff --check`.
|
||||
7. Publish one owning PR, verify the complete changed-file list, wait for exact-head CI, merge only under the active authority contract, and verify exact-default CI.
|
||||
8. Perform a final six-channel plus remote-artifact convergence pass.
|
||||
|
||||
## Concurrent candidate rule
|
||||
|
||||
If another Architecture session has already disclosed or created an unpublished lifecycle correction, verify only its branch, base/head, cleanliness, publication state, remote PR inventory, and claimed CI. Do not modify, rebase, publish, validate as your deliverable, or create a competing PR. Report uncovered contradictions as required scope for the owning review, distinguishing current default truth from unpublished candidate work.
|
||||
Reference in New Issue
Block a user