## Issue Triage — 2026-02-24

### 1) [Bug] URL in message triggers duplicate LLM calls — processed as both text and attachment (webapp) — **#6486 (elizaos/eliza)**
- **Current Status:** Open (reported, reproducible)
- **Impact Assessment:**
  - **User Impact:** High (any webapp user sending URLs)
  - **Functional Impact:** Partial (core chat works but produces duplicated outputs + double cost)
  - **Brand Impact:** High (visible “broken” behavior; unexpected billing/cost spikes)
- **Technical Classification:**
  - **Category:** Bug / Performance
  - **Component Affected:** Webapp + Server message ingestion / attachments pipeline + SSE streaming
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, server message pipeline, attachment parsing, SSE streaming
  - **Dependencies:** None, but validate against any attachment preview/link unfurl feature
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add a failing integration test: “message containing URL results in exactly one LLM run + one streamed response.”
  2. Instrument message pipeline to log/trace how the same URL becomes both `text` and `attachment`.
  3. Enforce a single canonical representation (either:
     - treat URLs strictly as text unless user explicitly uploads/link-attaches, or
     - dedupe attachments generated from text URLs before LLM dispatch).
  4. Ensure SSE “done” event corresponds to exactly one generation per user message.
  5. Add cost guard metric to detect duplicate dispatch (e.g., same messageId triggering >1 run).
- **Potential Assignees:**
  - **odilitime** (token/cost concerns; framework-level behavior)
  - **borisudovicic** (cloud/chat pipeline familiarity)
  - **lalalune** (runtime/message flow changes if needed)

---

### 2) Context/token bloat leading to 200k token limits (recent messages + reflections/providers) — **DISCORD-CTX-BOUNDS-2026-02-23**
- **Current Status:** Known ongoing problem (root cause suspected: recent messages + reflections accumulation; not actions)
- **Impact Assessment:**
  - **User Impact:** High (power users, many plugins; increasingly common as ecosystem grows)
  - **Functional Impact:** Yes (hard-fails at context limits; can block agent execution)
  - **Brand Impact:** High (perceived inefficiency/instability; cost blowups)
- **Technical Classification:**
  - **Category:** Performance
  - **Component Affected:** Plugin-bootstrap providers, reflection evaluator, context assembly, provider loading (MCP/METATOOL patterns discussed)
  - **Complexity:** Complex solution (needs design + guardrails)
- **Resource Requirements:**
  - **Required Expertise:** Prompt/context architecture, token accounting, plugin-bootstrap internals, retrieval/filtering (vector/BM25), evaluation pipeline
  - **Dependencies:** Coordinate with ongoing optimizations (e.g., action/provider filtering work; bootstrap optimizations)
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add **token budget enforcement** at context-build time (hard caps per section: recentMessages/reflections/providers).
  2. Implement **summarization/compaction** for reflections and long recent message windows (store compacted summaries in memory).
  3. Introduce **adaptive retrieval**: only load provider details at needed granularity; consider metatool/provider pattern only if it reduces time-to-fix.
  4. Add telemetry: token breakdown by section for every run; emit warnings before failure thresholds.
  5. Create a “Many plugins” regression scenario in CI to prevent reintroducing bloat.
- **Potential Assignees:**
  - **odilitime** (actively investigating token usage)
  - **Stan ⚡ (standujar)** (offered framework-level solution sharing)
  - **lalalune** (runtime architecture + action/provider filtering direction)

---

### 3) DB refactor / migration guardrails for v2.0.0 (auto-migration removal; enforce upgrade path) — **PR-context: #6521 (elizaos/eliza)**
- **Current Status:** In-flight refactor work; auto-migration removal discussed; risk of confusing/broken upgrades from older versions
- **Impact Assessment:**
  - **User Impact:** Medium→High (anyone upgrading from older deployments; ops teams)
  - **Functional Impact:** Partial (upgrades may fail or silently misconfigure without clear error path)
  - **Brand Impact:** High (upgrade pain = adoption friction for v2)
- **Technical Classification:**
  - **Category:** Bug / UX (upgrade experience) / Documentation
  - **Component Affected:** Core DB layer, plugin-sql, migration tooling, release/upgrade docs
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** DB migrations, TypeScript core, RLS/data isolation concepts, release engineering
  - **Dependencies:** Coordination with “great db refactor PR” (Odilitime) and RLS preservation
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Implement explicit version gate: if DB schema < required baseline, **fail fast with actionable instructions** (e.g., “upgrade to 1.6.x first”).
  2. Provide a documented migration path (supported source versions; step-by-step).
  3. Add CI coverage: simulate upgrade from last supported v1 baseline into v2 path.
  4. Ensure RLS behavior parity (noted as preserved in refactor) is validated with tests.
- **Potential Assignees:**
  - **Stan ⚡ (standujar)** (authored/leading #6521 context)
  - **odilitime** (parallel refactor; RLS continuity)
  - **anchapin** (defensive checks + guardrails)

---

### 4) Embedding failures on Linux in Ollama plugin — **#17 (elizaos-plugins/plugin-ollama)**
- **Current Status:** Open / under investigation (community-reported)
- **Impact Assessment:**
  - **User Impact:** Medium (Linux self-hosters are a key cohort for local-model usage)
  - **Functional Impact:** Yes (breaks embeddings → retrieval, memory search, tool routing quality)
  - **Brand Impact:** Medium (plugin reliability reflects on ecosystem)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Model Integration (Ollama embeddings), platform-specific (Linux)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Node/TS plugin dev, Linux env debugging, Ollama API specifics
  - **Dependencies:** Repro details (exact distro, Ollama version, model, request payload)
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Request/record full repro matrix (OS, arch, Ollama version, model name, endpoint, logs).
  2. Add a minimal Linux CI job (or containerized integration test) to hit embeddings endpoint.
  3. Validate request formatting (content-type, JSON shape) and response parsing on Linux builds.
  4. Implement clearer error messages + fallback behavior (disable embeddings gracefully).
- **Potential Assignees:**
  - **mbatini** (reporter; can validate repro)
  - **lalalune** (model integration direction)
  - **odilitime** (ecosystem stability focus)

---

### 5) Token migration confusion + scam risk (DM links / fake tickets) — **DISCORD-SEC-MIGRATION-2026-02-23**
- **Current Status:** Active community confusion; scam vectors observed; unclear “official” flow for missed migration
- **Impact Assessment:**
  - **User Impact:** High (broad community exposure; repeated questions)
  - **Functional Impact:** No (not core runtime) but impacts onboarding/retention
  - **Brand Impact:** **High** (trust + safety perception; can cause irreversible user loss)
- **Technical Classification:**
  - **Category:** Security / UX / Documentation
  - **Component Affected:** Community support workflows, official comms, any “ticket” process
  - **Complexity:** Simple fix (process + documentation), moderate if building tooling
- **Resource Requirements:**
  - **Required Expertise:** Security comms, moderation ops, documentation, basic web/support tooling
  - **Dependencies:** Decide official support channel + policy for missed migration
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single canonical “Migration & Safety” page: **no DMs**, no ticket links, official domains only.
  2. Pin message in Discord channels and add an auto-mod response to keywords (“migration”, “ticket”, “wallet address”).
  3. Provide a clearly documented “missed deadline” policy (even if “no longer supported”, state it explicitly).
  4. Add verification guidance: how to confirm official announcements and links.
- **Potential Assignees:**
  - **borisudovicic** (project coordination)
  - **Omid Sa** (community safety guidance; coordinate with mods)
  - **odilitime** (public-facing clarity; already addressing in chat)

---

### 6) OpenAI provider: support custom endpoint URL (OpenAI-compatible services) — **#6490 (elizaos/eliza)**
- **Current Status:** Open (feature request)
- **Impact Assessment:**
  - **User Impact:** Medium (growing set of users on OpenAI-compatible hosts)
  - **Functional Impact:** Partial (blocks certain deployments; forces provider forks)
  - **Brand Impact:** Medium (integration flexibility is expected in agent frameworks)
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component Affected:** Model Integration (OpenAI provider), configuration/env handling
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Provider configuration, HTTP client, env schema
  - **Dependencies:** Confirm how configs propagate across TS/Rust/Python in v2 direction
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or equivalent) with validation and safe default.
  2. Ensure it works across chat + embeddings + any tool endpoints used.
  3. Document examples for common providers (SiliconFlow, etc.).
  4. Add a unit test asserting base URL overrides the default.
- **Potential Assignees:**
  - **lalalune** (core/provider direction)
  - **odilitime** (integration + docs alignment)

---

### 7) Openclaw agent unexpectedly responding in Korean (localization/config leakage) — **DISCORD-BUG-LOCALE-2026-02-21**
- **Current Status:** Reported, untriaged (needs repro + logs)
- **Impact Assessment:**
  - **User Impact:** Low→Medium (likely configuration-specific, but alarming)
  - **Functional Impact:** Partial (conversation quality breaks; may indicate prompt/system mix-up)
  - **Brand Impact:** Medium (looks like “agent is possessed”/unreliable)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** Prompt assembly, locale detection, memory contamination, model/system prompts
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Prompt debugging, memory inspection, runtime logging
  - **Dependencies:** Need conversation logs + config snapshot + model used
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Collect repro artifacts: last 50 messages, character file, model/provider, any translation plugins.
  2. Add debug flag to print detected locale + language constraints injected into system prompt.
  3. Check for memory poisoning from scraped content or attachments.
  4. If confirmed, add safeguards: explicit language policy and/or per-room language setting.
- **Potential Assignees:**
  - **odilitime** (runtime/prompt behavior)
  - **borisudovicic** (agent prompt iteration experience)

---

### 8) Plugin guidance: image generation plugin confusion (plugin-image-generation vs plugin-bootstrap) — **DISCORD-DOCS-PLUGINS-IMG-2026-02-23**
- **Current Status:** Ongoing user confusion; ad-hoc answers in Discord
- **Impact Assessment:**
  - **User Impact:** Medium (common “how do I do images?” question)
  - **Functional Impact:** No (workarounds exist)
  - **Brand Impact:** Medium (perceived fragmentation/staleness of plugins)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component Affected:** Plugin System documentation, starter templates, registry metadata
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Docs + plugin ecosystem knowledge
  - **Dependencies:** Confirm current recommended plugin(s) and maintenance status
  - **Estimated Effort:** 1/5
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add a “Image Generation” section to docs: recommended plugin(s), minimal config, example action usage.
  2. Mark deprecated/legacy plugins clearly in registry/docs.
  3. Update `plugin-bootstrap` README with a discoverable image action example (if not already).
- **Potential Assignees:**
  - **odilitime** (already guiding users)
  - **anchapin** (small, high-leverage doc/robustness changes)

---

### 9) Revenue-critical engineering: Eliza App onboarding + billing not complete (blocks charging) — **DISCORD-PROD-BILLING-2026-02-23**
- **Current Status:** Declared top business priority (needs completion to start charging)
- **Impact Assessment:**
  - **User Impact:** Medium (customers waiting), but **business impact critical**
  - **Functional Impact:** Partial (product usable, but monetization blocked)
  - **Brand Impact:** High (professionalism + ability to sustain OSS work)
- **Technical Classification:**
  - **Category:** Feature / UX
  - **Component Affected:** Eliza App (backend/shared with hosted Milady), auth/onboarding, billing integration
  - **Complexity:** Complex solution (depends on existing billing architecture)
- **Resource Requirements:**
  - **Required Expertise:** Web backend, auth, billing/payments, product UX
  - **Dependencies:** Decide billing provider, pricing model, account lifecycle, and telemetry
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P0** (given stated restructuring + revenue imperative)
- **Specific Actionable Next Steps:**
  1. Define the minimal paid funnel (signup → onboarding complete → paywall → successful payment → entitlement).
  2. Implement entitlement checks server-side (avoid client-only gating).
  3. Add observability: funnel conversion events and billing failure reasons.
  4. Ship a “basic paid tier” quickly; defer advanced tiers.
- **Potential Assignees:**
  - **Shadow** (backend work on Eliza app + Milady per Discord)
  - **s** (project lead focus per restructuring)
  - **borisudovicic** (launch coordination; infra readiness)

---

## Immediate Focus Summary (Top 5–10)
1. **#6486 Duplicate LLM calls on URL messages (webapp)** — **P0**
2. **DISCORD-CTX-BOUNDS Context/token bloat hitting 200k limits** — **P0**
3. **DISCORD-PROD-BILLING Eliza App onboarding + billing completion** — **P0**
4. **DB refactor migration guardrails (PR-context #6521 / v2 upgrade path)** — **P1**
5. **#17 plugin-ollama Linux embeddings failure** — **P1**
6. **DISCORD-SEC-MIGRATION Scam risk + migration confusion** — **P1**
7. **#6490 Custom OpenAI endpoint support** — **P2**
8. **DISCORD-BUG-LOCALE Openclaw responding in Korean** — **P2**
9. **DISCORD-DOCS-PLUGINS-IMG Image generation plugin guidance** — **P3**

---

## Patterns / Themes Indicating Deeper Architectural Issues
- **Unbounded context assembly** (providers/reflections/recent messages) is becoming a systemic reliability risk as plugins scale; token budgeting and retrieval-based loading need to be first-class.
- **Upgrade/migration ergonomics lagging behind refactors** (DB + v2 direction) increases adoption friction and support load.
- **Cost regressions are user-visible** (duplicate LLM calls, token bloat) and directly conflict with the new revenue focus—cost controls need automated detection.
- **Ecosystem/plugin sprawl without clear “recommended paths”** leads to repeated Discord support and inconsistent user setups.

---

## Process Improvements (Prevention)
1. **Add “cost & token regression” CI gates**: scenario tests that fail if token usage per step exceeds thresholds or if a single message triggers >1 LLM run.
2. **Introduce a standard “Context Budget Contract”** for providers/evaluators (hard caps + compaction rules) and require new providers to declare their expected token footprint.
3. **Upgrade-path policy + tooling**: a documented supported upgrade matrix and explicit runtime checks with actionable errors (especially DB/schema).
4. **Security communications playbook**: pinned anti-scam guidance, official-link verification, and automated moderation responses for common scam keywords.
5. **Plugin recommendation index**: maintain a single “blessed” list for common tasks (images, embeddings, workflows) to reduce confusion and support churn.