## Issue Triage — 2026-04-26

### 1) **feat(virus): add autonomous rust agent (concept art)** — PR **#6613** (elizaos/eliza)
- **Current Status:** Open PR (unmerged); security review flags it as malware-like behavior (persistence + idle stealth + LLM-controlled shell)
- **Impact Assessment**
  - **User Impact:** High (if merged/distributed, could lead to real user harm)
  - **Functional Impact:** Partial (not blocking existing core paths, but introduces a high-risk execution surface)
  - **Brand Impact:** High (severe reputational risk; “RAT-like” package inside official monorepo)
- **Technical Classification**
  - **Issue Category:** **Security**
  - **Component Affected:** Core repo packaging/release surface; Rust examples/packages
  - **Complexity:** Architectural change (cannot be made safe with simple deny-lists)
- **Resource Requirements**
  - **Required Expertise:** Security engineering, maintainers familiar with release/distribution policies, Rust review
  - **Dependencies:** None; decision can be made immediately
  - **Estimated Effort:** 2/5 (to close/lock PR + document policy); 4/5 (if attempting a “safe sandboxed agent runner” redesign)
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps**
  1. Close PR **#6613** and add a maintainer note explaining rejection rationale (persistence/stealth/unrestricted shell).
  2. Add/clarify a repo policy: no autonomous agents with persistence/stealth behaviors; no LLM→shell without robust sandboxing.
  3. Add CI/review guardrails: flag packages/actions that execute shell commands + persistence hooks.
- **Potential Assignees:** **odilitime** (core), **lalalune** (core stability), **ai16z-demirix** (security), plus a Rust-focused maintainer.

---

### 2) **Implement a data-sanitization layer to protect user privacy before information reaches AI models** — Issue **#7007** (elizaos/eliza)
- **Current Status:** Open issue (initiative)
- **Impact Assessment**
  - **User Impact:** High (PII leakage risk scales with every agent deployment)
  - **Functional Impact:** Partial (not blocking execution, but affects safe usage in production)
  - **Brand Impact:** High (privacy failures damage trust, especially as agent commerce expands)
- **Technical Classification**
  - **Issue Category:** **Security**
  - **Component Affected:** Core Framework (prompt construction, providers, logging, message service)
  - **Complexity:** Complex solution (cross-cutting concerns; needs consistent enforcement)
- **Resource Requirements**
  - **Required Expertise:** Privacy/security, prompt pipeline, logging/redaction, evaluation harness design
  - **Dependencies:** Needs alignment with message service/reflection pipeline changes to avoid re-leaks via retries/synthesis
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. Define threat model: what to redact (emails, phone numbers, addresses, API keys, wallet seeds, OAuth tokens, etc.).
  2. Choose enforcement points: (a) pre-model prompt sanitizer, (b) post-model output scrubber, (c) log sink redactor.
  3. Add test fixtures: “known PII in → no PII out” across core message paths (reply, reflection, failure recovery).
  4. Provide plugin API hooks so plugins can register custom sensitive-field detectors.
- **Potential Assignees:** **lalalune** (message pipeline work), **odilitime** (core), **RemilioNubilio** (agent communication flows); consult **ai16z-demirix** for security review.

---

### 3) **Duplicate LLM calls when messages contain URLs or trigger providers (token-cost + duplicated output)** — PR **#6528** (elizaos/eliza) *(relates to #6486)*
- **Current Status:** Open PR (unmerged)
- **Impact Assessment**
  - **User Impact:** High (common case: URLs; doubles cost and can duplicate responses)
  - **Functional Impact:** Partial (responses still produced, but correctness/cost degraded)
  - **Brand Impact:** Medium (users perceive “buggy/expensive” behavior)
- **Technical Classification**
  - **Issue Category:** Bug / Performance
  - **Component Affected:** Core Framework (message service)
  - **Complexity:** Simple fix (surgical boolean condition change)
- **Resource Requirements**
  - **Required Expertise:** TypeScript runtime/message pipeline
  - **Dependencies:** None
  - **Estimated Effort:** 1/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. Reproduce with a URL message that triggers ATTACHMENTS provider.
  2. Validate no regression for multi-action (REPLY + tool) cases.
  3. Merge PR **#6528** and add a regression test that asserts exactly one model invocation.
- **Potential Assignees:** **odilitime**, **NubsCarson**, **nicolasdma** (author).

---

### 4) **fix(runtime): handle IGNORE action fallback and tolerate upstream IGNORE** — PR **#6543** (elizaos/eliza)
- **Current Status:** Open PR (unmerged); reviewer tooling flagged a type mismatch in embeddings code path
- **Impact Assessment**
  - **User Impact:** Medium–High (agents can error/hang when models emit IGNORE; varies by model/provider)
  - **Functional Impact:** Yes (can break a turn; may hang or throw “Action not found”)
  - **Brand Impact:** Medium (agent appears unreliable)
- **Technical Classification**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (runtime action dispatch; embeddings utility)
  - **Complexity:** Moderate effort (fix type issue + validate runtime behavior)
- **Resource Requirements**
  - **Required Expertise:** TypeScript core runtime, typing discipline, test stabilization
  - **Dependencies:** Should be coordinated with any recent message-service retry/reflection changes
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. Fix the flagged type mismatch (ensure cached-embedding call uses a string-normalized variable).
  2. Add/confirm a runtime test where planner returns `IGNORE` and system continues without error.
  3. Ensure consistent logging via elizaLogger (avoid console.error) to reduce noise in production.
- **Potential Assignees:** **paulf280-ui** (author), **lalalune**, **odilitime**.

---

### 5) **x402 paid plugin routes (monetization plumbing) + test harness hardening** — (No issue ID filed; reported as in-progress work)
- **Current Status:** In progress (per development log); no canonical tracking issue
- **Impact Assessment**
  - **User Impact:** Medium (builders wanting paid routes; increasingly important given marketplace/agent commerce direction)
  - **Functional Impact:** Partial (not blocking core chat, but blocks a strategic monetization workflow)
  - **Brand Impact:** Medium (ecosystem competitiveness; “paid services” demos depend on it)
- **Technical Classification**
  - **Issue Category:** Feature Request / Infrastructure
  - **Component Affected:** Plugin System + API routing + Payments (x402)
  - **Complexity:** Complex solution (authZ, metering, replay protection, error semantics, devnet/mainnet config)
- **Resource Requirements**
  - **Required Expertise:** Payments/x402, API design, security (signature verification), plugin architecture
  - **Dependencies:** Needs alignment with token utility work (ELIZAOS/$DegenAI as payment methods) and plugin marketplace efforts
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps**
  1. File a GitHub issue to track: scope, acceptance criteria, security model, reference implementation plugin.
  2. Define route contract: pricing discovery (`/.well-known/x402`), payment verification, idempotency, retries.
  3. Add integration tests: “unpaid → 402; paid → 200; replayed receipt → rejected.”
- **Potential Assignees:** **odilitime** (noted as working on payment methods), **NubsCarson** (model/plugin stability), invite **igor-peregudov** (marketplace plugin context).

---

### 6) **Discord moderation incident: suspicious SOL giveaway solicitation** — Discord user **ramson813** (no GitHub ID)
- **Current Status:** Observed in #coders; appears scam-like (“offering $400 in Solana to anyone in need”)
- **Impact Assessment**
  - **User Impact:** Medium (risk of community members being phished/scammed)
  - **Functional Impact:** No
  - **Brand Impact:** High (public safety perception of the community)
- **Technical Classification**
  - **Issue Category:** Security / Community Ops
  - **Component Affected:** Discord moderation and trust/safety process
  - **Complexity:** Simple fix (moderation actions + automations)
- **Resource Requirements**
  - **Required Expertise:** Moderation, community ops, Discord automation/bots
  - **Dependencies:** None
  - **Estimated Effort:** 1/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps**
  1. Remove message, warn/ban account if confirmed scam pattern; document in mod log.
  2. Add an auto-mod rule for common giveaway-scam phrasing + external wallet links.
  3. Post a short PSA: “No unsolicited giveaways; report DMs; never share seed phrases.”
- **Potential Assignees:** **odilitime** (Moderator/Community Ops), **neuro023** (Moderator).

---

### 7) **HTN (Hierarchical Task Networks) implementation ambiguity in v2 + missing documentation** — (No issue ID filed; raised on Discord)
- **Current Status:** Unclear/Unverified; community uncertain whether v2 “already added HTN” and what “HTN-lite” means
- **Impact Assessment**
  - **User Impact:** Medium (builders can’t reliably use/extend planning features without correct docs)
  - **Functional Impact:** Partial (planning works, but misinformed usage leads to brittle agents)
  - **Brand Impact:** Medium (perceived lack of clarity/consistency in core architecture)
- **Technical Classification**
  - **Issue Category:** Documentation (with architectural implications)
  - **Component Affected:** Core Framework (planning/orchestration)
  - **Complexity:** Moderate effort (needs code audit + docs + examples)
- **Resource Requirements**
  - **Required Expertise:** Core planning/runtime knowledge, technical writing
  - **Dependencies:** Should align with any roadmap for v2 beta planning upgrades (LLM planning vs hand-coded decomposition)
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps**
  1. Create a GitHub docs issue: “Planning architecture: HTN/HTN-lite status + extension points.”
  2. Audit codebase: identify actual HTN components (or absence) and current goal decomposition mechanism.
  3. Publish a short design note: terminology, current behavior, and a staged upgrade path (HTN-lite → full HTN).
- **Potential Assignees:** **odilitime**, **thirti.eth** (context gather), **RemilioNubilio** (agent orchestration UX).

---

## Highest-Priority Focus (Top 5–10 to address immediately)

1. **P0:** PR **#6613** — “virus” autonomous agent package (close + policy + guardrails)
2. **P1:** Issue **#7007** — Data-sanitization layer (privacy/security foundation)
3. **P1:** PR **#6528** — Duplicate LLM calls on URL/provider triggers (cost + duplicated output)
4. **P1:** PR **#6543** — IGNORE action handling (runtime stability; fix type mismatch)
5. **P1:** Discord scam solicitation (ramson813) — moderation + automod rules + PSA
6. **P2:** x402 paid plugin routes + tests (file tracking issue; define security model)
7. **P2:** HTN planning documentation/verification (reduce architectural confusion)

---

## Patterns / Themes Suggesting Deeper Issues

- **Safety boundaries are inconsistent across the stack:** the “virus” PR highlights how easily dangerous capabilities (persistence + shell) could enter the repo without an explicit policy and automated checks.
- **Message/planning pipeline complexity is producing emergent bugs:** duplicate model calls, IGNORE handling, and the need to prevent “internal mechanism” leakage indicate a fragile set of branching paths (providers/actions/retries/reflection/synthesis).
- **Rapid ecosystem expansion (payments/marketplaces) increases security and privacy requirements:** monetization plugins and x402 routes raise the stakes for PII handling, authorization scoping, and fraud prevention.
- **Documentation lag behind architecture changes:** HTN uncertainty suggests core concepts are being discussed without an authoritative, versioned reference.

---

## Process Improvement Recommendations

1. **Adopt a “dangerous capabilities” policy + checklist** (shell execution, persistence, credential access, wallet signing) and require explicit maintainer approval + security review for any PR touching these areas.
2. **Add automated CI detectors** for:
   - persistence hooks (Windows Run keys, launch agents, cron install scripts),
   - unrestricted shell exec surfaces,
   - outbound network calls from “examples” that could become de facto supported.
3. **Create a single “Message Turn Contract” test suite** that asserts:
   - max model invocations per turn (unless explicitly intended),
   - allowed planner actions and fallbacks (IGNORE, malformed XML),
   - no leakage of internal diagnostics into user-facing replies.
4. **Require tracking issues for in-progress strategic work** (e.g., x402 paid routes, HTN upgrades) to prevent “tribal knowledge” and to align docs, tests, and implementation.
5. **Strengthen Discord trust & safety operations** with auto-mod rules, a pinned anti-scam PSA, and a clear reporting path.