mars
MARS-107
Mars appEvents conform to fleet standard (evolutiva-appevents-standard.md): add categoryId uuid FK->lookupOptions + seed appEventCategory group (16 canonical + practica/studentAssignment/assignment) + backfill 18 free-text values w/ mapping; add 4 promoted cols (httpStatus/durationMs/path/failureCode); add logError/logWarn/logInfo wrappers + pickKnown + isCritical sync-bypass; append-only trigger (GUC-bypass) AFTER appEventRelays sidecar cutover (replace detail.relay.delivered UPDATE pattern); replace level-only prune with 5-cat-security tiered retention; canonical v_appEvents_* views; legacy_events sink. Staged db+coder. BLOCKED on committed SSOT + Elazar priority call.
Blocked normal
dmdb03-mars-ca
⛔ Blocker CORRECTED by pmmaster-evolutiva-cc 2026-10-06 - the stated gate was wrong in one half and mine in the other, and the real one is neither. (1) 'Committed SSOT' is SATISFIED: shared/md/evolutiva-appevents-standard.md exists, 46846 bytes, git-tracked in the canonical shared tree since 2026-07-30. That half of the block has been clear for over two months. (2) 'Elazar priority call' was never Elazar's - prioritising backlog is mine, and I am setting it rather than holding the row for him. (3) THE ACTUAL BLOCKER, which neither half named: this row is Class-A DDL on Mars, and Mars has NO WRITE-CAPABLE DB SEAT. db-mars-cc is retired; db-mars-ca and db03-mars-ca are read-only. So no agent can apply the migration regardless of priority or SSOT, and that is an Elazar decision about provisioning a seat, not about this row's merit. It is the same blocker as MARS-776, migration 183 and the bundle EXPLAIN read, and it should be escalated ONCE for all of them rather than per row. Lesson for the next triage: a block naming two gates can have both wrong and still read as rigorous - the test is whether clearing BOTH stated gates would let someone start work. Here it would not.
Activity
-
Fleet rulings from venus appEvents analysis (Elazar, 2026-06-13) to honor in conform: (a) 404 is a DEFECT — level at warn/error, never info 'expected churn' (the old Mars convention venus inherited); surface each. Mars has NO middleware.ts so server-side 404 capture is likely incomplete → track a request-instrumentation gap. (b) viewport/client-env telemetry = ONE event per session + skip bot UAs (venus had 60/89 events as viewport spam, burns egress). Mars recent-window scan showed zero viewport events — confirm Mars doesn't fire/capture it; add the 1/session+skip-bots rule regardless. Both also belong in the appevents-standard SSOT text.
-
Fleet rulings from venus appEvents analysis (Elazar 2026-06-13) for conform: (a) 404 is a DEFECT - level at warn/error never info 'expected churn'; surface each. Mars has NO middleware.ts so server-side 404 capture likely incomplete -> track request-instrumentation gap. (b) viewport/client-env telemetry = ONE event per session + skip bot UAs (venus had 60/89 viewport spam, burns egress). Mars recent scan showed zero viewport events - confirm Mars doesn't fire/capture; add 1/session+skip-bots rule regardless. Both belong in appevents-standard SSOT text.
-
TRIGGER ERRATUM (pm-venus 2026-07-03, found in VENUS-4 backfill): the appEvents append-only immutability trigger (SSOT §5.1) uses RETURN OLD on a BEFORE UPDATE OR DELETE trigger. In a BEFORE-UPDATE trigger RETURN OLD writes the UNCHANGED row, so any GUC-bypassed correction/backfill UPDATE (this WI's categoryId backfill + re-level of 18 free-text values) silently NO-OPS — reports 'UPDATE N' success but changes nothing. Only DELETE (retention) exercises the path, so it was never noticed. WHEN BUILDING THIS WI: do NOT trust the UPDATE rowcount — verify every bypassed UPDATE with a read-back. General fix = fn body 'IF TG_OP=''DELETE'' THEN RETURN OLD ELSE RETURN NEW', but that's a semantics change to the ratified trigger → needs a fleet decision + SSOT §5.1 erratum before applying. Venus workaround (one-time backfill): drop+recreate the trigger byte-identical inside the migration txn (ACCESS EXCLUSIVE lock covers the gap). Mars has NOT yet run any bypassed appEvents UPDATE (this WI still backlog), so no data was silently dropped.
-
TRIGGER ERRATUM (pm-venus 2026-07-03, VENUS-4): appEvents append-only trigger (SSOT 5.1) uses RETURN OLD on a BEFORE UPDATE OR DELETE trigger. In BEFORE-UPDATE, RETURN OLD writes the UNCHANGED row, so any GUC-bypassed backfill/correction UPDATE (this WI's categoryId backfill + re-level of 18 free-text values) silently NO-OPS: reports UPDATE N success but changes nothing. Only DELETE (retention) exercises it, so never noticed. WHEN BUILDING: do NOT trust the UPDATE rowcount, verify every bypassed UPDATE with a read-back. General fix = IF TG_OP=DELETE THEN RETURN OLD ELSE RETURN NEW, but that is a semantics change to the ratified trigger -> needs fleet decision + SSOT 5.1 erratum first. Venus one-time workaround: drop+recreate trigger byte-identical inside the migration txn (ACCESS EXCLUSIVE lock covers the gap). Mars has NOT yet run any bypassed appEvents UPDATE (WI still backlog), no data silently dropped.
-
db-mars-cc
-
Status was backlog while the description said BLOCKED - the false-not-blocked state, corrected by pmmaster-evolutiva-cc 2026-09-11. Backlog reads as available to pick up and this is not. Real gates, both named in the description: a COMMITTED fleet appEvents SSOT (evolutiva-appevents-standard.md), and a priority call that is Elazar's because this is a large migration on a live table with no user-visible symptom today. PLUTO-73 and PLUTO-533 are the same campaign and are also held. Do not start the migration. What IS available inside this row and does not need either gate: nothing - every part of it writes schema. If you want progress on this family, the useful move is to get the SSOT committed, which is EVO-work and not mars-work.
-
db03-mars-ca
-
Blocker CORRECTED by pmmaster-evolutiva-cc 2026-10-06 - the stated gate was wrong in one half and mine in the other, and the real one is neither. (1) 'Committed SSOT' is SATISFIED: shared/md/evolutiva-appevents-standard.md exists, 46846 bytes, git-tracked in the canonical shared tree since 2026-07-30. That half of the block has been clear for over two months. (2) 'Elazar priority call' was never Elazar's - prioritising backlog is mine, and I am setting it rather than holding the row for him. (3) THE ACTUAL BLOCKER, which neither half named: this row is Class-A DDL on Mars, and Mars has NO WRITE-CAPABLE DB SEAT. db-mars-cc is retired; db-mars-ca and db03-mars-ca are read-only. So no agent can apply the migration regardless of priority or SSOT, and that is an Elazar decision about provisioning a seat, not about this row's merit. It is the same blocker as MARS-776, migration 183 and the bundle EXPLAIN read, and it should be escalated ONCE for all of them rather than per row. Lesson for the next triage: a block naming two gates can have both wrong and still read as rigorous - the test is whether clearing BOTH stated gates would let someone start work. Here it would not.
task
2026-06-13 by wi-cli-venus
1w ago