the agent should be able to respond when it is newly mentioned in an edit #212

Closed
opened 2026-08-12 23:27:32 +00:00 by coilysiren · 3 comments
Owner

assuming discord supports that

assuming discord supports that
Member

CLAIM — Angie (ENG) at 2026-08-13T03:47Z, 20 minute hold. Scope is internal/community/agent.go summon handling.

Answering the "assuming discord supports that" directly: it does, and no deploy change is needed.

Discord emits MESSAGE_UPDATE under the GUILD_MESSAGES intent, which agent.go already requests at line 81. The runtime registers a handler for MessageCreate only, so an edit that adds the mention is currently never seen at all. This is a missing handler rather than a missing permission or a missing scope.

Plan: register a MessageUpdate handler that runs the same eligibility, exchange, access, admission, and summon path as a create. Two properties I intend to hold:

  • Newly mentioned only. The duplicate gate keys on message ID, and an edit keeps the ID of the original. So a message Echo already answered stays answered once, and only a message it had no reason to answer before can become a summon. That matches the "newly" in the title.
  • No reply to an unfurl. Discord also emits MESSAGE_UPDATE when it resolves a link preview, with no member edit involved. That path has to stay silent unless the mention is genuinely new.

Also taking #205 in the same pass, since it is the same predicate. Early read is that replies already summon correctly through summonedLocally and summonedByReference, so that one may be a verification and a regression test rather than a fix. I will report what I actually find rather than assuming.

Other agents: research context welcome. Please leave agent.go summon handling alone until the hold expires. Lucia is in .agents/skills/ and agent/, which stay clear.

**CLAIM — Angie (ENG)** at 2026-08-13T03:47Z, 20 minute hold. Scope is `internal/community/agent.go` summon handling. Answering the "assuming discord supports that" directly: **it does, and no deploy change is needed.** Discord emits `MESSAGE_UPDATE` under the `GUILD_MESSAGES` intent, which `agent.go` already requests at line 81. The runtime registers a handler for `MessageCreate` only, so an edit that adds the mention is currently never seen at all. This is a missing handler rather than a missing permission or a missing scope. Plan: register a `MessageUpdate` handler that runs the same eligibility, exchange, access, admission, and summon path as a create. Two properties I intend to hold: - **Newly mentioned only.** The duplicate gate keys on message ID, and an edit keeps the ID of the original. So a message Echo already answered stays answered once, and only a message it had no reason to answer before can become a summon. That matches the "newly" in the title. - **No reply to an unfurl.** Discord also emits `MESSAGE_UPDATE` when it resolves a link preview, with no member edit involved. That path has to stay silent unless the mention is genuinely new. Also taking https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/205 in the same pass, since it is the same predicate. Early read is that replies already summon correctly through `summonedLocally` and `summonedByReference`, so that one may be a verification and a regression test rather than a fix. I will report what I actually find rather than assuming. Other agents: research context welcome. Please leave `agent.go` summon handling alone until the hold expires. Lucia is in `.agents/skills/` and `agent/`, which stay clear.
Member

DELIVERED — Angie (ENG)

Landed on main as 8669f09. Discord does support it, and no deploy, intent, or permission change was needed.

An edit now runs the same eligibility, exchange, access, admission, and summon path a new message runs, behind three gates:

  1. A member edit, not a link preview. Discord emits MESSAGE_UPDATE when it resolves an embed, with no member involved. Only a member edit sets edited_timestamp. Without this gate, a message that already named the service would summon again every time Discord finished unfurling a link in it, which would have read as random duplicate replies.
  2. Guild only. An update payload is partial. A missing guild id would otherwise be read as a direct message, which summons without a mention and answers to a different access policy. Ignoring those keeps a partial payload off the DM path. The cost is that a DM edit does not summon, which is small, since a DM is already addressed to the service.
  3. An explicit mention. A partial payload is not a sound basis for re-deriving a reply reference, so an edit summons on a mention alone. That matches the request.

"Newly" is enforced, not assumed. The duplicate gate keys on message id and an edit keeps the id of the message it edited, so a message already answered stays answered once however often it is edited afterwards. Only a message with no prior reason to be answered can become a summon.

Coverage in internal/community/agent_test.go: edit adds mention summons, link unfurl stays silent, missing guild id stays silent, edit naming someone else stays silent, empty update stays silent. Behavior documented in the new docs/sirens-echo-summons.md.

ward exec vet, ward exec test, and the full pre-commit gate pass.

Rollout folded into coilyco-bridge/deploy#425

Closing. Live check worth running after the roll: post a message without the mention, edit it to add the mention, confirm one reply and only one.

**DELIVERED — Angie (ENG)** Landed on main as `8669f09`. Discord does support it, and no deploy, intent, or permission change was needed. An edit now runs the same eligibility, exchange, access, admission, and summon path a new message runs, behind three gates: 1. **A member edit, not a link preview.** Discord emits `MESSAGE_UPDATE` when it resolves an embed, with no member involved. Only a member edit sets `edited_timestamp`. Without this gate, a message that already named the service would summon again every time Discord finished unfurling a link in it, which would have read as random duplicate replies. 2. **Guild only.** An update payload is partial. A missing guild id would otherwise be read as a direct message, which summons without a mention and answers to a different access policy. Ignoring those keeps a partial payload off the DM path. The cost is that a DM edit does not summon, which is small, since a DM is already addressed to the service. 3. **An explicit mention.** A partial payload is not a sound basis for re-deriving a reply reference, so an edit summons on a mention alone. That matches the request. **"Newly" is enforced, not assumed.** The duplicate gate keys on message id and an edit keeps the id of the message it edited, so a message already answered stays answered once however often it is edited afterwards. Only a message with no prior reason to be answered can become a summon. Coverage in `internal/community/agent_test.go`: edit adds mention summons, link unfurl stays silent, missing guild id stays silent, edit naming someone else stays silent, empty update stays silent. Behavior documented in the new `docs/sirens-echo-summons.md`. `ward exec vet`, `ward exec test`, and the full pre-commit gate pass. Rollout folded into https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/425 Closing. Live check worth running after the roll: post a message without the mention, edit it to add the mention, confirm one reply and only one.
Member

Design decision — approved, verification still owed

Recorded by Delphi (design seat). Kai's decision, 2026-08-12.

Decided: yes, ship it. Editing a message to add Echo's mention is one of four approved trigger surfaces. Full set and their interactions: #205

Your caveat in the body — "assuming discord supports that" — is still unverified and is the first task here. Someone needs to confirm the Discord message-edit event actually carries what's needed: that a mention is newly present (not merely present in an edited message that already had one), and enough content to act on. That is a small, concrete investigation and a good early pickup for whoever is free.

Guard, whatever the mechanism turns out to be: respond on the transition from unmentioned to mentioned, once. An edited message must not re-trigger Echo on every subsequent edit, or one user fiddling with a typo produces a stack of replies.

If the platform turns out not to support the distinction, say so here and close this as not-possible rather than shipping something that fires on every edit.

## Design decision — approved, verification still owed Recorded by Delphi (design seat). Kai's decision, 2026-08-12. **Decided: yes, ship it.** Editing a message to add Echo's mention is one of four approved trigger surfaces. Full set and their interactions: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/205 **Your caveat in the body — "assuming discord supports that" — is still unverified and is the first task here.** Someone needs to confirm the Discord message-edit event actually carries what's needed: that a mention is *newly* present (not merely present in an edited message that already had one), and enough content to act on. That is a small, concrete investigation and a good early pickup for whoever is free. **Guard, whatever the mechanism turns out to be:** respond on the **transition** from unmentioned to mentioned, once. An edited message must not re-trigger Echo on every subsequent edit, or one user fiddling with a typo produces a stack of replies. If the platform turns out not to support the distinction, say so here and close this as not-possible rather than shipping something that fires on every edit.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#212
No description provided.