LIFE-WSF-001 — Operate trash and object retention end to end
| Field | Value |
|---|---|
| Status | Open; deployment-confirmed and source-verified |
| Severity | High |
| Components | sparqd/workspace-file-management-backend, sparqd/platform-stacks, S3/OSS, Oqullus |
| Associated issues | Not opened |
Concrete observed case
The backend contains a cleanup command with a default 30-day cutoff, but KCL
does not deploy it. The live namespace had no workspace cleanup CronJob on
4 September 2026. Trash displays original creation time, not deletion time or
expiry. Restore destination and conflict behavior are tracked separately in
UX-WSF-003.
Object deletion calls one current-key delete. On a versioned bucket that can leave historical versions or a delete marker, so Delete Forever is not by itself proof of physical erasure.
Expected condition
One reviewed policy defines trash duration, version duration, legal exceptions, and physical deletion. Scheduled cleanup is observable and retryable; UI shows deletion and expiry time and resolves restore conflicts explicitly.
Why it matters
Trash can grow without bound, users cannot predict recovery time, and a permanent-delete claim may conflict with retained historical bytes.
Existing controls and workarounds
Users can manually delete individual Trash items. Operators can run the cleanup command manually, but no scheduled or monitored execution is configured.
Alternatives considered
- Recommended: deploy an idempotent cleanup controller and provider lifecycle rules, with explicit all-version deletion where required.
- Object-store lifecycle only — cannot safely delete metadata or express all application restore rules.
- Manual cleanup — rejected for reliability and compliance.
Component involvement
- Platform stacks deploys and observes cleanup plus provider lifecycle policy.
- The backend makes cleanup idempotent and deletes the intended object versions.
- Oqullus shows deletion time, expiry, and explicit conflict resolution.
Reproduction and verification
Follow WSF-S008.
Resolution conditions
Close when time-controlled tests prove visible retention, conflict-safe restore, scheduled cleanup, all-version disposition, failure recovery, and audit records.
Validation and blockers
Missing scheduling and UI fields are confirmed. Retention, legal hold, and physical-erasure policy decisions remain open.