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

### 1) Potential compromise / phishing flow on ElizaOS token migration site (wallet-drain reports) — ID: DISCORD-SEC-2025-12-15-01
- **Current Status:** Reported in Discord; team acknowledged “We’re looking at it.” No public RCA or confirmation yet.
- **Impact Assessment:**
  - **User Impact:** **Critical** (potential direct fund loss for any user attempting migration)
  - **Functional Impact:** **Yes** (blocks safe token migration; users must be told to stop)
  - **Brand Impact:** **High** (security incident perception + trust erosion)
- **Technical Classification:**
  - **Category:** Security
  - **Component Affected:** Migration Web App / Wallet-connection flow (external to core repo but core ecosystem-critical)
  - **Complexity:** **Complex solution** (incident response + verification + hardening + comms)
- **Resource Requirements:**
  - **Required Expertise:** Web security, wallet UX/security, infra access/logging, incident response, domain/DNS verification
  - **Dependencies:** Access to hosting/CDN logs; confirmation of official domain + build provenance; potential third-party wallet connector libs
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediate freeze:** Put the migration site into maintenance mode (or prominent red banner) until verified safe; pin warning in Discord/Twitter/X.
  2. **Verify authenticity:** Confirm DNS, TLS certs, build pipeline integrity, hosting account security (2FA, access logs).
  3. **Reproduce claim:** Capture user flow/screenshots/tx prompts; identify whether approvals request “valuable tokens” unexpectedly.
  4. **On-chain analysis:** Identify reported victim tx signatures; determine destination wallets; publish known-drainer addresses.
  5. **Rotate secrets:** Rotate any API keys, deployment tokens, CI secrets; invalidate sessions.
  6. **Hardening:** Add allowlist for contract interactions; reduce wallet permissions; add “human readable tx” verification; implement content integrity (SRI), signed deployments.
  7. **Public incident update cadence:** Provide time-boxed updates even if incomplete (e.g., every 4 hours).
- **Potential Assignees:**
  - **Odilitime** (acknowledged investigation; likely ecosystem coordination)
  - **satsbased** (moderation + scam response)
  - **Forrest Jackson** (reporter; gather forensic details)
  - Add security-focused reviewer: **standujar** (security mindset; JWT work) + infra owner (whoever manages migration hosting)

---

### 2) JWT authentication & user management PR needs security review before merge — ID: PR-6200
- **Current Status:** Open PR (`feat(auth): implement JWT authentication and user management`) not merged.
- **Impact Assessment:**
  - **User Impact:** **High** (affects all multi-tenant / data-isolation deployments once enabled)
  - **Functional Impact:** **Partial** (feature-flagged via `ENABLE_DATA_ISOLATION=true`, but future default risk)
  - **Brand Impact:** **High** (auth bugs become security incidents)
- **Technical Classification:**
  - **Category:** Security / Feature
  - **Component Affected:** Server API auth middleware, Socket.IO auth, entity derivation
  - **Complexity:** **Architectural change** (auth boundary + tenancy model)
- **Resource Requirements:**
  - **Required Expertise:** App security, JWT/JWKS, multi-tenant design, API middleware, threat modeling
  - **Dependencies:** Clarity on entity model + RLS strategy (ties to data isolation / plugin-sql RLS work)
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Perform **threat model review**: issuer spoofing, algorithm confusion, JWKS caching, key rotation, replay, socket auth parity.
  2. Add **security test cases**: invalid issuer, kid mismatch, expired tokens, none-alg rejection, audience/issuer enforcement.
  3. Confirm **migration story** from `X-Entity-Id` legacy mode; document safe defaults.
  4. Validate **entityId derivation** from `sub` for providers with non-UUID subs (stringToUuid collisions/consistency).
  5. Ensure **rate limits / lockouts** on `/api/auth/*` endpoints when in secret mode.
- **Potential Assignees:**
  - **standujar** (author)
  - Reviewers: **ChristopherTrimboli** (server), **0xbbjoker** (review capacity), security-minded core maintainer

---

### 3) Twitter replies ingestion causing DB foreign key constraint failures — ID: DISCORD-BUG-2025-12-15-01
- **Current Status:** Reported; “latest codebase has SQL fixes” but version/verification unclear.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (affects users running Twitter/X ingestion and reply handling)
  - **Functional Impact:** **Yes** for that integration path (pipelines fail; data loss / stuck jobs)
  - **Brand Impact:** **Medium** (runtime instability + “DB errors” perception)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Plugin-SQL schema/migrations; message/reply persistence; ingestion pipeline
  - **Complexity:** **Moderate effort** (root-cause + migration/backfill + tests)
- **Resource Requirements:**
  - **Required Expertise:** SQL schema design, drizzle/postgres constraints, plugin-sql internals, ingestion ordering/idempotency
  - **Dependencies:** Identifying which “SQL fixes” (likely recent plugin-sql migration work) and ensuring release version availability
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Pin down the **exact failing constraint** and minimal reproduction (sample tweet thread with replies).
  2. Confirm whether fix is in **PR #6215 / #6202** (plugin-sql migration/RLS/organization) and which released version contains it.
  3. Add **integration test**: out-of-order inserts (reply before parent), retries, idempotent upserts.
  4. Provide **operational guidance**: how to recover (re-run ingestion, backfill parents first, or temporary constraint deferral).
- **Potential Assignees:**
  - **lalalune** (plugin-sql heavy changes recently)
  - **ChristopherTrimboli** (server/db integration)
  - **Redvoid** (Discord context; can confirm fix location)

---

### 4) Large Cloud integration PR requires controlled review & rollout plan — ID: PR-6216
- **Current Status:** Open PR (~10k LOC additions) integrating Eliza Cloud plugin + CLI + starter projects.
- **Impact Assessment:**
  - **User Impact:** **High** (CLI default path + onboarding; affects many new users)
  - **Functional Impact:** **Partial** (new default flows; risk of breaking create/deploy/publish)
  - **Brand Impact:** **High** (onboarding reliability strongly shapes perception)
- **Technical Classification:**
  - **Category:** Feature / Reliability
  - **Component Affected:** CLI, Cloud plugin integration, starter templates, auth/login provisioning flow
  - **Complexity:** **Architectural change** (cross-cutting onboarding + provisioning)
- **Resource Requirements:**
  - **Required Expertise:** CLI architecture, cloud provisioning, API client, auth flows, release engineering
  - **Dependencies:** Stable auth story (ties to PR-6200), docs readiness, e2e tests in CI
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Break review into **smaller logical chunks** (CLI login/provisioning, templates, cloud db/storage).
  2. Require **demo evidence** (screen recording) for core flows: `create → dev → deploy → publish`.
  3. Add/verify **e2e tests** for “no account”, “existing account”, “API key rotation”, and offline/timeout cases.
  4. Plan **feature flag / staged rollout**: keep non-cloud providers easily selectable; document rollback.
- **Potential Assignees:**
  - **lalalune** (author)
  - Reviewers: **ChristopherTrimboli**, **wtfsayo** (CLI/tooling familiarity), release maintainer

---

### 5) Token migration delays for Bithumb (CEX-controlled) causing user frustration + price/FUD — ID: DISCORD-MIG-2025-12-15-01
- **Current Status:** Ongoing; community explains “exchange is responsible,” but users request updates.
- **Impact Assessment:**
  - **User Impact:** **High** (Korean holders on Bithumb unable to complete migration)
  - **Functional Impact:** **Partial** (blocks access to migrated token utility for that segment)
  - **Brand Impact:** **High** (trust + communication; perceived project failure even if external)
- **Technical Classification:**
  - **Category:** UX / Documentation (plus Ecosystem Ops)
  - **Component Affected:** Migration communications + support tooling (not core runtime)
  - **Complexity:** **Moderate effort** (coordination + clear status + support scripts)
- **Resource Requirements:**
  - **Required Expertise:** Ecosystem operations, exchange liaison, community support, multilingual comms
  - **Dependencies:** Exchange timelines; official statements; support escalation path
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **single canonical status page/post**: what users can/can’t do, who is responsible, expected next check-in.
  2. Provide **Korean-language FAQ** + support instructions (what to ask Bithumb; evidence to provide).
  3. Establish **support intake** for stuck users (wallet addresses, proof of holdings on exchange, timestamps).
  4. Coordinate with Bithumb for an **ETA statement** (even if non-binding).
- **Potential Assignees:**
  - **Omid Sa** (already answering responsibility questions)
  - **satsbased** (community ops)
  - A designated **exchange liaison** from core team (owner not identified in data)

---

### 6) “TEXT_LARGE” error even for minimal prompts due to missing inference plugin / confusing setup — ID: DISCORD-UX-2025-12-13-01
- **Current Status:** Reported; community suspects OpenAI (or other AI provider) plugin not registered; suggested `elizaos update`.
- **Impact Assessment:**
  - **User Impact:** **Medium** (new users/testing; blocks first-run success)
  - **Functional Impact:** **Yes** (core chat/inference fails when misconfigured)
  - **Brand Impact:** **Medium** (feels “broken” on hello-world)
- **Technical Classification:**
  - **Category:** UX / Bug (error handling)
  - **Component Affected:** Core runtime validation, plugin system registration, CLI scaffolding
  - **Complexity:** **Simple fix → Moderate effort** (better detection + message + docs + CLI guardrails)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime, plugin registration flow, CLI scaffolding, error UX
  - **Dependencies:** Default provider selection changes (Cloud default in CLI) may reduce incidence, but runtime should still validate
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2** (promote to P1 if support volume spikes)
- **Specific Actionable Next Steps:**
  1. Add runtime preflight check: if no inference provider loaded, throw **actionable error** (“No AI provider plugin configured; install X or select Y”).
  2. In `elizaos create`, ensure **at least one provider** is configured and API key prompts are explicit.
  3. Add docs snippet: “Minimal working setup” + common failure signatures (`TEXT_LARGE`).
- **Potential Assignees:**
  - **wtfsayo** (community support; likely to implement UX/docs quickly)
  - **lalalune** (CLI/provider selection)
  - **ChristopherTrimboli** (core/runtime validation)

---

### 7) Hardware wallet migration confusion (tokens not visible when connecting Ledger) — ID: DISCORD-DOC-2025-12-14-01
- **Current Status:** Workaround shared: connect Ledger through a Solana-compatible browser wallet (Phantom/Solflare/Rabby/etc).
- **Impact Assessment:**
  - **User Impact:** **Medium** (subset using Ledger/hardware wallets)
  - **Functional Impact:** **Partial** (migration possible but unclear; high support burden)
  - **Brand Impact:** **Medium** (migration UX friction)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component Affected:** Migration site wallet connection UX; docs
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Docs, wallet UX, support
  - **Dependencies:** Migration site flow + supported wallet connectors list
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a **Migration → Hardware Wallets** doc with step-by-step and screenshots.
  2. Add a migration-site **inline hint**: “Using Ledger? Connect via Phantom/Solflare first.”
  3. List **supported wallets** and known troubleshooting steps (token not showing, derivation paths, network selection).
- **Potential Assignees:**
  - **DorianD** (provided working method; can validate docs)
  - **borisudovicic** (docs track record)
  - Web/migration maintainer

---

### 8) Add/clarify “connectors” strategy for ElizaOS integrations — ID: DISCORD-FEAT-2025-12-15-01
- **Current Status:** Mentioned with a GitHub link in Discord; no scoped issue in provided data.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (developers building integrations)
  - **Functional Impact:** **No** (not blocking core, but blocks ecosystem expansion)
  - **Brand Impact:** **Low**
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component Affected:** Plugin system / integrations layer
  - **Complexity:** **Complex solution** (depends on connector definition: MCP, n8n, A2A, etc.)
- **Resource Requirements:**
  - **Required Expertise:** Integration architecture, plugin interfaces, DX
  - **Dependencies:** Cloud platform direction; MCP/A2A services roadmap
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a scoped GitHub issue: define what “connector” means (protocols, auth, deployment target).
  2. Prioritize top 3 connectors by demand (e.g., n8n, Slack/Discord, database/Neon).
  3. Publish a minimal connector template + interface contract.
- **Potential Assignees:**
  - **lalalune** (cloud + starters)
  - **shaw** (platform direction)
  - Integration-focused contributor (TBD)

---

### 9) PR quality gate proposal: require screenshots/videos and stronger production verification — ID: DISCORD-PROC-2025-12-15-01
- **Current Status:** Proposed in core-devs channel; rationale: PRs pass review but fail in production.
- **Impact Assessment:**
  - **User Impact:** **Medium** (reduces regressions over time)
  - **Functional Impact:** **Partial** (process improvement; indirectly improves stability)
  - **Brand Impact:** **Medium** (higher reliability, fewer broken releases)
- **Technical Classification:**
  - **Category:** Documentation / Process (Quality)
  - **Component Affected:** Repo contribution workflow, CI expectations
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Maintainer workflow, GitHub templates/actions, release process
  - **Dependencies:** Agreement from maintainers; update PR template/CI checks
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Update PR template: require **Testing steps** always; require **screenshots/video** for UI/UX changes.
  2. Add a lightweight CI check: if files under `packages/client` changed, require “Screenshots” section non-empty.
  3. Define “production verification” checklist for high-risk PRs (cloud/auth/db).
- **Potential Assignees:**
  - **cjft** (proposer)
  - **ChristopherTrimboli** (review process)
  - Any maintainer owning GitHub workflows

---

## Top 5–10 Highest-Priority Items (Immediate Focus)
1. **P0:** Potential compromise/phishing on migration site (DISCORD-SEC-2025-12-15-01)
2. **P1:** JWT auth PR security review and hardening before merge (PR-6200)
3. **P1:** Twitter replies causing DB foreign key failures; verify fix and ship/test it (DISCORD-BUG-2025-12-15-01)
4. **P1:** Bithumb migration delays—publish status + Korean FAQ + support intake (DISCORD-MIG-2025-12-15-01)
5. **P1:** Large Cloud integration PR—break down, add e2e coverage, stage rollout (PR-6216)
6. **P2:** TEXT_LARGE / missing provider plugin—improve runtime validation and onboarding docs (DISCORD-UX-2025-12-13-01)
7. **P2:** Hardware wallet migration visibility docs + site hints (DISCORD-DOC-2025-12-14-01)
8. **P2:** PR quality gates for demos/tests to prevent “works in review, fails in prod” (DISCORD-PROC-2025-12-15-01)
9. **P3:** Define and prioritize “connectors” roadmap (DISCORD-FEAT-2025-12-15-01)

---

## Cross-Issue Patterns / Themes
- **Security & trust are ecosystem-wide, not just core-runtime:** migration site safety and auth changes are high-risk and highly visible.
- **Data layer fragility under real-world ordering:** foreign key failures (Twitter replies) indicate ingestion ordering/idempotency gaps and insufficient integration tests for out-of-order events.
- **Large, cross-cutting PRs increase regression risk:** Cloud integration (~10k LOC) and auth changes touch many surfaces; without staged rollout + strict review signals, production issues are likely.
- **Onboarding friction repeats:** missing AI provider plugin and hardware wallet confusion show that “first successful run” still isn’t reliably guided by the product.

---

## Process Improvement Recommendations
1. **Security incident playbook + rapid comms protocol:** predefined steps (freeze, verify domain/build, publish known-bad addresses, update cadence).
2. **Mandatory “risk-based” PR requirements:** for `auth`, `db/migrations`, `cloud onboarding` require (a) threat model / migration plan, (b) e2e test evidence, (c) rollback plan.
3. **Integration test expansion for ingestion + DB constraints:** add fixtures for out-of-order events (replies before parents), retries, and idempotent upserts.
4. **Onboarding guardrails in runtime + CLI:** fail fast with actionable errors when no inference provider configured; add “doctor” command or preflight checks.
5. **Single source of truth for migration support:** status page + multilingual FAQs; reduce Discord rumor amplification by linking one canonical update location.