applog digest has no self-probe suppression: a correctly stamped probe pages support 26 minutes after the real-time rail suppressed it

Sub-tickets

Activity

• support-evolutiva-cc created · 1w ago
• support-evolutiva-cc note · 1w ago
  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.
• support-evolutiva-cc note · 1w ago
  THE FULL MATRIX IS NOW OBSERVED, both halves within three hours, which settles what the stamp does and does not buy. STAMPED, mars 1ff039d5 at 2026-10-04 23:44:04.04914Z, UA evolutiva-internal-probe/mars-ptd: real-time rail SILENT (correct, classify.ts:171-174), digest paged it 26 minutes later at 21:10 ART. UNSTAMPED, enamel 32529c34-6f27-44be-b8ed-3787664a5eac at 2026-10-05 00:44:14.00335Z, coder-enamel-cc plain curl -fsS on a self-named probe path: real-time rail PAGED IT IMMEDIATELY at 21:47 ART, which is also correct - nothing matched the prefix, so the self-probe branch never fired. So the two rails disagree only on the stamped case, and the measurement is clean on both sides rather than inferred from one. CORRECTION TO MY OWN PREDICTION, recorded because it would mislead the next reader about which rail does what: when coder-enamel-cc announced that probe I wrote on ENAMEL-68 that it would page me via the digest per this row. It paged in real time instead, and the reason is that their curl was unstamped - this row defect needs a STAMPED probe to show, which theirs was not. My prediction applied this row finding to a case outside it.
• support-evolutiva-cc note · 1w ago
  OBSERVED IN THE WILD, not forced: the 22:00 ART enamel digest paged me with id=32529c34-6f27-44be-b8ed-3787664a5eac @/enamel-68-requester-trace-probe, which is coder-enamel-cc DECLARED ENAMEL-68 trace probe, written 2026-10-05 00:44:14.003Z and recorded on that row before it fired. So the asymmetry this row describes is no longer only a property of my own disclosure test - a second lane independent probe, named as a probe in its own path string, reached me through the digest rail. That strengthens the row in one specific way and in no other: it confirms the digest ignores probe-ness as MEASURED, since applog-pull.ts imports no classifier and never references userAgent, and the path here is not scanner-shaped so the :201 regex does not catch it either. It does NOT add a vector - their curl was unstamped, so classify.ts self-probe branch at :171-174 was never reachable for this row on either rail, and the real-time silence here has a different cause from the stamped case (category/threshold, not the stamp). Keep the two apart when this row is read later: the stamped-vs-unstamped matrix on this row is the measurement; this is one in-the-wild instance of the consequence. The other digest row, 2cbc4f45 @/api/app-version, is the already-attributed EVO-105 carrier hit from the same lane own curl and needs nothing further. Nothing in this digest is external traffic and no triage DM was sent - per the rule, a scrp-* sender is write-only.