@@ -174,6 +174,17 @@ else
   # a write while another connection holds the write lock, because waiting there could deadlock.
   # No timeout affects that path. The raise is kept because it does help ordinary lock waiting,
   # but it is not the fix for what is recorded as R26 in docs/06-risk-register.md.
+  #
+  # And the line below does not reach a sandboxed test at all, which is worth knowing before
+  # trusting it. `Ecto.Adapters.SQL.Sandbox.post_checkout/3` begins each test's transaction with
+  # `handle_begin([mode: :transaction] ++ opts, ...)`, and `Exqlite.Connection` resolves the mode
+  # as `Keyword.get(options, :mode, state.default_transaction_mode)`, so the explicit option wins
+  # over this setting and `:transaction` is a plain DEFERRED `BEGIN`. Every sandboxed test is
+  # therefore a DEFERRED transaction, and one that reads before it writes is on R26's unguarded
+  # upgrade path with no timeout able to help. `default_transaction_mode` below still governs the
+  # transactions the application itself opens, which is why it stays.
+  # `test/trinity/repo/sandbox_transaction_mode_test.exs` asserts both dependency lines so this
+  # paragraph fails rather than rots.
   config :trinity, Trinity.Repo,
     database: Path.expand("../trinity_test.db", __DIR__),
     pool: Ecto.Adapters.SQL.Sandbox,
@@ -260,6 +271,18 @@ config :trinity, :skills,
   # user_dir at a temporary directory first.
   pending_dir: Path.join(System.tmp_dir!(), "trinity-test-pending-skills"),
   watch: true,
+  # The shipped poll is every second (lib/trinity/skills/registry.ex) and it compares mtimes at
+  # one-second resolution, so its worst case is about two seconds, which is the whole of slice
+  # 040 AC3's bound. With no margin, the test asserting that bound failed intermittently on a
+  # loaded runner while the watcher was behaving exactly as designed. A shorter interval here
+  # leaves the mechanism under test, the fs_poll backend over mtimes, and takes the runner's
+  # scheduler out of the measurement. The shipped default is unchanged.
+  # One backend everywhere, so slice 040 AC3 measures the same mechanism on every machine. The
+  # gate's runners have no `inotifywait` and already take this path; a developer box takes the
+  # native one, and takes it badly when the machine is at its inotify instance ceiling, where the
+  # watch is never established and no edit ever arrives.
+  poll: true,
+  poll_interval_ms: 100,
   index_tokens: 338
 
 # Slice 060: no MCP client boots from rows in the suite (each test starts the clients it
 
@@ -304,13 +304,30 @@ defmodule Trinity.Skills.Registry do
   # has no native backend for, poll once a second (AC3's 2 s still holds; the poll compares
   # mtimes at one-second resolution). `TRINITY_SKILLS_POLL=1` forces the poll, so the
   # fallback can be exercised on a machine that has inotifywait.
+  #
+  # The interval is configurable because AC3's bound and this default leave no margin. A poll
+  # every second over mtimes at one-second resolution has a worst case of about two seconds all
+  # by itself, which is the whole of the criterion, so on a loaded shared runner the test that
+  # asserts it failed intermittently while the product was behaving exactly as designed. The
+  # default is unchanged and is what ships; the suite sets a shorter one so that what it measures
+  # is the watcher noticing rather than the runner's scheduler.
   defp backend do
-    poll = [backend: :fs_poll, interval: 1_000]
+    poll = [backend: :fs_poll, interval: poll_interval_ms()]
 
     cond do
       System.get_env("TRINITY_SKILLS_POLL") == "1" ->
         poll
 
+      # Same switch, from configuration rather than the environment, so the suite can pin one
+      # backend. Which backend the registry picks otherwise depends on the machine: a developer
+      # box has `inotifywait` and the gate's runners do not, so AC3's test measured a different
+      # mechanism in each place, and on a box already at its inotify **instance** ceiling
+      # (`/proc/sys/fs/inotify/max_user_instances`, 128 here with 119 in use) the native backend
+      # obtains no watch and fails silently, which the test could only report as an edit that
+      # never arrived.
+      Keyword.get(Application.get_env(:trinity, :skills, []), :poll, false) ->
+        poll
+
       match?({:unix, :linux}, :os.type()) ->
         if System.find_executable("inotifywait"), do: [], else: poll
 
@@ -327,6 +344,9 @@ defmodule Trinity.Skills.Registry do
 
   defp watch?, do: Application.get_env(:trinity, :skills, []) |> Keyword.get(:watch, true)
 
+  defp poll_interval_ms,
+    do: Application.get_env(:trinity, :skills, []) |> Keyword.get(:poll_interval_ms, 1_000)
+
   ## Helpers
 
   defp ensure_project(nil), do: :ok
 
@@ -0,0 +1,68 @@
+# SPDX-FileCopyrightText: Sudo Apt Holdings LLC
+# SPDX-License-Identifier: Apache-2.0
+defmodule Trinity.Repo.SandboxTransactionModeTest do
+  @moduledoc """
+  R26's residual half: `default_transaction_mode: :immediate` does **not** reach a sandboxed test.
+
+  Slice 005 reproduced R26 and demonstrated the fix, deliberately outside the sandbox, because
+  "the sandbox wraps each test in one connection's transaction and cannot express two contending
+  writers" (`test/trinity/repo/sqlite_transaction_mode_test.exs`). `config/test.exs` then sets
+  `default_transaction_mode: :immediate` on both test repos, which reads as though the suite were
+  covered too.
+
+  It is not, and this file is here so that sentence cannot quietly stay wrong.
+
+  `Ecto.Adapters.SQL.Sandbox.post_checkout/3` begins the per-test transaction with
+  `conn_mod.handle_begin([mode: :transaction] ++ opts, conn_state)`. `Exqlite.Connection` resolves
+  the mode as `Keyword.get(options, :mode, state.default_transaction_mode)`, so an explicit
+  `:mode` in the options **wins over the configured default**, and `:transaction` maps to a plain
+  `BEGIN TRANSACTION`, which is DEFERRED.
+
+  So every sandboxed test runs in a DEFERRED transaction. A test whose first statements read and
+  then write is doing exactly what R26 describes: the read makes the transaction a reader, the
+  write tries to upgrade, and if another connection has written in between SQLite answers
+  `SQLITE_BUSY` **without consulting the busy handler**, so neither the 30 s `busy_timeout` nor
+  the `:immediate` setting can help. `Trinity.Gateways.IdentitiesTest` is such a test and has
+  failed this way on CI (gate run 36742943477, while the other run on the same commit passed).
+
+  This is a fact about a dependency, so it is asserted against the dependency's source rather than
+  described. If an upgrade changes either line, this fails and the reasoning above gets revisited
+  instead of rotting.
+  """
+  use ExUnit.Case, async: true
+
+  @sandbox "deps/ecto_sql/lib/ecto/adapters/sql/sandbox.ex"
+  @exqlite "deps/exqlite/lib/exqlite/connection.ex"
+
+  test "the sandbox begins its per-test transaction with an explicit mode, and that mode is DEFERRED" do
+    sandbox = File.read!(@sandbox)
+
+    assert sandbox =~ "handle_begin([mode: :transaction] ++ opts",
+           """
+           #{@sandbox} no longer begins the sandbox transaction with `mode: :transaction`.
+
+           That is the line this project's understanding of R26-inside-the-suite rests on. Re-read
+           it: if the sandbox now begins IMMEDIATE, or takes the mode from the repo's
+           configuration, then `default_transaction_mode: :immediate` in config/test.exs finally
+           does reach sandboxed tests, and the moduledoc here and the comment in config/test.exs
+           should say so.
+           """
+  end
+
+  test "an explicit :mode option wins over the configured default_transaction_mode" do
+    exqlite = File.read!(@exqlite)
+
+    assert exqlite =~ "Keyword.get(options, :mode, state.default_transaction_mode)",
+           """
+           #{@exqlite} no longer resolves the transaction mode by preferring an explicit `:mode`
+           option over the configured default. If the precedence has reversed, the sandbox's
+           `mode: :transaction` no longer overrides `default_transaction_mode: :immediate`.
+           """
+
+    # And `:transaction` is the plain BEGIN, not the IMMEDIATE one: the two are separate clauses
+    # and only one of them takes the write lock up front.
+    assert exqlite =~ ~s|:transaction when transaction_status == :idle ->|
+    assert exqlite =~ ~s|handle_transaction(:begin, "BEGIN TRANSACTION", state)|
+    assert exqlite =~ ~s|handle_transaction(:begin, "BEGIN IMMEDIATE TRANSACTION", state)|
+  end
+end
@@ -136,15 +136,28 @@ defmodule Trinity.Skills.RegistryTest do
 
     started = System.monotonic_time(:millisecond)
 
-    assert Enum.find_value(1..100, fn _ ->
-             Process.sleep(20)
-
-             if Skills.get("watched").description == "After.",
-               do: System.monotonic_time(:millisecond) - started
-           end)
-           |> then(fn ms ->
-             IO.puts("\nAC3: the edit was in the registry after #{ms} ms")
-             ms
-           end) <= 2_000
+    # The poll window and the criterion used to be the same 2 000 ms: `1..100` with a 20 ms sleep
+    # is a 2 s budget, asserted against a 2 s bound, so there was no way to tell "it never
+    # arrived" from "it arrived late", and a slow scheduler turned one into the other. They are
+    # separate now. The loop waits far longer than the criterion so that a failure says which of
+    # the two happened, and the criterion is then asserted against the time actually measured.
+    latency_ms =
+      Enum.find_value(1..600, fn _ ->
+        Process.sleep(25)
+
+        if Skills.get("watched").description == "After.",
+          do: System.monotonic_time(:millisecond) - started
+      end)
+
+    assert latency_ms,
+           "the edit never reached the registry at all, in 15 s of waiting, and no rescan was " <>
+             "called. That is not AC3's 2 s bound being missed; it is the watcher not working."
+
+    IO.puts("\nAC3: the edit was in the registry after #{latency_ms} ms")
+
+    assert latency_ms <= 2_000,
+           "AC3 gives 2 000 ms and the edit took #{latency_ms} ms. The suite runs the fs_poll " <>
+             "backend at the interval config/test.exs sets, so this is the watcher being slow " <>
+             "rather than the poll interval leaving no margin."
   end
 end