Changes touching this path

• the site read tiers read the tree at one version by its manifest key instead of scanning every tree entry on the forge: listTree joined the tree view to the change view, both security_barrier views that Postgres does not flatten, so the join could not reach the tree_entry primary key and was answered with a scan of the whole table, every repo and every version, hashed down to one manifest. tree.ts treeAt now reads the tree view in a lateral subquery keyed by the change row manifest id with OFFSET 0, the #2346 shape, for the anonymous, owner and member tiers alike, and a new entryAt reads one path by (manifest_id, path), which the private blob route and the anonymous blob and diff loaders now ask instead of listing the whole tree and searching it. the views and their gates are unchanged and no migration is needed. measured as forge_owner on a throwaway Postgres 18 with 1,400 changes and a 7,240-path head, median of 7 runs (of 5 on one core): at 1.5M tree_entry rows the listing went from 148.7 ms (304.5 ms on one core) to 19.1 ms, at 7.6M from 607.9 ms (1,618 ms on one core) to 18.6 ms, and the one-path read is 0.26 and 0.25 ms where the blob route paid the whole listing, the same 7,240 rows and md5 before and after. pinned: a plan pin in owner.pg, member.pg and read.pg asks for both statements with nested loops and sequential scans priced out and refuses a tree_entry read not keyed by the change row manifest id, beside one-path tests on each tier. red under named mutations, each restored, over the 7 selected tests: the old join (3 failed and 4 passed), OFFSET 0 dropped (3 and 4), the old join for the one-path read alone (3 and 4), and the path filter dropped (3 and 4). bands() in the history route has the same scan (about 860 ms at 7.6M rows) and is left as it was, with a comment saying why the lateral alone does not cure it there. cargo test green, 4757 passed over 144 binaries with 13 ignored, the site live suites at 85 passed and the site gate at 863 passed. owes a site deploy (nyvxmxqz) 7e0ae25b · dbf3dbe6…
• the read.pg plan pin no longer swallows the tail of the test it was inserted into: 674494c put its new it() for the tree read by manifest key in the middle of opens the metadata half with one boolean, published half unmoved, so the change, historyOfPath and publishedIndex assertions ran after the pin finally block and reported under the pin name. site/test/read.pg.test.ts closes the pin after its finally and moves those assertions back into the metadata-half test, which now reads as it did before 674494c plus the entryAt lines 674494c added. site/test/plan.ts states what planWithLoopsPricedOut needs of its db, every query on one connection inside one open transaction, instead of naming withOwner and withMember. read.pg keeps its one-client ReadDb rather than readDbFromUrl, which is a pool of up to 10 clients and so does not promise that the pin SET LOCAL and EXPLAIN share one transaction. red under named mutations, each restored, over the 16 read.pg tests: a moved change message assertion broken fails the metadata-half test under its own name (15 passed and 1 failed), where on the unfixed file the same mutation failed under the pin name (15 and 1), and OFFSET 0 dropped from treeAt fails the pin alone (15 and 1). the site live suites at 85 passed over 7 files against a throwaway Postgres 18 and the site gate green at 881 passed; site tests only, no Rust touched and no cargo test run. no deploy owed; it also files kzwowoww (kzwowoww) e50ebf01 · dbf3dbe6…diff
• the History view reads its ledger and its bands by key: the ledger walk reads each step of parents through a lateral OFFSET 0 subquery over the parent view, and the page change rows and the size count read the change view the same way, so no step reads every change on the forge; bands() restricts the change view by the version ids it was asked for and reads the tree view laterally by manifest id and path, and forge migration 0028 adds change_node_by_manifest, the index the tree view gate asks a change by, so that gate no longer scans change_node once per touched path. the views and their gates are unchanged. measured as forge_owner on a throwaway Postgres 18 with 5,000 changes and 7.6M tree entries, medians of 7: page 1 of the ledger of a 1,400-deep line 1.7 s to 21 ms, its size query 1.7 s to 19 ms, and the bands of a 50-version page whose changes touched 6,356 paths, the ids bound as one array as the site binds them, 25.7 s to 56 ms, and 547 ms without the index. pinned in plan pins in owner.pg, member.pg and read.pg refusing an unkeyed read of change_parent, change_node or tree_entry in the ledger page, the size and the bands, planned with change_node holding enough rows that a keyed read wins, since on a near-empty table the gate read tied with a walk of the primary key and was taken. red under named mutations, each restored, each 3 failed and 7 passed over the 10 selected tests: the step as a plain join, the step without OFFSET 0, the page change rows as a plain join, the size count as a plain join, the bands tree read as a plain join, the bands change read without the id restriction, and the index dropped. not taken: an index on path_touch(repo_id, version_id), since the scan of the repo touches took 2 ms of the 60 ms bands query. cargo test green, 4829 passed over 144 test result lines with 14 ignored, the site gate green at 892 passed, and the site live suites 88 passed, also on a fresh cluster through ci/local.sh. owes a forge deploy for migration 0028 before the site deploy; it also carries the comment of review sweep 5 on mpkswzkl and files its fix-up ticket ztyxspll (rlztuvmo) c8bae938 · dbf3dbe6…diff
• the static Clerk key verifies outside the key cache the JWKS copy lives in: clerk.ts byStaticKey makes the category check verifyToken makes and hands a JWK built from CLERK_JWT_KEY to the same verifyJwt with the same options, where verifyToken given the key filed it through loadClerkJwkFromPem marked never to expire, which stopped the JWKS copy expiring, so a key the instance dropped kept verifying over the JWKS until a restart. a refusal Clerk reports as a failed verification goes to the JWKS only when the static key does not verify the signature, so a missing sub or a non-numeric exp, nbf or iat is answered by the static key alone, as the verify doc said and the code did not; the loot-wasm open_sealed_grant, grants.ts keyFor and CONTEXT.md cost claims now add a verify per authored change a grant body carries; the fetch an unknown key id costs is documented; site/test/plan.ts withChangesAtScale inserts inside its try and analyzes again after its deletes; Seam::Gate moved and Converged.moved say what they mean beside the anchor. pinned in 4 new clerk-verify tests: a dropped key stops verifying five minutes after the fetch though the static key verified after it, claim failures answered without the JWKS, HS256 keyed by the public key, the machine category and RS384 refused over both keys, and a key with its line breaks removed read. red under named mutations, each restored, over the 12 clerk-verify tests: the static path back on verifyToken (2 failed and 10 passed), no signature re-check (1 and 11), no category check (1 and 11), the JWK without alg (1 and 11), the PEM read with its armour lines kept (8 and 4); before the fix the new tests went 2 failed and 9 passed of 11. not taken: the span wrapping shared across the pool db.ts files, and running the pg files serially. cargo test green, 4832 passed over 144 test result lines with 15 ignored, the site gate green at 913 passed, and the site live suites 90 passed. owes a site deploy, after which CLERK_JWT_KEY can be set; it also files qpsuxosk, ylrvoopz, the Tickets route server time, and zlulwtlw, the History route live query time, carries a comment on uyzzknlm and resolves zxkpzxvz (qpsuxosk) 96800555 · dbf3dbe6…diff
• each statement of a private route is named in its Server-Timing: a pool query takes the name of its statement beside its SQL and records it under the pool prefix, owner.tickets.graph for one, where every statement of a pool summed under one name such as owner.query; the transaction statements are begin, bind, commit and rollback, the identity transaction is timed too, the anonymous read pool takes the names as well, json times writing the answer as answer, and the Tickets fold is tickets.first. the Tickets read reads what it answers by key: the head ticket files from tickets/ on in the tree key, in byte order and without the published flag it never answered, the history as the parent edges walked from the head, and the touches from tickets/ on in the repo touches, each id as hex from Postgres, where it read the whole head tree, every change and parent edge of the repo through views that read every change on the forge, and every touch of the repo, and turned each id into hex in the site. the answer is the same but for the order of its files. measured on a throwaway Postgres 18 shaped like this tracker, 5,463 ticket files at a head 1,400 changes deep with 3.8M ticket entries in the history trees, the read and its JSON took 78 ms before and 33 ms after, medians of 15 in two rounds, and with a second repo of 200,000 changes 151 and 152 ms before and 32 ms after; the two answers compared equal, files as a set. pinned in the new owner.pg tests that count a generation across a merge and past a parent the repo does not hold and that read the Tickets view files, history and touches through keys, in the pool timing tests now expecting each statement by name, and in private-timing, which names the writing of its answer. red under named mutations, each restored, over the 5 selected live tests: roots taken without asking the change view (1 failed and 4 passed), the walk step without OFFSET 0 (1 and 4), the step as a plain join (1 and 4), the touches without their bound (1 and 4), the files without their bound (1 and 4), the owner pool under one name (1 and 4); and the answer untimed (2 failed and 8 passed of the 10 private-timing tests). not taken: grouping the touches by change in the answer, since writing the whole answer took about 2 ms. the site gate green at 914 passed and the site live suites 92 passed; no Rust changed. CONTEXT.md says so. owes a site deploy; it also carries comments on uyzzknlm, zsxqmrtm, woyvmtwq and kwlxstko (ylrvoopz) 2a747a82 · dbf3dbe6…diff
• the History ledger walks one depth a step and bands a page asking each change tree once: ledgerWalk reads the parents of each version once, at its least depth, carrying as seen the versions of each depth that reached two or more, where its UNION over version and depth rows re-read a version once for every depth a path reached it at, 37,044 reads of parents for the 1,366 versions and 75 merges of this repo graph, which the linear fixture of rlztuvmo could not show; bandsOf groups the page touches by version and asks the tree view for each change with its touched paths as one array, so the view is read once per change and in the plans measured its gate ran once per change, where both ran once per touched path. measured as forge_owner on a throwaway Postgres 18 with this repo graph as a fixture, medians of 7: a first ledger page 273 ms before and 37 ms after, the ledger size 273 and 36 ms, and the bands of a page touching 6,170 paths 82 ms over 142,724 buffers before and 34 ms over 20,582 after; over the 1,400-deep line of rlztuvmo the page went from 32 to 34 ms and the bands from 21 to 16 ms. the answers compared equal row for row at depth caps of 2000, 300 and 7, and the bands over three sets of versions. live the page had read 644 ms and the bands 363 ms; the fixture reproduced the walk and not the whole bands gap. the seen rule was checked against a plain breadth-first walk over 20,000 random graphs with several heads, missing parents and a depth cap: no mismatch, and 10,927 and 3,610 mismatches with seen never grown or grown only past two versions. pinned in a new owner.pg test over a ladder of 8 diamonds: the answer, a walk capped at depth 5, and the plan loops, no read of change_parent run more often than there are versions and none of tree_entry more often than there are changes. red under named mutations, each restored, over the 3 selected live tests: the old walk back (1 failed and 2 passed), seen never grown (1 and 2), seen grown only past two versions (1 and 2), the old bands back (1 and 2), and the bands asking one path at a time (1 and 2). cargo test green, 4832 passed over 144 test result lines with 15 ignored, the site gate green at 914 passed, and the site live suites 93 passed. CONTEXT.md says so. owes a site deploy and no forge migration; it also carries a comment on ylrvoopz (zlulwtlw) 05f831e6 · dbf3dbe6…diff
• the History ledger walk carries no record of the versions it read on its rows: each row writes its depth as the scale of a zero, 0 then 0.0 then 0.00, and since a numeric compares by value a recursive UNION drops every later row of a version, so the walk keeps one row per version, at its least depth, and reads its parents once, where the zlulwtlw walk carried seen on every depth row and over 16 lanes of 2,100 changes stored 1,127,928 kB and took 9.8 s for a first page. measured as forge_owner on a throwaway Postgres 18, a first page in medians of 3, for the walk before zlulwtlw, the zlulwtlw walk and this one: this repo graph 259, 36 and 31 ms, the 1,400-deep line 33, 34 and 32 ms, 2 lanes 91, 373 and 87 ms, 4 lanes 187, 1,067 and 182 ms, 8 lanes 361, 3,055 and 338 ms, 16 lanes 735, 9,823 and 700 ms; the size query over this repo graph, the line, and 2 and 16 lanes went alike, 258, 36 and 29 ms, 32, 33 and 30 ms, 86, 381 and 84 ms, and 686, 9,463 and 654 ms. the answers compared equal to the walk before zlulwtlw row for row over this repo graph, the line, and 2 and 16 lanes at depth caps of 2000, 300 and 7, and over 21,000 random graphs with several heads, missing parents and depth caps: 143,645 rows and no difference, where a step of two places differed on 17,657 graphs and a value distinct per depth left 47,724 versions walked more than once. pinned in a new owner.pg test over 4 lanes of 150 changes: the answer, a walk capped at depth 5, and no CTE the page scans storing more than 256 bytes a version. red under named mutations, each restored, over the 4 selected live tests: the zlulwtlw walk back (1 failed and 3 passed, 1,642 kB against a bound of 150), the walk before it back (1 and 3), a value distinct per depth (1 and 3), and two places a step (2 and 2). cargo test green, 4842 passed over 144 test result lines with 15 ignored, the site gate green at 915 passed, and the site live suites 94 passed. CONTEXT.md says so. owes a site deploy and no forge migration (rmwmkyvu) 01378d5e · dbf3dbe6…diff

Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.