## Issue Triage — 2026-03-30

### 1) CI / Job Runner payments failing (jobs not starting) — **DISCORD-xfn-framework-2026-03-29**
- **Current Status:** Reported in Discord by `stan0473`; unconfirmed root cause; blocking CI/job execution.
- **Impact Assessment:**
  - **User Impact:** **High** (all contributors reliant on CI; potentially blocks releases/merges)
  - **Functional Impact:** **Yes** (CI/jobs do not start)
  - **Brand Impact:** **High** (public CI failures + stalled PRs)
- **Technical Classification:**
  - **Issue Category:** Performance / Infrastructure (Ops)
  - **Component Affected:** CI/CD, job runner account/billing
  - **Complexity:** Moderate effort (mostly ops + billing + verification)
- **Resource Requirements:**
  - **Required Expertise:** CI/CD ops (GitHub Actions / external runner), billing/admin access, org-level account management
  - **Dependencies:** Access to billing portal; confirmation whether it’s tied to “Soulmate Lang” org; possible spending limit policy
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Identify which CI provider/account emitted the exact error (“job not started due to failed account payments / spending limit”).
  2. Verify affected scopes: which repos/workflows are blocked (core repo vs plugins vs separate runner).
  3. Confirm billing owner and payment method validity; raise/disable spending limit if appropriate.
  4. Add a lightweight “CI Health” check (daily ping workflow) that alerts in Discord when job start fails.
  5. Post a brief status update + ETA in dev channels to reduce contributor churn.
- **Potential Assignees:** `stan0473` (reported, core dev), `odilitime` (core dev + ops), `ameliaguert` (suggested by Stan; org context)

---

### 2) Spend governance gap for autonomous x402 payments (operator visibility + pre-authorization) — **[Plugin Proposal] Dreamline x402 Policy Facilitator** — `elizaos/eliza#6695`
- **Current Status:** **OPEN**; cross-repo design discussion active; key open question: operator-visible event *before* fetch executes vs first signal being wallet balance change.
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (anyone enabling autonomous payments; increasing as “agent commerce” grows)
  - **Functional Impact:** **Partial** (payments work, but governance/controls insufficient for safe production use)
  - **Brand Impact:** **High** (uncontrolled agent spend is reputationally risky)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Payment system (x402), plugin system, runtime fetch/payment interception
  - **Complexity:** **Architectural change** (standard policy hook + UX/operator prompts/logging)
- **Resource Requirements:**
  - **Required Expertise:** Security engineering, x402 protocol familiarity, plugin architecture, wallet ops, eventing/telemetry
  - **Dependencies:** Clarify current x402 plugin lifecycle hooks; decide standard “preflight” interface; align across `elizaos/eliza` + `elizaos-plugins/registry`
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1** (ship a minimal governance hook this sprint; iterate)
- **Specific Actionable Next Steps:**
  1. **Answer the blocking question**: add/confirm an operator-visible “PAYMENT_PREFLIGHT” event emitted *before* settlement.
  2. Define a minimal standard interface: `preAuthorize(paymentIntent) -> approved/denied + reason + policyId`.
  3. Implement an MVP: per-agent daily cap + per-tx cap + allowlist/denylist (local config first; on-chain registry optional).
  4. Add audit logging requirements (intent created, policy decision, settlement result).
  5. Document “Policy Facilitator pattern” as a recommended extension point (core docs + registry guidance).
- **Potential Assignees:** `odilitime` (core/runtime), `HaruHunab1320` (core fixes & tests), `aisatoshinext-arch` (proposal author), `hermesnousagent` (pre-auth contract spec contributor per dev log)

---

### 3) MacOS: `elizaos` CLI command not found after global install (bun) — **Unable to use elizaos command after installation on MacOS** — `elizaos/eliza#6636`
- **Current Status:** **OPEN**; user reports PATH already set but binary still not found.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks new developers on a common platform)
  - **Functional Impact:** **Yes** (cannot run CLI; blocks onboarding and “create” workflows)
  - **Brand Impact:** **High** (first-run experience failure)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** CLI distribution, bun global install, PATH/docs
  - **Complexity:** Moderate effort (root cause may be packaging/bin mapping or docs)
- **Resource Requirements:**
  - **Required Expertise:** Node/bun packaging, CLI release process, MacOS shell environments (zsh)
  - **Dependencies:** Repro on a clean MacOS environment; confirm bun global bin path and `package.json` bin field
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce on MacOS with `bun i -g @elizaos/cli` and validate `bun pm bin -g` output vs user’s PATH.
  2. Confirm the installed binary location and whether bun is using `~/.bun/bin` or `~/.bun/bin` symlink behavior.
  3. Add a CLI self-check command in docs: `which elizaos`, `bun pm ls -g`, `echo $PATH`.
  4. If packaging issue: verify `bin` mapping in `@elizaos/cli` and release pipeline produces correct executable.
  5. Update install docs with exact PATH export line bun prints (and common pitfalls like non-login shells).
- **Potential Assignees:** `odilitime` (core dev), `HaruHunab1320` (CI/release reliability), `lalalune` (core maint), plus a MacOS maintainer from community once identified

---

### 4) Ecosystem confusion: projects built on ElizaOS not discoverable (Milady/SHAW relationship) — **DISCORD-discussion-ecosystem-visibility-2026-03-29**
- **Current Status:** Reported repeatedly in Discord; proposal: centralized hub on website listing agents/apps/dApps/community projects.
- **Impact Assessment:**
  - **User Impact:** **High** (newcomers/investors + builders; repeated confusion)
  - **Functional Impact:** **No** (not a runtime blocker)
  - **Brand Impact:** **High** (perception of fragmentation; undermines ecosystem narrative)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Website / docs IA, community comms
  - **Complexity:** Moderate effort (content model + curation + updates workflow)
- **Resource Requirements:**
  - **Required Expertise:** Docs/website (Next.js site), information architecture, community ops, lightweight data model
  - **Dependencies:** Decide source-of-truth (registry metadata? manual curation?); ownership for updates
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2** (plan now; execute near-term)
- **Specific Actionable Next Steps:**
  1. Create a website page: “Ecosystem Directory” with clear labels: *Built on ElizaOS*, *Incubated*, *Independent partner*, etc.
  2. Add a submission/update form or PR-based workflow (e.g., `ecosystem.yaml`) to prevent stale info.
  3. Explicitly document relationships for high-visibility projects (Milady, SHAW, Hyperscape) in one canonical place.
  4. Add cross-links from Discord channels, docs landing page, and README.
- **Potential Assignees:** `cyborgxai` (originating suggestion), `odilitime` (community ops), `stackvector` / `baogerbao` (design + community), website maintainers (not explicitly listed in today’s data)

---

### 5) Discord channel fragmentation (builder vs investor communities) + need for bridged room — **DISCORD-discussion-bridging-2026-03-29**
- **Current Status:** Proposed by `odilitime`; not yet implemented.
- **Impact Assessment:**
  - **User Impact:** **Medium** (community members, onboarding, investor comms)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium → High** (confusion, duplicated announcements, missed support)
- **Technical Classification:**
  - **Issue Category:** UX / Community Ops
  - **Component Affected:** Discord, comms infrastructure (bridging)
  - **Complexity:** Simple fix → Moderate (depends on tooling: Discord channels, bots, cross-posting)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod ops, bot setup (if bridging via bot), moderation policy alignment
  - **Dependencies:** Decide bridging method + moderation rules + what gets mirrored
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define bridging scope: which channels and what content types (announcements only vs full chat mirror).
  2. Implement with a bot or Discord native integrations; test for spam/scam amplification risks.
  3. Publish a short “Where to talk about what” guide pinned in both spaces.
- **Potential Assignees:** `odilitime` (proposed), `magicyte` (helper/mod context), `satsbased` (stakeholder raising concern)

---

### 6) Scam / impersonation attempts in community channels (e.g., fake “Kenk”, pluginweb3 scam messages) — **DISCORD-coders-scam-warnings-2026-03-29**
- **Current Status:** Active warnings; incidents recurring; handled ad-hoc by community.
- **Impact Assessment:**
  - **User Impact:** **High** (many users exposed; risk of fund loss)
  - **Functional Impact:** **No** (but safety-critical for ecosystem participation)
  - **Brand Impact:** **High** (trust/safety perception)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Discord community operations
  - **Complexity:** Moderate effort (process + tooling + enforcement)
- **Resource Requirements:**
  - **Required Expertise:** Moderation, Discord anti-scam tooling, incident response playbooks
  - **Dependencies:** Moderator coverage, bot configuration, reporting pipeline
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1** (community safety)
- **Specific Actionable Next Steps:**
  1. Enable/verify anti-phishing and suspicious link protections; tighten DM permissions guidance.
  2. Create a pinned “Official Accounts & Safety” post; include verification steps and “never share seed/private key” policy.
  3. Add a lightweight incident template: screenshot, user ID, message link, action taken.
  4. Consider an allowlist for posting links in high-risk channels (or new-user link throttling).
- **Potential Assignees:** `odilitime` (moderator), `satsbased` (mini mod), `baogerbao` (active reporter), `magicyte` (mod/helper)

---

### 7) Developer onboarding gap: agent-challenge model endpoints/cost expectations unclear — **DISCORD-agent-challenge-endpoints-2026-03-29**
- **Current Status:** User question remains effectively unanswered (open-source confirmed, but endpoint provisioning/cost unclear).
- **Impact Assessment:**
  - **User Impact:** **Medium** (new builder funnel; challenge participants)
  - **Functional Impact:** **Partial** (blocks participation decisions)
  - **Brand Impact:** **Medium** (confusion around costs and accessibility)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs, onboarding, challenge materials
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Docs + product clarity; knowledge of official model/provider setup
  - **Dependencies:** Confirm whether official hosted endpoints exist for the challenge; define recommended free/cheap local options
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish an “Agent Challenge: Model Access” FAQ: supported providers, expected costs, any credits, local model guidance (Ollama, etc.).
  2. Provide a reference `.env` template for each common provider.
  3. If endpoints are provided: publish rate limits + acceptable use + how to request access.
- **Potential Assignees:** `odilitime` (community ops), `satsbased` (answered partially), docs contributors (e.g., `vincent067`)

---

### 8) Plugin submission & distribution process unclear for third-party devs — **DISCORD-plugin-submission-process-2026-03-27**
- **Current Status:** Developer asked timeline/how-to; asked to provide registry PR/plugin name; process not clearly documented.
- **Impact Assessment:**
  - **User Impact:** **Medium** (plugin ecosystem growth)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (friction for contributors)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Plugin Registry, contributor docs
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Registry maintainers, docs
  - **Dependencies:** Align on review SLA and required metadata/security checks
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document the end-to-end plugin path: prepare package → registry PR → review checklist → publish/announce.
  2. Add expected SLA (best effort) and automated checks (lint, security scan, package metadata validation).
  3. Provide a “Plugin Readiness Checklist” (permissions, secrets, payment hooks, safety notes).
- **Potential Assignees:** `odilitime` (review gate), registry maintainers; community plugin authors like `meowww404` as feedback partner

---

## Summary: Top Highest-Priority Items to Address Immediately (Next 24–72 hours)
1. **P0:** CI/job runner billing failure preventing jobs from starting (**DISCORD-xfn-framework-2026-03-29**)
2. **P1:** x402 autonomous spend governance hook + operator pre-authorization standard (**elizaos/eliza#6695**)
3. **P1:** MacOS CLI “command not found” onboarding blocker (**elizaos/eliza#6636**)
4. **P1:** Recurring Discord scam/impersonation incidents (safety controls + pinned guidance) (**DISCORD-coders-scam-warnings-2026-03-29**)
5. **P2:** Ecosystem visibility hub to reduce fragmentation and clarify project relationships (**DISCORD-discussion-ecosystem-visibility-2026-03-29**)
6. **P2:** Bridged room strategy to reduce community fragmentation (**DISCORD-discussion-bridging-2026-03-29**)
7. **P2:** Agent-challenge endpoint/model cost clarity (**DISCORD-agent-challenge-endpoints-2026-03-29**)
8. **P2:** Plugin submission/distribution documentation (**DISCORD-plugin-submission-process-2026-03-27**)

---

## Patterns / Themes Indicating Deeper Architectural or Organizational Issues
- **“Agent Commerce” is outrunning governance:** Multiple parallel efforts (Dreamline policy facilitator, Orbis x402 marketplace, Pyrimid MCP commerce) highlight that **payment capability is mature enough to be dangerous** without a standardized preflight/policy/audit layer in core.
- **Onboarding friction clusters at the edges:** CLI install issues (MacOS/bun), unclear agent-challenge model access, and plugin submission ambiguity point to **documentation + packaging** as primary adoption bottlenecks rather than core runtime capability.
- **Community fragmentation amplifies both confusion and risk:** Split Discord spaces + unclear project relationships create information gaps that scammers can exploit and that weaken ecosystem credibility.

---

## Process Improvement Recommendations
1. **Establish an “Ops & CI Ownership” runbook**
   - Single source for billing owners, spending limits, provider dashboards, and escalation steps.
   - Add automated alerting when jobs fail to start (not just fail to run).

2. **Define a core “Payment Governance” extension point**
   - A minimal interface + event lifecycle in core runtime for any x402 payment attempt (preflight → decision → settlement → audit).
   - Require plugins that trigger payments to integrate with this hook (or explicitly opt out with warnings).

3. **Create an “Onboarding Health” checklist per release**
   - Test: MacOS bun install, Linux, Windows (where applicable), plus “hello world” agent creation.
   - Publish known-good versions and troubleshooting steps.

4. **Harden community safety**
   - Pinned “official links & accounts” and a consistent incident response workflow.
   - Rate-limit link posting for new accounts; enhance verification guidance.

5. **Improve ecosystem discoverability via a maintained directory**
   - PR-based listing file (e.g., `ecosystem.yaml`) with ownership fields and relationship labels to prevent drift.