## Issue Triage — 2026-03-15

### 1) Plugin initialization race condition (plugin-sql adapter registered as side-effect; parallel init breaks dependents) — **ID: TBD (create GitHub issue in `elizaos/eliza`)**
- **Current Status:** Reported in Discord; workaround exists in milaidy (manual pre-registration) but root cause unresolved; runtime refactor proposal open for feedback.
- **Impact Assessment:**
  - **User Impact:** **High** (affects any deployment relying on SQL + dependent plugins; failure mode is intermittent/hard to debug)
  - **Functional Impact:** **Yes** (can prevent agents from starting or make behaviors nondeterministic)
  - **Brand Impact:** **High** (race conditions look like “random instability”)
- **Technical Classification:**
  - **Issue Category:** Bug / Architectural
  - **Component Affected:** Core Framework (runtime init), Plugin System, plugin-sql integration
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Runtime architecture, TypeScript/Node concurrency, plugin lifecycle design, dependency injection patterns
  - **Dependencies:** Align with Odilitime’s runtime refactor proposal; may require coordinated changes across core + plugin-sql + any dependent plugins
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Open a GitHub issue capturing the exact failure mode, minimal reproduction, and current milaidy workaround (manual pre-registration).
  2. Define and document a **deterministic plugin lifecycle** (e.g., `registerInfrastructure()` phase strictly ordered before `start()` / `init()`).
  3. Implement **explicit dependency wiring**: make DB adapter a required constructor/runtime arg (no side-effect registration).
  4. Add a runtime validation step: if a plugin declares it needs an adapter, fail fast with actionable error if missing.
  5. Add concurrency tests to catch ordering regressions (CI test that parallel init cannot break adapter availability).
- **Potential Assignees:** **Odilitime** (runtime refactor owner), **s** (identified root cause), core runtime maintainers; consult plugin-sql maintainer if separate.

---

### 2) Migration scam / fake “Support Ticket bot” phishing seed phrases — **ID: TBD (create Security/Incident issue + Discord mod checklist)**
- **Current Status:** Confirmed scam in Discord; users warned ad-hoc; no formal incident runbook noted.
- **Impact Assessment:**
  - **User Impact:** **Critical** (seed phrase compromise = direct loss of funds)
  - **Functional Impact:** **Partial** (not breaking software, but breaks user safety and trust)
  - **Brand Impact:** **High** (public perception risk; security credibility)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Community/Support surface area (Discord), documentation/announcements
  - **Complexity:** **Moderate effort** (process + moderation + comms; some automation)
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation tooling, security comms, incident response, basic automation/bot config
  - **Dependencies:** Coordination with moderators; optionally website/docs update
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Pin an **official migration status + scam warning** message in all relevant Discord channels; include “never share seed phrase” banner.
  2. Publish an “Official links & support policy” page on docs site; link it in Discord server description.
  3. Add a lightweight incident intake: dedicated channel + form for reporting phishing accounts/links; document response steps.
  4. Tighten server settings: limit DMs from new users, increase verification level, enable AutoMod keyword/link filtering for known scam patterns (e.g., “migration help”, “seed phrase”, known domains).
  5. Create a public postmortem-style note (no sensitive data) to reinforce trust and clarify official support boundaries.
- **Potential Assignees:** **Odilitime** (project lead), **sb** (actively advising users), Discord moderators/security-minded contributors.

---

### 3) plugin-ollama embedding failures on Linux — **ID: `elizaos-plugins/plugin-ollama#17`**
- **Current Status:** Open; investigation started (per weekly summary).
- **Impact Assessment:**
  - **User Impact:** **High** (Linux is common for self-hosting; embeddings are core for RAG/search workflows)
  - **Functional Impact:** **Yes** (breaks embedding-dependent features)
  - **Brand Impact:** **Medium** (plugin reliability affects ecosystem trust)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Model Integration / plugin-ollama
  - **Complexity:** **Moderate effort** (env-specific debugging; packaging/runtime differences)
- **Resource Requirements:**
  - **Required Expertise:** Linux runtime debugging, Ollama API behavior, embeddings pipeline, node native deps if any
  - **Dependencies:** Repro steps; version matrix (Ollama version, distro, CPU/GPU)
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a diagnostic template to the issue (OS/distro, Ollama version, model name, logs, expected/actual vectors).
  2. Reproduce in CI (containerized Ubuntu) and add a smoke test for embeddings.
  3. Validate endpoint/response parsing; confirm vector dimensionality and JSON schema across versions.
  4. If dependency-related, publish a pinned compatibility matrix and fallback behavior.
- **Potential Assignees:** plugin-ollama maintainer(s); solicit help from **genife** (Linux + AI systems) if available.

---

### 4) Token migration transparency: completion rate + disposition of unmigrated tokens (burn vs redistribution) — **ID: TBD (create docs/announcement issue)**
- **Current Status:** Unanswered questions recurring in Discord; migration closed (Feb 4, 2026) but transparency gaps remain.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects holders/community; not all developers)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (token distribution clarity is trust-critical)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (communications)
  - **Component Affected:** Docs site, announcements, token migration policy
  - **Complexity:** **Simple fix** (if data available) / **Moderate** (if needs on-chain analysis)
- **Resource Requirements:**
  - **Required Expertise:** On-chain data analysis, token contract knowledge, technical writing
  - **Dependencies:** Access to migration contract data; agreement on policy for unmigrated allocation
  - **Estimated Effort (1-5):** **2-3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish migration stats: total eligible, migrated, remaining (methodology clearly stated).
  2. Publish an explicit policy decision for unmigrated tokens (burn timetable vs treasury vs redistribution), with rationale.
  3. Add a “Migration is closed” canonical page; link it in Discord auto-responses to migration questions.
- **Potential Assignees:** **Odilitime** (policy), a contributor comfortable with on-chain analytics; docs maintainer (**Stan ⚡** for publishing).

---

### 5) Safety/guardrails for on-chain execution in “Milady Prediction” (accuracy thresholds + execution gating) — **ID: TBD (create issue in relevant Milady repo / core integration tracker)**
- **Current Status:** System announced; key question unanswered: targeted prediction accuracy threshold; implies risk if executing on-chain based on probabilities.
- **Impact Assessment:**
  - **User Impact:** **Medium → High** (for users enabling auto-execution; financial risk)
  - **Functional Impact:** **Partial** (feature can exist without auto-exec, but unsafe defaults are dangerous)
  - **Brand Impact:** **High** (loss events harm reputation)
- **Technical Classification:**
  - **Issue Category:** Security / Feature design
  - **Component Affected:** Model Integration + On-chain execution logic + Risk controls
  - **Complexity:** **Complex solution** (metrics + policy + engineering)
- **Resource Requirements:**
  - **Required Expertise:** Quant evaluation, prediction market APIs, on-chain transaction safety, risk engineering
  - **Dependencies:** Defined product intent (informational vs automated execution); wallet safety layer (x402Guard or equivalent)
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define modes: **observe-only** vs **execute**; ship observe-only as default.
  2. Specify gating rules: min confidence, max loss, cooldowns, human confirmation, allowlists.
  3. Establish evaluation protocol: historical backtests + live shadow mode; publish target metrics.
  4. Require transaction policy enforcement (preferably via x402Guard-like proxy) before enabling execute mode.
- **Potential Assignees:** **ElizaBAO** (implementation), **Caesar ⚔️** (requirements/threshold focus), security reviewers; consult **dzik pasnik** for proxy alignment.

---

### 6) Release and standardize DeFi transaction safety layer (x402Guard plugin) — **ID: TBD (create plugin tracking issue + integration checklist)**
- **Current Status:** Announced; planned open-source plugin release “within weeks”; seeking early testers; supports Base + Solana; Rust implementation; uses EIP-7702 session keys.
- **Impact Assessment:**
  - **User Impact:** **Medium** today, **High** as DeFi agents grow
  - **Functional Impact:** **Partial** (not required for all agents, but critical for wallet-enabled agents)
  - **Brand Impact:** **High** (strong security posture differentiates elizaOS)
- **Technical Classification:**
  - **Issue Category:** Security / Feature
  - **Component Affected:** Plugin System, Wallet/Chain integrations
  - **Complexity:** **Complex solution** (cross-chain behavior, policy config, docs)
- **Resource Requirements:**
  - **Required Expertise:** Rust, EVM/Solana transaction policy, key management, plugin packaging, threat modeling
  - **Dependencies:** Plugin API expectations; example integrations; tester cohort
  - **Estimated Effort (1-5):** **4**
- **Recommended Priority:** **P2** (upgrade to **P1** if Milady/other agents are enabling autonomous on-chain execution imminently)
- **Specific Actionable Next Steps:**
  1. Create a public repo + minimal integration guide for elizaOS agents.
  2. Define configuration schema: spend limits, contract allowlists, per-action approvals, session key lifecycle.
  3. Provide sample policies for common DeFi flows; include “deny-by-default” templates.
  4. Recruit early testers from DeFi agent builders; collect failure cases and UX pain points.
- **Potential Assignees:** **dzik pasnik** (author), security-minded plugin maintainers, DeFi agent teams for testing.

---

### 7) Merge cloud documentation PR — **ID: `elizaos/elizaos.github.io#243`**
- **Current Status:** Mentioned as needing merge; cloud-related content pending.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves onboarding and clarity for cloud business model)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (docs freshness matters; reduces repeated Discord questions)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Docs site
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Docs review, light technical editing
  - **Dependencies:** Reviewer availability; ensure alignment with current tokenomics messaging
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Review for accuracy (cloud buybacks, what token benefits, current timelines).
  2. Merge and announce; link from Discord FAQ/pins.
- **Potential Assignees:** **Stan ⚡** (called out PR), docs maintainers.

---

### 8) Standardize `skill.md` agent discovery + telemetry/metrics for adoption — **ID: TBD (create spec + implementation tracker)**
- **Current Status:** Implemented by lightningprox on lightningprox.com and solanaprox.com; asked to monitor traffic metrics.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves agent discoverability and ecosystem growth)
  - **Functional Impact:** **Partial** (workflow improvement; not core runtime)
  - **Brand Impact:** **Low → Medium**
- **Technical Classification:**
  - **Issue Category:** UX / Documentation / Feature enablement
  - **Component Affected:** Agent Registry / Discovery
  - **Complexity:** **Moderate effort** (spec + validation + tooling)
- **Resource Requirements:**
  - **Required Expertise:** Web standards, documentation, registry/orchestration
  - **Dependencies:** Agreement on schema fields; compatibility with agentskills.io/openclaw/Hermes-agent
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a canonical `skill.md` schema and examples (required/optional fields, versioning).
  2. Provide a validator CLI or hosted checker.
  3. Collect adoption metrics (hits, successful discovery, registrations attributable to skill.md).
- **Potential Assignees:** **lightningprox** (already implementing), **Odilitime** (guidance/spec), docs contributors.

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0:** Plugin initialization race condition / adapter side-effect registration (core runtime stability) — **ID: TBD**
2. **P0:** Discord migration phishing/scam mitigation + official support boundaries — **ID: TBD**
3. **P1:** plugin-ollama Linux embedding failures — **plugin-ollama#17**
4. **P1:** Token migration transparency (completion stats + fate of unmigrated tokens) — **ID: TBD**
5. **P1:** Milady Prediction execution safety (thresholds + gating + defaults) — **ID: TBD**
6. **P2:** x402Guard plugin release + tester program (security layer for DeFi agents) — **ID: TBD**
7. **P2:** Merge cloud docs PR — **elizaos.github.io#243**
8. **P2:** Standardize `skill.md` discovery spec + metrics — **ID: TBD**

---

## Patterns / Themes Indicating Deeper Issues
- **Lifecycle and dependency management is underspecified**: side-effect-based registration + parallel init suggests the plugin/runtime contract needs stronger guarantees (ordering, dependency declaration, validation).
- **Security surface is expanding faster than formal guardrails**: wallet-enabled agents, prediction→execution flows, and Discord support vectors (phishing) all need a more explicit security program.
- **Repeated community questions signal missing canonical documentation**: token migration status/policy and cloud/tokenomics explanations are being re-litigated in chat instead of referenced via stable docs.

---

## Process Recommendations (Prevent Recurrence)
1. **Introduce an “RFC + decision record” flow for runtime/plugin lifecycle changes** (short template; merge only with explicit lifecycle contract updates).
2. **Add a security communications playbook**: pinned “official links”, scam response steps, and a lightweight security advisory page; schedule periodic reposts.
3. **Require dependency declarations for plugins** (e.g., “needs DB adapter”, “needs wallet policy provider”) and enforce via runtime preflight checks.
4. **Ship integration smoke tests in CI for major plugins** (e.g., embeddings, DB connectivity) across Linux/macOS baseline matrices.
5. **Create a “Known Answers / Canonical Policies” docs hub** and link it via Discord bot auto-replies for high-frequency questions (migration, tokenomics, official support).