## Issue Triage — 2026-01-04

### 1) “Model not found” error when integrating an agent into a website (Discord report — BAOVERSE🌟) — **ID: TBD (needs GitHub issue)**
- **Current Status:** Reported in Discord (#coders). Not yet tracked on GitHub.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks a common “embed agent into site” use case; likely affects many new users)
  - **Functional Impact:** **Yes** (prevents API-based usage / model routing)
  - **Brand Impact:** **High** (new-user failure on a flagship integration path)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (error handling)
  - **Component Affected:** API / Model Integration / Cloud routing (likely)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** API + model registry/routing knowledge; familiarity with OpenRouter/provider config; cloud deployment paths
  - **Dependencies:** Clarify whether this is OpenRouter plugin config, core provider registry, or Cloud API key/agent ID mismatch
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue with exact endpoint, request payload, agent ID, provider config, and full error text.
  2. Reproduce with a minimal sample: “public agent + API key + default provider” and “OpenRouter provider + explicit model”.
  3. Audit model name validation: ensure consistent canonical model IDs across UI, env, and API.
  4. Improve error response: return “known models / expected format / where configured” to reduce support load.
- **Potential Assignees:** **standujar** (core/message/provider path), **Borko** (docs + repro guidance), **Stan ⚡** (provider handling context from PR #6263)

---

### 2) Agent cannot recall information from bio / missing “knowledge & lore” sections in JSON (Discord report — YogaFlame) — **ID: TBD (needs GitHub issue)**
- **Current Status:** Reported in Discord (#coders). Not yet tracked on GitHub.
- **Impact Assessment:**
  - **User Impact:** **High** (affects many agent builders migrating configs / upgrading versions)
  - **Functional Impact:** **Partial** (agent “works” but personalization/memory appears broken)
  - **Brand Impact:** **High** (“agent feels dumb / forgetful” perception)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Core Framework (character config parsing), Memory/Embedding pipeline, Agent runtime prompt construction
  - **Complexity:** **Complex solution** (depends on whether schema changed, migration needed, or memory indexing regression)
- **Resource Requirements:**
  - **Required Expertise:** Character schema/config, memory store + retrieval, prompt assembly
  - **Dependencies:** Confirm current config schema; whether “bio” is included in system prompt; whether knowledge blocks are indexed
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. File GitHub issue with: previous JSON example (old version), current JSON, expected recall behavior, and actual runtime output.
  2. Add/verify automated test: “bio/knowledge content is present in initial context” + “retrievable after N turns”.
  3. Decide product behavior: (a) reintroduce `knowledge`/`lore` fields, (b) provide migration mapping, or (c) clearly document replacements.
  4. Add schema validation errors/warnings in CLI when deprecated fields are used or ignored.
- **Potential Assignees:** **standujar** (core behavior), **Stan ⚡** (runtime/message service familiarity), **Omid Sa** (community repro + validation)

---

### 3) Discord plugin versioning / release mismatch (v1.3.3 → v1.3.5; v1.3.4 update failed) (Discord report — YogaFlame) — **ID: TBD (likely in plugin-discord repo)**
- **Current Status:** Reported in Discord; suggests broken release/publishing pipeline or store propagation inconsistency.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (Discord is a primary integration surface; affects many operators)
  - **Functional Impact:** **Partial** (plugin may work but upgrades/compatibility become unreliable)
  - **Brand Impact:** **Medium** (trust in plugin ecosystem and “it just works” expectation)
- **Technical Classification:**
  - **Issue Category:** Bug / Release Engineering
  - **Component Affected:** Plugin System (plugin-discord), packaging/publishing, registry metadata
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** npm publishing, version tags, CI release workflow, plugin registry integration
  - **Dependencies:** Determine if issue is npm, Chrome/Edge store extension confusion, or internal plugin registry versioning
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Identify exact artifact type: Discord *plugin* vs browser *extension* (Discord users mentioned Chrome/Edge store comparisons).
  2. Audit release tags and package versions for gaps (why 1.3.4 failed; how 1.3.5 shipped).
  3. Add CI guardrails: “version monotonicity”, “tag == package.json”, “registry points to published version”.
  4. Publish a short “How to verify your installed version” doc + troubleshooting steps.
- **Potential Assignees:** **Stan ⚡** (core/devops familiarity), **Borko** (docs), plugin maintainers (not listed in provided contributors)

---

### 4) Separate public agent states (unauth visitor vs authenticated non-owner vs owner) — **Issue #6313**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **High** (public agents are a major acquisition funnel; affects most new visitors)
  - **Functional Impact:** **Partial** (features exist but presented incorrectly; can cause confusion/misuse)
  - **Brand Impact:** **High** (first impression for non-auth visitors)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** GUI (public agent page, auth-gated controls, navigation)
  - **Complexity:** **Architectural change** (state-driven UI rework; requires product clarity + routing rules)
- **Resource Requirements:**
  - **Required Expertise:** Frontend state management, auth/session gating, routing, product UX
  - **Dependencies:** Closely related to #6312 (message limit), possibly #6317 (wallet connect flow if Web3 auth is involved)
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P2** (important funnel work; schedule this sprint if growth/onboarding is a priority)
- **Specific Actionable Next Steps:**
  1. Convert description into acceptance criteria and UI states (what controls render per state).
  2. Implement state detection (unauth, authed non-owner, owner) at route-level and component-level.
  3. Add E2E tests for each state to prevent regressions (visibility of Edit/Fork/Toggle, gating overlay).
  4. Align copy + analytics events (views → chats → signup → fork).
- **Potential Assignees:** **borisudovicic** (reporter/product direction), **standujar** (review/architecture), **wtfsayo** (if frontend contributor bandwidth exists)

---

### 5) Limit messages for non-signed up user to ~2–3 — **Issue #6312**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects unauth visitors; could increase signups but also frustrate)
  - **Functional Impact:** **No** (product gating, not a breakage)
  - **Brand Impact:** **Medium** (paywall/gate perception)
- **Technical Classification:**
  - **Issue Category:** Feature Request / UX
  - **Component Affected:** GUI + API (rate limiting / session tracking), Auth
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Frontend + backend/session; analytics
  - **Dependencies:** Design alignment with #6313 (public states) and credit policy (#6315)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Define gating mechanism (cookie/session ID vs IP vs anon token) and reset policy.
  2. Implement soft gate overlay and clear CTA to sign up.
  3. Add telemetry: conversion rate, drop-off, abuse detection.
- **Potential Assignees:** **borisudovicic**, **standujar**

---

### 6) Connect wallet should ideally go straight to wallet options — **Issue #6317**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **Medium**
  - **Functional Impact:** **Partial** (wallet connection works but flow friction increases drop-off)
  - **Brand Impact:** **Medium** (onboarding polish)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** GUI (auth/wallet connect modal)
  - **Complexity:** **Simple fix–Moderate effort** (depending on current modal architecture)
- **Resource Requirements:**
  - **Required Expertise:** Frontend UI flows; wallet connector integration
  - **Dependencies:** None explicit; coordinate with any ongoing auth/onboarding work
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Map current clicks and remove intermediate step(s).
  2. Ensure wallet list is accessible and supports deep links for common wallets.
  3. Add small usability test / internal QA checklist for first-time connect.
- **Potential Assignees:** **borisudovicic**, **wtfsayo**

---

### 7) Scroll should work on whole page — **Issue #6318**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **Medium** (frustrating, especially for smaller screens; affects many users if global layout issue)
  - **Functional Impact:** **Partial** (blocks navigation/readability)
  - **Brand Impact:** **Medium** (UI quality signal)
- **Technical Classification:**
  - **Issue Category:** UX / Bug
  - **Component Affected:** GUI (layout/CSS container scrolling)
  - **Complexity:** **Simple fix** (typical overflow/layout correction) but verify across routes
- **Resource Requirements:**
  - **Required Expertise:** Frontend CSS/layout
  - **Dependencies:** Ensure no conflicts with chat scrolling containers
  - **Estimated Effort (1–5):** **1–2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Identify affected routes and reproduction (browser + OS).
  2. Fix overflow rules (body/html height, nested containers) and test chat scroll behavior.
  3. Add visual regression check for main layouts.
- **Potential Assignees:** **wtfsayo**, **borisudovicic**

---

### 8) Chat summaries don’t make much sense. Can we improve — **Issue #6311**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **Medium** (quality-of-life; affects navigation and perceived intelligence)
  - **Functional Impact:** **No** (non-blocking)
  - **Brand Impact:** **Medium** (summary quality reflects model quality)
- **Technical Classification:**
  - **Issue Category:** UX / Feature Request
  - **Component Affected:** GUI + summarization pipeline (if server-generated)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Prompting/summarization heuristics, UI labeling, possibly embeddings
  - **Dependencies:** Clarify whether summaries are deterministic (rules) or model-generated; might depend on provider behavior
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Define “good summary” acceptance criteria (length, recency bias, named entities).
  2. Add evaluation set (10–20 real chats) and compare new prompt/heuristic outputs.
  3. Implement fallback titles (first user message, task label) when summary confidence is low.
- **Potential Assignees:** **standujar** (pipeline), **borisudovicic** (UX target)

---

### 9) Public agent cards should have chat number — **Issue #6314**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **Low–Medium**
  - **Functional Impact:** **No**
  - **Brand Impact:** **Low** (nice-to-have social proof)
- **Technical Classification:**
  - **Issue Category:** Feature Request / UX
  - **Component Affected:** GUI + analytics aggregation
  - **Complexity:** **Moderate effort** (needs definition of “chat count” and efficient aggregation)
- **Resource Requirements:**
  - **Required Expertise:** Data aggregation, API additions, UI presentation
  - **Dependencies:** Requires a stable definition of “total messages between agent and all users”
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Define metric precisely (messages vs conversations; include system/tool messages?).
  2. Add API field + caching to avoid expensive counts on listing pages.
  3. Display with privacy considerations for private agents.
- **Potential Assignees:** **borisudovicic**, **standujar**

---

### 10) Change free credits from $5 to $1 — **Issue #6315**
- **Current Status:** **OPEN** (0 comments)
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects all new users; impacts experimentation)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (perceived generosity vs sustainability)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Product
  - **Component Affected:** Billing/Credits (Cloud), onboarding
  - **Complexity:** **Simple fix** (if single config) to **Moderate** (if multiple systems rely on the value)
- **Resource Requirements:**
  - **Required Expertise:** Billing/credits configuration, product analytics
  - **Dependencies:** Coordinate with #6312 gating and acquisition goals
  - **Estimated Effort (1–5):** **1–2**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Validate business rationale with usage data (CAC, abuse, cost per new user).
  2. Implement as a configurable parameter and document it.
  3. Add experiment flag if uncertain (A/B).
- **Potential Assignees:** **borisudovicic** (product), core cloud/billing owner (not in provided contributor list)

---

## Summary — Top Highest Priority Issues to Address Now (next 5–10)
1. **(P1)** “Model not found” website/API integration failure — **ID: TBD**
2. **(P1)** Agent not recalling bio / missing knowledge & lore config support — **ID: TBD**
3. **(P2)** Public agent state separation (unauth vs authed vs owner) — **#6313**
4. **(P2)** Fix global scroll behavior — **#6318**
5. **(P2)** Improve wallet connect flow to show options immediately — **#6317**
6. **(P2)** Message limit gating for unauth users (tie into onboarding state work) — **#6312**
7. **(P2)** Discord plugin versioning/release mismatch — **ID: TBD**
8. **(P3)** Chat summaries quality improvements — **#6311**
9. **(P3)** Add chat count to public agent cards — **#6314**
10. **(P3)** Adjust free credits ($5 → $1) — **#6315**

---

## Patterns / Themes Suggesting Deeper Issues
- **Onboarding & public agent UX is fragmented:** Multiple issues (#6313, #6312, #6317, #6318) point to inconsistent state handling (auth/ownership) and UI polish problems impacting first-time users.
- **Configuration/schema drift impacting agent “intelligence”:** Discord reports about missing `knowledge/lore` and bio recall suggest either breaking schema changes without migration tooling or gaps in prompt/memory indexing.
- **Ecosystem reliability (plugins + integrations):** Versioning mismatches and “model not found” integration failures indicate insufficient validation, clearer error messages, and release discipline across plugins/providers.

---

## Recommendations — Process Improvements
1. **Convert Discord reports into GitHub issues within 24 hours** using a lightweight template (repro steps, config, logs, version, provider/model IDs).
2. **Add E2E test coverage for the acquisition funnel**: public agent page in three auth states + wallet connect flow + unauth message gating.
3. **Introduce config/schema migration tooling** (or at least CLI warnings) for deprecated/ignored character JSON fields that affect memory/context.
4. **Standardize provider/model ID validation and error messages** (return “supported models” + “where to configure” hints).
5. **Establish a plugin release checklist** (version monotonicity, registry update, smoke test, compatibility note) to avoid silent version gaps.