conform appEvents to fleet SSOT (categoryId FK, promoted cols, append-only+GUC, appEventRelays sidecar, retention guard, logger, views)

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-13
• wi-cli-venus note · 2026-06-13
  Pluto-adapted conform plan (db-pluto-cc cell-verified vs fleet SSOT appevents-standard-v1). Step0: seed 4 missing canonical cats (client,admin,data,report) in lookupOptions appEventCategory. Step1: ADD COLUMN httpStatus int, durationMs int, path text, failureCode text. Step2: ADD categoryId uuid + backfill via lookupOptions match on NOMBRE (NOT valor - Pluto cols are grupo/campo/nombre); Step2b hand-crafted action-based backfill for ~700 category='' rows (serverError/clientError:*->system, require*Denied/accessDenied->authz, sendAdminEmail/email-sent->email, kpiCronReport/pollSecurityAlerts->cron, importExcel*->system +level fix error->info, practicaCreateFailed/estadoRevisionChangeFailed->system); then FK constraint. Pluto likely needs NO legacy_events sink (all action-mappable). Step4+5 ATOMIC/ordered: appEventRelays sidecar + migrate PLUTO-64 ux-relay (and any error-relay) OFF appEvents.detail.relay BEFORE/with the append-only trigger, else relay UPDATEs RAISE. Step7 retention: add auth+session to security guard (currently only authz/malicious/user -> Pluto under-retains auth/session security events TODAY) + add SET app.bypass_immutable=true in the prune DO-block. Step8 logger: Pluto already has wrappers+pickKnown+isCritical; align isCritical (drop warn? add malicious?) per ratified spec. Step9: fix severity misclass (auth-guard 4 *ForActionDenied error->authz per PLUTO-72; importExcel* error->info). Step10: rename 3 views to v_appEvents_* canonical + add missing (friction/404/misleveled/security). BLOCKED on: (a) SSOT ratified+committed to shared/md, (b) Elazar priority call (does logging program preempt PLUTO-69 P0 lockout + other open bugs). Large db+coder effort - stage into auditable sub-steps when unblocked.
• wi-cli-venus blocked · 2026-06-13
  Blocked on fleet appEvents SSOT ratification+commit to shared/md, and Elazar's priority call (logging program vs PLUTO-69 P0 lockout + open bugs). Pluto voted PASS-with-corrections on the draft.
• wi-cli-venus note · 2026-06-13
  Retention guard-widening applied EARLY (out-of-band, strictly-safe stop-the-loss): db-pluto patched pg_cron jobid=3 security guard authz/malicious/user -> auth/authz/session/malicious/user (all 3 clauses), verified read-back clean. So conform Step7's guard-fix is DONE; only the GUC-bypass remains (at trigger-add time). Commons-sync pending: pluto-commons §Logging still documents security set as authz/malicious/user -> must update to the 5-set in bin-whey's SSOT paired commit (alongside evolutiva-commons).
• wi-cli-venus assigned · 2026-07-15
  db-pluto-cc
• wi-cli-venus commented · 2026-07-15
  Likely superseded by PLUTO-533 (fleet appEvents schema standardization, mirror MARS-411, inProgress) - same scope (categoryId FK, promoted cols, append-only+GUC, retention guard, views). db-pluto-cc: confirm merge into 533 or cancel-as-duplicate once 533's design-hold resolves.
• wi-cli-venus commented · 2026-07-15
  Cross-fleet note (pm-venus-cc, 2026-07-15): the old spec assumption 'pluto owns the UUID normalizedRoute regex' was wrong - not-found-classify.ts has no lax-any-hex normalizer, only a strict RFC4122 validator for a different purpose. Venus is authoring the reference regex (lax any-hex segment->:uuid, numeric->:n) to unblock VENUS-82. When this WI builds normalizedRoute, conform to venus's exact regex text for cross-app errscan token consistency - don't re-derive independently.
• wi-cli-venus unblocked · 5w ago
• wi-cli-venus canceled · 5w ago
  CANCELLED AS DUPLICATE OF PLUTO-533 (pmmaster-evolutiva-cc ruling 2026-09-11, on the stated pre-condition, which was checked FIRST and FAILED). The pre-condition was: confirm 533's body already carries 73's seven-item enumeration; cancel only if it does. It did NOT - 533's description covers the fleet column contract (hot scalar promotion, jsonb-only-for-irregular, the no-wrappers logger collapse) plus the feedbackMechanism column, and carried none of items 1 (categoryId FK), 3 (append-only + GUC bypass), 4 (appEventRelays sidecar), 5 (retention guard) or 10 (canonical v_appEvents_* views). So per the ruling's own second branch, the full enumeration AND the Pluto-adapted Step0-Step10 conform plan were copied onto PLUTO-533 FIRST (commented there 2026-09-11, before this cancel), including the two cross-fleet constraints that ride with the scope: Venus owns the lax normalizedRoute regex (VENUS-82) and Pluto must conform to its exact text rather than re-derive one, and the pluto-commons Logging security-set sync to the 5-set in bin-whey's paired SSOT commit. Also carried over: Step7's guard-widening half is already DONE out-of-band on pg_cron jobid=3 (authz/malicious/user -> auth/authz/session/malicious/user, read-back verified), so only the app.bypass_immutable GUC in the prune DO-block remains of that step. Nothing is lost by this cancel. The blocker is INHERITED by 533 unchanged and is not cleared: fleet appEvents SSOT ratification + commit to shared/md, plus Elazar's priority call. Nothing Pluto-side holds either row - this cancel removes a duplicate, it does not unblock the work.