sealkeep 0.9.0 → 0.11.0

package/ARCHITECTURE.md

@@ -25,13 +25,19 @@ The client is trusted to handle plaintext. The control plane and object store ar
   segments hashed under a storage-scoped key, readable identity in a sealed sidecar.
 - `index-sync`: the sealed content index, pulled and pushed as ciphertext so every
   machine of the vault searches the whole history.
-- `retention`: active-session detection, policy evaluation, grace/trash staging.
-- `restore`: integrity checks, atomic output, native adapter mapping; `rehydrate`
-  restores an archived transcript before an agent's resume reads it.
+- `retention`: active-session detection, policy evaluation, verified/searchable gates,
+  and journaled source staging with a durable permanent-purge boundary.
+- `restore`: integrity checks, atomic output, native adapter mapping; reclaimed
+  Codex history keeps a lightweight native pointer and full restore is explicit.
+  `openFromCloud` is the no-local-record path — a machine reading an archive it
+  never sealed — and so must discover the remote layout itself: a chunk folder
+  is reassembled from the sealed sidecar's own chunk headers, hash-checked per
+  chunk, because the record that would otherwise describe it lives on somebody
+  else's laptop.
 - `local-api`: loopback API shared by CLI/TUI/desktop/MCP.
 
 Implemented as: `src/adapters.ts`, `src/watcher.ts`, `src/queue.ts`, `src/worker.ts`,
-`packages/vaultline-crypto/`, `src/providers/`, `src/secrets.ts`, `src/upload.ts`,
+`packages/sealkeep-crypto/`, `src/providers/`, `src/secrets.ts`, `src/upload.ts`,
 `src/chunk-store.ts`, `src/index-sync.ts`, `src/stream-to-cloud.ts`,
 `src/retention.ts` with `src/activity.ts` and `src/trash.ts`, `src/restore.ts` with
 `src/rehydrate.ts`, `src/share.ts`, `src/rotate.ts`,
@@ -63,11 +69,41 @@ archive on retry.
 
 ## 2.2 Hook boundary
 
-Hook commands hold no secret. They parse the lifecycle payload for a transcript
-path (`transcript_path`, `rollout_path`, and camelCase spellings), verify it is
-readable, enqueue, and exit. Unknown vendor fields are ignored rather than parsed,
-so a schema change cannot break preservation. Encryption happens later in
-`sealkeep queue run`, which is the only process that sees the recovery phrase.
+Hook command lines hold no secret. Preservation hooks parse the lifecycle payload
+for a transcript path (`transcript_path`, `rollout_path`, and camelCase spellings),
+verify it is readable, enqueue, and exit. Unknown vendor fields are ignored rather
+than parsed, so a schema change cannot break preservation. Archive encryption
+happens later in `sealkeep queue run`.
+
+Automatic context has a deliberately split latency contract:
+
+- `hook context` is the synchronous agent-facing lane. It uses the machine's
+  normal keystore, atomically claims one prepared context file, authenticates and
+  decrypts it locally, and exits. It performs no discovery, hosted request,
+  archive refresh, search, publication, or membership reconciliation. Prepared
+  context is consumed once and the hook fails open after two seconds.
+- `hook context-sync` is the asynchronous producer. It publishes team progress
+  before expensive recall work, reconciles the local realtime inbox, refreshes
+  and searches the encrypted index, then seals the bounded result locally for a
+  later safe boundary. Provider latency therefore changes freshness, never the
+  latency of the current prompt or tool result.
+
+Autopilot has a similarly explicit deletion boundary. A fresh installation
+preserves, indexes, and uploads, while `local-settings.json` records
+`reclaimEnabled: false`; neither the generated service unit nor the running
+daemon receives standing reclaim permission. `sealkeep autopilot --reclaim`
+or the confirmed local Settings switch records that permission. Retention
+rules remain a separate eligibility layer: enabling the machine switch repairs
+a non-reclaiming policy to `archive-and-reclaim`, while selecting a
+keep-originals policy revokes the machine switch. Re-running Autopilot during
+an upgrade preserves an existing saved choice and its timing/manual-approval
+policy instead of applying fresh-install defaults.
+
+Session resume remains non-blocking: a reclaimed Codex transcript keeps its same
+session id as a tiny valid native pointer. The resumed agent uses MCP search for
+relevant preserved memory. Downloading every historical byte is deliberately an
+explicit `sealkeep recover <archive-id> --native --overwrite backup` action, so a
+resume neither downloads gigabytes nor races an agent's open transcript handle.
 
 ## 3. Archive envelope (implemented, format v2)
 
@@ -90,7 +126,7 @@ time before any chunk is touched. An archive is durable only after the provider
 the byte count and checksum the client computed; `remote.verifiedAt` records that, and
 retention reads it.
 
-Full specification, test vectors, and tamper coverage: `packages/vaultline-crypto/`.
+Full specification, test vectors, and tamper coverage: `packages/sealkeep-crypto/`.
 
 ## 4. Control-plane API v1
 
@@ -98,7 +134,7 @@ Authentication is on by default. `SEALKEEP_CONTROL_PLANE_DEV=1` disables device
 and keeps state in memory for local interface work; `/health` reports
 `mode: development-interface` so a misconfigured deployment is visible in one request.
 
-All non-enrollment endpoints require an Ed25519 device signature over
+All non-enrollment endpoints require an Ed25519 device signature over the frozen legacy protocol string
 `vaultline-request:v1\n<METHOD>\n<path>\n<timestamp>\n<nonce>\n<sha256(body)>`, presented in
 `x-vaultline-device`, `-timestamp`, `-nonce`, and `-signature`. Timestamps outside a
 five-minute window are refused, and a nonce cache rejects verbatim replays.
@@ -132,6 +168,119 @@ deletes an archive; the response reports how many archives were retained. Revoca
 retroactive for ciphertext an attacker already holds — the client-side counterpart is
 `sealkeep recipients remove` followed by `sealkeep rewrap`.
 
+### What the plan buys
+
+Sealkeep works without an account. The vault, the sealing, the restore, the
+search and your own bucket are all local and always free — that is the product,
+and none of it phones anywhere. What a plan buys is the small hosted layer that
+removes setup nobody wants to do themselves, and it is enforced here rather
+than in the client, because a check the client makes is a check the customer
+can delete.
+
+| Capability | Needs | Why it costs |
+| --- | --- | --- |
+| Local vault, archive, restore, search | free | never touches this plane |
+| Your own bucket (S3, R2, B2, GCS) | free | your provider, your bill |
+| Key escrow — a sealed copy of the vault key | any paid tier | we hold and mind a row for you |
+| Machine registry, per-machine delete rights, revocation | any paid tier | identity is coordination, which is what this plane is for |
+| Connect Google Drive | any paid tier | our OAuth app and our server-held client secret |
+| Managed storage (upload, index slot) | `pro` / `team` | our GCS, our bytes, metered against quota |
+
+The tiers are `free | pro_lite | pro | team` on `account.plan`. Every gate
+answers **402**, never 400 or 403, so a client can tell "you have not paid for
+this" apart from "you are not allowed to do this" — they need different words
+in front of a person, and the CLI codes the first as `payment_required`.
+
+Seats are the other axis, enforced at device registration and counted over
+**active** machines only, so revoking one frees its seat at once: `pro_lite` 3,
+`pro` 10, `team` 100, and `free` cannot register a machine at all. The panel's
+`PACKAGES` list carries the same numbers; they have to be changed together or
+the page starts promising something the plane refuses.
+
+`team` is what the B2B features already in the client hang from — recipient
+keys (`sealkeep recipients` + `rewrap`), project-scoped membership
+(`--project`, `space members`), owner-key delete authority, and corporate
+bucket routing. None of that was new work; what was missing was a tier to sell
+it as and a limit that meant anything.
+
+A warning from writing these guards: **error strings are expression-evaluated**,
+so a bare word that matches an assigned variable name is rewritten. "Every
+machine seat on this plan is in use" shipped to a customer as "Every
+vars.machine seat…" because a later step assigns `machine`. Re-read every
+refusal against a live account before believing it.
+
+**A lapsed subscription stops writes at once and reads after 30 days.** The
+grace window runs from `subscription.current_period_end` (falling back to
+`updated_at`), and the download lease reports `reading_on_grace` and
+`grace_until` so a client can warn before the door shuts. The asymmetry is
+deliberate: the bytes are the customer's, and a billing failure should never be
+the reason they cannot get their own history out. Archives on their own bucket
+or their own Drive are untouched by any of this — they were never ours to hold.
+
+Escrow READS are never gated. Refusing someone the sealed copy of their own
+vault key because a card expired could lock them out of everything they own.
+
+### `/v1/cloud/security/*` — watching without reading
+
+The plane holds ciphertext. It could not scan a transcript for a leaked key if
+it wanted to, and it should not want to. So the scan runs on the developer's
+own machine, where the plaintext briefly exists, and only the verdict travels:
+the rule that matched, how many times, which machine, which archive.
+
+Never the matched text. Never the surrounding line. Not even `maskSecret`'s
+preview — that is masked well enough for a terminal, not well enough for a
+database that keeps it forever. And never the project name, which by design
+never reaches this plane at all. `test/security-findings.test.ts` pins the wire
+shape as an allow-list, so a new field is a deliberate decision rather than an
+accident.
+
+`POST /security/findings` records one row per rule, not per match: a session
+that pasted the same key forty times is one problem, and forty rows would bury
+the other findings under it. `GET /security/findings` is the company's feed.
+`GET /security/policy` hands every machine the company's own patterns, plus
+`block_on_high`, which is what turns detection into prevention — a machine that
+pulls it refuses to seal a session carrying a high-severity match rather than
+reporting it afterwards.
+
+Reporting is best-effort by construction. An account below `team` answers 402
+and the client stops asking; a network failure loses a report. The one thing it
+must never do is cost anyone a seal.
+
+### Seats, and why they are not storage
+
+`account.seats` is the purchased machine allowance and beats the tier default.
+It exists because storage is the wrong axis for a company: a team that keeps
+everything in its own bucket consumes none of ours and would otherwise pay for
+a storage tier it never touches. Seats and `quota_bytes` are priced apart, so
+bring-your-own-bucket costs seats alone.
+
+### Self-hosting
+
+`SEALKEEP_CLOUD_URL` points a machine at any compatible plane, and every path
+that reaches this one honours it — `cloud.ts`, `enroll.ts`, `local-api.ts`,
+`storage-targets.ts`. The only hard-coded address is `DEFAULT_CLOUD_URL`. The
+test suite runs a full seal → chunk upload → download → restore against a stub
+plane on `127.0.0.1` via that variable, so this is a tested path rather than an
+aspiration. What a self-hosting customer needs from us is the plane itself and
+this contract, not a client change.
+
+### `DELETE /v1/cloud/archives/:vault_key`
+
+Destroying is authorised separately from reading, because the bearer token
+names the account and not the machine: every laptop paired to a company account
+presents an identical one. The body carries either a **machine key** (issued
+once at device registration, only its bcrypt is stored) or an **owner key**
+(minted by a completed web sign-in, which a CLI token cannot perform). An
+archive records `sealed_by_machine` at upload completion; a machine may delete
+what it sealed, an owner key may delete anything, and everything else is
+refused. Allowed and refused attempts both write an audit row. Archives
+predating this carry no stamp and remain account-wide deletable — attribution
+starts at the next upload.
+
+Credentials travel in the request body rather than a header because this
+control plane does not surface request headers to endpoint logic; that was
+measured, not assumed.
+
 ### `GET /v1/audit`
 
 Account-scoped audit events: action, outcome, identifiers, and counts. No content.
@@ -167,7 +316,7 @@ command. Bodies are capped at 1 MB, validated with strict schemas, and rejected
 
 ## 5. Local MCP contract
 
-MCP tools call local APIs, not provider SDKs directly. `vaultline_create_upload` returns a lease object; it must never receive a cloud secret. Search defaults to metadata. Recover and archive require explicit local authorization/recovery secret.
+MCP tools call local APIs, not provider SDKs directly. `sealkeep_create_upload` returns a lease object; it must never receive a cloud secret. Search defaults to metadata. Recover and archive require explicit local authorization/recovery secret.
 
 ## 6. Failure behavior
 
@@ -184,8 +333,8 @@ Implemented and tested end to end: capture (hooks, watcher, durable queue), encr
 (format v2 with vectors and a tamper suite), provider clients (SigV4 verified against AWS's
 published example; multipart, GCS resumable, and the plain object verbs exercised against
 in-process emulators), verified upload, the chunk-folder remote layout with hashed naming
-and sealed identity, retention with trash staging, restore including native adapter paths
-and rehydrate-on-resume, the sealed index sync, the loopback API behind the dashboard and
+and sealed identity, retention with crash-safe staging and permanent source reclaim, restore including native adapter paths
+and the lightweight resume pointer, the sealed index sync, the loopback API behind the dashboard and
 TUI, the MCP server and its installer, the control plane with device auth and audit,
 search, and the local audit log.
 

package/CHANGELOG.md

@@ -3,6 +3,227 @@
 Notable changes, by published version. Sealkeep is pre-1.0: minor versions
 may change behavior, and say so here when they do.
 
+## 0.11.0 — 2026-09-16 — automatic memory that works, and an append-only index
+
+**Automatic recall now works on a real, long-lived vault.** The hook lane
+(`sealkeep hook context-sync` → daemon → `sealkeep hook context`) silently did
+nothing on a vault with months of history; every cause below was found by
+running it, not reading it.
+
+- Test daemons no longer re-target the machine's real agent hooks at a
+  temporary vault; the installer repairs hooks aimed at a vanished vault, and
+  `sealkeep doctor` fails, naming the path, when hooks route to a different
+  live vault.
+- The recall child is no longer CPU-paused behind the hours-long index
+  catch-up; each recall bounds its hosted index refresh, its start-of-session
+  team steps and its presence publish/catch-up to seconds, answering from the
+  local index when the plane is slow. The presence upload was a silent three-
+  to-six-second tail that tripped the stall deadline after the scan had
+  finished, so the pass was killed at the finish line and retried.
+- Nothing is injected when nothing was recalled. Personal vaults recall across
+  untagged sessions (hand-archived, or sealed before project tags existed)
+  without ever crossing into a different stable project key; `sealkeep archive
+  <file>` tags the agent and project itself.
+- Recall picks up to three specific terms from the prompt (never the project
+  name), prefers a session's later excerpts, and stops after the second
+  productive scan. "Recent preserved sessions" lists each session once, by its
+  newest snapshot: a live session is sealed every few minutes, and its
+  snapshots used to fill all five lines and hide every other session.
+- A session's end drops its queued recall work — including what a pass still
+  running for it writes afterwards; within a priority tier the newest request
+  is served first, so a finished session never delays the one being typed in.
+  Day-old prepared context, state and locks are swept, and the daemon's first
+  heartbeat removes replace-temporaries left by unclean stops.
+- The recall child's no-progress deadline is 20 s (was 8 s): a healthy pass on
+  a large vault reports progress 4–6 s apart under ordinary load, and every
+  budgeted hosted wait now keeps reporting progress while it lasts. The
+  two-minute absolute ceiling is unchanged.
+- The service heartbeat records the recall lane (`context`: state, consecutive
+  failures, last error as a stable word), and `sealkeep doctor` reports
+  `automatic-recall` — a warning after three failed passes in a row, otherwise
+  when memory was last prepared. Hooks fail open, so this is the only place a
+  dying lane is distinguishable from one with nothing to recall.
+- A memory hook that cannot unlock the vault still answers the agent's empty
+  object, but now leaves a marker the next successful hook clears, and doctor
+  fails `automatic-recall` naming the agent, the time and the secret backend
+  the hook ran with. On a real host the hooks were pinned to a secret backend
+  that no longer held the phrase: sealing and uploading kept working while
+  indexing, recall and hook capture were silently off.
+- `sealkeep_recover` is dry-run by default, as its context pack already said;
+  `sealkeep recover --dry-run` matches.
+- A seal now keeps the tokens it extracted from the plaintext as a sealed
+  sidecar beside the record (`<archive-id>.sktokens`, kilobytes) before it
+  merges them into the index, and the index catch-up indexes such an archive
+  from that file alone — nothing is decrypted or downloaded again. On a real
+  vault the merge had failed silently for 2,300 seals in one week, discarding
+  their tokens and re-queuing 1.85 TB of history for a full decrypt that never
+  completed. A merge or sidecar that fails is now named (`SealkeepIndexDeferred`
+  warning; `index.merge` / `index.tokens` audit entries).
+- **A term lookup no longer reads the whole index.** The index is sealed in
+  independent chunks (`zstd-chunk`) and each checkpoint writes a sealed term
+  directory beside it (`content-index.directory.skindex`: the byte offset of
+  every 64th token row and the archive/metadata regions). A query
+  binary-searches the directory, opens only the chunks holding its window and
+  parses a few hundred rows — the old read decrypted and inflated 100 MB and
+  parsed 1.5 million rows for every term, 8–12 s each on a real vault. An
+  index without a usable directory (older, or pulled from another machine)
+  still takes the full read.
+- **The index is append-only.** `sealkeep index migrate` moves a vault's
+  index onto sealed, immutable segments (`index/segments/`: one sealed body,
+  its envelope and a sealed term directory per segment, listed in a plaintext
+  manifest that holds only ids and counts). A sealed memory never changes, so
+  its index rows are written once: a seal appends a one-archive segment
+  instead of re-reading, rewriting and re-uploading the whole index; the
+  catch-up writes each checkpoint's batch as a segment and never holds more
+  than one batch, so the background child no longer dies on a large vault
+  (2 million terms exceeded its 1 GB heap on every attempt); a removed archive
+  becomes a tombstone that every lookup and the next compaction honour.
+  Compaction streams small segments into one bigger immutable segment — the
+  small-segment rule at seal time, the full policy in the build lane. A
+  lookup opens every segment's directory and reads only the blocks holding
+  its terms, then merges: 0.3–0.8 s per term on a 2-million-term vault, in a
+  process that stays under 350 MB. `index drop` keeps a migrated vault on
+  segments; a changed extraction policy resets the segments and re-indexes
+  instead of looping the daemon on "coverage incomplete"; `index status`
+  answers from the manifest. The single blob is still produced for the cloud
+  by a foreground build (the background child publishes only when the merged
+  index fits 400,000 tokens), and another machine's newer cloud index is not
+  yet folded into segments — both follow when segments themselves are
+  published; until then a segmented vault skips the pull of that blob, which
+  cost every recall pass the 2 s it was budgeted and a plain search 30 s on a
+  slow plane. Opening a segment unwraps its key once per process (two scrypt
+  derivations, ~70 ms each, were paid again for every decrypted window): a
+  term lookup is 5–40 ms, a full merge across segments under 200 ms, and
+  prompt → prepared memory on the 4,000-archive vault is 3.0–3.5 s.
+- **A local seal indexes itself.** Only the cloud seal path collected a
+  session's tokens as it sealed; a session sealed locally (no cloud, a cloud
+  that is unreachable, `sealkeep archive`) waited for the background catch-up,
+  which on a real vault sits behind hours of multi-gigabyte snapshots — the
+  session a person had just finished was the last thing that became
+  searchable. The daemon, the CLI and the MCP server now index a full seal as
+  part of the seal (chunk-compressed, up to the whale threshold; a delta is
+  still indexed as one chain by the catch-up), on segments always and on a
+  blob index while it is small and no catch-up is building it (the blob has
+  one writer at a time) — a large blob is merged whole in-process, and that
+  is the crash the segments exist to avoid, so a large vault gets seal-time
+  indexing by migrating. As on the cloud path, a failed entry is
+  named (`SealkeepIndexDeferred`, audit `index.merge`), never a failed seal.
+- **Segments travel between machines.** On a store that can hold objects
+  (bring-your-own storage) a machine uploads each of its immutable segments
+  once — three objects per segment, a per-machine head, a heads map for
+  discovery — and a peer downloads only the segments it has not seen,
+  registering them as remote: never compacted with its own, replaced when
+  the source publishes a newer set, the source's tombstones honoured. The
+  managed plane holds only the index's meta and blob objects, so a
+  segmented vault there keeps publishing the blob merged from its segments
+  (a foreground build always, the background child while the merge fits
+  400,000 tokens) and converts a peer's newer blob into one remote segment,
+  skipping its own publication and any blob over 64 MiB. The daemon runs a
+  publish pass whenever the manifest has moved since the last publication,
+  so a seal reaches the other machines without waiting for a catch-up.
+- **A transcript is indexed once.** A full re-seal of a file that replaces an
+  earlier snapshot (`supersedes`) is now the only snapshot of that file the
+  index holds: older snapshots are skipped by the catch-up, purged from a
+  blob index and tombstoned on segments, and `index status` no longer counts
+  them as missing. On a real vault the catch-up backlog was 416 snapshots of
+  a handful of multi-gigabyte Codex rollouts — one June rollout of 2.7 GB had
+  been sealed 88 times, and every copy was queued for a full decrypt. A
+  delta seal (the bytes appended since the last seal) now indexes those bytes
+  inline, under its own id and chunks, instead of waiting for the catch-up to
+  decrypt the whole chain again, each part answering for its own bytes.
+- Migrating a vault whose index carried another machine's sessions (pulled
+  from the account index) no longer loses them: the first build after the
+  migration tombstoned every one of them as "indexed here but no longer here"
+  — on the rehearsal's dev vault, all eleven of a teammate's sessions. A
+  migrated segment now records which rows are this machine's and which came
+  from elsewhere; only the former can ever be pruned, and `index status`
+  counts both.
+- Interrupted builds no longer leave the plaintext index behind. A killed
+  catch-up (the background child running out of memory, a reboot) left its
+  streaming checkpoint's staging file — every token of every session, in the
+  clear — under `index/` forever, because the sweep only knew sealed temps; a
+  real vault held 1.9 GB of them. Staging files older than an hour are swept
+  at the start of every build, under `index/` and `index/segments/` alike.
+- Automatic recall runs its terms concurrently, quotes two sessions per term
+  (`snippetLimit`) and takes sessions whose sealed bytes are on this disk
+  first (`quoteLocalFirst`) — a reclaimed session's quote is a ranged fetch
+  from the cloud, seconds on a slow plane. The top-ranked cloud-only session
+  still keeps its quote (one per term): a teammate's session is never on this
+  disk, and the rehearsal showed the person's own sessions filling every slot
+  while the colleague's decision ranked first and went unquoted.
+- A preserved Claude Code session's one line ("Recent preserved sessions", a
+  teammate's finished note) is its last assistant message. The scrape used to
+  take the last string in the file, which in a Claude transcript is the
+  harness's own reminder — so a session read as `<system-reminder>
+  <total_tokens>…`. Harness scaffolding is skipped in the fallback too, an
+  index pass re-derives a scaffold line while the source is still on disk,
+  and a quote never comes from the harness or from memory Sealkeep itself
+  injected on an earlier turn (a transcript carries both, and both matched —
+  a matching line with nothing else to show is dropped rather than quoted
+  raw). When two copies of the index are merged, a real one-liner wins over
+  a scaffold one from either side. A budgeted hosted index refresh is
+  attempted once a minute per process instead of once per lookup, and search
+  ranking no longer scans the record list inside its comparator. Prompt →
+  prepared memory on a 4,000-archive vault: 15 s → 2.5–4 s.
+- The index build interns posting tags (one string per archive chunk instead
+  of one per posting — 19 million on a real vault) and no longer indexes
+  numbers of four or more digits or digit-bearing tokens of sixteen or more
+  characters (a quarter of a real vault's vocabulary: line numbers, byte
+  counts, timestamps, base64 slivers). Ids such as `p04946`, `s3`, `sha256`,
+  `429` stay searchable.
+- The index catch-up schedules archives over 256 MB after every ordinary
+  session (newest-first within each group). Eight ~2.6 GB snapshots at the
+  head of a real vault's queue had held the lane for a week: nothing could
+  checkpoint before the first finished, and under the shared CPU budget and
+  daily restarts it never did. A checkpoint that fails to save is now named
+  (`SealkeepIndexCheckpoint` warning) instead of silently making "safe to
+  stop; it resumes here" untrue.
+
+- Contributor removal preserves authenticated shared history in durable owner
+  custody before changing membership, then republishes it for the surviving
+  roster. Interrupted handoffs resume without needing the contributor's machine.
+- Invitation acceptance checks a preserved history snapshot atomically. Writes
+  made while an invitation is pending require a refreshed snapshot; accepted
+  members receive preserved history through the owner's background handoff.
+- Team snippets use the authenticated project index, validate archive facts and
+  membership, and enforce bounded streaming reads and decompression. Personal
+  index records cannot override the authorization facts used for a shared read.
+- Concurrent backfill staging uses unique temporary files. Archive transfer
+  completion is reported only after its final journal state is durable.
+- A secret-free indexing watchdog now resumes and terminates its exact worker
+  if the owning service dies while that worker is CPU-paused. Work starts only
+  after the watchdog confirms ownership; watchdog failure stops the worker.
+- Concurrent scratch-space claims retry if the competing owner released its
+  lease during collision handling. Team realtime shutdown now drains pending
+  refreshes and writes instead of reconnecting or writing after close returns.
+- Enterprise deployment acceptance remains pending. The verification record in
+  `docs/enterprise-verification-2026-09-05.md` distinguishes hosted tests from
+  unverified isolated-runtime promises and records explicit operating limits.
+
+## 0.10.0 — 2026-09-04
+
+**Archived Codex sessions stay resumable without keeping their bulky local
+transcripts.** Safe disk reclaim leaves a tiny native rollout at the original
+path, so `codex resume <session-id>` still opens the same thread. The pointer
+tells Codex to use the local Sealkeep MCP, and recall searches every preserved
+snapshot carrying that exact Codex session UUID—not only the most recent
+archive. Questions whose facts span several resume/reclaim cycles are ranked
+inside that session boundary and never widened to unrelated threads.
+
+- Reclaim now fails closed unless the encrypted archive and the current
+  immutable managed search index are both verified. On a repeated resume it
+  also requires a current positive publication receipt and searchable postings
+  for every earlier reclaimed continuation, then rechecks all receipts and the
+  exact index head immediately before unlinking the source.
+- Historical indexing and context delivery run outside the interactive hook
+  path. Background work is serial and cooperative, targets at most 30% CPU,
+  shares one 8 Mbit/s vault-wide transfer ceiling, and runs in children with
+  explicit heap/RSS, cancellation, and progress-deadline limits.
+- Existing encrypted v3 indexes upgrade through the same managed CAS protocol
+  in the bounded background child. A successful publication avoids a full
+  rebuild; interrupted publication retains a durable retry marker, while an
+  incompatible or divergent index follows the authenticated rebuild path.
+
 ## 0.9.0 — 2026-08-20
 
 **Share a project, not the vault.** Until now a registered key opened everything
@@ -48,7 +269,8 @@ that no longer needs a spacious disk.
   a failed queue job used a stylesheet class that did not exist, five notes
   used an undefined token, and the retention view typed over edits in progress
   and could then save the policy you thought you had changed.
-- `archiveFile` accepts a chunk size (and honours `SEALKEEP_CHUNK_BYTES`).
+- Archive helpers accept an explicit typed test chunk size; production has no
+  undocumented environment override.
   Proving a multi-chunk archive used to mean writing 24 MB; it now takes 120 KB,
   which is why the suite stopped exhausting disks.
 - New: `npm run browser:audit` and `npm run browser:panel` — real Chrome,

package/CONTROL_PLANE.md

@@ -7,7 +7,7 @@ The control plane stores device identities, encrypted manifests, and provider co
 ```sh
 npm run control-plane                       # authenticated, durable
 SEALKEEP_CONTROL_PLANE_DEV=1 npm run control-plane   # unauthenticated, in memory
-docker build -t vaultline-control-plane . && docker run -p 8787:8787 -v vaultline-data:/data vaultline-control-plane
+docker build -t sealkeep-control-plane . && docker run -p 8787:8787 -v sealkeep-data:/data sealkeep-control-plane
 ```
 
 Endpoints:
@@ -44,7 +44,7 @@ deployed, stop it.
 ```json
 {
   "provider": "s3 | r2 | gcs | vaultline",
-  "bucket": "vaultline-archives",
+  "bucket": "sealkeep-archives",
   "region": "us-east-1",
   "prefix": "v1/accounts/<account-id>",
   "credentialMode": "server-managed | byo-role | byo-service-account"

package/LICENSE

@@ -1,4 +1,4 @@
-Vaultline Software License
+Sealkeep Software License
 
 Copyright (c) Spala.
 All rights reserved.