## Issue Triage — 2026-03-19

### 1) Token migration transparency gaps (ai16z → elizaOS) — ID: DISCORD-2026-03-16-TOKEN-MIGRATION
- **Current Status:** Reported in Discord; unanswered/undocumented (no canonical public breakdown yet).
- **Impact Assessment:**
  - **User Impact:** **Critical** (large holder base; reported ~100k addresses still holding ai16z; confusion around supply/accounting).
  - **Functional Impact:** **No** (does not break runtime), but blocks community operations and decision-making.
  - **Brand Impact:** **High** (trust/transparency risk; fuels ongoing community tension).
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (communications), Governance/Tokenomics (non-code but project-critical)
  - **Component Affected:** Project Communications, Tokenomics reporting
  - **Complexity:** Moderate effort (data gathering + publish + ongoing updates)
- **Resource Requirements:**
  - **Required Expertise:** On-chain analytics, treasury/tokenomics knowledge, ability to verify official team addresses, comms writing
  - **Dependencies:** Access to migration contract data, team wallets, any custodied migration addresses; alignment with legal/compliance if applicable
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish an official “Migration Transparency” post: migration % to date, total eligible supply, remaining allocation, and treatment of unmigrated community tokens.
  2. Provide a verified list of official team/migration addresses used for tracking (or a signed attestation).
  3. Add a living dashboard (Dune/Flipside or self-hosted) linked from docs.elizaos.ai.
  4. Open a GitHub “Tokenomics Transparency” tracking issue to centralize updates and questions.
- **Potential Assignees:** Odilitime (project lead), core ops/treasury contributor (TBD), community analytics volunteer (recruit from Discord), Stan (coordination)

---

### 2) Role assignment onboarding broken (“Invalid Dynamic Link” in Google Form flow) — ID: DISCORD-2026-03-17-ROLE-DYNAMIC-LINK
- **Current Status:** Reported in Discord; unresolved.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks new users from getting roles/access; affects broad onboarding).
  - **Functional Impact:** **Partial** (Discord access/workflow impaired; not core runtime).
  - **Brand Impact:** **Medium** (new-user friction signals poor operational quality).
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Community Ops tooling (Google Forms + Dynamic Links + Discord role automation)
  - **Complexity:** Simple fix (likely config) to Moderate (if automation pipeline needs changes)
- **Resource Requirements:**
  - **Required Expertise:** Firebase Dynamic Links / Google link configuration, Discord role bots/automation (e.g., Zapier/Make/custom bot)
  - **Dependencies:** Admin access to Google/Firebase project + Discord automation settings
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce error with a fresh invite/session and capture the failing URL + redirect chain.
  2. Verify Dynamic Links domain configuration and allowed URL patterns; rotate/regenerate links if needed.
  3. Add a fallback manual role request path (temporary) and pin it in onboarding channels.
  4. After fix, add a lightweight monitoring check (weekly link test + alert if redirect fails).
- **Potential Assignees:** Inhuman Resources (community ops), Odilitime (if infra access), Discord mods with admin permissions (TBD)

---

### 3) Form plugin rename/standardization may introduce breaking changes — ID: DISCORD-2026-03-18-XFN-PLUGIN-RENAME
- **Current Status:** Change announced: `plugin-form` → `plugin-form-chain`, `plugin-forms` → `plugin-form`; registry updated.
- **Impact Assessment:**
  - **User Impact:** **High** (plugin consumers may break on install/import; common in JS ecosystems).
  - **Functional Impact:** **Partial** (breaks projects relying on old package names).
  - **Brand Impact:** **Medium** (perceived instability if migrations aren’t smooth).
- **Technical Classification:**
  - **Issue Category:** Bug (compatibility) / Documentation
  - **Component Affected:** Plugin System, Registry, xfn-framework packaging
  - **Complexity:** Moderate effort (deprecation strategy, shims, release notes)
- **Resource Requirements:**
  - **Required Expertise:** npm packaging, semver/release management, registry maintenance
  - **Dependencies:** Registry CI, published package ownership, docs updates
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a migration note with exact rename mapping + code examples (import paths, config keys).
  2. If possible, ship compatibility “stub” packages that depend on/re-export the new packages (deprecate old names with warnings).
  3. Update registry entries, docs, and any templates/starters referencing old names.
  4. Add an automated check in registry CI to detect renamed packages and require a migration note.
- **Potential Assignees:** Odilitime (framework), Stan (registry coordination), a maintainer with npm publish rights (TBD)

---

### 4) Linux embedding failures in Ollama plugin — Issue: elizaos-plugins/plugin-ollama #17
- **Current Status:** Community-reported; “investigating” per latest weekly summary.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Linux is common for self-hosting; embeddings are core to RAG/memory).
  - **Functional Impact:** **Yes** for embedding-dependent features (RAG, semantic memory, retrieval).
  - **Brand Impact:** **Medium** (self-host reliability is a key expectation).
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration (Ollama plugin), Embeddings pipeline
  - **Complexity:** Moderate effort (environment-specific; could be binary/library/API mismatch)
- **Resource Requirements:**
  - **Required Expertise:** Node/TS plugin dev, Ollama API specifics, Linux env debugging (glibc, networking, file paths)
  - **Dependencies:** Repro steps + affected distro details; ollama version matrix
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Establish a CI repro (containerized Ubuntu) running a minimal embedding call test.
  2. Collect matrix: ollama versions, models used for embedding, Linux distro/kernel, CPU vs GPU.
  3. Add improved error surfacing (response body, status codes, timeout hints).
  4. Patch + release plugin version; document known-good versions.
- **Potential Assignees:** Plugin-ollama maintainers (TBD), core integrators familiar with model adapters, community Linux maintainer (recruit)

---

### 5) v2.0.0 “skills folder” governance + spam/bloat prevention decision — PR: elizaos/eliza #6597
- **Current Status:** PR introduced; open architectural question: ship v2 with **0 default skills** and push discovery to external `yourdomains.com/skills.md`.
- **Impact Assessment:**
  - **User Impact:** **High** (affects onboarding experience and ecosystem discoverability).
  - **Functional Impact:** **Partial** (core works, but “out-of-the-box utility” may drop without defaults).
  - **Brand Impact:** **High** (v2 expectations; risk of “empty framework” perception vs. “clean core” benefits).
- **Technical Classification:**
  - **Issue Category:** Architectural change / UX / Documentation
  - **Component Affected:** Core Framework (skills subsystem), Distribution/Discovery model
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Core architecture, security/review pipeline design, documentation + developer experience
  - **Dependencies:** Plugin/skills registry strategy; moderation policy; agreed format for `skills.md`
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define the “skills supply chain”: submission, review, signing/verification (if any), and deprecation.
  2. Decide “minimum starter set” vs “zero skills” and how new users bootstrap.
  3. Write a formal spec for `skills.md` (schema, hosting, versioning, trust signals).
  4. Add a reference “curated list” maintained by core team to avoid zero-utility first-run.
- **Potential Assignees:** Odilitime (core), Stan (ecosystem/registry), senior community contributors with DX focus (e.g., truebrujah as volunteer reviewer if aligned)

---

### 6) plugin-evm open issues + large goldrush.dev expansion (100+ onchain data sources) — ID: DISCORD-2026-03-16-PLUGIN-EVM-GOLDRUSH
- **Current Status:** In progress (per dinesh); “fixing open issues” plus major capability expansion.
- **Impact Assessment:**
  - **User Impact:** **Medium** (Web3 users; onchain data is a key differentiator but not universal).
  - **Functional Impact:** **Partial** (existing users may be blocked by current open issues; expansion adds value).
  - **Brand Impact:** **Medium** (quality of Web3 integrations affects ecosystem credibility).
- **Technical Classification:**
  - **Issue Category:** Bug / Feature
  - **Component Affected:** Plugin System (plugin-evm), Data Integrations
  - **Complexity:** Moderate effort (API integration + test coverage + bugfixes)
- **Resource Requirements:**
  - **Required Expertise:** EVM indexing/data APIs, TypeScript, rate limiting/caching
  - **Dependencies:** goldrush.dev API keys/quotas; testnets/mainnets; plugin-evm issue list (needs consolidation)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Convert “open issues” into a prioritized checklist (top 3 bugs blocking usage first).
  2. Add integration tests with mocked goldrush responses + one live smoke test.
  3. Document supported chains/data endpoints and expected cost/rate limits.
- **Potential Assignees:** dinesh (primary), Web3 plugin maintainers (TBD)

---

### 7) Ensoul persistence plugin adoption: security review + integration guidance — ID: DISCORD-2026-03-18-ENSOUL-PERSISTENCE
- **Current Status:** Newly announced (`@ensoul-network/plugin-elizaos`); request for testing/feedback.
- **Impact Assessment:**
  - **User Impact:** **Medium** (valuable for long-lived agents; not mandatory for all deployments).
  - **Functional Impact:** **No** (optional), but touches sensitive “memory/identity” paths.
  - **Brand Impact:** **High** if compromised/misrepresented (identity + encrypted persistence claims).
- **Technical Classification:**
  - **Issue Category:** Security / Feature / Documentation
  - **Component Affected:** Plugin System, Persistence layer, Agent identity/memory handling
  - **Complexity:** Complex solution (crypto, key management, failure modes)
- **Resource Requirements:**
  - **Required Expertise:** Cryptography/key management, threat modeling, storage/recovery reliability, plugin API internals
  - **Dependencies:** Clear interface contracts for memory export/import; compatibility with v2 skills/persistence architecture
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (upgrade to P1 if core team endorses it as “official/default persistence”)
- **Specific Actionable Next Steps:**
  1. Run a lightweight threat model: key custody, replay/impersonation, shard availability, tamper detection.
  2. Validate data lifecycle: what exactly is extracted, how consent/config works, and how users can delete/rotate.
  3. Create an “integration recipe” in docs: minimal setup + recovery drill + failure handling.
  4. Establish a compatibility badge process in registry (security-reviewed vs community plugin).
- **Potential Assignees:** DiamondRock-JD (author), core security-minded maintainer (TBD), Odilitime (plugin API alignment)

---

### 8) Unanswered chain support clarification for Milady (SOL vs BSC) — ID: DISCORD-2026-03-17-MILADY-CHAIN-DOC
- **Current Status:** Asked repeatedly; not answered in-thread.
- **Impact Assessment:**
  - **User Impact:** **Medium** (confusion impacts users trying to participate/use the correct network).
  - **Functional Impact:** **No** (not framework runtime), but affects product onboarding.
  - **Brand Impact:** **High** (perceived disorganization + fuels community frustration).
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Product docs/comms (Milady + ecosystem positioning)
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Product owner clarity, release/marketing alignment
  - **Dependencies:** Confirm authoritative chain(s) and official contract/app endpoints
  - **Estimated Effort:** **1/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a single canonical statement: supported chain(s), official links, and how it relates to elizacloud/elizaOS.
  2. Pin message in Discord + add to docs/FAQ.
- **Potential Assignees:** Odilitime, ElizaBAO (community comms), Shaw (if product owner)

---

## Top Priority Summary (address immediately: next 24–72 hours)
1. **P0 — Token migration transparency gaps** (DISCORD-2026-03-16-TOKEN-MIGRATION)
2. **P1 — Role assignment onboarding broken (Invalid Dynamic Link)** (DISCORD-2026-03-17-ROLE-DYNAMIC-LINK)
3. **P1 — Plugin rename compatibility/migration handling** (DISCORD-2026-03-18-XFN-PLUGIN-RENAME)
4. **P1 — Ollama embeddings failing on Linux** (plugin-ollama #17)
5. **P1 — v2.0.0 skills governance decision + PR #6597 direction** (elizaos/eliza #6597)
6. **P2 — plugin-evm bugfixes + goldrush.dev integration** (DISCORD-2026-03-16-PLUGIN-EVM-GOLDRUSH)
7. **P2 — Ensoul persistence plugin security review + official guidance** (DISCORD-2026-03-18-ENSOUL-PERSISTENCE)
8. **P2 — Clarify Milady chain support (SOL vs BSC)** (DISCORD-2026-03-17-MILADY-CHAIN-DOC)

---

## Patterns / Themes Indicating Deeper Architectural or Operational Problems
- **Ecosystem change management gaps:** Package renames and evolving plugin/skills distribution are happening without a clearly enforced migration/deprecation policy (risk of repeated breaking changes).
- **Onboarding and DX fragility:** Both the Discord role flow and “skills discovery” direction point to a need for a more reliable, unified onboarding funnel (new users currently depend on brittle external tooling and tribal knowledge).
- **Trust + identity are becoming core concerns:** Ensoul persistence, SAID/Z1N-style identity, and token migration transparency all converge on “verifiability” and “continuity”—areas that benefit from explicit specs and security posture, not ad-hoc integrations.

---

## Process Improvement Recommendations
1. **Adopt a formal “Breaking Change Protocol”** for plugins/packages:
   - Deprecation window, stub packages, migration docs required, and a registry CI check to block silent renames.
2. **Create a single public “Status & Transparency” hub** (docs page + dashboard links):
   - Token migration metrics, releases, known incidents (e.g., onboarding outages), and ETA windows.
3. **Add a lightweight release readiness checklist for launches (Milady/Babylon/elizacloud):**
   - Canonical chain/support statement, official links, FAQ, and incident contact path.
4. **CI-based cross-platform smoke tests for key integrations:**
   - At minimum: Linux embedding test for plugin-ollama; basic plugin install/import tests for renamed packages.
5. **Turn recurring Discord-reported blockers into GitHub issues within 24 hours:**
   - Assign owner, label severity, and link back to the originating thread for context.