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

The provider gap we closed

The authenticated pre-fix PeachJam image-build trace contained 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. Before this fix, the adapter preserved complete raw JSON but copied none of the displayable content into the timeline contract.

Implemented narrow fix

1. Normalize Lovable-equivalent content. Only reasoning.content[].reasoning_text is accepted; when absent, reasoning.summary[].summary_text is used. Empty values are trimmed, ordering is preserved, and multiple allowed entries are joined with paragraph breaks.
2. Keep it separate from model transcript text. A dedicated ThinkingText field carries display metadata; transcript Text is untouched.
3. Project it chronologically. Sanitized, bounded thinking_text is attached to the existing model-call completion event before the tool calls produced by that response.
4. Use the existing Details contract. Each per-call Details row becomes expandable without another endpoint or fetch.
5. Aggregate only for chat. Individual thoughts remain in Details. Completed work-card turns have zero chat markers; answer-only turns have exactly one; active pre-activity thinking has at most one.
6. Leave absent content absent. When neither allowlisted field exists, the duration-only row remains non-expandable. No text is decrypted, inferred, or fabricated.

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 proved it

Focused automated verification

• Adapter: one/multiple reasoning_text entries, summary_text fallback, and empty/malformed/arbitrary/encrypted-only rejection all pass.
• Replay invariant: the display field is not copied into transcript Text; raw JSON, continuation IDs, and order remain stable.
• Executor: redacted and bounded thinking_text reaches the matching model-call completion event and is omitted when no allowed content exists.
• Chronology: thought → tool/image/edit → next thought ordering is asserted 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: at most one active pre-activity marker is allowed and ownership transfers to the work card when activity begins.

Real provider-backed production acceptance

Sanitized live-state captures: sentinel build, answer-only follow-up, and image build.

Production video demos

These are direct Playwright recordings of the authenticated production UI after deployment. No DOM was altered and no behavior was mocked. Each recording starts on the real chat surface and then opens the real Details timeline.

Video audit: VP9 WebM (sentinel 960×1138; image 1280×800) with full-resolution H.264 fast-start MP4 fallback. Sentinel: 8.0s. Image build: 11.2s. Beginning, middle, and end frames were visually inspected before deployment; deployed WebM playback and seeking were then verified in Chromium.

Implementation and verification status

Shipped code surface

Outcome

The parity gap is closed: PeachJam now copies only reasoning.content[].reasoning_text, falling back to reasoning.summary[].summary_text, into display-only ThinkingText; projects it as bounded thinking_text; and leaves replay and the provider request untouched.

Chat and Details now have separate ownership: chat stays compact under the observed Lovable rule, while Details preserves the full ordered evidence. The implementation is merged, production-deployed, and verified by both automated tests and real model-backed website-creation runs.