## Issue Triage — 2026-03-31

### 1) [Plugin Proposal] Dreamline x402 Policy Facilitator for autonomous agent spend governance — elizaos/eliza **#6695**
- **Current Status:** OPEN (active discussion; open design question: whether x402 plugin surfaces operator events *before* fetch executes)
- **Impact Assessment:**
  - **User Impact:** **Critical** (anyone enabling autonomous spend is exposed)
  - **Functional Impact:** **Yes** (blocks safe use of x402 “Agent Commerce” in production)
  - **Brand Impact:** **High** (fund loss / governance failures undermine trust)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** **Core Framework + Plugin System (x402 payment flow)**
  - **Complexity:** **Architectural change** (policy interception layer + audit trail expectations)
- **Resource Requirements:**
  - **Required Expertise:** payment authorization design, threat modeling, plugin hooks/middleware, on-chain allow/deny lists, eventing/UX for operator approvals
  - **Dependencies:** clarity on x402 plugin lifecycle hooks (pre-request interception), operator notification channel, policy storage format (local vs on-chain)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Define the security model**: “default-deny vs default-allow”, budgets (per-tx / daily), whitelists/blacklists, and required audit artifacts.
  2. **Answer the blocker question**: confirm whether current x402 implementation can emit a **pre-execution event** and allow a synchronous “deny” decision; if not, create/extend hook points.
  3. Produce an **MVP spec** for a governance interface: `(request intent) -> (policy decision) -> (execute) -> (receipt)`.
  4. Implement minimal policy plugin (even if centralized) with: budget limits, destination allow/deny, and immutable receipt logging.
  5. Add regression tests: ensure “blocked” spend never executes and is logged.
- **Potential Assignees:**
  - **majorelalexis-stack** (raised security gap; proposed AIP/escrow approaches)
  - **hermesnousagent** (two-layer authorization concept; contract objects)
  - **odilitime** (core runtime + governance integration oversight)
  - Support: **HaruHunab1320** (core TS services, tests, reliability)

---

### 2) Unable to use `elizaos` command after installation on MacOS — elizaos/eliza **#6636**
- **Current Status:** OPEN (user reports `bun i -g @elizaos/cli` installs but `zsh: command not found: elizaos`)
- **Impact Assessment:**
  - **User Impact:** **High** (new users on macOS; blocks onboarding)
  - **Functional Impact:** **Yes** (CLI is primary entry point: create/run scaffolds)
  - **Brand Impact:** **High** (installation failure is a first-impression killer)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **CLI / Installation (bun global bin, PATH, packaging)**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** bun global installs, macOS shell environments (zsh), CLI package `bin` configuration, docs
  - **Dependencies:** determine whether this is docs-only (PATH) vs actual packaging/path resolution issue; confirm with repro on clean macOS
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce on a clean macOS environment with bun: verify `bun pm bin -g` output and actual binary location.
  2. Confirm `package.json` `bin` entry for `@elizaos/cli` and whether bun links it into `~/.bun/bin`.
  3. Provide a **single canonical install snippet** in docs + CLI postinstall output (detect missing PATH and print exact remediation).
  4. Add a troubleshooting doc section: zsh profile precedence (`.zshrc` vs `.zprofile`) and terminal restart requirements.
- **Potential Assignees:**
  - **odilitime** (core/CLI owner)
  - **kaiclawd** (recent work around `elizaos create` flow; likely familiar with CLI internals)

---

### 3) chore(integrations): import polymarket-agent snapshot for internal runtime… — elizaos/eliza **PR #6547**
- **Current Status:** OPEN (Greptile review flags **hard compile-time errors** + missing dependency declarations)
- **Impact Assessment:**
  - **User Impact:** **Medium** (only affects users/devs trying the Polymarket integration)
  - **Functional Impact:** **Partial** (doesn’t break core, but blocks integration validation and wastes reviewer time)
  - **Brand Impact:** **Medium** (shipping broken checkpoints harms perceived quality of integrations)
- **Technical Classification:**
  - **Issue Category:** **Bug / Maintenance**
  - **Component Affected:** **Integrations**
  - **Complexity:** **Simple fix** (syntax/import/deps), plus light cleanup
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, repo hygiene (deps), minimal integration testing
  - **Dependencies:** none, can be fixed within PR
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Fix critical syntax/import issues (duplicate `const creds`, duplicate `parseArgs` import).
  2. Add missing explicit dependency (`@ethersproject/wallet`) or refactor to existing deps.
  3. Set `private: true` for internal integration packages to avoid accidental publishing.
  4. Ensure CLI commands are implemented consistently (add missing `settings` switch case).
  5. Replace trivial “tests” with at least one meaningful smoke test (or remove misleading test block).
- **Potential Assignees:**
  - **miladyprediction** (PR author)
  - Support: **HaruHunab1320** (fast compile-fix + test patterns), **lalalune** (integration context)

---

### 4) docs: Add comprehensive CONTRIBUTING.md guide — elizaos/eliza **PR #6647**
- **Current Status:** OPEN (very large diff size; risk of accidental vendor content / wrong file inclusion)
- **Impact Assessment:**
  - **User Impact:** **Medium** (good docs help many, but only if correct)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (a CONTRIBUTING PR with massive unrelated changes signals poor repo hygiene)
- **Technical Classification:**
  - **Issue Category:** **Documentation / Process**
  - **Component Affected:** **Repository governance/docs**
  - **Complexity:** **Moderate effort** (review + reduce to minimal change set)
- **Resource Requirements:**
  - **Required Expertise:** maintainer review discipline, docs structure, monorepo contributor workflow knowledge
  - **Dependencies:** requires PR author to rescope and/or split PR
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Request PR author to **rebase and scope** to only `CONTRIBUTING.md` + strictly necessary references.
  2. Add CI guardrail: block docs PRs that touch unrelated directories unless explicitly labeled/approved.
  3. Maintain a short “Contributor Quickstart” plus links to deeper docs (avoid duplication across repos).
- **Potential Assignees:**
  - **odilitime** (maintainer review / merge authority)
  - **vincent067** (PR author; responsible for rescoping)

---

### 5) Plugin Proposal: AgentID — Cryptographic Identity & Trust Layer for ElizaOS Agents — elizaos/eliza **#6688**
- **Current Status:** OPEN (proposal; overlaps conceptually with existing identity initiatives like SAID)
- **Impact Assessment:**
  - **User Impact:** **Medium** (valuable for marketplaces / agent-to-agent interactions)
  - **Functional Impact:** **Partial** (not required for core runtime; important for trust/security posture)
  - **Brand Impact:** **Medium** (clear identity story improves ecosystem credibility)
- **Technical Classification:**
  - **Issue Category:** **Feature Request / Security**
  - **Component Affected:** **Core Framework + Model/Plugin Integration (identity, receipts)**
  - **Complexity:** **Complex solution** (trust levels, receipts, challenge-response, multi-chain bindings)
- **Resource Requirements:**
  - **Required Expertise:** cryptographic identity, key management, trust/reputation modeling, secure receipts, threat modeling
  - **Dependencies:** clarify how it coexists with SAID Protocol + AgentID overlaps; define “one identity interface” for plugins
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Produce an **Identity Abstraction RFC**: minimal interface that supports SAID/AgentID/others.
  2. Decide canonical key source: derived from agent Ed25519 vs external wallet binding.
  3. Define what becomes “core” vs “plugin-provided” (receipts, trust levels, verification gates).
- **Potential Assignees:**
  - **haroldmalikfrimpong-ops** (proposal author)
  - **odilitime** (core architecture decision-maker)
  - Support: **kaiclawd** (identity-on-create experience)

---

### 6) Integration: Pyrimid x402 Agent Commerce via MCP — elizaos/eliza **#6668**
- **Current Status:** OPEN (integration proposal; MCP server + tools available)
- **Impact Assessment:**
  - **User Impact:** **Medium** (useful for builders exploring paid APIs)
  - **Functional Impact:** **Partial** (extends capabilities; not required for baseline)
  - **Brand Impact:** **Medium** (good integration story strengthens “agent commerce” narrative)
- **Technical Classification:**
  - **Issue Category:** **Feature Request**
  - **Component Affected:** **Model Integration / MCP tooling / x402**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** MCP client integration, x402 payment flow, API catalog/discovery UX
  - **Dependencies:** must align with spend-governance work (policy checks before payments)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3** (promote to P2 once spend governance baseline exists)
- **Specific Actionable Next Steps:**
  1. Document “MCP + x402” reference architecture and security caveats (must use governance plugin when enabled).
  2. Add a minimal example agent that discovers a paid tool and performs a governed call.
- **Potential Assignees:**
  - **odilitime** (platform alignment)
  - Community integration contributors once governance is in place

---

### 7) Embedding failures on Linux environments — elizaos-plugins/plugin-ollama **#17**
- **Current Status:** OPEN (investigation ongoing per weekly summary)
- **Impact Assessment:**
  - **User Impact:** **Medium** (Linux users + anyone relying on local embeddings via Ollama)
  - **Functional Impact:** **Partial** (RAG/embedding workflows impaired)
  - **Brand Impact:** **Medium** (platform reliability on Linux)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin System / Model Integration (Ollama embeddings)**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Linux environment debugging, Ollama API specifics, embedding model config, dependency/ABI awareness
  - **Dependencies:** need reproducible environment matrix (distro, glibc/musl, GPU/CPU)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a minimal repro script + capture logs (request/response payload sizes, model name, endpoint).
  2. Test matrix: Ubuntu LTS + Debian + Arch; CPU-only vs GPU if relevant.
  3. Add integration test in plugin repo (skip if Ollama not available; run in nightly with containerized Ollama).
- **Potential Assignees:**
  - plugin-ollama maintainers (not listed in provided data)
  - Support: **HaruHunab1320** (tests + CI patterns)

---

### 8) Community fragmentation: Discord channel strategy + need centralized ecosystem hub — **COMM-IA-001** (Discord-driven)
- **Current Status:** Identified in Discord discussions (proposal: bridged room + website hub listing agents/apps/projects)
- **Impact Assessment:**
  - **User Impact:** **High** (builders/investors can’t find canonical info; repeated questions)
  - **Functional Impact:** **No** (not runtime-breaking)
  - **Brand Impact:** **High** (confusion fuels “abandoned/scam” narratives)
- **Technical Classification:**
  - **Issue Category:** **UX / Documentation**
  - **Component Affected:** **Community Ops + Website/Docs**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** community information architecture, web content ops, Discord moderation tooling
  - **Dependencies:** website changes (project directory/hub), agreement on canonical messaging for ecosystem relationships
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a **single “What is built on ElizaOS?” hub page** (agents/apps/dApps/projects; relationship statements).
  2. Stand up **bridged room** between key Discords (as proposed) with clear channel purposes and pinned “start here”.
  3. Add a short “Ecosystem map” section to docs + link from Discord welcome message.
- **Potential Assignees:**
  - **odilitime** (Community Ops, bridging proposal owner)
  - **shawmakesmagic** (moderation + community structure)
  - Support: **magicyte** (mini-mod coordination)

---

### 9) Scam/solicitation pressure in community channels — **SEC-COMM-002** (Discord-driven)
- **Current Status:** Ongoing warnings observed (fraud messages; vague “quick money” solicitations)
- **Impact Assessment:**
  - **User Impact:** **High** (especially new users)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (security optics + user trust)
- **Technical Classification:**
  - **Issue Category:** **Security / UX**
  - **Component Affected:** **Discord moderation & safety operations**
  - **Complexity:** **Simple fix** (policy + tooling), some moderate automation
- **Resource Requirements:**
  - **Required Expertise:** moderation automation (bots), community policy, incident response playbooks
  - **Dependencies:** none
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Tighten auto-mod rules for solicitation keywords + suspicious link patterns.
  2. Add a “Report scams” quick-action + pinned safety guidance in high-traffic channels.
  3. Publish an official stance on token/project status updates in a single pinned location to reduce rumor-driven exploit attempts.
- **Potential Assignees:**
  - **shawmakesmagic** (moderation)
  - **odilitime** (Community Ops)
  - Support: **magicyte** (mini-mod execution)

---

## Highest-Priority Focus (Top 5–10 to address now)
1. **P0:** elizaos/eliza **#6695** — x402 spend governance policy layer (security-critical)
2. **P1:** elizaos/eliza **#6636** — macOS CLI command not found (onboarding blocker)
3. **P1:** **COMM-IA-001** — ecosystem hub + Discord bridging to reduce confusion/rumors
4. **P1:** **SEC-COMM-002** — scam/solicitation mitigation in Discord
5. **P2:** plugin-ollama **#17** — Linux embedding failures (common RAG workflow impact)
6. **P2:** elizaos/eliza **PR #6547** — polymarket integration compile errors (cleanup to unblock integration work)
7. **P2:** elizaos/eliza **PR #6647** — rescope massive CONTRIBUTING PR to safe minimal change
8. **P2:** elizaos/eliza **#6688** — AgentID identity proposal (align with existing identity stack)
9. **P3:** elizaos/eliza **#6668** — Pyrimid MCP+x402 integration (enable after governance baseline)

---

## Patterns / Themes Suggesting Deeper Architectural Issues
- **Autonomous spend shipped faster than governance primitives:** x402 enablement is outpacing policy, audit, and operator-control mechanisms; this is a systemic security gap, not a single-plugin issue.
- **Onboarding fragility (CLI + docs + community IA):** install/path problems plus fragmented community information amplify user drop-off and rumor cycles.
- **Integration checkpoint quality variance:** large imported integrations and oversized documentation PRs indicate missing contribution guardrails (scoping, CI checks, review gating).

---

## Process Improvement Recommendations
1. **Security-by-default for “Agent Commerce”:**
   - Require an explicit “governance enabled” configuration for any autonomous payment capability.
   - Add a standard preflight hook + receipt logging interface in core for payment-like actions.
2. **Contribution guardrails:**
   - CI rule: flag PRs that change >N files/lines for docs-only labels; require maintainer approval and PR splitting.
   - Template checklists for integration imports: must compile, must declare deps, must set `private: true` where applicable.
3. **Onboarding quality loop:**
   - Maintain a tested install matrix (macOS/Linux/Windows) in CI or nightly docs verification.
   - Add a single “Start Here” canonical page and keep Discord pins synchronized to it.