## Issue Triage — 2026-03-23

### 1) Disk image uploads fail to arrive on server (ElizaCloud)
- **Issue Title & ID:** Disk image upload failure (client sends, server receives nothing) — **INT-ELIZACLOUD-IMGUPLOAD-001**
- **Current Status:** **Open / Investigating** (reported on Discord; stack noted as *elizaos 1.x CLI + elizacloud*)
- **Impact Assessment:**
  - **User Impact:** **High** (blocks any users attempting image-based deployment/import)
  - **Functional Impact:** **Yes** (breaks a core operational workflow if disk images are required for provisioning)
  - **Brand Impact:** **High** (looks like unreliable infra)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **ElizaCloud / Upload API / CLI↔Cloud integration**
  - **Complexity:** **Moderate effort** (could be auth, request size limits, storage, async processing, or gateway config)
- **Resource Requirements:**
  - **Required Expertise:** Backend/API debugging, cloud storage pipelines (S3/GCS), observability/logging, CLI networking
  - **Dependencies:** Access to server logs, request tracing, and reproducible client payload; may depend on CDN/WAF/proxy settings
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Add/confirm **request correlation IDs** in CLI and server logs; capture a failing upload end-to-end.
  2. Verify **ingress limits** (NGINX/body size, API gateway limits, timeouts) and **content-type** handling.
  3. Confirm server is persisting bytes: validate **temporary storage path**, multipart parsing, and final object store write.
  4. Add a minimal **/upload/health** endpoint + server-side metric: bytes received, parts received, object write success/fail.
  5. Create a regression test: **single small image** + **large image** cases.
- **Potential Assignees:** **Odilitime** (reported/investigating), **pmairca** (core dev), ElizaCloud backend maintainer(s)

---

### 2) Milady releases: GPG key + SHA256 checksum problems
- **Issue Title & ID:** Release signing/checksum mismatch or missing artifacts — **milady-ai/milady INT-RELEASE-CRYPTO-001**
- **Current Status:** **Open** (identified in Discord as needing resolution)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (users can’t reliably verify downloads; may block install automation)
  - **Functional Impact:** **Partial** (core app may run, but distribution pipeline is degraded)
  - **Brand Impact:** **High** (integrity/signing issues raise supply-chain concerns)
- **Technical Classification:**
  - **Issue Category:** **Security / DevOps**
  - **Component Affected:** **Release pipeline, artifact signing, checksum generation**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** CI/CD (GitHub Actions), GPG signing, artifact publishing, release engineering
  - **Dependencies:** Clarify desired trust model (cosign vs GPG), where artifacts are hosted, key management policy
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce by downloading latest release and verifying **published SHA256** and **signature**.
  2. Audit CI workflow: ensure checksum is computed **from the final uploaded artifact**, not a pre-pack step.
  3. Rotate or re-publish a stable **public verification key** and document verification steps.
  4. Add CI gate: fail release if checksum/signature verification fails in a clean runner.
- **Potential Assignees:** **jin** (reported), Milady repo maintainer(s), **pmairca** (if supporting release engineering)

---

### 3) plugin-ollama: Embedding failures on Linux
- **Issue Title & ID:** Embeddings fail on Linux environments — **elizaos-plugins/plugin-ollama #17**
- **Current Status:** **Open / Under investigation** (per weekly summary)
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is a common deployment target for agents/servers)
  - **Functional Impact:** **Partial** (core chat may work, but retrieval/memory/semantic features break)
  - **Brand Impact:** **Medium–High** (plugin reliability affects ecosystem credibility)
- **Technical Classification:**
  - **Issue Category:** **Bug / Compatibility**
  - **Component Affected:** **Model Integration (Ollama embeddings), plugin runtime, native deps**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Node/TS plugin debugging, Ollama API behavior, Linux env packaging, dependency resolution
  - **Dependencies:** Repro matrix (distro, glibc, CPU/GPU), Ollama version, embedding model used
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect minimal repro: OS, kernel, Ollama version, model, plugin config, exact error logs.
  2. Add CI job or container-based test for **Linux embeddings**.
  3. Validate request formatting and streaming behavior; confirm plugin handles **timeouts** and **non-JSON errors**.
  4. Document known-good versions and pin ranges until fixed.
- **Potential Assignees:** plugin-ollama maintainer(s), **pmairca**, community contributors familiar with Ollama

---

### 4) Autonomous agent monetization plugin (Base): security + safety review needed before broader promotion
- **Issue Title & ID:** Review agent monetization/marketplace plugin (Base, AGT payments) for safety — **INT-PLUGIN-MARKET-BASE-SEC-001**
- **Current Status:** **Announced / Season 1 live** (Discord); security posture unknown
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (early adopters handling funds; risk concentrated but severe if exploited)
  - **Functional Impact:** **Partial** (not core framework, but high-stakes extension)
  - **Brand Impact:** **High** (any exploit/scam narrative would reflect on elizaOS ecosystem)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Plugin System, Web3 integration, on-chain marketplace interactions**
  - **Complexity:** **Complex solution** (depends on smart contracts + off-chain agent behavior)
- **Resource Requirements:**
  - **Required Expertise:** Smart contract security, wallet/key management for agents, threat modeling, sandboxing permissions
  - **Dependencies:** Access to plugin repo + contract addresses, clear scope of what is “official” vs community
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Determine official status: add **“community plugin” labeling** if not vetted.
  2. Perform a rapid threat model: key custody, signing flow, reentrancy/approval risks, malicious job postings, prompt injection.
  3. Require a **permissions manifest** (what the agent can sign/spend; spending limits).
  4. If contracts exist: commission/perform a **lightweight audit** or at minimum run Slither + unit tests.
  5. Publish a short “Safe Usage” doc: recommended wallets, spending caps, and monitoring.
- **Potential Assignees:** **TraderTomson** (author), security-minded core contributors, **pmairca** (core dev support)

---

### 5) Documentation gap: “No whitepaper” messaging causes repeated confusion
- **Issue Title & ID:** Clarify documentation: no traditional token whitepaper; point to roadmap + arXiv — **INT-DOCS-WHITEPAPER-CLARITY-001**
- **Current Status:** **Known / Repeated question on Discord**
- **Impact Assessment:**
  - **User Impact:** **High** (frequently asked; affects onboarding and trust)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium–High** (confusion can be interpreted as lack of legitimacy)
- **Technical Classification:**
  - **Issue Category:** **Documentation / UX**
  - **Component Affected:** **Docs site, README(s), community FAQ**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, docs IA
  - **Dependencies:** Decide canonical links (roadmap, arXiv, any token docs)
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a top-level docs/FAQ entry: “Whitepaper?” → roadmap + arXiv + explanation.
  2. Add a short “Project artifacts” page: roadmap, paper, code repos, audits (if any).
  3. Pin the answer in Discord + add a bot command (`/whitepaper`).
- **Potential Assignees:** **Odilitime** (already answering), docs maintainers, community mods/helpers

---

### 6) Communication deliverables don’t match stakeholder concerns (updates exist but aren’t answering key questions)
- **Issue Title & ID:** Improve update content + surfacing (weekly cronjob videos/daily updates not addressing core questions) — **INT-COMMS-UPDATES-ALIGNMENT-001**
- **Current Status:** **Ongoing community friction** (Discord)
- **Impact Assessment:**
  - **User Impact:** **High** (broad community dissatisfaction)
  - **Functional Impact:** **No** (but affects adoption/contribution)
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** **UX / Documentation (Project Ops)**
  - **Component Affected:** **Release communication, roadmap visibility, changelogs**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Product communication, community management, release notes discipline
  - **Dependencies:** Agreement on “top questions” to answer (utility, milestones, release readiness)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Maintain a rolling “Top 10 community questions” and explicitly answer 3–5 in each weekly update.
  2. Add a standardized weekly template: shipped/blocked/next + known issues + ETAs as ranges.
  3. Cross-link updates to GitHub milestones/issues so progress is auditable.
- **Potential Assignees:** **Odilitime**, **sb** (ecosystem clarifications), project lead(s)/maintainers

---

### 7) Milady app readiness: “ready when ready” with unclear blockers; needs a public release criteria checklist
- **Issue Title & ID:** Define Milady launch criteria + track blockers publicly — **INT-MILADY-RELEASE-READINESS-001**
- **Current Status:** **In progress; not polished enough for marketing** (Discord)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (users keep asking timeline; adoption stalled)
  - **Functional Impact:** **Partial** (productization blocked, not core framework)
  - **Brand Impact:** **Medium–High** (perceived delays and vagueness)
- **Technical Classification:**
  - **Issue Category:** **UX / Release Engineering**
  - **Component Affected:** **Milady application**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Product/release management, QA, packaging/distribution
  - **Dependencies:** Resolve signing/checksum issue (see above), define MVP scope
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a “Release Criteria” checklist (stability, install path, signing, telemetry/opt-out, docs).
  2. Create a GitHub milestone “Marketing-ready Beta” with labeled blockers.
  3. Provide a narrow ETA range once top blockers are under control.
- **Potential Assignees:** Milady maintainers, **Odilitime** (comms linkage), QA-minded contributors

---

### 8) Discord #coders off-topic recruitment/spam (marketing manager for meme coin)
- **Issue Title & ID:** Enforce channel scope + reduce off-topic solicitation in #coders — **INT-DISCORD-MOD-SCOPE-001**
- **Current Status:** **Observed** (single post, but pattern risk)
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (noise; can drive away devs if it grows)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (signals poor moderation)
- **Technical Classification:**
  - **Issue Category:** **UX (Community Ops)**
  - **Component Affected:** **Discord moderation**
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Community moderation, Discord automation
  - **Dependencies:** Updated rules; mod bandwidth
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Clarify channel rules + add “no recruiting/solicitation” (or redirect to a dedicated channel).
  2. Add automod keyword triggers for “DM me / hiring / marketing manager / pay weekly”.
- **Potential Assignees:** **Odilitime**, Discord mod team, community helpers

---

## Highest-Priority Summary (Top 5–10 to address now)
1. **P0:** Disk image uploads failing in ElizaCloud — **INT-ELIZACLOUD-IMGUPLOAD-001**
2. **P1:** Milady release signing/checksum integrity issues — **INT-RELEASE-CRYPTO-001**
3. **P1:** plugin-ollama Linux embedding failures — **plugin-ollama #17**
4. **P1:** Security review + official/community labeling for Base monetization marketplace plugin — **INT-PLUGIN-MARKET-BASE-SEC-001**
5. **P2:** Docs FAQ: “no whitepaper” canonical answer + bot command — **INT-DOCS-WHITEPAPER-CLARITY-001**
6. **P2:** Align weekly/daily updates to community’s top unanswered questions — **INT-COMMS-UPDATES-ALIGNMENT-001**
7. **P2:** Milady release readiness checklist + public blockers — **INT-MILADY-RELEASE-READINESS-001**
8. **P3:** Reduce off-topic recruiting spam in #coders — **INT-DISCORD-MOD-SCOPE-001**

---

## Patterns / Themes Suggesting Deeper Issues
- **Release engineering maturity gaps:** checksum/signing problems + unclear “marketing-ready” criteria indicate missing standardized release pipelines and QA gates.
- **Observability and “last mile” reliability:** the ElizaCloud upload failure suggests insufficient tracing/metrics for critical user flows.
- **Ecosystem safety governance:** high-risk Web3 monetization plugins are emerging faster than a clear vetting/labeling/auditing framework.
- **Communication impedance mismatch:** updates exist, but lack structured answers to recurring questions, causing persistent trust/expectation issues.

---

## Process Improvement Recommendations
1. **Introduce a “Critical User Flows” dashboard** (upload/provision/install/plugin install) with SLOs, logs, and alerts.
2. **Standardize release pipelines** across flagship repos (Milady + core): signed artifacts, reproducible checksums, CI verification gates.
3. **Create an “Ecosystem Plugin Trust” program**: tiers (Unreviewed/Reviewed/Audited), required manifests (permissions, spend limits), and security checklist.
4. **Adopt a weekly public triage + milestone discipline**: top blockers, status labels, and explicit “answered questions” section in updates.
5. **Harden community channels** with scoped channels + automod to keep developer spaces high-signal.