## Issue Triage — 2026-03-13

### 1) Plugin initialization race condition: `plugin-sql` adapter registered as `init()` side-effect (breaks dependent plugins)
- **Issue Title & ID**: Plugin init race: `plugin-sql` DB adapter not available when other plugins start (DISC-xfn-framework-2026-03-12)
- **Current Status**: **Open / confirmed in Discord**; workaround exists in *milaidy* (manual pre-registration) but root cause unresolved.
- **Impact Assessment**
  - **User Impact**: **High** (hits any runtime using SQL + other plugins that expect adapter)
  - **Functional Impact**: **Yes** (can break startup / DB-backed features nondeterministically)
  - **Brand Impact**: **High** (random startup failures look like low-quality core)
- **Technical Classification**
  - **Category**: Bug / Architecture
  - **Component**: **Plugin System + Core Runtime initialization**
  - **Complexity**: **Architectural change** (requires changing how infra dependencies are provided)
- **Resource Requirements**
  - **Required Expertise**: TypeScript, concurrency/init ordering, dependency injection patterns, runtime architecture
  - **Dependencies**: Tied to the runtime refactor proposal (see next issue)
  - **Estimated Effort**: **4/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Create a tracking issue in `elizaos/eliza` describing the race + reproduction (parallel plugin init).
  2. Decide and implement a single canonical rule: **infra dependencies cannot be registered via plugin side-effects**.
  3. Make DB adapter an explicit dependency (constructor arg or runtime config), and enforce at compile/runtime with validation.
  4. Add an integration test: run plugin init in parallel repeatedly (N=100) to detect nondeterminism.
  5. Remove the *milaidy* workaround once fixed; document the new contract for plugin authors.
- **Potential Assignees**
  - **Odilitime** (runtime refactor owner)
  - **s** (identified/diagnosed design flaw, API-impact focused)
  - Support: **Stan ⚡** (monorepo integration), **BinaryCookies** (Milady DB integration context)

---

### 2) `AgentRuntime` “god object” (~6,273 LOC) and runtime setup logic entanglement (blocks maintainability + safe plugin lifecycle)
- **Issue Title & ID**: Runtime refactor: externalize runtime components; split setup logic out of runtime (DISC-xfn-framework-2026-03-12 / HackMD proposal)
- **Current Status**: **Proposed**; **feedback deadline Sunday**; implementation pending.
- **Impact Assessment**
  - **User Impact**: **Medium → High** (indirect, but drives regressions and slows fixes)
  - **Functional Impact**: **Partial** (core works, but causes cascading issues like init races)
  - **Brand Impact**: **High** (architecture concerns visible to contributors; slows ecosystem)
- **Technical Classification**
  - **Category**: Architecture / Performance (developer productivity) / Reliability
  - **Component**: **Core Framework Runtime**
  - **Complexity**: **Architectural change**
- **Resource Requirements**
  - **Required Expertise**: Systems design, TS refactors, API design, plugin lifecycle modeling
  - **Dependencies**: Must coordinate with plugin init fix (P0 above) to avoid duplicative work
  - **Estimated Effort**: **5/5**
- **Recommended Priority**: **P1** (start now; deliver incrementally)
- **Specific Actionable Next Steps**
  1. Convert the proposal into a GitHub epic with milestones: “runtime components,” “init lifecycle,” “adapter injection,” “compat layer.”
  2. Identify the minimal public API surface to keep stable; add a deprecation policy for breaking changes.
  3. Implement a compatibility shim so existing plugins keep working while the new lifecycle is introduced.
  4. Add instrumentation: log plugin init start/end times and dependency readiness to catch future races.
- **Potential Assignees**
  - **Odilitime** (primary)
  - **s** (API minimization reviewer)
  - Support: **Stan ⚡** (integration), **genife** (new contributor with orchestration/RAG background)

---

### 3) Security incident: fake “support ticket bot” phishing users for seed phrases (token migration context)
- **Issue Title & ID**: Discord phishing/scam bot impersonating support; directing to seed-phrase site (DISC-coders-2026-03-12)
- **Current Status**: **Active threat observed**; manual warnings issued; no documented hardening actions listed.
- **Impact Assessment**
  - **User Impact**: **Critical** (wallet compromise risk)
  - **Functional Impact**: **No** (not a code failure, but user safety is impacted)
  - **Brand Impact**: **High** (loss-of-funds incidents severely damage trust)
- **Technical Classification**
  - **Category**: Security / UX (trust & safety)
  - **Component**: **Community/Discord Operations** (and official comms surfaces)
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Discord admin/security, incident response, comms
  - **Dependencies**: Requires coordinated mod/admin permissions + announcement channels
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Pin a permanent “Never share seed phrase” + “Official links” message in key channels.
  2. Enable/raise AutoMod rules: block common phishing domains/keywords; restrict new accounts DMing.
  3. Create an “official support” process: one verified bot or form; publish verification steps.
  4. Post-incident playbook: where to report, how to verify staff, how to revoke compromised wallets.
- **Potential Assignees**
  - **Odilitime** (public warning + coordination)
  - **satsbased** (community ops)
  - Support: Discord moderators (not named in dataset)

---

### 4) `develop` branch reported broken, blocking planned work and releases
- **Issue Title & ID**: `develop` branch broken / next version of elizaOS blocked (DISC-2026-03-10)
- **Current Status**: **Known issue**; no fix details in log.
- **Impact Assessment**
  - **User Impact**: **High** (contributors and early adopters cannot track a working head)
  - **Functional Impact**: **Yes** (blocks integration, CI confidence, downstream tasks)
  - **Brand Impact**: **Medium → High** (signals instability)
- **Technical Classification**
  - **Category**: Bug / Build-Release
  - **Component**: **Core Framework + CI**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: CI/CD, TypeScript build tooling, monorepo dependency management
  - **Dependencies**: May be related to ongoing v2.0.0 alpha work and refactors
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Add a CI “branch health” gate: green build/test required for `develop`.
  2. Bisect to the breaking commit; patch or revert with a short-lived hotfix branch.
  3. Publish a known-good tag/commit SHA for integrators until `develop` is restored.
- **Potential Assignees**
  - **Odilitime**
  - **Stan ⚡** (build/monorepo integration support)

---

### 5) `plugin-ollama` embedding failures on Linux environments
- **Issue Title & ID**: Embeddings failing on Linux (`plugin-ollama` Issue **#17**)
- **Current Status**: **Open / investigating** (from weekly summary reference).
- **Impact Assessment**
  - **User Impact**: **High** (Linux is common for self-hosting; embeddings are core to RAG)
  - **Functional Impact**: **Partial → Yes** (RAG/memory/search features fail)
  - **Brand Impact**: **Medium** (self-hosters are core advocates)
- **Technical Classification**
  - **Category**: Bug / Compatibility
  - **Component**: **Model Integration (Ollama embeddings)**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Node native deps, Ollama API, Linux env debugging, CI matrix
  - **Dependencies**: Need reproducible env + version matrix (distro, libc, node)
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Reproduce with GitHub Actions Linux matrix (ubuntu-latest + pinned versions).
  2. Collect logs: request/response payloads, model name, Ollama version, node version.
  3. Add a fallback path or clearer error messaging when embeddings endpoint unavailable.
  4. Document Linux prerequisites in plugin README once root cause found.
- **Potential Assignees**
  - Maintainer(s) of `elizaos-plugins/plugin-ollama` (not named)
  - Support: **genife** (systems debugging), **Odilitime** (integration guidance)

---

### 6) Milady: unresolved system permissions/capabilities issues during Neon DB integration
- **Issue Title & ID**: Milady Neon DB integration blocked by permissions/capabilities (DISC-coders-2026-03-10)
- **Current Status**: **Open**; config location found; permissions unresolved.
- **Impact Assessment**
  - **User Impact**: **Medium → High** (Milady app launch is near-term; DB connectivity is core)
  - **Functional Impact**: **Yes** (blocks DB-backed functionality)
  - **Brand Impact**: **High** (Milady launch is public-facing)
- **Technical Classification**
  - **Category**: Bug / Configuration / DevOps
  - **Component**: **Milady App + DB Integration**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Postgres/Neon, env/config management, auth/roles, deployment permissions
  - **Dependencies**: Depends on final runtime/plugin-sql adapter approach
  - **Estimated Effort**: **3/5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Define the required DB permissions (schema create? migrations? read/write tables?).
  2. Add a startup self-check that validates DB privileges and prints actionable remediation.
  3. Provide a reference Neon setup guide + least-privilege SQL role script.
- **Potential Assignees**
  - **BinaryCookies** (already working on it)
  - Support: **Odilitime**, **s**

---

### 7) Token migration support load + ambiguity: “permanently closed” vs “maybe reopen” list
- **Issue Title & ID**: Token migration process ambiguity and support handling (DISC-2026-03-12)
- **Current Status**: **Ongoing support requests**; ad-hoc “affected users list”; reopen attempts unsuccessful.
- **Impact Assessment**
  - **User Impact**: **Medium** (subset of users, but emotionally/high-stakes)
  - **Functional Impact**: **No** (not framework functionality)
  - **Brand Impact**: **High** (perceived fairness and trust)
- **Technical Classification**
  - **Category**: UX / Documentation / Ops
  - **Component**: **Project Ops / Comms**
  - **Complexity**: **Simple fix** (policy + messaging), **Moderate** if tooling needed
- **Resource Requirements**
  - **Required Expertise**: Community ops, documentation, possibly lightweight web form tooling
  - **Dependencies**: Requires definitive policy from token admins
  - **Estimated Effort**: **2/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Publish a single canonical migration status page (closed, exact end time, no DMs).
  2. If collecting “affected users,” use a secure form and state clearly it’s **not a promise**.
  3. Add anti-scam warnings specifically tied to migration keywords (“seed phrase never needed”).
- **Potential Assignees**
  - **Odilitime**
  - Support: **satsbased** (community messaging)

---

### 8) Documentation / site update: cloud content PR pending
- **Issue Title & ID**: `elizaos.github.io` cloud content update (PR **#243**)
- **Current Status**: **Open PR**; requested to merge now that cloud is public.
- **Impact Assessment**
  - **User Impact**: **Medium** (improves onboarding and reduces repeated questions)
  - **Functional Impact**: **No**
  - **Brand Impact**: **Medium** (public docs are the “front door”)
- **Technical Classification**
  - **Category**: Documentation
  - **Component**: **Website / Docs**
  - **Complexity**: **Simple fix**
- **Resource Requirements**
  - **Required Expertise**: Docs review, cloud architecture knowledge for correctness
  - **Dependencies**: Ensure alignment with current cloud repo/public messaging
  - **Estimated Effort**: **1/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Do a fast technical accuracy review (links, repository names, auth assumptions).
  2. Merge; then add a follow-up issue for any missing diagrams or onboarding steps.
- **Potential Assignees**
  - **Stan ⚡** (submitted/mentioned)
  - Reviewer: **Odilitime**

---

### 9) Pipeline/repo tracking: add `elizaos/cloud` to tracked repos with correct default branch
- **Issue Title & ID**: CI/pipeline config update to include `elizaos/cloud` (DISC-2026-03-12)
- **Current Status**: **PR submitted** (number not provided); needs review/merge.
- **Impact Assessment**
  - **User Impact**: **Medium** (affects visibility and automated reporting)
  - **Functional Impact**: **Partial** (can break automation, summaries, release awareness)
  - **Brand Impact**: **Low → Medium**
- **Technical Classification**
  - **Category**: Build/Infra
  - **Component**: **CI / Repo pipeline configuration**
  - **Complexity**: **Simple fix**
- **Resource Requirements**
  - **Required Expertise**: CI config, repo permissions
  - **Dependencies**: None
  - **Estimated Effort**: **1/5**
- **Recommended Priority**: **P3**
- **Specific Actionable Next Steps**
  1. Verify default branch is truly `dev` for cloud repo; ensure automation permissions.
  2. Merge; confirm nightly pipeline includes cloud artifacts.
- **Potential Assignees**
  - **Stan ⚡** (likely reviewer for infra/docs workflows)
  - **Odilitime** (owner approval)

---

### 10) milady-ai/milady: PRs addressing issue #71 awaiting review/merge
- **Issue Title & ID**: Review/merge PRs for Milady GitHub issue **#71** (milady-ai/milady)
- **Current Status**: **PRs submitted** by Meme Broker; pending maintainer action.
- **Impact Assessment**
  - **User Impact**: **Medium** (depends what #71 is; not described in dataset)
  - **Functional Impact**: **Partial** (unknown without issue details)
  - **Brand Impact**: **Medium** (Milady launch proximity increases urgency)
- **Technical Classification**
  - **Category**: Bug / Feature (unknown)
  - **Component**: **Milady App**
  - **Complexity**: **Moderate effort** (review + test)
- **Resource Requirements**
  - **Required Expertise**: Milady codebase knowledge, QA/testing
  - **Dependencies**: Might depend on DB/plugin-sql work
  - **Estimated Effort**: **2/5**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Identify what #71 is (link and scope) and whether it’s launch-blocking.
  2. Run targeted tests + staging deploy; merge or request changes within 48h.
- **Potential Assignees**
  - **Meme Broker** (author)
  - Reviewer: **Odilitime** or Milady maintainers; support **BinaryCookies**

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0** — Plugin init race condition (`plugin-sql` adapter side-effect) (DISC-xfn-framework-2026-03-12)  
2. **P0** — Discord phishing/scam bot requesting seed phrases (DISC-coders-2026-03-12)  
3. **P0** — `develop` branch broken (DISC-2026-03-10)  
4. **P1** — Runtime refactor to break up `AgentRuntime` and formalize lifecycle (DISC-xfn-framework-2026-03-12)  
5. **P1** — `plugin-ollama` Linux embedding failures (Issue #17)  
6. **P1** — Milady Neon DB integration blocked by permissions/capabilities (DISC-2026-03-10)  
7. **P2** — Merge docs PR `elizaos.github.io` #243 (cloud content)  
8. **P2** — Milady issue #71 PR review/merge  
9. **P2** — Token migration messaging + secure intake process  
10. **P3** — Pipeline tracking for `elizaos/cloud` repo

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Implicit side-effects as dependency injection**: Infra (DB adapter) being registered during plugin `init()` is causing nondeterminism and brittle ordering assumptions.
- **Unbounded runtime responsibilities**: The oversized `AgentRuntime` indicates missing component boundaries (scheduler, storage, plugin manager, transport) and increases regression probability during feature growth.
- **Release/branch hygiene gaps**: “develop is broken” plus near-term product launches suggests insufficient CI gating and “known-good” references for contributors.
- **Security/comms as part of product reliability**: Repeated scam attempts show that operational security and canonical messaging must be treated like a core subsystem.

---

## Process Improvements (to prevent recurrence)
1. **Define a strict plugin lifecycle contract**: declare phases (register dependencies → init → start) and forbid side-effect registration after init begins; enforce with runtime validation.
2. **Add CI nondeterminism tests**: repeatedly initialize plugins in parallel in CI to catch races before merge.
3. **Branch health policy**: require `develop` to stay green; if broken, auto-open a “Branch Red” incident issue with owner + SLA.
4. **Security operations checklist**: pinned official links, verified support process, AutoMod rules, and a short incident playbook published in-repo and in Discord.
5. **Refactor via epics + compatibility shims**: convert the runtime refactor into incremental milestones with a deprecation path so improvements don’t stall shipping.