## Issue Triage — 2026-01-27 (elizaOS)

### 1) Scam “Create A Ticket” bot requesting wallet addresses (Discord)
- **Issue Title & ID:** “Fake support bot asking for wallet address + sending suspicious links” — DISCORD-SEC-2026-01-25-TICKETBOT
- **Current Status:** Reported in Discord; confirmed scam by community; mitigation status unknown
- **Impact Assessment:**
  - **User Impact:** **Critical** (targets many users via public channels/DMs)
  - **Functional Impact:** **No** (core runtime unaffected)
  - **Brand Impact:** **High** (support scam in official community space)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Community/Discord Operations
  - **Complexity:** Moderate effort (requires config + ongoing monitoring)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, bot permissions, security comms
  - **Dependencies:** None; faster with access to server moderation settings
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Immediately remove/ban the malicious bot(s) and any associated accounts; revoke OAuth permissions if installed.
  2. Lock down ticket/support flow: only one official ticket bot; restrict who can post “support” links.
  3. Add AutoMod rules to block common phishing phrases (“send wallet”, “migration”, “verify”, shortened links).
  4. Pin an “Official Support & Never Share Wallet/Seed” notice in high-traffic channels + #tickets.
  5. Publish an incident note with screenshots/red flags; encourage reporting suspicious DMs.
- **Potential Assignees:** The Void (support/tickets), Odilitime (core-dev coordination), Discord admins/mods (server configuration)

---

### 2) Token migration scam DM (ai16z → elizaOS) + urgent user guidance gap
- **Issue Title & ID:** “Fraudulent token migration instructions (send tokens to wallet, promise return)” — DISCORD-SEC-2026-01-24-MIGRATIONSCAM
- **Current Status:** Active scam pattern acknowledged; users still asking for migration help
- **Impact Assessment:**
  - **User Impact:** **Critical** (direct fund loss risk)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (users blame project if scammed)
- **Technical Classification:**
  - **Issue Category:** Security / Documentation
  - **Component Affected:** Token migration portal + Support/Docs
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Security communications, migration backend knowledge, support ops
  - **Dependencies:** Coordination with migration portal operators (Eliza Foundation)
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a single canonical “Migration Safety” page: **official URLs**, **never send tokens to any address**, support contact path.
  2. Add banner/warning on migration portal UI (if possible) + link to safety page.
  3. Add Discord bot auto-reply when “migration” is mentioned, pointing to official instructions.
  4. Collect known scam wallet addresses and publish a blocklist section (informational).
- **Potential Assignees:** The Void (support workflow), Shaw (foundation-level comms alignment), Odilitime (ship docs quickly), Sam (if portal/banner changes require infra support)

---

### 3) Model naming confusion: Opus/Sonnet ↔ Pro/Ultra mapping (Open GitHub issue)
- **Issue Title & ID:** “Opus - pro and Ultra - sonnet? Is this right?” — **elizaos/eliza #6390**
- **Current Status:** **OPEN** (reported as urgent in dev logs; affects shared understanding)
- **Impact Assessment:**
  - **User Impact:** **High** (anyone configuring models; high likelihood of wrong cost/quality expectations)
  - **Functional Impact:** **Partial** (agents run but may select unintended model tier/cost)
  - **Brand Impact:** **High** (billing/quality mismatch is reputationally damaging)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** Model Integration + Docs + Configuration defaults
  - **Complexity:** Simple fix (if only labels) to Moderate (if mapping is embedded across code/docs)
- **Resource Requirements:**
  - **Required Expertise:** Model provider integration knowledge, config/schema familiarity
  - **Dependencies:** Confirm canonical mapping with provider terminology used in codebase/CI (and any cloud UI)
  - **Estimated Effort (1-5):** 2–3
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Establish canonical mapping table (internal): `{provider_model_name → eliza tier name → pricing tier}`.
  2. Audit: code constants, docs, examples, CI workflows (Claude workflow references), and Cloud UI labels.
  3. Add an automated test that validates model aliases resolve to expected provider identifiers.
  4. Update docs with explicit “alias → provider model” notes and warnings about cost tiers.
- **Potential Assignees:** Odilitime (model/runtime + docs), wtfsayo (CI/workflows), Sam (cloud alignment), borisudovicic (UX labeling validation)

---

### 4) Plugin action handler callbacks: only first callback emitted / callbacks delayed until completion
- **Issue Title & ID:** “Plugin action handler callbacks only send first response (1.7.2, default settings)” — DISCORD-BUG-2026-01-26-CALLBACKS
- **Current Status:** Reported + being troubleshot; multiple callbacks supported in principle; no root cause yet
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (plugin authors and interactive agents)
  - **Functional Impact:** **Partial** (breaks progress updates/streaming-like UX for actions)
  - **Brand Impact:** **Medium** (docs vs reality mismatch)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Documentation
  - **Component Affected:** Core Framework (action execution / message service), Plugin System
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Core runtime, message service flow (onestep vs multistep planners), plugin action lifecycle
  - **Dependencies:** Repro project on 1.7.2; determine planner mode impact
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create minimal repro plugin action emitting 3 callbacks + final result; run in onestep and multistep planners.
  2. Identify where callbacks are buffered/overwritten: message service, transport adapter, or UI rendering.
  3. Decide contract: callbacks should be “immediate feedback” vs “completion payload”; update implementation or docs accordingly.
  4. Add an integration test: “multi-callback actions deliver N callbacks in order.”
- **Potential Assignees:** Odilitime (core), standujar (server/messaging tests), YuriNachos (runtime robustness), Victor Creed (reporter; can validate fix)

---

### 5) Token migration process unclear (Ledger + ai16z → elizaOS) causing support load and user risk
- **Issue Title & ID:** “Clarify token migration process (Ledger, ai16z → elizaOS)” — DISCORD-DOC-2026-01-26-MIGRATIONHOWTO
- **Current Status:** Users redirected to ticket channel; public step-by-step guidance insufficient/fragmented
- **Impact Assessment:**
  - **User Impact:** **High** (repeated questions; deadline pressure mentioned in community context)
  - **Functional Impact:** **No** (not runtime-related)
  - **Brand Impact:** **High** (confusion enables scams and distrust)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs + Support Process
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Migration portal knowledge, wallet UX familiarity, technical writing
  - **Dependencies:** Must align with official portal behavior and snapshot rules
  - **Estimated Effort (1-5):** 2
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single official migration guide: supported wallets, troubleshooting steps, and “what support will ask for” (never seed phrase).
  2. Add “Known Issues” section (hardware wallets, snapshot eligibility mismatches, connection steps).
  3. Include a safe support intake checklist (tx hashes, public address, screenshots) to reduce back-and-forth.
- **Potential Assignees:** The Void (support intake), Shaw (official comms), Odilitime (docs), community mods (pin + distribute)

---

### 6) Recovered “481K lines unreleased code” from old branches — provenance/security risk
- **Issue Title & ID:** “Recovered large unreleased codebase from old branch repos (481K LOC)” — DISCORD-RISK-2026-01-26-CODERECOVERY
- **Current Status:** Mentioned publicly; no formal triage or verification
- **Impact Assessment:**
  - **User Impact:** **Medium** (could leak secrets/vulns; or create confusion about “hidden features”)
  - **Functional Impact:** **No** (unless merged/used)
  - **Brand Impact:** **Medium–High** (perception of chaotic repo hygiene, potential sensitive leakage)
- **Technical Classification:**
  - **Issue Category:** Security / Process
  - **Component Affected:** Repo Management, Release Hygiene
  - **Complexity:** Complex solution (audit may be large), but initial mitigation is moderate
- **Resource Requirements:**
  - **Required Expertise:** Git history/repo forensics, secret scanning, licensing/provenance review
  - **Dependencies:** Access to recovered branches/artifacts; decide what is official
  - **Estimated Effort (1-5):** 4
- **Recommended Priority:** **P1** (treat as security/process risk until proven harmless)
- **Specific Actionable Next Steps:**
  1. Run secret scanning (GitHub Advanced Security or trufflehog) over recovered content.
  2. Confirm licensing and authorship; ensure no third-party code inadvertently included.
  3. If safe, document what it is (archive/experimental) and set expectations; if unsafe, remove public access and rotate exposed credentials immediately.
- **Potential Assignees:** wtfsayo (security/CI), Odilitime (core coordination), Sam (infra credential rotation), repo admins

---

### 7) CLI/Starter reliability: “elizaos create” failure due to exports path (closed, verify release propagation)
- **Issue Title & ID:** “Can not generate project (ERR_PACKAGE_PATH_NOT_EXPORTED)” — **elizaos/eliza #6388** (CLOSED)
- **Current Status:** Closed; fix landed (CLI import uses package alias per dev logs)
- **Impact Assessment:**
  - **User Impact:** **High** for newcomers if any stale versions remain
  - **Functional Impact:** **Yes** for onboarding (project creation blocked)
  - **Brand Impact:** **High** (first-run failure)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** CLI / Project Generator
  - **Complexity:** Simple fix (already implemented), moderate to ensure distribution
- **Resource Requirements:**
  - **Required Expertise:** Release management, npm/bun packaging
  - **Dependencies:** Confirm published versions of `elizaos` wrapper + `@elizaos/cli` and docs install commands
  - **Estimated Effort (1-5):** 2
- **Recommended Priority:** **P1** (until confirmed fully resolved for users)
- **Specific Actionable Next Steps:**
  1. Confirm the fix is in the latest published packages and that `bun i -g elizaos` installs the corrected wrapper.
  2. Update docs to recommend the supported install path (and remove any stale commands).
  3. Add a CI smoke test: install globally → run `elizaos create` → bootstrap a minimal agent.
- **Potential Assignees:** 0xbbjoker (CLI reliability), Odilitime (release/docs), YuriNachos (CLI/runtime tests)

---

### 8) Upgrade/migration pain: 1.6.5 → 1.7.2 cache/version conflicts + SQL migration/bootstrap errors
- **Issue Title & ID:** “Persistent version conflicts & SQL migration/bootstrap errors when updating to 1.7.2” — DISCORD-BUG-2026-01-24-UPGRADE
- **Current Status:** Workaround posted (clear bun cache, reinstall CLI, remove lockfiles); fixed bootstrap in 1.7.2 + discord 1.3.8, but upgrade UX remains fragile
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (existing users upgrading)
  - **Functional Impact:** **Partial** (blocks upgrades; can break Discord plugin bootstrap)
  - **Brand Impact:** **Medium** (upgrade instability perception)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Documentation
  - **Component Affected:** CLI, Plugin System, SQL migrations
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** bun package management behavior, CLI templates, migration tooling
  - **Dependencies:** Identify whether stale package.json templates or global wrapper causes conflicts
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `elizaos doctor` command to detect version mismatch (global wrapper vs `@elizaos/cli`) and cache issues.
  2. Improve upgrade docs into a single “upgrade playbook” with copy/paste commands and expected outputs.
  3. Ensure starter templates never pin stale versions and that CLI always writes current versions.
- **Potential Assignees:** 0xbbjoker (bun/CLI), Odilitime (templates/docs), standujar (migration testing)

---

### 9) External MCP server registration via Cloud API: docs + security posture of proxying
- **Issue Title & ID:** “Document /api/v1/mcps + validate external MCP proxy security model” — DISCORD-FEATURE-2026-01-25-MCP
- **Current Status:** Endpoint shared informally; documentation incomplete; adoption growing
- **Impact Assessment:**
  - **User Impact:** **Medium** (Cloud users integrating tools)
  - **Functional Impact:** **Partial** (feature exists but hard to use safely)
  - **Brand Impact:** **Medium** (security expectations for proxy features)
- **Technical Classification:**
  - **Issue Category:** Documentation / Security / Feature
  - **Component Affected:** API (Eliza Cloud), Model Integration (tooling), Docs
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** API design, auth/scoping, SSRF/egress controls, docs
  - **Dependencies:** Cloud team bandwidth; clarity on allowed outbound targets
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish API docs for `POST /api/v1/mcps` with required fields, auth, examples.
  2. Define and document security controls: allowlist/denylist, per-agent scoping, rate limiting, logging.
  3. Add warnings about exposing internal services; recommend network boundary patterns.
- **Potential Assignees:** Sam (cloud/API), Odilitime (docs), standujar (security tests / RLS mindset)

---

### 10) “Improve team communication during market downturn” (community trust issue)
- **Issue Title & ID:** “Lack of visible status updates during volatility leads to distrust” — DISCORD-BRAND-2026-01-26-COMMS
- **Current Status:** Ongoing community concern; no structured cadence indicated
- **Impact Assessment:**
  - **User Impact:** **Medium** (community sentiment; support overhead)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** UX (community experience) / Documentation
  - **Component Affected:** Project Communications
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Release/status communication, community management
  - **Dependencies:** None
  - **Estimated Effort (1-5):** 1–2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Establish weekly “Ship + Status” post: what shipped, what’s next, known issues, security notices.
  2. Maintain a public “Known Issues” page and link it in Discord channel topics.
  3. Route sensitive token topics to a single pinned explainer to reduce repeated arguments.
- **Potential Assignees:** Shaw (project voice), Odilitime (engineering updates), community mods

---

## Summary: Top Highest-Priority Issues to Address Immediately (Next 24–72 hours)
1. **P0:** Scam “Create A Ticket” bot requesting wallet addresses (DISCORD-SEC-2026-01-25-TICKETBOT)
2. **P0:** Token migration scam DM pattern + publish official safety guidance (DISCORD-SEC-2026-01-24-MIGRATIONSCAM)
3. **P0:** Model naming/mapping confusion Opus/Sonnet ↔ Pro/Ultra (**#6390**)
4. **P1:** Plugin action handler callbacks not behaving as documented (DISCORD-BUG-2026-01-26-CALLBACKS)
5. **P1:** Recovered unreleased codebase provenance/secret scan (DISCORD-RISK-2026-01-26-CODERECOVERY)
6. **P1:** Verify `elizaos create` fix is fully shipped + add smoke test (**#6388**, closed but onboarding-critical)
7. **P1:** Public migration process guide (Ledger + ai16z → elizaOS) to reduce scams/support load

## Patterns / Themes Suggesting Deeper Issues
- **Security/comms gaps in community surfaces:** Repeated scams succeed when official “single source of truth” is missing or hard to find.
- **Inconsistent contracts between docs and runtime behavior:** Callback semantics and model naming show that “what users think happens” diverges from actual behavior/labels.
- **Release/upgrade fragility:** bun caching, global wrappers, and template version pinning create “it works for core-devs but not for users” failure modes.

## Process Improvement Recommendations
1. **Security Playbook + Rapid Broadcast Mechanism:** A lightweight incident response checklist (ban bot, rotate keys, pin warning, publish advisory) and a dedicated `#security-advisories` channel.
2. **Docs-as-Contracts:** For runtime behaviors (callbacks, streaming, model aliases), require:
   - a minimal reproducible test,
   - an integration test in CI,
   - a docs section that matches the test’s observed behavior.
3. **Onboarding/Upgrade Smoke Tests in CI:** Nightly job that:
   - installs global CLI/wrapper,
   - runs `elizaos create`,
   - boots an agent with a core plugin (Discord optional),
   - runs a minimal action callback test.
4. **Single Canonical “Official Links” Page:** One pinned doc listing official domains, ticket flow, migration portal, and an explicit “we will never ask you to send tokens/seed phrase.”