pluto PLUTO-190

Harden intentional info-level appEvents streams against LOG_LEVEL changes (generalizes PLUTO-182's forceSync pattern). Today these persist ONLY because prod LOG_LEVEL=3 disables the logger.ts:98 info-drop gate — none pass forceSync, so lowering LOG_LEVEL (e.g. someone treating 3 as debug noise) would SILENTLY kill the email audit trail + telemetry. Promote to forceSync:true at the call sites so they're LOG_LEVEL-independent: email/email-sent + email/sendAdminEmail (audit trail), client-env/viewport (PLUTO-163), navigation/practica-link-dead, cron audit (pollSecurityAlerts, kpiCronReport, kpiCronSkipRecipient, ux-pain-digest), monitoring/applogListenerHeartbeat. After this, LOG_LEVEL becomes a true verbosity dial (incidental noise only) with no collateral audit-trail loss. EXCLUDE benign well-known + nav page_not_found (we WANT those droppable). Verify with db whether forceSync is a stored appEvents column or purely a logger control flag (affects how to audit coverage).

Backlog low cpcoder-pluto-cc

No sub-tickets.

No questions.

wi-cli-venus created · 2026-06-22
wi-cli-venus commented · 2026-06-22

db-confirmed: forceSync + isCritical are NOT stored appEvents columns (21 cols, neither present) — they're logger.ts-only control flags consumed at the L98 write gate, never persisted. IMPLICATION for this WI: audit forceSync coverage by GREPPING call sites (logEvent/logInfo invocations), NOT by querying rows. The promotion = add forceSync:true at each target call site. Confirms PLUTO-182's not-found-log.ts malicious path already passes it (call-site grep, not row-query, is how to verify).