## Issue Triage — 2026-03-18

### 1) Token migration transparency gaps (ai16z → elizaOS) — **DISCORD-2026-03-16-TOKEN-MIGRATION (needs GitHub issue)**
- **Current Status:** Unanswered questions in Discord; no canonical public accounting shared yet.
- **Impact Assessment:**
  - **User Impact:** **Critical** (large holder base; ~100k addresses mentioned)
  - **Functional Impact:** **No** (doesn’t break framework runtime)  
  - **Brand Impact:** **High** (trust/credibility + “where is the supply” narrative)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (communications), Governance
  - **Component Affected:** Ecosystem / Token migration ops
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Onchain analytics, tokenomics, project ops/comms
  - **Dependencies:** Access to official migration contracts/wallets; confirmed “team addresses”
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish a **single source-of-truth** post (docs + pinned Discord + X) with: migration contract(s), snapshot rules, timeline, and “team-controlled” addresses.
  2. Provide **current migration metrics**: migrated supply, remaining allocation, and methodology (Dune dashboard or reproducible script).
  3. Explicit policy statement for **unmigrated community allocation** (burn? treasury? extended window? redistribution?).
  4. Add an FAQ entry to docs: “How to verify migration status” + “How to migrate safely.”
- **Potential Assignees:** **Shaw** (final sign-off), **Odilitime** (comms + coordination), a data volunteer (e.g., **truebrujah**) for dashboard/scripts.

---

### 2) Google Form role assignment broken (“Invalid Dynamic Link”) — **DISCORD-2026-03-17-ROLE-DYNAMIC-LINK (needs GitHub issue)**
- **Current Status:** Reported in `#coders`; no fix or workaround posted.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks onboarding + role-gated channels/resources)
  - **Functional Impact:** **Partial** (community ops, not core runtime)
  - **Brand Impact:** **Medium** (first-run experience feels broken)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Community Ops Tooling (Forms + Firebase Dynamic Links or equivalent)
  - **Complexity:** Simple fix (likely config), could be Moderate if link-generation pipeline is custom
- **Resource Requirements:**
  - **Required Expertise:** Firebase Dynamic Links / URL routing; basic web ops
  - **Dependencies:** Admin access to the Dynamic Links domain/project settings
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Identify the Dynamic Link provider (Firebase presumed): confirm **Dynamic Links domain** configured and verified.
  2. Validate the **deep link URL** is properly encoded (no invalid path components; correct scheme).
  3. Regenerate the invite/role links; test on desktop + mobile; post a **temporary fallback** (manual role request workflow) until fixed.
  4. Add a small health-check: “role link status” page or monitored shortlink endpoint.
- **Potential Assignees:** **Inhuman Resources** (community admin access), **Odilitime** (coordination), **truebrujah** (implementation support).

---

### 3) Linux embedding failures in Ollama plugin — **elizaos-plugins/plugin-ollama#17**
- **Current Status:** “Investigating” per weekly summary; likely still open.
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for dev/servers; embeddings power RAG/search)
  - **Functional Impact:** **Partial** (blocks embedding/RAG workflows; chat may still work)
  - **Brand Impact:** **Medium** (perceived instability of model integrations)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / Plugin System (`plugin-ollama`)
  - **Complexity:** Moderate effort (OS-specific + dependency differences)
- **Resource Requirements:**
  - **Required Expertise:** Node/TS debugging, Linux envs, Ollama embeddings API specifics
  - **Dependencies:** Repro steps + environment matrix (distro, libc, GPU/CPU, Ollama version)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Require a minimal reproduction: exact model, Ollama version, plugin version, and request payload.
  2. Add CI smoke test (containerized) that runs an embeddings call on Linux.
  3. Confirm whether failures are due to: response parsing, endpoint mismatch, or binary/library differences.
  4. Ship a patch release and document supported Ollama versions.
- **Potential Assignees:** `plugin-ollama` maintainer(s), **truebrujah** (Linux + full-stack), plus a core reviewer from **Odilitime**’s circle.

---

### 4) v2.0.0 skills governance / default skills policy decision — **PR elizaos/eliza#6597 + DISCORD-2026-03-16-SKILLS-POLICY**
- **Current Status:** PR introduced; open architectural question: ship with **0 default skills** vs curated bundle.
- **Impact Assessment:**
  - **User Impact:** **High** (affects out-of-box experience and ecosystem quality)
  - **Functional Impact:** **Yes** (changes how users discover/use skills in v2)
  - **Brand Impact:** **High** (either “bloat/chaos” or “empty product” if mishandled)
- **Technical Classification:**
  - **Issue Category:** Architectural / UX
  - **Component Affected:** Core Framework + Skills system
  - **Complexity:** Architectural change (policy + tooling + docs)
- **Resource Requirements:**
  - **Required Expertise:** Core maintainers, ecosystem governance, docs
  - **Dependencies:** Decision on discovery mechanism (`skills.md` format + hosting + verification)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Decide and document a v2 policy: **(A)** zero default skills + discovery, or **(B)** small curated “blessed” set.
  2. Define `skills.md` schema (name, version, permissions, maintainer, source, checksum/signature).
  3. Add acceptance criteria for any “official” skill listing (security review, maintenance SLA).
  4. Merge PR #6597 only after docs + migration notes are ready.
- **Potential Assignees:** **Odilitime** (architectural owner), **Stan** (registry/discovery alignment), a docs maintainer.

---

### 5) plugin-evm: open issues + goldrush.dev integration for 100+ onchain data sources — **DISCORD-2026-03-16-PLUGIN-EVM-GOLDRUSH (needs GitHub issues/PR links)**
- **Current Status:** In progress per dinesh; unspecified open issues remain.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (web3 agents are a key use case; data breadth matters)
  - **Functional Impact:** **Partial** (depends on which open issues; could block EVM workflows)
  - **Brand Impact:** **Medium** (plugin ecosystem reliability)
- **Technical Classification:**
  - **Issue Category:** Bug + Feature
  - **Component Affected:** Plugin System / EVM integrations
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** EVM, plugin architecture, API integration, testing
  - **Dependencies:** goldrush.dev API limits/keys; plugin-evm issue list triage
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert “open issues” into an explicit checklist (link each GitHub issue).
  2. Add contract tests for the top 10 most-used data endpoints.
  3. Ensure secrets management and rate-limit handling are standardized across plugins.
  4. Publish a compatibility note: supported chains, required env vars, and example agent recipes.
- **Potential Assignees:** **dinesh** (primary), a reviewer from core plugins team, **truebrujah** (testing/DevOps help).

---

### 6) Clarify which Milady chain is supported (SOL vs BSC) — **DISCORD-2026-03-17-MILADY-CHAIN-SUPPORT (needs docs ticket)**
- **Current Status:** Asked repeatedly; unanswered.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects users trying to participate/understand strategy)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (confusion fuels “lack of direction” sentiment)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Docs / Communications
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Product/strategy knowledge; comms
  - **Dependencies:** Definitive internal decision from leadership
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Get an authoritative answer from **Shaw**.
  2. Update docs + pin a Discord message: “Official Milady support: chain(s), contract(s), and links.”
  3. Add a short “How this relates to elizacloud → elizaOS flywheel” explainer to reduce recurring questions.
- **Potential Assignees:** **Shaw** (source of truth), **Odilitime** (publication), **Inhuman Resources** (pin/moderation).

---

### 7) Elizacloud launch readiness (end-of-week/early-next-week target) — **DISCORD-2026-03-17-ELIZACLOUD-LAUNCH (needs release tracker)**
- **Current Status:** Announced target; launch checklist not visible.
- **Impact Assessment:**
  - **User Impact:** **High** (drives adoption + utility narrative)
  - **Functional Impact:** **Partial** (not core framework, but strategic distribution channel)
  - **Brand Impact:** **High** (missed targets amplify token/community frustration)
- **Technical Classification:**
  - **Issue Category:** Release / UX / Reliability
  - **Component Affected:** Product / API / Ops
  - **Complexity:** Complex solution (depends on product scope)
- **Resource Requirements:**
  - **Required Expertise:** Backend, infra, auth/billing (if any), QA, comms
  - **Dependencies:** Scope definition + launch criteria; monitoring and rollback plan
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a public/internal **launch tracker**: P0 blockers, owners, dates.
  2. Define “launch” (beta? limited access?) and publish onboarding steps.
  3. Add minimum monitoring: uptime, latency, error rates, signup funnel.
  4. Prepare a post-launch incident response plan + status page.
- **Potential Assignees:** **Odilitime** (program owner), core infra maintainers, **Stan** (ecosystem alignment).

---

### 8) Skills + plugins unified directory/registry (Clawhub-style) — **DISCORD-2026-03-17-UNIFIED-DIRECTORY**
- **Current Status:** Proposed; Stan supportive; no spec.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves discovery and reduces fragmentation)
  - **Functional Impact:** **Partial** (workflow friction; not runtime blocker)
  - **Brand Impact:** **Medium** (ecosystem polish)
- **Technical Classification:**
  - **Issue Category:** Feature Request / UX
  - **Component Affected:** Plugin System + Skills discovery + Web UI (if any)
  - **Complexity:** Architectural change
- **Resource Requirements:**
  - **Required Expertise:** Registry design, metadata schemas, web/catalog UX, moderation workflow
  - **Dependencies:** Decision from Issue #4 (skills policy), existing `elizaos-plugins/registry` constraints
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Draft a unified metadata model (plugins + skills) and ingestion flow.
  2. Decide whether this extends `elizaos-plugins/registry` or becomes a new service/site.
  3. Specify governance: verification, ranking, deprecation, security flags.
  4. Build an MVP: searchable index + install instructions + compatibility badges.
- **Potential Assignees:** **Stan** (product/structure), **Odilitime** (architecture), community contributor(s) like **truebrujah** for web UI/API.

---

### 9) “unbrowse” high-speed agent browser integration as plugin — **DISCORD-2026-03-17-UNBROWSE-PLUGIN**
- **Current Status:** Integration guidance provided; plugin not yet delivered.
- **Impact Assessment:**
  - **User Impact:** **Medium** (valuable capability; not required for baseline)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low–Medium** (innovation signal; ecosystem momentum)
- **Technical Classification:**
  - **Issue Category:** Feature Request
  - **Component Affected:** Plugin System / Tooling
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Plugin authoring, web APIs, indexing, performance
  - **Dependencies:** Plugin registry packaging rules; security review (web access)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a plugin skeleton PR (scaffold + minimal “fetch API map” tool).
  2. Define security boundaries: allowed domains, request caps, PII handling.
  3. Add example agent recipe + benchmarks (why “100x speed” in practice).
  4. Submit to `elizaos-plugins/registry` once stable.
- **Potential Assignees:** **lekt9** (primary implementer), **Odilitime** (review/guidance), a security-minded reviewer.

---

### 10) Lack of an admin/ticket support channel for user issues — **DISCORD-2026-03-17-TICKET-CHANNEL**
- **Current Status:** Asked; unanswered.
- **Impact Assessment:**
  - **User Impact:** **Medium** (support friction; issues linger)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (appears unresponsive/chaotic)
- **Technical Classification:**
  - **Issue Category:** UX / Process
  - **Component Affected:** Community operations
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling (e.g., ticket bot)
  - **Dependencies:** Mod bandwidth; escalation rules
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Decide support model: ticket bot vs dedicated `#support` channel with templates.
  2. Publish escalation paths (security, billing/elizacloud, dev support).
  3. Add a “Known Issues” pinned post to deflect repeats (e.g., role link outage).
- **Potential Assignees:** **Inhuman Resources** (server ops), **Odilitime** (policy), volunteer mods.

---

## Top Highest-Priority Issues (address immediately)
1. **P0:** Token migration transparency gaps — **DISCORD-2026-03-16-TOKEN-MIGRATION**
2. **P0:** Role assignment Google Form Dynamic Link broken — **DISCORD-2026-03-17-ROLE-DYNAMIC-LINK**
3. **P1:** Ollama plugin embeddings failing on Linux — **plugin-ollama#17**
4. **P1:** v2.0.0 skills governance + PR #6597 decision path — **eliza#6597 + policy**
5. **P1:** plugin-evm open issues + goldrush.dev integration — **DISCORD-2026-03-16-PLUGIN-EVM-GOLDRUSH**
6. **P1:** Clarify Milady chain support (SOL vs BSC) — **DISCORD-2026-03-17-MILADY-CHAIN-SUPPORT**
7. **P1:** Elizacloud launch readiness tracking — **DISCORD-2026-03-17-ELIZACLOUD-LAUNCH**

---

## Patterns / Themes Suggesting Deeper Issues
- **“No canonical source of truth” problem:** Repeated unanswered questions (migration stats, Milady chain support, support channel) indicate missing centralized, maintained documentation + pinned comms.
- **Onboarding friction:** Broken role assignment + lack of ticketing/support path degrade first-time contributor/user conversion.
- **Ecosystem governance scaling pains:** Skills/plugins growth is outpacing curation and discovery mechanisms; v2 skills policy and a unified directory are symptoms of the same scaling challenge.
- **Integration quality variance across plugins:** Linux embedding failures and “open issues” in plugin-evm point to inconsistent CI/testing standards for plugins.

---

## Recommendations (Process Improvements)
1. **Create an “Ops & Trust” release lane** (weekly): migration/accounting updates, product launch status, and pinned FAQs—owned by a named DRI.
2. **Enforce plugin quality gates:** minimal CI matrix (Linux/macOS), smoke tests for core actions (embeddings, auth, rate-limit handling), and standardized env var validation.
3. **Adopt a “Decision Record” (ADR) habit for v2 architecture:** short ADRs for skills policy, discovery model, and governance—linked from docs and PR descriptions.
4. **Add lightweight support intake:** a ticket bot or structured `#support` channel + “Known Issues” board to prevent repeated Discord churn and lost reports.
5. **Convert Discord action items into GitHub issues within 24 hours:** assign IDs, owners, and acceptance criteria so high-impact community blockers don’t stall in chat.