## Issue Triage — 2026-03-27

### 1) Supply-chain risk: `litellm-pypi` attack awareness → dependency exposure review
- **Issue Title & ID**: Supply-chain exposure review for `litellm-pypi` incident (Discord report 2026-03-24; tracking issue needed)
- **Current Status**: Reported in Discord; no confirmed impact to elizaOS repos in provided data; no formal security ticket referenced
- **Impact Assessment**
  - **User Impact**: **High** (potentially affects anyone installing/building from compromised dependency chain)
  - **Functional Impact**: **Partial** (depends on whether affected packages/versions are in use)
  - **Brand Impact**: **High** (security posture perception)
- **Technical Classification**
  - **Issue Category**: **Security**
  - **Component Affected**: **Core Framework / Dependency Management / Build Pipeline**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Node/Python dependency auditing, SBOM/SCA tooling, incident response, release management
  - **Dependencies**: Need accurate dependency inventory across `elizaos/*` and `elizaos-plugins/*`; confirm whether `litellm`/related packages are used directly or transitively
  - **Estimated Effort**: **4/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Create a **security tracking issue** in `elizaos/eliza` (and/or a central security repo) documenting the incident and response checklist.
  2. Run dependency audits across repos (lockfile + transitive): identify any `litellm*` / suspicious packages + versions.
  3. If present: pin/override to known-good versions, rotate any exposed tokens, and ship a patched release with advisory notes.
  4. Add/verify automated safeguards: Renovate/Dependabot rules, signature verification where feasible, and CI “denylist” for known malicious versions.
- **Potential Assignees**
  - **Primary**: `odilitime` (core/platform), a security-focused maintainer
  - **Support**: `trace.g` (backend/architecture), registry maintainers for plugin ecosystem coordination

---

### 2) Risky infra change: collapse prod + dev into a single staging (“one Spartan with all customer data”)
- **Issue Title & ID**: Consolidate prod/dev into staging for single Spartan instance (Discord action item 2026-03-26; tracking issue needed)
- **Current Status**: Planned/mentioned; no implementation details provided
- **Impact Assessment**
  - **User Impact**: **Critical** (could impact all hosted users if mishandled)
  - **Functional Impact**: **Yes** (outage/data-loss risk; auth/tenancy risk)
  - **Brand Impact**: **High** (trust + reliability of elizacloud ecosystem)
- **Technical Classification**
  - **Issue Category**: **Security / Reliability**
  - **Component Affected**: **Platform Infrastructure / Hosting / Data Management**
  - **Complexity**: **Architectural change**
- **Resource Requirements**
  - **Required Expertise**: DevOps/SRE, data migration, backups/restore, tenancy isolation, incident rollback planning
  - **Dependencies**: Clear environment strategy (dev/stage/prod), data classification, compliance expectations, migration/rollback runbooks
  - **Estimated Effort**: **5/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Open a **platform RFC + implementation issue** describing goals, risks, and success criteria (SLOs, RPO/RTO, isolation).
  2. Define tenancy/data boundaries: ensure “staging” is not a mixed-trust environment if it will hold customer data.
  3. Produce a migration plan: backups, validation checks, canary move, rollback steps, and an outage communication plan.
  4. Add controls: least-privilege access, audit logging, secrets separation, and environment-specific feature flags.
- **Potential Assignees**
  - **Primary**: `odilitime` (platform/core)
  - **Support**: `hatcherlabs` (hosting experience), `trace.g` (backend architecture)

---

### 3) Plugin registry gate: review/merge xProof decision-provenance plugin
- **Issue Title & ID**: Add xProof.app plugin to official registry — **PR #266** (`elizaos-plugins/registry`)
- **Current Status**: PR submitted; awaiting review/merge (per Discord 2026-03-26)
- **Impact Assessment**
  - **User Impact**: **Medium–High** (unblocks discoverability + standardized install path for provenance feature)
  - **Functional Impact**: **Partial** (feature addition; not core runtime)
  - **Brand Impact**: **Medium** (registry responsiveness signals ecosystem health)
- **Technical Classification**
  - **Issue Category**: **Feature / Documentation (ecosystem)**
  - **Component Affected**: **Plugin System / Registry**
  - **Complexity**: **Simple fix** (assuming standard registry checks pass)
- **Resource Requirements**
  - **Required Expertise**: Registry maintainership, package verification, security review of plugin metadata/install
  - **Dependencies**: CI checks, policy compliance (naming, versions, README, license)
  - **Estimated Effort**: **2/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Perform a quick security/quality review: package ownership, minimal permissions, dependency footprint.
  2. Ensure installation instructions and example usage are present and accurate.
  3. Merge PR and announce in Discord with a short “how to use” snippet.
- **Potential Assignees**
  - **Primary**: Registry maintainers; `odilitime` (if acting as maintainer)
  - **Support**: `jasonxkensei` (author) for requested changes

---

### 4) Linux embedding failures in Ollama plugin
- **Issue Title & ID**: Embedding failures on Linux — **Issue #17** (`elizaos-plugins/plugin-ollama`)
- **Current Status**: Reported and under investigation (from weekly summary reference)
- **Impact Assessment**
  - **User Impact**: **High** (Linux is a common deployment target for self-hosting)
  - **Functional Impact**: **Yes** (embeddings often power RAG/memory; breaks many agent workflows)
  - **Brand Impact**: **Medium–High** (core plugin reliability perception)
- **Technical Classification**
  - **Issue Category**: **Bug**
  - **Component Affected**: **Model Integration / Plugin System**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Linux runtime troubleshooting, Ollama API behavior, embedding model compatibility, Node native deps if any
  - **Dependencies**: Repro steps + environment matrix (distro, libc, CPU/GPU, Ollama version)
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Add a minimal reproducible example + CI matrix notes (Linux distros) to the issue.
  2. Confirm whether failure is model-specific, network/localhost binding, or response parsing.
  3. Implement robust error messages and fallback guidance (e.g., alternate embedding endpoint/model).
  4. Ship a patch release and document known-good versions.
- **Potential Assignees**
  - **Primary**: Plugin maintainers (Ollama plugin)
  - **Support**: `trace.g` (backend integration), community Linux users for verification

---

### 5) Platform direction item: “Make DegenAI the host for the platform”
- **Issue Title & ID**: DegenAI to become hosting/control-plane for platform (Discord action item 2026-03-26; tracking issue needed)
- **Current Status**: In progress conceptually; no concrete milestone/PR referenced
- **Impact Assessment**
  - **User Impact**: **Medium–High** (affects onboarding/operations and future hosted capabilities)
  - **Functional Impact**: **Partial** (platform capability/architecture; could become core for hosted users)
  - **Brand Impact**: **Medium** (clarity and stability of platform roadmap)
- **Technical Classification**
  - **Issue Category**: **Feature / Architectural**
  - **Component Affected**: **Platform / Core Services**
  - **Complexity**: **Architectural change**
- **Resource Requirements**
  - **Required Expertise**: Systems design, agent hosting, auth/tenancy, deployment orchestration, observability
  - **Dependencies**: Infra consolidation decisions; defined APIs between framework and hosting layer
  - **Estimated Effort**: **5/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Publish a short RFC: responsibilities of “DegenAI host” (scheduler, router, tool gateway, UI?).
  2. Define interfaces: how agents are provisioned, updated, and monitored.
  3. Create milestones: MVP hosting flow, security hardening, multi-tenant rollout.
- **Potential Assignees**
  - **Primary**: `odilitime`
  - **Support**: `hatcherlabs` (hosting feedback), `trace.g` (architecture)

---

### 6) Moderation/security: suspicious request to buy a wallet with transaction history
- **Issue Title & ID**: Discord trust & safety incident — wallet-with-history solicitation (Discord `💬-coders`, 2026-03-26)
- **Current Status**: Observed; no moderation outcome recorded
- **Impact Assessment**
  - **User Impact**: **Medium** (scam risk to community members)
  - **Functional Impact**: **No**
  - **Brand Impact**: **High** (safety of official channels)
- **Technical Classification**
  - **Issue Category**: **Security / Community Ops**
  - **Component Affected**: **Discord / Community**
  - **Complexity**: **Simple fix**
- **Resource Requirements**
  - **Required Expertise**: Moderation, policy enforcement, bot automation for scam detection
  - **Dependencies**: Clear community guidelines and enforcement workflow
  - **Estimated Effort**: **1/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Moderators to review logs, remove content if needed, warn/ban account depending on policy.
  2. Add a pinned message: “No buying/selling wallets, no escrow requests, report DMs.”
  3. Consider Discord automod rules for common scam phrases.
- **Potential Assignees**
  - **Primary**: `odilitime` (Moderator/Community Ops), other Discord mods/helpers (`bussynfrfr`, `swordsman816`, `jester_keri`)

---

### 7) Documentation gap: clarify Milady token relationship/support (base vs SOL milady.ai) in Milady app context
- **Issue Title & ID**: Clarify Milady token support matrix (Discord question 2026-03-25; doc issue needed)
- **Current Status**: Unanswered in discussion
- **Impact Assessment**
  - **User Impact**: **Medium** (confusion for new users; reduces successful onboarding)
  - **Functional Impact**: **No**
  - **Brand Impact**: **Medium** (perceived ambiguity/fragmentation)
- **Technical Classification**
  - **Issue Category**: **Documentation / UX**
  - **Component Affected**: **Docs / Ecosystem Communications**
  - **Complexity**: **Simple fix**
- **Resource Requirements**
  - **Required Expertise**: Product comms, ecosystem knowledge, accurate token/project boundary definitions
  - **Dependencies**: Confirmation from Milady app maintainers on what is supported
  - **Estimated Effort**: **2/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Add a FAQ entry: supported tokens, networks, official vs unofficial assets, and where to verify contracts.
  2. Provide a canonical “project relationships” page (ElizaOS framework vs elizacloud vs Milady vs third parties).
- **Potential Assignees**
  - **Primary**: `odilitime` (ecosystem clarity), Milady app maintainers (if separate)
  - **Support**: Docs contributors

---

### 8) Builder enablement gap: autonomous trading agent guidance + validated reference implementations
- **Issue Title & ID**: Autonomous trading agents onboarding/reference kit (Discord theme 2026-03-25 to 2026-03-26; issue needed)
- **Current Status**: Builders asking for feedback; no canonical guide linked
- **Impact Assessment**
  - **User Impact**: **Medium** (common use case; affects hackathon/builders)
  - **Functional Impact**: **Partial** (framework works, but lack of guidance slows adoption)
  - **Brand Impact**: **Medium**
- **Technical Classification**
  - **Issue Category**: **Documentation / UX**
  - **Component Affected**: **Docs / Examples / Templates**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Agent design patterns, risk controls, exchange integrations, backtesting/simulation, secrets management
  - **Dependencies**: Decide which data sources are “officially recommended” (e.g., Pythia MCP vs off-chain APIs)
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Publish a “Trading Agent Starter” doc: architecture, tool boundaries, paper-trading defaults, kill-switch, audit logs.
  2. Provide a reference config compatible with “ElizaOS V1 spec” patterns mentioned by builders (YAML frontmatter/character export).
  3. Add a checklist for safety: rate limits, max position sizing, and sandbox environments.
- **Potential Assignees**
  - **Primary**: `trace.g` (LLM workflows/backend), community builders (e.g., `sailorpepe.eth` if available), `odilitime` for alignment

---

## Summary: Top Highest-Priority Items (address immediately)
1. **P0** — Supply-chain exposure review for `litellm-pypi` incident (create security tracking + audit + mitigations).
2. **P0** — Infra consolidation plan (prod+dev→staging) with customer data: require RFC, controls, rollback, and SRE review.
3. **P1** — Fix/resolve **Ollama plugin Linux embedding failures** (Issue #17).
4. **P1** — **Moderation/security** response to wallet-with-history solicitation; strengthen automod + guidelines.
5. **P1** — Review/merge **registry PR #266** (xProof plugin) after lightweight security/quality checks.
6. **P1** — Define and milestone “DegenAI as host” architecture to avoid ad-hoc platform evolution.
7. **P2** — Milady token/support clarity documentation.
8. **P2** — Autonomous trading agent reference docs and safer starter templates.

---

## Patterns / Themes Suggesting Deeper Architectural Issues
- **Security maturity gaps**: supply-chain alerts and Discord scam content highlight the need for stronger security workflows across code + community.
- **Platform environment ambiguity**: collapsing environments and mixing “staging” with customer data suggests missing guardrails around tenancy/isolation and release engineering.
- **Ecosystem velocity vs. governance**: rapid plugin additions (xProof) and many third-party hosting/options increase adoption but require clearer verification, registry policies, and support boundaries.
- **High-demand vertical (trading agents) without canonical patterns**: repeated builder questions indicate the need for curated examples and safety defaults.

---

## Process Improvements (to prevent recurrence)
1. **Formalize Security Response**
   - Maintain a public security posture page + a private escalation path.
   - Add automated SCA (lockfile scanning), SBOM generation, and a documented “malicious dependency” playbook.
2. **Introduce Platform Change Control**
   - Require RFCs for environment/data migrations; define RPO/RTO, rollback plans, and approval gates.
   - Separate environments by trust level; never label a mixed-customer system as “staging” without explicit controls.
3. **Plugin Registry Governance**
   - Standard checklist for registry PRs: provenance, maintainer identity, dependency risk, minimal permissions, examples/tests.
4. **Builder Experience Improvements**
   - Publish “golden path” templates (trading, on-chain data, provenance logging).
   - Tie workshops/hackathons (Nosana challenge) to a living troubleshooting guide and known-issues dashboard.