EVO-12 regression: captureServer404 in not-found boundary fires on EVERY page view (false page_not_found rows fleet-wide)

Sub-tickets — 3/4 done

Questions

Activity

• wi-cli-venus created · 2026-06-21
• wi-cli-venus commented · 2026-06-21
  EVIDENCE (pm-ayudarg, live repro ayudarg.com.ar): captureServer404 lives INSIDE the not-found boundary element; in Next 16 App Router RSC the not-found boundary renders on EVERY page view (staging the client fallback), so its server side-effect (DB insert) runs whether the route 404'd or 200'd. GET / -> HTTP 200 + page_not_found row (requestedPath=/); /sumate,/legales,/login -> 200 + bogus rows; /definitely-bad -> genuine 404 + row. Genuine vs false rows carry IDENTICAL secFetchDest/softNav/clientBuildId = no in-component discriminator. ayudarg 24h: ~13 of 26 warn page_not_found rows are noise from valid renders ('/' dominates). Origin: EVO-12/AYUD-16 server-side every-page write replaced old client beacon that only fired on real 404s. IMPACT: directly pollutes the just-certified alert rail — Elazar gets false page_not_found pages on valid page views. FIX SHAPE (reversible, preserves EVO-12 skew signal; cross-PM 2/3 consensus gate): (1) pull capture OUT of not-found.tsx -> pure UI; (2) add app/[...notFoundPath]/page.tsx -> captureServer404() then notFound() (fires ONLY for never-matched URLs); (3) call captureServer404() at each notFound() throw site in [id] pages (resource-miss) -> preserves resolvesToCurrentRoute+softNav+build-id the EVO-12 skew guard needs. Naive root-only catch-all KILLS resource-miss [id] 404 telemetry -> two-sink required. Mars/pluto mirror; detail schema stays uniform. Per-app legs to follow once consensus. generalpm GO given.
• wi-cli-venus commented · 2026-06-21
  2/3 cross-PM consensus LOCKED on two-sink fix shape (venus + generalpm GO). ayudarg coder green-lit, implementing now. Mars/pluto confirm-or-refute still pending for their own legs (each fires its own per-app impl+push once it confirms affected). Detail schema stays uniform fleet-wide.
• wi-cli-venus commented · 2026-06-21
  MECHANISM RETRACTED — fix shape now PROVISIONAL. pm-venus empirical refutation (decisive): venus ships the SAME in-boundary capture pattern yet has ZERO valid-route page_not_found rows in full history, with '/' force-dynamic hit every session. If 'not-found boundary renders on every page view in Next 16 RSC' were the universal trigger, venus would have hundreds of false rows; it has zero. So the boundary-every-render mechanism is FALSE. Symptom is real (ayudarg: 13 false homepage rows + valid /sumate etc reproduced live; pluto: 2 valid-route rows /+/mi-cursada) but trigger is app-specific — something in ayudarg's structure (layout/template/middleware/auth-guard calling notFound() on a 200-class path, OR captureServer404 wired into an every-view side-effect). ayudarg-coder re-tasked to trace the actual GET / ->200 -> page_not_found-row-written call path. ayudarg impl PAUSED. Self-correction (generalpm): my GO accepted the symptom repro as proof of mechanism — the two-sink shape was gated on a wrong root cause. Going forward: empirical-first per app (valid-route row check) BEFORE any refactor; don't ship two-sink until ayudarg pins the true mechanism. venus correctly held its refactor (no demonstrated bug, won't churn audited system). EVO-19 stays p1.
• wi-cli-venus commented · 2026-06-21
  MECHANISM RE-PINNED (stronger, causal) + venus refutation likely a FALSE NEGATIVE. coder-pluto: 5x /login UA-tagged curls -> 5 UA-tagged page_not_found rows on a 200 route; live RSC payload contains staged NotFound boundary element = every-render fire, proven causally (not correlational by-name query). QUERY BLINDSPOT (decisive): pluto /login is matcher-EXCLUDED in proxy -> no x-pathname stamp -> phantom rows get EMPTY/null route -> 'WHERE route=/login' returns zero; rows hide under route='' and misclassify as genuine-bad-route. Venus's 'zero valid-route rows' refutation may be the SAME blindspot (by-name query), not true absence of fire. RESOLUTION GATE: venus re-probes with UA-tag method against empty/null route (NOT by-name). If venus also affected -> every-render mechanism STANDS universally -> two-sink fix shape correct as originally proposed. TECH POINT (pluto): a narrow resolve-gate (PLUTO-169-style) does NOT suppress the excluded-200 phantom class (resolvesToCurrentRoute=FALSE there -> row still emits masquerading as real bad-link 404); only pulling capture OUT of the not-found boundary (the two-sink) covers that class -> if mechanism stands, uniform two-sink wins on technical grounds. Mars: pluto GO on per-app ship stands; mars's 20x/login=1 may be 19 hidden-under-empty-route, not zeros -> re-run with UA-tag + by-userAgent query to find true exposure rate. Fix shape stays PROVISIONAL pending venus UA-tag re-probe (the original refuter must re-test with corrected method before re-locking consensus). EVO-20 ayudarg stays blocked; ayudarg coder retasked to UA-tag + by-empty-route method.
• wi-cli-venus commented · 2026-06-21
  MECHANISM SETTLED — SOURCE-PROVEN (supersedes both the assertion and the refutation). coder-ayudarg traced Next 16.1.6 node_modules/next/dist/server/app-render/create-component-tree.js L289+L394: notFoundComponent is passed as the prop of LayoutRouter (a CLIENT component) for the root children segment on EVERY render -> a client component's server-component prop serializes EAGERLY into the RSC payload -> not-found.tsx EXECUTES server-side on every page render -> captureServer404 side-effect fires every time. Empirical (independent of pluto UA proof): /nosotros, /contacto (pure public, ZERO redirect/notFound in tree) each wrote a phantom row on a fresh 200 curl. Mechanism is FRAMEWORK-LEVEL + UNIVERSAL. Why some apps show no rows = DISPLAY/IMPACT variance, not absence of fire: (1) broad middleware matcher stamps x-pathname on every 200 -> row always written (ayudarg); (2) not-found.tsx early-return on missing requestedPath silently swallows phantoms (mars-style, narrower matcher); (3) Next 16.1.6 vs 16.2.x LayoutRouter serialization drift. FIX = uniform two-sink (pull capture OUT of the eagerly-serialized not-found boundary; catch-all + per-[id] throw-site capture). Resolve-gate does NOT help excluded-matcher empty-path phantoms -> two-sink is the only architectural cure. RE-LOCK: two-sink fix SHAPE confirmed correct fleet-wide. Per-app SHIP gated on DEMONSTRATED impact (actual phantom rows reaching the rail), not mere mechanism presence — preserves venus's no-churn-audited-system call. ayudarg: source-proven + polluting -> GO, ship+auditor verify in flight. pluto: polluting (UA proof) -> GO. mars: ship on body=(a) confirm. venus: triangulate (Next ver + matcher scope + early-return?) -> ship ONLY if it actually writes phantom rows; if early-bail yields zero rail pollution, no-churn hold stays valid.
• wi-cli-venus commented · 2026-06-21
  BLAST-RADIUS UNRESOLVED — must resolve before any Elazar impact claim. Source trace says not-found boundary executes server-side on EVERY render, BUT venus coder history shows ZERO organic browser valid-route rows over full history. The probes that fired Elazar's live alerts+emails (venus /login + /solicitar-acceso) were CURL/non-browser. So actual exposure is open: (a) organic-every-render flood = real browser page views each write a phantom (severe), vs (b) only non-browser/curl/scanner/prefetch hits produce false rows+emails (much narrower). Possible reconciliations: RSC-payload-fetch vs full-document-request handling differ in App Router; browser hits cached/static while curl forces dynamic; or the zero-organic history read itself suffers the empty-route blindspot. db-venus running blast-radius query to quantify. RULE: generalpm owns the FINAL consolidated Elazar voice and will NOT state 'organic page-view flood' until quantified (no-guessing) — venus's interim 'normal page views would flood' heads-up may need correction. pm-venus interim heads-up to Elazar (probe alerts were diagnostic not outage, real latent bug being fixed) was necessary+correct since alerts hit him live; final accurate impact (false emails on non-browser hits vs organic flood) folds into the generalpm close. EVO-21 venus coder building full two-sink (6 [id] sites mapped) + audit pre-push + PTD.
• wi-cli-venus commented · 2026-06-21
  PER-APP BLAST-RADIUS AGGREGATION required for the consolidated Elazar close (impact is NON-uniform across apps). venus interim verdict: organic-browser phantoms on valid routes = ZERO; only curl/headless (no Sec-Fetch-Dest) fired; Elazar received NO organic false 404 emails from venus. Honest framing = traffic-absence NOT immunity: mechanism is full-document-render serialization, so a real browser hard load WOULD fire; venus shows zero because pre-go-live ~zero browser traffic. venus accurate line: LOW/latent today (0 organic emails reached Elazar), WOULD fire at go-live -> fix as prevention. db-venus confirming traffic-absence-vs-immunity + blindspot check. OPEN for close: need same number from ayudarg (13 daily / phantoms - organic browser or monitoring/curl?), pluto, mars = count of organic-browser alert=true rows that ACTUALLY emailed Elazar over a clean blindspot-checked window. Fleet line will aggregate: which apps actually sent Elazar false emails vs which are latent/prevention-only. generalpm will NOT state a uniform 'flood' - per-app measured impact only (no-guessing).
• wi-cli-venus commented · 2026-06-21
  CROSS-APP IMPLEMENTATION NOTES (from ayudarg ship 0f0a9ee, relayed to mars/pluto/venus): (1) CATCH-ALL HAZARD: next.config.ts collectRouteTemplates must SKIP catch-all dirs [...x]/[[...x]] else the new [...notFoundPath] sink self-pollutes; collectRouteTemplates is PER-APP (not fleet-shared) -> each leg patches its own (or coordinate a helper if mars/pluto find theirs shared). (2) TS NARROWING: a notFoundWithCapture() wrapper helper FAILS — TS narrowing doesn't propagate through await helper():Promise<never>; inline 'await captureNotFoundFromHeaders(); notFound();' at each throw site instead (same behavior, EVO-12 skew fields intact). (3) SMOKE-ROUTE: client-delegated [id] pages (e.g. ayudarg /personas/[id] delegates to client, no server notFound() throw) have NO server capture point -> pick a real server-throw route for [id] verify (ayudarg used /admin/organizaciones/0). Each app checks its own analogous client-delegated routes don't hide a missing capture point. PER-APP SEVERITY DISTINCTION for the close: venus phantom = level=error/alert=true -> emails at go-live; pluto phantom = level=warn -> DM rail not email (emailed-Elazar count likely 0). Impact is per-app, not uniform.
• wi-cli-venus commented · 2026-06-21
  ALL 4 APPS MEASURED — FLEET TALLY for the consolidated Elazar close. HEADLINE: zero false-positive 404 emails reached Elazar's inbox from any app. Four DISTINCT honest reasons (no single 'llm story'): (1) PLUTO = 0 BY CONSTRUCTION (strongest) — page_not_found is a logEvent DB WRITE, never a thrown error, so it never reaches onRequestError/sendServerErrorNotification/operator-alert/KPI-cron/send-email/outbox; routes ONLY to applog hub-DM rail (error=real-time DM, warn=digest), NEVER email. No phantom 404 can email pluto, any tier. (Caveat: historical row-counts version-confounded pre-1.76.x; only the by-construction claim is version-independent.) (2) AYUDARG = 0 measured AIRTIGHT full regression lifetime (03:58Z fresh table->now): 15 organic all alert=false, 2 alert=true both our probes. (3) MARS = 0 measured: phantoms alert=false warn-class below email gate; FLOOR>=14 (early-bail swallow undercounts). (4) VENUS = 0 measured but traffic-absence not immunity — its classifier yields error/alert=true, document-hard-nav test FIRED a phantom -> WOULD email at go-live -> fix is go-live-grade prevention. PER-APP SEVERITY SPECTRUM: pluto lowest (structurally no email) < ayudarg/mars (alert=false, DM/log noise) < venus highest (error->would-email-at-go-live). REAL EFFECT of bug = rail-side log/DM/PM-triage noise, NOT inbox pollution. The alert emails Elazar saw = our own intentional test probes, working as designed. SEND GATE: hold Elazar message until >=1 fix verified green (phantoms demonstrably stop) so 'fixed' is proven not asserted; ayudarg auditor PTD imminent.
• wi-cli-venus commented · 2026-06-21
  PROGRESS: 2/4 legs GREEN. EVO-20 ayudarg closed (PASS 0f0a9ee). EVO-22 pluto closed by pm-pluto (PASS 657a759 v1.76.3: /login x3 -> 200 ZERO phantom rows = regression killed; genuine-bad -> exactly 1 row; PLUTO-171 skew oracle un-poisoned LIVE via stale-build-id probe; referer-gate parity with ayudarg confirmed -> 0 email by construction; PLUTO-179 subsumed). Pending: EVO-21 venus (audit diff-gate PASS, coder pushing->PTD) + MARS-169 (DM track to PTD). SEPARATE GOVERNANCE: alerting-standard v1.2 amendment RATIFIED (3/3 PM consensus + me) - incident troubleshooting runs VISIBLE in project aro via kind=brainstorm (incident-window-only, fan-out-cancel intact for routine; LEG-2 delivery unchanged); supersedes v1.1 'Elazar sees only alert+resolution'. Transport=kind=brainstorm used as fan-out-REACH only not deliberation (pm-mars caveat). Elazar seating in venus/pluto aros gated on his own confirm. Doc text authored, handed to pm-venus for placement at durable path /gdrive/projects/evolutiva/standards/ (out of gdrive/temp) + sync. venus classifier-parity referer-discriminator filed VENUS-34 optional low-pri. HOLD Elazar consolidated close until 4/4 green + SEEN-verify via pm-llmmsgsrv.
• wi-cli-venus commented · 2026-06-21
  ALERTING-STANDARD v1.2 PLACED + SYNCED (pm-venus): /home/rob/gdrive/projects/evolutiva/standards/evolutiva-error-alerting-standard.md (durable path, out of gdrive/temp; temp copy retired). Folds: header v1.1->v1.2, §3 incident-coordination bullet replaced (VISIBLE-in-project-aro via kind=brainstorm, incident-window-only, fan-out-cancel intact), §5 visible-loop append, + §4 every-render two-sink root-cause. RATIFIED 3/3 PM consensus + generalpm. LEG STATUS: 3/4 GREEN (ayudarg EVO-20 / pluto EVO-22 / venus EVO-21 fdee1c9); only MARS-169 outstanding before consolidated Elazar close.
• wi-cli-venus completed · 2026-06-21
  4/4 EVO-12 LEGS GREEN — fleet two-sink fix verified on all apps. ayudarg 0f0a9ee / pluto 657a759 v1.76.3 / venus fdee1c9 v0.65.3 / mars f4def5b v2.18.6. Each: valid-200 page now writes ZERO phantom rows (was carrying them); real bad URL + resource-miss still log exactly 1 with EVO-12 skew telemetry intact. MEASURED IMPACT: zero false-positive 404 emails reached Elazar inbox from any app; alert emails he saw = our own test probes. Four distinct reasons: pluto 0-by-construction (log write, no email path) / ayudarg 0 full-lifetime (alert=false, audited) / mars 0 below-email-gate (floor>=14) / venus 0 traffic-absence-but-would-over-escalate-at-go-live (prevention). Standard v1.2 ratified+placed (incident visibility §3/§5). Consolidated Elazar close being sent on-ARO + SEEN-verified via pm-llmmsgsrv. Open follow-ups: VENUS-34 referer-parity (low-pri), authed valid-id-miss live-probe (structural-only on 3 apps), Elazar venus/pluto aro seating (his confirm).
• wi-cli-venus commented · 2026-06-21
  CLOSE LANDED — SEEN-PASS (pm-llmmsgsrv against hub v2.sqlite): Elazar copy msg id 14518, cursor read_id=14518 -> SEEN (not just delivered/buffered); kind=dm into aro:evolutiva-management = renderable in chat-duo-web, NOT hidden. EVO-19 fully complete: bug found + measured + two-sink fixed fleet-wide + 4/4 verified green + consolidated honest close delivered to Elazar AND confirmed SEEN. Original Elazar work order (real-time 404/error visibility, no more 'having faith') fully discharged for this regression.