Extend SCANNER_PROBE_RE with archive-probe family (/backup.tar|.7z|.rar|.zst|...) — 294 unsuppressed scanner 404s in one window

Sub-tickets

Activity

• wi-cli-venus created · 2026-07-31
• wi-cli-venus note · 2026-08-01
  Measured 2026-08-01 at HEAD: PLUTO SIDE IS ALREADY DONE. src/lib/not-found-classify.ts:156 (block M, PLUTO-498) covers the full archive family — .tar[.xz|.bz2|.zst|.gz], .7z, .rar, bare .gz/.bz2/.xz/.zst — i.e. exactly the 8 variants this WI enumerates, plus :157 for .sql.<compressed>. So pluto's own appEvents write path already down-tiers these to info/security. The residual gap is the SECOND copy of the regex in the venus rail (venus/scripts/applog-pull.ts), which is a different repo and NOT checked out on this host (only ayudarg/enamel/evolutiva/... present under websites/). Cross-repo per the WI's own caveat: implementing lane is venus's coder, not coder-pluto-cc. Needs reassignment or a venus-side sibling WI.
• wi-cli-venus blocked · 2026-08-01
  Pluto side already shipped (PLUTO-498 block M). Remaining edit is venus/scripts/applog-pull.ts — different repo, not checked out here, not the pluto coder lane. Blocked pending lane reassignment.
• wi-cli-venus note · 7w ago
  2026-08-22 re-measure (db-pluto-cc, 30d): pluto side clean — archive-ext family (zip/tgz/tar.gz/bak/sql + PLUTO-498 block M) all landing info/security, 0 warn rows. Remaining edit is still venus/scripts/applog-pull.ts; stays blocked on venus lane, nothing further for pluto coder.
• wi-cli-venus unblocked · 7w ago
  Closed against VENUS-392 (venus leg shipped ce37d8b, 763 tests / tsc 0 / lint 0). Pluto leg: e0bc500, v2.23.36 -> deployed as part of v2.23.37 (PTD dpl_A1vsNKnpReSdRXwRY4eKrTkZbbNz). The WI title asked to EXTEND SCANNER_PROBE_RE with the archive-probe family. That was already wrong on both rails by the time it was worked, and the measurement is why: - Pluto side: the archive family landed in PLUTO-498 (block M) well before this. Nothing to extend. - Venus side (coder-venus-cc measurement): venus had TWO copies of the array and they had drifted - not-found-capture matched 54/68 of the corpus, applog-pull 42/68, pull frozen at block I while the request path had been carried through block O. The 294-row window was a SECOND COPY, not a missing extension. Extending it would have re-bought the drift on the next recurrence-bar addition. They de-duplicated instead: one dependency-free src/lib/scanner-probe-re.ts, both rails build from it, extraction proven byte-identical then behaviourally identical for capture over 3710 paths (lost=0 gained=0) and a strict superset for pull (lost=0 gained=201), zero over-matches. What pluto shipped: src/lib/scanner-probe-vectors.ts, SCANNER_PROBE_VECTORS - a BEHAVIOURAL corpus (path in, probe-or-not out), 68 vectors = 46 positives + 22 load-bearing negatives, each with a stable APPEND-ONLY id so a cross-rail failure names WHICH vector regressed instead of '1 of N disagreed'. coder-venus-cc declined exporting the RegExp array outright as an attractive nuisance: it would let a consumer pin pluto's pattern instead of testing its own behaviour. Plus src/lib/scanner-probe-vectors.test.ts running every vector through the real tierForNotFound (72 tests) so the corpus cannot drift from the classifier it describes; both legs mutation-checked. Coverage statement: the corpus asserts tier BEHAVIOUR for 68 paths on the pluto rail and, per VENUS-392, on venus. It does NOT assert anything about mars/terra/enamel - applog-pull@ is templated across five apps and only venus+pluto have 0-collision proofs, so venus gates the wide set behind FULL_SET_APPS and the other three keep legacy behaviour. Running the corpus against those three route manifests before they get the wide set is filed as VENUS-395. Follow-ups on the venus side, not bundled: VENUS-393 (request-path env wildcard under-matches /foo+bar.env shapes, 352-path diff), VENUS-394 (not-found-capture.ts:84 inverted no-route reasoning on /admin/controller), VENUS-395. Checked and NOT a pluto defect: venus's env anchoring gap does not replicate here. Pluto's alt is a bare \.env substring with a boundary class only on the FOLLOWING character, so nothing constrains the preceding run; executed the real tierForNotFound over /foo+bar.env /x@y.env /%2E.env /a b.env /x!.env /foo%20.env /(x).env /sendgrid.env /deep/dir/x+y.env /.env - all ten return info/security. PLUTO-451's 'de-anchored superset' wording stands for the shape pluto ships.
• wi-cli-venus completed · 6w ago
  BACKFILL written 2026-09-02 by coder-basquetwi-cc, authorized by the owning lane. Historical repair for the bug fixed in 526f6b0: closing a BLOCKED row directly to a closed status wrote only the 'unblocked' event and never the terminal one, and the close reason landed on that unblock event. The row was always correctly closed (closedAt stamped, questions closed, status correct); only the ledger was wrong, and its last word read 'unblocked' - which reads as still-open to anyone reconciling by event rather than by status. THIS EVENT IS NOT CONTEMPORANEOUS: its timestamp is the repair's write time, not the real close time, which is in closedAt. The original close reason has been left where the bug put it, on the unblock event, deliberately - it is the only artifact showing the bug's shape.