## Issue Triage — 2025-12-26

### 1) Snapshot Eligibility + Tangem Wallet Not Supported for Migration
- **Issue Title & ID:** “Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised)” — elizaos/eliza **#6211** (OPEN)
- **Current Status:** Open; user blocked from migrating because snapshot wallet (Tangem) cannot connect via WalletConnect and seed cannot be exported.
- **Impact Assessment:**
  - **User Impact:** **High** (affects a non-trivial class of hardware-wallet users; repeated questions in Discord about “0 eligible”)
  - **Functional Impact:** **Yes** (blocks token migration for affected users)
  - **Brand Impact:** **High** (migration friction + public distrust; cited alongside scam concerns)
- **Technical Classification:**
  - **Category:** Bug / UX / Documentation (migration flow gap)
  - **Component Affected:** Migration Portal / Wallet Integration
  - **Complexity:** **Moderate effort** (depends on portal + backend eligibility verification + possible manual path)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration (WalletConnect), snapshot/eligibility backend, support ops
  - **Dependencies:** Clarity on official eligibility rules; ability to validate snapshot holdings independent of wallet connector
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Confirm (internally) definitive eligibility rules: snapshot date, wallet address, custody moves pre/post snapshot.
  2. Implement an **official “manual verification” path**: user signs a message with the snapshot address (if possible) or provides proof-of-ownership procedure endorsed by the team.
  3. Add a portal UX state for “eligible but wallet unsupported” with safe next steps (no DMs, no transfers).
  4. Publish a short “hardware wallets (Tangem, etc.)” migration guide and link it from the portal when “0 eligible” is shown.
- **Potential Assignees:**
  - **Alexei** (migration eligibility explanations in Discord)
  - **Odilitime** (token migration technical rationale/comms)
  - **Shaw** (product decision + escalation)
  - Support from a wallet-integration contributor (if available)

---

### 2) Discord Impersonation / Scam Attempts During Migration (Support Channel Trust Breakdown)
- **Issue Title & ID:** “Migration support impersonation & scam link attempts in tickets/DMs” — **DISCORD-SEC-2025-12-26-01** (NEW; needs GitHub issue)
- **Current Status:** Reported by users/mods; users being directed to unsafe actions; trust in Discord support is “compromised” per #6211 report.
- **Impact Assessment:**
  - **User Impact:** **Critical** (potential direct user fund loss)
  - **Functional Impact:** **Partial** (migration is “functionally unusable” for cautious users without trusted support)
  - **Brand Impact:** **High** (security perception + reputational damage)
- **Technical Classification:**
  - **Category:** **Security**
  - **Component Affected:** Community Support Infrastructure (Discord), Migration Support Workflow
  - **Complexity:** **Moderate effort** (process + tooling + permissions + verification)
- **Resource Requirements:**
  - **Required Expertise:** Community moderation, Discord admin/security, incident response playbooks
  - **Dependencies:** Lockdown of support channels; consistent “single source of truth” docs
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Put migration support behind **strict roles**; remove ability for non-staff to mimic “support” tags; audit permissions.
  2. Add an **auto-posted pinned warning** + periodic bot reminder: “No staff will ever ask you to send tokens.”
  3. Publish a **signed/verified support policy** on GitHub + website and link from Discord.
  4. Create an official “Report scammer” flow and publicly confirm actions taken (ban counts, process).
- **Potential Assignees:**
  - **Odilitime** (public comms + coordination)
  - **Serikiki / Hexx 🌐** (frontline migration help; can validate support playbook)
  - Discord admins/moderators (not listed in GitHub data; assign internally)

---

### 3) Migration Helper Bot Giving Incorrect Information
- **Issue Title & ID:** “Migration helper bot provides incorrect/unsafe guidance” — **DISCORD-BUG-2025-12-26-02** (NEW; needs GitHub issue)
- **Current Status:** Reported by Serikiki; causing confusion during already sensitive migration.
- **Impact Assessment:**
  - **User Impact:** **High**
  - **Functional Impact:** **Partial** (users can still migrate, but many will fail or be misled)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** Discord Bot / Support Automation
  - **Complexity:** **Simple fix → Moderate effort** (depends on bot code access; may be content-only)
- **Resource Requirements:**
  - **Required Expertise:** Bot maintenance, migration rules knowledge
  - **Dependencies:** Finalized canonical migration FAQ content
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1** (P0 if bot is actively giving dangerous instructions)
- **Specific Actionable Next Steps:**
  1. Freeze bot outputs to a minimal safe message until corrected.
  2. Replace with deterministic decision tree: snapshot date, wallet address at snapshot, supported connectors.
  3. Log “top confusion prompts” and refine responses weekly until migration tail ends.
- **Potential Assignees:**
  - **Alexei** (correct rule explanations)
  - **Odilitime**
  - A Discord tooling maintainer (internal)

---

### 4) Korean Exchange Delisting Risk / Compliance Readiness (January)
- **Issue Title & ID:** “Korean exchange compliance readiness to prevent delisting” — **OPS-RISK-2025-12-26-01** (TRACKING; create GitHub/Notion ticket)
- **Current Status:** Community flags potential January delisting risk (Bithumb/Coinone/Korbit).
- **Impact Assessment:**
  - **User Impact:** **Critical** (liquidity/access impact for a large regional user base)
  - **Functional Impact:** **Partial** (doesn’t break elizaOS runtime, but breaks ecosystem access)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Category:** Operations / Compliance (not a code bug, but requires coordinated deliverables)
  - **Component Affected:** Token Infrastructure, Exchange Relations, Communications
  - **Complexity:** **Complex solution** (multi-party coordination)
- **Resource Requirements:**
  - **Required Expertise:** Exchange listing/compliance, legal, token ops, comms
  - **Dependencies:** Migration stability, clear token contract properties (mintability rationale, CCIP plan)
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Assign a single DRI to produce an “Exchange Readiness Packet” (migration timeline, contract details, CCIP mintability explanation).
  2. Publish a public migration status page + “known issues” (reduces inbound support load and panic).
  3. Confirm any required technical actions (metadata, explorers, contract verification, CCIP config) and deadlines.
- **Potential Assignees:**
  - **Shaw** (executive coordination)
  - **Odilitime** (technical + comms)
  - Token/BD/compliance owner (internal; not present in provided GitHub contributor list)

---

### 5) CI / GitHub Actions Failure Due to Claude Billing Top-Up
- **Issue Title & ID:** “GitHub Actions job failing due to Claude billing needing top-up” — **CI-OPS-2025-12-26-01** (NEW; needs GitHub issue)
- **Current Status:** Reported in Discord; blocks automation.
- **Impact Assessment:**
  - **User Impact:** **Medium** (indirect, but slows merges and increases regressions)
  - **Functional Impact:** **Partial** (delivery pipeline reliability)
  - **Brand Impact:** **Medium** (visible red CI undermines confidence)
- **Technical Classification:**
  - **Category:** Reliability / DevEx
  - **Component Affected:** CI, Automation workflows
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** CI admin, billing/keys management
  - **Dependencies:** Access to billing account; rotate tokens if needed
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Top up billing / restore quota; re-run failed workflows.
  2. Add CI guardrail: if external AI step fails, mark as “neutral” or skip for forks to avoid blocking core checks.
  3. Document where billing is owned and add an alert before hitting zero.
- **Potential Assignees:**
  - **ChristopherTrimboli** (ecosystem/CI-touching work)
  - **standujar** (server/tooling familiarity)
  - DevOps maintainer (internal)

---

### 6) Monorepo Documentation Outdated / False After Core Changes
- **Issue Title & ID:** “Monorepo docs outdated/false; needs update after core changes” — **DOCS-2025-12-26-01** (reported by Stan; create/locate GitHub issue)
- **Current Status:** Actively being updated by Stan; still a gap.
- **Impact Assessment:**
  - **User Impact:** **High** (new users hit setup/architecture mismatches)
  - **Functional Impact:** **Partial** (slows onboarding; increases support burden)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Documentation
  - **Component Affected:** Core repo docs, onboarding, architecture references
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Core architecture knowledge, technical writing
  - **Dependencies:** Final API/message handling standardization decisions
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify “top 10” doc pages linked from README/CLI that must be correct.
  2. Add versioned guidance: “If you’re on ≥1.6.5 use X; older uses Y” where relevant.
  3. Add a quickstart that matches the current recommended path (Cloud default provider, messageService usage).
- **Potential Assignees:**
  - **Stan ⚡** (doc updates mentioned)
  - **wtfsayo** (recent messageService-related changes)
  - **standujar** (core/server details)

---

### 7) Standardize `elizaos.handleMessage` / Message Handling Across Plugins
- **Issue Title & ID:** “Standardize Elizaos.handleMessage across plugins (PR needs to be pushed)” — **CORE-PLUGINS-2025-12-26-01** (tracked from Discord core-devs)
- **Current Status:** In progress; called out as needing a PR.
- **Impact Assessment:**
  - **User Impact:** **High** (plugin behavior inconsistencies; regressions in chat handling)
  - **Functional Impact:** **Yes** (message routing is core runtime behavior)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Bug / Architectural alignment
  - **Component Affected:** Core Framework + Plugin System (Discord/Twitter/Telegram/etc.)
  - **Complexity:** **Complex solution** (cross-repo coordination + compatibility)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime, plugin APIs, backwards compatibility
  - **Dependencies:** Plugin maintainers availability; test coverage across plugins
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single “message handling contract” doc + reference implementation.
  2. Create a cross-repo checklist: Discord/Twitter/Telegram/Knowledge plugins compliance.
  3. Add integration tests ensuring consistent behavior (latest conversation opens, no duplication, etc.).
- **Potential Assignees:**
  - **standujar** (core/server rigor)
  - **wtfsayo** (messageService migration work)
  - **Odilitime** (plugin coordination)
  - **Stan ⚡** (mentioned the work item)

---

### 8) Eliza Cloud Integration PR Needs Review / Merge (Large PR)
- **Issue Title & ID:** “Eliza Cloud Integration, add MCP + A2A service starter, integrate CLI and starter projects tight” — elizaos/eliza **PR #6216** (OPEN)
- **Current Status:** Open; explicitly requests thorough review of create→deploy→publish/monetize flow.
- **Impact Assessment:**
  - **User Impact:** **High** (Cloud is the primary onboarding + “tokenomics engine” narrative)
  - **Functional Impact:** **Partial** (not a hard blocker, but delays Cloud adoption)
  - **Brand Impact:** **High** (Cloud rollout is central to public confidence right now)
- **Technical Classification:**
  - **Category:** Feature / Platform integration
  - **Component Affected:** CLI, Cloud Integration, Starter Projects, MCP/A2A services
  - **Complexity:** **Architectural change** (very large diff; high merge risk)
- **Resource Requirements:**
  - **Required Expertise:** CLI, Cloud APIs, auth/provisioning, starters, release engineering
  - **Dependencies:** CI stability; documentation updates; possibly JWT/data isolation direction
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Split review into sub-areas with explicit owners (CLI login/provisioning, Cloud DB/storage, starters, MCP/A2A).
  2. Require an end-to-end scripted test: new user → login → create → deploy → verify agent runs.
  3. If risk remains high, break PR into smaller mergeable chunks to reduce rollback blast radius.
- **Potential Assignees:**
  - **lalalune** (author)
  - **ChristopherTrimboli** (CLI + Cloud default provider work)
  - **standujar** (review for correctness/tests)
  - **wtfsayo** (runtime/message pipeline impact review)

---

### 9) Custom Model Hosting on Eliza Cloud (Roadmap “Next Week”)
- **Issue Title & ID:** “Support custom model hosting on user GPU servers via Eliza Cloud” — **CLOUD-FEAT-2025-12-26-01**
- **Current Status:** Announced as upcoming; not shipped.
- **Impact Assessment:**
  - **User Impact:** **Medium** (important to power users; not required for basic usage)
  - **Functional Impact:** **No** (enhancement)
  - **Brand Impact:** **Medium** (competitive differentiation)
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component Affected:** Cloud, Model Integration, Auth, Routing
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Model serving, secure networking, auth tokens, billing/quotas
  - **Dependencies:** Cloud auth story, agent runtime compatibility, upload/storage constraints
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define MVP: “Bring-your-own-endpoint” with signed requests + health checks.
  2. Threat model (SSRF, token leakage, prompt/data exfil) before rollout.
  3. Add UI/API surfaces for selecting custom provider per agent.
- **Potential Assignees:**
  - **Borko** (Cloud roadmap statements)
  - **standujar** (server/auth)
  - **Odilitime** (platform coordination)

---

### 10) Cloud Website UX/UI + Documentation Gaps (User Confusion)
- **Issue Title & ID:** “Improve ElizaOS Cloud website UX/UI and documentation” — **CLOUD-UX-2025-12-26-01**
- **Current Status:** Reported in Discord; users ask basic questions (uploads, utility, onboarding).
- **Impact Assessment:**
  - **User Impact:** **High** (Cloud is the front door; confusion reduces adoption)
  - **Functional Impact:** **Partial**
  - **Brand Impact:** **High** (perception during token turmoil)
- **Technical Classification:**
  - **Category:** UX / Documentation
  - **Component Affected:** Cloud Web, Onboarding Flow, Docs
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Product UX, technical writing, web frontend
  - **Dependencies:** Finalized feature set (uploads, auth, pricing/buybacks messaging constraints)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2** (upgrade to P1 if Cloud is being pushed for January ramp)
- **Specific Actionable Next Steps:**
  1. Add “Getting Started in 5 minutes” with screenshots + common failure modes.
  2. Make limits explicit in-product (e.g., **50MB upload**).
  3. Add a public status/roadmap snippet directly on the Cloud site (not only Discord).
- **Potential Assignees:**
  - **Borko** (Cloud feature clarifications)
  - **Stan ⚡** (docs alignment)
  - **madjin** (web/docs repo experience)

---

### 11) Analytics for Memories Table (Observability Gap)
- **Issue Title & ID:** “Implement analytics on memories table” — **OBS-DB-2025-12-26-01**
- **Current Status:** In development per core-devs notes.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves debugging and product iteration)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low → Medium**
- **Technical Classification:**
  - **Category:** Feature / Observability
  - **Component Affected:** Server/DB, Memory subsystem
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** DB schema knowledge, analytics/events, performance considerations
  - **Dependencies:** Decide KPIs (latency, size growth, retrieval hit rate)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define minimal metrics and retention policy (avoid runaway costs).
  2. Add dashboards/queries for top failure modes (timeouts, large embeddings, slow retrieval).
- **Potential Assignees:**
  - **Odilitime**
  - **standujar**

---

### 12) Bun/Node/NPM Version Inconsistencies Causing Installation Friction
- **Issue Title & ID:** “Fix Bun/Node/NPM version inconsistencies (install + DTS generation issues)” — **DEVEX-2025-12-26-01**
- **Current Status:** Reported in Discord troubleshooting; recurring new-user friction.
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **Partial** (blocks setup for some)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Bug / Developer Experience
  - **Component Affected:** CLI, toolchain, build scripts, types generation
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** JS tooling, Bun/Node compatibility, CI matrix
  - **Dependencies:** CI stabilization; documented supported versions
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a single “Supported Toolchain Versions” section and enforce via CI (matrix).
  2. Make `elizaos doctor` (or similar) output actionable: detected versions + fix commands.
- **Potential Assignees:**
  - **ChristopherTrimboli** (CLI/tooling)
  - **wtfsayo** (ecosystem migrations)
  - **standujar** (tests/CI enforcement)

---

## Highest Priority (Top 5–10) to Address Immediately
1. **P0:** elizaos/eliza **#6211** — Tangem (unsupported wallet) migration blocker + eligibility verification path.
2. **P0:** **DISCORD-SEC-2025-12-26-01** — Migration scam/impersonation incident response (lock down support).
3. **P0:** **OPS-RISK-2025-12-26-01** — Korean exchange delisting/compliance readiness for January.
4. **P1:** **CI-OPS-2025-12-26-01** — Restore CI reliability (Claude billing / workflow guardrails).
5. **P1:** **CORE-PLUGINS-2025-12-26-01** — Standardize `handleMessage` across plugins to prevent inconsistent chat behavior.
6. **P1:** elizaos/eliza **PR #6216** — Eliza Cloud integration: structured review + de-risking plan.
7. **P1:** **DOCS-2025-12-26-01** — Fix outdated monorepo documentation (reduce support load; improve onboarding).
8. **P2:** **CLOUD-UX-2025-12-26-01** — Cloud UX/docs improvements (especially around onboarding + limits).
9. **P2:** **DEVEX-2025-12-26-01** — Toolchain/version consistency and DTS generation friction.
10. **P2:** **CLOUD-FEAT-2025-12-26-01** — Custom model hosting MVP plan (security-first).

---

## Patterns / Themes Indicating Deeper Issues
- **Migration program gaps are primarily “support + UX + edge-case wallet support,” not just smart contract mechanics.** The system lacks a robust path for “eligible but cannot connect” users.
- **Trust and communication are now part of the technical surface area.** Discord impersonation risk turns product operations into a security problem affecting real users financially.
- **Cross-repo API evolution (message handling) continues to create churn.** Without a strict compatibility contract + integration tests, plugins drift and user-facing behavior regresses.
- **Cloud is the strategic center, but onboarding is not yet “self-serve reliable.”** Large integration PRs and incomplete docs increase time-to-value and amplify community frustration.

---

## Recommendations for Process Improvements
1. **Create a single public “Migration Status & Safety” page** (website + GitHub) that is treated as canonical; link everywhere (portal, Discord pins, bot responses).
2. **Introduce a formal “Security/Scam Response Playbook”** for Discord: permissions audit checklist, verified staff identity rules, escalation steps, and public incident updates.
3. **Add “edge-case acceptance tests” for critical flows**:
   - Migration portal: unsupported wallet flow, “0 eligible” explanation states, safe support links only.
   - Plugin messaging: standardized behavior tests across core plugins.
4. **De-risk large PRs via enforced splitting and staged rollouts** (feature flags, incremental merges, explicit E2E scripts required before review).
5. **Operational readiness checks for external dependencies** (CI billing/quota alerts, exchange/compliance deadlines tracked as P0 ops tickets with clear DRIs).