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 may fail independent of the "dismiss" word. CR-2026-151 (staged) fixes "dismiss" not being a recognized trigger word for discard_held. But the original testing also surfaced: "dismiss 15" and "dismiss held 15" both failed with the Companion saying it has no visibility into "held item #15" at all — despite Held 15 ("Prefers typing") genuinely existing in the panel at the time. This suggests a second, distinct problem beyond vocabulary: number-resolution to a specific held item may not reliably reach the held list in some conversational contexts. CR-2026-151 fixes the word; this deeper resolution question remains open and should be re-tested once CR-2026-151 ships, to see whether fixing the trigger word alone resolves it or whether a separate defect remains.
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.