@serfab/cadre-core 0.9.0 → 0.11.0

package/dist/strand-membership-writer.js

@@ -1,5 +1,6 @@
 import debug from 'debug';
-import { digest, sign, verify, generatePrivateKey, getPublicKey } from '@optimystic/quereus-plugin-crypto';
+import { toString as uint8ArrayToString } from 'uint8arrays';
+import { digest, sign, verify, generatePrivateKey, getPublicKey, randomBytes } from '@optimystic/quereus-plugin-crypto';
 import { canonicalDatetime } from './canonical-datetime.js';
 const log = debug('sereus:cadre:strand-membership');
 /**
@@ -19,18 +20,17 @@ export const STRAND_ENGINE = 'quereus';
  */
 export const STRAND_ENGINE_VERSION = '0.1.0';
 /**
- * The single-digest ed25519 signer the `Strand.*` membership/RBAC constraints
- * verify against.
+ * The single-payload ed25519 signer the `Strand.Invite`/`Strand.ConsumedInvite`
+ * handshake constraints verify against.
  *
- * `schemas/strand.qsql` signs a single SHA-256 digest over a `'|'`-joined payload
- * (e.g. `Member.Authorized` verifies
- * `verify(digest(new.Key), context.ManagerSignature, A.MemberKey, 'ed25519')`).
+ * Those constraints sign a single SHA-256 digest over a `'|'`-joined payload
+ * (e.g. `InviteValid` verifies
+ * `verify(digest(new.Key || '|' || coalesce(new.Expiration, '')), ...)`).
  * So the signer hashes the payload to raw bytes and ed25519-signs *those bytes*:
  * SQL `digest(...)`'s default output is base64url and `verify(...)`'s default
  * `inputEncoding` is base64url, so signer and verifier operate on identical bytes.
- * This differs from the control-layer's multi-field `buildAuthorizationMessage`
- * (a single digest over MANY fields) — the strand layer is a single digest over ONE
- * joined payload field.
+ * The membership/RBAC tables (Member/Manager/MemberPeer/Revocation) instead use
+ * domain/action-tagged VARIADIC digests — see {@link signStrandApproval}.
  *
  * All strand keys are ed25519, so the explicit `'ed25519'` curve arg is mandatory
  * (the crypto plugin otherwise defaults to secp256k1). Mirrors the proven
@@ -47,7 +47,7 @@ export function signStrandPayload(payload, privateKeyB64) {
 /**
  * The verifier counterpart to {@link signStrandPayload}.
  *
- * Mirrors what every `Strand.*` constraint computes:
+ * Mirrors what the single-payload `Strand.*` constraints compute:
  * `verify(digest(payload), signature, publicKey, 'ed25519')`.
  * SQL `digest`'s default output and `verify`'s default `inputEncoding`/`sigEncoding`/
  * `keyEncoding` are all base64url, so the off-engine check operates on the exact
@@ -64,6 +64,121 @@ export function verifyStrandPayload(payload, signatureB64, publicKeyB64) {
     const payloadDigest = digest([payload], 'sha256', 'base64url');
     return verify(payloadDigest, signatureB64, publicKeyB64, 'ed25519', 'base64url', 'base64url', 'base64url');
 }
+/**
+ * Sign a domain/action-tagged `Strand.*` membership/RBAC approval.
+ *
+ * Every `Authorized` branch on `Member`/`Manager`/`MemberPeer`/`Revocation`
+ * verifies a VARIADIC digest — `digest('<domain>', '<action>', <field>, ...,
+ * <StampId>)` — whose leading two elements are fixed literals (the domain tag,
+ * e.g. `'Strand.Member'`, and an action tag, e.g. `'add'`) and whose trailing
+ * element is the row's per-incarnation StampId. The tags keep an approval from
+ * verifying against any rule but the one it was minted for (the idiom of the
+ * control layer's `buildAuthorizationMessage`); the StampId binding makes it
+ * single-use — it authorizes exactly one incarnation of one row, and dies when
+ * that row's stamp is retired into `Strand.Revocation`.
+ *
+ * The caller passes the digest elements exactly as the matching SQL constraint
+ * lists them (each SQL argument = one array element), PRESERVING TYPE: the
+ * crypto plugin's digest framing is type-tagged (INTEGER 1 and TEXT '1' encode
+ * differently, deliberately), so `Manager.Authorized`'s promotion branch —
+ * whose digest includes the INTEGER `new.Generation` — must be signed over the
+ * NUMBER, not its string form. Integer `number` and `bigint` encode
+ * identically in that framing, so JS-side numbers match however the engine
+ * represents the SQL integer.
+ *
+ * Like {@link signStrandPayload}, the raw digest BYTES are ed25519-signed
+ * directly, matching SQL `verify(...)`'s default base64url input decoding.
+ *
+ * @param fields - The digest elements, in constraint order (tags first, StampId last).
+ * @param privateKeyB64 - The signer's base64url ed25519 private seed.
+ * @returns The base64url ed25519 signature over the tagged digest.
+ */
+export function signStrandApproval(fields, privateKeyB64) {
+    const hashBytes = digest(fields, 'sha256', 'bytes');
+    return sign(hashBytes, privateKeyB64, 'ed25519', 'bytes', 'base64url', 'base64url');
+}
+/**
+ * Mint a fresh per-row authorization nonce (StampId) for a `Strand.Member`,
+ * `Strand.Manager`, or `Strand.MemberPeer` row.
+ *
+ * 256 bits of CSPRNG output, base64url-encoded — enough entropy that a future
+ * legitimate stamp cannot be guessed and pre-planted into `Strand.Revocation`
+ * (the `RowIsGone` comment in `schemas/strand.qsql` leans on exactly this).
+ * Plain randomness, deliberately NOT the control layer's peer-derived
+ * `generateStampId`: strand rows are not per-peer, so entropy alone carries
+ * the uniqueness.
+ *
+ * @returns A fresh base64url stamp (43 chars for 32 bytes).
+ */
+export function generateStrandStampId() {
+    // randomBytes' first arg is BITS, not bytes — 256 bits = 32 bytes.
+    const bytes = randomBytes(256, 'bytes');
+    return uint8ArrayToString(bytes, 'base64url');
+}
+/**
+ * Run `fn` inside one explicit strand transaction: begin, fn, commit — with the
+ * standard rollback-on-failure shape.
+ *
+ * Used wherever two `Strand.*` writes must land atomically: the invite-consume
+ * pair (Member + ConsumedInvite) and every delete-plus-tombstone pair (the
+ * `RevocationRecorded` constraints require the `Revocation` row in the SAME
+ * transaction as the delete it retires).
+ *
+ * JOINS a caller-owned transaction instead of opening its own: Quereus's
+ * `Database.beginTransaction()` hard-throws "Transaction already active" on any
+ * nesting, and a caller composing several writers in one transaction (e.g. a
+ * resign + revoke pair that must land atomically) is exactly the case where the
+ * deferred constraints should fire once, at the CALLER's commit. In joined mode
+ * commit/rollback belong to the caller, so failures simply propagate.
+ */
+async function inStrandTransaction(db, fn) {
+    if (!db.getAutocommit()) {
+        await fn();
+        return;
+    }
+    await db.beginTransaction();
+    try {
+        await fn();
+        await db.commit();
+    }
+    catch (error) {
+        // A failed commit() already tears down the transaction, so rollback() would
+        // throw "No transaction active" and mask the real cause — swallow only that.
+        try {
+            await db.rollback();
+        }
+        catch (rollbackError) {
+            log('Rollback after strand transaction failure was a no-op: %s', rollbackError);
+        }
+        throw error;
+    }
+}
+/**
+ * File the `Strand.Revocation` tombstone that retires a deleted row's StampId.
+ *
+ * Runs inside the SAME transaction as the delete it accompanies — the guarded
+ * tables' `RevocationRecorded` (deferred) requires the tombstone at commit, and
+ * `Revocation.RowIsGone` (also deferred) requires the row to already be gone, so
+ * the pair only ever lands together.
+ *
+ * `Revocation.Authorized` verifies the retire-tagged digest against a
+ * PRE-transaction (`committed.Member`) row, so the retiree must have been a
+ * member BEFORE this transaction. Every writer flow satisfies this: managers are
+ * members, and a self-departing member is committed until this very transaction
+ * removes it. Unlike the sibling tables' nullable contexts, `Revocation`'s
+ * context is non-null — both fields are always supplied.
+ *
+ * @param db - The strand database, INSIDE an open transaction.
+ * @param tableName - Which guarded table the stamp belonged to.
+ * @param stampId - The retired stamp.
+ * @param retiree - The committed member filing the tombstone (the delete's own signer).
+ */
+async function insertRevocation(db, tableName, stampId, retiree) {
+    const signature = signStrandApproval(['Strand.Revocation', 'retire', tableName, stampId], retiree.privateKeyB64);
+    await db.exec(`insert into Strand.Revocation (TableName, StampId)
+       with context MemberKey = ?, Signature = ?
+       values (?, ?)`, [retiree.publicKeyB64, signature, tableName, stampId]);
+}
 /**
  * Count rows in a `Strand.*` table as seen by this database instance.
  *
@@ -108,38 +223,52 @@ async function insertHeaderIfAbsent(db, params) {
 /**
  * Insert the founding `Strand.Member` if no member exists yet.
  *
- * The empty-table state satisfies the `count(1) from Member <= 1` bootstrap branch
- * of `Member.Authorized`, so no manager signature is needed — the context fields
- * are explicit nulls. Guarding on the count makes this idempotent: a re-run (the
- * founder re-`addStrand`/`resumeStrand`) finds the member present and skips.
+ * The empty PRE-transaction member set (`count(1) from committed.Member = 0`)
+ * satisfies the bootstrap branch of `Member.Authorized`, so no signature is
+ * needed — the context fields are explicit nulls. The branch also caps the
+ * POST-image at one member, so it waives authorization for exactly this single
+ * seat, never for a batch. The row still mints a fresh StampId — the column is
+ * NOT NULL on every path; bootstrap only waives the SIGNATURE. Guarding on the
+ * count makes this idempotent: a re-run (the founder re-`addStrand`/
+ * `resumeStrand`) finds the member present and skips.
  */
 async function insertFounderMemberIfAbsent(db, memberKey, strandId) {
     if (await strandTableCount(db, 'Member') > 0) {
         log('Member already present for strand %s; skipping founder Member', strandId);
         return;
     }
-    await db.exec(`insert into Strand.Member (Key)
-       with context ManagerKey = null, ManagerSignature = null
-       values (?)`, [memberKey]);
+    await db.exec(`insert into Strand.Member (Key, StampId)
+       with context ManagerKey = null, ManagerSignature = null, MemberSignature = null
+       values (?, ?)`, [memberKey, generateStrandStampId()]);
     log('Inserted founding Member for strand %s', strandId);
 }
 /**
  * Insert the founding `Strand.Manager` if no manager exists yet.
  *
- * The empty-table state satisfies the `count(1) from Manager <= 1` bootstrap
- * branch of `Manager.Authorized`, so no signature is needed. Idempotent via the
- * same count guard. Must run AFTER the Header insert: `Manager.OnlyClosed` is a
- * deferred (subquery) check evaluated at commit, and the sequential auto-commit
- * Header→Member→Manager order ensures the closed `Header` is committed first.
+ * The empty-table state satisfies the bootstrap branch of `Manager.Authorized`, so
+ * no signature is needed (a fresh StampId is still minted — the column is NOT
+ * NULL). The founder is seated at `Generation = 0` — the root of
+ * the manager lineage; the bootstrap branch requires exactly that value, and every
+ * later manager is seated at a strictly greater generation (see {@link addManager}).
+ * Idempotent via the same count guard.
+ *
+ * ORDERING IS LOAD-BEARING, not merely convenient. The bootstrap branch is gated to
+ * the founding state and now reads `exists (select 1 from Member M where M.Key =
+ * new.MemberKey)` alongside `count(Manager) <= 1` and `count(Member) <= 1`, so the
+ * founding `Member` row MUST already exist when this commits — a Manager-first
+ * seeding path is rejected. It must also run AFTER the Header insert:
+ * `Manager.OnlyClosed` is a deferred (subquery) check evaluated at commit. The
+ * sequential auto-commit Header→Member→Manager order in
+ * {@link bootstrapFounderMembership} satisfies both.
  */
 async function insertFounderManagerIfAbsent(db, memberKey, strandId) {
     if (await strandTableCount(db, 'Manager') > 0) {
         log('Manager already present for strand %s; skipping founder Manager', strandId);
         return;
     }
-    await db.exec(`insert into Strand.Manager (MemberKey)
+    await db.exec(`insert into Strand.Manager (MemberKey, Generation, StampId)
        with context ManagerKey = null, Signature = null
-       values (?)`, [memberKey]);
+       values (?, 0, ?)`, [memberKey, generateStrandStampId()]);
     log('Inserted founding Manager for strand %s', strandId);
 }
 /**
@@ -229,8 +358,8 @@ export async function issueInvite(db, params) {
  * Redeem an invite to admit a new `Member`, atomically.
  *
  * `Member.Authorized`'s invite branch needs a `ConsumedInvite` row, while
- * `ConsumedInvite`'s `MemberExists`/`MemberValid` need the `Member` row — a
- * circular dependency. Both are deferred (subquery-bearing) checks that evaluate
+ * `ConsumedInvite`'s `MemberExists` needs the `Member` row — a circular
+ * dependency. Both are deferred (subquery-bearing) checks that evaluate
  * at COMMIT, so inserting `Member` then `ConsumedInvite` inside one explicit
  * transaction lets both rows exist when the deferred checks fire. This mirrors
  * `ControlDatabase.redeemInvitation` (Strand + FormationUsage in one txn).
@@ -238,7 +367,9 @@ export async function issueInvite(db, params) {
  * The `ConsumedInvite` insert carries an `InviteSignature` over
  * `InviteKey || '|' || MemberKey`, proving the consumer holds the invite private
  * key (the on-engine `ValidUsage` gate). The `Member` insert needs no member
- * signature — its admission is the existence of the matching `ConsumedInvite`.
+ * signature — its admission is the existence of the matching `ConsumedInvite` —
+ * but still mints a fresh StampId (NOT NULL on every path; a revoked-then-
+ * re-invited member is a fresh incarnation under a fresh stamp).
  *
  * Single-use: `ConsumedInvite`'s primary key is `InviteKey`, so a second consume
  * of the same invite is rejected by the PK (a distinct layer from the control
@@ -275,42 +406,171 @@ export async function consumeInvite(db, params) {
     // schema's `I.Expiration > context.Now` compares like-for-like canonical strings.
     // Plain runtime Date.now() — the tess Workflow restriction is on scripts, not libs.
     const nowCanonical = await canonicalDatetime(db, nowMs ?? Date.now());
-    await db.beginTransaction();
-    try {
+    await inStrandTransaction(db, async () => {
         // 1. Member — admitted by the deferred invite branch (the matching
         //    ConsumedInvite below), so no manager signature is supplied.
-        await db.exec(`insert into Strand.Member (Key)
-         with context ManagerKey = null, ManagerSignature = null
-         values (?)`, [memberKey]);
+        await db.exec(`insert into Strand.Member (Key, StampId)
+         with context ManagerKey = null, ManagerSignature = null, MemberSignature = null
+         values (?, ?)`, [memberKey, generateStrandStampId()]);
         // 2. ConsumedInvite — proves possession of the invite private key and that the
         //    invite has not expired (NotExpired gate against the canonical Now).
         await db.exec(`insert into Strand.ConsumedInvite (InviteKey, MemberKey)
          with context InviteSignature = ?, Now = ?
          values (?, ?)`, [inviteSignature, nowCanonical, inviteKey, memberKey]);
-        await db.commit();
-        log('Consumed invite %s -> member %s', inviteKey, memberKey);
+    });
+    log('Consumed invite %s -> member %s', inviteKey, memberKey);
+}
+/**
+ * Every value of `InviteKey` in one of the two invite-marker tables, as a `Set`.
+ *
+ * Unfiltered scan + JavaScript comparison, deliberately: `ConsumedInvite` and
+ * `CancelledInvite` each have the single column `InviteKey` as their primary key, so
+ * ANY where-equality on it is a FULL-PK predicate — which the optimystic virtual-table
+ * module serves via a single-key point lookup that can MISS on a networked strand (the
+ * argument {@link scanMemberPeers} makes in full). Reading the whole column and
+ * comparing in JS depends only on the scan returning a SUPERSET of the live rows.
+ *
+ * The table name is a fixed literal supplied by this module (never user input), so the
+ * interpolation is not an injection surface — same as {@link strandTableCount}.
+ *
+ * NOTE: every caller pays a WHOLE-column read — {@link cancelInvite}'s idempotence guard
+ * reads all cancelled keys to answer one membership question, and
+ * {@link listOutstandingInvites} reads both marker tables per call. Fine at strand scale
+ * (a handful of invitations); if invite churn ever gets large this wants a real filtered
+ * read, which in turn needs the networked point-lookup gap closed
+ * (`debt-composite-pk-point-lookup-unreliable-untracked`).
+ */
+async function scanInviteKeys(db, table) {
+    const keys = new Set();
+    for await (const row of db.eval(`select InviteKey from Strand.${table}`)) {
+        keys.add(row.InviteKey);
     }
-    catch (error) {
-        // A failed commit() already tears down the transaction, so rollback() would
-        // throw "No transaction active" and mask the real cause — swallow only that.
-        try {
-            await db.rollback();
+    return keys;
+}
+/**
+ * Cancel an outstanding invitation, permanently: it may never be consumed.
+ *
+ * Files a `Strand.CancelledInvite` tombstone carrying a manager signature over
+ * `digest('Strand.CancelledInvite', 'cancel', InviteKey)`. The digest binds the exact
+ * invite key, so an approval minted for one invitation cannot cancel another.
+ *
+ * One row, one statement — no transaction needed. `CancelledInvite.Authorized` is a
+ * deferred (subquery-bearing) check, so it fires at this statement's own auto-commit.
+ *
+ * Insert-if-absent, matching {@link registerMemberPeer}'s and {@link revokeMember}'s
+ * restart-safe shape: a repeat cancellation logs and returns rather than throwing on the
+ * primary key. (Check-then-write is not atomic; the primary key is the real backstop —
+ * the guard is for the sequential repeat/restart path.)
+ *
+ * Cancellation is what makes removal a re-entry gate: it is the `ConsumedInvite` insert
+ * that `NotCancelled` blocks, and `Member.Authorized`'s invite branch needs a
+ * same-transaction FRESH `ConsumedInvite` row, so a cancelled invitation rolls the whole
+ * join back. Un-cancelling is impossible (`CancelledInvite.Immutable`) — to re-invite a
+ * party, {@link issueInvite} a fresh invitation.
+ *
+ * Enumerate what there is to cancel with {@link listOutstandingInvites}: an invitation
+ * names no invitee, so the strand cannot tell a manager WHICH invitations a departing
+ * member holds. Invitee binding is tracked as `feat-strand-invitee-bound-invites`.
+ *
+ * @param db - The closed strand's database.
+ * @param params - The cancelling manager's keypair and the invite key to kill.
+ * @throws If `CancelledInvite.Authorized` rejects (a non-manager, a manager seated in
+ *   this transaction, or an approval minted for a different invite key) or `OnlyClosed`
+ *   rejects (an open strand); the insert rolls back, leaving no tombstone.
+ */
+export async function cancelInvite(db, params) {
+    const { managerKeyPair, inviteKey } = params;
+    if ((await scanInviteKeys(db, 'CancelledInvite')).has(inviteKey)) {
+        log('Invite %s already cancelled; skipping', inviteKey);
+        return;
+    }
+    const signature = signStrandApproval(['Strand.CancelledInvite', 'cancel', inviteKey], managerKeyPair.privateKeyB64);
+    await db.exec(`insert into Strand.CancelledInvite (InviteKey)
+       with context ManagerKey = ?, ManagerSignature = ?
+       values (?)`, [managerKeyPair.publicKeyB64, signature, inviteKey]);
+    log('Cancelled invite %s by manager %s', inviteKey, managerKeyPair.publicKeyB64);
+}
+/**
+ * The invitations that are still redeemable: neither consumed, nor cancelled, nor
+ * expired at `nowMs`.
+ *
+ * `Strand.Invite` is insert-only and carries no state column, so "outstanding" is not a
+ * property of the row — it is the `Invite` set minus the `ConsumedInvite` keys, minus
+ * the `CancelledInvite` keys, minus anything whose `Expiration` has passed. All three
+ * exclusions mirror gates a consume would hit anyway (`ConsumedInvite`'s primary key,
+ * `NotCancelled`, `NotExpired`).
+ *
+ * Reads via unfiltered scans and compares in JavaScript — see {@link scanInviteKeys} for
+ * why a full-PK where-equality is not reliable on a networked strand.
+ *
+ * Expiry is compared as `expiration > canonicalDatetime(nowMs)`: the same transform
+ * {@link issueInvite} uses to STORE `Invite.Expiration`, so the string comparison orders
+ * chronologically, and the same strict `>` the on-engine `NotExpired` gate uses (expiry
+ * is exclusive — an invitation is dead at its expiry instant, not after it).
+ *
+ * This is the manager's enumeration side of {@link cancelInvite}, and the "door is open"
+ * pre-flight behind `StrandMemberVerifier.isAuthorizedToJoin`.
+ *
+ * @param db - The closed strand's database.
+ * @param nowMs - The instant (epoch ms) to compare expiries against; defaults to
+ *   `Date.now()`. Tests pin it so the comparison is deterministic, mirroring
+ *   {@link consumeInvite}'s `nowMs` convention.
+ * @returns The redeemable invitations, in NO guaranteed order (the scans promise only a
+ *   superset of the live rows, not a stable sequence — sort by `expiration` if order
+ *   matters); empty if none.
+ */
+export async function listOutstandingInvites(db, nowMs) {
+    // Plain runtime Date.now() — the tess Workflow restriction is on scripts, not libs.
+    const nowCanonical = await canonicalDatetime(db, nowMs ?? Date.now());
+    const consumed = await scanInviteKeys(db, 'ConsumedInvite');
+    const cancelled = await scanInviteKeys(db, 'CancelledInvite');
+    const outstanding = [];
+    for await (const row of db.eval('select Key, Expiration from Strand.Invite')) {
+        const inviteKey = row.Key;
+        const expiration = row.Expiration ?? null;
+        if (consumed.has(inviteKey) || cancelled.has(inviteKey)) {
+            continue;
         }
-        catch (rollbackError) {
-            log('Rollback after consumeInvite failure was a no-op: %s', rollbackError);
+        if (expiration != null && expiration <= nowCanonical) {
+            continue;
         }
-        throw error;
+        outstanding.push({ inviteKey, expiration });
     }
+    return outstanding;
+}
+// ── Member admission + removal (manager-admit, revoke, leave) ─────────────────
+/**
+ * The live StampId of the `Strand.Member` row keyed by `memberKey`, or
+ * `undefined` if no such row is visible.
+ *
+ * `Member`'s primary key is the single `Key` column, so ANY where-equality on it
+ * is a full-PK predicate — which the optimystic virtual-table module serves via a
+ * single-key point lookup that can MISS on a networked strand (the same failure
+ * mode {@link scanMemberPeers} documents). So this reads via an UNFILTERED scan
+ * and compares the key in JavaScript: correctness depends only on the scan
+ * returning a superset of the live rows — the weakest possible assumption about
+ * the storage layer.
+ */
+async function memberStampId(db, memberKey) {
+    for await (const row of db.eval('select Key, StampId from Strand.Member')) {
+        if (row.Key === memberKey) {
+            return row.StampId;
+        }
+    }
+    return undefined;
 }
 /**
  * Admit a `Member` directly by manager signature — the sibling of the invite
  * path on `Member.Authorized`'s direct-manager branch.
  *
- * The constraint verifies `digest(new.Key)` against a `Manager` row matching
- * `context.ManagerKey`, so the payload is just the member key (no `'|'` join).
- * No `ConsumedInvite` is involved: this is the path a manager uses to seat a
- * member it already trusts (e.g. a manager-side enrollment that admits a
- * party already authorised out-of-band).
+ * The constraint verifies the add-tagged digest
+ * `digest('Strand.Member', 'add', new.Key, new.StampId)` against a pre-existing
+ * (`committed.Manager`) row matching `context.ManagerKey`. The stamp is minted
+ * fresh here and bound inside the signed digest, so the approval seats exactly
+ * this incarnation: once the member is removed (retiring the stamp), the captured
+ * approval can never re-seat it. No `ConsumedInvite` is involved: this is the
+ * path a manager uses to seat a member it already trusts (e.g. a manager-side
+ * enrollment that admits a party already authorised out-of-band).
  *
  * @param db - The closed strand's database.
  * @param params - The admitting manager keypair and the new member key.
@@ -319,32 +579,135 @@ export async function consumeInvite(db, params) {
  */
 export async function addMemberByManager(db, params) {
     const { managerKeyPair, memberKey } = params;
-    const signature = signStrandPayload(memberKey, managerKeyPair.privateKeyB64);
-    await db.exec(`insert into Strand.Member (Key)
-       with context ManagerKey = ?, ManagerSignature = ?
-       values (?)`, [managerKeyPair.publicKeyB64, signature, memberKey]);
+    const stampId = generateStrandStampId();
+    const signature = signStrandApproval(['Strand.Member', 'add', memberKey, stampId], managerKeyPair.privateKeyB64);
+    await db.exec(`insert into Strand.Member (Key, StampId)
+       with context ManagerKey = ?, ManagerSignature = ?, MemberSignature = null
+       values (?, ?)`, [managerKeyPair.publicKeyB64, signature, memberKey, stampId]);
     log('Admitted member %s by manager %s', memberKey, managerKeyPair.publicKeyB64);
 }
+/**
+ * Revoke a `Member` on the signature of an existing manager.
+ *
+ * Reads the target row's live StampId first (a quiet no-op if the row is already
+ * absent — a repeated or restarted revocation should not throw), then runs ONE
+ * transaction pairing the delete with its `Strand.Revocation` tombstone: the
+ * schema's `Member.RevocationRecorded` requires the tombstone in the same
+ * transaction, and the tombstone is what permanently retires the stamp so the
+ * captured admission approval can never re-seat this incarnation.
+ *
+ * The manager-removal branch of `Member.Authorized` verifies the remove-tagged
+ * digest `digest('Strand.Member', 'remove', old.Key, old.StampId)` against a
+ * `committed.Manager` row matching `context.ManagerKey` — distinct from the
+ * add-tagged admission payload, and bound to the live stamp, so neither a
+ * captured admission nor a captured PRIOR removal (whose stamp differs) replays.
+ *
+ * A revoked member cannot re-admit itself off the invite it ALREADY SPENT: that
+ * `ConsumedInvite` row is stale, and the invite branch requires a
+ * same-transaction FRESH consumption. Re-admission normally takes a fresh
+ * manager action ({@link addMemberByManager} or a new invite).
+ *
+ * An UNSPENT invite the revoked party holds is killed EXPLICITLY, by the manager
+ * calling {@link cancelInvite} on it (enumerate the candidates with
+ * {@link listOutstandingInvites}); a cancelled invitation can never be consumed,
+ * and cancellation is permanent. This removal does NOT cascade into cancellation:
+ * an invitation names no invitee, so there is nothing to match the removed member
+ * against — the strand cannot tell which invitations were meant for it, or whether
+ * it holds any. Binding an invitation to its invitee is tracked as
+ * `feat-strand-invitee-bound-invites`.
+ *
+ * A manager must resign its `Manager` row before (or in the same transaction
+ * as) losing membership — `Member.NotAManager` rejects un-membering a key that
+ * still holds a Manager row. And the strand never drops to zero members
+ * (`Member.MinOneMember`, a local-count floor with the same cross-node caveat
+ * as `MinOneManager`).
+ *
+ * @param db - The closed strand's database.
+ * @param params - The revoking manager keypair and the target member key.
+ * @throws If `Member.Authorized` rejects (a non-manager or same-transaction
+ *   signer), `Member.NotAManager` rejects (the target still holds a Manager
+ *   row), or `Member.MinOneMember` rejects (the removal would empty the member
+ *   set); the whole delete+tombstone transaction rolls back.
+ */
+export async function revokeMember(db, params) {
+    const { managerKeyPair, memberKey } = params;
+    const stampId = await memberStampId(db, memberKey);
+    if (stampId == null) {
+        log('Member %s already absent; skipping revoke', memberKey);
+        return;
+    }
+    const signature = signStrandApproval(['Strand.Member', 'remove', memberKey, stampId], managerKeyPair.privateKeyB64);
+    await inStrandTransaction(db, async () => {
+        await db.exec(`delete from Strand.Member
+         with context ManagerKey = ?, ManagerSignature = ?, MemberSignature = null
+         where Key = ?`, [managerKeyPair.publicKeyB64, signature, memberKey]);
+        await insertRevocation(db, 'Member', stampId, managerKeyPair);
+    });
+    log('Revoked member %s by manager %s', memberKey, managerKeyPair.publicKeyB64);
+}
+/**
+ * A member leaves the strand by deleting its own `Member` row.
+ *
+ * The self-departure branch of `Member.Authorized` verifies
+ * `digest('Strand.Member', 'leave', old.Key, old.StampId)` against `old.Key`
+ * itself via `context.MemberSignature`. The `'leave'` tag (vs the manager
+ * branch's `'remove'`) is belt-and-braces only — the two branches verify against
+ * different keys; the anti-replay fix is the stamp binding. Like
+ * {@link revokeMember}, the live stamp is read first (absent row → quiet no-op)
+ * and the delete pairs with its `Strand.Revocation` tombstone in one transaction.
+ *
+ * The same floors as {@link revokeMember} apply: a manager must resign first
+ * (`NotAManager`) and the last member cannot leave (`MinOneMember`).
+ *
+ * @param db - The closed strand's database.
+ * @param params - The departing member's own keypair.
+ * @throws If `Member.Authorized`, `Member.NotAManager`, or `Member.MinOneMember`
+ *   rejects; the whole delete+tombstone transaction rolls back.
+ */
+export async function leaveStrand(db, params) {
+    const { memberKeyPair } = params;
+    const memberKey = memberKeyPair.publicKeyB64;
+    const stampId = await memberStampId(db, memberKey);
+    if (stampId == null) {
+        log('Member %s already absent; skipping leave', memberKey);
+        return;
+    }
+    const signature = signStrandApproval(['Strand.Member', 'leave', memberKey, stampId], memberKeyPair.privateKeyB64);
+    await inStrandTransaction(db, async () => {
+        await db.exec(`delete from Strand.Member
+         with context ManagerKey = null, ManagerSignature = null, MemberSignature = ?
+         where Key = ?`, [signature, memberKey]);
+        await insertRevocation(db, 'Member', stampId, memberKeyPair);
+    });
+    log('Member %s left the strand', memberKey);
+}
 /**
  * Register a network node (`PeerId`) as acting on behalf of a member.
  *
- * The member self-signs `MemberKey || '|' || PeerId` with its OWN key; the schema's
- * `MemberPeer.Authorized` verifies that signature against `coalesce(new.MemberKey,
- * old.MemberKey)` — i.e. the member key itself — so only the member that owns the
- * key can register peers for it. A deferred `MemberExists` additionally requires the
- * `Member` row to already exist, so a peer for a non-member is rejected at commit.
+ * The member self-signs the add-tagged digest
+ * `digest('Strand.MemberPeer', 'add', new.MemberKey, new.PeerId, new.StampId)`
+ * with its OWN key; the schema's `MemberPeer.Authorized` verifies that signature
+ * against `new.MemberKey` — i.e. the member key itself — so only the member that
+ * owns the key can register peers for it. The stamp is minted fresh here and
+ * bound inside the digest, so a captured registration approval neither
+ * re-registers a cleared binding (its stamp is retired) nor authorizes a removal
+ * (wrong tag). A deferred `MemberExists` additionally requires the `Member` row
+ * to already exist, so a peer for a non-member is rejected at commit.
  *
- * Insert-if-absent on the composite PK `(MemberKey, PeerId)`: a re-register on
- * restart (or a redundant call) is a no-op rather than relying on the platform's
- * PK-uniqueness rejection (not enforced in bootstrap mode — see
- * `optimystic-insert-pk-uniqueness-not-enforced`). A member may register multiple
- * DISTINCT `PeerId`s (multi-device); each is its own row under the same `MemberKey`.
+ * Insert-if-absent: a re-register on restart (or a redundant call) is a no-op. The
+ * platform DOES reject a duplicate-PK insert, but a restart-safe re-register should
+ * succeed quietly rather than throw, so the writer guards on existence instead of
+ * catching. The guard ({@link memberPeerStampId}) scans the member's peers and compares
+ * both key columns in JavaScript rather than seeking the composite primary key — see
+ * {@link scanMemberPeers} for why a full-PK point lookup is not reliable on a networked
+ * strand. A member may register multiple DISTINCT `PeerId`s (multi-device); each is its
+ * own row (and its own stamp) under the same `MemberKey`.
  *
- * Out of scope: peer DELETION. The schema's `MemberExists` reads `new.MemberKey`,
- * which is null on delete, so a `MemberPeer` delete is currently rejected by the
- * schema (noted in the `apply-strand-membership-schema` review). Removing a peer
- * would need a schema tweak (e.g. `coalesce(new.MemberKey, old.MemberKey)` in
- * `MemberExists`), so no `removeMemberPeer` is provided here.
+ * Peer DELETION is signature-checked too, not rejected outright: `Authorized` carries
+ * distinct delete branches (self + manager), each over its own action-tagged digest
+ * bound to the row's stamp. Both removal paths live in {@link removeMemberPeer}.
+ * UPDATE is refused outright by `NoUpdate`: a re-binding is a remove plus a fresh
+ * register (under a fresh stamp).
  *
  * @param db - The closed strand's database (the member already exists).
  * @param params - The member's own keypair and the peer id to bind.
@@ -354,96 +717,356 @@ export async function addMemberByManager(db, params) {
 export async function registerMemberPeer(db, params) {
     const { memberKeyPair, peerId } = params;
     const memberKey = memberKeyPair.publicKeyB64;
-    if (await memberPeerExists(db, memberKey, peerId)) {
+    if (await memberPeerStampId(db, memberKey, peerId) != null) {
         log('MemberPeer (%s, %s) already present; skipping', memberKey, peerId);
         return;
     }
-    const payload = `${memberKey}|${peerId}`;
-    const signature = signStrandPayload(payload, memberKeyPair.privateKeyB64);
-    await db.exec(`insert into Strand.MemberPeer (MemberKey, PeerId)
-       with context Signature = ?
-       values (?, ?)`, [signature, memberKey, peerId]);
+    const stampId = generateStrandStampId();
+    const signature = signStrandApproval(['Strand.MemberPeer', 'add', memberKey, peerId, stampId], memberKeyPair.privateKeyB64);
+    await db.exec(`insert into Strand.MemberPeer (MemberKey, PeerId, StampId)
+       with context Signature = ?, ManagerKey = null, ManagerSignature = null
+       values (?, ?, ?)`, [signature, memberKey, peerId, stampId]);
     log('Registered MemberPeer (%s, %s)', memberKey, peerId);
 }
-/** True iff a `MemberPeer` row already exists for this `(MemberKey, PeerId)`. */
-async function memberPeerExists(db, memberKey, peerId) {
-    for await (const row of db.eval('select count(1) as Count from Strand.MemberPeer where MemberKey = ? and PeerId = ?', [memberKey, peerId])) {
-        return (row.Count ?? 0) > 0;
+/**
+ * Yield every `(PeerId, StampId)` bound to `memberKey`, re-comparing the member key
+ * in JavaScript.
+ *
+ * Deliberately does NOT filter on the full composite primary key. `MemberPeer`'s PK
+ * is `(MemberKey, PeerId)`, so a `where MemberKey = ? and PeerId = ?` predicate puts
+ * an equality on BOTH key columns — which the optimystic virtual-table module reports
+ * as fully handled and serves via a single-key point lookup (one `find` descent), with
+ * the SQL engine adding no filter of its own. On a networked strand that descent is not
+ * reliable: a miss returns zero rows for a row that provably exists.
+ *
+ * Filtering on only the LEADING key column is a partial PK match, which the same module
+ * explicitly declines to handle — it falls through to a table scan and the SQL engine
+ * applies `MemberKey = ?` itself. No seek is involved, so no seek can miss. The member key
+ * is then re-compared here in JavaScript, so correctness depends only on the scan returning
+ * a SUPERSET of the matching rows — the weakest possible assumption about the storage layer.
+ * The `where` clause only trims what crosses into JS — it is NOT pushed down (see the cost
+ * note below) — so it is not a correctness dependency: a dropped or mis-applied predicate
+ * cannot produce a row attributed to the wrong member.
+ */
+async function* scanMemberPeers(db, memberKey) {
+    // NOTE: because the predicate is not pushed down, the storage layer walks the WHOLE
+    // MemberPeer table (every member's rows) per call and the SQL engine filters. Fine at
+    // strand scale; if MemberPeer ever grows large, the fix is a reliable composite-key
+    // seek, not a bigger scan.
+    // NOTE: if a secondary index on MemberPeer.MemberKey is ever added, this query stops
+    // being a scan and becomes an index seek — re-introducing the seek dependency this
+    // shape exists to remove.
+    for await (const row of db.eval('select MemberKey, PeerId, StampId from Strand.MemberPeer where MemberKey = ?', [memberKey])) {
+        if (row.MemberKey === memberKey) {
+            yield { peerId: row.PeerId, stampId: row.StampId };
+        }
+    }
+}
+/**
+ * Every `PeerId` currently bound to `memberKey`, in storage order.
+ *
+ * The enumeration side of {@link removeMemberPeer}: a manager cleaning up after a
+ * revocation knows only the departed member's key, never which devices it registered, so
+ * cleanup is `listMemberPeers` then one `removeMemberPeer` per id. Reads only — the rows
+ * it returns may name a `MemberKey` with no `Member` row (see the `MemberPeer` table NOTE
+ * in the schema), so this is NOT a membership test.
+ *
+ * @param db - The closed strand's database.
+ * @param memberKey - The `MemberPeer.MemberKey` to enumerate.
+ * @returns The bound peer ids, empty if the member has none.
+ */
+export async function listMemberPeers(db, memberKey) {
+    const peerIds = [];
+    for await (const peer of scanMemberPeers(db, memberKey)) {
+        peerIds.push(peer.peerId);
+    }
+    return peerIds;
+}
+/**
+ * The live StampId of the `MemberPeer` row for this `(MemberKey, PeerId)`, or
+ * `undefined` if no such row is visible — doubling as the existence probe.
+ *
+ * NOTE: check-then-write is not atomic. Two nodes registering the same
+ * (MemberKey, PeerId) concurrently can both observe "absent"; the primary key is the
+ * real backstop. The existence half of this guard is for the sequential restart /
+ * re-register path.
+ */
+async function memberPeerStampId(db, memberKey, peerId) {
+    for await (const peer of scanMemberPeers(db, memberKey)) {
+        if (peer.peerId === peerId) {
+            return peer.stampId;
+        }
+    }
+    return undefined;
+}
+/**
+ * Delete a `MemberPeer` binding — either the member clearing its own, or a manager
+ * clearing another member's.
+ *
+ * Reads the row's live StampId first (absent → quiet no-op, mirroring
+ * {@link registerMemberPeer}'s insert-if-absent, so a repeated or restarted cleanup
+ * is not a silent zero-row "success" the caller cannot distinguish from a real one),
+ * then runs ONE transaction pairing the delete with its `Strand.Revocation`
+ * tombstone — `MemberPeer.RevocationRecorded` requires it, and the retirement is
+ * what keeps the captured registration approval from re-binding the cleared row.
+ *
+ * `MemberPeer` rows do NOT cascade when the member is revoked (`MemberExists` runs on
+ * insert only, and nothing deletes them), so a removed member's peer bindings survive
+ * as orphans — enumerate them with {@link listMemberPeers}, which is how a manager
+ * discovers what to clear. Only that member can sign the self branch, and a member being
+ * removed against its will has no reason to cooperate — hence the manager branch, which
+ * is the cleanup path after a revocation.
+ *
+ * The manager branch is deliberately NOT gated on the member already being gone: a
+ * manager may clear a still-present member's binding too, matching "any manager can
+ * remove any member". It verifies the manager-remove-tagged
+ * `digest('Strand.MemberPeer', 'manager-remove', old.MemberKey, old.PeerId, old.StampId)`
+ * against a `committed.Manager` row; the self branch verifies the remove-tagged
+ * sibling against the row's own member key.
+ *
+ * Cleanup is an explicit follow-up call by the revoking manager, never a cascade inside
+ * {@link revokeMember}: a revocation that also had to clear an unbounded number of peer
+ * rows in the same transaction would couple two concerns and make its failure modes
+ * harder to reason about.
+ *
+ * @param db - The closed strand's database.
+ * @param params - Either the owning member's keypair, or a manager's keypair plus the
+ *   target member key.
+ * @throws If `MemberPeer.Authorized` rejects (neither branch satisfied), or if the row
+ *   is still present after the delete (see the point-lookup note below).
+ */
+export async function removeMemberPeer(db, params) {
+    const memberKey = 'memberKeyPair' in params ? params.memberKeyPair.publicKeyB64 : params.memberKey;
+    const { peerId } = params;
+    const stampId = await memberPeerStampId(db, memberKey, peerId);
+    if (stampId == null) {
+        log('MemberPeer (%s, %s) already absent; skipping', memberKey, peerId);
+        return;
     }
-    return false;
+    await inStrandTransaction(db, async () => {
+        if ('memberKeyPair' in params) {
+            await deleteOwnMemberPeer(db, params, stampId);
+        }
+        else {
+            await deleteMemberPeerByManager(db, params, stampId);
+        }
+    });
+    // NOTE: the delete's `where` puts an equality on BOTH composite-PK columns, which the
+    // optimystic vtab module serves via a single-key seek that can MISS on a networked
+    // strand (see scanMemberPeers' doc). A missed seek deletes zero rows and still
+    // reports success. `Revocation.RowIsGone` now catches that first — the tombstone filed
+    // in the same transaction refuses to retire a stamp whose row is still visible, so the
+    // commit above fails loudly and this re-check is belt-and-braces behind it. Tracked as
+    // `debt-composite-pk-point-lookup-unreliable-untracked`; this is an availability
+    // failure mode, never a security one (a miss removes nothing, it never over-removes).
+    if (await memberPeerStampId(db, memberKey, peerId) != null) {
+        throw new Error(`MemberPeer (${memberKey}, ${peerId}) still present after delete`);
+    }
+    log('Removed MemberPeer (%s, %s)', memberKey, peerId);
+}
+/** The self branch: the owning member signs the remove-tagged digest + tombstone. */
+async function deleteOwnMemberPeer(db, params, stampId) {
+    const { memberKeyPair, peerId } = params;
+    const memberKey = memberKeyPair.publicKeyB64;
+    const signature = signStrandApproval(['Strand.MemberPeer', 'remove', memberKey, peerId, stampId], memberKeyPair.privateKeyB64);
+    await db.exec(`delete from Strand.MemberPeer
+       with context Signature = ?, ManagerKey = null, ManagerSignature = null
+       where MemberKey = ? and PeerId = ?`, [signature, memberKey, peerId]);
+    await insertRevocation(db, 'MemberPeer', stampId, memberKeyPair);
 }
+/** The manager branch: a manager signs the manager-remove-tagged digest + tombstone. */
+async function deleteMemberPeerByManager(db, params, stampId) {
+    const { managerKeyPair, memberKey, peerId } = params;
+    const signature = signStrandApproval(['Strand.MemberPeer', 'manager-remove', memberKey, peerId, stampId], managerKeyPair.privateKeyB64);
+    await db.exec(`delete from Strand.MemberPeer
+       with context Signature = null, ManagerKey = ?, ManagerSignature = ?
+       where MemberKey = ? and PeerId = ?`, [managerKeyPair.publicKeyB64, signature, memberKey, peerId]);
+    await insertRevocation(db, 'MemberPeer', stampId, managerKeyPair);
+}
+// ── Manager rotation (add / remove RBAC admins) ───────────────────────────────
 /**
- * Promote a member to `Manager` on the signature of an existing manager.
+ * The live `(Generation, StampId)` of the `Strand.Manager` row keyed by
+ * `memberKey`, or `undefined` if no such row is visible.
  *
- * The existing-manager branch of `Manager.Authorized` verifies
- * `digest(coalesce(new.MemberKey, old.MemberKey))` — `new.MemberKey` =
- * `newManagerKey` on insert — against a `Manager` row matching
- * `context.ManagerKey`. So the signer signs the new manager key directly (no
- * `'|'` join) and binds itself as `context.ManagerKey`.
+ * `Manager`'s primary key is the single `MemberKey` column, so any where-equality
+ * on it is a full-PK point lookup — unreliable on a networked strand (see
+ * {@link scanMemberPeers}). An unfiltered scan + JavaScript filter instead, same
+ * as {@link memberStampId}. Serves both {@link addManager} (the authorizer's
+ * generation) and {@link removeManager} (the target's stamp).
+ */
+async function managerRow(db, memberKey) {
+    for await (const row of db.eval('select MemberKey, Generation, StampId from Strand.Manager')) {
+        if (row.MemberKey === memberKey) {
+            return { generation: Number(row.Generation), stampId: row.StampId };
+        }
+    }
+    return undefined;
+}
+/**
+ * Promote a key that is ALREADY a `Strand.Member` to `Manager` on the signature of
+ * an existing manager — use {@link admitManager} to admit and promote atomically.
+ *
+ * The promotion branch of `Manager.Authorized` requires the authorizer to be a
+ * `Manager` row of STRICTLY SMALLER `Generation` than the new row, verifying
+ * `digest('Strand.Manager', 'add', new.MemberKey, new.Generation, new.StampId)`
+ * against `context.ManagerKey`. So this writer reads the authorizer's generation,
+ * seats the new manager at that value + 1 (the natural successor; the schema
+ * enforces only the strict ordering), mints a fresh stamp, and signs the
+ * add-tagged digest over all three: the generation inside the signed digest keeps
+ * a captured promotion from replaying at a different generation, and the stamp
+ * keeps it from re-seating a second incarnation once this one is removed.
+ * `new.Generation` is an SQL INTEGER digest arg — the digest framing is
+ * type-tagged, so the TS side signs over the NUMBER itself
+ * (see {@link signStrandApproval}).
+ *
+ * The strict ordering — not this writer — is what makes a same-transaction takeover
+ * impossible; the `Manager.Generation` column comment in `schemas/strand.qsql` carries
+ * that argument. All this writer owes it is a generation strictly above the
+ * authorizer's, inside the signed payload.
  *
- * Once the founder manager exists, the schema's `(select count(1) from Manager)
- * <= 1` bootstrap shortcut no longer applies to a second add (at commit the count
- * includes the new row, so it is ≥ 2), so this genuinely exercises signature
- * verification — a non-manager signer, or a signature over the wrong key, is
- * rejected.
+ * When the authorizer has NO `Manager` row (a non-manager signer, or an open
+ * strand with no managers at all), the scan finds nothing and the writer falls
+ * back to generation 1 and issues the insert anyway — deliberately letting the
+ * SCHEMA be the rejector (`Manager.Authorized` / `OnlyClosed`), not a
+ * writer-thrown error, so enforcement is pinned where it actually lives.
  *
  * @param db - The closed strand's database (founder manager already seated).
  * @param params - The authorizing manager's keypair and the new manager key.
- * @throws If `Manager.Authorized` rejects; the insert rolls back.
+ * @throws If `Manager.Authorized` rejects, or if `Manager.MemberExists` rejects because
+ *   `newManagerKey` holds no `Member` row (admit it first, or use
+ *   {@link admitManager}); the insert rolls back.
  */
 export async function addManager(db, params) {
     const { byManagerKeyPair, newManagerKey } = params;
-    const signature = signStrandPayload(newManagerKey, byManagerKeyPair.privateKeyB64);
-    await db.exec(`insert into Strand.Manager (MemberKey)
+    const authorizer = await managerRow(db, byManagerKeyPair.publicKeyB64);
+    // NOTE: +1 saturates at Number.MAX_SAFE_INTEGER, where the successor compares equal
+    // to its authorizer and the schema rejects. Unreachable while generations only ever
+    // grow by 1 from 0, but the schema enforces ordering, not adjacency, so a manager may
+    // seat a successor at any larger value; if arbitrary generations ever become writable
+    // from outside this function, clamp or reject here rather than emitting a dead row.
+    const generation = authorizer == null ? 1 : authorizer.generation + 1;
+    const stampId = generateStrandStampId();
+    const signature = signStrandApproval(['Strand.Manager', 'add', newManagerKey, generation, stampId], byManagerKeyPair.privateKeyB64);
+    await db.exec(`insert into Strand.Manager (MemberKey, Generation, StampId)
        with context ManagerKey = ?, Signature = ?
-       values (?)`, [byManagerKeyPair.publicKeyB64, signature, newManagerKey]);
-    log('Added manager %s by %s', newManagerKey, byManagerKeyPair.publicKeyB64);
+       values (?, ?, ?)`, [byManagerKeyPair.publicKeyB64, signature, newManagerKey, generation, stampId]);
+    log('Added manager %s (generation %d) by %s', newManagerKey, generation, byManagerKeyPair.publicKeyB64);
+}
+/**
+ * Admit a key as a `Member` AND promote it to `Manager`, atomically — the one-step
+ * pair for a key that is not in the strand yet. {@link addManager} alone promotes a
+ * key that is already a member.
+ *
+ * ONE transaction, because `Manager.MemberExists` is a deferred check reading the LIVE
+ * `Member` table: the sibling `Member` insert satisfies it at the shared commit, and a
+ * rejection of either half rolls BOTH rows back — never a `Member` row seated by a
+ * failed promotion, nor a `Manager` row with no member behind it.
+ *
+ * NO new authority: both halves are signed by the SAME manager, over two distinct
+ * action-tagged digests — `digest('Strand.Member', 'add', …)` for the admission and
+ * `digest('Strand.Manager', 'add', …)` for the promotion — each bound to its own row's
+ * fresh stamp. This composes exactly the two approvals that manager could already
+ * issue separately.
+ *
+ * The promoting manager must be a PRE-transaction manager: the direct-admit branch of
+ * `Member.Authorized` reads `committed.Manager`, so `admitManager` cannot be chained —
+ * a manager seated by an `admitManager` earlier in the SAME transaction cannot admit
+ * the next one. (A same-transaction promotion CHAIN rooted at a pre-existing manager
+ * is fine; only the `Member` half needs the committed authorizer.)
+ *
+ * NOT insert-if-absent: a repeat call for a key that is already a member fails on the
+ * `Member` primary key, matching {@link addMemberByManager}'s unguarded shape.
+ *
+ * @param db - The closed strand's database (founder manager already seated).
+ * @param params - The authorizing manager's keypair and the key to admit + promote.
+ * @throws If either half is rejected (`Member.Authorized`, `Manager.Authorized`, a
+ *   duplicate `Member` key, …); the whole transaction rolls back, leaving neither row.
+ */
+export async function admitManager(db, params) {
+    const { byManagerKeyPair, newManagerKey } = params;
+    await inStrandTransaction(db, async () => {
+        await addMemberByManager(db, { managerKeyPair: byManagerKeyPair, memberKey: newManagerKey });
+        await addManager(db, { byManagerKeyPair, newManagerKey });
+    });
+    log('Admitted + promoted manager %s by %s', newManagerKey, byManagerKeyPair.publicKeyB64);
 }
 /**
  * Remove a `Manager` row — either an admin removing a different manager or a
  * manager resigning itself.
  *
- * On a DELETE, `coalesce(new.MemberKey, old.MemberKey)` binds `old.MemberKey =
- * targetManagerKey` (there is no `new` row), so the signed payload is the target
- * key for BOTH accepting branches of `Manager.Authorized`, and a single context
- * construction serves both:
- * - **Admin removal**: `byManagerKeyPair` is a different existing manager; the
- *   existing-manager branch verifies the signature against `A.MemberKey =
- *   context.ManagerKey`.
- * - **Self-resignation**: `byManagerKeyPair` IS the target (its `publicKeyB64`
- *   equals `targetManagerKey`); the former-manager self branch verifies
- *   `old.MemberKey = context.ManagerKey` and the self-signature over `old.MemberKey`.
- *
- * The caller selects the case purely by which keypair it passes — no branching here.
- *
- * KNOWN PLATFORM GAP (not fixable here): the optimystic bootstrap-mode transactor
- * evaluates deferred (subquery-bearing) CHECK constraints only on INSERT, not on
- * DELETE. `Manager.Authorized` is deferred, so the platform currently accepts ANY
- * `Manager` delete regardless of signature — `removeManager`'s authorization is
- * effectively unenforced at runtime until that gap is closed (filed as
- * `optimystic-deferred-check-not-enforced-on-delete`). This writer still builds the
- * correct, signed delete so it works unchanged once enforcement lands — exactly as
- * the invite path issues correct inserts despite the open PK-uniqueness gap.
- *
- * KNOWN SCHEMA HAZARD (not guarded here): even with enforcement, `Manager.
- * Authorized`'s `(select count(1) from Manager) <= 1` bootstrap branch is true at
- * commit whenever a delete drops the count to ≤ 1, so removing the strand's LAST (or
- * second-to-last) manager would be accepted regardless of signature — and removing
- * the last one orphans the strand (no one can ever add another). The schema does not
- * prevent this; a "min-one-manager" invariant is deferred to a future schema change
- * rather than grown into this writer.
+ * Reads the target row's live `(Generation, StampId)` first (absent → quiet
+ * no-op, same restart-safe shape as {@link revokeMember}), then runs ONE
+ * transaction pairing the delete with its `Strand.Revocation` tombstone
+ * (`Manager.RevocationRecorded`). The two delete-side branches of
+ * `Manager.Authorized` verify DIFFERENT action-tagged digests, each bound to
+ * `(old.MemberKey, old.StampId)`:
+ * - **Admin removal** (`byManagerKeyPair` is a different existing manager): the
+ *   removal branch verifies `digest('Strand.Manager', 'remove', old.MemberKey,
+ *   old.StampId)` against `A.MemberKey = context.ManagerKey`. Deliberately NO
+ *   generation condition: a later-generation manager may remove an
+ *   earlier-generation one (generation is lineage, not privilege), and deletes
+ *   are safe once inserts are — every accepting branch requires a `Manager` row
+ *   in the post-image, and the promotion branch's generation ordering keeps
+ *   attacker rows out of it. The stamp binding is what makes a captured removal
+ *   single-use: a re-promoted manager carries a fresh stamp the old approval
+ *   does not match — closing the removal half of
+ *   `bug-strand-manager-authority-antireplay` (the insert half was already
+ *   closed by the generation-bearing promotion payload).
+ * - **Self-resignation** (`byManagerKeyPair` IS the target): the former-manager
+ *   self branch verifies `digest('Strand.Manager', 'resign', old.MemberKey,
+ *   old.StampId)` against `old.MemberKey` itself. The distinct `'resign'` tag is
+ *   belt-and-braces (different verifying keys); the anti-replay fix is the stamp.
+ *
+ * The caller selects the case purely by which keypair it passes; the only
+ * branching here is the action tag, chosen by comparing the signer to the target.
+ *
+ * Deferred (subquery-bearing) CHECK constraints are evaluated on DELETE as well
+ * as INSERT by Quereus plus the Optimystic vtab session — enforcement lives above
+ * the transactor (proven on the network transactor by
+ * `strand-membership-network-transactor-parity.spec.ts`), so `Manager.Authorized`
+ * — deferred — IS enforced here: a signer that is neither an existing manager nor
+ * the target itself is rejected at commit.
+ *
+ * THE LAST MANAGER CANNOT BE REMOVED. `Manager.MinOneManager` (`check on delete`,
+ * deferred, so it sees the POST-delete count) rejects any delete that would leave the
+ * strand with zero managers — an admin-less closed strand could never admit anyone
+ * again, since `Invite`, `addMemberByManager`, and `addManager` all require a
+ * `Manager` row. The bootstrap branch of `Manager.Authorized` is gated to INSERTs
+ * (`old.MemberKey is null`), so it does not waive the signature check on a delete
+ * that drops the count toward the floor: a second-to-last removal is authorized
+ * exactly like any other.
+ *
+ * HAND-OFF ORDER: a sole manager transferring control must ADD the successor FIRST
+ * and resign SECOND. A same-transaction delete-then-insert swap is rejected — the
+ * bootstrap branch is gated to the founding state (at most one `Member`), and the
+ * successor's insert has no other manager to authorize it once the sole manager's
+ * row is gone.
+ *
+ * Cross-node caveat: `MinOneManager` counts rows visible to THIS transaction, so two
+ * nodes concurrently removing different managers can each see a survivor and still
+ * converge to zero. Noted in the schema; a cross-node floor is not attempted here.
  *
  * @param db - The closed strand's database.
  * @param params - The authorizing keypair and the target manager key.
- * @throws If `Manager.Authorized` rejects (e.g. a non-manager admin removal
- *   while > 2 managers remain); the delete rolls back.
+ * @throws If `Manager.Authorized` rejects (a signer that is neither another existing
+ *   manager nor the target itself) or `Manager.MinOneManager` rejects (the removal
+ *   would leave no managers); the whole delete+tombstone transaction rolls back.
  */
 export async function removeManager(db, params) {
     const { byManagerKeyPair, targetManagerKey } = params;
-    const signature = signStrandPayload(targetManagerKey, byManagerKeyPair.privateKeyB64);
-    await db.exec(`delete from Strand.Manager
-       with context ManagerKey = ?, Signature = ?
-       where MemberKey = ?`, [byManagerKeyPair.publicKeyB64, signature, targetManagerKey]);
+    const target = await managerRow(db, targetManagerKey);
+    if (target == null) {
+        log('Manager %s already absent; skipping removal', targetManagerKey);
+        return;
+    }
+    const tag = byManagerKeyPair.publicKeyB64 === targetManagerKey ? 'resign' : 'remove';
+    const signature = signStrandApproval(['Strand.Manager', tag, targetManagerKey, target.stampId], byManagerKeyPair.privateKeyB64);
+    await inStrandTransaction(db, async () => {
+        await db.exec(`delete from Strand.Manager
+         with context ManagerKey = ?, Signature = ?
+         where MemberKey = ?`, [byManagerKeyPair.publicKeyB64, signature, targetManagerKey]);
+        await insertRevocation(db, 'Manager', target.stampId, byManagerKeyPair);
+    });
     log('Removed manager %s by %s', targetManagerKey, byManagerKeyPair.publicKeyB64);
 }
 //# sourceMappingURL=strand-membership-writer.js.map