## Issue Triage — 2026-04-12

### 1) `elizaos create` fails with “Bun's postinstall script was not run” on macOS — **#6704** (elizaos/eliza)
- **Current Status:** OPEN (no comments)
- **Impact Assessment:**
  - **User Impact:** **High** (blocks new-project creation for a common dev platform)
  - **Functional Impact:** **Yes** (CLI scaffolding/build is a primary onboarding path)
  - **Brand Impact:** **High** (first-run failure erodes trust quickly)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** CLI / Project scaffolding / Packaging
  - **Complexity:** Moderate effort (dependency + template/build flow adjustments; release required)
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun packaging, workspace dependency hygiene, CLI release process
  - **Dependencies:** None, but needs validation across macOS (aarch64), Linux, Windows
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce on macOS Apple Silicon with current published `@elizaos/cli`.
  2. Remove `bun` from **runtime** deps where possible; replace with `@types/bun` in dev deps (as reporter suggests) or detect/require system bun explicitly.
  3. Add CLI preflight: detect broken `node_modules/bun` stubs and print a targeted remediation instead of deleting the project directory.
  4. Add CI smoke test: `elizaos create` + build on macOS runner.
  5. Patch release `@elizaos/cli` and document known-install constraints.
- **Potential Assignees:** **odilitime** (core/packaging), **dirtybits** (reporter; can validate fix), plus a release owner for `@elizaos/cli`.

---

### 2) Regression risk from merged core PR: IGNORE memories silently dropped when `ALLOW_MEMORY_SOURCE_IDS` is set — **PR #6562 follow-up (no issue filed yet)** (elizaos/eliza)
- **Current Status:** **Merged** (2026-04-08); reviewer identified logic bug in `DefaultMessageService` IGNORE path
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (affects deployments using memory allowlisting; hard to detect)
  - **Functional Impact:** **Partial** (memory/audit behaviors become inconsistent; “IGNORE” decisions not persisted)
  - **Brand Impact:** **Medium** (subtle correctness failures + confusing behavior)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Core Framework (TypeScript runtime) / Message service / Memory persistence
  - **Complexity:** Simple fix (logic parity between normal response path and IGNORE path)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript core runtime, message pipeline semantics
  - **Dependencies:** None; should be fixed before more memory-gating features ship
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. File a dedicated issue referencing PR #6562 and the identified code region (`packages/typescript/src/services/message.ts`, IGNORE persistence logic).
  2. Change IGNORE persistence to not require `allowedSources.includes("agent_response")` (or align it with the main response persistence rules).
  3. Add unit test: when `ALLOW_MEMORY_SOURCE_IDS` is configured, IGNORE decisions are (a) handled consistently and (b) persisted/recorded per intended design.
  4. Patch release if behavior affects stable users.
- **Potential Assignees:** **odilitime** (authored PR), **NubsCarson** (message service experience, recent fixes in #6709).

---

### 3) Regression risk from merged core PR: embedding failure persists “zero-vector” memories (unretrievable/poisoned semantic recall) — **PR #6562 follow-up (no issue filed yet)** (elizaos/eliza)
- **Current Status:** **Merged** (2026-04-08); reviewer flagged zero-vector fallback
- **Impact Assessment:**
  - **User Impact:** **Medium** (only on embedding failure paths, but silently corrupts retrieval quality)
  - **Functional Impact:** **Partial** (semantic memory becomes inconsistent; “stored but never recalled”)
  - **Brand Impact:** **High** (perceived as “memory doesn’t work” / data loss)
- **Technical Classification:**
  - **Category:** Bug / Reliability
  - **Component:** Core Framework (TypeScript runtime) / Memory + Embeddings
  - **Complexity:** Moderate effort (decide correct failure policy + migration/cleanup strategy)
- **Resource Requirements:**
  - **Required Expertise:** embeddings pipeline, vector DB/search behavior, runtime persistence
  - **Dependencies:** Depends on how memory storage + retrieval are implemented across adapters
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. File an issue referencing PR #6562 and location (`packages/typescript/src/runtime.ts`, embedding failure fallback).
  2. Replace “persist with zero vector” with one of:
     - do not persist semantic entry until embedding succeeds, or
     - persist as “pending embedding” and retry asynchronously, or
     - persist as non-semantic memory (excluded from vector search).
  3. Add a metric/log event on embedding failures + retries.
  4. Provide a cleanup script or migration guidance to remove/repair zero-vector rows.
- **Potential Assignees:** **odilitime**, a maintainer familiar with memory adapters/vector search internals.

---

### 4) PR blocks: group addressee routing alias ambiguity breaks name resolution for agents with distinct `agentId` vs `entityId` — **PR #6712** (elizaos/eliza)
- **Current Status:** OPEN; reviewer marked **P1 logic bug**
- **Impact Assessment:**
  - **User Impact:** **High** for group-room deployments (Discord/Telegram-style multi-party rooms)
  - **Functional Impact:** **Partial** (feature being introduced is effectively disabled for a common identity configuration)
  - **Brand Impact:** **Medium** (group-chat correctness is highly visible: wrong replies, missed replies)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Core Framework / Group-room routing (`NameVariationRegistry`, addressee resolution)
  - **Complexity:** Moderate effort (identity mapping semantics + tests)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript core, entity/agent identity model, group messaging semantics
  - **Dependencies:** Should be resolved before merge; may touch AgentID direction
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (fix this sprint; blocks safe merge)
- **Specific Actionable Next Steps:**
  1. Adjust `aliasEntity()` / token-to-entity mapping so alternate IDs do not create multi-entity ambiguity for the same person/agent.
  2. Add tests specifically covering:
     - `agentId !== entityId` agents
     - multiple agents with similar name tokens
     - reply-thread `parentMessageAuthorEntityId` paths
  3. Re-run group-room scenarios (Discord connector) to confirm `isAddressedToSelf/Other` behavior.
- **Potential Assignees:** **odilitime** (PR author), plus a reviewer with connector experience (e.g., **NubsCarson**).

---

### 5) Open PR: TOON connector params + async terminal-action continuation loop fixes need merge decision — **PR #6709** (elizaos/eliza)
- **Current Status:** OPEN; reviewed positively; tested on Discord/milady connector
- **Impact Assessment:**
  - **User Impact:** **High** for TOON-based connectors (Discord, Milady) using required action params
  - **Functional Impact:** **Yes** for affected actions (required params never passed; async task actions spam filler)
  - **Brand Impact:** **Medium** (visible spam + “actions don’t work” reports)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** Core Framework / Message service / Prompt schema (TOON)
  - **Complexity:** Simple fix (already implemented; needs final review + merge)
- **Resource Requirements:**
  - **Required Expertise:** Message service, schema/prompt formats
  - **Dependencies:** None
  - **Estimated Effort:** **1/5** (to land) + **1/5** (post-merge monitoring)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Final maintainer review focusing on the message schema change and terminalActions set.
  2. Merge and cut a patch release if connectors depend on it.
  3. Add/confirm regression test: TOON path emits/consumes `params` for required-param actions.
- **Potential Assignees:** **NubsCarson** (author), **odilitime** (core maintainer to approve/merge).

---

### 6) Documentation gap: canonical Socket.IO v2 messaging protocol (message type enums, required/optional payload fields, auth entityId, DM channel creation) — **Discord 2026-04-10 (no GH issue linked)**
- **Current Status:** Untracked as a GitHub issue (action item raised in Discord)
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects integrators building dashboards/connectors)
  - **Functional Impact:** **Partial** (blocks some integrations; workarounds exist via source spelunking)
  - **Brand Impact:** **Medium** (perception: “undocumented protocol”)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component:** API / Realtime transport (Socket.IO), v2 integration docs
  - **Complexity:** Moderate effort (enumerate types, examples, and edge cases)
- **Resource Requirements:**
  - **Required Expertise:** Socket.IO server/client behavior, elizaOS message types, connector patterns
  - **Dependencies:** Align with v3 roadmap messaging decisions (document “as-is” support level)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a docs issue: “Socket.IO protocol reference (v2)”.
  2. Publish: message type enum + payload schemas + auth (`entityId` UUID) + join/send examples + HTTP polling fallback notes.
  3. Add a “Programmatic DM channel creation” recipe (or explicit statement it’s unsupported).
  4. Add minimal “supported/unsupported” banner given current v3 focus.
- **Potential Assignees:** **odilitime** (context), a docs maintainer, and a community integrator (e.g., **Shah0406** for validation).

---

### 7) Community support: Collab.land wallet verification failures — **Discord 2026-04-10 (no GH issue linked)**
- **Current Status:** Unresolved in discussion
- **Impact Assessment:**
  - **User Impact:** **Medium** (impacts onboarding/access control in Discord)
  - **Functional Impact:** **No** (not core framework functionality)
  - **Brand Impact:** **Medium** (community trust + contributor onboarding friction)
- **Technical Classification:**
  - **Category:** UX / Support
  - **Component:** Community Ops / Discord integrations
  - **Complexity:** Simple fix (runbook + troubleshooting; may be external)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin tooling, Collab.land configuration, wallet auth flows
  - **Dependencies:** External service status/behavior
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Create a “Wallet verification troubleshooting” doc/runbook (common errors, chain/network, signing method).
  2. Identify whether issue is user-side (wrong wallet, wrong network) vs server-side (Collab.land role binding).
  3. Provide escalation path (modmail channel, screenshots/log format).
- **Potential Assignees:** Discord/community moderators; a core team member to publish the runbook.

---

### 8) PR needs major rework before merge: `plugin-mnemopay` (economic memory) lacks persistence, has NaN reputation corruption risk, unsafe null casts, no tests — **PR #6701** (elizaos/eliza)
- **Current Status:** OPEN; review indicates “not safe to merge”
- **Impact Assessment:**
  - **User Impact:** **Low** (new plugin not yet shipped)
  - **Functional Impact:** **No** (does not block core), but would add instability if merged
  - **Brand Impact:** **Medium** if merged prematurely (broken “economic memory” promise)
- **Technical Classification:**
  - **Category:** Feature / Reliability
  - **Component:** Plugin System / Finance-oriented plugin
  - **Complexity:** Complex solution (persistence design + eviction + test coverage)
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture, persistence/storage adapters, testing strategy
  - **Dependencies:** Decide persistence approach (SQL adapter? file? provider DB?) and retention policy
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (keep unmerged; plan properly)
- **Specific Actionable Next Steps:**
  1. Require persistence (even minimal) or re-scope claims to “ephemeral memory”.
  2. Add config validation (guard against `NaN` delta; bounds checking).
  3. Fix handler null-safety (no unsafe casts after validate).
  4. De-conflict action triggers (`remember` keyword collision).
  5. Add memory eviction/retention policy + tests (unit tests at minimum).
- **Potential Assignees:** **t49qnsx7qt-kpanks** (author), plus a core plugin maintainer for design review.

---

### 9) Feature proposal: capability-token enforcement for tool calls (`@sint/eliza-plugin`) — **#6707** (elizaos/eliza)
- **Current Status:** OPEN (proposal)
- **Impact Assessment:**
  - **User Impact:** **Medium** (valuable for agents that can transact/post/act physically)
  - **Functional Impact:** **Partial** (addresses missing authorization layer; not a current outage)
  - **Brand Impact:** **High** if executed well (trust/security posture), **Medium** if ignored (users will build ad-hoc guardrails)
- **Technical Classification:**
  - **Category:** Security / Feature Request
  - **Component:** Core Framework / Guardrails / Tool execution pipeline
  - **Complexity:** Architectural change (policy gateway integration, approval flows, audit trail)
- **Resource Requirements:**
  - **Required Expertise:** Security architecture, cryptographic authorization, runtime/tool call interceptors
  - **Dependencies:** Alignment with **AgentID** direction and capability-based authorization discussions
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Triage with AgentID owners: define integration points (tool call intercept, policy decision, evidence ledger hook).
  2. Require a minimal MVP scope: enforce capability tokens on selected high-risk tool namespaces.
  3. Clarify whether this belongs in core vs plugin registry.
  4. Define a threat model + UX for human approval tiers.
- **Potential Assignees:** **pshkv** (proposer), plus core security-minded maintainers (AgentID stakeholders).

---

### 10) Plugin proposal: MAXIA AI Marketplace integration — **#6700** (elizaos/eliza)
- **Current Status:** OPEN (proposal)
- **Impact Assessment:**
  - **User Impact:** Low (optional integration)
  - **Functional Impact:** No
  - **Brand Impact:** Low → Medium (ecosystem breadth)
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component:** Plugin System / External marketplace integration
  - **Complexity:** Complex solution (large API surface; long-term maintenance)
- **Resource Requirements:**
  - **Required Expertise:** Plugin development, API integration, on-chain transaction safety
  - **Dependencies:** Review alignment with wallet plugin + safety checks
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Ask for a reduced-scope PR: a few high-value actions (swap + GPU rental) first.
  2. Require security review: signing, escrow flows, rate limits, secret handling.
  3. Prefer submission to plugin registry with clear maintenance ownership.
- **Potential Assignees:** **majorelalexis-stack** (proposer/maintainer), registry maintainers.

---

## Summary: Top highest-priority items to address now (next 1–7 days)
1. **#6704** — CLI `elizaos create` broken on macOS due to Bun dependency/postinstall behavior (**P0**)
2. **PR #6562 follow-up** — IGNORE memory persistence logic bug under `ALLOW_MEMORY_SOURCE_IDS` (**P0**, file issue + patch)
3. **PR #6562 follow-up** — zero-vector embedding fallback causing silent semantic memory corruption (**P0**, file issue + patch)
4. **PR #6712** — alias ambiguity breaks group addressee routing when `agentId !== entityId` (**P1**, fix before merge)
5. **PR #6709** — TOON action params + async task continuation loop spam fix (**P1**, merge + ship)
6. **Socket.IO v2 protocol docs gap** (Discord action item) (**P2**, create issue + publish reference)
7. **PR #6701** — plugin-mnemopay not mergeable without persistence/tests (**P2**, keep out of mainline until corrected)

---

## Patterns / Themes (possible deeper architectural issues)
- **Packaging + toolchain coupling (Bun + workspaces):** failures in first-run flows indicate that runtime dependencies and installer behavior aren’t consistently modeled across environments (macOS vs others).
- **Message pipeline correctness regressions:** multiple changes concentrate in `DefaultMessageService` and routing/shouldRespond logic; subtle branches (IGNORE, allowlists, reply-thread metadata) can silently change semantics without obvious failures.
- **Identity ambiguity:** repeated tension between `agentId` vs `entityId` and name/token resolution suggests the identity model needs a clearer, testable contract—especially as AgentID work progresses.
- **Persistence semantics under-specified:** both core memory (embedding failure policy) and new “economic memory” proposals show missing standards for durability, retry, and data hygiene.

---

## Process improvement recommendations
1. **Add “onboarding smoke tests” to CI:** `elizaos create` + build/run on macOS, Linux, Windows for each CLI release (and at least weekly on main).
2. **Require “behavioral parity tests” for message-service branches:** explicit unit tests for IGNORE, allowlists, reply threading, and group routing; treat these as invariants.
3. **Introduce a “persistence contract” checklist for memory-affecting PRs:** define how failures are handled (retry vs skip vs mark-pending), and require a migration/cleanup plan when storing vectors.
4. **Identity contract + fixtures:** create canonical fixtures where `agentId !== entityId`, multiple agents share partial name tokens, and connectors provide reply metadata—use these fixtures across routing/AgentID changes.
5. **Docs-to-issues hygiene from Discord:** when an action item is identified (Socket.IO protocol), immediately open a GitHub issue with owner + acceptance criteria to avoid repeated “check the codebase” guidance.