## Issue Triage — 2026-02-21

### 1) ElizaCloud API Explorer: mousepad scrolling broken / scrollbar nearly invisible (dashboard-wide)
- **Issue Title & ID:** Broken scrolling on ElizaCloud dashboard (API Explorer + other pages) — **DISC-2026-02-20-CLOUD-SCROLL**
- **Current Status:** Reported on Discord; acknowledged and forwarded to dev team; no tracked GitHub issue found.
- **Impact Assessment:**
  - **User Impact:** **High** (affects most users trying to use dashboard pages, especially API Explorer)
  - **Functional Impact:** **Partial** (core functionality still possible but severely impaired)
  - **Brand Impact:** **High** (basic UI regressions signal low quality)
- **Technical Classification:**
  - **Category:** UX / Bug
  - **Component:** **ElizaCloud GUI (Dashboard / API Explorer)**
  - **Complexity:** **Moderate effort** (likely CSS/overflow container + layout changes; needs cross-browser testing)
- **Resource Requirements:**
  - **Required Expertise:** Frontend (React/Next), CSS layout/scroll containers, trackpad scroll event handling, accessibility
  - **Dependencies:** None, but should be fixed before expanding Babylon/Cloud onboarding further
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue in eliza-cloud-v2 (or correct repo) with reproduction steps + affected pages list.
  2. Identify scroll container(s) and confirm whether `overflow: hidden`, nested scroll regions, or a custom scroll library is blocking wheel/trackpad events.
  3. Add automated UI sanity check (Playwright) to verify wheel scroll works on API Explorer and at least 1–2 other key pages.
  4. Increase scrollbar visibility (contrast/width) or enable OS default scrollbars.
- **Potential Assignees:** **borisudovicic** (cloud coordination), **Donhill** (UX/front-end, offered help), **odilitime** (triage/coordination)

---

### 2) ElizaCloud API Explorer: “Send request” returns “api key is required” even when key appears present
- **Issue Title & ID:** API Explorer test request fails with false missing API key error — **DISC-2026-02-20-CLOUD-APIKEY**
- **Current Status:** Reported on Discord; acknowledged and forwarded; no tracked GitHub issue found.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks common “try the API” workflow)
  - **Functional Impact:** **Yes (for API Explorer testing)**; **Partial (overall Cloud)** (users may still call API externally)
  - **Brand Impact:** **High** (“Try it” failing is a top-of-funnel conversion killer)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** **ElizaCloud GUI + API auth middleware**
  - **Complexity:** **Moderate effort** (state/auth token injection issue; could be environment/tenant mismatch)
- **Resource Requirements:**
  - **Required Expertise:** Frontend auth state, backend auth headers, API gateway/CORS, request signing
  - **Dependencies:** May depend on clarifying “use a different key” / BYOK behavior (see Issue #3)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0** (user-facing “API doesn’t work” failure in a critical product surface)
- **Specific Actionable Next Steps:**
  1. Capture failing request in DevTools: confirm whether `Authorization` header (or expected key header) is actually present.
  2. Confirm expected auth mechanism for the endpoint (project key vs user key vs session token).
  3. Add server-side logging for “missing key” branch including which header(s) were checked (redact values).
  4. Add an integration test for API Explorer “send request” ensuring the UI injects the correct key.
  5. If multi-key support exists, explicitly show which key is active and being used for the test call.
- **Potential Assignees:** **borisudovicic** (cloud/API), **odilitime** (routing to correct team), **lalalune** (auth/infra familiarity)

---

### 3) ElizaCloud: “Use a different key” unclear (BYOK vs internal keys), pricing per model not visible
- **Issue Title & ID:** Cloud key semantics + per-model pricing transparency missing — **DISC-2026-02-20-CLOUD-BYOK-PRICING**
- **Current Status:** Open questions on Discord; no official documentation/answer surfaced.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (confuses power users evaluating costs + integrations)
  - **Functional Impact:** **Partial** (doesn’t always break usage, but blocks adoption decisions)
  - **Brand Impact:** **High** (pricing opacity and key ambiguity reduce trust)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component:** ElizaCloud Dashboard + Docs
  - **Complexity:** **Simple fix** (docs + UI copy), potentially **Moderate** if pricing tables are not available server-side
- **Resource Requirements:**
  - **Required Expertise:** Product/UX writing, billing/pricing data, dashboard UI
  - **Dependencies:** Billing system source-of-truth; model catalog
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Decide/confirm product behavior: BYOK supported or not; which providers; how keys are stored and scoped.
  2. Update UI text: rename to “Bring your own key (OpenAI/OpenRouter/…)” if applicable; otherwise clarify “use another ElizaCloud key.”
  3. Add a pricing table page/modal with per-model input/output token pricing and last-updated timestamp.
  4. Add a short doc page: “Keys & Billing in ElizaCloud” with examples.
- **Potential Assignees:** **borisudovicic** (product infra), **Donhill** (UX), **odilitime** (community feedback loop)

---

### 4) [Bug] URL in message triggers duplicate LLM calls (processed as both text and attachment) — webapp
- **Issue Title & ID:** URL triggers duplicate LLM calls (text + attachment) in webapp — **elizaos/eliza#6486**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **High** (URLs are common; affects many conversations)
  - **Functional Impact:** **Partial** (responses still arrive but duplicated; cost doubles)
  - **Brand Impact:** **High** (visible duplication + unexpected billing/cost behavior)
- **Technical Classification:**
  - **Category:** Bug / Performance (cost amplification)
  - **Component:** Client message pipeline + attachments handling + SSE streaming
  - **Complexity:** **Moderate effort** (requires correct de-dup logic and ensuring single inference path)
- **Resource Requirements:**
  - **Required Expertise:** Webapp messaging pipeline, attachment parsing, SSE streaming, server message normalization
  - **Dependencies:** None
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0** (systematic cost/UX regression; doubles LLM spend)
- **Specific Actionable Next Steps:**
  1. Add a regression test: send message containing URL and assert only one model invocation + one streamed response.
  2. Trace where URL metadata preview becomes an “attachment” and why it triggers another generation.
  3. Implement a single “canonical message content” decision point (either treat as text-only or attachment-only).
  4. Ensure SSE “done” event is emitted only after the single generation completes; guard against concatenating two generations.
- **Potential Assignees:** **lalalune** (runtime/message architecture), **anchapin** (defensive fixes), **thewoweffect** (reporter for validation)

---

### 5) plugin-ollama: Embedding failures on Linux environments
- **Issue Title & ID:** Embedding failures on Linux — **elizaos-plugins/plugin-ollama#17**
- **Current Status:** **Investigating** (per weekly summary)
- **Impact Assessment:**
  - **User Impact:** **Medium** (subset: Ollama + embeddings + Linux, but common self-host setup)
  - **Functional Impact:** **Partial** (breaks RAG/vector workflows; chat may still work)
  - **Brand Impact:** **Medium** (self-host reliability concerns)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Model Integration / Plugin System (Ollama embeddings)
  - **Complexity:** **Moderate effort** (OS-specific libs, HTTP payload/streaming, model availability)
- **Resource Requirements:**
  - **Required Expertise:** Linux env debugging, Ollama API specifics, embeddings pipeline, CI matrix
  - **Dependencies:** Repro environment details (distro, kernel, ollama version, model)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Require issue template completion: ollama version, model name, sample request/response, logs.
  2. Add Linux CI job that runs a minimal embedding call (or a mocked contract test if Ollama not available in CI).
  3. Validate request formatting: content-type, encoding, chunking, timeouts.
  4. Implement clearer error propagation with actionable hints (missing model, wrong endpoint, unsupported embedding model).
- **Potential Assignees:** **odilitime** (plugin coordination), **lalalune** (model integration), plus any active plugin-ollama maintainer

---

### 6) OpenAI provider: Support custom OpenAI-compatible endpoint URL
- **Issue Title & ID:** Support custom OpenAI endpoint URL (OpenAI-compatible providers) — **elizaos/eliza#6490**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium** (important for users on alternative inference providers; growing demand)
  - **Functional Impact:** **Partial** (blocks specific deployments)
  - **Brand Impact:** **Medium** (integration flexibility is a key framework selling point)
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component:** Model Integration (OpenAI provider)
  - **Complexity:** **Simple fix** if base URL is plumbed through; **Moderate** if assumptions are widespread
- **Resource Requirements:**
  - **Required Expertise:** Provider config design, secure config handling, docs updates
  - **Dependencies:** Decide config precedence (env vs character vs runtime settings)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2** (high value, but not an outage)
- **Specific Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or provider-scoped `baseUrl`) support.
  2. Ensure it works for both chat and embeddings endpoints (if supported).
  3. Add docs + example for SiliconFlow/OpenAI-compatible endpoints.
  4. Add a unit test that asserts requests target the configured base URL.
- **Potential Assignees:** **lalalune** (core/provider architecture), **anchapin** (safe config patterns)

---

### 7) Token migration: users reporting lost coins / missed deadline; no clear support path (no ticket system)
- **Issue Title & ID:** Migration support gaps (lost coins / missed deadline / unclear process) — **DISC-2026-02-18-MIGRATION-SUPPORT**
- **Current Status:** Ongoing Discord questions; unresolved; no formal ticketing path.
- **Impact Assessment:**
  - **User Impact:** **High** (multiple users affected; repeated questions)
  - **Functional Impact:** **Partial** (not framework runtime, but critical to ecosystem continuity)
  - **Brand Impact:** **High** (financial loss claims are reputationally damaging)
- **Technical Classification:**
  - **Category:** UX / Process / Documentation (with possible backend ops)
  - **Component:** Support Operations + Migration tooling
  - **Complexity:** **Moderate effort** (process + tooling + comms)
- **Resource Requirements:**
  - **Required Expertise:** Support ops, incident handling, blockchain migration mechanics, fraud prevention
  - **Dependencies:** Access to authoritative migration contract/tooling details; policy decisions on late migrations
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0** (reputational/financial-risk issue; needs a clear, auditable path)
- **Specific Actionable Next Steps:**
  1. Publish a single “Migration Support” page: what’s possible, what’s not, required info, official links.
  2. Stand up a lightweight ticket intake (e.g., GitHub Discussions form, Zendesk/HelpScout, or Discord bot form) to stop ad-hoc DMs.
  3. Create a runbook for responders (verification steps, phishing warnings, escalation contacts).
  4. Provide a clear statement on missed-deadline handling (finality vs exception policy).
- **Potential Assignees:** **odilitime** (community ops), **ElizaBAO** (ecosystem/business), **Shaw** (policy sign-off)

---

### 8) Partner communications: weak comms causing negative sentiment among influential partner groups
- **Issue Title & ID:** Partner comms breakdown causing negative sentiment — **DISC-2026-02-20-PARTNER-COMMS**
- **Current Status:** Identified in 🥇-partners channel; no remediation plan documented.
- **Impact Assessment:**
  - **User Impact:** **Medium** (indirect, but impacts adoption and distribution)
  - **Functional Impact:** **No** (not a runtime bug)
  - **Brand Impact:** **High** (amplifies controversy; reduces partner-driven growth)
- **Technical Classification:**
  - **Category:** Process / Documentation (communications)
  - **Component:** Project Communications
  - **Complexity:** **Moderate effort** (cadence + ownership + messaging)
- **Resource Requirements:**
  - **Required Expertise:** Partner management, release communications, incident comms
  - **Dependencies:** Agreement on where canonical updates live (Twitter vs Farcaster vs Discord vs site)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define a single canonical weekly update post (site/blog/Discord announcement) mirrored to social platforms.
  2. Create a partner-facing changelog + roadmap snippet (what shipped, what’s next, known issues).
  3. Assign an “on-call comms” owner during incidents (Autofun/Twitter-type events).
- **Potential Assignees:** **ElizaBAO**, **odilitime**, **Shaw**

---

### 9) “Is there still a live Eliza agent to answer questions about the most recent ElizaOS codebase?”
- **Issue Title & ID:** Lack of a live, up-to-date support agent for codebase Q&A — **DISC-2026-02-20-LIVE-AGENT**
- **Current Status:** Unanswered on Discord.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects onboarding + developer productivity)
  - **Functional Impact:** **Partial** (support function missing)
  - **Brand Impact:** **Medium** (expectation mismatch for an “agent framework”)
- **Technical Classification:**
  - **Category:** Feature Request / Documentation
  - **Component:** Developer Experience / Support Tooling
  - **Complexity:** **Complex solution** (keeping agent context current; preventing hallucinations; sourcing docs/PRs)
- **Resource Requirements:**
  - **Required Expertise:** RAG, docs indexing, evaluation/guardrails, deployment
  - **Dependencies:** Up-to-date docs, repo indexing pipeline, policy on authoritative answers
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Decide scope: Discord helper bot vs web docs assistant; restrict to citing sources.
  2. Build an MVP using docs + release notes only; require citations and “unknown” behavior.
  3. Add feedback loop: “this answer is wrong” to capture gaps and update docs.
- **Potential Assignees:** **lalalune** (architecture), **odilitime** (community workflow), **jin** (site tooling, if applicable)

---

## Highest-Priority Issues to Address Immediately (Top 5–10)
1. **P0 — DISC-2026-02-20-CLOUD-APIKEY:** API Explorer “Send request” falsely claims missing API key (breaks try-the-API flow).
2. **P0 — elizaos/eliza#6486:** URL messages trigger duplicate LLM calls and duplicated SSE output (2× cost + broken UX).
3. **P0 — DISC-2026-02-18-MIGRATION-SUPPORT:** Migration support gaps (lost coins / missed deadline) with no ticketing/runbook (high reputational risk).
4. **P1 — DISC-2026-02-20-CLOUD-SCROLL:** Cloud dashboard scrolling broken (major UI regression).
5. **P1 — elizaos-plugins/plugin-ollama#17:** Linux embedding failures (breaks common self-host RAG workflows).
6. **P1 — DISC-2026-02-20-CLOUD-BYOK-PRICING:** BYOK key semantics + per-model pricing clarity (trust/adoption blocker).
7. **P1 — DISC-2026-02-20-PARTNER-COMMS:** Partner comms breakdown (amplifies negative sentiment, impacts growth).
8. **P2 — elizaos/eliza#6490:** Custom OpenAI-compatible endpoint URL support (important flexibility improvement).
9. **P2 — DISC-2026-02-20-LIVE-AGENT:** Live support agent for codebase questions (DX improvement; non-urgent).

---

## Patterns / Themes Suggesting Deeper Issues
- **“Funnel breakage” in Cloud:** The dashboard surfaces that should convert users (API Explorer, scrolling usability, pricing clarity) are currently unreliable or unclear—this suggests missing pre-release UX QA and product instrumentation on key flows.
- **Cost/usage correctness gaps:** Duplicate LLM calls (#6486) plus unclear pricing tables indicate the system may lack robust “cost correctness” guardrails and regression tests for billing-impacting behavior.
- **Support and incident operations are under-tooled:** Migration questions, coin-loss concerns, and partner sentiment all point to the absence of a centralized, auditable support + comms workflow (tickets, runbooks, canonical status pages).

---

## Process Improvements (Prevention)
1. **Establish “Revenue/Funnel Smoke Tests” for ElizaCloud:** Playwright suite covering: login → API Explorer scroll → API key injection → successful test call → pricing visibility.
2. **Add “LLM Invocation Count” regression tests:** For common message patterns (URLs, attachments, previews) assert exactly-one call unless explicitly configured otherwise.
3. **Create a public Support/Triage intake path:** A single form/ticket queue for migration + Cloud bugs; auto-respond with phishing warnings and required fields.
4. **Canonical communications cadence:** Weekly shipped/next/known-issues post (mirrored to Discord + socials) and a lightweight status page for active incidents.
5. **Definition of Done update for user-facing features:** Require (a) UX QA across trackpad/Chrome/Safari, (b) error-message accuracy checks, and (c) at least one automated test for the primary workflow.