Build 11.5 — Real LLM response path and chat transcript stabilization

[grumpystrongman]

Build 11.5 target

Start Build 11.5 for ThreadlineAI.

Product goal

Move the sidecar from prompt composition into an actual usable ask/answer loop while keeping the UI stable and context-aware.

Current working assumptions

• Active Window Content Resolution is complete.
• Sidecar Shell is stabilized.
• Auto-Follow and Follow/Lock are working.
• Ask currently composes prompts using resolved context, but does not yet return real LLM answers.

Scope

1. Stabilize the ListView-based conversation UI.
2. Improve the chat-style transcript:
   • Distinct user vs Threadline messages.
   • Reliable scroll-to-bottom behavior.
   • Clean message list rendering without diagnostic clutter.
3. Implement the real LLM response path:
   • Send composed prompt/context to the configured provider.
   • Surface assistant response in the conversation transcript.
   • Handle provider errors in a user-readable way.
4. Preserve Follow/Lock behavior when asking about current context.
5. Keep diagnostics hidden from the normal user experience unless explicitly enabled.

Acceptance criteria

• User can type an Ask request and see their message added to the transcript.
• Threadline sends the resolved/composed context to the provider path.
• Threadline response appears as a separate assistant message in the transcript.
• Conversation list remains stable during repeated asks.
• UI scrolls naturally as new messages arrive.
• Provider failures do not crash the app and produce a useful message.

Out of scope for this build

• Full workflow/action automation.
• Long-term memory.
• Browser extension expansion beyond current capture behavior.
• New provider configuration UX unless required to complete the response path.

Notes

This build should stay focused. The win is turning the current sidecar into a real conversational loop over resolved app/window context.

[grumpystrongman]

Build 11.5 retry status:

Completed Windows-side build work:

• Added ThreadlineLocalClient.AskAsync(...) for POST /sessions/{sessionId}/ask.
• Added AskResponseDto and a typed ThreadlineEndpointNotFoundException so the sidecar can distinguish a missing service endpoint from real provider/service failures.
• Updated MainWindow.AskAsync() so the chat flow now:
  • appends the user message immediately,
  • resolves current context,
  • sends the Ask request to the provider-response path,
  • appends the assistant answer as a separate Threadline message,
  • falls back to prompt composition only when the local service does not yet expose /ask.
• Updated service API docs with the Build 11.5 Ask contract.
• Updated README current status for Build 11.5.

Important limitation:

• I could not safely patch the backend endpoint implementation because the connector can fetch known files but is not listing/searching the service endpoint source files. The Windows side is ready for the endpoint and will degrade cleanly until the service route exists.

Commits made during this build include:

• 7904a7e client Ask contract
• b4df8f7 Ask response transcript route
• adae1ff service API docs
• f1f1d78 README status
• 0f823d5 cleanup

Next required backend work: implement POST /sessions/{sessionId}/ask in the service by reusing prompt composition and calling the active provider abstraction.