fix(wip): page complete workdir catalogs and fence full connection sets

This commit is contained in:
2026-10-05 19:01:13 +09:00
parent 01156f4c78
commit 6feed0f22f
13 changed files with 1187 additions and 57 deletions
+15 -4
View File
@@ -111,10 +111,21 @@ Historic session text remains append-only and is not rewritten or replayed.
Catalogs are request-time projections of existing Backend authority, not another
store or synchronization job. WIP list pages default to 50 and accept 1–100
items. Repository/Workdir pages sort by stable identity and use the last identity
as `next_cursor`; they project the existing Backend inventory response rather
than maintaining a catalog copy. Attachment pages use the Backend's SQL-bounded,
alias-ordered limit/offset query and opaque `offset:<n>` cursors. A cursor is not
items. Repository pages sort the existing complete Repository catalog by stable
key. Workdir pages use the signed caller-bound Backend
`workers/self/workdir-catalog` operation, with SQL keyset paging over the existing
Workdir registry in stable ID order. This is not the legacy bounded
`working-directories` browser/Tool snapshot: Workdirs older than its 200-record
cap remain reachable. `next_cursor` advances over scanned rows even when the
current read policy or unsupported legacy source makes a page sparse or empty;
`empty` describes that page, and `has_more` remains authoritative for progress.
Attachment pages use the Backend's SQL-bounded, alias-ordered limit/offset query
and opaque `offset:<n>` cursors. Both Workdir and attachment responses supply an
opaque complete-set `revision` derived from existing authoritative records in
the same database snapshot as the page, not by hashing the first page. The Host
uses this complete-set revision for the collection Object validator. A lifetime
or capability change beyond row 50 therefore invalidates old collection
observations without adding a ledger or revision store. A cursor is not
a snapshot or authority grant: restart listing after concurrent collection
changes. Filtering by exact `connection_id` is applied in the caller-scoped
Backend ledger before paging, so direct item lookup also works beyond the first