Treat 404 as error: emit level=error on 404 + email+DM + feed auto-fix protocol (Elazar 404-directive, kpi-n-optimization)

Sub-tickets

Activity

• wi-cli-venus created · 2026-06-20
• wi-cli-venus commented · 2026-06-20
  SCOPED (Elazar 404-directive via generalpm relay; matches the referer-gate I flagged to Elazar). Two parts: (1) EMIT: Pluto 404s currently do NOT emit level=error → never enter the alert pipeline. not-found handler/middleware must classify + emit so 404s ride the error+fatal path (email+DM to aro:pluto live PM). (2) CLASSIFY (the anti-flood gate): route Pluto owns / internal-referrer / in-sitemap 404 → ERROR → email+DM → auto-fix autonomously IF clear+reversible (restore route / repair link / add redirect); non-reversible/destructive → block to PM/Elazar. External scanner junk-paths (/wp-login.php, /.env, /.git, stray .php, no-referrer probes) → security log (appEvents malicious/security), NOT the fix-DM — so bot spam can't bury a real dead link. Auto-fix protocol = the standing mars/venus/pluto one: clear+reversible → ship solo, report after; non-reversible/destructive → block. Related: PLUTO-157 (venus rail delivers the DM; this WI is the Pluto-app-side classify+emit). Pending Elazar veto on the carve-out.
• wi-cli-venus blocked · 2026-06-20
  Pending (1) Elazar's ruling on bot-probe 404s (no-filter vs security-log carve-out — pm-venus driving the fleet confirm; same-origin/internal-link 404=bug is settled), and (2) the venus rail delivery template + PLUTO-157 (rail delivers the DM). Internal-404 classify+emit is actionable once those land; do not dispatch coder before then.
• wi-cli-venus commented · 2026-06-20
  ALIGNED to FINAL 404 spec (pm-venus, fleet-converged): own-route/internal/sitemap/own-domain-referrer 404 → ERROR, FIRST-HIT no-threshold → DM+email+auto-fix (reversible solo, irreversible/destructive blocks); external scanner/bot probes to never-defined paths (/wp-login.php,/.env,/.git,stray .php) → SECURITY LOG only, no fix-DM; AMBIGUOUS → default to error. Implement-as-default (Elazar may veto). Still blocked on venus rail template + PLUTO-157.
• wi-cli-venus commented · 2026-06-20
  DEPENDENCY w/ PLUTO-160 (minimization cull): 404 must KEEP ip+userAgent+referrer — PLUTO-158 classification (own-route/dead-link vs external bot-probe) requires them. PLUTO-160's ip/UA drop EXCLUDES 404 for this reason. Same file surface (logger.ts + log-404 route) → implement together to avoid one WI stripping a field the other needs.
• wi-cli-venus unblocked · 5w ago
  PARTIAL RELEASE, ruled by pmmaster-evolutiva-cc under Elazar's delegated GO. Blocker (1) was Elazar's ruling on bot-probe 404s. RULING: bot-probe/scanner 404s are security-log only - never email, never DM. Rationale: an alert that fires on internet background noise gets muted, and a muted alert is the blind spot the 404-directive exists to remove; mars already carries SCANNER_PROBE_RE for exactly this split. Same-origin/internal-link 404=bug was already settled, so the internal-404 classify+emit half is ACTIONABLE NOW and should not wait on blocker (2), the venus rail delivery template. Build classify+emit; wire delivery when PLUTO-157 lands.
• wi-cli-venus assigned · 4w ago
  unassigned
• wi-cli-venus statusChanged · 4w ago
  Unassigned and moved to backlog by pmmaster-evolutiva-cc 2026-09-12. The assigned agent did not exist: coder-venus-cc, db-venus-cc, coder-pluto-cc and db-pluto-cc are all absent from the hub roster and have no tmux pane, and venus and pluto currently have no staffed coder or db lane at all. A todo or inProgress row against an absent assignee reads as staffed-and-underway and is neither, so the status was a lie about this row rather than a claim about the work. The work itself is untouched and the priority is unchanged. Cause of the cluster, and it is a fleet-wide pattern rather than a bookkeeping slip: five auto-succession call sites plus resolvePm can leave a row pointing at an agent that has been deregistered, and nothing reconciles an assignee against the roster afterwards. Filed context: 178 rows across these four names, of which 23 carried a non-backlog status. Restaffing venus and pluto is Elazars decision, not a reassignment I can make.
• pmmaster-evolutiva-cc completed · 1w ago
  Superseded by PLUTO-171/165/182/184/442/653/689: 404 classify-by-shape + level=error on genuine-bad-route + scanner-probe carve-out already shipped and audited. Remaining literal-ask gap (email+DM firing) is NOTFOUND_PAGING_ENABLED, default-off by design (PLUTO-165 ruling) pending 3 fleet gates: skew-guard audit PASS, Elazar Q3 paging-policy ratify, Q4 alerts@ send-as ruling. Mirror flip-ticket filed for when those gates clear.