# Issue Triage — 2025-12-20 (elizaOS)

## 1) Release blocked by NPM token change (classic token deleted) — ID: (Ops) NPM_TOKEN_ROTATION_2025-12
- **Current Status:** Open (blocking release); discussed in `core-devs` (cjft)
- **Impact Assessment:**
  - **User Impact:** High (prevents shipping fixes/features)
  - **Functional Impact:** **Yes** (release pipeline cannot publish)
  - **Brand Impact:** High (missed release dates / stalled delivery perception)
- **Technical Classification:**
  - **Category:** Security / DevOps
  - **Component:** Release pipeline / CI/CD, npm publishing
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, npm org/token management, GitHub Actions secrets
  - **Dependencies:** None, but blocks all dependent release tasks (streaming launch, plugin version alignment)
  - **Estimated Effort:** 1 (≤ 1 hour once access is available)
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create new npm Automation/Granular token with least privilege needed for publish.
  2. Update GitHub Actions secret(s) (e.g., `NPM_TOKEN`) and verify workflow uses correct secret name.
  3. Dry-run publish (or publish to `next` tag) to validate permissions.
  4. Document token rotation procedure in RELEASE.md (include cadence + owner).
- **Potential Assignees:** **cjft** (reported), **Stan ⚡** (release coordination), **ChristopherTrimboli** (CI familiarity)

---

## 2) Cloud streaming release train sequencing + integration — ID: (Release) CLOUD_STREAMING_MONOREPO→PLUGIN→CLOUDV2
- **Current Status:** In progress; Monday release targeted; explicit sequence agreed in `core-devs`
- **Impact Assessment:**
  - **User Impact:** High (cloud users awaiting streaming UX; reduces “laggy” feel)
  - **Functional Impact:** **Partial** (core works, but streaming is a key UX capability)
  - **Brand Impact:** High (high-visibility feature; community sentiment already strained)
- **Technical Classification:**
  - **Category:** Feature / Release engineering
  - **Component:** Core Framework + Cloud (monorepo), `elizacloud-plugin`, `eliza-cloud-v2`
  - **Complexity:** Moderate effort (multi-repo coordination + versioning)
- **Resource Requirements:**
  - **Required Expertise:** Monorepo release process, semantic versioning, cloud deployment, plugin compatibility
  - **Dependencies:**
    - Requires **Issue #1** resolved (npm publish)
    - Requires correct core versioning in elizacloud-plugin (see next item)
  - **Estimated Effort:** 3
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Cut monorepo release containing streaming-ready core changes (confirm included PRs, especially streaming support work already merged earlier in month).
  2. Validate streaming on minimal scenario: simple message + action streaming (as reported working).
  3. Merge elizacloud-plugin PR(s) after rebasing onto released core version.
  4. Bump `cloud-v2` to latest core + plugin versions; run smoke tests (auth, chat creation, actions, disconnect/reconnect).
  5. Add release checklist item: “streaming event contract version pinned and validated.”
- **Potential Assignees:** **Stan ⚡** (driver), **Borko** (release stakeholder), **lalalune** (cloud integration context), **standujar** (messaging/auth touchpoints)

---

## 3) elizacloud-plugin pinned to old alpha core version (needs stable pin) — ID: (Repo) elizaos-plugins/elizacloud-plugin VERSION_PIN
- **Current Status:** Open; flagged in `core-devs`
- **Impact Assessment:**
  - **User Impact:** High (incompatibility, runtime errors, broken streaming)
  - **Functional Impact:** **Yes** (breaks cloud deployment path / plugin runtime)
  - **Brand Impact:** High (perceived fragility in official cloud stack)
- **Technical Classification:**
  - **Category:** Bug / Dependency management
  - **Component:** Plugin System, Cloud plugin
  - **Complexity:** Simple fix
- **Resource Requirements:**
  - **Required Expertise:** Node dependency/version pinning, release practices for plugins
  - **Dependencies:** Depends on monorepo release artifact/version (Issue #2)
  - **Estimated Effort:** 2
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Replace any `alpha`/outdated `@elizaos/*` references with the newly released stable version(s).
  2. Ensure plugin uses **explicit version pinning** (confirmed best practice in Discord).
  3. Add CI matrix test: plugin against latest stable core.
  4. Publish patched plugin version and update cloud-v2 lockfiles accordingly.
- **Potential Assignees:** **Stan ⚡**, **ChristopherTrimboli**, **lalalune**

---

## 4) Token migration: snapshot eligibility + Tangem wallet unsupported + impersonation risk — Issue #6211
- **Issue Title & ID:** “Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised)” — **#6211**
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** Critical (users may be unable to migrate; risk of being scammed)
  - **Functional Impact:** **Partial** (core framework unaffected; ecosystem-critical workflow impacted)
  - **Brand Impact:** **High** (security perception, trust, legitimacy; Discord impersonators explicitly reported)
- **Technical Classification:**
  - **Category:** Security / UX / Documentation (multi-faceted)
  - **Component:** Migration portal + wallet connectivity + support process
  - **Complexity:** Complex solution (policy + tooling + possible backend exception handling)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration (WalletConnect), backend eligibility logic, security operations, community support
  - **Dependencies:** Potential dependence on migration portal architecture and snapshot source of truth; coordination with comms/mods
  - **Estimated Effort:** 4
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Security response:** Publish an official pinned advisory: “We will never ask you to send tokens manually” + verified links only.
  2. Provide an **official GitHub-based support path** for edge wallets (like Tangem) with verifiable identity checks.
  3. Determine eligibility for Tangem-held tokens at snapshot (confirm snapshot address derivation and whether Tangem addresses are included).
  4. If eligible but unconnectable: implement one of:
     - Manual claim process via signed message from snapshot address (preferred), or
     - Backend allowlist mapping with strong verification, or
     - Add Tangem-compatible WalletConnect flow (if feasible quickly).
  5. Add migration FAQ section: “0 eligible” causes, exchange snapshot constraints, hardware wallet edge cases, and deadline (Feb 4, 2026).
- **Potential Assignees:** **jin / madjin** (comms + repo updates), **Omid Sa** (migration support workflow), **Kenk** (tokenomics/deadline clarity), **Stan ⚡** (engineering coordination)

---

## 5) EVM support uncertainty / plugin-evm perceived unmaintained — ID: (Ecosystem) plugin-evm STATUS_REVIEW
- **Current Status:** Open concern raised in `💬-coders`; Odilitime referenced active PR work “EVM support for Spartan”
- **Impact Assessment:**
  - **User Impact:** Medium–High (blocks onchain agent builders evaluating elizaOS)
  - **Functional Impact:** **Partial** (not core for all users; core for web3 segment)
  - **Brand Impact:** Medium (signals ecosystem instability / unclear “official” path)
- **Technical Classification:**
  - **Category:** Documentation / Feature reliability
  - **Component:** Plugin System, Model/Tool integration for EVM actions
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** EVM transaction tooling, plugin architecture, testing on testnets
  - **Dependencies:** Clarify which repo/plugin is “blessed” and ensure version compatibility with latest core
  - **Estimated Effort:** 3
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a short “Onchain capabilities” matrix: recommended plugin(s), maintenance status, supported networks/features.
  2. Review/merge the active EVM PR(s) and cut a tagged release of the EVM plugin.
  3. Add minimal CI: lint + unit tests + a mocked tx-signing flow; optionally a testnet smoke script.
- **Potential Assignees:** **Odilitime** (active), **Stan ⚡** (review), **0xbbjoker** (review/testing discipline)

---

## 6) Provider pipeline performance change proposal (parallel execution + timeout) — ID: PR #6263 (referenced)
- **Current Status:** Proposed in Discord; needs code review; possible duplication with PR #6209 noted
- **Impact Assessment:**
  - **User Impact:** Medium (latency improvements)
  - **Functional Impact:** **Partial** (performance + reliability; may break providers if semantics change)
  - **Brand Impact:** Medium (responsiveness improves perceived quality; regressions would hurt)
- **Technical Classification:**
  - **Category:** Performance / Architectural
  - **Component:** Core Framework (provider execution pipeline)
  - **Complexity:** Architectural change (or at least careful concurrency design)
- **Resource Requirements:**
  - **Required Expertise:** Concurrency, cancellation/timeouts, provider contract semantics, observability
  - **Dependencies:** Must reconcile with/avoid duplicating PR #6209; align with “provider best practices” docs
  - **Estimated Effort:** 4
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Determine overlap with PR #6209; consolidate into one approach.
  2. Define provider contract: allowed side effects, caching expectations, timeout behavior (warn vs abort).
  3. Implement structured telemetry: per-provider timing, timeout counters, warning logs (“Provider X took 2500ms…”).
  4. Add regression tests: slow provider, hanging provider, provider error propagation.
- **Potential Assignees:** **Stan ⚡** (proposed), **wtfsayo** (parallel execution history), **standujar** (server/messaging implications)

---

## 7) Discord plugin PR is oversized and stale (66 commits, 3+ weeks) — ID: elizaos-plugins/plugin-discord PR #30
- **Current Status:** Open; “ready to merge” but risky due to size/age per Discord
- **Impact Assessment:**
  - **User Impact:** Medium (Discord is a major deployment target for agents)
  - **Functional Impact:** **Partial** (plugin ecosystem quality; not core runtime)
  - **Brand Impact:** Medium (breakages in flagship integrations are visible)
- **Technical Classification:**
  - **Category:** Bug / Maintenance
  - **Component:** Plugin System (Discord plugin)
  - **Complexity:** Moderate effort (review + possible split/rebase)
- **Resource Requirements:**
  - **Required Expertise:** Discord API, plugin architecture, code review/rebase skill
  - **Dependencies:** May depend on messaging API changes in core; check compatibility with latest develop
  - **Estimated Effort:** 3
- **Recommended Priority:** **P2** (promote to P1 if Discord plugin is blocking a partner deployment)
- **Specific Actionable Next Steps:**
  1. Require author to rebase onto latest core/plugin interfaces and run a minimal integration test.
  2. If too large, split into: (a) refactor/cleanup, (b) functional changes, (c) bugfixes.
  3. Add a CI smoke test that boots a bot with mocked Discord events.
- **Potential Assignees:** **Odilitime** (raised), **standujar** (plugin refactor experience), **0xbbjoker** (review)

---

## 8) Starknet plugin integration: TypeScript runtime type mismatch + missing handler for deploy action — ID: (Ecosystem) STARKNET_PLUGIN_TYPES/HANDLER
- **Current Status:** In progress (FenrirFawks); blocked by `AgentRuntime` vs `IAgentRuntime` type compatibility + missing handler for `DEPLOY_STARKNET_UNRUGGABLE_MEME_TOKEN` delegate type
- **Impact Assessment:**
  - **User Impact:** Low–Medium (niche but important web3 segment)
  - **Functional Impact:** **Partial** (plugin development blocked)
  - **Brand Impact:** Medium (plugin dev friction signals instability)
- **Technical Classification:**
  - **Category:** Bug / Developer Experience
  - **Component:** Plugin System + TypeScript types + Actions registry
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript typing, core runtime interfaces, action registration patterns
  - **Dependencies:** Needs stable runtime interface exports and up-to-date action examples/docs
  - **Estimated Effort:** 3
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Provide canonical plugin TS template pinned to current core types (no `as any`).
  2. Add compile-time test for plugin action signature compatibility.
  3. Fix missing handler registration path (ensure action is exported/registered in `src/index`).
- **Potential Assignees:** **FenrirFawks** (owner), **Odilitime** (guidance), **Stan ⚡** (core typing decisions)

---

# Immediate Focus Summary (Top 5–10)

1. **P0 — NPM token rotation blocking publishes** (Ops) NPM_TOKEN_ROTATION_2025-12  
2. **P0 — Cloud streaming release train coordination** (Release) CLOUD_STREAMING_MONOREPO→PLUGIN→CLOUDV2  
3. **P0 — elizacloud-plugin core version pinned to old alpha** (Repo) elizacloud-plugin VERSION_PIN  
4. **P0 — Token migration Tangem + impersonation/security risk** Issue **#6211**  
5. **P1 — Provider parallelization/timeout proposal review + consolidation** PR **#6263** (and potential dup with **#6209**)  
6. **P1 — EVM support clarity + ship a maintained EVM path** plugin-evm STATUS_REVIEW  
7. **P2 — Discord plugin PR too large/stale; de-risk merge** plugin-discord PR **#30**  
8. **P2 — Starknet plugin TS/action handler dev-blockers** STARKNET_PLUGIN_TYPES/HANDLER  

---

# Cross-Issue Patterns / Themes

- **Release engineering as a recurrent single point of failure:** npm credentials + multi-repo sequencing shows insufficient automation and ownership clarity.
- **Versioning/compatibility friction across plugins:** repeated reminders to pin `@elizaos/*` versions, plus cloud plugin pinned to alpha, plus TS interface mismatches.
- **High-visibility ecosystem trust issues:** token migration confusion, exchange discrepancies, and impersonator-driven support risk directly affect perceived legitimacy.
- **Large, long-lived PRs in plugins:** risk accumulation (merge conflicts, outdated assumptions, harder review) is becoming a systemic drag.

---

# Process Improvement Recommendations

1. **Harden releases**
   - Introduce a formal release checklist (tokens/credentials, tag order, smoke tests, rollback plan).
   - Add a “release captain” rotation (single accountable owner per release).
2. **Plugin compatibility gates**
   - Require plugin CI to test against latest stable `@elizaos/core` (and optionally next/pre-release).
   - Enforce explicit version pinning via lint rule or template generator defaults.
3. **Security & support integrity**
   - Publish and continuously update a “Verified Links + Support Policy” page; pin in Discord and reference in migration portal UI.
   - Provide a GitHub-first escalation path for sensitive wallet/migration cases.
4. **PR size/age controls**
   - Add contribution guidance: PR size limits, mandatory splitting, and “stale PR” rebase policy after N days.
   - Encourage RFC issues for architectural changes (e.g., provider concurrency) before major implementation.