# Issue Triage — 2026-02-03

## P0 / P1 Issues (Immediate / This Sprint)

### 1) Skills not invoked reliably (56% of eval cases never trigger skills)
- **Issue Title & ID:** Skill invocation reliability regression — *DISCORD-core-devs-2026-02-02-skill-invocation-56pct*
- **Current Status:** Known issue; workaround exists (mandatory activation sequence via `UserPromptSubmit` hook); not yet standardized in core.
- **Impact Assessment:**
  - **User Impact:** **Critical** (affects most users relying on skills/tools)
  - **Functional Impact:** **Yes** (blocks core “agent uses tools/skills” functionality)
  - **Brand Impact:** **High** (agents appear “dumb”/unreliable even with docs)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** Core Framework (tool/skill routing), Prompting layer, Evaluation harness
  - **Complexity:** **Architectural change** (may require planner/tool selection changes + doc format conventions)
- **Resource Requirements:**
  - **Required Expertise:** LLM tool-calling behavior, prompt engineering, framework routing, eval design
  - **Dependencies:** Clear skill schema + descriptions; alignment with `AGENTS.md`/docs strategy; possible Cloud vs OSS parity
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Reproduce & measure**: add a deterministic eval suite covering “skill should trigger” vs “should not trigger” cases; record invocation rate by model.
  2. **Productize workaround**: provide an optional built-in policy (`force_skill_activation=true`) that implements the 3-step sequence without making conversations “weird” (e.g., hidden chain or structured internal step).
  3. **Triage root causes**: inspect skill metadata, descriptions, and selection heuristics; compare outcomes for Skills vs `AGENTS.md` flows.
  4. **Documentation standard**: publish a canonical skill description template + examples; validate against top failing skills.
  5. **Ship guardrails**: ensure the agent must explicitly decide “use tool now” before generating a final answer when a matching skill exists.
- **Potential Assignees:** **R0am** (workaround author), **Stan** (Cloud pattern), **0xbbjoker** (framework/tooling), **Odilitime** (docs/standards)

---

### 2) ElizaCloud MCP/OpenClaw integration failing: `isomorphic-dompurify` CommonJS/ESM load error
- **Issue Title & ID:** Cloud MCP endpoint fails due to CJS/ESM incompatibility (`isomorphic-dompurify`) — *DISCORD-2026-01-31-mcp-dompurify-esm*
- **Current Status:** Reported; not confirmed fixed; blocks agent connection despite “auth success.”
- **Impact Assessment:**
  - **User Impact:** **High** (anyone integrating OpenClaw/MCP into Cloud path)
  - **Functional Impact:** **Yes** (breaks core integration path)
  - **Brand Impact:** **High** (Cloud feels unstable / “unfit beta” feedback)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Cloud deployment/runtime bundling, MCP app, dependency loading
  - **Complexity:** **Moderate effort** (build config + dependency resolution)
- **Resource Requirements:**
  - **Required Expertise:** Node/Next bundling, ESM/CJS interop, serverless runtime debugging
  - **Dependencies:** Cloud build pipeline; dependency versions
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Capture exact stack traces + runtime environment (Node version, bundler, serverless target).
  2. Patch via one of: dependency upgrade/downgrade, conditional import, or bundler config to transpile the module.
  3. Add a CI smoke test for the MCP endpoint to prevent recurrence (imports + minimal request).
  4. Publish a Cloud status note + workaround (if any) for integrators.
- **Potential Assignees:** **0xbbjoker** (runtime/plugin-mcp experience), **Stan** (Cloud), **DorianD** (reporting/verification)

---

### 3) A2A `message/send` failing: `contentModerationService` function error
- **Issue Title & ID:** A2A `message/send` breaks due to `contentModerationService` error — *DISCORD-2026-01-31-a2a-contentmoderationservice*
- **Current Status:** Reported; no fix confirmed.
- **Impact Assessment:**
  - **User Impact:** **High** (A2A is a core protocol path for agent-to-agent / app messaging)
  - **Functional Impact:** **Yes** (message send endpoint failing)
  - **Brand Impact:** **High** (API reliability concerns)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** Cloud API (A2A), moderation middleware/service wiring
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** API debugging, service wiring/DI, observability/logging
  - **Dependencies:** Moderation provider config; environment secrets; deployment parity between envs
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add structured logs around moderation invocation (inputs/outputs, failure modes).
  2. Ensure the moderation service is optional/fails open in non-production or for allowed tenants (with clear policy).
  3. Add contract tests for `message/send` with moderation enabled/disabled.
- **Potential Assignees:** **Stan**, **0xbbjoker**, **DorianD** (verify)

---

### 4) ElizaCloud account duplication / agent disappears when using Proton email variants
- **Issue Title & ID:** Duplicate account / missing agent when logging in with `@proton.me` vs `@protonmail.com` — *DISCORD-coders-2026-02-02-proton-alias-dup-account*
- **Current Status:** Unresolved; user cannot see agent on dashboard; suspected duplicate identity records.
- **Impact Assessment:**
  - **User Impact:** **High** (affects any user with email aliases/normalization differences)
  - **Functional Impact:** **Partial** (core usage blocked for affected accounts)
  - **Brand Impact:** **High** (trust-impacting: “my agent disappeared”)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Cloud Auth, Identity linking, Dashboard tenancy
  - **Complexity:** **Complex solution** (account linking + safe merge + audit trail)
- **Resource Requirements:**
  - **Required Expertise:** Auth/identity, database migrations, customer support tooling
  - **Dependencies:** Email normalization rules; login provider behavior; safe merge flow
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Implement **email normalization** (case-folding + provider-specific alias handling) at identity creation.
  2. Add an **account linking/merge** admin tool: merge agents/projects/resources with explicit confirmation + logs.
  3. Add dashboard banner/help: “Used a different email alias? Recover your account.”
  4. Backfill: detect duplicate accounts by Proton alias heuristics + prompt affected users to merge.
- **Potential Assignees:** **Stan** (Cloud), **0xbbjoker** (backend), **Odilitime** (support workflow), **DorianD** (triage/validation)

---

### 5) ElizaCloud API key creation blocked without credit card (even with free credits); x402 disabled on free tier
- **Issue Title & ID:** Cannot create API keys without payment method; x402 disabled on free tier — *DISCORD-2026-02-01-cloud-api-keys-paywall*
- **Current Status:** Reported; blocking bot-based testing and developer onboarding.
- **Impact Assessment:**
  - **User Impact:** **High** (developer onboarding + automated testing)
  - **Functional Impact:** **Partial** (platform usable only after adding CC)
  - **Brand Impact:** **High** (perceived as hostile to builders / “not open”)
- **Technical Classification:**
  - **Issue Category:** UX / Platform
  - **Component Affected:** Cloud Billing, API Key service, Payments (x402)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Billing systems, entitlements, API key management, fraud controls
  - **Dependencies:** Risk limits/abuse prevention; free-tier policy decisions; x402 enablement
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Allow **limited API key issuance** on free tier (rate-limited + capped credits).
  2. Re-enable **x402 top-ups** for free-tier/dev-tier (with safeguards).
  3. Add clear UI messaging: why payment is required (if still required) + alternatives.
  4. Add automated tests for “free credits user can create API key.”
- **Potential Assignees:** **Stan** (Cloud/Billing), **borisudovicic** (product policy), **0xbbjoker** (backend)

---

## P2 Issues (Near-Term Planning)

### 6) ElizaCloud image generation lacks visual consistency across iterations (character identity not preserved)
- **Issue Title & ID:** Visual consistency / iterative edit workflow missing (LoRA suggested) — *DISCORD-coders-2026-02-02-image-consistency*
- **Current Status:** Known limitation; suggestion to build as app/integration; no committed plan.
- **Impact Assessment:**
  - **User Impact:** **Medium** (high for storytellers/brand users; lower for general users)
  - **Functional Impact:** **No** (not core framework; impacts a key Cloud use case)
  - **Brand Impact:** **Medium** (hurts “creative studio” positioning)
- **Technical Classification:**
  - **Issue Category:** Feature Request / UX
  - **Component Affected:** Model Integration (image), Cloud product layer
  - **Complexity:** **Complex solution** (identity embeddings, LoRA training pipeline, asset management, UI workflow)
- **Resource Requirements:**
  - **Required Expertise:** GenAI image pipelines, LoRA training/serving, storage/versioning, UI
  - **Dependencies:** Choice of base image model(s), LoRA infra cost, privacy policy for user assets
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define MVP: “character pack” creation (upload 10–20 refs → train LoRA → reuse token).
  2. Prototype as third-party/agent-built app (as suggested) with a reference implementation.
  3. Add an “edit with locked identity” mode using seeds + face/identity adapters where available.
- **Potential Assignees:** **DorianD** (product direction), **Stan** (Cloud), community app builders (agent/app ecosystem)

---

### 7) Token migration bridge not detecting pre-Nov 2025 holdings + “Max amount reached” migration error
- **Issue Title & ID:** Migration portal/bridge failures (detection + limits) — *DISCORD-discussion-2026-02-02-migration-bridge-errors*
- **Current Status:** Active user reports; redirected to support; deadline pressure noted (Feb 3).
- **Impact Assessment:**
  - **User Impact:** **Critical** (users may permanently lose tokens; high volume)
  - **Functional Impact:** **Partial** (not core framework, but critical ecosystem operation)
  - **Brand Impact:** **High** (trust + reputational damage)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (Operations)
  - **Component Affected:** Migration portal, bridge indexing, rate/limit enforcement
  - **Complexity:** **Moderate effort** (depends on underlying bridge/indexer)
- **Resource Requirements:**
  - **Required Expertise:** Solana token indexing, bridge backend, support ops
  - **Dependencies:** Indexer correctness, RPC reliability, migration rules/limits
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1** (time-sensitive due to deadline)
- **Specific Actionable Next Steps:**
  1. Publish a **live status page** + known issues list for migration portal.
  2. Add diagnostics UI: “what tokens we see” with mint + accounts + snapshot height.
  3. Investigate “Max amount reached” rule; clarify whether it’s per-wallet/per-day/per-tx; adjust if incorrect.
  4. Create a fast-path manual support workflow for affected wallets before cutoff.
- **Potential Assignees:** **Odilitime** (ops coordination), **Borko** (support routing), core infra engineer(s) handling bridge/indexer

---

### 8) Hyperliquid plugin reliability / compatibility uncertainty
- **Issue Title & ID:** Hyperliquid plugin may be broken/unreliable — *DISCORD-discussion-2026-02-02-hyperliquid-plugin*
- **Current Status:** Unclear; one user self-worked around by coding their own solution; no root-cause tracked.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (depends on plugin adoption)
  - **Functional Impact:** **Partial** (plugin-specific)
  - **Brand Impact:** **Medium** (plugin ecosystem trust)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Plugin System / Specific integration plugin
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Plugin API, Hyperliquid API specifics, integration tests
  - **Dependencies:** Plugin maintainer availability; API changes upstream
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a minimal reproducible test case and confirm current breakage.
  2. Verify authentication, endpoints, and rate limits; update docs.
  3. Add CI integration tests (mocked) for the plugin.
- **Potential Assignees:** Plugin maintainer/community; **0xbbjoker** (plugin infra), **GraV** (if willing to upstream their fix)

---

## P3 / P4 Issues (Backlog / Future)

### 9) Improve skill descriptions + adopt `AGENTS.md`-style documentation where it outperforms skills
- **Issue Title & ID:** Standardize `AGENTS.md` + skill description quality improvements — *DISCORD-core-devs-2026-02-02-agentsmd-vs-skills*
- **Current Status:** Evidence shared (agents.md 100% on Next.js eval vs skills up to 79%); not yet operationalized.
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **Partial** (affects reliability/quality)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Documentation / UX / Reliability
  - **Component Affected:** Docs, Skill registry conventions, evaluation harness
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Documentation design, evaluation, developer experience
  - **Dependencies:** Alignment with the P0 skill-invocation fix
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P3** (but should ride along with the P0 reliability effort)
- **Specific Actionable Next Steps:**
  1. Create an `AGENTS.md` template and migrate 3–5 top skills to validate improvement.
  2. Add linting/CI checks for required sections (capabilities, when to call, examples).
- **Potential Assignees:** **Stan**, **Odilitime**, **R0am**

---

### 10) [Agent] Eliza Character File & Prompt Engineering
- **Issue Title & ID:** [Agent] Eliza Character File & Prompt Engineering — **elizaos/eliza #6447**
- **Current Status:** **Open**
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **No** (quality/behavior improvement)
  - **Brand Impact:** **Medium** (public-facing agent persona)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** Agent configuration (character file), model settings
  - **Complexity:** **Moderate effort** (iterative prompting + testing)
- **Resource Requirements:**
  - **Required Expertise:** Prompt engineering, conversational QA, model cost/perf tradeoffs
  - **Dependencies:** Planned PRs for message examples + model switch (to Sonnet)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Collect failure examples from real chats; categorize (tone, refusals, tool usage, hallucinations).
  2. Land message example PRs; run A/B tests with Sonnet vs current model.
  3. Add regression tests for persona constraints and “must-use-skills” behaviors.
- **Potential Assignees:** **borisudovicic** (issue owner), **Ben** (PRs mentioned), **Stan** (model choice guidance)

---

### 11) Billing (empty issue shell)
- **Issue Title & ID:** Billing — **elizaos/eliza #6448**
- **Current Status:** **Open** (no description yet)
- **Impact Assessment:** Insufficient data; likely important given Cloud friction reports.
  - **User Impact:** **Unknown** (tentatively Medium–High)
  - **Functional Impact:** **Partial**
  - **Brand Impact:** **High** (billing friction directly affects trust/conversion)
- **Technical Classification:**
  - **Issue Category:** UX / Platform
  - **Component Affected:** Billing
  - **Complexity:** **Unknown**
- **Resource Requirements:**
  - **Required Expertise:** Billing/payments, entitlement design
  - **Dependencies:** Needs scope definition
  - **Estimated Effort (1–5):** **1** (to clarify) + re-estimate after details
- **Recommended Priority:** **P2 (definition required)**  
- **Specific Actionable Next Steps:**
  1. Update issue with concrete problem statement(s): API key paywall, x402, invoicing, usage limits, etc.
  2. Break into actionable sub-issues with acceptance criteria.
- **Potential Assignees:** **borisudovicic** (triage), **Stan** (Cloud billing), **DorianD** (reporter of billing friction)

---

## Summary: Top Highest-Priority Items to Address Now (5–10)
1. **P0:** Skill invocation reliability (56% non-trigger rate) — standardize fix + root-cause analysis.
2. **P0:** ElizaCloud MCP failing due to `isomorphic-dompurify` ESM/CJS issue.
3. **P0:** A2A `message/send` failing due to `contentModerationService` error.
4. **P0:** Cloud account duplication / missing agents due to Proton email aliasing.
5. **P1:** Cloud developer onboarding blocked by **API keys requiring credit card**; x402 disabled on free tier.
6. **P1:** Migration portal issues (bridge not detecting tokens; “Max amount reached”) given deadline urgency.
7. **P2:** Image generation iteration/visual consistency (LoRA/identity workflow).
8. **P2:** Hyperliquid plugin reliability confirmation + fix (if still broken).
9. **P2:** Eliza character file + prompt engineering improvements (#6447).
10. **P2:** Define scope for Billing issue shell (#6448).

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Tool/skill execution is not a guaranteed path**: The framework currently allows “answering without acting,” producing major reliability failures when skills/tools are expected.
- **Cloud runtime fragility**: Multiple integration-breaking issues (ESM/CJS module loading, moderation service hard-fail) indicate insufficient end-to-end smoke tests and runtime parity checks.
- **Identity & entitlement coupling**: Account duplication and billing gating (API keys blocked without CC) point to brittle identity/entitlement design that can lock users out or fragment resources.
- **“Beta quality” perception**: Repeated reports of Cloud instability and friction compound into brand risk; reliability and onboarding must be treated as core product features.

---

## Process Improvements (Prevent Recurrence)
1. **Introduce release-gating smoke tests for Cloud**: minimal tests for MCP endpoint import/load, A2A send flow, and dashboard resource listing per user.
2. **Add a “tool invocation contract”** in core: when a skill matches strongly, the agent must either call it or explicitly justify why not (logged/observable).
3. **Standardize skill documentation format**: adopt an `AGENTS.md`-like template with required “When to call / Examples / Constraints,” plus CI linting.
4. **Identity normalization & merge tooling**: enforce canonical email normalization + admin-assisted account merge with audit logs.
5. **Developer onboarding SLOs**: track time-to-first-success (create account → create API key → run agent) and treat regressions as P0/P1.