## Issue Triage — 2026-01-28

### 1) Knowledge plugin can generate unexpectedly high OpenAI costs when contextual embeddings are enabled
- **Issue Title & ID:** Knowledge plugin queries cost spike when `CTX_KNOWLEDGE_ENABLED=true` (Discord: **DISCORD-2026-01-27-KNOWLEDGE-COST**)
- **Current Status:** Reported in Discord; workaround identified (disable contextual embeddings / use minimal embedding config); no linked GitHub issue yet.
- **Impact Assessment:**
  - **User Impact:** **High** (anyone enabling contextual embeddings; likely many experimenting with Knowledge)
  - **Functional Impact:** **Partial** (system “works” but becomes economically unusable)
  - **Brand Impact:** **High** (perception of “Eliza is expensive / unsafe to run”)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance (cost-performance)
  - **Component Affected:** Plugin System → **Knowledge plugin**; Model Integration (embeddings)
  - **Complexity:** **Moderate effort** (guardrails + defaults + docs)
- **Resource Requirements:**
  - **Required Expertise:** embeddings/RAG, token accounting, plugin configuration, benchmarking
  - **Dependencies:** none hard; should coordinate with docs updates and defaults
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create GitHub issue in `elizaOS/knowledge` (or main repo if centralized) with reproduction + cost evidence (tokens/query).
  2. Change default to `CTX_KNOWLEDGE_ENABLED=false` (or require explicit opt-in + warning banner).
  3. Add runtime “cost guardrails”: log chunk count + estimated tokens; warn/abort if query/context exceeds threshold unless overridden.
  4. Add a “minimal recommended config” section (embedding model, chunking guidance) and “when to use contextual embeddings.”
  5. Add a unit/integration test that asserts bounded prompt size for small docs.
- **Potential Assignees:** **0xbbjoker** (plugin-knowledge expert), **Odilitime** (core alignment), **Stan ⚡** (platform defaults), **Tyrone** (docs/reporting)

---

### 2) Knowledge plugin validation error: `EMBEDDING_PROVIDER` rejects `openrouter` even when OpenRouter is used for embeddings
- **Issue Title & ID:** “Invalid enum value” for `EMBEDDING_PROVIDER` when set to `openrouter` (Discord: **DISCORD-2026-01-27-KNOWLEDGE-ENUM**)
- **Current Status:** Root cause explained in Discord (embedding provider must be `openai|google`); documentation/config examples likely confusing/outdated.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (blocks onboarding for Knowledge plugin users)
  - **Functional Impact:** **Partial** (blocks Knowledge setup)
  - **Brand Impact:** **Medium–High** (feels “broken on install”)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Documentation (config ergonomics)
  - **Component Affected:** Plugin System → Knowledge plugin config schema; Docs
  - **Complexity:** **Simple fix** (docs + schema messaging), potentially **Moderate** if refactor provider naming
- **Resource Requirements:**
  - **Required Expertise:** config schema validation (zod/valibot/etc), docs
  - **Dependencies:** coordinate with OpenRouter embedding usage patterns
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Update docs and example `.env` to clearly separate:
     - *embedding API provider* (`openai|google`) vs
     - *routing/provider platform* (OpenRouter model strings like `openai/text-embedding-3-small`).
  2. Improve validation error message to suggest the correct fix (“Use EMBEDDING_PROVIDER=openai; set OPENROUTER_EMBEDDING_MODEL=…”).
  3. Consider supporting `openrouter` as a first-class enum if technically accurate (or rename field to avoid semantic mismatch).
- **Potential Assignees:** **DigitalDiva** (triage + user support), **0xbbjoker** (knowledge plugin), **YogaFlame** (reporter/docs), **Odilitime**

---

### 3) Security incident: scam “Create A Ticket” bot requesting wallet addresses / sending suspicious links
- **Issue Title & ID:** Scam support bot requesting wallet addresses (Discord: **DISCORD-2026-01-25-SCAM-TICKETBOT**)
- **Current Status:** Confirmed scam in Discord; mitigation actions not documented in logs.
- **Impact Assessment:**
  - **User Impact:** **Critical** (wallet-drain risk)
  - **Functional Impact:** **No** (core framework unaffected) / **Partial** (community support pipeline compromised)
  - **Brand Impact:** **High** (trust/safety perception)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Community Ops / Discord automation; Support workflow
  - **Complexity:** **Moderate effort** (permissions, bot removal, comms, monitoring)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/security, incident response, community comms
  - **Dependencies:** identify bot origin; verify legitimate ticket flow
  - **Estimated Effort (1-5):** **2**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Audit Discord bots/roles: remove unauthorized bots; rotate any exposed tokens; lock down “Manage Webhooks/Bots.”
  2. Pin official support guidance: “No team member will ask for seed phrase or wallet address; only use official domains.”
  3. Add automod filters for common scam phrases/links; enable verification for new accounts if needed.
  4. Publish a short post-mortem + ongoing mitigations.
- **Potential Assignees:** **Odilitime** (mod/admin), **Hexx 🌐** (community comms), **The Void** (support process), Discord admin team

---

### 4) Workflow pivot risk: n8n integration architecture needs a concrete MVP spec + credential/OAuth gateway plan to meet funnel deadline
- **Issue Title & ID:** n8n workflow integration MVP definition + OAuth gateway layering (Internal: **CORE-2026-01-27-N8N-MVP**)
- **Current Status:** Architecture proposed (3 layers); multiple parallel action items; end-of-week funnel deadline stated; risk of scope creep.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks “workflow builder” primary user demand)
  - **Functional Impact:** **Yes** (blocks core near-term product direction)
  - **Brand Impact:** **High** (launch experience)
- **Technical Classification:**
  - **Issue Category:** Feature / Architecture
  - **Component Affected:** Core Framework + Cloud runtime + Plugin System + OAuth
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** n8n integration, OAuth multi-tenant credential storage, backend orchestration (cron/TaskService), product MVP scoping
  - **Dependencies:** hosted n8n instance scaling; credential passing from existing plugins; validation/testing harness
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P1** (with a P0 “definition” subtask to prevent thrash)
- **Specific Actionable Next Steps:**
  1. Write a 1–2 page MVP spec: “lander → poke → agent conversation → generate 1 workflow → execute 1 action.”
  2. Decide “single-tenant prototype vs multi-tenant from day 1” for OAuth gateway; document tradeoffs.
  3. Implement credential contract: how plugin-gmail credentials map into n8n credentials; include revocation/rotation.
  4. Create 5 prefab workflows (email summarize, calendar schedule, notion task create, linear issue create, webhook trigger).
  5. Add workflow validation: required credentials inference + dry-run execution.
- **Potential Assignees:** **Stan ⚡** (n8n + OAuth), **s** (MVP/funnel + workflow generation strategy), **Sam** (cloud runtime + messaging integration), **Borko** (n8n infra)

---

### 5) elizaOS CLI “create project” failure due to package exports path (regression risk; ensure released fix)
- **Issue Title & ID:** Can not generate project (`ERR_PACKAGE_PATH_NOT_EXPORTED`) — **elizaos/eliza #6388**
- **Current Status:** **Closed**; fix landed via PR **#6389** (“use package alias”).
- **Impact Assessment:**
  - **User Impact:** **High** (new-user onboarding blocker)
  - **Functional Impact:** **Yes** (blocks project creation)
  - **Brand Impact:** **High** (“can’t even start”)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** **CLI** / packaging
  - **Complexity:** **Simple fix** (already implemented)
- **Resource Requirements:**
  - **Required Expertise:** npm/bun packaging, Node ESM exports
  - **Dependencies:** release pipeline; version bump; docs install instructions
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P1** (verify + release + prevent recurrence)
- **Specific Actionable Next Steps:**
  1. Confirm fix is published to npm for all relevant packages (`elizaos`, `@elizaos/cli`) and that docs reference the fixed version.
  2. Add a CI smoke test: `bun i -g elizaos && elizaos create` on Node LTS + Node 22.
  3. Add “supported Node versions” statement and fail-fast message if unsupported.
- **Potential Assignees:** **Odilitime** (recent CLI work), **YuriNachos** (CLI robustness), release maintainer(s)

---

### 6) Plugin action handler callbacks perceived as “only first callback sent” (likely planner/config mismatch; docs unclear)
- **Issue Title & ID:** Action handler callbacks only send first response (Discord: **DISCORD-2026-01-26-CALLBACKS**)
- **Current Status:** Investigated in Discord; multiple callbacks supported; suspicion on task planner settings (`onestep` vs `multistep`) and expectations (immediate vs completion callback).
- **Impact Assessment:**
  - **User Impact:** **Medium** (plugin developers / advanced users)
  - **Functional Impact:** **Partial** (breaks streaming/progressive UX patterns)
  - **Brand Impact:** **Medium** (docs/behavior mismatch)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation / UX
  - **Component Affected:** Core Framework (action execution), Task planner, Plugin System
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** runtime action execution, planner modes, messaging transport semantics
  - **Dependencies:** clarify expected callback contract across transports (HTTP/SSE/WebSocket)
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a minimal reproduction repo and pin the planner mode + transport used.
  2. Update docs: define callback lifecycle (progress vs final), ordering guarantees, transport differences.
  3. Add an automated test verifying multiple callbacks arrive in `multistep` mode.
- **Potential Assignees:** **Odilitime** (core/runtime), **standujar** (tests), contributor from plugin ecosystem

---

### 7) V2 dynamic prompt execution engine PR has critical Python implementation bugs flagged in review tooling
- **Issue Title & ID:** Dynamic execution engine Python bugs (PR: **elizaos/eliza #6384**)
- **Current Status:** PR open; Greptile notes multiple Python runtime-breaking issues (state wrapping, attribute access, XML regex).
- **Impact Assessment:**
  - **User Impact:** **Medium** today, **High** if Python runtime is a flagship V2 onramp
  - **Functional Impact:** **Partial** (breaks Python path; TS/Rust may be fine)
  - **Brand Impact:** **Medium–High** (Python quickstart reliability)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** **Model Integration / Runtime (Python)**; Structured output parsing
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Python runtime internals, structured output parsing, test writing
  - **Dependencies:** align behavior with TS/Rust; add Python tests
  - **Estimated Effort (1-5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Patch Python callable invocation to pass state consistently (avoid double-wrapping).
  2. Fix state access patterns (`state.values` assumptions) to match actual State type.
  3. Update XML parsing regex to support underscores in validation field names.
  4. Add Python unit tests covering: JSON/XML parse, validation codes, retry/backoff.
- **Potential Assignees:** **odilitime** (author), **matomoniwano** (Python focus), Python-capable reviewer(s)

---

### 8) V2.0.0 mega-branch PR is huge and high risk; needs slicing plan + merge strategy
- **Issue Title & ID:** V2.0.0 working branch PR (PR: **elizaos/eliza #6351**)
- **Current Status:** Open; very large diff; “removes app/server/CLI and non-essentials” in favor of Rust/TS runtime focus.
- **Impact Assessment:**
  - **User Impact:** **High** (future direction; potential disruption)
  - **Functional Impact:** **Yes** (core architecture and repo structure)
  - **Brand Impact:** **High** (stability + contributor experience)
- **Technical Classification:**
  - **Issue Category:** Architectural change
  - **Component Affected:** Core Framework, repo structure, build tooling, releases
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** monorepo/release engineering, Rust+TS runtime, migration strategy
  - **Dependencies:** compatibility plan for existing plugins; versioning strategy (`@next` already used); docs
  - **Estimated Effort (1-5):** **5**
- **Recommended Priority:** **P2** (but must be actively managed to avoid blocking everything)
- **Specific Actionable Next Steps:**
  1. Produce a slicing plan: split into mergeable PRs (runtime core, plugin ports, build tooling, docs).
  2. Define compatibility targets: what remains supported in 1.7.x vs 2.x; publish migration guide outline.
  3. Add CI gates for V2: build + basic runtime smoke tests per language.
- **Potential Assignees:** **lalalune** (author), **s** (product direction), build/release maintainers, core reviewers

---

### 9) “Opus - pro and Ultra - sonnet? Is this right?” model tier confusion in UI/config
- **Issue Title & ID:** Model labeling/tier confusion — **elizaos/eliza #6390**
- **Current Status:** Open; limited context; likely UI/plan labeling mismatch.
- **Impact Assessment:**
  - **User Impact:** **Medium** (pricing/plan clarity affects conversions)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (trust in billing/quality)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** Cloud UI / Model selection
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** frontend/UI, product naming, billing plan mapping
  - **Dependencies:** confirm intended model availability per plan
  - **Estimated Effort (1-5):** **1**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Reproduce in production/staging; document expected vs actual label mapping.
  2. Fix labels and add a small tooltip explaining “Pro/Ultra” → model access.
- **Potential Assignees:** **borisudovicic** (reporter/product), frontend maintainer(s)

---

## Top 5–10 Highest Priority Issues to Address Immediately
1. **P0:** Knowledge plugin cost spike when contextual embeddings enabled (**DISCORD-2026-01-27-KNOWLEDGE-COST**)
2. **P0:** Discord scam ticket bot requesting wallet addresses (**DISCORD-2026-01-25-SCAM-TICKETBOT**)
3. **P1:** n8n integration MVP spec + OAuth/credential contract to hit funnel deadline (**CORE-2026-01-27-N8N-MVP**)
4. **P1:** Knowledge plugin enum/config validation confusion blocks setup (**DISCORD-2026-01-27-KNOWLEDGE-ENUM**)
5. **P1:** Ensure CLI create-project fix is released + add CI smoke tests (**elizaos/eliza #6388**)
6. **P1:** Fix Python runtime bugs in dynamic execution engine PR (**elizaos/eliza #6384**)
7. **P2:** Callback behavior/docs mismatch for plugin action handlers (**DISCORD-2026-01-26-CALLBACKS**)
8. **P2:** Manage V2 mega-PR via slicing/merge strategy (**elizaos/eliza #6351**)
9. **P2:** Model tier labeling confusion (**elizaos/eliza #6390**)

---

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Configuration surface area is too error-prone** (provider naming/semantics, env flags with major behavioral impact, confusing routing vs provider fields).
- **Cost and safety guardrails are missing by default** (Knowledge plugin can silently incur large spend; insufficient “bounded execution” defaults).
- **Large architectural pivots without tight MVP contracts** (n8n integration + V2 mega-PR risk parallel fragmentation and missed deadlines).
- **Docs lag behind fast-moving interfaces** (callbacks, provider enums, embedding settings), causing repeated onboarding failures.

---

## Recommendations for Process Improvements
1. **“Default-safe” cost controls:** Add standard cost telemetry + hard/soft limits (tokens/context/chunks) across RAG/Knowledge components.
2. **Config schema UX upgrades:** Provide actionable validation errors, auto-suggest fixes, and ship “known-good” minimal configs per plugin.
3. **Release gating smoke tests:** CI should run end-to-end “new user” flows (install CLI, create project, start agent, run one plugin).
4. **Security operations checklist for community infra:** periodic Discord bot/role audits, pinned official support policy, link allowlists.
5. **Architectural change discipline:** require MVP spec + slicing plan for large pivots/PRs; enforce “merge in increments” with feature flags.