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

### 1) Auto.fun balances stuck / withdrawals not updating (Discord-reported)
- **Issue Title & ID:** Auto.fun user balances stuck (DISCORD-PLATFORM-2026-03-02-AUTOFUN)
- **Current Status:** Reported by multiple users; one user indicated they “got it sorted out” but no root-cause or runbook captured.
- **Impact Assessment:**
  - **User Impact:** **High** (multiple user reports; affects funds access)
  - **Functional Impact:** **Partial** (platform operation impaired; core framework may be unaffected)
  - **Brand Impact:** **High** (custody/finance-adjacent issues erode trust quickly)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** Platform Integration / Payments or Balance Indexing (external service, but impacts ecosystem)
  - **Complexity:** **Complex solution** (likely involves reconciliation, indexing, and incident response)
- **Resource Requirements:**
  - **Required Expertise:** Backend + infra/observability; DB reconciliation; web3/payments ops (if applicable)
  - **Dependencies:** Access to auto.fun logs, DB/indexer state, and ability to deploy hotfixes; confirm ownership/support channel
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Open a tracked incident issue in the appropriate repo (or internal ops tracker) with timestamps, affected accounts, and symptoms.
  2. Add immediate observability: queue lag, indexer lag, failed job counts, reconciliation diffs.
  3. Produce a short “User Support Runbook” (what to collect, expected resolution time, safe remediation steps).
  4. Identify root cause category: stuck job, RPC/provider outage, DB lock, chain reorg handling, or idempotency bug.
  5. Implement automated reconciliation + alerting to prevent silent stuck states.
- **Potential Assignees:** Alexei (ops coordination), Odilitime (triage + routing), platform/backend maintainer(s) closest to auto.fun integration; enlist patatapicasa for reproduction steps (since they resolved it).

---

### 2) Possible wrong “Milady agent” running (Discord-reported)
- **Issue Title & ID:** Wrong Milady agent/version running in production (DISCORD-AGENTS-2026-03-02-MILADY)
- **Current Status:** Reported; no resolution documented.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (depends on how many users interact with that agent)
  - **Functional Impact:** **Partial** (incorrect agent behavior/config undermines agent correctness)
  - **Brand Impact:** **High** (public-facing agent running “wrong version” signals poor release hygiene)
- **Technical Classification:**
  - **Issue Category:** Bug / Release Engineering / UX
  - **Component Affected:** Agent Deployment Pipeline, Config Management, Registry/Distribution
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** DevOps, deployment pipelines, config/versioning, plugin/agent packaging
  - **Dependencies:** Need clarity on “expected” Milady agent artifact + environment where observed (BSC vs other)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Capture current running agent identifiers: git SHA, image tag, config hash, plugin versions, chain target.
  2. Compare to intended release artifact; identify how the mismatch occurred (stale deploy, wrong env var, wrong channel).
  3. Add a “/version” (or equivalent) introspection endpoint/command to every deployed agent.
  4. Add CI/CD guardrails: require signed tags or pinned versions for production deployments.
- **Potential Assignees:** Odilitime (coordination), Meme Broker (plugin/agent packaging context), a DevOps maintainer responsible for deployments.

---

### 3) Token legitimacy / official contract addresses unclear across chains (Discord-reported)
- **Issue Title & ID:** Official token legitimacy + canonical CAs across SOL/Base/BSC unclear (DISCORD-DOCS-2026-03-03-TOKEN-LEGITIMACY)
- **Current Status:** Ongoing confusion; partial clarification given for Solana CA, but questions remain (e.g., “old ai16z CA” unanswered; Ruby confusion recurring).
- **Impact Assessment:**
  - **User Impact:** **Critical** (users may buy scams or wrong assets)
  - **Functional Impact:** **No** (not core framework runtime, but critical ecosystem safety)
  - **Brand Impact:** **High** (scam/confusion narratives damage credibility)
- **Technical Classification:**
  - **Issue Category:** Documentation / Security (social engineering risk)
  - **Component Affected:** Docs site, README(s), Discord channel pins, website metadata
  - **Complexity:** **Simple fix** (content + verification process), with **moderate** process work
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, community ops, basic on-chain verification; website/docs publishing
  - **Dependencies:** Agreement from core team on “official” list; a single source of truth
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a single “Official Contracts & Links” page (docs + website) with:
     - Canonical contract addresses per chain
     - Status labels (Official / Not affiliated / Deprecated / Unknown)
     - Last-updated timestamp + maintainers
  2. Pin the link in Discord (#token or equivalent) and lock recurring Q&A to that reference.
  3. Answer specifically: “official CA of old ai16z” (or explicitly state deprecated/unsupported).
  4. Add anti-scam guidance: never trust DMs, verify via docs, how to validate token metadata.
- **Potential Assignees:** Odilitime (canonical answers), sayonara (docs publishing), Stan ⚡ (docs review), community mods.

---

### 4) Babylon chain release delayed since December (Discord-reported delivery risk)
- **Issue Title & ID:** Babylon chain release delay (promised “couple weeks” since Dec) (DISCORD-ROADMAP-2026-03-04-BABYLON)
- **Current Status:** Delayed; community calling it out.
- **Impact Assessment:**
  - **User Impact:** **Medium** (depends on who needs Babylon; affects planning)
  - **Functional Impact:** **Partial** (blocks chain-specific features/integrations)
  - **Brand Impact:** **High** (missed timelines amplify negative sentiment)
- **Technical Classification:**
  - **Issue Category:** Feature / Project Management
  - **Component Affected:** Chain Integration / Release Management
  - **Complexity:** **Complex solution** (unknown remaining engineering)
- **Resource Requirements:**
  - **Required Expertise:** Chain integration engineers; release manager; QA
  - **Dependencies:** External chain readiness, infra, audits, integration tests
  - **Estimated Effort (1–5):** **4** (until scope clarified)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert to a public roadmap issue with explicit scope, blockers, and milestone dates.
  2. Publish “what’s done vs what remains” + minimum viable release criteria.
  3. Ship a small “developer preview” if full release is blocked; collect feedback.
- **Potential Assignees:** Core chain/integration maintainers; Odilitime to coordinate comms and milestone clarity.

---

### 5) Embedding failures on Linux in plugin-ollama
- **Issue Title & ID:** Embedding failures on Linux environments — `elizaos-plugins/plugin-ollama` **#17**
- **Current Status:** Identified; investigating (per weekly summary).
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for self-hosting)
  - **Functional Impact:** **Yes** (embeddings often underpin RAG/memory/search)
  - **Brand Impact:** **Medium** (core experience degraded for self-hosters)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Model Integration (Ollama embeddings)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node/TS runtime, Ollama API quirks, Linux env debugging (libc, GPU/CPU backends), CI
  - **Dependencies:** Repro steps + environment matrix; may depend on specific Ollama versions/models
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a CI job for Linux embedding smoke tests (matrix: Ubuntu versions, Ollama versions).
  2. Collect minimal repro: model name, endpoint, payload, expected vs actual, logs.
  3. Implement robust error messages + fallback behavior (if embeddings fail, disable RAG with clear warning).
  4. Document known-good versions and setup commands.
- **Potential Assignees:** Maintainer(s) of plugin-ollama; recruit Linux-heavy community contributor; Odilitime to help prioritize/testing.

---

### 6) Reply action optimization present but unclear if used (possible dead code / undocumented feature)
- **Issue Title & ID:** Verify usage of “reply action optimization” (DISCORD-CORE-2026-03-03-REPLY-OPT)
- **Current Status:** Discovered; usage unknown.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (could be perf gain if enabled; could be maintenance risk if dead)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low–Medium** (technical debt signals)
- **Technical Classification:**
  - **Issue Category:** Performance / Maintenance
  - **Component Affected:** Core Framework (actions/reply pipeline)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Core framework internals; profiling/benchmarking; documentation
  - **Dependencies:** Need to locate code path + instrumentation
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Identify the code path and add metrics/logging to confirm runtime use.
  2. If unused: either remove (with changelog note) or wire it into the execution path.
  3. Add a short doc entry explaining what it is and when it applies.
- **Potential Assignees:** Odilitime (discovery), core maintainers familiar with action pipeline.

---

### 7) Memory integration guidance gap (memU/mem0) for new developers
- **Issue Title & ID:** Provide “memory provider” integration guide (memU/mem0) (DISCORD-DOCS-2026-03-03-MEMORY)
- **Current Status:** User asked; no concrete answer provided in-thread. MEM0 plugin work exists but onboarding guidance is missing.
- **Impact Assessment:**
  - **User Impact:** **Medium** (common need for agent builders)
  - **Functional Impact:** **Partial** (agents work, but persistent memory/RAG blocked for many)
  - **Brand Impact:** **Medium** (onboarding friction)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Plugin System, Memory/RAG integrations
  - **Complexity:** **Simple fix** (docs/examples), possibly **moderate** if API gaps exist
- **Resource Requirements:**
  - **Required Expertise:** Docs + example app; familiarity with mem0/MEM0 plugin architecture
  - **Dependencies:** Decide supported “memory interface” and reference implementation(s)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a “Memory Integrations” page: concept, supported providers, and minimal code samples.
  2. Add an example agent showing persistent conversation with MEM0 (happy path + deployment notes).
  3. If memU is desired, define an adapter interface and tracking issue for implementation.
- **Potential Assignees:** Meme Broker (MEM0 context), sayonara (Mintlify docs), a community contributor for examples.

---

### 8) Heartbeat/cron plugin architecture consistency (task service integration)
- **Issue Title & ID:** Standardize cron/heartbeat via plugin-bootstrap task service (DISCORD-PLUGINS-2026-03-02-HEARTBEAT)
- **Current Status:** Guidance given; plugin updated directionally, but standard pattern not yet codified.
- **Impact Assessment:**
  - **User Impact:** **Medium** (cron-like tasks are common; poor patterns lead to unreliable agents)
  - **Functional Impact:** **Partial**
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Architecture
  - **Component Affected:** Plugin System (plugin-bootstrap task service)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture; scheduler/task semantics; docs
  - **Dependencies:** A canonical example + API stability in plugin-bootstrap
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Write a “Scheduled Tasks” guide and provide a reference plugin template.
  2. Add linting or review checklist: no bespoke timers where task service exists.
  3. Ensure task lifecycle semantics (start/stop, persistence, jitter, error backoff) are defined.
- **Potential Assignees:** Odilitime (architecture guidance), Meme Broker (implementation), plugin-bootstrap maintainer(s).

---

## Top Highest-Priority Issues to Address Now (Next 24–72 hours)
1. **P0:** Auto.fun balances stuck (DISCORD-PLATFORM-2026-03-02-AUTOFUN)
2. **P0:** Official token legitimacy + canonical contract addresses (DISCORD-DOCS-2026-03-03-TOKEN-LEGITIMACY)
3. **P1:** Wrong Milady agent/version running (DISCORD-AGENTS-2026-03-02-MILADY)
4. **P1:** plugin-ollama Linux embedding failures — **#17**
5. **P1:** Babylon chain release delay / missing milestone clarity (DISCORD-ROADMAP-2026-03-04-BABYLON)
6. **P2:** Memory integration docs (memU/mem0/MEM0) (DISCORD-DOCS-2026-03-03-MEMORY)
7. **P2:** Standardize cron/heartbeat patterns via task service (DISCORD-PLUGINS-2026-03-02-HEARTBEAT)
8. **P2:** Reply action optimization usage audit (DISCORD-CORE-2026-03-03-REPLY-OPT)

---

## Patterns / Themes Indicating Deeper Issues
- **Release & environment drift:** “Wrong agent running” and “stuck balances” both suggest gaps in deployment observability, version pinning, and operational runbooks.
- **Single source of truth missing for ecosystem safety:** Recurring token legitimacy/CA confusion and “old CA” questions indicate the project needs authoritative, easily discoverable references.
- **Onboarding friction around memory & scheduling:** Multiple questions point to missing “golden path” examples for common agent capabilities (persistence + cron).
- **Linux/self-host quality risk:** Embedding failures on Linux highlight the need for broader CI matrices and smoke tests for popular self-host setups.

---

## Process Improvements (Prevent Recurrence)
1. **Create a “Critical Ops” playbook + incident template** (owner, severity, comms cadence, postmortem requirements) for any funds/balance/deployment incident.
2. **Add mandatory version introspection** for deployed agents/services (commit SHA, config hash, plugin lockfile hash) and surface it in UI/commands.
3. **Publish and maintain an “Official Links & Contracts” page** and pin it across Discord; treat changes as PR-reviewed content with audit trail.
4. **Expand CI to match real-world hosting** (Linux matrices, embedding smoke tests, minimal end-to-end RAG test).
5. **Establish “Golden Path” example repos** (memory + scheduled tasks + OpenAI-compatible provider) and link them prominently in Mintlify docs.