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

### 1) Persistent scam bots/impersonation targeting new Discord users
- **Issue Title & ID:** Scam bots DM/impersonation attacks in Discord onboarding flow — **DISCORD-SEC-2026-03-01**
- **Current Status:** **Ongoing**; moderators “actively managing” but problem persists; users report scammers intercepting “how to get started” questions.
- **Impact Assessment:**
  - **User Impact:** **High** (targets every new/first-time poster)
  - **Functional Impact:** **Partial** (blocks support/onboarding, not runtime)
  - **Brand Impact:** **High** (trust/safety perception, risk of users being drained/scammed)
- **Technical Classification:**
  - **Issue Category:** **Security / UX**
  - **Component Affected:** **Community/Support Infrastructure (Discord)**
  - **Complexity:** **Moderate effort** (requires layered mitigations + ongoing tuning)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, anti-spam systems, security comms
  - **Dependencies:** None, but benefits from clear official support workflow + docs
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Enable/strengthen anti-raid & verification gates (e.g., timed membership, phone/email verify, restrict DMs via onboarding instructions).
  2. Add an **official “Support: We never DM first”** auto-reply + pinned message + welcome banner; include official links only.
  3. Configure AutoMod rules for first-message patterns that trigger scam swarms (keywords like “migration”, “help”, “ticket”).
  4. Create a single **#start-here** channel with locked posting + curated steps; redirect onboarding questions there.
  5. Set up a lightweight incident playbook: how to report, how mods respond, how to publish warnings.
- **Potential Assignees:** **Arceon** (active in incident response), **Discord moderator team**, **Omid Sa** (security awareness), **aicodeflow** (reliability/process input)

---

### 2) v2.0.0 bcrypt issue requiring patches
- **Issue Title & ID:** v2.0.0 bcrypt install/runtime breakage requiring manual patch — **DISCORD-RUNTIME-2026-02-27-BCRYPT**
- **Current Status:** **Known issue**; community guidance suggests patching; v2.0.0 described as “very much alpha”.
- **Impact Assessment:**
  - **User Impact:** **High** (affects new installs / anyone attempting v2.0.0)
  - **Functional Impact:** **Yes** (can block startup/auth flows depending on usage)
  - **Brand Impact:** **High** (first-run failure, “alpha feels broken”)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Core Framework / Runtime dependencies**
  - **Complexity:** **Moderate effort** (depends on root cause: native module, bundling, Node version, fallback)
- **Resource Requirements:**
  - **Required Expertise:** Node.js native deps, build tooling, CI matrix, dependency management
  - **Dependencies:** Clarify supported Node versions; may relate to release packaging
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce in CI across OS/Node versions; publish an “officially supported Node versions” table for v2.0.0.
  2. Determine whether bcrypt can be swapped to **bcryptjs** or a prebuilt-compatible variant as a temporary mitigation.
  3. Ship a patch release or hotfix branch; document the workaround in release notes until fixed.
  4. Add a startup preflight check that fails with an actionable message rather than crashing.
- **Potential Assignees:** **Core runtime maintainers**, **Odilitime** (triage context), **Shaw** (v2 autonomy integration context)

---

### 3) Multiple core plugins broken out-of-the-box on elizaOS 1.7.2
- **Issue Title & ID:** plugin-linear / plugin-rolodex / plugin-memory broken OOTB on 1.7.2 — **DISCORD-PLUGINS-2026-02-27-1.7.2**
- **Current Status:** **Reported** by users; requires manual patching; “many runtime versions” cited as cause.
- **Impact Assessment:**
  - **User Impact:** **High** (common workflow plugins)
  - **Functional Impact:** **Partial → Yes** (blocks typical “agent with memory + integrations” setup)
  - **Brand Impact:** **High** (ecosystem appears unreliable)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin System / Plugin compatibility**
  - **Complexity:** **Complex solution** (versioning/compat contracts + backports)
- **Resource Requirements:**
  - **Required Expertise:** Plugin API, semantic versioning, release engineering, integration testing
  - **Dependencies:** Decision on “supported stable line” (v2-develop vs alpha vs 1.7.2)
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a compatibility matrix: **runtime version ↔ plugin versions** known-good pairs.
  2. Add contract tests for these plugins in CI (smoke tests: load, auth, basic action).
  3. Publish “recommended baseline” guidance (if **v2-develop** is preferred for stability, make it explicit).
  4. Backport minimal fixes or pin plugin versions for 1.7.2 users to stop the bleeding.
- **Potential Assignees:** **Odilitime** (versioning guidance), **plugin maintainers** (Linear/Memory/Rolodex), **Julio Holon** (reporter, can verify fixes)

---

### 4) Embedding failures on Linux in plugin-ollama
- **Issue Title & ID:** Embedding failures on Linux environments — **elizaos-plugins/plugin-ollama#17**
- **Current Status:** **Investigating** (noted in weekly summary).
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Linux is common for servers/VPS deployments)
  - **Functional Impact:** **Partial** (breaks embeddings/memory/search features)
  - **Brand Impact:** **Medium** (integration reliability concern)
- **Technical Classification:**
  - **Issue Category:** **Bug / Compatibility**
  - **Component Affected:** **Model Integration (Ollama)**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linux environment debugging, Ollama APIs, embeddings pipeline, dependency/ABI issues
  - **Dependencies:** Repro details (distro, CPU/GPU, ollama version), test fixture
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect repro matrix (Ubuntu/Debian/Arch; ollama versions; container vs bare metal).
  2. Add a minimal embeddings smoke test in CI (Linux runner) with mocked/fallback if needed.
  3. Improve error handling: surface “ollama not reachable / model missing / incompatible response” distinctly.
  4. Document known-good ollama + model versions for embeddings.
- **Potential Assignees:** **plugin-ollama maintainers**, **aicodeflow** (reliability focus), community Linux operators (e.g., **Meme Broker** via VPS work)

---

### 5) Regulatory/compliance risk: credit-building automation plugin (FCRA safeguards)
- **Issue Title & ID:** Add FCRA compliance verification & dispute safeguards for credit-builder plugin — **DISCORD-COMPLIANCE-2026-02-27-FCRA**
- **Current Status:** **Open question**; compliance approach not answered yet.
- **Impact Assessment:**
  - **User Impact:** **Medium** (plugin-specific) but high consequence
  - **Functional Impact:** **Partial** (plugin can work, but unsafe to deploy broadly)
  - **Brand Impact:** **High** (legal/regulatory fallout risk)
- **Technical Classification:**
  - **Issue Category:** **Security / Feature (Guardrails)**
  - **Component Affected:** **Plugin System (credit-builder)**
  - **Complexity:** **Complex solution** (policy + workflow constraints + auditing)
- **Resource Requirements:**
  - **Required Expertise:** Compliance/legal-informed engineering, workflow approvals, audit logging
  - **Dependencies:** Product decision: whether to distribute as “plugin-form candidate” with required safeguards
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define a “high-stakes automation” standard: mandatory human approval, evidence capture, audit logs.
  2. Add hard constraints: prevent mass/disallowed dispute templates; require user-provided documentation checks.
  3. Implement a compliance checklist in README and runtime prompts (agent must confirm conditions).
  4. Decide distribution posture: experimental vs vetted, and label accordingly in registry.
- **Potential Assignees:** **Meme Broker** (plugin author), **Caesar ⚔️** (raised safeguards), **Odilitime** (quality standards), a volunteer with compliance background

---

### 6) Version fragmentation and unclear “production-ready” guidance (v2-develop vs alpha vs v2.0.0)
- **Issue Title & ID:** Confusing version/channel guidance leading to broken builds — **DISCORD-RELEASE-2026-02-28-VERSIONS**
- **Current Status:** **Ongoing**; community recommends v2-develop for “more mature 1.x code”; v2.0.0 called alpha; users unsure what to ship.
- **Impact Assessment:**
  - **User Impact:** **High** (affects most builders choosing a baseline)
  - **Functional Impact:** **Partial** (causes misinstalls, broken plugins)
  - **Brand Impact:** **High** (“everything breaks every release” narrative)
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX / Release Engineering**
  - **Component Affected:** **Core Framework + Plugin ecosystem**
  - **Complexity:** **Architectural change** (or at least governance-level release discipline)
- **Resource Requirements:**
  - **Required Expertise:** Release management, semver discipline, CI policy, docs
  - **Dependencies:** Agreement on stable branch policy and support windows
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single “Which version should I use?” page with **clear categories**: Stable / Preview / Alpha.
  2. Define support windows and plugin compatibility rules (e.g., “plugins must declare minimum runtime”).
  3. Add automated checks in plugin repos to prevent releasing incompatible versions without bumping requirements.
  4. Create a “Known Issues” changelog section per release (bcrypt, broken plugins, etc.).
- **Potential Assignees:** **Odilitime** (already guiding), **core maintainers**, **docs maintainers**, **aicodeflow** (process/reliability input)

---

### 7) Potential architectural regression: plugins “creeping back” into core (PR #6531)
- **Issue Title & ID:** Review PR for reintroducing plugin code into core — **elizaos/eliza#6531 (PR review)**
- **Current Status:** **Concern raised**; needs explicit architectural review decision.
- **Impact Assessment:**
  - **User Impact:** **Medium** (long-term maintainability)
  - **Functional Impact:** **No** immediate, but can erode modularity
  - **Brand Impact:** **Medium** (signals architectural churn)
- **Technical Classification:**
  - **Issue Category:** **Architecture / Maintenance**
  - **Component Affected:** **Core Framework / Plugin System boundaries**
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Architecture stewardship, codebase modularity, dependency boundaries
  - **Dependencies:** Clear policy on what belongs in core vs plugin
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Perform architecture review: confirm whether functionality must be core (security/perf) or should remain plugin.
  2. If plugin code is justified in core, document rationale and create a “core inclusion checklist”.
  3. If not justified, request changes: extract back into plugin package + define interface.
- **Potential Assignees:** **Odilitime**, **core maintainers**, PR author/reviewer group

---

### 8) Autonomy/cron-like behavior unclear; multiple competing autonomy mechanisms
- **Issue Title & ID:** Cron-like autonomous scheduling unclear across tasks system / plugin-autonomous / v2 built-in / milaidy — **DISCORD-AUTONOMY-2026-02-28-CRON**
- **Current Status:** **Unanswered/unclear** for users implementing production workflows (e.g., monitoring Linear blocked issues).
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (common requirement for agents “doing work”)
  - **Functional Impact:** **Partial** (blocks autonomous ops without bespoke code)
  - **Brand Impact:** **Medium** (perceived fragmentation)
- **Technical Classification:**
  - **Issue Category:** **Documentation / Feature**
  - **Component Affected:** **Core Framework + Plugin ecosystem**
  - **Complexity:** **Moderate effort** (docs + a reference implementation)
- **Resource Requirements:**
  - **Required Expertise:** Agent runtime scheduling, plugin-autonomous, v2 autonomy, example apps
  - **Dependencies:** Decision on “recommended autonomy path” for each release line
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a definitive guide: “Autonomy in elizaOS” with when-to-use each mechanism.
  2. Provide a reference template: hourly poll + summarization + action proposal + human approval.
  3. Clarify whether plugin-pim covers chat-configurable cron and how it integrates.
- **Potential Assignees:** **Shaw** (v2 autonomy), **Odilitime** (ecosystem knowledge), **Julio Holon** (use-case validator)

---

### 9) Onboarding question “How do I get started?” not answered; scammers intercept support requests
- **Issue Title & ID:** Missing canonical onboarding path and support workflow — **DISCORD-DOCS-2026-03-01-GETSTARTED**
- **Current Status:** **Open**; legitimate onboarding question went unanswered due to scam interference.
- **Impact Assessment:**
  - **User Impact:** **High** (new devs/users)
  - **Functional Impact:** **Partial** (blocks adoption)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **Docs + Community workflows**
  - **Complexity:** **Simple fix → Moderate effort** (write docs + pin + bot automation)
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, developer experience, Discord config
  - **Dependencies:** Align with versioning guidance (Issue #6)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a single pinned “Start Here (5 minutes)” with: install, recommended branch, minimal agent, where to ask questions.
  2. Add a Discord bot auto-response when users ask “get started”, linking to official docs only.
  3. Add a “report scams” CTA in the same flow.
- **Potential Assignees:** **Docs maintainers**, **Arceon/mods**, **Odilitime**, **aicodeflow** (DX perspective)

---

### 10) Polymarket plugin integration for Milady (v2.0 custom build)
- **Issue Title & ID:** Package/standardize Polymarket integration as an official plugin (currently custom) — **DISCORD-FEATURE-2026-03-01-POLYMARKET**
- **Current Status:** **In progress (custom integration)**; offer to share privately; not yet standardized.
- **Impact Assessment:**
  - **User Impact:** **Medium** (new capability; not required for core)
  - **Functional Impact:** **No** (feature expansion)
  - **Brand Impact:** **Medium** (positive if released cleanly; negative if it fragments v2 further)
- **Technical Classification:**
  - **Issue Category:** **Feature Request**
  - **Component Affected:** **Plugin System / Model Integration / External APIs**
  - **Complexity:** **Complex solution** (API keys, risk controls, testing, distribution)
- **Resource Requirements:**
  - **Required Expertise:** Plugin authoring, Polymarket API, security (keys), deterministic execution, testing
  - **Dependencies:** Stable v2 plugin interfaces; guidance from Issue #6
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Extract integration into a standalone plugin repo with clear config + secrets handling.
  2. Add sandbox mode + rate limiting + audit logs (especially for market actions).
  3. Publish minimal example agent and integration tests.
- **Potential Assignees:** **ElizaBAO** (implementation owner), plugin maintainers, security reviewer(s)

---

## Summary — Top Highest-Priority Issues to Address Immediately (Next 1–2 weeks)

1. **P0:** Persistent Discord scam/impersonation attacks impacting onboarding (**DISCORD-SEC-2026-03-01**)  
2. **P0:** **v2.0.0 bcrypt** breakage blocking installs/usage (**DISCORD-RUNTIME-2026-02-27-BCRYPT**)  
3. **P1:** Core plugins broken OOTB on **1.7.2** (Linear/Rolodex/Memory) (**DISCORD-PLUGINS-2026-02-27-1.7.2**)  
4. **P1:** Linux embedding failures in **plugin-ollama** (**plugin-ollama#17**)  
5. **P1:** Release/version fragmentation causing repeated breakage perception (**DISCORD-RELEASE-2026-02-28-VERSIONS**)  
6. **P1:** Missing canonical “Get Started” flow + official support workflow (**DISCORD-DOCS-2026-03-01-GETSTARTED**)  
7. **P1:** Compliance guardrails for credit-builder automation (FCRA safeguards) (**DISCORD-COMPLIANCE-2026-02-27-FCRA**)  
8. **P2:** Architectural boundary concerns (plugins creeping into core) (**elizaos/eliza#6531**)  

---

## Patterns / Themes Suggesting Deeper Issues

- **Release/channel ambiguity + compatibility drift:** Users can’t reliably choose a baseline; plugins break across runtime versions, driving manual patching and undermining trust.
- **Insufficient automated compatibility testing:** Common integrations (memory, Linear, embeddings) fail without CI smoke tests and explicit compatibility declarations.
- **Fragmented autonomy story:** Multiple overlapping autonomy mechanisms without a single recommended path creates confusion for production workflows.
- **Security is not only code:** Community/social attack surface (Discord scams) is materially harming adoption and perceived project quality.

---

## Recommendations — Process Improvements

1. **Define and publish a stable support policy**
   - One clearly labeled “Stable” line with a support window; everything else explicitly “Preview/Alpha”.
2. **Add cross-repo integration smoke tests**
   - Minimal “agent boots + plugin loads + one action” tests for top plugins on Linux/macOS/Windows.
3. **Adopt a compatibility contract**
   - Plugins must declare required runtime range; CI blocks releases that violate declared compatibility.
4. **Ship “Known Issues” and “Workarounds” with every release**
   - Especially for installer/runtime blockers (e.g., bcrypt), with copy-pastable fixes until patched.
5. **Harden onboarding and support channels**
   - A single official onboarding funnel, bot-driven link hygiene, and a documented anti-scam playbook.