## Issue Triage — 2026-03-21

### 1) Deployment fails: `Cannot find module '@elizaos/plugin-discord'`
- **Issue Title & ID:** Deployment fails due to missing `@elizaos/plugin-discord` module — **Triage ID: DISC-2026-03-19-PLUGDISC**
- **Current Status:** Unresolved; reproduced in Eliza Cloud deployment flow (GUI-configured Discord plugin). Suspected missing package in container image.
- **Impact Assessment:**
  - **User Impact:** **High** (anyone deploying agents with Discord integration)
  - **Functional Impact:** **Yes** (blocks deployment / runtime startup)
  - **Brand Impact:** **High** (core “it works” expectation for default integrations)
- **Technical Classification:**
  - **Issue Category:** Bug / Packaging
  - **Component Affected:** **Plugin System**, **ElizaCloud build pipeline**, **CLI image build**
  - **Complexity:** **Moderate effort** (depends on build/release wiring and registry/package layout)
- **Resource Requirements:**
  - **Required Expertise:** Node/TS monorepo packaging, workspace resolution (pnpm/yarn/npm), Docker build pipelines, ElizaCloud deploy templates
  - **Dependencies:** Confirm actual plugin name/package path after recent plugin naming changes; verify registry references; ensure container build installs the plugin
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Reproduce in a clean environment**: deploy minimal agent with Discord plugin enabled (GUI and CLI paths).
  2. Inspect built image: verify `node_modules/@elizaos/plugin-discord` exists; validate workspace hoisting behavior.
  3. Verify `package.json` dependencies for the runtime package that imports it (is it missing, devDependency-only, or excluded from lockfile?).
  4. Confirm ElizaCloud build uses the correct workspace install command and includes all `packages/*` artifacts.
  5. Add CI guard: fail build if configured plugins are not resolvable at runtime (smoke test import).
- **Potential Assignees:** **Odilitime** (cloud/deploy context), **jin** (reporter + reproduction), **Stan ⚡** (registry / plugin ecosystem), build/infra maintainer for ElizaCloud.

---

### 2) ElizaCloud disk image upload succeeds client-side but never reaches server
- **Issue Title & ID:** Disk image upload not received server-side — **Triage ID: DISC-2026-03-20-UPLOAD**
- **Current Status:** Investigating; server reports no image received despite upload attempt; stack = elizaOS 1.x CLI + ElizaCloud.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks a key deployment workflow if disk images are required/standard)
  - **Functional Impact:** **Partial → Yes** (blocks certain deploy paths; can halt releases if images are primary artifact)
  - **Brand Impact:** **High** (cloud reliability perception)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** **ElizaCloud API**, **CLI uploader**, storage backend (object store), auth/proxy layer
  - **Complexity:** **Complex solution** (could be networking, auth, chunking, timeouts, storage permissions, or size limits)
- **Resource Requirements:**
  - **Required Expertise:** Backend API + storage (S3/GCS), HTTP upload semantics (multipart/chunked), observability/logging, CLI networking
  - **Dependencies:** Need server logs + request IDs; clarify expected artifact size/type; confirm any CDN/proxy limits
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add/enable **request correlation IDs** from CLI through API gateway to storage.
  2. Capture **CLI verbose logs** + exact endpoint + headers; confirm auth token validity and scope.
  3. Check infra limits: **max body size**, **proxy timeouts**, **multipart handling**, **CORS**, **content-type validation**.
  4. Validate server-side: ensure upload handler actually writes to storage and returns persisted object key; add metrics for “received bytes” vs “stored bytes”.
  5. Create a small reproducible test artifact + run in CI against staging.
- **Potential Assignees:** **Odilitime** (investigating), ElizaCloud backend owner, **jin** (repro + logs).

---

### 3) No container reload/redeploy control in GUI when deployments get stuck
- **Issue Title & ID:** Missing “reload/restart container” mechanism in Eliza Cloud GUI — **Triage ID: DISC-2026-03-19-GUIRELOAD**
- **Current Status:** Requested; user reported container stuck after failure with no GUI-based recovery.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (any user hitting failed deploys)
  - **Functional Impact:** **Partial** (workarounds may exist via CLI/support, but blocks self-serve recovery)
  - **Brand Impact:** **Medium** (platform maturity and operability)
- **Technical Classification:**
  - **Issue Category:** UX / Reliability
  - **Component Affected:** **ElizaCloud GUI**, orchestration layer (restart policies), deployment management API
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Frontend + backend API design, container orchestration (restart/redeploy), permissions/audit logging
  - **Dependencies:** Requires stable deployment identifiers and safe restart semantics; consider rate-limiting and role-based access
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add GUI actions: **Restart**, **Rebuild**, **Rollback to last good image**, **View logs**.
  2. Implement backend endpoints with audit logs and safe-guards.
  3. Add “stuck deployment” detector (no healthcheck for N minutes) and suggest restart.
- **Potential Assignees:** ElizaCloud frontend maintainer, ElizaCloud backend owner, **jin** (user validation), **Odilitime** (triage).

---

### 4) Release integrity issues: GPG key and SHA256 checksum problems (Milady repo)
- **Issue Title & ID:** GPG signing / SHA256 checksum mismatch or missing for Milady releases — **Triage ID: DISC-2026-03-20-SIGNING**
- **Current Status:** Reported; needs resolution before broader distribution/marketing push.
- **Impact Assessment:**
  - **User Impact:** **Medium** now, **High** once distribution scales
  - **Functional Impact:** **Partial** (doesn’t necessarily break runtime, but breaks trusted installation and supply-chain confidence)
  - **Brand Impact:** **High** (release professionalism + security optics)
- **Technical Classification:**
  - **Issue Category:** Security / Release Engineering
  - **Component Affected:** **Milady app release pipeline**, artifact hosting, documentation
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** CI/CD release signing, GPG key management, checksums, GitHub Releases automation
  - **Dependencies:** Decide canonical signing identity; rotate/revoke if compromised; update install docs to verify signatures
  - **Estimated Effort (1–5):** **2–3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Identify exact failure mode: wrong checksum published vs artifact changed post-build vs missing `.asc` signatures.
  2. Rebuild artifacts deterministically; publish checksums generated in CI; attach signatures from a controlled key.
  3. Document verification steps; add CI step to **fail release if checksum/signature not produced**.
- **Potential Assignees:** Milady release engineer/maintainer, **jin** (reporter), CI/CD maintainer.

---

### 5) Plugin naming standardization may cause breakage (`plugin-form` / `plugin-forms` rename)
- **Issue Title & ID:** Potential breaking change from plugin renames in xfn-framework/registry — **Triage ID: DISC-2026-03-18-PLUGINNAMES**
- **Current Status:** Change implemented; risk of downstream configs importing old names.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects users depending on these plugins)
  - **Functional Impact:** **Partial** (breaks imports/configs; can block agent startup)
  - **Brand Impact:** **Medium** (ecosystem stability)
- **Technical Classification:**
  - **Issue Category:** Bug (compatibility) / Documentation
  - **Component Affected:** **Plugin System**, **Registry**, user configs/templates
  - **Complexity:** **Simple fix → Moderate** (aliases + migration notes)
- **Resource Requirements:**
  - **Required Expertise:** Package publishing, registry metadata, deprecation strategy
  - **Dependencies:** Ensure registry and templates updated; ensure cloud deploy templates match new names
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Provide **compatibility aliases** (metapackages) for old names that depend on new packages.
  2. Add deprecation warnings with clear remediation.
  3. Update docs, example configs, and ElizaCloud plugin picker labels.
- **Potential Assignees:** **Odilitime** (implemented rename), **Stan ⚡** (registry), docs maintainer.

---

### 6) Plugin-ollama: embeddings failing on Linux environments
- **Issue Title & ID:** Linux embedding failures in `plugin-ollama` — **GitHub: elizaos-plugins/plugin-ollama#17**
- **Current Status:** Known/investigating (community-reported).
- **Impact Assessment:**
  - **User Impact:** **Medium** (Linux is common for self-hosting)
  - **Functional Impact:** **Partial** (embeddings are core to retrieval/RAG workflows)
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** **Model Integration** (Ollama), embeddings pipeline
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, native deps, Ollama API nuances, vector libraries
  - **Dependencies:** Need reproducible environment matrix (glibc versions, CPU/GPU, container vs bare metal)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect failure logs + versions (Ollama server, plugin version, distro).
  2. Add a Linux CI job to run a minimal embedding test.
  3. Confirm model names and endpoint compatibility; validate response parsing.
- **Potential Assignees:** plugin-ollama maintainer, model integration maintainer, Linux infra contributor.

---

### 7) Migration information hard to find / confusing for new users (Milady → elizaOS)
- **Issue Title & ID:** Migration documentation discoverability and clarity gaps — **Triage ID: DISC-2026-03-19-MIGDOCS**
- **Current Status:** Reported as community pain; contributing to confusion and negative sentiment.
- **Impact Assessment:**
  - **User Impact:** **High** (onboarding + investor/user confusion)
  - **Functional Impact:** **No** (not runtime), but materially affects adoption
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs site, README(s), pinned Discord/Twitter comms
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, information architecture
  - **Dependencies:** Align messaging with leadership; ensure links are canonical and maintained
  - **Estimated Effort (1–5):** **1–2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a single canonical “Migration Hub” page with FAQs, token/address clarity, and links.
  2. Pin it in Discord; link from main README and docs navbar.
  3. Add “common pitfalls” section and screenshots for key steps.
- **Potential Assignees:** Docs maintainer, **jin** (feedback loop), community mods, **Odilitime** (source-of-truth alignment).

---

### 8) Execute Babylon airdrop + implement ElizaCloud buyback mechanism (integration-delivered token utility)
- **Issue Title & ID:** Babylon airdrop execution & ElizaCloud buyback mechanism implementation — **Triage ID: DISC-2026-03-20-BABYLON-TOKENOMICS**
- **Current Status:** Announced; implementation details/timeline not public; high community attention.
- **Impact Assessment:**
  - **User Impact:** **High** (broad community affects)
  - **Functional Impact:** **Partial** (not core framework execution, but core “ecosystem utility” promise)
  - **Brand Impact:** **High** (credibility given token-performance concerns)
- **Technical Classification:**
  - **Issue Category:** Feature / Operations (with Security considerations)
  - **Component Affected:** Babylon integration, ElizaCloud billing/revenue routing, on-chain execution
  - **Complexity:** **Architectural change** (depending on design: revenue share, automated buybacks, compliance constraints)
- **Resource Requirements:**
  - **Required Expertise:** Smart contracts/ops, finance/revenue plumbing, security review, data accounting
  - **Dependencies:** Finalize buyback policy, source of funds, cadence, transparency reporting, and safe execution
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a technical spec: triggers, frequency, wallets, limits, reporting.
  2. Implement auditable reporting dashboard (even if manual initially).
  3. Security review of any automated on-chain components before enabling.
- **Potential Assignees:** Babylon integration lead, ElizaCloud finance/ops owner, smart contract engineer, security reviewer.

---

### 9) Milady app: “not polished enough for marketing” + undefined release readiness criteria
- **Issue Title & ID:** Lack of explicit release criteria/timeline for Milady app — **Triage ID: DISC-2026-03-20-MILADY-RELEASE**
- **Current Status:** Releases exist; polish and readiness gating unclear; “ready when ready.”
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily affects users waiting for app; broader ecosystem anticipation)
  - **Functional Impact:** **No** (framework can progress independently)
  - **Brand Impact:** **Medium–High** (expectation management; repeated questions)
- **Technical Classification:**
  - **Issue Category:** UX / Process
  - **Component Affected:** Milady app product, QA/release process
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Product QA, release management, user testing
  - **Dependencies:** Resolve release integrity issues (GPG/SHA256); ensure cloud deploy reliability if it’s part of distribution
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define “marketing-ready” checklist (crash-free rate, onboarding, install success, telemetry/bug reporting).
  2. Establish release channel labels (alpha/beta/stable) and communicate expectations.
  3. Create a public issue board for top blockers to reduce repeated Discord churn.
- **Potential Assignees:** Milady maintainers, QA lead, **Odilitime** (comms touchpoint).

---

### 10) Registry intake for new plugins (e.g., Moltraffle) lacks a fast, standardized path
- **Issue Title & ID:** Improve plugin submission + validation pipeline for registry — **Triage ID: DISC-2026-03-19-REGISTRY-INTAKE**
- **Current Status:** Community plugin announced; advised to submit PR; process may still be high-friction.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (builders and ecosystem growth)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (ecosystem vibrancy)
- **Technical Classification:**
  - **Issue Category:** Documentation / Developer Experience
  - **Component Affected:** Plugin registry CI, templates, contributor docs
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** CI, documentation, registry schema
  - **Dependencies:** None (can be iterative)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add “Submit a plugin” guide with a checklist (naming, actions, config schema, versioning).
  2. Add automated validation: package existence, import smoke test, README minimums.
- **Potential Assignees:** **Stan ⚡** (registry), registry CI maintainer.

---

## Highest Priority Summary (Top 5–10 to address immediately)
1. **P0:** Deployment fails due to missing `@elizaos/plugin-discord` (**DISC-2026-03-19-PLUGDISC**)
2. **P0:** Disk image upload not received server-side (**DISC-2026-03-20-UPLOAD**)
3. **P1:** Add GUI restart/redeploy controls for stuck containers (**DISC-2026-03-19-GUIRELOAD**)
4. **P1:** Fix Milady release integrity (GPG + SHA256) (**DISC-2026-03-20-SIGNING**)
5. **P1:** Fix Linux embedding failures in Ollama plugin (**plugin-ollama#17**)
6. **P1:** Migration documentation clarity/discoverability (**DISC-2026-03-19-MIGDOCS**)
7. **P1:** Babylon airdrop + buyback mechanism implementation plan (**DISC-2026-03-20-BABYLON-TOKENOMICS**)
8. **P2:** Provide compatibility/aliases for plugin rename changes (**DISC-2026-03-18-PLUGINNAMES**)
9. **P2:** Milady release readiness criteria + public blocker list (**DISC-2026-03-20-MILADY-RELEASE**)

---

## Patterns / Themes Indicating Deeper Issues
- **Release/packaging reliability gaps:** Multiple signals (missing plugin module at runtime, disk image upload failures, checksum/signing issues) point to an ecosystem that’s shipping fast without enough automated release validation.
- **Operational UX deficiencies in ElizaCloud:** Users get stuck without self-serve recovery (restart/redeploy), magnifying the impact of otherwise-fixable deployment bugs.
- **Breaking changes without compatibility layers:** Plugin renames improve consistency but can silently break downstream users unless deprecations/aliases and migration notes are standard.
- **Trust/communication as a “system dependency”:** Documentation/migration clarity and clear execution plans (airdrop/buyback) function as adoption-critical infrastructure; when missing, they amplify negative sentiment and support load.

---

## Process Improvement Recommendations
1. **Introduce “Deployment Smoke Tests” as a hard gate:** For each official plugin (e.g., Discord), build an image and run an import + minimal runtime boot in CI (cloud-like environment).
2. **Add end-to-end artifact verification:** Require checksum + signature generation in CI; publish only CI-produced artifacts; fail releases when integrity metadata is missing.
3. **ElizaCloud operability baseline:** Add GUI controls for restart/rebuild/rollback + log access; include healthchecks and stuck-deploy detection.
4. **Compatibility policy for ecosystem changes:** Any rename or registry update must ship with aliases (for at least N releases) and a migration note pinned in docs.
5. **Single source-of-truth “Status & Roadmap” page:** Link from Discord pins and README; include known incidents (uploads, deployment bugs) and ETAs/next updates to reduce repeated support churn.