## Issue Triage — 2026-01-31

### 1) **[SECURITY] Active support-ticket/DM impersonation scams leading to wallet theft**
- **Issue Title & ID:** “Support ticket phishing / fake ‘support team’ DMs causing wallet drain” (Discord report; **no GH issue yet**)
- **Current Status:** Ongoing in Discord; multiple reports (coolart hacked; FeRhaT_@ receiving fake friend requests)
- **Impact Assessment:**
  - **User Impact:** **Critical** (funds stolen; likely affects many users during migration)
  - **Functional Impact:** **No** (not a runtime bug, but blocks safe user participation)
  - **Brand Impact:** **High** (trust and reputation damage; “project is unsafe” narrative)
- **Technical Classification:**
  - **Issue Category:** **Security / UX**
  - **Component Affected:** Community Support, Ticketing, Migration Support Surface Area
  - **Complexity:** **Moderate effort** (process + automation; not just a code patch)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation tooling, security comms, basic web/automation (bot), support process design
  - **Dependencies:** Verified support workflow; official domain/link hardening; Discord bot permissions
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Open a GH issue** in `elizaos/eliza` (Security/Operations label) to track mitigations + status updates.
  2. Add **forced friction** in ticket flow: auto-post message in ticket channel and in every new ticket thread: “Support will never DM first” + “No screen-share / no seed phrase” + official domains list.
  3. Add a **Discord bot auto-moderation rule**: detect phrases like “support team”, “ticket support”, “verify wallet”, “rectify migration”, and auto-warn + remove + report to mods.
  4. Publish a short **Security Advisory** in docs + pinned Discord post: how to verify staff, how to verify URLs, recommended wallet hygiene during migration.
  5. Add **link hardening**: a single canonical “Support” page on `docs.elizaos.ai` listing official URLs and staff verification instructions; moderators only link that page.
- **Potential Assignees:** `jin (madjin)` (process + automation), `sam` (docs/support UX surface), moderators (`Odilitime`, `Zhuangzi`) for policy + pins

---

### 2) **[MIGRATION] Migration portal returns “0 eligible” for wallets holding tokens since 2024 (snapshot/eligibility mismatch)**
- **Issue Title & ID:** “Migration portal shows 0 eligible despite holding since late 2024” (Discord report; related historical GH: `elizaos/eliza#6369` **closed**)
- **Current Status:** Unresolved for multiple users (Arkanac, TonKLa); workaround guidance exists but not solving all cases
- **Impact Assessment:**
  - **User Impact:** **High** (blocks migration for legitimate holders; affects many during migration window)
  - **Functional Impact:** **Yes** (core token migration workflow blocked)
  - **Brand Impact:** **High** (perceived as broken/unfair; fuels token distrust)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** Migration Portal / Snapshot Eligibility Backend
  - **Complexity:** **Complex solution** (data pipeline + wallet edge cases: LP, multiple wallets, hardware wallets, Solana/EVM mapping)
- **Resource Requirements:**
  - **Required Expertise:** Snapshot indexing, Solana/EVM address handling, backend API debugging, data reconciliation
  - **Dependencies:** Access to snapshot source of truth; portal backend logs; ability to hotfix eligibility lists
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Open a new GH issue** dedicated to “0 eligible” with a standardized template: chain, wallet type (Phantom/Solflare/Tangem), token location (LP?), purchase date, tx links.
  2. Add portal-side **debug output** (non-sensitive): detected snapshot wallet(s), detected token accounts, snapshot block/time, reason codes for “0 eligible”.
  3. Build an **internal admin reconciliation tool**: query by address → show snapshot balance → show computed eligibility → allow manual override/whitelist with audit log.
  4. Publish “common causes” doc: LP tokens excluded, post-snapshot purchases, wrong wallet connected, wrong chain selected, etc.
- **Potential Assignees:** Backend owner(s) of migration infra (not named in data), `Odilitime` (triage + coordination), `jin` (data tooling), community support for reproduction capture

---

### 3) **[MIGRATION/AVAILABILITY] Migration portal returns HTTP 429 “Too many requests” on page load (pre-wallet connect)**
- **Issue Title & ID:** “migrate.elizafoundation.ai 429 Too Many Requests on page load” (Discord report; **no GH issue yet**)
- **Current Status:** Reported by jaistklaas; appears persistent even after IP reset; unanswered
- **Impact Assessment:**
  - **User Impact:** **High** (blocks migration access entirely for some users)
  - **Functional Impact:** **Yes** (migration portal unusable)
  - **Brand Impact:** **High** (looks like outage/anti-user throttling)
- **Technical Classification:**
  - **Issue Category:** **Performance / Bug**
  - **Component Affected:** Migration Portal Frontend + Edge/CDN + Rate Limiter / RPC usage
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web ops, CDN/WAF configuration, backend rate limiting, RPC provider tuning
  - **Dependencies:** Hosting provider logs, WAF rules, frontend telemetry
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Open GH issue** (repo for portal if public; otherwise `elizaos/eliza` ops issue) capturing timestamps, regions, user agents.
  2. Add **client-side backoff** + avoid burst calls on initial render (debounce eligibility checks until wallet connect).
  3. Inspect WAF/CDN: ensure static assets are not behind aggressive bot rules; whitelist read-only endpoints or raise thresholds.
  4. Add a **status banner** + fallback instructions when 429 occurs (retry interval, alternate endpoint).
- **Potential Assignees:** Web/infra maintainer(s), `sam` (frontend), `jin` (instrumentation)

---

### 4) **[CORE BUG] Eliza v1.7.2 action callbacks execute in reverse order; structured return message omitted**
- **Issue Title & ID:** “Action callback ordering reversed; structured return omitted (v1.7.2)” (Discord report by Victor Creed; **no GH issue yet**)
- **Current Status:** Unresolved; affects custom plugins (plugin-sql, plugin-openai, plugin-bootstrap)
- **Impact Assessment:**
  - **User Impact:** **High** (plugin authors and production bots relying on callback semantics)
  - **Functional Impact:** **Partial** (core actions still run, but output protocol broken)
  - **Brand Impact:** **High** (breaks documented behavior; undermines reliability)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** Core Framework (message service / action execution pipeline)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Typescript core runtime, async flow ordering, message dispatch pipeline
  - **Dependencies:** Repro case; version bisect between 1.7.1 and 1.7.2; tests for ordering
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. **Create GH issue** with exact expected vs actual sequence and minimal repro plugin.
  2. Add a **unit test** asserting callback order + presence of structured return.
  3. Identify regression commit (likely around message service/provider refactors) and patch.
  4. Publish a **changelog note** and recommended workaround (if any) until release.
- **Potential Assignees:** `Odilitime` (core), `wtfsayo` (core/CI), `0xbbjoker` (message-service familiarity)

---

### 5) **[DEV BRANCH REGRESSION] Provider selection fails in one-shot mode on `develop`**
- **Issue Title & ID:** “Develop: provider selection broken in one-shot mode” (core-devs Discord; **no GH issue yet**)
- **Current Status:** Active regression on develop; blocks testing/validation of latest changes
- **Impact Assessment:**
  - **User Impact:** **Medium** (mainly affects contributors / early adopters on develop)
  - **Functional Impact:** **Yes** for develop workflows (one-shot unusable)
  - **Brand Impact:** **Medium** (signals instability; slows v2 progress)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** Model Integration / Provider Router, Message Service
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Provider routing logic, runtime config, test harness for model selection
  - **Dependencies:** Known-good baseline commit; integration test coverage
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Open GH issue with commit range and logs; add “regression” label.
  2. Add an **integration test**: one-shot request must select configured provider/model deterministically.
  3. Patch and backport if it impacts release branches.
- **Potential Assignees:** `Odilitime`, `lalalune` (v2 work), `YuriNachos` (runtime robustness)

---

### 6) **[QUALITY] Missing integration test coverage in monorepo v2.x leading to frequent breakages**
- **Issue Title & ID:** “Monorepo: insufficient integration tests for 2.x; recurring breakages” (core-devs Discord; **no GH issue yet**)
- **Current Status:** Acknowledged systemic problem; Stan developing patterns in plugin-n8n-workflow
- **Impact Assessment:**
  - **User Impact:** **Medium** (end users feel instability indirectly; contributors hit it immediately)
  - **Functional Impact:** **Partial** (doesn’t break one feature; breaks confidence + release cadence)
  - **Brand Impact:** **High** (public perception of “always broken”)
- **Technical Classification:**
  - **Issue Category:** **Performance / Reliability**
  - **Component Affected:** Core Framework + Plugin System + CI
  - **Complexity:** **Architectural change** (test strategy + CI gating)
- **Resource Requirements:**
  - **Required Expertise:** CI design, test architecture, monorepo tooling (turbo/bun), mocking providers
  - **Dependencies:** Decide required “golden paths” to test (create → run agent → plugin actions → provider call)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert Stan’s plugin-n8n-workflow test approach into an **org-wide testing RFC**.
  2. Define a **minimum integration suite** gated in CI: (a) runtime init, (b) one-shot response, (c) multi-step response, (d) plugin load, (e) memory adapter smoke test.
  3. Add “release branch protection”: cannot cut release if integration suite red.
  4. Track flaky tests separately; introduce quarantining rules.
- **Potential Assignees:** `Stan ⚡ (standujar)` (test framework), `wtfsayo` (CI), `Odilitime` (core ownership)

---

### 7) **[PLUGIN/UX] `@elizaos/plugin-web-search` install resolves but runtime cannot find module**
- **Issue Title & ID:** “Cannot find module '@elizaos/plugin-web-search' after install” (Discord; **no GH issue yet**)
- **Current Status:** Workaround suggested (edit package.json / try bun); still a sharp edge for new builders
- **Impact Assessment:**
  - **User Impact:** **Medium** (new plugin users)
  - **Functional Impact:** **Partial** (blocks web-search capability; not core runtime)
  - **Brand Impact:** **Medium** (dependency friction during onboarding)
- **Technical Classification:**
  - **Issue Category:** **Bug / Documentation**
  - **Component Affected:** Plugin System, Packaging/Exports, CLI templates
  - **Complexity:** **Simple fix** (likely exports/entrypoints/docs)
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun module resolution, package.json exports, starter template maintenance
  - **Dependencies:** Reproduce across npm/bun/pnpm; confirm correct import path
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Open GH issue in the plugin repo (or `elizaos/eliza` if bundled) with reproduction steps.
  2. Validate `exports` and `main/module/types` fields; ensure CJS/ESM compatibility.
  3. Update docs: canonical install + import steps; add “bun vs npm” note.
- **Potential Assignees:** `Odilitime` (packaging experience), plugin maintainer(s), `sayonara` (docs)

---

### 8) **[MODEL INTEGRATION] OpenRouter embeddings failing in knowledge plugin for some users**
- **Issue Title & ID:** “Knowledge plugin: OpenRouter embeddings errors; only OpenAI works reliably” (Discord; **no GH issue yet**)
- **Current Status:** Reported by multiple users; v2 plan is to move embeddings fully to plugins
- **Impact Assessment:**
  - **User Impact:** **Medium** (users who need non-OpenAI embeddings)
  - **Functional Impact:** **Partial** (knowledge features degrade; embeddings are foundational for RAG)
  - **Brand Impact:** **Medium** (provider claims vs actual reliability)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** Model Integration (Embeddings), Knowledge Plugin
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Provider API differences, error handling, retries/timeouts, telemetry
  - **Dependencies:** Example failing requests + error payloads; provider keys; rate limits
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Open GH issue with logs (HTTP status, payload shape, model name).
  2. Add provider conformance tests: embeddings request/response schema checks.
  3. Improve fallback behavior (e.g., retry/backoff, clearer error messaging).
  4. Align with v2 direction: ensure the “embeddings-in-plugin” path is production-ready.
- **Potential Assignees:** `jin` (v2 architecture direction), `Odilitime` (runtime/plugins), `0xbbjoker` (data layer familiarity)

---

### 9) **[FEATURE/ARCH] Integrate N8N Workflow Engine as automation layer for “Eliza App”**
- **Issue Title & ID:** `[Plugin] Integrate N8N Workflow Engine` — `elizaos/eliza#6429`
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **High** (unlocks broad automation connectors; major adoption lever)
  - **Functional Impact:** **Partial** (not a bug, but blocks a strategic capability)
  - **Brand Impact:** **High** (shipping automation integration improves perceived completeness)
- **Technical Classification:**
  - **Issue Category:** **Feature Request**
  - **Component Affected:** Plugin System, Eliza App Automation Layer, OAuth/Integrations
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** N8N workflow JSON generation, OAuth flows, multi-tenant storage, secure execution
  - **Dependencies:** Social connection page / auth flow (Discord mentions Sam building connection page; Composio plugin/RFC from Stan may help)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P2** (strategic, but current sprint should focus on migration/security + core regressions)
- **Specific Actionable Next Steps:**
  1. Break into epics: (a) workflow generation, (b) credential management, (c) execution backend, (d) per-tenant storage, (e) node catalog exposure.
  2. Decide first execution mode: hosted `n8n.io` vs self-host; define security boundaries.
  3. Leverage Stan’s Composio work: evaluate whether Composio can standardize auth before N8N execution.
- **Potential Assignees:** `Stan ⚡ (standujar)` (workflow/testing), `sam` (auth UX), `borisudovicic` (PM/acceptance criteria), `lalalune` (v2 architecture alignment)

---

## Top 5–10 Highest Priority Issues to Address Immediately
1. **P0:** Support-ticket/DM impersonation scams causing wallet theft (Discord; open tracking issue needed)
2. **P0:** Migration portal “0 eligible” for legitimate holders (Discord; reopen as active engineering incident)
3. **P0:** Migration portal HTTP 429 on page load (Discord; infra/availability incident)
4. **P1:** Eliza v1.7.2 callback ordering regression + missing structured return (Discord; core behavior break)
5. **P1:** Develop branch one-shot provider selection broken (Discord; blocks contributor velocity)
6. **P1:** Monorepo v2.x integration-test deficit causing repeated breakages (systemic reliability)
7. **P2:** plugin-web-search module resolution install/runtime failure (onboarding friction)
8. **P2:** OpenRouter embeddings failing in knowledge plugin (provider reliability gap)
9. **P2:** N8N workflow engine integration (`elizaos/eliza#6429`) (strategic feature; queue once P0/P1 stabilized)

---

## Patterns / Themes Indicating Deeper Architectural Problems
- **Release quality gaps / insufficient integration testing:** Multiple regressions reported (develop provider selection, v1.7.2 callback ordering), plus explicit acknowledgment that v2 needs stronger integration tests.
- **Provider and packaging surface area is brittle:** Embeddings inconsistencies (OpenRouter), plugin install/module resolution failures, and provider routing regressions all point to weak conformance testing and unclear compatibility guarantees.
- **High-stakes user workflows lack “operational hardening”:** Token migration (eligibility + throttling) plus active scams show that the project needs production-grade incident response patterns, not just code fixes.

---

## Recommendations for Process Improvements
1. **Create an “Incident” playbook** (migration/security): single owner on rotation, defined severity levels, public status updates, and postmortems.
2. **Add CI-gated integration suites** covering golden paths (init, one-shot, multi-step, plugin load, embeddings, basic knowledge query).
3. **Standardize provider conformance tests** (text + embeddings): contract tests per provider to catch schema/rate-limit/timeout differences early.
4. **Improve “first-time user” reliability checks**: a CLI doctor command (`elizaos doctor`) that validates plugin resolution, provider keys, and required exports before runtime start.
5. **Security-by-default community UX**: canonical support page, automated scam phrase detection, and mandatory anti-scam banners in every ticket/migration help surface.