## Issue Triage — 2026-02-06

### 1) Welcome email “Get started” overwrites existing accounts/agents + incorrect credit amount
- **Issue Title & ID:** Welcome email link overwrites existing account/agents and creates new $1 account (missing promised $5) — **INC-ELIZACLOUD-001**
- **Current Status:** Reported in Discord (#💬-coders, 2026-02-05). **sam** requested affected user details to investigate. No confirmed fix yet. Suggested immediate mitigation: pause welcome emails.
- **Impact Assessment:**
  - **User Impact:** **Critical** (any new user clicking email CTA; also harms existing users if they click while logged in / already provisioned)
  - **Functional Impact:** **Yes** (breaks onboarding, can destroy/replace user state)
  - **Brand Impact:** **High** (loss of trust; “stealing credits / deleting agents” perception)
- **Technical Classification:**
  - **Issue Category:** Bug / UX (potentially Security-adjacent due to account takeover-like behavior)
  - **Component Affected:** **ElizaCloud** (Auth/session, email deep links, provisioning, credit ledger)
  - **Complexity:** **Architectural change** if root cause is identity-linking; otherwise **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Auth/session management, deep-link handling, backend provisioning, billing/credits ledger, email template system
  - **Dependencies:** Ability to reproduce with real email token + existing account; access to email link generation code and auth redirect handler
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediately disable/pause** sending the welcome email CTA (or replace link with a neutral landing page) until fixed.
  2. Add server-side guardrails: if deep link resolves to an authenticated session, **never create a new account**; require explicit confirmation before any provisioning.
  3. Audit link token semantics: ensure tokens are **single-use**, bound to intended recipient identity, and cannot map to “create new account” if a user already exists.
  4. Add idempotency to onboarding provisioning (credits + agent creation) keyed by userId/email.
  5. Write regression tests: (a) existing account clicks CTA, (b) new user clicks CTA multiple times, (c) user opens CTA on a different device.
  6. Run a one-time repair script: identify users created by CTA flow with $1 and reconcile to promised $5 where appropriate; restore overwritten agents if logs allow.
- **Potential Assignees:** **sam** (investigating), **Stan ⚡** (cloud/auth integration context), **0xbbjoker** (bugfix + infra), support from **tcm390** (deployment discipline)

---

### 2) Missing promised $5 credits on new accounts (onboarding credit ledger not applied)
- **Issue Title & ID:** New accounts not receiving promised $5 credits — **INC-ELIZACLOUD-002**
- **Current Status:** Reported alongside INC-ELIZACLOUD-001 (Discord 2026-02-05). Not confirmed resolved.
- **Impact Assessment:**
  - **User Impact:** **High** (affects many/most new signups)
  - **Functional Impact:** **Partial** (product usable but undermines trial/onboarding)
  - **Brand Impact:** **High** (appears deceptive)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** ElizaCloud Billing/Credits
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Billing ledger, signup pipeline, idempotent credit grants
  - **Dependencies:** Must be fixed in tandem with INC-ELIZACLOUD-001 to avoid double-crediting during retries
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Trace signup pipeline to confirm where credit grant should occur (DB trigger/job/endpoint).
  2. Add idempotent “grantTrialCredit(userId, campaignId)” function with unique constraint.
  3. Backfill credits for affected cohort (bounded by campaign start date; exclude fraud cases).
  4. Add dashboard alerting: percentage of signups with trial credit applied.
- **Potential Assignees:** **sam**, **0xbbjoker**

---

### 3) Payment/recharge flow blockers: VPN users blocked; no easy way to recharge friends; friction at conversion
- **Issue Title & ID:** Payment page blocked on VPN + inability to transfer/recharge accounts — **INC-ELIZACLOUD-003**
- **Current Status:** Reported in Discord (#💬-coders, 2026-02-05). Proposed solution: per-account wallet addresses for direct deposits.
- **Impact Assessment:**
  - **User Impact:** **High** (directly affects paid conversion; VPN usage is common)
  - **Functional Impact:** **Partial** (core usage possible until credits run out)
  - **Brand Impact:** **High** (lost customers at the “pay” moment)
- **Technical Classification:**
  - **Issue Category:** UX / Bug / Feature (combo)
  - **Component Affected:** ElizaCloud Payments, Billing, Fraud/Geo/VPN controls
  - **Complexity:** **Complex solution** (payments + compliance/fraud + ledger)
- **Resource Requirements:**
  - **Required Expertise:** Payments integration, risk controls, wallet accounting, ledger reconciliation, security
  - **Dependencies:** Decision on supported rails (card/crypto), compliance constraints, accounting model for transfers
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1** (P0 if revenue is currently materially impacted day-to-day)
- **Specific Actionable Next Steps:**
  1. Identify why VPN blocks payment page (WAF rule, payment provider policy, geo restrictions) and implement a **graceful fallback** (support contact + alternate link/rail).
  2. Define “recharge” primitives:
     - (a) **Deposit address per account** (crypto) with chain + memo/tag model
     - (b) Optional **internal transfers** between accounts with anti-abuse limits
  3. Implement minimal “deposit address” MVP: generate address, map deposits to user, confirmations, credit ledger entry, refund handling.
  4. Add conversion telemetry: drop-off rate at payment page, VPN correlation.
- **Potential Assignees:** **sam** (platform), **Stan ⚡** (cloud integrations), security review by **jin**

---

### 4) Babylon.market: failing API endpoints causing pages to break / users stuck
- **Issue Title & ID:** Babylon.market API endpoints failing (page functionality breaks, users stuck) — **INC-BABYLON-001**
- **Current Status:** Actively debugged in Discord (#core-devs, 2026-02-05). Fixes were pushed and **tcm390 merged to production**; stability still under test.
- **Impact Assessment:**
  - **User Impact:** **High** (all testers; blocks expansion beyond top-100)
  - **Functional Impact:** **Yes** (core navigation/flows fail)
  - **Brand Impact:** **High** (launch readiness)
- **Technical Classification:**
  - **Issue Category:** Bug / Reliability
  - **Component Affected:** Babylon.market API + frontend integration
  - **Complexity:** **Moderate effort** (may become complex if due to data model/auth)
- **Resource Requirements:**
  - **Required Expertise:** Backend API debugging, observability/logging, deployment
  - **Dependencies:** Repro steps from testers; API logs/traces; feature flags for staged rollout
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Create a single incident checklist: failing endpoints list, error codes, impacted routes.
  2. Add request correlation IDs and structured logs for auth + reward endpoints.
  3. Add smoke tests for critical pages in CI (login → profile → rewards claim).
  4. Establish a rollback plan and canary release for future fixes.
- **Potential Assignees:** **SYMBiEX** (deployment), **tcm390** (prod merges), support from **sam**

---

### 5) Babylon.market: username creation bug (“@userid:priv”)
- **Issue Title & ID:** Username generation shows “@userid:priv” instead of expected username — **INC-BABYLON-002**
- **Current Status:** Reported by users; **SYMBiEX** investigating (Discord 2026-02-05). No confirmed resolution in notes.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (visible to all affected signups; harms social/reputation aspects)
  - **Functional Impact:** **Partial** (site works but identity/UX broken; may break mentions/reward attribution)
  - **Brand Impact:** **High** (looks unpolished; “broken identity”)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Babylon.market Identity/Profile service
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Auth claims parsing, username normalization, DB constraints/migrations
  - **Dependencies:** Determine source field (“userid:priv”) and when it’s substituted (OAuth provider? internal auth?)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Trace username assignment: provider claim → internal user record → display.
  2. Add validation: reject placeholder usernames; require user prompt or deterministic safe default.
  3. Backfill: migrate existing affected users to corrected usernames; handle collisions.
- **Potential Assignees:** **SYMBiEX**, **tcm390**

---

### 6) Babylon.market: Discord OAuth account linking is broken
- **Issue Title & ID:** Discord OAuth linking not working — **INC-BABYLON-003**
- **Current Status:** Confirmed broken; fixes were pushed and merged to production (Discord 2026-02-05), but requires verification.
- **Impact Assessment:**
  - **User Impact:** **High** (many users rely on Discord identity)
  - **Functional Impact:** **Yes** for account-link flows and possibly rewards gating
  - **Brand Impact:** **High**
- **Technical Classification:**
  - **Issue Category:** Bug / Integration
  - **Component Affected:** OAuth integration, auth backend, callback routing
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** OAuth, redirect URI config, token exchange, session binding
  - **Dependencies:** Correct Discord app credentials + redirect URIs in each environment
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Validate in production with a test Discord account and recorded HAR logs.
  2. Add integration test that runs against a staging Discord app.
  3. Add runtime checks: mismatched redirect URI and state/nonce failures surfaced to user with actionable error.
- **Potential Assignees:** **tcm390**, **SYMBiEX**, support from **Stan ⚡** (OAuth experience across platforms)

---

### 7) Babylon.market: Twitter follow reward claiming fails with errors
- **Issue Title & ID:** Twitter follow reward claim errors — **INC-BABYLON-004**
- **Current Status:** Reported as broken; fix discussed and merged to production (Discord 2026-02-05). Needs confirmation and monitoring.
- **Impact Assessment:**
  - **User Impact:** **Medium–High** (impacts incentive loop; not all users)
  - **Functional Impact:** **Partial** (core site usable; growth loop degraded)
  - **Brand Impact:** **Medium–High** (rewards perceived as “scammy” if broken)
- **Technical Classification:**
  - **Issue Category:** Bug / Integration
  - **Component Affected:** Rewards service, Twitter/X verification integration
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** X API verification logic, anti-fraud, retries, rate limits
  - **Dependencies:** Reliable OAuth/token storage if required; cache/queue if verification is async
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Confirm resolution with 5–10 real accounts; document exact error messages if persists.
  2. Add retry + async verification (queue) to avoid timeouts/rate limits.
  3. Add audit log: reward claim attempt → verification outcome → credit/grant.
- **Potential Assignees:** **SYMBiEX**, **tcm390**

---

### 8) Skill ecosystem security: malicious skills on clawhub; need scanning/LLM review and/or sandboxing
- **Issue Title & ID:** Malicious skills risk in ecosystem; implement scanning/rewrite/LLM review + consider sandboxing — **SEC-SKILLS-001**
- **Current Status:** Discussed in Discord (2026-02-03). Proposed actions: scanner skills, code rewrite/adaptation phase, LLM review; sandboxing suggested by jin.
- **Impact Assessment:**
  - **User Impact:** **Critical** (supply-chain style compromise potential as adoption grows)
  - **Functional Impact:** **Yes** (can compromise machines, credentials, or agent outputs)
  - **Brand Impact:** **High** (security incident could be existential)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Plugin/Skill system (distribution + execution)
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Application security, sandboxing (containers/VM/WASM), static analysis, policy enforcement, signing/attestation
  - **Dependencies:** Define skill packaging standard; CI pipeline for scanning; runtime execution environment decisions
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Define threat model: what skills can access (FS, network, env vars, tokens).
  2. Implement minimum viable protections:
     - skill allowlist / publisher verification
     - static scanners (secrets, network calls, file ops)
     - permissions manifest required for each skill
  3. Prototype sandbox execution path (WASM or containerized runner) and compare tradeoffs.
  4. Add “LLM review” as advisory only; do not treat as a security boundary.
  5. Publish policy + secure-by-default guidelines for skill authors.
- **Potential Assignees:** **Odilitime** (plugin-cskills), **jin** (security direction), **0xbbjoker** (implementation support)

---

### 9) GitHub: “Billing” issue is open but empty (needs definition; likely overlaps ElizaCloud payment blockers)
- **Issue Title & ID:** Billing — **elizaos/eliza #6448**
- **Current Status:** **OPEN**, no description/comments in provided data.
- **Impact Assessment:**
  - **User Impact:** **Medium** (unknown scope; likely high if it tracks current ElizaCloud billing problems)
  - **Functional Impact:** **Partial** (likely affects payments/credits)
  - **Brand Impact:** **Medium–High**
- **Technical Classification:**
  - **Issue Category:** Bug/Feature (needs clarification)
  - **Component Affected:** Billing (Cloud), possibly core interfaces
  - **Complexity:** **Unknown** (pending scoping)
- **Resource Requirements:**
  - **Required Expertise:** Product + billing engineering
  - **Dependencies:** Must be linked to concrete incidents (INC-ELIZACLOUD-001/002/003)
  - **Estimated Effort (1–5):** **1** (to triage/scope), then re-estimate
- **Recommended Priority:** **P1** (triage immediately; implementation priority depends on scope)
- **Specific Actionable Next Steps:**
  1. Update the issue body with: symptoms, repro steps, expected behavior, logs/screenshots, impacted flows.
  2. Split into sub-issues: credits grant, payment access/VPN, transfers/deposits, ledger reconciliation.
  3. Add labels: `cloud`, `billing`, `onboarding`, `p0` where applicable.
- **Potential Assignees:** **borisudovicic** (opened), **sam** (platform owner)

---

### 10) Twitter plugin local compatibility confusion (users don’t know which Eliza version works)
- **Issue Title & ID:** Determine compatible Eliza version for Twitter plugin running locally — **DX-TWITTER-001**
- **Current Status:** Question raised in Discord (#💬-discussion, 2026-02-05); unanswered in provided data.
- **Impact Assessment:**
  - **User Impact:** **Medium** (developer onboarding friction)
  - **Functional Impact:** **Partial** (blocks common use case: local social agent testing)
  - **Brand Impact:** **Medium** (DX perception)
- **Technical Classification:**
  - **Issue Category:** Documentation / UX
  - **Component Affected:** Plugin system + plugin-twitter + CLI/versioning
  - **Complexity:** **Simple fix** (doc), **Moderate** if actual version skew/bug exists
- **Resource Requirements:**
  - **Required Expertise:** Maintainers familiar with plugin-twitter and recent breaking changes
  - **Dependencies:** Confirm current recommended branch/version (note: community suggested `odi-dev` branch in other discussions)
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Publish a compatibility matrix: CLI version ↔ core version ↔ plugin-twitter version.
  2. Add a “known good local setup” quickstart and pin versions.
  3. If incompatibility is real: open a GitHub issue with repro and fix or constraints.
- **Potential Assignees:** **Odilitime** (branch guidance), **0xbbjoker** (plugin work), docs support from **jin**

---

### 11) Token migration fallout: scam targeting + missing-deadline confusion (support & comms gap)
- **Issue Title & ID:** Migration support process gaps enabling scams + user confusion — **SEC-COMMS-001**
- **Current Status:** Active Discord discussion (2026-02-05). Scammer intervention occurred; community mods warned users. Users frustrated about deadline; migration site deactivated.
- **Impact Assessment:**
  - **User Impact:** **High** (holders seeking help; high emotional + financial stakes)
  - **Functional Impact:** **No** (not core framework), but harms ecosystem trust and support load
  - **Brand Impact:** **High** (scam victims will blame project)
- **Technical Classification:**
  - **Issue Category:** Security / Documentation / UX (support)
  - **Component Affected:** Community support, official comms, website/support tooling
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Community ops, security comms, basic web/content updates
  - **Dependencies:** Clear official support channel(s), ticketing or pinned guidance, official verification
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Publish a single canonical “Migration Help” page and pin it in Discord: **no DMs**, official links only, how to verify staff.
  2. Add an auto-moderation response for “migration” keywords with scam warnings + correct links.
  3. Provide a postmortem-style timeline + reminder policy for future deadlines (email + Discord + on-chain message if possible).
- **Potential Assignees:** **jasyn_bjorn** (community clarifications), **Kenk** (moderation), comms support from **Odilitime**

---

## Summary: Top Highest-Priority Issues (address immediately)
1. **INC-ELIZACLOUD-001 (P0):** Welcome email CTA overwrites accounts/agents and creates incorrect new accounts.
2. **INC-ELIZACLOUD-002 (P0):** Trial credits not applied ($5 missing) — onboarding credibility + retention.
3. **INC-BABYLON-001 (P0):** Babylon.market failing API endpoints causing broken pages/users stuck.
4. **INC-BABYLON-003 (P0):** Discord OAuth linking broken (verify fix in prod; add tests).
5. **SEC-SKILLS-001 (P0):** Malicious skills risk — establish scanning/permissions + sandbox roadmap.
6. **INC-ELIZACLOUD-003 (P1):** Payment/recharge blockers (VPN block, lack of transfer/deposit rails) impacting conversion.
7. **INC-BABYLON-002 (P1):** Username bug “@userid:priv” harming identity and possibly attribution.
8. **INC-BABYLON-004 (P1):** Twitter follow reward claiming errors harming growth loops.
9. **SEC-COMMS-001 (P1):** Migration scam surface area; tighten official support/anti-scam comms.
10. **elizaos/eliza #6448 (P1):** “Billing” issue needs immediate scoping and decomposition.

---

## Patterns / Themes Suggesting Deeper Problems
- **Identity + session binding issues across products:** The ElizaCloud email deep-link overwriting behavior and Babylon OAuth/linking failures both point to fragile handling of **state/identity binding** and insufficient guardrails around “create vs link vs login.”
- **Insufficient end-to-end testing for revenue-critical flows:** Onboarding credits, payment access, OAuth linking, and reward claiming are all **conversion funnels** that appear to lack reliable smoke tests and monitoring.
- **Security posture lagging ecosystem growth:** Skill/plugin distribution is expanding faster than safety controls (scanning, permissions, sandboxing, publisher verification), raising supply-chain risk.
- **Operational maturity gap (observability + canaries):** Repeated “merge to production then test” suggests missing staging parity, canary releases, and automated regression coverage.

---

## Recommendations: Process Improvements
1. **Introduce “Funnel SLOs” + monitoring:** Track and alert on signup→credit applied, email CTA→login success, payment page load success (incl. VPN), OAuth link success, reward claim success.
2. **Add release gates for critical paths:** Require passing automated smoke tests (staging) before production merges for onboarding/auth/payment/rewards.
3. **Implement safer link-handling standards:** All email deep links must be idempotent, single-use, and must not trigger account creation when a session exists.
4. **Establish a security baseline for skills/plugins:** Permissions manifest + allowlist/verification now; sandbox execution roadmap; publish secure authoring guidelines.
5. **Triage hygiene:** Ensure open GitHub issues (e.g., **#6448**) are non-empty, scoped, labeled, and linked to incidents; split large “billing” topics into actionable sub-issues with owners and acceptance criteria.