## Issue Triage — 2026-01-29

### 1) Migration portal not detecting ai16z tokens in Phantom wallets (eligibility/snapshot lookup)
- **Issue Title & ID:** Migration site fails to detect ai16z tokens in Phantom wallet — **DISCORD-2026-01-28-discussion-migration-phantom**
- **Current Status:** Reported by multiple users; no linked fix/PR yet (needs formal GitHub issue + triage owner).
- **Impact Assessment:**
  - **User Impact:** **High** (multiple reports; blocks a common migration path)
  - **Functional Impact:** **Yes** (prevents token migration)
  - **Brand Impact:** **High** (financial + deadline pressure; trust risk)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Migration Portal / Snapshot Eligibility Service
  - **Complexity:** Moderate effort (depends on root cause: RPC/indexer, snapshot mapping, wallet adapter)
- **Resource Requirements:**
  - **Required Expertise:** Solana wallet integration (Phantom), snapshot/indexer data pipelines, backend/API debugging, basic front-end wallet connection diagnostics
  - **Dependencies:** Access to snapshot dataset + portal backend logs; confirm RPC provider behavior; potential dependency on indexer refresh
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create/locate canonical GitHub issue in the migration portal repo (or elizaos/eliza if that’s the tracker) with reproduction details: wallet address, expected snapshot balance, observed balance.
  2. Add structured diagnostics to portal UI/API responses (e.g., “snapshot record not found” vs “RPC balance mismatch” vs “unsupported token account format”).
  3. Verify: Phantom connection returns the same public key used at snapshot; confirm associated token accounts derivation and mint address match.
  4. Cross-check snapshot lookup keying (owner vs token account vs consolidated address) and ensure hardware/hot wallet consolidation isn’t mis-keyed.
  5. Provide “manual verification / whitelist” workflow for edge cases (time-bound before Feb 4).
- **Potential Assignees:** **Hexx 🌐** (migration comms + process), backend portal engineer (unidentified in dataset), **jin** (infra debugging), community repro helpers: **ai16zbags**, **Never Broke Again (NBA)**

---

### 2) OpenRouter embeddings failing in Knowledge plugin (only OpenAI works reliably)
- **Issue Title & ID:** OpenRouter embeddings error with Knowledge plugin — **DISCORD-2026-01-28-coders-openrouter-embeddings**
- **Current Status:** Reproduced by multiple users; workaround is “use OpenAI embeddings”; investigation requested.
- **Impact Assessment:**
  - **User Impact:** **High** (affects users trying to avoid OpenAI / use OpenRouter)
  - **Functional Impact:** **Partial** (Knowledge works with OpenAI; broken for OpenRouter path)
  - **Brand Impact:** **Medium/High** (provider-agnostic promise undermined)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Plugin-Knowledge (embeddings provider integration), Model Integration
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Embeddings API compatibility (OpenRouter vs OpenAI semantics), request/response schema validation, error observability
  - **Dependencies:** Confirm exact OpenRouter embedding endpoint + headers; confirm model naming; verify “OpenAI-compatible” assumptions
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect exact error payloads from at least 3 users (model name, endpoint, status code, body).
  2. Add a minimal integration test for embedding providers (OpenAI/Ollama/OpenRouter) in CI (smoke test with mocked responses if needed).
  3. Validate configuration surface area: provider name, model field, dimension handling, and any required OpenRouter headers.
  4. Document known-good OpenRouter config (if supported) or explicitly mark as “experimental” until fixed.
- **Potential Assignees:** **0xbbjoker** (knowledge plugin expertise), **jin** (requested testing), **YogaFlame** (reported + investigating), **Odilitime** (runtime/provider plumbing)

---

### 3) Knowledge plugin config validation rejects `EMBEDDING_PROVIDER=openrouter` (enum mismatch)
- **Issue Title & ID:** EMBEDDING_PROVIDER enum rejects `openrouter` — **DISCORD-2026-01-27-coders-embedding-provider-enum**
- **Current Status:** Identified root cause (config uses openrouter but enum allows only openai|google in that context); users advised to switch to openai.
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (new user setup blocker depending on docs/examples)
  - **Functional Impact:** **Partial** (blocks non-OpenAI configuration path)
  - **Brand Impact:** **Medium** (setup friction; “docs don’t work” perception)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** Config schema + Knowledge plugin examples/docs
  - **Complexity:** Simple fix (if schema is wrong) or Moderate (if provider split is intentional but docs misleading)
- **Resource Requirements:**
  - **Required Expertise:** Types/config validation, docs maintenance
  - **Dependencies:** Align intended architecture (noted plan: embeddings move to plugins in v2.x)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Decide “source of truth”: if OpenRouter embeddings are supported, update enum + tests; if not, update docs/examples to prevent invalid configs.
  2. Add a clear error message that recommends correct values and links to docs.
  3. Ensure docs and `.env.example` reflect the same allowed provider names across v1.x and v2.x.
- **Potential Assignees:** **Odilitime** (core/config), **YogaFlame** (docs fix), **jin** (onboarding focus), docs maintainer **sayonara**

---

### 4) Knowledge plugin unexpectedly high cost due to contextual embeddings (`CTX_KNOWLEDGE_ENABLED=true`)
- **Issue Title & ID:** Knowledge plugin generating very high token usage/cost per query with CTX embeddings — **DISCORD-2026-01-27-coders-ctx-knowledge-cost**
- **Current Status:** Workaround provided (disable contextual embeddings; use minimal config); needs doc + sane defaults.
- **Impact Assessment:**
  - **User Impact:** **High** (cost surprises hit many; can cause immediate churn)
  - **Functional Impact:** **Partial** (functionality works but at unacceptable cost)
  - **Brand Impact:** **High** (“this project is expensive/broken” perception)
- **Technical Classification:**
  - **Issue Category:** Performance / UX (cost/perf)
  - **Component Affected:** Knowledge plugin, embedding pipeline defaults
  - **Complexity:** Moderate effort (defaults + guardrails + docs)
- **Resource Requirements:**
  - **Required Expertise:** Token/cost profiling, embeddings pipeline, product UX around defaults
  - **Dependencies:** Clarify intended use of contextual embeddings; confirm safe default settings for new users
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Change default template configs to **CTX_KNOWLEDGE_ENABLED=false** (or require explicit opt-in with warning).
  2. Add runtime warning when contextual embeddings are enabled, including estimated cost per chunk/query.
  3. Add a “cost-safe preset” section to docs with a reference config and recommended embedding models (e.g., `text-embedding-3-small`).
  4. Add a small benchmark suite (docs + CI optional) to prevent regressions in token usage.
- **Potential Assignees:** **0xbbjoker** (explained root cause), **Odilitime** (defaults), **Tyrone** (doc action item), **jin** (onboarding)

---

### 5) plugin-anthropic 1.x incompatible with `develop` branch
- **Issue Title & ID:** plugin-anthropic 1.x doesn’t work with develop branch — **DISCORD-2026-01-28-core-devs-plugin-anthropic-compat**
- **Current Status:** Known; type fixes being curated for PR.
- **Impact Assessment:**
  - **User Impact:** **Medium** (developers tracking develop / CI users)
  - **Functional Impact:** **Partial** (blocks Anthropic provider usage on develop)
  - **Brand Impact:** **Medium** (ecosystem “breaks on develop”)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Plugin System, Model Integration (Anthropic)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript types, plugin API contracts, versioning/release discipline
  - **Dependencies:** Align plugin API version vs core develop changes; might require coordinated releases
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Open/merge the curated type-fix PR; add a compatibility matrix (core version ↔ plugin versions).
  2. Add CI job that tests top 5 plugins against `develop` nightly.
  3. Publish a patch release for plugin-anthropic 1.x (or clearly deprecate in favor of 2.x line).
- **Potential Assignees:** **Odilitime** (already on it), plugin maintainers for Anthropic (unidentified), reviewer: **standujar** or **0xbbjoker**

---

### 6) SSE streaming fails with `MIME_TYPE_MISMATCH` (users switching to socket.io)
- **Issue Title & ID:** SSE streaming MIME_TYPE_MISMATCH during setup/deploy — **DISCORD-2026-01-28-coders-sse-mime-mismatch**
- **Current Status:** Reproduced; workaround is “use socket.io”; suspected misconfigured backend deployment.
- **Impact Assessment:**
  - **User Impact:** **Medium** (hits users enabling streaming; likely common)
  - **Functional Impact:** **Partial** (streaming breaks; non-streaming may still work)
  - **Brand Impact:** **Medium** (streaming is a “wow” feature; failures look sloppy)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (deployment ergonomics)
  - **Component Affected:** Server API (SSE transport), Client hooks, Deployment config
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** HTTP streaming/SSE headers, reverse proxies (Nginx/Cloudflare/Vercel), content-type correctness, server routing
  - **Dependencies:** Need canonical deployment docs and known-good configs
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2** (upgrade to P1 if streaming is required for near-term “top-of-funnel” demo)
- **Specific Actionable Next Steps:**
  1. Capture a failing trace: request URL, response headers/body, proxy in front, and server route.
  2. Add server-side assertion/logging for SSE route: `Content-Type: text/event-stream`, `Cache-Control: no-cache`, `Connection: keep-alive`.
  3. Publish “Streaming Transport Decision Guide”: SSE vs socket.io vs WebSocket; include deployment recipes.
  4. If SSE is fragile behind common proxies, consider defaulting demos to socket.io.
- **Potential Assignees:** **Chucknorris | ONYX P9 NODE RENT** (helped diagnose), server maintainers (unidentified), **Odilitime** (transport/hooks familiarity)

---

### 7) plugin action handler callbacks: only first callback observed / callbacks delayed until completion
- **Issue Title & ID:** Action handler callbacks not behaving as documented (multi-callback vs completion response) — **DISCORD-2026-01-26-discussion-callbacks-1.7.2**
- **Current Status:** Investigation underway; framework supports multiple callbacks, suspect planner config (onestep vs multistep) or integration misuse; docs may be misleading.
- **Impact Assessment:**
  - **User Impact:** **Medium** (plugin authors; impacts interactive UX)
  - **Functional Impact:** **Partial** (actions still run, but progressive feedback broken)
  - **Brand Impact:** **Medium** (developer trust/documentation quality)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** Core Framework (action execution), Task Planner, Plugin System
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Core runtime action pipeline, planner modes, event/callback semantics, docs
  - **Dependencies:** Clarify expected behavior across planners; add a minimal repro repo/test
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a minimal reproducible test: action emits 3 callbacks over time; verify client receives all in order.
  2. Document callback semantics per planner mode (onestep vs multistep) and per transport (SSE/socket).
  3. Add an automated test in core to lock in behavior.
- **Potential Assignees:** **Odilitime** (already troubleshooting), **Victor Creed** (reporter), core runtime maintainers (unidentified)

---

### 8) Integrate N8N Workflow Engine as primary automation layer (v2 architecture)
- **Issue Title & ID:** [Plugin] Integrate N8N Workflow Engine — **elizaos/eliza#6429**
- **Current Status:** **OPEN** (strategic “core architecture” issue; aligned with Discord plans; plugin-n8n-workflow ~30% complete).
- **Impact Assessment:**
  - **User Impact:** **High** (unblocks “workflow automation” value prop; large audience)
  - **Functional Impact:** **Yes (for v2 direction)** (core product strategy hinges on it)
  - **Brand Impact:** **High** (competitive differentiation; “Eliza App” capability)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Architectural Change
  - **Component Affected:** Plugin System, Cloud Runtime, OAuth Gateway, Workflow Engine
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** n8n workflow JSON, multi-tenant credential storage, OAuth flows, cloud execution, security boundaries
  - **Dependencies:** OAuth gateway layer; storage per tenant; hosted vs self-hosted n8n decision; node catalog exposure to agent
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1** (treat as “this sprint” if v2 top-of-funnel depends on automation demos)
- **Specific Actionable Next Steps:**
  1. Lock the v2 milestone scope: (a) generate workflow JSON, (b) execute via hosted n8n, (c) per-tenant storage, (d) credential validation.
  2. Deliver a “hello workflow” vertical slice: user prompt → JSON → stored → executed → result returned.
  3. Define credential interface between existing plugins (gmail/calendar) and n8n credential objects.
  4. Add a workflow “lint/validator” step before execution (required creds + allowed nodes).
- **Potential Assignees:** **Stan ⚡** (plugin + OAuth specs), **s** / **Shaw** (architecture direction from notes), **borisudovicic** (issue author), **Odilitime** (credential passing), reviewers: **jin**

---

### 9) Opus/Pro/Ultra model mapping confusion (provider plan labeling / UI correctness)
- **Issue Title & ID:** “Opus - pro and Ultra - sonnet? Is this right?” — **elizaos/eliza#6390**
- **Current Status:** **OPEN** (likely UX/docs/config mismatch; needs clarification or fix).
- **Impact Assessment:**
  - **User Impact:** **Low/Medium** (affects users choosing plans/models)
  - **Functional Impact:** **No** (unless wrong model is actually used/billed)
  - **Brand Impact:** **Medium** (billing/model trust)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation
  - **Component Affected:** Model Integration / UI labels (unclear from issue body)
  - **Complexity:** Simple fix (if label) to Moderate (if routing/billing mismatch)
- **Resource Requirements:**
  - **Required Expertise:** Provider model mapping, UI copy, billing semantics
  - **Dependencies:** Confirm actual model IDs used in code and displayed to user
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Confirm what the UI is showing vs what runtime requests (log actual model IDs).
  2. Fix labels or mapping; add a small test/assertion for model name display.
- **Potential Assignees:** **borisudovicic** (issue author context), model integration maintainer (unidentified), **Odilitime** (provider handling familiarity)

---

## Conclusion

### 1) Top 5–10 highest priority issues to address immediately
1. **P0:** Migration portal not detecting ai16z in Phantom wallets — **DISCORD-2026-01-28-discussion-migration-phantom**
2. **P1:** OpenRouter embeddings failing in Knowledge plugin — **DISCORD-2026-01-28-coders-openrouter-embeddings**
3. **P1:** Knowledge config schema/docs mismatch for `EMBEDDING_PROVIDER=openrouter` — **DISCORD-2026-01-27-coders-embedding-provider-enum**
4. **P1:** Knowledge plugin cost blowups with contextual embeddings enabled by default/unclear — **DISCORD-2026-01-27-coders-ctx-knowledge-cost**
5. **P1:** plugin-anthropic 1.x incompatible with develop — **DISCORD-2026-01-28-core-devs-plugin-anthropic-compat**
6. **P1:** N8N workflow engine integration (v2 strategic path) — **elizaos/eliza#6429**
7. **P2:** SSE `MIME_TYPE_MISMATCH` streaming setup failures — **DISCORD-2026-01-28-coders-sse-mime-mismatch**
8. **P2:** Action callback semantics inconsistent with docs — **DISCORD-2026-01-26-discussion-callbacks-1.7.2**
9. **P3:** Opus/Pro/Ultra model mapping confusion — **elizaos/eliza#6390**

### 2) Patterns/themes indicating deeper architectural problems
- **Provider/compatibility fragmentation:** Embeddings and model/provider integrations appear “OpenAI-first” in practice, creating recurring breakage for OpenRouter/Anthropic and confusing config schemas.
- **Onboarding-time footguns:** Defaults (contextual embeddings) and docs/schema drift cause new users to hit blockers or unexpected cost, amplifying churn risk.
- **Transport + deployment brittleness:** SSE issues suggest proxy/environment sensitivity; without canonical deployment recipes, users self-select to socket.io, fragmenting support.
- **Cross-repo version skew:** develop branch vs plugin versions (anthropic) indicates missing compatibility gates and release coordination.

### 3) Recommendations for process improvements
- **Introduce a “Golden Paths” CI matrix:** nightly tests covering (core develop × top plugins × top transports) plus at least one embeddings provider per vendor (OpenAI/Ollama/OpenRouter).
- **Configuration contract enforcement:** generate docs from the same schema/types used in runtime; add linting that blocks publishing examples with invalid enums.
- **Cost guardrails by default:** ship “safe preset” configs; require explicit opt-in for high-cost features with warnings and estimated token/cost ranges.
- **Deployment reference blueprints:** publish and maintain “known-good” configs for SSE/socket.io behind common proxies, with automated smoke tests (curl-based) in a public template repo.
- **Fast escalation path for financial blockers:** migration/eligibility issues should have an on-call owner, a standardized intake form, and a manual override process with audit logging.