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

### 1) `elizaos create` fails on macOS with “Bun’s postinstall script was not run” — **#6704**
- **Current Status:** OPEN (no comments)
- **Impact Assessment:**
  - **User Impact:** **High** (blocks new macOS users from creating projects)
  - **Functional Impact:** **Yes** (blocks core CLI “create” workflow)
  - **Brand Impact:** **High** (first-run failure + deletes generated project dir)
- **Technical Classification:**
  - **Category:** Bug / DX
  - **Component:** CLI / bootstrap template dependencies (`@elizaos/cli`, `@elizaos/plugin-bootstrap`)
  - **Complexity:** **Moderate effort** (dependency/packaging change + validation across installers)
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun packaging, monorepo dependency hygiene, CLI release workflow
  - **Dependencies:** Coordinate with template/build scripts; ensure no hidden runtime usage of `bun` npm package
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Remove `bun` **runtime** dependency from `@elizaos/cli` and `@elizaos/plugin-bootstrap`; replace with `@types/bun` in `devDependencies` if needed.
  2. Add CI smoke test: `bun install -g @elizaos/cli` then `elizaos create` on macOS (aarch64) and Linux.
  3. Change CLI behavior to **not delete** the generated directory on failure; keep artifacts for debugging.
  4. Cut patch release and announce workaround removal.
- **Potential Assignees:** `odilitime` (core/CLI), `dirtybits` (reporter; can validate on macOS), plus a packaging-focused contributor.

---

### 2) Follow-up: Memory persistence bug in IGNORE path when `ALLOW_MEMORY_SOURCE_IDS` is set (from merged PR **#6562**)
- **Issue Title & ID:** “IGNORE responses silently dropped from memory when `ALLOW_MEMORY_SOURCE_IDS` configured” — **(needs issue)**
- **Current Status:** **Untracked regression risk** (found in automated review notes; PR #6562 merged 2026-04-08)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (teams using allowlists will see inconsistent memory behavior)
  - **Functional Impact:** **Partial** (memory/behavior correctness; impacts moderation + conversation state)
  - **Brand Impact:** **Medium** (hard-to-debug “memory doesn’t work” reports)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Core Framework (TypeScript `DefaultMessageService` / memory pipeline)
  - **Complexity:** **Simple fix** (logic parity with non-IGNORE path + tests)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime/message pipeline
  - **Dependencies:** None, but should be patched before further memory-related changes stack
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create tracking issue referencing PR #6562 review findings.
  2. Fix IGNORE path to not require `allowedSources.includes("agent_response")` (or use correct sourceId).
  3. Add unit test: with `ALLOW_MEMORY_SOURCE_IDS` set, ensure IGNORE memory behavior matches intended design.
  4. Patch release notes: memory allowlist semantics clarified.
- **Potential Assignees:** `odilitime` (merged PR owner), `NubsCarson` (message-service familiarity).

---

### 3) Follow-up: Zero-vector fallback corrupts semantic memory on embedding failure (from merged PR **#6562**)
- **Issue Title & ID:** “Persisting zero-vector on embedding failure makes memories unretrievable” — **(needs issue)**
- **Current Status:** **Untracked regression risk** (not confirmed fixed post-merge)
- **Impact Assessment:**
  - **User Impact:** **Medium** (any deployment with intermittent embedding errors)
  - **Functional Impact:** **Partial** (memory retrieval degraded; silent data quality loss)
  - **Brand Impact:** **High** (agents appear forgetful/inconsistent)
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component:** Core Framework (runtime memory + embeddings)
  - **Complexity:** **Moderate effort** (decide policy: skip persist vs retry vs mark “unembedded”)
- **Resource Requirements:**
  - **Required Expertise:** Memory system, embeddings pipeline, DB schema (if adding status flags)
  - **Dependencies:** Might depend on how vector storage/retrieval is implemented across adapters
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create issue and reproduce by forcing embedding provider failure; verify stored vectors.
  2. Change behavior: do **not** write a semantic vector record on failure; queue retry, or store separately as “pending embedding”.
  3. Add metrics/logging: embedding failure rate + count of “pending embeddings”.
  4. Add test: failed embedding must not create a vector that breaks recall semantics.
- **Potential Assignees:** `odilitime`, plus a contributor familiar with DB adapters (`plugin-sql`) and vector search.

---

### 4) Group addressee routing PR has a P1 logic bug (`aliasEntity` ambiguity) — PR **#6712**
- **Issue Title & ID:** “`aliasEntity` breaks addressee resolution when `agentId !== entityId`” — **PR #6712**
- **Current Status:** OPEN PR (review flags a P1 bug; not yet merged)
- **Impact Assessment:**
  - **User Impact:** **High** (group chats/threads; multi-agent rooms are common)
  - **Functional Impact:** **Yes** (core “should respond” routing can fail silently)
  - **Brand Impact:** **High** (agents talk out of turn or fail to respond when addressed)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Core Framework (group routing / name registry / shouldRespond)
  - **Complexity:** **Moderate effort** (logic fix + broadened test coverage)
- **Resource Requirements:**
  - **Required Expertise:** Core message routing, entity model (agentId/entityId), test writing
  - **Dependencies:** Must land before v3 release announcement to avoid shipping broken group routing
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Fix `aliasEntity()` so token-to-entity mapping remains uniquely resolvable (avoid multi-entity sets caused by aliasing).
  2. Add tests specifically covering:
     - `agentId !== entityId` case
     - multiple agents with overlapping aliases
     - addressed-to-self vs addressed-to-other detection
  3. Run connector-level sanity test in Discord threads (reply-to behavior).
- **Potential Assignees:** `odilitime` (author), `greptile-apps` (review context), `NubsCarson` (routing/message-service testing).

---

### 5) Newly merged `agent/` workspace + submodule workflow may still risk fresh-clone install correctness — PR **#6702**
- **Issue Title & ID:** “Fresh clone install can break due to submodule workspace/lockfile inconsistencies” — **(needs verification issue)**
- **Current Status:** PR #6702 MERGED (review previously flagged P1 infra inconsistencies)
- **Impact Assessment:**
  - **User Impact:** **High** (developers onboarding to core repo)
  - **Functional Impact:** **Yes** (install/dev workflow can fail)
  - **Brand Impact:** **High** (repo feels brittle)
- **Technical Classification:**
  - **Category:** Bug / Build & Tooling
  - **Component:** Monorepo workspaces, submodules, `bun.lock`, dev scripts
  - **Complexity:** **Moderate effort** (tighten invariants + CI checks)
- **Resource Requirements:**
  - **Required Expertise:** Bun workspaces, git submodules, CI
  - **Dependencies:** Depends on intended policy: submodules optional vs required
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (upgrade to P0 if CI/onboarding reports failures)
- **Specific Actionable Next Steps:**
  1. Add CI job: fresh clone (no submodules initialized) → `bun install` must succeed (or fail with a clear message and documented step).
  2. Add CI job: with submodules initialized → `bun install` + `bun run dev` must succeed.
  3. Document “submodules optional dev workflow” clearly in README (including `plugin-submodules:restore` expectations).
- **Potential Assignees:** `odilitime`, `dutchiono` (Windows friction experience), a CI-focused maintainer.

---

### 6) Discord plugin feature parity gaps (typing indicators, reactions, streaming, slash commands) — WIP from dev logs
- **Issue Title & ID:** “Discord plugin parity: typing, reactions, streaming, slash commands” — **(needs issue(s) / epic)**
- **Current Status:** Work in progress (not represented as a single tracked issue in provided data)
- **Impact Assessment:**
  - **User Impact:** **High** (Discord is a primary surface for agents)
  - **Functional Impact:** **Partial** (core works, but UX and control surfaces incomplete)
  - **Brand Impact:** **High** (missing expected bot behavior)
- **Technical Classification:**
  - **Category:** UX / Feature / Reliability
  - **Component:** Plugin System (Discord plugin)
  - **Complexity:** **Complex solution** (multiple features + event handling + rate limits)
- **Resource Requirements:**
  - **Required Expertise:** Discord API, streaming message handling, interaction commands, rate limiting
  - **Dependencies:** May depend on core streaming abstractions and message service semantics
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a tracking epic with sub-issues per capability (typing, reactions, slash commands, streaming).
  2. Define acceptance tests for each feature (integration tests or harness-based).
  3. Verify compatibility with the new TOON encapsulation path (PR #6709 context).
- **Potential Assignees:** Core/plugin maintainers with Discord experience; `NubsCarson` (Discord connector testing context), `odilitime` (core integration).

---

### 7) Anthropic plugin: event payload compatibility fix still pending — WIP from dev logs
- **Issue Title & ID:** “Anthropic plugin event payload compatibility (post ai-sdk v6 migration)” — **(needs issue)**
- **Current Status:** Work in progress (Opus 4.x compatibility mostly addressed; payload fix pending)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Anthropic users; model upgrades are common)
  - **Functional Impact:** **Partial** (edge cases / streaming/events may break)
  - **Brand Impact:** **Medium** (model integration reliability perception)
- **Technical Classification:**
  - **Category:** Bug / Compatibility
  - **Component:** Model Integration (Anthropic plugin)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Anthropic API + ai-sdk v6 event schemas, streaming
  - **Dependencies:** Needs real payload samples (or fixtures) from affected users
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Capture failing payload examples and add fixtures to plugin tests.
  2. Implement backward/forward compatible parsing (tolerant decoder).
  3. Add CI matrix tests across supported Anthropic model versions if feasible.
- **Potential Assignees:** `NubsCarson` (already working in plugin-anthropic per weekly summary), model integration maintainers.

---

### 8) Agent safety / authorization layer remains unresolved (Discord discussion + multiple proposals)
- **Issue Title & ID:** “Prevent agents from performing unsafe operations (capability-based authorization)” — **(needs core issue; related to #6707, #6711, #6688)**
- **Current Status:** Unresolved question raised in Discord (2026-04-08); proposals exist
- **Impact Assessment:**
  - **User Impact:** **Critical** (anyone running agents with wallets/social posting/terminal actions)
  - **Functional Impact:** **Partial** today; will become **Yes** as financial/ops features expand
  - **Brand Impact:** **High** (safety incidents are reputationally expensive)
- **Technical Classification:**
  - **Category:** Security
  - **Component:** Core Framework + Plugin System (tool-call authorization)
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, capability models, cryptographic identity (AgentID), human-in-the-loop approval flows
  - **Dependencies:** Align with AgentID (#6688) direction; decide policy surface (core vs plugin)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P0** for a *design decision + roadmap*, **P1** for initial enforcement MVP
- **Specific Actionable Next Steps:**
  1. Open a core RFC issue: define threat model + minimum viable guardrails (deny-by-default for high-risk actions, approval tiers).
  2. Decide integration strategy:
     - Accept community plugin approach (e.g., #6707 SINT bridge) vs implement minimal core hooks.
  3. Produce an MVP spec: “capability tokens” or “policy engine hook” that runs before any tool/action executes.
  4. Add documentation: “Running agents safely” (defaults, recommended settings, examples).
- **Potential Assignees:** `odilitime` (core), `pshkv` (proposal author #6707), `aeoess` (delegation/scoped authority #6711), plus security oversight contributors (`loaditoutadmin` context).

---

### 9) Documentation gap: what is `elizabao_ai` and what can users do now? (Discord 2026-04-09)
- **Issue Title & ID:** “Docs: Clarify `elizabao_ai` purpose and current user actions” — **(needs docs issue)**
- **Current Status:** Unanswered/partially answered; community interest rising
- **Impact Assessment:**
  - **User Impact:** **Medium** (confusion + repeated questions)
  - **Functional Impact:** **No** (docs/expectation management)
  - **Brand Impact:** **Medium** (hype without clarity erodes trust)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component:** Docs / Community comms
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Product knowledge of elizabao_ai roadmap; ability to write clear docs
  - **Dependencies:** Need current status from project owner/manager
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a short “What is elizabao_ai?” page: current state, how to try (if possible), what’s not ready yet.
  2. Add a pinned Discord FAQ entry and link it from README/community docs.
- **Potential Assignees:** `baogerbao` (context), `odilitime` (community ops), a docs contributor.

---

### 10) Plugin PR: `plugin-mnemopay` has correctness and persistence gaps — PR **#6701**
- **Current Status:** OPEN PR (review highlights multiple blockers)
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (new plugin; not yet shipped)
  - **Functional Impact:** **Partial** (would be unreliable if merged as-is)
  - **Brand Impact:** **Medium** (merging a broken finance-memory plugin would hurt credibility)
- **Technical Classification:**
  - **Category:** Bug / Design
  - **Component:** Plugin System (new plugin)
  - **Complexity:** **Complex solution** (persistence design + action validation + tests)
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture, persistence/storage, input validation/testing
  - **Dependencies:** Decide whether core offers a persistence primitive plugins should use
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (block merge until resolved; not urgent for core stability)
- **Specific Actionable Next Steps:**
  1. Require persistence plan (DB adapter, file store, or explicitly “ephemeral mode” with warnings).
  2. Add guards against NaN config corruption (`MNEMOPAY_REPUTATION_DELTA`).
  3. Fix handler null-safety (`getService()` may be absent).
  4. Add tests and an eviction/retention policy to prevent unbounded growth.
- **Potential Assignees:** `t49qnsx7qt-kpanks` (author), a core plugin reviewer (`odilitime`), plus someone with storage experience.

---

## Summary: Top Highest-Priority Items (fix/decide immediately)
1. **#6704** — `elizaos create` fails on macOS (CLI onboarding blocker) — **P0**
2. **(New issue)** IGNORE memory persistence bug with `ALLOW_MEMORY_SOURCE_IDS` (post-merge regression) — **P0**
3. **(New issue)** Zero-vector embedding fallback corrupts semantic memory (post-merge regression) — **P0**
4. **PR #6712** aliasEntity ambiguity breaks group addressee routing — **P0**
5. **Agent safety / authorization RFC + MVP plan** (unsafe operations prevention) — **P0 (design/roadmap), P1 (implementation MVP)**
6. **Discord plugin parity epic** (typing/reactions/streaming/slash commands) — **P1**
7. **Anthropic plugin event payload compatibility** — **P1**
8. **Fresh-clone install verification for merged `agent/` + submodules workflow** — **P1**
9. **Docs for elizabao_ai current capabilities** — **P2**
10. **PR #6701 plugin-mnemopay hardening before merge** — **P2**

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Packaging & workspace fragility (Bun + submodules + lockfiles):** Multiple signals that “fresh clone → works” is not reliably enforced, which directly impacts contributor growth.
- **Memory pipeline correctness regressions:** Recent core changes increased configurability (allowlists, memory disable) but introduced subtle logic divergences and silent failure modes (IGNORE path, zero-vector fallback).
- **Routing/shouldRespond complexity:** As multi-agent/group-room behavior grows, deterministic routing utilities must be robust against identity model nuances (`agentId` vs `entityId`) and require stronger test coverage.
- **Safety/authorization is becoming a first-class requirement:** Discord discussions and plugin proposals converge on the same gap—there’s no standardized, enforceable “permission to act” boundary.

---

## Recommendations: Process Improvements
1. **Add “Fresh Clone” CI gates** for:
   - repo install without submodules,
   - repo install with submodules,
   - `elizaos create` on macOS/Linux (and Windows if possible).
2. **Mandate regression tests for configuration flags** (`DISABLE_MEMORY_CREATION`, `ALLOW_MEMORY_SOURCE_IDS`) and ensure behavior parity across response paths (RESPOND vs IGNORE).
3. **Introduce a “Safety Review Checklist”** for any action/plugin that can move funds, execute commands, or post externally (minimum: approval tier, rate limit, audit logging).
4. **Require “Identity invariants” tests** whenever adding routing logic (explicit fixtures for `agentId !== entityId`, multi-agent rooms, reply threads).
5. **Create epics for cross-cutting plugin parity work** (Discord/Telegram/Anthropic), with acceptance tests and compatibility matrices, to avoid “WIP in logs” without trackable issues.