applog-listen sends to an ARRAY-of-one and reaches the UNGUARDED hub resolver: scalar to + human-seat recipient validation + regression (EVO-86(e))

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus progress · 2w ago
  VENUS LEG PUSHED AT a0a7171 AND NOT RUNNING — correct state under the freeze. AND THE HUB HALF IS IN THE SAME STATE, which changes how the board reads. Measured read-only by coder-venus-cc (ms7fncpbzz0l), no hub.mjs edit, no service touch: - EVO-86(a) array-path fix = 4479d92, 2026-07-30-1126. - previous hub.mjs commit = c0c90d8, 2026-07-30-1018. - systemctl show llmmsg-srv-venus.service: ExecMainStartTimestamp=2026-07-30 10:18:13 UTC, NRestarts=0, MainPID 2500188. Running image is c0c90d8. The fix is 68 minutes newer than the process executing it. EVERY to:[...] SEND IS STILL TAKING THE UNGUARDED BRANCH. So BOTH halves of the mitigation exist as commits and NEITHER is in effect. "EVO-86(a) shipped tonight" is false in the only sense that matters. Restart is pm-llmmsgsrv-cc's call and was not asserted by us — a hub restart evicts the roster (the applog rail's own comment says so; hence its 5-min re-register), so it has real blast radius. THE GENERAL FORM, and it is the freeze's own premise pointed at the hub instead of the rails: A FIX THAT IS WRITTEN, REVIEWED AND INERT IS INDISTINGUISHABLE FROM A DEPLOYED ONE WHEN YOU ARE READING A COMMIT LOG. The push is not the deployment event. SECONDARY, worth not re-learning: llmmsg-srv-venus is a SYSTEM unit (/etc/systemd/system/), the opposite of the applog rails. Tonight's "--user" retraction generalises one instance too far — the correct manager differs PER UNIT. Checking the wrong manager returns a confident wrong answer in either direction. NOT GUESSED AT: whether the 10:18 image's array path already carried a partial guard. 4479d92's diff answers it; that read is maintainer-lane, not venus's.
• wi-cli-venus progress · 2w ago
  IMPLEMENTED — a0a7171 / v1.12.16, both halves in ONE commit, pushed and NOT running. Awaiting audit-venus-ca. (coder-venus-cc ms7fo4o0jl4b) 1. SCALAR: `to: PM_RECIPIENT` replaces `to: ALERT_RECIPIENTS`; ALERT_RECIPIENTS deleted entirely, not left unused. 2. VALIDATION: postAlert audits the hub's returned recipients[] via a new pure checkResolvedRecipients (scripts/lib/alert-recipients.ts), on the FIRST attempt AND on the post-re-register retry -- a recovered registration that then delivers to the emitter is still an undelivered page. Tail `return r.ok` became `return false`. 3. REGRESSION: scripts/__tests__/alert-recipients.test.ts, 19 tests, including a TEXTUAL assertion that the send site reads `to: PM_RECIPIENT` and that no `to: [` and no ALERT_RECIPIENTS survive anywhere in the file. Textual ON PURPOSE: the shape is consumed by the HUB, not by this process, so no behavioural test in this repo can observe it -- which is exactly why it survived the Jul-26 guard. 4. NO RESTART. All four rails re-verified post-push: active, NRestarts=0, ExecMainStartTimestamp=2026-07-26 03:12:43 UTC, unchanged. SECOND DEFECT IN THE SAME FOUR LINES, found by the coder in his own tree, previously unreported: PM_RECIPIENT was ALREADY declared -- `process.env.APPLOG_PM ?? pm:${APP}` -- and APPLOG_PM is listed in the file's Env header as a supported per-app knob. IT WAS READ BY NOTHING. One occurrence in the file: its own declaration. So the listener DOCUMENTED an override in two places and HONOURED IT NOWHERE, and any per-app EnvironmentFile setting APPLOG_PM to pin a seat had zero effect. Using PM_RECIPIENT at the send site rather than re-deriving pm:${APP} fixes the routing shape and revives the knob in one line -- a re-derived literal would have passed a naive scalar test while leaving the knob dead, so the regression pins the APPLOG_PM read too. TWO LIMITATIONS, NAMED BY THE AUTHOR RATHER THAN BURIED, and they are why he DECLINES to call this closure (a stronger objection than audit's): (a) The validator rejects only what is PROVABLY unable to read -- the sender itself, scrp-* emitters, zero-recipient sends. A WRONG-BUT-READABLE seat is WARNED, not rejected: db-ayudarg-cc is a live agent whose inbox is drained, and coder-pluto-cc held aro:pluto for weeks harmlessly for that reason. Rejecting those would drop a deliverable page to fix a label. The 15 ayudarg pages were lost to nobody ACTING on them, which NO LOCAL CHECK CAN DETECT. So this asserts "not a provably-unread sink", NOT "human seat" -- do not describe it as the latter. The gap is real and not closable inside this process. (b) A response with no parseable recipients[] is UNVERIFIED-AND-ACCEPTED, not rejected. Failing closed there would convert any future hub response-shape change into a TOTAL ALERTING OUTAGE on four rails -- trading a routing defect for silence, the worse direction. Same fail-open posture as 319's no-event-time. Consequence: a hub that stops returning the field SILENTLY DISARMS this check. Accepted limitation, not a covered case. Rejection returns false, so flush() re-enqueues and the watermark does NOT advance -- retryable, not discarded. At ~2 alerts/day a persistent bad seat costs a small retrying buffer. BARE HUB ok REMAINS NON-TERMINAL FOR 318, and so does this check. EVIDENCE: tsc --noEmit clean. 19/19 new, 420/420 full (401 before). SEVEN MUTATIONS, each killed only by its own tests: array-of-one to (2 fail), no self/emitter check (4), unverifiable-fails-closed (6), empty-list-as-unverifiable (2), reject-suspect-instead-of-warn (1), no-trim (2), seat-check-ignores-the-alias-gate (1). Baseline restored and re-confirmed 19/19. a0a7171 = fetched origin/main, `Agent: coder-venus-cc` present, ZERO verdict/reviewer strings. Four files, 322+/6-; ten staged paths from other lanes excluded by --only and still uncommitted.
• wi-cli-venus audit-finding · 2w ago
  BLOCK:a0a7171 (audit-venus-ca ms7fp8a4mkme), RATIFIED by pmmaster ms7fpplunjvn + reconciled ms7fqgfta0ig. Freeze holds, no restart. WI re-opens on coder-venus-cc under criteria 1-5. THE DEFECT, and it is the same collapse EVO-86 was ABOUT, one layer up: postAlert collapsing the hub's recipients array to r.ok is what let a six-week outage look healthy. auditDelivery() returning `true` for kind:"unverifiable" collapses a THREE-STATE outcome into the same boolean -- IN THE CODE WRITTEN TO FIX THE FIRST COLLAPSE. Trace: auditDelivery true -> postAlert returns the boolean -> flush() treats true as sent, records rtPaged IDs, ADVANCES THE WATERMARK. So "unverified-and-accepted" is TERMINAL TODAY. A boolean cannot carry "I could not tell", so every downstream caller is forced to read unknown as success. The in-code comment "unknown is never upgraded to a pass" IS THE EXACT CLAIM THE TYPE MAKES UNREPRESENTABLE -- not merely inaccurate. Shape note: the author named this as an accepted limitation in prose while the code did something stronger, and the prose is what a reviewer would have trusted. RECONCILIATION -- FAIL-CLOSED REJECTED, SETTLING ALSO REJECTED. Both parties were right about what they were defending. Failing closed on an unparseable recipients[] turns a future hub response-shape change into a four-rail alerting OUTAGE -- silence traded for a routing defect, the worse direction. AND accepted-unverified must not advance a watermark. The conflict exists only while the outcome is TWO-VALUED. It is three-valued, and it is the SAME three states VENUS-318 consumes. CRITERIA: 1. Explicit delivery result `verified | accepted-unverified | failed`. NOT a boolean, NOT a nullable boolean. 2. ONLY `verified` settles rows / records rtPaged / advances the watermark. `failed` -> re-enqueue+retry as today. `accepted-unverified` -> DEFERRED: alert IS SENT (no outage), rows RETAINED (no false settle), watermark does NOT advance, degraded-mode warning emitted naming the reason. Neither settles nor drops. 3. LANGUAGE ONLY -- no behaviour change. Comment, commit body and every board line say what the check proves: `not a provably-unread sink`. NEVER `human-seat validation`. Rejecting a readable-but-wrong seat is NOT wanted: it would drop a deliverable page to fix a label (db-ayudarg-cc, coder-pluto-cc are the proof). 4. Regression fixture where recipients[] is absent/malformed and THE WATERMARK PROVABLY DOES NOT ADVANCE. The non-advance is the assertion. 5. THE DISARM PATH MUST BE VISIBLE. "A hub that stops returning recipients[] silently disarms this check" was stated as a consequence and left silent at runtime -- the six-week outage's exact signature one abstraction up. The degraded-mode warning converts it from silent to loud. Without it the failure mode is written down instead of instrumented. SPEC DEFECT ACKNOWLEDGED BY PMMASTER, not an implementation miss: the 14:27 criterion said "human-seat recipient validation" and then let "recipient validation" stand as the deliverable. What shipped is a SINK validator, not a SEAT validator -- different guarantees; a name can be readable, registered, and still nobody's inbox. The implementation reasonably took the cheaper reading. The author's own objection preceded the ruling and IS now the ruling. HUMAN-SEAT VALIDATION REMAINS OPEN AND UNASSIGNED. Criteria 1-5 landing must NOT be read as satisfying it. APPLOG_PM finding accepted and it generalises past this file: A KNOB DOCUMENTED BUT UNREAD IS INDISTINGUISHABLE FROM A KNOB HONOURED, FROM EVERY POSITION EXCEPT READING THE CALL SITE. Pinned in the regression.
• wi-cli-venus progress · 2w ago
  BLOCK FIXED — 5a80f56 / v1.12.17, pushed, NOT restarted. Awaiting audit-venus-ca re-review. (coder-venus-cc ms7fwhd4ckun) ALL THREE BEHAVIOURAL REQUIREMENTS: - `DeliveryOutcome = "verified" | "accepted-unverified" | "failed"`, mapped by a pure exported deliveryOutcomeFor() IN THE LIB, not inside the logging wrapper. Deliberate: a mapping reachable only through module constants and a fake hub is HOW THE COLLAPSE SHIPPED UNNOTICED, so the mapping is now directly unit-testable. - Only `verified` writes the watermark. `failed` re-enqueues to the front of the buffer, unchanged. - `accepted-unverified` SETTLES NEITHER WAY: persists the rt-paged id set while leaving the cursor exactly where it is, via a new persistRtPagedWithoutAdvancing(). That needed a new function because writeWatermark stores the cursor AND the paged set in ONE file, so there was no way to durably record "already paged" without also asserting "progressed past". It reads the persisted cursor and writes it back unchanged; on first boot with no cursor it SKIPS the write rather than synthesising one. Net: no immediate duplicate of a message the hub accepted, no durable settlement, loud warn naming the newest row not settled. A restart drops the in-memory set and replays — the duplicate-over-missed direction this rail already prefers. THE SHARPER READING OF THE DEFECT, author's, and it is better than "wrong return value": THE COMMENT WAS NOT WRONG ABOUT THE INTENT. A two-state return had no third state to carry the intent in, so THE INTENT WAS UNREPRESENTABLE AND THE COMMENT WAS THE ONLY PLACE IT EXISTED. That is why it survived self-review, mutation testing and 19 passing tests: NOTHING WAS INCONSISTENT INSIDE THE FUNCTION. The contradiction exists only ACROSS the postAlert -> flush boundary and was invisible from either side. A PROSE CLAIM STANDING IN FOR A TYPE IS THE TELL — same class as a doc asserting a guarantee the guard does not implement. ONE MUTATION INITIALLY SURVIVED, AND IT IS THE MORE USEFUL RESULT. Deleting the persistRtPagedWithoutAdvancing() CALL left all 28 green, because the assertion was toContain("persistRtPagedWithoutAdvancing()") and the DECLARATION `function persistRtPagedWithoutAdvancing(): void` contains that substring — `(): void` supplies the empty parens. THE CHECK BOUNDED WHETHER AN IDENTIFIER APPEARED, NOT WHETHER IT WAS INVOKED. Tightened to anchor on the call site (trailing `;` plus adjacent warn); mutation now fails. Same narrowing as everything else tonight, in the test written to prevent it, found ONLY because the mutation was run. EVIDENCE: 9 new tests (28/28 targeted), 429/429 suite, tsc clean. 6 new mutations all killed — unverifiable->verified (the blocked defect itself), suspect->failed, advance-on-any-non-failed, drop the rt-paged persist, synthesise a cursor instead of preserving, revert the flush variable. 5a80f56 = fetched origin/main, `Agent: coder-venus-cc`, no verdict trailer. FREEZE re-verified under the fixed standard (one `systemctl --user show`, NRestarts dropped): all four applog-listen@* active, ExecMainStartTimestamp=Sun 2026-07-26 03:12:43 UTC, InvocationIDs venus fa249093 / mars 2a9438e0 / pluto a1e4d62d / ayudarg 9c52677c — all NON-EMPTY, so all four instances are real and have run, and none restarted across any of tonight's three pushes. STALE CITATION, uncorrectable in place: a0a7171's commit body calls pluto 50936 "still unexplained". It is CLOSED — predates 36225bc's scrp exclusion by ~2h45m, 54/54 explained. No history rewrite; the message of record is the correction. 5a80f56 does not repeat it.
• wi-cli-venus progress · 2w ago
  SECOND BLOCK FIXED — c7eb12d / v1.12.18, pushed, NOT restarted. BLOCK:5a80f56 accepted in full; the author's own reading: THE DESIGN WAS WRONG, NOT JUST THE CODE. Awaiting audit re-review. (coder-venus-cc ms7gh8sio4nj) FIX TAKEN: unverified rows NEVER enter rtPagedMap. That REMOVES THE SET'S DOUBLE MEANING rather than working around it, so no sweep can read "nothing new" as "nothing outstanding". NO DURABLE DEFERRED STATE, and audit's limbo point is what kills it: THE HUB CANNOT RETRO-VERIFY AN ACCEPTED SEND, so the ONLY deferred->verified transition is re-sending and checking THAT response. Hence bounded retry (3) then a loud settle. Plain "treat as failed" was REJECTED as unbounded — a hub that permanently stops returning recipients[] would page the same rows forever, turning a reporting change into a flood. So my earlier relayed spec (defer indefinitely, never settle) was not implementable as written; this supersedes it. TWO PRE-EXISTING DEFECTS FIXED, in NEITHER block: - The sweep advanced to scanNow whenever every row was excluded, WITHOUT ASKING whether it was excluded as DELIVERED or as still-BUFFERED. Broke the plain failed-retry path too. THE SIBLING BRANCH THREE LINES UP REFUSES EXACTLY THAT ADVANCE IN A COMMENT — the file argued against itself and the stricter half had no test. - flush's `newest` was a TEXT compare on createdAt. The rail has two formats (' ' vs 'T'), ' ' < 'T', so SAME-INSTANT ROWS ORDERED BY PRODUCER. Now parses event time. - Contiguous-prefix rule added (mayAdvanceTo): a delivered batch cannot pass an older pending row. Fails closed on incomparable. (This is VENUS-318's shape landing early in the producer.) TWO DEFECTS THE AUTHOR'S OWN TESTS CAUGHT, reported because they bear on how much to trust the rest: 1. newestOf skipped validating a SINGLE-ROW batch -> an unparseable createdAt would have become the PERSISTED CURSOR, and every later sweep would then throw on $1::timestamptz. Worse than the dropped row it was meant to avoid. 2. FlushDecision was first a FLAG RECORD; mutating the retry branch's markPaged to true (literally the blocked defect) SURVIVED, because the caller returns on requeue before reading it. So "a retried batch is never paged" existed ONLY AS STATEMENT ORDER IN ANOTHER FUNCTION — the same across-a-boundary prose-standing-in-for-a-type as the original boolean, one layer over. Now a discriminated union: requeue CANNOT CARRY a paged flag. That mutation now kills 5 tests. TESTING POSTURE WORTH KEEPING: the author DELETED the old textual flush assertions rather than rewording them, on the grounds that THEY PASSED WHILE THE DEFECT SHIPPED and were therefore coverage theatre at a level where coverage is impossible. 22 behavioural state-machine tests over the two real reducers replace them, including audit's exact sequences (unverified -> sweep-with-only-that-row -> cursor unchanged; unverified -> simulated restart -> still sweep-eligible; unverified then verified -> cursor cannot pass the older unverified row). 448/448, tsc clean, 11 mutations each killed only by its own tests. FREEZE INTACT under the fixed standard, ONE show: all four applog-listen@* LoadState=loaded, InvocationID fa249093/2a9438e0/a1e4d62d/9c52677c, ExecMainStartTimestamp 2026-07-26 03:12:43. No restart across four pushes tonight. NOT CLOSED, announced rather than buried: after the retry bound the rail SETTLES ON A BARE HUB ok. In-code, bounded, warned — a deliberate choice of a NARROW KNOWN WEAKENING over an unbounded page loop, not a covered case. VENUS-318 TERMINALITY STILL MAY NOT REST ON IT.
• wi-cli-venus decision · 2w ago
  pmmaster RATIFIED BOTH AUDIT BLOCKERS (ms7gk7ih5vok). One commit, both, plus regression. NO RESTART. BLOCKER 2 SEVERITY ESCALATED — it is not an edge case, it is the WHOLE THAW POPULATION. Rails frozen since Sun 2026-07-26 03:12:43 UTC, 4+ days. At thaw EVERY buffered row is older than the 2h prune by two orders of magnitude. A verified row blocked behind an older pending row enters rtPagedMap, is immediately pruned while the cursor stays behind, and the next sweep re-pages it. On first thaw that is the DEFAULT path for the entire backlog — a page storm on the exact restart the freeze exists to make safe. Invisible in normal operation precisely because normal operation has no multi-day backlog, which is why it survived to the one run that will have one. Retention MUST key on paged-at or on the cursor relation, NEVER on event age. Event-age retention is a statement about the DATA; the map needs a statement about the RAIL's own progress. Those coincide only when the rail is current, and at thaw it is definitionally not. BLOCKER 1 stands as audit revised it: an explicit PERSISTED disposition (verified vs bare-ok-after-unverified-bound; names yours), written AT THE ROW, consumable by 318 without treating a weakened row as proven delivery. FIX THEM AS ONE — they share a root: rtPagedMap's VALUE is currently createdAt, an event property, being asked two RAIL questions (how was this settled, when may it be forgotten). Neither is a property of the event. Make the value a small record carrying disposition + paged-at and both close together, and the retention key stops being a coincidence. Do NOT reintroduce a double meaning in the value shape after removing it from set membership. REGRESSION: persistence/reload/sweep as audit specified, and the fixture must be a MULTI-DAY-OLD backlog, not 3h — exercise the real thaw. audit-venus-ca re-reviews direct. Freeze holds on BOTH grounds now (EVO-86(e) correctness AND first-thaw storm): the thaw is unsafe today, not waiting on paperwork.
• wi-cli-venus commit · 2w ago
  3a42160 / v1.12.19 pushed — all five c7eb12d findings in ONE commit + multi-day-thaw regression. PTD: v1.12.19 live, dpl_7aK1CPWUS3CedDBNw57ojCdyUsut Ready. Re-review ask to audit-venus-ca + audit-pluto-ca (ms7h3k9dbnk7). NO RESTART; not FINISHED. Verbatim VENUS-318 sentence in commit body, carried into 318's spec. NEW BOUND (neither blocker): the paged record is DROPPED once the cursor passes the row. Correct for suppression, but VENUS-318 cannot read dispositions from this map on the normal path — 318 needs its own durable disposition store, and ABSENCE IN THIS MAP MEANS "cursor moved on", NEVER "verified". Coder deliberately did NOT widen the map's lifetime to serve 318: that reintroduces a second question into one structure, the defect this WI has now removed twice. Flagged to audit; if judged insufficient for blocker 1 the durable record becomes its own change, not a stretch of this one. 318's spec must not assume otherwise. Comparator bug found while fixing: Date.parse of Postgres's "+00" offset is NaN, so the micros comparator as first written returned null for EVERY real catch-up row. Fails closed — would have presented as a rail quietly ceasing to advance, not as a parse bug. Fixed and pinned.
• wi-cli-venus decision · 2w ago
  pmmaster RULING (ms7h53o9s25p). DISCLOSURE 1 — coder's call UPHELD. Do NOT widen the paged map's lifetime to serve 318. General rule, stated as a rule: A STRUCTURE'S LIFETIME IS PART OF ITS MEANING. Extending a map's retention so a downstream consumer can read it later puts a SECOND question back into one structure — the same double meaning both blockers exist to kill, arriving as a lifetime rather than as a value. That it would be convenient for 318 is the ARGUMENT AGAINST it; convenience is how the shape got in the first two times. 318 gets its own durable disposition store or does without. 318 SPEC REQUIREMENT, non-negotiable, as a SENTENCE not an implication: "Absence from the paged map means THE CURSOR MOVED PAST THIS ROW. It never means VERIFIED." Any 318 code reading absence as delivery is wrong on its face. Place it ADJACENT to the terminality sentence already carried over — the two are the same trap from opposite sides: one says a settled row may be weakly settled, the other says an unrecorded row is not settled at all. If audit judges this insufficient for blocker 1, the durable disposition store is its OWN change with its own review, not a stretch of 3a42160. DISCLOSURE 2 recorded at full weight. Date.parse NaN on Postgres "+00" made the micros comparator return null for EVERY real catch-up row, and it FAILS CLOSED — inside a freeze, a rail that quietly ceases to advance is INDISTINGUISHABLE from a rail that is correctly frozen. It would have shipped invisible, thawed invisible, and been diagnosed as EVO-86 recurring. A fail-closed defect wearing the costume of the safety property it violates: the worst available shape, and the one no amount of review catches — audit read this file twice and neither blocker described it. TRANSFERABLE CLAIM (both audit lanes carry it): not "test the boundary" but A FIXTURE BUILT FROM THE REAL POPULATION EXERCISES CODE PATHS NO FIXTURE BUILT FROM A PLAUSIBLE ONE WILL REACH. A 3h synthetic backlog would have passed while containing this. STANDING: no restart. Freeze holds on both grounds. Not FINISHED until PASS:3a42160 from audit-venus-ca; audit-pluto-ca's second read welcome, does not gate. On PASS, the RESTART PLAN goes to pmmaster SEPARATELY — the thaw is its own decision with its own blast radius and does not ride in on a review verdict.
• wi-cli-venus verified · 2w ago
  audit-venus-ca PASS:3a42160 (ms7h5u2v9lkc) for VENUS-323's two blockers. Verified: origin/main exact, 5 intended paths, 152/152 script tests, tsc --noEmit, git show --check. Cursor-relative retention closes the multi-day first-thaw duplicate storm; legacy entries preserve suppression without fabricating proof; exact-microsecond parsing handles both producer formats incl. Postgres "+00"; row-level disposition distinguishes verified from bounded bare-ok while the row remains selectable. NO RESTART AUTHORIZED BY THIS PASS.
• wi-cli-venus completed · 2w ago
  EVO-86(e) resolver-path hardening: three-valued delivery outcome, rtPagedMap disposition record w/ cursor-relative retention, contiguous-prefix advance, micros comparator. 3a42160/v1.12.19, audit PASS.
• wi-cli-venus statusChanged · 2w ago
  REOPENED — the close on 3a42160 was PREMATURE. audit-pluto-ca issued BLOCK:3a42160 already in flight when audit-venus-ca's PASS:3a42160 landed; both within a minute. The BLOCK is real. DEFECT: persistRtPagedWithoutAdvancing() returned early when readWatermark() was null, so on a FRESH rail (no state file, or corrupt) a verified row held behind an older pending row was recorded ONLY IN MEMORY, and a crash re-paged an already-delivered row. Reachable on exactly the first-thaw boot this WI exists to make safe. FIX: 43117bb / v1.12.20, live-verified, dpl_BTY1ZFcVvkg8fFqbky8y6hyUWAXr Ready. writeWatermark(cursor: Cursor | null), one transition for both write paths, no early return; cursor:null invents no boundary because readWatermark already returns null for a null-cursor file and for no file at all. THIRD INSTANCE OF THE ORIGINAL DEFECT CLASS IN THIS ONE WI. The thaw test asserting the held row "survives the round trip to disk" PASSED THE WHOLE TIME — because the HARNESS always wrote. The coder asserted against a persistence transition production did not implement: the test agreed with the model, not with the code. Same failure as the first BLOCK, one layer down, inside the fix for it. New regression states its own coverage limit inline (persistence is file I/O; no test in that file can observe production; compliance pinned by a source-shape guard). Both new guards mutation-killed. 155/155. PROCESS FINDING, recorded: a PASS and a BLOCK on the same SHA from two lanes is NOT a contradiction — it is the SECOND REVIEWER FINDING WHAT THE FIRST DID NOT. Arrival order made it look like a settled question. Had the PASS been read as closing the WI, this fix would not have been written. Corollary: an earlier PASS does NOT carry forward across a diff that fixes a durability defect. Re-review of the 43117bb delta asked of BOTH lanes (ms7hak2k58cw). The FINISHED banner citing 3a42160 was sent to Elazar before this arrived and has been RETRACTED.
• wi-cli-venus verified · 2w ago
  audit-venus-ca PASS:43117bbbd4e2b55a535b1ba2e7c03589344bd853 (ms7hbi7dkra3). Verified fetched origin/main exact, intended five-file delta, null-cursor persistence shares the single serialization path, early return removed, comments correctly bound rtPagedMap as SUPPRESSION state and not 318's ledger. Independently reran 155/155, tsc --noEmit, git show --check. Source-shape guard is an explicitly stated limit but pins the production file-I/O branch the reducer harness cannot execute. PASS does NOT authorize restart. BANNER STILL HELD. audit-pluto-ca's read on 43117bb is OUTSTANDING. Closing on the first verdict to arrive is exactly the error made 6 minutes ago on 3a42160; the second lane found what the first did not, and the second-lane read is now a gate on this WI, not a courtesy.
• wi-cli-venus verified · 2w ago
  audit-pluto-ca PASS:43117bb (ms7hcfwdkyoa) — five-file delta, shared null-cursor serialization path, corrected map-lifetime contract, 104/104 directly relevant tests, clean diff check. Verdict SOURCE-ONLY: no restart/runtime authorization. BOTH solicited lanes have now verdicted the SAME SHA (43117bb); banner gate satisfied.
• wi-cli-venus completed · 2w ago
  EVO-86(e) resolver-path hardening. 43117bb/v1.12.20. PASS from audit-venus-ca AND audit-pluto-ca on the same SHA. Source-only: authorizes no restart; rails stay frozen.
• wi-cli-venus note · 2w ago
  BOOKKEEPING, so a later reader does not read a discrepancy: audit-venus-ca reproduced 155/155 (FULL script suite), audit-pluto-ca 104/104 (DIRECTLY RELEVANT SUBSET). Different SCOPES, not different results — always record both numbers WITH their scope, never one bare. BLOCK HISTORY: four historical BLOCKs (a0a7171, 5a80f56, c7eb12d, 3a42160), all real, all corrective; 43117bb is the state. THREE of them were the SAME DEFECT CLASS AT SUCCESSIVE LAYERS, each found inside the fix for the previous one. PTD: live 1.12.20 == package.json, dpl_BTY1ZFcVvkg8fFqbky8y6hyUWAXr Ready on prod alias, SHA on origin/main, tsc clean. FLEET STANDING RULE from this round (pmmaster): on a Class-A change the WI's state is the CONJUNCTION OF OUTSTANDING VERDICTS, not the most recent arrival. A first PASS bounds what the FIRST reviewer looked at. The 'does not gate' waiver would have shipped a fresh-rail re-page defect that a thorough first PASS had cleared.