feat(gastown): parse H1 headers from agent output as automatic status updates#1374
Merged
jrf0110 merged 2 commits intoconvoy/parse-agent-status-from-h1-headers-repla/52d188d7/headfrom Mar 23, 2026
Conversation
… updates Parse markdown H1 headers from message.part.updated events in broadcastEvent() and post them to the agent status API. This provides dashboard visibility into agent activity without requiring agents to call gt_status explicitly. - Uses last H1 match (most current) when multiple exist in one text part - Deduplicates via lastStatusForAgent Map to avoid redundant API calls - Truncates status to 120 characters - Cleans up lastStatusForAgent on agent exit/stop/failure/shutdown Refs: #1307
Contributor
Code Review SummaryStatus: 1 Issues Found | Recommendation: Address before merge Overview
Fix these issues in Kilo Cloud Issue Details (click to expand)WARNING
Other Observations (not in diff)None. Files Reviewed (1 files)
Reviewed by gpt-5.4-20260305 · 306,482 tokens |
…rtial matches The H1 regex was matching incomplete headings during streaming, causing dozens of /status writes per heading as each token delta produced a different partial match. Adding a trailing newline requirement ensures status is only posted once the heading line is fully streamed.
| // Require a trailing newline so we only match completed headings; without it, | ||
| // every streaming delta would match the partial heading being typed and spam | ||
| // the /status endpoint with incremental fragments. | ||
| const matches = [...part.text.matchAll(/(?:^|\n)# (.+)\n/g)]; |
Contributor
There was a problem hiding this comment.
WARNING: This skips headings that end the text part
Requiring \n means # Done only matches if another line arrives afterward. Since this branch only runs on message.part.updated, an H1 that is the final line of the streamed text never reaches /status, so the dashboard can miss the agent's latest phase. Consider flushing the final heading on a completion event (or another signal that the text part is finished) instead of making newline the only terminator.
efbf99a
into
convoy/parse-agent-status-from-h1-headers-repla/52d188d7/head
2 checks passed
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Parse markdown H1 headers from
message.part.updated/message_part.updatedevents inbroadcastEvent()and post them to the agent status API. This provides dashboard visibility into what agents are doing without requiring explicitgt_statustool calls — agents just write naturally with H1 headers at phase transitions.Key implementation details:
lastStatusForAgentMap to avoid redundant API callslastStatusForAgententries at all agent exit paths:exitAgent(), stream error handler,stopAgent(), andstopAll()Refs: #1307
Verification
Visual Changes
N/A
Reviewer Notes
agents.get(agentId)call at line 173 (agentMeta) is redundant sinceagentwas already fetched at line 114 and is still in scope. Not a bug, but a minor inefficiency.(?:^|\n)# (.+)could theoretically match code comments (e.g., Python#) in code blocks, but false positives would just produce a slightly wrong status update — low severity and self-correcting.process-manager.tshas no existing test infrastructure to extend.