## Issue Triage — 2026-04-14

### 1) **Regression: embedding failure persists zero-vector memories (silent semantic memory corruption)** — PR #6562 (merged)
- **Current Status:** Shipped in `feat: Bring Odi logging, Memory lock down, banner, other core enh` (merged 2026-04-08). Reported by automated review notes (Greptile) as a correctness bug in `packages/typescript/src/runtime.ts`.
- **Impact Assessment:**
  - **User Impact:** **High** (any deployment with intermittent embedding/provider failures)
  - **Functional Impact:** **Yes** (breaks semantic recall/retrieval for affected memory rows)
  - **Brand Impact:** **High** (silent data corruption undermines trust in “memory” feature)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (Runtime / Memory / Embeddings)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime internals; embedding pipeline; data/memory storage semantics
  - **Dependencies:** None, but should coordinate with any memory persistence controls added in PR #6562
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Change behavior on embedding failure: **do not persist** memory with a zero vector (or persist with `embedding=null` + “needsEmbedding=true” flag and exclude from vector search).
  2. Add tests covering: embedding provider timeout/error → no zero-vector persisted; retry path works; memory remains retrievable after later re-embed.
  3. Add a one-time migration/repair tool (or runtime repair task) to find and re-embed existing all-zero vectors (if already shipped to users).
  4. Cut a patch release once merged; include release note warning + remediation steps.
- **Potential Assignees:** `odilitime` (authored PR #6562), `NubsCarson` (core message/runtime changes), `dutchiono` (core contributions)

---

### 2) **Regression: IGNORE responses not persisted when `ALLOW_MEMORY_SOURCE_IDS` is set (logic mismatch between response vs ignore paths)** — PR #6562 (merged)
- **Current Status:** Shipped in PR #6562 (merged 2026-04-08). Automated review indicates IGNORE persistence path incorrectly checks `allowedSources.includes("agent_response")` (hardcoded/unconfigurable), causing IGNORE memories to be silently dropped when allowlisting is enabled.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (deployments using `ALLOW_MEMORY_SOURCE_IDS` for compliance/control)
  - **Functional Impact:** **Partial** (memory + evaluation/audit trails become inconsistent; behavior deviates from docs)
  - **Brand Impact:** **Medium** (surprising behavior; “memory controls” appear unreliable)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework (Message Service / Memory persistence)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** TypeScript message pipeline; memory source-id semantics
  - **Dependencies:** Verify intended spec for IGNORE persistence under memory gating
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Align IGNORE persistence checks with the normal response path (either treat IGNORE as `sourceId=agent_response` consistently, or bypass allowlist for IGNORE by design—document explicitly).
  2. Add unit tests: with `ALLOW_MEMORY_SOURCE_IDS` set, IGNORE decisions persist (or intentionally do not) per spec.
  3. Audit other branches in `message.ts` for duplicated allowlist logic / variable shadowing noted in review.
- **Potential Assignees:** `odilitime`, `NubsCarson`

---

### 3) **`elizaos create` fails on macOS with “Bun's postinstall script was not run” (bun package listed as runtime dependency)** — Issue #6704
- **Current Status:** **OPEN** (no comments yet). Reproducible on macOS Apple Silicon; CLI deletes project directory on failure, worsening UX.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks new user onboarding on a common environment)
  - **Functional Impact:** **Yes** (prevents project creation)
  - **Brand Impact:** **High** (“getting started” failure is highly visible)
- **Technical Classification:**
  - **Issue Category:** Bug / DX
  - **Component Affected:** CLI / Plugin Bootstrap / Packaging
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun packaging; dependency management; CLI templates/install flow
  - **Dependencies:** Confirm current `@elizaos/cli` + `@elizaos/plugin-bootstrap` package.json dependency graphs; validate across npm/bun/pnpm
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Remove `bun` from runtime `dependencies` in CLI/bootstrap; move to `devDependencies` and depend on `@types/bun` if needed.
  2. Add install/create CI matrix: macOS (aarch64) + bun; ensure `elizaos create` completes and leaves project intact on failure.
  3. Change failure behavior: do **not** delete project dir automatically; keep artifacts/logs for debugging.
  4. Publish patched CLI versions and update docs (workarounds + recommended install path).
- **Potential Assignees:** `odilitime` (core/dev tooling), `dutchiono` (DX), `dirtybits` (reporter; can validate fix)

---

### 4) **Post-merge risk: repo dev harness + plugin submodule workspace/lockfile inconsistencies may break fresh clones/CI** — PR #6702 (merged)
- **Current Status:** **Merged** (2026-04-09). Pre-merge review flagged: committed workspace entries pointing to submodule paths + bun.lock mismatch (`workspace:*` vs `alpha` dist-tag) and missing submodule dirs on fresh clone.
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily affects contributors; can affect anyone building from source)
  - **Functional Impact:** **Partial** (install/build failures; broken dev workflow)
  - **Brand Impact:** **Medium** (contributor friction; “repo doesn’t install”)
- **Technical Classification:**
  - **Issue Category:** Bug / Build & Release Engineering
  - **Component Affected:** Monorepo workspace config; tooling scripts; lockfile hygiene
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** bun workspaces/lockfiles; monorepo tooling; CI
  - **Dependencies:** Validate actual current state on `main` (whether follow-up commits resolved it)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. On a clean environment (no submodules), run: `bun install` + CI build to confirm pass/fail.
  2. If failing: ensure default `package.json` does **not** include submodule workspace paths unless submodules are guaranteed present (or make submodules optional via scripts that run before install in CI).
  3. Regenerate `bun.lock` to match declared workspace resolution (or remove `workspace:*` if not stable).
  4. Add CI job: “fresh clone, no submodules initialized” + “with submodules initialized” to enforce both paths.
- **Potential Assignees:** `odilitime`, `dutchiono`

---

### 5) **Group addressee routing: `aliasEntity` introduces ambiguity causing name resolution failure when `agentId !== entityId`** — PR #6712 (open)
- **Current Status:** **OPEN PR** (not merged). Review flagged a P1 logic bug that can silently disable the feature the PR introduces.
- **Impact Assessment:**
  - **User Impact:** **Medium** (group-room deployments; multi-agent rooms)
  - **Functional Impact:** **Partial** (misrouting: agent may fail to respond when addressed or fail to ignore when others are addressed)
  - **Brand Impact:** **Medium** (multi-party chat quality/regressions are visible)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Core Framework (group routing, shouldRespond)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript; entity/agent identity model; group message routing semantics
  - **Dependencies:** Add missing test coverage for alias behavior
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (block merge until fixed)
- **Specific Actionable Next Steps:**
  1. Fix `aliasEntity`/token registry so aliasing does not create multi-entity ambiguity for single tokens (or adjust `resolveSingleToken` to prefer canonical mapping).
  2. Add unit tests specifically for `agentId !== entityId` scenarios, ensuring addressed-to-self/other resolves deterministically.
  3. Re-run existing message-service group routing tests and add regression tests for common connectors (Discord reply threads).
- **Potential Assignees:** `odilitime` (author), `NubsCarson` (message service experience)

---

### 6) **TOON connectors: missing action params + continuation-loop spam for async task actions** — PR #6709 (open)
- **Current Status:** **OPEN PR** (not merged). Contains targeted fixes for `DefaultMessageService` impacting Discord/Milady-style non-streaming “toon encapsulation” connectors.
- **Impact Assessment:**
  - **User Impact:** **High** (connectors that rely on TOON; actions with required params; orchestrator/task flows)
  - **Functional Impact:** **Yes** (actions fail silently without params; spammy filler responses during async tasks)
  - **Brand Impact:** **High** (visible “agent is broken/noisy” behavior)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Core Framework (Message Service / Prompt schema / Action execution loop)
  - **Complexity:** Simple fix (merge + minor cleanup)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript message service; action schema; connector formats
  - **Dependencies:** Ensure compatibility with recent prompt/template migrations and any shouldRespond changes
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Fast-track review and merge PR #6709.
  2. Add a regression test: TOON single-shot response includes `params` and actions execute with required params.
  3. Add a regression test: async task actions included in terminal set → no continuation-loop spam.
- **Potential Assignees:** `NubsCarson` (author), `odilitime` (core reviewer)

---

### 7) **plugin-mnemopay PR: no persistence, NaN reputation corruption, unsafe null casts, unbounded memory growth** — PR #6701 (open)
- **Current Status:** **OPEN PR** (not merged). Automated review recommends “not safe to merge” due to fundamental design gaps vs stated purpose.
- **Impact Assessment:**
  - **User Impact:** **Medium** (only if merged/used; but affects trust in “economic memory” narrative)
  - **Functional Impact:** **Partial** (plugin-level; but can crash via null deref and silently corrupt reputation via NaN)
  - **Brand Impact:** **Medium** (shipping “economic memory” that resets on restart is reputationally risky)
- **Technical Classification:**
  - **Issue Category:** Bug / Feature quality / Reliability
  - **Component Affected:** Plugin System (plugin-mnemopay within core repo)
  - **Complexity:** Complex solution (needs persistence + resource controls + tests)
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture; persistence adapters; testing; safe parsing/validation
  - **Dependencies:** Decide persistence layer approach (reuse SQL plugin? file-based? runtime memory store?)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (do not merge until addressed; schedule if strategically important)
- **Specific Actionable Next Steps:**
  1. Require persistence (SQL adapter integration or pluggable storage) or re-scope claims/docs to “in-memory demo only”.
  2. Add config validation (guard `MNEMOPAY_REPUTATION_DELTA` against NaN; clamp properly).
  3. Fix null-safety in every handler/evaluator (no unsafe casts).
  4. Add eviction/limits for evaluator-driven memory writes.
  5. Add tests for actions + evaluator + persistence behavior.
- **Potential Assignees:** `t49qnsx7qt-kpanks` (author), `odilitime` (plugin/core patterns), `dutchiono` (testing/DX)

---

### 8) **Plugin proposal: capability token enforcement for tool calls** — Issue #6707
- **Current Status:** **OPEN** (proposal; aligns with AgentID/capability-based authorization discussions)
- **Impact Assessment:**
  - **User Impact:** **Medium** (high value for agents doing irreversible actions; not required for basic use)
  - **Functional Impact:** **No** (not blocking; adds safety layer)
  - **Brand Impact:** **High** (security posture for agent actions is strategic)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Security
  - **Component Affected:** Plugin System; Guardrails/Authorization layer
  - **Complexity:** Architectural change (if standardized in core), otherwise moderate as community plugin
- **Resource Requirements:**
  - **Required Expertise:** Security engineering; cryptographic capabilities; policy engines; audit logging
  - **Dependencies:** Directional decision: how this integrates with AgentID (#6688 referenced) and existing GuardrailsService
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P3** (roadmap-level, but start design review)
- **Specific Actionable Next Steps:**
  1. Decide minimal interface for “authorization interceptors” in the tool-call pipeline.
  2. Clarify compatibility goals with AgentID schemas and evidence/audit formats.
  3. If accepted as plugin: define required hooks + example implementation; add to registry with security review checklist.
- **Potential Assignees:** `odilitime` (core), `pshkv` (proposal author)

---

### 9) **Plugin: SafeAgent token safety checks before trading** — Issue #6706
- **Current Status:** **OPEN** (proposal; intended for registry contribution)
- **Impact Assessment:**
  - **User Impact:** **Medium** (important for on-chain trading agents; not universal)
  - **Functional Impact:** **No** (optional)
  - **Brand Impact:** **Medium** (safer trading narrative helps, but must be vetted)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Security
  - **Component Affected:** Plugin System; Wallet/Trading tool ecosystem
  - **Complexity:** Moderate effort (integration + review + threat modeling)
- **Resource Requirements:**
  - **Required Expertise:** Web3 security; plugin review; RPC/DEX simulation safety; rate limiting
  - **Dependencies:** Registry submission process; security review standards for plugins handling trades
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Request a registry PR with clear API surfaces, failure modes, and safe defaults (block-by-default for low scores).
  2. Add docs: disclaimers, chain coverage, caching, RPC usage, and how to avoid MEV or risky simulations.
  3. Run lightweight security review before “official” endorsement.
- **Potential Assignees:** `CryptoGenesisSecurity` (author), `odilitime` (plugin governance)

---

### 10) **Plugin: MAXIA AI Marketplace integration** — Issue #6700
- **Current Status:** **OPEN** (proposal; seeking approach feedback)
- **Impact Assessment:**
  - **User Impact:** Low–Medium (use-case specific)
  - **Functional Impact:** No
  - **Brand Impact:** Low–Medium (ecosystem growth, but also introduces third-party risk)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Plugin System; Marketplace/Wallet integrations
  - **Complexity:** Complex solution (large API surface + long-term maintenance)
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture; API client design; wallet safety; maintenance planning
  - **Dependencies:** Define standards for marketplace/financial plugins; align with AgentID/trust framework direction
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P4**
- **Specific Actionable Next Steps:**
  1. Ask proposer to start with a minimal subset (swap + discovery) and ship iteratively.
  2. Require strict permissioning/guardrails for any asset-moving actions.
  3. Route to plugin registry rather than core unless there’s a strategic reason to vendor it.
- **Potential Assignees:** `majorelalexis-stack` (author), `odilitime` (review/guidance)

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0:** Zero-vector embedding fallback corrupts semantic memory — PR #6562 regression (core data correctness).
2. **P0:** `elizaos create` fails on macOS due to bun dependency/postinstall behavior — Issue #6704 (onboarding blocker).
3. **P1:** IGNORE memory persistence broken under `ALLOW_MEMORY_SOURCE_IDS` — PR #6562 regression (behavioral correctness + trust).
4. **P1:** Verify/fix post-merge workspace/submodule + bun.lock consistency — PR #6702 (fresh clone/install stability).
5. **P1:** Merge TOON params + async terminal-action continuation fixes — PR #6709 (connector reliability, action execution correctness).
6. **P1 (block merge):** Fix aliasEntity ambiguity in group addressee routing — PR #6712 (prevents feature from working).
7. **P2 (block merge):** plugin-mnemopay requires persistence, safety validation, and tests — PR #6701.
8. **P3:** Capability-token tool-call enforcement proposal — Issue #6707 (start design review; align with AgentID).
9. **P3:** SafeAgent token safety plugin proposal — Issue #6706 (registry + security review).
10. **P4:** MAXIA marketplace plugin proposal — Issue #6700 (defer; request MVP scope).

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Silent correctness failures in “memory” workflows:** multiple regressions indicate insufficient invariant testing around persistence, embedding lifecycle, and “memory gating” configs (`DISABLE_MEMORY_CREATION`, `ALLOW_MEMORY_SOURCE_IDS`).
- **Prompt/schema format evolution (XML ↔ TOON) impacts core action execution:** missing schema fields and continuation-loop logic show that connector encapsulation formats need explicit contract tests.
- **Monorepo/dev tooling changes can ship with install-time footguns:** submodule/workspace workflows are fragile without CI enforcing “fresh clone” install paths.
- **Identity ambiguity (`agentId` vs `entityId`) leaks into routing logic:** addressee resolution and aliasing need clear canonicalization rules in core types/utilities.

---

## Process Improvements (to prevent repeats)
1. **Add “Core invariants” test suite gates for memory correctness:**
   - No zero-vector persistence on embedding failure
   - Deterministic behavior for allowlist/disable-memory flags across all message paths (RESPOND + IGNORE)
2. **Introduce connector contract tests for encapsulation formats (TOON/XML):**
   - Required params extraction for a representative action set
   - Async action terminal behavior (no continuation spam)
3. **CI matrix for onboarding + repo install:**
   - `elizaos create` on macOS (aarch64) + bun
   - Fresh clone install without submodules initialized
   - Fresh clone install with submodules initialized (if supported)
4. **Pre-merge “risk checklist” for large PRs touching runtime/message pipeline:**
   - Explicit regression test additions required for each behavior change
   - Flag any default timeout/latency changes as “breaking-ish” requiring release notes
5. **Clarify and codify identity mapping rules in core (`agentId`, `entityId`):**
   - Provide a canonicalization helper and require routing features to use it
   - Add tests covering mixed-id deployments (multi-agent rooms, connectors with reply metadata)