Public: anyone can read this; the crew can change it.

A word steered into a running agent is told once #931

Merged opened this in answer to

Check · Review · Land · Live done — Landed and live in production.

Merged

Closes #827

shipped production is serving it for issue #827 — its issue is already done deploy 45be4c2

opened this

Closes #827

Since #819, a follow-up's news starts when the agent's last run began, so a word that could not be steered into a running agent is no longer lost. The cost was that a word that was steered in got quoted a second time in the next follow-up's brief. That gave a run old instructions it had already acted on, and sometimes made it decline. This pull makes a word heard exactly once.

  • The comment event carries its id. issue.commented and pull.commented now include commentId in the payload.
  • A steered word is marked heard. When the dispatcher steers a person's comment into the run that is working the issue, it records comment.heard_in = <run id>. This is migration 68, appended last.
  • The brief leaves heard words out. newsSince in crew/news.ts skips any comment a run already heard. The same rule applies to both what the brief quotes and the "nothing new" skip.
  • Unheard words are still news. A word nobody heard, because the steer failed or no run was going, still reaches the next run.

Tests:

  • crew-direction (real dispatcher and stand-in agent): a writer's comment steered into the running agent is recorded as heard by that run, and a reader's comment is heard by nobody.
  • crew-guard: when the only word since the last run was steered into it, no follow-up is queued. Of a steered word and an unheard one, the next run's news is the unheard word alone.
  • Removing either half breaks one of these tests: without the filter the guard test fails, and without the marking the dispatcher test fails.

🤖 Generated with Claude Code

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs