## Issue Triage — 2025-12-29

### 1) Discord Support Impersonation / Phishing Risk (Migration) — **elizaos/eliza #6211**
- **Current Status:** Open (reported on GitHub; Discord support described as “compromised”)
- **Impact Assessment:**
  - **User Impact:** **Critical** (migration users are a broad set; direct risk of token loss)
  - **Functional Impact:** **Partial** (migration can be blocked by fear/uncertainty; support channel becomes unusable)
  - **Brand Impact:** **High** (trust + safety incident)
- **Technical Classification:**
  - **Category:** **Security / UX (Trust & Safety)**
  - **Component Affected:** Community Support Ops, Migration Flow Comms, Identity Verification
  - **Complexity:** **Moderate effort** (mostly operational + light engineering for verification/automation)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation/security ops, incident response comms, basic bot automation
  - **Dependencies:** None, but should coordinate with migration portal team for official messaging
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a pinned, canonical “Official Support + Official Links” message (Discord + GitHub + website) and lock it.
  2. Enforce support flow: staff-only outbound links; disable DMs from non-friends in support instructions; auto-warn on “send tokens” phrasing.
  3. Add a lightweight verification bot or role-gated support ticketing; require staff badges + signed messages for sensitive guidance.
  4. Add a migration portal banner: “We will never ask you to send tokens manually” + link to verified domains.
  5. Post an incident update on GitHub issue #6211 with the safe path for Tangem/non-connectable wallets.
- **Potential Assignees:** **Odilitime** (community + platform comms), **Shaw** (official messaging alignment), **Omid Sa / Borko** (support operations), **standujar** (if adding signed/JWT-based verification endpoints or security middleware helps)

---

### 2) Migration Portal: Tangem Wallet Not Supported (WalletConnect limitation) — **elizaos/eliza #6211**
- **Current Status:** Open (user cannot connect Tangem; asks for official safe method)
- **Impact Assessment:**
  - **User Impact:** **High** (affects users holding at snapshot in Tangem; also any “non-exportable” wallet class)
  - **Functional Impact:** **Yes** (blocks migration for eligible users)
  - **Brand Impact:** **High** (appears as “funds stuck”; amplifies support load)
- **Technical Classification:**
  - **Category:** **Bug / UX**
  - **Component Affected:** Migration Portal (wallet connectors), Eligibility verification + claim flow
  - **Complexity:** **Complex solution** (connector support, or alternative claim mechanism)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration, WalletConnect, migration backend/allowlist tooling, secure manual claim process design
  - **Dependencies:** Clarify eligibility policy + snapshot source-of-truth; may require backend tooling or portal update
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1** (P0 if many wallets affected or migration window is short)
- **Specific Actionable Next Steps:**
  1. Confirm eligibility rules publicly: “snapshot wallet must be the claimant” vs “can migrate to a destination wallet.”
  2. Implement one of:
     - **Option A:** Add Tangem-compatible connection (if feasible via WalletConnect updates).
     - **Option B:** Add a **“proof-of-ownership” manual claim** flow (signed message from snapshot address + secure review + rate limits).
     - **Option C:** Allow a controlled “delegate/transfer claim” mechanism (careful: phishing risk).
  3. Provide a safe fallback doc linked from portal + GitHub issue.
- **Potential Assignees:** **Shaw** (migration architecture decisions), **Odilitime** (policy + comms), **standujar** (secure claim verification patterns), **lalalune** (portal/backend integration)

---

### 3) Migration Portal Error: “Max amount reached” / Snapshot Eligibility Confusion — **DISCORD-2025-12-28-MIG-001**
- **Current Status:** Reported on Discord; explanation given (“wallet not in snapshot”), but still recurring and causing support churn
- **Impact Assessment:**
  - **User Impact:** **High** (repeated reports across days; affects many attempting migration)
  - **Functional Impact:** **Partial** (some are truly ineligible; others may be UX/limits for “large amounts” perception)
  - **Brand Impact:** **High** (feels like a broken migrator)
- **Technical Classification:**
  - **Category:** **UX / Bug**
  - **Component Affected:** Migration Portal UI messaging, eligibility calculator, error handling
  - **Complexity:** **Simple fix → Moderate effort** (depending on whether it’s purely messaging vs a limit bug)
- **Resource Requirements:**
  - **Required Expertise:** Frontend UX, migration rules clarity, basic web3 UX writing
  - **Dependencies:** Final, canonical definition of “max amount reached”
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Replace ambiguous error with explicit states:
     - “Not eligible (not in snapshot)” vs “Eligible amount = X” vs “Claimed already.”
  2. Add “Why am I seeing this?” tooltip linking to snapshot policy and common cases (CEX purchases after snapshot, moved wallets, etc.).
  3. Add a self-serve “eligibility check” page that does not require wallet connect (paste address).
- **Potential Assignees:** **lalalune** (product/UX integration), **Odilitime** (policy wording), **wtfsayo** (frontend), **borisudovicic** (QA validation)

---

### 4) Migration Portal: Phantom Wallet Shows Coins but Cannot Exchange — **DISCORD-2025-12-28-MIG-002**
- **Current Status:** Reported on Discord (coins visible after Phantom connect; exchange disabled/blocked)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (likely common wallet; unclear prevalence)
  - **Functional Impact:** **Yes** (blocks migration for affected users)
  - **Brand Impact:** **High** (core user journey appears broken)
- **Technical Classification:**
  - **Category:** **Bug**
  - **Component Affected:** Migration Portal wallet adapter + transaction construction, allowance checks, chain/network switching
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web3 frontend, Phantom provider quirks, RPC/network config, contract interaction debugging
  - **Dependencies:** Repro steps (chain, token, error logs); may be tied to snapshot eligibility states
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect repro bundle: wallet address (redacted), network, console logs, expected eligible amount.
  2. Add diagnostic UI: show “eligible amount,” “reason exchange disabled,” and contract call simulation result.
  3. Confirm network switching + token program compatibility; ensure UI state isn’t blocked by “post-snapshot ineligible” logic.
- **Potential Assignees:** **Shaw** (migration contracts/architecture), **lalalune** (portal fixes), **Odilitime** (support triage + reproduction)

---

### 5) Agent Creation Bug: Names like `"null"` or Numeric (`"1"`, `"69"`, `"666"`) Cause Save Failures / Client Exceptions — **DISCORD-2025-12-27-AGENT-001**
- **Current Status:** Reported on Discord; reproducible; no linked GitHub issue in provided data
- **Impact Assessment:**
  - **User Impact:** **Medium** (hits users who pick certain names; easy to stumble into “1”)
  - **Functional Impact:** **Partial** (blocks creation/edit flows for some agents)
  - **Brand Impact:** **High** (basic creation flow crashing looks low-quality)
- **Technical Classification:**
  - **Category:** **Bug**
  - **Component Affected:** ElizaCloud Dashboard / Agent Builder (validation + API contract)
  - **Complexity:** **Moderate effort** (needs both frontend validation and backend sanitization)
- **Resource Requirements:**
  - **Required Expertise:** Frontend validation, backend API validation (schema), database constraints
  - **Dependencies:** Confirm whether name is used as identifier/slug somewhere
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add server-side validation: disallow reserved tokens (`null`, `undefined`, empty), enforce name regex, length, uniqueness rules.
  2. Add client-side validation with friendly error messages before submit.
  3. Add regression tests: create agent with `"null"`, `"1"`, `"0"`, `"$$"`, unicode; verify no crashes and consistent storage.
  4. Audit any code path converting name → numeric or using name as key.
- **Potential Assignees:** **wtfsayo** (client/UI), **standujar** (server validation patterns), **borisudovicic** (QA reproduction), **Shaw** (data model decisions)

---

### 6) ElizaCloud Login Errors / Application Errors During Login — **DISCORD-2025-12-26-CLOUD-LOGIN-001**
- **Current Status:** Reported on Discord; users experiencing login errors; no linked GitHub issue in provided data
- **Impact Assessment:**
  - **User Impact:** **High** (blocks access to hosted platform)
  - **Functional Impact:** **Yes** (cannot use cloud dashboard)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Category:** **Bug / Performance** (depends on root cause: auth/session/caching)
  - **Component Affected:** Cloud Auth, Dashboard, API sessions
  - **Complexity:** **Complex solution** if systemic auth/session issues; otherwise moderate
- **Resource Requirements:**
  - **Required Expertise:** Auth/session debugging, server logs/observability, frontend auth state handling
  - **Dependencies:** Need error telemetry (HTTP codes, correlation IDs), environment differences
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Instrument login flow: add request IDs and structured logging around auth/session creation.
  2. Create a public “Status + Known Issues” page for ElizaCloud with workaround steps.
  3. Identify top failing endpoint(s) and fix: cookies/CORS, token refresh, session persistence, rate limits.
  4. Add an automated login smoke test in CI against staging.
- **Potential Assignees:** **standujar** (auth expertise; JWT PR work), **Odilitime** (cloud ops triage), **wtfsayo** (frontend auth handling)

---

### 7) Agent Deployment Error: `username null` / Null Username During Deployment — **DISCORD-2025-12-26-DEPLOY-001**
- **Current Status:** Reported on Discord; deployment fails
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (blocks deploying agents on cloud)
  - **Functional Impact:** **Yes** (deployment path broken)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Category:** **Bug**
  - **Component Affected:** Cloud Deploy Pipeline, Identity/SSO integration, CLI/portal provisioning
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Backend identity model, deploy pipeline, database constraints
  - **Dependencies:** Depends on unified auth/SSO direction; may overlap with JWT/user management work
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify where `username` is sourced (JWT claims? profile record? OAuth provider?) and enforce non-null at creation time.
  2. Add migration: backfill usernames for existing users; prevent deploy if profile incomplete with a guided UI prompt.
  3. Add server-side invariant checks + clear error messaging.
- **Potential Assignees:** **standujar** (user management/auth), **Odilitime** (cloud ops), **lalalune** (integration touchpoints)

---

### 8) `elizaos deploy` ECS/ECR Credentials Error — **DISCORD-2025-12-27-CLI-DEPLOY-001**
- **Current Status:** Reported on Discord (ECR credentials error during deployment)
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects users using deploy command; likely developers)
  - **Functional Impact:** **Yes** for affected users (blocks deploy)
  - **Brand Impact:** **Medium–High** (CLI reliability perception)
- **Technical Classification:**
  - **Category:** **Bug / Documentation**
  - **Component Affected:** CLI Deploy (AWS ECS/ECR), credential discovery, docs
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** AWS IAM/ECR auth, CLI error handling, DX documentation
  - **Dependencies:** Confirm supported auth methods (env vars, profiles, SSO), and required permissions
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2** (move to P1 if deploy is a primary funnel this week)
- **Specific Actionable Next Steps:**
  1. Capture the exact error string and add a “known deploy errors” doc section with fixes.
  2. Improve CLI preflight checks: validate AWS identity, region, ECR login, permissions before starting deploy.
  3. Add a minimal reproducible deployment test in CI (mocked or sandbox).
- **Potential Assignees:** **ChristopherTrimboli** (CLI), **standujar** (server/infra knowledge), **lalalune** (DX)

---

### 9) Streaming Broken in Core Due to Wrong Dependencies / UI Multi-step Streaming Issues — **DISCORD-2025-12-26-STREAM-001**
- **Current Status:** Reported on Discord; PRs referenced (e.g., OpenAI streaming fixes and broader streaming support landed earlier, but regressions noted)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (affects perceived responsiveness; common feature)
  - **Functional Impact:** **Partial** (non-streaming may still work, but UX degraded / some flows broken)
  - **Brand Impact:** **High** (modern AI chat expects streaming)
- **Technical Classification:**
  - **Category:** **Bug / UX**
  - **Component Affected:** Core streaming plumbing, client chat rendering, model plugins
  - **Complexity:** **Moderate effort** (integration + UI state machine)
- **Resource Requirements:**
  - **Required Expertise:** Frontend streaming UI, SSE/socket events, plugin integration testing
  - **Dependencies:** Align core + plugin-openai streaming implementations; ensure consistent event contracts
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add an end-to-end streaming test that covers multistep tool interactions (the “otaku” reference) and verifies UI rendering order.
  2. Pin/verify dependency versions that broke streaming; add lockfile constraints if needed.
  3. Standardize streaming event payloads across core + plugins; document contract.
- **Potential Assignees:** **Stan ⚡** (streaming work referenced), **wtfsayo** (client), **standujar** (core/server streaming), **sayonara** (component streaming contributor)

---

### 10) Documentation Gaps: Migration Instructions Beyond Ledger + Clarify “by elizaOS” Affiliations — **DISCORD-2025-12-28-DOC-001**
- **Current Status:** Reported on Discord (users confused by migration steps; confusion around official vs ecosystem projects)
- **Impact Assessment:**
  - **User Impact:** **High** (repeated questions; affects both migration users and ecosystem perception)
  - **Functional Impact:** **Partial** (workarounds exist, but users get stuck)
  - **Brand Impact:** **High** (confusion undermines trust and ecosystem credibility)
- **Technical Classification:**
  - **Category:** **Documentation / UX**
  - **Component Affected:** Docs site, Migration portal help content, Ecosystem labeling guidelines
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, product comms, minimal engineering for site/banner updates
  - **Dependencies:** Final policy on snapshot eligibility and supported wallets; official affiliation criteria
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a single migration guide page with: eligibility rules, supported wallets, CEX limitations, and “never send tokens manually” warning.
  2. Add an “Official / Partner / Community-built” badge system and publish criteria; update “by elizaOS” language to “built on elizaOS.”
  3. Add a FAQ entry for “max amount reached” and “Phantom shows tokens but can’t exchange.”
- **Potential Assignees:** **madjin** (docs/site work), **Odilitime** (official comms), **borisudovicic** (UX feedback), **Shaw** (policy alignment)

---

## Top Priority Summary (Next 24–72 Hours Focus)
1. **P0:** **#6211 — Discord impersonation/phishing risk** (lock down support + publish canonical guidance).
2. **P1:** **#6211 — Tangem wallet migration blocked** (ship a safe alternative claim/connect method).
3. **P1:** **Migration portal errors** (“max amount reached” clarity + Phantom exchange blocked) — **DISCORD-MIG-001/002**.
4. **P1:** **Agent naming crash** (“null” / numeric names) — **DISCORD-AGENT-001**.
5. **P1:** **ElizaCloud login errors** — **DISCORD-CLOUD-LOGIN-001**.
6. **P1:** **Streaming regressions / multistep UI issues** — **DISCORD-STREAM-001**.
7. **P1:** **Deployment username null** — **DISCORD-DEPLOY-001**.
8. **P2:** **CLI deploy ECR credentials error** — **DISCORD-CLI-DEPLOY-001**.
9. **P2:** **Docs: migration beyond Ledger + affiliation labeling clarity** — **DISCORD-DOC-001**.

---

## Patterns / Themes Indicating Deeper Architectural Problems
- **Trust & Safety is now a product requirement:** migration + wallets + support channels create a high-value attack surface; operational controls need to be treated as part of the system.
- **Validation gaps across boundaries:** “null username,” “null/numeric agent name” suggest missing **server-side invariants** and overreliance on client assumptions.
- **Streaming + multistep UX complexity:** tool/multistep interactions expose fragile UI state management and inconsistent event contracts between core ↔ plugins ↔ client.
- **Onboarding and migration UX debt:** repeated Discord questions indicate missing in-product explanations and self-serve diagnostics.

---

## Process Improvement Recommendations
1. **Ship a “Known Issues / Status” page** for ElizaCloud + Migration (reduce Discord load; provides a canonical reference during incidents).
2. **Add server-side schema validation everywhere** (names, usernames, required fields) with consistent error codes; back it with regression tests.
3. **Introduce security playbooks for launches** (migration windows): verified links, pinned warnings, role-gated support, incident comms templates.
4. **Create an E2E “golden path” test suite** (login → create agent → deploy → chat streaming) running on staging daily.
5. **Standardize event contracts for streaming and tool steps** (versioned payload schema; compatibility tests across plugins).