@consiliency/agent-board-schema 1.48.0 → 1.50.0

package/tests/isolation/specs/claimpolicy_isolation_refusal.spec

@@ -0,0 +1,162 @@
+# Consiliency/message-board#405 — the board policy lock REFUSES a transaction
+# that is not READ COMMITTED, rather than being silently inert in one.
+#
+# THE DEPENDENCY THIS PINS. The whole mechanism is "take the lock, then re-read
+# the policy in a NEW statement". That works because under READ COMMITTED each
+# statement takes a fresh snapshot, so the re-read sees what the writer
+# committed while we were waiting. Under REPEATABLE READ and SERIALIZABLE the
+# snapshot is fixed at first use: the wait does not advance it, the re-read
+# returns the SAME stale policy, and the lock is not a guard at all — it is a
+# delay. That failure mode is invisible; nothing errors, nothing waits
+# incorrectly, the caller simply gets the answer the race was supposed to
+# prevent.
+#
+# SO THE DECISION IS REFUSE, NOT DOCUMENT. `_claimgate_lock_board_policy` reads
+# `current_setting('transaction_isolation')` and raises 0A000 naming the level.
+# Nothing in this repository sets another level (a repo-wide search finds only
+# two prose mentions and no code), so this refuses no caller that exists — and
+# if one appears it fails loudly at its first guarded claim instead of quietly
+# banking a horizon.
+#
+# THIS CANNOT BE A pgTAP ASSERTION. `SET TRANSACTION ISOLATION LEVEL` must be a
+# transaction's first statement, and the pgTAP suite is already inside one. An
+# isolation spec is the only place the level can be chosen.
+#
+# THREE PERMUTATIONS, because a refusal that fires everywhere is a different bug
+# from one that fires nowhere:
+#
+#   1. REPEATABLE READ, ownerless claim -> REFUSED, by name.
+#   2. READ COMMITTED, same call        -> SUCCEEDS (the allow side).
+#   3. REPEATABLE READ, 'machine' kind  -> NOT refused. The guard is scoped to
+#      the ownerless region it protects; a fleet-kind acquire never resolves
+#      board policy and must not be collateral damage.
+#
+# MUTATION SIGNAL (verified in the PR): invert the comparison in
+# `_claimgate_lock_board_policy` (`= 'read committed'`) -> permutation 1 succeeds
+# and permutation 2 raises; both halves of the golden move.
+
+setup
+{
+  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 ('40500000-0000-4000-8000-0000000000d1');
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id, owner_user_id)
+  values ('40500000-0000-4000-8000-000000000004', 'agent', 'agent',
+          'cpr-iso-owner', 'CPR Isolation Owner', 'active',
+          '40500000-0000-4000-8000-0000000000d1', '40500000-0000-4000-8000-0000000000d1');
+  select count(*) from agent_board.create_board(
+    '40500000-0000-4000-8000-000000000004', 'cpr-iso-board', 'CPR Isolation Board',
+    'message-board#405 isolation-level refusal probe', jsonb_build_object(), 'private');
+  insert into agent_board.threads(id, thread_type, created_by_agent_id, subject, board_id)
+  values ('40500000-0000-4000-8000-000000000050', 'coordination',
+          '40500000-0000-4000-8000-000000000004', 'CPR isolation thread',
+          (select id from agent_board.boards where slug = 'cpr-iso-board'));
+}
+
+teardown
+{
+  delete from agent_board.claims where agent_id = '40500000-0000-4000-8000-000000000004';
+  delete from agent_board.threads where id = '40500000-0000-4000-8000-000000000050';
+  delete from agent_board.board_membership_events where board_id in (
+    select id from agent_board.boards where slug = 'cpr-iso-board');
+  delete from agent_board.board_memberships where board_id in (
+    select id from agent_board.boards where slug = 'cpr-iso-board');
+  delete from agent_board.boards where slug = 'cpr-iso-board';
+  delete from agent_board.agents where id = '40500000-0000-4000-8000-000000000004';
+  delete from auth.users where id = '40500000-0000-4000-8000-0000000000d1';
+  delete from agent_board.claimgate_enforcement_flags where scope_key = 'ownerless_guards';
+}
+
+# rr: a REPEATABLE READ caller. The lease it asks for is WITHIN the cap, so nothing else in the
+# ownerless block would reject it -- the only reason this can fail is the isolation guard.
+session "rr"
+step "rr_begin" { BEGIN ISOLATION LEVEL REPEATABLE READ; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000d1'; }
+step "rr_acq"   {
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cpr-iso-key', now() + interval '1 hour',
+                                  null, '40500000-0000-4000-8000-000000000050');
+}
+# The fleet-kind path never resolves board policy, so it never reaches the guard. A claim with no
+# thread and no board: kind 'machine' is not ownerless, so the guarded region is skipped entirely.
+step "rr_machine" {
+  select resource_key
+    from agent_board.acquire_claim(null, 'machine', 'cpr-iso-machine', now() + interval '1 hour',
+                                  null, null);
+}
+step "rr_rollback" { ROLLBACK; }
+
+# rc: the same call under the level the guard demands.
+session "rc"
+step "rc_begin" { BEGIN; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000d1'; }
+step "rc_acq"   {
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cpr-iso-key', now() + interval '1 hour',
+                                  null, '40500000-0000-4000-8000-000000000050');
+}
+step "rc_commit" { COMMIT; }
+
+# sz: SERIALIZABLE. THE LEVEL THE OLD SPEC LEFT UNPINNED, and the one that matters most. Like
+# REPEATABLE READ, a serializable transaction fixes its snapshot at first use and waiting on the
+# writer's lock does NOT advance it -- so the re-read after the lock returns the SAME stale policy
+# and the advisory lock is silently ineffective rather than failing closed. Admitting this level
+# REOPENS THE RACE this whole issue exists to close.
+#
+# WHY IT NEEDED ITS OWN PERMUTATION. The guard is `<> 'read committed'`, so one permutation under
+# REPEATABLE READ appears to cover its siblings -- but only the levels a permutation NAMES are
+# pinned. Measured: narrowing the guard to `= 'repeatable read'` kept permutation 1 passing and the
+# entire pgTAP suite green while serializable sailed through. That mutation now fails HERE by name,
+# and structurally at CPR-25a.
+session "sz"
+step "sz_begin" { BEGIN ISOLATION LEVEL SERIALIZABLE; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000d1'; }
+step "sz_acq"   {
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cpr-iso-key', now() + interval '1 hour',
+                                  null, '40500000-0000-4000-8000-000000000050');
+}
+step "sz_rollback" { ROLLBACK; }
+
+# ru: READ UNCOMMITTED. A DIFFERENT KIND OF CLAIM, and the difference is deliberate rather than an
+# oversight -- do not collapse this permutation into the one above. PostgreSQL EXECUTES read
+# uncommitted AS read committed (fresh snapshot per statement), so the lock would in fact work at
+# this level: admitting it would NOT reopen the race. What the refusal defends is the guard's
+# one-accepted-spelling CONTRACT, which the migration argues for on the grounds that a guard
+# carrying an equivalence argument has to be re-argued by every reader.
+#
+# So this permutation pins a CONTRACT regression, not a correctness one. It is here because
+# `current_setting('transaction_isolation')` really does report `read uncommitted` distinctly --
+# the GUC preserves the requested spelling even though the engine does not distinguish the
+# behaviour -- which is the only reason a `<> 'read committed'` guard can see it at all.
+session "ru"
+step "ru_begin" { BEGIN ISOLATION LEVEL READ UNCOMMITTED; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000d1'; }
+step "ru_acq"   {
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cpr-iso-key', now() + interval '1 hour',
+                                  null, '40500000-0000-4000-8000-000000000050');
+}
+step "ru_rollback" { ROLLBACK; }
+
+session "chk"
+step "chk" {
+  select coalesce(string_agg(resource_key, ',' order by resource_key), '<none>') as claims
+    from agent_board.claims
+   where agent_id = '40500000-0000-4000-8000-000000000004'
+     and status = 'active' and released_at is null;
+}
+
+# 1. REPEATABLE READ is refused by name, and nothing is written.
+permutation "rr_begin" "rr_acq" "rr_rollback" "chk"
+
+# 2. THE ALLOW SIDE: the identical call under READ COMMITTED succeeds.
+permutation "rc_begin" "rc_acq" "rc_commit" "chk"
+
+# 3. SCOPE: a fleet-kind acquire under REPEATABLE READ never resolves board policy, so it is not
+# refused. A guard that raised on entry to acquire_claim would fail here.
+permutation "rr_begin" "rr_machine" "rr_rollback" "chk"
+
+# 4. SERIALIZABLE is refused by name, and nothing is written. The race-reopening level.
+permutation "sz_begin" "sz_acq" "sz_rollback" "chk"
+
+# 5. READ UNCOMMITTED is refused by name too -- the contract half. PostgreSQL runs this level AS
+# read committed, so this permutation pins the guard's single-accepted-spelling rule rather than a
+# correctness property; see session "ru" for why the two are not the same claim.
+permutation "ru_begin" "ru_acq" "ru_rollback" "chk"

package/tests/isolation/specs/claimpolicy_renew_revert_race.spec

@@ -0,0 +1,150 @@
+# Consiliency/message-board#405 — a renew whose snapshot predates a committed
+# advisory -> inherit revert must neither resolve the stale policy NOR hand back
+# the horizon the revert just clamped.
+#
+# THIS IS #406's OWN RECORDED LIMITATION 3, closed. That header says: "a
+# renew_claim whose snapshot predates the revert's commit resolves 'advisory'
+# and, under READ COMMITTED, re-evaluates and applies its full horizon AFTER
+# this function's row lock is released at commit ... Recorded as open rather
+# than quietly excluded from the claim."
+#
+# TWO INDEPENDENT PROPERTIES, AND THE SECOND IS THE ONE THAT IS EASY TO GET
+# WRONG.
+#
+#   (1) THE POLICY RE-READ. Without the board lock, r resolves 'advisory', skips
+#       the #373 TTL cap and the #388 convergence clamp, and writes the full
+#       400-day horizon after the revert has committed. `over_cap_lease` reads
+#       that out directly.
+#
+#   (2) THE CLAIM-STATE REVALIDATION. Re-reading only the POLICY moves the race
+#       instead of closing it, because the writer this waits on is
+#       set_board_claim_policy and since #400 that same call CLAMPS this board's
+#       ownerless leases on the revert. The row r read BEFORE the wait is
+#       exactly the row w changed DURING it, and `v_current_expires` — the
+#       baseline the convergence clamp least()s against — would still hold the
+#       pre-clamp horizon. w records the clamped lease in `cpr_renew_mark` while
+#       still uncommitted, and the checker asserts the renew left it EXACTLY
+#       there.
+#
+# WHY THE SECOND SIGNAL IS AN EQUALITY AND NOT A MAGNITUDE. `now()` is
+# transaction time. The reset writes w's `now() + 30 days`; the TTL cap computes
+# r's `now() + 30 days`, and r's transaction starts later, so a stale baseline
+# lets `least()` pick r's clock instead of w's and the lease creeps forward by
+# the gap between the two BEGINs. That gap is real but small, so the checker
+# scores `lease_expires_at = the recorded value` rather than a duration — a
+# boolean is deterministic where a difference of milliseconds is not. The
+# honest reading of that: this property's blast radius is one inter-transaction
+# gap per revert, not a full horizon. Property (1) is the large one; (2) is
+# pinned because "re-read the policy" and "revalidate the claim" are different
+# fixes and only one of them is complete.
+#
+# THE AGENT IS DELIBERATELY OVER QUOTA (quota + 1 active ownerless claims), because
+# the convergence clamp is the only consumer of `v_current_expires`. With the agent
+# at or under the ceiling that clamp never runs and signal (2) cannot exist.
+# The 50 filler claims carry NO thread, so #400's board-scoped reset does not touch
+# them (BCP-14) and the only claim whose lease moves is the one under test.
+#
+# MUTATION SIGNALS, MEASURED — and the first one is not what it was predicted to be:
+#   * delete `perform agent_board._claimgate_lock_board_policy(v_board_id)` from
+#     renew_claim -> over_cap_lease = t, lease_kept_by_revert = f. THE `<waiting ...>`
+#     LINE DOES NOT MOVE. Without the board lock the renew still blocks — later, on the
+#     claims ROW lock #400's cap reset is holding — but it has already resolved the stale
+#     'advisory' by then. A probe that scored the wait rather than the outcome would have
+#     passed this mutation clean, which is why the checker reports state and not timing.
+#   * delete the REVALIDATION select (keeping the lock and the policy re-read)
+#     -> over_cap_lease stays f, lease_kept_by_revert = f. Caught 10 times out of 10, so
+#     the inter-transaction gap this reads out is small but reliably nonzero.
+#
+# THE TWIN: the same renew with no revert at all. The board is advisory, so the
+# opt-out must still work and the 400-day renew must be GRANTED. A guard that
+# over-serialises, or one that resolved every board to 'inherit', passes the race
+# permutation and fails here.
+
+setup
+{
+  insert into agent_board.claimgate_enforcement_flags(scope_key, enabled) values ('ownerless_guards', true)
+    on conflict (scope_key) do update set enabled = true;
+  create table if not exists public.cpr_renew_mark(lease timestamptz);
+  grant select, insert on public.cpr_renew_mark to authenticated;
+  delete from public.cpr_renew_mark;
+  insert into auth.users (id) values ('40500000-0000-4000-8000-0000000000b1');
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id, owner_user_id)
+  values ('40500000-0000-4000-8000-000000000002', 'agent', 'agent',
+          'cpr-ren-owner', 'CPR Renew Owner', 'active',
+          '40500000-0000-4000-8000-0000000000b1', '40500000-0000-4000-8000-0000000000b1');
+  select count(*) from agent_board.create_board(
+    '40500000-0000-4000-8000-000000000002',
+    'cpr-ren-board', 'CPR Renew Board',
+    'message-board#405 renew stale-policy probe', jsonb_build_object(), 'private');
+  insert into agent_board.threads(id, thread_type, created_by_agent_id, subject, board_id)
+  values ('40500000-0000-4000-8000-000000000020', 'coordination',
+          '40500000-0000-4000-8000-000000000002', 'CPR renew thread',
+          (select id from agent_board.boards where slug = 'cpr-ren-board'));
+  update agent_board.boards set claim_policy = 'advisory' where slug = 'cpr-ren-board';
+  -- The claim under test: on the board, holding a horizon only the opt-out could have granted.
+  insert into agent_board.claims(id, agent_id, thread_id, resource_kind, resource_key, lease_token, lease_expires_at)
+  values ('40500000-0000-4000-8000-000000000030', '40500000-0000-4000-8000-000000000002',
+          '40500000-0000-4000-8000-000000000020', 'file', 'cpr-ren-key',
+          '40500000-0000-4000-8000-0000000000f1', now() + interval '400 days');
+  -- Filler that puts the holder OVER quota so the convergence clamp runs. No thread, so the
+  -- board-scoped reset leaves them alone and the only moving lease is the one under test.
+  insert into agent_board.claims(agent_id, resource_kind, resource_key, lease_expires_at)
+  select '40500000-0000-4000-8000-000000000002', 'file', 'cpr-ren-filler-' || g, now() + interval '1 hour'
+    from generate_series(1, agent_board._claimgate_ownerless_quota()) g;
+}
+
+teardown
+{
+  delete from agent_board.claims where agent_id = '40500000-0000-4000-8000-000000000002';
+  delete from agent_board.threads where id = '40500000-0000-4000-8000-000000000020';
+  delete from agent_board.board_membership_events where board_id in (
+    select id from agent_board.boards where slug = 'cpr-ren-board');
+  delete from agent_board.board_memberships where board_id in (
+    select id from agent_board.boards where slug = 'cpr-ren-board');
+  delete from agent_board.boards where slug = 'cpr-ren-board';
+  delete from agent_board.agents where id = '40500000-0000-4000-8000-000000000002';
+  delete from auth.users where id = '40500000-0000-4000-8000-0000000000b1';
+  delete from agent_board.claimgate_enforcement_flags where scope_key = 'ownerless_guards';
+  drop table if exists public.cpr_renew_mark;
+}
+
+# w: the owner reverting the opt-out. w_mark records what #400's reset actually wrote, from inside
+# the still-uncommitted transaction — the value the renew must not move.
+session "w"
+step "w_begin"  { BEGIN; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000b1'; }
+step "w_flip"   {
+  select claim_policy
+    from agent_board.set_board_claim_policy(
+           (select id from agent_board.boards where slug = 'cpr-ren-board'), 'inherit');
+}
+step "w_mark"   {
+  insert into public.cpr_renew_mark(lease)
+  select lease_expires_at from agent_board.claims where id = '40500000-0000-4000-8000-000000000030';
+}
+step "w_commit" { COMMIT; }
+
+# r: the in-flight renew, asking for the full horizon again.
+session "r"
+step "r_begin"  { BEGIN; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000b1'; }
+step "r_renew"  {
+  select resource_key
+    from agent_board.renew_claim('40500000-0000-4000-8000-0000000000f1', now() + interval '400 days');
+}
+step "r_commit" { COMMIT; }
+
+# checker: booleans only. `lease_kept_by_revert` is null in the twin (nothing was marked), which is
+# itself part of the golden.
+session "chk"
+step "chk" {
+  select (c.lease_expires_at > now() + interval '31 days') as over_cap_lease,
+         (c.lease_expires_at = (select m.lease from public.cpr_renew_mark m)) as lease_kept_by_revert
+    from agent_board.claims c
+   where c.id = '40500000-0000-4000-8000-000000000030';
+}
+
+# THE RACE: the renew is issued while the revert is uncommitted.
+permutation "w_begin" "w_flip" "w_mark" "r_begin" "r_renew" "w_commit" "r_commit" "chk"
+
+# THE TWIN: no revert. The board is advisory, the opt-out still works, the 400-day renew is granted
+# and nothing waits.
+permutation "r_begin" "r_renew" "r_commit" "chk"

package/tests/isolation/specs/claimpolicy_writer_keyshare.spec

@@ -0,0 +1,107 @@
+# Consiliency/message-board#405 — the WRITER-SIDE lock-order question, MEASURED
+# rather than argued (PR #397's standard).
+#
+# THE SHAPE OF THE CYCLE THAT WOULD EXIST. `set_board_claim_policy` now takes the
+# board policy advisory lock and THEN wants a row lock on `agent_board.boards`.
+# Any transaction that references that board row -- inserting a thread, a
+# membership, an invite, an inbox item: twelve tables carry an FK to `boards` --
+# holds `FOR KEY SHARE` on it, and if that same transaction then enters an
+# ownerless claim path it wants the advisory lock. advisory -> row versus row ->
+# advisory is a cycle, and #159 is open on lock ordering in this schema, so this
+# is exactly the class that has already produced a revert here (ab38805, a 40P01
+# on a comparable path).
+#
+# WHY IT IS NOT A CYCLE, AND WHY THAT IS AN OBSERVATION AND NOT A CLAIM. #400
+# reads the outgoing policy `for no key update`, which does NOT conflict with
+# `FOR KEY SHARE` -- so the writer never waits on the FK holder, and the wait
+# graph has one edge, not two. This spec drives the arrangement and records that
+# the writer COMPLETES: `t` holds KEY SHARE on the board row, `w` flips the
+# policy anyway, `t`'s acquire then queues on `w`'s advisory lock and proceeds
+# once `w` commits.
+#
+# THE PROBE IS DISCRIMINATING, which is the part that makes it evidence.
+# MUTATION SIGNAL (verified in the PR): change `for no key update` to
+# `for update` in set_board_claim_policy -> `w_flip` prints `<waiting ...>` on
+# t's KEY SHARE, `t_acq` then queues on w's advisory lock, and PostgreSQL
+# reports `ERROR: deadlock detected` (40P01). The same permutation, the same
+# fixture, one lock mode apart. CPR-10 pins the source spelling so the two fail
+# together.
+#
+# THE LEASE IS DELIBERATELY WITHIN THE CAP. This spec is about the wait graph,
+# not about which policy won: the acquire must succeed under either answer, so
+# any diff in the golden is a lock-order diff.
+
+setup
+{
+  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 ('40500000-0000-4000-8000-0000000000e1');
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id, owner_user_id)
+  values ('40500000-0000-4000-8000-000000000005', 'agent', 'agent',
+          'cpr-ks-owner', 'CPR KeyShare Owner', 'active',
+          '40500000-0000-4000-8000-0000000000e1', '40500000-0000-4000-8000-0000000000e1');
+  select count(*) from agent_board.create_board(
+    '40500000-0000-4000-8000-000000000005', 'cpr-ks-board', 'CPR KeyShare Board',
+    'message-board#405 writer-side KEY SHARE lock-order probe', jsonb_build_object(), 'private');
+  insert into agent_board.threads(id, thread_type, created_by_agent_id, subject, board_id)
+  values ('40500000-0000-4000-8000-000000000060', 'coordination',
+          '40500000-0000-4000-8000-000000000005', 'CPR keyshare thread',
+          (select id from agent_board.boards where slug = 'cpr-ks-board'));
+  update agent_board.boards set claim_policy = 'advisory' where slug = 'cpr-ks-board';
+}
+
+teardown
+{
+  delete from agent_board.claims where agent_id = '40500000-0000-4000-8000-000000000005';
+  delete from agent_board.threads where id = '40500000-0000-4000-8000-000000000060';
+  delete from agent_board.board_membership_events where board_id in (
+    select id from agent_board.boards where slug = 'cpr-ks-board');
+  delete from agent_board.board_memberships where board_id in (
+    select id from agent_board.boards where slug = 'cpr-ks-board');
+  delete from agent_board.boards where slug = 'cpr-ks-board';
+  delete from agent_board.agents where id = '40500000-0000-4000-8000-000000000005';
+  delete from auth.users where id = '40500000-0000-4000-8000-0000000000e1';
+  delete from agent_board.claimgate_enforcement_flags where scope_key = 'ownerless_guards';
+}
+
+# t: the FK holder. `for key share` is taken directly rather than by inserting a referencing row,
+# because it is EXACTLY the lock mode an FK reference takes and it names the board without dragging
+# a second RPC's own locking into the probe. Taken as the connecting role (not `authenticated`,
+# which holds no UPDATE on boards and so cannot take a row lock at all); the acquire that follows
+# drops into `authenticated`, which is the role the ownerless guards actually run for.
+session "t"
+step "t_begin"    { BEGIN; }
+step "t_keyshare" { select slug from agent_board.boards where slug = 'cpr-ks-board' for key share; }
+step "t_acq"      {
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000e1';
+  select resource_key
+    from agent_board.acquire_claim(null, 'file', 'cpr-ks-key', now() + interval '1 hour',
+                                  null, '40500000-0000-4000-8000-000000000060');
+}
+step "t_commit"   { COMMIT; }
+
+# w: the policy flip. Takes the advisory lock, then the `for no key update` row lock on the very
+# row t is holding KEY SHARE on.
+session "w"
+step "w_begin"  { BEGIN; SET LOCAL ROLE authenticated; SET LOCAL "request.jwt.claim.role" = 'authenticated'; SET LOCAL "request.jwt.claim.sub" = '40500000-0000-4000-8000-0000000000e1'; }
+step "w_flip"   {
+  select claim_policy
+    from agent_board.set_board_claim_policy(
+           (select id from agent_board.boards where slug = 'cpr-ks-board'), 'inherit');
+}
+step "w_commit" { COMMIT; }
+
+session "chk"
+step "chk" {
+  select coalesce(string_agg(resource_key, ',' order by resource_key), '<none>') as claims,
+         (select claim_policy from agent_board.boards where slug = 'cpr-ks-board') as policy
+    from agent_board.claims
+   where agent_id = '40500000-0000-4000-8000-000000000005'
+     and status = 'active' and released_at is null;
+}
+
+# KEY SHARE held, then the flip, then the acquire. With `for no key update` the writer does not
+# queue behind the FK holder, so there is exactly one wait edge and no cycle.
+permutation "t_begin" "t_keyshare" "w_begin" "w_flip" "t_acq" "w_commit" "t_commit" "chk"

package/tests/seeds/20261001000100_agent_board_claimpolicy_lock_grant_revoke.sql.pre.sql

@@ -0,0 +1,99 @@
+-- Consiliency/message-board#405 — the ADVERSARIAL PRE-STATE for 20261001000100.
+--
+-- WHAT THIS GATES, and why an assertion could not. CPR-22 checks the lock helper's final ACL in the
+-- ordinary fixture — where there is no delegated grant — so it stays GREEN if the migration's
+-- `CASCADE` were removed or its sweep narrowed back to a list of known roles. The migration's
+-- claimed behaviour is about a state the fixture never contains, so the fixture has to contain it.
+--
+-- THE STATE: `service_role` holds EXECUTE **WITH GRANT OPTION** and has granted it onward to
+-- `anon`. That is the adopter shape the migration exists to survive: a plain `REVOKE` defaults to
+-- RESTRICT and fails `dependent privileges exist` against it, which on an adopter database is a
+-- FAILED UPGRADE rather than a tidier ACL. Measured against this bundle: the plain form errors, the
+-- shipped form exits 0 and leaves `{postgres=X/postgres}`.
+--
+-- HOW THE GATE READS. This runs BEFORE 20261001000100 (the runner's tests/seeds/<migration>.pre.sql
+-- hook, #103). Afterwards, either
+--   * the migration swept the chain and CPR-22 reports an empty ACL — the claim holds; or
+--   * the migration RAISED, and the whole bundle replay fails loudly at this migration.
+-- There is no third outcome in which a narrowed sweep passes quietly.
+--
+-- ONLY PRE-EXISTING ROLES ARE USED — no CREATE ROLE. Roles are cluster-global, so a seed that
+-- created them would leak them into a shared cluster and could collide with a concurrent run;
+-- service_role and anon are part of the adopter base this bundle already assumes.
+--
+-- WHAT THIS FIXTURE GATES, precisely — and the second clause is NARROWER than an earlier version of
+-- this paragraph claimed. It gates that the sweep CASCADEs, and that it reaches a grantee OUTSIDE
+-- THE HISTORICAL HAND LIST (public/anon/authenticated/service_role). It does NOT gate that the
+-- sweep is catalog-DERIVED: a migration hard-coded to those four PLUS `authenticator` clears this
+-- fixture and its guard below. A fixture names specific roles by construction, so only a randomly
+-- generated grantee defeats any hand list.
+--
+-- A DISPOSABLE RANDOM GRANTEE WAS CONSIDERED AND REJECTED, checked rather than reasoned about. The
+-- runner has a `.pre.sql` hook and no post hook, so a role created here is never dropped; a seed
+-- that swept `mb_seed405_%` at its start to compensate would be dropping roles belonging to any
+-- CONCURRENT run on the same cluster, and this cluster is shared. Trading a stated gap for
+-- cross-run interference is the worse deal. Derivation itself stays mutation-verified: narrowing
+-- the sweep to known roles was injected and CPR-22 named the survivor.
+--
+-- WHAT IT DOES NOT GATE: that the sweep derives its SIGNATURES. That needs a pre-existing overload,
+-- and a seeded overload PERSISTS — the runner has a `.pre.sql` hook and no post hook, so nothing
+-- drops it, and tests/catalog/p_metadata_parameters.json enumerates every agent_board signature and
+-- would go red. Checked rather than assumed. So a migration narrowed back to the `(uuid)` signature
+-- stays green here; that half is mutation-verified only, and this paragraph is the record of it
+-- rather than a silence someone has to rediscover.
+
+do $$
+begin
+  -- Idempotent: a re-replay onto a database that already carries the chain must not fail here, or
+  -- the seed becomes a worse failure mode than the one it tests for.
+  if not exists (select 1 from pg_roles where rolname = 'service_role')
+     or not exists (select 1 from pg_roles where rolname = 'anon') then
+    raise exception
+      'claimpolicy lock-grant seed: service_role/anon absent — the adopter base this bundle assumes is not present'
+      using errcode = '42704';
+  end if;
+
+  -- A GRANTEE OUTSIDE THE FOUR NAMES THE OLD HAND LIST USED. Without this the fixture gates only
+  -- "CASCADE is present": a migration hard-coded to revoke public/anon/authenticated/service_role
+  -- with CASCADE would sweep the chain below, pass, and still abandon every arbitrary adopter
+  -- grantee — which is the entire reason the sweep was made catalog-derived. `authenticator` is
+  -- outside that list and is part of the Supabase adopter base, so nothing has to be created:
+  -- a role invented here would linger cluster-wide, since a seed has no post hook to drop it.
+  execute 'grant execute on function agent_board._claimgate_lock_board_policy(uuid) to authenticator';
+
+  execute 'grant execute on function agent_board._claimgate_lock_board_policy(uuid) to service_role with grant option';
+end $$;
+
+-- The onward grant must be made BY service_role, so the dependency really exists.
+--
+-- `SET ROLE`, NOT `SET LOCAL ROLE`, and that distinction is the whole gate. The runner applies this
+-- file with `psql -f` in AUTOCOMMIT, so every statement is its own implicit transaction and a
+-- `SET LOCAL` is discarded before the next one runs. The first version used SET LOCAL: the grant was
+-- then made by `postgres`, recorded as `anon=X/postgres` with no dependency on service_role's grant,
+-- and a plain RESTRICT revoke would have swept it happily — a gate that passed whether or not the
+-- migration cascaded. The check below caught exactly that, which is why it is here.
+set role service_role;
+grant execute on function agent_board._claimgate_lock_board_policy(uuid) to anon;
+reset role;
+
+-- Proof the pre-state is what this file claims, checked rather than assumed: if the chain did not
+-- form, the migration would sweep a state no harder than the ordinary one and the gate would be
+-- vacuous — green for the wrong reason, which is the failure mode this whole effort keeps finding.
+do $$
+declare v_acl text;
+begin
+  select coalesce(proacl::text, '<null>') into v_acl
+    from pg_proc where oid = to_regprocedure('agent_board._claimgate_lock_board_policy(uuid)');
+  if v_acl not like '%anon=X/service_role%' then
+    raise exception
+      'claimpolicy lock-grant seed: the delegated grant did not form (acl=%) — refusing to leave a VACUOUS gate that would pass whether or not the migration cascades',
+      v_acl
+      using errcode = '55000';
+  end if;
+  if v_acl not like '%authenticator=%' then
+    raise exception
+      'claimpolicy lock-grant seed: the out-of-list grantee did not take (acl=%) — without it this fixture gates only CASCADE, and a migration narrowed to the four historical role names would pass',
+      v_acl
+      using errcode = '55000';
+  end if;
+end $$;