## Issue Triage — 2025-12-30 (elizaOS)

### 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 (user requesting an official, verifiable migration path; mentions impersonation/scam risk in Discord support flow)
- **Impact Assessment:**
  - **User Impact:** **High** (any Tangem/WalletConnect-incompatible users; plus broader users exposed to support impersonation risk)
  - **Functional Impact:** **Partial** (blocks migration for a subset; harms ability to safely get help)
  - **Brand Impact:** **High** (security perception + trust in official channels)
- **Technical Classification:**
  - **Issue Category:** **Security / UX / Documentation**
  - **Component Affected:** Migration flow (portal/integration), Support workflow (community ops), WalletConnect compatibility
  - **Complexity:** **Moderate effort** (may require product/ops changes; potentially portal support for additional connectors or manual verification process)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration, backend allowlist/eligibility verification, security/community operations
  - **Dependencies:** Migration portal capabilities; WalletConnect/Tangem limitations; internal policy for manual eligibility verification
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a **single canonical “Official Migration Support” page** (site + GitHub) listing: official links, supported wallets, and a “never send tokens” warning.
  2. Define and document a **manual remediation path** for WalletConnect-incompatible wallets (e.g., signed message proof + snapshot verification + safe claim method).
  3. Add a **prominent banner** in migration UI: “If wallet unsupported, follow official manual process (link).”
  4. Community ops: lock down support flow (verified staff, ticket bot hardening, pinned warnings, impersonator reporting guidance).
- **Potential Assignees:** **Shaw** (product direction), **Stan ⚡** (core coordination), **standujar** (server/auth patterns + secure flows), **madjin** (docs/site comms)

---

### 2) Agent share-link chat fails (unspecified error)
- **Issue Title & ID:** “Error when chatting with an agent via share link” — **Discord report (no GitHub issue yet)**
- **Current Status:** Reported by user; root cause unknown; not yet tracked in GitHub
- **Impact Assessment:**
  - **User Impact:** **High** (share links are a key growth loop; affects new users disproportionately)
  - **Functional Impact:** **Yes** (breaks core “chat with agent” entrypoint)
  - **Brand Impact:** **High** (first-touch experience)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** Client share-link flow, API sessions/agents endpoints, auth/entity handling, message streaming
  - **Complexity:** **Moderate effort** (needs repro + instrumentation + likely edge-case fix)
- **Resource Requirements:**
  - **Required Expertise:** Full-stack debugging (client + server), observability/logging, session/auth flows
  - **Dependencies:** Ability to reproduce with a real share link; server logs; recent messaging/route changes
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue in elizaos/eliza: include share URL pattern, expected vs actual, screenshots, console/network logs.
  2. Add **temporary server-side logging** for share-link entry: agent lookup, session creation, room creation, message dispatch.
  3. Verify regressions around messaging routes (recent route standardization) and streaming/SSE pathways.
  4. Add an automated test covering “open share link → create session → send first message → receive response.”
- **Potential Assignees:** **wtfsayo** (client/runtime behavior), **standujar** (server messaging/services), **ChristopherTrimboli** (CLI + integration sanity), **0xbbjoker** (repro + diagnostics)

---

### 3) Agent creation: reserved names / numeric names cause save errors and dashboard exceptions
- **Issue Title & ID:** “Agent names like `null` or numeric values cause save problems or client exceptions” — **Discord report (no GitHub issue yet)**
- **Current Status:** Confirmed by community report (repro: “null” editable; numeric names trigger app errors; “$” works)
- **Impact Assessment:**
  - **User Impact:** **Medium** (agent creators using edge-case names; but can lead to confusing crashes)
  - **Functional Impact:** **Partial** (blocks creation/edit flows for certain inputs)
  - **Brand Impact:** **Medium–High** (visible crash undermines polish)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** Client validation, server schema/validation, DB constraints, slug/id generation
  - **Complexity:** **Simple fix** (tight validation + consistent server enforcement) to **Moderate** (if names are used as identifiers)
- **Resource Requirements:**
  - **Required Expertise:** Frontend form validation, backend request validation, DB schema constraints
  - **Dependencies:** Naming rules agreement; backward compatibility for existing agents
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. File GitHub issue with exact repro steps and stack traces.
  2. Decide naming policy: disallow reserved tokens (`null`, `undefined`), numeric-only, or enforce min length + allowed charset.
  3. Enforce validation **both client and server**, return user-friendly error messages.
  4. Add tests (client validation + server API validation).
- **Potential Assignees:** **borisudovicic** (UX expectations + acceptance criteria), **wtfsayo** (client), **standujar** (server validation)

---

### 4) Migration portal UX: “max amount reached” error and Phantom wallet tokens visible but not exchangeable
- **Issue Title & ID:** “Migration: ‘max amount reached’ / tokens visible but not exchangeable (Phantom)” — **Discord reports (no GitHub issue yet)**
- **Current Status:** Actively affecting multiple users; support redirecting to channels; root cause partly policy (snapshot eligibility) but messaging is confusing
- **Impact Assessment:**
  - **User Impact:** **High** (migration touches many holders)
  - **Functional Impact:** **Partial** (some users blocked; others misinformed)
  - **Brand Impact:** **High** (financial + trust-sensitive)
- **Technical Classification:**
  - **Issue Category:** **UX / Bug / Documentation**
  - **Component Affected:** Migration UI copy, eligibility checks, wallet connection, on-chain/off-chain indexer consistency
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet UX, backend eligibility logic, support ops/docs
  - **Dependencies:** Snapshot dataset; portal implementation details; chain/indexer reliability
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Replace ambiguous error text (“max amount reached”) with explicit reasons: “Wallet not in snapshot” vs “post-snapshot purchases not eligible.”
  2. Add “Why am I seeing tokens but can’t migrate?” help panel explaining read-only token detection vs eligibility.
  3. Add structured support intake form that captures: wallet, chain, token contract, snapshot status, error code.
- **Potential Assignees:** **Shaw** (product), **madjin** (docs/comms), **Stan ⚡** (coordination), **odilitime** (support workflow + messaging)

---

### 5) Restore first-class SQLite support (portability; PGLite corruption/file management concerns)
- **Issue Title & ID:** “Restore first-class SQLite support” — **Discord core-devs discussion (no GitHub issue yet)**
- **Current Status:** Requested by core contributors; rationale: portability + single-file DB vs PGLite issues
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (self-hosters, local dev, edge deployments; potential data corruption concerns elevate urgency)
  - **Functional Impact:** **Partial** (not always blocking, but DB reliability is foundational)
  - **Brand Impact:** **High** (data loss/corruption perception)
- **Technical Classification:**
  - **Issue Category:** **Bug / Architectural**
  - **Component Affected:** plugin-sql, storage layer, runtime migrator, cloud/local parity
  - **Complexity:** **Architectural change** (support matrix, adapters, testing, migration strategy)
- **Resource Requirements:**
  - **Required Expertise:** DB adapters (SQLite), migration tooling, test infra, backwards compatibility
  - **Dependencies:** Agreement on supported DBs; existing PGLite migrations; CLI defaults; docs
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Open a design issue: “SQLite as first-class adapter” with acceptance criteria (feature parity, migration story, perf).
  2. Prototype adapter + CI test matrix (SQLite + Postgres + PGLite where applicable).
  3. Define how `.eliza` storage layout works across adapters; ensure safe file locking and corruption mitigation.
  4. Publish “Choosing a DB” guidance (local dev vs prod).
- **Potential Assignees:** **standujar** (plugin-sql depth), **0xbbjoker** (DB-related fixes + reviews), **lalalune** (core integration), **Stan ⚡** (architecture)

---

### 6) Deployment failure: ECR credentials error with `elizaos deploy`
- **Issue Title & ID:** “ECR credentials error during deployment with `elizaos deploy`” — **Discord report (no GitHub issue yet)**
- **Current Status:** Reported; unknown prevalence; blocks deploy for affected users
- **Impact Assessment:**
  - **User Impact:** **Medium** (users deploying to AWS/ECS path)
  - **Functional Impact:** **Yes** (blocks deployment workflow)
  - **Brand Impact:** **Medium** (DX reliability)
- **Technical Classification:**
  - **Issue Category:** **Bug / Documentation**
  - **Component Affected:** CLI deploy command, AWS auth chain, docker build/push pipeline
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** AWS ECR/ECS, CLI tooling (Bun.spawn changes recently merged), credential provider chain diagnostics
  - **Dependencies:** User environment details; reproducible steps; CI/deploy docs
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue with full CLI output + `AWS_PROFILE`/region info + auth method (SSO, keys, assumed role).
  2. Add a `--debug` flag section in deploy docs to print which credential provider is used.
  3. Provide a preflight command (`elizaos deploy --check`) to validate ECR login and required IAM permissions.
- **Potential Assignees:** **ChristopherTrimboli** (CLI), **standujar** (infra/server), **lalalune** (CLI/core integration)

---

### 7) PRD/Epic: World-class TypeScript patterns (Decorators, DI, advanced types)
- **Issue Title & ID:** “Epic: World-class TypeScript patterns (Decorators, DI, advanced type system)” — elizaos/eliza **#6292**
- **Current Status:** Open
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (indirect; improves maintainability and plugin authoring)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (developer confidence + ecosystem quality)
- **Technical Classification:**
  - **Issue Category:** **Feature Request / Architectural**
  - **Component Affected:** Core framework, plugin system, build tooling
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** TypeScript architecture, DI frameworks/patterns, decorators, build config (tsconfig/emit)
  - **Dependencies:** Agreed coding standards; compatibility with Bun; runtime constraints
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Convert into a tracked RFC with milestones: (a) DI container choice or minimal in-house pattern, (b) decorator support policy, (c) migration plan.
  2. Identify 1–2 high-leverage refactors (e.g., service registration, plugin lifecycle) as pilot implementations.
  3. Add “type-safety gates” that are incremental (unused vars checks were discussed as a middle ground).
- **Potential Assignees:** **wtfsayo** (issue author), **standujar** (core/services), **Stan ⚡** (architecture review)

---

### 8) Feature request: Streaming Chain-of-Thought (CoT) reasoning
- **Issue Title & ID:** “Add support for streaming Chain of Thought (CoT) reasoning” — elizaos/eliza **#6294**
- **Current Status:** Open
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (some users want richer introspection; may conflict with safety/policy)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (could be positive if done safely; negative if it encourages leaking hidden reasoning)
- **Technical Classification:**
  - **Issue Category:** **Feature Request / UX**
  - **Component Affected:** Model integration, streaming pipeline, client renderer
  - **Complexity:** **Complex solution** (policy + UI + provider differences)
- **Resource Requirements:**
  - **Required Expertise:** Streaming protocols, model provider behavior, safety/policy alignment, UI/UX
  - **Dependencies:** Project stance on CoT visibility; provider support; existing streaming infrastructure
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Clarify requirement: “CoT” vs “structured trace/explanations.” Prefer a **safe reasoning trace** format (summaries, tool calls, steps) over raw hidden reasoning.
  2. Prototype UI as an optional “Debug/Trace” panel.
  3. Ensure defaults do not expose sensitive hidden tokens; add redaction rules.
- **Potential Assignees:** **linear** (issue author), **wtfsayo** (client/streaming), **standujar** (server streaming/events)

---

### 9) UX: Auto-open last conversation when clicking an agent
- **Issue Title & ID:** “When clicking an agent with ≥1 conversation, open that conversation automatically” — elizaos/eliza **#6295**
- **Current Status:** Open
- **Impact Assessment:**
  - **User Impact:** **Medium** (common workflow improvement)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (polish + perceived quality)
- **Technical Classification:**
  - **Issue Category:** **UX**
  - **Component Affected:** Client dashboard/agents UI, sessions routing
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Frontend routing/state, API client sessions ordering
  - **Dependencies:** Define “which conversation” (most recent; pinned; last active)
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Confirm UX rule: open most recent session by `updatedAt`.
  2. Implement deterministic selection + loading state.
  3. Add regression test for navigation behavior.
- **Potential Assignees:** **borisudovicic** (issue author/UX), **wtfsayo** (client)

---

### 10) Windows setup friction: “no module named src” when running DaVinci Resolve MCP batch file
- **Issue Title & ID:** “DaVinci Resolve MCP (Windows): `no module named src` when running .bat directly” — **Discord report (no GitHub issue yet)**
- **Current Status:** Workaround exists (set `PYTHONPATH` via PowerShell); needs proper fix/docs
- **Impact Assessment:**
  - **User Impact:** **Medium** (Windows users; new integrators)
  - **Functional Impact:** **Partial** (blocks integration setup)
  - **Brand Impact:** **Medium** (onboarding friction)
- **Technical Classification:**
  - **Issue Category:** **Documentation / Bug**
  - **Component Affected:** Integration project packaging, Windows launcher scripts
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Python packaging, Windows scripting
  - **Dependencies:** Identify canonical entrypoint; ensure repo structure supports module execution (`python -m ...`)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a Windows-friendly launcher that sets `PYTHONPATH` automatically or uses `python -m` with a proper package.
  2. Publish a short Windows setup guide with exact commands.
  3. Add a CI smoke test for the launcher (where feasible).
- **Potential Assignees:** **Irie_Rubz** (reporter, if contributor), **odilitime** (docs/support), **lalalune** (integration alignment)

---

## Summary: Top Highest-Priority Issues to Address Immediately (Top 5–10)
1. **#6211 Tangem migration + compromised support/impersonation risk** — **P0**
2. **Share-link chat failing (untracked)** — **P0**
3. **Migration portal confusing/blocking errors (“max amount reached”, Phantom not exchangeable)** — **P1**
4. **Restore first-class SQLite support (reliability/portability)** — **P1**
5. **`elizaos deploy` ECR credentials failure (blocks deploy)** — **P1**
6. **Agent naming crash/invalid names** — **P1**
7. **#6295 Auto-open conversation UX** — **P2**
8. **Windows MCP setup `PYTHONPATH`/module error** — **P2**
9. **#6292 TypeScript patterns epic** — **P2**
10. **#6294 Streaming “CoT” (needs safe framing)** — **P3**

---

## Patterns / Themes Indicating Deeper Architectural Problems
- **Fragile “entrypoint” UX paths:** Share links and migration flows are high-leverage; failures here create outsized brand damage.
- **Validation gaps across client/server:** Agent naming issues suggest inconsistent validation and possible overuse of user-provided strings as identifiers.
- **Storage layer uncertainty:** Ongoing SQLite vs PGLite concerns indicate a need for a clearly-defined, tested storage abstraction with a supported adapter matrix.
- **DX/ops drift:** Deploy credential failures and Windows setup friction suggest insufficient “first-run” and “preflight” tooling plus missing platform-specific docs.
- **Feature requests targeting internals (CoT/DI/decorators):** Signals appetite for stronger developer ergonomics, but also risk of large architectural churn without an RFC process.

---

## Recommendations for Process Improvements
1. **Create a “P0 Pipeline” playbook:** mandatory repro steps, required logs, owner within 24 hours, and a comms update cadence (especially for share-link and migration issues).
2. **Institute RFCs for architectural changes:** required for DI/decorators and storage adapter strategy; include migration plan + test plan + rollback strategy.
3. **Add preflight diagnostics to CLI and critical flows:** `elizaos doctor` (env, ports, credentials, DB adapter readiness) + better error codes for UI surfaces.
4. **Strengthen validation contract:** define canonical schemas (server-enforced), generate client validators from shared schemas, and add regression tests for edge cases.
5. **Security + comms hardening:** publish canonical “official links” and “never send tokens” guidance; improve verification of support identities and ticket workflows.