## Issue Triage — 2026-03-16

### 1) Linux embedding failures in Ollama plugin
- **Issue Title & ID:** Embeddings fail on Linux environments — `elizaos-plugins/plugin-ollama#17`
- **Current Status:** Open; community-reported; investigation pending/ongoing
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is a common dev/prod target for self-hosting)
  - **Functional Impact:** **Yes** (breaks embeddings-dependent features: retrieval, memory, semantic search)
  - **Brand Impact:** **High** (self-hosted “it doesn’t work on Linux” perception)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / Plugin System (`plugin-ollama`)
  - **Complexity:** Moderate effort (env-specific; may involve native libs, model server config, or file permissions)
- **Resource Requirements:**
  - **Required Expertise:** Linux diagnostics, Ollama runtime behavior, embeddings pipeline, Node/TS plugin debugging
  - **Dependencies:** Repro steps + environment matrix (distro, kernel, Ollama version); confirm whether issue is model-specific
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add an issue template comment requesting: distro, CPU/GPU, Ollama version, model name, plugin version, logs.
  2. Stand up CI-like repro matrix (Ubuntu LTS at minimum) and add a minimal embeddings smoke test.
  3. Determine failure class: request format, endpoint mismatch, timeouts, path/permissions, or binary incompat.
  4. Patch + release plugin version; document known-good versions and required Ollama settings.
- **Potential Assignees:** `plugin-ollama` maintainer(s); support from **Odilitime** (framework/plugin coordination)

---

### 2) Missing “production-grade” error handling patterns (agents fail ungracefully)
- **Issue Title & ID:** Standardize graceful error handling & recovery for production agents — `TRIAGE-NEW-2026-03-16-01` (needs GitHub issue)
- **Current Status:** Reported as a top production barrier in Discord; not yet tracked as a concrete GitHub issue
- **Impact Assessment:**
  - **User Impact:** **Critical** (impacts nearly all production deployments)
  - **Functional Impact:** **Partial** (core works, but brittle under real-world failures)
  - **Brand Impact:** **High** (“demo-only” perception)
- **Technical Classification:**
  - **Issue Category:** UX / Bug (reliability)
  - **Component Affected:** Core Framework (runtime orchestration, tool/plugin invocation, retries)
  - **Complexity:** Complex solution (requires conventions + possibly framework hooks)
- **Resource Requirements:**
  - **Required Expertise:** Runtime reliability, TS/Node, agent loop design, plugin boundary contracts, observability
  - **Dependencies:** Decide baseline policy: retry/backoff, circuit breakers, typed error taxonomy, user-safe messaging
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue with concrete acceptance criteria (examples: tool timeout, model rate-limit, plugin crash).
  2. Define a shared error taxonomy (transient vs permanent) and default retry/backoff behavior.
  3. Add structured error events + “receipt” logging at the framework boundary (tool call start/end/fail).
  4. Provide a “production agent template” showcasing safe fallbacks and user-facing error messaging.
- **Potential Assignees:** **Odilitime** (core), **Caesar ⚔️** (product requirements/polish), plus a core runtime contributor

---

### 3) Lack of context persistence across sessions (state continuity not guaranteed)
- **Issue Title & ID:** Conversation/context persistence across sessions — `TRIAGE-NEW-2026-03-16-02` (needs GitHub issue)
- **Current Status:** Identified as a key adoption blocker; not mapped to a single tracked issue in provided data
- **Impact Assessment:**
  - **User Impact:** **High**
  - **Functional Impact:** **Partial** (agents function, but cannot be trusted to “remember” reliably)
  - **Brand Impact:** **High** (breaks “autonomous agent” expectations)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Reliability
  - **Component Affected:** Core Framework (memory, storage, session management); possibly DB layer
  - **Complexity:** Architectural change (storage semantics + identity/session keys + data retention)
- **Resource Requirements:**
  - **Required Expertise:** Storage/DB design, identity/session modeling, backward compatibility, migration strategy
  - **Dependencies:** Align with ongoing DB refactor work (`elizaos/eliza#6509` referenced in weekly summary)
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue tying requirements to DB refactor milestones (what must persist, how to scope, retention).
  2. Define “session identity”: user id, channel id (Discord/WhatsApp/Gmail), agent id, and encryption needs.
  3. Implement minimal persistence MVP: restore last N turns + tool outcomes + agent state snapshot.
  4. Add tests: restart mid-conversation; ensure deterministic restoration behavior.
- **Potential Assignees:** **Odilitime** (core/DB direction), a DB-focused contributor; input from **Caesar ⚔️** (production requirements)

---

### 4) Localization gaps (Arabic RTL layout redesign called out as required polish)
- **Issue Title & ID:** Internationalization + RTL (Arabic) UI readiness — `TRIAGE-NEW-2026-03-16-03` (needs GitHub issue)
- **Current Status:** Raised as a concrete requirement for “enterprise trust”; no linked GitHub issue in provided data
- **Impact Assessment:**
  - **User Impact:** **Medium** (region-specific, but important for expansion)
  - **Functional Impact:** **No** (not blocking core execution)
  - **Brand Impact:** **Medium/High** (polish signal; enterprise readiness)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** GUI (dashboard/admin UI) + any templated UIs
  - **Complexity:** Moderate effort (layout mirroring, typography, component audit)
- **Resource Requirements:**
  - **Required Expertise:** Frontend i18n, RTL CSS/layout, UI QA
  - **Dependencies:** Identify which UI surface is “official” for elizaOS (dashboard/admin) and its i18n framework
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue with UI inventory and RTL acceptance checklist (bidirectional text, alignment, icons, charts).
  2. Add i18n scaffolding + locale switch; implement Arabic RTL as first “hard mode” locale.
  3. Add screenshot-based regression tests (or at minimum a QA checklist) for RTL layouts.
- **Potential Assignees:** Frontend/UI maintainer; **Caesar ⚔️** for acceptance criteria

---

### 5) Token migration transparency gaps (completion rates + unmigrated token fate) driving scam risk
- **Issue Title & ID:** Publish ai16z → elizaOS migration stats + policy for unmigrated tokens — `TRIAGE-NEW-2026-03-16-04` (needs GitHub issue / docs task)
- **Current Status:** Open questions repeatedly raised; migration confirmed closed; scam warnings circulating
- **Impact Assessment:**
  - **User Impact:** **High** (affects any holders who missed migration + community trust)
  - **Functional Impact:** **No** (not a software runtime blocker)
  - **Brand Impact:** **High** (trust, legitimacy, scam surface area)
- **Technical Classification:**
  - **Issue Category:** Documentation / Security (user safety)
  - **Component Affected:** Documentation site + announcements; possibly governance process
  - **Complexity:** Simple fix (content), Moderate effort if on-chain analytics needed
- **Resource Requirements:**
  - **Required Expertise:** On-chain/token analytics, technical writing, community comms
  - **Dependencies:** Source-of-truth data: snapshot block, migration contract addresses, final accounting policy decision
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a canonical doc page: migration closed, official links, and explicit “no late migration” statement.
  2. Add statistics: % migrated, remaining supply (as of date), and what happens to unmigrated tokens (burn/treasury/etc.).
  3. Add a “Scam Prevention” banner with examples of common scam patterns and how to verify official resources.
- **Potential Assignees:** **Odilitime** (official comms/docs direction), support from community mods (e.g., **sb**) for scam messaging

---

### 6) DeFi agent security guardrails not yet available as first-class elizaOS plugin (x402Guard)
- **Issue Title & ID:** Track integration/release plan for x402Guard (spend limits, whitelists, session keys, audit log) — `TRIAGE-NEW-2026-03-16-05`
- **Current Status:** Announced; targeted “within weeks”; needs a tracked milestone and integration contract
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (high for DeFi builders; lower for general users)
  - **Functional Impact:** **Partial** (agents can run today, but without strong transaction safety boundaries)
  - **Brand Impact:** **High** for DeFi positioning (security expectations are unforgiving)
- **Technical Classification:**
  - **Issue Category:** Security / Feature Request
  - **Component Affected:** Plugin System + Web3 integrations (Base/Solana); signing/session key flows
  - **Complexity:** Complex solution (crypto security + policy engine + audit logging + UX)
- **Resource Requirements:**
  - **Required Expertise:** Rust (proxy), blockchain transaction validation, key management (EIP-7702 session keys), plugin interface design
  - **Dependencies:** Define how agents route signing requests through proxy; policy schema; testnets; threat model
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P2** (elevate to P1 if elizaOS is actively marketing DeFi autonomy as core)
- **Specific Actionable Next Steps:**
  1. Create a tracking issue with scope: MVP chains (Base/Solana), policy primitives, audit log guarantees.
  2. Define plugin interface contract: request/response schema, failure modes, logging hooks.
  3. Recruit early testers (DeFi agent builders) and run adversarial test scenarios (prompt injection → tx attempt).
  4. Add documentation: “How to run an agent with enforced spend limits + contract whitelist.”
- **Potential Assignees:** **dzik pasnik** (author/maintainer), support from **Odilitime** (plugin registry + integration)

---

### 7) Clarify “Can I use Eliza to develop Solana dApps?” (positioning + docs)
- **Issue Title & ID:** Solana dApp development guidance/positioning — `TRIAGE-NEW-2026-03-16-06`
- **Current Status:** Asked in Discord; unanswered; likely a docs gap
- **Impact Assessment:**
  - **User Impact:** **Medium** (new builder onboarding question)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (uncertainty slows adoption)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Docs / Developer onboarding
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Solana ecosystem familiarity, elizaOS plugin capabilities, clear scoping language
  - **Dependencies:** Confirm current Solana support surface (SAID Protocol, plugins, wallet tooling)
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add a docs FAQ: what elizaOS can/can’t do for Solana dApps (agent integration vs writing full on-chain programs).
  2. Provide pointers: SAID identity, relevant plugins, example “agent interacts with Solana program” template.
- **Potential Assignees:** Docs maintainer; review by **Odilitime**

---

### 8) Define prediction accuracy threshold/quality gates for prediction-market agents (Milady integration)
- **Issue Title & ID:** Prediction-market agent quality gates (accuracy threshold, calibration, rollback rules) — `TRIAGE-NEW-2026-03-16-07`
- **Current Status:** Open question; no target threshold defined
- **Impact Assessment:**
  - **User Impact:** **Low/Medium** (depends on how many users run prediction automation)
  - **Functional Impact:** **Partial** (system exists, but without a safety/quality policy)
  - **Brand Impact:** **Medium** (wrong predictions + automated actions can harm trust)
- **Technical Classification:**
  - **Issue Category:** Feature Request / UX (safety policy)
  - **Component Affected:** Agent logic layer (decisioning), integrations (Kalshi/Polymarket/etc.)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Evaluation methodology, statistics/calibration, product risk controls
  - **Dependencies:** Access to historical data + definition of “accuracy” per market type
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Define minimal policy: confidence threshold + max stake + human-in-the-loop toggle.
  2. Add evaluation harness with backtests and reporting.
- **Potential Assignees:** **ElizaBAO** (integration context), **Caesar ⚔️** (product risk framing)

---

## Conclusion

### 1) Top highest-priority issues to address immediately (next 1–2 weeks)
1. **`plugin-ollama#17` Linux embeddings failure (P1)** — unblock core embeddings workflows for self-hosters.
2. **Graceful error handling & recovery standard (P1)** — reduce “demo-only” brittleness across all agents.
3. **Context persistence across sessions (P1)** — foundational for autonomous, long-running agents.
4. **Migration transparency + scam-prevention docs (P1)** — protect users and project trust.
5. **x402Guard tracking + integration contract (P2, consider P1 for DeFi push)** — establish credible DeFi safety boundaries.
6. **RTL/i18n readiness (P2)** — polish requirement for enterprise trust in key locales.
7. **Solana dApp guidance FAQ (P3)** — improve builder onboarding.
8. **Prediction accuracy/quality gates (P3)** — reduce risk for automated market actions.

### 2) Patterns/themes indicating deeper architectural problems
- **Production reliability is the dominant gap**: multiple discussions converge on trust signals—errors, persistence, and recoverability—suggesting the framework needs stronger **operational semantics** (what happens when tools/models fail, how state survives restarts, how outcomes are logged).
- **Security boundaries are becoming mandatory** for autonomous agents (especially DeFi): there’s a clear need for first-class patterns for **policy enforcement, key/session management, and immutable audit trails**.
- **Ecosystem maturity depends on “it just works” across environments** (Linux embeddings): cross-platform test coverage and compatibility guarantees are becoming as important as features.

### 3) Process improvements to prevent similar issues
- **Add production-readiness checklists** to new integrations/plugins: error taxonomy, retries/timeouts, structured logs/receipts, and restart/persistence behavior.
- **Introduce environment matrix smoke tests** for high-usage plugins (Linux/macOS/Windows; minimal “embeddings + chat + tool call” tests).
- **Create a “Security & Safety” review lane** for agent-wallet or agent-execution features (policy engine expectations, audit logging, session key handling).
- **Convert recurring Discord blockers into GitHub issues within 24–48 hours** with clear acceptance criteria, owners, and milestones (prevents “known but untracked” stagnation).