docs/findings/r5-003 still says disposition: open, but #129 is closed and FINDINGS.md admits no open disposition at rung exit

[Yaraslaut]

Summary

docs/findings/r5-003-no-model-level-background-job-seam.md carries disposition: open, but the issue it links — #129 — is closed, and was closed on architectural grounds rather than by a fix. examples/FINDINGS.md admits no open disposition at rung exit, so this needs a decision from the repo owner.

Raising rather than changing it, because FINDINGS.md is explicit that this call is not mine to make:

Every finding gets a disposition within one triage pass (the repo owner decides; the ladder never self-triages).

The state

docs/findings/r5-003-no-model-level-background-job-seam.md front matter, on master c429195c:

id: r5-003
title: No framework seam for a model's own execute() to post background work and later update its own state
subsystem: core
severity: minor
source: ledger rung 5, design spec §9
disposition: open
test: spec-cited
issue: https://github.com/LASTRADA-Software/morph/issues/129

#129 is closed. It was closed as wrong-layer: a model updating its own state from background work is off-strand mutation, which the concurrency model forbids — docs/spec/concurrency_and_lifetimes.md guarantees execute() is never re-entered concurrently for a given ModelId, so the unit of later work is another action, not a background write. The narrower needs that survived that analysis were filed separately as #160 and #161.

92422c4b (#329) closed out r5-001, r5-002 and r5-004's bookkeeping and deliberately left r5-003 alone — its commit message records that as an explicit decision, which is why this is a question rather than an oversight report.

Why it needs resolving

FINDINGS.md's rung exit criteria:

A rung is done when: ... 3. its findings are triaged (no open dispositions left).

So rung 5 does not currently satisfy its own exit criteria on paper. The three dispositions available are fix-scheduled, documented-limitation, and wontfix.

wontfix with rationale looks like the honest landing spot: the finding asks for a seam the architecture forbids, #129 established that in writing, and nothing is scheduled. documented-limitation would be the alternative if the intent is that concurrency_and_lifetimes.md already is the documentation of the limitation — in which case the finding's test: field should probably point at whatever pins that behaviour rather than staying spec-cited.

What would close this

A disposition set on r5-003, with a one-line rationale, by whoever owns the contract. If it is wontfix, the front matter and a sentence in the body are the whole change.

What would change the verdict

If keeping it open is deliberate — e.g. the seam is genuinely still under consideration despite #129's closure, and #160/#161 do not fully cover it — then this should close and FINDINGS.md's exit criteria should say that a finding may stay open when its issue is closed wrong-layer but the underlying need is unsettled.

[Yaraslaut]

Triage: rescope — the exit-criteria argument is false, and r5-003 is not the only one

I wrote this issue, so this pass went looking for reasons it is wrong. It found two, and they gut the stated argument while leaving a smaller real question behind.

The exit-criteria argument does not hold

The issue argues that rung 5 "does not currently satisfy its own exit criteria on paper", citing FINDINGS.md:

A rung is done when: … 3. its findings are triaged (no open dispositions left).

That criterion binds at rung exit. Rung 5 has not exited. examples/LADDER.md's rung table marks ledger 5*, and its footnote reads:

* = design annex: README is the deliverable; construction is a post-rung-4 decision (ledger under construction; lims built; forge → load script; crm → 7b spike).

No rung-exit declaration exists anywhere in the repository (git grep for exit language across examples/ and docs/ returns nothing). So an open disposition on a rung still under construction is the pipeline working as designed, not a violation of it. This was the issue's entire justification for urgency, and it is wrong.

r5-003 is not a singular oversight

The issue presents r5-003 as an isolated stale entry. It is not — four of the six findings on disk carry disposition: open:

Finding	Disposition
r4-001-sync-worker-conflates-undelivered-and-rejected	open
r4-002-flagship-gui-bypasses-forms	open
r5-001-rational-checked-arithmetic-mode	fix-scheduled
r5-002-rational-no-predecode-validation-seam	fix-scheduled
r5-003-no-model-level-background-job-seam	open
r5-004-lightweight-pool-no-transaction-cleanup	open

Singling out r5-003 because I happened to notice it while doing something else is exactly the framing error this repository keeps producing. If open dispositions are a problem, they are a four-finding problem across two rungs; if they are not, r5-003 is not one either.

What survives, and it is narrower

One thing in the original issue does hold, independent of exit timing: r5-003's question has been answered, and its disposition does not say so.

The finding asks for a seam letting a model's execute() post background work and later update its own state. #129 is closed, and closed wrong-layer — that work is off-strand, so updating model state there is a data race; docs/spec/concurrency_and_lifetimes.md guarantees execute() is never re-entered concurrently for a ModelId, and the unit of later work is another action. The narrower needs survived as #160/#161.

So the answer is "this is not a gap, and will not become one". open implies an unresolved question. wontfix is what that state is called.

That is a bookkeeping tidy with no deadline attached — not the exit-criteria breach this issue claimed. Note also that 92422c4b (#329) deliberately left r5-003 alone, which remains a reason to ask rather than to assume.

Corrected framing

Either:

• narrow this to "r5-003 should be wontfix, because No framework seam for a model's own execute() to post background work and later update its own state #129 answered it wrong-layer" — a one-line front-matter change plus a rationale sentence, decided by the repo owner per FINDINGS.md ("the repo owner decides; the ladder never self-triages"); or
• widen it to "four findings carry disposition: open; decide each" — which is the more honest shape if the concern is really pipeline hygiene rather than this one file.

It should not stay as filed, arguing from an exit criterion that is not yet in force.

What would change the verdict

A record that rung 4 or rung 5 has formally exited — that would put the exit criterion in force and restore the original argument for at least the r4-* entries. I could not find one; LADDER.md says ledger is still under construction, and nothing declares rung 4 done.