## Issue Triage — 2025-12-24

### 1) Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised)
- **Issue Title & ID:** Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised) — **#6211**
- **Current Status:** **OPEN** (user reports inability to connect Tangem via WalletConnect; Discord support impersonators reported)
- **Impact Assessment:**
  - **User Impact:** **High** (affects token migration subset; high-sensitivity user flow)
  - **Functional Impact:** **Partial** (blocks migration portal for affected wallet users; not core runtime)
  - **Brand Impact:** **High** (trust/safety + migration issues; amplified by impersonation risk)
- **Technical Classification:**
  - **Issue Category:** **Security / UX / Documentation**
  - **Component Affected:** **Migration Portal / Auth-Wallet Integration / Support channels**
  - **Complexity:** **Moderate effort** (may require backend exception path + comms)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration (WalletConnect), backend ops for eligibility/whitelist, security/community ops
  - **Dependencies:** Snapshot data access; migration portal code/infra; decision on supported wallets vs manual remediation policy
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Establish an official “unsupported wallet” remediation policy** (manual claim path, signed message proofs, or backend whitelist mapping).
  2. Add a **safe, verifiable support workflow** (GitHub Discussion/issue template + signed team messages; pin official links everywhere).
  3. If feasible: implement **WalletConnect alternative** or **“manual verify”** flow (proof of control of Tangem address via transaction signature or on-chain proof).
  4. Publish a **Security Advisory**: “No one will ask you to send tokens” + canonical URLs + how to verify staff.
- **Potential Assignees:**
  - **standujar** (server/auth systems, policy-enforcing middleware experience)
  - **lalalune** (Cloud/CLI onboarding flows; can help craft secure user flows)
  - **Kenk / Odilitime** (project comms + ecosystem coordination; operational support)

---

### 2) CVE-10 RCE in n8n (Supply Chain / Ops Exposure Check)
- **Issue Title & ID:** Investigate CVE-10 RCE exploit in n8n for potential security implications — **DISC-2025-12-22-SEC-01**
- **Current Status:** **Untracked (Discord alert)** — needs creation of a GitHub Security issue/advisory
- **Impact Assessment:**
  - **User Impact:** **Medium → Critical** (depends on whether elizaOS infra/devops uses n8n; could be total environment compromise)
  - **Functional Impact:** **Yes (if present in production tooling)** / **No (if not used)**
  - **Brand Impact:** **High** (security posture)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Infrastructure/Automation Tooling (CI/CD, workflows, internal ops)**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** DevSecOps, dependency/inventory auditing, patching/hardening
  - **Dependencies:** Accurate inventory of tooling used in Cloud beta + internal automations
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Inventory**: confirm whether n8n is used anywhere (Cloud, internal automation, contributor guides).
  2. If used: **pin/upgrade** to patched versions, rotate secrets, review exposed endpoints, restrict network access.
  3. If not used: document “not affected” in an internal security note; add to **dependency policy** checklist.
- **Potential Assignees:**
  - **standujar** (server/security-adjacent work)
  - **ChristopherTrimboli** (ecosystem dependency management experience)
  - **0xbbjoker** (strong reviewer; can help validate changes and controls)

---

### 3) Streaming and State Management Instability
- **Issue Title & ID:** Address streaming and state management in the application — **#5930**
- **Current Status:** **OPEN** (dev notes: “streaming issues in cloud build mode have been fixed” but broader issue remains)
- **Impact Assessment:**
  - **User Impact:** **High** (streaming is a flagship UX; regressions visible immediately)
  - **Functional Impact:** **Partial** (non-stream fallback may exist; but chat UX degraded and can break workflows)
  - **Brand Impact:** **High** (perceived reliability/quality)
- **Technical Classification:**
  - **Issue Category:** **Bug / Performance**
  - **Component Affected:** **Core messaging, client chat UI, server message bus, Cloud build mode**
  - **Complexity:** **Complex solution** (race conditions, ordering, partial updates, reconnect behavior)
- **Resource Requirements:**
  - **Required Expertise:** Realtime systems (Socket.IO), state management (client), message service semantics, concurrency testing
  - **Dependencies:** Related streaming work/PRs (e.g., streaming enhancements landed earlier in month; cloud build-mode fixes)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define **streaming correctness contract**: token ordering, final message commit semantics, retries, reconnect reconciliation.
  2. Add **repro harness**: automated tests for rapid message send, reconnect, multi-tab, slow network (CI).
  3. Instrument: server emits structured events (start/delta/end, messageId) + client traces for dropped/duplicated chunks.
  4. Close the loop with Cloud beta: collect **production traces** for streaming sessions (sampling + PII-safe).
- **Potential Assignees:**
  - **standujar** (core/server messaging + tests)
  - **prajwal-pl** (recent PR touching message handlers and async/cloud optimization)
  - **wtfsayo** (has worked on messageService migrations and client fixes)

---

### 4) CLI Install Errors Reported by Community
- **Issue Title & ID:** Eliza CLI installation error (community report; screenshot shared) — **DISC-2025-12-23-CLI-01**
- **Current Status:** **Untracked (Discord coders)** — needs a GitHub issue with logs, OS, package manager, node/bun versions
- **Impact Assessment:**
  - **User Impact:** **High** (CLI is primary onboarding path, especially with Cloud ramp in January)
  - **Functional Impact:** **Yes** (blocks new users from starting)
  - **Brand Impact:** **High** (first-touch failure)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **CLI / Installer / Create flow**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun packaging, cross-platform install troubleshooting, release engineering
  - **Dependencies:** Requires user-provided logs; possibly related to recent dependency churn
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue template for install failures: `elizaos --version`, OS, shell, node/bun, install command, full verbose logs.
  2. Add `elizaos doctor` (or `elizaos debug env`) to print environment diagnostics.
  3. Reproduce on fresh environments (macOS/Linux/Windows) using CI smoke tests.
  4. If error relates to Cloud login/provisioning: add clearer fallback + actionable messaging.
- **Potential Assignees:**
  - **ChristopherTrimboli** (CLI and dependency updates; Cloud default provider integration)
  - **lalalune** (Cloud integration path + create/deploy/publish flow)
  - **standujar** (CI/test coverage; can add smoke tests)

---

### 5) CLI Package Disk Bloat (~17GB) Due to Duplicated DB Files in Templates
- **Issue Title & ID:** CLI package uses ~17GB disk due to DB files copied multiple times in project-starter templates — **DISC-2025-12-21-CLI-02**
- **Current Status:** **Known (Discord); not tracked as GitHub issue** — needs formal issue + fix PR
- **Impact Assessment:**
  - **User Impact:** **High** (affects anyone using starters; painful on CI and laptops)
  - **Functional Impact:** **Partial** (not a runtime crash, but can break installs, slow builds, exceed quotas)
  - **Brand Impact:** **High** (“why is this so huge?” damages credibility)
- **Technical Classification:**
  - **Issue Category:** **Performance / Bug**
  - **Component Affected:** **CLI / project-starter templates / packaging**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Packaging, template generation, filesystem and bundling best practices
  - **Dependencies:** Identify which DB artifacts are being vendored; decide canonical location and generation strategy
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a **repo guardrail**: CI check that fails if generated templates include large binary/db artifacts.
  2. Refactor starters to **generate DB files on first run** (or download optional assets) instead of bundling.
  3. Ensure `.gitignore`/pack rules prevent accidental inclusion; validate npm/bun publish contents.
  4. Publish a quick mitigation note: how to clean caches / remove duplicated files.
- **Potential Assignees:**
  - **ChristopherTrimboli** (CLI packaging + ecosystem deps)
  - **wtfsayo** (has handled plugin-sql + example migrations; understands DB artifacts)
  - **lalalune** (starter flows + Cloud integration impacts)

---

### 6) Standardize `Elizaos.handleMessage` Across Plugins (Interoperability + Reliability)
- **Issue Title & ID:** Standardize `Elizaos.handleMessage` across plugins (PR needs to be pushed) — **DISC-2025-12-23-CORE-01**
- **Current Status:** **In progress (core-devs); PR not yet published**
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (plugin ecosystem stability; fewer “works in X but not Y” bugs)
  - **Functional Impact:** **Partial** (inconsistent behavior across integrations; breaks common use cases)
  - **Brand Impact:** **Medium** (developer experience + plugin reliability)
- **Technical Classification:**
  - **Issue Category:** **Bug / Architectural**
  - **Component Affected:** **Core Framework + Plugin System**
  - **Complexity:** **Architectural change** (API standardization, compatibility layer, deprecations)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime/messaging API, plugin integration, backward compatibility strategy
  - **Dependencies:** Ongoing plugin refactors (Discord/Telegram), message service handler work
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish the PR and define a **single canonical message contract** (types + lifecycle events).
  2. Provide a **migration guide** and deprecation timeline for old event systems.
  3. Add conformance tests that plugins must pass (message in/out, streaming compatibility, metadata).
- **Potential Assignees:**
  - **standujar** (core runtime + message service evolution)
  - **odilitime** (plugin work: Discord fixes; plugin-wrapped functionality)
  - **wtfsayo** (prior messageService migrations)

---

### 7) Starknet Plugin: “Failed to parse String to BigInt” When Deploying Unruggable Token
- **Issue Title & ID:** Starknet plugin BigInt parsing error in `DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN` — **DISC-2025-12-22-STARKNET-01**
- **Current Status:** **Untracked (Discord); debugging in DMs; modified `unruggable.ts` with added logging**
- **Impact Assessment:**
  - **User Impact:** **Medium** (subset using Starknet token deploy action)
  - **Functional Impact:** **Yes (for that action)** / **No (overall)**
  - **Brand Impact:** **Medium** (Web3 plugin reliability perception)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin System / Starknet Plugin**
  - **Complexity:** **Simple fix → Moderate effort** (likely input normalization; could be serialization boundary)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript BigInt handling, Starknet SDK types, JSON serialization pitfalls
  - **Dependencies:** Repro inputs (exact payload causing parse); confirm whether values exceed JS safe integer range
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Convert DM debugging into a GitHub issue with **redacted repro payload** and expected/actual.
  2. Audit for `JSON.stringify` / transport layers turning numeric strings into unexpected formats.
  3. Implement robust parsing: accept `0x` hex, decimal strings, and guard against commas/whitespace.
  4. Add unit tests covering representative on-chain values and edge cases.
- **Potential Assignees:**
  - **odilitime** (already engaged offering review)
  - **FenrirFawks** (reporter; can supply repro/test cases)
  - **standujar** (if fix requires shared parsing utilities)

---

### 8) Eliza Cloud Integration PR (Large Surface Area; Needs Focused Review)
- **Issue Title & ID:** Eliza Cloud Integration, add MCP + A2A service starter, integrate CLI and starter projects tight — **PR #6216**
- **Current Status:** **OPEN (not merged; very large diff ~10k additions)**; team also noted “review Cloud PR from user 500627620191404033” (likely separate PR)
- **Impact Assessment:**
  - **User Impact:** **High** (Cloud beta onboarding + January ramp)
  - **Functional Impact:** **Partial** (core still works, but Cloud-first path is strategic)
  - **Brand Impact:** **High** (Cloud is positioned as primary platform for agent registration)
- **Technical Classification:**
  - **Issue Category:** **Feature / Architectural**
  - **Component Affected:** **Cloud integration, CLI create/deploy/publish flow, starters**
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** CLI flows, auth/provisioning, storage/db provider abstractions, security review
  - **Dependencies:** Auth direction (JWT PR #6200), data isolation strategy, template size fixes
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Break review into checklists: **security**, **DX/onboarding**, **backward compatibility**, **telemetry**, **failure modes**.
  2. Require end-to-end test plan: create → deploy → publish; include offline/non-Cloud path.
  3. If feasible, split into smaller PRs (provider abstraction vs starter templates vs CLI UX).
- **Potential Assignees:**
  - **lalalune** (author; can split and iterate quickly)
  - **ChristopherTrimboli** (CLI/cloud onboarding; dependency correctness)
  - **standujar** (server/auth + multi-tenant implications)

---

### 9) Chat Renaming Functionality
- **Issue Title & ID:** Implementation of chat renaming functionality — **#6278**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium** (quality-of-life, organization)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (polish expectation for app UX)
- **Technical Classification:**
  - **Issue Category:** **UX / Feature Request**
  - **Component Affected:** **Client UI + Server messaging/session metadata**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Client UI, API endpoints for session/channel metadata, DB migration if needed
  - **Dependencies:** Clarify whether “chat” maps to room/session/channel; ensure data isolation compatibility
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define entity to rename (room vs session) and persistence layer.
  2. Add API route + optimistic UI update + validation (length/charset).
  3. Add e2e test for rename persistence across reload.
- **Potential Assignees:**
  - **wtfsayo** (client + message service experience)
  - **standujar** (server endpoints + schema)
  - **borisudovicic** (spec/UX acceptance criteria)

---

### 10) Add Feedback Button
- **Issue Title & ID:** Proposal to add a feedback button to the application — **#6280**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves feedback loop during Cloud beta)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (signals responsiveness and polish)
- **Technical Classification:**
  - **Issue Category:** **UX**
  - **Component Affected:** **Client UI**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Frontend, analytics tooling, privacy considerations
  - **Dependencies:** Decide destination (GitHub issues, Discord, email, in-app form); PII policy
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Decide “feedback sink” (GitHub prefilled issue URL recommended for OSS transparency).
  2. Implement UI entry + include build/version + environment metadata (opt-in).
- **Potential Assignees:**
  - **wtfsayo** (frontend)
  - **borisudovicic** (UX spec)

---

### 11) Update Brandkit on GitHub
- **Issue Title & ID:** Update the Brandkit on GitHub — **#6091**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Low → Medium** (partners/builders need assets)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (public-facing consistency; important for January PR ramp)
- **Technical Classification:**
  - **Issue Category:** **Documentation**
  - **Component Affected:** **Repo documentation/marketing assets**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Branding/content, repo maintenance
  - **Dependencies:** Updated logos/usage guidelines; ensure correct licensing
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add `/brand` folder or link to canonical brandkit repo/page; include usage guidelines and SVG/PNG assets.
  2. Ensure references are updated across README + website.
- **Potential Assignees:**
  - **madjin** (docs/site work)
  - **Kenk / Odilitime** (project comms/launch readiness)

---

## Highest-Priority Focus (Top 5–10 to Address Immediately)
1. **P0:** **#6211** Tangem wallet migration blockage + compromised support channel risk (trust & safety).
2. **P0:** **DISC-2025-12-22-SEC-01** n8n CVE-10 RCE exposure assessment (infra security).
3. **P1:** **#5930** Streaming + state management correctness (core UX reliability).
4. **P1:** **DISC-2025-12-23-CLI-01** CLI install failures (blocks onboarding during Cloud beta).
5. **P1:** **DISC-2025-12-21-CLI-02** CLI/template disk bloat (~17GB) (severe DX/ops issue).
6. **P1:** **DISC-2025-12-23-CORE-01** Standardize `Elizaos.handleMessage` across plugins (ecosystem stability).
7. **P1:** **PR #6216** Cloud integration large PR review (strategic launch dependency; must be hardened).
8. **P2:** **DISC-2025-12-22-STARKNET-01** Starknet BigInt parsing bug (important for Web3 plugin credibility).
9. **P2:** **#6278** Chat renaming (useful UX; schedule after stability/onboarding).
10. **P3:** **#6280 / #6091** Feedback button + brandkit refresh (good for January ramp, low risk).

---

## Patterns / Themes Indicating Deeper Architectural Problems
- **Message handling fragmentation:** Ongoing need to standardize `handleMessage` across plugins + streaming/state issues suggests the **messaging contract is still evolving** and inconsistently implemented.
- **Onboarding fragility under rapid iteration:** CLI install issues + huge template artifacts point to **insufficient release hygiene** for the “first hour” developer experience.
- **Security/comms as part of the product:** Wallet migration + impersonation concerns show that **support-channel integrity and verified workflows** are now part of elizaOS’s operational security boundary.
- **Large, high-coupling PRs:** Cloud integration work landing as very large diffs increases regression risk and slows reviews, especially amid ongoing architectural shifts (auth, data isolation, messaging).

---

## Recommendations: Process Improvements to Prevent Recurrence
1. **Create “Intake-to-Issue” discipline for Discord reports:** any actionable bug (CLI install, Starknet parse, disk bloat) gets a GitHub issue within 24 hours with required diagnostics.
2. **Add DX guardrails in CI:**
   - Template/package size budget checks
   - Fresh-environment install smoke tests (mac/win/linux)
   - Minimal “create agent” e2e test for CLI + Cloud path
3. **Messaging contract governance:**
   - Publish a versioned messaging spec (types + invariants)
   - Add plugin conformance tests and require passing for registry inclusion
4. **Security operations basics for launch ramp:**
   - Public, pinned “official links + staff verification” doc
   - Security advisory workflow for third-party CVEs and infra exposure checks
5. **PR sizing and reviewability:** enforce “split PR” guidance for >~1k LOC feature PRs; require explicit rollout plan + feature flags for Cloud-critical changes.