## Issue Triage — 2025-12-18

### 1) Potential security breach on ElizaOS migration site
- **Issue Title & ID:** Investigate potential security breach on ElizaOS migration site — **DISC-SEC-2025-12-15-MIGRATIONSITE**
- **Current Status:** **Unconfirmed / Under investigation** (reported on Discord; no linked GitHub issue in provided data)
- **Impact Assessment:**
  - **User Impact:** **Critical** (possible fund theft / user credential compromise)
  - **Functional Impact:** **Partial** (blocks safe migration usage; forces users to avoid portal)
  - **Brand Impact:** **High** (trust damage, “rug/hack” narratives)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Migration Web App / Token Migration Infrastructure**
  - **Complexity:** **Complex solution** (forensics + remediation + comms)
- **Resource Requirements:**
  - **Required Expertise:** Web security incident response, infra/log analysis, wallet/contract interaction verification, DNS/CDN/WAF hardening
  - **Dependencies:** Access to hosting/CDN logs, deployment pipeline, domain/DNS records, wallet/contract addresses used by the portal
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediately** confirm the canonical migration URL and **freeze deployments** (lock CI/CD, revoke tokens, rotate secrets).
  2. Pull **server/CDN logs**, compare hashes of deployed assets, and verify DNS records for hijack indicators.
  3. Validate on-chain: confirm the portal is interacting with the **intended contracts/programs** only; publish verified addresses.
  4. Add prominent **in-app and docs banner**: “How to verify you’re on the real portal” (domain, TLS cert, contract addresses).
  5. If compromise confirmed: publish a **post-mortem** (timeline, scope, mitigations) and open a GitHub security advisory.
- **Potential Assignees:**
  - **Forrest Jackson** (reported item; coordinate response)
  - **Stan (standujar)** (server/security implementation support)
  - **akshaydeep** (migration flow verification per Discord action item)
  - If available: infra maintainer for hosting/CDN/DNS ownership


### 2) Discord support impersonation/scam risk around migration (users being directed to send tokens)
- **Issue Title & ID:** Discord support compromised by impersonators directing manual token sends — **DISC-SEC-2025-12-07-IMPERSONATION**
- **Current Status:** **Ongoing** (users explicitly report impersonators; request GitHub-only support path)
- **Impact Assessment:**
  - **User Impact:** **High/Critical** (scams → direct fund loss)
  - **Functional Impact:** **No** (product runs, but support channel unsafe)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **Security / UX**
  - **Component Affected:** **Community Support / Discord Ops**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation, community ops, security comms
  - **Dependencies:** Discord admin perms, bot/automation tooling
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Lock down support flows: disable DMs from non-staff in ticket channels; require **staff verification** (roles + verified messages).
  2. Publish a single “**Official support policy**”: team will **never** ask users to send tokens; only use official portal/GitHub.
  3. Add **automated scam detection** and rapid-ban workflow; pin warnings in all migration-related channels.
  4. Create a GitHub **Security & Migration Support** discussion thread for verifiable responses.
- **Potential Assignees:**
  - **satsbased** (identified/banned scammer per Discord)
  - **Omid Sa / Kenk** (channel governance)
  - **Core team ops owner** (whoever controls Discord admin)


### 3) Snapshot eligibility + Tangem wallet connection not supported for migration
- **Issue Title & ID:** Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported — **GitHub Issue #6211**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **High** (blocks a segment of holders; escalated by “support unsafe” context)
  - **Functional Impact:** **Partial** (migration flow fails for specific wallet types)
  - **Brand Impact:** **High** (seen as broken/biased migration)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX / Documentation**
  - **Component Affected:** **Migration Portal (WalletConnect integration)**
  - **Complexity:** **Architectural change** (if non-exportable wallets must be supported)
- **Resource Requirements:**
  - **Required Expertise:** WalletConnect integration, backend eligibility proofs, security review for manual claims
  - **Dependencies:** Snapshot dataset integrity; policy decision for manual/alternative claim path
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Clarify eligibility rules: are Tangem-held tokens eligible if wallet held at snapshot? (publish authoritative answer).
  2. Provide an official alternative flow:
     - Add Tangem support if feasible, **or**
     - Implement a secure **manual claim** process (signed message + proof of control + snapshot verification).
  3. Add migration portal UI copy explaining why “0 eligible” may occur and what to do next.
  4. Link to a verified support channel (GitHub) to reduce Discord scam exposure.
- **Potential Assignees:**
  - **akshaydeep** (migration functionality verification)
  - **Stan (standujar)** (backend/security design)
  - **Core web/migration maintainer** (not named in provided data)


### 4) Exchange handling discrepancies for AI16Z → ELIZAOS swap (Bithumb vs Kraken) causing major confusion
- **Issue Title & ID:** Exchange-specific swap handling unclear; evidence request re: Bithumb snapshot timing — **DISC-DOC-2025-12-17-EXCHANGE-MIGRATION**
- **Current Status:** **Ongoing**
- **Impact Assessment:**
  - **User Impact:** **High** (many exchange-based holders, especially KR community)
  - **Functional Impact:** **No** (core framework unaffected) / **Partial** for token ecosystem usability
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **Public docs + comms**
  - **Complexity:** **Simple fix** (docs), **Moderate** (coordination with exchanges)
- **Resource Requirements:**
  - **Required Expertise:** Product comms, exchange liaison, documentation
  - **Dependencies:** Confirmed snapshot notice timeline; exchange statements; internal comms logs
  - **Estimated Effort (1–5):** **2–3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a dedicated doc: **“Migration on Exchanges vs Self-Custody”** with per-exchange known behavior (Kraken/Bithumb).
  2. Provide “what if I sold after snapshot?” and “what if exchange delayed?” decision tree.
  3. If possible, share **verifiable evidence** of outreach timelines to exchanges (or state constraints transparently).
  4. Pin this doc in Discord and on the migration portal.
- **Potential Assignees:**
  - **Odilitime** (already coordinating migration-related items in Discord)
  - **hildi / Serikiki** (context holders from Discord explanations)
  - **Project lead** for external comms approval


### 5) Cloud streaming: Actions UI renders full text instead of streaming
- **Issue Title & ID:** Actions UI streaming renders all-at-once (cloud/monorepo mismatch) — **DISC-BUG-2025-12-16-ACTIONS-STREAMING**
- **Current Status:** **Known issue** (streaming works for simple messages/actions; Actions UI display still incorrect)
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (affects many demos; degrades perceived responsiveness)
  - **Functional Impact:** **Partial** (feature works but UX broken)
  - **Brand Impact:** **Medium/High** (streaming is a core “quality” signal)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX / Performance**
  - **Component Affected:** **Client UI (Actions view) + streaming transport**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Frontend React, streaming protocol handling (SSE/ws), state management
  - **Dependencies:** Streaming PRs in **eliza-cloud-v2** + **eliza monorepo** (links referenced by Stan, not included here)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce with a minimal Actions payload; verify token-by-token events are emitted and received.
  2. Fix UI rendering pipeline to append chunks (avoid final overwrite); add regression test for incremental updates.
  3. Align streaming event schema between cloud and monorepo.
- **Potential Assignees:**
  - **Stan (standujar)** (owns/understands streaming PRs)
  - **wtfsayo** (client-side UX fixes experience)


### 6) PostgreSQL local setup: persistent migrations/permissions issues blocking onboarding
- **Issue Title & ID:** Local PostgreSQL migration/permission failures during setup — **DISC-BUG-2025-12-16-POSTGRES-MIGRATIONS**
- **Current Status:** **Ongoing troubleshooting** (moved to DMs)
- **Impact Assessment:**
  - **User Impact:** **Medium** (hits new devs; high friction)
  - **Functional Impact:** **Partial** (blocks local development for affected users)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **Bug / Documentation**
  - **Component Affected:** **plugin-sql + local dev tooling**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Postgres, Drizzle migrations, local dev DX
  - **Dependencies:** Version alignment (drizzle deps), migration scripts, docs
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Convert DM troubleshooting into a **public GitHub issue** with logs, versions, OS, and minimal reproduction.
  2. Add a “known-good” docker-compose for Postgres + required roles/permissions; include a one-command reset.
  3. Add CI coverage for migrations against Postgres (not only PGLite).
- **Potential Assignees:**
  - **Stan (standujar)** (already troubleshooting)
  - **standujar / plugin-sql maintainers** (migration expertise)
  - **lalalune** (DX improvements across tooling)


### 7) Twitter replies causing DB foreign key constraint failures (long-standing)
- **Issue Title & ID:** Twitter plugin DB failures due to foreign key constraints on replies — **GitHub Issue #39**
- **Current Status:** **OPEN / Persistent** (noted as still active in monthly report; Discord mentions “SQL fixes”)
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (Twitter is a major deployment target for agents)
  - **Functional Impact:** **Yes (for Twitter reply workflows)** / **Partial** overall
  - **Brand Impact:** **High** (public-facing agents failing)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin System (Twitter) + SQL schema/integrity**
  - **Complexity:** **Complex solution** (data model + ordering + idempotency)
- **Resource Requirements:**
  - **Required Expertise:** DB schema design, message ordering, plugin event ingestion, integration testing
  - **Dependencies:** Confirm whether latest plugin-sql migration fixes cover it; may require Twitter plugin changes
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Validate whether the “latest SQL fixes” actually resolve the constraint failure with a deterministic reproduction.
  2. Add integration tests simulating reply chains arriving out of order; enforce parent creation or deferred constraints.
  3. Decide on canonical behavior when parent tweet is missing (create placeholder, retry queue, or soft-link).
- **Potential Assignees:**
  - **plugin-sql maintainers** (schema/constraints)
  - **Stan (standujar)** (server/data pipeline)
  - **wtfsayo** (recent plugin-sql migrations work)


### 8) Discord plugin PR is too large/old (66 commits, open ~3 weeks) and risks destabilizing messaging integration
- **Issue Title & ID:** Review/merge large Discord plugin PR — **elizaos-plugins/plugin-discord PR #30**
- **Current Status:** **Open / Pending review** (Stan offered review; 24h wait)
- **Impact Assessment:**
  - **User Impact:** **High** (Discord is a primary deployment surface)
  - **Functional Impact:** **Partial** (current plugin works but improvements/compat fixes blocked)
  - **Brand Impact:** **Medium** (slow merges + big-bang changes reduce confidence)
- **Technical Classification:**
  - **Issue Category:** **Bug / Refactor (risk management)**
  - **Component Affected:** **Plugin System (Discord)**
  - **Complexity:** **Complex solution** (review + potential split)
- **Resource Requirements:**
  - **Required Expertise:** Discord API, plugin architecture, messaging API changes, regression testing
  - **Dependencies:** Any concurrent messaging API refactors; release timing
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Require a short **test plan** + “before/after” behavior checklist; add screenshots/video if UI behavior changed.
  2. If review surface is too large, **split** into smaller PRs (mechanical refactor vs behavior change).
  3. Run canary deploy in one internal Discord server before broad release.
- **Potential Assignees:**
  - **Stan (standujar)** (review)
  - **Odilitime** (driving merge; plugin familiarity)
  - **0xbbjoker** (review bandwidth; plugin ecosystem experience)


### 9) JWT authentication PR needs rebase and integration planning (data isolation mode)
- **Issue Title & ID:** Implement JWT authentication and user management — **elizaos/eliza PR #6200**
- **Current Status:** **Open**; Discord notes “rebase authentication PR”
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (enables multi-tenant + secure deployments)
  - **Functional Impact:** **Partial** (new capability; could block enterprise/hosted use cases)
  - **Brand Impact:** **Medium** (security posture improvement)
- **Technical Classification:**
  - **Issue Category:** **Security / Feature**
  - **Component Affected:** **Server API + Socket.IO auth middleware**
  - **Complexity:** **Complex solution** (needs careful rollout + docs)
- **Resource Requirements:**
  - **Required Expertise:** Auth/JWT, middleware, Socket.IO, deployment config, docs
  - **Dependencies:** Data isolation flag behavior, client UI compatibility, documentation updates
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2** (promote to P1 if enterprise/customer launch is imminent)
- **Specific Actionable Next Steps:**
  1. Rebase onto current main; resolve conflicts with any server refactors.
  2. Add migration notes: default mode behavior, headers deprecation timeline, environment variable matrix.
  3. Security review for verifier priority and internal service bypass secret handling.
- **Potential Assignees:**
  - **Stan (standujar)** (author/owner)
  - **ChristopherTrimboli** (review/testing discipline)
  - **Core server maintainers**


### 10) Cloud integration PR is very large and needs scope control before merge
- **Issue Title & ID:** Eliza Cloud Integration… create → deploy → publish/monetize flow — **elizaos/eliza PR #6216**
- **Current Status:** **Open**
- **Impact Assessment:**
  - **User Impact:** **High** (Cloud default path in CLI; onboarding funnel)
  - **Functional Impact:** **Partial** (improves “time to first agent” but risk of regressions)
  - **Brand Impact:** **High** (Cloud is flagship)
- **Technical Classification:**
  - **Issue Category:** **Feature / UX**
  - **Component Affected:** **CLI + Cloud Integration + starter projects**
  - **Complexity:** **Architectural change** (end-to-end flow + provisioning)
- **Resource Requirements:**
  - **Required Expertise:** CLI, cloud API, auth/login flows, deployment automation, DX
  - **Dependencies:** Cloud streaming work, auth strategy, docs readiness
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P2** (keep moving, but do not rush without staged rollout)
- **Specific Actionable Next Steps:**
  1. Break into mergeable slices: provisioning/auth, storage/db wiring, starter templates, monetize/publish.
  2. Add end-to-end acceptance tests for create/deploy on a staging cloud account.
  3. Produce minimal docs for the “happy path” and common failure modes.
- **Potential Assignees:**
  - **lalalune** (author/owner)
  - **ChristopherTrimboli** (CLI/testing)
  - **Stan (standujar)** (server/cloud integration review)


---

## Immediate Focus Summary (Top Priority: address now)
1. **P0:** Investigate/contain **migration site security breach** (DISC-SEC-2025-12-15-MIGRATIONSITE).
2. **P0:** Stop **Discord impersonation scams** and harden official support process (DISC-SEC-2025-12-07-IMPERSONATION).
3. **P1:** Resolve/define **Tangem wallet + snapshot eligibility** path (GitHub **#6211**).
4. **P1:** Fix **Actions UI streaming** so Cloud demos feel real-time (DISC-BUG-2025-12-16-ACTIONS-STREAMING).
5. **P1:** Unblock social deployment stability: address **Twitter reply FK failures** (GitHub **#39**).
6. **P1:** Reduce risk in core integration surface: review/merge **Discord plugin PR #30** with a safe rollout plan.
7. **P1:** Publish **exchange migration clarity** (Bithumb/Kraken) to stem community confusion (DISC-DOC-2025-12-17-EXCHANGE-MIGRATION).
8. **P2:** Convert local **Postgres migration** pain into a reproducible, documented fix (DISC-BUG-2025-12-16-POSTGRES-MIGRATIONS).
9. **P2:** Rebase and plan rollout/docs for **JWT auth PR #6200**.
10. **P2:** De-risk large **Cloud integration PR #6216** by slicing and adding E2E validation.

---

## Patterns / Themes Suggesting Deeper Issues
- **Security + Trust as a product dependency:** Migration tooling and community support are currently part of the “critical path.” Any weakness (portal integrity, Discord scams) becomes existential even if the core framework is healthy.
- **Large, long-lived PRs increasing integration risk:** The Discord plugin PR and Cloud integration PR both show “big-bang” merge risk (review fatigue, hidden regressions, delayed feedback).
- **Streaming and messaging consistency gaps:** Streaming works in some paths but not in Actions UI; Discord/Telegram refactors suggest ongoing messaging API churn that can destabilize plugins.
- **DX friction around databases:** Persistent Postgres migration/permission issues indicate local setup isn’t reliably reproducible, which slows contributor onboarding and increases support load.

---

## Process Recommendations (Prevention)
1. **Security incident playbook + verified comms:**
   - Add a permanent “Security & Official Links” page in docs and pin it in Discord.
   - Establish a standard incident checklist (freeze deploys, rotate secrets, publish verified addresses, status updates cadence).
2. **PR size limits and mandatory “How tested” section enforcement:**
   - Require a minimal test plan + screenshots/video for UX changes (as proposed in Discord).
   - Encourage splitting PRs > ~1k LOC net change into reviewable slices.
3. **Release gating for high-risk surfaces (migration, Discord/Twitter plugins, auth):**
   - Canary deploys + staged rollouts; add smoke tests for migration portal and top plugins.
4. **Turn recurring Discord support issues into GitHub artifacts:**
   - Anything that blocks onboarding/migration should become a tracked issue with reproduction steps and owner assignment.
5. **Database reproducibility improvements:**
   - Provide a single official docker-compose + “reset script”; run CI migrations against both **PGLite** and **Postgres** to catch divergence early.