# Issue Triage — 2026-03-01

## 1) **Most plugins broken out-of-the-box on ElizaOS v1.7.2**
- **Issue Title & ID:** Plugins (plugin-linear, plugin-rolodex, plugin-memory) broken OOTB on v1.7.2 — **DISCORD-2026-02-27-PLUGINS-172**
- **Current Status:** Reported by users; requires manual patching; no confirmed upstream fix yet.
- **Impact Assessment:**
  - **User Impact:** **High** (hits common “getting started” flows)
  - **Functional Impact:** **Partial** (core can run, but key integrations fail)
  - **Brand Impact:** **High** (perceived instability / “nothing works” first impression)
- **Technical Classification:**
  - **Category:** Bug / Compatibility
  - **Component:** Plugin System + Core runtime versioning/SDK
  - **Complexity:** **Moderate effort** (likely version pinning + adapter fixes + release packaging)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript/Node monorepo practices, plugin SDK versioning, CI/release tooling
  - **Dependencies:** Clarify supported runtime matrix (v1.7.2 vs v2-develop vs v2.0.0 alpha); plugin CI needs canonical “smoke test”
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce on clean install for each plugin with a published “quickstart” script.
  2. Identify the breaking interface(s) (SDK API change, config schema change, build tooling).
  3. Ship a hotfix path: either (a) backport compatibility layer into v1.7.2, or (b) clearly deprecate v1.7.2 and redirect to v2-develop with migration steps.
  4. Add CI “plugin canary suite” that runs basic init + one happy-path action per key plugin.
- **Potential Assignees:** **Odilitime** (runtime/version context), maintainers of **plugin-linear / plugin-memory**, plus a CI-focused contributor (release engineering)

---

## 2) **bcrypt issue in v2.0.0 requiring patches**
- **Issue Title & ID:** v2.0.0 bcrypt dependency/build failure requiring patches — **DISCORD-2026-02-27-BCRYPT-V2**
- **Current Status:** Known issue; users report patching required; no public resolution confirmed.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks installs/builds for alpha adopters)
  - **Functional Impact:** **Yes** (can prevent runtime from starting or installing)
  - **Brand Impact:** **High** (alpha is expected rough, but build blockers reduce adoption/testing)
- **Technical Classification:**
  - **Category:** Bug / Build & Dependencies
  - **Component:** Core Framework packaging + native deps
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node native modules, cross-platform build (Linux/macOS/Windows), dependency replacement (bcrypt vs bcryptjs)
  - **Dependencies:** Decide supported Node versions; align with CI runners; document workaround until fixed
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish minimal reproduction (Node version, OS/arch, install command).
  2. Evaluate replacing bcrypt with a pure-JS alternative or shipping prebuilds.
  3. Add CI matrix to fail fast on bcrypt install/compile across platforms.
  4. Post an “alpha known issues” entry with an official workaround until patched release lands.
- **Potential Assignees:** Core maintainers; **Odilitime** (triage + guidance), a contributor experienced with Node native modules

---

## 3) **plugin-ollama embeddings failing on Linux**
- **Issue Title & ID:** Embedding failures on Linux environments — **elizaos-plugins/plugin-ollama#17**
- **Current Status:** Identified and “began investigating” (open/ongoing).
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Linux is common for servers/VPS; embeddings are foundational)
  - **Functional Impact:** **Partial** (chat may work, but memory/retrieval features degrade or fail)
  - **Brand Impact:** **Medium** (hurts “runs on a VPS” expectations)
- **Technical Classification:**
  - **Category:** Bug / Platform Compatibility
  - **Component:** Model Integration (Ollama embeddings) + Plugin
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linux environments, Ollama API specifics, embeddings pipeline, dependency/ABI issues
  - **Dependencies:** Confirm Ollama version compatibility; verify endpoint/parsing; ensure deterministic tests
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect failing logs (HTTP status, payload sizes, model name, Ollama server version).
  2. Add a Linux CI job that runs a minimal local embedding call (mockable if needed).
  3. Validate model naming and embedding endpoint differences across Ollama versions.
  4. Implement better error messages + fallback behavior (disable embeddings gracefully).
- **Potential Assignees:** plugin-ollama maintainers; a Linux-focused contributor; model-integration maintainer

---

## 4) **Twitter input integration not working (version unclear)**
- **Issue Title & ID:** Twitter input functionality failing (needs version/product details) — **DISCORD-2026-02-26-TWITTER-INPUT**
- **Current Status:** Unresolved; blocked on reporter providing version/product info.
- **Impact Assessment:**
  - **User Impact:** **Medium** (important channel; unclear breadth)
  - **Functional Impact:** **Partial** (blocks a major integration for affected users)
  - **Brand Impact:** **Medium** (social integrations are high-visibility)
- **Technical Classification:**
  - **Category:** Bug / Integration
  - **Component:** Plugin System / Social integration (Twitter/X)
  - **Complexity:** **Moderate effort** (often auth/API drift)
- **Resource Requirements:**
  - **Required Expertise:** OAuth/auth flows, Twitter/X API changes, plugin configuration
  - **Dependencies:** Need exact runtime branch + plugin version + credentials mode
  - **Estimated Effort (1-5):** **2** (once reproducible)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create an issue intake checklist (runtime version, plugin version, API tier, error logs, minimal config).
  2. Reproduce against current Twitter API requirements; update docs/config defaults.
  3. Add an integration “health check” command to validate credentials and webhook/polling.
- **Potential Assignees:** Social integration/plugin maintainer; **Odilitime** for initial triage; a contributor with OAuth/API experience

---

## 5) **Governance/architecture drift: plugins “creeping back into” core codebase**
- **Issue Title & ID:** Plugins reintroduced into core (architecture boundary regression) — **elizaos/eliza PR#6531 (Concern)**
- **Current Status:** Raised as a concern; needs architectural review decision.
- **Impact Assessment:**
  - **User Impact:** **Medium** (indirect, but increases long-term instability)
  - **Functional Impact:** **No** (not an immediate runtime failure)
  - **Brand Impact:** **High** (signals lack of modular discipline; increases breakage rate)
- **Technical Classification:**
  - **Category:** Architectural / Maintenance
  - **Component:** Core Framework + Plugin System boundaries
  - **Complexity:** **Architectural change** (policy + refactor patterns)
- **Resource Requirements:**
  - **Required Expertise:** Architecture stewardship, monorepo modularization, dependency boundaries
  - **Dependencies:** Clear policy: what belongs in core vs plugins; enforce with tooling (lint rules / dep constraints)
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Review PR#6531 for boundary violations; decide accept/reject with rationale.
  2. Document “Core vs Plugin” decision record (ADR) and publish contributor guidance.
  3. Add automated checks to prevent importing plugin-only code into core (package boundary rules).
- **Potential Assignees:** Core maintainers; **Odilitime** (raised concern); a maintainer familiar with repo architecture

---

## 6) **Unclear production guidance: v2-develop vs v2.0.0 alpha vs 1.x**
- **Issue Title & ID:** Production version selection guidance unclear (v2-develop vs alpha) — **DISCORD-2026-02-28-VERSION-GUIDE**
- **Current Status:** Users actively confused; partial guidance exists in chat but not codified.
- **Impact Assessment:**
  - **User Impact:** **High** (affects most new adopters)
  - **Functional Impact:** **Partial** (leads to broken installs, wasted time)
  - **Brand Impact:** **High** (signals instability/opacity)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component:** Core Framework releases + docs site
  - **Complexity:** **Simple fix** (content + release labeling), but requires alignment
- **Resource Requirements:**
  - **Required Expertise:** Release management, documentation, maintainer consensus
  - **Dependencies:** Agreement on support policy and compatibility matrix
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a “Which branch should I use?” table (Use-case → recommended branch → caveats).
  2. Add “Support status” badges: alpha/beta/stable, and “last validated plugin set.”
  3. Pin guidance in Discord + link from README.
- **Potential Assignees:** Docs maintainers; **Odilitime** (has context); release manager/maintainer

---

## 7) **Cron-like autonomy implementation unclear (multiple competing autonomy systems)**
- **Issue Title & ID:** Cron-like autonomous behavior guidance unclear (plugin-autonomous vs v2 autonomy vs tasks vs plugin-pim) — **DISCORD-2026-02-28-AUTONOMY-CRON**
- **Current Status:** Unanswered in the referenced thread; multiple parallel implementations exist.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (common enterprise workflow need)
  - **Functional Impact:** **Partial** (blocks autonomous workflows unless users custom-build)
  - **Brand Impact:** **Medium** (confusing ecosystem story)
- **Technical Classification:**
  - **Category:** UX / Documentation (and potentially Feature consolidation)
  - **Component:** Core Framework autonomy + Plugin ecosystem
  - **Complexity:** **Moderate effort** (docs + a recommended reference implementation)
- **Resource Requirements:**
  - **Required Expertise:** Agent runtime scheduling, persistence, job queues, plugin APIs
  - **Dependencies:** Decide “blessed” path for cron-like scheduling and how it’s configured (chat vs config)
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document the three autonomy options and when to use each (with a minimal cron example).
  2. Provide one canonical “scheduled job” sample project.
  3. Decide whether chat-configurable scheduling is in-scope (plugin-pim?) and track gaps.
- **Potential Assignees:** **Shaw** (v2 autonomy), plugin-autonomous maintainer, **Odilitime** (ecosystem overview), a contributor experienced with schedulers/queues

---

## 8) **plugin-orchestrator and plugin-code viability/testing status unknown**
- **Issue Title & ID:** plugin-orchestrator + plugin-code testing/viability not documented — **DISCORD-2026-02-28-PLUGIN-VIABILITY**
- **Current Status:** Unanswered; no published compatibility/test matrix.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects teams choosing automation/tooling plugins)
  - **Functional Impact:** **Partial** (risk of adopting broken/unsafe plugins)
  - **Brand Impact:** **Medium–High** (perception that ecosystem is unvetted)
- **Technical Classification:**
  - **Category:** Documentation / QA
  - **Component:** Plugin ecosystem + Registry practices
  - **Complexity:** **Simple fix** (status + tests), possibly **Moderate** if CI missing
- **Resource Requirements:**
  - **Required Expertise:** Plugin CI, smoke testing, runtime matrix
  - **Dependencies:** Standardize plugin “compatibility contract” and minimal tests
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add README badges: “last tested against” (branch/commit) + “maintained/unmaintained.”
  2. Create a minimal “plugin certification” checklist (install, init, one action).
  3. If unmaintained, mark clearly and suggest alternatives.
- **Potential Assignees:** Plugin authors/maintainers; registry maintainers; QA-minded contributor

---

## 9) **Compliance risk: credit-building plugin needs FCRA safeguards**
- **Issue Title & ID:** Credit-building automation plugin lacks documented FCRA compliance verification/safeguards — **DISCORD-2026-02-27-FCRA-COMPLIANCE**
- **Current Status:** Concern raised; no safeguards described publicly in thread.
- **Impact Assessment:**
  - **User Impact:** **Medium** (depends on adoption, but stakes are high)
  - **Functional Impact:** **Partial** (plugin may work, but unsafe to use without guardrails)
  - **Brand Impact:** **High** (legal/regulatory reputational risk to ecosystem)
- **Technical Classification:**
  - **Category:** Security / Safety / Compliance
  - **Component:** Plugin System (regulated workflow automation)
  - **Complexity:** **Complex solution** (policy + UI/UX guardrails + audit logs)
- **Resource Requirements:**
  - **Required Expertise:** Compliance/legal-aware engineering, audit logging, human-in-the-loop design
  - **Dependencies:** Define “safe mode” requirements; terms/disclaimers; potential legal review
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P1** (treat as high urgency before promoting/adopting broadly)
- **Specific Actionable Next Steps:**
  1. Require explicit user confirmations + templated dispute boundaries (prevent “improper disputes”).
  2. Implement audit logs (what was sent, why, user approval, timestamps).
  3. Add a compliance checklist to plugin-form candidacy (including jurisdictional warnings).
  4. Consider rate limits + “cannot proceed” rules when evidence/criteria are missing.
- **Potential Assignees:** Plugin author (**Meme Broker**), **Caesar** (raised compliance concern), a maintainer to define ecosystem compliance standards

---

## 10) **Security/community risk: Discord scam links and DMs**
- **Issue Title & ID:** Ongoing scam attempts via ticket links/DMs — **DISCORD-2026-02-27-SCAM-AWARENESS**
- **Current Status:** Active warnings shared; needs systematic mitigation.
- **Impact Assessment:**
  - **User Impact:** **High** (community-wide exposure)
  - **Functional Impact:** **No** (not a code break)
  - **Brand Impact:** **High** (trust and safety perception)
- **Technical Classification:**
  - **Category:** Security / Community Ops
  - **Component:** Discord moderation + community processes
  - **Complexity:** **Moderate effort** (bots, permissions, playbooks)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation, bot configuration, incident response
  - **Dependencies:** Mod permissions, standardized reporting flow, pinned announcements
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Pin an official “No tickets in DMs” + “staff will never DM first” policy in key channels.
  2. Add AutoMod rules for common scam patterns (ticket keywords, suspicious domains).
  3. Create a single official support entry point and verification method for staff.
- **Potential Assignees:** Community mods/admins; **Omid Sa** (raised awareness); security-focused community volunteers

---

# Highest Priority Summary (Top 5–10 to address now)
1. **P0:** Plugins broken OOTB on **v1.7.2** (DISCORD-2026-02-27-PLUGINS-172)  
2. **P0:** **v2.0.0 bcrypt** install/build blocker (DISCORD-2026-02-27-BCRYPT-V2)  
3. **P1:** **plugin-ollama Linux embedding failures** (plugin-ollama#17)  
4. **P1:** **Twitter input integration failing** (DISCORD-2026-02-26-TWITTER-INPUT)  
5. **P1:** **Core/plugin boundary regression concern** (eliza PR#6531)  
6. **P1:** **Production version/branch guidance** is unclear (DISCORD-2026-02-28-VERSION-GUIDE)  
7. **P1:** **FCRA compliance safeguards** for credit-building plugin (DISCORD-2026-02-27-FCRA-COMPLIANCE)  
8. **P1:** **Discord scam mitigation** (DISCORD-2026-02-27-SCAM-AWARENESS)  
9. **P2:** **Cron-like autonomy** guidance and canonical approach (DISCORD-2026-02-28-AUTONOMY-CRON)  
10. **P2:** **plugin-orchestrator/plugin-code viability** status + tests (DISCORD-2026-02-28-PLUGIN-VIABILITY)

---

# Patterns / Themes Indicating Deeper Issues
- **Version fragmentation + breaking changes** are creating a “works only if you know the secret branch” experience (v1.7.2 vs v2-develop vs v2.0.0 alpha).
- **Lack of a validated compatibility matrix** between core runtime(s) and the “standard plugin set” drives repeated onboarding failures.
- **Multiple overlapping autonomy systems** (plugin-autonomous, v2 built-in autonomy, tasks system, milaidy) indicate an ecosystem that needs consolidation or at least a clearly blessed reference path.
- **Governance boundaries (core vs plugins)** appear unstable, risking long-term maintainability and increasing breakage frequency.

---

# Process Improvement Recommendations
1. **Publish and enforce a Runtime × Plugin Compatibility Matrix** (automated nightly “canary” runs against v2-develop and the latest tagged release).
2. **Adopt “Known Issues” and “Support Status” release notes** (alpha/beta/stable labels; explicit “do/don’t use in production” guidance).
3. **Add plugin certification levels in the registry** (e.g., Community / Verified / Maintained), requiring minimal smoke tests and a “last tested with” badge.
4. **Create Architecture Decision Records (ADRs)** for core-vs-plugin boundaries and autonomy strategy; enforce with tooling (dependency constraints).
5. **Standardize issue intake templates for integrations** (Twitter/X, Google, Linear, etc.) to avoid stalled triage due to missing version/config details.