@consiliency/agent-board-schema 1.45.0 → 1.50.0

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/isolation/specs/fleet_domain_no_downgrade_demote_race.spec

@@ -0,0 +1,292 @@
+# #397 — register_fleet_machine's no-downgrade guard (#395) against a destination DEMOTED while
+# the move waits.
+#
+# THE WINDOW. The guard's rank comparison is a conjunct of the ON CONFLICT DO UPDATE's WHERE, so
+# it is atomic against the conflicting MACHINE row. The DESTINATION domain's lifecycle is not:
+# pinning it needs a row lock on fleet_trust_domains, which was added to this function once
+# (PR #158, ab38805) and REVERTED for deadlocking 40P01 against reclaim_fleet_machine — #159 owns
+# the lock order and is open. So a `service_role` demotion of the destination can commit while the
+# upsert is blocked on the machine row, and the machine lands in a domain that is 'pending' at
+# commit time, still 'active' itself, with its fleet_machine_agents bindings intact (they key on
+# machine_id) — #395 again, under concurrency.
+#
+# WHAT WAS MEASURED, and why the obvious repair is not the one shipped. Moving the destination
+# read INTO the upsert as a correlated subquery does NOT close this: under READ COMMITTED an
+# upsert that waits on the conflicting row re-reads THAT ROW's latest version on resume but
+# evaluates every other relation against the statement's ORIGINAL snapshot, so the domain is still
+# read as of before the wait. Both the cached read and the correlated subquery were run against
+# this interleaving and both allowed the move. What closes it is a re-check of the destination in
+# a SEPARATE statement after the move — a fresh snapshot — which raises 42501 and unwinds it.
+#
+# P1 — the pin. rl locks the machine row and holds it; rm's register BLOCKS (isolationtester
+# prints `<waiting ...>`); rl then demotes the destination to 'pending' and commits; rm resumes,
+# its upsert applies the move against the row it now locks, and the post-move re-check — a fresh
+# statement, fresh snapshot — sees 'pending' and RAISES 42501, aborting rm. FINAL: the machine is
+# still in its ORIGINAL active domain.
+#
+# P2 — the twin. The same move with NO concurrent demotion SUCCEEDS and lands. Without it, a guard
+# that refused every move would satisfy P1 and this spec would be scoring an over-refusal as a
+# fix. P2 leaves the machine in the destination domain, so it runs after P1's fixture reset (each
+# permutation re-runs setup).
+#
+# WHAT EACH PERMUTATION PINS, and the mutation that falsifies it. Every refusal case carries a twin
+# so a guard that refused everything could not pass this spec.
+#
+#   P1 / P2            destination demoted during the wait → refused; uncontended move → succeeds
+#   P3 / P3-twin       a concurrent session RELOCATES the machine, then demotes → refused;
+#                      the relocation alone → the equal-rank move succeeds
+#   P4 / P4-twin       the LOCK HOLDER relocates, then demotes → refused; relocation alone → succeeds
+#   P5 / P5-reverse    register and reclaim serialize on the machine row in both starting orders
+#                      (see the rc session for what these do NOT show)
+#   P6 / P6-promote /  the first-registration race: the loser reaches the conflict path with no row
+#   P6-control         to lock, so it is REFUSED 40001 whether the destination is demoted (P6) or the
+#                      SOURCE is promoted (P6-promote); serialized, the same two registrations
+#                      succeed (P6-control)
+#
+# MUTATION SIGNALS, all four measured:
+#   * delete the post-move comparison            → P1, P3, P4 no longer raise; the checker shows the
+#                                                  machine 'active' in a 'pending' domain
+#   * remove the pre-read's FOR UPDATE           → P3, P4 no longer raise (the stale-pre-read bypass)
+#   * delete the lost-race (40001) refusal       → P6, P6-promote no longer raise
+#   * inject the #158-shaped fleet_trust_domains
+#     FOR UPDATE into register                   → P1, P3, P4 become `ERROR: deadlock detected`.
+#     THIS is the evidence that the machine-only lock avoids ab38805's revert; P5/P5-reverse stay
+#     GREEN under that injection and were mis-cited for it in an earlier round.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, handle, display_name, status) values
+    ('a3970000-0000-4000-8000-000000000001', 'agent', 'nodowngrade-iso-owner', 'No-downgrade Iso Owner', 'active'),
+    ('a3970000-0000-4000-8000-000000000002', 'agent', 'nodowngrade-iso-operator', 'No-downgrade Iso Operator', 'active'),
+    ('a3970000-0000-4000-8000-000000000003', 'agent', 'nodowngrade-iso-newowner', 'No-downgrade Iso New Owner', 'active');
+
+  -- Two ACTIVE domains owned by that agent: the machine's current one, and the move's destination.
+  insert into agent_board.fleet_trust_domains(id, slug, display_name, domain_kind, owner_agent_id, lifecycle_state, approved_at)
+  values ('d3970000-0000-4000-8000-000000000001', 'nodowngrade-iso-current', 'No-downgrade Iso Current', 'tailnet',
+          'a3970000-0000-4000-8000-000000000001', 'active', now()),
+         ('d3970000-0000-4000-8000-000000000002', 'nodowngrade-iso-dest', 'No-downgrade Iso Destination', 'tailnet',
+          'a3970000-0000-4000-8000-000000000001', 'active', now()),
+         -- X: a third ACTIVE domain the concurrent session RELOCATES the machine into (#397 round 2).
+         ('d3970000-0000-4000-8000-000000000003', 'nodowngrade-iso-x', 'No-downgrade Iso X', 'tailnet',
+          'a3970000-0000-4000-8000-000000000001', 'active', now()),
+         -- The reclaim probe's destination: active, owned by the arbitrated NEW owner.
+         ('d3970000-0000-4000-8000-000000000004', 'nodowngrade-iso-newdom', 'No-downgrade Iso New Owner Domain', 'tailnet',
+          'a3970000-0000-4000-8000-000000000003', 'active', now()),
+         -- P6 family: the first-registration race runs between two PENDING domains, which is the
+         -- shape the source-promotion case needs (#397 round 3, finding 1).
+         ('d3970000-0000-4000-8000-000000000005', 'nodowngrade-iso-race-src', 'No-downgrade Iso Race Source', 'tailnet',
+          'a3970000-0000-4000-8000-000000000001', 'pending', null),
+         ('d3970000-0000-4000-8000-000000000006', 'nodowngrade-iso-race-dest', 'No-downgrade Iso Race Destination', 'tailnet',
+          'a3970000-0000-4000-8000-000000000001', 'pending', null);
+
+  -- The bound-shaped machine the move would relocate. Inserted directly so its id is fixed.
+  insert into agent_board.fleet_machines(id, trust_domain_id, owner_agent_id, machine_label, machine_fingerprint,
+                                         lifecycle_state, enrollment_source, enrolled_at, metadata)
+  values ('c3970000-0000-4000-8000-000000000001', 'd3970000-0000-4000-8000-000000000001',
+          'a3970000-0000-4000-8000-000000000001', 'nodowngrade-iso-machine', 'sha256:nodowngrade-iso',
+          'active', 'portal', now(), jsonb_build_object('redacted', true, 'metadata-safe', true));
+}
+
+teardown
+{
+  delete from agent_board.fleet_machines where id = 'c3970000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_machines where machine_fingerprint = 'sha256:nodowngrade-iso-fresh';
+  delete from agent_board.fleet_trust_domains where id in (
+    'd3970000-0000-4000-8000-000000000001',
+    'd3970000-0000-4000-8000-000000000002',
+    'd3970000-0000-4000-8000-000000000003',
+    'd3970000-0000-4000-8000-000000000004',
+    'd3970000-0000-4000-8000-000000000005',
+    'd3970000-0000-4000-8000-000000000006');
+  delete from agent_board.agents where id in (
+    'a3970000-0000-4000-8000-000000000001',
+    'a3970000-0000-4000-8000-000000000002',
+    'a3970000-0000-4000-8000-000000000003');
+}
+
+# rl: holds the machine row (any concurrent writer of that row will do — reclaim, revoke and
+# reactivate all take it) and demotes the destination domain before releasing it.
+session "rl"
+step "rl_begin"  { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "rl_lock"   {
+  select id from agent_board.fleet_machines
+   where id = 'c3970000-0000-4000-8000-000000000001' for update;
+}
+step "rl_demote" {
+  update agent_board.fleet_trust_domains
+     set lifecycle_state = 'pending', approved_at = null, updated_at = now()
+   where id = 'd3970000-0000-4000-8000-000000000002';
+}
+step "rl_relocate_dest" {
+  update agent_board.fleet_machines
+     set trust_domain_id = 'd3970000-0000-4000-8000-000000000002', updated_at = now()
+   where id = 'c3970000-0000-4000-8000-000000000001';
+}
+step "rl_relocate_x" {
+  update agent_board.fleet_machines
+     set trust_domain_id = 'd3970000-0000-4000-8000-000000000003', updated_at = now()
+   where id = 'c3970000-0000-4000-8000-000000000001';
+}
+step "rl_promote_race_src" {
+  update agent_board.fleet_trust_domains
+     set lifecycle_state = 'active', approved_at = now(), updated_at = now()
+   where id = 'd3970000-0000-4000-8000-000000000005';
+}
+step "rl_demote_race_dest" {
+  update agent_board.fleet_trust_domains
+     set lifecycle_state = 'quarantined', approved_at = null, updated_at = now()
+   where id = 'd3970000-0000-4000-8000-000000000006';
+}
+step "rl_demote_current" {
+  update agent_board.fleet_trust_domains
+     set lifecycle_state = 'pending', approved_at = null, updated_at = now()
+   where id = 'd3970000-0000-4000-8000-000000000001';
+}
+step "rl_commit" { COMMIT; }
+
+# rm: the owner re-registering their own fingerprint into the destination domain — the #395 move.
+session "rm"
+step "rm_begin"  { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "rm_move"   {
+  select trust_domain_id
+    from agent_board.register_fleet_machine(
+      'a3970000-0000-4000-8000-000000000001', 'd3970000-0000-4000-8000-000000000002',
+      'nodowngrade-iso-machine-moved', 'sha256:nodowngrade-iso', 'portal',
+      jsonb_build_object('redacted', true));
+}
+step "rm_move_current"   {
+  select trust_domain_id
+    from agent_board.register_fleet_machine(
+      'a3970000-0000-4000-8000-000000000001', 'd3970000-0000-4000-8000-000000000001',
+      'nodowngrade-iso-machine-relabelled', 'sha256:nodowngrade-iso', 'portal',
+      jsonb_build_object('redacted', true));
+}
+step "rm_commit" { COMMIT; }
+
+# rc: the operator reclaim. It locks the machine row and then takes an FK KEY SHARE on the
+# destination domain — machine ≺ domain, the SAME acquisition order register takes.
+#
+# WHAT P5/P5-reverse DO AND DO NOT SHOW, corrected after a review seat pointed out that the first
+# version of this comment claimed the stronger thing. They show that register and reclaim SERIALIZE
+# on the machine row in both starting orders and that neither wedges. They do NOT reproduce the
+# historical domain↔machine cycle: they target different domains, and each RPC only starts after
+# the other has RETURNED, so no session is ever mid-call holding one lock and waiting for the other.
+# Measured, not assumed: injecting the #158-shaped fleet_trust_domains FOR UPDATE leaves BOTH of
+# them green. The permutations that actually falsify that lock are P1/P3/P4 — see the header.
+session "rc"
+step "rc_begin"   { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "rc_reclaim" {
+  select owner_agent_id, trust_domain_id
+    from agent_board.reclaim_fleet_machine(
+      'c3970000-0000-4000-8000-000000000001', 'a3970000-0000-4000-8000-000000000003',
+      'a3970000-0000-4000-8000-000000000002', 'iso reclaim vs register',
+      'd3970000-0000-4000-8000-000000000004');
+}
+step "rc_commit"  { COMMIT; }
+
+# rf: the session that WINS a first-registration race on a fingerprint no row exists for yet.
+# The loser's pre-read legitimately finds nothing, so v_prior_domain is null and the skip predicate
+# has no baseline — the one conflict path the locked pre-read cannot cover.
+session "rf"
+step "rf_begin"    { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "rf_register" {
+  select trust_domain_id
+    from agent_board.register_fleet_machine(
+      'a3970000-0000-4000-8000-000000000001', 'd3970000-0000-4000-8000-000000000005',
+      'nodowngrade-iso-fresh-winner', 'sha256:nodowngrade-iso-fresh', 'portal',
+      jsonb_build_object('redacted', true));
+}
+step "rf_commit"   { COMMIT; }
+
+# rm2: the loser of that race. Its insert blocks on the unique index, then takes the CONFLICT path
+# against a row it never read.
+session "rm2"
+step "rm2_begin"    { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "rm2_register" {
+  select trust_domain_id
+    from agent_board.register_fleet_machine(
+      'a3970000-0000-4000-8000-000000000001', 'd3970000-0000-4000-8000-000000000006',
+      'nodowngrade-iso-fresh-loser', 'sha256:nodowngrade-iso-fresh', 'portal',
+      jsonb_build_object('redacted', true));
+}
+step "rm2_commit"   { COMMIT; }
+
+# checker for the raced fingerprint.
+session "chkf"
+step "chkf" {
+  select fm.trust_domain_id, fm.lifecycle_state as machine_state, ftd.lifecycle_state as domain_state
+    from agent_board.fleet_machines fm
+    join agent_board.fleet_trust_domains ftd on ftd.id = fm.trust_domain_id
+   where fm.machine_fingerprint = 'sha256:nodowngrade-iso-fresh';
+}
+
+# checker: where the machine ended up, and the lifecycle of the domain it is in.
+session "chk"
+step "chk" {
+  select fm.trust_domain_id, fm.owner_agent_id, fm.lifecycle_state as machine_state,
+         ftd.lifecycle_state as domain_state
+    from agent_board.fleet_machines fm
+    join agent_board.fleet_trust_domains ftd on ftd.id = fm.trust_domain_id
+   where fm.id = 'c3970000-0000-4000-8000-000000000001';
+}
+
+# P1: the move blocks, the destination is demoted under it, and the post-move re-check refuses.
+permutation "rl_begin" "rl_lock" "rm_begin" "rm_move" "rl_demote" "rl_commit" "rm_commit" "chk"
+
+# P2 (twin): the same move with no concurrent demotion still succeeds and lands.
+permutation "rm_begin" "rm_move" "rm_commit" "chk"
+
+# P3 (#397 round 2, case A — the concurrent session RELOCATES the machine). rl moves the machine
+# D1→D2 uncommitted; rm re-registers into D1, so rm's prior-read sees the COMMITTED D1 and records
+# v_prior_domain = D1; rl then demotes D1 and commits; rm resumes against the machine row as it now
+# is (D2) and moves it D2→D1. The destination it lands in EQUALS the stale v_prior_domain, so a
+# skip predicate built on that pre-read reads "nothing moved" and skips the fresh-snapshot check —
+# leaving an active machine in a pending domain. MUST refuse.
+permutation "rl_begin" "rl_relocate_dest" "rm_begin" "rm_move_current" "rl_demote_current" "rl_commit" "rm_commit" "chk"
+
+# P3-twin: the same relocation with NO demotion. D1 is still active, so the move back into it is a
+# legitimate equal-rank relocation and MUST succeed — an over-refusing guard fails here.
+permutation "rl_begin" "rl_relocate_dest" "rm_begin" "rm_move_current" "rl_commit" "rm_commit" "chk"
+
+# P4 (#397 round 2, case B — the LOCK HOLDER relocates). rm re-registers into the machine's OWN
+# domain D1 (a label update, so both the destination gate and the rank pass and v_prior_domain =
+# D1); rl holds the machine row, relocates it to X, demotes D1, and commits; rm resumes and the
+# upsert genuinely moves the machine X→D1, which is now pending. Same stale-predicate skip.
+# rm blocks at the UPSERT, not at the prior-read — a plain SELECT does not wait, which is why the
+# pre-read is stale rather than merely early. MUST refuse.
+permutation "rl_begin" "rl_lock" "rm_begin" "rm_move_current" "rl_relocate_x" "rl_demote_current" "rl_commit" "rm_commit" "chk"
+
+# P4-twin: the same, without the demotion — X→D1 is equal-rank and MUST succeed.
+permutation "rl_begin" "rl_lock" "rm_begin" "rm_move_current" "rl_relocate_x" "rl_commit" "rm_commit" "chk"
+
+# P5 (lock order). register's machine-row FOR UPDATE is the SAME row reclaim_fleet_machine locks,
+# and both then reach fleet_trust_domains only through the FK — machine ≺ domain in both, so no
+# cycle. Evidence, not assertion: reclaim holds the machine row, register blocks, reclaim commits,
+# register resumes and is refused by #141 (the machine now belongs to the new owner). No 40P01.
+permutation "rc_begin" "rc_reclaim" "rm_begin" "rm_move_current" "rc_commit" "rm_commit" "chk"
+
+# P5-reverse: the other acquisition order. register takes the machine row first and holds it to
+# commit; reclaim blocks and completes afterwards. Still no cycle.
+permutation "rm_begin" "rm_move_current" "rc_begin" "rc_reclaim" "rm_commit" "rc_commit" "chk"
+
+# P6 (the first-registration race — the one conflict path the locked pre-read cannot cover). Both
+# race domains are PENDING. rf first-registers the fingerprint into SRC and holds it uncommitted;
+# rm2 registers the SAME fingerprint into DEST and blocks on the unique index; DEST is demoted to
+# quarantined (rank 0, below pending) and committed while rm2 waits; rf commits; rm2 resumes onto
+# the CONFLICT path against a row it never read and never locked. There is no recoverable baseline
+# — the domain the machine was in belonged to a row we never read, and the upsert has overwritten
+# it — so this is REFUSED as a serialization failure (40001, retryable) rather than approximated.
+permutation "rf_begin" "rf_register" "rm2_begin" "rm2_register" "rl_begin" "rl_demote_race_dest" "rl_commit" "rf_commit" "rm2_commit" "chkf"
+
+# P6-promote: THE ROUND-3 PANEL'S CASE, in its own shape. Nothing is demoted — the SOURCE is
+# PROMOTED to active while both racers are in flight, so rm2 would move the machine OUT of a
+# now-active domain INTO a pending one. Round 2's fallback compared the cached destination rank
+# against itself (1 >= 1) and passed this; the refusal must come from the ABSENT BASELINE, which is
+# why it does not depend on any rank comparison at all.
+permutation "rf_begin" "rf_register" "rm2_begin" "rm2_register" "rl_begin" "rl_promote_race_src" "rl_commit" "rf_commit" "rm2_commit" "chkf"
+
+# P6-control (the twin): the SAME two registrations, SERIALIZED — rf commits before rm2 starts, so
+# rm2 has a row to lock and a real baseline. Both domains are pending, so its move is equal-rank and
+# MUST succeed and land in DEST. Without this, a guard that refused every second registration would
+# satisfy P6 and P6-promote.
+permutation "rf_begin" "rf_register" "rf_commit" "rm2_begin" "rm2_register" "rm2_commit" "chkf"

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 $$;