Friction rollup views (digest/top/by-user) + /admin/friction page (fleet bs-mrlqhi9hhir)
Fleet-agreed shape (Elazar-opened bs-mrlqhi9hhir, 2026-07-15): layered friction views with one final rollup entrypoint an agent SELECTs directly (no schema spelunking) + an /admin/friction page for Elazar. Criteria-agnostic split (mirrors PLUTO-560): build vFrictionDigest (per category/action/day: count + affected-user count + trend) + vFrictionTop (worst actions last 7/30d) + vFrictionByUser, against the CURRENT vFrictionEvents1w criteria — base-view WHERE clause is repointable later without touching page/agent query shape. Indexes already sufficient per db-venus-cc (categoryId+action, createdAt DESC, actorUserId, level) — no new index needed. actorUserId 99.7% populated, no capture-path bug on venus (unlike pluto). No existing /admin friction page — greenfield. BLOCKED (criteria-broadening half only): fleet 3-way criteria fork (venus/pluto/mars each propose different opt-out/allowlist shapes) still open — do NOT widen criteria to include the 4 missing categories (clientWindowError/resourceUnavailable/clientPageError/clientUnhandledRejection) or apply any opt-out rule until fleet converges; must include a dedup rule excluding backend-diagnostic categories (crearPracticaFailed etc.) that already pair with a toast row ~0.3-0.5s later, and must not resurrect dead category=client action=slow_query (killed 2026-06-10, zero rows since).
Questions
Activity
-
CORRECTION to filed description's dedup claim — earlier check was masked (small-sample), same failure mode mars found. Re-verified per-action with EXISTS: crearPracticaFailed 27/32 paired (84.4%), editarPracticaFailed 5/5 paired (100%, n too small to trust), getPracticaByIdFailed 2/10 paired (20.0% — mostly UNIQUE signal). Revised: do NOT blanket-exclude all 3. Include getPracticaByIdFailed (80% unpaired = genuine friction). Lean include crearPracticaFailed too (16% unpaired = real rows lost if excluded). editarPracticaFailed treat as include-by-default (sample too small). Dedup rule must be per-action verified-pairing, not per-category — matches mars's MARS-465 finding.
-
Fleet convergence CLOSED (bs-mrlrxvqesgi). Final spec: opt-out base (log all user-facing, exclude ops-rail email/cron/integration) + per-event anti-join (NOT EXISTS actorUserId+short-window vs toast row, replaces per-action %-threshold — venus's unpaired crearPracticaFailed rows stay by construction, no hardcoded list) + fail-closed action-classification table (user-facing|ops|test, default-excluded, CI-guard-enforced). Classification table + CI guard = Class-A DDL -> routes to db-venus-cc + team review, NOT solo. Infra half (rollup views/admin page) stays criteria-agnostic and dispatchable now.
-
Final candidate domain: 28 pairs (27 toast/warn/error + resourceUnavailable as named exception, NOT level-bumped). Classification: user-facing=13, ops=11, test=4 (full list in llmmsg thread db-venus-cc-mrlskorbuc0d). Default-included view (LEFT JOIN + COALESCE 'user-facing') confirmed vs audit-mars-ca fail-closed catch. Fleet forced-candidate-flag correction (pm-mars-cc, alert-rail warn-paging regression on level-bump) does not affect venus - db-venus-cc used named-exception/union for resourceUnavailable, never bumped its level. DDL drafting now, will design-ping audit-venus-ca before apply.
-
DB half APPLIED + audit-venus-ca PASS (2 corrections: idempotent seed, vFrictionByUser distinctActionTypes fix). Live: appEventFrictionClass(28 rows), vFrictionCandidates, vFrictionClassified(default-included), vUserFrictionEvents redefined (full classified shape, 800 rows). Page half: coder-venus-cc pushed 8eba990/v0.96.0, self-verify PASS - but page currently reads OLD narrow vFrictionEvents1w/1m + vAppErrorsRecent, NOT the new broadened vUserFrictionEvents/vFrictionClassified. Repoint needed for page to reflect VENUS-250's actual broadened criteria - dispatching now.
-
coder-venus-cc flag post-repoint (v0.96.1 live): broadened view re-includes toast/success-shown + toast/toast-shown (success, not friction) - venus deliberately excluded these via action='error-shown' filter (venus-commons §Friction Views). Candidacy formula's 'toast unconditional' clause pulled them in as user-facing-classified. Fix belongs in appEventFrictionClass (db-venus-cc), not a page-side re-filter. Dispatching db-venus-cc to reclassify.
-
Fixed: appEventFrictionClass gained 4th value 'success', toast/success-shown+toast/toast-shown reclassified there. audit-venus-ca PASS. Live split: 11 user-facing/11 ops/4 test/2 success. vUserFrictionEvents confirmed 0 rows for those 2 actions - excluded from friction cut, still visible in vFrictionCandidates/vFrictionClassified. No coder-side change needed (page already reads vUserFrictionEvents).
-
Friction rollup views + classification table + /admin/friction page all shipped, audited PASS, success-toast drift fixed. DB: appEventFrictionClass(28 rows, 4-way split)+vFrictionClassified+vFrictionCandidates+vUserFrictionEvents live. Page: coder-venus-cc ed51ea1/v0.96.1 live, repointed onto classified domain.