## Issue Triage — 2026-02-22

### 1) [Bug] ElizaCloud API explorer “Send request” returns “api key is required” even when key is present — **DISCORD-2026-02-20-APIEXPLORER-KEY**
- **Current Status:** Reported in Discord; forwarded to dev team (no GitHub issue linked yet)
- **Impact Assessment**
  - **User Impact:** **High** (blocks a core “try the API” workflow for most dashboard users)
  - **Functional Impact:** **Yes** (prevents testing requests in the dashboard)
  - **Brand Impact:** **High** (makes cloud product appear broken/unreliable)
- **Technical Classification**
  - **Issue Category:** Bug / UX
  - **Component Affected:** ElizaCloud Dashboard + API Explorer (frontend) and/or API gateway auth middleware
  - **Complexity:** Moderate effort
- **Resource Requirements**
  - **Required Expertise:** Web frontend (React/Next), API auth (headers, bearer tokens), browser storage/session debugging
  - **Dependencies:** Need repro details (browser, account state), confirm expected auth mechanism (dashboard key vs BYOK key)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps**
  1. Create a GitHub issue in `elizaos/eliza` (or ElizaCloud repo if separate) with exact repro steps + HAR capture.
  2. Validate request builder: confirm the API key is actually attached (header name, scope, environment selection).
  3. Add integration test for “Send request” path (mocked API) to prevent regressions.
  4. If BYOK is involved, ensure UI clearly indicates which key is active and where it’s stored.
- **Potential Assignees**
  - **borisudovicic** (cloud/chat API context; previously filed cloud chat API issue)
  - **odilitime** (core/platform debugging and routing)
  - **lalalune** (runtime/platform integration; can help identify expected auth surface)

---

### 2) ElizaCloud dashboard pages have broken mousepad scrolling; scrollbar hard to see — **DISCORD-2026-02-20-DASH-SCROLL**
- **Current Status:** Reported in Discord; no tracked issue linked yet
- **Impact Assessment**
  - **User Impact:** **High** (affects broad dashboard navigation, not just one page)
  - **Functional Impact:** **Partial** (workarounds exist but usability is degraded)
  - **Brand Impact:** **High** (visible quality regression)
- **Technical Classification**
  - **Issue Category:** UX / Bug
  - **Component Affected:** ElizaCloud Dashboard UI layout/overflow handling
  - **Complexity:** Simple fix to Moderate (depends on root cause: CSS overflow, nested scroll containers, event handling)
- **Resource Requirements**
  - **Required Expertise:** Frontend CSS/layout, cross-browser input devices (trackpad)
  - **Dependencies:** Identify affected browsers/OS; confirm whether issue is global or API explorer-specific
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. File GitHub issue with OS/browser + video repro.
  2. Inspect overflow containers and scroll locking (e.g., `overflow: hidden` on body, nested `position: fixed`).
  3. Add visual regression + basic E2E scroll test for dashboard critical pages.
- **Potential Assignees**
  - **borisudovicic** (product ownership / cloud UX)
  - **odilitime** (triage + routing to correct repo/owner)

---

### 3) [Bug] URL in message triggers duplicate LLM calls (processed as both text and attachment) — **elizaos/eliza #6486**
- **Current Status:** **OPEN**
- **Impact Assessment**
  - **User Impact:** **High** (any webapp user sending URLs; common case)
  - **Functional Impact:** **Partial** (responses still appear, but duplicated and costly)
  - **Brand Impact:** **High** (users see “duplicated output” + cost inefficiency)
- **Technical Classification**
  - **Issue Category:** Bug / Performance / UX
  - **Component Affected:** Webapp message ingestion + attachment/URL preview pipeline + SSE streaming assembly
  - **Complexity:** Moderate effort
- **Resource Requirements**
  - **Required Expertise:** Webapp/client SSE handling, server message normalization, attachment parsing
  - **Dependencies:** Confirm where the duplication occurs (client vs server) and whether URL unfurling is treated as attachment
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0** (cost + correctness regression in core chat flow)
- **Specific Actionable Next Steps**
  1. Add tracing: log correlation IDs for each user message → number of LLM invocations.
  2. Ensure URL preview metadata does not create a second “assistant run” unless explicitly requested.
  3. Fix by deduplicating at a single canonical representation stage (pre-LLM), or by preventing double-enqueue.
  4. Add regression test: “message with URL” should yield exactly one model call and one streamed assistant message.
- **Potential Assignees**
  - **odilitime** (core/runtime + message pipeline)
  - **lalalune** (architecture changes in next/v2 pipelines)
  - **anchapin** (stability-focused fixes; defensive coding patterns)

---

### 4) Embedding failures on Linux in Ollama plugin — **elizaos-plugins/plugin-ollama #17**
- **Current Status:** **OPEN / Investigating** (noted in weekly summary)
- **Impact Assessment**
  - **User Impact:** **Medium–High** (Linux is common for self-hosting; embeddings often required for RAG)
  - **Functional Impact:** **Yes** for embeddings/RAG scenarios (core agent capability for many deployments)
  - **Brand Impact:** **Medium** (plugin reliability perception; self-hosters are vocal)
- **Technical Classification**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / plugin-ollama (embedding endpoint, platform-specific behavior)
  - **Complexity:** Moderate effort
- **Resource Requirements**
  - **Required Expertise:** Ollama API, Node/Bun networking, Linux environment debugging, embeddings pipeline
  - **Dependencies:** Need exact error logs, Ollama version, model name, CPU/GPU environment
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. Reproduce in CI using Linux runner with pinned Ollama + a known embedding model.
  2. Verify request payload/endpoint compatibility (Ollama embeddings API differences across versions).
  3. Add fallback/clear error messaging if embeddings not supported by selected model.
  4. Document known-good Ollama versions/models for embeddings.
- **Potential Assignees**
  - **odilitime** (platform triage and coordination)
  - **lalalune** (model integration patterns; cross-runtime consistency)
  - (If identified) **plugin-ollama maintainers** once confirmed

---

### 5) Agent unexpectedly starts responding in Korean (unexpected locale/config behavior) — **DISCORD-2026-02-21-LOCALE-KO**
- **Current Status:** Reported in Discord (DorianD); not tracked as GitHub issue yet
- **Impact Assessment**
  - **User Impact:** **Medium** (unclear prevalence; potentially configuration-specific)
  - **Functional Impact:** **Partial** (content quality/intent mismatch; can break product use)
  - **Brand Impact:** **Medium–High** (agents “randomly switching languages” looks unstable)
- **Technical Classification**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / Prompting / Character config / language detection
  - **Complexity:** Complex solution (may involve model behavior + prompt + memory contamination)
- **Resource Requirements**
  - **Required Expertise:** Prompt engineering, memory/state inspection, model settings, i18n defaults
  - **Dependencies:** Need: model/provider, system prompt/character file, recent conversation logs, any locale headers
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (promote to P1 if reproduced broadly)
- **Specific Actionable Next Steps**
  1. Request a minimal repro bundle: character file, last N messages, provider/model, runtime version.
  2. Check if any tool/provider is injecting locale (browser locale → prompt context).
  3. Add a “language lock” setting (or clear doc) if intentional multilingual behavior exists.
  4. Add guardrail test: if configured language is `en`, responses should remain English unless user requests otherwise.
- **Potential Assignees**
  - **borisudovicic** (prompt/character and cloud chat behavior context)
  - **lalalune** (runtime/prompt assembly paths in next/v2)
  - **odilitime** (triage + diagnostics)

---

### 6) v2.0.0 branch is recommended but lacks sufficient documentation — **DISCORD-2026-02-21-V2-DOCS-GAP**
- **Current Status:** Known gap; requested in Discord
- **Impact Assessment**
  - **User Impact:** **High** (new builders are being directed to v2; documentation is the onboarding path)
  - **Functional Impact:** **Partial** (software works, but adoption/contribution slows)
  - **Brand Impact:** **High** (perception of instability/confusion during major version transition)
- **Technical Classification**
  - **Issue Category:** Documentation
  - **Component Affected:** Core Framework / CLI / Getting Started (v2)
  - **Complexity:** Moderate effort (structured doc work + examples validation)
- **Resource Requirements**
  - **Required Expertise:** Technical writing, v2 architecture knowledge, examples maintenance
  - **Dependencies:** Clarify what “recommended” means (stability guarantees, feature parity, migration notes)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. Publish a v2 “Start Here” page: install, minimal agent, run, configure DB, add plugins.
  2. Add a migration doc: v1 → v2 differences (removed app/server/CLI pieces, new runtime layout).
  3. Create a compatibility matrix: supported plugins/providers per runtime (TS/Rust/Python).
  4. Add “known issues” section (DB selection, data migration not supported, etc.).
- **Potential Assignees**
  - **lalalune** (v2/next author; architecture source-of-truth)
  - **odilitime** (bootstrap/runtime integration knowledge)
  - **mcp97** (docs hygiene; recent changelog/doc maintenance)

---

### 7) plugin-sql supports pglite + Neon, but no automatic data migration; configuration unclear for users — **DISCORD-2026-02-21-DB-MIGRATION**
- **Current Status:** Clarified in Discord; not implemented
- **Impact Assessment**
  - **User Impact:** **Medium** (affects users switching local ↔ cloud DB)
  - **Functional Impact:** **Partial** (causes “why is my data missing” confusion)
  - **Brand Impact:** **Medium** (data continuity expectations)
- **Technical Classification**
  - **Issue Category:** Documentation + Feature Request
  - **Component Affected:** Plugin System (plugin-sql), Deployment/Operations
  - **Complexity:** Architectural change (true migration) or moderate (explicit export/import tooling)
- **Resource Requirements**
  - **Required Expertise:** Postgres tooling, schema/versioning, data export/import
  - **Dependencies:** Define supported migration paths (pglite → Neon; Neon → pglite) and version constraints
  - **Estimated Effort:** **4/5** (if automated), **2/5** (if documented manual flow + scripts)
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps**
  1. Document current behavior prominently: DB chosen by env vars; no auto-migration.
  2. Provide a supported manual migration recipe (dump/restore or logical export).
  3. Consider adding `elizaos db export/import` CLI helpers (scoped to plugin-sql schemas).
- **Potential Assignees**
  - **odilitime** (platform architecture)
  - **lalalune** (v2 infra patterns)
  - **anchapin** (robustness + safe guards)

---

### 8) Feature Request: Support custom OpenAI endpoint URL for OpenAI provider — **elizaos/eliza #6490**
- **Current Status:** **OPEN**
- **Impact Assessment**
  - **User Impact:** **Medium** (important for OpenAI-compatible providers; growing need)
  - **Functional Impact:** **Partial** (users can’t use OpenAI-compatible endpoints without a new provider)
  - **Brand Impact:** **Medium** (integration flexibility expectation)
- **Technical Classification**
  - **Issue Category:** Feature Request
  - **Component Affected:** Model Integration (OpenAI provider configuration)
  - **Complexity:** Simple fix to Moderate (config plumbing + validation + docs)
- **Resource Requirements**
  - **Required Expertise:** Provider abstraction, config/env management, security (avoid SSRF footguns)
  - **Dependencies:** Decide config surface (env var, config file, runtime param) and allowlist/validation policy
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps**
  1. Add `baseURL` / `endpoint` to provider config with safe defaults to official OpenAI.
  2. Add validation and warnings (e.g., only https; avoid localhost in cloud mode unless explicit).
  3. Update docs with examples for common OpenAI-compatible services.
- **Potential Assignees**
  - **lalalune** (core provider abstractions; next/v2 direction)
  - **odilitime** (security + platform review)

---

### 9) Investigate dApp deployment capabilities to Solana Seeker (unclear support/roadmap) — **DISCORD-2026-02-21-SOLANA-SEEKER**
- **Current Status:** Asked in Discord; unanswered
- **Impact Assessment**
  - **User Impact:** **Low–Medium** (developer subset; unclear demand)
  - **Functional Impact:** **No** (not blocking elizaOS core)
  - **Brand Impact:** **Low** (unless repeatedly asked without response)
- **Technical Classification**
  - **Issue Category:** Documentation / Feature Request
  - **Component Affected:** Deployment guides / Solana integration messaging
  - **Complexity:** Moderate (requires clarity on what’s possible and supported)
- **Resource Requirements**
  - **Required Expertise:** Solana tooling, deployment constraints, platform partnerships (if any)
  - **Dependencies:** Determine whether elizaOS intends to support Seeker-specific deployment workflows
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps**
  1. Provide an official answer: supported/unsupported + recommended alternatives.
  2. If supported, add a short deployment guide or reference.
- **Potential Assignees**
  - **odilitime** (platform direction)
  - **kaiclawd** (Solana identity/SAID context)

---

### 10) Review/integrate Erlang “unbreakable agents” implementation (nebuluzno/scr) — **DISCORD-2026-02-21-ERLANG-SCR**
- **Current Status:** Proposed in Discord; positive initial review from Odilitime
- **Impact Assessment**
  - **User Impact:** **Low–Medium** (future resilience; not immediate blocker)
  - **Functional Impact:** **No** (enhancement)
  - **Brand Impact:** **Medium** (if delivered well; could differentiate reliability story)
- **Technical Classification**
  - **Issue Category:** Feature Request / Architectural exploration
  - **Component Affected:** Core Framework runtime architecture / resilience
  - **Complexity:** Architectural change
- **Resource Requirements**
  - **Required Expertise:** Erlang/BEAM, distributed systems, interop boundaries with TS/Rust/Python
  - **Dependencies:** Define integration strategy (sidecar supervisor? message bus? embedding runtime?)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P4** (track as RFC; do not interrupt beta stability work)
- **Specific Actionable Next Steps**
  1. Convert into an RFC: goals, minimal integration surface, benchmarks, failure modes.
  2. Decide whether to incubate as external “resilience runtime” rather than core.
- **Potential Assignees**
  - **odilitime** (architecture stewardship)
  - **King Nebuluz** (author; external contributor)

---

## Highest-Priority Summary (Top 5–10 to address now)
1. **P0:** ElizaCloud API explorer “Send request” incorrectly reports missing API key (**DISCORD-2026-02-20-APIEXPLORER-KEY**)
2. **P0:** URL messages trigger **duplicate LLM calls** and duplicated streamed output (**elizaos/eliza #6486**)
3. **P1:** Ollama plugin **embeddings failing on Linux** (**plugin-ollama #17**)
4. **P1:** ElizaCloud dashboard **scrolling broken** / poor usability (**DISCORD-2026-02-20-DASH-SCROLL**)
5. **P1:** **v2.0.0 documentation gap** despite being recommended (**DISCORD-2026-02-21-V2-DOCS-GAP**)
6. **P2:** Agent unexpectedly switching to Korean (possible locale/memory/prompt contamination) (**DISCORD-2026-02-21-LOCALE-KO**)
7. **P2:** plugin-sql DB switching confusion + no migration path (**DISCORD-2026-02-21-DB-MIGRATION**)
8. **P2:** Custom OpenAI endpoint URL support (**elizaos/eliza #6490**)

---

## Patterns / Themes Suggesting Deeper Issues
- **Version transition risk (v2/next):** Community is told “v2 is recommended” while docs and migration guidance lag, creating misaligned expectations and support load.
- **Message normalization gaps:** The duplicate URL processing bug indicates **multiple ingestion paths** (text + attachment/preview) can trigger redundant downstream execution.
- **Cloud UX regressions:** Dashboard scrolling + API explorer key handling point to missing **end-to-end UI checks** for critical flows (try API, navigate dashboard).
- **Configuration ambiguity (DB + keys):** Repeated questions about DB selection, key usage (“use a different key” / BYOK) suggest that **runtime configuration surfaces aren’t explicit** and may be inconsistently implemented across products (OSS vs cloud).

---

## Process Recommendations (Prevent Repeat Issues)
1. **Add “golden path” E2E tests for Cloud:**  
   - Dashboard scroll sanity + API explorer send-request test with a real-ish mocked auth flow.
2. **Introduce execution deduplication guards:**  
   - Ensure each user message maps to exactly one run unless explicitly multi-run; add correlation IDs and “one message → one run” assertions in tests.
3. **Publish a v2 rollout contract:**  
   - Define “recommended” criteria, feature parity notes, and migration steps; keep a single canonical “Getting Started (v2)” doc.
4. **Standardize configuration documentation and UI wording:**  
   - Explicitly differentiate: platform key vs BYOK, local vs cloud DB, and data migration expectations; link these from both CLI help and dashboard tooltips.
5. **Triage hygiene:**  
   - Convert Discord-reported defects into GitHub issues within 24 hours with owner/labels (Cloud/UI vs Core vs Plugins), so they don’t stall untracked.