## Issue Triage — 2026-03-20 (elizaOS)

### 1) Eliza Cloud deploy fails: `Cannot find module '@elizaos/plugin-discord'` after GUI Discord plugin config (DISCORD-CLOUD-001)
- **Current Status:** Open / unresolved; reproducible reported on CLI v1.7.2 deploy; container ends up “stuck”
- **Impact Assessment:**
  - **User Impact:** **High** (blocks Discord agents on Cloud; affects common “hello world” deployment path)
  - **Functional Impact:** **Yes** (Discord integration is a core channel; deployment fails)
  - **Brand Impact:** **High** (Cloud perceived as broken/unreliable)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Eliza Cloud + Plugin System + Packaging/Build pipeline
  - **Complexity:** **Moderate effort** (could be dependency packaging, workspace resolution, image build step, or registry sync)
- **Resource Requirements:**
  - **Required Expertise:** Node/TypeScript monorepos, npm workspaces/pnpm, Docker image build pipelines, Cloud/ECS deployment
  - **Dependencies:** Need clarity on Cloud image build context (what packages are copied), how GUI toggles plugins, and how runtime resolves `@elizaos/*`
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Reproduce with a minimal Cloud project**: enable only Discord plugin via GUI; deploy via CLI; capture build logs + final container filesystem.
  2. In the built image/container, verify:
     - `node_modules/@elizaos/plugin-discord` existence
     - workspace install output (pnpm/npm/yarn lock + install mode)
     - whether `packages/plugin-discord` exists in build context (Odilitime suspicion)
  3. Confirm the Cloud builder is not excluding plugin packages (e.g., `.dockerignore`, selective copy, or “production install” pruning).
  4. Add **preflight validation**: when GUI enables Discord, verify dependency is present/installed before allowing deploy.
  5. Add an automated **Cloud canary** job for “Discord agent deploy” on each CLI/Cloud release.
- **Potential Assignees:** Odilitime (framework/plugins), Jin / dankvr (Cloud deploy), Cloud infra maintainer familiar with ECS image build

---

### 2) Eliza Cloud GUI lacks a “reload/restart container” control; deployments can become stuck (DISCORD-CLOUD-002)
- **Current Status:** Open; user explicitly asked for GUI-based reload mechanism; none available
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (any failed deploy becomes a support ticket / CLI-only recovery)
  - **Functional Impact:** **Partial** (workaround exists via CLI, but many users start in GUI)
  - **Brand Impact:** **High** (Cloud feels unfinished; increases frustration during failures)
- **Technical Classification:**
  - **Issue Category:** UX / Feature Request
  - **Component Affected:** Eliza Cloud GUI + Cloud API/Orchestration
  - **Complexity:** **Moderate effort** (UI + backend endpoint + permissions/audit)
- **Resource Requirements:**
  - **Required Expertise:** Cloud orchestration (ECS), backend API, frontend UI
  - **Dependencies:** Define restart semantics (task restart vs service redeploy), auth/role model
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Implement backend endpoint: `POST /containers/:id/restart` (or service/task equivalent).
  2. Add GUI controls: Restart, Stop, Redeploy last successful image.
  3. Provide status visibility: last deploy logs, current task state, “stuck” detection.
- **Potential Assignees:** Jin / dankvr (Cloud UX), Cloud infra maintainer

---

### 3) Cloud deploy UX: GUI deploy attempts fail → forced CLI; Docker image build step appears to “hang” with no progress feedback (DISCORD-CLOUD-003)
- **Current Status:** Open; users report GUI deploy failures and long image build/upload times
- **Impact Assessment:**
  - **User Impact:** **High** (onboarding friction; new users churn)
  - **Functional Impact:** **Partial** (CLI works but is not the intended path for many)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** UX / Performance (progress feedback) + Bug (GUI deploy failure)
  - **Component Affected:** Eliza Cloud GUI + Build pipeline
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Frontend, build system observability, Docker registry uploads
  - **Dependencies:** Identify why GUI deploy fails (API errors, auth, timeouts), add streaming logs/progress
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Capture GUI deploy failure telemetry: request IDs, response codes, timeouts.
  2. Add progress UI for build phases: build, compress, upload, deploy, health check.
  3. Document expected build time and provide “it’s still working” indicators.
- **Potential Assignees:** Jin / dankvr, Cloud frontend engineer

---

### 4) Plugin naming standardization may break existing installs (`plugin-form` / `plugin-forms` rename) (DISCORD-PLUGINS-004)
- **Current Status:** Recently changed; registry updated; downstream break risk not fully assessed
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects users depending on older package names)
  - **Functional Impact:** **Partial** (agents depending on old names may fail to load)
  - **Brand Impact:** **Medium** (perceived instability across releases)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** Plugin System + Registry
  - **Complexity:** **Simple fix → Moderate** (depends on approach: alias packages vs migration tooling)
- **Resource Requirements:**
  - **Required Expertise:** npm publishing, semver policy, registry maintenance
  - **Dependencies:** Need decision: provide transitional alias packages and/or deprecation warnings
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish **deprecated alias packages** (if feasible) that depend on the new canonical packages.
  2. Add migration note to docs + registry README: old → new mapping.
  3. Add runtime warning when old plugin identifiers are detected.
- **Potential Assignees:** Odilitime, Stan ⚡ (registry)

---

### 5) Discord role assignment Google Form: “Invalid Dynamic Link” error (DISCORD-COMM-005)
- **Current Status:** Open; blocks role assignment flow; indicates Firebase Dynamic Links misconfiguration (domain/URI parsing)
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects onboarding and community ops)
  - **Functional Impact:** **No** (doesn’t block core framework, but blocks community workflow)
  - **Brand Impact:** **Medium** (onboarding polish)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Community tooling / Discord automation
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Firebase Dynamic Links (or alternative), Discord role automation
  - **Dependencies:** Access to the Dynamic Links configuration + form redirect targets
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Validate Dynamic Links domain allowlist and link templates.
  2. Confirm the form’s redirect URL encoding and scheme.
  3. Add a fallback/manual verification route while fixed.
- **Potential Assignees:** Community ops maintainer, Jin (if owning feedback/onboarding systems)

---

### 6) Migration & chain support confusion: users can’t find authoritative info (Milady SOL vs BSC; old token confusion) (DISCORD-DOCS-006)
- **Current Status:** Open; repeatedly asked; migration execution criticized; “old token trading higher” confusion risk
- **Impact Assessment:**
  - **User Impact:** **High** (many community members/integrators affected)
  - **Functional Impact:** **Partial** (blocks correct integrations and user decisions)
  - **Brand Impact:** **High** (trust + perceived professionalism)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs site, migration guides, announcement channels
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, release/migration communications
  - **Dependencies:** Need a single source of truth from leadership/product about supported chains and migration status
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a pinned “Migration & Official Contracts / Chains” page (docs + Discord pin).
  2. Add FAQ: supported Milady chain(s), official token addresses, what to ignore, timelines.
  3. Add “Last updated” timestamps and change log.
- **Potential Assignees:** Stan ⚡ (docs/registry coordination), Odilitime (technical validation), designated comms owner

---

### 7) Moltraffle plugin needs registry inclusion + basic review (REGISTRY-PR-007)
- **Current Status:** Ready for PR submission; requested by Stan ⚡
- **Impact Assessment:**
  - **User Impact:** **Medium** (adds useful Web3 utility; not blocking)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (ecosystem momentum; demonstrates extensibility)
- **Technical Classification:**
  - **Issue Category:** Feature / Documentation
  - **Component Affected:** Plugin Registry
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Registry maintenance, security review (on-chain actions), plugin interface standards
  - **Dependencies:** PR submission; ensure actions and secrets handling comply with guidelines
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Moltraffle submits PR to `elizaos-plugins/registry` with metadata and usage docs.
  2. Run automated checks; add manual review focusing on transaction signing, parameter validation, and VRF assumptions.
  3. Provide example agent config snippet for quickstart.
- **Potential Assignees:** Stan ⚡ (registry), Odilitime (plugin API fit), Moltraffle (author)

---

### 8) “Token utility” gaps driving community crisis (DISCORD-PRODUCT-008)
- **Current Status:** Open-ended; strong community demand; buyback plan mentioned but timeline unknown
- **Impact Assessment:**
  - **User Impact:** **High** (community/investors; impacts willingness to build on platform)
  - **Functional Impact:** **No** (not a runtime blocker)
  - **Brand Impact:** **Critical** (trust erosion, retention risk, contribution decline)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Product
  - **Component Affected:** Product strategy (Eliza Cloud monetization loop, token-linked utilities if applicable)
  - **Complexity:** **Architectural change** (depends on what “utility” means: billing, staking, access control, rewards, etc.)
- **Resource Requirements:**
  - **Required Expertise:** Product leadership, tokenomics, legal/compliance awareness, payment/billing integration
  - **Dependencies:** Clear roadmap alignment with Cloud revenue model; partner coordination
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1** (due to brand/community impact)
- **Specific Actionable Next Steps:**
  1. Define 1–2 concrete utilities with measurable delivery dates (e.g., Cloud credits, plugin marketplace mechanics, usage-based perks).
  2. Publish a short RFC with scope, non-goals, and constraints.
  3. Establish a cadence of weekly updates (even if small) to reduce uncertainty.
- **Potential Assignees:** Product lead (Shaw), Odilitime (delivery feasibility), Jin (Cloud linkage)

---

## Top Highest-Priority Issues (Immediate Focus: next 1–2 weeks)
1. **P0:** (DISCORD-CLOUD-001) Cloud deploy fails due to missing `@elizaos/plugin-discord`
2. **P1:** (DISCORD-CLOUD-002) Add GUI restart/reload controls to recover from stuck containers
3. **P1:** (DISCORD-CLOUD-003) Fix/diagnose GUI deploy failures + add build/upload progress feedback
4. **P1:** (DISCORD-DOCS-006) Publish authoritative migration + supported chain info (reduce repeated confusion)
5. **P1:** (DISCORD-PRODUCT-008) Define and communicate concrete token-utility plan with deliverables
6. **P2:** (DISCORD-PLUGINS-004) Mitigate plugin rename breakage via alias packages + migration docs
7. **P2:** (DISCORD-COMM-005) Fix Google Form Dynamic Link role assignment issue
8. **P2:** (REGISTRY-PR-007) Review and merge Moltraffle plugin into registry

---

## Patterns / Themes Indicating Deeper Issues
- **Packaging & distribution fragility:** Cloud runtime/module resolution failures and plugin renames suggest insufficient guardrails around **monorepo/workspace dependency packaging** and **backwards compatibility**.
- **Cloud operational gaps:** Missing restart controls and weak deploy observability indicates the Cloud product lacks basic **day-2 operations UX** (recoverability, logs, health states).
- **Documentation as a system dependency:** Migration/chain ambiguity is repeatedly blocking users; docs and pinned “source of truth” are acting like a missing product feature.
- **Release/process coupling:** Plugin naming changes + Cloud deploy issues suggest changes are shipping without a comprehensive **end-to-end canary** (e.g., “deploy Discord agent via GUI” as a required release gate).

---

## Process Improvement Recommendations
1. **Add Cloud canary pipelines as release gates**
   - Required checks: GUI deploy, CLI deploy, Discord plugin enabled, module resolution verified, container health OK.
2. **Adopt a plugin compatibility policy**
   - Enforce semver, publish deprecation/alias packages for renames, and require migration notes in the registry.
3. **Improve Cloud observability and self-service recovery**
   - Streaming logs, build progress, restart/redeploy controls, and clear error explanations linked to docs.
4. **Create a single-source “Official Info” hub**
   - One docs page + Discord pinned message covering migration, supported chains, official addresses, and status updates.
5. **Weekly triage + comms cadence**
   - Convert recurring Discord questions into tracked issues; publish weekly changelog/roadmap deltas to reduce speculation and repeated support load.