ladder: the ledger scenario corpus fails intermittently with "database is locked" — observed once, not reproduced

[Yaraslaut]

Found during the landing sweep for PR #654, whose Application ladder leg went red. Filed rather than folded: the failure has nothing to do with that branch, and an unrecorded intermittent failure is one nobody finds again on purpose.

The finding

One scenario in the ledger corpus failed on a SQLite database is locked error while the rest of the corpus and all 1031 ladder tests passed.

Verification status: observed once in CI, not reproduced, and not investigated

From Application ladder, job 106204287825 of run 35557586945 (PR #654 at 0644d6cf, 2026-09-21T04:20:01Z):

ledger: 16 file(s) against ws://127.0.0.1:35615
  ok   step 34 (line 137) [books] use books
  ok   step 35 (line 139) [books] do SetCategory accountId=$spend categoryId=$loser ruleId=$rule ruleVersion=7
FAIL step 35 (line 140): do SetCategory accountId=$spend categoryId=$loser ruleId=$rule ruleVersion=7
  expected: @kind == ok
  actual:   @kind == err
  client:   books (modelId=9761190600845593476)
  reply:    err message="HY000 (5) - [SQLite]database is locked (5)"

.../scripts/scenario/scenarios/ledger/update-rule-version-conflict.scenario: 38 steps, 56 assertions, 1 failure
  FAIL update-rule-version-conflict.scenario

FAILED: ledger

What I did NOT do: reproduce it locally, re-run the leg, inspect the scenario, read the ledger server's SQLite configuration, or check whether update-rule-version-conflict.scenario is unusual in its concurrency. This is a log reading, nothing more.

Why it is worth a ticket despite the weak evidence

1. It is not PR core: stop a cancelled control call reaching the wrapped backend, and pin parkIfInFrame's unreachable double-claim arm (fixes #636, fixes #648) #654's fault, and the next person will assume it is. The whole ladder test suite passed — 100% tests passed, 0 tests failed out of 1031 — and the branch touches SynchronousBackendAdapter and parkIfInFrame, neither of which the ledger scenario server goes near. A red Application ladder on an unrelated PR costs that PR a 49-minute cycle and a diagnosis, which is exactly what it cost here.
2. database is locked is a contention signature, not a logic error. SQLite returns SQLITE_BUSY when another connection holds a write lock past the busy timeout. That points at the corpus runner's concurrency or the server's busy-timeout configuration rather than at the scenario's assertions.
3. Step 35 appears twice in the excerpt — once ok at line 139 and once FAIL at line 140. Whether that is a retry, two adjacent steps sharing a number, or a display artefact of the runner, I do not know, and it may be the most informative detail here.

What would resolve it

• Establish whether the ledger scenario server sets a SQLite busy timeout at all, and what the corpus runner's concurrency is. If there is no busy timeout, this is a configuration defect with a one-line fix and the intermittency is explained.
• If a busy timeout exists and is adequate, find what holds the write lock — the scenario is named update-rule-version-conflict, so it is plausibly designed to produce contention, which would make this a scenario that races its own premise.

What would change the verdict

• Close as invalid if SQLITE_BUSY here is the deliberate, asserted outcome of a conflict scenario and the corpus expected err — i.e. if the expected: @kind == ok line means the scenario file itself is wrong rather than the run.
• Raise in priority if it recurs on another unrelated PR. One observation is a flake; two is a tax on every PR that touches the ladder path filter.

Related

• ci: check_spec_sync.sh reports "Spec sync OK" when it is run with no input at all #655, tests/lint/ fixtures are inside clang-tidy-diff's scope, and nothing tells the author that until CI is red #650, 60 of 470 tracked C/C++ sources are outside clang-tidy-diff's reach, and 11 of them only because one CMake flag is missing #651 — the current cluster about gates whose coverage is not what it looks like. This is the neighbouring class: a gate that is correct but intermittently red, which erodes trust in it just as effectively.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Triage: rescope

The observation stands. All three of the cheap explanations the issue offers are
eliminated by measurement, which changes what this ticket is about — it is not
a missing busy timeout, not a scenario asserting its own conflict, and not a
display artefact. What is left is a narrower and more interesting defect.

Verified on master @ a9cb5649, by reading the tree, not by reproducing the
failure.

Hypothesis 1 — "no busy timeout" — eliminated

The issue's first resolution step: "Establish whether the ledger scenario server
sets a SQLite busy timeout at all... If there is no busy timeout, this is a
configuration defect with a one-line fix."

It sets one, and the corpus runner sets it too. scripts/scenario/run_scenarios.py:106,
which builds the environment for every rung server including ledger:

env[self.db_var] = f"DRIVER=SQLite3;Database={db_path};Timeout=5000"

and the server's own fallback, examples/ledger/src/server/main.cpp:89-91:

const char* connectionString = std::getenv("LEDGER_DB");
ledger::db::setup(connectionString != nullptr ? connectionString
                                              : "DRIVER=SQLite3;Database=ledger.db;Timeout=5000");

LEDGER_DB is set by the runner (run_scenarios.py:196), so the 5000 ms value
is the one that was in force during the failing job. There is no one-line fix here.

Hypothesis 2 — "the scenario asserts the conflict" — eliminated

The issue's invalid condition: "Close as invalid if SQLITE_BUSY here is the
deliberate, asserted outcome of a conflict scenario."

It is not. scripts/scenario/scenarios/ledger/update-rule-version-conflict.scenario,
lines 139-140:

do SetCategory accountId=$spend categoryId=$loser ruleId=$rule ruleVersion=7
expect ok

The scenario asserts ok. The version conflicts the file is named for are
resolved earlier (line 133's UpdateRule ... expectedVersion=6, asserted ok
with version == 7); by line 139 the scenario is past its conflict and is
checking that the settled rule can be applied. So the err was not the designed
outcome.

Hypothesis 3 — "step 35 appears twice" — explained, and it is not informative

The issue flags this as "may be the most informative detail here." It is not: it
is the runner's ordinary reporting shape. Line 139 is the do and line 140 is its
expect; the runner numbers a step by its do and reports the send and the
assertion separately against the two source lines. Not a retry, not two steps
sharing a number.

What is actually left

A single SQLite file, one server process, a sequential corpus (no
ThreadPool, max_workers, or parallel dispatch anywhere in
run_scenarios.py), and a 5000 ms busy timeout — and still database is locked.
Those four facts together rule out ordinary cross-client contention, because there
is no second client and the one writer waits five seconds.

That leaves contention inside the server process, between two connections it
opened itself. The shape is there to support it: every ledger handler constructs
its own mapper, e.g. examples/ledger/src/models/ledger_model.cpp:646,672,718,739
and five more sites in budget_model.cpp, each a fresh

Lightweight::DataMapper mapper;

resolving from Lightweight's process-global default connection string — so one
connection per live mapper, against one file. And write transactions are held
across work: ledger_model.cpp:7 includes <Lightweight/SqlTransaction.hpp>, and
:137 records that "side is already atomic (storeJournalImpl holds a
SqlTransaction)".

Inferred from reading, not measured: if any handler opens a second
DataMapper while an enclosing one holds a write transaction, that is a
self-deadlock on one thread across two connections, and a busy timeout cannot
clear it — the holder never proceeds, because it is waiting for the waiter to
return. That predicts exactly what was seen: intermittent (depends on whether the
prior write had committed), database is locked, after the full timeout, with no
concurrent client.

The rescoped ticket

Establish whether the ledger server ever holds two DataMapper connections open
at once with a write transaction on the outer one. That is a static question
answerable by reading the handler call graph — no reproduction needed — and it
either finds the defect or eliminates the last cheap explanation too.

• If it does: the fix is to thread one mapper (or one transaction) through the
  call, not to lengthen the timeout. Check SetCategory's cascade first —
  examples/ledger/include/ledger/db/book_access.hpp:143,160 describes it joining
  an account, and it is the handler that failed.
• If it does not: re-file as a genuine unknown, and the next step becomes
  instrumentation (log every connection open/close and transaction begin/commit in
  the scenario server) rather than more reading.

I am not asking for the intermittent failure to be reproduced. One CI
observation plus a static call-graph answer is enough to decide this, and
reproducing a race that fired once in one job is a poor use of a lane.

What would change the verdict

• invalid if the call graph shows a single mapper per request throughout and
  no nesting — the mechanism above would be dead and this returns to an
  unexplained one-off.
• Raise priority if it recurs, per the original. Still true.
• Note the original's framing of this as a CI-flake tax is half right: if the
  nesting hypothesis holds it is a product defect in the ladder's persistence
  layer reachable by any application whose action writes through two models, and
  the CI flake is only how it was noticed.

[Yaraslaut]

The rescoped question is answered: no. And the premise that made it the last explanation is false.

Verified on master @ c6f6d953, by reading the tree. Not reproduced — per the rescope, I did not try to.

The static question: does any ledger handler open a second DataMapper while an enclosing one holds a write transaction?

No. Enumerated exhaustively:

Every Lightweight::DataMapper construction in ledger's non-test code sits at the top of one public execute() overload, and nothing below it constructs another:

examples/ledger/src/models/ledger_model.cpp:646,672,718,739,823,1053,1157,1311,1360,1507,1536
examples/ledger/src/models/budget_model.cpp:87,111,155,203,241
examples/ledger/src/models/rule_model.cpp:82,110

Every Lightweight::SqlTransaction in that code:

ledger_model.cpp:880   execute(StoreTransaction)
ledger_model.cpp:1537  execute(SetCategory)
ledger_model.cpp:1601  storeJournalImpl

and nothing else in the rung opens one. So a nested mapper would need one execute() to call another, and none does — the two candidates both take the enclosing mapper by reference instead:

• SetCategory (:1530-1546), the handler that failed, is one mapper, one transaction: DataMapper mapper; SqlTransaction sqlTxn{mapper.Connection(), ROLLBACK}; setCategoryImpl(mapper, action); sqlTxn.Commit();. setCategoryImpl (:1548-1586) takes Lightweight::DataMapper& and uses only it; the two gates it calls, db::requireOwnedParentBook and db::requireCategoryInBook (include/ledger/db/book_access.hpp), take the same mapper or take no mapper at all.
• The rule cascade inside execute(StoreTransaction) calls setCategoryImpl(mapper, cascadeAction) at :1015 — deliberately the same mapper, with the comment at :948-953 saying why.

logAction/logFailure (:571-640) write to a morph::journal::IActionLog, not to SQLite, so they are not a second connection either.

So the self-deadlock mechanism the triage inferred does not exist in this rung. That eliminates the last cheap explanation the triage left standing — and the triage's own invalid condition says this returns the issue to an unexplained one-off.

Except it does not, because the fourth fact in "those four facts together" is wrong

A single SQLite file, one server process, a sequential corpus (no ThreadPool, max_workers, or parallel dispatch anywhere in run_scenarios.py) [...] Those four facts together rule out ordinary cross-client contention, because there is no second client and the one writer waits five seconds.

The corpus runner is sequential. The server is not. examples/ledger/src/app/app.cpp:133-137:

App::App(std::string tokenSecret, std::chrono::milliseconds runInterval, std::size_t workers, QObject* parent)
    : QObject{parent},
      _pool{workers},

with std::size_t workers = 4 (include/ledger/app/app.hpp:106) — a four-thread model worker pool behind RemoteServer. And App arms a report-runner timer that ticks every second by default (app.hpp:105, app.cpp:190-199), whose pass:

1. opens its own connection for the sweep query — ::Lightweight::SqlStatement stmt; stmt.Prepare("SELECT id, ledger_id FROM ledger_report_jobs WHERE status = ?") (app.cpp:227-230), a fresh statement over the process-global default connection, not over any handler's mapper; and
2. fire-and-forget dispatches RunReportJob for every Pending row through a BridgeHandler onto _reportExecutor (app.cpp:257-269), landing on a pool thread, where execute(RunReportJob) opens a third DataMapper (ledger_model.cpp:1360) and holds a raw read transaction across the whole aggregation (WalSnapshotGuard = BEGIN DEFERRED, :1460) before writing finishReportJob (:1468).

examples/ledger/src/server/main.cpp constructs ledger::app::App app{tokenSecret} with all defaults, so the scenario server runs with four worker threads and a 1 Hz sweeper. The scenario itself drives five clients on five sockets against three models (AuthModel, RuleModel, LedgerModel, BudgetModel) whose strands are independent.

So there is a second connection, in-process, concurrent with the client's write. Cross-client contention is back on the table, and the only thing "sequential corpus" ruled out was a second external client.

And the busy timeout is not 5000 ms, and would not have helped anyway

Two corrections to the timeout half of the argument, both already recorded in this tree:

(a) The effective value is 60000, not 5000. examples/common/testkit/db_busy_fixture.hpp:52-63 records, as a measured finding, that Lightweight's PostConnect() issues PRAGMA busy_timeout = 60000 on every SQLite connection after connect, which overrides the connection string's Timeout= (the ODBC driver would otherwise honour it, but the PRAGMA runs later and wins). ledger_model.cpp:326 refers to "the full 60s busy_timeout" for the same reason. So the writer was not waiting five seconds; it was configured to wait sixty, and database is locked came back anyway.

(b) A busy timeout cannot clear this particular contention. SQLite documents that it will not invoke the busy handler where doing so could deadlock, and returns SQLITE_BUSY immediately instead — specifically when a connection holding a read lock inside an open transaction tries to promote it while another connection holds RESERVED. That is exactly SetCategory's shape: SqlTransaction turns autocommit off, then two SELECTs (accountRows, categoryRows) and two ownership reads take a read lock inside that transaction, and only then does mapper.Update(accountRows.front()) (:1585) ask to promote it. If the report worker's connection holds RESERVED at that instant, the promotion returns SQLITE_BUSY — "database is locked" — with no wait at all, whatever the timeout says.

That predicts every observed property: intermittent (depends on the sweeper's phase), immune to the timeout, one external client, one process, and on SetCategory — the handler in this rung whose write is preceded by the most reads inside its own transaction.

Verification status, stated plainly

• Measured: the mapper/transaction enumeration above, the worker-pool size, the timer wiring, and the two connections the report pass opens. All from reading master @ c6f6d953; every line cited was read.
• Inferred, not measured: that the promotion-under-RESERVED path is what fired. I did not instrument the server, did not reproduce the failure, and did not confirm the database is in rollback-journal rather than WAL mode (nothing in the tree issues PRAGMA journal_mode, and WalSnapshotGuard is named for WAL but only issues BEGIN DEFERRED — which is itself worth checking, see below).
• Not checked: whether the failing corpus run had any Pending report rows at all. If the runner starts a fresh database per scenario and that scenario never calls SubmitReport, the sweeper's contribution is the bare SELECT on its own connection once a second — still a second connection taking a read lock, still enough for the mechanism, but a much narrower window than a full aggregation.

What this changes about the fix

Not "thread one mapper through the call" — there is nothing to thread. The candidates are, in order of how much they are worth:

1. Shorten the write transaction's read prefix in SetCategory. The two lookups and two ownership gates do not need to be inside the transaction; only the final mapper.Update does. A transaction that opens immediately before the write cannot be in the promote-under-contention state at all.
2. Retry on SQLITE_BUSY at the handler boundary, which is the only remedy that works for a return the busy handler never sees.
3. PRAGMA journal_mode = WAL, which would let the reader and the writer coexist. Note WalSnapshotGuard's name asserts this is already the case and nothing in the tree sets it — that is its own finding and I have filed it separately.

What would change this verdict

• Reproduce with logging — every connection open/close and every transaction begin/commit, with thread ids — and the mechanism is either visible or refuted in one run. That is now a much cheaper experiment than before, because the prediction is specific: two connections, one in the read-to-write promotion, no busy wait before the error.
• Back to unexplained if the report timer turns out to be disabled in the scenario server (it is not — main.cpp takes the default runInterval) or if the sweeper's SELECT can be shown never to overlap a handler write.

[Yaraslaut]

Reproduced locally — 1 failure in 180 runs, byte-identical to the CI report

Verified on master @ 084ad056, Linux, linux-everything preset (clang, Release),
ladder_ledger_server built from that tree. The run loop was
python3 scripts/scenario/run_scenarios.py --rung ledger --build-dir build/linux-everything,
foreground, one run at a time, ~3.8 s per run (all 16 ledger files against one
server and one database).

This moves the issue off "observed once in CI, not reproduced". The failure is
real, it is in the shipped configuration, and it is rare.

The reproduction

Run 49 of the first batch of 60:

  ok   step 34 (line 137) [books] use books
  ok   step 35 (line 139) [books] do SetCategory accountId=$spend categoryId=$loser ruleId=$rule ruleVersion=7
FAIL step 35 (line 140): do SetCategory accountId=$spend categoryId=$loser ruleId=$rule ruleVersion=7
  expected: @kind == ok
  actual:   @kind == err
  client:   books (modelId=2793710737219516221)
  reply:    err message="HY000 (5) - [SQLite]database is locked (5)"

/.../scripts/scenario/scenarios/ledger/update-rule-version-conflict.scenario: 38 steps, 56 assertions, 1 failure
  FAIL update-rule-version-conflict.scenario
  ok   zero-sum-holds-per-currency.scenario

FAILED: ledger

Same file, same step, same line, same handler, same message as job 106204287825.
modelId differs, as it would; nothing else does.

Run budget, stated in full

Arm	Configuration	Runs	database is locked failures
Baseline batch 1	shipped (runInterval = 1 s, workers = 4)	60	1
Baseline batch 2	shipped, identical binary	120	0
Sweeper off	runInterval = 1 h (local edit, reverted)	80	0
Sweeper fast	runInterval = 5 ms (local edit, reverted)	30	0

Baseline rate: 1/180 ≈ 0.6 %. Both baseline batches ran the same binary on
the same machine with nothing else running; the difference between them is
noise at this rate, not a signal.

The two arms do not identify the mechanism, and I am saying so rather than rounding up

The "sweeper off" arm was meant to test the rescope's report-runner hypothesis.
It does not: 0/80 against a 0.6 % base rate has an expected count of 0.45,
so observing zero is what you would expect either way. It is not evidence for
the hypothesis and it is not evidence against it. Recorded because it was run,
not because it settles anything.

The "sweeper fast" arm is worse than uninformative — it is contaminated. All
30 runs failed, but never on database is locked and never on this scenario:

     30 FAIL step 33 (line 143): do GetReportStatus jobId=$jobOne
     30   FAIL two-books-are-isolated.scenario
     30   reply:    ok body={"status":"Done", ...}

A 5 ms sweep finishes the job before the next step polls it, and that scenario
asserts status == "Pending". That is a separate defect in the corpus, filed
separately; as an experiment this arm measured the wrong thing. It does tell us
one thing about this issue, though: driving the sweeper 200× harder produced
zero additional database is locked, which is the opposite of what the
report-runner hypothesis predicts if the sweep SELECT alone were enough.
Weak evidence, one configuration.

What the tree actually says, re-read on 084ad056

Confirming and correcting the earlier comments against the current revision
(three of the files involved were rewritten by morph#739 / morph#750 since):

1. The scenario is not unusual in its concurrency, and drives no parallel
   clients. update-rule-version-conflict.scenario opens five clients
   (auth, editorOne, editorTwo, books, budgets) on five sockets, but
   the runner is strictly request/response — one do, wait for the reply, next
   do. Line 139 asserts ok; the conflicts the file is named for are
   resolved by line 133. Unchanged from the first triage.

2. A busy timeout is set, twice, and neither value is the effective one.
   run_scenarios.py:106 puts Timeout=5000 in LEDGER_DB, and
   examples/ledger/src/server/main.cpp:89-91 falls back to the same. Both are
   overridden: Lightweight's SqlConnection::PostConnect() issues
   PRAGMA busy_timeout = 60000 after connect, which wins
   (examples/common/testkit/db_busy_fixture.hpp:52-63 records this as a
   measured finding). So the writer was configured to wait 60 s and got
   database is locked anyway — in a corpus run that completes end to end in
   3.8 s. Whatever produced this did not wait.

3. The server is concurrent even though the corpus is sequential.
   examples/ledger/include/ledger/app/app.hpp:105-106 still defaults to
   runInterval = 1 s and workers = 4, and main.cpp takes both defaults, so
   the scenario server runs a four-thread model pool and a 1 Hz report sweep
   that opens its own SqlStatement (app.cpp:227-229) on a second connection.

4. New, and it closes the "Not checked" item from the second triage. That
   comment could not tell whether the failing run had any Pending report rows.
   It did. run_rung() (run_scenarios.py:451-486) runs a rung's whole
   directory against one server and one database file, in sorted order,
   and submit-a-report-and-poll-it.scenario — which sorts two files before
   update-rule-version-conflict.scenario — submits two report jobs and never
   waits for either to finish (it only asserts status != "Failed"). The
   captured ids in the failing run confirm the shared database directly:
   rule=4, cash=34, spend=35, survivor=10, loser=11, none of which a fresh
   database would produce.

   So the sweeper does have real work in flight in that window, and
   RunReportJob holds a BEGIN DEFERRED read transaction across the whole
   aggregation (ledger_model.cpp:1460 and the
   DeferredReadTransactionGuard doc comment at :317-367, which morph#739
   rewrote to say outright that in rollback-journal mode this blocks every
   writer on the file for as long as it is held).

5. SetCategory still has the read-then-promote shape.
   ledger_model.cpp:1566-1581 opens the SqlTransaction first, then
   setCategoryImpl (:1584-1621) runs two SELECTs plus two
   requireOwnedParentBook reads and a requireCategoryInBook check, and only
   then mapper.Update(accountRows.front()).

Verification status, stated plainly

• Measured: the reproduction and all four run counts above; the one-database-
  per-rung lifecycle; that submit-a-report-and-poll-it leaves jobs unfinished;
  the worker-pool size, sweep interval and their defaults at 084ad056; the
  SetCategory transaction shape.
• Inferred, not measured: that the report runner's read transaction is what
  the failing SetCategory collided with. Nothing here instruments the server,
  and neither experimental arm discriminates.
• Not attempted: a fix. At a 0.6 % base rate, no fix can be shown to work
  by running this corpus — 180 clean runs of a patched tree would be the
  expected outcome of a patch that did nothing. Landing one now would be a
  control that measures nothing, which is the failure mode AGENTS.md names
  first.

What would change the verdict

• The mechanism is settled by instrumenting the server — every connection
  open/close and every transaction begin/commit with thread ids — and running
  the corpus until it fires again. At 0.6 % that is ~180 runs ≈ 11 minutes per
  hit, which is now a known, affordable cost rather than a guess.
• A fix becomes verifiable only once a configuration with a high
  database is locked rate exists. The 5 ms sweeper is not it. Finding one is
  the prerequisite for closing this, not an optional extra.
• Close as fixed when the mechanism is instrumented, a change is made, and
  the failure stops appearing in a configuration where it previously appeared
  reliably.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VptDWG2fKr2vBnLSJcgzgW

[Yaraslaut]

Non-repro data point, from the lane that fixed #765

Not a fix and not a claim that this is closed -- recording it because the
neighbouring scenario changed and this issue's file ran beside it.

While verifying morph#765 (a different file, two-books-are-isolated.scenario,
a status-phase race rather than a lock contention), I ran the whole ledger
corpus twice against the same database, which includes
update-rule-version-conflict.scenario:

python3 scripts/scenario/run_scenarios.py --rung ledger --twice
...
  ok   update-rule-version-conflict.scenario
ledger: second pass, same database
...
  ok   update-rule-version-conflict.scenario

every scenario passed in: ledger

exit code 0. Then a mutation run over the corpus's own driver on the changed
file only -- which reruns that file 78 times but not this one, so it adds
nothing here.

What this is evidence of: two consecutive passes, one machine (Linux,
clang-release, SQLite via the scenario driver's own temp database), on
084ad05 plus the two commits in PR morph#774. database is locked did not
appear.

What it is not evidence of: anything about the conditions under which #658
was seen. Nothing in morph#774 touches update-rule-version-conflict.scenario,
RuleModel, or the journal/locking path, so if this stops reproducing it is
not because of that PR. A lock-contention failure that does not reproduce in
two passes on one machine is exactly the shape that reproduces on the third, or
on a loaded CI runner, and 2 runs is not a sample.

Left open.

[Yaraslaut]

Closed under a policy change — the ladder is a detector, not a product.

The owner's call today: examples/ exists to prove the framework works and to surface framework gaps. It stays building and unit/GUI tested, but defects in an example are no longer fixed or tracked on their own account. A bug that appears once gets fixed inline if a lane is already there; a bug that appears twice is evidence of a missing framework seam and is filed against include/morph instead.

Today's measurement is the reason: examples/ took +2658 lines against the library's +1171, and the largest single class of that work — nine kanban handlers each hand-rolling the same commit-then-post-commit-tail shield — was one framework gap repaired nine times in the demo rather than once in morph.

The evidence here stays on the record.

Specific to this one: it was reproduced at 1 failure in 180 corpus runs (0.6%), and its own lane declined to ship a fix because at that rate 180 clean runs of a patched tree is what a patch that did nothing would produce. That reasoning still stands.

Re-open if the same database is locked shape appears in a framework path rather than the ledger scenario corpus — that would be a morph defect, not a ladder one.