change_assertion's existing "held target" path is documented (classifier.py:86-91) as frictionless by design: "Held target: revise in place, frictionless. Committed target: supersede via revise_assertion behind a two-turn confirm." That asymmetry was written for the explicit-number case — "change 1 to June 27" — where the Operator already named the target themselves, so no further confirmation is needed.
Live verification during CR-2026-145's build showed the classifier's own reasoning generalizes this same frictionless path to implicit, unnamed corrections too — a plain restatement of a fact, with no number given at all, that the classifier infers on its own is a correction of a specific held item.
Four held facts captured (soil pH, PostgreSQL, deadline, greenhouse watering), then, several turns later:
"For the record, the soil pH is actually 7.0, not 6.5."
Response: "Updated held 1 — it now reads: “The soil pH is 7.0.”." — applied immediately, no proposal, no confirmation. The classifier correctly picked out held item #1 among four candidates purely from conversational/semantic context, extracted held_reference=1, and change_assertion's existing held-target branch revised it in place — the same silent-apply behavior CR-2026-145 was written to prevent, just reached by a different route (an inferred number, not an explicit one).
A paraphrased version ("Actually I was wrong about the pH — it needs to be higher, around 7") produced the identical frictionless result.
By contrast, the same scenario against a committed target does NOT take this frictionless path — it correctly falls through to add_knowledge, where CR-2026-145's new correction-check catches it and proposes before acting. The gap is specific to held targets.
CR-2026-145 was written on the premise that the system has no way to recognize an implicit correction and simply adds a new, unrelated assertion. Live testing showed that premise is only half true: for a held target, the classifier already recognizes the correction just fine — it just acts on it without asking, via a path (change_assertion's frictionless-held branch) that predates this CR and was designed around explicit-number addressing, not inferred addressing. The frictionless design choice made sense when the Operator had to name the number themselves (an explicit act, functionally equivalent to already confirming); it's a different risk when the classifier is inferring the target on the Operator's behalf.
A propose-and-confirm gate on change_assertion's held-target path — but only when the target was inferred rather than explicitly named. The router does not currently retain a signal distinguishing "the Operator gave a number" from "the classifier figured out the number" — held_reference arrives as an extracted parameter either way. Closing this gap likely requires either (a) the classifier flagging inferred-vs-explicit targeting as a distinct extracted parameter, or (b) a different mechanism entirely for the inferred case. Needs its own Step-0 investigation before scoping a fix — deliberately not folded into CR-2026-145, which was scoped and tested against the committed-target gap only.
Not yet scheduled. Recorded so it is not lost. Should be considered before treating CR-2026-145 as a complete closure of the correction-recognition problem — it closes the committed-target half, not the held-target half.