TenantAtlas/specs/406-governance-artifact-lifecycle-retention/spec.md

Feature Specification: Spec 406 - Governance Artifact Lifecycle & Retention

Feature Branch: 406-governance-artifact-lifecycle-retention
Created: 2026-06-23
Status: Draft / Ready for implementation preparation review
Type: Product-contract implementation / lifecycle hardening / auditability spec
Input: User-provided Spec 406 draft, Spec 400 product-contract audit context, Specs 403-405 proof lineage, existing Spec 267 read-only lifecycle contract close-out, docs/product/spec-candidates.md, docs/product/roadmap.md, and docs/product/standards/lifecycle-governance.md.

Candidate Selection Context

• Selected candidate: Governance Artifact Lifecycle & Retention.
• Source location: Direct user-provided Spec 406 draft in /Users/ahmeddarrazi/.codex/attachments/75e1fbd9-6253-41a7-a47b-634099bd597f/pasted-text.txt.
• Why selected: docs/product/spec-candidates.md marks the automatic candidate queue as empty, but also lists governance-artifact-lifecycle-retention-runtime as manual-promotion backlog item 2. The operator supplied that manual promotion as Spec 406 after Specs 400-405 supplied adjacent product-contract, evidence/currentness, PDF runtime, and JSONB substrate proof lineage. Spec 403 is closed as PASS; Specs 404 and 405 are PASS WITH CONDITIONS because external Staging/Dokploy proof remains unavailable, so Spec 406 must carry those conditions forward and must not claim production/staging readiness from them.
• Roadmap relationship: Supports the current trust and auditability hardening lane by proving retained governance artifacts can be released, exported, archived, expired, held, deleted, and downloaded without false evidence claims, file/database drift, customer-safe leakage, or authorization drift.
• Completed-spec guardrail result:
  • specs/267-artifact-lifecycle-retention/ is completed/historical context for the shared read-only lifecycle and retention contract. Its implementation close-out, checked task history, browser smoke, and deferred hold/deletion-request decision must not be rewritten.
  • Specs 158, 262, 267, 400, 401, 402, 403, 404, and 405 are read-only context. Their validation history, implementation reports, and completed task markers must not be normalized or removed.
  • No specs/406-governance-artifact-lifecycle-retention/ package existed before this preparation. A different branch named 406-provider-policy-domain-public-taxonomy exists, but it has no matching Spec 406 lifecycle package and is unrelated.
• Smallest viable implementation slice: Inventory existing governance artifact families; create a lifecycle matrix; implement only bounded lifecycle, hold, export/download, delete/archive/expire, and file/database consistency behavior that can be attached to existing artifact owners; add audit/OperationRun proof where repo contracts require it; run focused tests and browser proof against existing surfaces; produce a final implementation report. No new major surface, compliance claim, portal, registry, purge platform, or broad export center is allowed.
• Feature description for Spec Kit: Prove and minimally harden lifecycle behavior for existing TenantPilot governance artifacts so retained proof can be safely viewed, exported, held, archived, expired, deleted, or blocked according to explicit product rules without weakening evidence truth, customer-safe boundaries, authorization, auditability, or file/database consistency.

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: TenantPilot has repo-real evidence snapshots, review packs, stored reports, management-report PDFs, OperationRun proof, findings, exceptions, and customer review outputs, but lifecycle actions and retention behavior remain uneven across artifact families.
• Today's failure: A generated or released artifact can look downloadable when its file is missing, an expired artifact can be interpreted as current proof, a held artifact can lack enforceable delete blocking, and customer-safe exports can rely on local assumptions instead of a tested lifecycle contract.
• User-visible improvement: Operators and customer reviewers get honest artifact availability and lifecycle state. Destructive or export actions are authorized, confirmation-backed where visible, audited, and blocked when state or hold rules require it.
• Smallest enterprise-capable version: Implement lifecycle proof for existing high-risk artifact families only: review packs, stored reports/management PDFs, evidence snapshots, OperationRun proof packages where exposed as artifacts, governance inbox/finding exception artifacts, and current customer-review outputs. Scope includes lifecycle matrix, retention/expiration/hold/delete/export/download gates, tests, browser proof, and final report.
• Explicit non-goals: No new customer portal, eDiscovery product, legal compliance claim, broad export center, new report template, PDF layout rewrite, evidence/currentness semantics rewrite, JSONB migration, provider integration, backup/restore behavior, authorization model, or full browser/UX/runtime audit.
• Permanent complexity imported: Possible current-table metadata fields, lifecycle transition service/action code, policy methods, retention command/job adjustments, audit event IDs, targeted tests, focused browser proof, and one implementation report. No generic artifact super-table or universal lifecycle framework is approved by default.
• Why now: Spec 267 delivered read-only lifecycle truth but deferred hold and deletion-request persistence. Specs 400-405 closed or bounded adjacent blockers; Spec 404/405 conditions are non-blocking only where the lifecycle matrix proves they do not affect Spec 406 storage, download, runtime, or deployment claims. The supplied Spec 406 now targets the remaining retained-artifact runtime risk before a broad browser/UX/runtime audit can be trusted.
• Why not local: Local fixes on one download route or one resource would not prove cross-artifact hold, export, delete, retention, customer-safe, and file/database consistency semantics.
• Approval class: Core Enterprise.
• Red flags triggered: New lifecycle/action semantics across several artifact families. Defense: the slice is restricted to existing artifacts and existing surfaces, requires a matrix-first implementation, and forbids new surfaces, generic registries, legal claims, and purge-platform scope.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve as a bounded runtime hardening and proof package.

Problem Statement

TenantPilot uses governance artifacts as operational, customer, audit, or management proof. The product is not lifecycle-stable until it can answer:

Can TenantPilot prove that governance artifacts have clear lifecycle, retention, export, delete, and hold semantics without weakening evidence truth, authorization, customer-safe output, file/database consistency, or auditability?

This spec closes the remaining runtime proof gap over existing artifacts. It does not create a new compliance product. It makes existing retained proof safer and more honest.

Product / Business Value

• Reduces accidental deletion, orphaned generated file, and false downloadable-state risk.
• Prevents customer-safe output from exposing internal-only evidence, raw payloads, OperationRun internals, or cross-workspace data.
• Gives release reviewers a single lifecycle matrix and final gate result before broader browser/UX/runtime audit work proceeds.
• Makes future retention, purge, export-before-delete, and customer-portal work smaller because the high-risk current artifact rules are explicit.

Primary Users / Operators

• Workspace admins managing review packs, evidence, stored reports, and management outputs.
• System or support operators reviewing audit and OperationRun proof without exposing internal details to customers.
• Customer reviewers consuming released customer-safe artifacts.
• Engineering reviewers validating lifecycle, authorization, audit, and retention behavior before productization continues.

Spec Scope Fields (mandatory)

• Scope: workspace plus managed-environment artifact lifecycle hardening over existing artifact records and existing rendered/download surfaces.
• Primary Routes / Surfaces:
  • ReviewPackResource list/detail and signed review-pack download route.
  • Management report PDF generation/download surfaces backed by StoredReport.
  • Evidence snapshot list/detail and evidence overview/currentness surfaces.
  • Customer review workspace retained-output consumption.
  • OperationRun detail/proof only where a run is exposed as artifact proof.
  • Finding exception / accepted-risk / governance inbox artifacts where existing surfaces expose retained proof.
• Data Ownership:
  • Governance artifacts remain owned by their current workspace and managed environment records.
  • Stored reports and generated files remain StoredReport records plus private exports disk paths.
  • Review packs remain ReviewPack records plus existing file metadata.
  • Evidence snapshots remain EvidenceSnapshot records and related evidence items.
  • No generic artifact super-table is approved by default.
• RBAC:
  • Workspace and managed-environment entitlement are required before artifact visibility, download, export, hold, archive, delete, or lifecycle mutation.
  • Non-members and wrong-scope actors receive deny-as-not-found (404).
  • In-scope members without capability receive 403.
  • Customer reviewers can access only released customer-safe artifacts allowed by the existing customer-output contract.
  • Destructive/high-impact lifecycle actions require server-side authorization, explicit confirmation when exposed through Filament, audit proof, and hold-state blocking.

For canonical or mixed-scope surfaces:

• Default filter behavior when environment context is active: Existing route-owned workspace/environment scope remains authoritative. Lifecycle actions must resolve the persisted artifact and its owner, not hidden current context.
• Explicit entitlement checks preventing cross-tenant leakage: Download/export/delete/hold/archive/expire routes and actions must re-check workspace, managed environment, capability, customer-safe state, artifact lifecycle state, and file existence at execution time.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production for this lifecycle hardening.

• Compatibility posture: canonical lifecycle behavior over current artifact records.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no, unless this spec is updated with an explicit compatibility exception.
• Why clean replacement is safe now: lifecycle action behavior is not yet productized as a production customer contract. Existing historical specs remain read-only context, and current runtime behavior may be tightened before production.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• New table/form/state added
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

UI/Productization Coverage

• Route/page/surface: Existing review-pack, stored-report/management-PDF, evidence, customer-review, OperationRun proof, and finding/exception artifact surfaces.
• Current or new page archetype: Report Page, Receipt Page, Decision Page, Technical Annex, and Search/Index Page depending on the existing surface.
• Design depth: Domain Pattern Surface for existing artifact owner surfaces; Technical Annex for OperationRun/raw proof detail.
• Repo-truth level: repo-verified for review packs, stored reports, evidence snapshots, OperationRun, findings, and current customer review output.
• Existing pattern reused: native Filament resources/pages, existing signed download controllers, shared artifact-truth/badge paths, current policies/capabilities, existing audit logging, private exports disk.
• New pattern required: none by default. Any new lifecycle action must be attached to an existing artifact owner surface.
• Screenshot required: yes for focused lifecycle/browser proof on representative rendered surfaces.
• Page audit required: no full page audit; only focused product-surface proof.
• Customer-safe review required: yes for released/downloadable/customer-review artifacts.
• Dangerous-action review required: yes for delete, hard-delete, purge-like, hold release when it enables deletion, and lifecycle actions that change availability.
• Coverage files updated or explicitly not needed:
  • docs/ui-ux-enterprise-audit/route-inventory.md - review/update required if implementation materially changes a listed route, action, status, or customer-output surface; otherwise record checked no-update rationale in the implementation report.
  • docs/ui-ux-enterprise-audit/design-coverage-matrix.md - review/update required if implementation materially changes visible complexity, page archetype, dangerous-action posture, or customer-safe output; otherwise record checked no-update rationale in the implementation report.
  • docs/ui-ux-enterprise-audit/page-reports/...
  • docs/ui-ux-enterprise-audit/strategic-surfaces.md
  • docs/ui-ux-enterprise-audit/grouped-follow-up-candidates.md
  • docs/ui-ux-enterprise-audit/unresolved-pages.md
  • N/A - no reachable UI surface impact
• No-impact rationale when applicable: N/A. Existing surfaces can change; implementation must either update the registry artifacts above or record a checked no-update rationale when the change is non-material to route inventory and design coverage.

Product Surface Impact (mandatory)

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: yes, because existing rendered status, report, download, customer-output, and dangerous-action behavior may change.
• Page archetype: Report Page for customer/management outputs, Receipt Page for generated artifact proof, Decision Page for lifecycle action confirmation, Technical Annex for OperationRun/internal evidence, Search/Index Page for artifact lists.
• Primary user question: "Can this artifact still be trusted, used, exported, downloaded, held, or deleted?"
• Primary action: One artifact-appropriate action such as Download artifact, View source review, Place hold, Release hold, or Delete artifact.
• Surface budget result: pass expected; any exception must be documented in the implementation report.
• Technical Annex / deep-link demotion: OperationRun links, raw evidence IDs, source keys, detectors, fingerprints, provider payloads, raw file paths, and technical logs stay out of customer-facing defaults and remain secondary/internal.
• Canonical status vocabulary: Use Product Surface states such as Ready, Needs attention, Blocked, Running, Failed, Expired, Historical, Superseded, and Unknown. Domain lifecycle values may exist internally but must map before product display.
• Visible complexity impact: neutral or decreased; increased visible complexity requires an approved exception.
• Product Surface exceptions: none planned.

Browser Verification Plan (mandatory)

• Browser proof required?: yes.
• No-browser rationale: N/A.
• Focused path when required: representative review-pack detail/download, management-report PDF owner/download state, evidence snapshot/detail, and customer review workspace retained-output path.
• Primary interaction to execute: view lifecycle state, attempt allowed download/export, attempt blocked customer/unauthorized access, attempt delete on held artifact, and verify expired/deleted/missing-file artifacts are not presented as valid downloads.
• Console, Livewire, Filament, network, and 500-error checks: planned.
• Full-suite failure triage: unrelated failures may be documented only when focused Spec 406 proof is green and evidence supports the classification.

Human Product Sanity Check (mandatory)

• Required?: yes.
• No-human-sanity rationale: N/A.
• Reviewer questions: purpose clear, exactly one dominant next action per surface, technical details demoted, status labels canonical, customer-safe boundary understandable, destructive action risk clear, complexity not worse.
• Planned result location: specs/406-governance-artifact-lifecycle-retention/implementation-report.md.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed.
• Browser proof is planned for rendered lifecycle/download/action behavior.
• Human Product Sanity is planned.
• Product Surface exceptions are none planned.
• Implementation report will state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite assertion.

Functional Requirements

• FR-406-001: The implementation MUST inventory all in-scope governance artifact families and produce a Governance Artifact Lifecycle Matrix before lifecycle code changes.
• FR-406-002: Every in-scope artifact family MUST have a lifecycle classification or a documented exception.
• FR-406-003: Lifecycle state, retention state, evidence/currentness truth, and file availability MUST remain separate dimensions.
• FR-406-004: A released artifact MUST remain point-in-time proof and MUST NOT silently become current runtime evidence after underlying evidence changes.
• FR-406-005: A generated or ready artifact MUST NOT be downloadable when its required file is missing, zero-byte, corrupt, on the wrong disk, or not authorized for the current actor.
• FR-406-006: A failed artifact MUST NOT be released or displayed as valid generated proof without successful regeneration.
• FR-406-007: For every artifact family classified as supporting hold in Spec 406, a held artifact MUST NOT be deleted, purged, or automatically cleaned up while the hold is active.
• FR-406-008: Hold, unhold, archive, expire, delete, export, and download behavior MUST be authorized directly and tested for positive, negative, cross-workspace, cross-environment, and customer-reviewer cases where the action exists.
• FR-406-009: Destructive or high-impact Filament actions MUST execute via Action::make(...)->action(...), include ->requiresConfirmation(), and enforce server-side authorization.
• FR-406-010: Delete behavior MUST be explicit for each artifact family before adding runtime mutation code: archive-only, soft delete, file delete, metadata delete, hard delete, or deferred/no-delete.
• FR-406-011: If the repo has no purge concept for a family, this spec MUST NOT invent broad purge semantics. Any purge-like need must be recorded as a follow-up or explicit family-local decision.
• FR-406-012: Export and download paths MUST exclude internal-only evidence, raw provider payloads, raw source keys, internal OperationRun details, stack traces, internal exception messages, system-only links, and cross-workspace data from customer-safe output.
• FR-406-013: Retention and expiration behavior MUST use existing configuration where present and add only bounded configurable defaults where necessary.
• FR-406-014: Retention cleanup or expiration jobs MUST be idempotent, skip held artifacts, not cross workspace/environment boundaries, and record audit/OperationRun proof where existing contract requires it.
• FR-406-015: File/database consistency MUST be tested for generated/ready, failed, expired, deleted, missing-file, held, and customer-safe download cases.
• FR-406-016: Lifecycle-sensitive actions MUST write audit proof with actor, workspace, managed environment where applicable, artifact family, safe artifact reference, old state, new state, result, and failure reason where applicable.
• FR-406-017: OperationRun proof MUST remain internal proof unless the existing product contract explicitly allows customer exposure.
• FR-406-018: The implementation MUST NOT add a new navigation entry, panel, artifact portal, export center, legal/eDiscovery product, broad lifecycle framework, new compliance claim, or new report template.
• FR-406-019: The implementation MUST preserve Spec 403 evidence/currentness semantics, Spec 404 PDF runtime gate semantics, Spec 405 JSONB storage semantics, and Spec 267 read-only lifecycle close-out history.
• FR-406-020: A final implementation report MUST include the Governance Artifact Lifecycle Matrix, tests, browser proof, residual findings, gate result, and recommended next step.
• FR-406-021: Before any hold/delete/retention mutation is implemented, the lifecycle matrix MUST classify each in-scope artifact family's hold/delete support as SUPPORTED_NOW, DEFERRED, or PRODUCT_DECISION_REQUIRED; families classified DEFERRED or PRODUCT_DECISION_REQUIRED MUST NOT receive partial runtime behavior inside Spec 406.

Non-Functional Requirements

• Security: Access remains workspace and managed-environment scoped; customer-safe output must not expose internal-only data.
• Reliability: Lifecycle transitions must be transactionally safe where database and file operations interact, and failures must not leave false downloadable states.
• Auditability: Lifecycle actions must produce safe audit metadata with no secrets or raw sensitive payloads.
• Performance: Retention scans must use existing indexes or justified query-backed indexes only.
• Deployment: Any migration, queue, scheduler, storage, config, or env impact must be documented for Sail, staging, and Dokploy production promotion.
• Test governance: Use focused Feature/Filament/Pest/browser coverage; do not create a broad heavy-governance family unless the implementation report justifies it.

User Stories And Acceptance Scenarios

User Story 1 - Operator understands artifact lifecycle and allowed actions (Priority: P1)

As a workspace admin, I need each artifact surface to state whether a retained artifact is current, released, historical, archived, expired, deleted, held, failed, or unavailable so I do not rely on false proof.

Independent Test: Given representative review-pack, stored-report/PDF, evidence, and customer-review artifacts, a permitted operator can identify lifecycle state, file availability, and the one allowed or blocked next action without opening raw diagnostics.

User Story 2 - Destructive lifecycle actions are blocked or audited correctly (Priority: P1)

As an operator or reviewer, I need hold/delete/archive/expire actions to enforce policy, confirmation, hold blocking where the family is classified SUPPORTED_NOW, file consistency, and audit proof so TenantPilot cannot silently destroy retained proof.

Independent Test: For families classified SUPPORTED_NOW for hold, a held artifact cannot be deleted through UI or direct execution; unauthorized and cross-workspace actors are blocked; an allowed delete/archive/expire action records audit proof and does not leave accessible orphan files.

User Story 3 - Customer-safe exports and downloads remain bounded (Priority: P1)

As a customer reviewer, I need released customer-safe artifacts to be downloadable only when valid, released, and safe, while unreleased/internal/deleted/missing-file artifacts stay unavailable.

Independent Test: Customer reviewer can access a released customer-safe artifact, cannot access unreleased/internal artifacts, and cannot download deleted, expired-without-access, failed, or missing-file artifacts.

User Story 4 - Retention behavior is deterministic (Priority: P2)

As a release reviewer, I need retention jobs/actions to expire or archive eligible artifacts deterministically, skip held artifacts where hold is classified SUPPORTED_NOW, and document any product decision gaps before purge/export-before-delete work.

Independent Test: Retention logic marks only eligible artifacts, skips held artifacts for SUPPORTED_NOW hold families, remains idempotent, and records explicit exceptions or missing decisions instead of inventing broad purge behavior.

Edge Cases

• File exists but database state is failed or deleted.
• Database state is generated/ready but file is missing, zero-byte, corrupt, or on a wrong disk.
• Released review/report references older evidence after current evidence changes.
• Held artifact also has deletion requested or is past retention.
• Customer reviewer attempts direct route access to unreleased internal artifact.
• Workspace is suspended/read-only but retained artifacts should remain readable.
• OperationRun failed or cancelled but an artifact was partially generated.
• Retention job fails after updating metadata but before file deletion.
• Existing signed URL is used after artifact state changed.

Data And Truth Source Requirements

• Execution truth: OperationRun status/outcome remains execution proof, not artifact lifecycle truth.
• Artifact truth: ReviewPack, StoredReport, EvidenceSnapshot, and related current artifact owners remain artifact truth sources.
• File truth: private storage existence, size, hash, and disk/path metadata must agree before download.
• Evidence truth: Spec 403 currentness/released proof semantics remain authoritative.
• Customer-safe truth: existing customer-output gates remain authoritative and must be tested for lifecycle paths.
• Retention truth: existing config such as tenantpilot.review_pack.retention_days, tenantpilot.review_pack.hard_delete_grace_days, and tenantpilot.stored_reports.retention_days is reused before new config is considered.

Proportionality Review

• New source of truth?: possibly, only if existing artifact families lack necessary lifecycle metadata.
• New persisted entity/table/artifact?: no generic artifact table approved by default; current-table metadata only where necessary.
• New abstraction?: possibly a bounded lifecycle service/action layer if current family-local code cannot safely coordinate state, file, authorization, and audit.
• New enum/state/reason family?: possibly bounded lifecycle/retention values, but only when each value changes allowed actions, retention behavior, audit responsibility, or customer visibility.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: retained artifacts can become misleading or unsafe when lifecycle action, file, export, and retention behavior are implicit.
• Existing structure is insufficient because: Spec 267 delivered read-only lifecycle truth and explicitly deferred hold/deletion persistence; current retention/file/delete behavior is still family-local and not proven across high-risk artifacts.
• Narrowest correct implementation: matrix-first classification, current artifact owners, family-local metadata where necessary, existing Filament/controller surfaces, and focused tests/browser proof.
• Ownership cost: lifecycle service/actions, audit IDs, targeted tests, possible migrations, scheduler/deploy notes, and final report upkeep.
• Alternative intentionally rejected: generic artifact registry, universal purge engine, broad export center, legal hold/eDiscovery product, and full UI audit.
• Release truth: current-release runtime hardening over already-existing retained artifacts.

Dependencies

• docs/product/spec-candidates.md
• docs/product/roadmap.md
• docs/product/standards/lifecycle-governance.md
• docs/product/standards/product-surface-contract.md
• specs/158-artifact-truth-semantics/
• specs/262-lifecycle-governance-taxonomy/
• specs/267-artifact-lifecycle-retention/
• specs/400-product-contract-spec-completeness-audit/
• specs/403-evidence-anchor-currentness-runtime-closure/
• specs/404-management-report-pdf-staging-validation/
• specs/405-json-to-jsonb-data-layer-hardening/

Assumptions

• Spec 267 read-only lifecycle truth is implemented/historical and will not be rewritten.
• Specs 404 and 405 are predecessor proof lineage with PASS WITH CONDITIONS, not unconditional production/staging readiness. The Spec 406 implementation report must state whether each remaining Staging/Dokploy condition affects the touched artifact family, download path, storage path, runtime path, or deployment claim.
• Review packs and stored reports remain the primary generated-file artifact families in this slice.
• Customer-facing download/export behavior must reuse existing customer-output gates.
• No live production data requires compatibility shims unless implementation discovers and documents an explicit exception.
• Actual retention values remain configurable product settings, not legal compliance claims.

Risks

• Hold/delete behavior may require migrations on multiple existing artifact tables.
• Retention cleanup can create file/database drift if not transactionally and operationally tested.
• Customer-safe export/download behavior can leak internal evidence if raw proof layers are not demoted.
• A broad purge/export-before-delete workflow may be discovered but must be split rather than hidden in this slice.
• Browser proof may require representative fixtures for multiple artifact families.

Open Questions

• Which artifact families should support actual deletion in Spec 406 versus archive/expire-only behavior?
• Do customer reviewers retain access to expired released artifacts, or should expired access always be blocked unless a specific existing contract permits it?
• Does any artifact family require true hold persistence now, or is hold limited to review packs/stored reports until a later purge/export-before-delete spec?

These are implementation-time product decisions. They do not block preparation or inventory because the tasks require matrix classification and explicit SUPPORTED_NOW, DEFERRED, or PRODUCT_DECISION_REQUIRED rows before runtime mutation. They do block runtime mutation for affected families until the classification is recorded.

Success Criteria

• SC-406-001: Every in-scope artifact family has a lifecycle matrix row with status, risk, test proof, browser proof, and follow-up.
• SC-406-002: For every artifact family classified SUPPORTED_NOW for hold, held artifacts cannot be deleted by UI, direct action, or retention cleanup; any high-risk family left DEFERRED or PRODUCT_DECISION_REQUIRED is reported and prevents a stronger result than PASS WITH CONDITIONS.
• SC-406-003: Deleted, failed, expired-without-access, or missing-file artifacts cannot be downloaded as valid proof.
• SC-406-004: Customer-safe downloads/exports are proven not to expose internal-only proof.
• SC-406-005: Authorization and cross-workspace/cross-environment denial are tested for lifecycle-sensitive actions.
• SC-406-006: Audit proof exists for lifecycle actions according to existing TenantPilot conventions.
• SC-406-007: Focused browser proof passes for representative existing rendered surfaces.
• SC-406-008: Final gate result is PASS, PASS WITH CONDITIONS, or FAIL according to remaining P0/P1 lifecycle risk.

Follow-up Spec Candidates

• Retention & Purge Governance v1 for irreversible purge, purge scheduling, purge proof, and export-before-delete preconditions.
• Data Export Before Deletion v1 for customer-owned export bundles and completion proof.
• Workspace & Tenant Closure Lifecycle v1 for broader workspace/managed-environment closure behavior.
• External/customer artifact portal only if a later product decision requires a new consumption surface.
• Full Browser/UX Runtime Audit after Spec 406 returns PASS or acceptable PASS WITH CONDITIONS.

Implementation Report Requirement

The implementation loop must create specs/406-governance-artifact-lifecycle-retention/implementation-report.md with:

• Candidate gate result.
• Dirty state before/after.
• Governance Artifact Lifecycle Matrix.
• Spec 404/405 condition carry-forward assessment.
• Per-family hold/delete support classification.
• Runtime changes and migrations.
• Lifecycle rules implemented.
• Tests and browser proof.
• Authorization/customer-safe proof.
• File/database consistency proof.
• Retention/hold/delete proof.
• Remaining P0/P1/P2/P3 findings.
• Deferred items.
• Validation commands.
• Recommended next step.