Loomworks — conversation search (Companion message search) — scoping note — v0.1

Document: loomworks-conversation-search-scoping-note-v0_1 Version: v0.1 Status: scoping note — queued. Captures the need and early shape; full scoping is a fresh chat after the add-side rework phases land. Date: 2026-06-27 Origin: Operator: an Operator would reasonably recall asking for something and getting an answer, then later (days/weeks) want to see that response again — without re-asking and forcing the request to be re-processed. A way to search past Companion-surface messages.

The need

The Operator wants to find a past Companion exchange — a question asked and the answer given — at any later point, without re-asking (which re-processes the request and may produce a different answer). Find the prior message, see it again.

This fits the product's core thesis directly: recall over a body that does not forget. Finding a past exchange without re-asking is recall — applied to the conversation itself.

The important distinction — conversation search ≠ recall

There are two different bodies, and they must not be conflated:

• Recall (existing — ask_about_past_input): searches committed assertions (notes on record). "What do I have on record about parking?"
• Conversation search (this note): searches the Companion message stream — the chat history itself. "Find where the Companion listed those song suggestions."

A Companion answer (e.g. the Led Zeppelin song list) is a conversation message, not a committed assertion — so recall would not find it. Conversation search covers the message stream that recall doesn't. The Operator may expect one to cover the other; the relationship between them is a scoping decision (see below).

Early shapes (to settle at full scoping)

1. A command — "search for …" / "find where you told me about …" → searches Companion messages, surfaces matches.
2. A search field on the Companion surface — a persistent search affordance over the conversation stream.
3. Both — command for voice-first, field for direct text search.

Early lean: both. A spoken "find where you …" fits the voice-first posture; a search field on the Companion surface is the direct-manipulation reference. Settle at full scoping.

What full scoping needs (the open questions)

• The data is already there. The conversation stream is paginated (CR-1/CR-2, keyset on (created_at, id)) — the messages are stored and fetchable. Conversation search reads that existing body; it likely does not need new storage, just a search path over it.
• Search mechanism. Text match over message content (simple, deterministic) vs. semantic/LLM search (finds by meaning, fuzzier). The recall side dumps the committed set to the LLM to focus; conversation search could do likewise, OR be a deterministic text search (more predictable, no re-processing — which is the point the Operator is making: don't re-process, just find). Lean: deterministic text search first — it matches the Operator's stated intent (see it again without re-processing), and is cheaper/predictable; semantic search is a later enhancement.
• Scope of the search. Within the current engagement's conversation only, or across all engagements' conversations? (Recall is engagement-scoped; conversation search probably should be too, with cross-engagement as a later option.)
• Result presentation. Show the matching message(s) in place (scroll/jump to them in the stream) vs. a separate results list. Jumping-in-place preserves context (you see the question and answer together).
• Relationship to recall. Are these two separate affordances (search-conversation vs. ask-about-notes), or one unified "find" that searches both bodies and distinguishes the results? Lean: separate but clearly named — they search different things; conflating them muddies what the Operator is asking. But worth deciding deliberately.
• The Companion surface dependency. Searching/jumping-to-a-message needs the Companion surface to actually show the conversation. On desktop it does (ConversationPane). On mobile, the persistent Companion surface is the queued mobile-Companion-as-fifth-swipe-surface work — so mobile conversation search depends on that landing first. Named dependency.

Sequencing

Queued. Do NOT fold into the add-side rework. Scope as its own piece after the add-side phases (4-5) land. Two named dependencies: (1) the mobile-Companion surface (for mobile conversation search to have somewhere to show results); (2) none on desktop — the paginated ConversationPane is ready. Relates conceptually to the recall side and the queued command-discoverability piece (all "find what the system holds").

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — conversation search (Companion message search) — scoping note — v0.1 — 2026-06-27 Find a past Companion exchange without re-asking. Distinct from recall (which searches committed assertions, not messages). Data already there (paginated conversation stream). Early lean: both a "find where you…" command and a search field, deterministic text search first, engagement-scoped, results shown in place. Mobile depends on the queued mobile-Companion surface. Queued — full scoping after the add-side phases.