## Issue Triage — 2026-01-02

### 1) Jeju OAuth3 testnet demo login does not work (DISC-2026-01-02-01)
- **Current Status:** Reported in Discord (2025-12-31); no linked GitHub issue found in provided data; blocking demo usability.
- **Impact Assessment:**
  - **User Impact:** Medium (demo users + early partners)
  - **Functional Impact:** **Yes** (authentication is a core entrypoint for Jeju)
  - **Brand Impact:** **High** (public demo failure undermines “ready to go public” narrative)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Cloud/Jeju Auth (OAuth3), Web App
  - **Complexity:** Moderate effort (could be config, callback, session, or chain/IPFS routing edge)
- **Resource Requirements:**
  - **Required Expertise:** OAuth flows, web auth/session handling, on-chain registry routing, IPFS asset resolution, infra config
  - **Dependencies:** Jeju backend routing + registry/IPFS integration; any environment variables/secrets management
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Capture failing flow details: browser console, network trace, server logs, callback URL, state/nonce validation.
  2. Validate OAuth3 config: redirect URIs, client registration, cookie domain/samesite/secure flags.
  3. Add minimal automated auth smoke test for testnet environment (login → token → session → landing page).
  4. If chain/IPFS routing is in the critical path, add graceful fallback error messaging and observability (correlation IDs).
- **Potential Assignees:** **Shaw** (Jeju backend/infra), **Odilitime** (web3 signing + integration), **Stan** (type/route standardization; reliability)

---

### 2) Discord role gating / Collabland still reflects AI16Z holdings instead of ElizaOS (DISC-2026-01-02-02)
- **Current Status:** Action item noted (2025-12-30); no linked GitHub issue found in provided data; ongoing user friction for gated channels (e.g., Spartan).
- **Impact Assessment:**
  - **User Impact:** High (many token holders attempting verification/migration)
  - **Functional Impact:** Partial (core framework unaffected; community access + support flows impacted)
  - **Brand Impact:** High (token migration confusion + “broken verification” perception)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Community Infrastructure (Discord verification), Token integration
  - **Complexity:** Moderate effort (depends on Collabland configuration + chain support + contract addresses)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin tooling, Collabland configuration/API, on-chain token verification (SOL + BSC per discussion)
  - **Dependencies:** Final contract addresses + migration rules + chain indexing source
  - **Estimated Effort:** 2–3/5
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Confirm canonical contract addresses (BSC + SOL) and migration recognition rules.
  2. Update Collabland (or replacement verifier) to validate **ElizaOS** holdings, not AI16Z.
  3. Add a public “verification status” help page + Discord pinned message with troubleshooting steps.
  4. Add monitoring: verification failure rate, common rejection reasons (wrong chain, stale cache, RPC errors).
- **Potential Assignees:** **Kenk** (verification process), **coinfucius.eth** (raised item), **Borko** (token utility/comms alignment)

---

### 3) Token migration questions unanswered (deadline, contract address, “token integrated into cloud”) (DISC-2026-01-02-03)
- **Current Status:** Repeated unanswered questions in Discord (2026-01-01); docs exist but are not resolving key FAQs.
- **Impact Assessment:**
  - **User Impact:** **Critical** (broad token-holder base; repeated support load)
  - **Functional Impact:** No (core runtime unaffected)
  - **Brand Impact:** **High** (trust + legitimacy + onboarding friction)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Docs site, website, cloud/token messaging
  - **Complexity:** Simple fix (content + links), with coordination needs
- **Resource Requirements:**
  - **Required Expertise:** Technical writing, tokenomics/migration knowledge, web/docs publishing
  - **Dependencies:** Confirmed authoritative answers (deadline, CA, supported wallets, cloud integration meaning)
  - **Estimated Effort:** 1–2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single canonical “Migration FAQ” answering: deadline, contract addresses (all chains), supported wallets, step-by-step.
  2. Define and document “token integrated into cloud” (billing? gating? staking? account linking?).
  3. Add prominent links in: docs front page, website footer (short term: CoinGecko links), Discord pinned posts, #migration-help bot response.
  4. Create a short decision tree: “I have AI16Z on MetaMask / Phantom / Tangem / hardware wallet → what to do.”
- **Potential Assignees:** **Kenk** (already updating token docs/website), **Borko** (token utility context), **Broccolex** (requested dedicated token page), **chomppp** (raised cloud integration doc need)

---

### 4) Desktop Phantom wallet connect issue (DISC-2026-01-02-04)
- **Current Status:** Reported (2025-12-31 action item); no linked GitHub issue found in provided data; impacts migration and verification.
- **Impact Assessment:**
  - **User Impact:** High (common wallet; affects token actions)
  - **Functional Impact:** Partial (blocks token-related workflows)
  - **Brand Impact:** Medium–High (users blame project even if wallet-side)
- **Technical Classification:**
  - **Issue Category:** Bug / Integration
  - **Component Affected:** Web3 wallet connect layer (desktop), migration tooling (if applicable)
  - **Complexity:** Moderate effort (depends on wallet adapter, browser differences, chain selection)
- **Resource Requirements:**
  - **Required Expertise:** Wallet adapters (Solana/EVM), frontend integration, RPC/provider debugging
  - **Dependencies:** Repro steps; environment matrix (Chrome/Brave, extensions, OS)
  - **Estimated Effort:** 3/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Collect repro matrix + logs; confirm if issue is with Phantom extension, deep link, or provider injection.
  2. Validate wallet adapter versions; add fallback/connect retry + clearer error states.
  3. Publish workaround (e.g., import EOA into Phantom vs MetaMask, as suggested by Kenk) with security caveats.
  4. If it’s third-party, pin known-issues + recommended versions and track upstream.
- **Potential Assignees:** **Odilitime** (web3 signing), **Kenk** (support + workflow), a frontend maintainer familiar with wallet adapters

---

### 5) OpenAI plugin: image generation fix + caching to prevent redundant media processing (elizaos-plugins/plugin-openai PR #23)
- **Current Status:** PR opened (per weekly summary); not confirmed merged in provided data.
- **Impact Assessment:**
  - **User Impact:** Medium–High (anyone using image/audio media tooling)
  - **Functional Impact:** Partial (media generation unreliable/inefficient)
  - **Brand Impact:** Medium (quality/performance)
- **Technical Classification:**
  - **Issue Category:** Bug / Performance
  - **Component Affected:** Model Integration (OpenAI plugin), Media pipeline
  - **Complexity:** Moderate effort (review + test + edge cases)
- **Resource Requirements:**
  - **Required Expertise:** Plugin architecture, OpenAI media endpoints, caching strategies, regression testing
  - **Dependencies:** None major; ensure cache invalidation + concurrency safety
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Review PR #23 for correctness (cache keys, TTL, memory/disk usage, concurrency).
  2. Add tests for “same media input” dedupe + multi-run determinism.
  3. Ensure no breaking changes to plugin public API; ship patch release.
- **Potential Assignees:** **Odilitime** (author), plugin maintainers/reviewers with media handling experience

---

### 6) Unified hooks with multi-transport support (HTTP/SSE/WebSocket) + duplicate event mitigation (elizaos/eliza PR #6300)
- **Current Status:** In-progress per Discord (2025-12-30); repository activity window shows no PR updates Jan 1–2, but work is referenced.
- **Impact Assessment:**
  - **User Impact:** Medium (developers building real-time experiences/integrations)
  - **Functional Impact:** Partial (duplicate events cause downstream bugs; transport limitations constrain integrations)
  - **Brand Impact:** Medium (stability/reliability)
- **Technical Classification:**
  - **Issue Category:** Bug / Feature
  - **Component Affected:** Core Framework (hooks/eventing), API transports
  - **Complexity:** Complex solution (transport parity + ordering/idempotency)
- **Resource Requirements:**
  - **Required Expertise:** Eventing semantics, SSE/WebSocket implementation, idempotency patterns, API design
  - **Dependencies:** Any ongoing messaging API refactor discussions (see #6298)
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P2** (promote to P1 if duplicates are still impacting production users)
- **Specific Actionable Next Steps:**
  1. Define event contract: unique event IDs, delivery guarantees, replay behavior, ordering.
  2. Add integration tests per transport ensuring no duplicates under reconnect/retry.
  3. Provide migration notes for plugin authors consuming hooks.
- **Potential Assignees:** **Stan** (referenced as working on it), core maintainers familiar with transports

---

### 7) Messaging API refactor to prevent double-processing / reliability issues (elizaos/eliza Issue #6298)
- **Current Status:** Open discussion item (per weekly summary); not updated in provided data window.
- **Impact Assessment:**
  - **User Impact:** Medium (manifests as flaky behavior; hard-to-debug)
  - **Functional Impact:** Partial (messaging is core; failures degrade agents/plugins)
  - **Brand Impact:** Medium–High (perceived “unreliable agents”)
- **Technical Classification:**
  - **Issue Category:** Architectural / Bug
  - **Component Affected:** Core Framework (messaging/event pipeline)
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Distributed systems patterns, message lifecycle design, plugin compatibility planning
  - **Dependencies:** Hooks/transports work (#6300), plugin refactors (Discord/Telegram messaging alignment)
  - **Estimated Effort:** 5/5
- **Recommended Priority:** **P2** (strategic, but should be scheduled deliberately)
- **Specific Actionable Next Steps:**
  1. Write an RFC: current failure modes (double-processing), proposed invariants, migration plan.
  2. Instrument current pipeline to quantify duplicates and identify triggers.
  3. Produce a staged rollout plan (behind feature flag) to avoid breaking plugins.
- **Potential Assignees:** Core maintainers; **Stan** (type/route standardization experience), contributors active in messaging-related plugin refactors

---

### 8) Chain-of-Thought (CoT) support discussion risks (scope clarity + safety) (elizaos/eliza Issue #6294)
- **Current Status:** Open discussion item (per weekly summary); no new activity in provided window.
- **Impact Assessment:**
  - **User Impact:** Low–Medium (future capability)
  - **Functional Impact:** No (not blocking current functionality)
  - **Brand Impact:** Medium (if mis-scoped, can create confusion or unsafe defaults)
- **Technical Classification:**
  - **Issue Category:** Feature Request / Architecture
  - **Component Affected:** Core Framework (reasoning/agent runtime)
  - **Complexity:** Architectural change (if implemented as first-class feature)
- **Resource Requirements:**
  - **Required Expertise:** Agent design, prompt/runtime safety, evaluation, product framing
  - **Dependencies:** Messaging/memory/tooling interfaces; policy on hidden reasoning vs summaries
  - **Estimated Effort:** 4/5
- **Recommended Priority:** **P3**
- **Specific Actionable Next Steps:**
  1. Clarify goals: “explicit CoT exposure” vs “internal reasoning traces” vs “structured plans.”
  2. Align with safety and privacy posture (avoid storing sensitive reasoning by default).
  3. Define minimal viable implementation (e.g., “plan objects” or “tool call rationale” summaries).
- **Potential Assignees:** Core architecture leads; contributors experienced with agent evaluation and safety

---

### 9) Token migration support gaps for unsupported wallets (elizaos/docs Issue #6211; related registry issue referenced)
- **Current Status:** Active in weekly summary; community workarounds exist; still a recurring pain point.
- **Impact Assessment:**
  - **User Impact:** High (wallet fragmentation)
  - **Functional Impact:** Partial (blocks migration for subset of users)
  - **Brand Impact:** High (token operations are high-sensitivity)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX (with some integration considerations)
  - **Component Affected:** Docs + migration tooling guidance
  - **Complexity:** Simple fix (docs) to Moderate (if tooling changes required)
- **Resource Requirements:**
  - **Required Expertise:** Web3 wallet operations, clear technical writing, support triage
  - **Dependencies:** Canonical migration flow; wallet compatibility list
  - **Estimated Effort:** 2/5
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Consolidate best workarounds into official docs with warnings and verification steps.
  2. Add “known supported wallets” + “unsupported wallet workaround” section.
  3. Create a migration checklist and add screenshots/video for highest-friction cases.
- **Potential Assignees:** Docs maintainers; **Kenk** (support patterns), community contributors who provided workarounds

---

## Top 5–10 Highest Priority Issues (Immediate Focus)
1. **P0:** Jeju OAuth3 testnet demo login broken (DISC-2026-01-02-01)
2. **P0:** Discord role gating / Collabland not updated for ElizaOS holdings (DISC-2026-01-02-02)
3. **P1:** Token migration FAQ gaps (deadline/CA/cloud integration meaning) (DISC-2026-01-02-03)
4. **P1:** Desktop Phantom wallet connect issue (DISC-2026-01-02-04)
5. **P1:** Unsupported wallet migration support consolidation (elizaos/docs #6211)
6. **P1:** OpenAI plugin media fix + caching (plugin-openai PR #23)
7. **P2:** Unified hooks multi-transport + duplicate event mitigation (elizaos/eliza PR #6300)
8. **P2:** Messaging API refactor to prevent double-processing (elizaos/eliza #6298)
9. **P3:** CoT support scope/safety clarification (elizaos/eliza #6294)

---

## Patterns / Themes Indicating Deeper Issues
- **Go-to-market readiness gaps:** Public-facing demos (Jeju auth) and community gating (Collabland) are not meeting reliability expectations, even while infra is described as “ready to go public.”
- **Token operations as a persistent support hotspot:** Migration, contract addresses, wallet compatibility, and “cloud integration” meaning are generating repeated questions and confusion—suggesting missing canonical, easily discoverable sources of truth.
- **Reliability/duplication concerns across layers:** Duplicate events and double-processing themes appear in hooks/messaging discussions, indicating a broader need for consistent idempotency and event lifecycle contracts across core + plugins.

---

## Recommendations (Process Improvements)
1. **Establish a “Canonical Answers” system for token + migration topics:** single source of truth (docs page) mirrored into Discord pinned posts and an auto-responder in #migration-help.
2. **Add release-gating smoke tests for public demos:** especially auth (login flow) and critical routing (registry → IPFS). Make “demo health checks” visible to core maintainers.
3. **Create an “Eventing Contract” RFC requirement:** any changes to hooks/messaging/transports should define idempotency, ordering, retry/reconnect behavior, and compatibility notes for plugin authors.
4. **Support playbooks for high-volume issues:** wallet-connect troubleshooting matrix + standardized template for collecting logs/repro steps to reduce back-and-forth in Discord.
5. **Operational ownership clarity:** explicitly assign DRIs for (a) Jeju demos, (b) token migration docs, (c) Discord verification tooling—so “action items” don’t stall without an issue/owner.