@consiliency/agent-board-schema 1.28.0 → 1.38.0

package/tests/isolation/specs/task_thread_lock_order.spec

@@ -0,0 +1,197 @@
+# Consiliency/message-board#281 (R1) — append_task_event must take THREADS BEFORE TASKS,
+# and must still serialise its event_sequence computation.
+#
+# THE DEFECT. #290's FK-aware detector found 40 unserialised ABBA rows on
+# `tasks <-> threads`, the largest block of the 186 and the only one whose operand
+# coincidence is an ordinary workload:
+#     append_task_event:  tasks (explicit FOR UPDATE)  ->  threads (KEY SHARE, task_events.thread_id FK)
+#     post_message:       threads (UPDATE, in _next_thread_message_sequence)  ->  tasks (KEY SHARE, messages.task_id FK)
+# The colliding operand is `postMessage({ threadId: task.threadId, taskId: task.id })`
+# concurrent with any agent claiming/delegating/resolving that task.
+#
+# READ THIS BEFORE READING THE GOLDEN: THE REAL PAIR DOES NOT DEADLOCK, AND PERMUTATIONS 2
+# AND 3 ARE THE EVIDENCE FOR THAT, NOT A FAILED REPRODUCTION.
+#   `_next_thread_message_sequence` updates threads.last_message_sequence / updated_at.
+#   `threads` has exactly one unique index (threads_pkey on id), so neither column is a key
+#   column and that UPDATE takes FOR NO KEY UPDATE — which does NOT conflict with the FOR
+#   KEY SHARE append_task_event takes on threads through task_events_thread_id_fkey. (The
+#   matrix is pinned verbatim as FKL-2 in agent_board_fk_lock_edges.test.sql:
+#   `no key update/key share=false`.) So post_message blocks on append_task_event's
+#   `tasks FOR UPDATE`, and append_task_event never blocks on post_message's threads lock:
+#   ONE-WAY BLOCKING, NO CYCLE. The detector reports 40 rows because `_acq` aggregates any
+#   write-update to mode `update` — it over-reports by design.
+#   Permutations 2 and 3 therefore show block-then-complete in both directions, and they
+#   showed the same thing BEFORE the fix. No pre-fix reproduction of the real pair is
+#   claimed here, because none exists.
+#
+# THE "probe" SESSION IS AN ORDER INSTRUMENT, NOT A post_message STAND-IN. State it that
+# way or a reader will draw the wrong conclusion from permutation 1.
+#   * It takes `threads FOR UPDATE` then `tasks FOR UPDATE`. No DUAL-RELATION shipped path
+#     takes threads FOR UPDATE — and the scope of that claim is load-bearing, so read it
+#     against its evidence rather than past it. agent_board_task_thread_lock_order.test.sql
+#     TT-1 enumerates the functions that touch BOTH relations, and across that class the
+#     only threads modes are `key share` and `update`(write-update, i.e. FOR NO KEY UPDATE).
+#     TT-1's class is dual-relation BY CONSTRUCTION, so a threads-only caller is outside it
+#     — out of scope, not a counterexample.
+#   * AND THERE IS SUCH A CALLER. `create_or_find_thread` takes a real
+#     `select … from agent_board.threads … for update`
+#     (20260517000000_agent_board_addressing.sql:265-273), and it is the ONLY function in
+#     the bundle holding an EXPLICIT lock on threads — catalog-derived: exactly one row with
+#     `rel_name = agent_board.threads and via = 'textual'`, everything else that conflicts
+#     with KEY SHARE on threads does so through `write-update`. It cannot close a cycle here
+#     because it takes NO lock on `tasks` at all (its only other edges are FK KEY SHARE on
+#     `agents` and `boards`), so it is one-way blocking against append_task_event in either
+#     direction. An earlier draft of this header claimed "NO shipped caller takes threads
+#     FOR UPDATE" and cited TT-1 for it: a universal claim resting on a class-scoped
+#     assertion that never covered it. The citation made it look verified. It was false.
+#   * It is deliberately STRONGER than the real pair's modes. That is its purpose: those
+#     modes do not conflict, so post_message vs append_task_event cannot make the ORDER
+#     observable. FOR UPDATE conflicts with FOR KEY SHARE, which turns the order into
+#     something isolationtester can see and a golden can pin.
+#   * BUT DO NOT READ "INSTRUMENT" AS "HYPOTHETICAL" — it is closer to a shipped caller than
+#     that word suggests, and this is the reason not to prune this permutation as synthetic.
+#     `create_or_find_thread` ALREADY performs the probe's first step for real, on its reuse
+#     path. The probe is that function PLUS a `tasks` lock, and nothing else. Measured with a
+#     three-session run (real create_or_find_thread, real append_task_event, and a
+#     `tasks … for key share` observer): PRE-FIX the observer WAITS, because append_task_event
+#     blocked on the thread lock WHILE HOLDING `tasks FOR UPDATE` and convoyed every other
+#     writer of that task; POST-FIX the observer completes immediately, because the appender
+#     now waits holding nothing. So the ordering this permutation pins already pays off
+#     today — the synthetic part is only the second step.
+#   * What it proves is exactly this: with append_task_event tasks-first, a threads-first
+#     adversary deadlocks; with append_task_event threads-first, the same adversary merely
+#     serialises. That is the property the fix claims, and it is the property that becomes
+#     load-bearing the day any real function strengthens its threads lock.
+#   * VERIFIED PRE-FIX, and quoted at the width it was actually observed. Against the
+#     20260816000100 body, permutation 1 emits `step probe_tasks:  <waiting ...>` and then
+#     `step append_run: <... completed>` / `ERROR:  deadlock detected` -- isolationtester
+#     reports the primary line only, not the `while locking tuple in relation ...` DETAIL,
+#     so no DETAIL is quoted here. Against the 20260913000100 body the same permutation
+#     produces the serialisation in this golden. Permutations 2, 3 and 4 are BYTE-IDENTICAL
+#     under both bodies, which is the reachability finding above stated as an observation.
+#
+# PERMUTATION 4 IS THE GUARD THE REORDER COULD HAVE BROKEN. The `tasks FOR UPDATE` is not
+# decoration: it is the mutual exclusion behind `select coalesce(max(event_sequence),0)+1`
+# against task_events_task_id_event_sequence_key. Two concurrent appends on one task must
+# serialise and produce 1 then 2. Mutation-verified: delete the FOR UPDATE and this
+# permutation stops blocking and ends in a duplicate-key error instead.
+
+setup
+{
+  insert into agent_board.agents(id, agent_type, kind, handle, display_name, status)
+  values ('7a810000-0000-4000-8000-000000000001','agent','agent','r1iso-actor','R1 ISO Actor','active');
+
+  insert into agent_board.threads(id, thread_type, created_by_agent_id, subject)
+  values ('7a820000-0000-4000-8000-000000000001','coordination',
+          '7a810000-0000-4000-8000-000000000001','R1 ISO thread');
+
+  insert into agent_board.tasks(id, thread_id, created_by_agent_id, title, status)
+  values ('7a830000-0000-4000-8000-000000000001','7a820000-0000-4000-8000-000000000001',
+          '7a810000-0000-4000-8000-000000000001','R1 ISO task','pending');
+}
+
+teardown
+{
+  delete from agent_board.messages where thread_id = '7a820000-0000-4000-8000-000000000001';
+  delete from agent_board.task_events where task_id = '7a830000-0000-4000-8000-000000000001';
+  delete from agent_board.tasks where id = '7a830000-0000-4000-8000-000000000001';
+  delete from agent_board.threads where id = '7a820000-0000-4000-8000-000000000001';
+  delete from agent_board.agents where id = '7a810000-0000-4000-8000-000000000001';
+}
+
+# The real append, unmodified. Only deterministic columns reach the golden — the event id is
+# a fresh uuid and the timestamps are wall-clock.
+session "append"
+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;
+}
+step "append_commit" { COMMIT; }
+
+# A second real append, for the event_sequence guard in permutation 4.
+session "append2"
+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;
+}
+step "append2_commit" { COMMIT; }
+
+# The real post_message, task-attached into the task's own thread — the exact operand
+# coincidence #281 R1 is about.
+session "post"
+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;
+}
+step "post_commit" { COMMIT; }
+
+# THE ORDER INSTRUMENT. See the header: threads FOR UPDATE is stronger than any shipped
+# caller's threads lock, on purpose, because the shipped modes do not conflict.
+session "probe"
+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;
+}
+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;
+}
+step "probe_commit" { COMMIT; }
+
+session "check"
+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;
+}
+
+# 1. THE ORDER, made observable. probe holds threads(H) FOR UPDATE; append then runs.
+#    TASKS-FIRST (pre-fix), append takes tasks(T) FOR UPDATE and blocks wanting threads(H)
+#    KEY SHARE; probe_tasks then wants that same task row and the server aborts one with
+#    `deadlock detected`. THREADS-FIRST (fixed), append blocks at its FIRST lock statement
+#    holding nothing, probe completes, and the append drains afterwards. The difference
+#    between those two worlds is the whole golden.
+permutation "probe_begin" "probe_threads" "append_begin" "append_run" "probe_tasks" "probe_commit" "append_commit" "check"
+
+# 2. THE REAL PAIR, append first. append holds tasks FOR UPDATE; post_message needs
+#    tasks KEY SHARE for the messages.task_id FK and blocks. It is released by the commit,
+#    never by a deadlock. This is one-way blocking and it is the same before and after the
+#    fix — see the header.
+permutation "append_begin" "append_run" "post_begin" "post_run" "append_commit" "post_commit" "check"
+
+# 3. THE REAL PAIR, post first. post holds threads(H) FOR NO KEY UPDATE and tasks(T) KEY
+#    SHARE. append's threads KEY SHARE is GRANTED — the two modes do not conflict, which is
+#    the reachability finding stated as an observation rather than as prose — and it then
+#    blocks on tasks FOR UPDATE until post commits. Again no cycle in either direction.
+permutation "post_begin" "post_run" "append_begin" "append_run" "post_commit" "append_commit" "check"
+
+# 4. THE event_sequence GUARD, positively. Two concurrent appends on ONE task: the second
+#    blocks on the first's `tasks FOR UPDATE` and only then computes its sequence, so the
+#    two events are 1 and 2 and the unique constraint is never tested. Remove that FOR
+#    UPDATE and this permutation stops blocking and ends in a duplicate-key error — which is
+#    the mutation that pins this assertion.
+permutation "append_begin" "append_run" "append2_begin" "append2_run" "append_commit" "append2_commit" "check"

package/tests/seeds/20260916000100_agent_board_federated_identity_injective_slug.sql.pre.sql

@@ -0,0 +1,196 @@
+-- Pre-migration seed for 20260916000100 (message-board#246, change 2 of 3).
+--
+-- WHY A SEED AND NOT A FIXTURE INSIDE THE TEST. The thing under test is the SHIPPED
+-- backfill, which runs once, inside the migration. A fixture created inside the pgTAP
+-- transaction would be created AFTER the migration had already run and would prove
+-- nothing about it. The message-board#103 pre-migration seed hook exists for exactly
+-- this: these rows are inserted immediately BEFORE 20260916000100 applies, in the
+-- migration-N-1 schema, so the backfill meets real pre-existing rows and
+-- agent_board_federated_identity_injective_slug.test.sql asserts what it actually
+-- wrote.
+--
+-- These rows model the production shape measured on mqccjfqngptkemnchlko (2026-08-16):
+-- one federated owner uid, its own human agent row whose handle IS the slug, and
+-- several agents that reference it only by owner_user_id. The real pair is a live
+-- person's identity and is deliberately not reproduced here; these are synthetic pairs
+-- whose slugs were computed with the same two expressions the migration uses.
+--
+-- Three named identities, one per recovery arm the backfill has to get right:
+--
+--   F1 d2460001-… HUMAN ARM      pair P1, recoverable via agents.auth_user_id.
+--                                Carries a SECOND agent stamped with the SAME pair, so
+--                                a backfill counting rows instead of DISTINCT pairs
+--                                refuses it -- which is what production's six-agent
+--                                owner would do.
+--   F2 d2460002-… OWNER-ONLY ARM pair P2, NO agent on that auth_user_id at all. The
+--                                only route to the pair is owner_user_id. Drop that
+--                                arm and this row becomes unrecoverable.
+--   F3 d2460003-… DECOY ARM      pair P3, plus an owned agent stamped with an unrelated
+--                                pair that does NOT reproduce F3's slug. Drop the
+--                                "reproduces the current slug" filter and F3 suddenly
+--                                has two candidate pairs and is refused.
+--   F4 d2460004-… DIVERGENT ARM  pair P4, but its raw_user_meta_data.slug and its
+--                                identity_data sub/slug hold values that are NOT its old
+--                                slug. The backfill rewrites those two only when they
+--                                EQUAL the old slug (a `case` arm each), and F1-F3 all
+--                                have them equal -- so before F4 existed, making both arms
+--                                UNCONDITIONAL survived every assertion. F4 is the
+--                                complement of BF-2d (which pins the same narrowness for
+--                                agents.handle) and it is the assertion that was missing.
+--
+-- Slugs, computed from the pairs below (old = the ambiguous `issuer || '|' || subject`,
+-- new = the netstring form the migration introduces):
+--   P1 https://fixture-246.example/idp-a  fixture-246-subject-a
+--        old fed-human-d50f81b6913e066dba4c19f5cb6b202a
+--        new fed-human-6c056fe12e1fb58fb2c072ff8bd9a613
+--   P2 https://fixture-246.example/idp-b  fixture-246-subject-b
+--        old fed-human-7ab9c8b527e1cce671305defc65fe7c0
+--        new fed-human-ec861cc1407f8f585e94cb9e8ece6039
+--   P3 https://fixture-246.example/idp-c  fixture-246-subject-c
+--        old fed-human-def7953eb096d786392090ce33952d9d
+--        new fed-human-d4211005ca6d96ac0f8a90d2065dceda
+--   P3-decoy https://fixture-246.example/idp-decoy  fixture-246-subject-decoy
+--        old fed-human-0897be463845203cbc1c6099e8befcb0  (reproduces nothing here)
+--   P4 https://fixture-246.example/idp-d  fixture-246-subject-d
+--        old fed-human-38b45a2207cfb4847a4c62c9973cd676
+--        new fed-human-25bf058f71a25339995a9a2012ced65b
+--
+-- The literals are spelled out rather than computed so that the seed and the test agree
+-- on a NAMED value: a seed that derived the slug with the same expression as the code
+-- under test would move silently whenever that expression moved.
+
+-- The owner auth.users rows, in the pre-migration (old-slug) form _ensure_agent_auth_user
+-- would have written them.
+insert into auth.users (
+  id, instance_id, email, email_confirmed_at, encrypted_password,
+  created_at, updated_at, raw_app_meta_data, raw_user_meta_data, aud, role
+)
+values
+  ('d2460001-0000-4000-8000-000000000001', '00000000-0000-0000-0000-000000000000',
+   'agent+fed-human-d50f81b6913e066dba4c19f5cb6b202a@agent-board.local', now(), '',
+   now(), now(),
+   jsonb_build_object('provider', 'agent_board', 'providers', jsonb_build_array('agent_board')),
+   jsonb_build_object('slug', 'fed-human-d50f81b6913e066dba4c19f5cb6b202a',
+                      'issuer', 'agent_board.provision_agent'),
+   'authenticated', 'authenticated'),
+  ('d2460002-0000-4000-8000-000000000002', '00000000-0000-0000-0000-000000000000',
+   'agent+fed-human-7ab9c8b527e1cce671305defc65fe7c0@agent-board.local', now(), '',
+   now(), now(),
+   jsonb_build_object('provider', 'agent_board', 'providers', jsonb_build_array('agent_board')),
+   jsonb_build_object('slug', 'fed-human-7ab9c8b527e1cce671305defc65fe7c0',
+                      'issuer', 'agent_board.provision_agent'),
+   'authenticated', 'authenticated'),
+  ('d2460003-0000-4000-8000-000000000003', '00000000-0000-0000-0000-000000000000',
+   'agent+fed-human-def7953eb096d786392090ce33952d9d@agent-board.local', now(), '',
+   now(), now(),
+   jsonb_build_object('provider', 'agent_board', 'providers', jsonb_build_array('agent_board')),
+   jsonb_build_object('slug', 'fed-human-def7953eb096d786392090ce33952d9d',
+                      'issuer', 'agent_board.provision_agent'),
+   'authenticated', 'authenticated'),
+  -- F2's owned agent needs an auth_user_id of its own, so that F2's owner uid is
+  -- reachable ONLY through owner_user_id. This row is not a fed-human identity.
+  ('d2460002-0000-4000-8000-0000000000a2', '00000000-0000-0000-0000-000000000000',
+   'agent+mb246-fixture-a2@agent-board.local', now(), '',
+   now(), now(),
+   jsonb_build_object('provider', 'agent_board', 'providers', jsonb_build_array('agent_board')),
+   jsonb_build_object('slug', 'mb246-fixture-a2', 'issuer', 'agent_board.provision_agent'),
+   'authenticated', 'authenticated'),
+  -- F4: the email carries the old slug, but the meta slug deliberately does NOT. An
+  -- unconditional rewrite of raw_user_meta_data.slug would clobber this value; the
+  -- shipped `case` arm leaves it alone.
+  ('d2460004-0000-4000-8000-000000000004', '00000000-0000-0000-0000-000000000000',
+   'agent+fed-human-38b45a2207cfb4847a4c62c9973cd676@agent-board.local', now(), '',
+   now(), now(),
+   jsonb_build_object('provider', 'agent_board', 'providers', jsonb_build_array('agent_board')),
+   jsonb_build_object('slug', 'mb246-f4-legacy-meta-slug', 'issuer', 'agent_board.provision_agent'),
+   'authenticated', 'authenticated')
+-- RESET, not insert-if-absent. The replay database is reused between runs and the
+-- previous run's backfill already moved these rows to the new slug; an insert that
+-- skipped on conflict would leave the second run asserting a move that had already
+-- happened. Restoring the OLD form here makes every run exercise the backfill.
+on conflict (id) do update
+  set email              = excluded.email,
+      raw_user_meta_data = excluded.raw_user_meta_data;
+
+insert into auth.identities (
+  id, user_id, provider_id, provider, identity_data, last_sign_in_at, created_at, updated_at
+)
+values
+  ('d2460011-0000-4000-8000-000000000001', 'd2460001-0000-4000-8000-000000000001',
+   'fed-human-d50f81b6913e066dba4c19f5cb6b202a', 'agent_board',
+   jsonb_build_object('sub', 'fed-human-d50f81b6913e066dba4c19f5cb6b202a',
+                      'slug', 'fed-human-d50f81b6913e066dba4c19f5cb6b202a'),
+   now(), now(), now()),
+  ('d2460012-0000-4000-8000-000000000002', 'd2460002-0000-4000-8000-000000000002',
+   'fed-human-7ab9c8b527e1cce671305defc65fe7c0', 'agent_board',
+   jsonb_build_object('sub', 'fed-human-7ab9c8b527e1cce671305defc65fe7c0',
+                      'slug', 'fed-human-7ab9c8b527e1cce671305defc65fe7c0'),
+   now(), now(), now()),
+  ('d2460013-0000-4000-8000-000000000003', 'd2460003-0000-4000-8000-000000000003',
+   'fed-human-def7953eb096d786392090ce33952d9d', 'agent_board',
+   jsonb_build_object('sub', 'fed-human-def7953eb096d786392090ce33952d9d',
+                      'slug', 'fed-human-def7953eb096d786392090ce33952d9d'),
+   now(), now(), now()),
+  -- F4: provider_id DOES carry the old slug (so the update's WHERE matches and the row is
+  -- genuinely visited), while identity_data.sub/slug deliberately do not. The two `case`
+  -- arms must leave those alone; provider_id, which is rewritten unconditionally, moves.
+  ('d2460014-0000-4000-8000-000000000004', 'd2460004-0000-4000-8000-000000000004',
+   'fed-human-38b45a2207cfb4847a4c62c9973cd676', 'agent_board',
+   jsonb_build_object('sub', 'mb246-f4-legacy-sub', 'slug', 'mb246-f4-legacy-slug'),
+   now(), now(), now())
+on conflict (id) do update
+  set provider_id   = excluded.provider_id,
+      identity_data = excluded.identity_data;
+
+-- F1: the human agent whose HANDLE is the slug (the surface a relabel would move), plus
+-- a second agent carrying the SAME stamp so DISTINCT is load-bearing.
+insert into agent_board.agents (
+  id, agent_type, kind, handle, display_name, status, auth_user_id, owner_user_id, metadata
+)
+values
+  ('d2460101-0000-4000-8000-000000000001', 'human', 'human',
+   'fed-human-d50f81b6913e066dba4c19f5cb6b202a', 'MB246 fixture F1 human', 'active',
+   'd2460001-0000-4000-8000-000000000001', 'd2460001-0000-4000-8000-000000000001',
+   jsonb_build_object('federation', jsonb_build_object(
+     'issuer', 'https://fixture-246.example/idp-a',
+     'subject', 'fixture-246-subject-a'))),
+  ('d2460102-0000-4000-8000-000000000001', 'agent', 'agent',
+   'mb246-fixture-f1-owned', 'MB246 fixture F1 owned agent', 'active',
+   null, 'd2460001-0000-4000-8000-000000000001',
+   jsonb_build_object('federation', jsonb_build_object(
+     'issuer', 'https://fixture-246.example/idp-a',
+     'subject', 'fixture-246-subject-a'))),
+
+  -- F2: owner reachable ONLY via owner_user_id.
+  ('d2460201-0000-4000-8000-000000000002', 'agent', 'agent',
+   'mb246-fixture-a2', 'MB246 fixture F2 owned agent', 'active',
+   'd2460002-0000-4000-8000-0000000000a2', 'd2460002-0000-4000-8000-000000000002',
+   jsonb_build_object('federation', jsonb_build_object(
+     'issuer', 'https://fixture-246.example/idp-b',
+     'subject', 'fixture-246-subject-b'))),
+
+  -- F3: the true pair, plus a decoy stamp that does not reproduce F3's slug.
+  ('d2460301-0000-4000-8000-000000000003', 'human', 'human',
+   'fed-human-def7953eb096d786392090ce33952d9d', 'MB246 fixture F3 human', 'active',
+   'd2460003-0000-4000-8000-000000000003', 'd2460003-0000-4000-8000-000000000003',
+   jsonb_build_object('federation', jsonb_build_object(
+     'issuer', 'https://fixture-246.example/idp-c',
+     'subject', 'fixture-246-subject-c'))),
+  ('d2460302-0000-4000-8000-000000000003', 'agent', 'agent',
+   'mb246-fixture-f3-decoy', 'MB246 fixture F3 decoy-stamped agent', 'active',
+   null, 'd2460003-0000-4000-8000-000000000003',
+   jsonb_build_object('federation', jsonb_build_object(
+     'issuer', 'https://fixture-246.example/idp-decoy',
+     'subject', 'fixture-246-subject-decoy'))),
+
+  -- F4: an ordinary human row whose handle IS the slug, so the row is recovered and
+  -- re-keyed normally. Its value is entirely in the divergent meta/identity_data above.
+  ('d2460401-0000-4000-8000-000000000004', 'human', 'human',
+   'fed-human-38b45a2207cfb4847a4c62c9973cd676', 'MB246 fixture F4 human', 'active',
+   'd2460004-0000-4000-8000-000000000004', 'd2460004-0000-4000-8000-000000000004',
+   jsonb_build_object('federation', jsonb_build_object(
+     'issuer', 'https://fixture-246.example/idp-d',
+     'subject', 'fixture-246-subject-d')))
+on conflict (id) do update
+  set handle   = excluded.handle,
+      metadata = excluded.metadata;