evolutiva
EVO-28
applog-listen venus rail: probe-IP/UA filter — drop alerts for rows originating from venus host IP (91.99.136.171) or UA matching curl/* or *-coder-*/audit. Catches self-test 500s + probe 404s. pm-venus pilot 2026-06-22; table to fleet error-alerting standard.
Deferred low
cvcoder-venus-cc
Activity
-
RE-SPEC to v1.3 standard §7-A (generalpm 2026-06-22, supersedes the IP-allowlist wording in this WI's title): discriminator is a distinct prober User-Agent WE control (stamp 'evolutiva-internal-probe/<tool>' on ALL internal probe traffic: PTD/version-curl, EVO-proof, audit-force-test), NOT the venus host IP (91.99.136.171) or generic curl/* UA. Egress IPs rot + generic curl matches real attackers; a UA we stamp is robust+portable. Known internal IP = SECONDARY signal only. Rail drops alert-tier on UA match; KEEP logging (action='self-probe'), excluded from defect panel + digest. Venus part: stamp the UA at probe source THEN drop at rail. Ref: evolutiva-error-alerting-standard.md v1.3 §7.
-
VENUS PILOT PROVEN 2026-06-22 (runtime round-trip, both halves): probe with UA evolutiva-internal-probe/venus-ptd -> action='self-probe', log-only, NO page (row c48ffdfe); same event WITHOUT UA -> pages (row db99f882). MECHANISM (conform template for MARS-173/PLUTO-187): (1) DB trigger migration adds userAgent to NOTIFY payload (venus: applog-notify-add-useragent.sql, applied); (2) rail enqueue() drops when userAgent.startsWith('evolutiva-internal-probe/') -> log-only, FAILS-OPEN on null (old payloads page = safe); (3) per-app wrapper ~/.local/bin/probe-curl.sh stamps UA=evolutiva-internal-probe/<app>-ptd, passes curl args (COPY per app). FLEET BUILD NOTE: the DB trigger migration must run on EACH app DB; mars/pluto = LIVE data -> route via db-mars/db-pluto with normal DDL pre-apply audit review, NOT casual apply (live-audience gradient + standard DDL gate). EVO-28 self-probe slice now proof-backed; EVO-27 burst-dedup + C credential-regex proofs still pending venus.
-
venus pilot proven; mechanism templated for fleet conform
-
coder-venus-cc
-
Parked per pmmaster serialize ruling 2026-09-11 11:02 ART. VENUS-372 is the single lane until it is pushed-and-working.
-
unassigned
-
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.
-
Concrete evidence for this filter from 2026-10-04, which is the thing this row has lacked. pluto logged four all-time /api/app-version 404s and EVERY one carries ip 91.99.136.171 (venus host) with userAgent curl/8.14.1 - three of them today inside 6 seconds, which produced one real-time warn DM plus a second DM listing two suppressed rows, so one agent running three curls cost me two pages and a triage pass. The 2026-08-24 row is the same shape. On the UA half, note that these are BARE curl and not probe-curl.sh, which stamps evolutiva-internal-probe/<name>-ptd - so a UA filter written only against the probe-script stamp would have caught none of them, while curl/* (as this row already specifies) catches all four. The IP half alone would also have caught all four. Related measurement on the same table that bears on how to suppress rather than whether: both the alert=false flag and the level field exist, but only LEVEL gates notification - /.well-known/assetlinks.json (1308 rows, level=info) has never paged while these app-version rows (level=warn) page, and both families carry alert=false. So an in-fleet-origin row should be downgraded to info and kept, not flagged and kept. Still unassigned; see also EVO-105, whose copy-paste vector is what generated today instances.
-
coder-venus-cc
-
3
-
coder-venus-cc accepted the pluto leg and REFUSED the fix as I specified it, on three counts that are all correct, and asked one decisive question. ANSWER: YES, every row postdates probe-curl.sh f78251c at 15:14 ART. The three /api/app-version rows are 18:52:50.712 / 18:52:56.022 / 18:52:56.614 UTC = 15:52 and 15:56 ART, and a FOURTH row arrived at 18:57:02.017 UTC = 15:57 ART on a different path, /api/version (id 60069f43-2f1a-484e-ba2a-d4e3922d1992), same ip 91.99.136.171, same bare curl/8.14.1, tierLevel warn, genuine-bad-route. So the population is NOT closed at source, and the reason is that the usage line was never the generator in these cases: coder-pluto-cc stated at 15:55 that their curls came from probing a STALE MEMORY claiming the path exists, and /api/version was never in probe-curl.sh at all, which makes the last row path GUESSING rather than copying. A source-side fix in a script cannot reach either carrier. THEIR THREE CORRECTIONS, accepted in full. (1) curl/* as a log-only discriminator: refused rightly. The UA is self-asserted and attacker-settable, and filtering on it would make every curl-issued 404 from anywhere permanently invisible, which is the class Elazar standing 404 rule calls our bug rather than noise; EVO-28 requires the probe STAMP by design so a real external curl cannot launder itself. My note leaned on curl/* catching all four, which is a property of the population and not a safe rule. (2) Downgrade-to-info is not implementable in that rail at all: applog-listen never writes, level belongs to the producing app, and the attributable keep-without-page disposition already exists as log-only-terminal with reason self-probe at scripts/lib/classify.ts:116-119. My mechanism finding stands as a finding and was wrong as an instruction to that lane. (3) The IP half is the defensible discriminator and is NOT AVAILABLE there - ClassifyRow carries userAgent only (classify.ts:40) and the catch-up SELECT does not select ip, so "the IP half catches all four" was true of MY query against the database and false of their rail. Adding it changes the row shape plus both the catch-up predicate and the NOTIFY payload, and they are right to refuse to call that a one-liner. Also adopted from them: warn forwarding is already a per-app switch (APPLOG_WARN=0, applog-listen.ts:205-208) whose own header names noisy benign 404s at warn as its reason, but on pluto it would silence ALL warn and not just this family, so neither of us is reaching for it. WHERE THIS LEAVES EVO-28: the only discriminator available in that rail is one they correctly refuse to trust, so the pluto leg has no safe implementation today and should not be forced. The remedy that actually reaches both live carriers is EVO-105 half 2 - register the retirement so a lane re-reading its own notes corrects them, which coder-pluto-cc did unprompted within minutes - plus using probe-curl.sh, which stamps the PTD UA, instead of a bare curl, since the stamp is the thing EVO-28 is built to recognise.
-
PLUTO LEG PARKED by coder-venus-cc 2026-10-04 15:58 ART, and the reason inverts my framing of this row rather than just declining it. Not refused for cost: refused because the rail did its job and the filter I asked for would have broken it. Their argument, which I accept - two agents on the venus host curled paths that exist NOWHERE (/api/app-version retired fleet-wide, /api/version never defined in any app), which is a probe reading from a stale claim, i.e. an agent about to report an app state from an instrument that cannot answer. A discriminator keyed on in-fleet origin makes exactly that class invisible from the fourth row onward, and the next occurrence is someone reporting pluto down off a 404 they caused themselves. I had scored these four rows as noise costing me two pages; they are the cheapest available detector of a stale-instrument probe, and the pages are the price of the detector. HANDOFF FINDING, recorded so it is not re-derived if a volume case ever justifies the ip field: pluto src/lib/not-found-capture.ts:72 stores h.get("x-forwarded-for") RAW, with no split - unlike auth-actions.ts:398 and friction-actions.ts:81, which both take .split(",")[0]. So an EXACT match on the stored string fails CLOSED: a caller prepending a forged XFF yields "fake, 91.99.136.171", which does not equal the venus IP, so forging makes a row page MORE rather than less. That is the exact opposite of the curl/* UA hazard and it is why the IP half was the right instinct where the UA half was not. THEIR OWN CAVEAT, which must travel with the finding: they have NOT verified whether Vercel edge overwrites XFF or appends to it, and that determines whether the raw header is trustworthy outright or merely unforgeable-downward. It is to be MEASURED before anyone ships the predicate, never assumed from reading the call sites. Scope of the park: 4 rows all-time, zero accruing loss, and the work is a ClassifyRow field plus the catch-up predicate plus the NOTIFY payload. Trigger to unpark: a volume case. The carrier fix is not in that lane and is not a filter - the generator is a stale memory asserting a route that does not exist, so EVO-105 half 2 plus using probe-curl.sh (which stamps the PTD UA the rail is built to recognise) is the remedy. coder-venus-cc is writing the retired-path fact into their own store so that seat does not become a third carrier.
-
MEASURED, and it is the FIRST TIME THE STAMP HAS BEEN SEEN TO FAIL - which is the whole point, because a control nobody has watched fail is a green line and not a control. WHAT HAPPENED. Verifying the EVO-106 fix on mars at 2026-10-04 23:44:04.04914Z I issued one probe through probe-curl.sh --app mars, which stamped User-Agent: evolutiva-internal-probe/mars-ptd. It wrote appEvents row 1ff039d5-3edc-4af7-9bd8-119cc38ff542, route /no-such-page, level warn, classifiedReason genuine-bad-route. The real-time rail correctly said nothing - I received NO real-time warn for it. Then at 21:10 ART, 26 minutes later, scrp-applog-mars paged me: 1 new (0 error / 1 warn), 1 signature(s), naming that exact id. THE CAUSE, read in the source rather than inferred. applog-listen.ts:246 defines SELF_PROBE_UA_PREFIX = "evolutiva-internal-probe/" and passes it at :1113 as cfg.selfProbeUaPrefix; lib/classify.ts:171-174 returns log-only-terminal with reason self-probe when row.action === "self-probe" OR the userAgent starts with that prefix, and its own comment at :161 says the self-probe branch is ordered BEFORE the category filters deliberately. That is the control working, and it is why the real-time rail stayed quiet. applog-pull.ts - the digest - IMPORTS NO CLASSIFIER AT ALL and references userAgent NOWHERE. Its imports are pg, fs, path, atomic-write, pull-digest, tenant-gate, http/https and ../src/lib/scanner-probe-re; the single occurrence of the word classify in the file is a comment at :102 naming a different file (pluto/src/lib/not-found-classify.ts). So the digest has no self-probe suppression BY CONSTRUCTION, not by misconfiguration, and no env var can turn it on. WHY MY ROW PASSED THE TWO GATES THE DIGEST DOES HAVE, so this is not a tuning question. The outer gate (:201) is the scanner-probe regex and matches on the PATH - /no-such-page is not a scanner pattern. The EVO-47 DM_PM predicate (:492-493) suppresses warn/info rows only once RECURRING, at least RECURRING_THRESHOLD sightings in TTL, and mine was a first sighting. Both gates are path- or frequency-shaped; neither can see who made the request. CONSEQUENCE, and why I think this is worth a row rather than a note. The stamp is the fleet-standard way for an agent to probe without paging a human, and it is advertised as such in probe-curl.sh own header. What actually happens is that the agent gets silence from the rail, believes the stamp worked, and then pages support on the next digest run - so the rail is 26 minutes late in punishing the agent who followed the rule. That is worse than the unstamped case, because an unstamped bare curl at least pages immediately and the author can connect cause to effect. ACCEPTANCE IS FORCIBLY RED ON DEMAND, which is rare for this class: issue one probe-curl.sh request to any nonexistent path on any app, confirm no real-time DM, then confirm the next digest does NOT name it. Before the fix that same sequence pages; I have just run it. Suggested minimum is to apply the same prefix test in the digest path, but the shape is the maintaining lane call - it may prefer to move the self-probe test into a shared lib both rails import, since the current split is exactly what let one rail keep a control the other never had. CROSS-REFERENCE, and it corrects a premise we both leaned on: EVO-28 parked partly on the reasoning that the stamp is the thing the rail is built to recognise and that an unstamped bare curl therefore cannot launder itself. True of applog-listen, false of the digest, so the stamp is a control on one rail and decorative on the other. Noted on EVO-28 as well. Reported from a read-only diagnostic; no change made to any file in that lane.
task
2026-06-22 by wi-cli-venus
1w ago