RFC Draft: Discord Forum Tags as a Kanban Status Projection

Summary

Hermes Kanban is the durable source of truth for task state. Discord Forum Channels are a useful human-facing discussion surface: each forum post is represented by Discord as a thread, and the parent forum channel can define a small set of tags that are applied to those posts.

This RFC proposes an optional Hermes Discord integration that mirrors Kanban task status onto Discord Forum/Media post tags when the task discussion lives in a forum/media thread.

Important scope correction: this is about Discord Forum/Media Channel tags (available_tags on the parent channel, applied_tags on the forum/media thread). It is not a generic tagging system for ordinary text-channel threads.

• Keep Kanban as the source of truth.
• Treat Discord Forum tags as a lightweight UI projection, not authoritative state.
• Only use native applied_tags for Discord Forum/Media threads.
• Do not depend on ordinary text-channel thread behavior.
• Leave existing behavior unchanged by default.

Community / upstream context

A review of current Hermes discussions suggests that upstream work is focused on Discord forum/thread routing and thread-based workflow plumbing, not native Forum tag sync itself.

Relevant adjacent work:

• #14581 — enumerate Discord forum parent channels.
• #15929 — auto-join new forum/text threads in watched channels.
• #12496 — first message in a new Discord forum thread may be ignored until the bot is mentioned.

Less directly related work that should not define this RFC's scope:

• #33657 — thread context isolation for one-thread-per-task deployments. Useful for ordinary thread workflows, but not specifically Forum tags.
• #30848 — Kanban session_event delivery mode. Potential event plumbing, but not required for tag projection.
• #33374 — Discord thread closeout metadata / labels. Related to thread lifecycle decoration, but not native Forum applied_tags.

Current evidence:

• Hermes source currently has no direct available_tags / applied_tags implementation.
• GitHub search found no focused upstream issue/PR for native Discord Forum tag synchronization.
• #29291 mentions applied_tags only as a possible future adapter metadata example for cron delivery; it is not an implementation of Forum tag sync.

Therefore this RFC should be framed as filling a small Hermes capability gap, not as following an already-established upstream Forum-tags design.

Problem

When a Kanban task is discussed in a Discord Forum Channel, the current task state is not visible from the forum post list unless someone manually edits tags or titles. Users must open the Kanban dashboard, run CLI commands, or read the thread to know whether a task is ready, running, blocked, in review, done, or failed.

Discord Forum tags are already visible in the forum index and are a natural low-friction status indicator for this specific surface.

Goals

1. Reflect Kanban task status in Discord Forum/Media post tags.
2. Keep Kanban authoritative; Discord tags are only a projection.
3. Scope native tag behavior to Forum/Media threads only.
4. Make the feature optional and default-off.
5. Avoid coupling the initial implementation to broader thread isolation, session-event, or closeout PRs.
6. Fail safely: tag sync must never block normal Kanban notifications or gateway message delivery.

Non-goals

• Do not replace the Kanban dashboard.
• Do not make Discord tags authoritative task state.
• Do not create a generic tag system for ordinary Discord text-channel threads.
• Do not require Discord forum channels for Kanban.
• Do not auto-create or mutate a server's Forum tag schema by default.
• Do not bundle close-thread, signoff, session_event, or thread context isolation behavior into the first PR.

Proposed configuration

discord:
  kanban_forum_tags:
    enabled: false
    missing_tag_behavior: warn   # warn | ignore
    statuses:
      ready: ready
      running: running
      blocked: blocked
      review: review
      done: done
      gave_up: failed
      archived: archived

Alternative placement under kanban.discord_forum_tags is also reasonable. The important design points are default-off behavior and explicit mapping from Kanban states to existing Forum tag names.

Status mapping

The exact mapping must be configurable because Discord servers may already have tag conventions.

Event flow

Kanban task status changes
  ↓
Kanban notification / subscription path resolves Discord destination
  ↓
If destination is a Discord Forum/Media thread:
    fetch parent channel available_tags
    resolve configured status tag name → tag id
    read current applied_tags
    remove previous Kanban status tags managed by Hermes
    add desired status tag id
    deduplicate tag ids
    keep applied_tags within Discord's limit
    PATCH thread applied_tags
Else:
    no native tag sync
  ↓
Continue normal notification/session delivery

Native Discord constraints

Discord Forum tags are intentionally limited and should be treated as lightweight UI state:

• available_tags live on the parent Forum/Media channel.
• applied_tags live on the Forum/Media thread/post.
• Forum/Media threads can have only a small number of applied tags.
• Parent channels have a limited number of available tags.
• Ordinary text-channel threads do not have this native Forum tag model.

Implementation should therefore avoid treating tags as a full metadata system. Owner, module, priority, task id, and artifact links belong in Kanban, GitHub, dashboard state, or a bot status card — not necessarily in Forum tags.

Failure behavior

Forum tag sync must never block or fail Kanban event delivery.

• Missing Discord permissions: log/debug and continue.
• Destination is not a Forum/Media thread: no-op.
• Parent channel cannot be resolved: no-op or warn.
• Configured tag name does not exist: warn or ignore according to config.
• Thread deleted/archived/unresolvable: no-op or normal stale-subscription cleanup path.
• Discord API rate limits: use existing gateway retry/backoff conventions; do not spin.
• Duplicate events: idempotently keep the same tag state.
• Duplicate tag ids: deduplicate before PATCH.

Implementation sketch

1. Add config parsing for discord.kanban_forum_tags.
2. Add a Discord adapter helper, e.g. update_kanban_forum_status_tag(thread_id, status).
3. Detect whether the destination is a Forum/Media thread and resolve its parent Forum/Media channel.
4. Read parent available_tags and build a tag name → id map.
5. Maintain the set of Hermes-managed status tag ids from configured mappings.
6. Update applied_tags by replacing only the managed Kanban status tag while preserving unrelated user tags.
7. Deduplicate and enforce Discord limits before PATCH.
8. Call this helper from the Kanban notification/subscription path after normal destination resolution.
9. Add tests for:
   • no-op when disabled;
   • no-op for non-Discord destinations;
   • no-op for ordinary text-channel threads;
   • Forum tag update when matching tag exists;
   • existing non-Hermes tags are preserved;
   • previous Hermes-managed status tag is replaced;
   • missing tag behavior does not block notification;
   • missing permissions/API failure does not block notification;
   • idempotent repeated status events.
10. Add docs to Discord messaging and Kanban feature docs.

Open questions

1. Should config live under discord.kanban_forum_tags or kanban.discord_forum_tags?
2. Should Hermes ever offer an explicit admin command to create the configured tags, or should it only use existing tags?
3. Should status tags update for all lifecycle events or only terminal/blocking states?
4. How should archived/completed threads be handled when Discord disallows editing archived threads?
5. Should the dashboard expose a per-task Discord forum tag projection status?

Suggested upstream sequence

1. Open a focused RFC/issue for native Discord Forum tag projection.
2. Mention adjacent forum/thread issues only as background, not prerequisites.
3. Implement a small default-off PR for Forum/Media applied_tags sync only.
4. Later, optionally connect it to richer Kanban session-event and closeout metadata flows.