# Issue Triage — 2026-03-26 (elizaOS)

## 1) Audit & mitigate exposure to `litellm-pypi` supply-chain attack (Tracking)
- **Issue Title & ID:** Supply-chain risk: `litellm-pypi` compromise — ecosystem dependency audit (SEC-TRK-2026-03-24)
- **Current Status:** **Untracked / needs formal GitHub issue** (raised on Discord by DorianD; acknowledged by Odilitime)
- **Impact Assessment:**
  - **User Impact:** **Critical** (potentially affects any user/build using impacted dependency paths)
  - **Functional Impact:** **Partial** (may not break functionality immediately, but compromises integrity/execution)
  - **Brand Impact:** **High** (security posture and trust)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Core Framework / Model Integration / Dependency Supply Chain**
  - **Complexity:** **Moderate effort** (audit + mitigations + release process)
- **Resource Requirements:**
  - **Required Expertise:** AppSec, dependency management (npm/pnpm), SBOM generation, CI hardening, incident response
  - **Dependencies:** Identify whether elizaOS directly or transitively depends on affected packages; confirm versions; ensure lockfiles are authoritative
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a security tracking issue + private advisory draft (if policy supports) describing scope and actions.
  2. Inventory direct + transitive dependencies for `litellm*` across core + plugins; record exact versions from lockfiles.
  3. If impacted: pin to known-good versions, rotate any secrets used in CI/runtime, and publish a security patch release + advisory.
  4. Add CI checks: dependency diff review gates, lockfile enforcement, basic SCA (Dependabot/Renovate + audit step), and optional provenance verification where available.
  5. Communicate clearly in Discord + docs: “Are you affected?” guidance and remediation steps.
- **Potential Assignees:** **Odilitime** (core), **repo maintainers for dependencies/infra**, **DorianD** (report context), plus a designated **security lead** if one exists.

---

## 2) Ollama embeddings failing on Linux
- **Issue Title & ID:** Embedding failures on Linux environments — Ollama plugin (#17)  
  - **Repo:** `elizaos-plugins/plugin-ollama`
- **Current Status:** **Open / under investigation** (noted in weekly summary; no resolution captured)
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for self-hosting; embeddings are core for RAG/memory)
  - **Functional Impact:** **Yes** (blocks embeddings-dependent features: retrieval, long-term memory, semantic search)
  - **Brand Impact:** **Medium–High** (self-host reliability expectation)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin System / Model Integration (Embeddings)**
  - **Complexity:** **Moderate effort** (env-specific repro + dependency/runtime fixes)
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, Node/TS, Ollama API specifics, networking/HTTP client behavior, binary/arch nuances
  - **Dependencies:** Requires reliable repro matrix (distros, glibc/musl, container vs bare-metal); may depend on Ollama server version
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define a repro template: OS/distro, kernel, container runtime, Ollama version, model name, plugin version, logs.
  2. Add an automated integration test (GitHub Actions) for Linux embeddings call (mock if needed, but prefer real via service container).
  3. Verify request payload/headers and streaming vs non-streaming handling; check timeouts and IPv6/localhost resolution issues.
  4. Document known-good Ollama versions and required environment variables; ship a patch release once confirmed.
- **Potential Assignees:** **plugin-ollama maintainers**, **Odilitime** (integration help), Linux-focused community contributors (e.g., **satsbased** for coordination, not necessarily coding).

---

## 3) Security/operations readiness for Builders’ Challenge support load (Nosana × ElizaOS)
- **Issue Title & ID:** Builders’ Challenge readiness: support workflow + incident escalation (OPS-TRK-2026-03-26)
- **Current Status:** **Untracked / needs GitHub tracking** (workshops scheduled; Denis offered support)
- **Impact Assessment:**
  - **User Impact:** **High** (many new builders during challenge)
  - **Functional Impact:** **Partial** (not a code blocker, but blocks effective onboarding and issue resolution)
  - **Brand Impact:** **High** (first impressions during a high-visibility partnership)
- **Technical Classification:**
  - **Issue Category:** **UX / Documentation / Process**
  - **Component Affected:** **Developer Experience / Support Operations**
  - **Complexity:** **Simple fix → Moderate effort** (mostly coordination + docs + templates)
- **Resource Requirements:**
  - **Required Expertise:** DevRel, triage process, Discord moderation/support, documentation
  - **Dependencies:** Needs clarity on ownership (who fields which category: core vs plugins vs partner infra)
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single “Builders’ Challenge Support” doc: where to ask, required debug info, response SLAs, escalation path.
  2. Create GitHub issue templates for: installation problems, plugin bugs, model/provider issues, security concerns.
  3. Set up a rotating on-call triage owner for workshop days (Mar 26, Apr 2) with a checklist.
  4. Maintain a pinned Discord thread with known issues + workarounds (update daily during challenge).
- **Potential Assignees:** **Denis** (program coordination), **Odilitime** (engineering escalation), **satsbased** (community ops), plus one doc maintainer.

---

## 4) Documentation gap: autonomous trading agents “starter kit” + safety guidance
- **Issue Title & ID:** Docs: Autonomous trading agents on elizaOS — reference architecture + guardrails (DOC-TRK-2026-03-25)
- **Current Status:** **Untracked** (multiple builders asking; no canonical guidance)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (frequent interest; likely to grow with hackathons/challenges)
  - **Functional Impact:** **Partial** (framework works, but builders lack patterns; risk of unsafe implementations)
  - **Brand Impact:** **Medium** (perception of maturity for real-world agent use cases)
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **Core Framework + Plugins (market data, execution), Examples**
  - **Complexity:** **Moderate effort** (docs + sample project + best practices)
- **Resource Requirements:**
  - **Required Expertise:** Agent architecture, risk controls, plugin composition, secrets management, testing/simulation
  - **Dependencies:** Decide whether to recommend specific data sources (e.g., Pythia MCP, CoinGecko) and execution interfaces; ensure disclaimers
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create an “Autonomous Trading Agent” example with: paper trading mode, deterministic configs, logging, and backtest harness hooks.
  2. Add a guardrails section: position sizing, max loss/day, kill switch, rate limits, audit logs, secrets isolation.
  3. Provide integration notes for market data (including on-chain oracle option) and memory usage patterns.
  4. Curate community implementations for review (Ape Ape setup; sailorpepe.eth approach) and extract reusable patterns.
- **Potential Assignees:** **gelgit.eth** (review builder setups), **Ivan Jeremic** (data/oracle integration guidance), **Denis** (builder coordination), experienced plugin maintainers.

---

## 5) Clarify token/app support confusion (Milady app: bas Milady vs SOL milady.ai)
- **Issue Title & ID:** Docs/FAQ: Relationship between bas Milady and SOL milady.ai + app support matrix (DOC-TRK-2026-03-25-MLDY)
- **Current Status:** **Unanswered in Discord / untracked**
- **Impact Assessment:**
  - **User Impact:** **Medium** (recurring user confusion; likely many observers)
  - **Functional Impact:** **No** (not a framework blocker)
  - **Brand Impact:** **High** (public confusion around “official support” and expectations)
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **App Docs / Public Comms**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Product communication, release/status messaging, basic technical verification of supported networks/tokens
  - **Dependencies:** Requires authoritative confirmation from the team on what is supported and what is not
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a pinned FAQ entry: supported tokens/networks; what is official vs community; how support will be announced.
  2. Add an in-app (or landing page) “Support Status” section with last-updated timestamp.
  3. Define who can speak “officially” to reduce contradictory answers.
- **Potential Assignees:** **Odilitime** (authoritative technical/product confirmation), a designated **comms/docs maintainer**, **satsbased** (community pinning/policy).

---

## 6) Optional/near-term: Provide an official plugin path for oracle-based market indicators (Pythia MCP)
- **Issue Title & ID:** Plugin/Integration: Pythia MCP server connector + example agent (FEAT-TRK-2026-03-24-PYTHIA)
- **Current Status:** **Available externally; integration guidance offered** (Ivan Jeremic)
- **Impact Assessment:**
  - **User Impact:** **Medium** (high relevance for DeFi agents; reduces API-key friction)
  - **Functional Impact:** **Partial** (enables better market context; not required for base operation)
  - **Brand Impact:** **Medium** (shows robust DeFi readiness)
- **Technical Classification:**
  - **Issue Category:** **Feature Request / Documentation**
  - **Component Affected:** **Plugin System / Model Context Protocol tooling**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** MCP integration, TypeScript, data validation, caching, rate limiting, oracle semantics
  - **Dependencies:** Decide plugin registry acceptance criteria; security review for data provenance claims
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a minimal official example: “oracle-indicators agent” using Pythia MCP.
  2. Add caching + timeframe selection patterns; document failure modes (stale oracle data, chain outages).
  3. Consider publishing a plugin wrapper in `elizaos-plugins/registry` if it meets maintenance/support expectations.
- **Potential Assignees:** **Ivan Jeremic** (author), a **plugin registry maintainer**, **gelgit.eth** (review), core maintainers for standards.

---

# Top Priority Summary (fix/act immediately)
1. **P0:** Supply-chain risk tracking + mitigation for `litellm-pypi` compromise (SEC-TRK-2026-03-24)  
2. **P1:** Fix/repro **Linux embedding failures** in `plugin-ollama` (#17)  
3. **P1:** Builders’ Challenge operational readiness: support workflow + escalation (OPS-TRK-2026-03-26)  
4. **P2:** Docs: Autonomous trading agent starter kit + guardrails (DOC-TRK-2026-03-25)  
5. **P2:** Docs/FAQ: Milady token/app support clarification (DOC-TRK-2026-03-25-MLDY)  
6. **P3:** Optional: official connector/example for Pythia MCP oracle indicators (FEAT-TRK-2026-03-24-PYTHIA)

# Patterns / Themes Indicating Deeper Issues
- **Security posture needs codification:** Security concerns are being surfaced socially (Discord) but not consistently converted into trackable, auditable work items (issues/advisories, release notes).
- **Self-host reliability gaps cluster around model/embedding integrations:** Linux-specific failures suggest insufficient CI coverage for common deployment targets and model-provider permutations.
- **High builder interest in trading/DeFi but limited canonical guidance:** Repeated questions indicate missing reference architectures, safety patterns, and vetted examples.

# Process Improvement Recommendations
1. **Create a “Discord → GitHub” triage pipeline:** a lightweight rule that any security concern or widely-asked question becomes a tracking issue within 24 hours, with an owner and next action.
2. **Add CI coverage for top self-host matrices:** at minimum Linux containers for key plugins (Ollama embeddings, MCP tools), plus smoke tests that validate embeddings and basic memory workflows.
3. **Publish an “Official Statements” policy + FAQ ownership:** clearly identify who can answer product/token support questions and where the canonical answers live (pinned FAQ + docs site).
4. **Standardize incident communications:** security advisories, affected versions, remediation steps, and a postmortem template to protect user trust.