discard_held at all, since "dismiss" wasn't a recognized trigger word) — not a second, separate resolver bug as v0.2 speculated. CR-2026-151 (adding "dismiss" as a trigger word) is the complete fix for that specific symptom; no further number-resolution work is needed on that front.
Observed (E0060, 6:08 PM): After a sequence (change 12 → a conversational comment → a save-offer), the Operator said "happy to say that the brown leaf is now fixed." The Companion offered "Good news for Fenwick! Want me to save that as a note?" The Operator said "yes" → the Companion tried to commit held 14 (a non-existent number) and replied "I don't see a held item 14 here, so I haven't committed anything."
The defect: the bare-"yes"-after-offer mechanism does not reliably bind to the just-offered note when the conversation is complex. The "yes" resolved to a phantom number instead of committing the offered item. A clean "speak note → yes" works; a messy multi-turn conversation breaks the binding.
Root cause to diagnose (not patch the phrase): why does "yes" resolve to a number at all, and why a phantom one? The confirm flow should bind "yes" to the specific offered note's display_number carried in context — not re-parse the utterance for a reference. The offered-note context is likely not being carried forward reliably, so "yes" falls through to number-extraction and lands on garbage.
Observed: Warm/observational remarks ("Fenwick looks healthy today," "happy to say the brown leaf is now fixed") get captured/offered as held notes. The wide net built for commit phrasings has a sibling problem on the capture side: the classifier reads observations as add-knowledge intents, so conversation becomes memory too eagerly.
Concrete evidence (E0030 Personal space, 2026-07-01): two distinct sub-problems, both visible in the Operator's own personal Memory:
The design question (not obviously a bug): should every observation become a held note, or should the Companion distinguish "this is a fact to record" from "this is conversational" and "this is a command to execute"? Corrections-spawn-duplicate suggests the capture path doesn't recognize "this is a refinement of the thing I just captured" — related to, and possibly sharing a fix with, R1's referent-tracking gap.
Number-resolution to held items — confirmed NOT a separate defect. The original testing surfaced "dismiss 15" and "dismiss held 15" both failing, with the Companion claiming no visibility into "held item #15" at all — despite Held 15 genuinely existing at the time. CR-2026-151's Step-0 investigation tested this directly: bare-number resolution and the full discard round-trip both worked cleanly for a held item #15 in an isolated scratch test. This confirms the original symptom was pure misclassification — "dismiss" wasn't a recognized trigger word, so the utterance never reached the discard-handling code at all. CR-2026-151 (adding "dismiss" as a trigger word, merged) is the complete fix. No further action needed on this thread.
The wide-net reduction (still owed). CR-2026-127 shipped the commit-acceptance net deliberately wide, pending reduction by observed usage (not done in the abstract). Not yet executed.
Both R1 and R2 are real Operator-authority and "corrections preserved, not smoothed" concerns: R1 risks the Companion acting on the wrong item without clear signal; R2 risks Memory accumulating noise (commands treated as facts) and losing correction relationships (duplicates instead of supersession) — the same category of problem CR-2026-145 later fixed for one specific case (voice-dictated corrections to committed facts). R1/R2 predate CR-2026-145 and cover the broader, still-unfixed pattern across held items generally, not just the voice/committed-correction case.
Both are ready to become a properly scoped CR — root causes are reasoned about but not diagnosed by direct code trace. Recommend Step-0 investigation (mirroring this session's discipline) before drafting a build brief.