## Issue Triage — 2026-02-07

### 1) ElizaCloud welcome email creates duplicate accounts (prod vs dev subdomain) + agent fragmentation
- **Issue Title & ID**: Welcome email “Get started” routes to `dev.elizacloud.ai`, creating duplicate accounts and splitting agents | **DISCORD-ELIZACLOUD-001**
- **Current Status**: **Open** (repro confirmed by user; being handled via DMs; needs product fix)
- **Impact Assessment**
  - **User Impact**: **Critical** (hits new-user onboarding; likely affects many signups)
  - **Functional Impact**: **Yes** (breaks onboarding flow; fragments agents/accounts)
  - **Brand Impact**: **High** (looks like unsafe/unreliable account system)
- **Technical Classification**
  - **Issue Category**: **Bug / UX**
  - **Component Affected**: **ElizaCloud Auth + Email/Link Routing + Account Provisioning**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Web auth/session, email template/link generation, environment config, account identity model
  - **Dependencies**: Email provider/template system; environment routing; account merge tooling
  - **Estimated Effort (1-5)**: **4**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. **Immediately patch email templates** to point to **production** (`https://elizacloud.ai/...`) and remove any dev base URL in all transactional emails.
  2. Add **server-side guardrails**: if an email already exists, **do not create a new account** on link-click; force login + attach credit to existing identity.
  3. Add telemetry: log **email link environment**, **account created via email link**, and **duplicate-email detected** events.
  4. Write a one-off **account consolidation script** for duplicates (same email across envs) including agent ownership reconciliation.
  5. Publish a short status note (changelog/support) acknowledging the onboarding bug and that credits will be restored.
- **Potential Assignees**
  - **sam** (cloud/app integration, was already engaged)
  - **Odilitime** (triage + user support coordination)
  - **Cloud team/oncall** (routing + auth stack owner)

---

### 2) $5 welcome credit not applied (users see $1 / incorrect crediting)
- **Issue Title & ID**: Welcome credit misallocation ($5 promised, $1 credited / none credited) | **DISCORD-ELIZACLOUD-002**
- **Current Status**: **Open** (confirmed by user report; manual remediation in progress)
- **Impact Assessment**
  - **User Impact**: **High** (directly affects conversion and retention)
  - **Functional Impact**: **Partial** (core usage possible but paywall/trial expectations broken)
  - **Brand Impact**: **High** (trust/payment perception)
- **Technical Classification**
  - **Issue Category**: **Bug**
  - **Component Affected**: **Billing/Credits + Promotions + Account Events**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Billing ledger/credits, event-driven provisioning, idempotency
  - **Dependencies**: Depends on fix for duplicate-account routing (DISCORD-ELIZACLOUD-001) to prevent repeated mis-credit
  - **Estimated Effort (1-5)**: **3**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Make credit grant **idempotent** (e.g., promo applied once per verified email / user id).
  2. Ensure credit grant triggers on **successful verification/login completion**, not on environment-specific link click.
  3. Backfill: query signups during affected window and **auto-credit** eligible accounts; reconcile duplicates after merge.
  4. Add an automated test covering: signup → welcome email → get started → credit balance == $5.
- **Potential Assignees**
  - **sam** (cloud)
  - **Billing/infra owner** (if separate)
  - **Odilitime** (validation + user-facing follow-up)

---

### 3) ElizaCloud dashboard login “cycling” loop (login ↔ dashboard)
- **Issue Title & ID**: Dashboard session loop cycles between login and dashboard | **DISCORD-ELIZACLOUD-003**
- **Current Status**: **Open** (forwarded to cloud team; awaiting repro details)
- **Impact Assessment**
  - **User Impact**: **High** (blocks access for affected users)
  - **Functional Impact**: **Yes** (can’t use dashboard)
  - **Brand Impact**: **High**
- **Technical Classification**
  - **Issue Category**: **Bug**
  - **Component Affected**: **Web App Auth (cookies/session), Redirect logic, Possibly CORS/domain**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: Web auth, cookie domains/samesite, reverse proxy, env config
  - **Dependencies**: Could be exacerbated by prod/dev domain confusion; investigate alongside DISCORD-ELIZACLOUD-001
  - **Estimated Effort (1-5)**: **3**
- **Recommended Priority**: **P0**
- **Specific Actionable Next Steps**
  1. Collect repro package: browser, URL, HAR, console logs, cookie state; confirm whether user is landing on dev vs prod.
  2. Check cookie **Domain/SameSite/Secure** flags across `elizacloud.ai` and any subdomains.
  3. Add server-side detection for invalid session and show a **single** deterministic resolution path (clear session + reauth) rather than redirect loop.
  4. Add E2E test for login flow with redirect assertions.
- **Potential Assignees**
  - **Cloud team/oncall**
  - **sam**
  - **Odilitime** (triage + repro collection)

---

### 4) Payment flow blockers: VPN blocked, no easy recharge/transfer, missing “deposit address” option
- **Issue Title & ID**: Payment/recharge friction (VPN blocks checkout; no transfer; need per-account deposit address) | **DISCORD-ELIZACLOUD-004**
- **Current Status**: **Open** (identified as churn driver; solution proposed)
- **Impact Assessment**
  - **User Impact**: **High** (affects conversion from trial to paid; reported “customer loss”)
  - **Functional Impact**: **Partial** (core works; monetization impaired)
  - **Brand Impact**: **High** (users perceive platform as hard to pay for)
- **Technical Classification**
  - **Issue Category**: **UX / Feature Request** (with possible **Bug** depending on VPN policy)
  - **Component Affected**: **Billing/Payments, Risk/Fraud checks, Account Walleting**
  - **Complexity**: **Architectural change** (if adding deposit addresses/ledger flows)
- **Resource Requirements**
  - **Required Expertise**: Payments integration, compliance/risk, ledger accounting, crypto deposit monitoring
  - **Dependencies**: Product decision on supported rails; security review; accounting/ledger design
  - **Estimated Effort (1-5)**: **5**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Short-term: publish supported payment guidance; clarify VPN policy; add a **fallback** support-assisted payment path.
  2. Investigate VPN block root cause (payment provider restrictions vs app-level blocking) and implement graceful error messaging.
  3. Design proposal: **per-account deposit address** (custodial or smart-contract) + automatic crediting to internal balance.
  4. Add “transfer credits” between accounts (with limits) if legally/operationally acceptable.
- **Potential Assignees**
  - **sam** (cloud integration)
  - **Infra/billing engineer** (payments/ledger)
  - **Security reviewer** (deposit + crediting threat model)

---

### 5) Security matter raised privately (untriaged public report)
- **Issue Title & ID**: Unspecified security report pending private intake | **DISCORD-SECURITY-001**
- **Current Status**: **Open** (reported by memi; no documented triage outcome)
- **Impact Assessment**
  - **User Impact**: **Unknown → potentially Critical**
  - **Functional Impact**: **Unknown**
  - **Brand Impact**: **High** if mishandled
- **Technical Classification**
  - **Issue Category**: **Security**
  - **Component Affected**: **Unknown (needs intake)**
  - **Complexity**: **Unknown** (depends on report)
- **Resource Requirements**
  - **Required Expertise**: Security triage, incident response, responsible disclosure handling
  - **Dependencies**: Use existing security protocol (`SECURITY.md` exists in core repo history)
  - **Estimated Effort (1-5)**: **2** (triage) / TBD (fix)
- **Recommended Priority**: **P0** (triage immediately)
- **Specific Actionable Next Steps**
  1. Respond with the **official reporting channel** (security email/GitHub security advisory flow) and request minimal repro details.
  2. Create an internal tracking ticket with confidentiality controls.
  3. Confirm whether the report affects ElizaCloud, Babylon, or core framework; assign severity within 24 hours.
- **Potential Assignees**
  - **sam** (coordination)
  - **Odilitime** (community intake + routing)
  - **Designated security maintainer** (per SECURITY.md ownership)

---

### 6) Babylon.market: authentication + rewards regressions (Discord OAuth broken, username bug, reward claiming errors)
- **Issue Title & ID**: Babylon internal launch blockers (Discord OAuth broken; `@userid:priv` usernames; Twitter follow rewards failing) | **DISCORD-BABYLON-001**
- **Current Status**: **Open/Partially mitigated** (some fixes merged during testing; remaining items still reported)
- **Impact Assessment**
  - **User Impact**: **Medium → High** (depends on rollout; blocks account linking/rewards)
  - **Functional Impact**: **Partial** (game usable but onboarding/identity/rewards broken)
  - **Brand Impact**: **High** (public-facing product readiness)
- **Technical Classification**
  - **Issue Category**: **Bug**
  - **Component Affected**: **Babylon Auth/OAuth + Identity + Rewards API**
  - **Complexity**: **Moderate effort**
- **Resource Requirements**
  - **Required Expertise**: OAuth flows, backend API debugging, identity mapping, rate limits
  - **Dependencies**: Credentials/redirect URI correctness; environment config; reward provider APIs (X/Discord)
  - **Estimated Effort (1-5)**: **4**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. Establish a single “launch checklist” with pass/fail for: username creation, Discord link, reward claim, network switching.
  2. Add integration tests/mocks for reward claim endpoints; log structured errors with correlation IDs surfaced in UI.
  3. Fix username derivation rules to prevent leaking internal IDs (`@userid:priv`).
- **Potential Assignees**
  - **SYMBiEX** (was actively investigating Babylon issues)
  - **tcm390** (rapid fix/merge track record during Babylon test)
  - **puncar** (product owner / coordination)

---

### 7) Babylon.market: profile image upload failure (“Failed to update profile”) — regression watch
- **Issue Title & ID**: Profile image upload fails with “Failed to update profile” | **DISCORD-BABYLON-002**
- **Current Status**: **Resolved** (fix merged; confirmed by tester)
- **Impact Assessment**
  - **User Impact**: **Medium** (profile customization)
  - **Functional Impact**: **No**
  - **Brand Impact**: **Medium**
- **Technical Classification**
  - **Issue Category**: **Bug**
  - **Component Affected**: **Babylon Profile/Storage**
  - **Complexity**: **Simple fix**
- **Resource Requirements**
  - **Required Expertise**: Web upload/storage, API validation
  - **Dependencies**: None
  - **Estimated Effort (1-5)**: **1** (done)
- **Recommended Priority**: **P3** (post-fix monitoring only)
- **Specific Actionable Next Steps**
  1. Add a regression test for profile update endpoint (including image payload constraints).
  2. Ensure errors show actionable feedback (size/type limits).
- **Potential Assignees**
  - **tcm390**, **puncar**

---

### 8) elizaos/eliza PR risk: “plugin-bootstrap null checks” PR includes major undocumented architectural changes
- **Issue Title & ID**: PR scope creep risk: plugin-bootstrap null-check PR also adds request-context + message service refactor | **PR-6470 (elizaos/eliza)**
- **Current Status**: **Open (not merged)**; review flagged scope mismatch and rollback risk
- **Impact Assessment**
  - **User Impact**: **Medium** (could become High if merged and introduces regressions)
  - **Functional Impact**: **Partial** (intended crash fix is good; bundled changes raise risk)
  - **Brand Impact**: **Medium** (engineering discipline / stability perception)
- **Technical Classification**
  - **Issue Category**: **Bug + Architectural/Process**
  - **Component Affected**: **Plugin System (plugin-bootstrap), Core runtime settings, Server message service**
  - **Complexity**: **Complex solution** (because changes are entangled)
- **Resource Requirements**
  - **Required Expertise**: TypeScript core, runtime settings resolution, server messaging, release management
  - **Dependencies**: Align with already-merged RequestContext PR-6457 to avoid duplicate/conflicting implementations
  - **Estimated Effort (1-5)**: **3**
- **Recommended Priority**: **P1**
- **Specific Actionable Next Steps**
  1. **Split PR-6470** into (a) plugin-bootstrap null/undefined guards (fast merge) and (b) any additional features/refactors (separate PRs).
  2. Verify no duplication/conflict with **PR-6457** (already merged request context).
  3. Add targeted unit tests reproducing the original `Object.entries(null|undefined)` crash in providers.
- **Potential Assignees**
  - **anchapin** (PR author)
  - **0xbbjoker** (request-context expertise)
  - **core maintainers** (review/merge authority)

---

### 9) elizaos/eliza: Eliza character file & prompt engineering improvements
- **Issue Title & ID**: [Agent] Eliza Character File & Prompt Engineering | **#6447 (elizaos/eliza)**
- **Current Status**: **Open**
- **Impact Assessment**
  - **User Impact**: **Medium** (affects default agent quality)
  - **Functional Impact**: **No**
  - **Brand Impact**: **Medium** (first impressions of “Eliza” agent)
- **Technical Classification**
  - **Issue Category**: **UX / Feature Request**
  - **Component Affected**: **Agent Defaults / Prompts / Model selection**
  - **Complexity**: **Moderate effort** (iterative)
- **Resource Requirements**
  - **Required Expertise**: Prompt engineering, evaluation harness, model cost/perf tradeoffs
  - **Dependencies**: Planned PRs for message examples + model switch (Sonnet mentioned)
  - **Estimated Effort (1-5)**: **2**
- **Recommended Priority**: **P2**
- **Specific Actionable Next Steps**
  1. Land the two dependent PRs (message examples + Sonnet model switch) then baseline evaluations.
  2. Add a small regression suite (conversation scripts) to detect personality/quality drift.
- **Potential Assignees**
  - **borisudovicic** (issue author)
  - **Ben** (mentioned as having PRs)
  - **Stan ⚡** (prompt/provider standards familiarity)

---

## Conclusion

### (1) Top highest-priority issues to address immediately (next 24–72 hours)
1. **P0 — DISCORD-ELIZACLOUD-001**: Welcome email routes to dev → duplicate accounts + agent fragmentation  
2. **P0 — DISCORD-ELIZACLOUD-002**: $5 welcome credit not applied / miscredited  
3. **P0 — DISCORD-ELIZACLOUD-003**: Dashboard login loop (login ↔ dashboard cycling)  
4. **P0 — DISCORD-SECURITY-001**: Security report intake + severity triage (private)  
5. **P1 — DISCORD-ELIZACLOUD-004**: Payment conversion blockers (VPN checkout issues; missing recharge/transfer/deposit address)  
6. **P1 — DISCORD-BABYLON-001**: Babylon OAuth/identity/reward claim breakages (Discord OAuth, username bug, rewards failing)  
7. **P1 — PR-6470**: Prevent risky merge by splitting PR and aligning with already-merged request-context work

### (2) Patterns/themes suggesting deeper architectural problems
- **Environment separation failures (prod vs dev)**: Links and auth/session behavior suggest incomplete isolation and/or misconfigured canonical domains, impacting onboarding and login stability.
- **Identity/crediting idempotency gaps**: Promo credits and account creation appear not robust to repeated clicks, multi-env flows, or existing-email constraints.
- **Release/PR hygiene risk**: Large PRs with mismatched titles/descriptions increase regression probability and slow down safe delivery, especially around core runtime and messaging.

### (3) Process improvement recommendations
- **Add “canonical domain” enforcement**: Central config + CI checks that block sending any transactional email containing dev/staging URLs; runtime redirect to canonical host.
- **Make onboarding workflows idempotent by design**: Single source of truth for identity; explicit “account exists” branch; promo ledger entries keyed by (promo_id, user_id).
- **Introduce a Cloud E2E smoke suite** (runs per deploy): signup → email link → login → credit balance → create agent → dashboard access.
- **PR scope policy**: Enforce “one theme per PR” for core repos; require changelog-style “What changed” section; block merge if scope exceeds stated intent without re-scoping.
- **Security intake SLA**: Document a 24-hour triage SLA and ensure moderators always route reports to the official channel (per SECURITY.md) with a standard response template.