## Issue Triage — 2026-01-03 (elizaOS)

### 1) Token migration: tokens not appearing / transfer failures to Phantom
- **Issue Title & ID:** AI16Z → ElizaOS migration: tokens not showing in Phantom after transfer (Discord: 💬-discussion, 2026-01-02; no GitHub ID)
- **Current Status:** Reported by multiple users; support happening ad-hoc in DMs; no linked tracked issue in GitHub from provided data.
- **Impact Assessment:**
  - **User Impact:** **Critical** (migration affects a large portion of token holders; repeated reports)
  - **Functional Impact:** **Yes** (blocks migration completion / perceived loss of funds)
  - **Brand Impact:** **High** (trust + credibility risk)
- **Technical Classification:**
  - **Issue Category:** Bug / UX / Documentation (likely a mix of wallet UX + chain/contract/wallet indexing)
  - **Component Affected:** Migration site + wallet connectivity + chain RPC/indexing + support/docs
  - **Complexity:** **Moderate effort** (triage + repro + fix + comms)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet flows, Phantom/MetaMask behaviors, token contract + explorer verification, frontend telemetry, support playbooks
  - **Dependencies:** Need clarity on supported wallets/chains, snapshot rules, and whether issue is UI-only vs on-chain state
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a tracked GitHub issue in the appropriate repo (core/docs/migration) with a standard incident template (wallet, chain, tx hash, timestamp, screenshots).
  2. Publish an “Immediate Checks” guide: verify tx on explorer, add token contract to Phantom, confirm correct network, wait for indexing, common misroutes.
  3. Add migration-site UX: post-transfer status stepper + “paste tx hash” validator + automatic detection of chain/network mismatch.
  4. Add internal support macros and a single canonical Discord help thread to reduce DMs and inconsistent answers.
- **Potential Assignees:** Kenk (wallet workaround context), Pete (support triage), Borko (token utility/migration comms), Shaw (platform/infrastructure coordination)

---

### 2) Token migration: lack of WalletConnect / Tangem support requests
- **Issue Title & ID:** Add WalletConnect (and/or Tangem) support for token migration (Discord: 💬-discussion, 2026-01-02; no GitHub ID)
- **Current Status:** Requested by users; no implementation plan referenced in provided logs.
- **Impact Assessment:**
  - **User Impact:** **High** (users blocked if their wallet cannot connect)
  - **Functional Impact:** **Partial** (migration possible only for a subset of wallets)
  - **Brand Impact:** **High** (seen as exclusionary/broken)
- **Technical Classification:**
  - **Issue Category:** UX / Feature / Documentation
  - **Component Affected:** Migration site wallet adapter layer
  - **Complexity:** **Complex solution** (depends on current auth/signing flow and chain support)
- **Resource Requirements:**
  - **Required Expertise:** WalletConnect integration, EIP-1193 provider handling, mobile/desktop wallet deep links, security review for signing
  - **Dependencies:** Current wallet stack; supported chains; security constraints around signing/bridging
  - **Estimated Effort:** **5/5**
- **Recommended Priority:** **P1** (P0 if migration volumes spike and Tangem share is high)
- **Specific Actionable Next Steps:**
  1. Quantify how many users are blocked (support ticket tags + Discord polling + on-site failed-connection telemetry).
  2. If WalletConnect is viable, implement as an alternative connector; otherwise publish an official workaround (e.g., import EOA into Phantom) with risk warnings.
  3. Add a “Supported Wallets” matrix + “What if my wallet isn’t supported?” decision tree to docs and migration UI.
- **Potential Assignees:** Shaw (launch coordination), Kenk (wallet support context), a frontend contributor familiar with wallet providers (unidentified in provided data)

---

### 3) `singleShot` needs parameter support to prevent “action problems”
- **Issue Title & ID:** Make `singleShot` support parameters to prevent action problems (Discord: core-devs, 2026-01-02; no GitHub ID)
- **Current Status:** Acknowledged (“Yes”) by Stan ⚡; not shown as filed/linked.
- **Impact Assessment:**
  - **User Impact:** **High** (affects agent tool/action reliability; likely hits many workflows)
  - **Functional Impact:** **Partial** (breaks or degrades action execution in common agent patterns)
  - **Brand Impact:** **Medium–High** (agents feel unreliable)
- **Technical Classification:**
  - **Issue Category:** Bug / Core reliability
  - **Component Affected:** Core Framework (action execution / tool invocation pipeline)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Core runtime, tool/action schema, parameter extraction + validation
  - **Dependencies:** Related “multi-step workflows with retry logic and parameter extraction” work in progress
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert the Discord action item into a GitHub issue with a minimal reproducible example (current behavior vs expected).
  2. Define parameter passing contract (types, defaults, serialization) and add validation errors that surface to users.
  3. Add tests covering: missing params, extra params, nested objects, and backwards compatibility with existing singleShot calls.
- **Potential Assignees:** Stan ⚡ (core review/streaming context), Odilitime (raised the need), Shaw (core oversight)

---

### 4) Streaming functionality review/merge blocker (PR #6286 mentioned)
- **Issue Title & ID:** Streaming functionality stabilization (PR #6286 referenced in Discord; exact PR not included in provided GitHub list)
- **Current Status:** Being reviewed/tested by Stan ⚡; “made improvements/fixes” and planned merge.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (streaming is a major UX/perf feature for interactive agents)
  - **Functional Impact:** **Partial** (core works, but real-time responsiveness limited/buggy without streaming)
  - **Brand Impact:** **Medium** (perceived modernity/responsiveness)
- **Technical Classification:**
  - **Issue Category:** Performance / Bug
  - **Component Affected:** Core Framework + Model Integration (streaming adapters)
  - **Complexity:** **Complex solution** (edge cases + transport + logging)
- **Resource Requirements:**
  - **Required Expertise:** Streaming protocols, message aggregation, DB logging consistency, backpressure handling
  - **Dependencies:** Prior fix to streaming DB logging noted in weekly summary; plugin streaming parity across providers
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Ensure PR has: reproducible demo, load/latency notes, and regression tests for partial chunks + cancel + reconnect.
  2. Verify “streaming calls reliably logged to DB” remains correct under streaming concurrency.
  3. Publish a short “Streaming support status” note for plugin maintainers to align implementations.
- **Potential Assignees:** Stan ⚡ (active reviewer), Shaw (core/platform), plugin maintainers as follow-ups (not specified here)

---

### 5) Public agent UX is conflating distinct states (unauthenticated vs authenticated vs owner)
- **Issue Title & ID:** Separate public agent states — **#6313**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **High** (public agent links are a growth funnel; confusion impacts many first-time users)
  - **Functional Impact:** **Partial** (core chat works, but incorrect controls/visibility harms usage)
  - **Brand Impact:** **High** (first impression quality)
- **Technical Classification:**
  - **Issue Category:** UX
  - **Component Affected:** GUI / Web app (public agent pages, auth gating, permissions)
  - **Complexity:** **Architectural change** (permissioned UI states + routes + component decomposition)
- **Resource Requirements:**
  - **Required Expertise:** Frontend architecture, auth/permissions, product UX
  - **Dependencies:** Closely linked to **#6312** (message limit gating) and potentially analytics counters (#6314)
  - **Estimated Effort:** **4/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Write a UX spec mapping the three states to routes, visible controls, and permissions (as described in the issue).
  2. Implement state detection in a single source of truth (auth + ownership + agent visibility).
  3. Add E2E tests for each state to prevent regressions (unauth visitor, signed-in non-owner, owner).
- **Potential Assignees:** borisudovicic (author/product intent), Shaw (product/platform), a frontend-focused contributor (not identified in provided data)

---

### 6) Rate-limit / soft-gate public agents for unauthenticated users
- **Issue Title & ID:** Limit messages for non-signed up user to ~2–3 — **#6312**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **High** (affects all public agent traffic; also protects resources)
  - **Functional Impact:** **Partial** (prevents abuse; adds conversion gate)
  - **Brand Impact:** **Medium** (must be implemented with good UX to avoid frustration)
- **Technical Classification:**
  - **Issue Category:** UX / Performance / Abuse-prevention
  - **Component Affected:** API + GUI (session tracking, gating overlay), possibly model spend controls
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Rate limiting, anonymous session identity, frontend gating UX, analytics
  - **Dependencies:** Best done together with state separation **#6313** (clean unauth experience)
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Define “anonymous identity” strategy (cookie/session id, IP heuristics, device fingerprinting—privacy aware).
  2. Implement server-side enforcement (not only UI), with clear error codes for the frontend overlay.
  3. Add metrics: message count before signup, conversion rate, abuse signals.
- **Potential Assignees:** Shaw (platform/API), borisudovicic (product), Stan ⚡ (core reliability if it touches runtime)

---

### 7) Chat summaries are low quality / misleading
- **Issue Title & ID:** Chat summaries don’t really make much sense. Can we improve — **#6311**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (affects navigation and trust in summaries)
  - **Functional Impact:** **Partial** (doesn’t block chat, but harms usability)
  - **Brand Impact:** **Medium** (perceived polish/quality)
- **Technical Classification:**
  - **Issue Category:** UX / Bug (prompting/output quality)
  - **Component Affected:** Model Integration + GUI (summary generation + display)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Prompt design, summarization evaluation, UI copy, possibly retrieval of last N messages
  - **Dependencies:** Depends on where summaries are generated (client/server) and which provider/model
  - **Estimated Effort:** **3/5**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Collect failure examples and define target format (as per screenshot expectation).
  2. Implement deterministic summary constraints: title-like output, token limit, include key entities, avoid hallucinated “actions taken”.
  3. Add a fallback heuristic (e.g., first user message trimmed) when LLM summary confidence is low.
- **Potential Assignees:** borisudovicic (reporter), Stan ⚡ (if summary pipeline is core), Jin (content pipeline experience, if relevant)

---

### 8) Public agent cards should show total chat/message count
- **Issue Title & ID:** Public agent cards should have chat number — **#6314**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium** (improves discovery/trust; not essential)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (adds “social proof” polish)
- **Technical Classification:**
  - **Issue Category:** UX / Feature
  - **Component Affected:** GUI + Analytics/DB aggregation
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** DB aggregation, caching, privacy considerations (counting messages across users)
  - **Dependencies:** Needs a reliable definition of “chat number” and performant aggregation strategy
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3** (promote to P2 if public agents are the primary growth channel this sprint)
- **Specific Actionable Next Steps:**
  1. Define metric precisely: messages vs conversations vs unique users; include/exclude owner tests/bots.
  2. Add backend endpoint or materialized aggregate; cache to avoid hot queries.
  3. Update UI cards and add loading/empty states.
- **Potential Assignees:** borisudovicic (requester), Shaw (backend/product), a DB-minded contributor (not identified)

---

### 9) Free credits change ($5 → $1)
- **Issue Title & ID:** Change free credits from $5 to $1 — **#6315**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects new-user experimentation)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (can be perceived as stingy if not framed; but may be required for cost control)
- **Technical Classification:**
  - **Issue Category:** Feature / Product policy
  - **Component Affected:** Cloud billing/credits + onboarding UX + abuse controls
  - **Complexity:** **Simple fix** (if purely configuration), otherwise **Moderate** (if spread across services)
- **Resource Requirements:**
  - **Required Expertise:** Billing/credits system, growth metrics, abuse prevention
  - **Dependencies:** Should be informed by spend/abuse data and gating work (#6312/#6313)
  - **Estimated Effort:** **2/5**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Pull data: average cost per new user, abuse rate, conversion rate at $5.
  2. If changing, coordinate copy updates + FAQ to avoid confusion.
  3. Consider alternative: keep $5 but enforce stricter anonymous message limits and/or phone/email verification thresholds.
- **Potential Assignees:** Shaw (product/platform), Borko (comms), borisudovicic (requester)

---

## Top 5–10 Highest Priority Issues (Do Now)
1. **P0:** AI16Z → ElizaOS migration tokens not showing / transfer failures to Phantom (Discord incident; create tracked issue)
2. **P1:** Add WalletConnect/Tangem pathway or official workaround + docs (migration unblocks)
3. **P1:** `singleShot` parameter support to prevent action problems (core reliability)
4. **P1:** Streaming functionality stabilization and merge (PR #6286 referenced; ensure regressions covered)
5. **P1:** Separate public agent states (**#6313**) (first-time user funnel correctness)
6. **P1:** Limit unauthenticated messages (**#6312**) (cost control + abuse prevention + conversion)
7. **P2:** Improve chat summaries (**#6311**) (quality/polish; reduces confusion)
8. **P3:** Add public agent chat number (**#6314**) (nice-to-have metric/UX)
9. **P3:** Adjust free credits policy (**#6315**) (business decision; align with gating)

---

## Patterns / Themes Suggesting Deeper Architectural Issues
- **Authentication/identity boundaries are leaky in the UI:** #6313/#6312 indicate permissions and onboarding states aren’t first-class concepts, leading to confusing controls and brittle gating.
- **Reliability gaps in “agent action execution” primitives:** The `singleShot` parameter limitation and concurrent work on retry logic/parameter extraction suggest the tool/action contract needs clearer schemas and stronger validation.
- **Operational readiness around critical user flows (migration) is under-instrumented:** Repeated Discord questions with few authoritative answers implies missing telemetry, dashboards, and a single source of truth for support.

---

## Process Improvement Recommendations
1. **Create an “Incident → Issue” protocol:** any repeated Discord report (e.g., migration failures) must become a GitHub issue within 2 hours, with an owner, repro fields, and a public status comment pinned in Discord.
2. **Add funnel instrumentation for high-stakes flows:** migration (connect → sign → transfer → verify), public agent entry (view → message → gated → signup). Use this data to prioritize #6312/#6313 and wallet support.
3. **Define and enforce contracts for core execution APIs:** formalize schemas for actions/tools (`singleShot`, parameter extraction, retries). Require tests for backwards compatibility and add typed validation errors surfaced to users.
4. **UX state modeling standard:** require each new UI surface to declare supported states (unauth/auth/non-owner/owner) and include E2E tests per state before merge.
5. **Centralize user-facing policy changes (credits, limits):** one config source + one doc page + one in-product explanation to prevent mismatch between implementation and community expectations.