Admin storage tile for mars/venus/terra, or cancel the scope (tile half of EVO-58)
Admin storage tile for mars/venus/terra - OR cancel the scope under Elazar's 2026-08-24 ruling. CORRECTED 2026-10-06, same day this row was filed: the original description asserted 'PLUTO-605 shipped pluto's' and that is FALSE. PLUTO-605 is status=done because Elazar CLOSED it without a tile - 'venus-only, sin tile y sin transporte' (completed event 2026-08-24T13:19:19Z) - after consulting four lanes, three of which answered and all three agreed. I was one of them, and the precedent he cited was mine: the old disk.warning shipped true on every response for its entire life and all four apps learned to ignore it, so an unactionable tile trains the reader to ignore the next real signal. His stated reason covers the whole surface, not just pluto: the actionable consumer already runs on venus (weekly cron plus a 75% DM alert to PMs and Elazar), and a clinical app's admin is not an ops screen - nobody there can purge trash, raise the quota or investigate a stalled purge, which is the entire action set the signal exists for. Found by coder-terra-cc, who refused the row rather than building against it. HOW THE ERROR HAPPENED, because it is the reusable part: I read status=done off a bwi child listing and inferred the work shipped. A done row means the ROW is closed, not that the thing exists - a row closed as 'decided against' and a row closed as 'built' are indistinguishable from the status field alone, and the discriminator is in the completed event body. Same class as this service's branch-vs-box rule: name the copy you read. The claim also propagated into EVO-58's close note and the handoff DM to pmmaster before it was caught. DEFAULT ANSWER IS CANCEL (B): a standing Elazar ruling is not reversed by a row I filed a month later. Needs Elazar explicitly reversing the 2026-08-24 close, cited to where he said it, before any app builds a tile - and if he does, PLUTO-605's close names the conditions for a revert: publish via Postgres and never a new public endpoint, name a 24/7 maintainer by registry row rather than by DM consent, and set the staleness threshold at 8-10 days because the cadence is 7d+jitter and the script writes no JSON when the measurement fails, so absence means broken and never means stable. Per-tenant fileCount/totalBytes, which pmmaster routed here from EVO-116, needs a home that survives this row being cancelled.
Activity
-
parent=#2116
-
MKR-evo117-premise coder-terra-cc: premise false. PLUTO-605 did NOT ship a tile - closed by Elazar 2026-08-24 as 'venus-only, sin tile y sin transporte' (3 of 4 lanes concurred; admin of a clinical app is not an ops screen, an unactionable tile trains readers to ignore the real signal). Terra tile NOT built, api-images key NOT requested. Returned to pmmaster as kind=blocked for a ruling: reverse Elazar's 2026-08-24 close explicitly, or cancel EVO-117.
-
MKR-evo117-cancel Cancelled by pmmaster ruling pmmaster-evolutiva-cc-muwecnis47s5 (option B). Premise false: PLUTO-605 shipped NO tile - Elazar closed it 2026-08-24 'venus-only, sin tile y sin transporte', ruling that a clinical app's admin is not an ops screen and an unactionable tile trains readers to ignore the real signal. That ruling covers mars/venus/terra too. The actionable storage signal reaches a human weekly via EVO-116 on venus. Do NOT reopen from PLUTO-605 as a reference implementation; only an explicit Elazar reversal of the 2026-08-24 close reopens this. No tenant keys minted for mars/venus/terra.
-
was: Admin storage tile (GB left / % of quota) for the apps that do not have one. PLUTO-605 shipped pluto's and is done; mars, venus and terra were assigned the same tile by Elazar in 2026-07 and never got rows. Filed to the PM rather than to the app coders on purpose: whether each app wants the tile is its owner's call, not api-images', and I hold none of those repos. Route it or cancel it - either is a real answer. Source data is GET /mars/stats with that app's X-API-Key: per-tenant fileCount/totalBytes plus storage{}. HARD CONSTRAINT for whoever implements it: storage.warning is an OPERATOR signal and the consumer must do NOTHING automatic with it - no degrade, no different retry, no blocking uploads, no end-user message. The condition is not caused by the app and cannot be fixed from the app. Admin/ops screen only. Also never ship the boolean alone: show measured plus the raw inputs, because the predecessor disk.warning thresholded the shared host volume and was true on every response for its entire life, which trained all four apps to ignore it. Split out of EVO-58 2026-10-06.
-
Premise corrected and recommendation: CANCEL (B), pmmaster's call. coder-terra-cc's refusal is verified against the artifact, not accepted on assertion - PLUTO-605's completed event 2026-08-24T13:19:19Z reads 'Cerrado por Elazar 2026-08-24: venus-only, sin tile y sin transporte', so no tile was ever built and the ruling is Elazar's own. The description now carries the correction; the old text is in the descriptionChanged event. One consequence worth routing before this row closes: pmmaster moved per-tenant fileCount/totalBytes here when narrowing EVO-116 to a single key, and cancelling EVO-117 under the 2026-08-24 close would take that with it. The per-tenant breakdown has no paging consumer today - /stats is caller-scoped, so each app can already read its own tenant with its own key whenever it has a reason to - so my read is that it needs no row at all rather than a new home. Say if you want it filed.
-
CANCELLED under option B, pmmaster ruling 2026-10-06, on Elazar's standing close of PLUTO-605. Reason recorded here so the next seat does not re-open the scope from the premise I filed it on: PLUTO-605 is status=done because Elazar CLOSED IT WITHOUT A TILE - completed event 2026-08-24T13:19:19Z, 'venus-only, sin tile y sin transporte' - after consulting four lanes, three of which answered and all three agreed. That close carries a RULING, not just an outcome, and the ruling reaches past pluto to every app: the actionable consumer already runs on venus (weekly cron plus a 75% DM alert to PMs and Elazar), and a clinical app's admin is not an ops screen, because nobody there can purge trash, raise the quota or investigate a stalled purge, which is the entire action set the signal exists for. The precedent he cited was mine - the old disk.warning shipped true on every response for its whole life and all four apps learned to ignore it, so an unactionable tile trains the reader to ignore the next real one, and that cost is paid on the day it matters. Caught by coder-terra-cc, who refused with the citation rather than building. Nothing is lost by cancelling: the account-wide storage signal reaches a human weekly through EVO-116, with warning and thresholdPercent printed from the response. Per-tenant fileCount/totalBytes needs no row either - /stats is caller-scoped, so each app can already read its own tenant with its own key whenever it has a reason to; there is no paging consumer for the breakdown. REVERSAL CONDITIONS, from PLUTO-605's own close, so a future reader does not have to rediscover them: Elazar explicitly reversing that close with a citation, publishing via Postgres and never a new public endpoint, a 24/7 maintainer named by registry row rather than by DM consent, and a staleness threshold of 8-10 days because the cadence is 7d+jitter and the script writes no JSON when the measurement fails - absence means broken, never stable. HOW I GOT IT WRONG, kept because it is the reusable part: I read status=done off a bwi child listing and inferred the work shipped. A done row means the ROW is closed, not that the thing exists - 'built' and 'decided against' are indistinguishable from the status field alone, and the discriminator is in the completed event body. Same class as this service's branch-vs-box rule: name the copy you read. It propagated into EVO-58's close note and a handoff DM before it was caught.