The owner uses finite virtual-clock histories over public createPacedMutations and the three real strategy factories. Its independent models use an appointment time, pending mutation IDs, and a plain ordered list. The tests compare immediate public Collection rows, mutation callback times and payloads, returned transaction identity, final transaction state, and isPersisted.promise fulfillment with the returned transaction object. A held-write history crosses the queue timer and two pending persistence promises to check serialization.
The maintainer chose the documented pacing behavior: factories preserve caller-owned options, maxSize overflow fails the returned transaction and rolls back its optimistic state, and explicit non-leading throttle waits for its first trailing edge. The baseline maxSize:1 witness returned two completed and two permanently pending transactions after four calls. The baseline explicit non-leading throttle witness started at t=0 rather than the trailing edge. The follow-up oracle encoded both laws and failed on the unchanged production implementation. Omitted leading/trailing defaults remain outside the finite domain.
| Requirement | Outcome |
|---|---|
| ORC-001 authority and limits | Pass for documented queue order and bounded admission, explicit debounce trailing and throttle edges, optimistic rows, and persistence settlement. Omitted defaults, failed writes, and broader generated schedules remain outside this finite owner. |
| ORC-002 independent judgment | Pass. The expected trace is computed from a virtual appointment list, a quiet-period grouping rule, and a leading/trailing window rule. No pacer-lite code or production scheduler enters the model. |
| ORC-003 five responsibilities | Pass. The opening states the law and limits; queueStarts, debounceStarts, and throttleStarts are the model; action arrays are the finite grammar; runProduction is the real driver; exact trace and receipt assertions are the refinement check. |
| ORC-004 grammar controls | Bounded enumeration, not an important generated property. It reconstructs all four queue position combinations, zero queue wait, queue capacity zero/one with waiting and in-flight writes, debounce reset, both throttle edge forms, and held queue settlement. Distinct IDs isolate queue admission; a focused same-key witness checks that overflow rollback leaves an admitted update intact through first-write settlement. A deferred custom queue checks the void-return compatibility boundary. Negative waits and broader capacities are outside the claimed grammar. |
| ORC-005 path and observation | Pass. Real strategy instances drive the public manager and Collection; callback times and payloads, public rows, returned transaction identity/state, and persistence receipts are observed at virtual-clock cuts. Rejected receipts carry QueueCapacityExceededError; admitted same-key state survives the preceding write's settlement. |
| ORC-006 checker calibration | Pass for hostile queue extraction, disabled debounce trailing, disabled throttle leading, early non-leading throttle, ignored capacity, false-green overflow admission, and caller-option mutation controls. Each reaches and fails its corresponding checker. |
| ORC-007 fixed/random campaigns | Not triggered: this owner is bounded finite enumeration, not an important generated property. |
| ORC-008 model minimality | Pass. The queue's ready-list order distinguishes later extraction; due time distinguishes a call before/after eligibility. Debounce pending IDs and quiet-period due distinguish which transaction persists and when. Throttle pending IDs and next edge distinguish merged trailing output from a fresh leading call. |
| ORC-009 vocabulary mapping | Pass. The opening maps model pending IDs, ready list, and due appointment to production concepts without importing their implementation. It uses the glossary terms optimistic transaction and settlement. |
| ORC-010 failure fidelity | Pass. The driver compares the complete trace before cleanup. withCleanup stops strategy timers and cleans the Collection. When comparison and cleanup both fail, it retains the comparison as the cause and reports cleanup errors separately. A hostile cleanup test checks both errors and Collection cleanup. No shrinking or external capture occurs. |
| ORC-011 second formulation | Not triggered for the documented finite schedule laws: the model's appointment/list formulation differs from pacer-lite's timers and promise chain, and no named shared semantic fault has a meaningful second formulation. Broader capacities and schedules remain open. |
ORC-012 is this versioned record, tied to the reviewed implementation commit and the coverage-map owner. The sampled finite histories do not prove every legal schedule.
The original audit accurately found absent queue option coverage and no paced-mutation oracle. It correctly rejected a pacer-lite differential as permanent authority. It missed the pending transaction on queue rejection and the early non-leading throttle start. Hire recommendation: hire for issue discovery with a reproduction and contract-authority gate; good signal and prioritization, incomplete edge/settlement analysis.
The source ledger has six claims. GAP04-1, GAP04-3, and GAP04-4 are fixed for the finite domain described above, including bounded capacity and hostile capacity controls. GAP04-2 has a maintainer decision and a tested implementation. GAP04-5 is accepted and implemented: the copied pacer-lite differential is not the oracle. GAP04-6 is deferred to the proposed MUT-05 replacement. The source claims stay distinct in the task-local ledger.
The follow-up review found two oracle gaps: the same-key witness did not observe the admitted update after the first write settled, and direct receipt awaits could hang before cleanup. Both were fixed by holding writes across a settlement cut and recording receipt outcomes before asserting them. A simplifier removed a duplicate queue transaction reference; a separate non-leading timer remains necessary because pacer-lite 0.2.1 measures its first wait from epoch zero.
The repair adds 37 net production lines across the queue admission result, a named rejection reason, targeted rollback, caller-option cloning, and the trailing-only timer. The tests and contract documents grow separately. Each added production branch supports a public law demonstrated by a RED witness and a GREEN oracle run.
CodeRabbit reviewed abf7740b921de88589c5b4a1ef53d6ea832a9145 and posted one inline finding. Its claim was accurate: if (!admitted) rejected a custom queue strategy that admitted work and returned void. The previous QueueStrategy.execute contract allowed that return. The new Boolean-only type also broke source compatibility for that strategy.
The permanent deferred-callback witness failed on the reviewed commit at the admission checkpoint: the returned transaction was failed instead of pending. DB typecheck rejected the void-returning strategy. The repair treats only explicit false as rejection and restores the prior void and promise return types. The same witness then passed, and the bounded queue witnesses still rejected overflow. The focused DB suite passed 18 oracle and 13 existing tests. DB typecheck, ESLint, Prettier, and diff checks passed.
The review had one actionable finding and one non-blocking suggestion to run a local CodeRabbit CLI review. The finding is fixed-now in the task ledger. The CLI suggestion is deferred to the normal CodeRabbit PR re-review after push. No other technical item appeared in the raw review body, inline comments, or footnotes. Loss audit: 2 raw items = 1 fixed-now + 1 deferred. No evidence gap remains.
Reviewer assessment: 1 of 1 actionable findings was correct and specific. The suggested conditional fixes the runtime bug. The reviewer did not mention the related type compatibility break, which the RED typecheck exposed. The review had high signal and a narrow but useful analysis. Hire recommendation: hire for targeted PR review, with an oracle and typecheck gate before accepting fixes.
The review in pr-1918-1934-review-summary.md examined HEAD 0654b2aa574b760e8d6935cccafff9ce9d8d208b and contained five numbered findings plus six contextual claims. The task-local append-only ledger preserves all eleven in source order.
Finding 1 exposed a real omitted-leading throttle gap. Pacer-lite 0.2.1 defaults both edges only when both are absent. With { wait: 10, trailing: true }, leading remains undefined; its first trailing timeout subtracts the epoch-based elapsed time and fires at virtual time 0. The new public createPacedMutations oracle case failed before the fix: actual starts included { at: 0, ids: [1] } while the independent non-leading model expected { at: 10, ids: [1, 2] }. The same case passed after changing the guard to leading !== true && trailing === true. Explicit non-leading, explicit leading, and both-omitted default cases pass alongside it. The pre-fix implementation is the hostile timing control at the exact start-time checkpoint. The repair is one changed production line.
Finding 2 correctly flags a new public error and observable overflow change. It is not a TypeScript source incompatibility: the export is additive and old source still compiles. The old silent drop left an optimistic row and pending persistence receipt, so relying on it as a completed no-op was not a coherent public contract. The prior maintainer decision, patch changeset, guide, and bounded RED/GREEN capacity oracle cover the intended behavioral change.
Finding 3 is accurate. Pacer-lite checks items.length >= maxSize before insertion and processing, so zero rejects even the first mutation. The existing public oracle verifies three rejected transactions for maxSize: 0; the focused suite passed it. The guide, option type, and reference text now state the zero boundary and rejection semantics.
Finding 4 accurately identifies a separate timer path. It does not show a second behavioral fault or a safe local root fix: pacer-lite owns a private epoch-based clock, and this branch has no public way to reset it. Keep the narrow trailing-only timer until an upstream pacer-lite repair can provide the same documented schedule; the oracle's explicit and omitted-leading cases are the migration checks. This maintenance idea is deferred here, not dropped.
Finding 5 is partly imprecise: the comment said “captured transaction” rather than the literal removed identifier capturedTx, and the concept was still correct. Naming txToReturn directly makes the comment match the code; that one-line comment edit is complete.
The scoreboard, opening attention note, and cross-PR observation correctly call this a production behavior change with a new public API. The three named changes are bounded queue rejection and rollback, explicit trailing throttle timing, and caller-options immutability. The omitted-leading correction closes one adjacent configuration. These claims are recorded in the changeset, guide, oracle, and this review record. The PR remains a narrow bug-fix release despite exceeding the batch's test-only shape.
Reviewer assessment: the key omitted-leading finding was precise, reproducible, and paired with the correct one-line classifier fix. The capacity and stale-reference notes identified useful documentation cleanup. The compatibility note overstates source breakage, and the timer note is a design preference without a concrete alternative. Signal-to-noise is good; prioritization is sound. Hire recommendation: hire for focused review, with a public oracle and compatibility terminology check.
Verification after the fix: DB paced oracle 20/20, existing paced tests 13/13, React paced hook 6/6, DB typecheck, changed-file ESLint, Prettier, and diff whitespace checks. Loss audit of the raw review: 11 claims = 3 fixed-now (findings 1, 3, 5) + 6 already documented contextual claims + 1 refuted as phrased (source incompatibility) + 1 deferred maintenance idea (upstream timer repair). No item lacks evidence. Other edge combinations, failed persistence, broader capacities, and generated schedules remain outside this finite oracle owner.
CodeRabbit reviewed bad0a0091e6914ba60d67e9875f640a05e9e7238 and posted one inline finding at docs/guides/mutations.md:1231-1232. Its claim was accurate: queueStrategy.cleanup() stopped the timer and cleared admitted waiting callbacks. Their optimistic transactions stayed pending, their persistence receipts did not settle, and their optimistic rows stayed visible. This behavior predates the PR. The guide promised that every admitted queue mutation is attempted before and after the PR.
A controlled public probe held the first write and called cleanup while the next item waited. After 20ms, the second write had not started, its transaction and receipt stayed pending, and its optimistic row remained visible. The permanent FIFO oracle case failed on the reviewed commit at its start-order checkpoint: actual [1], expected [1, 2]. The owner previously ran cleanup only after every admitted call settled, which explains the false-green coverage.
The repair stops new admission and lets the existing LiteQueuer timer drain admitted callbacks at the configured wait interval. Cleanup still returns synchronously. The held first write gates later starts. FIFO and LIFO oracle histories check exact start order, transaction and receipt settlement, a repeated cleanup call, and direct strategy rejection of a new callback after cleanup. An additional public clock history checks two immediate writes: starts remain [0] at the first cut and become [0, 10] after the wait. All three histories pass. The prior stop-and-clear implementation failed the drain checker. A stop(); flush() candidate passed settlement but failed the timing checker with starts [0, 0]. Both are hostile controls at their intended checkpoints.
The reviewer suggested weakening the guide to say cleanup can discard admitted work. That would contradict the documented admission guarantee. The guide and changeset instead describe a graceful drain. The repair adds one disposal flag and keeps the existing timer until the queue empties. It adds no second timer or recovery path. A separate public probe called mutate() after cleanup. Its transaction failed and its receipt rejected with QueueCapacityExceededError. That error reason is inaccurate for disposal. The direct strategy test only asserts no new callback is admitted. A future owner must decide and witness the public post-cleanup call contract before changing its error path. The coverage map records this limit.
Verification on the repaired worktree: DB paced oracle 23/23, existing paced tests 13/13, React paced hook 6/6, DB and React typechecks, changed-file ESLint, Prettier, and diff checks. The raw review had one finding and one optional local CodeRabbit CLI suggestion. Loss audit: 2 items = 1 fixed-now + 1 deferred to automatic PR re-review. No review item lacks evidence.
Reviewer assessment: the single actionable finding was technically accurate and found a real lifecycle gap. The proposed documentation-only fix would preserve stranded optimistic transactions and weaken a public promise. The reviewer did not check the prior guide or the transaction receipt contract. Signal was high, analysis depth and fix quality were mixed. Hire recommendation: hire for defect discovery with contract review and public-path RED/GREEN gates.
The rereview in pr-1918-1934-rereview-status.md checked 16d84046bc0152e2d7e6f50c1e57e6670dfa83ca. Its five prior findings, three new claims, and overall verdict are retained separately in the task-local source-order ledger.
The earlier epoch-zero throttle fix, named overflow error, documented maxSize: 0 rejection, and comment correction all remain on the branch. The separate trailing-only timer still has an upstream pacer-lite migration owner. The reviewer correctly observed that cleanup now lets admitted writes run after a separately cleaned-up Collection. A public controlled-clock probe called both strategy.cleanup() and Collection.cleanup(), then observed the admitted second network callback start at t=10 and both receipts fulfill. This is the documented queue-drain behavior: the strategy has no Collection lifecycle signal, and the guide promised every admitted write would be attempted even before the PR. The old stop-and-clear behavior stranded an optimistic transaction and receipt. The guide now states the bounded Collection-cleanup interaction explicitly. This does not establish cancellation semantics for a Collection-owned adapter or guarantee that an external network client remains usable after its own teardown.
Two other claims were product bugs. Before the fix, a new public oracle case for throttleStrategy({ wait: 10, leading: false }) failed: expected starts at t=10 and t=20, actual starts [], with optimistic transactions unpersisted. Pacer-lite 0.2.1 only defaults both edges to true when both options are omitted; with leading: false alone it schedules neither edge. Its documented leading: false behavior waits for a trailing execution, and the public paced-mutation contract requires settlement. The strategy now enables the trailing-only window for this omitted-trailing combination. The prior explicit-leading, explicit-trailing, omitted-leading, and both-omitted witnesses remain green.
Before the other fix, a public call after queue cleanup rolled back and rejected its receipt with QueueCapacityExceededError. The new oracle expected a disposal reason and failed at that exact receipt assertion. The queue now throws QueueDisposedError at the admission boundary; createPacedMutations catches that specific error, rolls back only the new optimistic transaction, and returns its rejected receipt. A previously admitted write still completes, while no post-cleanup network callback runs. No recovery state was added. Direct strategy calls also report disposal instead of capacity.
RED: the two new oracle cases failed separately on the intake head, with actual throttle starts [] and receipt error name QueueCapacityExceededError. GREEN on the repaired working tree: paced oracle 26/26, existing DB paced tests 13/13, React paced hook 6/6, DB typecheck, changed-file ESLint, Prettier, and diff check. The original implementations are the hostile controls for both new assertions. Both-edge-disabled throttle, failed persistence, and broader generated schedules remain outside the finite owner. The newly described Collection-cleanup interaction is a bounded observation, not a generic cancellation law.
Reviewer assessment: two new actionable defects were accurate and supported by specific paths. The cleanup behavior observation was also accurate, but the recommendation to reopen its policy overlooked the existing admission guarantee and the prior RED cleanup witness. Technical accuracy and signal are high; fix quality is good for the throttle default and weaker for cleanup because it omitted the stranded-receipt trade-off. Hire recommendation: hire for focused review with contract and public-observation checks.
Loss audit at the intake commit: nine raw items = four already addressed prior findings, one deferred timer-maintenance idea, one refuted cleanup blocker with its true observation retained, two fixed-now bugs, and one verdict duplicated by those findings. No raw item is omitted. Recheck the final diff and evidence after publication because this paragraph describes the working tree before the follow-up commit.
The first two RED cases exposed a larger legal option class. Pacer-lite 0.2.1 defaults both edges together only when both are omitted. trailing: false with omitted leading therefore started nothing; explicit leading started the first write but silently stranded a call inside its wait window; both edges disabled stranded every optimistic transaction. A separate epoch-zero probe found that even explicit leading with either trailing setting failed to start the first call at virtual time zero. Controlled public witnesses failed at exact start, transaction-state, optimistic-row, and receipt checkpoints. The supported trailing: false meaning is to drop calls inside a window, so the manager now rejects those calls immediately with ThrottleCallDroppedError and rolls back their optimistic state. A held first write plus a same-row dropped update proves that rollback preserves the admitted write. Omitting leading when trailing is false enables the leading edge; omitting trailing when leading is false enables the trailing edge. The oracle also retains both-omitted, explicit leading/trailing, and omitted-leading explicit-trailing schedules.
The two-path LiteThrottler plus custom trailing timer could not expose a dropped-call result or reliably place the first edge at epoch zero. One local timer and one next-allowed timestamp now handle all four edge choices. This removes the dual-path maintenance concern from the earlier review. The implementation stores the most recent pending callback, so later calls in one trailing window merge into the transaction at that edge. An independent reviewer challenged option combinations, first/later boundaries, callback replacement, and same-row rollback and found no new counterexample.
That reviewer identified a separate cleanup history: leading:false,trailing:true, mutate(1) at t=0, cleanup at t=4. The former timer cancellation left the optimistic transaction and receipt pending forever. The new public oracle failed at t=10 before the repair: no callback started. Cleanup now leaves the admitted trailing timer in place; the callback starts at t=10, and the transaction and receipt complete after a separately cleaned-up Collection. This matches the queue's documented choice to drain admitted work at the configured pace, while preserving the throttle's distinct merged-write behavior. Queue cleanup stops later admission and reports QueueDisposedError. No throttle admission-stop contract is documented; calls after throttle cleanup remain outside this finite owner and must not be inferred from the queue rule. Failed persistence and wider generated schedules are also open.
The now-stale working-tree summary above is superseded in two dispositions: R30-4's dual-timer concern is fixed now, and R30-7 covers the adjacent legal edge combinations and epoch-zero first call. At this stage, the primary oracle passes 33/33. The final surrounding checks, production diff, commit SHA, and CI receipt will be recorded after the last review pass.
Final pre-push verification on the expanded working tree: DB paced oracle 33/33, existing DB paced suite 13/13, React hook suite 6/6, DB and React package typechecks, changed-file ESLint, Prettier, and diff whitespace checks all pass. The last change corrects a timer comment after independent review. The cleanup oracle shows the throttle transaction pending at t=9, a single write start at t=10 after both strategy and Collection cleanup, and a fulfilled receipt. New throttle calls after cleanup remain undefined by the throttle contract and outside this oracle. The full PR's production source diff from merge base 33a19494 is +113/−29, net +84 lines. The new lines serve three named rejection reasons, targeted optimistic rollback, serial queue admission and drain, and one timer for every supported throttle edge combination. An independent simplification pass found no duplicate state or branch worth another rewrite.
The final raw-source audit found nine items. The source lists prior findings in order 1, 5, 2, 3, 4 before the three new claims and its verdict. The task-local ledger retains stable finding-number IDs and records this exact order. Four prior items remain already addressed, three items received fixes in this follow-up, the cleanup blocker is refuted by the documented drain contract, and the overall verdict duplicates those claims. The reviewer accurately observed that admitted network writes can run after Collection cleanup. The guide now states that interaction. No raw claim lacks evidence.
The final cleanup audit found the same stranded-receipt pattern in the default debounce strategy. The guide promises that the final merged state persists after inactivity, and the public mutation function returns an optimistic transaction with a persistence promise. Before this follow-up, debounceStrategy.cleanup() canceled its pending LiteDebouncer timer. A controlled public probe called mutate(1) at t=0, cleaned the strategy at t=4, and observed no write at t=10. The transaction and receipt stayed pending while its optimistic row had been visible before cleanup.
The permanent oracle now uses two calls at t=0 and t=4. It checks that they return the same transaction and expose both optimistic rows. Cleanup runs at t=8, followed by separate Collection cleanup. The transaction and receipt remain pending at t=13. The single merged write starts at t=14, the last call's quiet edge, with IDs [1, 2]; the transaction completes and the receipt fulfills with the returned identity. This test failed against the canceling implementation at the t=14 start checkpoint and passes when cleanup leaves the existing timer scheduled. It also rejects an immediate-flush cleanup because no write may start at t=8 or t=13.
The debounce, throttle, and queue cleanup witnesses now share the bounded settlement law: cleanup does not strand work that already owns a scheduled write. Each retains its own timing rule. Queue cleanup also stops new admission because its contract says so. New debounce and throttle admission after cleanup has no defined cancellation rule, so this oracle does not claim one. The debounce production edit replaces one cancel call with an explanatory comment and adds no timer or recovery state. The guide, reference, changeset, and coverage map state the drain behavior and its limit.
Two independent reviews found that the cleanup repair still left legal debounce options with pending transactions. Pacer-lite 0.2.1 defaults both edges together only when both options are absent. Explicit leading: false with omitted trailing therefore scheduled no write. Explicit leading: true with omitted trailing ran the first call but stranded a second call inside the quiet window. With trailing: false, a skipped call also kept an optimistic row and pending receipt. Both edges disabled stranded every call.
Five new public oracle cases failed before the option repair at their write-start, transaction-state, row, or receipt checkpoints. The factory now supplies independent defaults: omitted leading is false, and omitted trailing is true. For an intentionally skipped call when trailing is false, the strategy returns false. The manager rolls back that optimistic transaction and rejects its receipt with DebounceCallDroppedError. A held first write and same-row dropped update checks that this rollback preserves the first write. The default cleanup case and the explicit-leading, omitted-trailing case retain the pending timer through their quiet edge after separate Collection cleanup. The oracle passes 40/40 with these changes.
The final review found two new compatibility edges. The manager initially treated every strategy's false result as a dropped call. A custom batch strategy may return false while retaining its callback under the existing base type. The public batch witness failed before the narrow fix: its transaction was failed at the admission cut, and the later callback could not commit. Only debounce and throttle now interpret false as an intentional drop. The same witness remains pending until its t=10 callback and then fulfills its receipt.
The debounce strategy also checked the live caller-owned options.trailing after giving LiteDebouncer a copy. A caller could change that exposed option after construction, causing the admission result to disagree with the captured timer setting. A public witness starts a leading-only write, changes options.trailing to true, and calls again inside the window. Before the fix, the second transaction stayed pending. The strategy now checks the captured trailing value and rejects that second call. This preserves the construction-time option meaning and prevents a mutable options object from stranding a receipt.
The final primary oracle passes 42/42. It covers the listed finite clock histories, edge options, public rows, callback starts, transaction state, and receipts at their named cuts. New debounce calls after cleanup, failed persistence, and broader generated schedules remain outside the owner. The primary oracle and coverage map name both the repaired class and its limits.
Final implementation commit: 7733fc042580ac7b9f4585b077db722e32786697. On that commit, the paced oracle passed 42/42, the existing DB paced suite passed 13/13, and the React hook suite passed 6/6. DB and React package typechecks, changed-file ESLint, Prettier, and diff whitespace checks passed. The full PR's production source diff from merge base 33a194941c8d51f8f98babb999fef2987dd6ff8b was +140/−31 lines, net +109. Tests and contract documentation are excluded from that weight. The final independent review's batch and mutable-options counterexamples were RED before their narrow fixes and GREEN afterward. No reachable in-scope counterexample remains in the named finite histories; failed persistence, later strategy admission after cleanup, and broader schedules retain the coverage-map owner.