## Issue Triage — 2025-12-19

### 1) Snapshot Eligibility + Tangem Wallet Connection Not Supported (Discord Support Compromised)
- **Issue Title & ID:** Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised) — **#6211**
- **Current Status:** **OPEN** (active concern; 1 comment)
- **Impact Assessment:**
  - **User Impact:** **High** (affects a subset of token holders; Tangem is common enough to recur)
  - **Functional Impact:** **No** (doesn’t block elizaOS runtime), but blocks **migration workflow** for affected users
  - **Brand Impact:** **High** (explicit claim of impersonators + unsafe support paths; high reputational risk)
- **Technical Classification:**
  - **Issue Category:** **Security / UX / Documentation** (support-channel integrity + migration UX)
  - **Component Affected:** **Migration tooling + Community Support + WalletConnect integration**
  - **Complexity:** **Moderate effort** (policy + comms + potential portal enhancement)
- **Resource Requirements:**
  - **Required Expertise:** Security incident response/comms; web3 wallet/WC knowledge; portal/backend ops
  - **Dependencies:** Coordination with migration portal maintainers; ability to publish official comms rapidly
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Publish an official security advisory** (GitHub + docs + Discord announcement) defining: official links, “never send tokens” rule, and verified support process.
  2. Add a **“Unsupported wallets (Tangem)”** section to migration docs with safe alternatives (if any) and explicit “no manual transfers” warning.
  3. Evaluate feasibility of **WalletConnect/Tangem support** or a **read-only proof-based claim path** (e.g., signed message / address proof) that doesn’t require Tangem portal connection.
  4. Establish a **single source of truth** page for snapshot rules and exchange handling disclaimers (Kraken/Bithumb differences).
- **Potential Assignees:**
  - **@standujar** (core/server + operational ownership patterns)
  - **@lalalune** (cloud/CLI/product flows; can drive official comms page)
  - **@odilitime** (ecosystem + docs/process coordination)
  - (If available) a designated **community/security moderator lead** for incident playbook execution

---

### 2) Provider pipeline performance and correctness under slow providers (timeout/parallelism)
- **Issue Title & ID:** Optimize provider handling in MultiStep (parallel execution + timeout) — **PR #6263** (triage item; potential duplicate of **PR #6209**)
- **Current Status:** **OPEN PR**; design debate ongoing (timeouts, provider best practices)
- **Impact Assessment:**
  - **User Impact:** **High** (providers are a common extension point; affects many agents indirectly)
  - **Functional Impact:** **Partial** (slow providers can degrade responsiveness; new timeout could also abort pipelines unexpectedly)
  - **Brand Impact:** **Medium/High** (perceived reliability/performance of agents)
- **Technical Classification:**
  - **Issue Category:** **Performance / Bug-risk**
  - **Component Affected:** **Core Framework (default-message-service / MultiStep provider execution)**
  - **Complexity:** **Complex solution** (needs careful semantics + observability + compatibility)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime internals; concurrency; cancellation/timeout semantics; test design
  - **Dependencies:** Decision on provider contract (are network calls allowed?); confirm duplication with #6209
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. **Confirm whether #6263 duplicates #6209**; if overlapping, consolidate to one approach and close/supersede the other.
  2. Define and document a **provider contract**: allowed I/O, caching expectations, and SLA guidance.
  3. Add **instrumentation**: per-provider timing, warnings for slow providers, and a structured event for timeouts.
  4. Ensure timeout behavior is **configurable** and defaults are safe (avoid surprising aborts in common deployments).
  5. Add **regression tests**: slow provider, hanging provider, partial provider failures, ordering determinism.
- **Potential Assignees:**
  - **@standujar** (author)
  - **@odilitime** (provider architecture stance + review)
  - **@wtfsayo** (runtime execution patterns; previously working on parallelism)

---

### 3) Streaming UI regression: Actions UI renders streamed text all at once
- **Issue Title & ID:** Streaming works for simple messages/actions but **Actions UI still displays text all at once** — **(Untracked; needs GitHub issue)**
- **Current Status:** Reported in Discord; core streaming PR **#6212 merged**; UI behavior still incorrect
- **Impact Assessment:**
  - **User Impact:** **High** (streaming is a key UX expectation; affects most interactive users)
  - **Functional Impact:** **Partial** (responses still work, but degraded UX and perceived latency)
  - **Brand Impact:** **High** (feels “broken”/unfinished even when backend streams correctly)
- **Technical Classification:**
  - **Issue Category:** **Bug / UX**
  - **Component Affected:** **Client UI (Actions rendering) + streaming event wiring**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Client React rendering; socket/message stream events; state management
  - **Dependencies:** Clarify event model for action streams vs message streams; reproduce in monorepo
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub issue with a **minimal repro** (agent action producing long output; expected incremental tokens).
  2. Verify whether Actions UI uses the same streaming pathway as normal chat (`use-socket-chat`, message stream events).
  3. Implement incremental rendering for action output (buffer tokens/chunks, flush by animation frame or chunk interval).
  4. Add a UI test or integration test asserting chunked updates.
- **Potential Assignees:**
  - **@standujar** (streaming architecture context)
  - **@wtfsayo** (client UX fixes history)
  - **@ChristopherTrimboli** (CLI/client integration experience)

---

### 4) Bootstrap action/provide format change causes initialization issues (initPromise fix)
- **Issue Title & ID:** bootstrap action/provide format change fix + initPromise fix — **PR #6261**
- **Current Status:** **OPEN PR**; needs compatibility verification with latest `develop`
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (affects new projects / core bootstrap flows)
  - **Functional Impact:** **Yes/Partial** (agent initialization and action wiring can fail)
  - **Brand Impact:** **Medium** (setup reliability is a strong first impression)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Core Framework / plugin-bootstrap**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Core runtime initialization; action registration; bootstrap plugin behavior
  - **Dependencies:** Must align with any recent action/provide API changes; coordinate with streaming changes
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Rebase and run full CI on `develop`.
  2. Add a focused test: “fresh agent bootstraps + registers providers/actions + initialize() resolves deterministically”.
  3. Confirm no breaking behavior for existing plugin action definitions.
- **Potential Assignees:**
  - **@odilitime** (author)
  - **@standujar** (core review)
  - **@lalalune** (end-to-end flow validation)

---

### 5) Local PostgreSQL migration/setup failures block contributors
- **Issue Title & ID:** Persistent DB migration issues when setting up elizaOS with local PostgreSQL — **(Untracked; needs GitHub issue)**
- **Current Status:** Reported in Discord; troubleshooting in DMs; unclear reproducibility
- **Impact Assessment:**
  - **User Impact:** **Medium** (primarily developers/contributors, but impacts adoption)
  - **Functional Impact:** **Yes (for local dev)** (can block running the stack)
  - **Brand Impact:** **Medium/High** (“can’t get it running” is costly)
- **Technical Classification:**
  - **Issue Category:** **Bug / Documentation**
  - **Component Affected:** **plugin-sql + migrations + local dev tooling**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Postgres permissions, drizzle/migrations, plugin-sql internals
  - **Dependencies:** Need logs + exact versions + migration state; may depend on recent migration work (#6215)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Open a GitHub issue with sanitized logs, Postgres version, and steps.
  2. Provide a **known-good docker-compose** for Postgres + required roles/permissions.
  3. Add a “first-run doctor” script (or CLI check) that validates DB connectivity and permissions before migrations.
- **Potential Assignees:**
  - **@standujar** (SQL/migrations depth)
  - **@lalalune** (developer experience, scripts)
  - **@odilitime** (triage + reproduction)

---

### 6) runtime.db reassignment removed (multi-connection safety / correctness)
- **Issue Title & ID:** remove reassign runtime.db to individual connection — **PR #6262**
- **Current Status:** **OPEN PR**
- **Impact Assessment:**
  - **User Impact:** **Medium** (depends on how often multiple connections/agents are used)
  - **Functional Impact:** **Partial** (could fix subtle DB state bugs; risk of regressions if wrong)
  - **Brand Impact:** **Medium** (data correctness issues are trust-eroding)
- **Technical Classification:**
  - **Issue Category:** **Bug / Architectural hygiene**
  - **Component Affected:** **Core Framework + DB integration**
  - **Complexity:** **Complex solution** (shared mutable state risks)
- **Resource Requirements:**
  - **Required Expertise:** Core runtime lifecycle; DB adapter patterns; concurrency
  - **Dependencies:** Ensure compatibility with plugin-sql behavior and new data isolation/JWT work
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Require a clear write-up in the PR: what bug this fixes + reproduction scenario.
  2. Add tests for multiple agent runtimes using DB concurrently (no cross-contamination).
  3. Validate with `ENABLE_DATA_ISOLATION` modes (if relevant).
- **Potential Assignees:**
  - **@nguyennk92** (author)
  - **@standujar** (core/server reviewer)
  - **@0xbbjoker** (review capacity + bugfix focus)

---

### 7) Starknet plugin integration blocked by AgentRuntime vs IAgentRuntime type incompatibilities
- **Issue Title & ID:** Type conversion issues across action files (`AgentRuntime` vs `IAgentRuntime`) — **(Untracked; plugin issue recommended)**
- **Current Status:** Reported in Discord by plugin integrator; workaround “update action files”
- **Impact Assessment:**
  - **User Impact:** **Medium** (plugin developers; impacts ecosystem growth)
  - **Functional Impact:** **Partial** (blocks compiling/building the plugin)
  - **Brand Impact:** **Medium** (signals unstable plugin API/types)
- **Technical Classification:**
  - **Issue Category:** **Bug / Developer Experience**
  - **Component Affected:** **Plugin System + Type definitions**
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** TypeScript public API design; plugin action interfaces; versioning strategy
  - **Dependencies:** Confirm pinned versions policy; identify breaking type changes since last plugin update
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Open an issue in the Starknet plugin repo (or elizaOS repo if types are wrong) with exact TS errors.
  2. Provide a codemod or upgrade guide: “actions signature changes since version X”.
  3. Consider exporting a single canonical runtime type for plugins to import.
- **Potential Assignees:**
  - **@odilitime** (plugin development guidance)
  - **@standujar** (core types/exports)
  - **FenrirFawks** (reporter; can validate fixes)

---

### 8) Starknet action fails: missing handler for delegate type in DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN
- **Issue Title & ID:** Missing handler error for delegate type in `DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN` — **(Untracked; plugin issue recommended)**
- **Current Status:** Reported in Discord; unanswered
- **Impact Assessment:**
  - **User Impact:** **Low/Medium** (specific action; niche user set)
  - **Functional Impact:** **Yes (for that action)** (action execution fails)
  - **Brand Impact:** **Low/Medium** (plugin quality perception)
- **Technical Classification:**
  - **Issue Category:** **Bug**
  - **Component Affected:** **Plugin System (Starknet plugin action handlers)**
  - **Complexity:** **Simple fix → Moderate** (depending on handler architecture)
- **Resource Requirements:**
  - **Required Expertise:** Starknet plugin internals; action registration/dispatch
  - **Dependencies:** Requires reproduction + stack trace + config
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Capture the full error + stack trace and minimal config.
  2. Verify the action is exported/registered in `src/index`.
  3. Add unit test for handler registration and delegate-type dispatch.
- **Potential Assignees:**
  - FenrirFawks (implement + test)
  - **@odilitime** (review/architecture)
  - A Starknet plugin maintainer (if assigned)

---

### 9) Documentation backlog item with unclear scope
- **Issue Title & ID:** Docs — **#6264**
- **Current Status:** **OPEN**; no comments
- **Impact Assessment:**
  - **User Impact:** **Low/Unknown** (scope not specified)
  - **Functional Impact:** **No**
  - **Brand Impact:** **Medium** (documentation perception matters, but needs concrete scope)
- **Technical Classification:**
  - **Issue Category:** **Documentation**
  - **Component Affected:** **Docs site / developer docs**
  - **Complexity:** **Unknown → likely Simple/Moderate**
- **Resource Requirements:**
  - **Required Expertise:** Technical writing; familiarity with current docs IA
  - **Dependencies:** Needs clarification and breakdown
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Request the reporter to specify: which docs, what’s wrong, expected outcome.
  2. Convert into a checklist of discrete doc tasks and link related issues/PRs.
- **Potential Assignees:**
  - **@borisudovicic** (author; can scope)
  - **@odilitime** (docs cleanup/sync mentioned)
  - **@lalalune** (product docs for onboarding flows)

---

### 10) Plugin-Discord large PR waiting (staleness + integration risk)
- **Issue Title & ID:** plugin-discord PR “66 commits ready to merge” — **elizaos-plugins/plugin-discord PR #30** (referenced in Discord)
- **Current Status:** **OPEN** ~3 weeks; large diff; merge pending review
- **Impact Assessment:**
  - **User Impact:** **Medium/High** (Discord is a primary integration channel)
  - **Functional Impact:** **Partial** (delays improvements/fixes; risk of divergence)
  - **Brand Impact:** **Medium** (ecosystem stability)
- **Technical Classification:**
  - **Issue Category:** **Bug/Feature delivery risk**
  - **Component Affected:** **Plugin System / Discord integration**
  - **Complexity:** **Complex solution** (large PR; review/merge strategy)
- **Resource Requirements:**
  - **Required Expertise:** Discord API, plugin framework, migration to messageService patterns
  - **Dependencies:** Might depend on recent messaging/streaming refactors
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Do a **risk-based review**: identify breaking changes, migration notes, and key files.
  2. If too large, **split into smaller PRs** (refactor vs behavior changes vs fixes).
  3. Run integration tests against latest monorepo messaging APIs.
- **Potential Assignees:**
  - **@odilitime** (pushing for merge; knows context)
  - **@standujar** (messaging refactors context)
  - **@0xbbjoker** (review support)

---

## Top priority summary (fix immediately / this sprint)

1. **P0 — #6211 Tangem + migration support compromised by impersonators:** publish official security guidance + safe migration pathways.
2. **P1 — PR #6263 provider timeout/parallelism:** finalize provider contract + consolidate with #6209 + add instrumentation/tests.
3. **P1 — Streaming Actions UI not actually streaming (untracked):** fix client incremental rendering for actions.
4. **P1 — PR #6261 bootstrap initPromise / action-provide format compatibility:** prevent initialization regressions; add tests and merge.
5. **P2 — Local Postgres migration/setup failures (untracked):** reproduce, document, and harden first-run experience.
6. **P2 — PR #6262 runtime.db reassignment removal:** validate with concurrency tests; ensure no cross-runtime contamination.
7. **P2 — Plugin-Discord PR #30 large/stale:** de-risk by splitting or focused review and merge plan.
8. **P2 — Plugin TS type incompatibilities (AgentRuntime vs IAgentRuntime):** stabilize plugin-facing types and provide upgrade guidance.

---

## Patterns / themes indicating deeper issues

- **Unclear contracts at extension boundaries (Providers, Actions, Runtime types):** recurring friction around what providers may do (I/O vs cache) and type/API drift (`AgentRuntime` vs `IAgentRuntime`).
- **Streaming is “feature-complete” in backend but inconsistent in UI surfaces:** indicates event model fragmentation (messages vs actions) and missing UI-level acceptance tests.
- **Operational/security risk in community support flows:** migration-related confusion plus impersonation reports suggests the project needs hardened “official support + official links” infrastructure.
- **Large, long-lived PRs in plugins:** indicates review bandwidth constraints and risk of ecosystem divergence from core changes.

---

## Process improvement recommendations

1. **Define and version “Plugin API contracts”** (providers/actions/runtime types) with a short compatibility policy and migration notes per release.
2. **Add acceptance tests for streaming UX** (at least one for message streaming, one for action streaming) to prevent regressions.
3. **Introduce a “Support Security” playbook**:
   - single canonical links page,
   - verification guidance,
   - pinned Discord messages,
   - GitHub issue template for migration/security reports.
4. **Enforce PR size/age guardrails** (especially in plugins):
   - encourage splitting into reviewable chunks,
   - require a test plan section,
   - set an internal SLA for review or rebase.
5. **Improve onboarding diagnostics**:
   - CLI “doctor” checks for DB/migrations,
   - publish known-good docker compose files,
   - document common permission pitfalls and recovery steps.