Changes touching this path

• the collaborator can read someone else's namespace: migration 0015 adds the fourth role forge_member and eleven forge_member views, one per relation 0009 serves, so the shared prefix-parameterised TreeReader reads either family unchanged - and the gate is strictly stronger than 0009's, because the app names only the account the Clerk session resolved to while the membership join sits INSIDE the barrier view, so the application cannot name a repo it is not a member of even by mistake. metadata_public is absent as both column and predicate, and repo_member is named exactly once, by the gate. Two premises did not survive, and the first is a defect in the decision itself: ADR 0077's and the ticket's literal current_setting of loot.reader_tenant cast to bigint DOES NOT fail closed. It fails closed for an UNSET parameter and not for a CLEARED one, because set_config with NULL leaves the empty string behind and casting that to bigint RAISES - which 0009 never met because decoding an empty string as hex does not. Proved by removing the fold from the shipped migration and reading invalid input syntax for type bigint, so the gate ships as nullif and then the cast, malformed values still raise deliberately, and withMember validates a positive decimal with the pin on both sides. The second is a defect in #1727, which landed earlier tonight: its exact-set spelling, that the views naming repo_member equal the forge_member family, is satisfiable ONLY by a family of one, because the ten chained views name the GATE view and never the base table - so a second member view gaining the roster, which is precisely the disclosure ADR 0077 forbids, read as CORRECTNESS under the old spelling. It is re-spelled to exactly forge_member_repo whenever the family exists, its vacuity guard extended to require the member family non-empty, and its positive control now plants four breaks where it planted two. The row-level-security interaction is proved rather than assumed, as three readings on one database in one moment: the seven enabled tables this family reads really carry relrowsecurity, read as a set; the role handed a direct SELECT on repo reads ZERO rows, which is 0014's own named accident and shows the policy system live for that role; and the same role on the same connection at the same moment reads its repo through the gate view and gets one. The mechanism is then named from the catalogue and red-proved by setting security_invoker, which takes the read to insufficient_privilege, and the failure text names the non-superuser deployment case so a future deploy diagnoses itself. The isolation break is ADR 0077's own named careless shape rather than an invented one - the gate keeps its repo_member join and loses only the correlation to repo, which passes every text guard in migrate.rs - and seven of eight tests fire on it. Rows are planted from tests and from the site, outside account_tier.rs's scan of src, the way rls.rs already recorded, so the tripwire is untouched and green. forge_member ships NOLOGIN and provisioning is a different repo, so the class answers 404 rather than 500 and is not an existence oracle (#1726) e76ca863 · dbf3dbe6…
• the forge live-database suites now run in CI: test-main.yml stands up a postgres:18 service, provisions it the way setup-forge.js does including its default privileges, migrates it with the commit own loot-forge --migrate, sets every LOOT_FORGE_TEST database url the Rust and site suites read, and runs cargo test and then the site pg tests against it. LOOT_FORGE_TEST_REQUIRE_DATABASE turns a database test skip into a failure through pg::live_opt_in and the site skippingLive helper, and with it set and no url 91 Rust tests and all six site pg files fail, while two half-suites that used to skip silently now say so. The default-privilege tripwires run in CI by decision, and fail on a cluster without provisioning. A new migration that neutralises the roster policy passed the bare suite and failed rls.rs and membership.pg.test.ts against the cluster. It is a canary on landed main and not a pre-land gate, and the prose that said no workflow sets these urls now says that instead (#1735) c0931f78 · dbf3dbe6…diff
• the forge test harnesses no longer race each other migrating a scratch database: a migration that adds one of the narrow roles creates it inside a check-then-act DO block and then states the attributes with ALTER ROLE, which writes a pg_authid row no database owns, so two harness threads each migrating their own scratch database write that row at once and postgres answers one of them tuple concurrently updated, the flake #1744 saw once in CI as migration 0003 failing on a fresh database. it reproduces three ways against a throwaway cluster: six concurrent loot-forge --migrate processes over six fresh databases failed 4 of 18 with that error, each leaving a ledger stopped at version 2 with the server log naming migration 0003; the statement alone, looped from sessions in separate databases, failed 2 of 4 where 18 single statements collided 0 times; and the two migrating pg::tests cases run as a pair went red in 5 of 8 runs. the new pg::migration_serial takes a session-level pg_advisory_lock on the admin url database and gives it back when the returned value drops, so the disconnect is the unlock and a test that panicked holding it releases it too. it is a lock on the cluster rather than the MIGRATING mutex the harnesses under tests/ each carried, because the row belongs to the cluster and the lib tests and each tests/*.rs are their own binary; every harness application of a migration now holds it, namely PrefixDb::new, the new apply_migration that apply and the new reapply share, the member read gate restore, and the rls case that makes a role bypass row security, where a second binary migrating during that window would have had migration 0014 refuse it. with the lock the pair is 0 of 8 red and four concurrent processes of it are 0 of 12; a process mutex in its place is 6 of 12 red, no lock in PrefixDb::new is 2 of 6 red with the census naming that function (1 passed, 1 failed), the lock dropped from the member_class harness is named too (0 passed, 1 failed), and the pg_advisory_xact_lock spelling reddens the new lock case (0 passed, 1 failed) and 4 of 6 runs. every_scratch_database_migration_holds_the_cluster_lock walks src/ and tests/ for the statements that apply a migration, holds the set of functions equal to what it expects and names migrate as the one deploy path exempt, since it already serialises runs on one database with LOCK TABLE schema_migration; it went red with ROOTS emptied and with that exemption emptied (0 passed, 1 failed each) and it needs no cluster, unlike the cases it reads. the_migration_lock_is_one_lock_for_the_whole_cluster pins that an advisory lock is per database, which is why the lock is taken on the url unmodified. PrefixDb migration panics print the server sentence through pg::describe now, where the original report read db error. docs/evidence/forge-datastores.md carries the run and answers the suspicion its #1744 section left open, the forge suite is green against the cluster (469 passed over nine binaries, no skip note) and the workspace suite is green (3832 passed) (#1956) 8aebb4de · dbf3dbe6…diff
• the live-database checks test-main.yml runs can run locally, from the same script CI runs, because the account is out of Actions minutes and a land never ran them: the provisioning, the database keys and the suites move out of the workflow into ci/test-main.sh, which builds every connection URL from a host and a port it requires rather than defaulting to the one a real cluster listens on, and the workflow keeps only what prepares a fresh runner and calls it. ci/local.sh starts a throwaway Postgres on its own port, refuses if anything already answers there, runs that script against it and deletes the cluster on exit, so it runs beside a real cluster and from a lane before a land. run in a lane against a portable Postgres 18.6 it applied forge migrations 0001 to 0017 and the three site migrations, and 122 cargo test results and all seven site live files passed with LOOT_FORGE_TEST_REQUIRE_DATABASE set, so none skipped, before and after the review fixes. with the returning alias put back into read.ts it failed at the site step on syntax error at or near returning, and pointed at the port a real cluster owns it refused with exit 2. the CI-shape pin reads through the script and its STEPS list, because the job is still named cargo test --workspace and a check on the workflow text alone would pass on the name after the command had gone; it went red when the workflow stopped calling the script and when the script dropped --locked. the comments and living docs that said the workflow sets the keys now say the script does, the dated ADR and evidence entries are left as history, and AGENTS.md, docs/agents/workflow.md and the afk-loop security hunt point at the script. the Actions wiring itself is unexercised until minutes return (#2061) 8ff6117c · dbf3dbe6…diff
• the web can now list a repo's proposals, and a pin holds it to the same rule the CLI answers with: migration 0020 adds forge_read_proposal, forge_owner_proposal and forge_member_proposal, each one join onto its family's existing gate view, so none re-derives a gate and each inherits how that gate fails closed, and each family's role is granted its own view and nothing else. propose::visible_to in Rust and these views in SQL are two implementations of one disclosure rule, so tests/proposal_read.rs plants one fixture in a scratch Postgres, pairs each Rust reader with the web reader the site would use for the same person - anonymous, an owner through the account holding a rotated namespace key, an accountless namespace key, a member through its roster row - and demands the whole row set match, terminal rows included, with a vacuity guard that every class but the anonymous reader of a private repo sees rows on both sides, and an executable red that rebuilds the anonymous view without its gate and requires the pin to name that class and repo. THE KEY ARM IS PINNED RATHER THAN SKIPPED: visible_to admits a proposer and a tip author by key and no family names a key, so the web is narrower than the CLI by exactly the rows a key presented or authored and never wider, and the test fails if the difference is ever anything else. the family set is derived in migrate.rs from the earlier grants rather than listed, so a new barrier family meets the text guard and must carry its own proposal view or change it with a reason. a cleared gate answers no rows rather than raising, through the views that inherit it. the plan at 10000 proposals over 100 repos reaches proposal through proposal_pkey on repo_id for the owner and anonymous views, which were measured, with no sequential scan of proposal and no per-row author lookup, since the views carry no author; the member view joins proposal the same way through its gate and its plan was not taken. member_read's row-security set gains proposal, which a member view now reads, and drops the counts beside it; 0011, 0015, ADR 0075 and visible_to's doc now point at the second implementation. red under mutation, counts read each time, against a PG18 throwaway cluster: the owner view dropping terminal rows (0 passed and 1 failed), the member view reaching the owner gate (0 passed and 1 failed), the anonymous view ungated (0 passed and 1 failed, naming the four rows the ungated view served), the member view casting without nullif (0 passed and 1 failed on 22P02), the member grant dropped (0 passed and 1 failed), and the anonymous view reading repo in the text guard (0 passed and 1 failed), each restored to 1 passed. numbered 0020 because #2250 landed 0019 while this was built; the merge that follows resolves migrate.rs against it and carries the suite. the forge owes a deploy for the migration before the site can read these views (#2175) 232d49ae · dbf3dbe6…diff
• the web can read a proposal thread with exactly the audience of its proposal: migration 0023 adds forge_read_proposal_comment, forge_owner_proposal_comment and forge_member_proposal_comment, each granted to the role of its own family and each one inner join onto that family proposal view from 0020 on both halves of the proposal key, since one change can be proposed to more than one repo; they serve every comment column but the envelope, which no rendering surface verifies, so a withdrawn comment is its tombstone with no body. tests/proposal_read.rs now compares threads as well: for every reader class the thread the route serves against each view, tombstones, an edit, a path anchor and a reply included, with a vacuity guard, the key arm pinned as the only difference, a cleared gate answering no rows, every view read whole as its own role after a withdrawal through the store, a change proposed to a public and a private repo read with no repo filter, and an executable red that rebuilds the anonymous comment view onto the proposal base table; migrate.rs text guards pin one comment view per family, its grant, its reach, the whole-key join and no envelope. red with each piece undone, counts read each time, each restored green: the anonymous and owner views joined on change_id alone (1 passed and 6 failed), the owner view alone so (6 and 1, caught only by the unfiltered read), the member view reaching the anonymous proposal view (1 and 6, and 2 and 1 on the text guards), a withdrawal that keeps the body with its CHECK dropped (6 and 1), and the envelope served, a cross-family grant and a view without security_barrier (2 and 1 each on the text guards). the timeline and the Markdown renderer are not built: an attestation row carries no time and no reader role has a view of it, the decline reason is #2336, and no site surface renders a thread yet (#2165). ADR 0095 amended and CONTEXT.md updated; setup-forge checks reader views by prefix since scripts@1b2b9ed, so the member view needs no edit there. bash ci/local.sh is green against Postgres 18 (4482 passed over 139 binaries, 13 ignored). no format constant or codec byte moves; migration 0023 rides the forge binary, so this owes a forge deploy (#2332) 38e8b55a · dbf3dbe6…diff
• key management on the site: a key can be retired by itself, named, and chosen at unlock. per the operator grill on #2398 (ADR 0100): POST /api/identity/retire retires one key of the signed-in account, refusing the last live key under the account-row lock registration takes and never re-dating a retirement, with no route to un-retire and no deletion, since #506 keeps every key resolvable; /account lists live keys and folds retired ones under a collapsed section, and the retire confirmation names the repos the key owns. names live in a new owner-only account_key_label table (migration 0027) that only forge_identity reaches, trimmed, at most 40 characters, with control, line-separator and direction characters refused and a CHECK repeating the cap; they reach only /account, the unlock picker and the private bar, always beside the fingerprint. the unlock picker lists every live key, defaulting to the key that owns the URL namespace, then the key this device last unlocked, then the only live key, and a key with no stored passphrase asks for its 24 words and can save one. both routes are Bearer only and refuse a key of another account; /api/identity/me stops returning the internal tenant id. rebased by hand over migration 0026 and ADR 0099. pg tests pin the role reach, route and picker tests pin the rules, each red under a named mutation; bash ci/local.sh green against Postgres 18 (4568 passed), site gate 842 passed. owes the setup-forge tripwire update, a forge deploy, then a site deploy (#2398) a90c85fb · 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.