# Issue Triage — 2026-01-06

## 1) Critical / Highest-Impact Issues

### 1. fix(plugin-sql): data isolation breaks DB ops due to `SET LOCAL` parameterization (PR #6316)
- **Current Status:** PR open (not merged); includes unit + integration tests
- **Impact Assessment:**
  - **User Impact:** **High** (any deployment with `ENABLE_DATA_ISOLATION=true`)
  - **Functional Impact:** **Yes** (breaks “all database operations” under data isolation)
  - **Brand Impact:** **High** (core reliability regression; “DB is broken” perception)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework / DB layer (`plugin-sql`, Postgres context manager)
  - **Complexity:** Moderate effort (code + tests already drafted; needs review/merge)
- **Resource Requirements:**
  - **Required Expertise:** Postgres, Drizzle ORM behavior, Eliza DB isolation semantics
  - **Dependencies:** None (but should coordinate with any ongoing DB/migrations work)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Fast-track review focusing on SQL injection safety (since `sql.raw()` is introduced).
  2. Validate integration test coverage across CI environment (real Postgres availability).
  3. Merge + cut patch release; add changelog note for data-isolation users.
  4. Add a guardrail doc note: “Postgres `SET` cannot be parameterized.”
- **Potential Assignees:** `0xbbjoker` (author), `standujar` (core reviewer), DB-focused maintainer

---

### 2. “Model not found” when using agent ID + API endpoints (DISCORD-2026-01-03-API-MODEL-NOT-FOUND)
- **Current Status:** Reported on Discord; no linked GitHub issue found in provided data (needs formalization)
- **Impact Assessment:**
  - **User Impact:** **High** (likely affects any API consumer hitting the same path)
  - **Functional Impact:** **Yes** (blocks API-based agent usage)
  - **Brand Impact:** **High** (API reliability and onboarding)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** API / Model Integration routing (agent ID → model/provider resolution)
  - **Complexity:** Complex solution (could be config, registry, auth scope, or routing mismatch)
- **Resource Requirements:**
  - **Required Expertise:** API layer, agent config resolution, provider/model registry, auth/tenancy
  - **Dependencies:** Repro details required (request payload, endpoint, agent config, provider env)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue with a minimal repro template (endpoint, headers, agentId, provider, model name).
  2. Add diagnostic logging around model resolution (requested model, resolved provider, final model string).
  3. Confirm whether error originates from provider (OpenAI/Anthropic/etc.) vs internal registry.
  4. Add an API validation step returning a clearer error (e.g., “provider configured but model missing”).
- **Potential Assignees:** `standujar` (core/services), a maintainer familiar with model/provider plumbing; reporter follow-up: BAOVERSE🌟 (for repro)

---

### 3. Discord plugin version publishing gap (v1.3.4 failed; jump v1.3.3 → v1.3.5) (DISCORD-2026-01-03-DISCORD-PLUGIN-VERSIONING)
- **Current Status:** Reported on Discord; no linked GitHub issue found in provided data
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (breaks predictable upgrades; may strand users on bad versions)
  - **Functional Impact:** **Partial** (depends if a fix was expected in 1.3.4)
  - **Brand Impact:** **High** (ecosystem maturity, release process trust)
- **Technical Classification:**
  - **Issue Category:** Bug / Release Engineering
  - **Component Affected:** Plugin System / Publishing pipeline (npm, registry, tags)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** npm publishing, CI release workflows, semver/tagging, plugin registry
  - **Dependencies:** Access to publishing logs + npm dist-tags history
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Open GitHub issue in the plugin repo with npm error logs + CI run link.
  2. Audit the release workflow: tag creation, provenance, npm token scope, 2FA, “already exists” cases.
  3. Decide policy: yanking vs deprecating vs republishing (note: npm immutability constraints).
  4. Add a “release checklist” + automated guard (fail if version already exists / missing changelog).
- **Potential Assignees:** Plugin maintainer(s), release tooling maintainer; coordination: `standujar` (process), YogaFlame (reporter)

---

### 4. Turbo build tool high memory usage (21GB+) (DISCORD-2026-01-04-TURBO-MEMORY)
- **Current Status:** Reported on Discord; investigation requested
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily contributors/devs; may block lower-RAM machines/CI)
  - **Functional Impact:** **Partial** (build instability; slows iteration)
  - **Brand Impact:** **Medium** (DX reputation)
- **Technical Classification:**
  - **Issue Category:** Performance
  - **Component Affected:** Tooling / Build system (Turbo)
  - **Complexity:** Complex solution (could be caching, watch mode, monorepo graph, misconfig)
- **Resource Requirements:**
  - **Required Expertise:** JS/TS build systems, Turbo config, monorepo patterns, CI tuning
  - **Dependencies:** Repro steps + environment (OS, node/bun version, command used)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P2** (raise to P1 if confirmed affecting CI or common dev setups)
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue with peak RSS, command, repo state, and Turbo version.
  2. Attempt reproduction on CI runner + one local machine; capture heap snapshots if possible.
  3. Review Turbo pipeline for tasks that fan out too broadly; ensure caching is effective.
  4. Add docs/workarounds (e.g., limit concurrency, scope packages, disable sourcemaps in dev).
- **Potential Assignees:** `odilitime` (raised it), build/DX maintainers

---

## 2) Product / UX Issues (Public Agents + Chat)

### 5. Separate public agent states (unauth visitor vs authed non-owner vs owner) — elizaos/eliza #6313
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** **High** (applies to all public-agent visitors; key funnel)
  - **Functional Impact:** **Partial** (current UI works but mismatched intents; confusion)
  - **Brand Impact:** **High** (first impressions from shared links)
- **Technical Classification:**
  - **Issue Category:** UX / Feature
  - **Component Affected:** GUI (public agent page), Auth gating, Permissions
  - **Complexity:** Architectural change (distinct states + UI surfaces + routing rules)
- **Resource Requirements:**
  - **Required Expertise:** Frontend UX, auth state management, product analytics
  - **Dependencies:** Likely tied to message limits for guests (#6312) and public agent cards/analytics (#6314)
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P2** (strategic/high leverage; schedule but not emergency)
- **Specific Actionable Next Steps:**
  1. Convert description into a UI spec: exact components per state + acceptance criteria.
  2. Define routes/guards and which API calls are allowed unauthenticated.
  3. Add event tracking: view → first message → gate hit → signup conversion.
  4. Implement incrementally: start with removing owner controls for non-owners + visitor UI cleanup.
- **Potential Assignees:** `borisudovicic` (author/product), frontend maintainer(s)

---

### 6. Limit messages for non-signed up user to ~2–3 — elizaos/eliza #6312
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** **High** (all unauth visitors)
  - **Functional Impact:** **No** (growth/monetization lever)
  - **Brand Impact:** **Medium** (too aggressive gating can backfire; needs good UX)
- **Technical Classification:**
  - **Issue Category:** Feature / UX
  - **Component Affected:** API + GUI (rate limiting / gating overlay), Auth
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Backend enforcement + frontend gating UI, analytics
  - **Dependencies:** Should align with state separation (#6313) to avoid inconsistent UI
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Decide enforcement point: server-side (recommended) vs client-side.
  2. Define what counts as a “message” (user only vs both sides) and reset conditions.
  3. Implement soft gate overlay with CTA; ensure share link still works.
  4. Add metrics: gate-hit rate, conversion, bounce.
- **Potential Assignees:** `borisudovicic`, backend/API maintainer, frontend maintainer

---

### 7. Public agent cards should have “chat number” — elizaos/eliza #6314
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** **Medium** (discovery UX; social proof)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (polish + trust)
- **Technical Classification:**
  - **Issue Category:** UX / Feature
  - **Component Affected:** GUI + Analytics counters (messages aggregation)
  - **Complexity:** Moderate effort (needs efficient aggregation + caching)
- **Resource Requirements:**
  - **Required Expertise:** DB aggregation/perf, frontend display, privacy considerations
  - **Dependencies:** Data model for counting messages across users; may depend on logging correctness (recently improved)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3** (promote to P2 if discovery launch is imminent)
- **Specific Actionable Next Steps:**
  1. Specify calculation precisely (total messages user↔agent; include/exclude system messages).
  2. Implement aggregated counter (materialized/cached) to avoid expensive queries.
  3. Add privacy guardrails (no per-user exposure; only totals).
  4. Display formatting + loading states on cards.
- **Potential Assignees:** `borisudovicic`, DB maintainer, frontend maintainer

---

### 8. Chat summaries don’t make sense; improve — elizaos/eliza #6311
- **Current Status:** OPEN
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **Partial** (affects navigation and comprehension; not blocking chat)
  - **Brand Impact:** **Medium** (perceived “AI quality” and polish)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** GUI + summarization logic (prompting / heuristics)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Prompting/summarization heuristics, frontend copy, evaluation
  - **Dependencies:** Need examples of “bad” summaries and desired outputs (provided screenshots help)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Collect ~20 real failing examples and define rubric (“use first user intent + topic”).
  2. Decide whether to generate titles from first N messages vs periodic summarization.
  3. Add deterministic fallback (e.g., first user message truncated) when LLM summary is low quality.
  4. A/B test: current vs new summarizer for click-through and user edits.
- **Potential Assignees:** Frontend maintainer, model/prompting contributor; product guidance: `borisudovicic`

---

### 9. Need refresh for conversation to show as deleted — elizaos/eliza #6322
- **Current Status:** OPEN (mentioned in contributor activity summary)
- **Impact Assessment:**
  - **User Impact:** **High** (common UX action; makes app feel broken)
  - **Functional Impact:** **Partial** (delete works but UI state incorrect)
  - **Brand Impact:** **High** (basic CRUD expectations)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** GUI state management (conversations list), API cache invalidation
  - **Complexity:** Simple fix to Moderate effort (depends on state architecture)
- **Resource Requirements:**
  - **Required Expertise:** Frontend state/query caching (React Query/SWR/etc.), API responses
  - **Dependencies:** Identify where deletion mutation fails to invalidate/refetch
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reproduce with network tab: confirm server deletion success vs client-only failure.
  2. Ensure deletion mutation invalidates the conversations list + active conversation view.
  3. Add e2e test: delete conversation → it disappears without refresh.
- **Potential Assignees:** Frontend maintainer; reporter/owner: `borisudovicic`

---

### 10. Agent sorting doesn’t work — elizaos/eliza #6319
- **Current Status:** OPEN (mentioned in contributor activity summary)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (affects discovery and management as agent count grows)
  - **Functional Impact:** **Partial**
  - **Brand Impact:** **Medium**
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** GUI + API query params (sorting), possibly DB indexes
  - **Complexity:** Simple fix to Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Frontend list rendering, API sorting contract
  - **Dependencies:** Clarify desired sort options and current behavior
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Confirm whether sort is broken in UI only (state not applied) vs backend ignoring sort param.
  2. Add contract tests for API sorting; add UI test verifying sort selection changes order.
  3. Ensure stable sorting (tie-breakers) to prevent flicker.
- **Potential Assignees:** Frontend maintainer; product guidance: `borisudovicic`

---

## 3) Docs / Developer Enablement

### 11. Agent memory/recall confusion: add “knowledge” & “lore” sections to JSON configuration guidance (DISCORD-2026-01-03-AGENT-KNOWLEDGE-CONFIG)
- **Current Status:** Reported as a need on Discord; no linked GitHub issue in provided data
- **Impact Assessment:**
  - **User Impact:** **High** (recurring onboarding pain; “memory doesn’t work” complaints)
  - **Functional Impact:** **Partial** (feature exists but is hard to use correctly)
  - **Brand Impact:** **Medium–High** (perceived capability gap)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs + Agent configuration schema
  - **Complexity:** Simple fix (docs) to Moderate (if schema/tooling needs improvement)
- **Resource Requirements:**
  - **Required Expertise:** eliza agent config schema, docs writing, examples
  - **Dependencies:** Decide canonical config keys and validation rules
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a docs issue: “How to add knowledge/lore to agent JSON” with working examples.
  2. Add schema validation + CLI linting error messages if sections are missing/malformed.
  3. Provide a minimal “memory-enabled agent” template in repo.
- **Potential Assignees:** Docs maintainer, `standujar` (config/lint direction), community helpers (YogaFlame as reporter)

---

### 12. Prepare documentation & presentation for Eliza knowledge data pipelines (DISCORD-2026-01-04-KNOWLEDGE-PIPELINES-DOCS)
- **Current Status:** In progress (Jin); documentation/presentation phase upcoming
- **Impact Assessment:**
  - **User Impact:** **Medium** (dev-facing; improves adoption of knowledge features)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (credibility and clarity)
- **Technical Classification:**
  - **Issue Category:** Documentation
  - **Component Affected:** Knowledge subsystem / Data pipelines
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Knowledge pipeline architecture, technical writing, examples
  - **Dependencies:** Confirm “golden path” pipeline flow and recommended tooling
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Publish an outline: ingestion → chunking → embedding → retrieval → evaluation.
  2. Include one end-to-end tutorial with sample dataset + expected outputs.
  3. Add troubleshooting section (common failure modes, performance tips).
- **Potential Assignees:** Jin (owner), docs reviewer(s)

---

## Conclusion

### A) Top 5–10 highest priority items to address immediately
1. **P0:** PR **#6316** — plugin-sql data isolation breaks DB ops (review/merge/release).
2. **P1:** **DISCORD-2026-01-03-API-MODEL-NOT-FOUND** — “Model not found” via API (create GH issue + reproduce + fix).
3. **P1:** **DISCORD-2026-01-03-DISCORD-PLUGIN-VERSIONING** — Discord plugin publishing/version gap (stabilize release pipeline).
4. **P1:** Issue **#6322** — conversation deletion requires refresh (UI invalidation fix).
5. **P2:** Issue **#6319** — agent sorting doesn’t work (fix for manageability/discovery).
6. **P2:** Issue **#6313** — separate public agent states (spec + phased implementation).
7. **P2:** Issue **#6312** — guest message limit (align with #6313; server-side enforcement).
8. **P2:** **DISCORD-2026-01-04-TURBO-MEMORY** — Turbo memory blow-up (triage; prevent CI/dev blocks).
9. **P2:** **DISCORD-2026-01-03-AGENT-KNOWLEDGE-CONFIG** — clarify knowledge/lore config (docs + validation).
10. **P3:** Issue **#6311** — improve chat summaries (quality/polish).

### B) Patterns/themes suggesting deeper architectural problems
- **State invalidation + UI consistency gaps:** Issues like “delete needs refresh” and “sorting doesn’t work” point to missing or inconsistent query invalidation/state management patterns.
- **Release/process fragility in plugins:** Version publishing anomalies suggest the plugin ecosystem needs stronger CI/release guardrails and clearer ownership.
- **Configuration discoverability problems:** Repeated questions about multi-model setup and knowledge/memory configuration indicate schema + docs + tooling need to converge on a “pit of success.”
- **Operational reliability under advanced settings:** The data isolation break (PR #6316) shows high-risk paths (tenancy/isolation) need dedicated regression coverage.

### C) Process improvements to prevent repeats
1. **Add “mutation → invalidate” frontend test coverage** for core CRUD (delete/rename/sort) using e2e smoke tests.
2. **Introduce a plugin release checklist + automated checks** (tag/version existence, changelog presence, npm publish dry-run in CI).
3. **Require minimal repro templates** for Discord-reported bugs (API errors, build perf) and link them to GitHub within 24 hours.
4. **Expand regression suite for “advanced flags”** (e.g., `ENABLE_DATA_ISOLATION`) with CI jobs that run at least nightly.
5. **Strengthen config linting + examples** (extend the logging/config linter approach to agent schema validation and “known-good” templates).