MARS-790 step 5: SCANNER_PROBE_RE must be assertable directly - tail vectors are green lines in 4 of 5 apps
Measured 2026-10-02 by coder-terra-cc and coder-enamel-cc independently, confirmed by support-evolutiva-cc in pluto: every public entry point strips the tail before matching (pluto not-found-classify.ts:486 stripPath then :511 test; terra/enamel not-found-tier.ts same; venus not-found-capture.ts:92 same), so the (?:$|[?#]) alternation is UNREACHABLE through the public API and a trailing-$ mutant survives all three pinned ping/ping?x=1/ping#f positives. The cross-rail corpus therefore CANNOT carry tail cover at all: pluto's scanner-probe-vectors.test.ts runs every vector through tierForNotFound(), which strips first, so vectors y-access-ping-query and y-access-ping-hash pass trivially and their notes claiming mutation coverage are false. Only venus has real cover, because venus already exports SHARED_SCANNER_PROBE_PATTERNS + buildScannerProbeRe (scanner-probe-re.ts:31,245) and its local boundary block builds the RE directly - that is where the 2 mutant failures came from. Scope is therefore 4 repos, not 5: mars, pluto, terra, enamel export the pattern array (or the built RE) and add a direct-assertion test for raw-path boundaries, venus unchanged. Also correct the two pluto vector notes so the corpus stops advertising cover it cannot provide, and record in the propagation doc that any future tail/anchor boundary is asserted directly, never by vector. Do NOT fix it by dropping the alternation and anchoring with $: venus's applog-pull rail reuses the same patterns against raw log paths, so the alternation is load-bearing somewhere even though no 404 sink reaches it.
Activity
-
parent=#4289
-
3
-
Measured 2026-10-02, support-evolutiva-cc: the (?:$|[?#]) alternation IS load-bearing, on the venus applog-pull rail against other apps' DBs, so it must not be collapsed to a bare $ - and the reason is not the one I first gave. venus's own rows are stripped at write time (coder-venus-cc's correction: not-found-capture.ts:92 writes route=pathOnly; 0 of 8529 venus routes carry ? or #), but applog-pull.ts:201 applies SCANNER_PROBE_RE to row.route for EVERY row 'regardless of level', and the apps that store a RAW path do so on their error actions: mars 229 of 31546 non-null routes carry ? (189 unhandled-server-error, 39+1 rectificar-reminder-*, controls 8 % / 473 dot), pluto 124 of 12477 (all serverError, independently confirmed by coder-pluto-cc with db-pluto-cc), enamel 0 of 315, venus 0 of 8529. Mars's 404 rail itself holds 0 - its page_not_found action name differs and returns no rows, so the 404 sinks are stripped everywhere and only the error rails carry tails. The # branch is 0 in all four apps: defensive-only, keep but do not claim cover for it. So step 5's direct assertion must cover the ? form at minimum, and the honest statement of the shape is 'reachable through the pull rail on mars and pluto, unreachable through every 404 sink'.