@consiliency/agent-board-schema 1.28.0 → 1.38.0

package/fixtures/already-applied.json

@@ -508,6 +508,46 @@
     {
       "id": "20260909000100_agent_board_ledger_revoked_authority",
       "sha256": "7522e32c61f8845e511255d94d273d98eb7b72b2f906976c3a2494629927462d"
+    },
+    {
+      "id": "20260910000100_agent_board_ceiling_lock_comment_truth",
+      "sha256": "b8ddc658be347d9e7207111968d0b8de7a88759cb3cf181f61c4ef306086f384"
+    },
+    {
+      "id": "20260911000100_agent_board_ledger_revoked_board_creation",
+      "sha256": "4291af2bd6c93b7d9f8ec596f41dc62edf941ea10a51529df04e223d1cbc50c5"
+    },
+    {
+      "id": "20260912000100_agent_board_receipt_subject_gate",
+      "sha256": "1083f7720ccab9c9b422415f2a8eb743de5d84b0ab8d8689059bd355514e9aa9"
+    },
+    {
+      "id": "20260913000100_agent_board_task_thread_lock_order",
+      "sha256": "259a05c4a6603518ab449e799fcb235b0e16a6650954cb2db19b436c0a7a1e83"
+    },
+    {
+      "id": "20260914000100_agent_board_claim_subject_gate",
+      "sha256": "88207b2e3f28ec8022ad4ca921721ebba877668042c66b5ac74c85e4c8cefc21"
+    },
+    {
+      "id": "20260915000100_agent_board_fedsession_stored_identity_gate",
+      "sha256": "5a8f4abb822e30c2a695a310bb1742f2565bb2afd0b6a06cad43fcbdd106ad5e"
+    },
+    {
+      "id": "20260916000100_agent_board_federated_identity_injective_slug",
+      "sha256": "d9f05e18094954f2e4ee32bf7b129f0a9ffc39bc800a5efa9cf7938e1555c8dc"
+    },
+    {
+      "id": "20260917000100_agent_board_invite_no_downgrade",
+      "sha256": "c205a9a679dca059979972b49c89c3b1b3b8f8e2039bd7675a10578f49f9b35a"
+    },
+    {
+      "id": "20260918000100_agent_board_signed_write_enforced_repoint",
+      "sha256": "f76dd01744029bfd0088bd4f6cf6fa5cb93e3c9b7fa5559ad83857cf7f4eb8ce"
+    },
+    {
+      "id": "20260919000100_agent_board_signed_write_model_key",
+      "sha256": "464ae39acbd96330c5ad1c753fa1204ca290baa0d6f82d7d30d0ead4d2944d37"
     }
   ]
 }

package/migrations/20260910000100_agent_board_ceiling_lock_comment_truth.sql

@@ -0,0 +1,89 @@
+-- Consiliency/message-board#277 -- the ceiling lock COMMENT claimed a property
+-- three of its four readers did not have, and the suite already said so.
+--
+-- WHAT WAS FALSE. 20260901000110:110 commented _lock_board_authority_ceiling as
+--
+--     every RPC that writes the ceiling and every RPC that reads it for
+--     authorization takes this FIRST, before any boards row lock
+--
+-- while the catalog-derived class assertion in
+-- agent_board_atomic_fleet_onboarding.test.sql enumerated the ceiling-authorization
+-- readers from pg_proc and declared most of them UNSERIALIZED. The COMMENT is the
+-- most discoverable statement of intent about this lock -- it is attached to the
+-- lock itself -- so the next person reasoning about a ceiling race would have read
+-- it and concluded their path was serialized while the suite said the opposite.
+--
+-- THIS IS A COMMENT FIX, AND ONLY A COMMENT FIX. The ceiling-ABSENCE race the old
+-- text implied was closed is real for the UNSERIALIZED readers and was knowingly
+-- left open (20260901000110's own header records the three it did not examine).
+-- Nothing here acquires a lock, changes a body, or drops anything: this migration
+-- contains one `comment on function` and no other statement, so no ACL and no other
+-- COMMENT is disturbed.
+--
+-- WHY NOT SERIALIZE THE REMAINDER INSTEAD, which would have made the old prose
+-- true. Each acquisition is a NEW edge in a lock graph that has already produced a
+-- reproduced ABBA deadlock (#269 F4) and needed a fifth round of order analysis in
+-- #276. Every reader would need its own total-order analysis and interleaving
+-- proof; that is not a comment fix wearing a code hat, and a lock added to make
+-- prose true is how deadlocks ship. Recorded here so the option is not re-litigated
+-- as an oversight: it was considered and deliberately deferred per reader.
+--
+-- WHAT THE SET ACTUALLY IS, derived from pg_proc on a fresh replay of this bundle
+-- and not from #277's issue text (which predates #276) or from memory:
+--
+--   readers of the ceiling for authorization (they call _grant_within_ceiling)
+--     agent_board.grant_board_role(uuid,uuid,text,uuid)                 serialized
+--     agent_board.onboard_federated_fleet_agent(...)                    serialized
+--     agent_board._redeem_unbounded_invite_for_agent(text,uuid)         UNSERIALIZED
+--     agent_board.create_invite_link(...)                               UNSERIALIZED
+--   writers of board_authority_ceilings
+--     agent_board.set_board_authority_ceiling(uuid,text,uuid)           serialized
+--
+-- grant_board_role joined the serialized side in #276 (20260909000100), which is
+-- exactly why the issue's own list is already one entry stale: it says three of
+-- four are UNSERIALIZED and two of four are.
+--
+-- HOW THIS COMMENT IS PREVENTED FROM ROTTING AGAIN -- the point of the exercise.
+-- The two lists are written in a fixed machine-readable form,
+--
+--     WRITERS[serialized: <names>][UNSERIALIZED: <names>]
+--     READERS[serialized: <names>][UNSERIALIZED: <names>]
+--
+-- and agent_board_atomic_fleet_onboarding.test.sql parses those blocks out of
+-- obj_description() and compares them to the SAME pg_proc-derived classes its
+-- existing registry assertion uses. A reader or writer added, removed, or moved
+-- between serialized and UNSERIALIZED now fails an assertion that NAMES the
+-- disagreement, and so does deleting or mangling the block (the parse yields NULL,
+-- which cannot equal a catalog list). The prose around the blocks still has to be
+-- read by a human, so it is kept to claims that have their own named pin:
+--   * the setter takes the lock before its owner gate and its upsert
+--     (agent_board_atomic_fleet_onboarding.test.sql + isolation spec
+--     ceiling_setter_lock_before_upsert.spec);
+--   * onboard_federated_fleet_agent takes it before its boards row lock
+--     (same file + isolation spec onboarding_ceiling_lock_order.spec);
+--   * grant_board_role takes no boards row lock at all, so it makes no ordering
+--     claim -- checked against its live body, not assumed.
+-- The old "before any boards row lock" was applied to every reader at once and had
+-- a pin for exactly one of them. A single-word `serialized` that a test compares to
+-- the catalog is worth more than a paragraph nothing checks.
+--
+-- NAMES, NOT SIGNATURES, in the blocks: onboard_federated_fleet_agent has 23
+-- parameters and a signature list would be unreadable. Bare names are only an
+-- identity while no two class members share a name, so the test asserts that
+-- separately (as it already does for this helper's overload count).
+--
+-- KNOWN SIBLING, NOT FIXED HERE. set_board_authority_ceiling's live body still
+-- carries the same overclaim as an inline comment: "Same board-keyed advisory lock
+-- every ceiling READER for authorization takes." Correcting it means recreating a
+-- SECURITY DEFINER function -- a far wider blast radius than this migration's --
+-- to change prose, so it is left to a deliberate decision instead of being smuggled
+-- in here. It is recorded POSITIVELY as a failing-when-fixed assertion in
+-- agent_board_atomic_fleet_onboarding.test.sql rather than as a note in a PR body,
+-- so it cannot be quietly lost.
+
+comment on function agent_board._lock_board_authority_ceiling(uuid) is
+  'Board-keyed transaction advisory lock serializing the ABSENCE of a board_authority_ceilings row. Held to commit. '
+  'WRITERS[serialized: set_board_authority_ceiling][UNSERIALIZED: (none)] -- the RPCs that write board_authority_ceilings. set_board_authority_ceiling takes this lock before its owner gate and its upsert, and therefore before the boards row that upsert reaches through board_authority_ceilings'' FK on INSERT. A direct table write by service_role bypasses every function-level lock (deliberate, 20260717000400). '
+  'READERS[serialized: grant_board_role, onboard_federated_fleet_agent][UNSERIALIZED: _redeem_unbounded_invite_for_agent, create_invite_link] -- the RPCs that read the ceiling for authorization through _grant_within_ceiling. onboard_federated_fleet_agent takes this lock BEFORE its boards row lock, because the writer reaches boards through that FK and the two orders must agree (inverted, they deadlocked). grant_board_role takes no boards row lock, so it makes no ordering claim. The UNSERIALIZED readers evaluate the ceiling WITHOUT serializing against its absence: a concurrent set_board_authority_ceiling can commit a first ceiling row after such a reader observed none, and it passes as default-owner. That race is real, known and accepted (#277); it is deliberately NOT closed by adding acquisitions, since each new edge in this lock graph has already produced a reproduced ABBA deadlock once (#269 F4). '
+  'Both lists are machine-compared against pg_proc by agent_board_atomic_fleet_onboarding.test.sql, which fails when this COMMENT and the catalog disagree -- do not edit a list by hand without the catalog. '
+  'Internal: it takes a lock with NO authorization check on an arbitrary board id, so it must never be grantable to authenticated.';

package/migrations/20260911000100_agent_board_ledger_revoked_board_creation.sql

@@ -0,0 +1,330 @@
+-- Consiliency/message-board#280 — revoked means revoked: a fleet-revoked agent cannot create a
+-- board either.
+--
+-- THE RATIFIED DECISION, and what it overturns. #276 (20260909000100) gated the three board
+-- authority chokepoints and both invite halves, and DELIBERATELY left `create_board` open. Its
+-- argument was narrow and sound: creating a fresh board confers nothing on anyone else, takes
+-- nothing from an existing board, and the ratified criterion for #276 spoke about GRANTING board
+-- roles — and here there is no grantee, because the board did not exist a moment earlier. The
+-- owner has since decided that the simpler operator-facing rule is worth more than that
+-- distinction. A fleet-revoked principal creates nothing. This migration implements the
+-- decision, not the debate.
+--
+-- THIS SUPERSEDES the "NAMED RESIDUAL (#280)" paragraph in 20260909000100's header. That file's
+-- BYTES ARE NOT EDITED HERE, and that is a rule rather than a preference: #264's release gate
+-- keys on the manifest's `aggregateSha256`, which moves for a byte edit to a shipped forward
+-- migration — so amending 20260909000100's prose would make the published 1.28.0 artifact stop
+-- being the bytes at 1.28.0, which is the exact failure #264 exists to catch. The record is
+-- corrected forward, here, and the pgTAP file's RESIDUAL assertions are flipped in the same
+-- commit so the change is behaviour rather than commentary.
+--
+-- ONE MECHANISM, NOT A SECOND. The gate is #276's `_assert_actor_not_fleet_revoked` — same
+-- helper, same predicate (the existence of an agent-subject `fleet_revocation_events` row), same
+-- 42501 with the `fleet_revoked:` prefix, same share lock. Every judgement recorded in
+-- 20260909000100 carries over unchanged and is deliberately NOT re-litigated here: agent-wide
+-- and binding-blind (JUDGEMENT 1), no supersession clause, and a principal that was never in a
+-- fleet has no row and is unaffected by construction (JUDGEMENT 2). That last one is the
+-- capability-regression risk on THIS function and it is the property most worth pinning, because
+-- `create_board` is the one gated site that every ordinary user reaches: the new pgTAP section
+-- asserts a NON-FLEET agent still creates a board and is still seeded its owner, POSITIVELY, on
+-- both the authenticated and the service_role route.
+--
+-- ============================================================================
+-- THE CLASS — create_board was ALREADY IN IT, listed as an exemption.
+-- ============================================================================
+-- #276's authority-write class is catalog-derived and matches ANY insert into
+-- `board_memberships` (its memberships arm was deliberately made shape-blind BECAUSE
+-- `create_board` seeds `role = 'owner'` with an INSERT that an UPDATE-shaped regex could not
+-- see). So this function has always been a member of the class; it was carried as one of four
+-- EXEMPTIONS with a positive disposition.
+--
+-- This migration moves it from exempt to gated, and the exemption's positive disposition is
+-- REMOVED rather than left behind claiming something that is no longer true. The old EXEMPTION B
+-- assertions (B1: it declares no role parameter; B2: the seat is the literal 'owner' for the
+-- board's own created_by_agent_id; B3: the slug-collision branch cannot elevate a membership on
+-- a pre-existing board) all remain TRUE — but they exist to license an exemption that no longer
+-- exists, and a live assertion that licenses nothing is the shape this repo has been bitten by.
+-- They are deleted, the exemption list drops from four to three, and the ledger-consult set
+-- grows from five to six. Both sets are derived from pg_catalog on each run, so the two edits
+-- must agree with the shipped schema or the difference NAMES create_board.
+--
+-- ============================================================================
+-- LOCK ORDER — stated in full, and checked against #276 and #269 by name.
+-- ============================================================================
+-- The gate is placed at the point where BOTH branches converge, immediately before
+-- `return query`, i.e. AFTER every write. That is the same placement, for the same reason, as
+-- `set_board_authority_ceiling`, `set_board_role_gate` and `create_invite_link`.
+--
+--   create_board, FRESH-BOARD branch
+--       boards(INSERT, a row this transaction created)
+--         -> board_memberships(INSERT; FK KEY SHARE on agents(actor) and on the new boards row)
+--         -> agents(SHARE)
+--   create_board, SLUG-COLLISION branch
+--       boards(FOR UPDATE, a pre-existing row)
+--         -> agents(SHARE)
+--
+-- Both are boards-before-agents, which is the canonical order (#194 established boards before
+-- auth.users before agents after a reproduced `deadlock detected`, and
+-- onboard_federated_fleet_agent takes advisory -> boards -> auth.users -> agents ->
+-- board_memberships -> agents -> agent_signing_keys). Every order above is a subsequence of that.
+--
+-- HOISTING THE GATE IS THE ABBA, and it is #269 F4's exact pair. Placed after actor resolution
+-- and before the slug read, the collision branch would become agents(SHARE) -> boards(FOR
+-- UPDATE): one session inside onboarding holds a `boards` row and wants `agents`, while a
+-- concurrent `create_board` holds that `agents` row at SHARE and wants that `boards` row at FOR
+-- UPDATE. SHARE and FOR UPDATE conflict, so both sides genuinely wait. That is the cycle #269
+-- reproduced as `deadlock detected` and #276 refused to re-create; the placement here is
+-- therefore load-bearing and must not be "tidied" to read more naturally.
+--
+-- Correctness is unaffected by the position: the function is one transaction, so the raise rolls
+-- back the boards INSERT (or UPDATE), the membership seat and the emitted membership event. A
+-- refused caller never sees a board id and no `owner_seed` event survives. This is #269's and
+-- #276's ratified argument for the identical placement, not a new one.
+--
+-- WHAT THE FOR SHARE ACTUALLY BUYS, per branch, measured rather than claimed — the same honesty
+-- 20260909000100 applied to the mint path:
+--
+--   * FRESH-BOARD branch: nothing. `board_memberships_agent_id_fkey` (and
+--     `board_memberships_created_by_agent_id_fkey`) make the seat INSERT take FOR KEY SHARE on
+--     the actor's `agents` row, and that insert PRECEDES the gate. KEY SHARE already conflicts
+--     with `revoke_fleet_subject`'s FOR UPDATE, so the serialization on this path is supplied by
+--     the FK; by the time the gate runs, this transaction already holds the row and upgrading
+--     KEY SHARE to SHARE adds no new wait. The isolation permutations for this branch pin the
+--     OUTCOME (it blocks, then fails closed, leaving no board and no seat) and CANNOT pin this
+--     lock, because the FK acquisition always precedes the gate.
+--   * SLUG-COLLISION branch: everything. The `boards` UPDATE sets name/description/status/
+--     visibility/metadata/updated_at and does NOT touch `created_by_agent_id`, so no FK trigger
+--     fires and no `agents` lock is taken anywhere else in that branch. The gate's FOR SHARE is
+--     the FIRST and ONLY `agents` lock on that path, which makes it the genuine serialization
+--     point — and gives this migration the lock discriminator the mint path could not provide.
+--     `ledger_authority_revoke.spec` permutation 11 is that discriminator: with the FOR SHARE
+--     removed, the reopen reads its own snapshot and SUCCEEDS instead of blocking.
+--
+-- CHECKED BY NAME against the functions #269 F4 and #276 named:
+--   * revoke_fleet_subject       — fleet_machines -> agents -> fleet_machine_agents ->
+--     fleet_revocation_events. It touches neither `boards` nor `board_memberships`, so it shares
+--     no second operand with either branch above: it can only be WAITED ON, which is the point.
+--   * _revoke_agent_principal    — agents -> agent_signing_keys. Same: no boards, no memberships.
+--   * onboard_federated_fleet_agent — advisory -> boards -> auth.users -> agents ->
+--     board_memberships -> agents -> agent_signing_keys. Both branches above are subsequences.
+--   * enroll_federated_identity  — takes `boards FOR KEY SHARE` (20260903000100:112-114, hoisted
+--     there by #194 to fix a reproduced deadlock) before it reaches any membership work. Again
+--     boards-before-agents; create_board does not invert against it.
+--
+-- ============================================================================
+-- THE agents/board_memberships CYCLE CLASS (signer_lifecycle section 9) — WHY create_board
+-- DOES NOT JOIN IT, ASSERTED RATHER THAN ASSUMED.
+-- ============================================================================
+-- #276 discovered, the hard way, that adding this same gate to `grant_board_role` put it in the
+-- class that section 9 pins from the call graph — every function row-locking BOTH `agents` and
+-- `board_memberships` must take the board advisory lock — and the assertion FAILED and named it.
+-- The obvious question here is whether create_board now joins that class too. It does not, and
+-- the reason is substantive rather than a regex accident:
+--
+--   * create_board's ONLY `board_memberships` write is the owner seat, and it happens ONLY on
+--     the fresh-board branch — against a `boards` row this same transaction inserted moments
+--     earlier. No other session can hold, see or contend for a membership row on a board that
+--     does not exist outside this transaction, so create_board cannot be one end of the
+--     (agents, board_memberships) cycle F4 reproduced. The `on conflict` clause is defensive and
+--     structurally unreachable on a board with no memberships.
+--   * And it COULD NOT take the advisory lock even if the class demanded it. That lock is keyed
+--     on the board id, which on the fresh path does not exist until after the `boards` INSERT —
+--     so taking it would give boards -> advisory, inverting against
+--     onboard_federated_fleet_agent's advisory -> boards. The fix would BE the cycle, which is
+--     the shape #276 rejected for the redeem path.
+--
+-- Section 9's assertion is left unchanged and re-run: it must still report exactly three members
+-- (grant_board_role, onboard_federated_fleet_agent, signed_grant_board_role). That it stays
+-- green is CHECKED after this migration is applied, not inferred from this paragraph.
+--
+-- ============================================================================
+-- SCOPE — THE COLLISION BRANCH IS GATED TOO, and that is more than "board creation".
+-- ============================================================================
+-- Recorded explicitly rather than shipped quietly. `create_board` is two operations behind one
+-- name: it creates a board, and — when the slug already exists AND the actor holds an ACTIVE
+-- owner membership on it — it renames/reopens/re-visibilities that existing board. The second
+-- branch writes NO authority relation and is therefore not in the class this issue is about.
+--
+-- The gate at the convergence point covers both, deliberately:
+--   * The ratified rule is a rule about a PRINCIPAL, not about a syntax. "A fleet-revoked agent
+--     cannot create a board, but can still flip an existing board to `visibility = 'open'` and
+--     `status = 'active'`" is precisely the conditional, hard-to-state behaviour the owner's
+--     decision replaced.
+--   * Reopening an archived board and making it publicly visible is an operator act on a
+--     resource that DOES already exist and DOES already have other members — materially closer
+--     to the invite half #276 closed than to the "confers nothing on anyone else" argument that
+--     licensed the original exemption.
+-- A revoked NON-owner colliding on a slug still gets the pre-existing `board slug already in
+-- use` 42501 from the owner check, which runs first; the fleet_revoked refusal is reachable only
+-- by the actor who would otherwise have been allowed through.
+--
+-- ============================================================================
+-- BLAST RADIUS — create_board is `authenticated`-callable and on a live path.
+-- ============================================================================
+-- IN-DATABASE CALLERS: NONE. Swept from pg_catalog on the shipped schema, over every namespace
+-- and all three carriers of SQL — `pg_proc.prosrc ~ '\mcreate_board\s*\('` (excluding the
+-- function itself), `pg_views.definition`, and `pg_trigger` — exactly zero referrers. So unlike
+-- grant_board_role (whose signed wrapper inherits the gate by construction) there is no second
+-- in-schema route to keep in step, and no in-DB caller can be broken by this change.
+--
+-- OUT-OF-DATABASE CALLERS, enumerated and unchanged by this migration — the signature, the
+-- return shape and the ACL are all identical, so nothing needs a client release:
+--   * SDK      AgentBoardClient.createBoard (packages/agent-board-client/src/client.ts) — posts
+--              to the `create_board` RPC; `create_board` is in the client's actor-argument map
+--              and its M-posture table, neither of which changes.
+--   * MCP      the `agent_board.create_board` tool (packages/agent-board-mcp/src/tools.ts).
+--   * CLI      the standalone board command, AND the enroll flow's DEFAULT post-enroll intent
+--              (`kind: "create_board"` with the agent's own slug —
+--              packages/agent-board-client/src/enroll_command.ts).
+--
+-- THE ONE LIVE CONSEQUENCE WORTH NAMING, because a subscriber should read it here and not
+-- discover it: a FLEET-REVOKED agent that re-runs enroll now gets a durable enrollment and then
+-- a `fleet_revoked:` failure at the default board-create step. Enrollment itself is untouched.
+-- That is the decision working exactly as ratified — a revoked principal ends up enrolled and
+-- boardless rather than enrolled and owning a fresh namespace — but it is a behaviour change on
+-- a path every CLI user hits, and it is the item for an adopter's migration checklist. A
+-- never-revoked agent, and any principal that was never in a fleet at all, is unaffected: there
+-- is no ledger row to find (JUDGEMENT 2), and the pgTAP file asserts that positively rather than
+-- by the absence of a refusal.
+--
+-- CREATE OR REPLACE preserves the ACL and the COMMENT, but both are restated below anyway — the
+-- behaviour changed, so the comment must, and this repo has been bitten by a recreation that
+-- silently re-granted PUBLIC.
+
+-- ---------------------------------------------------------------------------
+-- create_board — verbatim from 20260807000100:272 plus ONE line: the #276 gate at the point
+-- where both branches converge. Nothing else in the body changes.
+-- ---------------------------------------------------------------------------
+create or replace function agent_board.create_board(p_created_by_agent_id uuid, p_slug text, p_name text, p_description text DEFAULT NULL::text, p_metadata jsonb DEFAULT '{}'::jsonb, p_visibility text DEFAULT 'private'::text)
+ RETURNS TABLE(board_id uuid, slug text, name text, status text, visibility text, created_at timestamp with time zone, updated_at timestamp with time zone)
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO 'agent_board', 'public'
+as $$
+#variable_conflict use_column
+declare
+  v_seed_state text;
+  v_actor uuid;
+  v_existing agent_board.boards%rowtype;
+  v_board agent_board.boards%rowtype;
+begin
+  if nullif(trim(p_slug), '') is null or nullif(trim(p_name), '') is null then
+    raise exception 'board slug and name are required' using errcode = '22023';
+  end if;
+  if coalesce(p_visibility, 'private') not in ('private', 'invite_only', 'open', 'directory_hidden') then
+    raise exception 'invalid board visibility' using errcode = '22023';
+  end if;
+
+  -- Effective actor: service_role -> supplied arg (create-on-behalf-of);
+  -- authenticated -> current_agent_id() and rejects arg <> current (42501).
+  v_actor := agent_board._resolved_actor_agent_id(p_created_by_agent_id, 'p_created_by_agent_id');
+
+  if not exists (select 1 from agent_board.agents where id = v_actor) then
+    raise exception 'agent not found' using errcode = 'P0002';
+  end if;
+
+  select * into v_existing
+    from agent_board.boards b
+   where b.slug = trim(p_slug);
+
+  if found then
+    -- Slug-collision path is OWNER-ONLY, keyed on CURRENT authority: the actor must
+    -- hold an ACTIVE owner-role membership on the existing board — NOT merely be its
+    -- original `created_by_agent_id`. A demoted or departed original creator no longer
+    -- owns the board and must NOT be able to re-open/rename/flip-visibility it.
+    if not exists (
+      select 1 from agent_board.board_memberships m
+       where m.board_id = v_existing.id
+         and m.agent_id = v_actor
+         and m.role = 'owner'
+         and m.membership_state in ('joined', 'subscribed')
+    ) then
+      raise exception 'board slug already in use' using errcode = '42501';
+    end if;
+
+    update agent_board.boards as b
+       set name = trim(p_name),
+           description = nullif(trim(p_description), ''),
+           status = 'active',
+           visibility = coalesce(p_visibility, 'private'),
+           metadata = coalesce(b.metadata, '{}'::jsonb) || coalesce(p_metadata, '{}'::jsonb),
+           updated_at = now()
+     where b.id = v_existing.id
+    returning * into v_board;
+    -- No owner re-seed: the owner was seeded at this board's original creation, and
+    -- re-promoting on every create_board would resurrect a deliberately demoted owner.
+  else
+    insert into agent_board.boards as b(slug, name, description, created_by_agent_id, visibility, metadata)
+    values (
+      trim(p_slug),
+      trim(p_name),
+      nullif(trim(p_description), ''),
+      v_actor,
+      coalesce(p_visibility, 'private'),
+      coalesce(p_metadata, '{}'::jsonb)
+    )
+    returning * into v_board;
+
+    -- Seed the creator's owner membership, bound to the board's ACTUAL
+    -- created_by_agent_id (never the raw param). Idempotent against the active
+    -- partial-unique index so at most one active owner row exists.
+    insert into agent_board.board_memberships as bm(board_id, agent_id, membership_state, role, created_by_agent_id)
+    values (v_board.id, v_board.created_by_agent_id, 'joined', 'owner', v_board.created_by_agent_id)
+    on conflict (board_id, agent_id) where (membership_state in ('joined', 'subscribed'))
+      do update set role = 'owner', updated_at = now()
+    returning bm.membership_state into v_seed_state;
+    -- The creator seeds their OWN owner seat, so the session is the subject and this emits
+    -- target-authored. Under service_role it emits operator-designated instead -- correct
+    -- either way, because the helper reads the session rather than being told.
+    --
+    -- v_seed_state, NOT a literal 'joined'. The ON CONFLICT above lifts only the ROLE, so a
+    -- board whose creator already holds a `subscribed` row stays subscribed while a literal
+    -- would record `joined` -- a ledger contradicting the table. Same defect the redemption
+    -- path had; fixing one instance without sweeping the class is how it survived here.
+    perform agent_board._emit_membership_event(v_board.id, v_board.created_by_agent_id, v_seed_state, 'owner_seed');
+  end if;
+
+  -- #280. Revoked means revoked: a fleet-revoked agent creates nothing. #276 gated the three
+  -- authority chokepoints and both invite halves and left this function open on a stated
+  -- argument (a fresh board confers nothing on anyone else); the owner overturned that in favour
+  -- of the simpler rule, and this line is the whole of the change.
+  --
+  -- SITED HERE, at the convergence of both branches and AFTER every write, for the lock order.
+  -- Fresh branch: boards(insert) -> board_memberships(insert, FK KEY SHARE on agents) ->
+  -- agents(SHARE). Collision branch: boards(FOR UPDATE) -> agents(SHARE). Both are
+  -- boards-before-agents, the canonical order. HOISTED above the slug read it would become
+  -- agents(SHARE) -> boards(FOR UPDATE) on the collision branch, which is #269 F4's exact ABBA
+  -- against onboard_federated_fleet_agent's boards -> agents. One transaction, so this raise
+  -- rolls back the board, the owner seat and the owner_seed event alike -- position costs
+  -- nothing in correctness and everything in deadlock safety.
+  --
+  -- On the fresh branch the FK on the seat insert has ALREADY taken KEY SHARE on this row, so
+  -- the FOR SHARE is a free upgrade and is NOT what serializes that path (see the header). On
+  -- the collision branch it is the only agents lock there is, and it is the serialization point.
+  perform agent_board._assert_actor_not_fleet_revoked(v_actor, 'create_board');
+
+  return query
+  select v_board.id, v_board.slug, v_board.name, v_board.status, v_board.visibility, v_board.created_at, v_board.updated_at;
+end;
+$$;
+
+comment on function agent_board.create_board(uuid, text, text, text, jsonb, text) is
+  'Creates a board and seeds the resolved actor''s owner membership; on a slug COLLISION it '
+  'instead renames/reopens/re-visibilities the existing board, but only for an actor holding an '
+  'ACTIVE owner-role membership on it (else 42501 ''board slug already in use''), and it never '
+  're-seeds an owner. Actor is _resolved_actor_agent_id: service_role uses the supplied arg '
+  '(create-on-behalf-of), authenticated uses current_agent_id() and fails closed on mismatch. '
+  '#280: the resolved actor is then checked against the fleet revocation ledger by '
+  '_assert_actor_not_fleet_revoked -- an agent carrying an agent-subject fleet_revocation_events '
+  'row cannot create a board at all (42501, ''fleet_revoked:''), the same answer '
+  'evaluate_fleet_sender_policy already gives it on the send path and #276 gave it on the five '
+  'authority routes. This CLOSES the residual #276 named and left open. The gate covers BOTH '
+  'branches by design, so a revoked owner also cannot reopen or re-visibility an existing board. '
+  'It is placed AFTER the writes so the lock order stays boards -> agents (fresh branch: '
+  'boards -> board_memberships -> agents); hoisting it would give agents -> boards on the '
+  'collision branch and invert against onboard_federated_fleet_agent, the ABBA #269 reproduced. '
+  'The function is one transaction, so the raise rolls back the board, the owner seat and the '
+  'owner_seed event. A principal with no fleet binding has no ledger row and is unaffected.';
+
+revoke all on function agent_board.create_board(uuid, text, text, text, jsonb, text) from public, anon;
+grant execute on function agent_board.create_board(uuid, text, text, text, jsonb, text) to authenticated, service_role;