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

- [x] Lane assignment stays `N/A` because the slice is docs-only.
- [x] Validation remains artifact and repo-search based; no new runtime tests are added.
- [x] No browser or heavy-governance family is introduced.
- [x] 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.

- [x] 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`
- [x] T002 [P] Verify the standards landing zone and index expectations in `docs/product/standards/README.md`
- [x] 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.

- [x] 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`
- [x] 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
- [x] 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

- [x] 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
- [x] 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

- [x] T009 [US1] Finalize the dimension definitions, current repo-real examples, and forbidden proxy rules in `docs/product/standards/lifecycle-governance.md`
- [x] 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

- [x] 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
- [x] 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

- [x] 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
- [x] 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

- [x] 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`
- [x] 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

- [x] 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
- [x] 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.

- [x] 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`
- [x] T020 Run the repo-search validation commands from `quickstart.md`
- [x] 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.