## Issue Triage — 2026-04-23

### 1) CI: `claude-code-action` failing to fetch OIDC token (missing `id-token: write`)
- **Issue Title & ID:** Fix GitHub Actions OIDC permissions for `claude-code-action` (elizaos-plugins/registry **PR #346**)
- **Current Status:** Open; workflow failing due to repository/workflow permissions misconfiguration (not code-related)
- **Impact Assessment:**
  - **User Impact:** **High** (blocks contributors’ PR validation/automation in plugin registry)
  - **Functional Impact:** **Partial** (core runtime works, but ecosystem delivery pipeline blocked)
  - **Brand Impact:** **High** (public CI red on registry undermines reliability perception)
- **Technical Classification:**
  - **Category:** Bug / Infrastructure
  - **Component Affected:** CI/CD (GitHub Actions) for Plugin Registry
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** GitHub Actions security model, OIDC, workflow permissions
  - **Dependencies:** Repo-level settings; workflow YAML permissions stanza; org policy constraints
  - **Estimated Effort (1–5):** **1**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Update workflow permissions in failing job to include `permissions: { id-token: write, contents: read }` (or job-level equivalent).
  2. Confirm the action is intended to use OIDC (vs PAT); validate `GITHUB_TOKEN` scope and `audience`/`role` config if applicable.
  3. Re-run workflow on PR #346; ensure forks are handled safely (restrict OIDC on forked PRs if needed).
  4. Add a short CI troubleshooting note in registry CONTRIBUTING / README for future PR authors.
- **Potential Assignees:** **stan0473** (CI triage), **odilitime** (core infra), **lalalune** (build/release stability)

---

### 2) Discord posts auto-deleted without audit log entries
- **Issue Title & ID:** Discord messages auto-deleting without audit log trace (**No GH issue yet — create one**)
- **Current Status:** Ongoing/unclear; multiple users affected (e.g., flykite, nusko_); manual reposting workaround
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (blocks community support, sharing links/resources)
  - **Functional Impact:** **No** (does not break elizaOS runtime, but disrupts support pipeline)
  - **Brand Impact:** **High** (appears like censorship or instability; fuels distrust amid lawsuit concerns)
- **Technical Classification:**
  - **Category:** UX / Community Ops / Platform Reliability
  - **Component Affected:** Discord server moderation tooling / integrations
  - **Complexity:** **Moderate effort** (requires systematic isolation)
- **Resource Requirements:**
  - **Required Expertise:** Discord admin/mod tooling, AutoMod, bots/webhooks, role permissions, channel settings
  - **Dependencies:** Third-party bots; Discord platform incidents; server audit configuration
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GitHub tracking issue in the appropriate ops/meta repo (or `elizaos/elizaos.github.io` if that’s the chosen “ops” tracker).
  2. Inventory server automations: AutoMod rules, bot message deletion permissions, link filters, anti-spam services.
  3. Enable/verify logging: message delete logs (bot logs + Discord audit), and isolate by channel/user role.
  4. Run a controlled reproduction: test messages with links vs no links; test from affected roles; document exact timestamps.
  5. Publish a brief status note in Discord explaining it’s a platform/config issue and how users can route critical posts (e.g., dev channel / DM mod) until fixed.
- **Potential Assignees:** **odilitime** (moderation + incident owner), **stan0473** (server perms), **pmairca** (community ops)

---

### 3) Security advisory: wallet drainer phishing at `bulkdao.co/allocation`
- **Issue Title & ID:** Publish security advisory + add anti-phishing guidance (**No GH issue yet — create one**)
- **Current Status:** Incident reported; community warned; link preserved for awareness; no formal advisory artifact yet
- **Impact Assessment:**
  - **User Impact:** **Critical** (direct fund loss; likely repeat victimization)
  - **Functional Impact:** **No** (not a framework bug, but impacts user safety in ecosystem)
  - **Brand Impact:** **High** (users associate loss with project/community if guidance is absent)
- **Technical Classification:**
  - **Category:** Security / Documentation
  - **Component Affected:** Community security posture; onboarding docs; Discord moderation
  - **Complexity:** **Simple fix** (content + pinned messaging), **Moderate** if adding in-product warnings
- **Resource Requirements:**
  - **Required Expertise:** Security comms, Discord moderation, docs
  - **Dependencies:** Where official advisories live (docs site vs repo security advisories)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create a GH issue to track advisory publication and distribution checklist.
  2. Add a docs page: “Common scams & wallet safety” including the reported domain, wallet-connection warnings, and verification steps.
  3. Pin a Discord message in relevant channels; add AutoMod keyword/domain alerts (without encouraging clicks).
  4. Add a “Never DM support / never connect wallet for migration” warning to migration-related copy and FAQs.
- **Potential Assignees:** **igor.peregudov** (incident reporter), **odilitime** (moderation + docs approval), **hide.o.n** (community visibility)

---

### 4) Token migration late requests (missed window) — support process & communications
- **Issue Title & ID:** Late AI16Z → ELIZAOS migration requests workflow (**No GH issue; process item**)
- **Current Status:** Migration closed; ad-hoc waitlist offered; user frustration ongoing
- **Impact Assessment:**
  - **User Impact:** **High** (affected holders cannot complete migration; repeated support load)
  - **Functional Impact:** **Partial** (not runtime; but impacts ecosystem participation)
  - **Brand Impact:** **High** (trust erosion; amplifies fraud/dumping allegations)
- **Technical Classification:**
  - **Category:** UX / Documentation / Policy
  - **Component Affected:** Migration support + public comms
  - **Complexity:** **Moderate effort** (policy + tooling; potentially legal constraints)
- **Resource Requirements:**
  - **Required Expertise:** Community ops, legal/compliance coordination, wallet ops, comms
  - **Dependencies:** Legal counsel guidance; migration contract/infra ability to reopen; exchange considerations
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Decide and document policy: “closed permanently” vs “possible reopen under conditions,” with a single canonical FAQ.
  2. If waitlist continues: standardize intake (form + required proof) and set expectations (no guarantees, response times).
  3. Add scam-resistant guidance: official-only channels, no tickets via DMs, no wallet connections to unknown sites.
  4. Publish a short statement about the process to reduce repetitive Discord disputes.
- **Potential Assignees:** **odilitime** (process owner), **pmairca** (community ops), (legal liaison as available)

---

### 5) Telegram read receipt optimization: avoid nested lookups for message ID fetching
- **Issue Title & ID:** Telegram read receipt optimization (elizaos/eliza **#7009**)
- **Current Status:** Open follow-up required (per dev digest)
- **Impact Assessment:**
  - **User Impact:** **Medium** (Telegram users; likely common connector)
  - **Functional Impact:** **Partial** (performance/latency/reliability in message handling)
  - **Brand Impact:** **Medium** (connector quality reflects on framework)
- **Technical Classification:**
  - **Category:** Performance / Bug
  - **Component Affected:** Telegram integration / messaging runtime
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime internals, Telegram APIs, message state caching/indexing
  - **Dependencies:** Existing message store/index; potential interaction with prompt bloat reduction work
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Profile current message ID fetch path; identify the nested lookup hotspots.
  2. Introduce caching/index for message ID → receipt mapping (bounded + eviction).
  3. Add regression tests for read receipt correctness under high throughput.
  4. Validate on real Telegram export/replay dataset.
- **Potential Assignees:** **odilitime** (core runtime), **lalalune** (message service stability), **0xSolace** (runtime performance hardening)

---

### 6) Cloud platform: tenant ID formatting + session expiry handling bugs
- **Issue Title & ID:** Fix tenant ID formatting + session expiry handling (elizaos/cloud **Issue ID not provided — create GH issues**)
- **Current Status:** In progress per digest; not yet validated as resolved
- **Impact Assessment:**
  - **User Impact:** **High** (auth/session issues can lock users out)
  - **Functional Impact:** **Yes/Partial** (blocks login / sustained sessions in cloud experience)
  - **Brand Impact:** **High** (login failures are highly visible)
- **Technical Classification:**
  - **Category:** Bug
  - **Component Affected:** Cloud Auth / Identity (Steward migration related)
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web auth, session management, Steward integration, database identity mapping
  - **Dependencies:** Recent auth migration PRs; front-end login button changes (EVM/Solana)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Create two explicit issues with reproduction steps and affected environments.
  2. Add logging/telemetry for tenant resolution and session refresh/expiry transitions.
  3. Build an integration test covering: new user login, returning user, expired session refresh, multi-wallet linking.
  4. Coordinate release notes so users understand changes post-Steward migration.
- **Potential Assignees:** **odilitime** (platform), **stan0473** (platform), **lalalune** (stability)

---

### 7) “v2 alpha” stability + versioning convention confusion (onboarding friction)
- **Issue Title & ID:** Clarify versioning and publish a stability matrix for v2/v3 (**No GH issue — create doc issue**)
- **Current Status:** Community confusion reported; v2 considered usable but “alpha”; version tags counterintuitive (0.x/1.x/2.x mapping)
- **Impact Assessment:**
  - **User Impact:** **High** (new builders blocked by uncertainty)
  - **Functional Impact:** **Partial** (development proceeds but adoption slows)
  - **Brand Impact:** **Medium–High** (signals instability / unclear roadmap)
- **Technical Classification:**
  - **Category:** Documentation / UX
  - **Component Affected:** Docs site, release process, repository tags
  - **Complexity:** **Simple fix** (docs), potentially **Architectural change** if renaming/tag strategy changes
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, docs, ecosystem coordination
  - **Dependencies:** Planned v3 release timing; current alpha channel practices
  - **Estimated Effort (1–5):** **2** (docs only) / **4** (if retagging strategy)
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish “Which version should I build on?” doc: stability guarantees, API compatibility notes, recommended branch/tag.
  2. Add a simple table: connectors/plugins known-good on each version (Discord/Telegram, etc.).
  3. Decide whether to introduce clearer “v3” branding externally even if internal semver differs (e.g., docs headline).
- **Potential Assignees:** **stan0473** (versioning explainer), **odilitime** (release owner), **vincent067** (docs contributor, based on CONTRIBUTING PR work)

---

### 8) Port `elisym` integration to v3 after ecosystem merge
- **Issue Title & ID:** Port Elisym integration to v3 (tracking item; related to `@elisym/plugin-elizaos` and roadmap — **No GH issue ID provided**)
- **Current Status:** Next “quest” identified; v2 port feasible; v3 port pending
- **Impact Assessment:**
  - **User Impact:** **Medium** (marketplace monetization path; affects plugin builders)
  - **Functional Impact:** **Partial** (ecosystem capability, not core runtime)
  - **Brand Impact:** **Medium** (signals ecosystem momentum)
- **Technical Classification:**
  - **Category:** Feature / Integration
  - **Component Affected:** Plugin system, Nostr/NIP-89/90 handling, Solana payments integration surface
  - **Complexity:** **Complex solution** (cross-version API differences)
- **Resource Requirements:**
  - **Required Expertise:** Plugin API in v3, protocol integration (Nostr), Solana payment flows, testing/CI
  - **Dependencies:** v3 API stability; registry publishing pipeline health (CI issue above)
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Create a v3 porting checklist: API diffs, required adapters, test harness.
  2. Define minimal v3-compatible feature set (capability cards + encrypted job request loop + payment receipt).
  3. Ensure registry CI is green first; then stage alpha release for v3 users.
- **Potential Assignees:** **igor.peregudov** (implementation owner), **stan0473** (v3 guidance), **odilitime** (ecosystem merge coordination)

---

## Highest-Priority Summary (Top 5–10 to address immediately)
1. **P0:** Fix registry CI OIDC permissions blocking PR #346 (elizaos-plugins/registry PR #346).
2. **P1:** Investigate Discord silent auto-deletion and restore reliable community support flow (create GH issue).
3. **P1:** Publish a formal anti-phishing/security advisory for the `bulkdao.co/allocation` drainer incident (create GH issue + docs + pinned warnings).
4. **P1:** Stabilize/communicate migration support posture for late AI16Z → ELIZAOS requests (policy + scam-resistant workflow).
5. **P1:** Cloud tenant ID formatting + session expiry bugs (create GH issues; prioritize auth stability after Steward migration).
6. **P1:** Publish a version stability matrix + clarify v2/v3 naming to reduce onboarding friction (create docs issue).
7. **P2:** Telegram read receipt performance optimization (elizaos/eliza #7009).
8. **P2:** Port Elisym integration to v3 (create tracking issue; proceed after CI + v3 API readiness).

---

## Patterns / Themes Indicating Deeper Issues
- **Ecosystem reliability is gated by infrastructure correctness**: CI permission misconfigurations and registry workflow fragility can halt community contributions even when core code is fine.
- **Trust & safety pressures are spilling into technical channels**: scams, phishing, and migration disputes are creating operational load and reputational risk; lack of “single source of truth” amplifies chaos.
- **Versioning/release communication gap**: developers are willing to build, but uncertainty around “alpha/stable” and confusing version semantics slows adoption and increases repetitive support questions.
- **Connector quality is a recurring pain-point**: Telegram performance/read receipts and Discord community tooling issues both map to “message transport + state handling” as a sensitive area.

---

## Process Improvement Recommendations
1. **Create an “Ops/Incidents” GitHub project (or repo) for non-code blockers** (Discord incidents, phishing advisories, migration support), so urgent operational work is tracked with owners and deadlines.
2. **Add a CI “permissions checklist” to workflow PR reviews** (especially for OIDC usage): require explicit `permissions` blocks and fork-safe behavior before merge.
3. **Publish a monthly “Stability & Compatibility Matrix”** (core + key plugins/connectors) and link it prominently in README/docs to reduce Discord support churn.
4. **Security posture baseline for community**: pinned “No DM support” policy, scam reporting workflow, and a maintained denylist/alert list for known malicious domains—paired with periodic reminders during high-risk events (migration windows, legal news cycles).
5. **Release readiness rubric for “stable”**: define minimal criteria (CI green across matrix, connector smoke tests, docs updated) to make “stable v2” timing predictable for builders planning integrations.