## Issue Triage — 2026-03-09

### 1) Embedding failures on Linux (Ollama plugin) — elizaos-plugins/plugin-ollama **#17**
- **Current Status:** Open / under investigation (community-reported; investigation noted in weekly summary)
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is a common deploy target for self-hosters/CI)
  - **Functional Impact:** **Partial** (blocks embeddings/RAG features for affected users; core chat may still work)
  - **Brand Impact:** **High** (perceived “it doesn’t work on Linux” hurts adoption and credibility)
- **Technical Classification:**
  - **Issue Category:** Bug / Compatibility
  - **Component Affected:** Model Integration (Ollama embeddings) / Plugin System
  - **Complexity:** Moderate effort (likely env/library/ABI/path differences, model availability, or HTTP/runtime differences)
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, Ollama APIs, embeddings pipelines, Node/TS plugin diagnostics
  - **Dependencies:** Repro steps + target distros; access to logs; confirm Ollama version matrix
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a minimal reproduction script + expected/actual output; request `ollama --version`, OS, arch, and model name.
  2. Instrument plugin with debug logging around embedding calls (request payload, endpoint, response codes, timeouts).
  3. Validate Linux-specific differences: networking (localhost vs 127.0.0.1), permissions, CA certs, IPv6, file paths, ESM/CJS.
  4. Create a compatibility table in README (Ollama versions + known-good models + Linux distros tested).
  5. Ship a patch release with improved error messages + fallback guidance.
- **Potential Assignees:** Plugin maintainers; **brightsyntax0821** (Linux + AI integration), a core plugin maintainer; volunteer support from **Challenger** (full-stack/DevOps skillset)

---

### 2) Review & merge xproof plugin registry entry — elizaos-plugins/registry **PR #266** (“xproof plugin for on-chain audit trails”)
- **Current Status:** Awaiting maintainer review (CodeRabbit approved; no conflicts)
- **Impact Assessment:**
  - **User Impact:** Medium (users wanting auditability/compliance benefit; not universal)
  - **Functional Impact:** No (new capability; does not unblock core runtime)
  - **Brand Impact:** Medium (shipping vetted plugins improves ecosystem momentum)
- **Technical Classification:**
  - **Issue Category:** Feature / Ecosystem
  - **Component Affected:** Plugin Registry / Plugin System
  - **Complexity:** Simple fix (review/merge + verify registry metadata)
- **Resource Requirements:**
  - **Required Expertise:** Registry conventions, basic security review, plugin metadata validation
  - **Dependencies:** Maintainer availability; confirm plugin source/release tags; verify supply-chain checks
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Maintainer performs final checklist: repository ownership, pinned versions/tags, license, install instructions, minimal permissions.
  2. Run registry validation/CI, ensure package naming and scoped org alignment.
  3. Merge PR; announce in Discord with a short “what it does + example config” snippet.
- **Potential Assignees:** Registry maintainers; PR author **jasonxkensei**

---

### 3) Security/community safety: scam risk in Discord channels — (No GitHub issue ID; create tracking issue in core repo or ops repo)
- **Current Status:** Reported warning (“potential scam activity in coders channel”); no tracked mitigation work visible
- **Impact Assessment:**
  - **User Impact:** **Critical** (users can lose funds / get malware’d; affects all community members)
  - **Functional Impact:** No (not runtime), but **operationally critical**
  - **Brand Impact:** **High** (security incidents severely damage trust)
- **Technical Classification:**
  - **Issue Category:** Security / UX (community operations)
  - **Component Affected:** Discord Ops / Community Safety
  - **Complexity:** Moderate effort (policy + automation + moderation workflow)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, phishing/scam patterns, community ops
  - **Dependencies:** Moderator bandwidth; agreement on verification and link policies
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Open a tracked issue: “Discord anti-scam hardening (roles, link restrictions, reporting flow)”.
  2. Implement/verify: limited posting permissions for new accounts, anti-phishing bot, auto-delete suspicious links, require account age/verification for #coders.
  3. Pin an “Official Links & Safety” message in major channels; add a “Never DM first” policy and impersonation reporting instructions.
  4. Create an incident response playbook (what mods do in first 10 minutes).
- **Potential Assignees:** **satsbased** (raised warning), community mods, **Odilitime** for policy approval

---

### 4) Documentation gap enabling token/brand impersonation: clarify “official Milady token” status — (No GitHub issue ID; create docs issue)
- **Current Status:** Community confusion persists; team stated “no legit Milady token yet,” but this is not captured in canonical docs
- **Impact Assessment:**
  - **User Impact:** **High** (users may get scammed or misinformed)
  - **Functional Impact:** No (not framework runtime)
  - **Brand Impact:** **High** (perceived disorganization + scam adjacency)
- **Technical Classification:**
  - **Issue Category:** Documentation / Security (social engineering prevention)
  - **Component Affected:** Documentation site + Discord pinned messages
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Clear technical writing, comms alignment, link hygiene
  - **Dependencies:** Team sign-off on the exact wording and “source of truth” URLs
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a short canonical statement: “No official Milady token launched yet” + where official announcements will appear.
  2. Pin it in Discord (#discussion, #announcements) and add to docs/website FAQ.
  3. Add guidance for verifying official contracts (when applicable) and reporting impersonators.
- **Potential Assignees:** **Odilitime** (authoritative messaging), docs maintainers; support from **LillAnders** (ecosystem comms)

---

### 5) ZARQ pre-trade risk scoring plugin: QA + registry entry + minimal usage docs — (No PR/issue ID in provided data; create tracking issue)
- **Current Status:** Plugin announced as published; integration surfaced in Discord; registry/documentation status unclear
- **Impact Assessment:**
  - **User Impact:** Medium (primarily trading/DeFi agents)
  - **Functional Impact:** Partial (for users relying on risk gating, lack of docs/QA blocks adoption)
  - **Brand Impact:** Medium (shipping integrations without docs feels incomplete)
- **Technical Classification:**
  - **Issue Category:** Feature / Documentation
  - **Component Affected:** Plugin System / Registry / Agent tooling
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Plugin packaging, API keys/secrets handling, example agent configuration, basic security review
  - **Dependencies:** Confirm plugin repo/package name; define rate limits/SLAs; ensure safe defaults
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a single “ZARQ plugin onboarding” doc page: install, config, example tool call, recommended thresholds.
  2. Add a small test harness (mock responses) + CI checks for schema stability.
  3. If not already: submit registry PR with pinned version + verified maintainer contact.
- **Potential Assignees:** **LillAnders** (announced/published), registry maintainers, a plugin QA volunteer (e.g., **brightsyntax0821**)

---

### 6) Agent-to-vendor credit line enforcement primitive (bond + atomic slashing) — (Design proposal; create RFC issue)
- **Current Status:** Validation phase; community feedback requested; no evidence of consolidated requirements/RFC
- **Impact Assessment:**
  - **User Impact:** Low–Medium today (depends on how many agents transact for compute/tools)
  - **Functional Impact:** No (future capability)
  - **Brand Impact:** Medium (payments reliability matters for serious adopters)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Architecture
  - **Component Affected:** Core Framework / Payments / Tooling contracts
  - **Complexity:** Architectural change (touches execution lifecycle, accounting, settlement)
- **Resource Requirements:**
  - **Required Expertise:** Mechanism design, smart contracts (if on-chain), payment settlement, threat modeling
  - **Dependencies:** Clear problem statement + real incident data; decision on chain(s) (Solana/BSC) and off-chain enforcement
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Open an RFC: define the unpaid-compute problem, actors, threat model, and success metrics.
  2. Collect 3–5 real-world provider anecdotes (API/tool vendors) to validate necessity.
  3. Compare alternatives: prepaid escrow, metered streaming payments, rate-limited tool access, off-chain invoicing.
- **Potential Assignees:** **N0vaMp4** (proposer), a core architect/maintainer, community members with Web3 infra experience

---

### 7) Transparency/documentation: ai16z migration snapshot & holdings verification — (No GitHub issue ID; create docs issue)
- **Current Status:** Stated as verifiable on-chain; not centralized into a single reference doc for users
- **Impact Assessment:**
  - **User Impact:** Medium (token holders and ecosystem participants)
  - **Functional Impact:** No
  - **Brand Impact:** High (trust/transparency directly impacts community confidence)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Website/docs + Discord announcements
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Basic on-chain verification instructions, clear writing, link curation
  - **Dependencies:** Confirm addresses/transactions to reference; avoid doxxing/private keys; legal/comms review
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish “How to verify the snapshot/migration holdings on-chain” with explorer links.
  2. Add FAQ: what was snapshotted, timelines, and where official updates will be posted.
- **Potential Assignees:** **Odilitime**, docs maintainers

---

## Top Priority Summary (address immediately: top 5–10)
1. **P0:** Discord anti-scam hardening + incident playbook (create tracked issue; implement moderation controls)
2. **P1:** plugin-ollama **#17** — Linux embedding failures (repro + diagnostics + fix)
3. **P1:** Official Milady token status clarification (canonical doc + pinned safety notice)
4. **P2:** registry **PR #266** — merge xproof plugin after maintainer checklist
5. **P2:** ZARQ plugin onboarding: registry/QA/docs to make the integration usable and safe
6. **P2:** ai16z migration snapshot verification documentation (reduce FUD via a single source of truth)
7. **P3:** RFC for agent-to-vendor credit line enforcement (validate problem before building)

---

## Patterns / Themes Indicating Deeper Problems
- **Trust & safety gaps are now as urgent as code bugs:** repeated community confusion (official token status) plus scam warnings suggests missing “canonical sources of truth” and inadequate community hardening.
- **Ecosystem shipping without an adoption package:** multiple plugin announcements (xproof, ZARQ) lack a visible, standardized path: registry entry → version pinning → minimal docs → example configs → QA checks.
- **Validation-before-building is inconsistent:** the credit-line primitive is correctly in validation, but lacks a formal RFC pipeline to convert discussion into a decision and scoped work.

---

## Process Improvement Recommendations
1. **Create an “Operational Security” lane** in the tracker (P0-capable) for Discord/website/community safety tasks, with an owner rotation.
2. **Plugin release checklist (required for announcements):** registry PR merged, pinned version/tag, minimal README, example agent config, security notes (keys, permissions), and a smoke test.
3. **Canonical announcements policy:** one “Official Updates” page + pinned Discord message; every token/project-status claim must link back to that page.
4. **RFC template for architectural features:** problem statement, user stories, threat model, alternatives, and exit criteria—required before implementation work is approved.