Version. 0.1 Date. 2026-06-30 Status. Recorded follow-on. Surfaced during CR-2026-127 live testing. NOT blocking — CR-2026-127's core grammar works and is pushed. These are the edges found by talking to it under realistic, messy conversation. To become a focused robustness CR (and a separate image-pathway item). Origin. Operator live-testing CR-2026-127 in E0060, 2026-06-30. Found by real conversation, not unit tests — the value of testing-by-talking.
Verified by the Operator talking to the Companion, not by suite assertions:
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." Companion offered "Good news for Fenwick! Want me to save that as a note?" Operator said "yes" → 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 (14) instead of committing the offered item. Offered-note referent tracking is fragile under realistic back-and-forth. A clean "speak note → yes" works; a messy multi-turn conversation breaks the binding.
Root 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. Likely the offered-note context isn't 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. Some of these are genuine facts to record; some are just conversational warmth. The wide net we 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 (2026-07-01, E0030 Personal space): Inspecting the Operator's Personal engagement made R2 vivid and showed two distinct sub-problems:
The design question (not obviously a bug): should every observation become a held note offered for saving, or should the Companion distinguish "this is a fact to record" from "this is conversational" AND "this is a command to execute"? The burden swung from "nothing commits" (the original bug) to "everything gets held" — including commands and every incremental correction. The right resting point is somewhere between — and it's a feel question to settle by talking, like the wide-net reduction. Note the tie to the routing finding: correction-spawns-duplicate suggests the capture path doesn't recognize "this is a refinement of the thing I just captured" — which is related to (and may share a fix with) the referent-tracking gap (R1).
CR-2026-127 shipped the commit-acceptance net DELIBERATELY WIDE pending reduction. The reduction was not done — ship-wide-reduce-later was chosen (over-acceptance is harmless; one session can't tell surplus from staple; let a week of real use carve it down). The accepted set to reduce from (in the prompt, marked intentionally wide): bare affirmatives (yes/yeah/yep/ok/okay/sure/do it/go ahead/yes please), save-verbs (save it/save that/keep it/commit it/save/keep), confirm-verbs (confirm/confirm it/confirm that), numbered (save N / save N-word / commit one). Reduce by observed usage, not in the abstract.
These touch the upload/file-analysis pathway, not the held-tray grammar. Record separately; ground against the upload pathway's intended design (there is prior upload-pathway investigation + a Phase 59 upload-completion CR) before scoping.
Observed (E0060, 5:57 PM): Uploaded "Monstera deliciosa New Leaf.jpg". Companion surfaced a skill-picker — "I think this is —" (BLANK description) with image_metadata (0%), image_ocr (0%), image_vision_analysis (0%) — all three skills at 0% confidence. After proceeding: "Here's what I found in that file" with only the filename, no description of the image content. The Operator remembers the upload process adding a description during engine testing — so this looks like a regression or disconnection. 0% across all skills suggests the confidence scorer or the vision skill wiring, not the image. Diagnose as a probable regression.
Observed: The image upload produced NO held assertion — nothing in the Memory panel, nothing to commit. A spoken note becomes a held item; an uploaded image goes through a different (skill-picker/file-analysis) path that doesn't feed the held-tray. So an uploaded image is a second-class citizen — it doesn't become memory the way a spoken note does.
Design question (needs grounding): should an uploaded image (or its description) become a held assertion that flows through the same capture→confirm→commit grammar? Claude's read: yes, consistent with the seed's "Memory accumulates with provenance" — a file the Operator uploaded about the subject should be able to enter Memory. But this touches the upload pathway's design; ground against what upload was scoped to do (was image-into-memory specified, deferred, or never built?) before treating I2 as a defect vs unbuilt.