@consiliency/agent-board-schema 1.27.0 → 1.35.0

package/tests/isolation/expected/signer_lifecycle_revoke.out

@@ -92,7 +92,7 @@ step auth_grant:
  <waiting ...>
 step revoke_commit: COMMIT;
 step auth_grant: <... completed>
-ERROR:  signer_not_active: signed authority write signer is revoked, not active
+ERROR:  fleet_revoked: grant_board_role is not permitted for a fleet-revoked agent
 step auth_commit: COMMIT;
 step check: 
   select

package/tests/isolation/expected/task_thread_lock_order.out

@@ -0,0 +1,203 @@
+Parsed test spec with 5 sessions
+
+starting permutation: probe_begin probe_threads append_begin append_run probe_tasks probe_commit append_commit check
+step probe_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step probe_threads: 
+  select count(*)::int as locked_threads from (
+    select 1 from agent_board.threads t
+     where t.id = '7a820000-0000-4000-8000-000000000001' for update) s;
+
+locked_threads
+--------------
+             1
+(1 row)
+
+step append_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step append_run: 
+  select e.event_sequence,
+         (e.thread_id = '7a820000-0000-4000-8000-000000000001') as thread_is_task_thread
+    from agent_board.append_task_event(
+           '7a830000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'commented') e;
+ <waiting ...>
+step probe_tasks: 
+  select count(*)::int as locked_tasks from (
+    select 1 from agent_board.tasks tk
+     where tk.id = '7a830000-0000-4000-8000-000000000001' for update) s;
+
+locked_tasks
+------------
+           1
+(1 row)
+
+step probe_commit: COMMIT;
+step append_run: <... completed>
+event_sequence|thread_is_task_thread
+--------------+---------------------
+             1|t                    
+(1 row)
+
+step append_commit: COMMIT;
+step check: 
+  select (select array_agg(te.event_sequence order by te.event_sequence)
+            from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001') as event_sequences,
+         (select count(*)::int from agent_board.messages
+           where thread_id = '7a820000-0000-4000-8000-000000000001') as messages,
+         (select count(*)::int from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001'
+             and te.thread_id <> '7a820000-0000-4000-8000-000000000001') as events_on_wrong_thread;
+
+event_sequences|messages|events_on_wrong_thread
+---------------+--------+----------------------
+{1}            |       0|                     0
+(1 row)
+
+
+starting permutation: append_begin append_run post_begin post_run append_commit post_commit check
+step append_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step append_run: 
+  select e.event_sequence,
+         (e.thread_id = '7a820000-0000-4000-8000-000000000001') as thread_is_task_thread
+    from agent_board.append_task_event(
+           '7a830000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'commented') e;
+
+event_sequence|thread_is_task_thread
+--------------+---------------------
+             1|t                    
+(1 row)
+
+step post_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step post_run: 
+  select m.message_sequence,
+         (m.task_id = '7a830000-0000-4000-8000-000000000001') as task_attached
+    from agent_board.post_message(
+           '7a820000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'r1 iso body',
+           'comment',
+           '7a830000-0000-4000-8000-000000000001') m;
+ <waiting ...>
+step append_commit: COMMIT;
+step post_run: <... completed>
+message_sequence|task_attached
+----------------+-------------
+               1|t            
+(1 row)
+
+step post_commit: COMMIT;
+step check: 
+  select (select array_agg(te.event_sequence order by te.event_sequence)
+            from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001') as event_sequences,
+         (select count(*)::int from agent_board.messages
+           where thread_id = '7a820000-0000-4000-8000-000000000001') as messages,
+         (select count(*)::int from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001'
+             and te.thread_id <> '7a820000-0000-4000-8000-000000000001') as events_on_wrong_thread;
+
+event_sequences|messages|events_on_wrong_thread
+---------------+--------+----------------------
+{1}            |       1|                     0
+(1 row)
+
+
+starting permutation: post_begin post_run append_begin append_run post_commit append_commit check
+step post_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step post_run: 
+  select m.message_sequence,
+         (m.task_id = '7a830000-0000-4000-8000-000000000001') as task_attached
+    from agent_board.post_message(
+           '7a820000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'r1 iso body',
+           'comment',
+           '7a830000-0000-4000-8000-000000000001') m;
+
+message_sequence|task_attached
+----------------+-------------
+               1|t            
+(1 row)
+
+step append_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step append_run: 
+  select e.event_sequence,
+         (e.thread_id = '7a820000-0000-4000-8000-000000000001') as thread_is_task_thread
+    from agent_board.append_task_event(
+           '7a830000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'commented') e;
+ <waiting ...>
+step post_commit: COMMIT;
+step append_run: <... completed>
+event_sequence|thread_is_task_thread
+--------------+---------------------
+             1|t                    
+(1 row)
+
+step append_commit: COMMIT;
+step check: 
+  select (select array_agg(te.event_sequence order by te.event_sequence)
+            from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001') as event_sequences,
+         (select count(*)::int from agent_board.messages
+           where thread_id = '7a820000-0000-4000-8000-000000000001') as messages,
+         (select count(*)::int from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001'
+             and te.thread_id <> '7a820000-0000-4000-8000-000000000001') as events_on_wrong_thread;
+
+event_sequences|messages|events_on_wrong_thread
+---------------+--------+----------------------
+{1}            |       1|                     0
+(1 row)
+
+
+starting permutation: append_begin append_run append2_begin append2_run append_commit append2_commit check
+step append_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step append_run: 
+  select e.event_sequence,
+         (e.thread_id = '7a820000-0000-4000-8000-000000000001') as thread_is_task_thread
+    from agent_board.append_task_event(
+           '7a830000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'commented') e;
+
+event_sequence|thread_is_task_thread
+--------------+---------------------
+             1|t                    
+(1 row)
+
+step append2_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step append2_run: 
+  select e.event_sequence
+    from agent_board.append_task_event(
+           '7a830000-0000-4000-8000-000000000001',
+           '7a810000-0000-4000-8000-000000000001',
+           'status_changed') e;
+ <waiting ...>
+step append_commit: COMMIT;
+step append2_run: <... completed>
+event_sequence
+--------------
+             2
+(1 row)
+
+step append2_commit: COMMIT;
+step check: 
+  select (select array_agg(te.event_sequence order by te.event_sequence)
+            from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001') as event_sequences,
+         (select count(*)::int from agent_board.messages
+           where thread_id = '7a820000-0000-4000-8000-000000000001') as messages,
+         (select count(*)::int from agent_board.task_events te
+           where te.task_id = '7a830000-0000-4000-8000-000000000001'
+             and te.thread_id <> '7a820000-0000-4000-8000-000000000001') as events_on_wrong_thread;
+
+event_sequences|messages|events_on_wrong_thread
+---------------+--------+----------------------
+{1,2}          |       0|                     0
+(1 row)
+

package/tests/isolation/specs/enroll_identity_board_owner_lock_order.spec

@@ -60,12 +60,13 @@ setup
   -- 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).
+  -- #246: through the shared derivation helper, deliberately. The point of this row is
+  -- that it is the SAME row the enrollment will resolve to; a copied expression here
+  -- would silently stop matching the moment the derivation moved, and this spec would
+  -- go on "passing" while holding a lock on an unrelated row.
   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;
+    agent_board._federated_identity_slug('https://lo194-iso.test', 'iso-human')) as uid;
 }
 
 # Holds the human owner row, so the enrollment parks on it in either schema.

package/tests/isolation/specs/fedsession_provider_absent_owner_lock.spec

@@ -22,12 +22,12 @@
 
 setup
 {
+  -- #246: through the shared derivation helper, deliberately -- see the note in
+  -- enroll_identity_board_owner_lock_order.spec. The row must be the one the path under
+  -- test would resolve to, not a copy of an expression that can drift away from it.
   create table lo193_owner as
   select agent_board._ensure_agent_auth_user(
-    'fed-human-' || substr(
-      encode(extensions.digest(
-        convert_to('https://lo193-iso.test' || '|' || 'iso-orphan', 'UTF8'), 'sha256'), 'hex'),
-      1, 32)) as uid;
+    agent_board._federated_identity_slug('https://lo193-iso.test', 'iso-orphan')) as uid;
 }
 
 # Holds the human owner row that the absent-provider path must never reach.

package/tests/isolation/specs/ledger_authority_revoke.spec

@@ -0,0 +1,405 @@
+# Consiliency/message-board#276 — a board AUTHORITY write reads the fleet revocation ledger
+# under a share lock on the actor's agents row, so a concurrent revoke_fleet_subject('agent')
+# serializes against the write instead of racing it.
+#
+# WHY THIS CANNOT BE A pgTAP FILE. The predicate ("a ledger-revoked grantor is refused") is
+# provable in one transaction and is proved in agent_board_ledger_authority.test.sql. The
+# property THIS file exists for is not the predicate: it is that the read is LOCKED. An
+# unlocked `exists (select 1 from fleet_revocation_events ...)` passes every pgTAP assertion in
+# that file and still leaves the TOCTOU wide open — the authority write reads "not revoked", a
+# revocation commits, and the grant lands anyway. A single rolled-back transaction cannot
+# produce that interleaving. isolationtester prints `<waiting ...>` / `<... completed>` whenever
+# a step blocks, so the lock is a byte in the golden rather than a claim in a comment.
+#
+# THE ADVERSARY IS THE SHIPPED FUNCTION, not a stand-in. `revoke_fleet_subject('agent', X)`
+# (20260901000100:1062) is the exact call the issue is about: it locks the machines X is bound
+# to, then the agents row FOR UPDATE, then the bindings, then writes the agent-subject ledger
+# row. That `agents` FOR UPDATE is what the gate's FOR SHARE conflicts with, and it is the sole
+# reason the two orders below produce different outcomes.
+#
+# BOTH ROUTES ARE DRIVEN, because the whole point of siting the check inside grant_board_role
+# was that the wide `authenticated` door and the narrow signed one could not diverge:
+#   ugrant  — grant_board_role called directly by the authenticated owner. No gateway.
+#   sgrant  — signed_grant_board_role called by the service_role gateway, with a decision
+#             naming a live, owned, verified key so a refusal can only be #276's gate and
+#             never #269's signer revalidation.
+#
+# The check session also reads agents.status: it must stay 'active' throughout. If a future
+# change made fleet revocation flip the status, these permutations would still pass — but for
+# a different reason — and that column in the golden is what makes the substitution visible.
+#
+# MUTATION-VERIFIED: dropping `for share` from _assert_actor_not_fleet_revoked (leaving the
+# ledger read unlocked) changes permutations 2 and 4 — the authority write no longer waits.
+# Clean schema -> byte-identical across 10 runs.
+#
+# #280 RE-RAN THAT MUTATION and measured which of the four new permutations it moves. The result
+# is the honest form of this migration's lock claim, so it is recorded here rather than argued:
+#   * Permutations 9 and 10 (the FRESH-BOARD branch) are BYTE-IDENTICAL with the lock removed.
+#     That is expected and is the point: the owner-seat INSERT's FK already holds KEY SHARE on
+#     the actor's agents row before the gate runs, so the FK — not the FOR SHARE — is what makes
+#     that branch wait. These two permutations pin the OUTCOME (blocks, fails closed, no board
+#     and no seat) and CANNOT pin the lock. Nothing here should be read as though they do.
+#   * Permutations 11 and 12 (the SLUG-COLLISION branch) BOTH move. With the lock removed,
+#     permutation 11 stops waiting entirely and the reopen SUCCEEDS on its pre-revocation
+#     snapshot: the check row goes from `K276 ISO Board | private` to `K280 ISO REOPENED | open`
+#     — a ledger-revoked owner reopening an existing board and making it publicly visible across
+#     a committing revocation. That is the TOCTOU the FOR SHARE closes, and permutation 11 is the
+#     only place in this spec where the lock itself is discriminated.
+
+setup
+{
+  insert into auth.users (id) values
+    ('27700000-0000-0000-0000-0000000000a1'),
+    ('27700000-0000-0000-0000-0000000000a2'),
+    ('27700000-0000-0000-0000-0000000000a3');
+
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status, auth_user_id)
+  values
+    ('27710000-0000-4000-8000-000000000001','agent','agent','k276iso-owner','K276 ISO Owner','active','27700000-0000-0000-0000-0000000000a1'),
+    ('27710000-0000-4000-8000-000000000002','agent','agent','k276iso-grantee','K276 ISO Grantee','active','27700000-0000-0000-0000-0000000000a2'),
+    ('27710000-0000-4000-8000-000000000003','agent','agent','k276iso-revoker','K276 ISO Revoker','active','27700000-0000-0000-0000-0000000000a3');
+
+  insert into agent_board.boards(id, slug, name, created_by_agent_id, visibility, status)
+  values ('27720000-0000-4000-8000-000000000001','k276-iso-board','K276 ISO Board',
+          '27710000-0000-4000-8000-000000000001','private','active');
+
+  insert into agent_board.board_memberships(board_id, agent_id, role, membership_state, created_by_agent_id)
+  values
+    ('27720000-0000-4000-8000-000000000001','27710000-0000-4000-8000-000000000001','owner','joined','27710000-0000-4000-8000-000000000001'),
+    ('27720000-0000-4000-8000-000000000001','27710000-0000-4000-8000-000000000002','member','joined','27710000-0000-4000-8000-000000000001');
+
+  insert into agent_board.agent_signing_keys(
+    id, agent_id, key_id, key_version, public_key, public_key_format, fingerprint, status, proof_state)
+  values ('27730000-0000-4000-8000-000000000001','27710000-0000-4000-8000-000000000001',
+          'primary', 1, public.test_pubkey('k276-iso'), 'raw_ed25519_base64url',
+          public.test_key_fingerprint('k276-iso'), 'active', 'proven');
+
+  -- A real fleet binding, so revoke_fleet_subject('agent') walks its full path (machine locks,
+  -- agents lock, binding revocation, ledger write) rather than a degenerate one.
+  insert into agent_board.fleet_trust_domains(id, slug, display_name, domain_kind, owner_agent_id, lifecycle_state, approved_at)
+  values ('27740000-0000-4000-8000-000000000001','k276-iso-domain','K276 ISO Domain','tailnet',
+          '27710000-0000-4000-8000-000000000003','active', now());
+  insert into agent_board.fleet_machines(id, trust_domain_id, owner_agent_id, machine_label, machine_fingerprint, lifecycle_state, enrolled_at)
+  values ('27750000-0000-4000-8000-000000000001','27740000-0000-4000-8000-000000000001',
+          '27710000-0000-4000-8000-000000000003','k276-iso-machine','fp-k276-iso','active', now());
+  insert into agent_board.fleet_machine_agents(id, machine_id, agent_id, agent_role, lifecycle_state)
+  values ('27760000-0000-4000-8000-000000000001','27750000-0000-4000-8000-000000000001',
+          '27710000-0000-4000-8000-000000000001','phase_worker','active');
+
+  -- An OUTSTANDING admin link, modelled as a pre-existing row because that is what it is: a
+  -- link minted before its creator was revoked, which the mint gate structurally cannot reach.
+  -- Seeded rather than minted through create_invite_link for two reasons, both mechanical: the
+  -- generated code is random (a golden must not contain one), and board_invite_tokens carries
+  -- a CREATOR-ONLY read policy (board_invite_tokens_creator_read), so a redeem session running
+  -- as `authenticated` cannot look the code up -- it holds the code out of band, as a real
+  -- redeemer does. An earlier revision of this spec did look it up and every redemption failed
+  -- 'invite is not usable' on a null code, which the uniform error made indistinguishable from
+  -- the gate firing. The code is a literal here for exactly that reason.
+  insert into agent_board.board_invite_tokens(
+    code, board_id, preset_role, preset_membership_state, max_uses, expires_at, created_by_agent_id)
+  values ('k276isolink', '27720000-0000-4000-8000-000000000001', 'admin', 'joined', 5,
+          now() + interval '2 days', '27710000-0000-4000-8000-000000000001');
+}
+
+teardown
+{
+  delete from agent_board.signature_evidence
+   where agent_id in (select id from agent_board.agents where handle like 'k276iso-%');
+  delete from agent_board.board_invite_redemptions
+   where invite_id in (select id from agent_board.board_invite_tokens
+                        where board_id = '27720000-0000-4000-8000-000000000001');
+  delete from agent_board.board_invite_tokens
+   where board_id = '27720000-0000-4000-8000-000000000001';
+  delete from agent_board.board_membership_events
+   where board_id in (select id from agent_board.boards where slug like 'k280-iso-%');
+  delete from agent_board.board_memberships
+   where board_id in (select id from agent_board.boards where slug like 'k280-iso-%');
+  delete from agent_board.boards where slug like 'k280-iso-%';
+  delete from agent_board.board_membership_events
+   where board_id = '27720000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_revocation_events
+   where agent_id in (select id from agent_board.agents where handle like 'k276iso-%')
+      or subject_id in (select id from agent_board.agents where handle like 'k276iso-%')
+      or revoked_by_agent_id in (select id from agent_board.agents where handle like 'k276iso-%');
+  delete from agent_board.fleet_machine_agents where id='27760000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_machines where id='27750000-0000-4000-8000-000000000001';
+  delete from agent_board.fleet_trust_domains where id='27740000-0000-4000-8000-000000000001';
+  delete from agent_board.agent_signing_keys
+   where agent_id in (select id from agent_board.agents where handle like 'k276iso-%');
+  delete from agent_board.board_authority_ceilings where board_id='27720000-0000-4000-8000-000000000001';
+  delete from agent_board.board_memberships where board_id='27720000-0000-4000-8000-000000000001';
+  delete from agent_board.boards where id='27720000-0000-4000-8000-000000000001';
+  delete from agent_board.agents where handle like 'k276iso-%';
+  delete from auth.users where id in (
+    '27700000-0000-0000-0000-0000000000a1',
+    '27700000-0000-0000-0000-0000000000a2',
+    '27700000-0000-0000-0000-0000000000a3');
+}
+
+# The WIDE door: the authenticated owner calling the chokepoint directly, no gateway involved.
+session "ugrant"
+step "ugrant_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a1';
+}
+step "ugrant_grant" {
+  select g.role as granted_role
+    from agent_board.grant_board_role(
+      '27720000-0000-4000-8000-000000000001',
+      '27710000-0000-4000-8000-000000000002',
+      'admin') g;
+}
+step "ugrant_commit" { COMMIT; }
+
+# The NARROW door. Only the deterministic column is selected -- signature_evidence_id is a
+# fresh uuid and a golden must not contain a random value.
+session "sgrant"
+step "sgrant_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "sgrant_grant" {
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '27720000-0000-4000-8000-000000000001',
+        'p_agent_id', '27710000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '27710000-0000-4000-8000-000000000001',
+        'signing_key_id', '27730000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k276',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+}
+step "sgrant_commit" { COMMIT; }
+
+session "revoke"
+step "revoke_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "revoke_agent" {
+  select subject_kind
+    from agent_board.revoke_fleet_subject(
+      'agent',
+      '27710000-0000-4000-8000-000000000001',
+      '27710000-0000-4000-8000-000000000003',
+      'k276 iso fleet revocation');
+}
+step "revoke_commit" { COMMIT; }
+
+# The invite MINT half (#276 G3). Locked like the three chokepoints: the actor IS the principal
+# whose authority is being spent, since an admin-preset link is a deferred grant of admin.
+session "mint"
+step "mint_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a1';
+}
+step "mint_link" {
+  select m.preset_role
+    from agent_board.create_invite_link(
+      '27720000-0000-4000-8000-000000000001', 'admin', 'joined', 5,
+      now() + interval '2 days') m;
+}
+step "mint_commit" { COMMIT; }
+
+# The invite REDEEM half. DELIBERATELY UNLOCKED -- every way of row-locking the creator here
+# closes a cycle (enroll_federated_identity reaches this function holding a boards lock; see the
+# migration header). This session exists to record the ACCEPTED window as bytes rather than
+# prose: with the revocation in flight and uncommitted, the redemption does NOT block and
+# succeeds on its own snapshot. Permutation 6 then shows the very next redemption refused.
+session "redeem"
+step "redeem_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a2';
+}
+step "redeem_link" {
+  select r.role as redeemed_role
+    from agent_board.redeem_invite_link('k276isolink') r;
+}
+step "redeem_commit" { COMMIT; }
+
+# A SECOND redeemer of the SAME token. Exists to bound the accepted window: two redemptions of
+# one token cannot both sit between their ledger read and their commit, because the token
+# FOR UPDATE is the redeem path's first statement. Permutation 8 drives exactly that.
+session "redeem2"
+step "redeem2_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a3';
+}
+step "redeem2_link" {
+  select r.role as redeemed_role
+    from agent_board.redeem_invite_link('k276isolink') r;
+}
+step "redeem2_commit" { COMMIT; }
+
+# ---------------------------------------------------------------------------------------------
+# #280 — create_board. TWO sessions, because the function is two operations behind one name and
+# the FOR SHARE means something different on each branch (see 20260911000100's header).
+#
+#   cboard  — the FRESH-BOARD branch. The owner seat INSERT takes FK KEY SHARE on the actor's
+#             agents row BEFORE the gate runs, so the FK — not the gate — is what makes this
+#             branch wait. Permutations 9 and 10 therefore pin the OUTCOME (blocks, then fails
+#             closed, leaving NO board and NO seat) and structurally cannot pin the lock.
+#   creopen — the SLUG-COLLISION branch, re-opening the board the actor already owns. The boards
+#             UPDATE does not touch created_by_agent_id, so no FK fires and the gate's FOR SHARE
+#             is the ONLY agents lock on that path. Permutation 11 is the genuine lock
+#             discriminator this migration has and the mint path could not provide: remove the
+#             FOR SHARE and the reopen stops waiting and SUCCEEDS on its own snapshot.
+# ---------------------------------------------------------------------------------------------
+session "cboard"
+step "cboard_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a1';
+}
+step "cboard_create" {
+  select c.slug
+    from agent_board.create_board(
+      '27710000-0000-4000-8000-000000000001', 'k280-iso-fresh', 'K280 ISO Fresh') c;
+}
+step "cboard_commit" { COMMIT; }
+
+session "creopen"
+step "creopen_begin" {
+  BEGIN;
+  SET LOCAL ROLE authenticated;
+  SET LOCAL "request.jwt.claim.role" = 'authenticated';
+  SET LOCAL "request.jwt.claim.sub" = '27700000-0000-0000-0000-0000000000a1';
+}
+# p_metadata is passed as NULL below rather than as an empty-object jsonb literal, and this note
+# lives OUTSIDE the step for the same reason: the isolationtester spec lexer matches BRACES to
+# delimit a step body, so an empty-object literal anywhere inside the SQL closes the step early
+# and the parse dies on the next quote. create_board coalesces a null p_metadata to that same
+# empty object, so the call is identical. (Backticks break the lexer here too.)
+step "creopen_call" {
+  select c.name, c.visibility
+    from agent_board.create_board(
+      '27710000-0000-4000-8000-000000000001', 'k276-iso-board', 'K280 ISO REOPENED',
+      null, null, 'open') c;
+}
+step "creopen_commit" { COMMIT; }
+
+# The #280 state row. Kept separate from "check" so the existing golden rows keep their shape and
+# a diff in permutations 1-8 can only be a real change.
+session "cbcheck"
+step "cbcheck" {
+  select
+    (select count(*) from agent_board.boards where slug = 'k280-iso-fresh') as fresh_boards,
+    (select count(*) from agent_board.board_memberships bm
+       join agent_board.boards b on b.id = bm.board_id
+      where b.slug = 'k280-iso-fresh') as fresh_seats,
+    (select name from agent_board.boards
+      where id = '27720000-0000-4000-8000-000000000001') as existing_board_name,
+    (select visibility from agent_board.boards
+      where id = '27720000-0000-4000-8000-000000000001') as existing_board_visibility,
+    (select status from agent_board.agents
+      where id = '27710000-0000-4000-8000-000000000001') as owner_status,
+    (select count(*) from agent_board.fleet_revocation_events
+      where subject_kind = 'agent'
+        and subject_id = '27710000-0000-4000-8000-000000000001') as agent_ledger_rows;
+}
+
+session "check"
+step "check" {
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '27720000-0000-4000-8000-000000000001'
+        and agent_id = '27710000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '27710000-0000-4000-8000-000000000001') as owner_status,
+    (select count(*) from agent_board.fleet_revocation_events
+      where subject_kind = 'agent'
+        and subject_id = '27710000-0000-4000-8000-000000000001') as agent_ledger_rows,
+    (select count(*) from agent_board.fleet_machine_agents
+      where agent_id = '27710000-0000-4000-8000-000000000001'
+        and lifecycle_state = 'active') as active_bindings,
+    (select count(*) from agent_board.board_invite_tokens
+      where board_id = '27720000-0000-4000-8000-000000000001'
+        and code <> 'k276isolink') as minted_tokens,
+    (select uses_count from agent_board.board_invite_tokens
+      where code = 'k276isolink') as outstanding_link_uses;
+}
+
+# 1. Write first (UNSIGNED). The revocation must WAIT on the share-locked agents row rather
+#    than committing underneath a grant that has already been authorized. The grant stands and
+#    the revocation lands after it -- a grant that beat the revocation, which is the same
+#    outcome as a grant one millisecond earlier.
+permutation "ugrant_begin" "ugrant_grant" "revoke_begin" "revoke_agent" "ugrant_commit" "revoke_commit" "check"
+
+# 2. THE DEFECT'S OWN INTERLEAVING, unsigned route. The revocation is in flight when the
+#    authority write runs; the write blocks on the agents row, then observes the committed
+#    revocation and fails closed. Before #276 this permutation COMPLETED the grant: the
+#    chokepoint read no ledger at all, so there was nothing to block on and nothing to see.
+permutation "revoke_begin" "revoke_agent" "ugrant_begin" "ugrant_grant" "revoke_commit" "ugrant_commit" "check"
+
+# 3. Write first, SIGNED route. Same property through the gateway wrapper, which reaches the
+#    gate only because the check lives inside the inner chokepoint.
+permutation "sgrant_begin" "sgrant_grant" "revoke_begin" "revoke_agent" "sgrant_commit" "revoke_commit" "check"
+
+# 4. The defect's interleaving through the SIGNED route. #269 already made this wrapper block
+#    on the agents row for a STATUS change; this permutation is what proves it also fails
+#    closed on a LEDGER revocation, which leaves agents.status untouched.
+permutation "revoke_begin" "revoke_agent" "sgrant_begin" "sgrant_grant" "revoke_commit" "sgrant_commit" "check"
+
+# 5. The MINT half, revoke-in-flight. The mint blocks on the creator's agents row, then observes
+#    the committed revocation and fails closed -- and leaves no token, so no code escapes. This
+#    is the permutation the FOR SHARE in _assert_actor_not_fleet_revoked exists for on this path.
+permutation "revoke_begin" "revoke_agent" "mint_begin" "mint_link" "revoke_commit" "mint_commit" "check"
+
+# 6. THE ACCEPTED WINDOW, recorded rather than described. The outstanding link exists, the
+#    revocation is IN FLIGHT and uncommitted, and the redemption does NOT block -- it reads its
+#    own snapshot and succeeds. That is the TOCTOU this migration deliberately accepts on the
+#    redeem path, because every row lock that would close it closes a deadlock cycle instead
+#    (see the header). The check row shows the use consumed; the pgTAP file shows the NEXT
+#    redemption, after the revocation commits, refused.
+permutation "revoke_begin" "revoke_agent" "redeem_begin" "redeem_link" "redeem_commit" "revoke_commit" "check"
+
+# 7. ...and the same interleaving with the revocation COMMITTED first: now the redemption is
+#    refused. The pair is what makes permutation 6 a bounded window rather than an open door.
+permutation "revoke_begin" "revoke_agent" "revoke_commit" "redeem_begin" "redeem_link" "redeem_commit" "check"
+
+# 8. THE RESIDUAL BOUND, driven rather than argued. Two redeemers of the SAME token with the
+#    revocation in flight: the first reads the ledger before the revocation commits and slips
+#    through; the second BLOCKS on the token row -- board_invite_tokens FOR UPDATE is the redeem
+#    path's first statement -- and by the time it proceeds the revocation has committed, so its
+#    own ledger read refuses it. That is why the disclosure says "at most one redemption per
+#    outstanding token" and not "one redemption": tokens serialise redemptions of themselves,
+#    but a creator holding K links has K independent windows. outstanding_link_uses = 1 in the
+#    check row is the byte that says exactly one slipped.
+permutation "revoke_begin" "revoke_agent" "redeem_begin" "redeem_link" "redeem2_begin" "redeem2_link" "revoke_commit" "redeem_commit" "redeem2_commit" "check"
+
+# 9. #280, FRESH branch, create first. The revocation must WAIT rather than commit underneath a
+#    board creation that has already run its gate. The board stands and the revocation lands
+#    after it -- a creation that beat the revocation, the same outcome as a creation a
+#    millisecond earlier. What makes the revoker wait here is the seat INSERT's FK KEY SHARE on
+#    the actor's agents row, not the gate; recorded so nobody reads this permutation as a lock
+#    pin for the FOR SHARE.
+permutation "cboard_begin" "cboard_create" "revoke_begin" "revoke_agent" "cboard_commit" "revoke_commit" "cbcheck"
+
+# 10. #280's OWN interleaving, FRESH branch: the revocation is in flight when create_board runs.
+#     The creation blocks, then observes the committed revocation and fails closed -- fresh_boards
+#     and fresh_seats are both 0, so the boards INSERT, the owner seat and the owner_seed event
+#     all rolled back together. Before 20260911000100 this permutation COMPLETED the creation:
+#     create_board read no ledger at all, so there was nothing to see. This is the OUTCOME pin.
+permutation "revoke_begin" "revoke_agent" "cboard_begin" "cboard_create" "revoke_commit" "cboard_commit" "cbcheck"
+
+# 11. #280, SLUG-COLLISION branch, revoke in flight -- THE LOCK DISCRIMINATOR. The boards UPDATE
+#     leaves created_by_agent_id alone, so no FK takes an agents lock and the gate's FOR SHARE is
+#     the only one on this path. The reopen blocks on it, then fails closed, leaving the existing
+#     board's name and visibility untouched. Drop the FOR SHARE from
+#     _assert_actor_not_fleet_revoked and this permutation stops waiting and SUCCEEDS on its own
+#     pre-revocation snapshot -- which permutations 9 and 10 cannot show, and neither can the
+#     mint path (permutation 5), where the FK always gets there first.
+permutation "revoke_begin" "revoke_agent" "creopen_begin" "creopen_call" "revoke_commit" "creopen_commit" "cbcheck"
+
+# 12. ...and the collision branch write-first, for the pair: the reopen is authorized and stands,
+#     the revocation waits on the share-locked agents row and lands after it.
+permutation "creopen_begin" "creopen_call" "revoke_begin" "revoke_agent" "creopen_commit" "revoke_commit" "cbcheck"