## Issue Triage — 2026-04-20

### 1) Private security vulnerabilities reported via Discord DM (kullai → odilitime) — **SEC-PRIV-2026-04-18**
- **Current Status:** Reported privately; receipt acknowledged by **odilitime**; not yet tracked publicly (no advisory/ticket referenced).
- **Impact Assessment:**
  - **User Impact:** **Critical** (unknown scope until reproduced; potential broad exposure in OSS)
  - **Functional Impact:** **Yes** (security issues can block safe usage/deployment)
  - **Brand Impact:** **High** (public disclosure without coordinated fix would severely harm trust)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Core Framework** (exact components not provided)
  - **Complexity:** **Moderate effort** (likely multiple fixes + regression tests once details confirmed)
- **Resource Requirements:**
  - **Required Expertise:** AppSec, secure coding, exploit reproduction, CI/regression test authoring
  - **Dependencies:** Need full repro details from reporter; may depend on release timing (avoid shipping known vuln)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a **private GitHub Security Advisory (GHSA draft)** and log the report details + timeline.
  2. Reproduce vulnerabilities in a dedicated branch; define affected versions and attack preconditions.
  3. Implement fixes + add regression tests; run full CI matrix (TS/Python/Rust if applicable).
  4. Coordinate a **coordinated disclosure**: patch release notes + credit policy; decide CVE request if warranted.
- **Potential Assignees:** **odilitime** (primary), **stan0473** (core dev), **lalalune** (infrastructure/runtime), plus a security-minded reviewer (**ai16z-demirix** if available for validation based on prior security work).

---

### 2) Phishing/scam activity in Discord (impersonation + fake airdrop links) — **COMM-SEC-2026-04-19**
- **Current Status:** Malicious accounts removed/banned by moderators (**satsbased**, **odilitime**); recurring attempts noted.
- **Impact Assessment:**
  - **User Impact:** **High** (community-wide exposure; newcomers most vulnerable)
  - **Functional Impact:** **Partial** (doesn’t break framework, but breaks community safety/support workflows)
  - **Brand Impact:** **High** (scams in official community channels damage legitimacy)
- **Technical Classification:**
  - **Issue Category:** **Security / UX (community safety)**
  - **Component Affected:** **Discord / Community Ops**
  - **Complexity:** **Moderate effort** (policy + automation + education)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation, server security configuration, anti-phishing bots/automations
  - **Dependencies:** Clarify official comms channels; align with disclosure guidelines
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Enable/raise **Discord verification + anti-impersonation controls** (role-gated posting in sensitive channels, link restrictions where feasible).
  2. Add **automated link scanning/flagging** and keyword triggers (“airdrop”, “claim”, “tag”) with auto-timeout.
  3. Pin a single canonical message: “**No airdrops announced in Discord**” + official announcement sources.
  4. Create a lightweight **incident runbook** (what to do, who to ping, evidence capture).
- **Potential Assignees:** **satsbased** (mod), **odilitime** (Community Ops), **doriand0963** (partner/mod support).

---

### 3) “feat(virus): add autonomous rust agent (concept art)” — **PR elizaos/eliza#6613**
- **Current Status:** **Open PR**; includes behaviors flagged as malware-like (persistence, idle stealth, unrestricted shell execution).
- **Impact Assessment:**
  - **User Impact:** **Critical** (if merged, creates high-risk distribution surface)
  - **Functional Impact:** **Partial** (doesn’t block core runtime, but introduces severe safety liability)
  - **Brand Impact:** **High** (association with RAT-like tooling under elizaOS org)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Examples / Rust package distribution within monorepo**
  - **Complexity:** **Simple fix** (close PR / remove package / move to external fork)
- **Resource Requirements:**
  - **Required Expertise:** Security review, OSS governance/maintainer decision-making
  - **Dependencies:** Repo policy on dangerous examples; contribution guidelines
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Close PR** with clear rationale; request author to host in an external repo if they insist on the concept.
  2. Add/clarify a **policy**: no persistence/stealth + no LLM-driven arbitrary shell exec in official examples.
  3. Add a “**Security-sensitive contributions**” checklist to PR template (flags persistence, shell exec, credential handling).
- **Potential Assignees:** **odilitime**, **stan0473** (core maintainers), with optional review/endorsement from **ai16z-demirix**.

---

### 4) V2.0.0 release mega-PR (CI/release automation overhaul) — **PR elizaos/eliza#6530**
- **Current Status:** **Open PR**, very large; medium risk flagged; affects multi-language release workflows and publishing.
- **Impact Assessment:**
  - **User Impact:** **High** (release reliability impacts all users consuming packages)
  - **Functional Impact:** **Yes** (can block publishing / break installation paths)
  - **Brand Impact:** **Medium–High** (failed releases and broken installs erode trust)
- **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/PyPI/crates.io publishing, monorepo tooling, supply-chain scanning
  - **Dependencies:** Must align with current develop state; may depend on recently merged release-unblocking fixes
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Break review into **mergeable slices** (CI changes vs release workflows vs docs automation).
  2. Run **dry-run publishes** in a staging namespace; verify workspace version rewriting doesn’t corrupt lockfiles.
  3. Add rollback plan: revert commits or feature-flag workflows to reduce blast radius.
- **Potential Assignees:** **odilitime** (author/owner), **lalalune** (build/release stability), **dutchiono** (cross-platform/config consistency).

---

### 5) Runtime robustness: “handle IGNORE action fallback and tolerate upstream IGNORE” — **PR elizaos/eliza#6543**
- **Current Status:** **Open PR**; includes a known type mismatch flagged in review (`embedding.ts` wrong variable passed).
- **Impact Assessment:**
  - **User Impact:** **High** (agents can error/hang on common LLM output patterns)
  - **Functional Impact:** **Yes** (runtime stability)
  - **Brand Impact:** **Medium** (crashy runtime feels low quality)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Core Framework (runtime + embeddings)**
  - **Complexity:** **Moderate effort** (needs careful review due to breadth, including Python refactor)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime internals, embeddings pipeline, test authoring
  - **Dependencies:** Must fix type mismatch before merge; ensure Python changes don’t regress
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Fix `embedding.ts` bug (pass `text` not `input`) and add a regression test for non-string inputs.
  2. Replace `console.error` with project logger for consistent diagnostics.
  3. Scope Python refactor risk: require targeted tests or split Python changes into a follow-up PR.
- **Potential Assignees:** **paulf280-ui** (author), **lalalune** (runtime stability), **NubsCarson** (model/runtime integration), **odilitime** for final merge.

---

### 6) Memory consistency bug: InMemoryDatabaseAdapter roomId change handling — **PR elizaos/eliza#6965**
- **Current Status:** **Open PR** (reported in dev logs as improved handling for accurate memory updates when `roomId` changes).
- **Impact Assessment:**
  - **User Impact:** **High** (memory corruption/misattribution affects many agent deployments)
  - **Functional Impact:** **Partial–Yes** (core behavior: memory correctness)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Core Framework (Memory/DB adapter)**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Data modeling, adapter semantics, concurrency/race analysis, tests
  - **Dependencies:** Needs reproducible scenario(s): room migration, multi-room chat bridges, orchestrator routing
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a regression test: memory write + roomId transition + readback correctness.
  2. Audit for similar patterns in other adapters (SQL, plugin-backed stores).
  3. Validate with Discord routing/orchestrator flows where room identifiers may shift.
- **Potential Assignees:** **avasis-ai** (author), **lalalune**, **odilitime** (review).

---

### 7) Orchestration reliability changes: subagent “end_turn” reading + remove task-heartbeat — **PR elizaos/eliza#6964**
- **Current Status:** **Open PR**; dev logs indicate synthesis refined and heartbeat module removed.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (multi-agent/task flows; reduces “dishonest” synthesis and noisy loops)
  - **Functional Impact:** **Partial** (affects orchestrator/task management quality)
  - **Brand Impact:** **Medium** (agent behavior credibility)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **Agent Orchestration / Task system**
  - **Complexity:** **Complex solution** (behavioral correctness + timing)
- **Resource Requirements:**
  - **Required Expertise:** Orchestrator internals, conversation protocol semantics (`end_turn`), evaluation harness
  - **Dependencies:** Coordinate with routing/submodule dependency updates (see #6968) and any UI task panels
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (promote to P1 if it’s currently causing production regressions)
- **Specific Actionable Next Steps:**
  1. Define acceptance tests: multi-turn subagent tasks terminate correctly without heartbeat.
  2. Add telemetry/logs for synthesis termination conditions to prevent silent stalls.
  3. Validate against Discord + cron orchestrations where timing previously relied on heartbeat.
- **Potential Assignees:** **RemilioNubilio** (author), **NubsCarson** (orchestration/runtime), **odilitime** (review).

---

### 8) Plugin-agent-orchestrator / plugin-cron routing & submodule dependency updates (stability risk) — **PR elizaos/eliza#6968**
- **Current Status:** **Open PR**; dev logs mention Discord routing and submodule dependency updates.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (breaks orchestration scheduling and Discord-based agent routing)
  - **Functional Impact:** **Partial–Yes** (can block common deployments using cron/orchestrator)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** **Bug / Infrastructure**
  - **Component Affected:** **Plugin System (orchestrator/cron) + Discord integration path**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Plugin packaging, dependency graph, Discord routing, monorepo submodules
  - **Dependencies:** Must align with changes in task synthesis + roomId/memory correctness
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Validate dependency graph under bun/node; ensure ESM/CJS boundaries remain correct.
  2. Add a minimal integration test: cron triggers orchestrator action → Discord route → memory write.
  3. Document any breaking changes for plugin maintainers.
- **Potential Assignees:** **NubsCarson** (author), **dutchiono** (config/build), **lalalune** (stability), **odilitime** (merge).

---

### 9) Missing formal vulnerability disclosure guidelines + no bug bounty clarity — **DOC-SEC-2026-04**
- **Current Status:** Identified in Discord discussions; community unsure whether to open public issues/PRs for security bugs.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects how quickly and safely vulns get reported)
  - **Functional Impact:** **No** (process/documentation)
  - **Brand Impact:** **High** (public mishandling of security reports is reputationally damaging)
- **Technical Classification:**
  - **Issue Category:** **Documentation / Security**
  - **Component Affected:** **Repo governance/docs**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Security process, documentation, GitHub Security Advisories
  - **Dependencies:** Align with how maintainers want inbound reports handled (email vs GHSA vs Discord DM)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add `SECURITY.md` with: private channels, expected response times, disclosure policy, supported versions.
  2. Update issue templates: “Do not file security bugs publicly” banner + link to `SECURITY.md`.
  3. Decide and document stance on bug bounties (explicit “none” is fine).
- **Potential Assignees:** **odilitime**, **stan0473**, **lalalune** (docs/maintainer support), plus contributor help from **vincent067** (has an open CONTRIBUTING PR).

---

### 10) Token staking requests (community asks; currently not available) — **FEAT-TOKEN-STAKE-2026-04**
- **Current Status:** Multiple moderators confirmed **staking not available**; no technical work item defined.
- **Impact Assessment:**
  - **User Impact:** **Medium** (recurring question, but not core framework)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low–Medium** (confusion/expectation management)
- **Technical Classification:**
  - **Issue Category:** **Feature Request / Documentation**
  - **Component Affected:** **Project Comms (not elizaOS core)**
  - **Complexity:** **Architectural change** (if implemented; involves tokenomics/contracts)
- **Resource Requirements:**
  - **Required Expertise:** Token contract engineering, product/legal/compliance, ops
  - **Dependencies:** Strategic decision; should not distract from core framework priorities
  - **Estimated Effort:** **5/5** (if pursued; otherwise 1/5 to document)
- **Recommended Priority:** **P4**
- **Specific Actionable Next Steps:**
  1. Add an FAQ entry in official docs/website: staking availability = “not supported”.
  2. Avoid opening engineering tickets unless there’s a confirmed roadmap owner and spec.
- **Potential Assignees:** **odilitime** (comms), **doriand0963** (community responses).

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0:** **SEC-PRIV-2026-04-18** — privately reported security vulnerabilities (triage + GHSA + fixes).
2. **P0:** **elizaos/eliza#6613** — close/deny “virus” PR to remove severe security/brand risk.
3. **P1:** **COMM-SEC-2026-04-19** — recurring Discord phishing/impersonation mitigations.
4. **P1:** **elizaos/eliza#6543** — runtime IGNORE fallback + embedding type bug fix; stabilize agent runtime.
5. **P1:** **elizaos/eliza#6530** — v2.0.0 release PR: de-risk and move forward in reviewable slices.
6. **P1:** **elizaos/eliza#6965** — roomId/memory update correctness to prevent memory corruption.
7. **P2:** **elizaos/eliza#6964** — subagent end_turn + remove heartbeat (validate termination correctness).
8. **P2:** **elizaos/eliza#6968** — routing/submodule dependency changes (integration tests + docs).
9. **P2:** **DOC-SEC-2026-04** — SECURITY.md + secure reporting guidance to prevent public disclosure mistakes.
10. **P4:** **FEAT-TOKEN-STAKE-2026-04** — track only as FAQ unless roadmap changes.

---

## Patterns / Themes Suggesting Deeper Architectural Issues
- **Security surface area is expanding faster than governance/process**: agent autonomy, shell execution concepts, and multi-plugin commerce proposals increase risk without consistent guardrails (policies, SECURITY.md, threat modeling).
- **Orchestration + memory correctness are tightly coupled**: changes to routing, `roomId`, and task termination (`end_turn`, heartbeat removal) indicate fragile cross-component contracts.
- **Release/CI complexity is high and centralized**: the v2 release overhaul and frequent workflow churn suggest the project needs stronger “small PR” discipline and staged rollout practices.

---

## Process Improvement Recommendations
1. **Establish a formal security intake path**: publish `SECURITY.md`, mandate GHSA drafts for any privately reported vuln, and add a “security-sensitive change” PR checklist.
2. **Introduce a minimal threat-model review for risky capabilities** (shell execution, persistence, wallet operations, agent-to-agent commerce): require explicit maintainer approval + sandboxing guidelines.
3. **Add cross-component integration tests** for the core failure modes seen repeatedly:
   - orchestrator/cron → Discord routing → memory writes/readback
   - roomId transitions and multi-room/message-bridge scenarios
   - task termination semantics (`end_turn`) without heartbeat
4. **De-risk mega-PRs**: require slicing into smaller PRs with clear rollback plans; enforce CI “gates” before merging release-engineering changes.
5. **Community safety operations**: maintain an incident runbook and automate scam detection; keep a single pinned “official announcements only” reference to reduce social engineering success.