## Issue Triage — 2025-12-21

### 1) Snapshot Eligibility Issue + Tangem Wallet Connection Not Supported (Discord Support Compromised) — #6211
- **Current Status:** OPEN (1 comment)
- **Impact Assessment:**
  - **User Impact:** High (affects Tangem users + anyone unsure about snapshot wallets; repeated questions on Discord)
  - **Functional Impact:** Partial (blocks token migration for a subset of eligible holders)
  - **Brand Impact:** High (users report Discord impersonation, “compromised support”; erosion of trust)
- **Technical Classification:**
  - **Issue Category:** Security + UX + Documentation
  - **Component Affected:** Migration Portal (external), Support/Comms, WalletConnect integration assumptions
  - **Complexity:** Architectural change (if adding wallet support) / Moderate effort (if providing safe manual flow)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet integration (WalletConnect), backend ops for allowlists, security/comms
  - **Dependencies:** Snapshot dataset + migration backend tooling; decision on “manual migration” policy
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Publish an **official, signed migration support policy** on GitHub (README + pinned issue) explicitly stating: “no DMs, no manual transfers, only official portal links.”
  2. Add a **“Non-connectable wallet” safe path** (Tangem-like): documented verification steps + secure manual allowlist update or alternate signing flow.
  3. Confirm eligibility rule: snapshot wallet must be connectable vs. “ownership provable” (and document it).
  4. Add portal UX copy: “If your snapshot wallet cannot connect, do X” with clear SLA expectations.
  5. Close the loop on #6211 with a concrete resolution path and timeline.
- **Potential Assignees:**
  - **Alexei** (contracts/addresses, user-facing canonical info)
  - **Jin / madjin** (security/comms + publishing official info)
  - **Stan ⚡ / standujar** (platform/backend coordination, policy-to-implementation)
  - **Kenk** (migration deadline + policy clarification)

---

### 2) Discord Scam/Impersonation Pressure During Migration (Suspicious Links, Ticket Impersonators) — (No GitHub issue; Discord incident)
- **Current Status:** Ongoing (moderators actively preventing clicks; multiple warnings on 2025-12-20)
- **Impact Assessment:**
  - **User Impact:** Critical (broad community exposure; high likelihood of loss if a user is tricked)
  - **Functional Impact:** No (doesn’t break code, but breaks safe access to support)
  - **Brand Impact:** High (community stating Discord support is “compromised”)
- **Technical Classification:**
  - **Issue Category:** Security
  - **Component Affected:** Community ops, support workflow, Discord permissions/bots
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Security ops, Discord admin/mod tooling, incident response
  - **Dependencies:** Discord server configuration; migration communications
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a **GitHub Security Advisory-style** canonical page: official links, contracts, portal URL, “never send tokens” guidance.
  2. Enforce Discord hardening: restrict link posting in support channels, lock down ticket bot permissions, verified-role-only ticket creation.
  3. Add an **auto-moderation rule set**: block common phishing domains, block lookalike portal URLs, quarantine first-time posters.
  4. Publish a weekly “security bulletin” in Discord + website/docs.
- **Potential Assignees:**
  - **Hexx** (mod execution; already preventing clicks)
  - **Jin / madjin** (security comms + canonical publishing)
  - **Stan ⚡** (coordination with release/migration messaging)

---

### 3) Cloud MVP “Monday” Release Train Risk: Monorepo → elizacloud-plugin → cloud-v2 Version Alignment — (Release task; no GitHub issue)
- **Current Status:** In progress (explicit dependency order stated on 2025-12-19)
- **Impact Assessment:**
  - **User Impact:** High (Cloud MVP is a public-facing delivery milestone)
  - **Functional Impact:** Yes (blocks Cloud streaming rollout; release cannot proceed cleanly)
  - **Brand Impact:** High (missed ship date compounds token/roadmap skepticism)
- **Technical Classification:**
  - **Issue Category:** Release Engineering / Reliability
  - **Component Affected:** Core Framework (monorepo), Plugin System (elizacloud-plugin), Cloud product (cloud-v2)
  - **Complexity:** Complex solution (multi-repo coordination, version pinning, regression risk)
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, npm publishing, dependency/version management
  - **Dependencies:** Monorepo release completion; elizacloud-plugin review/merge; cloud-v2 bump
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a single tracking issue (“Cloud MVP ship checklist”) with owners per step.
  2. Freeze versions: ensure plugins **pin exact `@elizaos/*` versions** (reinforced on 2025-12-18).
  3. Gate release on a minimal e2e: cloud streaming + chat creation + no-summary conversation path.
  4. Publish release notes with known limitations + rollback plan.
- **Potential Assignees:**
  - **Borko** (ship owner)
  - **Stan ⚡** (dependency ordering + technical lead)
  - **cjft** (release execution; v1.7.0 shipping context)
  - **ChristopherTrimboli** (CLI/Cloud integration touchpoints)

---

### 4) NPM Publishing/Token Rotation Breakage (Classic Tokens Deleted) — (Release task; no GitHub issue)
- **Current Status:** Active concern (noted 2025-12-19; “classic token deleted”)
- **Impact Assessment:**
  - **User Impact:** Medium–High (delays releases; affects downstream installs)
  - **Functional Impact:** Yes (blocks publishing pipeline)
  - **Brand Impact:** Medium (visible release instability)
- **Technical Classification:**
  - **Issue Category:** Infrastructure / Reliability
  - **Component Affected:** CI/CD, npm publish pipeline
  - **Complexity:** Simple fix → Moderate effort (depending on CI secret propagation)
- **Resource Requirements:**
  - **Required Expertise:** CI admin, npm org admin, GitHub Actions secrets
  - **Dependencies:** Access to npm org; CI workflows
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Rotate to **automation tokens** (scoped) and update GitHub Actions secrets.
  2. Add a CI preflight that fails fast with a clear “npm auth invalid/expired” message.
  3. Document release operator runbook (token rotation steps + owners).
- **Potential Assignees:**
  - **cjft** (release tooling context)
  - **ChristopherTrimboli** (CI + CLI workflow familiarity)
  - **Stan ⚡** (release governance)

---

### 5) Provider Pipeline Performance: Parallel Execution + Configurable Timeout (Default 1s) — PR #6263
- **Current Status:** OPEN (proposal discussed 2025-12-18; concern about provider best practices/duplication with #6209)
- **Impact Assessment:**
  - **User Impact:** High (provider latency affects every message; timeouts can cause failures)
  - **Functional Impact:** Partial (can abort pipeline if misconfigured; can improve responsiveness)
  - **Brand Impact:** Medium (perceived speed/reliability)
- **Technical Classification:**
  - **Issue Category:** Performance / Reliability
  - **Component Affected:** Core Framework (provider execution pipeline)
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** Core runtime, async orchestration, observability/logging
  - **Dependencies:** Confirm relationship/overlap with PR #6209; provider guidelines
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Reconcile scope vs **PR #6209** (duplicate or complementary) and choose one implementation path.
  2. Add structured metrics: per-provider duration histogram + warnings (“Provider X took 2500ms…”).
  3. Document provider rules: avoid live API calls, cache, deterministic + fast.
  4. Add integration tests for timeout behavior to prevent silent regressions.
- **Potential Assignees:**
  - **standujar** (author; core expertise)
  - **wtfsayo** (parallel action execution context; #6209 mentioned)
  - **Stan ⚡** (review + design constraints)
  - **odilitime** (provider best-practice documentation)

---

### 6) Eliza Cloud Integration “Tight” CLI/Create→Deploy→Publish Flow — PR #6216
- **Current Status:** OPEN (large PR; “may still need some work”)
- **Impact Assessment:**
  - **User Impact:** High (affects onboarding and default path if Cloud is emphasized)
  - **Functional Impact:** Partial (risk of broken flow; provisioning/login complexity)
  - **Brand Impact:** High (first-run experience; “it just works” expectation)
- **Technical Classification:**
  - **Issue Category:** Feature + UX + Reliability
  - **Component Affected:** CLI, Cloud plugin, starter projects, deployment/publish tooling
  - **Complexity:** Complex solution (large surface area; regression risk)
- **Resource Requirements:**
  - **Required Expertise:** CLI, Cloud API, auth/provisioning, packaging/release
  - **Dependencies:** Cloud MVP release train; npm publishing stability
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Break into reviewable chunks (auth/login, provisioning, deploy, publish/monetize).
  2. Add a “golden path” e2e test: new user → login → create → deploy → chat.
  3. Validate rollback path for users who want local-only (no Cloud dependency).
- **Potential Assignees:**
  - **lalalune** (author)
  - **ChristopherTrimboli** (CLI + Cloud default provider work)
  - **Stan ⚡** (architecture review)
  - **standujar** (server/auth implications)

---

### 7) JWT Authentication + Data Isolation / Multi-Entity Support — PR #6200
- **Current Status:** OPEN (feature complete with tests; docs needed)
- **Impact Assessment:**
  - **User Impact:** Medium–High (critical for hosted/multi-tenant, less for single-user local)
  - **Functional Impact:** Partial (enables secure multi-tenant mode; can block certain Cloud paths if required)
  - **Brand Impact:** Medium (security posture)
- **Technical Classification:**
  - **Issue Category:** Security / Feature
  - **Component Affected:** Server API, Socket.IO auth, middleware, entity isolation
  - **Complexity:** Complex solution
- **Resource Requirements:**
  - **Required Expertise:** Auth/JWT/JWKS, server middleware, threat modeling
  - **Dependencies:** Decide default auth mode for Cloud MVP; documentation updates
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P2** (escalate to P1 only if Cloud MVP requires multi-tenant isolation immediately)
- **Specific Actionable Next Steps:**
  1. Perform security review: issuer whitelist behavior, verifier priority, service-bypass secret.
  2. Add docs + deployment examples (Auth0/Clerk/Privy/Supabase/Google).
  3. Define migration path from `X-Entity-Id` legacy mode to JWT mode.
- **Potential Assignees:**
  - **standujar** (author)
  - **Stan ⚡** (security + architecture review)
  - **ChristopherTrimboli** (developer experience + docs alignment)

---

### 8) Starknet Plugin Integration Blockers: TypeScript `AgentRuntime` vs `IAgentRuntime` + Missing Delegate Handler — (No GitHub issue/PR in provided data)
- **Current Status:** In progress (reported 2025-12-18)
- **Impact Assessment:**
  - **User Impact:** Low–Medium (impacts Starknet plugin adopters)
  - **Functional Impact:** Partial (blocks specific Starknet actions; prevents plugin completion)
  - **Brand Impact:** Low–Medium (plugin ecosystem quality)
- **Technical Classification:**
  - **Issue Category:** Bug / Developer Experience
  - **Component Affected:** Plugin System, Core types, Action handlers
  - **Complexity:** Moderate effort
- **Resource Requirements:**
  - **Required Expertise:** TypeScript types, plugin action architecture, Starknet domain knowledge
  - **Dependencies:** Clarify canonical runtime interface; ensure version pinning
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Add a minimal reproduction + open a GitHub issue in the relevant repo (core or plugin).
  2. Publish a “Plugin TS compatibility” guide (how to target `IAgentRuntime` reliably).
  3. Implement/fix the missing action handler for the delegate deploy flow.
- **Potential Assignees:**
  - **FenrirFawks** (reporter/implementer)
  - **odilitime** (TS migration advice; plugin support)
  - **Stan ⚡** (core types guidance)

---

## Top Highest-Priority Items (Immediate Focus: next 24–72 hours)
1. **P0:** #6211 — Tangem migration + compromised support narrative (must publish official safe path)
2. **P0:** Discord phishing/impersonation incident hardening (canonical links, lock down support workflow)
3. **P0:** Cloud MVP release train coordination (monorepo → elizacloud-plugin → cloud-v2) with a single tracking checklist
4. **P1:** npm token rotation/publishing stability (unblock releases)
5. **P1:** PR #6263 provider parallelization/timeout (decide vs #6209; add observability + tests)
6. **P1:** PR #6216 Cloud integration mega-PR (split + validate golden path)
7. **P2:** PR #6200 JWT auth/data isolation (security review + docs; promote if Cloud needs it now)
8. **P2:** Starknet plugin TS/runtime handler blockers (formalize into tracked issue + fix)

---

## Patterns / Themes Indicating Deeper Problems
- **Release engineering fragility:** multiple steps across repos + npm auth changes = high risk of missed ship dates.
- **“Support is the product” gap:** migration complexity + impersonation risk shows missing canonical, verifiable support channel and playbook.
- **Interface churn / type drift in plugins:** repeated TS compatibility issues suggest insufficient stability guarantees and migration guides for plugin authors.
- **Performance best-practice ambiguity:** provider behavior expectations (no API calls, caching) are being discovered ad hoc rather than enforced via contracts/tests.

---

## Process Recommendations (Prevent Recurrence)
1. **Establish a “Single Source of Truth” security + migration page** (GitHub Pages/docs) and link it everywhere; pin it in Discord.
2. **Adopt a release checklist + owner mapping** for multi-repo launches; require a tracking issue for every “ship date.”
3. **CI preflight + automated publishing health checks** (npm auth validation, version pin validation, dependency mismatch detection).
4. **Plugin API stability policy:** versioned interfaces, codemods, and a dedicated “plugin author migration guide” per minor release.
5. **Observability-by-default for runtime pipelines:** standardized timing logs/metrics for providers/actions to catch performance regressions before users do.