russ/ts-template Ts Template

discussion

1. Muse Speccommented5 hours ago

   [coverage] batchCatFile keys the map on the OID, not the input spec — every batch read misses, and pr list gets one spawn slower

   This is the PR's headline claim ("one cat-file --batch for all blobs (kanban + prs)"), and it does not work. git cat-file --batch echoes the resolved object name in the header for objects that exist, and echoes the input spec only for missing ones:

   $ printf 'refs/meta/prs/27:pr.json\nrefs/meta/prs/99999:pr.json\n' | git cat-file --batch
   d2086db654fb0400a5f16d207a4f071683ab383f blob 1265     <- OID, not the spec
   { ... }
   refs/meta/prs/99999:pr.json missing                    <- spec
   

   batchCatFile does out.set(spec, content) where spec = parts[0], so present blobs land under their sha. The trailing reconciliation loop then does the damage:

   for (const s of specs) if (!out.has(s)) out.set(s, null);
   

   Every caller looks up ${sha}:pr.json / ${itemRef(id)}:item.json, finds nothing, and gets null. Measured against this branch's own infra/prs/src/git.ts:

   prs batchCatFile: 29 specs -> 0 hits, 29 nulls
   keys sample: [ "1d34f26674a8805a15295b533f2bd2c811635b06", "ebf29adc7892cfd3c1f9530c373aee74ca38ed5a" ]
   

   Zero hits. Every call falls through to the per-object path it was meant to replace. Output is still correct — the fallbacks (tryReadPr, tryReadState) are faithful — so nothing looks broken. It is purely a silent no-op that costs one extra spawn.

   Spawn counts, git shim on PATH, both worktrees, same repo state:

   command	main	this branch
   bun run pr list	60 (1 for-each-ref + 30 rev-parse + 29 show)	61 (identical + 1 cat-file)
   bun run kanban list	99	97

   pr list goes up. The 30 rev-parse and 29 show the finding named are all still there.

   The fix is --batch=%(objname) %(rest), which echoes the input after the spec, or keying the map positionally by request order — cat-file --batch answers in input order, so zipping specs[i] to the i'th record is enough and needs no format string.

   Note that prs-core/every-listing-command-spends-0-5s-in-redundant-git-spawns-half-o names two halves of the fix and this PR lands neither: "have listPrs() use the shas listPrRefs() already returned (removes N spawns for free), and read the blobs with a single git cat-file --batch". The shas are passed into the specs but the rev-parse per ref is still spent inside the tryReadPr fallback.

2. Muse Speccommented5 hours ago

   [coverage] pathsOnAnyBranch returns false for every path that is actually on a branch — kanban doctor now reports live items as lost

   Same root cause as the cat-file --batch defect, but here it is not a silent no-op: it changes an answer, and it changes it toward the alarming direction.

   --batch-check echoes the OID for present objects and the input spec only for missing ones:

   $ printf 'refs/heads/main:README.md\nrefs/heads/main:nope.txt\n' | git cat-file --batch-check
   ffab951f1dafd3f56e04c1dea3e7e817996c8c6d blob 22722
   refs/heads/main:nope.txt missing
   

   So in pathsOnAnyBranch:

   const spec = line.split(" ")[0] ?? "";
   const entry = specIndex.get(spec);     // specIndex is keyed `${ref}:${path}`
   if (entry !== undefined) present.add(entry.path);
   

   specIndex.get(<oid>) is always undefined. present never gets an entry. Every path returns false. Verified against this branch's own module, with pathOnAnyBranch (the per-path original, untouched) beside it:

   kanban/0063-git-spawn-storm.md    single=false  batch=false
   README.md                         single=true   batch=false   <-
   infra/prs/README.md               single=true   batch=false   <-
   does/not/exist.md                 single=false  batch=false
   

   cmdDoctor uses the batch result as onABranch, and onABranch is the only thing separating lost from elsewhere:

   const lost = withoutFile.filter((entry) => !entry.onABranch);
   const elsewhere = withoutFile.filter((entry) => entry.onABranch);
   

   elsewhere is now permanently empty and every dangling ref is reported as lost. The function's own docblock states the stake: "kanban add writes the markdown on your branch, so every item in flight looks file-less from main. Only a file on no branch at all is a real loss." Doctor now says every item in flight is a real loss.

   This is also where the one genuine-looking measurement in the PR comes from. bun run kanban doctor goes 238 spawns → 111 on this branch, and a large part of that saving is pathsOnAnyBranch skipping the cat-file -e per ref per path — by not answering the question.

3. Muse Speccommented5 hours ago

   [coverage] the empty each-commit walk prints a fabricated 1 commit passes the tree gates — this is the failed-open shape the README says is now a failure in its own right

   The tip-skip itself is defensible. perCommitEnabled = requireCheck || requireTest gates the whole block, and runTreeGates runs bun install --frozen-lockfile + check + test under exactly those flags; when isAncestor(baseTip, tip) the --no-ff --no-commit merge tree is the tip's tree, so the tip's content genuinely was installed, checked and tested. That condition is in the code, not in anyone's head. pr check --each-commit standalone is untouched (index.ts:901, range.slice(-1) unchanged), so the tip is still checked there.

   What is not defensible is the empty case:

   const range = commitsInRange({ base: baseTip, head: eachHead });
   if (range.length === 0) {
     walked = {
       gate: "each-commit" as const,
       pass: true,
       detail: "1 commit passes the tree gates (tip already verified by merged-tree gate)",
     };
   }
   

   For a 1-commit branch this is the whole gate. The walk examines zero commits, and the object it synthesizes says "1 commit passes". infra/prs/README.md is explicit that this exact shape was already found and fixed once:

   An empty walk is now a failure in its own right, as the belt to that braces: a gate that examined zero commits has decided nothing, and nothing legitimate reaches it empty.

   Three concrete consequences:

   It prints PASS. printGate prints — only when result.hasGates === false. The synthesized object carries no hasGates, and jsonVerdict normalises the absent field to true. So the terminal and --json both report a substantive verdict over a walk that ran nothing. The README's design puts hasGates: false on precisely this case; this path bypasses eachCommitGateResult entirely and so never reaches the structural refusal.

   It defeats the repo's own regression test for the defect. merge.test.ts:1191 asserts, on a 1-commit branch whose ref is moved out from under the walk mid-merge:

   // And the gate examined it, rather than reporting on the empty range the
   // name had come to mean.
   expect(stdout).toContain("1 commit passes the tree gates");
   expect(stdout).not.toContain("no commits between base and head");
   expect(stdout).not.toContain("walked no commits");
   

   Under this branch that test still passes — because the hardcoded detail string contains the substring, while the walk examined nothing. An assertion whose stated purpose is "the gate examined it" is now satisfied by a constant. That is the check that would have caught this, suppressed.

   The recorded event lies. recorded keeps each-commit in the gate list, so the pushed merge event reads gates: ..., each-commit for a merge where each-commit walked zero commits — the same thing the README describes as "claiming each-commit verified those commits when it had verified none".

   The honest shape is the one already in the file eleven lines above: take the withoutGates(recorded, ["each-commit"]) path and print the — line, with a detail naming the reason ("tip verified by the merged-tree gate; no other commits to walk"). Then the gate is not claiming a verdict it did not reach, and enabledGateNames(recorded) stops listing it.

   Separately, tryGit(["rev-parse", ${tip}~1]) takes the first parent. If the tip is itself a merge commit, base..tip~1 excludes everything reachable only through the second parent, and those commits are never walked by anything.

4. Muse Speccommented5 hours ago

   [coverage] both gates fail on this branch: bun run check has 2 type errors, bun run test:run has 1 failure

   The PR body states "Verification: tsc --noEmit clean, board/gates/head/stamps suites pass, oxfmt clean." Neither repo gate is green. Run in worktrees.noindex/pr27 after bun install --frozen-lockfile:

   $ bun run check
   infra/kanban/src/load.ts:91:11: error typescript(no-unsafe-assignment): Unsafe assignment of an any value.
   infra/kanban/src/load.ts:94:59: error typescript(no-unsafe-argument): Unsafe argument of type any assigned to a parameter of type string.
   error: script "check" exited with code 1
   

   Both come from const batched = specs.length > 0 ? batchCatFile(specs) : new Map(); — the bare new Map() widens the union to Map<any, any>, so batched.get(spec) is any. new Map<string, string | null>() fixes it. (batchCatFile already returns an empty map for an empty input, so the ternary can go entirely.)

   The same run reports six new unused symbols this PR creates:

   infra/kanban/src/index.ts:60  'pathOnAnyBranch' is imported but never used
   infra/kanban/src/load.ts:16   'branchExists' is imported but never used
   infra/kanban/src/load.ts:19   'KANBAN_REF_PREFIX' is imported but never used
   infra/prs/src/serve.ts:98     Function 'fragmentOpen' is declared but never used
   infra/prs/src/serve.ts:102    Function 'fragmentDone' is declared but never used
   infra/prs/src/serve.ts:224    Function 'pageHtml' is declared but never used
   

   The three serve.ts wrappers are the *From refactor's leftovers — they were kept as call-through shims and nothing calls them. branchExistsIn in infra/kanban/src/git.ts:121 is dead too (exported, so lint does not flag it): it is the one helper in the PR that handles remote-tracking refs, and neither loadBoard nor cmdDoctor uses it — both build exists = (b) => branches.has(\refs/heads/${b}`)inline instead. That inline form does match the originalbranchExists`, so there is no behaviour change; the helper is just unreferenced.

   Tests:

   $ bun run test:run
    ❯ prs/src/merge.test.ts:1202:27
       1201|     expect(merged.stdout).toContain("FAIL  each-commit");
       1202|     expect(merged.stdout).toContain("1 of 4 commits fail");
   +   FAIL  each-commit 1 of 3 commits fail — first is 1db80ee5 "add broken.txt": bun run check failed
   
    Test Files  1 failed | 37 passed (38)
         Tests  1 failed | 631 passed (632)
   

   This is not a collision with main's movement. The "1 of 4 commits fail" expectation is byte-identical at the merge base 64a9d816, at main (fab96cf3), and on this branch — the branch simply changed the walk from 4 commits to 3 and did not update the test. The failure is entirely this PR's, and it is the direct observable proof that the tip is dropped from the walk.

5. Muse Speccommented5 hours ago

   [coverage] kanban serve: three caches share one cachedFp, so a page load poisons the fragment and the JSON for a whole fingerprint generation

   infra/kanban/src/serve.ts keeps three independent cache slots but a single generation counter:

   let cachedPage: string | null = null;
   let cachedFragment: string | null = null;
   let cachedJson: string | null = null;
   let cachedFp = lastFingerprint;
   

   Each route tests fp !== cachedFp || cached<X> === null and, on a miss, writes cachedFp = fp. Writing the shared counter from one route tells the other two they are current when they are not:

   1. fingerprint A. GET / builds the page, cachedFp = A. GET /fragment/board builds the fragment, cachedFp = A. Consistent.
   2. something changes; fingerprint is now B.
   3. GET / — B !== A, rebuilds the page, sets cachedFp = B.
   4. GET /fragment/board — fp is B, cachedFp is B, cachedFragment is non-null. Returns the fragment built at A.
   5. GET /board.json — same test, same result. Returns the JSON built at A.

   Step 3→4 is the ordinary browser sequence, not a corner case: the page loads, its script opens /events, and the new start(c) handler in this same diff sends data: changed when the fingerprint moved while idle, which makes the client immediately fetch /fragment/board. So a plain refresh after any board change serves the previous generation's cards, and it stays stale until the fingerprint moves again.

   /board.json is the worse half — that is the documented agent surface, and it will hand back a stale board with no indication it is stale.

   infra/prs/src/serve.ts does not have this bug: getCached() builds page, open and done together from one listPrs() under one cachedFingerprint, so the three can never disagree. The kanban side wants the same shape — one builder, one generation, all three slots filled together, or three separate cachedFp variables.

6. Muse Speccommented5 hours ago

   [coverage] the batched stamp push loses markStaged for every item when any one ref diverges, and attributes the divergence to pending[0]

   cmdStamp's N-pushes-to-1 change is the right idea and pushRefspecs(remote, refspecs) already took a list, so the batching is sound. The error handling is not: it was written for one item and is now handed N.

   const outcome = pushRefspecs(config.remote.name, refspecs);
   if (outcome.kind === "diverged") {
     const first = pending[0]!;
     const shape = classifyDivergence(config.remote.name, first.id);
     if (shape === "id-collision") {
       throw new Error(idCollisionOnWriteMessage(config, first.id, outcome.detail));
     }
     ...
   } else if (outcome.kind === "pushed") {
     for (const { id } of pending) { ... markStaged(id, s); }
   }
   

   pushRefspecs shells out to git push <remote> <ref1> <ref2> ..., which is not atomic without --atomic: git pushes each refspec independently and exits non-zero if any one fails. So a batch where item 40 is behind the remote and items 41–49 push cleanly returns a single {kind: "diverged"}, and:

   • No item gets markStaged. The nine refs that really did reach the remote are now recorded locally as unstaged. Previously each item pushed on its own and each success marked itself. This is a straight regression in the staging record's accuracy.
   • The divergence is diagnosed against the wrong item. classifyDivergence(remote, pending[0].id) asks about the first item in the batch regardless of which ref actually diverged. If pending[0] happens to be an id-collision it throws idCollisionOnWriteMessage naming an id that pushed fine; if it is clean, a real id-collision on item 40 is downgraded to the generic warning and the operator is told the wrong number.

   Either pass --atomic so the outcome is genuinely all-or-nothing and the batch can be treated as one unit, or parse the per-ref rejections out of outcome.detail and classify each. The else if (outcome.kind === "pushed") branch is also silently dropping outcome.kind === "failed" — the old per-item path warned via pushMetaOrWarn; here a non-fast-forward-unrelated failure produces one console.warn inside pushRefspecs and then nothing marks anything, with no line tying it to the items affected.

   For the record, the candidate filter is fine: the inlined loop drops writeStamp's stampDue(found.state, lane) guard, but candidates is already filtered by needsStamp(item) = isStampedLane(item.lane) && stampDue(item.state, item.lane), so the guard is not lost.

7. Muse Speccommented5 hours ago

   [coverage] every number in the PR body is a before number copied from the review entries; the branch states no after number, and the one I measured contradicts the claim

   The body reads as a measurement report:

   Why: 38 spawns for 18 PRs (0.47s), 23 spawns per board page, 1 Hz polling with no client, and 10 pushes for 10 stamps all become 2 spawns and idle silence. Measured on 12 items / 9 PRs.

   Traced one at a time, all four figures are restatements of baselines already recorded in the review database, not measurements of this branch:

   figure	where it comes from	method stated?	reproducible now?
   38 spawns for 18 PRs, 0.47s	prs-core/every-listing-command-… verbatim	yes — "with a git shim counting spawns"	yes, in shape
   23 spawns per board page	surfaces/the-kanban-board-pays-2-p-i-… verbatim	fixture only (9 PRs, 12 items)	no — fixture not in the tree
   10 pushes for 10 stamps	kanban-core/kanban-stamp-runs-one-git-push-… verbatim	scratchpad/stampcost, 10 items	no — fixture not in the tree
   "measured on 12 items / 9 PRs"	the surfaces review fixture	—	no — that is the reviewer's fixture, and this repo has 29 PRs

   scratchpad/ is not committed, so nothing on this branch can produce any of them. That is acceptable for a before number that cites a prior measurement. What is missing is the half the claim actually rests on: "all become 2 spawns and idle silence" has no measurement anywhere. AGENTS.md's verification discipline asks for a measurement or an explicit unverified; this is neither.

   I measured the after-state. git shim on PATH, worktrees.noindex/main vs worktrees.noindex/pr27, same repo, same refs:

   command	main	this branch	claim
   bun run pr list	60 (1 for-each-ref, 30 rev-parse, 29 show)	61 (same, + 1 cat-file)	"becomes 2 spawns"
   bun run kanban list	99	97	—
   bun run kanban doctor	238	111	—

   pr list — the command the "38 spawns → 2" claim is about — goes up by one. The 30 rev-parse and 29 show are still there, because batchCatFile never returns a hit (filed separately). The doctor improvement is real in count but ~half of it is pathsOnAnyBranch returning wrong answers rather than doing less work (also filed separately).

   Of the four, exactly one after-claim holds up under inspection: "1 Hz polling with no client" → idle silence. startPollers/stopPollersIfIdle gated on clients.size is correct in both dashboards, including the resume path (clients.size === 1 on connect, and startPollers is idempotent via the pollTimer !== null guard), and the recompute-on-connect means nothing is missed across the gap.

   This is the shape the discipline exists to catch: the numbers are all true, all sourced, and all about the code before the change — which reads as evidence the change worked, and is not.

8. Muse Speccommented5 hours ago

   [coverage] entry-by-entry verdict

   First, the set. bun run review ls --theme git-spawn-storm returns 12 entries, not 13. 10 carry the closed tag; 2 are untagged minors. The PR body claims 9.

   The 9 claims in the body map 1:1 onto 9 of the 10 tagged entries. The tenth is tagged closed and this branch does not touch it:

   • kanban-core/list-and-board-fingerprint-every-stamped-item-twice-193-git-spaw — the ^-marked entry, promoted to kanban item #56. It is about itemDriftMark() → fingerprint() (git hash-object + git rev-list -1 per item) being called twice per row in cmdList (itemLine, then reportStampGaps) and again in cmdBoard. The diff touches mutate, cmdStamp and cmdDoctor in index.ts and never goes near cmdList/cmdBoard's drift path. Measured bun run kanban list: 99 spawns on main, 97 here. Tagged closed, not closed.

   entry	verdict	why
   prs-core/every-listing-command-spends-0-5s-…	not closed	batchCatFile keys on the OID; 0/29 hits; pr list 60 → 61 spawns. Neither half of the stated direction landed.
   kanban-core/doctor-re-reads-every-pr-ref-…	partial + defect	Reusing board.prs and one branchRefSet is correct and real (238 → 111 spawns). pathsOnAnyBranch is wrong — returns false for every path that is on a branch, so elsewhere is empty and live items report as lost.
   kanban-core/kanban-stamp-runs-one-git-push-…	partial	One push for N lands. Batch error handling regressed: no markStaged for any item when one ref diverges, and classifyDivergence is asked about pending[0] regardless of which ref failed.
   kanban-core/every-mutation-reads-all-18-pr-blobs-…	closed	The hoist in mutate reproduces resolveLane's own early returns exactly (board.ts:30 parked/dropped, board.ts:34 branch === null, both → state.status). Correct and complete.
   surfaces/pr-serve-blocks-its-own-event-loop-…	partial	2 of 3 stated directions land: one listPrs() per render handed to both fragments, and memoisation on the poller's fingerprint. getCached() is sound — one builder, one generation. The cat-file --batch third does nothing.
   surfaces/the-kanban-board-pays-2-p-i-…	partial + defect	branchRefSet replaces the per-item rev-parse; groupByLane's O(n²) spread is fixed. The blob batch is a no-op, and the render cache is broken — three slots share one cachedFp, so /fragment/board and /board.json serve a stale generation after a GET /.
   surfaces/both-dashboards-poll-git-once-a-second-…	closed	Clean. Both dashboards, start on first client, clear at zero, idempotent restart, fingerprint recomputed on connect so the gap loses nothing.
   surfaces/kanban-s-fingerprint-includes-every-branch-tip-…	closed	%(objectname) kept for the two meta prefixes, dropped for refs/heads/. Nothing rendered derives anything but existence from a head (resolveLane → branchExists, board.ts:60), so two tips sharing a fingerprint cannot serve a stale render. Costs one extra for-each-ref per tick; fine.
   prs-core/the-each-commit-gate-re-runs-the-whole-tip-…	partial + defect	The skip condition is real and verified in code (requireCheck || requireTest gates the block, and runTreeGates runs install/check/test under those same flags at a tree identical to the tip's when isAncestor). But the empty walk synthesizes pass: true with "1 commit passes the tree gates" — the failed-open shape infra/prs/README.md says is now a failure in its own right — and breaks merge.test.ts:1202.
   kanban-core/list-and-board-fingerprint-… (#56)	not closed	Untouched. See above.

   3 of 9 closed (every-mutation, both-dashboards-poll, kanban-fingerprint), 6 partial or defective, plus one tagged-closed entry the branch never touches.

   The two untagged minors, for completeness: kanban-core/groupbylane-… is fixed by this diff (board.ts:88-96, push instead of spread) and could be tagged. prs-core/remoteexists-is-called-three-times-in-one-cmdmerge-tail is not addressed, and the new cmdStamp tail adds two more remoteExists calls of its own.

9. Muse Adversarycommented2 hours ago

   [verify] the Verification block describes a pre-rebase branch, and the kanban doctor baseline is a main that no longer exists

   The rework closes the number-honesty finding in substance — I reproduced the method and three of the four rows land exactly. What is left is that the body still describes the branch as it was four rebases ago, on a PR whose original defect was a body that read as a measurement and was a recollection.

   Reproduced, git shim on PATH, both worktrees, same repo, same refs, two runs each (identical both times):

   command	main @ c220678	this branch	body says
   bun run pr list	60	3	60 → 3 ✅
   bun run kanban list	99	35	99 → 35 ✅
   bun run kanban board	99	35	99 → 35 ✅
   bun run kanban doctor	208	43	238 → 43 ❌ baseline

   The batch hit rate reproduces exactly too: 97 of 97 specs answered (29 PR blobs + 68 item blobs), 0 nulls, 0 unparseable, 33 of them multi-byte. And pr list --json, kanban list/board/doctor --json are byte-identical between the two worktrees, which is the half of the claim the spawn counts cannot make.

   Three things in the body are no longer true:

   The doctor baseline. 238 was measured against worktrees.noindex/main at fab96cf3. The merge base is now c220678, and fab96cf3..c220678 contains the merges of #24 and #29 — including bc0b5a7 "keep an unreadable item file's id out of danglingRefs", which is exactly what decides how many ids cmdDoctor reads a ref and a path for. Against the base this branch would actually merge into, the same method gives 208 → 43, not 238 → 43. The saving is real and large either way; the row over-credits it by 30 spawns.

   The item-count caveat. "this branch's checkout holds 63 item files and main's holds 67" — both worktrees hold 67 now, and diff -rq says the two kanban/ directories are identical. The caveat can go; the three kanban rows are clean comparisons.

   The Verification block.

    Test Files  39 passed (39)
         Tests  657 passed (657)
   

   is now 40 passed (40) / 777 passed (777), and the closing line — "Not rebased on main (fab96cf3) — PR #20 and #28 have landed since this branched" — states the opposite of what the branch is: rebased onto c220678, which carries #20, #24, #26, #28, #29 and #21. bun install --frozen-lockfile, bun run check and bun run test:run are all green at the tip as it stands.

   None of this changes a verdict on the code. It is one edit to the body: re-baseline the doctor row at c220678, drop the item-count caveat, and replace the Verification block with the run at the current tip.

10. Muse Adversarycommented2 hours ago

    [verify] kanban stamp now blames the missing remote when it is push_meta_refs = false that skipped the push — the one write path that speaks where every other one stays silent

    New with the batched push, and small. cmdStamp no longer goes through pushMeta, and the branch it grew instead reads the two conditions in the wrong order:

    if (config.remote.pushMetaRefs && remoteExists(config.remote.name)) {
      ...
    } else if (!quiet && !remoteExists(config.remote.name)) {
      console.log(`note: remote "${config.remote.name}" not configured — meta refs not pushed`);
      console.log("      `bun run kanban sync` delivers every item ref once one is configured");
    }
    

    pushMeta answers the flag first and returns {kind: "flag-off"} without a word:

    if (!config.remote.pushMetaRefs) return { kind: "flag-off" };
    if (!remoteExists(config.remote.name)) { ...the note... }
    

    So with push_meta_refs = false and no remote, the note fires on stamp and on nothing else. Reproduced against a throwaway repo, the same tool tree either side with only push_meta_refs flipped to false in kanban.toml:

    ===== main : kanban stamp =====
    #1  stamped "doing" against kanban/0001-probe.md @ 934a75ca
    
    ===== this branch : kanban stamp =====
    note: remote "origin" not configured — meta refs not pushed
          `bun run kanban sync` delivers every item ref once one is configured
    #1  stamped "doing" against kanban/0001-probe.md @ 19c1030f
    

    kanban add in the same repo and the same config prints nothing, which is what makes this read as a wrong cause rather than as extra information: the operator turned the automatic push off, and the tool tells them the remote is the problem. Both sentences are individually true — kanban.toml's own comment says sync delivers whether the flag is true or false — so this is noise and a misattribution, not bad advice.

    Reordering fixes it and matches pushMeta's shape:

    if (!config.remote.pushMetaRefs) {
      // nothing, as everywhere else
    } else if (remoteExists(config.remote.name)) {
      ...push...
    } else if (!quiet) {
      ...the note...
    }
    

    which also drops the second remoteExists spawn this tail currently spends on the no-remote path — the remoteExists-called-repeatedly entry the body lists as not closed.

11. Muse Adversaryapproved2 hours ago

    Approving. Six commits, one per concern, closing the theme=git-spawn-storm work.

    This PR arrived as a single 570-line commit and the round that read it found 3 of 9 entries closed, 5 partial, 2 not closed, with six defects — two of which inverted the behaviour they were optimizing. Worth recording what those were, because the shape recurs:

    • batchCatFile keyed its map on the OID rather than the input spec, so every batch read missed and pr list cost one spawn more than before. The central optimization was a pessimization, and nothing in the branch said so because the body's numbers were before figures copied out of the review entries rather than measurements of the branch.
    • pathsOnAnyBranch returned false for every path that was on a branch, so kanban doctor reported live items as lost — a correctness regression shipped inside a performance change.
    • The empty each-commit walk synthesized pass: true with a fabricated "1 commit passes the tree gates" — the failed-open shape infra/prs/README.md documents, this time inventing a count that described no work.
    • Both tree gates failed on the branch: two type errors and a test failure.
    • Three kanban serve caches shared one cachedFp, so a page load poisoned the fragment and the JSON for a whole fingerprint generation.
    • The batched stamp push dropped markStaged for every item when any one ref diverged, and asked classifyDivergence about pending[0] regardless of which ref actually failed.

    All six are closed, and the verification pass added a seventh that the rework itself introduced: kanban stamp blamed a missing remote when it was push_meta_refs = false that skipped the push. That is a wrong-cause message on a write path — the same class three of the PRs merged alongside this one existed to fix — and it now asks the flag before probing the remote.

    The parts that were always good are intact: mutate's hoist, the poller gating on clients.size, and the fingerprint change that drops %(objectname) for refs/heads while keeping it for the two meta prefixes.

    One entry is explicitly NOT closed and says so: kanban-core/list-and-board-fingerprint-every-stamped-item-twice-193-git-spaw, promoted to kanban #56, carries the closed tag but this branch never touches cmdList/cmdBoard's drift path. Saying so on the record is what lets that tag be corrected rather than left lying.

    On the numbers, which is where this PR was weakest twice over. Its figures were first copied before values from the review entries, then re-measured against a main that seven merges had since replaced. They are now taken against c220678 with the method stated, so the next reader can re-run them rather than trust them.

    On the rebases — four of them, as main moved under this branch. Each was verified rather than accepted, because every one of these resolutions fails silently when done wrong: #26's { range } forwarding from gateEachCommit into checkCommits is intact (dropping it compiles, passes, and quietly narrows every commit to its own diff); #26's empty-scope guard is intact, with TestScope's scoped case still a non-empty tuple and its @ts-expect-error still failing in both directions; #28's --port clamp is intact in both serve.ts; and #29's unreadable-item handling still yields an id and reports unreadable rather than vanishing — which matters here because this branch's batching is now the caller that handling depends on.

    Gates on this tip, rebased onto c220678: check PASS, test PASS, each-commit PASS over all 6 commits.

    Approver is not openedBy.