feat(orch): two-way comments for actively-worked issues (route in + comment_issue out)#69
Merged
Conversation
When an allowlisted @-mention lands on an issue that already has an active objective, triggerIssueObjective used to just return — a fresh comment (mid-flight guidance like "look at PR #X first") reached no one. Now route it to the objective's manager via Steer, so the manager can act on it directly or relay it to a running worker with message_session. If the objective has parked with no live manager (e.g. its PR is up for review), a new human comment is actionable, so revive a manager with the comment baked into its resume prompt — mirroring notifyManagerOfMerge — while respecting the manager respawn budget. A waiting_user or budget-exhausted objective records an audit event instead. Each comment is claimed once (RecordIssueTask), so a re-poll never re-delivers. Assignments carry no body and still no-op when the issue is already active.
…thread The manager could route an issue comment down to its workers (prior commit) but had no sanctioned way to reply ON the issue: orcha's MCP surface had no issue-comment tool, so a public reply could only go out via a worker's raw `gh issue comment` — untracked and bypassing the comment_pr guardrails. Add a manager comment_issue tool (and Orchestrator.CommentIssue) that posts as the bot on the GitHub issue the objective was created from. The target issue is resolved server-side from issue_tasks (Store.IssueForObjective), so the manager can only comment on the issue it is working — it passes no number. The body is tagged with the bot marker like CommentPR so the mention monitor never re-ingests orcha's own reply. The routing message and manager preamble now point at comment_issue and forbid the gh CLI for issue/PR replies.
nathanwhit
changed the title
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
1 participant
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.
Closes the loop on comments for issues orcha is actively working — both directions.
Problem
When orcha picks up a GitHub issue (via @-mention or assignment) and is actively working it, a follow-up comment on that issue reaches no one.
triggerIssueObjectivefinds the already-active objective and justreturns, so mid-flight guidance — "look at PR #X first", "also handle Windows", a correction — is silently dropped. PRs have a full feedback→follow-up pipeline; issues had only a one-shot trigger. And even once an agent did learn of a comment, the bot had no sanctioned way to reply on the issue thread.Real example: denoland/deno#35516 — the bot picked up the issue, then a maintainer left
@nathanwhitbot you might want to look into #32789 first. orcha's event system never saw it; the pointer only got addressed because a human hand-relayed it into the worker via the dashboard steer box, and the eventual reply went out via the worker's rawgh issue comment.Fix
Inbound (issue comment → team). When an allowlisted @-mention lands on an issue that already has an active objective, route the comment to that objective's manager via
Steerinstead of dropping it. The manager is the coordination point — it decides whether to absorb the guidance,message_sessionit down to the running worker, re-scope, or spawn. (orcha can't know which worker a comment is about; the manager can, and it persists for the whole objective.)notifyManagerOfMerge, while respecting the manager respawn budget.waiting_user/ budget exhausted → record an audit event, leave for the human.RecordIssueTask, so a re-poll never re-delivers.Outbound (team → reply on the issue). Add a manager
comment_issuetool (andOrchestrator.CommentIssue) so the bot can reply on the issue thread through orcha instead of an agent reaching for rawgh. The target issue is resolved server-side fromissue_tasks(Store.IssueForObjective), so the manager can only comment on the issue it's working — it passes no number, just a body. The reply is tagged with the bot marker likeCommentPRso the mention monitor never re-ingests orcha's own comment. The routing message and manager preamble now point atcomment_issueand forbid theghCLI for issue/PR replies.Assignments carry no body and still no-op when the issue is already active.
Tests
TestIssueTrigger_CommentRoutedToActiveManager: a first mention spawns objective + manager; a second mention while active steers the manager (asserted via the transcript), spawns no duplicate objective, posts no second ack, and routes exactly once across re-polls.TestCommentIssue_PostsToIssueWithMarker: the manager replies on its objective's issue with the bot marker appended; an objective not tied to an issue is rejected.comment_issue. Full suite passes.