Skip to content

fix(chat): an answer before a wake-up nobody typed is not folded into the next turn's work - #483

Merged
devswha merged 3 commits into
mainfrom
fix/omo-answer-before-wake
Oct 5, 2026
Merged

devswha merged 3 commits into
mainfrom
fix/omo-answer-before-wake

Conversation

@devswha

@devswha devswha commented Oct 5, 2026

Copy link
Copy Markdown
Owner

Change

In the chat of an OmO pane (and omp, gjc, pi: they share parseOmpTranscript), adjacent assistant messages merged into one turn unless a user message or a shown notice came between them. OmO wakes its agent with hidden custom_message records (senpi-monitor:notification, senpi-terminal:notification, goal-continuation, ... all display: false). #477 draws the background-task wake as a card, but every other wake still merged the work after it into the turn before. The chat shows only the text after a turn's last action as the answer, so the earlier final answer was folded under "Worked for".

Seen live: a 6-minute review turn ended with the full review (stopReason: "stop"), a monitor notification woke the agent 7 ms later, and it wrote one short line. The chat showed "Worked for 5m 43s" and the short line only; the review was inside the fold while the terminal showed it.

The fix: an assistant message that stopped for good (stopReason: "stop") ends its turn, so the next assistant message starts a new one. This covers any wake, named or not, without listing custom types. toolUse and error (OmO retries after an error) keep merging as before. Hidden custom_message records are not used as the boundary themselves, because some (omo-kibitzer:recall, environment-context, omo-memory:notice) are injected mid-turn.

Validation

  • bun run typecheck: clean. bun run test:unit: 1376 pass, 0 fail.
  • New case in server/conversation.test.ts: answer, hidden monitor notification, short answer → two assistant turns, the first ending on its answer.
  • Re-parsed the real OmO session file from the report: the turns after the user's message are now three, whose answers (splitTurn) are "Codex 결과를 기다리는 중…", "Ask: feat(terminal): 다른 웹 UI 서버가 연 pane을 여기서 열기로 가져오기 #368 리뷰…" and "이 알림은 이미 반영된…", instead of one turn answering only the last.

Not tested

  • No browser run: the client is unchanged and already renders consecutive assistant turns (same as a gjc notice split).

@coderabbitai

coderabbitai Bot commented Oct 5, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration
  • Configuration used: Repository: devswha/herdr-web-ui/.coderabbit.yaml
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 49a1c379-2a1b-413d-abdb-2bb671a503a7
📥 Commits

Reviewing files that changed from the base of the PR and between ef8f9ea and 4edefc0.

📒 Files selected for processing (3)
  • CHANGELOG.md
  • server/conversation.test.ts
  • server/transcript-records.ts
 _________________________________________
< Make it work, make it right, make it 🥕. >
 -----------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).
✨ Finishing Touches
📝 Generate docstrings
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR
  • Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Comment @coderabbitai help to get the list of available commands.

@devswha
devswha merged commit c5eb477 into main Oct 5, 2026
11 of 12 checks passed
@devswha
devswha deleted the fix/omo-answer-before-wake branch October 5, 2026 22:43
devswha added a commit that referenced this pull request Oct 6, 2026
Its branch had appended the tab-strip sentence to the fonts entry under
[0.3.50], which was released before #479 merged. The sentence is its own
entry under [0.3.51] Fixed, and the 0.3.50 entry links #473 alone again.

Bumps package.json and herdr-plugin.toml to 0.3.51 and moves the
Unreleased notes under [0.3.51] - 2026-10-06, with the compare link. Raises the
remote PC bundle to 18: #368 adds the `take-over` capability the bridge
advertises, and #477, #483, #484, #485 and #486 change what the bridge reads
(transcripts, prompts, process start times, a pane's Codex store), so a
remote PC on bundle 17 keeps the old behaviour until its bridge is updated.
Push the `remote-v18` tag and let the bundle workflow publish before
running release.yml.

Carries #368 #477 #479 #481 #482 #483 #484 #485 #486 #487

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant