kiro-discord-bot: Instructions file for Kiro

Decision And Failure Patterns

This file records how to avoid repeating known wrong turns. Use it when a task touches architecture direction, multi-bot behavior, cron/thread delivery, MCP tools, cwd/Kiro settings, stuck agents, release/deploy, or any recurring runtime failure.

When To Update This File

Update this file when any of these happen:

• A proposed fix is rejected because it solves the symptom in the wrong layer.
• A behavior is intentionally left unsupported or out of scope.
• A production/runtime issue reveals a reusable debugging pattern.
• A bug fix adds a regression test for a failure that could return.
• A release/deploy incident exposes a missing verification signal.
• A future issue should be opened, but the current change should not start that architecture work.
• A new architecture layer, shared helper, runtime mode, deployment target, or MCP tool category changes the source of truth documented in steering.
• The root AGENTS.md entrypoint stops matching the active project architecture, security boundaries, verification expectations, or cross-agent source-of-truth map.

Do not hide these decisions only in chat history. Future maintainers need the decision, tradeoff, and trigger conditions in the repository.

Decision Record Template

Use this shape for significant direction changes:

Decision:
- What we decided.

Context:
- Current behavior and evidence.
- User goal or operational problem.

Rejected alternatives:
- Option and why it was rejected.

Current scope:
- What this change will do now.
- What this change explicitly will not do.

Future trigger:
- What evidence or requirement should reopen the decision.

Verification:
- Tests, logs, docs, or runtime checks that prove the current scope.

Current Architecture Non-Goals

These are deliberate boundaries unless a new architecture task changes them:

• This project is not currently a single-process orchestrator for multiple Discord bot identities.
• Multiple deployed bots in one Discord server are independent runtimes. They may share code and configuration patterns, but they do not have a reliable distributed coordination layer through Discord mentions.
• Do not rely on bot-to-bot tag conversations as a durable task handoff mechanism. Discord delivery order, network delay, thread membership, permissions, and bot filtering can make that unreliable.
• Do not teach agents to coordinate by recursively asking each other questions in Discord. That creates latency, loop, mention-target, and accountability problems.
• Do not patch multi-bot coordination by weakening requiresHumanMention, peer filtering, MCP policy, or safe egress.
• If reliable multi-bot orchestration becomes a product goal, design it as an explicit server-side architecture with owned routing, state, audit, and bot identity boundaries.