Held-Tray Conversational Robustness + Image Findings — Follow-On Scope

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.

What works (pushed in CR-2026-127 — the core is solid)

Verified by the Operator talking to the Companion, not by suite assertions:

Capture shows the held number ("Got it — held N: '...'. Want me to save it?").
Commit by reference: "commit N", "commit all" — one-shot, no second yes (the addressed command is the approval).
The wide commit net works: "save", "yes", "confirm", "keep it", "save it" all commit.
"confirm" is an accepted commit verb (the word on the held-card button).
Number-words work spoken ("commit two", "every one"→all).
Change in place (held) and supersede-with-confirm (committed, prior preserved).
Discard records, never erases.
Timestamps on held cards, matching the conversation format.
Panel reactive: held-tray actions refresh the Memory panel live (incl. on capture).
Never-silent contract: every inbound utterance gets a response. Cut-off speech recovers gracefully ("That seemed to cut off mid-thought — keep going?"). Garbled input gets a fallback, never silence. Structural guard at the converse chokepoint.

Follow-on Finding R1 — "yes" loses its referent under conversational complexity

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.

Follow-on Finding R2 — over-eager capture of conversational comments

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:

Commands captured as notes. Held 11 "Show birthdays" and Held 19 "Parked on 13." — these are commands/queries the Operator issued ("show birthdays", something about parking on level 13), but they were held as if they were facts to remember. A command became a note. (Note: "Show birthdays" as a held note is the same string that showed as a held item in CR-127's on-main verification — it's been sitting mis-captured for a while.)
Corrections created duplicates instead of revising. Held 21, 22, 23, 24, 26 are all variants of the SAME Friday meeting, captured as separate notes as the Operator corrected details turn by turn ("Meeting on Friday at Claude code Miami." → "…from 5:30 p.m. to 9:00 p.m." → "…with Justin to make him aware of steel and Loom works." → "…Aldous might come"). Each correction spawned a NEW held note rather than revising the prior one. So the personal tray is cluttered with near-duplicate meeting notes plus command-fragments.

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).

Follow-on — the wide-net reduction (still owed)

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.

Image-pathway findings (separate subsystem — not CR-127, not the robustness CR)

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.

Image Finding I1 — image-description degraded/disconnected

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.

Image Finding I2 — uploaded image does not enter Memory

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.

Sequencing recommendation

CR-2026-127 core: PUSH (done — the working grammar lands).
Robustness CR (R1 referent-tracking + R2 over-eager-capture + the reduction): a focused follow-on, scoped fresh, not patched at session-tail.
Image findings (I1 regression + I2 design): separate, grounded against the upload pathway.
Then Room 1 → Finding 1b (retract, after this) → Finding 3 (false-success audit) → Room 1 closes.

DUNIN7 — Done In Seven LLC — Miami, Florida · Loomworks — Held-Tray Robustness + Image Findings — v0.1 — 2026-06-30