Reflect message edits and deletions in agent history (Discord, VK, Slack)

Aperta
  • Qualcosa non va?
#32 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
cpp
Ambito
ai, backend

Direzione di ricerca

Start by reading the channel-context work referenced in #14–20 and the related issue #30, then trace how inbound messages enter session history and whether their source message IDs are retained. From there, inspect the Discord, Slack, and VK adapter event handling described in the issue. Done means edits appear as marked appended entries, deletions retain content with a [deleted] marker, and new inbound entries carry source IDs.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

adapter enhancement

Summary

In channels where messages can be edited or deleted (Discord, VK, Slack), the agent's session history never learns about it — survey confirms zero handling of MESSAGE_UPDATE / MESSAGE_DELETE (Discord gateway), message_changed / message_deleted (Slack events), or VK edit events. History diverges from channel reality, enabling two failure classes:

  1. Post-hoc bamboozling: a user gets a reply, then edits their original message — the agent's record (and any later reasoning over that session) now misrepresents what it actually saw. Classic injection vector: the transcript becomes evidence of something that never happened.
  2. Honest confusion: normal human edit/delete behavior (typos, retractions) leaves the agent reasoning over stale phantoms.

Proposed behavior

  • Edited message → appended as a new entry underneath the original, marked as the edited version (original retained, never mutated). History stays append-only; the edit chain is visible and auditable.
  • Deleted message → the original stays in history but is marked [deleted] — content not destroyed (preserves the agent's reasoning trace and prevents history gaslighting; a hole where context used to be is worse than a marked tombstone).

Work items

  1. Subscribe/handle edit-delete events per adapter: Discord gateway MESSAGE_UPDATE/MESSAGE_DELETE; Slack Events API message_changed/message_deleted; VK long-poll edit/delete events.
  2. Session-history update mechanism: an append-with-marker primitive in the channel-context pipeline (fits the 1a trusted-context architecture — mutable source data vs immutable local record is exactly the split that architecture introduces).
  3. Match IDs, not content: events carry message IDs; inbound history entries must retain source message IDs to be addressable (check current ingestion stores them — if not, add it; this is a prerequisite).

References

  • Candidate 1a / #14-20 (channel context separation — this ticket is the mutation half of trusted context)
  • #30 (same theme: keeping what the agent believes about the channel in sync with the channel)

Acceptance

  • Edit in Discord/VK/Slack → agent history shows original + marked edited entry
  • Delete → original tombstoned [deleted], no content removed
  • New inbound history entries carry source message IDs
Lingua principale
C++
Stelle
2
Fork
2
Merge medio
1h 16m
PR unite (30g)
82

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di railstracks/animus

Tutte le issue di railstracks/animus

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.