## Issue Triage — 2026-02-12

### 1) CI pipeline instability / failing checks (PR to fix: elizaos/eliza#6477)
- **Current Status:** In progress (fix submitted). CI reported broken; awaiting validation/merge.
- **Impact Assessment:**
  - **User Impact:** Medium (contributors + downstream users waiting for releases)
  - **Functional Impact:** **Yes** (blocks merges/releases; slows incident response)
  - **Brand Impact:** High (signals low engineering reliability)
- **Technical Classification:**
  - **Category:** Bug / Infrastructure
  - **Component:** CI/CD, Repo tooling
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** CI workflows (GitHub Actions), monorepo build/test pipeline, Bun/Node tooling
  - **Dependencies:** None, but may be entangled with recent large PRs (v2/“next”, plugin-bootstrap optimizations)
  - **Estimated Effort (1–5):** 2–3
- **Recommended Priority:** **P0**
- **Actionable Next Steps:**
  1. Reproduce CI failure locally (or via reruns) and confirm root cause category (flaky tests vs config vs dependency resolution).
  2. Validate #6477 fixes all failing jobs across OS matrix and does not mask failures.
  3. Add a minimal “CI health” smoke workflow step (lint + typecheck + one integration test) that runs fast and fails deterministically.
  4. If failures are test-flake related, quarantine flaky tests with tracking issues and retries limited to those suites.
- **Potential Assignees:** **odilitime** (submitted fix), **lalalune** (recent large merges affecting CI), **anchapin** (stability fixes)

---

### 2) Crash on fresh install: `agent_skill_instructions` provider (`skill.description.toLowerCase is not a function`) — Discord report
- **Issue Title & ID:** Agent Skills Provider crash on startup (`skill.description.toLowerCase` type error) — **(Discord; needs GitHub issue)**
- **Current Status:** Known bug (acknowledged by Odilitime); no linked fix/issue in provided data.
- **Impact Assessment:**
  - **User Impact:** High (fresh installs; affects “milaidy VPS installation” path)
  - **Functional Impact:** **Yes** (runtime crash blocks agents from running)
  - **Brand Impact:** High (first-run crash is a major trust breaker)
- **Technical Classification:**
  - **Category:** Bug
  - **Component:** Plugin System / `@elizaos/plugin-agent-skills` (provider `agent_skill_instructions`)
  - **Complexity:** Simple fix (type-guard + schema validation), possibly Moderate if data normalization is inconsistent
- **Resource Requirements:**
  - **Required Expertise:** TypeScript, plugin provider contract, runtime/provider data models
  - **Dependencies:** Confirm shape of `skill` objects across versions; may depend on plugin registry entries
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P0**
- **Actionable Next Steps:**
  1. Create GitHub issue with stack trace + minimal repro (fresh install + plugin list).
  2. Add defensive normalization: `String(skill.description ?? '')` before `.toLowerCase()`; validate `skill.description` type at ingest.
  3. Add unit test covering non-string descriptions (null/object/array).
  4. Release patch version for the plugin; update installation docs with pinned known-good version if needed.
- **Potential Assignees:** **odilitime** (acknowledged bug), **anchapin** (defensive null/type guards track record), **azsxdc** (reporter; can verify fix)

---

### 3) Webapp doubles LLM calls when message contains a URL (elizaos/eliza#6486)
- **Current Status:** Open
- **Impact Assessment:**
  - **User Impact:** High (any user who pastes URLs; common behavior)
  - **Functional Impact:** **Partial** (core chat works but duplicates output/cost)
  - **Brand Impact:** High (visible duplicated responses + unnecessary spend)
- **Technical Classification:**
  - **Category:** Bug / Performance
  - **Component:** Webapp message ingestion + attachment/preview pipeline + SSE streaming
  - **Complexity:** Moderate effort (needs correct de-dupe in processing graph)
- **Resource Requirements:**
  - **Required Expertise:** Client/server message pipeline, SSE streaming, attachment extraction/URL preview logic
  - **Dependencies:** Interaction with “attachment metadata/preview” logic; may intersect with message service refactors
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P0** (cost + UX regression)
- **Actionable Next Steps:**
  1. Instrument logs around message classification: confirm where URL becomes both text and attachment.
  2. Decide single-source-of-truth: either (a) treat URLs as text only, or (b) convert to a single “link attachment” object and remove from text before model call.
  3. Ensure only one LLM invocation per user message; add an idempotency key per message through the pipeline.
  4. Add regression test: send message with URL and assert exactly one model call + one streamed response.
- **Potential Assignees:** **lalalune** (core runtime/message flow work), **odilitime** (core stability), **thewoweffect** (reporter for validation)

---

### 4) ElizaCloud.ai: account recharge fails under VPN / unclear billing flow — Discord feedback (5 investor tests)
- **Issue Title & ID:** VPN compatibility issues prevent recharging; billing UX unclear — **(Discord; likely elizacloud repo; needs GitHub issue)**
- **Current Status:** Unresolved; acknowledged as affecting some users.
- **Impact Assessment:**
  - **User Impact:** Medium → High (any VPN users; crypto-native audience often uses VPN)
  - **Functional Impact:** **Yes** (blocks paid usage / revenue)
  - **Brand Impact:** High (payment failures + confusion)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** ElizaCloud Dashboard + Payments provider integration + anti-fraud rules
  - **Complexity:** Complex solution (depends on payment processor policies, fraud checks, geo/VPN heuristics)
- **Resource Requirements:**
  - **Required Expertise:** Web payments, risk/fraud tooling, backend billing systems, observability
  - **Dependencies:** Payment provider settings; possible need for alternate provider or explicit VPN-tolerant flow
  - **Estimated Effort (1–5):** 4
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Capture failing scenarios: processor error codes, regions, VPN ASN lists; add structured billing error telemetry.
  2. Provide explicit UI error messaging and a fallback path (“Contact support with code X”).
  3. Audit fraud rules/3DS settings; consider allowing “deposit credits” via alternate rails (crypto on-ramp) as fallback.
  4. Publish a short billing FAQ inside the dashboard (what “add USD” means, minimums, settlement).
- **Potential Assignees:** **odilitime** (cloud lead), a dedicated **payments-focused maintainer** (recruit from community: **bigzee** / **aicodeflow** as potential hires), plus whoever owns ElizaCloud billing integration

---

### 5) ElizaCloud.ai: double account creation for one email + duplicated $5 welcome bonus — Discord report
- **Issue Title & ID:** Duplicate accounts / welcome bonus duplication — **(Discord; needs GitHub issue)**
- **Current Status:** Reported; no fix referenced.
- **Impact Assessment:**
  - **User Impact:** Medium (new users)
  - **Functional Impact:** **Partial** (can still use product but causes billing identity issues)
  - **Brand Impact:** High (looks scammy/buggy; also potential financial abuse)
- **Technical Classification:**
  - **Category:** Bug / Security (abuse vector) / UX
  - **Component:** ElizaCloud Auth + user provisioning + referral/welcome-credit logic
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Auth flows, transactional DB constraints, idempotency, anti-abuse
  - **Dependencies:** How identity providers are linked (email/password vs OAuth vs SIWE/Privy)
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Add unique constraint and idempotent “create user” endpoint keyed by normalized email + provider subject.
  2. Make welcome bonus grant a single atomic transaction guarded by a “bonus_granted_at” flag.
  3. Backfill cleanup script: detect duplicates and merge balances/usage histories.
  4. Add audit logs for credit grants to detect abuse patterns.
- **Potential Assignees:** **odilitime**, ElizaCloud backend maintainer familiar with auth/user DB, plus **anchapin** (idempotency/defensive patterns)

---

### 6) Group chat functionality not working — Discord report (core-devs channel)
- **Issue Title & ID:** Group chat broken — **(Discord; needs GitHub issue, likely elizaos/eliza client/server)**
- **Current Status:** Reported; unanswered in thread.
- **Impact Assessment:**
  - **User Impact:** Medium (users trying multi-user chat; potentially a flagship feature)
  - **Functional Impact:** **Yes/Partial** (blocks collaborative usage; may block “community agents” demos)
  - **Brand Impact:** High (chat product perceived unstable)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** Client (group routes/components) + Server (socket/auth) + JWT/data-isolation interactions
  - **Complexity:** Complex solution (likely auth/session isolation + socket rooms + permissions)
- **Resource Requirements:**
  - **Required Expertise:** Websocket/socket.io, auth (JWT), data isolation, client routing/state
  - **Dependencies:** Recent JWT auth + data isolation rollout (PR #6200); group components exist in client
  - **Estimated Effort (1–5):** 4
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Define “broken”: cannot create group, cannot join, messages not delivered, or permissions error—collect exact repro + logs.
  2. Validate against JWT enabled/disabled and data isolation flags.
  3. Add integration test for group chat flow (create group → join → send/receive).
  4. If socket auth is culprit, ensure token refresh + ProtectedRoute doesn’t block socket handshake.
- **Potential Assignees:** **lalalune** (core/client-server), maintainers involved in JWT rollout, plus a frontend-focused contributor

---

### 7) Token migration manual support backlog (ticket-0550 pending >1 week) — Support/Operations
- **Issue Title & ID:** Manual migration ticket backlog (example: **ticket-0550**) — **(Ops; not GitHub)**
- **Current Status:** Pending; user reported >1 week delay; staff said tickets before Feb 4 are being processed.
- **Impact Assessment:**
  - **User Impact:** Medium (subset of holders who missed window; highly vocal)
  - **Functional Impact:** No (doesn’t block framework), but blocks token resolution for affected users
  - **Brand Impact:** High (trust + scam risk; fuels FUD)
- **Technical Classification:**
  - **Category:** UX / Process / Security (scam exposure)
  - **Component:** Support operations, migration tooling
  - **Complexity:** Moderate effort (tooling + staffing)
- **Resource Requirements:**
  - **Required Expertise:** Ops, basic chain/accounting verification, support tooling, anti-scam moderation
  - **Dependencies:** Availability of canonical migration records + tooling to verify claims
  - **Estimated Effort (1–5):** 3
- **Recommended Priority:** **P1**
- **Actionable Next Steps:**
  1. Publish an official status page for migration support (queue size, SLA, cutoff rules).
  2. Build/ship a lightweight internal tool: lookup by txid/wallet, compute owed amount, generate response template.
  3. Add Discord auto-response + pinned message: “Only official tickets; never send tokens to DMs.”
  4. Escalate ticket-0550 as a canary and close it end-to-end to validate the process.
- **Potential Assignees:** **Omid Sa** (already coordinating ticket info), **odilitime** (authority to resolve), a dedicated support moderator

---

### 8) Babylon feedback: “share to farcaster” link displays incorrectly — Discord report
- **Issue Title & ID:** Babylon feedback Farcaster share link incorrect — **(Discord; needs GitHub issue in Babylon repo if separate)**
- **Current Status:** Reported; unanswered where feedback goes.
- **Impact Assessment:**
  - **User Impact:** Low → Medium (users sharing feedback)
  - **Functional Impact:** Partial (sharing/virality loop broken)
  - **Brand Impact:** Medium (rough edges in public-facing UX)
- **Technical Classification:**
  - **Category:** Bug / UX
  - **Component:** Babylon UI / share link builder
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Frontend URL encoding, Farcaster share intents
  - **Dependencies:** None
  - **Estimated Effort (1–5):** 1–2
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Capture screenshot + malformed URL; confirm required Farcaster share format.
  2. Fix encoding (spaces/newlines) and ensure proper OG metadata if used.
  3. Add unit test for share URL generator.
- **Potential Assignees:** Babylon frontend maintainer, **odilitime** (recent Babylon SIWE work suggests involvement)

---

### 9) ElizaCloud authentication: implement SIWE (EIP-4361) + agent-friendly API key generation — Discord action item
- **Issue Title & ID:** SIWE auth + agent API key provisioning for ElizaCloud — **(Discord; needs GitHub issue/epic)**
- **Current Status:** Committed by Odilitime; collaboration with Privy may change implementation.
- **Impact Assessment:**
  - **User Impact:** Medium (developers/agents wanting programmatic access; strategic for “agents as users”)
  - **Functional Impact:** Partial (not required for basic usage, but blocks scalable agent onboarding)
  - **Brand Impact:** Medium → High (clean auth story improves trust and developer adoption)
- **Technical Classification:**
  - **Category:** Feature Request / Security
  - **Component:** ElizaCloud Auth, API, CLI integration
  - **Complexity:** Architectural change (signature auth, provisioning flow, rate limits, abuse prevention)
- **Resource Requirements:**
  - **Required Expertise:** Web3 auth (SIWE), backend security, key management, Privy integration, threat modeling
  - **Dependencies:** Privy roadmap/SDK behavior; decisions on “proof-of-agent” gating
  - **Estimated Effort (1–5):** 4
- **Recommended Priority:** **P2** (start now, but don’t block P0/P1 bug fixes)
- **Actionable Next Steps:**
  1. Write an RFC: threat model, session semantics, how API keys are minted/rotated/revoked, rate limits per agent/entity.
  2. Implement minimal SIWE login + key issuance first; add “proof-of-agent tasks” as a second phase.
  3. Ensure compatibility with existing JWT/data isolation strategy (avoid parallel auth silos).
  4. Add CLI flow: `elizaos cloud login` → obtains token/key non-interactively for agents.
- **Potential Assignees:** **odilitime** (owner), **lalalune** (core/auth architecture), a security-minded reviewer

---

### 10) OpenAI provider should support custom endpoint URL (elizaos/eliza#6490)
- **Current Status:** Open
- **Impact Assessment:**
  - **User Impact:** Medium (users of OpenAI-compatible providers like SiliconFlow)
  - **Functional Impact:** Partial (blocks a common deployment pattern)
  - **Brand Impact:** Medium (developer friction)
- **Technical Classification:**
  - **Category:** Feature Request
  - **Component:** Model Integration / OpenAI provider config
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Provider configuration plumbing, env var/schema updates
  - **Dependencies:** Ensure it doesn’t break existing OpenAI defaults; docs update needed
  - **Estimated Effort (1–5):** 2
- **Recommended Priority:** **P2**
- **Actionable Next Steps:**
  1. Add `OPENAI_BASE_URL` (or provider-specific config field) with default `https://api.openai.com/v1`.
  2. Update docs + examples; add a quick integration test using a mock server.
  3. Confirm streaming + auth headers remain compatible across vendors.
- **Potential Assignees:** **lalalune** (core/provider work), model integration maintainer, **coolRoger** (reporter for validation)

---

## Highest-Priority Focus (Top 5–10 to address immediately)
1. **P0:** CI pipeline instability (validate/merge fix for #6477; restore deterministic checks)
2. **P0:** Agent Skills Provider crash on fresh installs (`skill.description.toLowerCase` type error)
3. **P0:** URL triggers duplicate LLM calls in webapp (elizaos/eliza#6486) causing 2× cost + duplicated output
4. **P1:** ElizaCloud recharge failures under VPN / unclear billing flow (revenue + onboarding)
5. **P1:** ElizaCloud duplicate account creation + duplicated welcome bonus (abuse + trust)
6. **P1:** Group chat not working (core collaboration UX; likely auth/socket related)
7. **P1:** Manual migration support backlog (e.g., ticket-0550) + anti-scam comms
8. **P2:** Babylon Farcaster share link bug (small fix with visible UX benefit)
9. **P2:** SIWE + agent-friendly API key provisioning for ElizaCloud (strategic platform unlock)
10. **P2:** Custom OpenAI endpoint support (elizaos/eliza#6490) for OpenAI-compatible providers

---

## Patterns / Themes Indicating Deeper Issues
- **Input normalization & defensive programming gaps** (provider crashes; URL treated as both text and attachment). Suggests inconsistent schemas across plugins/providers and insufficient validation at boundaries.
- **Auth and multi-tenant complexity surfacing as UX breakage** (group chat issues likely intersecting with JWT/data isolation, socket auth, and routing).
- **Onboarding friction concentrated around “money paths”** (recharge via VPN, unclear USD deposit, duplicate welcome bonus). These are high-sensitivity flows where small bugs have outsized trust impact.
- **Operational support load creates security exposure** (migration delays correlate with scam attempts and community confusion).

---

## Process Improvements (Prevention)
1. **Introduce “boundary schema validation”** at provider interfaces (zod/io-ts) to enforce types early; add “strict mode” in dev that fails fast with actionable errors.
2. **Add cost-regression tests** for common chat patterns (URLs, attachments, previews) to assert “1 user message → ≤1 model call” unless explicitly configured.
3. **Establish release-blocking SLOs:** CI green + fresh-install smoke test + core chat flows (including group chat) must pass before merges to main.
4. **Create a unified incident intake:** Discord bug reports must be converted into GitHub issues within 24h with repro steps, logs, and owner assignment.
5. **Operational transparency for support queues:** publish SLAs/status for migration tickets; pin anti-scam guidance; add automated ticket acknowledgments with tracking IDs.
6. **Payment UX hardening:** add structured billing telemetry, clearer in-dashboard guidance, and a documented fallback payment rail to reduce “silent failure” churn.