@consiliency/agent-board-schema 1.24.0 → 1.27.0

package/tests/isolation/expected/signer_lifecycle_revoke.out

@@ -0,0 +1,307 @@
+Parsed test spec with 5 sessions
+
+starting permutation: auth_begin auth_grant revoke_begin revoke_signer auth_commit revoke_commit check
+step auth_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step auth_grant: 
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+
+granted_role
+------------
+admin       
+(1 row)
+
+step revoke_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step revoke_signer: 
+  select revoked_agent_count, revoked_key_count
+    from agent_board.revoke_agent_subtree(
+      '26940000-0000-4000-8000-000000000001',
+      '26940000-0000-4000-8000-000000000003',
+      'k269 iso revoke');
+ <waiting ...>
+step auth_commit: COMMIT;
+step revoke_signer: <... completed>
+revoked_agent_count|revoked_key_count
+-------------------+-----------------
+                  1|                1
+(1 row)
+
+step revoke_commit: COMMIT;
+step check: 
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+
+grantee_role|signer_status|key_status|evidence_rows
+------------+-------------+----------+-------------
+admin       |revoked      |revoked   |            1
+(1 row)
+
+
+starting permutation: revoke_begin revoke_signer auth_begin auth_grant revoke_commit auth_commit check
+step revoke_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step revoke_signer: 
+  select revoked_agent_count, revoked_key_count
+    from agent_board.revoke_agent_subtree(
+      '26940000-0000-4000-8000-000000000001',
+      '26940000-0000-4000-8000-000000000003',
+      'k269 iso revoke');
+
+revoked_agent_count|revoked_key_count
+-------------------+-----------------
+                  1|                1
+(1 row)
+
+step auth_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step auth_grant: 
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+ <waiting ...>
+step revoke_commit: COMMIT;
+step auth_grant: <... completed>
+ERROR:  signer_not_active: signed authority write signer is revoked, not active
+step auth_commit: COMMIT;
+step check: 
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+
+grantee_role|signer_status|key_status|evidence_rows
+------------+-------------+----------+-------------
+member      |revoked      |revoked   |            0
+(1 row)
+
+
+starting permutation: suspend_begin suspend_signer auth_begin auth_grant suspend_commit auth_commit check
+step suspend_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step suspend_signer: 
+  update agent_board.agents set status = 'suspended', updated_at = now()
+   where id = '26940000-0000-4000-8000-000000000001';
+
+step auth_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step auth_grant: 
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+ <waiting ...>
+step suspend_commit: COMMIT;
+step auth_grant: <... completed>
+ERROR:  signer_not_active: signed authority write signer is suspended, not active
+step auth_commit: COMMIT;
+step check: 
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+
+grantee_role|signer_status|key_status|evidence_rows
+------------+-------------+----------+-------------
+member      |suspended    |active    |            0
+(1 row)
+
+
+starting permutation: auth_begin auth_grant suspend_begin suspend_signer auth_commit suspend_commit check
+step auth_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step auth_grant: 
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+
+granted_role
+------------
+admin       
+(1 row)
+
+step suspend_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step suspend_signer: 
+  update agent_board.agents set status = 'suspended', updated_at = now()
+   where id = '26940000-0000-4000-8000-000000000001';
+ <waiting ...>
+step auth_commit: COMMIT;
+step suspend_signer: <... completed>
+step suspend_commit: COMMIT;
+step check: 
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+
+grantee_role|signer_status|key_status|evidence_rows
+------------+-------------+----------+-------------
+admin       |suspended    |active    |            1
+(1 row)
+
+
+starting permutation: auth_begin auth_grant keyrevoke_begin keyrevoke_key auth_commit keyrevoke_commit check
+step auth_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step auth_grant: 
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+
+granted_role
+------------
+admin       
+(1 row)
+
+step keyrevoke_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step keyrevoke_key: 
+  update agent_board.agent_signing_keys
+     set status = 'revoked', proof_state = 'revoked', revoked_at = now(), updated_at = now()
+   where id = '26960000-0000-4000-8000-000000000001';
+ <waiting ...>
+step auth_commit: COMMIT;
+step keyrevoke_key: <... completed>
+step keyrevoke_commit: COMMIT;
+step check: 
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+
+grantee_role|signer_status|key_status|evidence_rows
+------------+-------------+----------+-------------
+admin       |active       |revoked   |            1
+(1 row)
+
+
+starting permutation: keyrevoke_begin keyrevoke_key auth_begin auth_grant keyrevoke_commit auth_commit check
+step keyrevoke_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step keyrevoke_key: 
+  update agent_board.agent_signing_keys
+     set status = 'revoked', proof_state = 'revoked', revoked_at = now(), updated_at = now()
+   where id = '26960000-0000-4000-8000-000000000001';
+
+step auth_begin: BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role';
+step auth_grant: 
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+ <waiting ...>
+step keyrevoke_commit: COMMIT;
+step auth_grant: <... completed>
+ERROR:  signer_key_not_live: signed authority write signing key is revoked, not active
+step auth_commit: COMMIT;
+step check: 
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+
+grantee_role|signer_status|key_status|evidence_rows
+------------+-------------+----------+-------------
+member      |active       |revoked   |            0
+(1 row)
+

package/tests/isolation/specs/signed_grant_onboarding_deadlock.spec

@@ -0,0 +1,159 @@
+# Consiliency/message-board#269 (F4) — signed_grant_board_role must be ACYCLIC against
+# onboard_federated_fleet_agent.
+#
+# THE DEFECT. The grant wrapper's lock order was
+#     board_memberships(grantee, via the inner grant's UPDATE) -> agents(signer, FOR SHARE)
+# while onboard_federated_fleet_agent takes
+#     agents(20260901000110:349, FOR UPDATE) -> board_memberships(:397, FOR UPDATE)
+# — the opposite order, with no advisory lock on the grant side to serialize them. That is an
+# ABBA cycle between two HONEST callers: a board owner who created a fleet invite while
+# concurrently granting the enrollee a role. Both operands are routine on one board (the
+# collision needs enrolling agent == grantee and invite creator == signer). Reproduced before
+# the fix as a live `ERROR: deadlock detected ... while locking tuple in relation
+# "board_memberships"`, with the real wrapper on one side.
+#
+# THE FIX this spec pins: the wrapper takes the board-keyed _lock_board_authority_ceiling
+# advisory lock FIRST. Both authority wrappers now take it before anything else, and onboarding
+# takes it at :290 holding only board_invite_tokens and fleet_onboarding_invite_bounds — rows no
+# authority wrapper ever touches — so the transactions are serialized per board rather than
+# merely ordered. Mutual exclusion survives a new lock being added downstream; an ordering
+# argument would have to be re-derived each time.
+#
+# THE "onboard" SESSION IS A LOCK-EQUIVALENT STAND-IN, and here is the equivalence, stated the
+# way this suite requires rather than assumed.
+#   * It runs onboard_federated_fleet_agent's three cycle-relevant acquisitions, in its order
+#     and its modes: _lock_board_authority_ceiling(board) (:290), then `agents ... for update`
+#     (:349), then `board_memberships ... for update` (:397).
+#   * It omits that function's other locks — board_invite_tokens, fleet_onboarding_invite_bounds,
+#     boards, fleet_machines, fleet_trust_domains, the fingerprint-keyed advisory, auth.users,
+#     board_authority_ceilings, board_invite_redemptions, and the enrolled agent's own agents/
+#     agent_signing_keys rows. Every one of those is on a relation the grant wrapper never
+#     touches, so none can participate in a cycle with it; including them would change nothing
+#     observable and would require provisioning a full fleet invite, machine, trust domain and
+#     PoP-verified identity inside an isolation setup block.
+#   * A full onboarding replay was rejected for that reason alone, not because it would fail.
+#     The claim under test is a LOCK ORDER, and these are the locks.
+#   THE ADVISORY ACQUISITION IN THIS SESSION IS LOAD-BEARING, not decoration. Drop it and this
+#   spec deadlocks even against the FIXED wrapper — the stand-in would hold agents(signer) while
+#   taking no advisory lock, so the wrapper would sail through its own advisory acquisition and
+#   into the same cycle. A reader who "simplifies" this session by deleting the advisory step is
+#   not testing onboarding; they are testing a caller that does not exist, and they will read the
+#   resulting deadlock as a failed fix.
+#
+# WHY THE EXISTING signer_lifecycle_revoke.spec DOES NOT COVER THIS. Its three adversaries are
+# revoke_agent_subtree, a bare suspend, and a key-only update. NONE of them takes a
+# board_memberships lock, and board_memberships is one of the two operands in this cycle, so its
+# green golden is silent here. That is why this is a separate spec rather than a permutation
+# added there.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status)
+  values
+    ('f4940000-0000-4000-8000-000000000001','agent','agent','f4iso-signer','F4 ISO Signer/Creator','active'),
+    ('f4940000-0000-4000-8000-000000000002','agent','agent','f4iso-grantee','F4 ISO Grantee/Enrollee','active');
+
+  insert into agent_board.boards(id, slug, name, created_by_agent_id, visibility, status)
+  values ('f4950000-0000-4000-8000-000000000001','f4-iso-board','F4 ISO Board',
+          'f4940000-0000-4000-8000-000000000001','private','active');
+
+  insert into agent_board.board_memberships(board_id, agent_id, role, membership_state, created_by_agent_id)
+  values
+    ('f4950000-0000-4000-8000-000000000001','f4940000-0000-4000-8000-000000000001','owner','joined','f4940000-0000-4000-8000-000000000001'),
+    ('f4950000-0000-4000-8000-000000000001','f4940000-0000-4000-8000-000000000002','member','joined','f4940000-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 ('f4960000-0000-4000-8000-000000000001','f4940000-0000-4000-8000-000000000001',
+          'primary', 1, public.test_pubkey('f4-iso'), 'raw_ed25519_base64url',
+          public.test_key_fingerprint('f4-iso'), 'active', 'proven');
+}
+
+teardown
+{
+  delete from agent_board.signature_evidence
+   where agent_id in (select id from agent_board.agents where handle like 'f4iso-%');
+  delete from agent_board.board_authority_ceilings where board_id='f4950000-0000-4000-8000-000000000001';
+  delete from agent_board.board_memberships where board_id='f4950000-0000-4000-8000-000000000001';
+  delete from agent_board.boards where id='f4950000-0000-4000-8000-000000000001';
+  delete from agent_board.agent_signing_keys
+   where agent_id in (select id from agent_board.agents where handle like 'f4iso-%');
+  delete from agent_board.agents where handle like 'f4iso-%';
+}
+
+# The real signed authority write, unmodified. Only the deterministic column is selected: the
+# evidence id is a fresh uuid and must never reach a golden.
+session "auth"
+step "auth_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "auth_grant" {
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', 'f4950000-0000-4000-8000-000000000001',
+        'p_agent_id', 'f4940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', 'f4940000-0000-4000-8000-000000000001',
+        'signing_key_id', 'f4960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:f4iso',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+}
+step "auth_commit" { COMMIT; }
+
+# onboard_federated_fleet_agent's cycle-relevant locks, in its order and modes. See the header
+# for the equivalence argument; the advisory step is load-bearing.
+session "onboard"
+step "onboard_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "onboard_advisory" {
+  select agent_board._lock_board_authority_ceiling('f4950000-0000-4000-8000-000000000001') is null as advisory_taken;
+}
+step "onboard_agents" {
+  select count(*)::int as locked_agents from (
+    select 1 from agent_board.agents a
+     where a.id = 'f4940000-0000-4000-8000-000000000001' for update) s;
+}
+step "onboard_membership" {
+  select count(*)::int as locked_memberships from (
+    select 1 from agent_board.board_memberships bm
+     where bm.board_id = 'f4950000-0000-4000-8000-000000000001'
+       and bm.agent_id = 'f4940000-0000-4000-8000-000000000002'
+     order by bm.id for update) s;
+}
+step "onboard_commit" { COMMIT; }
+
+session "check"
+step "check" {
+  select
+    (select role from agent_board.board_memberships
+      where board_id = 'f4950000-0000-4000-8000-000000000001'
+        and agent_id = 'f4940000-0000-4000-8000-000000000002') as grantee_role,
+    (select count(*)::int from agent_board.signature_evidence
+      where operation = 'grant_board_role'
+        and agent_id = 'f4940000-0000-4000-8000-000000000001') as evidence_rows;
+}
+
+# 1. THE CYCLE, in the order that produced the deadlock. onboard takes the advisory lock and
+#    then the signer's agents row; the wrapper then runs. UNFIXED, the wrapper acquires the
+#    grantee membership row (its inner UPDATE) and blocks wanting agents FOR SHARE, onboard
+#    then wants that same membership row, and the server aborts one of them with `deadlock
+#    detected`. FIXED, the wrapper blocks at its FIRST statement — the advisory lock onboard
+#    already holds — so it holds nothing, onboard completes, and the grant proceeds after.
+#    The difference between those two worlds is the whole golden.
+permutation "onboard_begin" "onboard_advisory" "onboard_agents" "auth_begin" "auth_grant" "onboard_membership" "onboard_commit" "auth_commit" "check"
+
+# 2. The same operands with the wrapper first. It holds the advisory lock, so onboard waits at
+#    its OWN first step and never reaches the rows; once the wrapper commits, onboard proceeds.
+#    auth_commit is scheduled while onboard is still waiting on purpose — with it ordered after
+#    onboard's row steps the wait is unresolvable and isolationtester cancels the step, which
+#    records a `canceling statement due to user request` in the golden rather than the
+#    serialization this permutation exists to show.
+permutation "auth_begin" "auth_grant" "onboard_begin" "onboard_advisory" "auth_commit" "onboard_agents" "onboard_membership" "onboard_commit" "check"
+
+# 3. onboard holds the advisory lock alone, with no row locks yet. The wrapper must still block
+#    on it — this is what proves the acquisition is FIRST in the wrapper rather than merely
+#    present somewhere in it.
+permutation "onboard_begin" "onboard_advisory" "auth_begin" "auth_grant" "onboard_agents" "onboard_membership" "onboard_commit" "auth_commit" "check"

package/tests/isolation/specs/signer_lifecycle_revoke.spec

@@ -0,0 +1,176 @@
+# Consiliency/message-board#269 — a signed AUTHORITY write revalidates its signer inside
+# its OWN transaction, and the lifecycle rows it reads are share-locked so a concurrent
+# revoke/suspend serializes against the mutation instead of racing it.
+#
+# WHY THIS CANNOT BE A pgTAP FILE. The defect is a window BETWEEN two committed
+# transactions: Portal verifies the signature and reads lifecycle in one PostgREST call,
+# a revocation commits, and the wrapper runs in a second call. A pgTAP file is one
+# rolled-back transaction and can only reach the predicate ("a suspended signer is
+# refused"), never the interleaving or the blocking. Both are the point here, and both are
+# observable in the trace: isolationtester prints `<waiting ...>` / `<... completed>`
+# whenever a step blocks, so the lock is a byte in the golden rather than a claim.
+#
+# THE THREE ADVERSARIES, and why each is the real thing and not a stand-in.
+#   revoke_agent_subtree  — the shipped cascade. Its primitive _revoke_agent_principal
+#                           (20260901000100:1277, the NEWEST definition) locks the agents
+#                           row FOR UPDATE and then the signing keys, which is why this
+#                           helper takes agents first: matching the transaction the gate
+#                           exists to serialize against is what keeps the order acyclic.
+#   suspend               — a bare `update agent_board.agents set status='suspended'`. This
+#                           is lock-identical to the platform-admin RPC revoke_agent
+#                           (20260512000000:569), whose suspension is likewise a plain
+#                           UPDATE of a non-key column taking FOR NO KEY UPDATE. It is used
+#                           directly only to avoid provisioning a platform-admin JWT inside
+#                           an isolation session; the lock interaction under test is the
+#                           same byte for byte.
+#   keyrevoke             — a key-only `update agent_board.agent_signing_keys set
+#                           status='revoked'...`, which is the UPDATE statement
+#                           revoke_fleet_subject's signing_key branch runs, minus the agent
+#                           row lock that function takes first. Every shipped key-revoking
+#                           path locks the agent first, so only a key-ONLY writer can pin
+#                           the agent_signing_keys FOR SHARE at all -- and it must be a
+#                           PLAIN update. issue_signing_key_challenge was tried here and
+#                           rejected: it takes FOR UPDATE on the key, which also conflicts
+#                           with the FOR KEY SHARE the evidence row's foreign key already
+#                           takes, so it blocks whether or not this change exists and
+#                           distinguishes nothing. A plain UPDATE takes FOR NO KEY UPDATE,
+#                           which the FK's KEY SHARE does NOT block and FOR SHARE does --
+#                           so this session, and only this session, makes the key lock and
+#                           its MODE observable. The table's UPDATE privilege is the
+#                           owner's alone (service_role has SELECT), so this models
+#                           owner-level incident DML and any future key-only writer.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status)
+  values
+    ('26940000-0000-4000-8000-000000000001','agent','agent','k269iso-signer','K269 ISO Signer','active'),
+    ('26940000-0000-4000-8000-000000000002','agent','agent','k269iso-grantee','K269 ISO Grantee','active'),
+    ('26940000-0000-4000-8000-000000000003','agent','agent','k269iso-revoker','K269 ISO Revoker','active');
+
+  insert into agent_board.boards(id, slug, name, created_by_agent_id, visibility, status)
+  values ('26950000-0000-4000-8000-000000000001','k269-iso-board','K269 ISO Board',
+          '26940000-0000-4000-8000-000000000001','private','active');
+
+  insert into agent_board.board_memberships(board_id, agent_id, role, membership_state, created_by_agent_id)
+  values
+    ('26950000-0000-4000-8000-000000000001','26940000-0000-4000-8000-000000000001','owner','joined','26940000-0000-4000-8000-000000000001'),
+    ('26950000-0000-4000-8000-000000000001','26940000-0000-4000-8000-000000000002','member','joined','26940000-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 ('26960000-0000-4000-8000-000000000001','26940000-0000-4000-8000-000000000001',
+          'primary', 1, public.test_pubkey('k269-iso'), 'raw_ed25519_base64url',
+          public.test_key_fingerprint('k269-iso'), 'active', 'proven');
+}
+
+teardown
+{
+  delete from agent_board.signature_evidence
+   where agent_id in (select id from agent_board.agents where handle like 'k269iso-%');
+  delete from agent_board.agent_signing_key_challenges
+   where agent_id in (select id from agent_board.agents where handle like 'k269iso-%');
+  delete from agent_board.fleet_revocation_events
+   where agent_id in (select id from agent_board.agents where handle like 'k269iso-%')
+      or revoked_by_agent_id in (select id from agent_board.agents where handle like 'k269iso-%');
+  delete from agent_board.board_authority_ceilings where board_id='26950000-0000-4000-8000-000000000001';
+  delete from agent_board.board_memberships where board_id='26950000-0000-4000-8000-000000000001';
+  delete from agent_board.boards where id='26950000-0000-4000-8000-000000000001';
+  delete from agent_board.agent_signing_keys
+   where agent_id in (select id from agent_board.agents where handle like 'k269iso-%');
+  delete from agent_board.agents where handle like 'k269iso-%';
+}
+
+# The signed authority write. The signature_evidence_id it returns is a fresh uuid, so only
+# the deterministic column is selected — a golden must not contain a random value.
+session "auth"
+step "auth_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "auth_grant" {
+  select w.role as granted_role
+    from agent_board.signed_grant_board_role(
+      jsonb_build_object(
+        'p_board_id', '26950000-0000-4000-8000-000000000001',
+        'p_agent_id', '26940000-0000-4000-8000-000000000002',
+        'p_grantee_role', 'admin'),
+      jsonb_build_object(
+        'agent_id', '26940000-0000-4000-8000-000000000001',
+        'signing_key_id', '26960000-0000-4000-8000-000000000001',
+        'key_id', 'primary',
+        'key_version', 1,
+        'algorithm', 'Ed25519',
+        'verification_status', 'verified',
+        'payload_digest', 'sha256:k269',
+        'enforcement_mode', 'require_for_agent_writes')) w;
+}
+step "auth_commit" { COMMIT; }
+
+session "revoke"
+step "revoke_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "revoke_signer" {
+  select revoked_agent_count, revoked_key_count
+    from agent_board.revoke_agent_subtree(
+      '26940000-0000-4000-8000-000000000001',
+      '26940000-0000-4000-8000-000000000003',
+      'k269 iso revoke');
+}
+step "revoke_commit" { COMMIT; }
+
+session "suspend"
+step "suspend_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "suspend_signer" {
+  update agent_board.agents set status = 'suspended', updated_at = now()
+   where id = '26940000-0000-4000-8000-000000000001';
+}
+step "suspend_commit" { COMMIT; }
+
+# Key-only writer: a PLAIN update of the signing key, touching no agents row.
+session "keyrevoke"
+step "keyrevoke_begin" { BEGIN; SET LOCAL "request.jwt.claim.role" = 'service_role'; }
+step "keyrevoke_key" {
+  update agent_board.agent_signing_keys
+     set status = 'revoked', proof_state = 'revoked', revoked_at = now(), updated_at = now()
+   where id = '26960000-0000-4000-8000-000000000001';
+}
+step "keyrevoke_commit" { COMMIT; }
+
+session "check"
+step "check" {
+  select
+    (select role from agent_board.board_memberships
+      where board_id = '26950000-0000-4000-8000-000000000001'
+        and agent_id = '26940000-0000-4000-8000-000000000002') as grantee_role,
+    (select status from agent_board.agents
+      where id = '26940000-0000-4000-8000-000000000001') as signer_status,
+    (select status from agent_board.agent_signing_keys
+      where id = '26960000-0000-4000-8000-000000000001') as key_status,
+    (select count(*) from agent_board.signature_evidence
+      where operation = 'grant_board_role') as evidence_rows;
+}
+
+# 1. Write first: the revocation must WAIT on the share-locked lifecycle rows rather than
+#    committing underneath a grant that has already been authorized. The grant stands and
+#    the revocation lands after it.
+permutation "auth_begin" "auth_grant" "revoke_begin" "revoke_signer" "auth_commit" "revoke_commit" "check"
+
+# 2. The defect's own interleaving, in the order that exposes it. The revocation is in
+#    flight when the wrapper runs; the wrapper blocks on the agents row, then observes the
+#    committed revocation and fails closed. Before #269 this permutation completed the
+#    grant: the wrapper read no lifecycle at all, so there was nothing to block on.
+permutation "revoke_begin" "revoke_signer" "auth_begin" "auth_grant" "revoke_commit" "auth_commit" "check"
+
+# 3. Suspension, which touches the agents row and NOT the key — so it isolates the agents
+#    FOR SHARE from the key FOR SHARE.
+permutation "suspend_begin" "suspend_signer" "auth_begin" "auth_grant" "suspend_commit" "auth_commit" "check"
+
+# 4. Suspension the other way round: the write holds the agents row and the suspension waits.
+permutation "auth_begin" "auth_grant" "suspend_begin" "suspend_signer" "auth_commit" "suspend_commit" "check"
+
+# 5. The key half, isolated. Nothing here touches the agents row, so the wait is produced by
+#    the agent_signing_keys FOR SHARE and by nothing else -- and by its MODE: FOR KEY SHARE
+#    would not conflict with this plain UPDATE's FOR NO KEY UPDATE.
+permutation "auth_begin" "auth_grant" "keyrevoke_begin" "keyrevoke_key" "auth_commit" "keyrevoke_commit" "check"
+
+# 6. And the key revocation's own race: revoked in flight, the authority write blocks on the
+#    key row, then observes the committed revocation and fails closed -- the key-side twin of
+#    permutation 2.
+permutation "keyrevoke_begin" "keyrevoke_key" "auth_begin" "auth_grant" "keyrevoke_commit" "auth_commit" "check"