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).

Sub-tickets

Activity

• 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).
• wi-cli-venus completed · 7w ago
  Shipped da1f867 v2.23.35, PTD green (live 2.23.35, dpl_6owW9h6m7D21fXBeZDHUh4KrM3ph). 9 call sites promoted to forceSync: email/email-sent (email-outbox.ts), email/sendAdminEmail (email-admin.ts), cron/ux-pain-digest, cron/pollSecurityAlerts, cron/kpiCronReport, cron/kpiCronSkipRecipient x3 (jtp/adjunto/titular), navigation/practica-link-dead x2 (practicas/[id], mi-cursada/[id]). Levels left at info deliberately: warn pages via fn_notify_applog_err, and practica-link-dead is already forcedCandidate in FRICTION_CLASSIFICATIONS precisely so friction picks it up WITHOUT a level bump. TWO NAMED TARGETS DO NOT EXIST and were not invented to fill the list: client-env/viewport was REMOVED by PLUTO-536 (reportClientEnv deleted, Elazar 2026-07-07, fleet collection complete) and monitoring/applogListenerHeartbeat has no emitter in this repo at all - it lives in the venus rail. So the WI's 'promote these' list was 2 items stale. ANSWERS THE WI'S OWN VERIFICATION QUESTION: forceSync is NOT a stored appEvents column. Checked db/schema.md (zero hits) and the logger INSERT column list - it is purely a control flag read at logger.ts:102 to compute isCritical. Consequence, which is the reason this WI needed a test rather than a query: coverage is UNAUDITABLE FROM DATA. No appEvents query can tell you which call sites are protected, so the source is the only place it is visible, and the test asserts it there. EXCLUSIONS HONOURED AND ASSERTED: page_not_found and benign navigation stay droppable - there is an explicit test that they still drop at LOG_LEVEL<3, so a later over-broad promotion fails rather than silently making the dial useless. LOG_LEVEL=0 remains a hard off switch, forceSync included; also asserted. 11 tests in src/lib/logger-force-sync.test.ts. Two independent legs: the GATE (forceSync survives LOG_LEVEL<3, an identical unmarked row does not) and CALL-SITE COVERAGE (each site still passes the flag; the kpi cron asserts exactly 5 forceSync rows and 3 skip sites, so adding a skip tier without the flag fails). Both mutation-checked: removing forceSync from logger's isCritical kills the gate test; removing it from the email-outbox call site kills the coverage test. COVERAGE STATEMENT: what is proven is that the gate honours forceSync and that these 9 sites carry it. NOT exercised - no prod run at LOG_LEVEL<3, because prod is LOG_LEVEL=3 and I am not lowering a live logging dial to prove a test that already proves the mechanism. The claim is 'these rows no longer DEPEND on LOG_LEVEL=3', and that is established at the gate, not in prod.