@consiliency/agent-board-schema 1.12.0 → 1.23.0

package/tests/isolation/specs/ceiling_setter_lock_before_upsert.spec

@@ -0,0 +1,117 @@
+# Consiliency/message-board#196 — set_board_authority_ceiling must HOLD the
+# board-keyed ceiling advisory lock BEFORE it touches board_authority_ceilings.
+#
+# WHY THIS SPEC EXISTS. The ordering was pinned only by a positional pgTAP
+# assertion over RAW function text ('the ceiling setter holds the same lock
+# before its owner gate and upsert'). Moving the `perform
+# agent_board._lock_board_authority_ceiling(p_board_id)` to the END of the
+# function made that assertion fail -- and adding ONE `--` comment naming the
+# marker made the whole file pass 52/52 with the ordering violated. Measured
+# against all 20 committed specs, NOTHING else moved: this ordering had no
+# runtime backstop at all.
+#
+# HOW THE ORDER IS OBSERVED (a lock trace, not a return value). The outcome of
+# the call is the same in both orders, so the observable has to be what the
+# transaction is HOLDING while it is blocked:
+#   * a guard session holds the ceiling advisory lock, so the setter blocks --
+#     isolationtester prints `<waiting ...>`;
+#   * a third session then probes the ceiling ROW with `for update nowait`.
+#     CORRECT ORDER: the setter is parked on the advisory lock and has not
+#     reached its upsert, so the row is free and the probe returns 'admin'.
+#     LOCK-LAST ORDER: the setter already ran `on conflict do update`, so it
+#     holds the row and the probe fails immediately with
+#     `ERROR: could not obtain lock on row in relation "board_authority_ceilings"`.
+# NOWAIT is what makes this terminate in BOTH states -- the probe never joins the
+# wait graph, so a violated ordering produces a diff, never a hang.
+#
+# The ceiling row is SEEDED in setup on purpose: with no pre-existing row the
+# upsert takes the INSERT path and there is no row for the probe to witness.
+#
+# MUTATION-VERIFIED: `perform agent_board._lock_board_authority_ceiling(p_board_id)`
+# relocated after the upsert -> this golden changes (probe errors instead of
+# returning 'admin'). Clean schema -> byte-identical across 10 runs.
+
+setup
+{
+  insert into auth.users (id) values ('19600000-0000-0000-0000-0000000000a1');
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id)
+  values ('19600000-0000-0000-0000-000000000001', 'agent', 'agent',
+          'ceiling-order-owner', 'Ceiling Order Owner', 'active',
+          '19600000-0000-0000-0000-0000000000a1');
+  select count(*) from agent_board.create_board(
+    '19600000-0000-0000-0000-000000000001',
+    'ceiling-order-board', 'Ceiling Order Board',
+    'Consiliency/message-board#196 ceiling setter lock-order probe',
+    jsonb_build_object(), 'private'
+  );
+  insert into agent_board.board_authority_ceilings(board_id, max_grantable_role)
+  values ((select id from agent_board.boards where slug='ceiling-order-board'), 'admin');
+}
+
+teardown
+{
+  delete from agent_board.board_authority_ceilings where board_id in (
+    select id from agent_board.boards where slug='ceiling-order-board'
+  );
+  delete from agent_board.board_memberships where board_id in (
+    select id from agent_board.boards where slug='ceiling-order-board'
+  );
+  delete from agent_board.boards where slug='ceiling-order-board';
+  delete from agent_board.agents where id='19600000-0000-0000-0000-000000000001';
+  delete from auth.users where id='19600000-0000-0000-0000-0000000000a1';
+}
+
+# Holds the SAME board-keyed advisory lock the setter must take first. It calls
+# the helper rather than re-deriving the key, so a key-derivation change cannot
+# silently make this guard lock a different object.
+session "holder"
+step "holder_begin" { BEGIN; }
+step "hold_ceiling_lock" {
+  select agent_board._lock_board_authority_ceiling(
+    (select id from agent_board.boards where slug='ceiling-order-board')) as locked;
+}
+step "holder_commit" { COMMIT; }
+
+# The ceiling setter is owner-gated on current_agent_id(), so it runs as the owner
+# under `authenticated` (service_role's current_agent_id() is null and the gate
+# rejects it).
+session "setter"
+step "setter_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '19600000-0000-0000-0000-0000000000a1';
+}
+step "set_ceiling" {
+  select ceiling_max_grantable_role from agent_board.set_board_authority_ceiling(
+    (select id from agent_board.boards where slug='ceiling-order-board'),
+    'member'
+  );
+}
+step "setter_commit" { COMMIT; }
+
+# NOWAIT probe: witnesses whether the blocked setter is already holding the
+# ceiling row. Never blocks, so the permutation terminates in both orders.
+session "probe"
+step "probe_begin" { BEGIN; }
+step "probe_ceiling_row" {
+  select max_grantable_role from agent_board.board_authority_ceilings
+   where board_id = (select id from agent_board.boards where slug='ceiling-order-board')
+   for update nowait;
+}
+step "probe_commit" { COMMIT; }
+
+session "check"
+step "check" {
+  select max_grantable_role from agent_board.board_authority_ceilings
+   where board_id = (select id from agent_board.boards where slug='ceiling-order-board');
+}
+
+# THE ORDERING PROBE. The setter is parked on the advisory lock; the ceiling row
+# must still be free.
+permutation "holder_begin" "hold_ceiling_lock" "setter_begin" "set_ceiling" "probe_begin" "probe_ceiling_row" "probe_commit" "holder_commit" "setter_commit" "check"
+
+# Uncontended control: with nobody holding the advisory lock the setter completes
+# in one step, so a `<waiting ...>` above is attributable to the lock and not to
+# some unrelated serialization.
+permutation "setter_begin" "set_ceiling" "setter_commit" "probe_begin" "probe_ceiling_row" "probe_commit" "check"

package/tests/isolation/specs/claimgate_ownerless_quota.spec

@@ -0,0 +1,77 @@
+# CLAIMGATE/SHADOW (#133) — the ownerless per-agent active-claim QUOTA is transactionally
+# serialized. The agent already holds (quota - 1) = 49 active 'file' claims. Two sessions then
+# each acquire ONE MORE ownerless claim on DISTINCT keys concurrently. The row-level uniqueness
+# index does NOT serialize them (different keys), so a naive count-before-insert would let BOTH
+# observe 49 (< 50) and BOTH insert — 51 active claims, quota bypassed.
+#
+# The shipped acquire_claim takes an actor-scoped pg_advisory_xact_lock BEFORE the count, so the
+# two acquisitions by the same actor SERIALIZE: session sb BLOCKS on sa's lock until sa commits,
+# then counts 50 (>= 50) and is DENIED (errcode 54000). Final state: exactly 50 active claims.
+#
+# WHAT THIS PINS (a TRACE): sb's acquire prints `<waiting ...>` on sa's advisory lock; after sa
+# commits, sb COMPLETES with `ERROR: ownerless active-claim quota reached`. The checker sees 50.
+#
+# MUTATION SIGNAL (verified in the PR): remove the pg_advisory_xact_lock line from acquire_claim
+# -> sb no longer waits, both count 49 and both INSERT, no error line, and the checker sees 51.
+# The golden diverges on both the missing `<waiting ...>` and the 50-vs-51 count.
+#
+# Sessions run as `authenticated` (NOT service_role — the operator carve-out exempts service_role
+# from the quota), with request.jwt.claim.sub selecting the quota agent.
+
+setup
+{
+  -- SHADOW ships the ownerless guards OFF by default; this spec pins the quota ENFORCEMENT path,
+  -- so enable the guard flag first (the state an operator/ENFORCE reaches post-census).
+  insert into agent_board.claimgate_enforcement_flags(scope_key, enabled) values ('ownerless_guards', true)
+    on conflict (scope_key) do update set enabled = true;
+  insert into auth.users (id) values ('c0a70000-0000-4000-8000-0000000000aa');
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id, owner_user_id)
+  values ('c0a70000-0000-4000-8000-0000000000bb', 'agent', 'agent', 'cg-quota-iso', 'CG Quota Iso', 'active',
+          'c0a70000-0000-4000-8000-0000000000aa', 'c0a70000-0000-4000-8000-0000000000aa');
+  -- seed (quota - 1) active file claims for the agent.
+  insert into agent_board.claims(agent_id, resource_kind, resource_key, lease_expires_at)
+  select 'c0a70000-0000-4000-8000-0000000000bb', 'file', 'cg-iso-seed-' || g, now() + interval '1 hour'
+    from generate_series(1, agent_board._claimgate_ownerless_quota() - 1) g;
+}
+
+teardown
+{
+  delete from agent_board.claims where agent_id = 'c0a70000-0000-4000-8000-0000000000bb';
+  delete from agent_board.agents where id = 'c0a70000-0000-4000-8000-0000000000bb';
+  delete from auth.users where id = 'c0a70000-0000-4000-8000-0000000000aa';
+  delete from agent_board.claimgate_enforcement_flags where scope_key = 'ownerless_guards';
+}
+
+# sa acquires the 50th (=quota) claim: it takes the actor advisory lock, counts 49 (< 50), inserts,
+# and holds the lock until commit.
+session "sa"
+step "sa_begin" { BEGIN; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = 'c0a70000-0000-4000-8000-0000000000aa'; }
+step "sa_acq"   {
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cg-iso-sa', now() + interval '1 hour', null, null);
+}
+step "sa_commit" { COMMIT; }
+
+# sb acquires a DIFFERENT-key claim: its acquire blocks on sa's advisory lock, then on sa commit
+# counts 50 (>= 50) and raises the quota error.
+session "sb"
+step "sb_begin" { BEGIN; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = 'c0a70000-0000-4000-8000-0000000000aa'; }
+step "sb_acq"   {
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cg-iso-sb', now() + interval '1 hour', null, null);
+}
+step "sb_commit" { COMMIT; }
+
+# checker: exactly 50 active file claims survive (sa's succeeded, sb's was denied).
+session "chk"
+step "chk" {
+  select count(*)::int as active_file_claims
+    from agent_board.claims
+   where agent_id = 'c0a70000-0000-4000-8000-0000000000bb'
+     and resource_kind = 'file'
+     and status = 'active'
+     and released_at is null
+     and lease_expires_at > now();
+}
+
+permutation "sa_begin" "sa_acq" "sb_begin" "sb_acq" "sa_commit" "sb_commit" "chk"

package/tests/isolation/specs/claimkey_renew_race.spec

@@ -0,0 +1,67 @@
+# CLAIMGATE/CLAIMKEY (#133) MUST-FIX 1 — renew_claim canonicalization is race-safe.
+#
+# Two ACTIVE claims name the SAME physical machine via distinct legacy keys that both
+# canonicalize to 'fpRace' ('machine:fpRace' and '  fpRace  '). Renewed concurrently, each
+# session's canonicalizing UPDATE targets 'fpRace' on claims_active_resource_unique. A
+# check-then-act guard would let both observe the slot free at READ COMMITTED and one would
+# raise 23505 — the panel's must-fix. The shipped renew wraps the UPDATE in a unique_violation
+# handler that retries ONCE keeping the current key, so the loser does NOT raise: it renews the
+# lease and keeps its legacy key (the deferred alias ENFORCE closes).
+#
+# WHAT THIS PINS (a TRACE, per Postgres's own isolation suite): session rb's renew BLOCKS on
+# ra's uncommitted index entry (isolationtester prints `<waiting ...>`), and after ra commits rb
+# COMPLETES returning its kept legacy key '  fpRace  ' — no error line. Both leases stay active.
+#
+# MUTATION SIGNAL (verified in the PR): drop the `exception when unique_violation ... retry`
+# handler (or stop it catching unique_violation) → rb no longer completes cleanly; the trace
+# shows `ERROR:  duplicate key value violates unique constraint "claims_active_resource_unique"`
+# and the golden diverges. Both sessions run as service_role (renew's ownership check is bypassed
+# for the operator carve-out; canonicalization is actor-independent).
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, handle, display_name, status)
+  values ('c1a70000-0000-4000-8000-000000000001', 'agent', 'ck-race-agent', 'CK Race Agent', 'active');
+  insert into agent_board.claims(agent_id, resource_kind, resource_key, lease_token, lease_expires_at) values
+    ('c1a70000-0000-4000-8000-000000000001', 'machine', 'machine:fpRace',
+     '00000000-0000-4000-8000-0000000000c1', now() + interval '1 hour'),
+    ('c1a70000-0000-4000-8000-000000000001', 'machine', '  fpRace  ',
+     '00000000-0000-4000-8000-0000000000c2', now() + interval '1 hour');
+}
+
+teardown
+{
+  delete from agent_board.claims where agent_id = 'c1a70000-0000-4000-8000-000000000001';
+  delete from agent_board.agents where id = 'c1a70000-0000-4000-8000-000000000001';
+}
+
+# ra renews the 'machine:fpRace' row -> canonical 'fpRace' is free at its snapshot, so it takes
+# the slot and holds the uncommitted index entry.
+session "ra"
+step "ra_begin"  { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "ra_renew"  {
+  select resource_key
+    from agent_board.renew_claim('00000000-0000-4000-8000-0000000000c1', now() + interval '2 hours');
+}
+step "ra_commit" { COMMIT; }
+
+# rb renews the '  fpRace  ' row -> canonicalizes to the SAME 'fpRace'; its UPDATE blocks on ra's
+# index entry, then on ra commit hits unique_violation and the handler retries keeping '  fpRace  '.
+session "rb"
+step "rb_begin"  { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "rb_renew"  {
+  select resource_key
+    from agent_board.renew_claim('00000000-0000-4000-8000-0000000000c2', now() + interval '2 hours');
+}
+step "rb_commit" { COMMIT; }
+
+# checker: both leases remain active; ra healed to 'fpRace', rb kept its legacy '  fpRace  '.
+session "chk"
+step "chk" {
+  select resource_key
+    from agent_board.claims
+   where lease_token in ('00000000-0000-4000-8000-0000000000c1','00000000-0000-4000-8000-0000000000c2')
+   order by resource_key;
+}
+
+permutation "ra_begin" "ra_renew" "rb_begin" "rb_renew" "ra_commit" "rb_commit" "chk"

package/tests/isolation/specs/consent_approval_lock.spec

@@ -0,0 +1,98 @@
+# message-board#115 — the consent-approval SET-lock serialises a concurrent withdrawal.
+#
+# resolve_board_request opens with an UNFILTERED, id-ordered `for update` over the
+# WHOLE (board, agent) membership set, BEFORE it reads consent or writes. That
+# breadth is load-bearing: a concurrent self-withdrawal on a DIFFERENT physical row
+# (the active one) than the pending row being resolved must serialise behind it
+# (message-board#109). A pending-only / filtered / LIMITed lock would leave the
+# active row free and reopen the race.
+#
+# WHAT THIS PINS (and, deliberately, what it does NOT): on current code a lost
+# UPDATE is independently prevented by membership_id threading (the sink acts on the
+# exact row the resolver validated), so dropping the lock does NOT corrupt the final
+# state — it changes SERIALIZATION. The observable that regresses is the BLOCK
+# itself: with the lock, the withdrawer waits; without it (dropped OR narrowed), the
+# withdrawer proceeds immediately. isolationtester records that as the presence vs
+# absence of `<waiting ...>` in the trace, and the golden diff is the signal. This is
+# exactly how Postgres's own isolation suite pins lock behaviour.
+#
+# THE SURGICAL PERMUTATION: the subject S carries a legal (active A, pending P)
+# duplicate. The approver resolves S to 'joined' — with an active row present this is
+# the Option-1 path: resolve acquires the SET-lock and returns the ACTIVE row A
+# untouched. (Post-#116 it also retires the dangling pending row P via the sink — a
+# write to P, never to A.) So resolve never WRITES A; the SET-lock is the ONLY thing
+# it does to A, isolating the lock as the single variable. The withdrawer withdraws
+# the ACTIVE row A; it blocks on the SET-lock, then applies after commit.
+#
+# Both sessions run as service_role — the SET-lock sits AFTER the actor check and is
+# actor-independent, so this needs no auth.users identity substrate; the lock trace
+# is identical to the authenticated path.
+#
+# MUTATION SIGNAL (a TRACE diff): drop the `for update` block, OR narrow it with
+# `and bm.membership_state in ('requested','invited')` — either leaves A unlocked, so
+# w_leave no longer shows `<waiting ...>` and the golden diverges. Both mutations are
+# verified in the PR.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, handle, display_name, status) values
+    ('115a0000-0000-4000-8000-000000000001', 'agent', 'iso115-owner',   'Iso115 Owner',   'active'),
+    ('115a0000-0000-4000-8000-000000000002', 'agent', 'iso115-subject', 'Iso115 Subject', 'active');
+  insert into agent_board.boards(id, slug, name, created_by_agent_id, visibility, status)
+    values ('115b0000-0000-4000-8000-000000000001', 'iso115-board', 'Iso115 Board',
+            '115a0000-0000-4000-8000-000000000001', 'private', 'active');
+  -- Legal (active, pending) duplicate for the subject: A is joined (active), P is a
+  -- separate pending request. The active-unique index permits it (only A is active).
+  insert into agent_board.board_memberships(id, board_id, agent_id, membership_state, role, created_by_agent_id) values
+    ('115c0000-0000-4000-8000-0000000000aa', '115b0000-0000-4000-8000-000000000001',
+     '115a0000-0000-4000-8000-000000000002', 'joined',    'member', '115a0000-0000-4000-8000-000000000002'),
+    ('115c0000-0000-4000-8000-0000000000bb', '115b0000-0000-4000-8000-000000000001',
+     '115a0000-0000-4000-8000-000000000002', 'requested', 'member', '115a0000-0000-4000-8000-000000000002');
+}
+
+teardown
+{
+  delete from agent_board.board_membership_events where board_id = '115b0000-0000-4000-8000-000000000001';
+  delete from agent_board.board_memberships     where board_id = '115b0000-0000-4000-8000-000000000001';
+  delete from agent_board.boards                where id       = '115b0000-0000-4000-8000-000000000001';
+  delete from agent_board.agents                where id in ('115a0000-0000-4000-8000-000000000001','115a0000-0000-4000-8000-000000000002');
+}
+
+# approver resolves the subject to 'joined'. With active row A present this is the
+# Option-1 path — it acquires the whole-set `for update` and returns A untouched
+# (retiring the dangling pending row P via the sink, but never writing A).
+session "approver"
+step "a_begin"   { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "a_resolve" {
+  select membership_state
+    from agent_board.resolve_board_request(
+      '115b0000-0000-4000-8000-000000000001',
+      '115a0000-0000-4000-8000-000000000002',
+      'joined',
+      '115a0000-0000-4000-8000-000000000001');
+}
+step "a_commit"  { COMMIT; }
+
+# withdrawer withdraws the subject's ACTIVE membership (row A). Its write blocks on
+# the approver's whole-set lock until the approver commits.
+session "withdrawer"
+step "w_begin"   { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "w_leave"   {
+  select membership_state
+    from agent_board.update_board_membership(
+      '115b0000-0000-4000-8000-000000000001',
+      '115a0000-0000-4000-8000-000000000002',
+      'left');
+}
+step "w_commit"  { COMMIT; }
+
+# checker asserts the active row landed 'left' — the withdrawal applied, serialised
+# after the approval, not overwritten.
+session "checker"
+step "chk" {
+  select membership_state
+    from agent_board.board_memberships
+   where id = '115c0000-0000-4000-8000-0000000000aa';
+}
+
+permutation "a_begin" "a_resolve" "w_begin" "w_leave" "a_commit" "w_commit" "chk"

package/tests/isolation/specs/consent_emit_actual_state.spec

@@ -0,0 +1,79 @@
+# message-board#105 — membership writers emit the ACTUAL row state, not a literal.
+#
+# bootstrap_board_owner_memberships upserts the owner membership with
+# `INSERT ... ON CONFLICT (board_id, agent_id) WHERE (active) DO UPDATE SET role='owner'`
+# and emits `RETURNING bm.membership_state` (the ACTUAL post-upsert state), NOT a
+# literal 'joined'. The ON CONFLICT branch lifts only the role, so a membership a
+# concurrent session already made 'subscribed' STAYS subscribed — and the emitted
+# ledger event must say 'subscribed', not 'joined'.
+#
+# That conflict branch is only reachable under concurrency (a single-transaction
+# pgTAP file cannot produce it): bootstrap's eligibility read must see the owner as
+# having NO active membership (so it enters the loop and attempts the INSERT), yet
+# its INSERT must collide with an active row. We force it deterministically:
+#
+#   maker holds an UNCOMMITTED 'subscribed' owner membership. Its row is invisible
+#   to boot's eligibility read (READ COMMITTED), so boot enters the loop; boot's
+#   INSERT then BLOCKS on maker's uncommitted entry in the partial active-unique
+#   index (isolationtester reports <waiting>). maker commits; boot's ON CONFLICT
+#   resolves against the now-committed 'subscribed' row and emits result_state
+#   'subscribed'.
+#
+# MUTATION SIGNAL (a VALUE diff): revert the emit to a literal 'joined' and the
+# checker step reports 'joined' instead of 'subscribed' — the golden diverges.
+#
+# bootstrap()'s output is filtered to this board and projects only the two FIXED
+# UUIDs (never the random membership_id) so the golden is deterministic.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, handle, display_name, status)
+    values ('105a0000-0000-4000-8000-000000000001', 'agent', 'iso105-owner', 'Iso105 Owner', 'active');
+  insert into agent_board.boards(id, slug, name, created_by_agent_id, visibility, status)
+    values ('105b0000-0000-4000-8000-000000000001', 'iso105-board', 'Iso105 Board',
+            '105a0000-0000-4000-8000-000000000001', 'private', 'active');
+}
+
+teardown
+{
+  delete from agent_board.board_membership_events where board_id = '105b0000-0000-4000-8000-000000000001';
+  delete from agent_board.board_memberships     where board_id = '105b0000-0000-4000-8000-000000000001';
+  delete from agent_board.boards                where id       = '105b0000-0000-4000-8000-000000000001';
+  delete from agent_board.agents                where id       = '105a0000-0000-4000-8000-000000000001';
+}
+
+# maker creates (but does not yet commit) an ACTIVE 'subscribed' owner membership.
+session "maker"
+step "m_begin"  { BEGIN; }
+step "m_sub"    {
+  insert into agent_board.board_memberships(board_id, agent_id, membership_state, role, created_by_agent_id)
+  values ('105b0000-0000-4000-8000-000000000001', '105a0000-0000-4000-8000-000000000001',
+          'subscribed', 'member', '105a0000-0000-4000-8000-000000000001');
+}
+step "m_commit" { COMMIT; }
+
+# boot runs the operator bootstrap (service_role-only). Projects only the two fixed
+# UUIDs for THIS board so the trace is deterministic.
+session "boot"
+step "b_begin"  { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "b_boot"   {
+  select board_id, owner_agent_id
+    from agent_board.bootstrap_board_owner_memberships()
+   where board_id = '105b0000-0000-4000-8000-000000000001';
+}
+step "b_commit" { COMMIT; }
+
+# checker reads the emitted ledger event: its result_state must be the ACTUAL row
+# state ('subscribed'), not the literal 'joined'.
+session "checker"
+step "chk" {
+  select result_state, event_kind, provenance
+    from agent_board.board_membership_events
+   where board_id = '105b0000-0000-4000-8000-000000000001'
+     and agent_id = '105a0000-0000-4000-8000-000000000001'
+     and event_kind = 'operator_repair'
+   order by seq desc
+   limit 1;
+}
+
+permutation "m_begin" "m_sub" "b_begin" "b_boot" "m_commit" "b_commit" "chk"

package/tests/isolation/specs/domain_reclaim_revoke_race.spec

@@ -0,0 +1,88 @@
+# #153 TOCTOU — reclaim_fleet_trust_domain serializes against a concurrent squatter
+# revoke('trust_domain'), and revoke re-checks domain ownership UNDER a row lock.
+#
+# revoke_fleet_subject's trust_domain-ownership authz check was UNLOCKED: a squatter could call
+# revoke('trust_domain', D); its ownership SELECT reads owner=squatter (passes) with no lock, then
+# its lifecycle UPDATE blocks on reclaim's `select ... for update` and — pre-fix — applies AFTER
+# reclaim commits (owner=new_owner), revoking the domain the operator just handed over (a
+# DoS-flavoured defeat of reclaim's atomicity — the exact whole-domain analogue of #150's machine
+# TOCTOU). The fix takes `select ... for update` on the owning fleet_trust_domains row BEFORE the
+# ownership check, so revoke serializes behind reclaim and the re-read sees committed ownership
+# (owner=new_owner) → the squatter's revoke is refused 42501.
+#
+# P1 — reclaim-vs-squatter-revoke (the pin). reclaim (service_role) takes the lock and holds it;
+# the squatter's authenticated revoke BLOCKS at its own FOR UPDATE (isolationtester prints
+# `<waiting ...>`), then after reclaim commits RE-READS ownership under the lock, sees owner=
+# new_owner, and RAISES `trust domain is not owned by current_agent_id()`. FINAL: owner=new_owner,
+# lifecycle=active — the reclaimed domain is NOT nuked.
+#
+# MUTATION SIGNAL: drop the trust_domain FOR UPDATE lock from revoke_fleet_subject → the squatter's
+# ownership SELECT reads the stale (pre-commit) owner=squatter and PASSES without waiting; revoke
+# then blocks at its lifecycle UPDATE, and after reclaim commits it SUCCEEDS (returns an event id)
+# and the checker shows lifecycle=revoked / owner=new_owner — the trace diverges from this golden.
+
+setup
+{
+  insert into auth.users(id) values ('b2000000-0000-4000-8000-000000000002');
+
+  insert into agent_board.agents(id, agent_type, handle, display_name, status, auth_user_id) values
+    ('a2000000-0000-4000-8000-000000000001', 'agent', 'domreclaim-iso-operator', 'Dom Reclaim Iso Operator', 'active', null),
+    ('a2000000-0000-4000-8000-000000000002', 'agent', 'domreclaim-iso-squatter', 'Dom Reclaim Iso Squatter', 'active', 'b2000000-0000-4000-8000-000000000002'),
+    ('a2000000-0000-4000-8000-000000000003', 'agent', 'domreclaim-iso-newowner', 'Dom Reclaim Iso New Owner', 'active', null);
+
+  -- An active domain owned by the squatter (the squatted domain).
+  insert into agent_board.fleet_trust_domains(id, slug, display_name, domain_kind, owner_agent_id, lifecycle_state, approved_at)
+  values ('d2000000-0000-4000-8000-000000000001', 'domreclaim-iso-domain', 'Dom Reclaim Iso Domain', 'tailnet',
+          'a2000000-0000-4000-8000-000000000002', 'active', now());
+}
+
+teardown
+{
+  delete from agent_board.fleet_revocation_events where subject_id = 'd2000000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_trust_domains where id = 'd2000000-0000-4000-8000-000000000001';
+  delete from agent_board.agents where id in (
+    'a2000000-0000-4000-8000-000000000001',
+    'a2000000-0000-4000-8000-000000000002',
+    'a2000000-0000-4000-8000-000000000003');
+  delete from auth.users where id = 'b2000000-0000-4000-8000-000000000002';
+}
+
+# ra: the operator reclaim (service_role). Its `select ... for update` locks the domain row until
+# ra commits, reassigning ownership to the new owner.
+session "ra"
+step "ra_begin"   { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "ra_reclaim" {
+  select owner_agent_id
+    from agent_board.reclaim_fleet_trust_domain(
+      'd2000000-0000-4000-8000-000000000001', 'a2000000-0000-4000-8000-000000000003',
+      'a2000000-0000-4000-8000-000000000001', 'iso operator domain reclaim');
+}
+step "ra_commit"  { COMMIT; }
+
+# rb: the squatter's revoke via the authenticated domain-owner path. With the fix it BLOCKS at its
+# own FOR UPDATE, then re-reads committed ownership and is refused 42501.
+session "rb"
+step "rb_begin"  {
+  BEGIN;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = 'b2000000-0000-4000-8000-000000000002';
+}
+step "rb_revoke" {
+  select revocation_event_id
+    from agent_board.revoke_fleet_subject(
+      'trust_domain', 'd2000000-0000-4000-8000-000000000001', 'a2000000-0000-4000-8000-000000000002',
+      'iso squatter domain revoke', jsonb_build_object('redacted', true));
+}
+step "rb_commit" { COMMIT; }
+
+# checker: final ownership + lifecycle of the contested domain.
+session "chk"
+step "chk" {
+  select owner_agent_id, lifecycle_state
+    from agent_board.fleet_trust_domains
+   where id = 'd2000000-0000-4000-8000-000000000001';
+}
+
+# P1: reclaim holds the lock; the squatter's revoke blocks then is refused → domain stays active
+# under the new owner (the revoke is NOT applied).
+permutation "ra_begin" "ra_reclaim" "rb_begin" "rb_revoke" "ra_commit" "rb_commit" "chk"

package/tests/isolation/specs/enroll_identity_board_owner_lock_order.spec

@@ -0,0 +1,117 @@
+# Consiliency/message-board#194 — enroll_federated_identity is the THIRD federated
+# write route and the one that inverted board/owner order. It was a session in NO
+# lock-order spec, which is why the cycle shipped: atomic_fedsession_fleet_lock_order
+# pairs enroll_federated_human against onboard_federated_fleet_agent only.
+#
+# WHAT IS ASSERTED, AND WHY IT IS NOT THE DEADLOCK ITSELF.
+# The invariant is an ORDER: this route must hold the invite's board BEFORE it takes
+# the auth.users owner lock. A guard session holds the owner row, so the enrollment
+# blocks there in BOTH the pre-fix and post-fix schema -- and a third session then
+# asks, with NOWAIT, whether the board is already held:
+#
+#   pre-fix   the board is FREE while the enrollment waits on the owner
+#             -> `bprobe_board_nowait` SUCCEEDS and returns the row
+#   post-fix  the enrollment already holds the board FOR UPDATE
+#             -> it fails with 55P03 could not obtain lock on relation "boards"
+#
+# The `check` row is IDENTICAL in both runs (the enrollment completes and redeems
+# once the guard commits). Do not read that as "no difference": the entire golden
+# diff is the bprobe step, and that step IS the ordering claim.
+#
+# WHY NOT DRIVE THE ABBA DIRECTLY. A permutation pairing this route against
+# enroll_federated_human does reproduce the real cycle -- measured on the pre-fix
+# schema: pg_stat_database.deadlocks = 1, and with ONLY the class-40 re-raise applied
+# the victim surfaces `ERROR: deadlock detected`. But as shipped, the victim SWALLOWED
+# 40P01, returned success with invite_redeemed=f and no membership, and held the owner
+# row to commit -- so the counterpart session waited on it indefinitely and the
+# permutation had to be interrupted. An unbounded hang is not a failing test; it is
+# indistinguishable from an environment fault, and this runner has no per-spec
+# timeout. The shape below terminates in both schemas and discriminates in both.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status)
+  values ('194b0000-0000-0000-0000-000000000001', 'agent', 'agent',
+          'lo194-iso-owner', 'LO194 Iso Owner', 'active');
+
+  select count(*) from agent_board.create_board(
+    '194b0000-0000-0000-0000-000000000001',
+    'lo194-iso-board', 'LO194 Iso Board',
+    'Consiliency/message-board#194 enroll lock-order proof',
+    jsonb_build_object(), 'private'
+  );
+
+  insert into agent_board.identity_providers(
+    issuer, audience, supported, policy_approved,
+    allowed_scopes, allowed_board_scopes, allowed_agent_kinds
+  ) values (
+    'https://lo194-iso.test', 'message-board', true, true,
+    ARRAY[]::text[], ARRAY[]::text[], ARRAY['agent','human']
+  );
+
+  insert into agent_board.board_invite_tokens(
+    code, board_id, preset_role, preset_membership_state, max_uses,
+    expires_at, created_by_agent_id)
+  select 'lo194-iso-code', b.id, 'member', 'joined', 10,
+         now() + interval '1 hour', '194b0000-0000-0000-0000-000000000001'
+    from agent_board.boards b
+   where b.slug = 'lo194-iso-board';
+
+  -- Materialize the owner auth.users row the enrollment will derive, so the guard
+  -- holds the SAME row (a race to INSERT it would block on the unique index, not on
+  -- the lock order under test).
+  create table lo194_owner as
+  select agent_board._ensure_agent_auth_user(
+    'fed-human-' || substr(
+      encode(extensions.digest(
+        convert_to('https://lo194-iso.test' || '|' || 'iso-human', 'UTF8'), 'sha256'), 'hex'),
+      1, 32)) as uid;
+}
+
+# Holds the human owner row, so the enrollment parks on it in either schema.
+session "ohold"
+step "ohold_begin" { BEGIN; }
+step "ohold_lock" {
+  select 1 as locked from auth.users u
+   where u.id = (select uid from lo194_owner)
+   for update;
+}
+step "ohold_commit" { COMMIT; }
+
+session "enroll"
+step "enroll_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "enroll_enroll" {
+  select agent_handle, invite_redeemed
+    from agent_board.enroll_federated_identity(
+      'https://lo194-iso.test', 'message-board', 'iso-human',
+      jsonb_build_object('iss','https://lo194-iso.test','aud','message-board','sub','iso-human'),
+      'lo194-iso-agent',
+      public.test_pubkey('lo194-iso-k1'), 'raw_ed25519_base64url',
+      public.test_key_fingerprint('lo194-iso-k1'),
+      true, null, 'agent', ARRAY[]::text[], ARRAY[]::text[],
+      'lo194-iso-code'
+    );
+}
+step "enroll_commit" { COMMIT; }
+
+# THE ORDERING ASSERTION. One unwrapped statement, so whatever lock it takes is
+# released the instant it returns and no other session can ever wait on it.
+session "bprobe"
+step "bprobe_board_nowait" {
+  select slug from agent_board.boards where slug='lo194-iso-board' for update nowait;
+}
+
+session "check"
+step "check" {
+  select
+    (select count(*) from agent_board.board_memberships m
+      join agent_board.agents a on a.id = m.agent_id
+     where m.board_id = (select id from agent_board.boards where slug='lo194-iso-board')
+       and a.handle = 'lo194-iso-agent'
+       and m.membership_state = 'joined') as enrolled_agent_memberships,
+    (select count(*) from agent_board.board_invite_redemptions r
+      join agent_board.board_invite_tokens t on t.id = r.invite_id
+     where t.code = 'lo194-iso-code') as redemptions;
+}
+
+permutation "ohold_begin" "ohold_lock" "enroll_begin" "enroll_enroll" "bprobe_board_nowait" "ohold_commit" "enroll_commit" "check"