# Issue Triage — 2026-01-18

## 1) USE_OPENAI_EMBEDDING setting not respected → SQL embedding dimension mismatch
- **Issue Title & ID:** `USE_OPENAI_EMBEDDING setting not respected (dimension mismatch → SQL errors)` — elizaos/eliza **#6380**
- **Current Status:** Open (flagged “URGENT ATTENTION REQUIRED” in dev summary)
- **Impact Assessment:**
  - **User Impact:** **High** (anyone using embeddings + SQL adapter; likely common path)
  - **Functional Impact:** **Yes** (breaks memory/embedding storage; can crash or block agent init/search)
  - **Brand Impact:** **High** (core “it doesn’t work” failure; looks like broken configuration)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Core Framework + plugin-sql / embeddings pipeline
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript core runtime, embedding providers, plugin-sql schema/migrations
  - **Dependencies:** May intersect with `EMBEDDING_DIMENSION` logic (recent optimization) and adapter dimension resolution
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Reproduce with a minimal config matrix:
     - `USE_OPENAI_EMBEDDING=true/false`
     - `EMBEDDING_DIMENSION` set/unset
     - SQL adapters (pg/pglite/neon) if applicable
  2. Trace the “effective embedding provider” selection order and ensure `USE_OPENAI_EMBEDDING` is honored consistently at runtime initialization and memory search/write.
  3. Add a hard validation at startup:
     - If DB embedding dimension != provider output, fail fast with a clear diagnostic and remediation steps.
  4. Add regression tests covering:
     - config precedence
     - dimension negotiation / persistence
  5. Document the canonical config combinations (including `EMBEDDING_DIMENSION`) in env var docs.
- **Potential Assignees:**
  - **standujar** (plugin-sql architecture/testing)
  - **0xbbjoker** (SQL/adapter correctness)
  - **wtfsayo** (core reliability + plugin-sql changes)
  - **Shaw** (final call on expected config behavior)

---

## 2) Discord integration regression: `this.runtime.elizaOS.sendMessage` is undefined
- **Issue Title & ID:** `Discord client TypeError: this.runtime.elizaOS.sendMessage is undefined` — **Discord report** (no GH issue ID referenced; blocked pending PR in **elizaos-plugins/plugin-discord** + `@elizaos/cli` **1.7.1**)
- **Current Status:** Reported by users; fix blocked on plugin-discord PR + CLI version alignment
- **Impact Assessment:**
  - **User Impact:** **High** (Discord is a primary integration surface; many community bots)
  - **Functional Impact:** **Yes** (breaks Discord message handling)
  - **Brand Impact:** **High** (high-visibility integration looks unstable)
- **Technical Classification:**
  - **Issue Category:** Bug / Integration
  - **Component Affected:** Plugin System (plugin-discord) + CLI/runtime API compatibility
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** plugin-discord internals, runtime messaging APIs, release/versioning
  - **Dependencies:** Specific pending PR in plugin-discord; requires `@elizaos/cli` 1.7.1 compatibility confirmation
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create/locate the corresponding GitHub issue in `elizaos-plugins/plugin-discord` (if missing, open one with stack trace + version matrix).
  2. Identify what `runtime.elizaOS.sendMessage` is expected to be (API contract) and when it was changed/removed.
  3. Patch plugin-discord to use the current supported messaging interface (or reintroduce a compatibility shim).
  4. Publish a compatibility table:
     - `eliza` core version ↔ `plugin-discord` version ↔ `@elizaos/cli` version
  5. Add an integration test that boots a minimal Discord adapter and asserts message send path exists.
- **Potential Assignees:**
  - **odilitime** (recent integration/compat fixes; good for API contract alignment)
  - **Stan ⚡** (review/merge throughput)
  - **Shaw** (runtime API intent/approval)

---

## 3) Remove/raise 500-character limit in first application prompt
- **Issue Title & ID:** `Remove 500-character limit in the first application prompt` — elizaos/eliza **#6381**
- **Current Status:** Open (flagged “URGENT ATTENTION REQUIRED”)
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (new users onboarding; anyone with complex first prompt)
  - **Functional Impact:** **Partial** (workflow friction; not a crash)
  - **Brand Impact:** **Medium** (feels arbitrary / “toy product” limitation)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** App / onboarding prompt UI + server validation (if enforced backend)
  - **Complexity:** Simple fix (if purely UI) to Moderate (if DB/schema/validation constraints)
- **Resource Requirements:**
  - **Required Expertise:** Frontend + API validation
  - **Dependencies:** Confirm whether limit is enforced client-side, server-side, or DB column sizing
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Locate where the limit is enforced (UI text field, API validator, DB schema).
  2. Replace hard cap with:
     - a higher cap (e.g., 4k–16k) aligned to model context practices, or
     - soft guidance (warning + truncation preview) if needed.
  3. Add tests ensuring prompt isn’t silently truncated without user visibility.
  4. Update onboarding docs to recommend prompt sizing best practices.
- **Potential Assignees:**
  - **borisudovicic** (UX/product issues history)
  - **madjin** (web UX features)
  - **Shaw** (product direction)

---

## 4) Token migration UX failures (Trust Wallet serialization error; Phantom button non-functional)
- **Issue Title & ID:** `Token migration failures: Trust Wallet “serialized message is not a function”; Phantom migration button broken` — **Discord reports** (no GH issue IDs referenced)
- **Current Status:** Ongoing user reports; Phantom workaround (clear site data) exists; Trust Wallet error unresolved in provided data
- **Impact Assessment:**
  - **User Impact:** **Critical** (broad holder base; migration deadline pressure)
  - **Functional Impact:** **Yes** (users cannot migrate)
  - **Brand Impact:** **High** (money-adjacent flow; high reputational risk)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Migration web app + wallet connectors/provider compatibility
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration (EVM/Solana depending on flow), frontend state mgmt, signing/serialization
  - **Dependencies:** Wallet SDK versions; migration backend; clear public spec of supported wallets
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0** (if owned by elizaOS team; otherwise P1 with immediate comms)
- **Specific Actionable Next Steps:**
  1. Publish an “official supported wallets + known issues” page and pin it (Discord + site).
  2. Capture telemetry (or at least reproducible logs) from affected wallets:
     - Trust Wallet browser vs mobile in-app browser
     - Phantom browser extensions + version
  3. Add a “diagnostics mode” to show exact wallet adapter + signing path + failure location.
  4. Implement robust fallback signing/serialization handling for Trust Wallet adapter (likely mismatch in expected message type/serializer).
  5. If Phantom issue is cache/state related, add a built-in “Reset connection” button and defensive state clearing on failure.
- **Potential Assignees:**
  - **Shaw** (coordination/ownership)
  - **odilitime** (CLI/env + integration stability mindset)
  - A dedicated Web3/frontend maintainer (not clearly identified in provided data)

---

## 5) Security/brand incident: GitHub repo spoofing via manipulated commits
- **Issue Title & ID:** `Mitigate repo spoofing confusion (commit email spoofing) + improve official verification guidance` — **Discord incident** (no GH issue ID referenced)
- **Current Status:** Acknowledged as not a hack; community confusion persists
- **Impact Assessment:**
  - **User Impact:** **Medium** (security-sensitive users; contributors)
  - **Functional Impact:** **No**
  - **Brand Impact:** **High** (perceived compromise risk)
- **Technical Classification:**
  - **Issue Category:** Security (communications / supply-chain trust)
  - **Component Affected:** Project governance + documentation + repo settings
  - **Complexity:** Simple fix (docs) to Moderate (policy enforcement)
- **Resource Requirements:**
  - **Required Expertise:** GitHub security, release signing, contributor verification practices
  - **Dependencies:** GitHub org settings; documented policies; CI attestation choices
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add a SECURITY.md section: “How to verify real elizaOS code/announcements” (PGP-signed commits, verified org members, official repos list).
  2. Pin an announcement: “We will never announce via unofficial repos; here’s the canonical repo list.”
  3. Consider enforcing:
     - “Require signed commits” (where feasible)
     - branch protection + verified signatures for release tags
  4. Add release provenance/attestation (SLSA-style) for published artifacts (CLI builds, docker images).
- **Potential Assignees:**
  - **wtfsayo** (CI/security workflows)
  - **odilitime** (process + docs + core maintainer)
  - **Shaw** (org policy decisions)

---

## 6) Polymarket integration: Safe proxy wallet architecture is confusing; plugin should “just work”
- **Issue Title & ID:** `Polymarket uses Safe proxy (1/1 multisig): address mismatch vs exported private key; plugin-polymarket should handle proxy flow` — **Discord report** (example plugin + okay-bet/plugin-polymarket referenced; no GH issue ID provided)
- **Current Status:** Under investigation by users; explanation provided (proxy Safe); unclear if plugin handles automatically
- **Impact Assessment:**
  - **User Impact:** **Medium** (subset building Polymarket agents; but high-value use case)
  - **Functional Impact:** **Partial** (trading fails if auth/address handling wrong)
  - **Brand Impact:** **Medium** (integration seen as fragile/opaque)
- **Technical Classification:**
  - **Issue Category:** Bug / Documentation
  - **Component Affected:** Model Integration (trading plugin) / Plugin System
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** EVM wallets, Safe contract interaction, Polymarket CLOB auth headers, plugin architecture
  - **Dependencies:** Polymarket API requirements; plugin-polymarket design decisions
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2** (P1 if positioned as an official flagship example)
- **Specific Actionable Next Steps:**
  1. Confirm expected auth flow: signer EOA → Safe proxy address; identify required headers/fields.
  2. Update plugin-polymarket to:
     - detect Safe proxy automatically (or accept `proxyAddress`)
     - validate that deposited funds are in the proxy and warn clearly otherwise
  3. Add a doc page: “Polymarket wallets: signer vs proxy Safe; what keys you store; what address holds funds.”
  4. Provide a minimal “known-good” example config + end-to-end test (place/cancel order in sandbox).
- **Potential Assignees:**
  - **Shaw** (owns the example direction)
  - **sayonara** (demonstrated domain understanding; good reviewer/consult)
  - A plugin maintainer from okay-bet/plugin-polymarket (external coordination)

---

## 7) Polymarket CLOB API blocked by Cloudflare in serverless (Supabase Edge Functions) + proxy/cert limitations
- **Issue Title & ID:** `Cloudflare 403 calling Polymarket CLOB API from Supabase Edge; Oxylabs proxy cert failures (UnknownIssuer) and runtime proxy restrictions` — **Discord report**
- **Current Status:** Unresolved in serverless; recommendation trending toward self-hosting with static egress
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects a common deployment choice for builders)
  - **Functional Impact:** **Partial** (integration unusable in that environment)
  - **Brand Impact:** **Medium** (looks like “Eliza can’t deploy serverless” even if it’s third-party constraints)
- **Technical Classification:**
  - **Issue Category:** Performance/Integration (networking) + Documentation
  - **Component Affected:** Deployment guidance; plugin-polymarket networking
  - **Complexity:** Architectural change (if insisting on serverless compatibility); otherwise simple doc fix
- **Resource Requirements:**
  - **Required Expertise:** Networking, Cloudflare behaviors, serverless runtime constraints, compliance/geofencing considerations
  - **Dependencies:** Polymarket/Cloudflare policies; Supabase Edge runtime capabilities
  - **Estimated Effort (1–5):** **2** (document + recommended architectures) / **5** (make serverless robust)
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Document a supported deployment pattern for Polymarket agents:
     - dedicated server/VPS, static IP, private node/provider
  2. Add a troubleshooting guide:
     - 403 causes (geo/compliance, bot detection)
     - required headers/user-agent patterns
     - why custom CA/proxy env vars fail in Supabase Edge
  3. If prioritizing serverless support: prototype a “browser-like fetch” worker or an egress proxy under user control.
- **Potential Assignees:**
  - **Chucknorris | ONYX P9 NODE RENT** (architecture guidance; could co-design reference deployment)
  - **Shaw** (official guidance)
  - DevRel/docs contributor for publishing the deployment guide

---

## 8) Windows/WSL plugin path resolution issues (Spartan setup without Docker)
- **Issue Title & ID:** `Windows/WSL: Spartan setup plugin path resolution errors (no Docker)` — **Discord report**
- **Current Status:** Reported; WSL recommended but still problematic
- **Impact Assessment:**
  - **User Impact:** **Medium** (Windows devs are a meaningful segment)
  - **Functional Impact:** **Partial** (blocks local development for some)
  - **Brand Impact:** **Medium** (cross-platform “it’s broken on Windows” perception)
- **Technical Classification:**
  - **Issue Category:** Bug / Developer Experience
  - **Component Affected:** CLI + Plugin loader + path handling
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Node/Bun path resolution, Windows filesystem semantics, WSL interoperability
  - **Dependencies:** Repro project + environment details; possibly related to CLI directory validation work
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Collect exact error output + how plugins were installed (workspace vs global vs symlink).
  2. Add a Windows CI smoke test for:
     - plugin discovery
     - relative/absolute path handling
  3. Harden plugin path resolution:
     - normalize separators
     - avoid assumptions about case sensitivity
     - improve error messages with “expected path / resolved path”
  4. Publish a canonical Windows setup guide (WSL2 + recommended shell + known pitfalls).
- **Potential Assignees:**
  - **odilitime** (CLI/env handling)
  - **Stan ⚡** (review/merge)
  - A Windows-heavy community contributor (not identified in provided data)

---

## 9) Unclear versioning/merge strategy: PR #6113 held for 2.x despite user impact
- **Issue Title & ID:** `Decide fate of PR #6113 (held for 2.x) vs backport to 1.x` — elizaos/eliza **PR #6113** (pending decision)
- **Current Status:** Rebased with working tests; merge on hold pending Shaw decision
- **Impact Assessment:**
  - **User Impact:** **Medium** (depends on what correctness fixes it contains; described as correctness-over-speed for streaming work)
  - **Functional Impact:** **Partial** (potential correctness bugs remain in current release line)
  - **Brand Impact:** **Medium** (signals process uncertainty; slows fixes)
- **Technical Classification:**
  - **Issue Category:** Process / Bugfix release management
  - **Component Affected:** Core Framework (streaming/message service related)
  - **Complexity:** Moderate effort (evaluation + potential backport conflicts)
- **Resource Requirements:**
  - **Required Expertise:** Core maintainers, release management, test validation
  - **Dependencies:** V2 roadmap; risk tolerance for 1.x patch releases
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Summarize PR #6113 changes into:
     - “safe for 1.x” parts vs “2.x-only” parts
  2. If safe: backport minimal correctness fixes into a small 1.x PR.
  3. Establish a rule: criteria for holding fixes for 2.x vs shipping in 1.x (severity-based).
- **Potential Assignees:**
  - **Shaw** (decision owner)
  - **Stan ⚡** (merge/review execution)
  - **odilitime** (author context)

---

# Immediate Focus Summary (Top Priority 5–10)
1. **P0:** elizaos/eliza **#6380** — `USE_OPENAI_EMBEDDING` not respected → embedding dimension mismatch & SQL errors  
2. **P0:** **Discord integration regression** — `runtime.elizaOS.sendMessage` undefined (plugin-discord + CLI alignment)  
3. **P0/P1:** **Token migration failures** — Trust Wallet serialization error; Phantom migration UI failures (plus urgent comms)  
4. **P1:** elizaos/eliza **#6381** — remove/raise 500-char first prompt limit  
5. **P1:** **Repo spoofing confusion** — publish verification guidance + strengthen signing/attestation practices  
6. **P2:** **Polymarket proxy Safe wallet flow** — make plugin handle proxy automatically + document signer vs proxy  
7. **P2:** **Polymarket Cloudflare 403 in serverless** — publish supported deployment patterns + troubleshooting  
8. **P2:** **Windows/WSL plugin path issues** — improve path resolution + Windows CI smoke tests  
9. **P2:** **PR #6113 release strategy** — decide backport vs 2.x hold based on severity

---

# Cross-Issue Patterns / Themes
- **Configuration precedence & contract drift:** Multiple breakages stem from “setting says X but runtime does Y” (e.g., embeddings dimension resolution; Discord sendMessage API changes).
- **Version compatibility gaps across the ecosystem:** Core ↔ CLI ↔ plugins (notably Discord) lack a clearly enforced compatibility matrix, causing runtime missing-method failures.
- **Integration “edge environment” fragility:** Serverless/network constraints (Cloudflare + Supabase Edge) and platform differences (Windows/WSL) highlight missing official support boundaries and reference deployments.
- **High-stakes user flows need stronger UX + observability:** Token migration and wallet interactions need better error diagnostics, guided recovery, and pinned official instructions.

---

# Recommendations (Process Improvements)
1. **Publish and enforce a compatibility matrix** (core, CLI, first-party plugins). Add CI checks that fail builds when declared peer dependencies drift.
2. **Add “startup validation gates”** for critical configuration (embedding provider selection, embedding dimension vs DB schema). Prefer fast-fail with actionable remediation text.
3. **Introduce a “Reference Deployments” docs section** for high-demand integrations (Discord, Polymarket), explicitly stating supported environments (serverless vs VPS) and providing known-good templates.
4. **Strengthen release provenance and trust signals**:
   - SECURITY.md + pinned “official repos” list
   - signed tags/releases where feasible
   - artifact attestation for CLI builds
5. **Create an intake rule for Discord-reported bugs**: if it blocks core integrations or money flows, it must become a tracked GitHub issue within 24 hours with owner + milestone.