## Issue Triage — 2026-03-24 (elizaOS)

### 1) Milady app launch blocked by unresolved readiness criteria / unknown remaining defects (no date communicated)
- **Issue Title & ID:** Milady app launch readiness unclear; no ship criteria or timeline — **DISCORD-2026-03-23-MILADY-READY**
- **Current Status:** In active development; team worked through weekend; release date unknown (“when it’s ready”).
- **Impact Assessment:**
  - **User Impact:** **High** (repeated user inquiries; primary product expectation)
  - **Functional Impact:** **Partial** (doesn’t block core elizaOS framework usage, but blocks flagship app delivery)
  - **Brand Impact:** **High** (perceived lack of delivery/opacity)
- **Technical Classification:**
  - **Issue Category:** UX / Bug (unknown) / Release Management
  - **Component Affected:** Application layer (Milady) + elizaOS integration points
  - **Complexity:** **Complex solution** (unknown defects + release coordination)
- **Resource Requirements:**
  - **Required Expertise:** Full-stack app debugging, agent runtime integration, QA/release engineering
  - **Dependencies:** Needs a defined “Definition of Done” (DoD), test plan, and release checklist; may depend on elizaOS core fixes if app is hitting framework edge cases
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **Milady Release Readiness Checklist** (ship criteria, must-fix vs nice-to-have).
  2. Create a single **public tracking issue/board** listing remaining blockers (crashes, onboarding, auth/wallet, latency, infra, etc.).
  3. Add **smoke tests** (install/start agent, connect key integrations, basic conversation loop, persistence).
  4. Commit to a communication artifact: **weekly delta** (“what changed, what’s blocked, what’s next”).
- **Potential Assignees:** **Odilitime** (directly involved), **Milady app core devs**, **sb** (architecture clarifications), **QA/release volunteer(s)** from Spartan Dev/Core Dev roles.

---

### 2) Ollama plugin: Embedding failures on Linux environments
- **Issue Title & ID:** Embeddings fail on Linux in plugin-ollama — **elizaos-plugins/plugin-ollama#17**
- **Current Status:** Reported and “began investigating” (per weekly summary); resolution not documented in provided data.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Linux is common for self-hosting; embeddings are key for RAG/memory)
  - **Functional Impact:** **Partial** (blocks embedding-dependent features; chat may still work)
  - **Brand Impact:** **Medium** (self-host reliability concerns)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Plugin System → Model Integration (Ollama embeddings)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node/TS plugin debugging, Linux environment troubleshooting, Ollama API familiarity
  - **Dependencies:** Repro steps + environment matrix (distro, CPU/GPU, Ollama version); may depend on upstream Ollama behavior
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Require reporter to provide: `ollama --version`, model name, embedding endpoint payload, logs, OS/distro, libc, container vs bare metal.
  2. Add CI-like **Linux repro script** (docker compose) to validate embeddings end-to-end.
  3. Implement **better error surfaces** (HTTP status, response body, retry hints) and fallback guidance.
  4. Document known-good versions and a compatibility table.
- **Potential Assignees:** **plugin-ollama maintainer(s)**, **Core Dev** familiar with model providers; recruit a **Linux-heavy community contributor** to reproduce.

---

### 3) “Whitepaper” confusion: users cannot find canonical docs; repeated questions
- **Issue Title & ID:** Documentation gap—no whitepaper; redirect to roadmap + arXiv not prominent — **DISCORD-2026-03-22-DOC-WHITEPAPER**
- **Current Status:** Answered ad-hoc in Discord; not clearly solved as a documentation/product issue.
- **Impact Assessment:**
  - **User Impact:** **High** (recurring onboarding question; affects evaluators/partners)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (perceived lack of legitimacy/clarity)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs site + README(s) + roadmap repo linkage
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, docs IA/navigation
  - **Dependencies:** None
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a top-level docs page: **“Whitepaper / Research / Roadmap (Canonical Links)”**.
  2. Update README(s) to include: roadmap URL + arXiv paper + “why no traditional whitepaper”.
  3. Pin a Discord message + bot command (e.g., `!whitepaper`) to reduce repeated support load.
- **Potential Assignees:** **Odilitime** (community + comms), **docs maintainers** (elizaos.github.io contributors), **Mr. Ronnie Debryne** (already assisting users).

---

### 4) Perception of poor communication despite weekly/daily updates (information not addressing top concerns)
- **Issue Title & ID:** Communication mismatch—updates exist but don’t answer “what users care about” — **DISCORD-2026-03-21-COMMS-MISMATCH**
- **Current Status:** Team points to cronjob videos + daily updates channel; community still dissatisfied.
- **Impact Assessment:**
  - **User Impact:** **High** (broad community sentiment; repeated)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (trust erosion; “dead project” narrative risk)
- **Technical Classification:**
  - **Issue Category:** UX (project UX) / Documentation
  - **Component Affected:** Project communications pipeline (Discord, Twitter, updates channel)
  - **Complexity:** **Moderate effort** (process + content changes)
- **Resource Requirements:**
  - **Required Expertise:** Product comms, community ops, release notes discipline
  - **Dependencies:** Agreement on KPIs and what “status” means (milestones, shipped features, blockers)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Introduce a weekly **“Top 5 Questions Answered”** section in updates (utility, milestones, timelines, integrations, risks).
  2. Maintain a public **Known Issues / What’s Shipping Next** list (single source of truth).
  3. Establish an escalation path: when sentiment spikes, post a short **incident-style update** (what happened, what we know, next check-in).
- **Potential Assignees:** **Odilitime** (community), **Rainman** (helper process), **Shaw** (Twitter alignment), a designated **PM/Release Captain**.

---

### 5) Missing token utility tied to shipping products (users asking “why buy/hold?” unanswered)
- **Issue Title & ID:** No concrete token utility integration plan surfaced; repeated unanswered questions — **DISCORD-2026-03-21-TOKEN-UTILITY-GAP**
- **Current Status:** Community requests; no concrete plan documented in provided data.
- **Impact Assessment:**
  - **User Impact:** **High** (large holder/community base; impacts adoption incentives)
  - **Functional Impact:** **Partial** (doesn’t break software, but blocks ecosystem monetization narrative)
  - **Brand Impact:** **Critical** (trust, credibility, long-term ecosystem health)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Product
  - **Component Affected:** Token integration, marketplace, app gating, plugin ecosystem incentives
  - **Complexity:** **Architectural change** (needs coherent design + implementation across components)
- **Resource Requirements:**
  - **Required Expertise:** Tokenomics + smart contracts + product design + backend integration
  - **Dependencies:** Finalize utility scope; align with marketplace plugin initiatives; security review
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1** (strategic + brand-critical; schedule design sprint immediately)
- **Specific Actionable Next Steps:**
  1. Draft a one-page **Utility Spec v0**: use cases, flows, required contracts, and non-goals.
  2. Decide on a near-term “MVP utility” that can ship in weeks (e.g., marketplace fees, premium features, agent registration).
  3. Create an implementation plan with milestones + audits (especially if funds/fees involved).
- **Potential Assignees:** **Core team product lead**, **TraderTomson** (marketplace/monetization context), **smart contract engineer(s)**, **Odilitime** (alignment + comms).

---

### 6) Autonomous agent monetization plugin on Base: security/compliance and integration readiness review
- **Issue Title & ID:** Plugin enabling autonomous on-chain marketplace (Base) needs security review + integration guidelines — **DISCORD-2026-03-22-AGENT-MONETIZATION-BASE**
- **Current Status:** Announced as live (“Season 1” with incentive pool); no technical audit status mentioned.
- **Impact Assessment:**
  - **User Impact:** **Medium** now, potentially **High** if adopted widely
  - **Functional Impact:** **Partial** (not core runtime, but high-value ecosystem feature)
  - **Brand Impact:** **High** (any exploit/scam narrative severely damages project)
- **Technical Classification:**
  - **Issue Category:** Security / Feature
  - **Component Affected:** Plugin System + Web3 integration + payments
  - **Complexity:** **Complex solution**
- **Resource Requirements:**
  - **Required Expertise:** Smart contract security, threat modeling, key management, plugin sandboxing
  - **Dependencies:** Clear ownership (repo, maintainers), audit pipeline, registry inclusion policies
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0** (if promoted to users with real funds at risk); otherwise **P1** pending rollout scope
- **Specific Actionable Next Steps:**
  1. Perform a **rapid threat model** (private key handling, approvals, reentrancy, phishing vectors, agent-to-agent hiring abuse).
  2. Require an **independent audit** (or at minimum a structured internal review) before official endorsement.
  3. Publish safe integration patterns: hardware wallets, relayers, spending limits, simulation/dry-run.
- **Potential Assignees:** **TraderTomson** (author), **Core security-minded maintainers**, external **smart contract auditor**.

---

### 7) Token recovery lag vs market: “something isn’t right” (needs data-driven diagnosis)
- **Issue Title & ID:** Token underperforms broader market; root cause unknown — **DISCORD-2026-03-21-TOKEN-RECOVERY-DIAG**
- **Current Status:** Acknowledged; no investigation plan documented.
- **Impact Assessment:**
  - **User Impact:** **High** (community confidence and retention)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Performance (market) / Operations
  - **Component Affected:** Market operations, liquidity, listings, comms
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Market analytics, liquidity analysis, exchange ops, on-chain forensics
  - **Dependencies:** Access to trading/liquidity data; coordination with partners/exchanges
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2** (important, but must not preempt shipping/security unless it indicates exploit/manipulation)
- **Specific Actionable Next Steps:**
  1. Produce a **weekly market health report**: liquidity, volumes, holder distribution, wallets, sell pressure sources.
  2. Check for technical causes: token migration artifacts, contract permissions, vesting unlock misconceptions, LP concentration.
  3. If manipulation suspected, document evidence and mitigation options.
- **Potential Assignees:** Business/ops lead, analytics contributor(s), **Odilitime** for comms bridging.

---

### 8) BitMart listing outreach needs an owner and an intake process (partner requests risk being dropped)
- **Issue Title & ID:** Partner intake gap—BitMart listing team requested contact; no documented routing — **DISCORD-2026-03-23-BITMART-INTAKE**
- **Current Status:** Outreach occurred; no next action recorded.
- **Impact Assessment:**
  - **User Impact:** **Medium** (indirect; affects accessibility/liquidity)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (missed partnerships reinforce “disorganized” perception)
- **Technical Classification:**
  - **Issue Category:** Operations / Process
  - **Component Affected:** Partner portal / BD workflow
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** BD ops, partner management, basic compliance checklists
  - **Dependencies:** Named owner; documented inbound routing
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Assign a **single BD owner** + backup; respond to BitMart with a standard intake form.
  2. Create a lightweight **Partner CRM / tracker** (even a GitHub project board).
  3. Publish “How to partner” instructions (email, expected response time, requirements).
- **Potential Assignees:** **Odilitime** (noted “partner portal - self assign”), BD/staff team member(s).

---

## Summary — Top Highest-Priority Issues to Address Now (Top 5–10)
1. **P0:** Autonomous agent monetization plugin on Base — **Security review + safe integration guidance** (**DISCORD-2026-03-22-AGENT-MONETIZATION-BASE**)
2. **P1:** Milady app launch readiness blockers — **define ship criteria + tracking + QA** (**DISCORD-2026-03-23-MILADY-READY**)
3. **P1:** Ollama plugin embeddings failing on Linux — **fix compatibility + add repro + improve errors** (**plugin-ollama#17**)
4. **P1:** Token utility gap — **write Utility Spec v0 + select MVP utility + milestone plan** (**DISCORD-2026-03-21-TOKEN-UTILITY-GAP**)
5. **P1:** Communication mismatch — **answer top questions + publish “what’s next/known issues”** (**DISCORD-2026-03-21-COMMS-MISMATCH**)
6. **P1:** “Whitepaper” documentation gap — **canonical links page + pinned Discord command** (**DISCORD-2026-03-22-DOC-WHITEPAPER**)
7. **P2:** Token recovery lag diagnosis — **weekly market health + forensics** (**DISCORD-2026-03-21-TOKEN-RECOVERY-DIAG**)
8. **P2:** BitMart partner intake ownership — **assign owner + tracker** (**DISCORD-2026-03-23-BITMART-INTAKE**)

---

## Patterns / Themes Suggesting Deeper Problems
- **Release management is under-specified** (Milady “when ready” without public ship criteria → uncertainty, repeated support load).
- **Security posture risk from fast ecosystem expansion** (monetization/on-chain automation features need audits and standardized key management patterns).
- **Documentation and comms are reactive rather than productized** (same questions repeat; answers live in chat, not in canonical docs).
- **Product narrative disconnect** between engineering progress and what users evaluate (utility, timelines, “what shipped this week”).

---

## Process Improvements (Prevent Recurrence)
1. **Create a canonical “Status + Roadmap + Known Issues” hub** updated weekly; link it everywhere (docs, Discord pins, Twitter).
2. **Adopt lightweight release discipline** for major surfaces (Milady): DoD checklist, blocker board, smoke tests, release captain rotation.
3. **Security gating for Web3 plugins**: minimum threat model + key handling guidelines + audit requirement before official promotion.
4. **Turn recurring Discord Q&A into docs automatically**: weekly sweep → add/refresh FAQ; add bot commands for top links (roadmap, paper, updates).
5. **Partner intake workflow** with clear ownership, SLA, and tracking to avoid missed opportunities and improve perceived professionalism.