applog-listen burst dedup reads the WRONG CLOCK: processing wall-clock instead of event time, and never dedups event IDs

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus titleChanged · 2w ago
  applog-listen burst dedup reads the WRONG CLOCK: processing wall-clock instead of event time, and never dedups event IDs
• wi-cli-venus decision · 2w ago
  RE-SCOPED 2026-07-30 (pmmaster ms7eabyhmn9z + ms7eavwyn1b5, on audit-venus-ca's measurement). The narrow ID-dedup framing was too small and would have tested clean while the defect remained. MEASURED (audit-venus-ca, conclusive): enqueue() starts setTimeout(..., BURST_DEDUP_WINDOW_MS) on first PROCESSING; BurstEntry holds only {count,timer}; burstKey is signature+UA. Neither createdAt nor event id is ever read. The code contains no timestamp comparison at all, so the window is processing wall-clock, not event time. CONSEQUENCE: after a stale cursor, catchUp() returns every newer row and enqueues them SYNCHRONOUSLY, so two genuinely-distinct rows DAYS apart in event time are processed milliseconds apart and falsely pair into an x2 burst. Both-rows-behind-cursor is not an edge case - it is the normal case after any stall. FIX SCOPE = identity AND clock semantics: group bursts by DB event timestamps, not processing time; dedup on event id. ACCEPTANCE CRITERIA (pmmaster: criteria, not suggestions): (a) same-id replay does NOT increment the counter; (b) two distinct old rows >60s apart in EVENT time do NOT pair into a burst. (b) is the one a naive ID-dedup passes while the defect survives. SEQUENCING: VENUS-319 -> EVO-84 category/categoryValue probe (row selection) -> VENUS-318 (cursor disposition). VENUS-318's terminality test is DEFINED IN TERMS OF the event-time window 319 installs, so 318 cannot be implemented correctly first. Diff crosses coder-mars-cc + coder-pluto-cc before push.
• wi-cli-venus audit-finding · 2w ago
  BLOCK (audit-venus-ca ms7egeetqvn7, design review of the working diff, 2026-07-30). Do not push before this is resolved. 1. FAIL-CLOSED BRANCH: parseEventMs(createdAt) === null currently logs the row as an isolated 1-off and returns. An unusable timestamp means event-time burst membership is UNKNOWN, not proven one-off. Silently filtering it violates the purity discriminator, and it can later let VENUS-318 dispose/advance past an event whose alert classification was never valid. Alert rails must FAIL OPEN here: route through enqueueDirect (normal paging/dedup path) or return an explicit deferred/error disposition - do NOT label it log-only. Regression required: malformed / missing-zone-invalid timestamp proving it cannot be silently suppressed. 2. DESIGN CAVEAT to record or fix: the 5-minute eviction makes grouping PARTLY PROCESSING-TIME AGAIN for a distinct matching event delayed >5m despite <=60s event-time separation. If that is intentional memory bounding, state it as a coverage limit; otherwise evict by event-time closure driven by scanNow / current DB time, not an arbitrary processing TTL. 3. The two required core cases DO match the model in the diff: same id ignored within an open window; distinct old rows >60s event-time do not pair. PROCESS NOTE: implementation started before the design-ping I asked for, so this diff is reviewed as PROVISIONAL.
• wi-cli-venus verified · 2w ago
  MEASURED PRODUCTION INSTANCE — VENUS-319 was filed live-but-INFERRED; it is now live-and-OBSERVED, on the MARS rail, at x10 with dated rows (coder-mars-cc ms7ehqfeegcc, 2026-07-30, retracting his own earlier 'mars definitively not stalled'). ROWS BEHIND MARS CURSOR 2026-07-27 16:00:06.770551+00: warn: 11 rows, 2026-07-27 16:14:53 -> 2026-07-29 20:21:38 error/fatal: 0 Split at the last catch-up (Jul-29 18:02:05): 10 scanned-then-STRANDED (Jul-27 16:14 -> Jul-29 16:14) + 1 never-scanned (Jul-29 20:21, normal pending work). WHY IT IS THIS BUG: all 11 are category='toast', action='nudge-shown', message 'Tu docente te pidio rectificar practicas.' - identical signature. Walk the filters: self-probe no; bot/security no; log-only no (LOG_ONLY_CATEGORIES = {'access'} at :105, 'toast' not in it); slow_query threshold no (action doesn't match); warn-off no (WARN_ENABLED true - APPLOG_WARN unset in mars.env, predicate at :573 is level IN ('warn','error','fatal')). What remains is BURST-DEDUP. All 10 carry the same signature and were processed MILLISECONDS APART inside one synchronous catch-up pass while spanning 48 HOURS in event time. burstKey is signature+UA under processing wall-clock and never reads createdAt, so the pairing was structurally forced. This is exactly the case audit-venus-ca predicted from code reading, now with production rows. It also settles the §3 disagreement empirically: coder-mars-cc's withdrawn 'strictly later createdAt, never behind the cursor together' premise is falsified by ten rows that are ALL behind the cursor together AND all >60s apart in event time. USE AS THE REGRESSION FIXTURE FOR ACCEPTANCE CRITERION (b) - distinct old rows >60s apart in event time must not pair. Ten real rows, one real cursor, reproducible from the mars DB. Do not hand-synthesize a fixture when a dated production one exists. METHOD NOTE worth carrying: this was missed because the audit query bounded level IN ('error','fatal') while the rail's own catch-up predicate is level IN ('warn','error','fatal'). Bounding a NARROWER set than the predicate under audit returns a confident clean. Any backlog/lag query for these WIs must use the rail's own three-level predicate.
• wi-cli-venus audit-finding · 2w ago
  CORRECTION — MY PRIOR 'verified' EVENT IS WRONG. Mars's stranded rows are NOT a VENUS-319 burst instance and must NOT be used as the acceptance fixture for criterion (b). (audit-venus-ca ms7eig2i44am, correcting coder-mars-cc's attribution and my record of it.) WHY: burst code handles only the EXACT signatures 'Script error.' and 'Failed to fetch'. Mars's stranded rows are action='nudge-shown' - they never enter burstMap at all. They hit a DIFFERENT filter: enqueueDirect's processing-time 10-MINUTE ROUTE DEDUP THROTTLE. So VENUS-319 remains live-but-INFERRED. It does not have a measured production instance. Withdraw the 'live-and-observed' claim. THE METHOD ERROR, since it is the same one three times tonight and it landed in this WI: the attribution was reached by ELIMINATION - walk the filter list, rule out self-probe / bot / log-only / slow_query / warn-off, conclude burst is 'what remains'. Elimination is only valid if the surviving candidate is known to APPLY to the row, and burst's signature allowlist was never checked. A filter that cannot fire on this row is not a remaining candidate. WHAT MARS ACTUALLY SHOWS, both parts still real: (1) VENUS-318 partial interleaving, confirmed; (2) probably a THIRD defect - the 10-minute route dedup throttle is ALSO measured in processing time, so the wrong-clock bug is not confined to burstMap. If confirmed, VENUS-319's fix scope must cover both clocks or it fixes one filter and leaves its twin. audit-venus-ca has asked coder-mars-cc to reconstruct the ordered 13-row batch with signatures and routes before any buffered/suppressed counts are assigned; nothing is attributed until that lands.
• wi-cli-venus questionAsked · 2w ago
  OPEN SCOPE QUESTION (pmmaster ms7ekb0eqiar — ruled OPEN, not resolved; carry as a question, not a finding). DOES VENUS-319's FIX SCOPE INCLUDE enqueueDirect()'s ROUTE DEDUP THROTTLE? The throttle appears to be measured in PROCESSING time (10-minute window), same as burstMap. If that holds, the wrong-clock defect is NOT confined to burstMap, and a 319 that fixes only burst grouping fixes one filter and leaves its structural twin — passing every test in the WI while the defect survives in the adjacent code path. That is the 'tests clean' failure this WI already exists to avoid, pre-registered this time rather than discovered in a diff. BLOCKING MEASUREMENT: coder-mars-cc's ordered 13-row batch reconstruction (signatures + routes) landing with audit-venus-ca. NOTHING IS ATTRIBUTED UNTIL IT DOES — the last attribution made ahead of that measurement was wrong and reached a WI marked verified. Resolve this before 319 is declared done, either way: in scope (fix both clocks) or out of scope (separate WI, named, with the reason stated).
• wi-cli-venus verified · 2w ago
  SCOPE QUESTION ANSWERED — MEASURED AGAINST THE RUNNING CODE, NOT INFERRED (coder-mars-cc ms7ekvhp5cbo). YES: the fix scope MUST cover both clocks. In e874465, the version actually EXECUTING on mars: function dedupAllow(e) { const key = e.route ?? '__no_route__'; const now = Date.now(); // <- processing wall-clock if (!entry || now >= entry.windowEnd) { ... return true } entry.suppressedCount++; So the wrong-clock defect is NOT confined to burstMap; its structural twin is enqueueDirect()'s route dedup throttle, and it is deployed. A VENUS-319 that lands event-time grouping in classifyBurst and leaves dedupAllow on Date.now() fixes one filter and SHIPS ITS TWIN while passing every test in this WI. Decide it before the edit is finished, not after. FIXTURE REINSTATED, POINTED AT THE RIGHT FILTER: mars's ten stranded rows ARE a production fixture — for the DEDUP-THROTTLE twin, not for burst grouping. Ten identical-ROUTE warn rows spanning 48h in event time, replayed synchronously through a Date.now()-windowed throttle in one catch-up pass. That exercises dedupAllow's wrong clock exactly as criterion (b) describes, on deployed code. Same rows, different defect; the earlier retraction was correct about burst and wrong to discard the rows entirely. LIMIT ON THE 13-ROW RECONSTRUCTION, stated so nobody blocks on it: only the ELEVEN DB-visible warn rows are recoverable, in order. The buffered-vs-suppressed split depends on dedupMap's in-memory windowEnd/suppressedCount at Jul-29 18:02:05 plus the other 2-3 rows of that batch — never persisted, long overwritten, process not restarted. THE EXACT PER-ROW DISPOSITION OF THAT BATCH IS NOT RECOVERABLE FROM ANY ARTIFACT. Recoverable and sufficient: the rows exist, are newer than the cursor, were scanned, were not buffered. Anything past 'a processing-time filter dropped them' is inference.
• wi-cli-venus note · 2w ago
  VERSION DISCIPLINE — LINE NUMBERS IN THIS WI AND ITS THREAD ARE UNSAFE WITHOUT A VERSION (coder-mars-cc). Three versions of scripts/applog-listen.ts are in play: 1. RUNNING on mars: e874465 (Jul-14). Daemon ActiveEnterTimestamp 2026-07-26 03:12:43, NRestarts=0, tsx loads the file once at start. ee9dac6's per-DB category-column fix is NOT live on mars. Burst branch at :377 there. 2. COMMITTED HEAD: ee9dac6 (Jul-30 10:14). 3. WORKING TREE: uncommitted WIP, 75 insertions / 9 deletions, DOES NOT COMPILE — classifyBurst() is called at :412 and never defined. Every line number quoted in this thread (:453, :483, :573, :359-432, :408, etc.) is from version 3. Pre-push review of the WIP is correct practice; the failure was that nobody named their version, so BEHAVIOURAL claims about the RUNNING rail were drawn from an edit that has never executed anywhere. A working tree that does not compile cannot be any system's behaviour. Also established: VENUS-319 is ALREADY HALF-IMPLEMENTED in coder-venus-cc's working tree (comment at :116-120 states the 60s window is now event-time). That answers 'which lands first' factually.
• wi-cli-venus progress · 2w ago
  DIFF READY FOR REVIEW (coder-venus-cc ms7en67l7txd). Base ee9dac6. Diff + both new files at /srv/share/incoming/venus/venus319-diff-ee9dac6 (same-host, readable directly). tsc --noEmit exit 0; vitest 389/389 across 42 files; 16 new tests. The earlier 'does not compile / undefined classifyBurst' read was a mid-edit tree — resolved, import at :46. DECLARED READY, so behavioural claims may now cite it (version discipline). 3 files: applog-listen.ts, new scripts/lib/burst-classify.ts (pure decision), new scripts/__tests__/burst-classify.test.ts. AUDIT'S 3 BLOCKS RESOLVED: 1. FAIL OPEN on unusable createdAt — returns explicit {kind:'no-event-time'}; caller logs 'indeterminate ... failing open to page' and calls enqueueDirect(e). Never log-only. 2. EVICTION now event-time driven — windowProvablyClosed(entry, observedEventMs, windowMs) = observedEventMs - windowStartMs > windowMs, swept across all keys on every burst-class row. DIRECTIONAL on purpose: an older out-of-order row proves nothing and must not evict a live window, since NOTIFY can interleave with a replay batch. 3. STATED COVERAGE LIMIT (the alternative to fixing, as offered): BURST_EVICT_MS remains a PROCESSING-time timer, now 60min, as a pure memory backstop for a key that never recurs (burstMap is keyed partly by unbounded userAgent). It is the one remaining path by which wall clock can touch grouping — a pair within 60s EVENT time whose second row arrives >60min later in wall clock reads as two one-offs. Strictly narrower than the 60s setTimeout it replaces, and it fails toward a MISSED page, not a false one. Removing it trades a bounded miss for an unbounded leak. DISCRIMINATION MEASURED, NOT ASSERTED — 4 mutations, each kills only its own tests: dup-id check removed -> 2 fail (criterion a); event-time window ignored (= old behaviour) -> 4 fail (criterion b, including the naive-id-dedup-passes case and the boundary at exactly 60s vs 60s+1ms); fail-closed on bad timestamp -> 2 fail; Math.abs in windowProvablyClosed -> 1 fail. Restored 16/16. FIXTURE: criterion (b) uses the ~48h shape, explicitly NOT mars's 10 rows, and the test file RECORDS WHY so nobody reinstates them here. Coder reached that independently before the PM retraction landed. NOT pushed. Awaiting PASS. No work started on 318.
• wi-cli-venus audit-finding · 2w ago
  BLOCK (audit-venus-ca ms7eoq5er6ma, candidate on base ee9dac6). One defect: THE CROSS-KEY SWEEP IS UNSOUND UNDER THE PATCH'S OWN OUT-OF-ORDER MODEL. sweepClosedBurstWindows(decision.eventMs) treats a later event for ANY signature/UA key as proof that an OLDER key can no longer receive an in-window row. It proves no such thing when NOTIFY can interleave with catch-up. COUNTEREXAMPLE: key A opens at t; unrelated key B is observed at t+60s+1 and evicts A; a delayed A row at t+30 then becomes a one-off — losing a genuine page. The directional comparison only protects older OBSERVATIONS; it does not establish a global event-time WATERMARK. Worth naming the shape, since it is a variant of the night's recurring one: a per-key observation was used as a global watermark. The directionality fix was correct for the case it was written against and silently widened to a claim about all keys. REQUIRED: remove cross-key event-time sweeping (and windowProvablyClosed if it then has no user). Same-key rows already safely replace/close their own entry through classifyBurst. REGRESSION REQUIRED: an integration/state-machine test for the sequence A(t), B(t+60s+1), delayed A(t+30). The current pure windowProvablyClosed tests ENCODE THE INVALID PREMISE, so they pass while the defect stands — remove or rewrite them rather than leaving green tests asserting the wrong model. ACCEPTED as-is: the 60-MINUTE WALL-CLOCK MEMORY BACKSTOP stays, ruled on explicitly as a decision rather than accepted as a disclosure — named, bounded, avoids unbounded UA-key growth, fails toward a missed page. Also acceptable: fail-open, duplicate-ID ordering, event-time membership. Audit confirmed locally 16/16 focused and tsc --noEmit exit 0.
• wi-cli-venus note · 2w ago
  CORRECTING MY OWN RECORD + PUSH-MECHANICS REQUIREMENT. 1. THE 'WORKING TREE DOES NOT COMPILE / classifyBurst UNDEFINED' CLAIM IS FALSE, AND I RELAYED IT INTO THIS WI AS FACT. classifyBurst IS defined — in scripts/lib/burst-classify.ts, imported at :46-51; tsc --noEmit clean, 389/389. The original grep -c was bounded to ONE file while the definition lives in ANOTHER. Fifth instance in this thread of a clean result about a narrower corpus than the question, and the first to propagate downward carrying PM authority. Extracting the pure decision logic into a separately unit-tested module is BETTER practice than editing inline, and it was reported as breakage. The version-count finding (three versions in play, name your version) SURVIVES; only the non-compiling half is void. 2. VERSION-DISCIPLINE FORM SHARPENED (coder-pluto-cc, adopted fleet-wide): QUOTE THE CONSTANT OR THE PREDICATE TEXT, NEVER THE LINE NUMBER. The file grew ~89 lines under this thread; :582/:422 and :573/:377 were each correct for their version and none was citable. 3. PUSH MECHANICS — MANDATORY, gitpush.sh --only IS PER-FILE: scripts/lib/burst-classify.ts and scripts/__tests__/burst-classify.test.ts are UNTRACKED (??). Both paths go in the --only list or the push ships an import with no target: compiles locally forever, red on every fresh checkout. General failure mode — a dirty-unpushed dependency invisible to a per-file status. 4. RESTART IS AN EXPLICIT NAMED STEP IN THIS WI, never a side effect. These units are tsx-from-checkout with no build: the push is not the deployment event, the RESTART is, and nothing schedules it. Fleet freeze on all applog-listen@* restarts holds until this WI posts PASS+pushed. After push: RESTART VENUS ALONE, observe, then VENUS-321. Performed by coder-venus-cc. 5. VENUS-321 SPLIT RATIFIED by pmmaster with the measured argument: three populations reach the ROUTE THROTTLE (mars 10, ayudarg 774, venus filtered-class) and ZERO reach burst. So a 319 that lands event-time in classifyBurst and leaves dedupAllow on Date.now() fixes the path with no observed instances and ships its twin.
• wi-cli-venus decision · 2w ago
  FLEET RESTART POLICY (pmmaster ms7eqzacgtaf) — VENUS CARRIES AN OBLIGATION UNDER IT. VENUS restarts PER-CHANGE. Mars, pluto and ayudarg restart ONCE, at the end, after VENUS-318 lands. Reasoning: venus has a CONFIRMED 15-day stall — a known-bad state, so each restart has something specific to verify and observation is cheap and conclusive. The other three have no such fixture; a per-change restart there buys four exposure events with NOTHING TO OBSERVE AGAINST, on rails running Jul-26 code that is imperfect but understood. Staged rollout is the right shape when each stage is measurable and strictly worse when only one is. COST ACCEPTED EXPLICITLY, not hidden: mars/pluto/ayudarg take all four changes in one restart, so if that restart misbehaves the bisect is four-wide. VENUS IS THE STAGING FOR THE OTHER THREE — it is the only staging this architecture has. VENUS'S OBLIGATION: **if venus's per-change observation is SKIPPED OR INCONCLUSIVE at any step, this policy is VOID and the other three go per-change too.** coder-venus-cc must say so explicitly on the channel when that happens. Silence is not a pass — an inconclusive observation reported as nothing leaves three rails taking a four-wide rollout on a staging result that never existed. Separately: ayudarg's restart is blocked on OWNERSHIP (largest strand, no owner, escalated to Elazar; nobody restarts a rail they do not own). Enamel restarts only after EVO-84 ships per-app routing — the VENUS-319 freeze and the pre-existing EVO-84 stop are INDEPENDENT holds and both must clear. VENUS-319 AUDIT STATUS: exactly ONE open block — the cross-key sweep, which must become per-key. Fail-open resolved; 60-min processing-time memory backstop documented and accepted; tsc + 16/16 pass; undefined classifyBurst void. (An earlier three-block count was a remembered enumeration, not a read.)
• wi-cli-venus audit-finding · 2w ago
  BLOCK EXTENDED — SECOND BLOCKER. audit-venus-ca ms7eulgzy1kz, confirming coder-pluto-cc ms7eu32e7yv6, who reached it independently from the diff. CRITERION (a) IS NOT SATISFIED END-TO-END. On burst-confirm the diff does burstMap.delete(burstKey), discarding both ids (same as legacy). On reconnect behind the same stalled cursor: replay A finds no entry -> one-off, fresh window ids={A}; replay B is a distinct id inside the event-time window -> burst -> PAGES THE IDENTICAL [burst x2] AGAIN. The duplicate-id check only protects an OPEN one-off window, and the confirm path just closed it. N reconnects => N identical pages from two database rows. NOT A REGRESSION (running(<=Jul-26) deletes on confirm too) but it IS exactly 319's replay-manufactured-false-page defect class, it gets MORE likely the further the cursor falls behind — which is 319's own compounding argument — and 318 does not close it either (a settled prefix stops indefinite recurrence, but any replay before the cursor advances still re-pages). So a comment-only waiver is INSUFFICIENT; audit overrode coder-pluto-cc's minimum ask on that point. REQUIRED: preserve a bounded replay tombstone / seen-id state after confirmation, without changing the intended treatment of genuinely new C/D occurrences; document any restart/TTL residual explicitly. Regression: feed A then B (one page); replay A then B with state retained (ZERO additional pages). Do NOT solve it with the invalid cross-key timestamp sweep. CURRENT BLOCKERS ARE TWO RELATED STATE ISSUES: 1. remove/redesign the cross-key eviction, per-key from the key's own successor or the scan clock, with the A(t)/B(t+60s+1)/delayed-A(t+30) regression. coder-pluto-cc concurs from the diff: sweepClosedBurstWindows(decision.eventMs) iterates ALL keys, so an unrelated key's row at t+60s+1 retires key A's window while a genuine A(t+30) is still legitimately arriving — and after catchUp orders createdAt ASC, an interleaved live NOTIFY makes that ordinary, not exotic. The in-diff comment is true only for the row's OWN key. 2. retain confirmed-pair ids, with the A/B/replay-A/replay-B regression above. Plus: rewrite the pure windowProvablyClosed tests that encode the invalid premise. PUSH LANE: --only needs ALL THREE PATHS, comma-separated — scripts/applog-listen.ts, scripts/lib/burst-classify.ts, scripts/__tests__/burst-classify.test.ts. The latter two are untracked. For a tsx-from-checkout rail an untracked import target is NOT a build failure; it is an UNRESOLVABLE IMPORT AT PROCESS START ON THE NEXT RESTART OF EVERY RAIL. The freeze is the only reason it does not already matter; the push is exactly when it starts to. State the path list in the PASS request so audit can check the LIST and not only the diff. OPEN QUESTION TO ANSWER IN THE PASS REQUEST (coder-mars-cc, asked as a question and not asserted, because he does not hold the tree): if classifyBurst's extraction changed how any burst-path alert is posted, does the same void-vs-await asymmetry found in dedupAllow exist there? If it does, it is a THIRD INSTANCE OF ONE BUG, not a fourth WI. WHAT READS WELL, recorded so it is not lost in the block (coder-pluto-cc): no-event-time fail-open routes to enqueueDirect rather than log-only, so 318 can never advance a cursor over a disposition that was never earned — the correct posture, and the one he would have blocked on. Zone-less createdAt normalized to UTC rather than trusting the host clock, with a regression that would otherwise pass BY LUCK on this UTC host. duplicate-id checked BEFORE the window test with a test pinning the ORDER, and the test says why. windowProvablyClosed directional rather than Math.abs, asymmetry justified in place.
• wi-cli-venus audit-finding · 2w ago
  BLOCK v2 (audit-venus-ca ms7f22vbeh4u, direct to coder-venus-cc — no PM relay needed, recorded here for the ledger). CLEARED: both v1 blockers fixed — cross-key eviction and confirmed-pair replay. Local focused 25/25 + tsc --noEmit pass. REMAINING, ONE CORRECTNESS ISSUE: the per-key cap uses 'while (next.length > max) next.shift()', which drops the EARLIEST INSERTED, not the OLDEST EVENT-TIME — i.e. the cap's implementation contradicts its own stated policy, under exactly the out-of-order model this patch exists to handle. Sequence, max=2: t100 live, t0 replay, t300 one-off evicts t100; then t110 live can no longer pair with t100 and A REAL PAGE IS MISSED. Fix: evict min windowStartMs (or equivalent), with a regression preserving t100 in that sequence. SECOND, AND IT IS A DOCUMENTATION-ACCURACY DEFECT OF THE SAME CLASS THE WHOLE NIGHT HAS BEEN ABOUT: the in-diff comment claiming process restart, the 60-minute backstop, and the cap 'all ... fail toward a duplicate page, never a missed one' IS FALSE, and it contradicts the patch's own earlier TTL disclosure. Correct statement: losing an UNCONFIRMED window via restart/TTL/cap can MISS a genuine later pair; losing CONFIRMED ids can DUPLICATE a page. ANY BOUNDED EVICTION THEREFORE HAS BOTH-DIRECTION RESIDUALS unless state phases prove otherwise. State it accurately — a comment asserting a one-directional failure mode is precisely the kind of claim that reads as a guarantee to the next reader and survives into a summary. Push remains blocked. No restart.
• wi-cli-venus note · 2w ago
  PASS-REQUEST ADDENDUM ANSWERED (coder-venus-cc ms7f2hvuqcle), both items I required. 1. PUSH PATH LIST, verbatim: scripts/applog-listen.ts,scripts/lib/burst-classify.ts,scripts/__tests__/burst-classify.test.ts 2. VOID-VS-AWAIT IN THE BURST PATH: NO — read, not inferred. NOT a third instance. The burst path never calls postAlert; confirmed bursts go enqueueDirect(e) -> buffer -> flush(), and flush at :551 already does 'const sent = await postAlert(...)' and branches (true: set rtPagedMap + advance watermark; false: re-enqueue to the FRONT of the buffer, reschedule, leave the watermark behind). The extraction changed nothing — classifyBurst/stepBurst are pure, return no promise, and their only call sites are console.log and enqueueDirect. CONSEQUENCE FOR 321(b): it has a SAME-FILE PRECEDENT TO COPY rather than a design to invent — flush()'s branch-on-sent including the failure re-enqueue. Recorded on VENUS-321.
• wi-cli-venus audit-finding · 2w ago
  PASS v3 — audit-venus-ca ms7f6egqnp2i, base ee9dac6, artifact /srv/share/incoming/venus/venus319-diff-v3. WHAT CLEARED THE v2 BLOCK: the cap now PREFERS CONFIRMED WINDOWS, then evicts minimum EVENT-TIME within class. The max=2 t100/t0/t300/t110 regression proves insertion order cannot drop the live t100 window. Residuals now state BOTH DIRECTIONS accurately for restart/TTL/cap — the false 'never a missed one' claim is gone. Cross-key isolation and confirmed-pair replay fixes intact. INDEPENDENTLY VERIFIED BY AUDIT LOCALLY, not taken from the coder: focused 28/28, tsc --noEmit exit 0, git diff --check clean. APPROVED PUSH LIST, exactly and both new files mandatory: scripts/applog-listen.ts,scripts/lib/burst-classify.ts,scripts/__tests__/burst-classify.test.ts NO RESTART IMPLIED. The fleet freeze and EVO-86 sequencing hold.
• wi-cli-venus decision · 2w ago
  PM RULING — THE PER-CHANGE RESTART POLICY IS VOID AS WRITTEN, BY THE CONDITION I ATTACHED TO IT MYSELF. I set it as: venus restarts per-change because it has a confirmed fixture; mars/pluto/ayudarg restart ONCE at the end; and 'if venus's per-change observation is SKIPPED OR INCONCLUSIVE at any step, this policy is VOID and the other three go per-change too. Silence is not a pass.' coder-venus-cc DECLARED the inconclusive case rather than letting a silent restart read as a pass, which is exactly what that clause was for. WHAT VOIDS IT (coder-venus-cc ms7fb5ql7q0n, audit-venus-ca concurring): a venus restart is a WEAK OBSERVATION FOR 319 SPECIFICALLY. Four rows sit past the frozen cursor (2026-07-15 10:52:47) — 98a42866 clientPageError /practicas/nueva Jul-15 10:52:48 (pageable, non-burst), one 'Failed to fetch' Android, one category=security bot-filtered, and the Jul-29 'Script error.' iPhone. THE TWO BURST-CLASS ROWS HAVE DIFFERENT KEYS — signature::userAgent differs on both halves — SO THEY WOULD NOT HAVE PAIRED EVEN UNDER THE OLD PROCESSING-TIME WINDOW. A venus restart exercises catch-up discharge, watermark advance and delivery; IT DOES NOT EXERCISE THE PAIRING BEHAVIOUR 319 CHANGED. RESTATED POLICY: 1. NO RAIL RESTARTS TO VALIDATE 319. Nobody holds a burst-pair fixture — venus's two burst-class rows have different keys; mars's ten and ayudarg's 774 are dedupAllow route-throttle rows, not burstMap, and page_not_found/nudge-shown are not in BURST_ERRORCLASS_SIGNATURES at all. 319's changed pairing semantics are UNOBSERVABLE IN PRODUCTION ON EVERY RAIL. Its assurance comes from audit's 28/28 + independent re-run, and that is the whole of it. DO NOT MANUFACTURE A FIXTURE TO GET AN OBSERVATION — a synthesised pair on a live rail pages a human with a fake alert. 2. VENUS STILL STAGES 318 AND EVO-86, and that survives intact — the four backlog rows DO exercise catch-up discharge, watermark advance and delivery, which is precisely what 318's cursor change and EVO-86's delivery fix touch. Venus goes per-change on those two. 3. MARS/PLUTO/AYUDARG: unchanged, restart ONCE at the end after 318. The original justification (venus validates first) is withdrawn for 319 and HOLDS for 318 — which is the only one of the three where a staged observation was ever going to mean anything. 4. A pushed 319 sitting unexecuted remains the correct state. For a tsx-from-checkout rail the push is not the deployment event; the restart is, and no restart is authorised. WORTH RECORDING BECAUSE THE POLICY WORKED THE WAY POLICIES USUALLY DO NOT: the void condition was written when the policy was set, it fired, and the agent it constrained is the one who invoked it against his own convenience. He could have restarted, observed a clean catch-up discharge, and reported a pass that was true and irrelevant. THAT WOULD HAVE BEEN INDISTINGUISHABLE FROM A REAL VALIDATION and would have licensed three more restarts on its authority. CITATION CORRECTION REQUIRED BY audit-venus-ca (ms7fbtnziv27), and it applies to the VENUS-322 event above: do NOT write 'derived from the code the RUNNING rail loaded, i.e. e874465'. Historical dirty state at Jul-26 boot is unrecoverable, so exact running(e874465) is UNPROVABLE. Correct form: running(<=Jul-26 boot), committed content consistent-with e874465, dirty-state-at-boot unrecoverable — with the measured predicate text quoted SEPARATELY. THE BUCKET COUNTS STILL STAND as DB measurements under an explicitly queried predicate; they are not proof of the unrecoverable process image. Two different claims, and only one of them was measured.
• wi-cli-venus verified · 2w ago
  POST-PUSH PASS — audit-venus-ca ms7fbtnziv27. 811b6cf23d0411006ca942e8cc4cd9a1de2fda3e EQUALS FETCHED origin/main (verified by fetch + rev-parse on both sides, not by gitpush's own output). Exact paths: package.json auto-bump + the approved three script paths. 730+/14-, 4 files. 'Agent: coder-venus-cc' trailer present, NO verdict trailer. Audit independently reran focused 28/28, tsc --noEmit, git show --check — all pass. Version 1.12.15. git status before and after confirms nothing else was bundled; 11 stray paths from other lanes were reported excluded by gitpush and remain uncommitted (shared-worktree discipline held). NO RESTART AUTHORIZED. No PTD owed — this is not deployed app code and the version endpoint is not the oracle for a checkout-executed script. SCOPE, stated so the close cannot be misread: 319 fixes WHICH ROWS THE BURST PATH DECIDES TO PAGE. IT DOES NOT RESTORE ALERT RELIABILITY — that is EVO-86.
• wi-cli-venus completed · 2w ago
  Burst-path clock semantics + identity: event-time windows, per-key eviction, confirmed-pair replay state. 811b6cf/v1.12.15, audit PASS pre- and post-push, on origin/main. Not restarted — freeze holds until 318.