fix: preserve task lifecycle approval evidence
This commit is contained in:
@@ -204,7 +204,7 @@ Architecture derives and maintains implementation-task semantics, dependencies,
|
||||
|
||||
Architecture owns complete Task decomposition for every Feature allocated to the release. Before reporting a release planning-ready, Architecture must:
|
||||
|
||||
1. review existing Tasks and retain, revise, or supersede them according to the current Feature outcomes and Architecture boundaries;
|
||||
1. Architecture creates missing Tasks, reviews existing Tasks, and retains, revises, supersedes, or removes them according to the current Feature outcomes and Architecture boundaries. Architecture may freely revise or remove only draft Tasks with no implementation approval, Kanban admission, execution, or completion evidence;
|
||||
2. define at least two independently executable Tasks per Feature unless a recorded Architecture rationale proves that one atomic Task is the smallest verifiable boundary;
|
||||
3. map the Feature's Tasks collectively to every acceptance outcome and every applicable requirement, with reciprocal canonical traceability;
|
||||
4. encode within-Feature sequencing and every cross-Feature prerequisite as acyclic Task dependencies;
|
||||
@@ -213,6 +213,8 @@ Architecture owns complete Task decomposition for every Feature allocated to the
|
||||
|
||||
Architecture must not report planning readiness while any Feature allocated to the release lacks this complete Task breakdown. A Feature-shaped placeholder Task, a generated empty Task group, or requirement coverage without executable Tasks does not satisfy the gate.
|
||||
|
||||
Approved, Kanban-admitted, in-progress, or completed Tasks must not be deleted or silently rewritten. Retain an obsolete Task with a terminal Superseded or Cancelled status, its prior evidence and history, and explicit replacement links. A material change to Task scope, outcome, dependency, repository, or component must invalidate prior readiness evidence and return the affected record to the appropriate pre-approval state; renewed human `Approved for Implementation` and a separate exact-task Kanban Focus admission are required where applicable before execution resumes.
|
||||
|
||||
```text
|
||||
canonical_id | display_id | feature | outcome | scope | dependencies | owner | status | acceptance evidence | affected repository/component
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user