# Issue Triage — 2026-03-10

## 1) Model configuration inconsistent across different agents (DISCORD-2026-03-09-01)
- **Current Status:** Reported on Discord by BinaryCookies; no linked GitHub issue found (needs creation).
- **Impact Assessment:**
  - **User Impact:** High (commonly hit when running multiple agents/profiles)
  - **Functional Impact:** Partial (agents run, but with wrong/undesired model selection and behavior)
  - **Brand Impact:** High (appears “unreliable / hard to configure”)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Core Framework (agent runtime), Model Integration (provider/model selection), Configuration system
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime/config layering; provider adapters; debugging config precedence
  - **Dependencies:** Clarify intended config precedence (global vs agent vs plugin vs env vars); need reproducible example
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue with a minimal repro (two agents with different desired models; show actual resolution).
  2. Audit config resolution order (env → global config → agent config → session overrides).
  3. Add debug logging flag: “resolved model/provider per agent at startup”.
  4. Add a config validation step that warns when multiple conflicting keys are set.
  5. Add docs snippet: “How to set model per agent” + common pitfalls.
- **Potential Assignees:** Shaw Walters (core), core maintainers; BinaryCookies (repro/testing)

---

## 2) Embedding failures on Linux in `plugin-ollama` (elizaos-plugins/plugin-ollama **#17**)
- **Current Status:** Known issue; “investigating” per weekly summary (Feb 15–21, 2026).
- **Impact Assessment:**
  - **User Impact:** Medium–High (Linux is common for self-hosting; embeddings are foundational for RAG)
  - **Functional Impact:** Yes (blocks embeddings/RAG workflows for Ollama users on Linux)
  - **Brand Impact:** Medium (self-host story weakened; “works on my machine” perception)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System, Model Integration (Ollama embeddings)
  - **Complexity:** Moderate effort (possibly environment/ABI or request formatting differences)
- **Resource Requirements:**
  - **Required Expertise:** Node/TS HTTP client; Ollama embeddings API; Linux environment debugging
  - **Dependencies:** Confirm Ollama versions, embedding model names, and response parsing; need CI coverage on Ubuntu
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect matrix: distro, kernel, Node version, Ollama version, embedding model used, error logs.
  2. Add an integration test (GitHub Actions Ubuntu) hitting Ollama in a container (or mocked API contract test).
  3. Verify request payload shape + content-type; harden parsing and error handling.
  4. Document known-good versions and a troubleshooting section.
- **Potential Assignees:** plugin-ollama maintainer(s); contributors with Linux infra experience (e.g., NerdPanic for repro/CI)

---

## 3) Lack of a functional Google voice plugin (alternative to ElevenLabs costs) (DISCORD-2026-03-09-02)
- **Current Status:** Feature request from BinaryCookies; no linked GitHub issue found (needs creation/spec).
- **Impact Assessment:**
  - **User Impact:** Medium (voice is a popular “wow” feature; costs block experimentation)
  - **Functional Impact:** Partial (core works; voice capability limited/expensive)
  - **Brand Impact:** Medium (cost complaints in community channels)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Plugin System, Model Integration (TTS)
  - **Complexity:** Moderate effort (auth, quotas, streaming audio, SSML/voices)
- **Resource Requirements:**
  - **Required Expertise:** Google Cloud TTS API (or other Google voice stack), auth, plugin packaging
  - **Dependencies:** Decide target (Google Cloud Text-to-Speech vs other Google voice service); key management patterns
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P2** (raise to P1 if voice is a launch-critical capability)
- **Specific Actionable Next Steps:**
  1. Create GitHub issue + spec: required features (streaming/non-streaming, voice selection, caching, cost controls).
  2. Implement minimal plugin: `speak(text, voice, format)` with env-based credentials.
  3. Add cost guardrails: per-day character cap + logging.
  4. Provide example agent + docs: switching providers (ElevenLabs ↔ Google).
- **Potential Assignees:** Plugin contributors (community); BinaryCookies (acceptance testing); possibly LillAnders (plugin ecosystem)

---

## 4) Scheduled/timed agent-to-agent interactions in Discord not productized (DISCORD-2026-03-09-03)
- **Current Status:** Workaround shared by community member “s” pointing to examples and milady trigger systems; not first-class/documented.
- **Impact Assessment:**
  - **User Impact:** Medium (common automation use case)
  - **Functional Impact:** Partial (possible via custom code; not easy/standard)
  - **Brand Impact:** Medium (framework appears “code-only” for basic scheduling)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Documentation
  - **Component Affected:** Plugin System (Discord), Core Framework (scheduler/trigger runtime), Examples/Docs
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript; Discord plugin/event loop; job scheduling patterns; safe concurrency
  - **Dependencies:** Decide canonical scheduler (cron-like, interval jitter, persistence); coordinate with existing “autonomous” examples
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Convert the known workaround into an official example: “discord-timer-conversation”.
  2. Define a small scheduler interface (in-memory first; optional persistence later).
  3. Add guardrails: rate limits, backoff, opt-in channel allowlist.
  4. Document mapping from `TWITTER_POST_INTERVAL_MIN/MAX` to Discord timer config.
- **Potential Assignees:** “s” (example author), Discord plugin maintainers, Shaw (review)

---

## 5) Unclear adapter development & distribution path (DISCORD-2026-03-09-04)
- **Current Status:** Question by meowww404 unanswered; suggests missing guidance for plugin/adaptor authors.
- **Impact Assessment:**
  - **User Impact:** Medium (blocks ecosystem growth; fewer third-party adapters)
  - **Functional Impact:** No (core works), but slows adoption and contributions
  - **Brand Impact:** Medium (perception: unclear “how to build on this”)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Plugin System, Registry, Developer Docs
  - **Complexity:** Simple fix (docs) to Moderate (tooling improvements)
- **Resource Requirements:**
  - **Required Expertise:** Plugin packaging, registry submission, semantic versioning, release automation
  - **Dependencies:** Current registry policies and CI requirements
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a doc page: “Build an adapter/plugin + publish to registry + distribution best practices”.
  2. Provide a template repo (cookiecutter-like) with CI, lint, tests, release workflow.
  3. Add “support matrix” guidance (Node versions, OS, required env vars).
- **Potential Assignees:** Registry maintainers; documentation contributors; community plugin authors

---

## 6) Community-facing communication gaps: airdrop plan, use cases, listings, buybacks (DISCORD-2026-03-09-05)
- **Current Status:** Raised by paolin; recurring concern across multiple days; no canonical source-of-truth referenced.
- **Impact Assessment:**
  - **User Impact:** High (broad community confusion; repeated questions)
  - **Functional Impact:** No (not a code blocker)
  - **Brand Impact:** **High** (FUD, trust erosion, adoption friction)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (project communications)
  - **Component Affected:** Docs site, Release/Announcement process, Governance/comms
  - **Complexity:** Moderate effort (coordination + publication cadence)
- **Resource Requirements:**
  - **Required Expertise:** Technical writing + project management; ability to confirm facts with core team
  - **Dependencies:** Leadership approval; up-to-date internal roadmap/decisions
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single “Project Status & FAQ” page (versioned, dated) covering: use cases, roadmap, airdrop status, listings policy, buyback stance.
  2. Set a weekly cadence for updates (even if “no change”).
  3. Pin the FAQ in Discord and link from docs homepage.
  4. Add an “Announcements changelog” to reduce rumor-driven narratives.
- **Potential Assignees:** Odilitime (project updates), Shaw (technical roadmap alignment), docs maintainers

---

## 7) Need clearer guidance on multi-chain focus (Solana + BSC) and related developer paths (DISCORD-2026-03-08-01)
- **Current Status:** Clarified in chat (“Solana and BSC are active”); not captured as developer-facing guidance.
- **Impact Assessment:**
  - **User Impact:** Medium (builders need to know what to target)
  - **Functional Impact:** No
  - **Brand Impact:** Medium (mixed messaging harms credibility)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Docs / Ecosystem guides
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Technical writing; awareness of current chain integrations and plugins
  - **Dependencies:** Confirm official stance and timelines
  - **Estimated Effort (1–5):** 1
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add “Supported chains” page with status labels: active / experimental / planned.
  2. Link to relevant plugins (SAID, exchanges, wallets) and examples.
- **Potential Assignees:** Docs maintainers; ecosystem maintainers

---

## 8) Plugin ecosystem reliability: ensure registry/review automation remains unblocked (reference: registry issue **#259** was previously critical)
- **Current Status:** Previously fixed (per weekly summary); recommend monitoring to prevent regression.
- **Impact Assessment:**
  - **User Impact:** Medium (affects contributors and plugin velocity)
  - **Functional Impact:** Partial (ecosystem growth blocked when broken)
  - **Brand Impact:** Medium (contributors churn if PRs can’t land)
- **Technical Classification:**
  - **Issue Category:** Performance / DevEx
  - **Component Affected:** Plugin Registry CI/review automation
  - **Complexity:** Moderate effort (hardening + alerting)
- **Resource Requirements:**
  - **Required Expertise:** GitHub Actions; CI security for forks; automation scripting
  - **Dependencies:** Registry workflows; permission model
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add canary PR checks or scheduled workflow tests for fork PR validation.
  2. Add maintainers-oncall notification when the review bot fails.
  3. Document contributor troubleshooting steps.
- **Potential Assignees:** Registry maintainers; DevOps-minded contributors (e.g., NerdPanic)

---

# Top Highest-Priority Issues to Address Immediately (Top 5–10)
1. **P1:** Model configuration inconsistent across agents (DISCORD-2026-03-09-01)  
2. **P1:** `plugin-ollama` Linux embedding failures (plugin-ollama #17)  
3. **P1:** Communication gaps: airdrop/use cases/listings/buybacks (DISCORD-2026-03-09-05)  
4. **P2:** Stabilize/monitor plugin registry automation to prevent contributor blocking (post-#259 hardening)  
5. **P2:** Scheduled Discord agent timers (productize example + minimal scheduler interface)  
6. **P2:** Google voice plugin alternative to ElevenLabs (cost-sensitive voice path)  
7. **P2:** Adapter development & distribution documentation (unblock ecosystem growth)  
8. **P3:** Multi-chain focus documentation (Solana + BSC clarity)

---

# Patterns / Themes Indicating Deeper Issues
- **Configuration & “it just works” gaps:** Model selection confusion suggests config precedence and validation need tightening.
- **Ecosystem maturity vs. demand:** Requests for scheduling, voice alternatives, and adapter distribution indicate users want higher-level “batteries included” capabilities, not just primitives.
- **Operational credibility is now a product dependency:** Repeated comms concerns show that lack of a single source of truth materially impacts adoption and contributor momentum.
- **Platform parity risks:** Linux embedding failures highlight the need for OS/CI coverage for self-hosted pathways.

---

# Process Improvements (Prevention)
1. **Introduce a “Discord → GitHub” intake workflow:** Any repeated Discord issue gets a GitHub issue within 24 hours with owner + reproduction checklist.
2. **Add config observability:** Standard debug output for resolved provider/model per agent; config validation with actionable warnings.
3. **CI matrix for key plugins:** Minimum Ubuntu + Node LTS integration coverage for model/embedding plugins; publish support matrices.
4. **Docs as a release artifact:** Each sprint ships at least one “How-to” aligned with the most common Discord questions (scheduling, voice, plugin publishing).
5. **Weekly public status post (dated):** Roadmap deltas, airdrop state, and major technical progress—reduce rumor load and repeated support churn.