## Issue Triage — 2026-02-01

### 1) ElizaCloud MCP app fails after “auth success” due to `isomorphic-dompurify` ESM/CJS import error
- **Issue Title & ID**: ElizaCloud MCP endpoint crash: `isomorphic-dompurify` CommonJS/ESM incompatibility (DISC-2026-01-31-CODERS-01)
- **Current Status**: Reported by user; reproducible during OpenClaw → ElizaCloud MCP connection; unresolved.
- **Impact Assessment**
  - **User Impact**: **High** (blocks integrations for any external agent trying to connect to ElizaCloud MCP)
  - **Functional Impact**: **Yes** (prevents successful session/use even after auth)
  - **Brand Impact**: **High** (public-facing cloud reliability; “unfit beta” sentiment)
- **Technical Classification**
  - **Issue Category**: Bug
  - **Component Affected**: ElizaCloud / MCP deployment packaging
  - **Complexity**: Moderate effort (build/runtime module format alignment)
- **Resource Requirements**
  - **Required Expertise**: Node.js packaging, ESM/CJS interop, bundlers (Vite/Next/node runtime), server deployment
  - **Dependencies**: None, but may interact with A2A endpoint fixes below
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Capture stack trace + exact runtime (node version, bundler, platform) from production logs.
  2. Reproduce locally with production build (not dev) and confirm whether `isomorphic-dompurify` is being imported from server-side code path.
  3. Apply one of: (a) switch to ESM build consistently, (b) pin/replace module version, (c) dynamic import with `await import()` guarded for server/client, (d) bundle/alias to correct entry (`module` vs `main`).
  4. Add a deployment smoke test: “MCP connect → auth → list tools” to CI/CD.
- **Potential Assignees**
  - **DorianD** (reporter; can validate fix against OpenClaw client)
  - **0xbbjoker** (ElizaCloud/A2A familiarity; already sharing A2A docs)
  - **Core web/platform maintainer** from ElizaCloud team (owner of deployment pipeline)

---

### 2) A2A `message/send` fails due to `contentModerationService` function error
- **Issue Title & ID**: ElizaCloud A2A `message/send` breaks: `contentModerationService` failure (DISC-2026-01-31-CODERS-02)
- **Current Status**: Reported; unresolved; blocks messaging flow.
- **Impact Assessment**
  - **User Impact**: **High** (affects anyone using A2A messaging via ElizaCloud)
  - **Functional Impact**: **Yes** (core protocol endpoint failing)
  - **Brand Impact**: **High** (protocol stability + developer trust)
- **Technical Classification**
  - **Issue Category**: Bug
  - **Component Affected**: API / A2A protocol implementation (ElizaCloud)
  - **Complexity**: Moderate effort (service wiring/config + runtime guards)
- **Resource Requirements**
  - **Required Expertise**: TypeScript backend, service initialization/DI, feature-flagging, API error handling, observability
  - **Dependencies**: Potentially depends on moderation provider credentials/configuration being present in env
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Add structured logging around moderation invocation (inputs redacted).
  2. Confirm whether `contentModerationService` is undefined, mis-typed, or throwing due to missing provider config.
  3. Implement a safe fallback path (e.g., “moderation disabled” or “pass-through”) behind a config flag for beta to avoid hard failure.
  4. Add contract tests for `message/send` (happy path + moderation failure path).
- **Potential Assignees**
  - **0xbbjoker** (A2A docs and likely proximity)
  - **DorianD** (can supply request payloads / client reproduction)
  - **Platform/API maintainer** (owns ElizaCloud services)

---

### 3) Eliza Framework 1.7.2 action callbacks execute in reverse order; structured return omitted
- **Issue Title & ID**: Action callback sequencing broken in `eliza` v1.7.2 (reverse order + missing structured return) (DISC-2026-01-29-CODERS-01)
- **Current Status**: Reported; no workaround confirmed; affects multiple plugins (`plugin-sql`, `plugin-openai`, `plugin-bootstrap` usage patterns).
- **Impact Assessment**
  - **User Impact**: **High** (breaks common plugin authoring expectations; likely widespread in custom agents)
  - **Functional Impact**: **Partial** (agents run but produce wrong/missing outputs, breaking workflows)
  - **Brand Impact**: **High** (core framework reliability + plugin ecosystem confidence)
- **Technical Classification**
  - **Issue Category**: Bug
  - **Component Affected**: Core Framework (action execution / messaging pipeline)
  - **Complexity**: Complex solution (ordering can be affected by async concurrency, streaming, middleware)
- **Resource Requirements**
  - **Required Expertise**: Core runtime internals, async sequencing, message bus/event queue, regression testing
  - **Dependencies**: None, but needs reproduction harness + pinned version tests
  - **Estimated Effort**: **4/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Create minimal reproduction plugin demonstrating the 3-message sequence expectation vs actual behavior.
  2. Bisect between 1.7.1 → 1.7.2 (or nearest known good) to identify offending commit.
  3. Decide intended semantics: strict sequential emits vs “best effort” concurrent emits; update docs only if behavior is deliberately changed (unlikely).
  4. Add a regression test to lock ordering and ensure “structured return” is emitted.
- **Potential Assignees**
  - **Odilitime** (core framework involvement; strong context on breakages)
  - **Stan ⚡** (test harness patterns; can help build regression tests)
  - **Victor Creed** (reporter; validate fix in real plugin usage)

---

### 4) Migration portal shows “0 eligible” for wallets that should qualify; also reports of HTTP 429 on load
- **Issue Title & ID**: Migration portal eligibility/ratelimit failures (“0 eligible” + 429 on page load) (DISC-2026-01-30-MIGRATE-01)
- **Current Status**: Ongoing user reports; partial troubleshooting (LP, wallet mismatch, snapshot timing); unresolved for some (including Ledger snapshot case).
- **Impact Assessment**
  - **User Impact**: **Critical** (token holders blocked from migration; high support burden)
  - **Functional Impact**: **Yes** (primary migration function fails)
  - **Brand Impact**: **High** (trust + “scam” confusion amplification)
- **Technical Classification**
  - **Issue Category**: Bug / Performance (rate limiting) / UX (unclear diagnostics)
  - **Component Affected**: Web app + backend eligibility API + infra rate limiting
  - **Complexity**: Moderate effort (API robustness + UX messaging + caching)
- **Resource Requirements**
  - **Required Expertise**: Web/API engineering, blockchain snapshot/eligibility logic, infra (CDN/WAF), rate-limit tuning
  - **Dependencies**: Access to snapshot dataset, indexer reliability, WAF configuration
  - **Estimated Effort**: **4/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Instrument eligibility endpoint with reason codes (e.g., `IN_LP_AT_SNAPSHOT`, `POST_SNAPSHOT_ACQUISITION`, `UNINDEXED_ADDRESS`, `CHAIN_MISMATCH`).
  2. Add “self-diagnose” UI that shows which chain, which snapshot block/time, and what balances were detected.
  3. Fix 429s: precompute/cache eligibility responses; apply per-IP and per-wallet rate limits separately; ensure page load doesn’t trigger multiple concurrent eligibility calls.
  4. Publish a canonical “Official Support Never DMs” banner directly on the migration page to reduce scam success.
- **Potential Assignees**
  - **Omid Sa** (support routing; can validate user flows)
  - **Odilitime** (has been troubleshooting; can define reason-code UX)
  - **Web/infra maintainer** for migrate.elizafoundation.ai (rate limit + caching)

---

### 5) Active scam/social engineering targeting users during migration and support flows
- **Issue Title & ID**: Migration-era impersonation scams (fake support DMs requesting seed phrases) (DISC-2026-01-31-SEC-01)
- **Current Status**: Active incidents; moderators intervened successfully in at least one case; ongoing risk.
- **Impact Assessment**
  - **User Impact**: **Critical** (direct user fund loss risk)
  - **Functional Impact**: **Partial** (not a code crash, but blocks safe adoption and increases churn)
  - **Brand Impact**: **High** (users associate scams with project if not clearly mitigated)
- **Technical Classification**
  - **Issue Category**: Security / UX
  - **Component Affected**: Support process, Discord moderation, migration site UX, documentation
  - **Complexity**: Moderate effort (process + comms + small product changes)
- **Resource Requirements**
  - **Required Expertise**: Security response, community moderation ops, web UX/content
  - **Dependencies**: Coordination with Discord admins/mod tooling; website deployment
  - **Estimated Effort**: **2/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Pin an “Official Support Policy” in Discord + migrate site: no DMs, no seed phrase, only verified ticket channel.
  2. Add “report scam” workflow and auto-response in ticket system.
  3. Add DM-scam warning to any eligibility failure screen (since that’s when scammers pounce).
  4. Collect known scam handles/domains and publish a blocklist internally for mods.
- **Potential Assignees**
  - **Maff || Hourglass ⌛** (already intervening effectively)
  - **Security lead / maintainers of `SECURITY.md` process** (ensure consistent reporting)
  - **Web maintainer** for migration UI warnings

---

### 6) Provider selection fails in `develop` branch for “one-shot” mode
- **Issue Title & ID**: `develop` one-shot mode provider selection bug (DISC-2026-01-30-DEV-01)
- **Current Status**: Reported by core dev; unresolved.
- **Impact Assessment**
  - **User Impact**: Medium (affects dev branch users and CI; but blocks testing and upcoming releases)
  - **Functional Impact**: **Yes** for one-shot flows
  - **Brand Impact**: Medium (dev experience + regression risk)
- **Technical Classification**
  - **Issue Category**: Bug
  - **Component Affected**: Core Framework / Model Integration (provider routing/selection)
  - **Complexity**: Moderate effort
- **Resource Requirements**
  - **Required Expertise**: Provider abstraction, configuration resolution, runtime defaults
  - **Dependencies**: Might depend on recent provider-handling refactors
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Add a failing unit test for one-shot with explicit provider + default provider.
  2. Validate env/config precedence rules (CLI args vs config file vs defaults).
  3. Patch and backport if release is imminent.
- **Potential Assignees**
  - **Odilitime** (raised monorepo stability concerns)
  - **Core runtime maintainer** (provider pipeline owner)

---

### 7) Missing/insufficient integration tests causing recurring monorepo breakages (v1x vs 2x stability)
- **Issue Title & ID**: Add integration test coverage to prevent recurring version breakages (DISC-2026-01-30-QA-01)
- **Current Status**: Acknowledged; Stan building a test framework pattern via plugin-n8n-workflow.
- **Impact Assessment**
  - **User Impact**: High (frequent breakages affect many builders)
  - **Functional Impact**: Partial (not one specific feature, but release reliability)
  - **Brand Impact**: High (perception of “half-completed” / unstable releases)
- **Technical Classification**
  - **Issue Category**: Quality / Reliability (fits under Bug-prevention; closest: Performance/UX for devs)
  - **Component Affected**: Core Framework + Plugin System + CI
  - **Complexity**: Architectural change (test strategy + fixtures + CI gating)
- **Resource Requirements**
  - **Required Expertise**: CI engineering, test harness design, plugin contract testing
  - **Dependencies**: Decide “golden paths” to test (create project, run agent, execute plugin, provider selection)
  - **Estimated Effort**: **5/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Adopt Stan’s plugin-n8n-workflow approach as a standard template.
  2. Define 5–8 “release gates” (create project, run one-shot, run multi-step action callback ordering, install key plugins).
  3. Add a nightly matrix across Node versions + package managers (npm/pnpm/bun if supported).
  4. Require green integration suite for merges to release branches.
- **Potential Assignees**
  - **Stan ⚡** (already implementing patterns)
  - **Odilitime** (owns stability priority)
  - **CI/DevOps maintainer** for the monorepo

---

### 8) `@elizaos/plugin-web-search` install/runtime “Cannot find module” due to module resolution
- **Issue Title & ID**: plugin-web-search module resolution failure after install (DISC-2026-01-29-PLUGINS-01)
- **Current Status**: Workaround suggested (edit package.json, try bun); needs real fix.
- **Impact Assessment**
  - **User Impact**: Medium–High (popular capability; breaks onboarding workflows)
  - **Functional Impact**: Partial (plugin-specific, but common)
  - **Brand Impact**: Medium (DX friction)
- **Technical Classification**
  - **Issue Category**: Bug / Documentation
  - **Component Affected**: Plugin System / Packaging (exports, entry points)
  - **Complexity**: Simple fix to Moderate (depends on root cause)
- **Resource Requirements**
  - **Required Expertise**: Node package exports, TS build outputs, bundler compatibility
  - **Dependencies**: Might depend on scoped CLI/package conventions
  - **Estimated Effort**: **2/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Reproduce on clean project generated by latest CLI.
  2. Fix package `exports`/`main`/`types` fields and publish patch release.
  3. Update docs to remove “edit package.json” workaround once fixed.
- **Potential Assignees**
  - **Odilitime** (already advising users; can drive fix)
  - **Plugin maintainer** for web-search

---

### 9) ElizaCloud CLI requires browser-based auth; request for API-token-only login
- **Issue Title & ID**: Add CLI login via API token (no browser flow) (DISC-2026-01-31-CODERS-03)
- **Current Status**: Requested; unanswered; likely missing feature.
- **Impact Assessment**
  - **User Impact**: Medium (power users, CI automation, headless servers)
  - **Functional Impact**: Partial (workarounds exist but painful)
  - **Brand Impact**: Medium (developer ergonomics)
- **Technical Classification**
  - **Issue Category**: Feature Request / UX
  - **Component Affected**: CLI + Auth API
  - **Complexity**: Moderate effort
- **Resource Requirements**
  - **Required Expertise**: Auth flows, token issuance/scopes, secure local storage, CLI UX
  - **Dependencies**: Requires token management endpoints and docs
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Define token types/scopes (read-only vs agent-control) and rotation/revocation.
  2. Implement `eliza login --token $TOKEN` storing in OS keychain or encrypted config.
  3. Update docs + add CI example for headless deployments.
- **Potential Assignees**
  - **DorianD** (clear user need; can validate in headless OpenClaw integration)
  - **ElizaCloud auth/API maintainer**
  - **CLI maintainer**

---

### 10) Babylon deployment into TEE + parallel workstream recommendation (avoid locking iteration)
- **Issue Title & ID**: Babylon TEE deployment plan (parallelize engine dev + TEE integration) (DISC-2026-01-31-CORE-01)
- **Current Status**: Strategic decision in progress; needs execution plan and ownership.
- **Impact Assessment**
  - **User Impact**: Medium (not an immediate crash, but key to near-term adoption)
  - **Functional Impact**: No (new capability), but time-sensitive to market window
  - **Brand Impact**: High (public momentum + perception of shipping)
- **Technical Classification**
  - **Issue Category**: Feature / Architectural change
  - **Component Affected**: TEE deployment pipeline, game/agent runtime, infra
  - **Complexity**: Architectural change
- **Resource Requirements**
  - **Required Expertise**: TEE/Phala deployment, secure enclaves, remote attestation, CI/CD, game runtime
  - **Dependencies**: Coordination with Phala team; definition of minimal viable TEE scope
  - **Estimated Effort**: **5/5**
- **Recommended Priority**: **P1** (time-sensitive strategic delivery)
- **Specific Actionable Next Steps**
  1. Lock the “minimum TEE slice” (what must run inside enclave vs outside).
  2. Start parallel tracks: (A) iterate engine outside TEE, (B) build TEE wrappers + deployment automation.
  3. Set weekly integration checkpoints and a “switch-over” criteria checklist.
  4. Create a public milestone plan to reduce community uncertainty.
- **Potential Assignees**
  - **Agent Joshua ₱ | TEE** (offered help; TEE focus)
  - **puncar** (proposed parallel approach)
  - **s** (driving prioritization and Phala coordination)

---

## Highest-Priority Summary (Top 5–10 to address immediately)
1. **P0** — ElizaCloud MCP crash: `isomorphic-dompurify` ESM/CJS incompatibility (DISC-2026-01-31-CODERS-01)  
2. **P0** — A2A `message/send` failing due to `contentModerationService` error (DISC-2026-01-31-CODERS-02)  
3. **P0** — Core callback ordering bug in Eliza v1.7.2 (DISC-2026-01-29-CODERS-01)  
4. **P0** — Migration portal “0 eligible” + 429 rate limiting + poor diagnostics (DISC-2026-01-30-MIGRATE-01)  
5. **P0** — Active migration scams; require stronger official-policy surfacing and anti-scam UX (DISC-2026-01-31-SEC-01)  
6. **P1** — `develop` one-shot provider selection regression (DISC-2026-01-30-DEV-01)  
7. **P1** — Integration test strategy to stop recurring monorepo breakages (DISC-2026-01-30-QA-01)  
8. **P1** — Babylon TEE deployment parallelization plan and execution (DISC-2026-01-31-CORE-01)  
9. **P2** — plugin-web-search module resolution/install failure (DISC-2026-01-29-PLUGINS-01)  
10. **P2** — CLI token-only login for headless usage (DISC-2026-01-31-CODERS-03)

---

## Patterns / Themes Suggesting Deeper Issues
- **Release reliability gaps**: Multiple reports point to regressions and “breakage cycles” (callback ordering, provider selection, plugin install failures), indicating insufficient end-to-end test coverage and weak regression gates.
- **Packaging and runtime boundary problems**: ESM/CJS incompatibilities and module resolution errors suggest inconsistent build targets across repos (core, plugins, cloud).
- **Operational maturity and trust deficits**: Migration failures + active scams + “unfit beta” feedback compound into a single trust problem; even small bugs become reputationally expensive without strong guardrails and clear comms.
- **Cloud/API hard-failure behavior**: A2A endpoint appears to fail closed (moderation service error breaks send). Beta systems should degrade gracefully to preserve core flows.

---

## Process Improvement Recommendations
1. **Establish “Golden Path” CI gates** (must pass before release/merge): create project, install common plugins, one-shot run, multi-step action with ordered callbacks, basic A2A send in staging.
2. **Standardize packaging rules across org**: single decision on ESM vs CJS per runtime target; enforce via lint/CI checks on `package.json` exports and build outputs.
3. **Add beta-safe degradation** in Cloud endpoints: moderation and optional services should not hard-stop core messaging; implement feature flags and fallback paths.
4. **Security-by-UX for support**: embed anti-scam warnings in the exact failure moments (migration eligibility errors, ticket creation confirmation), not only in Discord pins.
5. **Improve incident feedback loops**: require each P0 to include (a) reproducible steps, (b) owner, (c) ETA, (d) public status update location to reduce speculation and repeated support load.