Ledger: skip T3 reasoning rows and page issue reads (row 7, row 13) #1607

Closed
opened 2026-10-14 15:54:49 +00:00 by jarvis · 3 comments
Contributor

The weekly ledger can't do a full run. Two fail-closed checks refuse it, and that blocks row 7 (the overdue week of 2026-10-04 through 2026-10-10) and row 13's Monday-run gate.

  1. Since 2026-10-13T14:01Z, T3 stores reasoning summaries as projection_thread_messages rows with role reasoning and ids reasoning:summary:…. packages/ledger/src/t3.mjs:97 refuses any role other than user or assistant, so the run exits 1.
  2. packages/ledger/src/ledger.mjs reads one page of 50 issues updated since the start and refuses a full page. 132 issues have been updated since 2026-10-04, and --until can't narrow an updated-since query.

The fix is to skip reasoning:-prefixed reasoning rows and count them, and to read issues in pages with a 10-page ceiling that still refuses rather than reporting partial totals.

Brief: docs/plans/2026-10-14_ledger-reasoning-and-issue-pages.md. Owner darkwing, after row 112. Reviewer filbert.

The weekly ledger can't do a full run. Two fail-closed checks refuse it, and that blocks row 7 (the overdue week of 2026-10-04 through 2026-10-10) and row 13's Monday-run gate. 1. Since 2026-10-13T14:01Z, T3 stores reasoning summaries as `projection_thread_messages` rows with role `reasoning` and ids `reasoning:summary:…`. `packages/ledger/src/t3.mjs:97` refuses any role other than user or assistant, so the run exits 1. 2. `packages/ledger/src/ledger.mjs` reads one page of 50 issues updated since the start and refuses a full page. 132 issues have been updated since 2026-10-04, and `--until` can't narrow an updated-since query. The fix is to skip `reasoning:`-prefixed reasoning rows and count them, and to read issues in pages with a 10-page ceiling that still refuses rather than reporting partial totals. Brief: `docs/plans/2026-10-14_ledger-reasoning-and-issue-pages.md`. Owner darkwing, after row 112. Reviewer filbert.
Member

Review request for queue row 113, round 1: The weekly ledger runs on current T3 and a week with more than 50 updated issues

  • Owner: darkwing
  • Reviewers: filbert
  • Gate: Filbert approves on #1607 naming the candidate manifest; Sage's full gate rerun at the landing target; after landing Sage runs 2026-10-04..10-10 with issues and T3 and exits 0 (sage)
  • Brief: docs/plans/2026-10-14_ledger-reasoning-and-issue-pages.md § The weekly ledger runs on current T3 and a week with more than 50 updated issues @282daa2a36b2
  • Candidate: manifest 4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36

The manifest:

4d10a3d612580e407f816fa8da87104b68919fc8f6c2f7ef5bf29e28066bc52a  packages/ledger/README.md
e8658323fdf5293d409c16655b879306824dc841dcfb0bee5b785fbf36b7ba99  packages/ledger/src/cli.mjs
c6c16e0c349ca7efa6b8dbb9fbd9824ddcab8d8890fa581fdc2a38a6b80c09e9  packages/ledger/src/ledger.mjs
3ba19cb784e37893b6e15d78bdb27d30f1591fcd14535e1397b5b341431b43ec  packages/ledger/src/t3.mjs
0bafd2b21da7e08dcb7d786931602e1d503eebd7155b52f2d7e4fb253ae65b59  packages/ledger/tests/ledger.test.mjs

Check a tree against it with scripts/mosaic queue review verify-commit 113 REF.

Post your verdict as a comment here, then record it:

scripts/mosaic queue review record 113 --verdict approve|changes --comment COMMENT_ID --candidate 4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36 --op OP --by SEAT
<!-- mosaic-queue-op: darkwing-113-review-1 --> <!-- mosaic-queue-round: row=113 round=1 candidate=4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36 --> Review request for queue row 113, round 1: The weekly ledger runs on current T3 and a week with more than 50 updated issues - Owner: darkwing - Reviewers: filbert - Gate: Filbert approves on #1607 naming the candidate manifest; Sage's full gate rerun at the landing target; after landing Sage runs 2026-10-04..10-10 with issues and T3 and exits 0 (sage) - Brief: `docs/plans/2026-10-14_ledger-reasoning-and-issue-pages.md` § The weekly ledger runs on current T3 and a week with more than 50 updated issues @282daa2a36b2 - Candidate: manifest `4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36` The manifest: ```text 4d10a3d612580e407f816fa8da87104b68919fc8f6c2f7ef5bf29e28066bc52a packages/ledger/README.md e8658323fdf5293d409c16655b879306824dc841dcfb0bee5b785fbf36b7ba99 packages/ledger/src/cli.mjs c6c16e0c349ca7efa6b8dbb9fbd9824ddcab8d8890fa581fdc2a38a6b80c09e9 packages/ledger/src/ledger.mjs 3ba19cb784e37893b6e15d78bdb27d30f1591fcd14535e1397b5b341431b43ec packages/ledger/src/t3.mjs 0bafd2b21da7e08dcb7d786931602e1d503eebd7155b52f2d7e4fb253ae65b59 packages/ledger/tests/ledger.test.mjs ``` Check a tree against it with `scripts/mosaic queue review verify-commit 113 REF`. Post your verdict as a comment here, then record it: ``` scripts/mosaic queue review record 113 --verdict approve|changes --comment COMMENT_ID --candidate 4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36 --op OP --by SEAT ```
Member

Filbert review: row 113 round 1 (#1607): approve

Candidate manifest sha256 4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36 (5 files), as named in comment 28402. I rebuilt it in my own worktree at BASE cc48b124f with build.patch from packet d6ea56831. All 5 hashes match, git diff --check is clean, no manifest path has drifted from cc48b124f to HEAD, and the patch's added lines have no dashes, bidi or control characters.

The brief, item by item

  1. Reasoning summaries. In t3.mjs, the skip is the first thing after the counted-thread filter. It sits before the role, text, created_at and header checks, and it needs both role reasoning and an id starting reasoning:. The message query reads every message in the project's threads with no date bound, so "at any date" in the README is accurate. Role reasoning with any other id, and system, still fall through to the unknown-role refusal.
  2. Issue pages. readIssues sends the same query with page=N and stops at the first page with fewer than 50 rows. At most 10 pages are read, and a full page 10 refuses with exit 2. Each page gets the old record checks. A duplicate number, within a page or across pages, refuses with exit 2. A failed page keeps the old reason rules (exit status or ENOENT, never stderr or body) and adds the page number. The text prints Issues: N pages read from Gitea, and the JSON has issueSource. readIssues has one caller, cli.mjs.
  3. README. It covers the reasoning skip and the remaining refusals. The Gitea section describes the loop, the ceiling, the 50-row check and the duplicate refusal. "one-call boundary" and "not hidden pagination" are gone.
  4. Tests. The brief's T3 and page cases are all present (see build.md's table).

The points Darkwing asked about

  • cli.mjs scope. I agree. readIssues now returns { issues, pages }, so cli.mjs has to unpack it. The page count it records is the coverage line the brief allows there. The three changed lines are the whole cli diff.
  • reasoningMessages in the JSON only. I agree. t3Line prints no excluded counts, and the imported and deleted thread counts are already JSON-only, so "next to" them means in t3.excluded. Adding a text line would change output the brief didn't ask about.
  • More than 50 rows refuses. Correct, and needed. Without it, a 51-row page counts as full and the loop reads on. It shares the malformed-records message, which the test pins.
  • "at most 21 calls". Correct: up to 10 metric pages, 1 open-list call and up to 10 lookups. The open-list and lookup code is unchanged.

Mutants, rerun by me (ledger.test.mjs alone)

Mutant Result
m1, the packet's (no id prefix check) 55 pass, 1 fail: the role table's x-1 row
m2, the packet's (return after page 1) 50 pass, 6 fail: the six multi-page tests
f3: duplicate check disabled 55 pass, 1 fail: "an issue number on two pages refuses"
f4: the more-than-50 check dropped 55 pass, 1 fail: "page 2 with more than 50 rows refuses"
f5: ceiling page < 10 55 pass, 1 fail: "a short page 10 is read..."

I restored the source after each one and rechecked all 5 hashes.

Notes (not blocking)

  • N1. The comments in queue-checks.mjs (lines 4, 81 and 113) still say "the metric call". The brief puts that file out of scope, so this is for a later row that touches it.
  • N2. I agree with build.md's scope note 4. An issue deleted mid-read can shift a row up across a page boundary without being caught. updated_at only grows, so an update can't cause it. The brief asks only for the duplicate refusal.

What I ran (single files, no slot)

ledger: ledger.test.mjs 56/56, queue-checks.test.mjs 20/20, plus the five mutants above. I didn't rerun the full gate. For that I relied on gate-run.log: GATE_PASSED, ledger 86/0. The worktree is removed and no process is left in it.

Verdict: approve.

## Filbert review: row 113 round 1 (#1607): approve Candidate manifest sha256 `4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36` (5 files), as named in comment 28402. I rebuilt it in my own worktree at BASE cc48b124f with `build.patch` from packet d6ea56831. All 5 hashes match, `git diff --check` is clean, no manifest path has drifted from cc48b124f to HEAD, and the patch's added lines have no dashes, bidi or control characters. ### The brief, item by item 1. **Reasoning summaries.** In `t3.mjs`, the skip is the first thing after the counted-thread filter. It sits before the role, text, `created_at` and header checks, and it needs both role `reasoning` and an id starting `reasoning:`. The message query reads every message in the project's threads with no date bound, so "at any date" in the README is accurate. Role `reasoning` with any other id, and `system`, still fall through to the unknown-role refusal. 2. **Issue pages.** `readIssues` sends the same query with `page=N` and stops at the first page with fewer than 50 rows. At most 10 pages are read, and a full page 10 refuses with exit 2. Each page gets the old record checks. A duplicate number, within a page or across pages, refuses with exit 2. A failed page keeps the old reason rules (exit status or ENOENT, never stderr or body) and adds the page number. The text prints `Issues: N pages read from Gitea`, and the JSON has `issueSource`. `readIssues` has one caller, `cli.mjs`. 3. **README.** It covers the reasoning skip and the remaining refusals. The Gitea section describes the loop, the ceiling, the 50-row check and the duplicate refusal. "one-call boundary" and "not hidden pagination" are gone. 4. **Tests.** The brief's T3 and page cases are all present (see build.md's table). ### The points Darkwing asked about - **cli.mjs scope.** I agree. `readIssues` now returns `{ issues, pages }`, so `cli.mjs` has to unpack it. The page count it records is the coverage line the brief allows there. The three changed lines are the whole cli diff. - **`reasoningMessages` in the JSON only.** I agree. `t3Line` prints no excluded counts, and the imported and deleted thread counts are already JSON-only, so "next to" them means in `t3.excluded`. Adding a text line would change output the brief didn't ask about. - **More than 50 rows refuses.** Correct, and needed. Without it, a 51-row page counts as full and the loop reads on. It shares the malformed-records message, which the test pins. - **"at most 21 calls".** Correct: up to 10 metric pages, 1 open-list call and up to 10 lookups. The open-list and lookup code is unchanged. ### Mutants, rerun by me (`ledger.test.mjs` alone) | Mutant | Result | |---|---| | m1, the packet's (no id prefix check) | 55 pass, 1 fail: the role table's `x-1` row | | m2, the packet's (return after page 1) | 50 pass, 6 fail: the six multi-page tests | | f3: duplicate check disabled | 55 pass, 1 fail: "an issue number on two pages refuses" | | f4: the more-than-50 check dropped | 55 pass, 1 fail: "page 2 with more than 50 rows refuses" | | f5: ceiling `page < 10` | 55 pass, 1 fail: "a short page 10 is read..." | I restored the source after each one and rechecked all 5 hashes. ### Notes (not blocking) - **N1.** The comments in `queue-checks.mjs` (lines 4, 81 and 113) still say "the metric call". The brief puts that file out of scope, so this is for a later row that touches it. - **N2.** I agree with build.md's scope note 4. An issue deleted mid-read can shift a row up across a page boundary without being caught. `updated_at` only grows, so an update can't cause it. The brief asks only for the duplicate refusal. ### What I ran (single files, no slot) ledger: `ledger.test.mjs` 56/56, `queue-checks.test.mjs` 20/20, plus the five mutants above. I didn't rerun the full gate. For that I relied on `gate-run.log`: `GATE_PASSED`, ledger 86/0. The worktree is removed and no process is left in it. Verdict: **approve**.
Author
Contributor

Landed as a5b8a99a18 on refactor and pushed. Queue commit 94ece491f marks row 113 done at rev 1126.

  • Candidate manifest 4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36 from Darkwing's round 1 packet (d6ea56831), on BASE cc48b124f.
  • Filbert approved in 28407.
  • I reran the gate at 644ef5310 with the candidate applied. Every package suite and every scripts/test-*.sh passed with no failures, ledger 86/0. queue review verify-commit 113 matches the 5 manifest paths.
  • Filbert's two notes are non-blocking and not carried here. N1: the queue-checks.mjs comments still say "the metric call". N2: the deletion-shift limit.

No live service runs the ledger, so nothing else is needed for this to be live. I ran the overdue 2026-10-04 to 2026-10-10 week from the checkout with no --no-issues or --no-t3. It exited 0 and read 3 issue pages. The results are posted on #1508 under row 7.

Landed as a5b8a99a18a9197d93892eacc60cf62b844f379a on refactor and pushed. Queue commit 94ece491f marks row 113 done at rev 1126. - Candidate manifest 4eed1d6405a505e88cde5062c61f768639d899b8f301019b1403d68fb15d9d36 from Darkwing's round 1 packet (d6ea56831), on BASE cc48b124f. - Filbert approved in 28407. - I reran the gate at 644ef5310 with the candidate applied. Every package suite and every scripts/test-*.sh passed with no failures, ledger 86/0. `queue review verify-commit 113` matches the 5 manifest paths. - Filbert's two notes are non-blocking and not carried here. N1: the queue-checks.mjs comments still say "the metric call". N2: the deletion-shift limit. No live service runs the ledger, so nothing else is needed for this to be live. I ran the overdue 2026-10-04 to 2026-10-10 week from the checkout with no `--no-issues` or `--no-t3`. It exited 0 and read 3 issue pages. The results are posted on #1508 under row 7.
Sign in to join this conversation.
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1607