TenantAtlas/specs/406-governance-artifact-lifecycle-retention/checklists/requirements.md

Requirements Checklist: Spec 406 - Governance Artifact Lifecycle & Retention

Feature: specs/406-governance-artifact-lifecycle-retention/
Review date: 2026-06-23
Scope: Preparation artifact quality only. No application implementation performed.

Candidate Selection Gate

• The selected candidate was directly provided by the operator as Spec 406.
• The selected candidate matches manual backlog item governance-artifact-lifecycle-retention-runtime.
• docs/product/spec-candidates.md was reviewed and still reports no safe automatic next-best-prep target.
• The candidate aligns with docs/product/roadmap.md Governance Artifact Lifecycle & Retention runtime priority.
• Completed Spec 267 is treated as read-only historical context and is not modified.
• Specs 158, 262, 400, 403, 404, and 405 are read-only context.
• No existing specs/406-governance-artifact-lifecycle-retention/ package existed before preparation.
• A different branch named 406-provider-policy-domain-public-taxonomy is recorded as unrelated.
• The smallest slice is lifecycle action, retention, export/download, hold/delete, file/database consistency, audit, tests, browser proof, and final report over existing artifacts.
• Close alternatives are deferred instead of hidden inside this package.
• Candidate Selection Gate result: PASS as a manual operator-promoted follow-through candidate.

Spec Completeness

• Problem statement is clear and product-oriented.
• Business/product value is explicit.
• Primary users/operators are named.
• Scope fields cover routes/surfaces, ownership, RBAC, and leakage checks.
• Functional requirements are testable.
• Non-functional requirements cover security, reliability, auditability, performance, deployment, and test governance.
• User stories include independent tests and acceptance scenarios.
• Edge cases are documented.
• Out-of-scope boundaries forbid portal, eDiscovery, compliance claims, report redesign, evidence/currentness rewrite, JSONB migration, and broad audit scope.
• Success criteria are measurable.
• Assumptions, risks, and open questions are explicit.

Constitution And Proportionality

• Spec Candidate Check is filled out.
• Approval class is exactly one class: Core Enterprise.
• Score is recorded and above the minimum threshold.
• Proportionality Review is completed.
• No generic artifact table/entity/source of truth is approved by default.
• No broad lifecycle framework, purge platform, export center, compliance taxonomy, or UI framework is approved by default.
• Runtime changes are limited to confirmed in-scope lifecycle/action/proof defects over existing artifacts.
• The spec requires stopping and updating spec/plan before broader architecture or product scope.

Product Surface Contract

• docs/product/standards/product-surface-contract.md is referenced.
• No-legacy posture is recorded.
• Product Surface Impact is completed for existing artifact/status/download/customer-output surfaces.
• Page archetypes are identified as Report Page, Receipt Page, Decision Page, Technical Annex, and Search/Index Page where applicable.
• Surface-budget expectations and Technical Annex/deep-link demotion are documented.
• Canonical status vocabulary expectations are documented.
• Product Surface exceptions are none planned.
• Browser proof is required and focused.
• Human Product Sanity is required.
• UI coverage registry review/update or checked no-update rationale is required if rendered existing surfaces materially change.
• Implementation-report close-out fields are required.
• Completed historical specs are read-only context and must not be rewritten.

Plan Completeness

• Plan identifies PHP/Laravel/Filament/Livewire/Pest/PostgreSQL/Sail/Dokploy context.
• Plan names existing runtime code surfaces likely affected if defects are found.
• Plan distinguishes Spec 267 read-only lifecycle completion from Spec 406 action/runtime hardening.
• Plan includes UI/Product Surface, Filament/Livewire/deployment, shared-pattern, OperationRun, RBAC, audit, storage, and test-governance posture.
• Plan defines lifecycle matrix-first implementation.
• Plan includes stop conditions.
• Plan does not contradict repository architecture or current code truth.

Task Completeness

• Tasks are ordered by preparation, inventory, matrix, tests, implementation, browser proof, and close-out.
• Tasks are small and verifiable.
• Tasks require tests before runtime fixes where practical.
• Tasks include explicit lane classification.
• Tasks include Product Surface and Filament output-contract close-out fields.
• Tasks require authorization, cross-workspace, customer-safe, evidence/currentness, failure, storage, retention, audit, and file/database consistency proof.
• Tasks include focused browser proof and Human Product Sanity.
• Tasks include non-goals preventing scope creep.
• Tasks include final validation commands and implementation-report completion.

Open Questions And Readiness

• Product decisions about actual deletion support, expired customer access, and hold persistence are recorded as implementation-time decisions handled by matrix classification.
• No open question blocks starting the implementation loop because unsafe decisions must become PRODUCT DECISION REQUIRED rows rather than invented behavior.
• Spec Readiness Gate result: PASS for implementation preparation.

Review Outcome

• Review outcome class: acceptable-special-case for a bounded governance artifact lifecycle runtime-hardening gate.
• Workflow outcome: keep.
• Final note location: future implementation report specs/406-governance-artifact-lifecycle-retention/implementation-report.md.
• No application implementation was performed during preparation.