## Issue Triage — 2026-01-26

### 1) Scam: “Create A Ticket” bot requesting wallet addresses in Discord (DISCORD-SEC-001)
- **Current Status:** Active reports on Discord (confirmed scam by Odilitime); no formal incident ticket referenced.
- **Impact Assessment:**
  - **User Impact:** **High** (targets broad community; high likelihood of victims)
  - **Functional Impact:** **No** (doesn’t break elizaOS runtime, but breaks support trust)
  - **Brand Impact:** **High** (security posture / community safety perception)
- **Technical Classification:**
  - **Issue Category:** Security / UX (community safety)
  - **Component Affected:** Community/Support Infrastructure (Discord)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, bot permissions, incident response, comms
  - **Dependencies:** Need mod/admin permissions; coordination with Discord bot management
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Immediately remove/ban the offending bot(s) and revoke permissions; audit recently added bots and integrations.
  2. Post a pinned security advisory: “No team member/support will ask for wallet address or ask you to send tokens.”
  3. Add AutoMod rules: block common scam phrases (“ticket”, “wallet address”, “send tokens”, suspicious domains).
  4. Create a single official “Support” flow with verified bot + clearly listed official links.
  5. Open a public incident tracking issue (in a community/meta repo) to document remediation and future safeguards.
- **Potential Assignees:** Odilitime (comms + verification), Shaw (admin), senior Discord mods; optionally a security-minded contributor.

---

### 2) Fraudulent token migration “send tokens to wallet” scam (DISCORD-SEC-002)
- **Current Status:** Reported by users; known scam pattern; no canonical “official migration process” page referenced in the discussion.
- **Impact Assessment:**
  - **User Impact:** **Critical** (direct financial loss)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (users associate scam with project name)
- **Technical Classification:**
  - **Issue Category:** Security / Documentation
  - **Component Affected:** Ecosystem communications + migration portal messaging
  - **Complexity:** Simple fix (docs/comms) + moderate (anti-phishing hardening)
- **Resource Requirements:**
  - **Required Expertise:** Security comms, web/docs, Discord moderation
  - **Dependencies:** Access to official website/docs; migration portal messaging if applicable
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish an “Official Migration Safety” page: never send tokens to “support”; list the only legitimate domains and steps.
  2. Add a banner/warning on the migration portal (if still active) about scams and official support channels.
  3. Pin the warning in Discord + add a `!scam` bot command to output the warning + official links.
  4. Provide a standard response template for moderators and community helpers.
- **Potential Assignees:** Odilitime (Discord + messaging), web/docs maintainer, community mods.

---

### 3) Discord plugin: DM failures with role provider (“User has no name or username, skipping.”) (TBD — needs GitHub issue)
- **Current Status:** Persisting after updating to plugin-discord v1.3.8; server functionality restored but DM path still erroring.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (DM-based onboarding/support flows common)
  - **Functional Impact:** **Partial** (DM workflows impacted; server chats may work)
  - **Brand Impact:** **Medium** (plugin reliability)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → Discord plugin; Bootstrap role provider/actions
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Discord API (DM objects, partial users), plugin-bootstrap role provider logic, runtime entity handling
  - **Dependencies:** Repro steps + logs; confirm Discord API fields in DMs (username/displayName changes)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Open a GitHub issue in `elizaos-plugins/plugin-discord` with logs + minimal repro (DM event payload).
  2. Add defensive handling: fall back to `globalName`/`displayName`/`id` when username is absent.
  3. Add tests covering DM event payloads and “nameless” user objects.
  4. Confirm role provider assumptions: roles in DMs may be undefined; avoid role checks or gate them to guild contexts.
- **Potential Assignees:** 0xbbjoker (plugin triage), Odilitime (bootstrap/provider logic), YuriNachos (runtime/provider robustness).

---

### 4) plugin-telegram: crash TypeError during image processing (elizaos-plugins/plugin-telegram #23)
- **Current Status:** Reported as a critical runtime crash; fix not shown in provided logs.
- **Impact Assessment:**
  - **User Impact:** **Medium** (Telegram users specifically, but likely many)
  - **Functional Impact:** **Yes (for image workflows)** (crashes break bot responsiveness)
  - **Brand Impact:** **Medium–High**
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → Telegram plugin (media handling pipeline)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Telegram Bot API, Node/Bun runtime, media decoding/stream handling
  - **Dependencies:** Sample payloads (image messages), version matrix with core `@elizaos/core` 1.7.x
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce using a fixture image message; add an integration test if feasible.
  2. Identify null/undefined fields causing TypeError; add guards and clear error reporting (do not crash process).
  3. Ensure plugin returns a safe “cannot process image” response when decode fails.
  4. Release patch version and announce in Discord.
- **Potential Assignees:** 0xbbjoker (plugin maintenance), wtfsayo (stability/CI), Telegram plugin contributors.

---

### 5) plugin-discord: undefined message functions runtime error (elizaos-plugins/plugin-discord #43)
- **Current Status:** Reported; fix status not included in provided data.
- **Impact Assessment:**
  - **User Impact:** **High** (Discord is a primary integration)
  - **Functional Impact:** **Yes** (runtime error can break message handling)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System → Discord plugin (message handling layer)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Discord event handling, TypeScript, plugin architecture compatibility with core 1.7.x
  - **Dependencies:** Confirm version combos (core, plugin-discord, plugin-bootstrap) and which message handlers are undefined
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Validate repro on latest: core 1.7.2 + plugin-discord 1.3.8 (and pinned peer deps).
  2. Add runtime assertion and graceful fallback when handler missing; emit actionable log telling user to upgrade mismatched packages.
  3. Add a compatibility check at startup that prints the supported core version range.
  4. Publish a short “Upgrade Matrix” doc.
- **Potential Assignees:** 0xbbjoker, Odilitime, YuriNachos.

---

### 6) CLI/core migration & version-cache upgrade pain (Discord report: 1.6.5 → 1.7.2 SQL migration failures; cached package.json)
- **Current Status:** Workaround documented by community (cache removal + reinstall); indicates systemic UX issue.
- **Impact Assessment:**
  - **User Impact:** **High** (common upgrade path; affects new adopters)
  - **Functional Impact:** **Partial** (blocks upgrades; can block new projects)
  - **Brand Impact:** **Medium–High**
- **Technical Classification:**
  - **Issue Category:** UX / Bug / Documentation
  - **Component Affected:** CLI + Plugin SQL migrator + project templates
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Bun package management behavior, CLI packaging, migrations, release engineering
  - **Dependencies:** Repro on clean machine; identify where stale versions are read (global vs local)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a CLI `eliza doctor` (or `eliza debug versions`) command: prints detected core/plugin versions and warns about mismatches/cached globals.
  2. On `eliza start`, detect if global CLI version doesn’t match project’s expected version and print fix steps.
  3. Add an “Upgrade Guide: 1.6.x → 1.7.x” doc, including bun cache guidance and common SQL migration errors.
  4. Consider pinning/locking template dependencies and adding postinstall checks.
- **Potential Assignees:** 0xbbjoker (practical upgrade pain), standujar (SQL/migrations), YuriNachos (CLI/runtime robustness).

---

### 7) External MCP registration: missing/unclear docs for `POST /api/v1/mcps` (DOCS-CLOUD-001)
- **Current Status:** Endpoint exists and is being used ad-hoc; users asked for documentation.
- **Impact Assessment:**
  - **User Impact:** **Medium** (fast-growing interest; blocks self-serve integration)
  - **Functional Impact:** **Partial** (feature works but is hard to adopt)
  - **Brand Impact:** **Medium** (API maturity perception)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Eliza Cloud API / MCP integration surface
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** API documentation, examples, auth/scopes
  - **Dependencies:** Confirm request/response schema, auth requirements, proxy behavior constraints
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document `POST /api/v1/mcps` with full schema, auth requirements, and an end-to-end example (curl + JavaScript).
  2. Include security guidance (allowlist domains, secrets handling, timeouts, logging redaction).
  3. Provide a “Hello MCP Server” reference implementation + recommended deployment patterns.
- **Potential Assignees:** SOLOMON VANDY (context + user support), Odilitime (core guidance), docs maintainer.

---

### 8) Security review needed before merging: V2 dynamic execution engine PR has Python correctness concerns (elizaos/eliza PR #6384)
- **Current Status:** PR open; automated review flagged likely Python runtime errors (callable invocation/state access/XML regex).
- **Impact Assessment:**
  - **User Impact:** **Medium** now, **High** if merged (breaks Python runtime users)
  - **Functional Impact:** **Partial** (V2 path; but could block V2 adoption)
  - **Brand Impact:** **Medium** (V2 stability perception)
- **Technical Classification:**
  - **Issue Category:** Bug / Architectural risk
  - **Component Affected:** Core Framework (V2) + Python runtime
  - **Complexity:** Complex solution (cross-language parity, validation/streaming)
- **Resource Requirements:**
  - **Required Expertise:** Python runtime internals, schema/validation tooling, structured parsing (XML/JSON), streaming
  - **Dependencies:** Agreement on canonical behavior across TS/Rust/Python; tests
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1** (as a merge-blocker for V2)
- **Specific Actionable Next Steps:**
  1. Add targeted Python tests for: callable model handler invocation, `state` shape access, XML validation fields with underscores.
  2. Fix the Python state/template assumptions to match actual `State` object behavior.
  3. Ensure parity test vectors across TS/Rust/Python for the same schema + prompt.
  4. Gate merge on “Python examples run end-to-end” CI job.
- **Potential Assignees:** Odilitime (PR author), matomoniwano (Python infra), reviewers with Python expertise.

---

### 9) Token ecosystem clarity: relationship between various tokens and elizaOS core (DOCS-ECOSYSTEM-001)
- **Current Status:** Community question unanswered; ongoing confusion (and reputational drag).
- **Impact Assessment:**
  - **User Impact:** **Medium** (broad community confusion)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (trust, legitimacy, scam surface area)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (messaging)
  - **Component Affected:** Project documentation + governance messaging
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Clear comms, governance framing, official-link hygiene
  - **Dependencies:** Agreement from core team on official vs unofficial token listings/criteria
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a canonical “Official vs Community Tokens” page: definitions, disclaimers, and verification method.
  2. Add a “How to verify official announcements” section with official handles/domains.
  3. Pin in Discord and link in README / website footer.
- **Potential Assignees:** Odilitime (community comms), Shaw (official stance), docs maintainer.

---

### 10) Adoption gap: lack of “one-trick” specialized agents in the wild (PROD-UX-001)
- **Current Status:** Open product question; indicates potential onboarding/friction or missing distribution primitives.
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (perception of ecosystem vibrancy)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Feature Request
  - **Component Affected:** Developer experience, templates, agent discovery/distribution
  - **Complexity:** Architectural change (if it requires marketplace/discovery improvements), otherwise moderate
- **Resource Requirements:**
  - **Required Expertise:** DX, product, templates/examples, cloud publishing flow
  - **Dependencies:** Clarity on recommended deployment (Cloud vs self-host), templates, agent sharing/discovery roadmap
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Run a short developer survey: “What blocks you from shipping a single-purpose agent?”
  2. Create 5–10 reference “micro-agents” (single capability) with copy-paste deploy buttons.
  3. Document “agent packaging” conventions: config, secrets, minimal plugins, and hosting recipes.
- **Potential Assignees:** borisudovicic (product issues), docs/examples contributors, Eliza Cloud maintainers.

---

## Summary — Top Priority (address immediately)
1. **P0:** Discord scam bot requesting wallet addresses (DISCORD-SEC-001)  
2. **P0:** Token migration “send tokens” scam mitigation + official safety page (DISCORD-SEC-002)  
3. **P1:** Discord plugin DM failures (“no name/username”) — open + fix + tests (TBD)  
4. **P1:** plugin-discord undefined message functions error (plugin-discord #43)  
5. **P1:** plugin-telegram image crash TypeError (plugin-telegram #23)  
6. **P1:** CLI upgrade/version-cache + SQL migration failure UX (create tracked issue + `doctor`)  
7. **P1:** V2 dynamic execution engine PR #6384 — Python correctness fixes before merge  
8. **P2:** MCP registration endpoint docs (`POST /api/v1/mcps`)  
9. **P2:** Token ecosystem documentation/verification page  
10. **P3:** Specialized agent adoption barriers (DX/product workstream)

---

## Patterns / Themes Indicating Deeper Issues
- **Security surface area is dominated by comms gaps**: scams exploit unclear “official support” processes and lack of canonical links/pages.
- **Version skew and upgrade fragility**: repeated pain around mismatched core/plugin versions and bun global/local caching suggests missing tooling and guardrails in the CLI.
- **Plugin reliability concentrates on edge-case payloads** (DM contexts, Telegram media): integrations need better fixture-driven testing and graceful-degradation patterns.
- **Cross-language parity risk for V2**: new V2 features (schema validation/streaming) increase complexity; Python parity needs stronger test gates to avoid regressions.

---

## Process Improvements (to prevent repeats)
1. **Establish a Security Comms Playbook**: one pinned Discord post + one website page listing official domains, “never send tokens,” and how to report scams.
2. **Add Release/Compatibility Guardrails**:
   - Publish a simple compatibility matrix (core ↔ plugin versions).
   - Add CLI startup checks that warn on mismatched major/minor versions.
3. **Introduce Integration Test Fixtures for Plugins**:
   - DM payload fixtures for Discord; media payload fixtures for Telegram.
   - Require “no-crash” behavior (errors become messages/logs, not process exits).
4. **Merge Gates for V2 Cross-Language Features**:
   - Require parity tests and a minimal “Python example runs” CI job for any runtime API changes.
5. **Create a “Doc-as-a-Feature” rule** for new Cloud endpoints (e.g., MCP): endpoint must ship with example + security guidance before being promoted in community channels.