amadan
everywhere-class rows with operator-touched Backing/Tunnel/Caps survive record deletion on far boxes Feature Request open
Migrated from github.com/carlosframework/platform issue #250, opened 2026-08-22. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: Far-box everywhere-class survivors with operator-touched fields have no visibility surface and no cleanup verb.
---
From the multi-region backhaul branch (plan 2, Task 5). The serving-class change adopts static/public-addr routes on every platform box, and removal deliberately keeps the conservative grant-purge doctrine: a row with non-default Backing/Tunnel/Caps is never auto-removed. Composition consequence, measured during review: mint an everywhere-class record, touch a FAR box's copy with an operator verb, delete the record — the home box deletes its row, the far box keeps its copy Provisioned, grants intact, still serving the retired site; carlos remove stops being fleet-wide the moment anyone touches a far copy.
Accurate reproduction (per re-review): -grant/-backing cannot target a static row (CLI rails refuse non-instance kinds) — the reachable shapes are (a) a public-addr instance route given -backing unit then -grant on a far box, or (b) any everywhere-class row, static included, touched with -tunnel (no kind restriction).
The conservative gate is correct (human-gated grant purge is standing doctrine). The ask is visibility + a no-infra cleanup path: surface far-box survivors in the console/CLI (a route whose record is gone), and provide a member-or-operator verb to retire them without a box command — per the CLI no-infra rule. Belongs with the multi-region rollout bookkeeping (arming a second region is when this becomes reachable).