# Issue Triage — 2026-03-06

## 1) Embeddings fail on Linux environments (Ollama plugin) — elizaos-plugins/plugin-ollama #17
- **Current Status:** Open; “identified and began investigating” (per weekly summary)
- **Impact Assessment:**
  - **User Impact:** **High** (Linux devs/operators; common server OS)
  - **Functional Impact:** **Partial** (blocks embeddings/RAG workflows; chat may still work)
  - **Brand Impact:** **High** (perceived instability of model integrations)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Model Integration → `plugin-ollama` embeddings
  - **Complexity:** **Moderate effort** (environment-specific; may require upstream coordination)
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime/debugging, Ollama embeddings API behavior, Node/TS plugin internals, dependency/native library troubleshooting
  - **Dependencies:** Possibly Ollama version/embedding model availability; CI coverage on Linux; reproducible test case
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a minimal reproduction script + expected output to the issue (model name, Ollama version, OS/distro, CPU/GPU, command line).
  2. Confirm whether failure is: model pull, HTTP API mismatch, JSON schema, streaming parsing, or vector dimension handling.
  3. Add Linux CI job to run an embeddings smoke test (even if mocked) and/or a contract test against a pinned Ollama container.
  4. Implement improved error surfacing (log raw Ollama error payload; include remediation hints).
  5. Publish compatibility matrix (Ollama versions × embedding models) in plugin README once fixed.
- **Potential Assignees:** `plugin-ollama` maintainer(s), **Odilitime** (core integrations), **genife** (model integration/RAG/vector DB expertise)

---

## 2) Clarify which ElizaOS-related tokens are official across chains (SOL/BSC/etc.) — DISCORD-2026-03-03-TOKEN-LEGIT
- **Current Status:** Unanswered in Discord; no canonical doc referenced
- **Impact Assessment:**
  - **User Impact:** **Critical** (broad community; affects buyers/builders/partners)
  - **Functional Impact:** **No** (not a code blocker)
  - **Brand Impact:** **High** (trust, scam/confusion risk, reputational damage)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (trust & safety)
  - **Component Affected:** Project Comms, Docs Site, Repo READMEs
  - **Complexity:** **Moderate effort** (requires alignment + sustained updates)
- **Resource Requirements:**
  - **Required Expertise:** Project governance, comms, basic on-chain verification (contract addresses), docs publishing
  - **Dependencies:** Team decision on “official” definition; who owns announcements; legal/brand guidance if applicable
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create an “Official Tokens & Contracts” page in docs with: chain, contract address, ticker, verified links, and “no other tokens are official” statement.
  2. Pin the doc link in Discord (and route token questions to it).
  3. Add a short “How to verify” checklist (block explorer verification, official repo/org links).
  4. Establish an owner + update cadence (e.g., monthly review or upon any token event).
- **Potential Assignees:** **Odilitime** (project coordination), **sayonara** (docs publishing), **Stan ⚡** (docs feedback/review)

---

## 3) “Old ai16z” contract address (CA) request unanswered; ongoing token confusion — DISCORD-2026-03-04-CA-REQUEST
- **Current Status:** Unanswered question in Discord
- **Impact Assessment:**
  - **User Impact:** **High** (community members actively asking; risk of misinformation)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (trust + perceived disorganization)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (trust & safety)
  - **Component Affected:** Community Support, Docs/FAQ
  - **Complexity:** **Simple fix** (if information is known/approved to share)
- **Resource Requirements:**
  - **Required Expertise:** Community moderation, official comms approval
  - **Dependencies:** Must align with the “official tokens” stance (Issue #2) to avoid contradictions
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Decide whether the CA will be published; if yes, publish only via official channels (docs + pinned Discord message).
  2. If no, publish a clear policy (“We do not endorse/provide CAs here; see Official Tokens page”).
  3. Add an AutoMod/FAQ response for “CA?” queries pointing to the canonical source.
- **Potential Assignees:** **Odilitime**, Discord mods/core community stewards (including **satsbased** for routing/pinning)

---

## 4) Babylon chain release repeatedly delayed since December (“couple weeks”) — DISCORD-2026-03-04-BABYLON-DELAY
- **Current Status:** Delayed; no public milestone/issue tracker referenced
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (depends on how many users are waiting; visible frustration)
  - **Functional Impact:** **Partial** (blocks promised functionality/launch plans)
  - **Brand Impact:** **High** (delivery credibility)
- **Technical Classification:**
  - **Issue Category:** Feature Delivery / Project Management
  - **Component Affected:** Chain Integration / Release Management
  - **Complexity:** **Complex solution** (unknown scope; likely cross-component)
- **Resource Requirements:**
  - **Required Expertise:** Chain integration engineering, release management, QA
  - **Dependencies:** External chain readiness, internal audit/review, deployment pipelines
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (upgrade to P1 if it blocks contractual commitments or major launches)
- **Specific Actionable Next Steps:**
  1. Create a public tracking issue/milestone with scope, dependencies, and weekly status updates.
  2. Publish a revised ETA window + “what’s left” checklist (even if high-level).
  3. Identify the single biggest blocker (technical, audit, integration, or resourcing) and staff it explicitly.
- **Potential Assignees:** Core maintainers responsible for chain work (unidentified in provided data), **Odilitime** (triage + milestone creation)

---

## 5) Reply action optimization discovered but unclear if used (possible dead code / missing wiring) — DISCORD-2026-03-03-REPLY-OPT
- **Current Status:** Discovered; utilization unknown
- **Impact Assessment:**
  - **User Impact:** **Medium** (could affect latency/cost if not used; or risk if partially implemented)
  - **Functional Impact:** **Partial** (performance/behavioral correctness risk)
  - **Brand Impact:** **Medium** (quality/maintainability)
- **Technical Classification:**
  - **Issue Category:** Performance / Bug (tech debt)
  - **Component Affected:** Core Framework (action pipeline / reply handling)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Core framework internals, profiling/benchmarking, code archaeology
  - **Dependencies:** Needs tests/benchmarks to validate behavior and regression safety
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Locate call sites and feature flags; determine whether the optimization is reachable in production.
  2. Add a targeted benchmark + correctness tests for reply behavior.
  3. Decide: (a) wire it properly, (b) document it, or (c) remove it to reduce maintenance burden.
- **Potential Assignees:** **Odilitime** (core code familiarity), experienced core contributors (unidentified in provided data)

---

## 6) memU / mem0 “drop-in memory” integration guidance missing for newcomers — DISCORD-2026-03-03-MEM-INTEGRATION
- **Current Status:** User asked; no solution provided; indicates onboarding gap
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects new builders; memory is a common need)
  - **Functional Impact:** **Partial** (blocks a common advanced use case: long-term memory / RAG)
  - **Brand Impact:** **Medium** (perceived lack of guidance/examples)
- **Technical Classification:**
  - **Issue Category:** Documentation / Feature Request
  - **Component Affected:** Memory subsystem, Plugin System, Examples
  - **Complexity:** **Moderate effort** (doc-only path) to **Complex** (first-class integration)
- **Resource Requirements:**
  - **Required Expertise:** Memory architecture, plugin interfaces, example app writing
  - **Dependencies:** Current memory abstraction stability; recommended third-party library choice/policy
  - **Estimated Effort:** **2/5** (docs/examples) or **4/5** (native integration)
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a “Memory integrations” guide: how to implement a memory adapter + where to hook it in.
  2. Provide a reference plugin/example for one memory provider (even minimal).
  3. Add an FAQ entry addressing mem0/memU specifically (supported vs community-supported).
- **Potential Assignees:** **genife** (RAG/vector DB experience), **Odilitime** (framework integration), community contributor **C0rrupt1** (as reporter/tester)

---

## 7) Ruby token confusion despite “not official” clarification; needs canonical messaging & channel routing — DISCORD-2026-03-04-RUBY-CONFUSION
- **Current Status:** Clarified ad-hoc by Odilitime; confusion persists due to market activity
- **Impact Assessment:**
  - **User Impact:** **High** (active speculation; repeated questions likely)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (association risk; misinformation spread)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (trust & safety)
  - **Component Affected:** Community Comms, Docs, Discord moderation tooling
  - **Complexity:** **Simple fix** (canonical statement + routing), **Moderate** (automation)
- **Resource Requirements:**
  - **Required Expertise:** Community moderation, docs edits
  - **Dependencies:** Align with “Official Tokens” page (Issue #2)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a canonical blurb to the “Official Tokens” page: Ruby is not a labs project; no dev plans; where to discuss it.
  2. Create a pinned Discord message + keyword-triggered AutoMod response redirecting Ruby talk to the correct channel.
- **Potential Assignees:** **Odilitime**, Discord mods, **sayonara** (docs)

---

## 8) Add default LLM API options automatically (agent scans GitHub + submits PRs) — DISCORD-2026-03-04-DEFAULT-LLM-PR-BOT
- **Current Status:** Proposed idea; not tracked as an issue
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves onboarding; reduces friction)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (ecosystem competitiveness)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Automation
  - **Component Affected:** Plugin/Provider registry, Installer/OpenClaw flow (as referenced), CI tooling
  - **Complexity:** **Complex solution** (automation + governance controls)
- **Resource Requirements:**
  - **Required Expertise:** GitHub App/bot development, CI, security review (to prevent supply-chain risk), provider evaluation criteria
  - **Dependencies:** Provider vetting policy; signing/verification; review workflow
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Convert to a GitHub RFC with acceptance criteria (what qualifies as “default,” security checks, rollback plan).
  2. Prototype a “suggest providers” bot first (creates issues), before auto-PRs.
  3. Add a human approval gate + allowlist to prevent malicious defaults.
- **Potential Assignees:** Automation-inclined contributors, **Odilitime** (governance/triage), interested community builders

---

## 9) Route inbound partnership inquiry (Coin Post Media) to correct owner — DISCORD-2026-03-04-COINPOST-BIZDEV
- **Current Status:** Requested contact; unresolved in log
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (bizdev opportunity; not product functionality)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (responsiveness to partners)
- **Technical Classification:**
  - **Issue Category:** Process / Operations
  - **Component Affected:** BizDev intake, community ops
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Project ops/bizdev ownership clarity
  - **Dependencies:** Identify official contact + publish intake method
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a single published bizdev contact route (email alias or form) and pin in Discord.
  2. Respond to Nikita with the official channel and expected response SLA.
- **Potential Assignees:** **satsbased** (community routing), core org admins/mods

---

# Summary: Top Highest-Priority Issues to Address Now (Next 1–2 weeks)
1. **plugin-ollama embeddings failing on Linux — #17 (P1)**
2. **Official token legitimacy across chains needs canonical documentation — DISCORD-2026-03-03-TOKEN-LEGIT (P1)**
3. **“Old ai16z” CA question + policy for sharing CAs — DISCORD-2026-03-04-CA-REQUEST (P1)**
4. **Babylon chain delivery slippage needs a public tracker + updated ETA — DISCORD-2026-03-04-BABYLON-DELAY (P2)**
5. **Reply action optimization: confirm usage or remove/wire + test — DISCORD-2026-03-03-REPLY-OPT (P2)**
6. **memU/mem0 memory integration guidance + example adapter — DISCORD-2026-03-03-MEM-INTEGRATION (P2)**
7. **Ruby token confusion: pin canonical statement + AutoMod routing — DISCORD-2026-03-04-RUBY-CONFUSION (P2)**

# Patterns / Themes Suggesting Deeper Issues
- **Documentation and “single source of truth” gaps** are driving repeated community questions (token legitimacy, CAs, memory integration), increasing support load and reputational risk.
- **Integration reliability on common platforms (Linux)** needs stronger CI/contract testing to prevent regressions in plugins.
- **Roadmap visibility and delivery tracking** (Babylon) appears insufficient, creating distrust even when progress may exist.
- **Potential technical debt/unknown code paths** (reply optimization) suggests the need for systematic ownership and periodic cleanup.

# Process Improvement Recommendations
1. **Create a “Discord-to-GitHub intake” rule:** unanswered technical questions that recur become a tracked issue/RFC within 48 hours.
2. **Add integration smoke tests in CI for key plugins** (at minimum: embeddings, basic chat completion, network error handling) with Linux coverage.
3. **Publish and maintain a canonical “Trust & Safety” docs section** (official tokens/contracts, verification steps, impersonation/scam guidance) and pin it in Discord.
4. **Adopt public milestones for externally promised deliverables** (e.g., Babylon) with weekly status notes and explicit blockers/owners.
5. **Quarterly tech-debt review:** identify unreachable/unused optimizations and either wire, document, or delete with regression tests.