## Issue Triage — 2026-03-22

### 1) Eliza Cloud deploy fails: `Cannot find module '@elizaos/plugin-discord'` (Discord report, 2026-03-19; CLI v1.7.2)
- **Current Status:** Unresolved; reproducible in at least one user deployment; suspected missing package folder in container/build context.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks anyone trying to deploy with Discord integration on ElizaCloud)
  - **Functional Impact:** **Yes** (deployment fails; core “agent runs in cloud” path blocked)
  - **Brand Impact:** **High** (looks like a broken official plugin / broken platform)
- **Technical Classification:**
  - **Issue Category:** Bug / Platform Reliability
  - **Component Affected:** ElizaCloud deployment pipeline, Plugin System packaging/bundling
  - **Complexity:** Moderate effort (could be config/packaging regression, monorepo workspace resolution, or build image contents)
- **Resource Requirements:**
  - **Required Expertise:** Node/TS monorepo packaging, Docker build pipelines, workspace dependency resolution (pnpm/yarn/npm), ElizaCloud build/runtime
  - **Dependencies:** May depend on how ElizaCloud builds images (what gets copied) and how plugins are declared/installed
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce with a minimal agent config enabling Discord plugin on ElizaCloud (pin CLI 1.7.2 and latest).
  2. Inspect built image: confirm whether `node_modules/@elizaos/plugin-discord` exists and whether `packages/plugin-discord` is included in build context.
  3. Validate plugin dependency declaration (is it a dependency/devDependency/optional?) in the agent template used by ElizaCloud.
  4. Add CI check in ElizaCloud build to assert presence of selected plugins before launch; fail early with actionable message.
  5. Publish a short workaround (CLI flags or “install plugin” step) until fixed.
- **Potential Assignees:**
  - **pmairca** (Core Dev; likely strongest for monorepo/plugin packaging)
  - **shawmakesmagic** (Core Dev; framework/tooling)
  - **jin** (reporter; can assist with reproduction/verification)
  - **odilitime** (platform coordination; can shepherd triage + user comms)

---

### 2) Eliza Cloud GUI lacks “reload/restart container” mechanism after failed deploy (Discord report, 2026-03-19)
- **Current Status:** Unresolved; user reports being stuck after failure with no GUI-based recovery path.
- **Impact Assessment:**
  - **User Impact:** Medium → **High** (common operational need; increases support load)
  - **Functional Impact:** **Partial** (platform may work, but recovery is painful and blocks progress)
  - **Brand Impact:** **High** (cloud UX feels incomplete/unreliable)
- **Technical Classification:**
  - **Issue Category:** UX / Platform Reliability
  - **Component Affected:** ElizaCloud GUI + backend orchestration controls
  - **Complexity:** Moderate effort (requires safe restart semantics + UI wiring)
- **Resource Requirements:**
  - **Required Expertise:** Web UI, cloud orchestration (containers), API design
  - **Dependencies:** Depends on ElizaCloud backend capability to restart/replace containers
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define minimal controls: Restart, Rebuild, View logs, Rollback to last successful image.
  2. Implement backend endpoints + permission checks.
  3. Add UI controls with clear warnings and progress states.
  4. Add post-failure callout: “Deploy failed — Restart / Rebuild” with suggested next actions.
- **Potential Assignees:**
  - **odilitime** (platform owner/ops coordination)
  - **pmairca** (backend/platform support)
  - **jin** (product feedback + acceptance testing)

---

### 3) Disk image upload succeeds client-side but never arrives server-side (ElizaCloud) (Discord report, 2026-03-20)
- **Current Status:** Under investigation; server reports receiving nothing despite client upload attempt; stack noted as “elizaos 1.x CLI + elizacloud”.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks a key deployment artifact path)
  - **Functional Impact:** **Yes** (prevents completing cloud workflows requiring images)
  - **Brand Impact:** **High** (data loss / “upload doesn’t work” is a severe trust breaker)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** CLI upload client, ElizaCloud upload API, storage layer (S3/GCS/etc), networking/proxy
  - **Complexity:** Complex solution (could be multipart upload, auth, proxy limits, checksum mismatch, CORS, timeouts)
- **Resource Requirements:**
  - **Required Expertise:** Network debugging, HTTP multipart uploads, cloud storage, observability/logging
  - **Dependencies:** Requires server logs + request tracing; may require infra configuration changes
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add request IDs and end-to-end tracing for uploads (CLI prints ID; server logs correlate).
  2. Confirm server ingress limits (body size), proxy timeouts, and multipart settings.
  3. Capture a failing upload HAR/curl reproduction; test small vs large images.
  4. Add server-side “upload started/received bytes” logging and client-side progress + retry.
  5. Implement integrity verification (SHA256) and explicit “stored at” response.
- **Potential Assignees:**
  - **odilitime** (platform triage + infra coordination)
  - **pmairca** (core/platform engineering)
  - **jin** (repro steps + verification)

---

### 4) Milady release artifacts: GPG key + SHA256 checksum problems (milady-ai/milady, Discord report 2026-03-20)
- **Current Status:** Known; needs resolution before broader marketing/distribution; Milady beta announced “playable and running” on 2026-03-21 but release hygiene remains a risk.
- **Impact Assessment:**
  - **User Impact:** Medium (affects users downloading/verifying builds)
  - **Functional Impact:** **Partial** (app may run, but trust/installation flow degraded)
  - **Brand Impact:** **High** (signature/checksum issues look like supply-chain risk)
- **Technical Classification:**
  - **Issue Category:** Security / Release Engineering
  - **Component Affected:** Milady build & release pipeline (signing, checksum publishing)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, GPG signing, CI/CD (GitHub Actions), artifact hosting
  - **Dependencies:** Depends on how releases are packaged and distributed
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Standardize release process: deterministic build, generate SHA256, sign checksums, publish public key + verification instructions.
  2. Rotate/validate GPG key ownership and storage (avoid developer-local keys if possible).
  3. Add CI step that fails release if checksum/signature mismatches.
  4. Publish a “How to verify Milady download” doc.
- **Potential Assignees:**
  - **shawmakesmagic** (core dev; likely involved in product releases)
  - **pmairca** (tooling/release support)
  - **odilitime** (release coordination + comms)

---

### 5) Linux embedding failures in `@elizaos/plugin-ollama` (elizaos-plugins/plugin-ollama #17)
- **Current Status:** Investigating (per weekly summary); still open risk for local inference users on Linux.
- **Impact Assessment:**
  - **User Impact:** Medium (Linux users are a significant dev segment)
  - **Functional Impact:** **Partial** (core agent may run, but embeddings-based features degrade/fail)
  - **Brand Impact:** Medium (local model integration reliability)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Model Integration (Ollama plugin), embeddings pipeline
  - **Complexity:** Moderate effort (often environment/library/version specific)
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, Ollama API behavior, embeddings model configuration, node native deps (if any)
  - **Dependencies:** Needs reproducible environment matrix (distro, ollama version, model)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Collect environment details from reporters (distro, kernel, ollama version, model, plugin version).
  2. Add a minimal reproduction script + expected response validation.
  3. Run CI smoke tests on Ubuntu for embeddings endpoint.
  4. Implement clearer error messages and fallback behavior (disable embeddings features gracefully).
- **Potential Assignees:**
  - **pmairca** (core dev familiarity with integrations)
  - **community maintainer for plugin-ollama** (if identified in repo)
  - **sb** (technical contributor; can help with integration reasoning)

---

### 6) ElizaCloud build/deploy latency: Docker image build/upload “takes a while” with poor progress signaling (Discord report, 2026-03-19)
- **Current Status:** Ongoing pain point; not necessarily a bug, but harms perceived reliability and usability.
- **Impact Assessment:**
  - **User Impact:** Medium (all cloud deploy users)
  - **Functional Impact:** **Partial** (work eventually completes, but workflow friction)
  - **Brand Impact:** Medium (feels slow/unprofessional)
- **Technical Classification:**
  - **Issue Category:** Performance / UX
  - **Component Affected:** ElizaCloud build pipeline, CLI deploy UX
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Docker layering/caching, registry uploads, UX telemetry
  - **Dependencies:** May depend on artifact size, caching, and server-side build infra
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add explicit progress stages (build, compress, upload, register, start).
  2. Enable layer caching where possible; reduce image size (multi-stage builds).
  3. Document expected deploy times and common bottlenecks.
- **Potential Assignees:**
  - **odilitime** (platform)
  - **pmairca** (build tooling)

---

### 7) Documentation gap: migration + “old token vs new token” confusion for newcomers (Discord report, 2026-03-19)
- **Current Status:** Unaddressed; community reports confusion and poor discoverability.
- **Impact Assessment:**
  - **User Impact:** **High** (new users/investors repeatedly impacted)
  - **Functional Impact:** **No** (not a runtime blocker)
  - **Brand Impact:** **High** (trust/credibility issue; “poor migration execution” narrative)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs site, pinned Discord resources, GitHub READMEs
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, release/migration knowledge
  - **Dependencies:** Needs canonical answers from core team (what to do, what not to do)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a single canonical “Migration & Token Contract FAQ” page; pin it in Discord + link from docs homepage.
  2. Add a “If you hold X, do Y” flowchart and scam-prevention guidance.
  3. Keep it updated with an “as-of date” and owner.
- **Potential Assignees:**
  - **odilitime** (community ops; owns messaging)
  - **encumbered_304** (Announcements/helper; doc distribution)
  - **sb** (technical validation)

---

### 8) Documentation gap: ecosystem architecture confusion (ElizaOS vs Milady vs OpenClaw) (Discord report, 2026-03-21)
- **Current Status:** Clarified ad-hoc in coders channel; not yet captured in durable docs.
- **Impact Assessment:**
  - **User Impact:** Medium (builders evaluating platform choices)
  - **Functional Impact:** **No**
  - **Brand Impact:** Medium (confusion suggests lack of clear product story)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Docs / ecosystem diagrams
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Architecture communication, diagramming
  - **Dependencies:** Needs authoritative confirmation from core maintainers
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish an “Ecosystem Architecture” doc page with a diagram: ElizaOS (foundation) → Milady (product layer) → OpenClaw (compatible agents).
  2. Add a “When should I use X?” section.
  3. Pin in Discord and link from README(s).
- **Potential Assignees:**
  - **sb** (already providing clarification)
  - **odilitime** (distribution + narrative)
  - **gby_17 / magicyte** (design/diagram support)

---

### 9) Registry contribution pipeline: Moltraffle plugin needs PR to `elizaos-plugins/registry` (Community action item, 2026-03-19)
- **Current Status:** Not yet submitted/merged (per discussion).
- **Impact Assessment:**
  - **User Impact:** Low → Medium (users who want raffle/on-chain plugin)
  - **Functional Impact:** **No**
  - **Brand Impact:** Low (but helps ecosystem growth)
- **Technical Classification:**
  - **Issue Category:** Feature / Ecosystem
  - **Component Affected:** Plugin Registry
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Registry submission process, plugin packaging metadata
  - **Dependencies:** Plugin author readiness; registry checks
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Ensure plugin repo meets registry requirements (README, versioning, package name, license).
  2. Submit PR; run automated checks; assign a reviewer.
- **Potential Assignees:**
  - **Stan ⚡** (guided process)
  - **registry maintainers** (review/merge)
  - **Moltraffle** (author)

---

## Highest-Priority Focus (Top 5–10 to act on now)
1. **P0:** ElizaCloud deploy fails with `@elizaos/plugin-discord` missing (blocks cloud deployments with Discord).
2. **P0:** Disk image upload not reaching server (blocks key cloud workflows; high trust risk).
3. **P1:** Add GUI restart/rebuild controls for failed containers (reduces “stuck” states and support burden).
4. **P1:** Milady release signing/checksum (GPG/SHA256) reliability (supply-chain trust + release readiness).
5. **P1:** Migration documentation to reduce recurring confusion and reputational damage.
6. **P2:** plugin-ollama Linux embeddings failures (#17) (important dev-platform compatibility).
7. **P2:** ElizaCloud deploy performance/progress transparency.
8. **P2:** Ecosystem architecture documentation (ElizaOS vs Milady vs OpenClaw).
9. **P3:** Moltraffle registry PR (ecosystem growth, low risk).

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Cloud packaging & plugin resolution fragility:** The Discord plugin module-missing error strongly suggests the build pipeline is not reliably translating “selected plugins” into runtime dependencies, indicating a systemic gap in **dependency declaration, workspace packaging, or image build context**.
- **Operational maturity gaps in ElizaCloud:** Missing restart controls, unclear deploy progress, and unreliable uploads point to insufficient **platform observability, lifecycle management, and UX affordances** for recovery.
- **Release engineering trust issues:** Milady checksum/signing problems indicate the release pipeline may not yet be standardized, creating **supply-chain and credibility risk**.
- **Documentation debt amplifying community friction:** Repeated confusion (migration + architecture) shows critical knowledge is trapped in chat, not in canonical docs.

---

## Process Improvement Recommendations
1. **Introduce a “Cloud Deploy Smoke Test” CI gate:** Nightly (or per release) deploy a minimal agent with the top 3 plugins (e.g., Discord + one model provider + one tool) to catch missing-module and packaging regressions early.
2. **Add end-to-end observability for uploads and deploys:** Request IDs, correlated logs, and user-visible status timelines; make “what happened?” diagnosable without manual staff intervention.
3. **Standardize release engineering:** One documented, automated pipeline for checksums + signing + verification docs; block releases if integrity checks fail.
4. **Create canonical docs from recurring Discord questions:** A lightweight weekly cadence: pick top 3 repeated questions → publish/update a doc page → pin/link in Discord.
5. **Define ownership for critical docs and platform UX:** Assign explicit maintainers (with review rotation) for migration docs, architecture docs, and ElizaCloud UX to prevent drift.