Conform Mars monitoring/notifications to fleet scrp- standard (bs-mqmr47bwkk4)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-20
• wi-cli-venus commented · 2026-06-20
  Fleet standard decided in brainstorm bs-mqmr47bwkk4 (2026-06-20, aro:kpi-n-optimization). Mars conformance scope: (1) app-error monitoring routes to aro:mars LIVE PM via hub /aro_config lookup, NOT hardcoded pm-mars-cc - applies to the current applog-mars-cc agent path, which pm-venus clarified migrates into the venus-hosted applog rail as per-app instances scrp-applog_listen-mars (.service Restart=always + WatchdogSec + sd_notify) and scrp-applog_pull-mars (.timer), origin_aro=aro:mars; that unit-side work is OWNED BY nw-venus (rail owner), Mars coordinates. (2) Mars Vercel-side DMs to hub use sender app-mars-notifier (no -cc), origin_aro=aro:mars, live-PM routing. (3) error-digest email: HTML, first line 'Report from: scrp-<sender> | <host> | <ts UTC>'; DM gate error+fatal only, warn/info digest-only; durable watermark independent of hub. Mars ALREADY satisfies: daily heartbeat-at-zero (MARS-148, error-digest-ran), durable store (appEvents + emailOutbox), and scrp-dbperf-mars proves the scrp-/no-cc naming. BLOCKED/SEQUENCED: do not independently rename - the decision mandates a single coordinated migration pass led by bin-whey-cc with verify-before-retire (dual-run, watermark-deduped) for the live error sink. Start when the coordinated pass reaches Mars.
• wi-cli-venus commented · 2026-06-20
  Elazar standing directive 2026-06-20 (fleet, post bs-mqmr47bwkk4): HTTP 404 = ERROR severity, not noise. Rationale: we build the apps/sites from scratch on Vercel - a visitor 404 is a coding bug or dead internal link, NEVER an old bookmark. Mars code change required: 404 appEvents currently logged at warn level -> flip to error so 404 crosses the error+fatal DM gate (immediate DM to aro:mars live PM + HTML email), no threshold/rate-limit, first hit triggers. Pairs with the existing Fly-Solo Error Remediation protocol (evolutiva-pm-commons): on 404 notification, owning agent fixes without Elazar if clear AND reversible (broken route/dead link/misnamed page = common reversible case); only non-reversible/destructive blocks. Coder scope on this WI: (a) locate 404 logging path, set level=error; (b) confirm 404 carries enough context (path, referer) for fly-solo fix. Fleet severity-clause update routed to generalpm; nw-venus tracking on OPS-22, nw-whey on OPS-21.
• wi-cli-venus commented · 2026-06-20
  404 classifier carve-out (generalpm refinement, Elazar-pending-veto but implement): 404=error must NOT let external bot-probe spam bury a real dead link. Discriminator for Mars: 404 -> error + fix-DM + email when EITHER (a) same-origin Referer header (reached via our own internal link = definitionally our bug) OR (b) path matches a defined/sitemap/known-prior-valid route. 404 -> SECURITY log only (no fix-DM, no email) when external/absent referrer AND path matches bot-probe allowlist (/wp-login.php, /.env, /.git, stray .php, etc.). Ambiguity defaults to ERROR (fail toward catching a real dead link); bot-probe patterns are an explicit suppress-allowlist, never the default bucket. Coder scope addition: implement this discriminator at the 404 logging path, not a blanket level=error.
• wi-cli-venus commented · 2026-06-20
  Naming-rule amendment (Elazar, amends bs-mqmr47bwkk4, via generalpm 2026-06-20): prefer DESCRIPTIVE names over abbreviations fleet-wide — spell the function out (applog_listen not applog_lstn, context_monitor not ctx-monitor). Mars legs already comply: sender app-mars-notifier, unit-side scrp-applog_listen-mars / scrp-applog_pull-mars (nw-venus-owned). No terse abbreviations in any Mars sender/unit/script introduced by this WI. Already-descriptive existing names (dbperf, rkhunter) stand.
• wi-cli-venus commented · 2026-06-20
  Email-hygiene acceptance criteria (from the OPS-22 rkhunter false-pass, generalpm 2026-06-20) — apply to Mars error-digest/notifier email: (1) From = dedicated monitoring sender (Mars uses SMTP_FROM verified GWS alias, never Elazar's personal address) consistent across envelope + displayed From; (2) body is a SINGLE clean text/html charset=UTF-8 part — NO duplicate header block (From/To/Subject/Script/Caller) dumped as plain text before <html> (that corrupts MIME → client renders raw tags); headers live only in the MIME header section; first body line per standard = 'Report from: scrp-<sender> | <host> | <ts UTC>' then HTML; (3) sanitize any count/number to a single integer (strip newlines/whitespace at capture) so it can't split Subject/heading. VERIFY the RENDERED output (test send to a maintainer/inbox), not just exit 0 — 'sent' \!= 'renders correctly'. Mars error-digest is already HTML (MARS-148) but must be re-checked against these three at conformance.
• wi-cli-venus commented · 2026-06-20
  Hub-URL standard (Elazar directive 2026-06-20, via pm-llmmsgsrv): ALL scrp- EnvironmentFiles use LLMMSG_HUB_URL=https://llmmsg-hub.pensanta.com (Caddy-fronted HTTPS, fleet standard) — NOT http://127.0.0.1:9703 (localhost, rejected) and NOT hub.pensanta.com:9703 (dead subdomain; MSG-77 DNS repoint CANCELLED). When nw-venus builds the Mars app-plane units (scrp-applog_listen-mars / scrp-applog_pull-mars EnvironmentFiles), HUB_URL must be the llmmsg-hub.pensanta.com HTTPS endpoint. Mars-side Vercel notifier (app-mars-notifier) likewise targets the same hub endpoint.
• wi-cli-venus commented · 2026-06-20
  Telemetry-shape convergence (Elazar fleet directive 2026-06-20, venus-driven, learn-from-mars-and-pluto): standardize viewport telemetry to (a) once-per-LOGIN and (b) STORE role on the row. Mars current state (audit-traced; code UNMOUNTED per MARS-156 freeze): cadence=once-per-browser-SESSION via sessionStorage mars:viewport-logged (per-tab, never resets on logout) - NOT once-per-login; role=NOT on row (only actorUserId; cross-tab needs userRoles JOIN). Mars converge delta (~6 lines, both reversible): (1) ROLE-ON-ROW - add roles:session.roles to the detail object in log-client-env/route.ts:86-92; getSession already returns live userRoles roles (no extra query, satisfies Role Resolution live-DB rule). (2) ONCE-PER-LOGIN - swap per-tab sessionStorage gate for login-scoped localStorage mars:viewport-logged:loginId (loginId=supabase session id, threaded from client) in viewport-telemetry.tsx. HELD: do not dispatch yet - awaiting venus coordinated single-shape spec so mars+pluto+venus adopt identical field name + gate scope. Also gated behind MARS-156 telemetry re-mount decision (collection currently frozen).
• wi-cli-venus commented · 2026-06-20
  DELIVERABLE SHIPPED (1 of several under this WI): email subject de-branding. SHA f182043 / v2.16.78, audit PASS — build READY (dpl_4tzPVcSVfcJCLEitmAG1zibZ9sKt), live /api/app-version flipped 2.16.77→2.16.78, runtime error/fatal/warn=0. Dropped all 8 inline app self-tags across 4 files (weekly-kpi.ts ×4 Mars-emdash→empty, soporte/actions.ts ×2 and support-tickets-digest [Mars Soporte]→Soporte·, error-digest [Mars Errores]→Errores·); withSubjectPrefix() Endodoncia/Mars/ untouched = sole app identifier per fleet one-prefix-owns-branding rule (bs-mqmr47bwkk4). Coverage caveat: subject strings deployed but not exercised by a live send in-window. WI STAYS OPEN — remaining items: 404 warn→error flip + bot-probe carve-out, telemetry v1 conform (push 2 in flight), descriptive-naming, hub-URL standard.
• wi-cli-venus commented · 2026-06-20
  DELIVERABLE SHIPPED (2 of several): telemetry v1 fleet-schema conformance + MARS-156 freeze LIFTED. SHA 04992c7 / v2.16.79, audit PASS — build READY (dpl_ChjCp6tA4726vmnNANnS7baFux1s), live /api/app-version=2.16.79, runtime error/fatal/warn=0, diff-reviewed 4 files. Three changes: (1) roles-on-row = roles:session.roles (live userRoles via getSession, NOT JWT) appended additively to client-env detail, jsonb no new column; (2) once-per-login gate = localStorage mars:client-env:loginId where loginId=JWT session_id decoded client-side, NEVER on row (WI#32 held); (3) re-mount ViewportTelemetry in (protected)/layout. Persist invariant HELD (awaited in-handler logEvent untouched, no verbosity gate — Mars has no pluto-class info-drop). COVERAGE CAVEAT: capture-integrity NOT yet exercised live (authed emit not forceable from audit session) — db armed to confirm first organic post-deploy client-env row carries populated detail.roles (poll 30/60min, lower-bound 2026-06-20 22:56 UTC). WI STAYS OPEN — remaining: 404 warn→error+carve-out, descriptive-naming, hub-URL standard. OPEN FLEET DECISION: band-scheme canonical (Mars numeric-32px vs venus named-breakpoint) — pushed numeric-as-lossless-superset, awaiting 2/3 PM consensus.
• wi-cli-venus commented · 2026-06-20
  Telemetry-v1 capture-integrity CONFIRMED LIVE (closes the deferred verify on 04992c7): real post-deploy client-env/viewport row at 2026-06-20 22:58:07 UTC, verbatim detail = {roles:[alumno], osFamily:iOS, dprBucket:3+, deviceType:mobile, orientation:portrait, viewportBand:384-415}. roles[] populated, info-level row persisted post-conformance → no pluto-class silent-drop, gate+re-mount work, WI#32 held (no loginId on row). db cancelled the 30/60min poll crons (resolved early). Fleet byte-spec finalized + relayed to venus/pluto: detail keys [viewportBand,dprBucket,orientation,deviceType,osFamily,roles]; deviceType {mobile,desktop} tablet→mobile; osFamily {iOS,Android,ChromeOS,Windows,macOS,Linux,Desconocido} first-match Android-before-Linux; bandToBreakpoint mapper boundaries (all ×32). Band-canonical = Mars numeric, 2/3 consensus. Both telemetry deliverables under this WI now DONE+verified; WI stays open for 404-flip + descriptive-naming + hub-URL items.
• wi-cli-venus commented · 2026-06-21
  404-logger COMPLETENESS GAP surfaced during a cross-PM rail test (pm-llmmsgsrv curled /administrarddfd, no row landed). Root cause: the Mars 404 logger fires CLIENT-SIDE on the rendered not-found page, so it has two blind spots that the warn->error flip alone will NOT close: (1) AUTH-GATED routes (/administrar*) hit UNAUTHENTICATED redirect to /login at middleware BEFORE the not-found page renders -> logger never fires -> zero appEvent; (2) any SERVER-SIDE / non-rendering 404 (API routes, non-JS clients, bots) -> no client render -> no log. Confirmed working for NON-gated routes: /informeste, /informest log category=navigation action=404 level=warn in both isAuthenticated true/false. Implication for this WI + MARS-160: flipping warn->error makes RENDERED 404s push, but a dead link behind an auth gate or a server-route 404 still silently escapes the rail. Coder scope add (evaluate, don't assume fix): consider a server-side/middleware-level 404 capture so the error rail sees 404s that never reach the client not-found render. Lower priority than the flip itself but it bounds what 'all 404s push' actually covers - don't claim full 404 coverage on the client-logger alone.
• wi-cli-venus commented · 2026-06-21
  404-classifier REFINEMENT (from a live benign-triage of 4 warn 404s @/informest+/informeste, 00:55 UTC 2026-06-21). The same-origin-referer escalation rule needs a sharper predicate than 'referer host == our host'. Edge case: on direct URL navigation / typo, the browser sets referer == the bad path ITSELF (referer URL equals requestedPath). That is SAME-ORIGIN but is NOT a dead internal link - nobody linked to it, the user typed it. A REAL dead internal link shows referer = a DIFFERENT valid mars page (e.g. referer=/informes, path=/informeste from a broken Link). So the escalate-to-error discriminator must be: referer is same-origin AND referer-path \!= requested-path AND referer-path resolves to a real route. referer==self (or referer-path==requested-path) => treat as direct-nav/typo => stays warn/security-log, NOT an error push. Without this, every user typo of a URL would false-trigger an error DM. Evidence: /informest+/informeste both showed referer==self, authed+unauthed pair = one user typing the URL directly twice; benign, no dead link, closed no-fix. Folds into the bot-probe carve-out already on this WI.
• wi-cli-venus commented · 2026-06-21
  404-capture work now ROLLS UP to parent WI EVO-12 (pm-llmmsgsrv, fleet-confirmed 2026-06-21: mars+pluto+venus+ayudarg all client-side-only 404 capture, same 3 blind spots, 404=warn below rail gate). EVO-12 holds the canonical spec = server-side 404 capture + honor the ratified push/digest tier (bs-mqn2ze006f7) + bot-probe carve-out + referer-discriminator (referer-path \!= requested-path; see prior comment). Mars's per-app retrofit leg is HELD - do NOT start implementation until pm-llmmsgsrv greenlights on Elazar's priority call. Scope split for clarity: the simple warn->error level FLIP is the Mars-local quick win still under this WI; the SERVER-SIDE capture that closes the 3 blind spots is the EVO-12 leg (bigger, gated). Don't conflate or double-implement. The classifier-refinement + bot-probe carve-out notes above feed EVO-12's canonical spec.
• wi-cli-venus commented · 4w ago
  Classifier-gap evidence (2026-07-20, coder-verified read-only): two navigation/404 warns (/mi-cur id=fe939edd @18:29:15, /m id=e938d81b @18:29:16) were an external WhatsApp link-preview crawler (UA=WhatsApp/2.23.20.0 both, referrer=null, no session, softNav=false full-server-nav, same IP 181.9.209.217, classifiedReason=genuine-bad-route, alert=false). Benign-closed. BUT they landed tierLevel=warn, not info — per the error-alerting suppress standard (external bot/scanner-UA 404 -> info), the bot-UA classifier isn't catching LINK-PREVIEW crawler UAs. Recommend extending the bot-UA match set to include link-preview/social crawlers: WhatsApp, facebookexternalhit, Twitterbot, Slackbot, TelegramBot, Discordbot, LinkedInBot, Applebot, etc. These fetch malformed/truncated shared links (partial-prefix paths like /mi-cur, /m) and should be info-tier digest, not warn. Low-risk read-layer classifier tweak; folds into the MARS-173 suppress-conform work.