## Issue Triage — 2026-04-25

### 1) “feat(virus): add autonomous rust agent (concept art)” — PR #6613 (elizaos/eliza)
- **Current Status:** Open PR (unmerged); flagged by automated review as malware-like behavior (persistence + idle-time execution + unrestricted shell).
- **Impact Assessment:**
  - **User Impact:** Medium (directly affects anyone who builds/runs it), **but** could become High if it ships in official artifacts.
  - **Functional Impact:** Partial (not blocking core runtime, but contaminates repo/distribution surface).
  - **Brand Impact:** **High** (association with RAT-like behavior under elizaOS brand).
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Examples/Tooling distribution, Repo integrity (monorepo)
  - **Complexity:** Simple fix (process decision + removal/quarantine), but may require governance decision
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, OSS governance/release management
  - **Dependencies:** None (can be actioned immediately by maintainers)
  - **Estimated Effort (1-5):** 2
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add a maintainer comment formally stating this PR will not be merged as-is due to persistence + autonomous shell execution.
  2. Close PR or request major changes: move to external repo, remove persistence/stealth, remove unrestricted shell, add explicit “unsafe research” labeling and build-time exclusions.
  3. Add a CI policy gate: block new packages that implement autostart/persistence or unrestricted command execution without explicit security approval.
- **Potential Assignees:** odilitime (release/maintainer), lalalune (core maintainer), ai16z-demirix (security reviewer), stan0473 (core dev review)

---

### 2) “Implement a data-sanitization layer to protect user privacy before information reaches AI models” — Issue #7007 (elizaos/eliza)
- **Current Status:** Open (new initiative referenced in weekly summary).
- **Impact Assessment:**
  - **User Impact:** **High** (all users who pass PII/credentials through agents)
  - **Functional Impact:** Partial (framework works, but unsafe-by-default flows risk data leakage)
  - **Brand Impact:** **High** (privacy regressions severely harm trust and adoption)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Core Framework (prompt assembly, providers, memory, logging, tool calls)
  - **Complexity:** Complex solution (needs consistent interception points + tests + policy design)
- **Resource Requirements:**
  - **Required Expertise:** Security/privacy engineering, prompt/tooling pipeline, logging/memory internals
  - **Dependencies:** Alignment with runtime message pipeline changes (reflection/providers prompt bloat work suggests active churn)
  - **Estimated Effort (1-5):** 5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Define a minimal v1 threat model: what counts as PII/secrets; where it can leak (logs, memory, provider payloads, tool args).
  2. Implement a central “sanitize()” hook in the message/tool execution pipeline (pre-model + pre-tool + pre-log).
  3. Add fixtures/tests: redact API keys, emails, phone numbers, addresses, wallet seeds; ensure reversibility rules (never store raw secrets).
  4. Provide opt-in/opt-out config with safe defaults; document behavior clearly.
- **Potential Assignees:** odilitime (core runtime), lalalune (message service), NubsCarson (runtime/plugin load hardening), dutchiono (cross-plugin consistency)

---

### 3) “Release stable v2 (currently alpha) / clarify v2 stability + release timing” — (Tracking Item; Discord + dev planning)
- **Current Status:** Not a single GitHub issue in provided data; repeatedly requested by plugin builders (Discord).
- **Impact Assessment:**
  - **User Impact:** **High** (builders waiting on stable target; reduces ecosystem shipping)
  - **Functional Impact:** Yes (blocks production adoption decisions and plugin port schedules)
  - **Brand Impact:** Medium (alpha forever signals instability)
- **Technical Classification:**
  - **Issue Category:** Documentation / Release Engineering
  - **Component Affected:** Core Framework, Plugin System, CI/CD
  - **Complexity:** Moderate effort (release criteria + cut process + versioning clarity)
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, CI, package publishing, semver policy
  - **Dependencies:** Resolve known release blockers; ensure plugin pipeline stability (anthropic pipeline stabilization noted)
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create/confirm a single “v2 stable release checklist” issue (tests, docs, migration notes, CI green across matrix).
  2. Publish a target date + criteria (what “alpha → stable” means).
  3. Ensure registry + key plugins (anthropic, discord, sql, x402) are compatible with the release candidate.
- **Potential Assignees:** odilitime, stan0473, lalalune

---

### 4) “fix(runtime): handle IGNORE action fallback…” — PR #6543 (elizaos/eliza) (type mismatch blocks merge)
- **Current Status:** Open PR; automated review reports a critical type mismatch in `embedding.ts` (passing `input` instead of `text` to cached embedding retrieval).
- **Impact Assessment:**
  - **User Impact:** Medium (affects runtime stability for some model responses; IGNORE handling is common)
  - **Functional Impact:** Partial (can cause runtime errors depending on execution path)
  - **Brand Impact:** Medium (core runtime reliability)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (`@elizaos/core` embedding + runtime)
  - **Complexity:** Simple fix (single-line variable correction + linting)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, core embedding/runtime internals
  - **Dependencies:** None
  - **Estimated Effort (1-5):** 1
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Patch `embedding.ts` to pass `text` (string) into `retrieveCachedEmbedding`.
  2. Add a regression test for non-string inputs + cache path.
  3. Re-run `bun run test:core` and ensure deterministic embedding tests pass.
- **Potential Assignees:** odilitime, lalalune, NubsCarson

---

### 5) “prevent duplicate LLM calls when message contains URL or triggers providers” — PR #6528 (elizaos/eliza) (relates to Issue #6486)
- **Current Status:** Open PR; described as low-risk surgical fix removing an incorrect `providers.length` condition.
- **Impact Assessment:**
  - **User Impact:** **High** for hosted/self-hosted users with URL-heavy chats (double responses, higher cost)
  - **Functional Impact:** Partial (doesn’t fully break, but causes duplicated output + token waste)
  - **Brand Impact:** Medium (perceived “buggy/expensive” behavior)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance (cost)
  - **Component Affected:** Core Framework message service (`packages/typescript/src/services/message.ts`)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime/message pipeline
  - **Dependencies:** None
  - **Estimated Effort (1-5):** 1
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Confirm no edge cases where providers should force action path (add test: REPLY+providers must be single-call).
  2. Merge PR and cut an alpha patch quickly (cost bugs should ship fast).
  3. Add telemetry/debug log to detect double-invocation regressions.
- **Potential Assignees:** lalalune, odilitime, NubsCarson

---

### 6) “Port elisym monetization plugin to v3 after registry merge” — (Discord action item; registry PR already merged: elizaos-plugins/registry#346)
- **Current Status:** Plugin exists and is in registry; v3 porting identified as “next quest”.
- **Impact Assessment:**
  - **User Impact:** Medium (builders wanting paid agent-to-agent services)
  - **Functional Impact:** Partial (not core, but strategic ecosystem capability)
  - **Brand Impact:** Medium (positions elizaOS as commerce-ready)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Plugin System, Model Integration, External integrations (Nostr + Solana)
  - **Complexity:** Moderate effort (API changes across major version, testing on devnet)
- **Resource Requirements:**
  - **Required Expertise:** Plugin API, Solana, Nostr, agent-to-agent protocol design
  - **Dependencies:** v3 plugin API stability; v2→v3 migration guidance
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a tracking issue in the plugin repo for v3 port with a compatibility matrix.
  2. Add an end-to-end integration test: capability publish → paid request → settlement → response delivery.
  3. Document minimal security guidance for paid calls (rate limits, replay protection, receipt verification).
- **Potential Assignees:** igor.peregudov (plugin author), odilitime (plugin infra), stan0473 (versioning guidance)

---

### 7) “Enable plugins to accept $ELIZAOS and $DegenAI as x402 payments” — (Discord technical action item; 1.x branch work resumed)
- **Current Status:** Planned/resumed; not landed in provided logs.
- **Impact Assessment:**
  - **User Impact:** Medium (builders who want token-native monetization)
  - **Functional Impact:** No (optional commerce layer)
  - **Brand Impact:** Medium (token utility narrative; risk if half-implemented)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Plugin System / Payments (x402)
  - **Complexity:** Moderate effort (payment rails, UX, receipts, error handling)
- **Resource Requirements:**
  - **Required Expertise:** Payments integration, x402 spec familiarity, wallet handling
  - **Dependencies:** Token/payment infra decisions; avoid coupling protocol governance into core runtime prematurely
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Produce a minimal design doc: supported chains, settlement tokens, exchange-rate handling, failure modes.
  2. Implement behind feature flags in a payment plugin rather than core, unless strictly necessary.
  3. Add a reference paid API demo (similar to DeepBlue/LemonCake patterns) to validate end-to-end flow.
- **Potential Assignees:** odilitime, lemoncake03027 (payments domain), igor.peregudov (agent commerce)

---

### 8) “Discord messages auto-deleting without audit log entries” — (Discord ops incident; 2026-04-22)
- **Current Status:** Unresolved; manual reposting used as workaround.
- **Impact Assessment:**
  - **User Impact:** Medium (affects multiple users; disrupts support + coordination)
  - **Functional Impact:** Partial (blocks community workflows, not core runtime)
  - **Brand Impact:** Medium (feels chaotic/unreliable)
- **Technical Classification:**
  - **Issue Category:** UX / Community Ops
  - **Component Affected:** Discord server moderation tooling/bots
  - **Complexity:** Moderate effort (requires audit of bots, automod rules, webhooks, Discord settings)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin, bot configuration, moderation logs
  - **Dependencies:** Inventory of installed bots and their permissions
  - **Estimated Effort (1-5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Temporarily disable/relax automod rules and any third-party moderation bots to isolate cause.
  2. Enable enhanced logging: webhook/bot event logs, message delete event capture to a private mod channel.
  3. Post a short incident note + workaround for users (copy before posting, retry guidance).
- **Potential Assignees:** odilitime (server admin), cidsociety / stan0473 (core community operators)

---

### 9) “Late AI16Z → ELIZAOS token migration requests (window closed; waitlist)” — (Discord support issue)
- **Current Status:** Migration window closed; ad-hoc waitlist mentioned.
- **Impact Assessment:**
  - **User Impact:** Medium (subset of holders; high personal impact)
  - **Functional Impact:** No (not framework functionality)
  - **Brand Impact:** **High** (token-holder trust + reputational risk)
- **Technical Classification:**
  - **Issue Category:** UX / Documentation (process), potentially Governance/Ops
  - **Component Affected:** Migration tooling/process (off-chain ops)
  - **Complexity:** Moderate effort (policy + tooling + comms)
- **Resource Requirements:**
  - **Required Expertise:** Ops, legal/compliance awareness, on-chain migration mechanics
  - **Dependencies:** Legal constraints and custody/migration policy decisions
  - **Estimated Effort (1-5):** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a definitive public policy: whether late migrations are possible, and under what criteria.
  2. If possible: create a lightweight intake form + tracking ticket per request (avoid DMs-only support).
  3. Add documentation banner in relevant repos/sites to prevent repeat misses.
- **Potential Assignees:** odilitime (ops), foundation/steering group members (quanteliza, valleybeyond7991 for comms support)

---

### 10) “Integrate LemonCake M2M payments plugin (spend-capped, revocable pay tokens)” — (Discord; eliza-plugin-lemoncake)
- **Current Status:** Plugin announced + approved; integration is “one line” in v2, but docs/integration guide needed.
- **Impact Assessment:**
  - **User Impact:** Medium (builders needing paywalled API access)
  - **Functional Impact:** Partial (unblocks common “agent hits paywall” use cases)
  - **Brand Impact:** Medium (signals production readiness)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Documentation
  - **Component Affected:** Plugin System, Payments
  - **Complexity:** Moderate effort (docs, examples, receipts, sandbox testing)
- **Resource Requirements:**
  - **Required Expertise:** Plugin authoring, docs, security review (spend limits/kill switch semantics)
  - **Dependencies:** Clear plugin registry entry + example agent template
  - **Estimated Effort (1-5):** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add an official docs page: setup, sandbox mode, receipts, spend caps, revocation.
  2. Ship an example agent that calls a paid API end-to-end and demonstrates idempotency keys.
  3. Do a quick security review: token scoping, replay resistance, logging of sensitive payment artifacts.
- **Potential Assignees:** lemoncake03027 (owner), odilitime (approval + integration), dutchiono (docs/testing)

---

## Highest-Priority Summary (Top 5–10 to address now)
1. **P0:** PR #6613 (“virus” autonomous shell + persistence) — block/close/quarantine; add repo security gate.
2. **P0:** Issue #7007 (data sanitization / PII protection) — define and implement a minimal sanitization layer.
3. **P1:** PR #6528 (duplicate LLM calls on URLs/providers; cost + UX regression) — merge + ship patch.
4. **P1:** PR #6543 (IGNORE handling) — fix the embedding type mismatch and merge safely.
5. **P1:** v2 stable release planning (currently alpha) — publish checklist + timeline.
6. **P2:** Discord auto-deletion incident — isolate/disable culprit bot/automod and restore trust in comms.
7. **P2:** Late token migration support policy + intake — reduce reputational risk via clarity and tracking.
8. **P2:** Elisym v3 port tracking + tests — ensure commerce plugins don’t fragment across versions.
9. **P2:** LemonCake plugin docs + example — make “agent pays API” a first-class, safe path.
10. **P3:** x402 acceptance for $ELIZAOS/$DegenAI — proceed only with clear spec + plugin-first implementation.

---

## Patterns / Themes Indicating Deeper Architectural Issues
- **Security boundaries are inconsistent across packages/plugins:** The repo is accumulating powerful capabilities (shell execution, payments, wallet actions) without a uniform “capability sandbox / policy enforcement” layer.
- **High churn in core message/runtime pipeline:** Multiple fixes target action selection, reflection/providers prompt bloat, duplicate calls, and output formatting—suggesting the pipeline needs clearer invariants and stronger regression tests.
- **Version fragmentation (v2 alpha vs v3 planning) impacts ecosystem velocity:** Plugin authors need stable targets; otherwise commerce/payment plugins bifurcate.

---

## Process Recommendations (to prevent repeats)
1. **Introduce a “Dangerous Capabilities” security gate** (PR label + required approvals) for: shell execution, persistence/autostart, wallet signing/spending, payment settlement, and remote control.
2. **Add end-to-end regression tests for the message pipeline** (single-call guarantees, action/provider interplay, reflection prompt size caps, cost regression checks).
3. **Create a formal release checklist + cadence** (even if lightweight) so plugin authors can plan ports and compatibility.
4. **Operational incident playbooks** for Discord (bot inventory, audit logging, rollback steps) and security warnings (phishing/scam message handling + pinned advisories).