Fleet server-side error/404 capture: client-side-only logging leaves 3 blind spots (non-JS clients, auth-redirect-before-render, API/server 404s) — push-tier errors can be silently dropped upstream of the applog rail

Sub-tickets — 0/1 done

Activity

• wi-cli-venus created · 2026-06-21
• wi-cli-venus note · 2026-06-21
  CONFIRMED FLEET-WIDE (code-confirmed mars+pluto+venus, ayudarg same green-field): 404 capture is CLIENT-SIDE only — not-found.tsx → client useEffect → POST /api/log-404 → appEvents WARN. 3 blind spots where errors are NEVER captured: (1) non-JS clients (curl/bots) - no JS = no row; (2) auth-gated route hit unauth - redirect to /login before not-found renders; (3) API/server-side 404s bypass not-found.tsx. SEVERITY: ratified push protocol bs-mqn2ze006f7 puts 404-on-own-route in PUSH/error tier, but those 404s can land in blind spots -> push-tier errors silently dropped UPSTREAM of the applog rail. Rail itself is healthy (MSG-82); this is capture completeness. GOAL: server-side capture, complete regardless of client, honoring ratified tier (404-on-own-route=push; bot-probe no-referer/random=digest-only, carve-out preserved). IMPL CONSTRAINTS: (a) not-found.tsx is a Server Component -> can logEvent server-side, closes #1; BUT unmatched pathname isn't cleanly server-exposed in Next (reason it's client today) - solve via middleware-set req header carrying path. (b) API/server 404s (#3) need a catch-all route handler or shared helper. (c) auth-redirect (#2) is a redirect not a true 404 - decide whether to capture at the auth-gate as a separate signal. (d) GOTCHA pluto WI#486: server action POSTs to unmatched path -> 404s before body runs; that's why it moved to route handler - don't repeat. (e) venus: instrumentation.onRequestError catches thrown 500s only (notFound() doesn't throw); middleware excludes /api/*. (f) TEMPLATE: pluto has proven per-page server-side capture (mi-cursada/[id], practicas/[id]) emitting server-side event before notFound(). LEGS (file under parent EVO-12, each app PM owns): mars (pm-mars-cc), pluto (pm-pluto-cc), venus (pm-venus-cc), ayudarg green-field (pm-ayudarg-cc - best time to do it right). HELD pending Elazar priority call.
• wi-cli-venus statusChanged · 2026-06-21
  GREENLIT per ratified brainstorm bs-mqn8g0rhso5 (4/4, Elazar in-room; EVO-12 = fleet-restore item 1, greenlight routed to pm-llmmsgsrv). Legs released to app PMs. Canonical: server-side capture (client-independent), 404-on-own-route→error/push, bot-probe→digest carve-out, pluto per-page template. Per-app close proof = genuine wrong-URL-on-own-route round-trip (DM+email both land).
• wi-cli-venus note · 2026-06-21
  CANONICAL CLARIFICATION (coder-ayudarg-cc catch, generalpm-evolutiva endorsed): the 404 close-proof MUST come from the SERVER-SIDE 404-CAPTURE path, NOT instrumentation.ts. notFound() renders the not-found boundary WITHOUT throwing, so onRequestError never sees a 404. EVO-12 email = TWO paths, ONE dormant flag-gated sender: (1) instrumentation.ts onRequestError -> direct in-process SMTP on real 500s (DB-down class, per bs-mqn8ogqjpze LEG-1); (2) server-side 404-capture -> email when tier===error (own-route 404s). Adding the verified send-as lights up both. DO NOT wire the 404 email into instrumentation.ts.
• wi-cli-venus note · 2026-06-21
  PREDICATE CORRECTION (audit-venus catch, 2026-06-21): the 2-signal guard (RSC soft-nav AND manifest-match) is UNSOUND - it downgrades a genuine data-miss notFound() on a valid dynamic route (e.g. /practicas/[badId] via RSC nav) to WARN, breaking the data-miss-stays-ERROR invariant. CANONICAL FLEET PREDICATE is now 3-signal: downgrade error->warn ONLY when ALL of (1) RSC soft-nav headers present, (2) path matches a valid CURRENT route via build manifest, (3) served build-id/deploymentId != current build-id (stale build). Signal (3) is the discriminator - data-miss on the current build has matching build-ids so stays ERROR; true deploy-skew (stale build) downgrades. Supersedes the 2-signal 'final' note. venus 3-signal version is the reference.
• wi-cli-venus note · 2026-06-21
  PREDICATE CORRECTION v2 (mars-audit catch, 2026-06-21): signal-3 is PLAN-CONDITIONAL, not a uniform build-id mandate. The client-expected build-id reaches the server ONLY via the Vercel Skew-Protection header (Pro+); on Hobby it is absent so no server-side build-id compare is possible. Circular: where the header exists (Pro+) Skew Protection already routes stale clients to their old deployment so the stale-404 mostly never fires (guard moot); where the guard is load-bearing (Hobby) the header is absent. CORRECTED CANONICAL: Pro+ app = Skew Protection handles stale-404 at source, in-app build-id mismatch is belt-and-braces; Hobby app = signal-3 = build-recency <=10min timer (canonical-correct for Hobby, NOT a degraded fallback) but LOSSY: a real data-miss 404 within <=10min of a deploy is downgraded to warn for that window (bounded, post-deploy only). The <=10min Hobby lossiness is the Q3 go/no-go cost for Elazar. Supersedes the build-id-mandate note.
• wi-cli-venus note · 4w ago
  STALL DIAGNOSED 2026-09-12 by pmmaster-evolutiva-cc in the rot sweep: 82 days inProgress, and the cause is NOT engineering. On 2026-06-21 this item was GREENLIT and its four legs were 'released to app PMs' - pm-mars-cc, pm-pluto-cc, pm-venus-cc, pm-ayudarg-cc. ALL FOUR OF THOSE AGENTS ARE NOW ABSENT FROM THE ROSTER, and EVO-12 HAS ZERO CHILDREN, so not one leg was ever filed as a queryable row. This is the exact failure I track elsewhere as row-state-hidden-in-an-event-body, in its most expensive form: the work was authorized, assigned and then made invisible in the same message, and the only witness was an event body nobody joins to a query. A leg released in prose is not a leg assigned. FIXED FOR THE ONE LEG THAT HAS A LIVE OWNER: MARS-724 filed against coder-mars-cc, carrying the full 3-signal predicate including the Pro-vs-Hobby plan-conditional and the do-not-use-instrumentation.ts constraint, parented here. THE OTHER THREE LEGS ARE UNSTAFFED, NOT UNSTARTED, and that distinction is the thing to escalate rather than re-assign: pluto, venus and ayudarg each currently have ZERO live agents of any role. Filing rows against them would manufacture queue depth against nobody, which is worse than the present state because it reads as progress. Recorded as a staffing decision for Elazar, not an engineering blocker. Do not close EVO-12 on MARS-724 alone.