reactivateInactive motivo has no persistence other than the truncated archive-reason slice
Third DDL leg found while clearing PLUTO-767, and it is distinct from the accessRequests column. src/lib/admin-actions.ts:1010 interpolates trimmed.slice(0,200) of the operator motivo into the archive reason admin:user:reactivateInactive, and its UPDATE sets only users.isActive and updatedAt - no reason column is written. users.deleteReason is NOT the destination: reactivate at admin-actions.ts:1237 deliberately NULLs deletedBy/deleteReason so a restored row never carries a stale actor/reason, so writing a reactivation motivo there would be wrong and would be nulled by the next path anyway. So the 200-char slice is currently the ONLY persistence of that datum anywhere, exactly like support-admin-access-core.ts:151 was. PLUTO-767 therefore HOLDS this site interpolating until a real destination exists - per pmmaster's ordering constraint, bad evidence beats none while it is the only copy. Needs a db-lane decision on the destination (a column on users, or a row in an existing operator-action store) before the coder side can drop the interpolation. Field holds operator free text about a person: PII at rest, name it for what it is, expect the archive trigger to snapshot it into rowBefore/rowAfter.
Activity
-
db-pluto-ca / db
-
Explicit exact-byte apply GO received for migration 132 SHA-256 6fbb1f287151c0d5d40b13ad2aeb1ac1f7bdbdad99b8c6a7408d71f0bc7ebda6. Immediate hash/read matched. Supabase MCP apply_migration denied permission; available direct DSN authenticates as coder_pluto_cc_ro, unable to ALTER postgres-owned public.users. No DDL ran. PM asked for an approved privileged apply route; approved bytes remain unchanged.
-
ELAZAR-GATED: no write-capable DB seat exists for pluto. Apply GO is live on 6fbb1f287151c0d5d40b13ad2aeb1ac1f7bdbdad99b8c6a7408d71f0bc7ebda6 with audit-general-ca source PASS and a clean read-only preflight - the file and the authority are ready and only capability is missing. Measured 2026-10-06, both probes under the agents' own named roles, no credential borrowed: db-pluto-ca's Supabase MCP apply_migration returned 'You do not have permission to perform this action' with no DDL run, and its only DSN authenticates as coder_pluto_cc_ro which cannot ALTER postgres-owned public.users; support-evolutiva-cc, holding the standing cross-project mandate, got 'must be owner of table users' on BEGIN/ALTER/ROLLBACK under support_evolutiva_cc_ro with a clean residue check. Same pattern as Mars after db-mars-cc's retirement: a read-only seat and no provisioned writer. Needs Elazar to provision a pluto write role or apply it himself. Do not reassign this around the lanes - three seats have now been measured incapable, not unwilling.
-
support-evolutiva-cc DDL capability probe, own named role support_evolutiva_cc_ro: BEGIN; ALTER TABLE public.users ADD COLUMN probe_only_drop_me text; ROLLBACK -> ERROR: must be owner of table users. Residue check immediately after: to_regclass('public.users') = users, 0 columns named probe_only_drop_me. Nothing created, nothing left behind, no credential borrowed. So support-evolutiva-cc is NOT an apply route for this row: pluto has no write-capable DB seat and is Elazar-gated for DDL, the same shape as Mars after db-mars-cc's retirement. The apply GO on 6fbb1f28 is blocked on capability, not authority.
-
Support-evolutiva-cc independently probed under its own support_evolutiva_cc_ro role (hub tag support-evolutiva-cc-muwoxfkn19bn-db-pluto-ca): registry SELECT denied for schema supabase_migrations; rolled-back ALTER TABLE public.users ADD COLUMN probe_only_drop_me denied 'must be owner of table users'; residue column count 0. db-pluto-ca named credential file absent and Supabase MCP apply_migration denied. Thus no available named DB seat can apply exact approved SHA-256 6fbb1f287151c0d5d40b13ad2aeb1ac1f7bdbdad99b8c6a7408d71f0bc7ebda6; no DDL ran. PM owns Elazar escalation; exact-byte GO remains live pending capability.