38c01725 · zzmq.dev@gmail.com/zz
Commit
38c0172536aa69417bf95803a850621c62d25548
Build the Ladder tree cache from the write itself, not a re-read A brand-new repo's just-written Ladder notes aren't reliably fetchable from Artifacts for a while after the write -- confirmed live, including from the exact same request/repo-handle the write itself used, so this isn't fixable by being cleverer about re-reading sooner. The fix: stop re-reading at all. mergeRungsIntoLadderTreeCache builds the cached ResolvedRung tree directly from the SimpleRung objects writeLadder already has in hand (same shape, trivial conversion), merged into whatever was already cached. A "_repo" write replaces root's own fields and keeps its existing children (those always come from the separate appendRepoChildren call, not from the rung object itself); a non-root rung is upserted as a child of root directly -- which is also exactly what appendRepoChildren would otherwise be linking, and the one real caller (mergeLaneLadder) always calls writeLadder with the same rungs right before appendRepoChildren, so that second call's own cache step is now unnecessary and left alone rather than risking an Artifacts-read-based refresh clobbering a cache this already got right. Verified live: a brand-new repo's ladder_tree call now returns the real tree (README/LICENSE/changeset, correct summaries) immediately after creation, instead of the previous {"[missing]"} placeholder. ladder_read (which reads one rung directly from Artifacts, not from this cache) still shows the underlying gap when called directly -- expected, and not what the Ladder tab/zz top actually call.
Troy Howard <thoward37@gmail.com> -- 2026-10-13T08:46:35.000Z