## Issue Triage — 2026-03-03

### P0 / P1 Candidates (Immediate Attention)

---

### 1) Persistent scam bots targeting new users in Discord
- **Issue Title & ID:** Scam bots DM / reply to first-time posters (Discord) — **DISC-2026-03-01-SCAMBOTS**
- **Current Status:** Ongoing; moderators “actively managing” but problem persists
- **Impact Assessment:**
  - **User Impact:** **Critical** (hits essentially all new joiners who speak)
  - **Functional Impact:** **Partial** (blocks onboarding/support effectiveness)
  - **Brand Impact:** **High** (signals unsafe/unprofessional community)
- **Technical Classification:**
  - **Category:** Security / UX
  - **Component Affected:** Community Ops (Discord), Onboarding
  - **Complexity:** Moderate effort (requires layered mitigations + monitoring)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation tooling, anti-spam automation, community ops
  - **Dependencies:** Discord server settings; potential bot integration (AutoMod / third-party)
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Turn on/raise **Discord AutoMod** thresholds for first-time posters (keyword + link filters).
  2. Add **rate limits**: restrict posting links/attachments for accounts < X days or without verified email/phone.
  3. Create a **#start-here** flow: require reaction/role gating before posting in main discussion.
  4. Pin a **scam warning** and “team will never DM first” banner in key channels.
  5. Start a lightweight **incident log** (time, message patterns, accounts) to tune filters weekly.
- **Potential Assignees:** Arceon (raised issue), Odilitime (admin), server moderators

---

### 2) “Wrong Milady agent is running” (deployment/version mismatch)
- **Issue Title & ID:** Wrong Milady agent/version running (Discord) — **DISC-2026-03-02-MILADY-DEPLOY**
- **Current Status:** Reported; unanswered; suspected misconfiguration (mentions BSC version vs “correct”)
- **Impact Assessment:**
  - **User Impact:** **High** (anyone using/observing the Milady agent)
  - **Functional Impact:** **Yes** if production agent behavior is incorrect or tied to funds/actions
  - **Brand Impact:** **High** (public-facing agent running the wrong build undermines trust)
- **Technical Classification:**
  - **Category:** Bug / Ops
  - **Component Affected:** Deployment pipeline, Agent configs, Environment/versioning
  - **Complexity:** Moderate effort (root cause could be CI/CD, config drift, or registry mismatch)
- **Resource Requirements:**
  - **Required Expertise:** DevOps, release management, agent runtime configuration
  - **Dependencies:** Access to deployment logs, config repo/secrets, image tags/versions
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Identify the **canonical “Milady” agent spec** (repo/branch, chain target, config hash).
  2. Compare running instance **image tag/commit SHA** vs intended.
  3. Audit **env vars + chain configuration** (Solana/Base/BSC endpoints, keys, feature flags).
  4. Add “**/version**” or status endpoint to expose commit SHA + config checksum.
  5. After fix, publish a short **post-mortem** (what happened, how prevented).
- **Potential Assignees:** ElizaBAO (Milady integration work), Odilitime (core ops), relevant deploy maintainer(s)

---

### 3) Users reporting balances stuck on auto.fun
- **Issue Title & ID:** auto.fun stuck balances (Discord) — **DISC-2026-03-02-AUTOFUN-BALANCE**
- **Current Status:** Multiple reports; one user said they resolved it but no steps shared
- **Impact Assessment:**
  - **User Impact:** **High** (funds perceived as stuck → immediate user distress)
  - **Functional Impact:** **Partial** (may be external platform, but impacts ecosystem users)
  - **Brand Impact:** **High** (financial issues reflect back on elizaOS community perception)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** External integration / platform ops (auto.fun), Support playbooks
  - **Complexity:** Moderate effort (triage + reproduce + coordinate with platform)
- **Resource Requirements:**
  - **Required Expertise:** Web3 ops/support, transaction debugging, partner coordination
  - **Dependencies:** auto.fun team responsiveness; chain explorers; logs
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect a **minimum debug bundle** from affected users: chain, txid, wallet, timestamps, screenshots.
  2. Ask patatapicasa to document the **exact resolution steps** and post in a pinned thread.
  3. If auto.fun is partner-run, establish a **single escalation contact** + SLA expectations.
  4. Create a short **FAQ + troubleshooting checklist** to reduce repeated support load.
- **Potential Assignees:** Odilitime (community point), patatapicasa (known resolver), partner/ops liaison

---

### 4) Token confusion (Solana vs Base) creating scam risk
- **Issue Title & ID:** Confusion over “correct” ELIZAOS token/CA across chains (Discord) — **DISC-2026-03-02-TOKEN-CLARITY**
- **Current Status:** Active confusion; CA provided in chat; unanswered “team contact” questions
- **Impact Assessment:**
  - **User Impact:** **High** (many casual users; repeated question pattern)
  - **Functional Impact:** **No** (not framework runtime), but impacts ecosystem safety
  - **Brand Impact:** **High** (confusion enables scams / reputational harm)
- **Technical Classification:**
  - **Category:** Documentation / Security
  - **Component Affected:** Docs site, Discord pins, Website, Token/channel governance
  - **Complexity:** Simple fix (publish authoritative references) + ongoing moderation
- **Resource Requirements:**
  - **Required Expertise:** Documentation, community moderation
  - **Dependencies:** Agreement on canonical links (website, registry, verified social accounts)
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a **single canonical “Token & Contracts” page** (chains, CAs, verification steps).
  2. Pin that link in Discord **#discussion** and token channels; add to bot “!token” command.
  3. Add “**team will not DM first**” + “verify CA from official site” warnings.
  4. Provide an explicit “**How to reach the team**” entry (answering 0xBlock’s repeated question).
- **Potential Assignees:** Odilitime (already answering), Jin (content pipeline), Arceon (scam-prevention focus)

---

## P1 / P2 Engineering & Ecosystem Issues

---

### 5) Embedding failures on Linux for Ollama plugin
- **Issue Title & ID:** Embedding failures on Linux — **elizaos-plugins/plugin-ollama #17**
- **Current Status:** Identified; “began investigating” (from weekly summary)
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for servers/VPS)
  - **Functional Impact:** **Yes** for RAG/embedding-based memory/search workflows
  - **Brand Impact:** **Medium** (plugin reliability concerns)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Model Integration (Ollama), Embeddings pipeline
  - **Complexity:** Moderate effort (environment-specific; may involve native deps)
- **Resource Requirements:**
  - **Required Expertise:** Node/TS, Linux runtime debugging, Ollama API, vector/embedding toolchain
  - **Dependencies:** Repro steps, Ollama versions, CI coverage on Linux
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a **Linux CI job** that runs a minimal embedding smoke test.
  2. Capture matrix: distro, kernel, Ollama version, CPU/GPU, model used, response payload.
  3. Implement better **error surfacing** (actionable message when embeddings endpoint fails).
  4. Document known-good versions and fallback behavior.
- **Potential Assignees:** plugin-ollama maintainer(s), community infra contributors (e.g., Meme Broker for VPS-heavy contexts)

---

### 6) Heartbeat “cron” plugin needs canonical integration path via plugin-bootstrap tasks
- **Issue Title & ID:** Heartbeat plugin architecture alignment with plugin-bootstrap task service (Discord) — **DISC-2026-03-02-HEARTBEAT-TASKS**
- **Current Status:** In progress; guidance given; plugin updated but needs validation/adoption
- **Impact Assessment:**
  - **User Impact:** **Medium** (devs building autonomous agents)
  - **Functional Impact:** **Partial** (workarounds exist but fragmentation risk)
  - **Brand Impact:** **Medium** (ecosystem consistency/quality)
- **Technical Classification:**
  - **Category:** Bug / Architecture / DX
  - **Component Affected:** Plugin System, Task scheduling
  - **Complexity:** Moderate effort (integration + docs + examples)
- **Resource Requirements:**
  - **Required Expertise:** elizaOS plugin-bootstrap internals, scheduling/task semantics
  - **Dependencies:** Clear task service API stability in plugin-bootstrap
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a **reference example**: “scheduled tasks with plugin-bootstrap” (minimal repo).
  2. Add a **conformance checklist** for plugins that schedule work (quiet hours, backoff, budgets).
  3. Decide whether heartbeat becomes **official** (registry promotion) vs community plugin.
- **Potential Assignees:** Odilitime (architecture guidance), Meme Broker (author)

---

### 7) APEX Oracle v0.5.0: stress testing + safe integration patterns for APEX_TOKEN_SCAN
- **Issue Title & ID:** APEX Oracle API stress-test & integration feedback loop (Discord) — **DISC-2026-03-02-APEX-STRESSTEST**
- **Current Status:** Needs 5 developers; wrapper exists; integration underway
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily trading agent builders)
  - **Functional Impact:** **Partial** (enhancement; but could prevent losses/scams)
  - **Brand Impact:** **Medium** (quality of agent ecosystem, safer trading agents)
- **Technical Classification:**
  - **Category:** Performance / Feature
  - **Component Affected:** Plugin System, External API integration
  - **Complexity:** Moderate effort (load testing + response validation + latency budgets)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, load testing, trading agent evaluation, Solana data plumbing
  - **Dependencies:** API keys, rate limits, benchmark harness, reproducible evaluation dataset
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define a **standard eval harness**: latency, error rates, and “decision impact” logging.
  2. Add **circuit breakers**: timeouts, retries, fallback policy when APEX endpoint degrades.
  3. Provide a **schema contract** for JSON output and version it.
- **Potential Assignees:** Vlt9 (owner), Meme Broker (integrator), interested trading-agent contributors

---

## P2 / P3 Documentation & Product Clarity

---

### 8) Production guidance: “v2-develop vs alpha” and plugin viability (plugin-orchestrator / plugin-code)
- **Issue Title & ID:** Lack of clear “production-ready” guidance for branches/plugins (Discord) — **DISC-2026-02-28-PROD-GUIDE**
- **Current Status:** Unanswered questions; recurring confusion
- **Impact Assessment:**
  - **User Impact:** **High** (affects most builders choosing stack)
  - **Functional Impact:** **Partial** (mis-picks lead to instability/support load)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component Affected:** Core Framework release channels, Plugin registry metadata
  - **Complexity:** Simple fix (docs + labels), potentially moderate if release process changes
- **Resource Requirements:**
  - **Required Expertise:** Release management, documentation, plugin governance
  - **Dependencies:** Agreement on stability definitions + versioning policy
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a **“Stability Matrix”** page: alpha vs v2-develop vs tagged releases (who should use what).
  2. Mark plugins with **maturity tags** (Experimental/Beta/Stable) in the registry.
  3. Add “last tested against core version X” metadata for key plugins.
- **Potential Assignees:** Odilitime (core), registry maintainers, Jin (docs/content)

---

### 9) Token migration closed: reduce repeated questions + scam exposure
- **Issue Title & ID:** Token migration no longer available; users still ask (Discord) — **DISC-2026-03-01-MIGRATION-CLOSED**
- **Current Status:** Clarified ad-hoc; not visibly documented in onboarding
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (confusion + scam risk)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component Affected:** Docs, FAQ, Discord bot responses
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Docs, community tooling
  - **Dependencies:** None
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add a pinned FAQ: “**Migration closed** (date), no official conversion available.”
  2. Add bot command “!migration” returning the official stance and scam warning.
- **Potential Assignees:** Arceon (already answering), moderators

---

## Summary: Top Highest-Priority Issues (Next 24–72 hours)

1. **P0:** Scam bots targeting first-time posters (**DISC-2026-03-01-SCAMBOTS**)  
2. **P0:** Wrong Milady agent/version running (**DISC-2026-03-02-MILADY-DEPLOY**)  
3. **P1:** auto.fun stuck balance reports (**DISC-2026-03-02-AUTOFUN-BALANCE**)  
4. **P1:** Token/CA cross-chain confusion enabling scams (**DISC-2026-03-02-TOKEN-CLARITY**)  
5. **P1:** Ollama plugin embedding failures on Linux (**plugin-ollama #17**)  
6. **P2:** Heartbeat scheduling alignment via plugin-bootstrap tasks (**DISC-2026-03-02-HEARTBEAT-TASKS**)  
7. **P2:** APEX Oracle stress-test + safe integration patterns (**DISC-2026-03-02-APEX-STRESSTEST**)  

## Patterns / Themes Indicating Deeper Issues

- **Operational maturity gaps:** Reports of wrong agent deployments and stuck balances indicate missing runbooks, observability, and clear ownership boundaries (core vs partner platforms).
- **Trust & safety as a scaling bottleneck:** Scam bots + token confusion are compounding problems that directly impact onboarding and brand credibility.
- **Ecosystem fragmentation:** Multiple plugins introducing core-like capabilities (scheduling, memory, orchestration) without a single canonical path increases inconsistency and support burden.
- **Release-channel ambiguity:** Repeated questions about “alpha vs v2-develop” and plugin readiness suggest insufficient product signaling around stability.

## Recommendations (Process Improvements)

1. **Create an “Ops & Safety” rotation** (weekly owner) covering Discord anti-scam, partner escalations, and public incident responses.  
2. **Introduce a “Canonical Source of Truth” policy**: one official page for contracts, team contacts, migration status, and verified links—pinned everywhere.  
3. **Add lightweight release governance:** stability matrix + plugin maturity tags + “tested against core version” metadata.  
4. **Standardize deployment verification:** every public agent should expose **/version (commit SHA + config checksum)** and have a basic smoke-test checklist before promotion.  
5. **Require repro bundles for user-facing issues** (template for balances stuck, plugin failures, latency), reducing time-to-triage and back-and-forth.