docs(chord): slice 6b D3, one id counter per store

packages/chord/docs/next/decisions.md

@@ -1639,6 +1639,15 @@ validation and copies the v2 kernel added around Delta.
   the outbox, export, import, the applier and later `evolveTable` versions handle them as every table. The partial
   head index becomes an index on `(conversation_id, has_head, id)`; indexed strings that must stay lossless keep
   Durable's JSON encoding.
+- **Slice 6b D3: one id counter per store (owner, 2026-10-27: "a"):** the store's counter (`next_document_id`, renamed
+  `next_id`; the archive manifest's `nextDocumentId` becomes `nextId`) numbers every id in the store: Durable's
+  `mintId` (conversations, entries, tasks, submissions, documents) takes from it in memory, explicit ids in Durable's
+  writes raise it (an entry committed with id 100: the next mint is 101), and Chord's commit step takes its documents'
+  ids from it; it is persisted as a high-water mark with every commit. `record_ids` stays for Durable's type check of
+  an id ("already belongs to entry"); supersedes "Slice 6 first decisions" (3)'s `coalesce(max(id), 1) + 1` and 6a's
+  "document ids monotonic with seq". Durable's own ids still rise in its creation order (its Session line serializes
+  its commits and mints inside them), which its scans, transcripts and windows rely on; Chord's ids are gaps between
+  them, as the five record types already leave. A minted id never committed may come again after a reopen (S10).
 - **The performance and memory bar, and converging reviews (owner, 2026-10-27: "yes"):** supersedes "as good as
   HEAD in everything" for Chord v2 slices and pi changes. CPU: each hot path (calls, changes, watches, links) within
   about 5% of HEAD, measured in bursts with alternating processes pinned to one CPU; worse is fixed or goes to the

packages/chord/docs/next/slice-6b.md

@@ -78,17 +78,12 @@ kinds and keys) keep Durable's JSON encoding in their columns.
 
 ### 1.2 IDs
 
-> **Decision needed (D3): one id counter or two.** Durable mints ids before a commit (`mintId`), one namespace across
-> conversations, entries, tasks, submissions and documents ("greater than every id minted since this storage was
-> opened and every id stored, also across reopen", S10); its documents carry their id into the commit. Chord's store
-> assigns its documents' ids inside the step from its own counter (`next_document_id`), and the engine's
-> `chord_documents.id` is the primary key for both. Options: (a) **one counter per store**: `mintId` takes from the
-> store's counter in memory (persisted as a high-water mark with every commit), Chord's step takes from it too; Chord's
-> document ids are then no longer monotonic with seq (6a small item 11) and a Durable id minted but never committed
-> is skipped; (b) **two counters**: Durable's from `record_ids` (`coalesce(max(id), 1) + 1` at open, decided), Chord's
-> as today, and the engine's documents table keyed by `(namespace, id)` (Durable's document ids live in Durable's
-> namespace). Proposal: (b): Durable keeps its id contract unchanged and Chord its step-assigned ids; the composite key
-> costs nothing measurable and keeps the two adapters apart (S13: the engine is shared, the namespaces are not).
+**One counter per store (D3, owner, 2026-10-27):** the store's counter (`next_document_id` renamed `next_id`, the
+manifest's `nextDocumentId` renamed `nextId`) numbers every id: `StoreStorage.mintId()` takes from it in memory,
+explicit ids in Durable's writes raise it, Chord's commit step takes its documents' ids from it, and every commit
+persists it as a high-water mark. `record_ids` stays for Durable's "ID n already belongs to entry" check. Durable's ids
+rise in its creation order (its scans and windows rely on it); Chord's ids are gaps between them. Spec reviewers check
+that nothing relies on Chord's document ids rising with seq.
 
 ### 1.3 Documents