## Issue Triage — 2025-12-28

### 1) Snapshot Eligibility + Tangem Wallet Connection Not Supported (Discord Support Compromised)
- **Issue Title & ID:** “Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised)” — elizaos/eliza **#6211**
- **Current Status:** **OPEN** (1 comment). User reports inability to migrate due to Tangem not supported via WalletConnect; additionally reports Discord impersonation/scam risk.
- **Impact Assessment:**
  - **User Impact:** **High** (token migration affects many; Tangem subset but likely non-trivial)
  - **Functional Impact:** **Partial** (blocks migration for affected wallets; not core framework but core “project flow” for many users)
  - **Brand Impact:** **High** (migration friction + “Discord compromised” perception)
- **Technical Classification:**
  - **Issue Category:** **Security / UX / Documentation**
  - **Component Affected:** **Migration portal + Support workflow (Discord), WalletConnect integration**
  - **Complexity:** **Moderate effort** (process + potentially product changes)
- **Resource Requirements:**
  - **Required Expertise:** Wallet/WC integration knowledge, backend allowlist/migration tooling, community ops/security
  - **Dependencies:** Migration backend constraints; WalletConnect/Tangem capabilities; comms channel hardening
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish an **official, signed** migration support notice (GitHub + website) describing: snapshot rule, supported wallets, and **anti-scam** guidance.
  2. Confirm whether **Tangem snapshot addresses are eligible** and if so, define an **official workaround** (e.g., manual claim path, support queue, or alternate signing flow).
  3. Add migration portal UX: detect “0 eligible” + show “not in snapshot vs unsupported wallet” help and link to official docs.
  4. Lock down Discord support: verified staff list, disable DMs via bot warning, pinned anti-scam banner, ticketing hardening.
- **Potential Assignees:** **odilitime** (migration/support context), **Borko** (token/migration policy), **standujar** (server/auth patterns), + community ops maintainer.

---

### 2) Agent Naming Causes Client Exceptions (names like `null` or numeric values)
- **Issue Title & ID:** “Agent names `null` or numeric values cause save failures / client exceptions” — **DISCORD-2025-12-27-AGENT-NAME**
- **Current Status:** **Reported on Discord (#coders)**; reproducible by reporter; not yet linked to a GitHub issue in provided data.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (agent creation is a primary workflow in Eliza Cloud)
  - **Functional Impact:** **Yes** (blocks creation/editing for certain names; triggers app errors)
  - **Brand Impact:** **High** (basic input validation bugs reduce trust)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **Eliza Cloud UI + API validation + persistence layer**
  - **Complexity:** **Simple fix** if only validation; **Moderate** if name used as identifier/key
- **Resource Requirements:**
  - **Required Expertise:** Frontend validation, API schema validation, DB constraints
  - **Dependencies:** Clarify whether agent “name” is treated as display name vs unique identifier/slug
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue with exact repro steps and stack traces; add failing test.
  2. Decide policy: allow numeric names? (If yes, fix parsing); if no, enforce validation with clear error.
  3. Add server-side schema validation: reject reserved words (`null`, `undefined`) and invalid formats; return structured error.
  4. Add UI inline validation + sanitize payload to avoid `"name": null` serialization bugs.
- **Potential Assignees:** **wtfsayo** (client work), **standujar** (server/api validation), **ChristopherTrimboli** (CLI/cloud flows).

---

### 3) `elizaos deploy` fails due to ECR credentials / repository not found
- **Issue Title & ID:** “Deployment fails: ECR credentials / repository not found during `elizaos deploy`” — **DISCORD-2025-12-27-ECR-DEPLOY**
- **Current Status:** **Reported on Discord (#coders)**; blocks deployment for reporter.
- **Impact Assessment:**
  - **User Impact:** **High** (deploy is core to adoption; affects any AWS/ECR path users)
  - **Functional Impact:** **Yes** (blocks deployments)
  - **Brand Impact:** **High** (broken deploy = “project doesn’t work”)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **CLI Deploy (ECS/ECR path), cloud provisioning**
  - **Complexity:** **Moderate effort** (AWS edge cases + better diagnostics)
- **Resource Requirements:**
  - **Required Expertise:** AWS ECR/ECS, CLI DX, auth/credentials chain
  - **Dependencies:** Confirm expected AWS setup; any recent changes in deploy flow (related to cloud integration work)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Capture full CLI logs and AWS error codes; add a “--debug” output snippet template to docs.
  2. Validate whether CLI should **auto-create ECR repo** if missing; otherwise fail with explicit command to create.
  3. Add preflight checks: AWS account/region mismatch, repo existence, IAM permissions (`ecr:*`, `sts:GetCallerIdentity`).
  4. Add integration test (mock or optional live) for “repo missing” path.
- **Potential Assignees:** **ChristopherTrimboli** (CLI), **standujar** (server/tooling), **lalalune** (cloud integration PR context).

---

### 4) Eliza Cloud login errors / application errors on sign-in
- **Issue Title & ID:** “ElizaCloud login triggers application errors for some users” — **DISCORD-2025-12-26-LOGIN-ERROR**
- **Current Status:** **Reported on Discord**; multiple users discussing; no linked GitHub issue in provided data.
- **Impact Assessment:**
  - **User Impact:** **High** (prevents access to cloud)
  - **Functional Impact:** **Yes** (blocks platform usage)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Cloud Auth (web), session handling**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web auth flows, session cookies/JWT, error observability
  - **Dependencies:** Possible interaction with pending auth work (e.g., JWT auth PR #6200)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Triage via logs: correlate failures by browser, region, account state; add request IDs surfaced in UI.
  2. Add Sentry (or equivalent) event breadcrumbs around login and initial API calls.
  3. Produce a minimal repro checklist (fresh account, existing account, expired session).
  4. If related to auth rework, define a short-term patch vs waiting for larger JWT changes.
- **Potential Assignees:** **standujar** (auth/server), **odilitime** (cloud ops), **wtfsayo** (client).

---

### 5) Streaming functionality broken in core due to wrong dependencies
- **Issue Title & ID:** “Streaming broken in core due to incorrect dependencies” — **DISCORD-2025-12-26-STREAM-DEPS**
- **Current Status:** **Known issue** discussed; related work referenced (e.g., streaming PR efforts); unclear if fully resolved in production.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (streaming is a major UX feature; affects many agents)
  - **Functional Impact:** **Partial** (non-streaming fallback may work)
  - **Brand Impact:** **Medium–High**
- **Technical Classification:**
  - **Issue Category:** **Bug / Performance**
  - **Component Affected:** **Core Framework + Model Integration + Client streaming UI**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** SSE/streaming, dependency graph, client rendering
  - **Dependencies:** Alignment across plugins implementing streaming; ensure one “reference implementation”
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify the exact broken dependency/import path; pin versions if needed.
  2. Add a CI test that validates a streaming response end-to-end (server → client).
  3. Document the canonical streaming interface for plugin authors to avoid divergence.
- **Potential Assignees:** **standujar** (core/server), **wtfsayo** (client), **Stan ⚡** (from Discord; likely core), plugin maintainers.

---

### 6) Client chat UI weak for multi-step streaming interactions (vs “otaku”)
- **Issue Title & ID:** “Multi-step interaction rendering in chat UI is inferior / confusing” — **DISCORD-2025-12-27-UI-MULTISTEP**
- **Current Status:** **Acknowledged**; “Stan ⚡” to review “otaku” implementation.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects perceived responsiveness/clarity)
  - **Functional Impact:** **No** (mostly UX, but can hinder usability)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **UX**
  - **Component Affected:** **Client Chat UI**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** React UI, streaming state machines, message grouping
  - **Dependencies:** Depends on stable streaming event schema
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define desired behavior: step grouping, progress indicators, partial tool outputs, final answer presentation.
  2. Compare event formats produced by “otaku” vs current client; unify if needed.
  3. Add visual regression test cases for multi-step conversations.
- **Potential Assignees:** **wtfsayo**, **standujar/Stan ⚡**.

---

### 7) “Description” field required in view layer but allows empty values
- **Issue Title & ID:** “Description required in UI but backend allows empty; inconsistent validation” — **DISCORD-2025-12-27-DESC-REQUIRED**
- **Current Status:** **Reported**; requires investigation.
- **Impact Assessment:**
  - **User Impact:** **Medium** (confusing UX; can lead to broken listings/search)
  - **Functional Impact:** **Partial** (data quality + downstream display issues)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **Cloud UI + API validation**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Form validation, API schema constraints
  - **Dependencies:** Decide whether description is truly required for all agent types
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Align requirements: either enforce required server-side or relax UI requirement.
  2. Add contract test: create agent with empty description should either fail with message or succeed consistently.
- **Potential Assignees:** **wtfsayo** (UI), **standujar** (API).

---

### 8) Eliza Cloud API endpoints discoverability is poor
- **Issue Title & ID:** “API endpoints exist but are hard to find / not clearly documented” — **DISCORD-2025-12-27-API-DOCS**
- **Current Status:** User asked; response: “they’re on the site,” but request implies discoverability gap.
- **Impact Assessment:**
  - **User Impact:** **Medium** (developer onboarding friction)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **Docs site / Cloud developer portal**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, docs IA
  - **Dependencies:** None
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a single canonical “API Reference” page linked from Cloud dashboard and README.
  2. Include authentication method, base URLs, example curl/TS client snippets, error codes.
- **Potential Assignees:** **madjin** (docs/site work in summaries), **odilitime** (cloud context), **0xtechdean** (docs PR activity).

---

### 9) Token migration UI message “max amount reached” is misleading (actually “wallet not in snapshot”)
- **Issue Title & ID:** “Migrator error copy: ‘max amount reached’ incorrectly indicates snapshot ineligibility” — **DISCORD-2025-12-27-MIGRATOR-COPY**
- **Current Status:** Confirmed in Discord Q&A: message means wallet not in snapshot.
- **Impact Assessment:**
  - **User Impact:** **High** (confuses many users during migration)
  - **Functional Impact:** **Partial** (migration may still be possible; but causes support load)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **UX / Documentation**
  - **Component Affected:** **Migration portal**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Frontend copy/UX, basic eligibility logic
  - **Dependencies:** None
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Replace message with explicit reason: “This wallet was not included in the snapshot” + link to eligibility docs.
  2. Add an “Eligibility checker” explanation: snapshot date, required wallet, common cases (CEX users, moved wallets).
- **Potential Assignees:** **odilitime** (migration comms), frontend maintainer, **madjin** (site/docs).

---

### 10) Custom SSO to unify authentication/identity across Cloud
- **Issue Title & ID:** “Implement custom SSO solution to unify authentication and identity” — **DISCORD-2025-12-26-SSO**
- **Current Status:** **Planned/Discussed**
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves cohesion; reduces auth edge cases)
  - **Functional Impact:** **Partial** (can reduce login issues but not an immediate fix)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **Feature Request / Architecture**
  - **Component Affected:** **Cloud Auth, CLI login, API**
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Auth architecture, JWT/OAuth/OIDC, multi-tenant identity
  - **Dependencies:** Related large auth work (e.g., JWT auth PR #6200) and data isolation strategy
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P3** (unless it is the confirmed root cause of login failures, then reclassify to P1)
- **Specific Actionable Next Steps:**
  1. Decide target model: OIDC provider integration vs first-party IdP.
  2. Write an RFC covering flows: web, CLI, agents, service-to-service.
  3. Pilot behind feature flag for internal accounts first.
- **Potential Assignees:** **standujar** (auth implementation experience), **ChristopherTrimboli** (CLI integration), cloud maintainers.

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0:** elizaos/eliza **#6211** — Tangem snapshot migration blockage + Discord impersonation/scam risk  
2. **P0:** **DISCORD-2025-12-27-AGENT-NAME** — Agent naming (`null`, numeric) causes exceptions / broken creation  
3. **P1:** **DISCORD-2025-12-27-ECR-DEPLOY** — `elizaos deploy` ECR/repo/credentials failure blocks deployment  
4. **P1:** **DISCORD-2025-12-26-LOGIN-ERROR** — Eliza Cloud login/application errors block access  
5. **P1:** **DISCORD-2025-12-26-STREAM-DEPS** — Streaming broken due to dependencies (core UX feature)  
6. **P1:** **DISCORD-2025-12-27-MIGRATOR-COPY** — Misleading migrator error message causing widespread confusion  
7. **P2:** **DISCORD-2025-12-27-UI-MULTISTEP** — Multi-step streaming UI parity with “otaku”  
8. **P2:** **DISCORD-2025-12-27-DESC-REQUIRED** — Inconsistent required-field validation (data quality/UX)  
9. **P2:** **DISCORD-2025-12-27-API-DOCS** — API endpoints documentation/discoverability gap  
10. **P3:** **DISCORD-2025-12-26-SSO** — Unified SSO architecture (plan/RFC)

---

## Patterns / Themes Indicating Deeper Issues
- **Validation inconsistencies across client and server** (agent name edge cases, “required” description allowing empty). This suggests missing shared schemas/contract tests.
- **“Core workflow reliability” gaps** in Cloud onboarding: login stability, deploy failures, and migration UX—all high-visibility funnels.
- **Streaming feature fragmentation** (dependencies, UI parity, plugin/core alignment), indicating the need for a single canonical streaming event contract and end-to-end tests.
- **Support/security surface area**: reports of Discord impersonation highlight a non-code risk that directly impacts user safety and brand trust.

---

## Process Improvement Recommendations
1. **Contract-first validation:** Define shared Zod/JSON schema for agent creation/update payloads and generate both client and server validators from the same source.
2. **E2E “golden path” CI suite:** Add automated tests for: sign-up/login → create agent → chat (streaming on) → deploy (mocked AWS or preflight simulation).
3. **Error-message quality gate:** Treat user-facing error strings in migration/deploy/login as UX-critical; require explicit “reason + next step + link” format.
4. **Security comms hardening:** Maintain an always-updated “Official Links & Staff” page; enforce Discord verification workflows and pinned anti-scam notices; move sensitive support flows to signed GitHub/website posts.
5. **Triage hygiene:** Convert Discord action items into GitHub issues within 24 hours, with labels (`cloud`, `cli`, `auth`, `streaming`, `migration`) and a required “repro + logs” checklist.