TenantAtlas/specs/262-lifecycle-governance-taxonomy/tasks.md

Tasks: Workspace, Tenant & Managed Object Lifecycle Governance v1

Input: Design documents from /specs/262-lifecycle-governance-taxonomy/
Prerequisites: plan.md, spec.md, checklists/requirements.md, research.md, data-model.md, quickstart.md, contracts/lifecycle-governance-taxonomy.yaml

Tests (TEST-GOV-001): N/A - docs/standards-only package. Validation stays repo-based and artifact-based using the search commands already captured in plan.md and quickstart.md. Do not add browser, heavy-governance, or runtime unit/feature families for this slice. Operations: No new OperationRun, queue, scheduled work, or runtime mutation is introduced. This package only defines the governance rule for how future lifecycle work chooses audit-only versus shared OperationRun execution paths. RBAC: No new authorization behavior is introduced. The package documents that lifecycle state must never replace scope entitlement or capability checks. UI / Surface Guardrails: No operator-facing runtime surface is changed. This is a workflow-only guardrail package and must not smuggle UI implementation into the lifecycle candidate. Organization: Tasks are grouped by user story so later implementation can remain bounded to standards and governance artifacts only.

Test Governance Checklist

• Lane assignment stays N/A because the slice is docs-only.
• Validation remains artifact and repo-search based; no new runtime tests are added.
• No browser or heavy-governance family is introduced.
• The close-out note records the explicit workflow outcome and test-governance outcome inside the spec package.

Phase 1: Setup (Repo Truth Inventory)

Purpose: Lock the lifecycle source inputs and standards landing zone before drafting the shared contract.

• T001 [P] Verify the current lifecycle-bearing repo sources across specs/143-tenant-lifecycle-operability-context-semantics/spec.md, specs/251-commercial-entitlements-billing-state/spec.md, specs/261-provider-missing-policy-visibility/spec.md, specs/091-backupschedule-retention-lifecycle/spec.md, apps/platform/app/Models/Tenant.php, apps/platform/app/Models/Policy.php, apps/platform/app/Models/ReviewPack.php, apps/platform/app/Models/BackupSet.php, apps/platform/app/Models/RestoreRun.php, apps/platform/app/Console/Commands/PruneReviewPacksCommand.php, and apps/platform/config/tenantpilot.php
• T002 [P] Verify the standards landing zone and index expectations in docs/product/standards/README.md
• T003 [P] Verify the promotion context and follow-up slice names in docs/product/spec-candidates.md

Checkpoint: The repo-real lifecycle inputs and the standards landing zone are locked before the lifecycle contract is written.

---

Phase 2: Foundational Contract (Blocking)

Purpose: Author the shared lifecycle taxonomy and the machine-readable matrix before any downstream standards or candidate-history updates land.

CRITICAL: No downstream standard or candidate-history work should begin until this phase is complete.

• T004 Create docs/product/standards/lifecycle-governance.md from the approved taxonomy in spec.md, research.md, data-model.md, and contracts/lifecycle-governance-taxonomy.yaml
• T005 Copy the six lifecycle dimensions, authoritative source mapping, current repo-real values, reserved follow-up values, and forbidden proxy meanings from contracts/lifecycle-governance-taxonomy.yaml into the standard in docs/product/standards/lifecycle-governance.md, keeping the YAML contract as the canonical machine-readable source
• T006 Update docs/product/standards/README.md to add the new lifecycle-governance standard to the standards index and explain when future specs must use it

Checkpoint: The shared lifecycle standard exists and the standards index points at it.

---

Phase 3: User Story 1 - Classify lifecycle concerns before implementation (Priority: P1) 🎯 MVP

Goal: Give future specs one authoritative map from lifecycle concern to lifecycle dimension.

Independent Test: Review the standard and contract artifacts and confirm that each current repo-real lifecycle example maps to exactly one primary lifecycle dimension.

Validation for User Story 1

• T007 [P] [US1] Run the repo-search validation from quickstart.md and confirm that tenant lifecycle, provider presence, commercial lifecycle, retention signals, and restore continuity all map into one dimension each
• T008 [P] [US1] Re-run checklists/requirements.md and confirm the package still distinguishes current repo-real values from reserved follow-up values

Implementation for User Story 1

• T009 [US1] Finalize the dimension definitions, current repo-real examples, and forbidden proxy rules in docs/product/standards/lifecycle-governance.md
• T010 [US1] Finalize the machine-readable dimension data in contracts/lifecycle-governance-taxonomy.yaml so it stays aligned with the standard

Checkpoint: Every lifecycle concern in scope maps to one dimension and one authoritative source.

---

Phase 4: User Story 2 - Choose the right transition safeguards (Priority: P1)

Goal: Make confirmation, audit, OperationRun, and export/retention preconditions explicit before later runtime slices start.

Independent Test: Review the standard and contract artifacts and confirm that archive/delete, provider observation, commercial suspension, retention/purge, and restoreability transitions all have explicit safeguard rules.

Validation for User Story 2

• T011 [P] [US2] Review the transition-governance table in docs/product/standards/lifecycle-governance.md against data-model.md and contracts/lifecycle-governance-taxonomy.yaml, confirming that export requested remains a reserved retention/compliance value while Data Export Before Deletion v1 remains a separate runtime slice
• T012 [P] [US2] Confirm that audit-only versus OperationRun-backed guidance is explicit and does not imply new runtime behavior in this slice

Implementation for User Story 2

• T013 [US2] Finalize the transition-governance matrix in docs/product/standards/lifecycle-governance.md, including confirmation, audit, OperationRun, export-before-delete, and retention-review rules
• T014 [US2] Keep contracts/lifecycle-governance-taxonomy.yaml aligned with the final transition-governance rules

Checkpoint: Future lifecycle slices can choose the correct safeguard path without guessing.

---

Phase 5: User Story 3 - Keep follow-up slices bounded (Priority: P2)

Goal: Prevent the promoted lifecycle candidate from collapsing back into one oversized umbrella change.

Independent Test: Review the standard, spec package, and candidate history and confirm that every major adjacent concern is listed as an explicit follow-up slice rather than hidden in primary scope.

Validation for User Story 3

• T015 [P] [US3] Verify that export requested appears as a reserved retention/compliance value and that Provider-Missing Managed Object Truth v1, Workspace & Tenant Closure Lifecycle v1, Data Export Before Deletion v1, Retention & Purge Governance v1, and Restoreability Expiry & Evidence Retention v1 appear consistently across spec.md, quickstart.md, data-model.md, and contracts/lifecycle-governance-taxonomy.yaml
• T016 [P] [US3] Verify that the standard in docs/product/standards/lifecycle-governance.md points future runtime work at these follow-up slices instead of absorbing them locally

Implementation for User Story 3

• T017 [US3] Verify that docs/product/spec-candidates.md still records the explicit promotion to Spec 262 without turning the active queue back into an auto-prep target, and refine any stale promotion-versus-deferred wording if the retained history drifts
• T018 [US3] Add the follow-up slice boundaries and review instructions to docs/product/standards/lifecycle-governance.md

Checkpoint: The lifecycle-governance candidate is promoted cleanly and its adjacent concerns stay explicitly separated.

---

Phase 6: Polish & Final Validation

Purpose: Reconcile wording and finish the bounded review path.

• T019 [P] Reconcile any remaining terminology drift for archived, deleted, ignored, provider missing, expired, retained, export requested, purge due, and restorable across spec.md, plan.md, data-model.md, quickstart.md, contracts/lifecycle-governance-taxonomy.yaml, and docs/product/standards/lifecycle-governance.md
• T020 Run the repo-search validation commands from quickstart.md
• T021 [P] Record the final review outcome, workflow outcome, and test-governance outcome in checklists/requirements.md, plan.md, and quickstart.md

Implementation Evidence

• docs/product/standards/lifecycle-governance.md created as the reviewer-facing lifecycle standard.
• docs/product/standards/README.md updated to index lifecycle governance and route lifecycle-bearing specs through it.
• contracts/lifecycle-governance-taxonomy.yaml aligned with the standard through standards_document, transition ownership, and execution-path fields.
• Validation passed with the focused repo-search commands from quickstart.md, YAML parse for six dimensions and six transition rules, and git diff --check.
• Browser smoke test is not applicable because this slice changes no operator-facing runtime surface.

---

Dependencies & Execution Order

Phase Dependencies

• Setup (Phase 1): starts immediately and locks the repo-real lifecycle inputs.
• Foundational Contract (Phase 2): depends on Setup and blocks all later work.
• User Story 1 (Phase 3): depends on Foundational Contract.
• User Story 2 (Phase 4): depends on User Story 1 because the transition rules rely on the final dimension map.
• User Story 3 (Phase 5): depends on User Stories 1 and 2 so follow-up slices reflect the final taxonomy and safeguard rules.
• Polish (Phase 6): depends on all desired user stories being complete.

User Story Dependencies

• US1: no dependencies beyond Foundational Contract.
• US2: depends on US1.
• US3: depends on US1 and US2.

Parallel Opportunities

• T001, T002, and T003 can run in parallel during Setup.
• T004, T005, and T006 run in sequence during the Foundational Contract phase.
• T007 and T008 can run in parallel for User Story 1.
• T011 and T012 can run in parallel for User Story 2.
• T015 and T016 can run in parallel for User Story 3.

Notes

• Suggested MVP scope: Phase 1 through Phase 4 only. That is the minimum needed to answer the deferred candidate's lifecycle-question set safely.
• Explicit non-goals remain: runtime deletion, closure, purge, migration, panel/provider work, assets, lifecycle dashboard, and lifecycle framework implementation.
• All tasks above stay on the standards and documentation path only.