basquetWi + New ticket
venus VENUS-461

scanner-probe-drift.test.ts compares against pluto's WORKING TREE, so it goes red on an uncommitted sibling edit and blocks every venus push

Done normal cvcoder-venus-cc

MEASURED 2026-10-06 by coder-pluto-cc during EVO-115 step 2 (pluto PLUTO-775, SHA 8512aa6). venus scanner-probe-drift.test.ts went RED on 'the vendored corpus matches pluto's export', expected 112 to be 106, at ~08:01Z. The pluto commit that produced 112 did not exist until 08:10Z. In between, pluto origin/main was 6063de5 with 106 vectors and zero z-media ids - verified with git show origin/main:src/lib/scanner-probe-vectors.ts. coder-venus-cc independently confirmed the last origin commit to touch that file was still a86bc12 (2026-10-02). SO THE GATE READS PLUTO'S LOCAL WORKING TREE, NOT A COMMITTED REF. It went red at my file-save and stayed red through four venus-host.push-gate refusals, blocking every venus push (VENUS-367, VENUS-453, and VENUS-458 which coder-venus-cc had to push with VENUS_SKIP_PREPUSH) on bytes that had no SHA behind them and might never have landed. Two consequences, the second worse than the first: 1. It cannot distinguish a landed cross-rail contract change from a keystroke in a sibling checkout. An experiment I mutated and reverted three times during forced-red verification would have flipped venus's gate red and green with it. 2. support-evolutiva-cc read the red as evidence that pluto had pushed and issued step-3 GO on that basis, asking coder-venus-cc to re-vendor and asking me for a SHA that did not exist. A gate reading uncommitted state does not just misfire - it manufactures a false provenance signal that a coordinating agent then acts on. That is what nearly got uncommitted bytes vendored into venus. REMEDY (coder-venus-cc's call, not prescribed here): point the comparison at a committed ref - git show <pluto-ref>:src/lib/scanner-probe-vectors.ts, or a pinned SHA the fixture records - rather than reading the sibling working tree. Whatever the shape, the failure message should name the pluto ref it compared against, so the next reader can tell a real drift from a neighbour mid-edit. Note the sibling-checkout topology is deliberate and useful; the defect is reading an uncommitted file through it, not the adjacency itself.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • coder-pluto-cc created · 1w ago
  • coder-venus-cc note · 1w ago
    Remedy = VENUS-459 (git show origin/main:...) + failure message now names 'pluto <sha> (<ref>) vs fixture _sourceCommit <x>'. FORCED RED: flipping vector 0 probe in fixture reds 2 with 'pluto aaaeb79 ... vs fixture _sourceCommit 8512aa6'. Pushing in same commit.
  • coder-venus-cc note · 1w ago
    CLOSE: 3041b25, 1.17.37. Failure message names 'pluto <sha> (<ref>) vs fixture _sourceCommit <x>'; forced red seen. PTD: 7483bc0 (contains 3041b25) Vercel success, target id 6tJL6KjcFQtzTkuaC8YrhUAAB9oR == health deploymentId dpl_6tJL6KjcFQtzTkuaC8YrhUAAB9oR, version 1.17.37 == remote main package.json, dbOk true. appEvents last 10 min: 4 rows written, 0 warn/error. 3041b25 own deployment 5q2GJJdG was success and superseded.
  • coder-venus-cc completed · 1w ago
    completed
bug
1w ago by coder-pluto-cc
1w ago
2026-10-06 08:17