P0: practica create/edit with antecedentes raises since venus88 (fn_antecedentes_confirm_catalog casts object elements to integer)

Sub-tickets

Activity

• coder-venus-cc created · 1w ago
• coder-venus-cc progress · 1w ago
  audit-general-ca BLOCK on 65dfbe786328 (int casts accept 1.5/1e40/overlong digits; postflight did not exercise). Revised to sha256 3fddd85f2588: cast-free text compare; postflight rollback-scoped real-data exercise. Harness: prior draft RED on 3 fixtures; 3 postflight mutants RED; real GREEN, no residue. Re-asked apply-GO.
• coder-venus-cc progress · 1w ago
  venus91 APPLIED by db-venus-cc at sha256 3fddd85f2588 (audit-general-ca GO). Independent readback: live prosrc has the text compare and no (elem)::integer; trigger enabled O; unconfirmed=15 unchanged. Committing applied/ venus88+90+91 records.
• coder-venus-cc completed · 1w ago
  FIXED. venus91 applied by db-venus-cc at sha256 3fddd85f2588 (audit-general-ca GO after BLOCK on 65dfbe786328). Record commit 182a96f (applied/ venus88+90+91, Authored-By db-venus-cc); app version unchanged 1.17.36 (sql-only). Independent readback: live prosrc text-compare, no (elem)::integer; trigger enabled; unconfirmed=15. IMPACT: 0 appEvents 'invalid input syntax for type integer' and 0 practicas created in the last 6h, so no observed user hit. Window: venus88 apply until venus91 apply. NOT EXERCISED: a live práctica create through the app.
• pmmaster-evolutiva-cc blocked · 1w ago
  Elazar-only storage-shape decision on his own 2026-06-14 no-encryption GO; three options stated on the row, recommendation (c). No agent action, no rotation, until he picks.
• pmmaster-evolutiva-cc unblocked · 1w ago
  CORRECTION by pmmaster-evolutiva-cc 2026-10-06: the block I placed on this row seconds ago was MINE AND WRONG, and it is withdrawn in full. The reason text I attached - an Elazar storage-shape decision about the venus-state-backup gdrive leg - belongs to VENUS-450 and has nothing to do with this row. I typed 446 while reading 450 off the create output. Nothing about this P0 is blocked by it and no decision of Elazar's gates it. How it happened, because the mechanism matters more than the slip: I issued the block in the same command as the add that minted the new row, so I wrote the reference from memory instead of from the add's output. A create and a mutation on the created row do not belong in one batch - the ref does not exist until the create returns, so batching them means the mutation is addressed from a guess. The cost here was blocking an unrelated P0 with a false reason, which is the most expensive single thing a triage pass can do: a P0 blocked for a reason nobody can act on stops being triaged by anyone, and the reason reads as authoritative because it is specific. This row is OPEN and is a P0. Nothing on it changed except that it briefly carried someone else's blocker.
• pmmaster-evolutiva-cc completed · 1w ago
  RE-CLOSED by pmmaster-evolutiva-cc 2026-10-06, restoring the state my own mis-addressed block destroyed. This row was ALREADY CLOSED at 06:06:55Z by coder-venus-cc with a real completion record; my block at 06:11:54 reopened it to todo, and my unblock at 06:12:13 left it todo rather than closed. So the slip cost two things, not one: an unrelated P0 briefly carried someone else's blocker, AND a finished row was returned to the open queue where the next sweep would have re-dispatched completed work. THE CLOSURE EVIDENCE IS NOT MINE AND IS PRESERVED UNCHANGED, from coder-venus-cc's completed event: fn_antecedentes_confirm_catalog rewritten to read parentId and childIds from the stored object shape instead of casting jsonb array elements to integer; venus91 applied by db-venus-cc at sha256 3fddd85f2588 after audit-general-ca GO, which had BLOCKed the prior 65dfbe786328; record commit 182a96f carrying applied/ venus88+90+91 with Authored-By db-venus-cc; app version unchanged at 1.17.36 because the change is SQL only; independent readback confirmed live prosrc has the text compare and no (elem)::integer, trigger enabled, unconfirmed count 15 unchanged. I am not re-asserting that verdict, only restoring the status it earned. The lanes did this one right: a latent cast bug made live by venus88's sentinel inserts, caught the same night, replayed read-only against prod to confirm the error before touching anything, fixed in the db lane, BLOCKed once by audit and re-submitted, and verified by an independent readback of the live function body rather than by the migration having run. PROCESS, mine: a status mutation addressed from memory can do more than mislabel a row - it can silently revive a closed one, and a reopened closed row is invisible as an error because it looks exactly like ordinary open work. Read the ref off the output that created it, and after any mis-addressed mutation check the TARGET's prior status rather than assuming the inverse operation restores it: unblock does not mean re-close.