Keep reasoning out of chat noise—and make it useful in Details

The issue

Lovable groups internal model work under the completed card: its main chat stays compact, while Details contains chronological, expandable thought content. PeachJam currently renders every model-call duration in chat and shows the same calls as disabled rows in Details.

What Lovable actually does

The current public Lovable client reduces its trajectory stream into ordered message parts. An agentOutputThinking event becomes a first-class object with content, its source event ID, a start timestamp, and a duration calculated when the next output event arrives.

{
  "type": "thinking",
  "content": "The user wants a minimal sentinel website…",
  "durationMs": nextOutputTimestamp - thinkingStartTimestamp,
  "startedAtMs": thinkingStartTimestamp,
  "thinking_event": "trajectory-event-id"
}

For persisted legacy messages, the same information appears as ordered custom nodes inside the AI message:

<lov-tool-use name="lov-think"
  data="The user wants me to build something directly…">
<lov-tool-use name="imagegen--generate_image" …>
<lov-tool-use name="lov-think"
  data="I'm setting up the design system…">

Its chat selector then joins thought content into one aggregate and applies this rule:

showChatThought = hasThinking && !(hasActivity && initialAssistantText == null)

// Details does not use that suppression rule:
detailsRows = orderedParts.filter(part => part.type == "thinking")

PeachJam’s actual provider gap

The authenticated PeachJam image-build trace contains 23 DeepSeek model calls. Every call returned a reasoning item with a non-empty content[] entry typed reasoning_text; every summary[] was empty. Text lengths ranged from 29 to 1,579 characters. The adapter recognizes the reasoning item and preserves the complete raw JSON, but copies none of this content into a display field.

Suggested narrow fix

1. Normalize Lovable-equivalent content. Accept only reasoning.content[].reasoning_text; if absent, fall back to reasoning.summary[].summary_text. Trim empties, preserve order, and join multiple allowed entries with paragraph breaks.
2. Keep it separate from model transcript text. Add a dedicated ThinkingText field to the internal provider output item. Do not reuse Text.
3. Project it chronologically. Put sanitized thinking_text on the existing model-call completion event. That event already sits before the tool calls produced by the same response, matching Lovable’s ordered part model.
4. Use the existing Details contract. The frontend already accepts thinking_text; each per-call Details row becomes expandable without another endpoint or fetch.
5. Aggregate only for chat. Keep individual thoughts in Details. For chat, collapse eligible thinking to one marker. Completed work-card turns have zero chat markers; answer-only turns have exactly one; active pre-activity thinking may have one.
6. Leave absent content absent. If neither allowlisted field is present, keep the duration-only non-expandable row. Never decrypt, infer, or fabricate text.

Exact before / after contract

The phrase “changing provider-response handling” means changing PeachJam’s normalization of response bytes it already receives. It does not mean changing the request sent to the model or requesting additional reasoning.

1. Provider response: unchanged

{
  "type": "reasoning",
  "id": "rs_123",
  "content": [
    {"type": "reasoning_text", "text": "I should inspect the app before changing the layout."}
  ],
  "summary": []
}

2. Provider adapter: one new display-only field

OutputItem{
  Type:   OutputItemTypeReasoning,
  Status: "completed",
  Text:   "",
  Raw:    originalRawJSON,
}

OutputItem{
  Type:         OutputItemTypeReasoning,
  Status:       "completed",
  ThinkingText: "I should inspect the app before changing the layout.",
  Text:         "",
  Raw:          originalRawJSON,
}

3. Persisted model transcript: unchanged

Both before and after, model replay receives the same empty text, original raw item, stable IDs, and visibility. The display field is deliberately not copied here.

{
  "type": "reasoning",
  "text": "",
  "raw": {"...": "original reasoning item"},
  "visibility": {
    "model": true,
    "chat": false,
    "timeline": false,
    "debug": true
  }
}

4. Execution event: optional user-facing thought content

{
  "title": "Model call completed",
  "payload": {"diagnostics": {
    "call_index": 1,
    "duration_ms": 4680,
    "model": "deepseek/deepseek-v4-pro",
    "provider": "responses-compatible"
  }}
}

{
  "title": "Model call completed",
  "payload": {"diagnostics": {
    "call_index": 1,
    "duration_ms": 4680,
    "model": "deepseek/deepseek-v4-pro",
    "provider": "responses-compatible",
    "thinking_text": "I should inspect the app before changing the layout."
  }}
}

5. User-facing behavior

Safety and non-goals

How we will prove it

Focused automated tests

• Adapter: extract one/multiple reasoning_text entries; fall back to summary_text; ignore empty, malformed, arbitrary, and encrypted-only fields.
• Replay invariant: prove the new display field is not copied into transcript Text, raw JSON is unchanged, and continuation IDs/order remain stable.
• Executor: project redacted and bounded thinking_text onto the matching model-call completion event; omit it when no allowlisted content exists.
• Chronology: assert thought → tool/image/edit → next thought ordering in Details.
• Chat exactly once: an answer-only fixture with several model calls renders one chat-thinking-item, not one per call.
• Work-card suppression: completed text-only and image builds render zero chat Thought markers while every thought remains expandable in Details.
• Active transition: allow at most one active pre-activity marker; remove it from chat once work activity owns the turn.

Real live-run acceptance

Implementation and verification status

Planned code surface

Recommendation

Approve the revised, evidence-backed response-normalization change: copy only reasoning.content[].reasoning_text, falling back to reasoning.summary[].summary_text, into display-only ThinkingText; project it as thinking_text; leave replay and the provider request untouched.

Then refine chat aggregation to Lovable’s at-most-one ownership rule, run focused Go and Playwright tests, and complete all three real provider-backed acceptance runs before the draft PR moves toward merge.