fix: defer/block refuse a RESOLVED item instead of blanking its resolution

[Brian Krabach (bkrabach)]

What this closes

defer and block on an already-resolved item exited 0, moved it out of resolved, and
blanked its stored resolution — destroying the official, already-published record with no
warning, no confirmation, no archive and no trace of what it used to say.

Measured first-hand before touching any code (bd 1.1.2, 2026-09-03, throwaway project created and
destroyed through the sanctioned CLI — evidence/measurement-BEFORE.txt):

$ … resolve --id <id> --reason "ORIGINAL TEXT"    EXIT=0   resolution: "ORIGINAL TEXT"
$ … defer   --id <id> --reason probe              EXIT=0   {"status": "deferred"}
$ … block   --id <id> --reason probe              EXIT=0   {"status": "blocked"}
$ … list    --id <id> --json                      EXIT=0   status blocked | resolution: null   ← GONE
$ … block   --id <id> --clear                     EXIT=0   {"status": "open"}
$ … claim   --id <id> --actor probe               EXIT=0
$ … resolve --id <id> --reason "CORRECTED TEXT"   EXIT=0
  FINAL: status resolved | resolution = CORRECTED TEXT | closed_at moved

Two consequences, both load-bearing:

1. It refutes "a closed item's resolution is unwritable through every sanctioned path" — the
   premise of model_performance-uma and model_performance-44f. It was always writable, with no
   bd invocation anywhere. 44f's own §1.7 summary table lists work_defer/work_block as
   "status/location only — no" against resolution; that row is wrong on both counts. Neither
   lane ever tested these two verbs against a closed item.
2. It is strictly worse than the defect feat: reopen verb + work_reopen tool; resolve on a closed item fails loud #67 closed. That one discarded the text you send;
   this discards the text already stored. And it sat one verb away from release(), whose
   docstring goes to deliberate lengths to make exactly this transition "structurally impossible
   from this path".

The same measurement after the fix

evidence/measurement-AFTER.txt — the loop stops at its first verb:

$ … defer   --id <id> --reason probe              EXIT=1
    refusing to defer <id>: it is already resolved, and defer would move it out of
    resolved and DESTROY the resolution stored on it. NOTHING WAS WRITTEN.
      status:             resolved
      stored (unchanged): ORIGINAL TEXT
      closed_at:          2026-09-03T07:08:55+00:00
    If you genuinely mean to reopen it, use `reopen` — it archives the resolution above
    (and closed_at) into an attributed comment FIRST:
      amplifier-work-tracker reopen --project … --id … --reason '<why the stored text is wrong>'
      (agents: work_reopen(project=…, item_id=…, reason=…))
$ … block   --id <id> --reason probe              EXIT=1   (same refusal)
$ … list    --id <id> --json                      EXIT=0   status resolved | resolution: "ORIGINAL TEXT"
$ … block   --id <id> --clear                     EXIT=1   it is 'resolved', not 'blocked'
$ … claim   --id <id> --actor probe               EXIT=1   issue not claimable: status closed
$ … resolve --id <id> --reason "CORRECTED TEXT"   EXIT=1   (#67's divergent-text refusal)
  FINAL: status resolved | resolution = ORIGINAL TEXT | closed_at UNMOVED

closed_at is byte-identical before and after the whole attempted loop — the record was not
merely restored, it was never touched.

The change

File	What
src/amplifier_work_tracker/adapter.py	_status_change_on_resolved_error(), _STATUS_CHANGE_VERB, and a pre-write guard in _set_status_with_reason — the one path both verbs go through. Docstrings on both verbs.
src/amplifier_work_tracker/contract.py	defer.refuses_resolved, block.refuses_resolved (shared _refuses_resolved body), registered in CHECKS.
AGENTS.md	doctor count 34 → 36, in both places, MEASURED from doctor output — not 34+2 arithmetic.
tests/integration/test_defer_block.py	+10 tests (4 discriminating, 6 "unaffected").
tests/cli/test_cli_new_verbs.py	+2 (parametrised): exit code + record intact, on the surface that shipped it.
modules/tool-work-tracker/tests/test_work_defer_block.py	+2 (parametrised): success=False on the agent-facing surface.

Placed in _set_status_with_reason on purpose — the single shared implementation of both
verbs, so there is exactly one guard and it cannot drift between them. The doctor assumptions are
nevertheless asserted separately per verb, so a future change that gives block its own path
cannot leave one door open while the other check keeps passing.

Checked BEFORE any write — that ordering is what makes the refusal's own "NOTHING WAS
WRITTEN" literally true, and it is the same ordering resolve and release already depend on.

Deliberately tolerant of a read failure, mirroring resolve's own pre-write read: an item that
does not exist keeps surfacing through bd's own update failure exactly as before. This guard must
not newly re-diagnose "not found".

Both doors, deliberately in one file

The unsafe door closes; the safe one stays open.
test_reopen_still_succeeds_on_the_same_item_and_still_archives_first reopens the very item
defer was just refused on, and asserts reopen still archives the previous resolution and
closed_at into an attributed comment first. A guard that shut both would be a regression of
its own.

And the ordinary workflow is untouched: 6 parametrised tests cover defer/block on open, held
and already-deferred-or-blocked items. Those 6 pass at the parent commit too, which is the
point — a guard that refused too much would break the verb for its actual purpose.

Fail-before evidence

evidence/fail-before-parent-2468a69.txt. The new test files are copied verbatim onto a worktree of
parent 2468a69; only src/ is the parent's, pinned with PYTHONPATH=<parent-worktree>/src
and verified in the capture itself. Without that pin the editable install silently resolves the
FIXED source and everything passes.

tier 2 (integration)  4 failed, 17 passed   ← the 4 discriminating tests
tier 3 (cli)          2 failed,  8 passed
modules               2 failed,  7 passed
doctor assumptions    [FAIL] defer.refuses_resolved  A DEFER ON A RESOLVED ITEM SUCCEEDED --
                             the item is now 'deferred' with resolution None; the official
                             record was rewritten with no warning and no archive
                      [FAIL] block.refuses_resolved  (same)

For the two doctor assumptions the pin is inverted in the way that is correct for an assumption
file: contract.py (the test) is the lane's, adapter.py (the code under test) is the
parent's, unmodified.

Test tiers, by name

The false immutability claim, corrected where it was made

• model_performance-uma — already corrected by its own lane before this one started
  (resolution §(0) and design ADDENDUM 2 both name the block → clear → claim → resolve path).
• model_performance-44f — corrected here, 2026-09-03T07:56Z, via the sanctioned edit
  verb on the installed CLI (--actor agent-2nx-lane), and verified by reading the record
  back: a design addendum stating the §1.7 row is wrong, what was measured, and that the door
  is now closed, with the prior text preserved verbatim beneath it.
• 44f's ai-notes FINDINGS.md §1.7 lives in a different repo and another lane's directory. The
  exact correction is prepared as a ready-to-apply patch at
  docs/lanes/2nx-defer-block-refuse-resolved/proposed-44f-findings-correction.md — one paste for
  whoever owns that repo.

Spend

$0.00 (authorized $0). No API spend, no DTU, no infrastructure created, so nothing was
registered in the infra ledger and nothing needed tearing down. sweep was never run.

Refs: model_performance-2nx. Full note:
docs/lanes/2nx-defer-block-refuse-resolved/DONE-NOTE.md.

[Brian Krabach (bkrabach)]

Manager: lane died markerless; work RECOVERED and pushed. Stays draft — now CONFLICTING.

The lane process ended at ~00:40 mid "commit and push". Its work was complete and uncommitted in its worktree. I committed it unchanged (c84cb86, now this PR's head) and re-ran every tier before publishing rather than trusting the state I found it in:

tier	result
unit	789 passed
integration + cli (test_defer_block.py, test_cli_new_verbs.py)	31 passed
modules (test_work_defer_block.py)	9 passed
ledger	24 passed
ruff check / ruff format --check	clean, 145 files

tests/unit/test_supervisor_web.py is the known port-binding flake, not a regression: fail / pass / fail across three runs of the same file on this tree, the failing test's identity varies, and this branch does not touch supervisor.py.

Why it is not merged yet

mergeable: CONFLICTING on src/amplifier_work_tracker/adapter.py. Main moved from this branch's base 2468a69 to ea233a7 while the lane was running — two PRs from a different highway landed in the same file:

• highway wave 1: custody-ledger fixes — module tests in CI, post-reclaim fence, write read-back, atomic claim, prose true-up #68 — custody-ledger fixes: post-reclaim fence, write read-back, atomic claim
• highway wave 2: Conformance Fixtures 2/3/4 + Ruling-1 conditions (mutation harness, VIOLATION-MOVEMENT) #71 — conformance fixtures 2/3/4 + Ruling-1 conditions

This is not a mechanical conflict I am willing to resolve in passing. #68's post-reclaim fence and write read-back are status-transition logic in the same region as this PR's defer/block refusal guard, so the merge needs someone to decide whether the two guards compose or duplicate — and to re-run the tiers afterward. Resolving it blind would risk silently weakening either one.

Status: verified-good, published, conflict-blocked. Top merge candidate once the adapter.py conflict is reconciled against #68/#71.

Merge policy note: this is a correctness fix with a reproduced fail-before, so it is merge-eligible under wins-only — the conflict is the only thing standing between it and main.

[Brian Krabach (bkrabach)]

Manager verification — rebased onto current main, conflict resolved keeping BOTH behaviours

This branch was CONFLICTING. It is now rebased onto ea233a7 and MERGEABLE; head 5a14cec.

The conflict, and why it needed a human decision rather than -X theirs

One hunk, in _set_status_with_reason — the shared body behind defer() and block(). Two changes wanted the same lines:

• highway wave 1: custody-ledger fixes — module tests in CI, post-reclaim fence, write read-back, atomic claim, prose true-up #68 (main) replaced the plain self._run(...) with _verified_write(...) — a read-back that confirms the status and the reason actually landed.
• fix: defer/block refuse a RESOLVED item instead of blanking its resolution #72 (this PR) added a pre-write refusal when the item is already resolved.

These compose; they do not compete. Resolved by keeping both, in this order:

if not reason or not reason.strip(): raise BeadsError(...)
# ---- model_performance-2nx: refuse BEFORE any write ----
...  if current.status == "resolved": raise _status_change_on_resolved_error(...)
# ---- #68: verified write (read-back confirms status AND reason) ----
args = [...]; self._verified_write(lambda: self._run(args, actor=actor), _verify, ...)

The ordering is load-bearing in both directions: the guard must run before any write for its own NOTHING WAS WRITTEN promise to be literally true, and #68's read-back must still wrap the write that does happen. Taking either side wholesale would have silently dropped the other — which is why I did not resolve this in passing last cycle.

Fail-before, reproduced against current main (not just the old parent)

test_defer_block.py run against ea233a7 with this PR's source absent:

FAILED ...refuse_and_the_resolution_survives[defer]
FAILED ...refuse_and_the_resolution_survives[block]
FAILED test_the_destructive_loop_now_stops_at_its_first_verb
FAILED test_reopen_still_succeeds_on_the_same_item_and_still_archives_first
4 failed, 17 passed

So the defect is still live on main today, and this branch is what closes it. The fourth failure matters as much as the first three: it pins that the safe path (reopen, which archives first) still works — a guard that closed the unsafe door by welding the safe one shut would pass the first three and fail that one.

All four documented tiers, post-rebase

tier	result
unit	790 passed
integration	366 passed, 3 skipped (18:14)
cli	82 passed, 1 failed ← pre-existing
modules	115 passed
ledger	26 passed
ruff check / ruff format --check	clean, 150 files
doctor	All 36 assumptions hold

doctor was measured, not computed — 36 read off the tool, and AGENTS.md's two claims say 36/36, so they agree.

The one cli failure is test_doctor_quick_succeeds_against_the_real_installed_bd (model_performance-jyg). I ran it on clean origin/main with none of this PR present and it fails identically — it dies at the first assertion (returncode == 0; the isolated test root has no sweep heartbeat), nowhere near this change. Worth noting it is not the \berror\b collision (model_performance-wp6) that is currently blocking #70: this PR's two new assumption descriptions contain no bare error token.

No overlap with the live wp6 lane — checked before pushing: #72 does not touch tests/_util.py.

FIX with a reproduced fail-before → merging (squash + --admin, plain squash refused by the base-branch review policy as with #67/#353/#58/#49).

[Brian Krabach (bkrabach)]

Re-based a second time onto 1e421cc (main moved again while CI ran — #73 landed). Head is now e93dbf4.

The second rebase was clean, no conflict, and I re-verified rather than assuming: both markers still present in _set_status_with_reason (model_performance-2nx: refuse BEFORE any write and #68: verified write), adapter.py parses, unit 815 passed, ledger green, and the four refusal tests 21 passed.

The one unit failure in that re-run is the known port-binding flake (test_supervisor_web.py) — it failed on serves_https this time, having failed on omits_trust_bootstrap in an earlier run on a different tree, and it does not touch anything in this PR.