# Issue Triage — 2026-03-29

## Scope & Data Notes
- **GitHub issue/PR feed for 2026-03-29 was not provided** in the input bundle (only Discord summaries and an older weekly GitHub recap were available). Triage below is based on:
  - Discord discussions (2026-03-26 to 2026-03-28)
  - Referenced GitHub items from the latest available weekly summary (Feb 15–21, 2026)

---

## 1) “plugin-ollama: Embedding failures on Linux environments” — elizaos-plugins/plugin-ollama **#17**
**Current Status**
- Reported/investigating (community-reported per weekly summary); no resolution details in provided data.

**Impact Assessment**
- **User Impact:** High (Linux is common for self-hosting; embeddings are foundational for RAG/memory)
- **Functional Impact:** **Partial** (agents may run but lose retrieval/memory quality or fail on embedding-dependent flows)
- **Brand Impact:** High (core “it works on my server” expectation)

**Technical Classification**
- **Category:** Bug
- **Component:** Model Integration / Plugin (Ollama embeddings)
- **Complexity:** Moderate effort (likely env/build/library mismatch, model/endpoint variance, or vector dtype issues)

**Resource Requirements**
- **Required Expertise:** Linux debugging, Node/TS runtime, Ollama API behavior, embeddings pipeline, CI reproduction
- **Dependencies:** Need reproducible Linux matrix (Docker/CI), confirm supported Ollama versions/models
- **Estimated Effort (1–5):** 3

**Recommended Priority:** **P1** (affects a core capability for many deployers; likely blocking RAG use cases)

**Specific Actionable Next Steps**
1. Reproduce in CI: add a **Linux embedding smoke test** (install Ollama, pull a known embedding model, run minimal embed call).
2. Collect diagnostics from reporters: distro, kernel, Node version, Ollama version, model name, error logs, response payload.
3. Validate embedding endpoint contract (dimensions, content-type, streaming vs non-streaming) and add defensive parsing.
4. Patch + release plugin version; document known-good versions and troubleshooting steps.

**Potential Assignees**
- **Primary:** Odilitime (core dev coordination), plugin-ollama maintainer(s)
- **Support:** trace (systems/backend + agent workflows), _rexxtor_ (coder role; if active on plugins), community Linux testers

---

## 2) “Collapse production + development into a single staging (‘Spartan’) with all customer data” — Internal infra consolidation (Discord 2026-03-26)
**Current Status**
- Planned/announced in Discord; execution details not provided.

**Impact Assessment**
- **User Impact:** Critical (risk of downtime, data exposure, performance regression if mishandled)
- **Functional Impact:** **Yes** (platform availability and data integrity)
- **Brand Impact:** High (trust + reliability; especially with “all customer data” in one place)

**Technical Classification**
- **Category:** Security / Reliability / Performance (operational risk)
- **Component:** Hosting/Platform Infrastructure (elizacloud / Spartan instance)
- **Complexity:** Architectural change (data isolation, environments, access controls)

**Resource Requirements**
- **Required Expertise:** DevOps/SRE, database ops/migrations, secrets management, access control, backup/restore, incident planning
- **Dependencies:** Clear environment strategy (staging vs prod), compliance posture, rollback plan, maintenance window comms
- **Estimated Effort (1–5):** 5

**Recommended Priority:** **P0** (high blast radius; must be designed + executed with safeguards)

**Specific Actionable Next Steps**
1. Write a one-page **Migration RFC**: goals, risks, scope, non-goals (esp. “staging” semantics with customer data).
2. Define **security boundaries**: least-privilege IAM, network segmentation, audit logs, secrets rotation plan.
3. Implement **backup/restore + disaster recovery test** before cutover.
4. Run **load/perf baseline** and capacity plan; identify noisy-neighbor risks.
5. Create a **rollback playbook** and run a tabletop incident simulation.
6. Communicate downtime expectations and data-handling posture publicly (or at least in customer channels).

**Potential Assignees**
- **Primary:** Odilitime (platform/core dev ownership)
- **Support:** Spartan Dev / Core Dev group, SRE-minded contributors (trace), trusted infra maintainers

---

## 3) “AI16Z → ElizaOS migration support: missed migration window requests” — Support/Docs gap (Discord: Marvis + earlier 2026-03-26 Q&A)
**Current Status**
- Unanswered request on 2026-03-28; earlier guidance indicates “waitlist, no guarantees.”

**Impact Assessment**
- **User Impact:** Medium (subset of token/users; but recurring)
- **Functional Impact:** No (framework still works; impacts onboarding/ownership expectations)
- **Brand Impact:** High (public perception, trust, repeated unanswered questions)

**Technical Classification**
- **Category:** Documentation / UX (support)
- **Component:** Onboarding / Migration Process (community + ops)
- **Complexity:** Simple fix (docs + canned responses) to Moderate (if tooling is needed)

**Resource Requirements**
- **Required Expertise:** Community ops, documentation, (optional) tooling for eligibility checks
- **Dependencies:** Confirm official policy + what can/can’t be done technically/legally
- **Estimated Effort (1–5):** 2 (docs) / 3 (light tooling)

**Recommended Priority:** **P1** (high brand impact; repetitive support load)

**Specific Actionable Next Steps**
1. Publish a **single canonical migration page**: deadlines, eligibility, what “waitlist” means, expected response times.
2. Add a **Discord pinned message / bot command** (`/migration`) to answer instantly.
3. Create an **intake form** for waitlist with required fields (wallet, tx hashes, etc.) to reduce back-and-forth.
4. Provide a “can’t migrate” section with alternatives (best-effort support boundaries).

**Potential Assignees**
- **Primary:** Odilitime (Migration Support role), Community Ops
- **Support:** pmairca (migration support tag present), docs contributors

---

## 4) “xProof plugin registry submission: merge & verify on-chain decision provenance plugin” — elizaos-plugins/registry **PR #266**
**Current Status**
- PR submitted; pending review/merge per Discord action items.

**Impact Assessment**
- **User Impact:** Medium (valuable to teams needing auditability; not required for all)
- **Functional Impact:** Partial (adds trust/audit features; doesn’t unblock base agents)
- **Brand Impact:** Medium (shows maturity: provenance, verification, governance)

**Technical Classification**
- **Category:** Feature / Security-adjacent (provenance)
- **Component:** Plugin System / Registry
- **Complexity:** Moderate effort (review for safety, key handling, network calls, failure modes)

**Resource Requirements**
- **Required Expertise:** Plugin review, security review, blockchain integration sanity checks, packaging/release practices
- **Dependencies:** Registry CI checks; plugin guideline compliance
- **Estimated Effort (1–5):** 2

**Recommended Priority:** **P2** (good ecosystem growth; ensure review quality)

**Specific Actionable Next Steps**
1. Perform registry checklist review: license, provenance of dependencies, minimal permissions, docs completeness.
2. Add failure-mode guidance: what happens when chain is down/slow; timeouts; retries; idempotency.
3. Confirm no sensitive data is anchored on-chain inadvertently; document what is hashed vs stored.
4. Merge + announce with example agent workflow.

**Potential Assignees**
- **Primary:** Odilitime (registry maintainer), registry reviewers
- **Support/Author:** jasonxkensei (plugin author)

---

## 5) “Third-party plugin submission & distribution process unclear (trading flow plugin inquiry)” — Registry process/docs (Discord 2026-03-27)
**Current Status**
- Dev asked how long to be included; maintainer requested “registry PR or plugin name.”

**Impact Assessment**
- **User Impact:** Medium (blocks contributors; slows ecosystem)
- **Functional Impact:** No (doesn’t break core runtime)
- **Brand Impact:** Medium (open-source contributor experience)

**Technical Classification**
- **Category:** Documentation / UX (developer experience)
- **Component:** Plugin System / Registry governance
- **Complexity:** Simple fix (docs + templates) to Moderate (automation improvements)

**Resource Requirements**
- **Required Expertise:** Maintainer workflow design, docs, GitHub templates/actions
- **Dependencies:** Agreement on acceptance criteria and SLAs (even informal)
- **Estimated Effort (1–5):** 2

**Recommended Priority:** **P2**

**Specific Actionable Next Steps**
1. Add a **“How to publish a plugin”** doc: naming, package requirements, security expectations, review stages.
2. Create GitHub **PR template** for registry submissions (checklist: tests, docs, permissions, maintainer contact).
3. Define target review time (e.g., “initial response within 72 hours”) to set expectations.
4. For the trading flow plugin specifically: request repo link + run a quick security scan and usage demo.

**Potential Assignees**
- **Primary:** Odilitime (registry/core), plugin registry maintainers
- **Support:** meowww404 (plugin author), docs contributors

---

## 6) “TaskBounty integration: autonomous task browsing/submission + crypto payouts via REST/OpenAPI” — External integration request (Discord 2026-03-28)
**Current Status**
- Announced as available; integration into Eliza agents is an action item, not yet implemented.

**Impact Assessment**
- **User Impact:** Medium (high value for power users; optional)
- **Functional Impact:** No (new capability)
- **Brand Impact:** Medium (shows real-world agent utility; also risk if insecure)

**Technical Classification**
- **Category:** Feature (with security considerations)
- **Component:** Plugin System / API Integration / Tooling
- **Complexity:** Moderate effort (auth, wallet/payment workflow, sandboxing, rate limits)

**Resource Requirements**
- **Required Expertise:** API client implementation, OpenAPI tooling, secure secret handling, wallet ops, prompt/tool safety
- **Dependencies:** Decide architecture: official plugin vs community plugin; policy for financial actions
- **Estimated Effort (1–5):** 3

**Recommended Priority:** **P2**

**Specific Actionable Next Steps**
1. Implement as a **plugin** (preferred) with strict config: API key storage, allowlist of task categories, spend limits.
2. Add **human-in-the-loop** toggle for paid actions and submissions (default ON).
3. Create OpenAPI-based client generation or minimal handcrafted client with typed schemas.
4. Provide reference agent: “bounty-worker” with safe defaults + audit logs.

**Potential Assignees**
- **Primary:** eliottre (announcer; likely domain knowledge), plugin maintainers
- **Support:** trace (workflow automation), Odilitime (governance/security gate)

---

## 7) “Orbis: agent self-subscription to external APIs (no browser/OAuth), plus MCP server support” — Integration opportunity (Discord 2026-03-28)
**Current Status**
- Shared as a tool; not yet integrated/validated within elizaOS.

**Impact Assessment**
- **User Impact:** Low to Medium (useful for rapid API access; depends on adoption)
- **Functional Impact:** No
- **Brand Impact:** Medium (if endorsed without review and it’s insecure)

**Technical Classification**
- **Category:** Feature / Security review
- **Component:** Tooling / API Integration / Secrets
- **Complexity:** Moderate effort (security evaluation + sample integration)

**Resource Requirements**
- **Required Expertise:** Security review, secrets handling, threat modeling (API key issuance), MCP familiarity
- **Dependencies:** Decide whether to “officially recommend” vs “community resources”
- **Estimated Effort (1–5):** 2–3

**Recommended Priority:** **P3** (validate before endorsing; not urgent)

**Specific Actionable Next Steps**
1. Perform a lightweight **security/threat assessment** (key issuance, revocation, scope limits, logging).
2. Build a small proof-of-concept plugin or recipe doc (three-fetch flow: browse/register/subscribe).
3. Add a docs page: “External API subscription patterns” with best practices.

**Potential Assignees**
- **Primary:** TheRedWizardDev (source), Odilitime (approval), security-minded reviewers
- **Support:** trace (MCP + workflow experience)

---

# Concluding Section

## A) Top 5–10 Highest-Priority Issues to Address Immediately
1. **P0:** Infrastructure consolidation into single “Spartan” instance with customer data (design + safeguards before execution)
2. **P1:** plugin-ollama Linux embedding failures — plugin-ollama #17 (repro, fix, ship)
3. **P1:** AI16Z → ElizaOS missed migration support/docs + Discord automation (reduce brand/support drag)
4. **P2:** Merge/review xProof plugin registry PR #266 (with security/failure-mode checks)
5. **P2:** Clarify plugin submission/distribution process (PR templates, docs, review expectations)
6. **P2:** TaskBounty integration as a gated/safe plugin (economic actions need guardrails)
7. **P3:** Orbis integration validation + security posture before endorsement

## B) Patterns/Themes Suggesting Deeper Architectural Problems
- **Ops maturity gap / environment semantics:** “Staging containing all customer data” indicates unclear separation between dev/staging/prod and increases blast radius.
- **Ecosystem growth outpacing governance:** Multiple new integrations/plugins (trading, provenance, task marketplaces, API subscription) without clearly visible standardized review/security gates.
- **Critical-path reliance on plugins for core capabilities:** Embeddings/RAG stability depends on plugin quality and CI coverage across OS matrices.

## C) Process Improvements (to Prevent Recurrence)
1. **Define environment policy** (prod/staging/dev) and minimum controls when customer data is present (access, audit, backups, DR tests).
2. **Add CI matrices for “core capability plugins”** (embeddings, vector stores, messaging) across Linux/macOS/Windows where feasible.
3. **Standardize plugin review requirements**: security checklist (secrets, payments, network calls), timeout/retry policy, and minimal test expectations.
4. **Create “support load reducers”**: pinned FAQs + Discord bot commands for recurring topics (migration, plugin submission, roadmap/updates).
5. **Introduce lightweight RFCs for high-blast-radius changes** (infra moves, payment-enabled agents), with explicit rollback plans and owner sign-off.