# Issue Triage — 2026-03-25

## 1) Supply-chain compromise in `litellm` 1.82.8 (PyPI) harvesting secrets
- **Issue Title & ID:** Supply-chain attack in `litellm` 1.82.8 (PyPI) — `DISC-SEC-2026-03-24-01`
- **Current Status:** Reported on Discord by DorianD; acknowledged by Odilitime; project impact not yet assessed.
- **Impact Assessment:**
  - **User Impact:** **Critical** (any developer/CI/runtime installing the malicious version is at risk)
  - **Functional Impact:** **Partial** (may not break functionality, but compromises environments)
  - **Brand Impact:** **High** (security incident association if not addressed quickly/clearly)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Dependency Management / Build & Runtime Supply Chain (potentially Core + Plugins if they depend on `litellm`)
  - **Complexity:** Moderate effort (investigation + mitigation + comms)
- **Resource Requirements:**
  - **Required Expertise:** Python packaging, SBOM/dependency auditing, CI security, incident response
  - **Dependencies:** Need definitive dependency graph across core repos/plugins; confirm whether `litellm` is direct or transitive dependency anywhere
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediate audit:** Search org-wide for `litellm` usage (direct + transitive) across `elizaos/*` and `elizaos-plugins/*`.
  2. **Pin/ban:** Add constraints to block `litellm==1.82.8` (and any other known-bad versions) in lockfiles/constraints files; republish images if applicable.
  3. **CI/CD checks:** Add Dependabot/Renovate policy or CI gate that fails builds on known-compromised packages (OSV, pip-audit, safety, osv-scanner).
  4. **Credential hygiene:** If any runners or dev machines installed the malicious build, rotate exposed secrets (SSH keys, cloud creds, K8s tokens), and invalidate long-lived tokens.
  5. **Public guidance:** Post a short security advisory in Discord + GitHub Security tab: “Do not install litellm 1.82.8; how to check; how to remediate.”
- **Potential Assignees:** Odilitime (core/devops), DorianD (reporter; security coordination), Baogerbao (CI/process support)

---

## 2) Missing security posture for dependency ingestion (preventing future supply-chain incidents)
- **Issue Title & ID:** Establish org-wide dependency security baseline (SBOM, auditing, pinning) — `OPS-SEC-2026-03-25-01`
- **Current Status:** Not tracked as a formal issue; surfaced due to `litellm` incident.
- **Impact Assessment:**
  - **User Impact:** High (reduces probability of future compromise)
  - **Functional Impact:** Partial (process/CI changes)
  - **Brand Impact:** High
- **Technical Classification:**
  - **Issue Category:** Security / Performance (CI) / Documentation (policy)
  - **Component Affected:** Core + Plugins + CI/CD
  - **Complexity:** Architectural change (process + tooling standardization)
- **Resource Requirements:**
  - **Required Expertise:** DevSecOps, CI pipelines, release engineering
  - **Dependencies:** Decision on standard tooling (e.g., Renovate + OSV + pip-audit) and supported package managers/lockfile strategy
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define a **minimum bar**: lockfiles required, dependency update cadence, “denylist” mechanism.
  2. Add automated **SBOM generation** (CycloneDX/SPDX) per release artifact.
  3. Add **OSV-based scanning** in CI for Python/Node dependencies across repos.
  4. Document an **incident playbook** (triage → comms → remediation → postmortem).
- **Potential Assignees:** Odilitime (platform), Baogerbao (CI automation), community DevOps contributors (as available)

---

## 3) Project impersonation / unclear official spokesperson risk in partnership inquiries
- **Issue Title & ID:** Clarify official comms channels to prevent impersonation/confusion — `COMM-2026-03-24-01`
- **Current Status:** Active confusion observed; Odilitime clarified a responder “does not represent the project.”
- **Impact Assessment:**
  - **User Impact:** Medium (partners/builders may contact wrong people)
  - **Functional Impact:** No
  - **Brand Impact:** High (trust and legitimacy risk)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation (community ops)
  - **Component Affected:** Community + Governance/Comms (non-code)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Community operations, documentation, Discord moderation
  - **Dependencies:** Agreement on official points-of-contact + verification method
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish an **“Official Contacts”** page (website/docs + pinned Discord message).
  2. Add a Discord **/contact** command or bot auto-reply for partnership inquiries.
  3. Establish verification: list official handles + require “Core Dev/Moderator” role for outbound partnership responses.
- **Potential Assignees:** Odilitime (owner), Denis (partner-facing for Nosana challenge), moderators/helpers (e.g., gby_17, seed_bawa1)

---

## 4) Nosana Builders’ Challenge launch support load + escalation path (starts Mar 25; workshops Mar 26 & Apr 2)
- **Issue Title & ID:** Builders’ Challenge support readiness & triage lane — `EVENT-2026-03-25-01`
- **Current Status:** Launch announced; Denis offered support; no formal support workflow documented.
- **Impact Assessment:**
  - **User Impact:** High (many builders likely to need onboarding/debug help)
  - **Functional Impact:** Partial (blocks adoption/onboarding, not core runtime)
  - **Brand Impact:** Medium–High (first impressions during challenge)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation
  - **Component Affected:** Onboarding, Developer Experience, Community Support
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Developer advocacy, troubleshooting, Discord support ops
  - **Dependencies:** Needs a single source of truth for setup steps and known issues
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a **Challenge FAQ + “Known Issues”** doc (install, common errors, logs to collect).
  2. Stand up a **#builders-support** channel with templates (environment, versions, minimal repro).
  3. Define an **escalation path** (helpers → core dev) and time windows during workshops.
  4. Capture issues into GitHub with a **“builders-challenge”** label for traceability.
- **Potential Assignees:** Denis (frontline), Odilitime (escalations), helpers/mods (e.g., dEXploarer, martin_net6)

---

## 5) Pythia MCP server integration opportunity (on-chain indicators via Chainlink/Polygon) needs compatibility guidance
- **Issue Title & ID:** Integrate/validate Pythia MCP server as supported MCP tool — `FEAT-MCP-2026-03-24-01`
- **Current Status:** Announced by Ivan Jeremic; integration assistance offered; not tracked in repo.
- **Impact Assessment:**
  - **User Impact:** Medium (primarily DeFi/agent-trading builders)
  - **Functional Impact:** No (adds capability)
  - **Brand Impact:** Medium (shows ecosystem momentum; reduces reliance on API keys)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Documentation
  - **Component Affected:** Plugin System / Model Context Protocol (MCP) integration surface
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** MCP integration, plugin packaging, TypeScript/Python depending on integration path
  - **Dependencies:** Confirm preferred plugin distribution path (registry listing vs external); security review (oracle assumptions, RPC usage)
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a lightweight **integration PR**: example agent/tool config showing how to call the MCP server.
  2. Add a **docs page**: “On-chain market indicators without API keys (Pythia MCP)”.
  3. Run a **security sanity check**: dependency audit, RPC endpoints, rate/abuse limits.
  4. Decide whether to **list in plugin registry** (if applicable) with clear maintenance ownership.
- **Potential Assignees:** Ivan Jeremic (owner/integration), Odilitime (framework alignment), community plugin maintainers

---

## 6) Documentation gap: “No whitepaper” causes repeated questions; official references need centralization
- **Issue Title & ID:** Consolidate canonical docs pointers (roadmap + arXiv) and reduce repeated “whitepaper” queries — `DOCS-2026-03-22-01`
- **Current Status:** Answer provided ad hoc in Discord (roadmap repo + arXiv paper); not standardized in docs/FAQ.
- **Impact Assessment:**
  - **User Impact:** Medium (frequent newcomer friction)
  - **Functional Impact:** No
  - **Brand Impact:** Medium (perception of missing/unclear documentation)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs site, README, Discord onboarding
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, docs tooling
  - **Dependencies:** None
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a prominent docs section: **“Whitepaper?” → Roadmap + arXiv + architecture overview**.
  2. Pin the answer in Discord and add to bot auto-responses for FAQ triggers.
- **Potential Assignees:** Odilitime, Mr. Ronnie Debryne (docs help), docs contributors

---

## 7) Milady app launch ambiguity creating repeated timeline questions (expectation management)
- **Issue Title & ID:** Improve release communication for Milady app (status page / milestones) — `COMM-PROD-2026-03-23-01`
- **Current Status:** “Launching when ready” communicated; no public milestone or status indicator; repeated inquiries.
- **Impact Assessment:**
  - **User Impact:** Medium (community uncertainty)
  - **Functional Impact:** Partial (doesn’t break core framework; affects adoption/engagement)
  - **Brand Impact:** Medium (perceived lack of transparency)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Process
  - **Component Affected:** Product release process, community comms
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Release management, community ops
  - **Dependencies:** Internal readiness criteria; decision on what can be shared publicly
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a **public checklist** (e.g., “alpha → beta → launch”) without dates if necessary.
  2. Provide a **weekly status note** (what changed, what’s blocked).
  3. Create a single **launch announcement channel** and redirect questions there.
- **Potential Assignees:** Odilitime, moderators/community ops

---

## 8) `plugin-ollama` Linux embedding failures (community-reported) still under investigation
- **Issue Title & ID:** Embedding failures on Linux environments — `elizaos-plugins/plugin-ollama#17`
- **Current Status:** Identified and “began investigating” (per latest available weekly summary); current resolution unknown.
- **Impact Assessment:**
  - **User Impact:** Medium (Linux is common for self-hosters)
  - **Functional Impact:** Partial (embeddings often power memory/RAG; may degrade core agent capability for affected users)
  - **Brand Impact:** Medium
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / Plugin (Ollama)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, embeddings pipeline, Ollama integration details
  - **Dependencies:** Need reproducible environment details and logs from affected users
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Request/collect **minimal repro** (distro, kernel, Ollama version, model, GPU/CPU, error logs).
  2. Add **diagnostic logging** around embedding calls and model availability.
  3. Document known working configurations and provide a fallback path if embeddings fail.
- **Potential Assignees:** Plugin maintainers; community Linux-focused contributors; Odilitime for escalation

---

# Highest-Priority Summary (Top 5–10 to address immediately)
1. **P0:** `DISC-SEC-2026-03-24-01` — `litellm` 1.82.8 supply-chain compromise: audit, block, rotate secrets, publish advisory.
2. **P1:** `OPS-SEC-2026-03-25-01` — Formalize dependency security baseline (SBOM + scanning + incident playbook).
3. **P1:** `COMM-2026-03-24-01` — Prevent impersonation/confusion: publish official contacts and comms policy.
4. **P1:** `EVENT-2026-03-25-01` — Nosana Builders’ Challenge support readiness: support channel, FAQ, escalation, GitHub labeling.
5. **P2:** `elizaos-plugins/plugin-ollama#17` — Linux embedding failures: repro + fix path.
6. **P2:** `DOCS-2026-03-22-01` — Centralize “no whitepaper” FAQ + canonical links.
7. **P2:** `COMM-PROD-2026-03-23-01` — Milady app status communications to reduce repeated uncertainty.
8. **P2:** `FEAT-MCP-2026-03-24-01` — Pythia MCP integration guidance + security review.

# Patterns / Themes Indicating Deeper Issues
- **Supply-chain exposure + missing standardized safeguards:** The `litellm` incident highlights the need for consistent org-wide dependency policies, scanning, and release hygiene.
- **Support/comms scalability gaps during events:** Partnerships and challenges drive bursts of support needs; without structured intake and escalation, core dev time gets fragmented.
- **Documentation discoverability issues:** Repeated “whitepaper” and launch-timeline questions suggest onboarding information isn’t centralized or prominent enough.
- **Ecosystem growth outpacing governance signals:** Confusion about who represents the project suggests the project needs clearer public-facing governance/comms boundaries.

# Process Improvement Recommendations
1. **Security:** Add automated dependency scanning (OSV) + SBOM generation in CI for every repo; maintain a denylist for known-compromised versions.
2. **Incident Response:** Create a lightweight security incident runbook (roles, steps, comms templates, credential rotation checklist).
3. **Event Triage Pipeline:** For hackathons/challenges, create a dedicated intake label set + support channel + “known issues” page before launch day.
4. **Comms Governance:** Maintain an “Official Representatives & Contacts” page and pin it in Discord; require moderator/core roles for partnership replies.
5. **Docs UX:** Add a “Start Here” landing page that answers the top recurring questions (whitepaper, roadmap, papers, official links, current status).