## Issue Triage — 2026-03-12 (elizaOS)

### 1) Develop branch is broken (blocks vNext work + contributor velocity) — **ID: DISCORD-DEV-2026-03-10-01**
- **Current Status:** Acknowledged by core dev; not yet resolved (develop branch currently broken).
- **Impact Assessment:**
  - **User Impact:** **High** (breaks installs/tests for anyone tracking develop; impacts contributors most directly)
  - **Functional Impact:** **Yes** (blocks core dev workflow and downstream tasks)
  - **Brand Impact:** **High** (signals instability in mainline development)
- **Technical Classification:**
  - **Category:** Bug / Build & Release Engineering
  - **Component Affected:** Core Framework / Repo health (CI, packaging, dependency graph)
  - **Complexity:** **Moderate effort** (could be simple if a single regression; could expand if dependency/monorepo)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript/Node monorepo maintenance, CI debugging, dependency management
  - **Dependencies:** None, but unblocks multiple items (v2 stabilization, comms, integrations)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Freeze merges to develop except fixes; enable “required checks” gating.
  2. Identify first failing commit via `git bisect` + CI logs; reproduce locally with a pinned Node/pnpm version.
  3. Patch regression; add/strengthen CI coverage to prevent recurrence (smoke test: install + minimal agent run).
  4. Publish a short “develop is healthy again” note + known-good commit hash.
- **Potential Assignees:** **Odilitime** (core), **Stan ⚡** (monorepo/integration support), additional reviewer: **s**

---

### 2) Discord phishing attempt claiming “wallet linking required” — **ID: DISCORD-SEC-2026-03-11-01**
- **Current Status:** Warning issued in Discord; no systematic hardening measures captured yet.
- **Impact Assessment:**
  - **User Impact:** **Critical** (risk of direct user fund loss)
  - **Functional Impact:** **No** (not a framework runtime bug), but impacts safe community participation
  - **Brand Impact:** **High** (security incidents materially damage trust)
- **Technical Classification:**
  - **Category:** Security
  - **Component Affected:** Community Ops / Security Messaging (Discord)
  - **Complexity:** **Simple fix** (policy + automation + pinned guidance), with ongoing ops
- **Resource Requirements:**
  - **Required Expertise:** Discord moderation tooling, security comms, lightweight automation (bots/webhooks)
  - **Dependencies:** None
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Pin an official security notice: “No wallet linking required; admins will never DM for keys/sigs.”
  2. Add AutoMod rules (block common scam phrases; restrict new accounts DMing via server settings if possible).
  3. Create a `#security-alerts` channel + incident template (what happened, what to do, where to report).
  4. Add a short section to docs: “Operational Security for Agents & Community.”
- **Potential Assignees:** **Odilitime** (security stance), **satsbased** (community response), Discord mods/ops

---

### 3) Wallet-capable agent security model not yet standardized (prompt-injection/drain prevention) — **ID: DISCORD-SEC-2026-03-11-02**
- **Current Status:** Best-practice described (“LLM fully isolated from keys/addresses” via Spartan), but not captured as a project standard/spec.
- **Impact Assessment:**
  - **User Impact:** **High** (builders shipping wallet agents are exposed without clear reference architecture)
  - **Functional Impact:** **Partial** (framework can run, but unsafe patterns likely)
  - **Brand Impact:** **High** (wallet drains would reflect on elizaOS ecosystem)
- **Technical Classification:**
  - **Category:** Security / Documentation (with possible framework hooks)
  - **Component Affected:** Core Framework + Plugin System (wallet integrations)
  - **Complexity:** **Architectural change** (if enforced technically) or **Moderate** (if guidance + reference impl)
- **Resource Requirements:**
  - **Required Expertise:** Security architecture, key management, sandboxing, plugin boundary design
  - **Dependencies:** May depend on plugin APIs and action-execution boundary design in v2
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Write an “Agent Wallet Safety Spec v1” (non-negotiables: no keys in prompt/context; signer isolation).
  2. Provide a reference implementation: external signer microservice or hardware-backed signing adapter.
  3. Add a security linter/checklist for wallet plugins before listing in registry.
  4. Add red-team test prompts demonstrating injection attempts and expected safe behavior.
- **Potential Assignees:** **Odilitime** (Spartan approach), security-minded community contributors; reviewer: **Stan ⚡**

---

### 4) Model configuration inconsistencies across different agents — **ID: DISCORD-BUG-2026-03-09-01**
- **Current Status:** Reported by BinaryCookies; no resolution captured.
- **Impact Assessment:**
  - **User Impact:** **High** (common builder workflow; misconfig leads to non-functional agents or unexpected costs)
  - **Functional Impact:** **Yes** (agents may fail to start or run incorrectly)
  - **Brand Impact:** **Medium–High** (feels “flaky”/hard to use)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component Affected:** Core Framework (config loading/overrides), Model Integration
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Config schema design, runtime config resolution, testing across examples/templates
  - **Dependencies:** Might intersect with v2 config refactors and prompt batching scheduler
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce with 2–3 representative agents (templates + real-world configs).
  2. Define precedence rules (env vs json vs runtime overrides) and enforce via schema validation.
  3. Add clear error messages (missing keys, invalid provider/model pair, incompatible settings).
  4. Add a “config doctor” CLI command to print resolved config + warnings.
- **Potential Assignees:** **BinaryCookies** (reporter, repro), **Odilitime** (core), **s** (examples guidance)

---

### 5) v2.0.0 alpha published but requires completion/stabilization (release readiness) — **ID: DISCORD-REL-2026-03-11-01**
- **Current Status:** Alpha released; multiple WIP items nearing completion.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (early adopters + plugin authors depend on stable APIs)
  - **Functional Impact:** **Partial** (alpha works but likely has gaps/regressions)
  - **Brand Impact:** **High** (public alpha sets expectations; instability can deter adoption)
- **Technical Classification:**
  - **Category:** Bug / Release Engineering / UX
  - **Component Affected:** Core Framework, Plugin System, Model Integration
  - **Complexity:** **Complex solution** (stabilization typically spans multiple areas)
- **Resource Requirements:**
  - **Required Expertise:** Release management, regression testing, API stability, docs
  - **Dependencies:** Blocked/complicated by broken develop branch (see P0 issue)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define “Alpha Exit Criteria” (top 10 bugs, API freeze list, minimum docs).
  2. Cut a stabilization branch; run CI + basic scenario tests (chat, tools/actions, memory, plugin load).
  3. Produce a migration guide (v1 → v2) focusing on config, plugin APIs, scheduling/autonomy.
  4. Publish weekly changelog snapshots to reduce community uncertainty.
- **Potential Assignees:** **Odilitime** (core lead), **Shaw** (product coordination), **s** (comms + validation)

---

### 6) Embeddings microservice proposal (cloud REST endpoint for embeddings + persistence) — **ID: DISCORD-ARCH-2026-03-11-01**
- **Current Status:** Proposed architecture in xfn-framework discussion; not implemented.
- **Impact Assessment:**
  - **User Impact:** **Medium** (helps scale/cost/control for teams; not required for all users)
  - **Functional Impact:** **Partial** (improves reliability/performance; can decouple heavy workloads)
  - **Brand Impact:** **Medium** (positions elizaOS as production-ready)
- **Technical Classification:**
  - **Category:** Performance / Architectural change
  - **Component Affected:** Core Framework (embeddings pipeline), API/Services, Storage layer
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Service design, auth, queues, DB schema, observability, cost controls
  - **Dependencies:** Decisions on embedding provider support; existing memory/vector abstractions
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Draft a minimal spec: endpoints, auth (API keys/JWT), payload formats, idempotency.
  2. Choose deployment target (serverless vs container) + persistence (pgvector, managed vector DB).
  3. Implement an adapter interface in core: local embedder vs remote embedder.
  4. Add rate limiting + caching + tracing (to prevent runaway costs).
- **Potential Assignees:** **Odilitime** (architecture), infra-focused community contributors; reviewer: **Stan ⚡**

---

### 7) Linux embedding failures in Ollama plugin — **ID: elizaos-plugins/plugin-ollama#17**
- **Current Status:** Previously identified as under investigation; current resolution unknown.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Linux is a primary dev/runtime environment for self-hosters)
  - **Functional Impact:** **Yes** (breaks embeddings; impacts RAG/memory/core agent capability)
  - **Brand Impact:** **Medium** (plugin reliability affects ecosystem perception)
- **Technical Classification:**
  - **Category:** Bug / Compatibility
  - **Component Affected:** Model Integration (Ollama embeddings), Plugin System
  - **Complexity:** **Moderate effort** (often env/provider/version mismatch; could be deeper)
- **Resource Requirements:**
  - **Required Expertise:** Linux env debugging, Ollama API specifics, embeddings pipeline
  - **Dependencies:** Might depend on how embeddings are requested/stored in current core
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect reproducible matrix: distro, kernel, Ollama version, model, plugin version.
  2. Add verbose logging around embedding request/response + timeouts.
  3. Create a minimal standalone reproduction script for CI (container-based).
  4. Patch and add a regression test (skip if Ollama not available; run in nightly pipeline).
- **Potential Assignees:** Plugin maintainers (not named in logs), **Odilitime** (coordination), community Linux testers

---

### 8) Milady integration: system permissions/capabilities issues (Neon DB + runtime perms) — **ID: DISCORD-INT-2026-03-10-01**
- **Current Status:** Config location found (env in JSON), but permissions/capabilities remain unresolved.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects teams adopting Milady + managed DB setups)
  - **Functional Impact:** **Partial** (blocks some deployments/integrations)
  - **Brand Impact:** **Low–Medium**
- **Technical Classification:**
  - **Category:** Bug / Deployment
  - **Component Affected:** Integrations / DB connectivity / Runtime permissions
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Cloud DB connectivity, secrets/env handling, runtime sandbox/capabilities
  - **Dependencies:** May depend on how integrations define capabilities in the framework
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document required permissions/capabilities for DB operations (minimum viable set).
  2. Provide a Neon “known-good” example config + troubleshooting section.
  3. Add preflight checks that fail fast with actionable messages.
- **Potential Assignees:** **BinaryCookies** (hands-on), Milady maintainers, reviewer: **s**

---

### 9) Video briefing pipeline: daily/weekly automation + channel delivery + Telegram expansion — **ID: DISCORD-FEAT-2026-03-11-01**
- **Current Status:** Prototype exists; needs “fixes” for consistent daily/weekly updates and channel posting workflow.
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves community clarity; reduces support overhead)
  - **Functional Impact:** **No** (non-core framework), but important for ecosystem comms
  - **Brand Impact:** **Medium–High** (addresses perception of silence/chaos)
- **Technical Classification:**
  - **Category:** Feature / UX (Comms tooling)
  - **Component Affected:** Tooling/Automation (elizaOS.news workflows), Discord/Telegram integration
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Media pipeline automation, scheduling, API integrations, content QA
  - **Dependencies:** Access tokens/permissions for Discord + Telegram; stable data sources
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define the MVP schedule + deterministic output format (time, sections, length).
  2. Add monitoring/alerts for failed renders/posts; keep an artifact store for replay.
  3. Implement Telegram posting only after Discord reliability >95% over 7 days.
- **Potential Assignees:** **jin** (owner), reviewer: **Odilitime** (content strategy feedback)

---

### 10) PRR git branch “story” tool needs productization (docs + adoption path) — **ID: elizaOS/prr#5**
- **Current Status:** PR exists; demoed; adoption/use-case integration not defined.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (high leverage for maintainers; less for end users)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low–Medium**
- **Technical Classification:**
  - **Category:** Feature / Developer Tools
  - **Component Affected:** Tooling
  - **Complexity:** **Simple fix** to **Moderate** (depending on integration goals)
- **Resource Requirements:**
  - **Required Expertise:** Dev tooling, documentation, CI integration
  - **Dependencies:** None
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Add README with examples + intended workflows (release notes, branch comparison).
  2. Publish as a CLI (or GitHub Action) to generate “branch story” artifacts automatically.
- **Potential Assignees:** **Odilitime** (author), doc helper: **jin**

---

## Top Priority Summary (focus for immediate attention)
1. **P0 — Develop branch is broken** (DISCORD-DEV-2026-03-10-01)  
2. **P0 — Discord phishing/wallet-link scam hardening** (DISCORD-SEC-2026-03-11-01)  
3. **P1 — Standardize wallet-agent security architecture** (DISCORD-SEC-2026-03-11-02)  
4. **P1 — Model configuration inconsistencies across agents** (DISCORD-BUG-2026-03-09-01)  
5. **P1 — v2.0.0 alpha stabilization plan + exit criteria** (DISCORD-REL-2026-03-11-01)  
6. **P1 — Ollama plugin Linux embedding failures** (plugin-ollama#17)  
7. **P2 — Embeddings cloud REST microservice (spec + adapter)** (DISCORD-ARCH-2026-03-11-01)

## Patterns / Themes Suggesting Deeper Architectural Issues
- **Config + lifecycle complexity is rising**: repeated signals around broken develop, inconsistent model config, and proposals like lazy loading/prompt batching suggest configuration resolution and service initialization order may be fragile.
- **Security is becoming ecosystem-critical, not optional**: wallet-capable agents and active phishing attempts mean elizaOS needs a formal security posture (docs, reference designs, and plugin review standards).
- **Scaling vectors/embeddings is a recurring pressure point**: both the **cloud embeddings endpoint** idea and the **Linux embedding failures** indicate the embeddings layer needs clearer abstraction boundaries and stronger compatibility testing.

## Process Improvement Recommendations
- **Release/branch hygiene**
  - Enforce protected branches + required CI checks on develop.
  - Add a nightly “minimal agent scenario suite” (install → run → memory/embeddings smoke test).
- **Configuration governance**
  - Define and document a single configuration precedence model.
  - Add schema validation + a `config doctor` CLI to print resolved settings and warn on pitfalls.
- **Security operations baseline**
  - Create a lightweight security policy: reporting, incident comms, and “never ask for wallet linking/keys” rules.
  - Add wallet-plugin guidelines + a mandatory isolation pattern (reference signer service).
- **Compatibility testing**
  - Maintain an OS/provider matrix for embeddings and model integrations (at least Linux/macOS/Windows; Ollama/OpenAI/local).
  - Require reproducible issue templates with environment capture for plugin repos.