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

### 1) Persistent scam bots targeting new users in Discord
- **Issue Title & ID:** Scam bots DM/target first-time posters; phishing links in channels — **DISC-20260301-SEC-01**
- **Current Status:** Ongoing; moderators “actively managing” but attacks persist; at least one suspicious invite link observed (2026-03-03).
- **Impact Assessment:**
  - **User Impact:** **High**
  - **Functional Impact:** **Partial** (blocks onboarding/support flows)
  - **Brand Impact:** **High** (trust & safety risk)
- **Technical Classification:**
  - **Category:** Security / UX
  - **Component Affected:** Community Ops / Discord
  - **Complexity:** Moderate effort (policy + bot + moderation automation)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation tooling, anti-phishing workflows, community operations
  - **Dependencies:** Discord permissions/roles, existing moderation bots, channel configs
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Enable/raise verification gates: minimum account age, phone/email verification, and/or “first-message” quarantine channel.
  2. Add an auto-moderation rule set: block common phishing patterns (fake forms, “complaint submission”, non-whitelisted invites).
  3. Create an official “Links & Forms” pinned message listing canonical URLs (docs, GitHub, official Discord invite).
  4. Implement a “new user” slowmode + limited posting permissions until they acknowledge rules.
  5. Post a short security PSA in welcome + discussion; include screenshots of known scam formats.
- **Potential Assignees:** **Arceon** (moderation), **satsbased** (community program), **Odilitime** (policy/ops support)

---

### 2) Token legitimacy confusion across chains (SOL/BSC/Base) + need official statement
- **Issue Title & ID:** Clarify which ElizaOS-related tokens are official/sanctioned across chains — **DISC-20260303-DOC-01**
- **Current Status:** Unanswered publicly; community confusion persists; Solana CA shared informally (DuMbhu7…ELiZA), but BSC/Base legitimacy unclear.
- **Impact Assessment:**
  - **User Impact:** **High** (financial risk; scam exposure)
  - **Functional Impact:** **No** (core framework unaffected)
  - **Brand Impact:** **Critical** (credibility, legal/reputation risk)
- **Technical Classification:**
  - **Category:** Documentation / Security (social engineering vector)
  - **Component Affected:** Public communications, docs site, Discord token channel
  - **Complexity:** Simple fix (authoritative post + ongoing maintenance)
- **Resource Requirements:**
  - **Required Expertise:** Project leadership + comms; token ops knowledge
  - **Dependencies:** Confirm with core team/legal; source-of-truth location (website/GitHub)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a single canonical “Official Token & Contracts” page on **elizaos.github.io** (and pin in Discord).
  2. Explicitly list: official contracts per chain, official bridges (if any), and “NOT affiliated” known impostors.
  3. Add a signed verification method (e.g., GitHub release note + website + Discord announcement posted by admins).
  4. Add a policy for future deployments: how the team announces new contracts and how community verifies them.
- **Potential Assignees:** **Odilitime** (technical verification), **Arceon** (Discord pin/announcements), **jin** (docs/content publishing)

---

### 3) Auto.fun users reporting “stuck balance”
- **Issue Title & ID:** auto.fun balance stuck / funds not updating — **DISC-20260302-BUG-01**
- **Current Status:** Reported by multiple users; at least one user resolved it but resolution steps not captured.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (depends on volume; affects funds)
  - **Functional Impact:** **Partial** (blocks trading/usage on that platform)
  - **Brand Impact:** **Medium–High** (users associate pain with ecosystem)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** External integration / ecosystem platform (auto.fun)
  - **Complexity:** Moderate effort (needs reproduction + integration debugging)
- **Resource Requirements:**
  - **Required Expertise:** Web3 app debugging, RPC/indexer knowledge, incident triage
  - **Dependencies:** auto.fun team responsiveness; logs; chain explorer evidence
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create an incident template for reports: chain, tx hashes, screenshots, timestamps, wallet, expected vs actual.
  2. Collect the “got it sorted out” fix steps from **patatapicasa** and document them.
  3. If auto.fun is partner-affiliated: open a joint ticket with their team; otherwise publish a community workaround guide.
  4. Add a Discord FAQ entry: “Stuck balance troubleshooting checklist”.
- **Potential Assignees:** **satsbased** (ecosystem coordination), **Odilitime** (technical triage), **aicodeflow** (reliability/ops mindset)

---

### 4) plugin-ollama embedding failures on Linux
- **Issue Title & ID:** Embedding failures on Linux environments — **elizaos-plugins/plugin-ollama #17**
- **Current Status:** Known issue; “identified and began investigating” (per weekly summary).
- **Impact Assessment:**
  - **User Impact:** **Medium** (Linux devs/self-hosters are common)
  - **Functional Impact:** **Partial** (breaks embeddings → RAG/memory/search features)
  - **Brand Impact:** **Medium** (self-host reliability)
- **Technical Classification:**
  - **Category:** Bug / Compatibility
  - **Component Affected:** Model Integration (Ollama embeddings), Plugin System
  - **Complexity:** Moderate effort (env-specific; possibly native deps)
- **Resource Requirements:**
  - **Required Expertise:** Node/Python runtime nuances (as applicable), Linux deployment, Ollama API specifics
  - **Dependencies:** Repro environment matrix (distro, libc, GPU/CPU), ollama version constraints
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add CI smoke test on Ubuntu for embeddings (minimal model pull + embed call).
  2. Request reporters to provide: ollama version, model, logs, and exact API endpoint behavior.
  3. Validate whether failure is due to path/permissions, binary availability, or API response parsing.
  4. Publish a pinned “Known Issues: Ollama Linux Embeddings” workaround once root cause is found.
- **Potential Assignees:** **Odilitime** (core/plugin expertise), **genife** (full-stack + model integration), community maintainers of plugin-ollama

---

### 5) Wrong “Milady agent” running (version/config mismatch)
- **Issue Title & ID:** Wrong Milady agent running (BSC vs expected) — **DISC-20260302-BUG-02**
- **Current Status:** Reported; not diagnosed in logs provided.
- **Impact Assessment:**
  - **User Impact:** **Medium** (Milady users + public visibility)
  - **Functional Impact:** **Partial** (agents behaving unexpectedly)
  - **Brand Impact:** **High** (public-facing agent wrong = trust hit)
- **Technical Classification:**
  - **Category:** Bug / Ops
  - **Component Affected:** Deployment / Agent configuration
  - **Complexity:** Moderate effort (config, environment, release process)
- **Resource Requirements:**
  - **Required Expertise:** DevOps, release management, environment config, agent runtime
  - **Dependencies:** Access to deployment manifests, environment variables, token/chain routing logic
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify the authoritative “expected agent” spec (chain, plugins, model, config hash).
  2. Compare running deployment config vs repo config (diff env vars, plugin list, endpoints).
  3. Add a runtime “/health” or “/info” endpoint that prints build/version + config fingerprint.
  4. Add deployment guardrails: require version tag + config checksum to match before promoting.
- **Potential Assignees:** **ElizaBAO** (Milady integration context), **Odilitime** (framework/runtime), **aicodeflow** (reliability)

---

### 6) Memory integration confusion: memU / mem0 wiring guidance
- **Issue Title & ID:** Need reference implementation/docs for memory providers (memU/mem0) — **DISC-20260303-DOC-02**
- **Current Status:** Asked by newcomer; no concrete answer provided; memU repo shared; mem0 plugin/integration discussed earlier (2026-03-02).
- **Impact Assessment:**
  - **User Impact:** **Medium** (common need; blocks new builders)
  - **Functional Impact:** **Partial** (memory/RAG is core for many agents)
  - **Brand Impact:** **Medium** (developer experience)
- **Technical Classification:**
  - **Category:** Documentation / UX (DevEx) *(possible Feature if abstraction missing)*
  - **Component Affected:** Core Framework (memory interface), Plugin System
  - **Complexity:** Moderate effort (docs + example; maybe adapter layer)
- **Resource Requirements:**
  - **Required Expertise:** Framework internals, plugin authoring, RAG/vector DB patterns
  - **Dependencies:** Decide canonical memory interface; align with existing mem0 plugin approach
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document “Memory Providers” with a clear interface contract (store/retrieve, namespaces, TTL, embeddings).
  2. Provide a minimal working example: swap default memory → mem0 → memU (if supported) via config.
  3. If mem0 is already integrated by community: promote to registry + add “officially supported” vs “community”.
  4. Add troubleshooting section: latency, consistency, embedding model mismatch, migration.
- **Potential Assignees:** **Meme Broker** (mem0 integration knowledge), **Odilitime** (core interface), **genife** (RAG/vector DB experience)

---

### 7) “Reply action optimization” may be unused/undocumented (possible dead code / tech debt)
- **Issue Title & ID:** Audit reply action optimization usage; remove or document — **DISC-20260303-TECHDEBT-01**
- **Current Status:** Discovered by core dev; unclear if in active use.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (depends on perf/behavior impact)
  - **Functional Impact:** **No** (unless it causes subtle bugs)
  - **Brand Impact:** **Low–Medium** (maintainability)
- **Technical Classification:**
  - **Category:** Performance / Bug (potential), Maintenance
  - **Component Affected:** Core Framework (reply/action pipeline)
  - **Complexity:** Moderate effort (code tracing + tests)
- **Resource Requirements:**
  - **Required Expertise:** Core framework internals, profiling, test coverage
  - **Dependencies:** Identify call sites; confirm intended behavior; measure perf delta
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Grep + trace: find references, feature flags, config toggles.
  2. Add/verify unit tests covering reply action ordering and side effects.
  3. If unused: remove and note in changelog; if used: document and add a benchmark.
- **Potential Assignees:** **Odilitime**, **aicodeflow** (performance/maintainability)

---

### 8) Heartbeat plugin should use plugin-bootstrap task service (architecture consistency)
- **Issue Title & ID:** Align heartbeat/cron plugin with task service (avoid parallel scheduler) — **DISC-20260302-ARCH-01**
- **Current Status:** Feedback given; plugin updated directionally, but ensure best-practice guidance is captured.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (plugin authors)
  - **Functional Impact:** **Partial** (scheduler duplication can cause bugs)
  - **Brand Impact:** **Low–Medium**
- **Technical Classification:**
  - **Category:** Bug Prevention / Architecture
  - **Component Affected:** Plugin System / plugin-bootstrap
  - **Complexity:** Simple fix (docs + reference code)
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture, task service APIs
  - **Dependencies:** Clear documentation and examples in plugin-bootstrap
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add “Cron/Heartbeat plugin template” showing task service usage.
  2. Add linter/docs warning: avoid standalone schedulers inside plugins.
- **Potential Assignees:** **Meme Broker** (author), **Odilitime** (architecture)

---

## Conclusion

### (1) Top highest-priority issues to address immediately (next 5–10)
1. **P0:** Scam bots/phishing targeting new Discord users — **DISC-20260301-SEC-01**
2. **P0:** Official token legitimacy/contracts clarification across chains — **DISC-20260303-DOC-01**
3. **P1:** auto.fun “stuck balance” incident pattern + documented workaround — **DISC-20260302-BUG-01**
4. **P1:** Wrong Milady agent running (deployment/config mismatch) — **DISC-20260302-BUG-02**
5. **P1:** Ollama plugin embeddings failing on Linux — **plugin-ollama #17**
6. **P2:** Memory provider integration docs/examples (mem0/memU) — **DISC-20260303-DOC-02**
7. **P2:** Reply action optimization audit (possible dead code) — **DISC-20260303-TECHDEBT-01**

### (2) Patterns/themes suggesting deeper issues
- **Trust & authenticity gaps (non-code):** Token legitimacy uncertainty + Discord phishing indicates the ecosystem lacks a strong, consistently referenced “source of truth” and hardened onboarding.
- **Operational maturity needs:** Reports like “wrong agent running” and “stuck balance” point to missing incident playbooks, environment introspection, and release/config verification.
- **DevEx/documentation lag:** Repeated questions about memory integration and “is OpenAI-compatible supported?” suggest key capabilities exist but aren’t discoverable or packaged as clear guides.

### (3) Recommendations for process improvements
- **Establish canonical public sources of truth:**
  - A single docs page for official contracts/links; mirrored in pinned Discord posts and GitHub releases.
- **Add lightweight incident management:**
  - Standard report template (tx hash/logs/version), a public “Known Issues” page, and postmortems for recurring incidents.
- **Improve release & runtime introspection:**
  - Require version tags + config checksums; add runtime “/info” endpoints to agents/plugins to reduce ambiguity.
- **Harden community onboarding/security by default:**
  - Verification gates, link whitelisting, first-message quarantine, and prominent anti-phishing education.
- **DevEx roadmap for “common integrations”:**
  - Official guides for memory providers, OpenAI-compatible endpoints, and plugin task scheduling patterns (with copy-paste examples).