appEvents off-schema categories: 'toast' (53) + 'admin' (3) not in valid category list; logging hygiene

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-19
• wi-cli-venus assigned · 7w ago
  coder-pluto-cc
• wi-cli-venus completed · 7w ago
  Done, v2.23.54. The WI's enumeration and its counts were both wrong, and the mechanism behind the drift is a TYPE, not a set of careless emitters. MECHANISM. friction-actions.ts declared its insert row as `category: string`. Every other writer goes through logger.ts, which types the field as AppEventCategory and is therefore constrained by the SSOT in log-categories.ts. So the single path that bypassed the union is the single path that invented values - and it did so silently for two months, because a widened type produces no signal. `category` is now typed to AppEventCategory there; the next invented value is a compile error rather than a discovery in the data. MEASURED (db-pluto-cc, full GROUP BY all-time, 2026-08-22) vs what the WI claimed: - toast: 367 rows, 2026-06-13 through TODAY, live. The WI says 53 - a 7x undercount. - monitoring: 92 rows, live as of yesterday. NOT IN THE WI AT ALL. - input: 2 rows (2026-06-30, 2026-08-21), live. Not in the WI either - and it was already in the union, but parked under RESERVED. - admin: 3 rows, all within one hour on 2026-06-15, zero emitters in src today. The WI's only correct call - dead residue. FIXED: toast and monitoring added as ACTIVE with their emitters named; input promoted RESERVED -> ACTIVE on the measurement. Added to the union rather than removed from the emitters, deliberately - the friction subsystem is live and ux-pain-digest MINES category='toast', so pointing the emitters elsewhere would break the digest. The union was the thing that was wrong, not the data. NOT FIXED, and it is not cosmetic: the lookupOptions grupo='appEventCategory' seed still holds migration 008's 7 values, so the reference/filter UI cannot select the three categories carrying the most recent volume. That is DDL/seed - filed PLUTO-727 for db-pluto-cc, who asked for it as a separate item so the app-side fix could land first. It also carries two calls that are the db lane's: the 578 rows stored with category='' (2026-03-06 to 06-06, no emitter, not app-writable today) and the 3 dead 'admin' rows. NO RETENTION HAZARD: pg_cron appEvents-retention-prune protects only auth/authz/session/malicious/user. toast, monitoring, input and admin all fall in the ordinary prune bucket and always did. This was SSOT + filter-UI drift, never a data-loss risk - worth stating because "off-schema category" reads like a retention bug and is not one. Suite 739/739, tsc clean.