## Issue Triage — 2026-02-08

### 1) ElizaCloud welcome email routes users to **dev** and creates duplicate accounts / missing $5 credit
- **Issue Title & ID:** Welcome email misroutes to dev → duplicate accounts + $5 credit not applied (DISC-ELIZACLOUD-ONBOARD-001)
- **Current Status:** Reported in Discord (2026-02-05/06). Triage acknowledged; user asked to DM email for manual consolidation; no public fix confirmed.
- **Impact Assessment:**
  - **User Impact:** **Critical** (hits all new signups clicking email CTA; also affects existing users who click the link again)
  - **Functional Impact:** **Yes** (breaks onboarding + fragments agents/accounts; credit promise fails)
  - **Brand Impact:** **High** (promised credit not honored; “account overwrite” perception)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Cloud (ElizaCloud auth/onboarding), Email link generation, Account + billing/credits
  - **Complexity:** **Moderate effort** (routing + idempotent claim + account merge rules)
- **Resource Requirements:**
  - **Required Expertise:** Web/auth (OAuth/session), email templating, backend account/credit ledger, prod/dev environment config
  - **Dependencies:** Email template/ESP config; account model constraints (unique email); credit issuance pipeline
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. **Immediately disable or hotfix** the welcome-email “Get started” link to always target **https://elizacloud.ai** (prod).
  2. Add **environment guardrails**: refuse creating accounts on dev from production email campaigns; stamp links with environment + signature.
  3. Make $5 credit claim **idempotent** (single grant per email/user) and log all grants with correlation IDs.
  4. Implement **account consolidation workflow** (admin tool): merge agents/projects by verified email, preserve balances/usage history.
  5. Write regression tests: “click CTA twice” and “existing user clicks CTA” should not create a second account.
- **Potential Assignees:** **sam** (cloud/backend), **Odilitime** (triage + coordination), Cloud team on-call; involve billing/credits owner.

---

### 2) ElizaCloud dashboard “login ↔ dashboard” cycling loop
- **Issue Title & ID:** Dashboard auth/session loop (login → dashboard → login) (DISC-ELIZACLOUD-AUTH-002)
- **Current Status:** Reported in Discord (2026-02-06). Forwarded to cloud team; awaiting repro + fix.
- **Impact Assessment:**
  - **User Impact:** **High** (blocks affected users completely)
  - **Functional Impact:** **Yes** (cannot access dashboard)
  - **Brand Impact:** **High** (looks like downtime)
- **Technical Classification:**
  - **Issue Category:** Bug
  - **Component Affected:** Cloud dashboard, auth cookies/session, redirects, possibly CDN/cache headers
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Frontend routing, auth/session handling, cookie/SameSite, API gateway
  - **Dependencies:** Ability to reproduce (browser, region, extensions, VPN); logs/telemetry
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0**
- **Specific Actionable Next Steps:**
  1. Capture affected user environment: browser/version, extensions, VPN, region, timestamp, HAR file.
  2. Add/inspect server logs for repeated 302s, session refresh failures, CSRF mismatch.
  3. Verify cookie domain/SameSite/secure flags across **elizacloud.ai** and any subdomains.
  4. Add a health diagnostic panel (“auth status”, token expiry, API reachability) to reduce support cycles.
- **Potential Assignees:** Cloud frontend owner + **sam**; support coordination by **Odilitime**.

---

### 3) Security concern: malicious code in “skills” + setup vulnerabilities (unverified report)
- **Issue Title & ID:** Potential malicious code in skills / setup path (DISC-SEC-SKILLS-003)
- **Current Status:** Raised in Discord (2026-02-07) without indicators-of-compromise (IOCs) or repo references; not yet converted into a tracked security ticket.
- **Impact Assessment:**
  - **User Impact:** **Critical** if real (supply-chain risk; arbitrary code execution)
  - **Functional Impact:** **Partial** (depends on distribution vector; could become full compromise)
  - **Brand Impact:** **High** (trust + ecosystem safety)
- **Technical Classification:**
  - **Issue Category:** **Security**
  - **Component Affected:** Plugin/skills ecosystem, installation/bootstrap scripts, registry/distribution channels
  - **Complexity:** **Complex solution** (needs investigation + policy + tooling)
- **Resource Requirements:**
  - **Required Expertise:** AppSec, supply-chain security (npm/pip/cargo), CI hardening, code signing, sandboxing
  - **Dependencies:** Obtain concrete evidence (links, commits, packages, hashes); clarify what “skills” refers to in elizaOS context (repo, registry, or third-party packs)
  - **Estimated Effort (1–5):** **5** (investigation may be quick; remediation program is larger)
- **Recommended Priority:** **P0** (triage immediately; remediation priority depends on findings)
- **Specific Actionable Next Steps:**
  1. Open a private security ticket and request details from reporter (IOCs, repo/package names, logs).
  2. Audit recent/most-installed skills/plugins: check for postinstall scripts, obfuscated code, unexpected network calls.
  3. Add baseline controls: lockfiles, provenance (SLSA), dependency scanning, signed releases, allowlist/verified publisher concept for registry.
  4. Document a responsible disclosure process and a security contact path.
- **Potential Assignees:** Security lead (TBD), **Odilitime** (triage), maintainers of plugin registry; consider involving **anchapin**/**0xbbjoker** for codebase familiarity.

---

### 4) Agent crash: `Object.entries` null/undefined in plugin-bootstrap providers (fix exists but PR scope concerns)
- **Issue Title & ID:** Prevent `Object.entries` crash in plugin-bootstrap providers (PR elizaos/eliza **#6470**)
- **Current Status:** PR opened (not merged). Reviewer tooling flagged major scope creep (bundled request-context + message service changes).
- **Impact Assessment:**
  - **User Impact:** **High** (agent crash during normal messaging flows; “IGNORE action” symptom)
  - **Functional Impact:** **Yes** (runtime instability)
  - **Brand Impact:** **High** (crashes on basic usage)
- **Technical Classification:**
  - **Issue Category:** Bug (with additional architectural changes bundled)
  - **Component Affected:** Plugin system (`plugin-bootstrap`), Core runtime settings resolution, Server message service
  - **Complexity:** **Moderate effort** (if split); **Architectural change** (if merged as-is)
- **Resource Requirements:**
  - **Required Expertise:** TypeScript runtime, providers/context formatting, release hygiene (splitting PRs)
  - **Dependencies:** Decide merge strategy: split into safe bugfix PR + separate feature PR(s)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P0** (but **do not** merge the large bundle without split/review gates)
- **Specific Actionable Next Steps:**
  1. Ask author to **split PR #6470** into:
     - (A) minimal plugin-bootstrap null guards (crash fix)
     - (B) request-context feature (core)
     - (C) message service refactor / event emission changes (server)
  2. Fast-track review/merge for (A) with targeted regression tests.
  3. Run CI + minimal runtime smoke tests: start agent, send messages, verify no crash and context providers render safely.
  4. For (B), require an ADR: how per-user settings interact with multi-tenant isolation guarantees.
- **Potential Assignees:** **anchapin** (author), core maintainer reviewer (**lalalune** or runtime owner), with optional review by **borisudovicic** (infra context).

---

### 5) Babylon.market launch stability: broken Discord OAuth linking / username bug / rewards claiming errors
- **Issue Title & ID:** Babylon.market auth + rewards regressions (DISC-BABYLON-LAUNCH-004)
- **Current Status:** Multiple issues reported (2026-02-05). A production fix was “pushed and merged” during discussion, but no confirmation that **all** items are resolved (only later profile upload bug was confirmed fixed on 2026-02-06).
- **Impact Assessment:**
  - **User Impact:** **High** (onboarding + incentives are core to product adoption)
  - **Functional Impact:** **Partial to Yes** (OAuth linking and rewards are key flows)
  - **Brand Impact:** **High** (launch quality)
- **Technical Classification:**
  - **Issue Category:** Bug / UX
  - **Component Affected:** Babylon backend APIs, OAuth integrations (Discord), rewards service, username assignment
  - **Complexity:** **Moderate effort**
- **Resource Requirements:**
  - **Required Expertise:** Web auth (OAuth), backend API debugging, database constraints for usernames, reward ledger correctness
  - **Dependencies:** Access to prod logs; reproducible test accounts; rate limits for Discord/Twitter APIs
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Convert each symptom into a tracked bug with acceptance criteria:
     - “@userid:priv” username assignment
     - Discord OAuth link flow broken
     - Twitter follow reward claim error
  2. Add end-to-end test checklist for launch: signup → username → link Discord → claim reward.
  3. Instrument rewards with auditable events (request, validation, grant, failure reason).
  4. Provide a temporary “status page” / known issues banner in-app to reduce support load.
- **Potential Assignees:** **tcm390** (recent Babylon fix velocity), **SYMBiEX** (triage/coord), **puncar** (product owner).

---

### 6) Milaidy repo: unclear contribution workflow + PR backlog risk (3 PRs waiting)
- **Issue Title & ID:** Milaidy contribution process + PR review bottleneck (DISC-MILAIDY-PROC-005)
- **Current Status:** 3 PRs submitted by community contributor; contributor paused further work awaiting guidance (2026-02-07).
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects speed to production; not yet wide user base)
  - **Functional Impact:** **Partial** (blocks community throughput)
  - **Brand Impact:** **Medium** (signals maintainer responsiveness)
- **Technical Classification:**
  - **Issue Category:** Documentation / Process
  - **Component Affected:** Milaidy repository governance, CI, review process
  - **Complexity:** **Simple fix**
- **Resource Requirements:**
  - **Required Expertise:** Repo maintainership, OSS workflow (issues/PR templates), CI basics
  - **Dependencies:** None
  - **Estimated Effort (1–5):** **2**
- **Recommended Priority:** **P1**
- **Specific Actionable Next Steps:**
  1. Add `CONTRIBUTING.md` with: issue-first policy, labeling, PR size guidance, review SLA, how to tag issues in PRs.
  2. Add GitHub templates: bug report, feature request, PR checklist (tests, reproduction steps).
  3. Triage and respond to the 3 PRs within 24–48h: merge, request changes, or close with rationale.
- **Potential Assignees:** **s** (project lead), plus a maintainer delegate (e.g., **Wes** as community maintainer if trusted).

---

### 7) Milaidy: Mac-native .app production readiness + plugin connector ports (delivery risk)
- **Issue Title & ID:** Milaidy Mac app packaging + connector/plugin parity with OpenClaw (DISC-MILAIDY-ENG-006)
- **Current Status:** In active development; “needs a couple days” noted; bugs remain; recruiting testers (2026-02-07).
- **Impact Assessment:**
  - **User Impact:** **Medium** (new product; early adopters)
  - **Functional Impact:** **Partial** (core promise is “simple .app” + connectors; incomplete blocks launch)
  - **Brand Impact:** **Medium** (launch polish matters)
- **Technical Classification:**
  - **Issue Category:** Feature / Bug (stabilization)
  - **Component Affected:** Desktop packaging, plugin system integration, connectors
  - **Complexity:** **Complex solution** (multi-surface: app packaging + runtime + plugins)
- **Resource Requirements:**
  - **Required Expertise:** macOS app packaging/signing, TypeScript runtime integration, plugin architecture, QA
  - **Dependencies:** Stable plugin API; connector implementations; CI artifacts for Mac builds
  - **Estimated Effort (1–5):** **4**
- **Recommended Priority:** **P2** (unless tied to a hard public launch date)
- **Specific Actionable Next Steps:**
  1. Define “production-ready” checklist: install/uninstall, updates, logs, crash reporting, permissions.
  2. Stand up nightly signed builds + basic smoke tests.
  3. Prioritize top connectors and defer long-tail ports to post-MVP.
- **Potential Assignees:** **s** (lead), community testers (Wes, Maarmapa), plus a Mac build/release owner (TBD).

---

### 8) Core UX quality: Eliza character file & prompts need iteration
- **Issue Title & ID:** [Agent] Eliza Character File & Prompt Engineering (GitHub elizaos/eliza **#6447**)
- **Current Status:** **OPEN**
- **Impact Assessment:**
  - **User Impact:** **Medium** (affects conversational quality broadly)
  - **Functional Impact:** **No** (doesn’t block core runtime)
  - **Brand Impact:** **Medium** (first impressions)
- **Technical Classification:**
  - **Issue Category:** UX / Feature improvement
  - **Component Affected:** Agent configuration (character file), model selection/testing
  - **Complexity:** **Moderate effort** (iteration + evaluation)
- **Resource Requirements:**
  - **Required Expertise:** Prompt engineering, eval design, model cost/perf tradeoffs
  - **Dependencies:** Pending PRs mentioned in issue (message examples; model switch to Sonnet)
  - **Estimated Effort (1–5):** **3**
- **Recommended Priority:** **P2**
- **Specific Actionable Next Steps:**
  1. Merge/land the message-examples PR(s) referenced in issue; define a repeatable eval script.
  2. A/B test current model vs Sonnet with a small fixed conversation suite.
  3. Add “tone/guardrails” acceptance criteria (refusal style, tool-use boundaries, verbosity).
- **Potential Assignees:** **borisudovicic** (issue author), **lalalune** (core direction), plus anyone owning eval tooling.

---

### 9) Large “next” / v2 branches: high-risk integration and reviewability (potential release management issue)
- **Issue Title & ID:** Oversized PRs and parallel “next/V2.0.0” branches increase integration risk (GitHub PR elizaos/eliza **#6474**, **#6351**, **#6216**)
- **Current Status:** PRs open (large diffs); not merged.
- **Impact Assessment:**
  - **User Impact:** **Medium** now; **High** if merged without staged rollout (risk of regressions)
  - **Functional Impact:** **Partial** (blocks maintainers; slows releases)
  - **Brand Impact:** **Medium** (shipping instability / long-lived broken branches)
- **Technical Classification:**
  - **Issue Category:** Process / Architecture
  - **Component Affected:** Core framework (multi-language runtime), CLI/cloud integration, repo structure
  - **Complexity:** **Architectural change**
- **Resource Requirements:**
  - **Required Expertise:** Release engineering, architecture, CI, migration planning
  - **Dependencies:** ADRs, feature flags, incremental merge plan
  - **Estimated Effort (1–5):** **5**
- **Recommended Priority:** **P1** (for maintainers: create a merge strategy; not necessarily to “finish all features” this sprint)
- **Specific Actionable Next Steps:**
  1. Require an **integration plan**: milestones, what merges first, compatibility guarantees, deprecation timeline.
  2. Enforce PR size limits or “stacked PR” approach; mandate per-package CI + smoke tests.
  3. Add feature flags / compatibility shims to avoid breaking plugin ecosystem.
- **Potential Assignees:** **lalalune** (author), core maintainers + CI/release owner.

---

## Summary — Top Highest-Priority Issues to Address Immediately (next 24–72h)
1. **(P0)** ElizaCloud welcome email misrouting to dev causing duplicate accounts + missing $5 credit (DISC-ELIZACLOUD-ONBOARD-001)  
2. **(P0)** ElizaCloud dashboard auth loop (DISC-ELIZACLOUD-AUTH-002)  
3. **(P0)** Potential malicious code in skills / setup vulnerabilities — start security triage + evidence gathering (DISC-SEC-SKILLS-003)  
4. **(P0)** plugin-bootstrap crash fix path: split/review/merge minimal null-guard fix from PR #6470 (elizaos/eliza #6470)  
5. **(P1)** Babylon.market launch blockers: Discord OAuth linking, username bug, rewards claim errors (DISC-BABYLON-LAUNCH-004)  
6. **(P1)** Milaidy contribution workflow + PR review bottleneck (DISC-MILAIDY-PROC-005)  
7. **(P1)** Release management risk from oversized “next/V2” PRs; define staged merge plan (PR #6474/#6351/#6216)

## Patterns / Themes Suggesting Deeper Architectural Problems
- **Environment separation failures (prod vs dev):** The ElizaCloud email CTA routing indicates missing hard boundaries and safety checks between environments.
- **Auth/session fragility:** Both the onboarding duplication and dashboard cycling point to insufficient end-to-end auth testing and weak observability around session state.
- **Oversized change sets:** Multiple large PRs and scope creep in “bugfix” PRs reduce review quality and increase regression risk.
- **Supply-chain attack surface:** Concerns about “skills” safety plus interest in running untrusted code (sprites.dev sandboxes) highlights a growing need for a formal plugin/security model.

## Recommendations — Process Improvements
1. **Introduce a P0 Cloud Onboarding Test Suite:** Automated browser-based E2E covering signup → email CTA → credit grant → dashboard access (run on every deploy).
2. **Enforce PR Hygiene:** Require PR templates with “Scope” + “Split checklist”; block merges when title/description do not match changed surface area.
3. **Security Intake + Verification Pipeline:** Private disclosure channel, triage SLA, and lightweight “verified publisher” / signing plan for plugins/skills distribution.
4. **Observability Defaults:** Standardize correlation IDs across email → signup → credit grant → first agent creation; add dashboards/alerts for anomalies (duplicate accounts per email, credit grant failures).
5. **Launch Readiness Gates for Babylon/Milaidy:** Minimal acceptance criteria + smoke tests before “production-ready” announcements (auth linking, rewards, profile updates, packaging/install).