## Issue Triage — 2026-01-05

### 1) **Data isolation breaks all DB operations on PostgreSQL due to parameterized `SET LOCAL`**
- **Issue Title & ID:** `fix(plugin-sql): use sql.raw() for SET LOCAL to avoid parameterization…` — **PR #6316** (acts as a P0 incident)
- **Current Status:** Open PR; not merged; includes unit + integration tests; described as “critical bug”.
- **Impact Assessment:**
  - **User Impact:** **Critical** (any deployment with `ENABLE_DATA_ISOLATION=true` on Postgres is effectively down)
  - **Functional Impact:** **Yes** (breaks database operations)
  - **Brand Impact:** **High** (core reliability regression, multi-tenant/data isolation is a trust feature)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework / DB layer (plugin-sql / Drizzle/Postgres integration)
  - **Complexity:** Simple fix (already implemented) + validation
- **Resource Requirements:**
  - **Required Expertise:** Postgres + Drizzle/sql templating; release engineering
  - **Dependencies:** None, but should be coordinated with release/cut
  - **Estimated Effort (1–5):** **2** (review + merge + release)
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Fast-track review focusing on SQL injection safety of `sql.raw()` usage and correct escaping/quoting strategy for `entityId`.
  2. Run CI + verify integration test against real Postgres in pipeline (or manually if needed).
  3. Merge PR; cut a patch release / announce mitigation.
  4. Add a regression test ensuring `SET LOCAL` commands never pass through parameterization.
- **Potential Assignees:**
  - **0xbbjoker** (author; context owner)
  - **Core maintainer familiar with DB isolation/multi-tenancy** (review/merge)
  - **Release owner** (to ship patch quickly)

---

### 2) **“Model not found” when integrating agent with a website (provider/model configuration mismatch)**
- **Issue Title & ID:** “Model not found error with website integration” — **DISC-2026-01-03-01** (Discord report; needs GitHub issue)
- **Current Status:** Reported in Discord (BAOVERSE🌟); no GitHub issue linked.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks common “embed agent on website” path; likely repeats across new users)
  - **Functional Impact:** **Partial** (core works, but a primary integration path fails)
  - **Brand Impact:** **High** (new-user onboarding breakage)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (configuration validation)
  - **Component Affected:** Model Integration / OpenRouter plugin / API key & model routing
  - **Complexity:** Moderate effort (repro + better validation/errors)
- **Resource Requirements:**
  - **Required Expertise:** Provider routing (OpenRouter/OpenAI/Anthropic), env/config parsing, API error handling
  - **Dependencies:** Clarify whether website integration uses CLI defaults (ElizaOS Cloud default provider) vs OpenRouter env
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue in `elizaos/eliza` with exact error payload + integration steps.
  2. Add preflight validation: when model/provider is missing, fail with actionable guidance (show configured provider, expected model IDs, link to docs).
  3. Add a troubleshooting doc section: “Model not found” causes (wrong provider, outdated model name, missing OpenRouter model prefix, etc.).
  4. Add an automated integration test for “website embed minimal config” to catch provider/model misconfigs early.
- **Potential Assignees:**
  - **standujar (Stan ⚡)** (provider/model configuration guidance; recent core work)
  - **Kenk** (integration/onboarding perspective)
  - **Maintainer familiar with OpenRouter plugin + CLI defaults**

---

### 3) **Agent cannot recall information from bio (memory ingestion/retrieval regression or unclear behavior)**
- **Issue Title & ID:** “Agent’s inability to recall information from bio” — **DISC-2026-01-03-02** (Discord report; needs GitHub issue)
- **Current Status:** Reported in Discord (YogaFlame); no linked issue.
- **Impact Assessment:**
  - **User Impact:** **High** (many agents rely on bio/identity grounding; common expectation)
  - **Functional Impact:** **Partial** (agents still respond, but identity/consistency fails)
  - **Brand Impact:** **High** (perceived as “agent is dumb/unreliable”)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (expected behavior unclear; likely implementation gap)
  - **Component Affected:** Core Framework (memory system, prompt assembly, persona/bio injection)
  - **Complexity:** Moderate effort (needs repro + spec: when/how bio is added to context)
- **Resource Requirements:**
  - **Required Expertise:** Memory architecture, prompt/context builder, tests around persona injection
  - **Dependencies:** May intersect with messaging refactors and multi-step provider execution changes
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert to GitHub issue with: agent config, bio text, prompt template, example conversation where it fails.
  2. Decide expected behavior: bio always in system prompt vs stored memory vs retrieval-augmented inclusion.
  3. Add unit tests: “bio facts must be present in initial context” and “agent answers consistent with bio”.
  4. If retrieval-based, ensure bio is indexed and retrieval threshold guarantees inclusion for identity queries.
- **Potential Assignees:**
  - **Core maintainer familiar with memory/prompt pipeline**
  - **standujar** (core service changes context)
  - **YogaFlame** (repro provider)

---

### 4) **Discord/browser plugin versioning mismatch (v1.3.3 vs v1.3.5) across stores**
- **Issue Title & ID:** “Investigate Discord plugin versioning issue (v1.3.3 to v1.3.5)” — **DISC-2026-01-03-03**
- **Current Status:** Reported in Discord (YogaFlame); Omid Sa suggested checking latest versions across Edge/Chrome stores.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (impacts installation and trust; likely affects non-technical users)
  - **Functional Impact:** **Partial** (feature availability depends on store version)
  - **Brand Impact:** **Medium** (looks like poor release hygiene)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation / Release Engineering
  - **Component Affected:** Plugin distribution pipeline (browser extensions / plugin-discord ecosystem)
  - **Complexity:** Moderate effort (audit release process + store propagation + documentation)
- **Resource Requirements:**
  - **Required Expertise:** Release management, browser extension publishing, version pinning
  - **Dependencies:** Identify which “Discord plugin” is meant (browser extension vs `elizaos-plugins/plugin-discord`)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Clarify artifact: browser extension name + store links + expected version; map to repo/tag/commit.
  2. Document store rollout delays and add “current stable version” badge in docs.
  3. Add CI step that verifies version alignment (manifest version ↔ git tag ↔ release notes).
  4. Post a pinned Discord note with troubleshooting steps until fixed.
- **Potential Assignees:**
  - **Omid Sa** (already troubleshooting)
  - **Plugin maintainer for Discord integration**
  - **Release/ops maintainer**

---

### 5) **Public agent page UX conflates unauthenticated visitor, authenticated non-owner, and owner flows**
- **Issue Title & ID:** “Separate public agent states” — **#6313**
- **Current Status:** Open; detailed UX spec for three states + gating flow.
- **Impact Assessment:**
  - **User Impact:** **High** (public agent links are a core discovery/onboarding mechanism)
  - **Functional Impact:** **No** (not a crash), but affects core product funnel
  - **Brand Impact:** **High** (first impression for new visitors)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** GUI (public agent page, auth gating, ownership detection)
  - **Complexity:** Complex solution (multiple UI states, permissions, routing, analytics hooks)
- **Resource Requirements:**
  - **Required Expertise:** Frontend (state/route/auth), product UX, possibly backend for analytics counters
  - **Dependencies:** Likely linked to #6312 (message limit gating) and #6314 (chat numbers), possibly auth/session handling
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Break into subtasks: (a) unauth visitor UI, (b) authenticated non-owner UI, (c) owner UI.
  2. Define authorization checks and routing rules (owner vs non-owner; public vs private).
  3. Implement feature flags for incremental rollout to reduce risk.
  4. Add E2E tests for all 3 states.
- **Potential Assignees:**
  - **borisudovicic** (author; product intent)
  - **Frontend maintainer(s)** (public pages/auth flows)
  - **Kenk** (onboarding/funnel alignment)

---

### 6) **Limit messages for non-signed-up users to 2–3 (soft gate for public agents)**
- **Issue Title & ID:** “Limit messages for non-signed up user to ~2-3” — **#6312**
- **Current Status:** Open.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects unauth visitors; can prevent abuse and manage costs)
  - **Functional Impact:** **Partial** (intentionally restricts functionality)
  - **Brand Impact:** **Medium** (if implemented poorly, could feel “bait-and-switch”)
- **Technical Classification:**
  - **Issue Category:** UX / Feature Request (growth + cost control)
  - **Component Affected:** API + GUI (rate limiting/quota enforcement + UI overlay)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Backend request/session tracking, frontend gating UI, analytics
  - **Dependencies:** Ideally coordinated with #6313 public states; also aligns with credit changes (#6315)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2** (upgrade to P1 if infra costs/abuse is currently acute)
- **Specific Actionable Next Steps:**
  1. Specify enforcement mechanism: per-IP, per-session cookie, or device fingerprint (privacy implications).
  2. Define bypass rules (signed-in users, owners, allowlist).
  3. Add clear UX copy and “Sign up to continue” flow.
  4. Add telemetry: conversion and drop-off at gate.
- **Potential Assignees:**
  - **borisudovicic** (product direction)
  - **Frontend + backend owner for auth/session**
  - **Kenk** (growth/onboarding)

---

### 7) **Chat summaries are low-quality / confusing**
- **Issue Title & ID:** “Chat summaries don't really make much sense. Can we improve” — **#6311**
- **Current Status:** Open; includes example screenshots of current vs desired.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects navigation and comprehension of chat history)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (perceived polish)
- **Technical Classification:**
  - **Issue Category:** UX / Bug (summary generation quality)
  - **Component Affected:** GUI + summarization logic (prompting/heuristics)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Prompting/summarization, UI display constraints
  - **Dependencies:** None, but should align with any upcoming messaging/refactor changes
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document acceptance criteria: length, format (“Topic: …”), avoid nonsense tokens, language consistency.
  2. Add deterministic fallback: first user message truncated + keyword extraction if LLM summary fails.
  3. Add evaluation set: 20–50 conversations with expected summary patterns.
  4. Ship behind a feature flag; compare engagement/navigation metrics.
- **Potential Assignees:**
  - **Frontend maintainer**
  - **Core maintainer for summarization pipeline**
  - **borisudovicic** (UX expectation)

---

### 8) **Public agent cards should display chat/message count (“chat number”)**
- **Issue Title & ID:** “Public agent cards should have chat number” — **#6314**
- **Current Status:** Open; no comments.
- **Impact Assessment:**
  - **User Impact:** **Low–Medium** (improves discovery/trust via social proof)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low–Medium**
- **Technical Classification:**
  - **Issue Category:** Feature Request / UX
  - **Component Affected:** GUI + backend stats aggregation
  - **Complexity:** Moderate effort (requires correct definition + efficient aggregation)
- **Resource Requirements:**
  - **Required Expertise:** Backend aggregation, caching, frontend UI
  - **Dependencies:** Might pair naturally with #6313 state separation and future analytics
  - **Estimated Effort (1–5):** **2–3**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Confirm metric definition (total messages across all users; include system/tool messages or not).
  2. Add backend endpoint / cached counter updated on message write.
  3. Update agent card UI and add tests for correctness/performance.
- **Potential Assignees:**
  - **Frontend maintainer**
  - **Backend maintainer familiar with message storage**
  - **borisudovicic** (requester)

---

### 9) **Change free credits from $5 to $1**
- **Issue Title & ID:** “Change free credits from $5 to $1” — **#6315**
- **Current Status:** Open; no comments.
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects all new users; potentially reduces ability to trial)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (perception of generosity/onboarding friendliness)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Product Ops
  - **Component Affected:** Billing/Credits system (likely API + onboarding)
  - **Complexity:** Simple fix (config), but needs product decision + comms
- **Resource Requirements:**
  - **Required Expertise:** Billing/credits configuration, product analytics
  - **Dependencies:** Ideally coordinate with #6312 gating strategy to avoid double-friction
  - **Estimated Effort (1–5):** **1–2**
- **Recommended Priority:** **P2** (if burn/abuse is driving urgency); otherwise **P3**
- **Specific Actionable Next Steps:**
  1. Confirm rationale with metrics (CAC, abuse rates, average trial consumption).
  2. Implement config change + update docs/onboarding copy.
  3. Add monitoring for signup conversion and support tickets post-change.
- **Potential Assignees:**
  - **borisudovicic** (opened; likely product driver)
  - **Owner of credits/billing subsystem**

---

## Highest-Priority Focus (Top 5–10)

1. **P0 — PR #6316:** Postgres data isolation broken by parameterized `SET LOCAL` (merge + patch release immediately).
2. **P1 — DISC-2026-01-03-01:** “Model not found” website integration failure (convert to GH issue; add validation + docs).
3. **P1 — DISC-2026-01-03-02:** Agent cannot recall bio (memory/prompt ingestion correctness; define expected behavior + tests).
4. **P1 — #6313:** Separate public agent states (critical onboarding UX; implement in slices).
5. **P2 — #6312:** Non-signed-up message limit gating (coordinate with #6313; ensure good UX + privacy-safe enforcement).
6. **P2 — #6311:** Improve chat summaries (quality + deterministic fallback + eval set).
7. **P2 — DISC-2026-01-03-03:** Plugin versioning mismatch across stores (release hygiene + documentation).
8. **P2/P3 — #6315:** Free credits $5 → $1 (product decision; coordinate with gating).
9. **P3 — #6314:** Show chat count on public agent cards (requires counters/analytics plumbing).

---

## Cross-Issue Patterns / Themes (Potential Deeper Architectural Problems)

1. **Configuration + provider routing is brittle**: Repeated confusion around multi-model setups and “model not found” suggests missing preflight validation, weak error messaging, and unclear docs for provider/model naming.
2. **Onboarding/public sharing is under-specified in code**: Multiple issues (#6313, #6312, #6314, #6315) point to the need for a cohesive “public agent funnel” architecture (state machine + metrics).
3. **Core reliability hinges on database edge cases**: The `SET LOCAL` parameterization incident indicates insufficient integration test coverage for Postgres-specific behavior, especially for multi-tenant/data isolation features.
4. **Memory/persona expectations mismatch**: “Bio recall” complaints suggest either a regression or unclear contract about what gets injected into context and when.

---

## Process Improvement Recommendations

1. **Introduce “Incident Fast Path” for P0s**
   - Label PRs/issues as P0, require same-day review, and define a patch release playbook (merge → tag → announce).
2. **Add preflight config validation + “doctor” command**
   - A CLI `eliza doctor` (or startup checks) that validates provider/model IDs, required env vars, and prints actionable fixes.
3. **Strengthen Postgres integration coverage**
   - CI job running a minimal Postgres matrix for critical DB features (data isolation, transactions, `SET LOCAL`, migrations).
4. **Formalize Discord → GitHub intake**
   - Use a lightweight template and assign an “intake captain” weekly to convert Discord reports into reproducible GitHub issues with logs/config.
5. **Define UX state machines for key funnels**
   - For public agents, codify the three-state model (#6313) and enforce with E2E tests to prevent UI regressions.