## Issue Triage — 2026-04-18 (elizaOS)

### 1) **feat(virus): add autonomous rust agent (concept art)** — PR `elizaos/eliza#6613`
- **Current Status:** Open PR; high-risk security/ethics concerns raised in automated review (RAT-like behavior, persistence, unrestricted shell)
- **Impact Assessment:**
  - **User Impact:** High (if merged/distributed, could harm users who run it; security incident potential)
  - **Functional Impact:** Partial (not required for core framework, but could contaminate distribution/reputation)
  - **Brand Impact:** High (association with malware behaviors)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Core Framework repo / Distribution & Examples (packaging risk)
  - **Complexity:** Simple fix (process/decision) → **close/reject**; if kept, would require **architectural change** to make safe (likely infeasible)
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, OSS governance, release/distribution policy
  - **Dependencies:** None; blocks nothing but introduces major risk if not handled
  - **Estimated Effort:** 1–2 (close + document policy)
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Immediately label `security-risk` + `do-not-merge` and request changes or close PR with clear rationale.
  2. Add/clarify repo policy: disallow code that implements persistence, stealth activation, or LLM-driven arbitrary command execution in official repos.
  3. If concept is valuable, require it to live in an external sandbox repo with explicit warnings and no affiliation in official distributions.
- **Potential Assignees:** `odilitime` (core/release oversight), `stan0473` (core), `lalalune` (maintainers/process)

---

### 2) **fix(core): prevent duplicate LLM calls when message contains URL or triggers providers** — PR `elizaos/eliza#6528`
- **Current Status:** Open PR (relates to issue `#6486`); fix appears surgical and low-risk
- **Impact Assessment:**
  - **User Impact:** High (affects anyone sending URLs; doubles token spend; duplicate responses)
  - **Functional Impact:** Partial (doesn’t fully break runtime, but degrades correctness/cost significantly)
  - **Brand Impact:** Medium–High (visible “buggy” duplicate output + cost complaints)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance (cost)
  - **Component Affected:** Core Framework (message handling pipeline)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** TypeScript core runtime/message service
  - **Dependencies:** None
  - **Estimated Effort:** 1–2
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Run targeted regression tests: URL messages, provider-enriched messages, multi-action messages.
  2. Merge if CI green; backport if there is a stable branch used by v3 beta.
  3. Add a small test to prevent reintroduction (URL → providers set → must remain single-shot).
- **Potential Assignees:** `odilitime`, `lalalune`, `stan0473`

---

### 3) **fix(runtime): handle IGNORE action fallback and tolerate upstream IGNORE** — PR `elizaos/eliza#6543`
- **Current Status:** Open PR; automated review flags a **type mismatch bug** in `embedding.ts` and logging inconsistencies
- **Impact Assessment:**
  - **User Impact:** Medium–High (agents can error/hang when LLM emits `IGNORE`; depends on model/prompt frequency)
  - **Functional Impact:** Partial (runtime robustness issue; can stall conversations)
  - **Brand Impact:** Medium (agent appears unreliable)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (`@elizaos/core` runtime + embeddings)
  - **Complexity:** Moderate effort (fix type mismatch + verify runtime behavior + review large Python changes)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript core, embeddings pipeline; Python runtime reviewers for the large diff
  - **Dependencies:** Should coordinate with any pending core runtime refactors to avoid merge conflicts
  - **Estimated Effort:** 3–4
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Fix `embedding.ts` bug: pass `text` (string) to `retrieveCachedEmbedding` instead of `input` (unknown).
  2. Standardize logging (`elizaLogger` vs `console.error`) to keep observability consistent.
  3. Split PR if possible: (a) IGNORE handling + TS fixes, (b) Python refactor, to reduce review/merge risk.
  4. Add a runtime test: model returns `IGNORE` → no crash, no hang, conversation continues.
- **Potential Assignees:** `odilitime` (core), `lalalune` (runtime/message service), `NubsCarson` (stability-oriented reviewer)

---

### 4) **V2.0.0 release (CI/release automation overhaul)** — PR `elizaos/eliza#6530`
- **Current Status:** Open PR; very large CI/release system changes (multi-language release workflows, SBOM scanning, NPM/PyPI/crates automation)
- **Impact Assessment:**
  - **User Impact:** Medium–High (release failures block users from receiving fixes; broken publishing breaks installs)
  - **Functional Impact:** Yes (blocks shipping reliable releases)
  - **Brand Impact:** High (broken releases damage trust quickly)
- **Technical Classification:**
  - **Issue Category:** Performance/Infrastructure (Release Engineering)
  - **Component Affected:** CI/CD, Packaging, Multi-language toolchains
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** GitHub Actions, NPM publishing, Rust/WASM build, PyPI, supply-chain tooling
  - **Dependencies:** Must align with current stabilized serialized workflows introduced this week (avoid conflicting approaches)
  - **Estimated Effort:** 4–5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Require a staged rollout plan: enable workflows behind branch conditions; test on tags in a dry-run mode.
  2. Validate “workspace:* rewrite” logic does not corrupt lockfiles or published package manifests.
  3. Produce a checklist: publish order, rollback steps, artifact verification (npm/crates/pypi), SBOM output.
  4. Assign two reviewers: one release engineer + one maintainer for policy/structure.
- **Potential Assignees:** `odilitime` (author/owner), `stan0473` (core maintainer), `lalalune` (maintenance/reliability)

---

### 5) **Plugin review backlog (ecosystem growth blocked)**  
- **Items:**
  - **Add Radius Network support** — PR in `plugin-evm` (chain `eip155:723487`) *(ID not provided in data)*
  - **Add @thecolony/elizaos-plugin** — PR in `elizaos-plugins/registry` *(ID not provided in data)*
  - **Add megalaunch-elizaos-plugin** — PR in `elizaos-plugins/registry` *(ID not provided in data)*
- **Current Status:** Open PRs awaiting review (3 total)
- **Impact Assessment:**
  - **User Impact:** Medium (plugin authors + users waiting on registry discovery)
  - **Functional Impact:** Partial (doesn’t block core, but blocks ecosystem velocity)
  - **Brand Impact:** Medium (slow merges signal inactivity/poor maintainer responsiveness)
- **Technical Classification:**
  - **Issue Category:** Feature / Process
  - **Component Affected:** Plugin System (registry + EVM plugin)
  - **Complexity:** Simple fix (review/merge) assuming submissions meet standards
- **Resource Requirements:**
  - **Required Expertise:** Plugin registry standards, chain metadata validation, security review of plugin manifests
  - **Dependencies:** None; but should use a standardized checklist to avoid supply-chain risk
  - **Estimated Effort:** 2–3 total (across all PRs)
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Apply a plugin intake checklist: ownership, license, versioning, minimal README, security notes, verified npm scope where possible.
  2. For Radius Network: verify chain ID mapping, RPC defaults, and test transactions (if applicable).
  3. Merge in batches with a single maintainer “registry review hour” per day to keep queue short.
- **Potential Assignees:** `stan0473` (ecosystem/core), `odilitime` (reviews), plus a rotating community reviewer group (Helpers/Coders)

---

### 6) **Wallet address ↔ GitHub profile linking problems (contributor onboarding / identity mapping)** — Discord-reported (2026-04-15)
- **Current Status:** Unresolved question raised by `mladcepes`; no documented response; no linked GitHub issue
- **Impact Assessment:**
  - **User Impact:** Medium (affects contributors/users needing identity linking; likely repeated questions)
  - **Functional Impact:** Partial (blocks whatever workflow depends on linking—e.g., contributor verification, portals, rewards, access)
  - **Brand Impact:** Medium (confusing onboarding)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Documentation (unclear which until reproduced)
  - **Component Affected:** Account/Identity integration (likely Partner Portal / Contributor systems)
  - **Complexity:** Moderate effort (needs reproduction + logs + documentation)
- **Resource Requirements:**
  - **Required Expertise:** Web/auth integration, GitHub OAuth/linking flows, wallet signature verification
  - **Dependencies:** Need clarity on the current canonical system (Portal? Discord roles? GitHub org membership?)
  - **Estimated Effort:** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue in the appropriate repo (or a central “community-ops” tracker) with reproduction steps and screenshots.
  2. Collect failure modes: signature mismatch, stale nonce, GitHub OAuth scope issues, wrong wallet network, duplicate accounts.
  3. Add a short help doc/FAQ entry once resolved (“How to link wallet + GitHub; common errors”).
- **Potential Assignees:** `odilitime` (community ops + platform), `satsbased` (comms/docs follow-through), `stan0473` (triage routing)

---

### 7) **Scam/airdrop link attacks in community channels (ongoing security operations)** — Discord incidents (2026-04-15 to 2026-04-17)
- **Current Status:** Moderation actions taken (bans/removals); repeated scam warnings continue
- **Impact Assessment:**
  - **User Impact:** High (large community exposure; social engineering risk)
  - **Functional Impact:** No (doesn’t break framework), but impacts community safety
  - **Brand Impact:** High (users associate scams with project if unmanaged)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Community Ops / Discord moderation tooling
  - **Complexity:** Moderate effort (automation + policy + comms)
- **Resource Requirements:**
  - **Required Expertise:** Discord automod, incident response, security communications
  - **Dependencies:** None
  - **Estimated Effort:** 2–3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Pin an “Official links only” message in high-traffic channels; add a permanent `#security-advisories`/`#official-links` reference.
  2. Enable/strengthen AutoMod: block common phishing domains, suspicious Unicode, fresh-account link posting, bulk-mention behavior.
  3. Establish an incident playbook: where to report, how to verify, response SLA, and post-incident summaries.
- **Potential Assignees:** `odilitime` (Moderator/Community Ops), `neuro023` (moderation enforcement), `stan0473` (announcements coordination)

---

### 8) **Communication gap on project direction (Labs dissolution, open contribution model, Solana deployment status)** — Discord feedback (2026-04-16 to 2026-04-17)
- **Current Status:** Clarifications provided ad hoc in chat; community requests regular roadmap/progress updates
- **Impact Assessment:**
  - **User Impact:** High (recurring confusion; increases support load; discourages contributors)
  - **Functional Impact:** No (doesn’t break runtime), but directly affects adoption/contributions
  - **Brand Impact:** High (perception of instability/inactivity)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (developer experience)
  - **Component Affected:** Project communications, docs, release notes
  - **Complexity:** Moderate effort (ongoing process, not a one-off)
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, release management, community ops
  - **Dependencies:** Align messaging with actual v3 beta milestones and repo reality
  - **Estimated Effort:** 2
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a short “State of the Project” post: Labs status, contributor model, where v3 is, what “beta” means, and how to help.
  2. Add a lightweight cadence: weekly changelog + “PRs needing review” callout.
  3. Update README/docs with canonical statements (e.g., “ElizaOS is already deployed on Solana” clarification, if relevant to ecosystem).
- **Potential Assignees:** `satsbased` (docs/comms), `stan0473` (core messaging), `odilitime` (community ops)

---

## Top Highest-Priority Focus (next 24–72 hours)
1. **P0:** `elizaos/eliza#6613` — close/reject “virus” PR; add policy to prevent similar submissions.
2. **P0:** `elizaos/eliza#6528` — merge fix preventing duplicate LLM calls (URL/provider path).
3. **P1:** `elizaos/eliza#6543` — fix type mismatch + split PR if needed; land IGNORE fallback safely.
4. **P1:** `elizaos/eliza#6530` — create staged rollout plan + focused review for release automation overhaul.
5. **P1:** Discord scam mitigation — harden AutoMod + official-links pin + incident playbook.
6. **P2:** Clear plugin PR review backlog (registry + plugin-evm) with an intake checklist.
7. **P2:** File and triage wallet↔GitHub linking bug; publish linking FAQ once resolved.
8. **P2:** Publish “State of the Project” / roadmap heartbeat to reduce repeated confusion.

---

## Patterns / Themes Indicating Deeper Problems
- **Security boundary ambiguity:** Proposals/PRs that blur “agent autonomy” with unsafe execution (arbitrary shell, persistence) suggest missing **explicit security and governance policies** for what can live in official repos.
- **Release + runtime churn concentration:** Multiple large, high-impact PRs are open simultaneously (runtime semantics, embeddings, CI/release). This increases merge conflict risk and can destabilize v3 beta readiness without strict sequencing.
- **Ecosystem throughput bottlenecks:** Registry/plugin PRs waiting on review indicate reviewer bandwidth constraints; delays translate directly into slower adoption.
- **Communication as a reliability dependency:** Confusion around org structure and deployment status is repeatedly surfacing; lack of canonical, updated docs increases support load and dilutes contributor focus.

---

## Process Improvement Recommendations
1. **Adopt a “Security Acceptance Policy” for official repos**
   - Explicitly ban persistence mechanisms, stealth behaviors, and LLM-driven arbitrary command execution in official packages/examples.
   - Add required security review labels/checklist for sensitive PRs.

2. **Establish a PR merge train for core runtime + release engineering**
   - Timebox and sequence: runtime correctness fixes (P0/P1) → CI/release changes → large refactors.
   - Require smaller PRs (split large diffs) to reduce review latency and risk.

3. **Create a lightweight plugin intake SLA + checklist**
   - Scheduled “registry review hour,” plus automated checks (license, README, publish provenance, basic static analysis).

4. **Operationalize community security**
   - Permanent official-links channel, pinned warnings, automod rules, and an incident response template.

5. **Weekly “State of Core” update**
   - One post per week: what merged, what’s blocked, what needs review, and current v3 beta milestones to reduce repeated Discord support cycles.