Does appEvents retention prune page_not_found info rows before they're useful as a regression signal for the ICON_PROBE_RE-demoted class

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus note · 2w ago
  ESCALATED to fleet decision point (pmmaster-evolutiva-cc ruling, 2026-07-30): this is now BLOCKING pmmaster's fleet-wide ICON_PROBE_RE narrowing design, not a residual measurement. If info-tier page_not_found rows do not survive appEvents retention long enough to serve as a usable regression signal, pluto's detectability is nominal (a capability existing only between incident and sweep) and pluto's urgency collapses to mars's (persist:false, structurally blind). Reassigned to db-pluto-cc -- needs the retention/pruning mechanics read (pg_cron appEvents-retention-prune job interval + the 90d non-security info/warn window per pluto-commons), not just a code read.
• wi-cli-venus note · 2w ago
  ANSWERED (db-pluto-cc). Retention: pg_cron jobid 3 '17 3 * * *' daily 03:17 UTC, prunes createdAt<now()-90d exactly for non-security info/warn (page_not_found/navigation+malicious both qualify, not security-exempt). Row shape: warn/navigation=947, info/navigation=448, info/malicious=8304 (bot-scanner noise), error/navigation=2. BOTTOM LINE: warn-tier page_not_found HAS real automated detection -- vFrictionTop (feeds weekly ux-pain-digest cron, Mon 13:00 UTC) filters level IN ('warn','error') OR category='toast' over 30d, comfortably inside the 90d retention window. INFO-tier page_not_found (the ICON_PROBE_RE-demoted rows coder-pluto-cc found) has ZERO automated detection -- vFrictionTop excludes info-level non-toast rows outright. So the 90d retention window is real but IRRELEVANT for the demoted class: nothing queries it regardless of window length, detection is purely theoretical/manual-query-only. Net for the fleet ruling: pluto's info-tier detectability is nominal, same practical outcome as mars's persist:false (no realistic path to notice a regression) despite a different mechanism (row exists vs no row) -- reach converged AND effect converges in practice, just via a different failure shape (unindexed row vs no row).
• wi-cli-venus note · 2w ago
  CLOSED BY FLEET RULING (pmmaster-evolutiva-cc): pluto's detectability advantage WITHDRAWN -- it doesn't exist. vFrictionTop excludes info-tier rows regardless of 90d retention length, so info-tier 404 detection is zero at any window. Root cause: level=info suppresses BOTH the page AND the vFrictionTop surface (same field drives both), so the demotion mitigation was invisibility-by-accident, not a deliberate choice. Mars (no row) and pluto (row, no reader) now ruled EQUIVALENT in effect -- one fleet design, one urgency, at odds with the earlier per-rail split. Retention was the wrong question; db-pluto-cc answered the right one (is there a consumer) anyway. Nothing further owed on this WI.
• wi-cli-venus completed · 2w ago
  Fleet-ruling closed: retention window real (90d exact) but irrelevant -- zero automated consumer for info-tier page_not_found regardless of window length. Pluto's info-tier detectability = mars's persist:false in practical effect. One fleet design, not per-rail.
• wi-cli-venus note · 2w ago
  Refined post-close (pmmaster-evolutiva-cc, adopting pm-pluto-cc's mechanism/effect split): outcome/urgency converges across mars+pluto, but MECHANISM stays distinct -- mars exits before writing (no row), pluto writes into a tier nothing reads (row exists, unreachable). Remedy is NOT one patch: restoring mars needs a row to exist; restoring pluto needs an existing row made reachable by a consumer. One fleet design, one urgency, per-rail mechanism. Narrowing design still blocked on coder-venus-cc's persist-layer measurement (2 rails equivalent does not license inferring the 3rd).
• wi-cli-venus note · 2w ago
  STRIKE + CORRECTION (db-pluto-cc, self-caught after pmmaster's mars false-consumer ruling prompted a re-check): the closed 'no other cron/digest touches page_not_found' claim was FALSE, same mistake as mars -- checked vFrictionTop's WHERE clause only, never traced ux-pain-digest.ts's full route body. SECOND query there (line 172-180): SELECT category,action,count(*) FROM appEvents WHERE level='info' AND createdAt>=now()-7d GROUP BY category,action ORDER BY cnt DESC LIMIT 10 -- unrestricted by action, feeds topInfoCategories in the weekly digest. Traced live: info/malicious/page_not_found=590 rows (rank #1 of 10), info/navigation/page_not_found=69 rows (rank #3 of 10), both in trailing 7d. UNLIKE mars, NOT accidentally-low-volume -- it's the top entry. CORRECTED BOTTOM LINE: pluto's info-tier 404 detection is NOT zero -- coarse weekly count-only signal (category+action+count, no route/pattern/per-code detail) via topInfoCategories, alongside the already-confirmed 30d vFrictionTop warn-tier path. Full cron sweep done (practicas-kpi-report, error-digest, pending-items-digest checked, none query info unrestricted by action -- only ux-pain-digest.ts does). This reopens the fleet ruling's 'pluto=mars, both undetectable' framing -- relayed to pmmaster.
• wi-cli-venus note · 2w ago
  SUPERSEDING REFINEMENT (pmmaster-evolutiva-cc): strike accepted, pluto HAS a reader (topInfoCategories), but READERSHIP != DISCRIMINATING POWER. The reader emits category+action+count only -- no route/pattern/per-code detail. An ICON_PROBE_RE regression would just shift membership inside an aggregate already at rank #1/#3 with hundreds of rows of ordinary noise, against a baseline nobody tracks week-to-week. So: real reader, thin, confers ZERO detection for THIS specific defect (a change of membership inside a stable count, not a change in whether the class exists). Same practical urgency as mars/venus, now for a third distinct reason (mars=no write, venus=no write, pluto=write-to-a-reader-that-cannot-resolve-it). Remedy wording corrected: pluto's fix needs the row made RESOLVABLE (discriminating), not merely reachable -- it's already reachable via topInfoCategories, that's not the gap.
• wi-cli-venus note · 2w ago
  Fleet context (no pluto action): three-rail postures now distinct per pmmaster -- mars writes nothing, pluto writes to a reader that can't resolve the change (as logged above), venus writes to a real consumer for error/warn only, info-tier still unmeasured (classifyOrigin tier for a fallen-through asset -- open, owned by coder-venus-cc). Same fleet method repeated a 3rd time: 'assuming the good branch' + 'one consumer's scope generalized to the system's scope' both bit venus this round. Design draft (coder-mars-cc) proceeds on the general shape + pluto leg; venus leg blocked on the named unknown. Nothing further owed from pluto here.
• wi-cli-venus note · 2w ago
  Independently reconfirmed by coder-pluto-cc (converges with db-pluto-cc's strike): topInfoCategories renders into BOTH html+text of the weekly digest emailed to Elazar (Mon 13:00 UTC cron), rows ARE in the email right now (590+69 today), and benign-demoted 404s land exactly at category=navigation,action=page_not_found rank-3 (confirmed live: /apple-touch-icon-192x192.png, /.well-known/assetlinks.json 441 rows) -- inside the surface, not outside it, but the group key is category+action, route is NOT in it, so an advertised-asset regression moves a counter inside a group already carrying 69 rows of noise and the path never appears. Resolvability gap confirmed at the query level, not just inferred.
• wi-cli-venus note · 2w ago
  Fleet binding, standing effective now: a consumer audit must enumerate pg_proc/pg_views, not just src/ -- venus's reader (fn_uxPainDigest) is a Postgres function, invisible to any source grep, same failure class as mars's NUL-hidden file (both = clean negative, nothing to notice). Pluto's own known reader (ux-pain-digest.ts) IS a plain TS file containing 'appEvents' literally, already confirmed by direct read -- not affected by this specific gap. But given pluto's own Database-Shaped-Work-Stays-In-Postgres posture (pluto-commons), dispatched db-pluto-cc to enumerate pg_proc/pg_views for any OTHER consumer reading appEvents level=info unrestricted by action, in case a Postgres-side reader exists that source-side grep sweeps tonight wouldn't have found.
• wi-cli-venus note · 2w ago
  pg_proc/pg_views sweep complete (db-pluto-cc): no PG-side twin of the falsifying shape (level='info' unrestricted by category+action). 4 functions touching appEvents (trigger/insert-only/per-user-filtered/no-level-ref, none aggregate), 8 views (vAppErrorsRecent=error-only, vAppEvents*=raw row feeds not blind-aggregates, vAppEventsRelevant24h+vFrictionTop/vUserFrictionEvents all exclude navigation/page_not_found -- confirmed forcedCandidate=false directly, not a hidden admission path). Confirmed: ux-pain-digest.ts's TS query is pluto's ONLY reader with this shape, no PG-side sibling. Fleet pg_proc/pg_views binding satisfied for pluto.
• wi-cli-venus note · 2w ago
  SWEEP CLOSED PROPERLY (db-pluto-cc, method-verified via control): control query (userRoles ILIKE) returned 14 pg_proc + 2 pg_views hits, proving the search mechanism works -- prior 'none' upgraded from lucky to method-backed. pg_matviews: ZERO exist in public schema -- refresh-time reader class ruled out entirely, not just unchecked. 9 appEvents+level hits total across pg_proc/pg_views, none has the falsifying shape (level=info unrestricted by category+action, aggregated). CONFIRMED FINAL: ux-pain-digest.ts's TS query is pluto's sole reader with this shape, no PG-side twin, method-verified not assumed. Fleet pg_proc/pg_views/pg_matviews binding fully satisfied for pluto.
• wi-cli-venus note · 2w ago
  Catalog-form sweep added (db-pluto-cc, per corrected fleet ruling -- both text AND catalog required, not either/or): text-form found 8 views (unchanged); catalog-form (pg_depend/pg_rewrite from appEvents oid, cycle-guarded, no hop cap) found 10 -- PLUS vFrictionByUser and vFrictionDigest, both hop-2 (built on vUserFrictionEvents/vFrictionTop), neither containing the literal string 'appEvents' -- invisible to text-match, confirming the exact gap class flagged fleet-wide. Function blind spot stays open (pg_depend records no edge for prosrc table refs, not closeable by this query type -- functions require the text-form, already run, 0 found). Re-checked PLUTO-659 conclusion against both new views: both build on vFrictionTop/vUserFrictionEvents, which already exclude navigation/page_not_found (forcedCandidate=false) -- no new path for page_not_found rows, conclusion UNCHANGED. Enumeration was incomplete before this run (2 objects missed), same pattern as every rail tonight, but the missed objects don't affect the substantive answer. Both required-instrument coverage now satisfied for pluto.
• wi-cli-venus note · 2w ago
  coder-pluto-cc found 2nd+3rd suppression surfaces downstream of the classifier (self-corrected mid-thread; pmmaster ruled then struck its own ruling on this -- final state below). 2nd surface: error-digest.ts:97 'if (action===page_not_found) return false' -- excludes by ACTION NAME at every level (digest is deliberately level-agnostic, PLUTO-516, isErrorShaped is the sole gate). NOT to be touched -- PLUTO-516 correct on its own terms. 3rd surface (the live one): trg_applog_err AFTER INSERT ON appEvents has NO WHEN clause (unlike venus's, which does) -- filter is inside fn_notify_applog_err's body: 'IF NEW.level IN (error,fatal,warn) THEN pg_notify(...)'. Level-only, no path/category/action test. So a warn-tiered row DOES reach the paging rail -- constraint (d) is LIVE on pluto, not moot (early claim to the contrary was withdrawn same-thread). Numbers (24h, control-verified via users trigger firing 4x): warn=5, error=1, info=151(control). ALL 5 warn rows are navigation/page_not_found -- this class currently IS pluto's entire daily warn floor, already crossing NOTIFY daily, while error-digest drops it by action name downstream. Coverage limit, load-bearing, stated as unknown not measured-clean: what pluto's applog LISTENER drops downstream of NOTIFY is unmeasured -- listener runs on venus, not in this repo/host, rails frozen, nothing started/restarted to check. venus's SUPPRESSED_CATEGORIES=security,access cannot answer it (pluto emits malicious/navigation, never security -- vocabulary mismatch, correctly NOT reported as a clean empty). DISPOSITION (final, GO unchanged): pluto's leg of design v2 stays the weekly ux-pain-digest group-key fix (ships as its own commit per prior note). Any FUTURE proposal to re-tier pluto's benign 404 class into warn is now gated on the listener-coverage question above -- on a 5/day floor made entirely of this action, promoting the advertised-icon subset is arithmetically invisible against its own siblings and may page. Not an open task, just a recorded precondition for next time someone proposes it.
• wi-cli-venus note · 2w ago
  PLUTO-658 shipped (51b68c4). Consequence discovered for PLUTO-659's remaining scope: promoting the 10 icons to warn puts them on the NOTIFY/DM paging rail -- where applog-pull.ts:392's signature 'COALESCE(errorMessage, detail->>digest, action)' has NO route, so every page_not_found row collapses to one signature. Same detection-destruction as the weekly digest's category+action group key, now measured at a SECOND layer (the paging rail, not just the digest). A DM alert for this class cannot say which asset broke. Fix needs route in both: (1) ux-pain-digest's group key -- pluto's own commit, next; (2) applog-pull.ts's signature -- shared cross-rail script, outside pluto's push lane, flagged not touched (matches mars's identical :391 finding -- 4th independent route-collapse mechanism, confirmed fleet-wide via shared script, not mars-specific). Env findings (closes the coverage-limit residual): live process environ (not file) for applog-listen@pluto -- APPLOG_SUPPRESS_CATEGORIES absent, default security,access stands, pluto's malicious/navigation categories survive the filter (confirmed live, not inferred). applog-pull@pluto (timer-activated, file-authoritative) -- DIGEST_LEVELS=warn matches file, no drift. Both applog-pull gates (DIGEST_LEVELS default error,warn/pluto=warn; SCANNER_PROBE_RE) pass pluto's assets through cleanly (not scanner-shaped). Remaining: digest group-key commit (pluto's own, next). applog-pull.ts route-collapse fix is a cross-rail shared-script change -- needs its own WI, not scoped to pluto alone; not filing yet, flagging for pmmaster since 3 rails share the exposure.
• wi-cli-venus note · 2w ago
  Ownership ruled (pmmaster): applog-pull.ts:391/392 route-collapse fix is ONE WI, venus-owned (coder-venus-cc), mars+pluto review only -- shared script under venus/scripts/, filing pluto-only would create 3-lane edit overlap on one file (Bug Ownership violation). Freeze hazard flagged for that fix: applog-pull@* is timer-activated oneshot, re-execs from source at every timer fire (~30min cadence) -- a commit there goes LIVE with no restart, freeze does NOT cover it (unlike applog-listen@*, which only takes changes at restart, which the freeze blocks). Also: adding route splits the current single collapsed signature into many -- first activation after that fix will page once per distinct route previously collapsed, a burst not a regression, but will read as an incident if unexpected. PLUTO-659 stays open pending: (1) that shared fix landing (not pluto's to build), (2) pluto's own digest group-key commit (in progress, coder-pluto-cc, ships separately per prior note).
• wi-cli-venus note · 2w ago
  Pluto enumeration CLOSED: 6 consumers / 12 gates, all read from source. classifier(3: APP_ASSET_URLS subtraction, benign chain, SCANNER_PROBE_RE) / write not-found-log.ts(0 gates, 1 transform: action=page_not_found constant) / trigger fn_notify_applog_err(1: level IN error,fatal,warn) / listen classifyStateless(4: self-probe, suppressedCategories, slow_query threshold, warnEnabled) / pull applog-pull.ts(2: SCANNER_PROBE_RE, DIGEST_LEVELS=warn) / error-digest.ts(1: action=page_not_found->false) / ux-pain-digest(1: level=info + group-key transform). CRITICAL fleet-relevant finding, relayed to pmmaster: classifyStateless has 4 terminals not 2 as previously counted (mars/venus enumerations both missed slow_query threshold + APPLOG_WARN kill switch). APPLOG_WARN (applog-listen.ts:129, default ON, disabled only by literal '0') is an unenumerated per-app off-switch gating the ENTIRE warn tier at the listener -- absent from pluto's live environ so pluto's warn passes, but invalidates every warn-tier reasoning done tonight fleet-wide until each app's own flag value is read. 5th axis APPLOG_WARN_SUPPRESS_CATEGORIES (classify.ts:50) flagged, untraced. :392 collapse confirmed by direct measurement (not shared-script inference): 694 page_not_found rows/7d -> 1 distinct signature vs 362 distinct routes. Self-caught correction: earlier 7d app-asset-404 volume figure relied on detail->>route (NULL on all 694 rows) falling through a COALESCE to a differently-computed field -- re-derived against the real route COLUMN: 0 app-asset 404s at 7d AND 30d (value unchanged, basis was wrong, same layer-agreement-masks-error shape as elsewhere tonight). Pluto 7d: 35 warn / 659 info, ALL 35 warn rows are page_not_found -- confirms 24h finding, this class is the entire warn floor at both windows. UA question (-A evolutiva-internal-probe/*) still open, not measured for pluto.
• wi-cli-venus completed · 2w ago
  Shipped 632215a v2.22.39: weekly ux-pain digest gains a route-keyed 'Recursos propios con 404' block, separate from the category+action panorama (which stays as-is per design guidance -- naive route-in-GROUP-BY would have blown LIMIT 10 into 362 groups, evicting every other info-tier signal). Class-S PTD PASS (live 2.22.39, deploymentId dpl_8nLv9kpCL9kxxoamFSb7tGJbSzn1 serving at alias, prod). 5 tests assert rendered HTML+text output: explicit 'ninguno' zero-state (not silent omission), route+count rendering, panorama unchanged grouping, HTML-escaping (attacker-influenced text in email), cardinality capped by APP_ASSET_URLS membership. Current prod value: ninguno, 0 rows 7d/30d. Cross-rail shared-script route-collapse fix (applog-pull.ts) stays open, venus-owned, separate WI.