carlos / platform Public

| Earlier finding | Disposition at 387d469d | |---|---| | R4.1 — Recovery bypasses empty-bucket safeguard | Fixed: §2 applies the tripwire to absence-based finalization. | | R4.2 — Trash UI/API promises 30 days | Fixed: §5 specifies one effective deadline. | | R5.1 — Route-only permanent service can become temporary | Fixed for the reported paths: namespace enforcement precedes the fleet scan and feature enablement. | | R5.2 — Expiry markers defeat the tripwire | Fixed: markers do not establish nonempty-bucket evidence. | | R6.1 — Local inventory misses remote routes | Fixed: §3 requires fleet-wide enforcement and inspection before enablement. | | R6.2 — Reconciliation can reassign permanent routes | Fixed for the reported counterexample: its permanent tmp- route cannot be introduced through the covered writers. | | R7.1 — Older writers invalidate the rollout scan | Fixed within the stated scope: every box must be upgraded first; deliberately invoking retained old binaries is explicitly excluded. | | R7.2 — Grant/backfill bypasses reservation | Fixed: grant refuses reserved names; backfill skips them; rollout checks both tables. | | R7.3 — Interrupted last-app purge cannot retry | Fixed: matching-marker purge retries remain allowed when the tripwire trips. | | R7.4 — Direct delete overpromises recovery | Not fixed completely: the replacement wording still overpromises on retries; finding 2 below. |

1. P2 — §§2, 5: a failed manual-trash row update can postpone recovery past the three-day deadline.

Manually trash a temporary app whose expiry is still 30 days away. The marker write succeeds, but the row update fails. This is an explicitly handled failure in the existing API: the marker is written at apicli.go:1247, and a failed row update returns without repairing the row at apicli.go:1279.

Neither §5 candidate query selects this app: its expiry is in the future, and its row still has deleted_at = 0 and purge_after = 0. Consequently, settleApp never runs for it during those passes. Startup materialization can repair the row (materialize.go:367), but without a restart or another operation on the app, the three-day deadline passes unnoticed.

Fix: periodically settle temporary rows before filtering expiry/purge candidates, or persist recoverable trash intent before writing the marker. Test manual trash with a future TTL, failure of the final row update, and recovery/purge after three days without a restart or user request.

1. P2 — §§5, 7: direct-mode deletion still promises extra recovery time when retried.

The new sentence promises “restorable for at least 3 days.” However, TrashApp preserves an existing marker and its original timestamp (trash.go:50). headlessTrash already re-reads that marker precisely to avoid restarting the displayed clock (apps.go:298).

Retry direct-mode deletion two days after a temporary app was trashed. The proposed output promises at least three more days, while its specified purge deadline is only one day away. A retry after the deadline can print the same assurance immediately before purge.

Fix: report that the authoritative deadline is unavailable without the console, or express the possible deadlines relative to the original tombstone timestamp, explicitly handling elapsed deadlines. Test retries before and after the three-day deadline.

Verdict: revise.