# User Feedback Analysis — 2026-03-14 (based on 2026-03-11 to 2026-03-13 sources)

## 1) Pain Point Categorization (Top recurring friction areas)

> **Note on quantification:** Activity volume was light. Counts/percentages below are based on ~10–12 distinct user-initiated questions/threads observed across Discord summaries for 2026-03-11 to 2026-03-13, so treat as directional.

### A. **Security / Community → Scam risk around token migration & “support”**
- **What users report (high severity, recurring):**
  - Users who missed the **AI16Z → elizaOS** migration deadline still ask for a way to migrate (e.g., “please help my migration”), then get exposed to impersonation/scam attempts.
  - A **fake support bot** routed users to a site requesting seed phrases (colabdesk); multiple moderators issued warnings.
  - A separate scam claimed **Discord requires wallet linking**.
- **Frequency:** ~30% of observed threads (migration + support-bot + wallet-linking scam).
- **Most affected:** newcomers / token holders returning after inactivity.

### B. **Technical Functionality → Plugin lifecycle & initialization race conditions (2.x architecture)**
- **What users report (high severity for builders):**
  - A concrete **race condition**: `plugin-sql` registers the DB adapter as a side-effect during `init()` while plugins init in parallel; `plugin-personality` may run before adapter exists.
  - Workaround in milaidy: manually pre-register `plugin-sql` before `initialize()`—seen as treating symptoms, not root cause.
- **Frequency:** ~10–15% (one major thread, but core-architecture impact is large).
- **Most affected:** developers building multi-plugin agents; anyone relying on DB-backed plugins.

### C. **Integration / Technical Functionality → Scheduling agents (cron/heartbeat) & Discord automation**
- **What users report (medium-high frequency, medium severity):**
  - Repeated need: “post on Discord on a schedule without manual triggers.”
  - Confusion over **which scheduling plugin to use by version**:
    - `plugin-cron` recommended for **2.x**
    - `plugin-heartbeat` recommended for **1.x**
  - Practical friction adapting examples from Spartan repo to older versions (e.g., users on **1.7.2**).
- **Frequency:** ~20% of threads.
- **Most affected:** builders shipping “always-on” agents and community managers.

### D. **Documentation → Version compatibility + “blessed” examples are scattered**
- **What users report (medium severity):**
  - Users rely on code pointers (e.g., Spartan’s `tsk_discord_post.ts`, DM utilities) but lack a single canonical “How to schedule a Discord poster in 1.x vs 2.x”.
  - Questions indicate missing docs for: plugin selection by version, minimal examples, migration path from 1.x → 2.x.
- **Frequency:** overlaps with (C); effectively ~20–30% of builder questions.

### E. **Communication / Community → Token migration policy clarity + tokenomics expectations**
- **What users report (medium severity, recurring):**
  - Migration closure wasn’t internalized: migration permanently closed **Feb 4, 2026** (after a 3‑month window), yet users still seek exceptions.
  - Tokenomics confusion: repeated questions about whether **Milady token** vs **elizaOS token** benefits from buybacks; “any token use case or still nothing?”
- **Frequency:** ~20% combined (migration policy + token value narrative).
- **Most affected:** token holders and new community members evaluating legitimacy/value accrual.

### F. **Integration / Engineering Process → Repo structure & composability questions (eliza-cloud-v2)**
- **What users report (lower frequency, but high leverage):**
  - Concern: why entire cloud repo lives in a `v2.0.0` branch instead of submodules / single-source-of-truth composition.
- **Frequency:** ~10%.
- **Most affected:** infra contributors; teams trying to vendor / extend cloud components.

### G. **Performance / Reliability (emerging) → “Always-on” ops patterns**
- **What users imply (early signal):**
  - Builders are implementing 1–3 hour cron loops (OpenClaw) and “agent wake-up” via cron triggers. That hints at reliability expectations (catch-up behavior, missed schedules, idempotency), though explicit perf complaints were limited this week.
- **Frequency:** implicit in scheduling threads.

---

## 2) Usage Pattern Analysis (actual vs intended)

### How users are actually using elizaOS
1. **Autonomous community ops agents** (Discord posting, scheduled updates, DMs)
   - Evidence: recurring requests for scheduled Discord posting; sharing Spartan examples like `tsk_discord_post.ts`.
2. **Agent discovery + monetization infrastructure**
   - Evidence: lightningprox’s public agent registry (`/api/agents/register`, `/api/agents`) with ratings, multi-rail payments (Lightning/Solana/x402), and auto-approval scoring.
3. **Token-integrated agent economics**
   - Evidence: a new plugin for **PumpFun tokenized agent buyback payments** on Solana; token buyback narrative around Milady cloud profits → elizaOS token buybacks.
4. **Content summarization/meta tooling**
   - Evidence: Jin’s video briefing system; Odilitime’s git-branch “story” tool.

### Mismatch vs intended usage (signals)
- Users treat Discord as the primary “support + docs” surface (asking versioning, architecture, scheduling), which suggests official docs aren’t meeting “time-to-first-agent” needs.
- Builders expect plugin initialization order guarantees (traditional framework expectation), but current architecture allows side-effect registration and parallel init hazards.

### Emerging / unexpected use cases worth supporting
- **Open agent registries** as first-class ecosystem components (capability slugs, skill discovery via `skill.md`, auto-approval pipelines).
- **Scheduled “wake-up” orchestration** as a core primitive (cron as de facto runtime heartbeat).
- **Payment rails & pricing per call** being embedded into agent discovery (registry-level economics).

### Feature requests that align with observed usage
- First-class **scheduler API** (version-stable) for recurring tasks + “run-once at startup” hooks.
- First-class **agent registry integration** (publish capabilities, verify endpoints, health checks).
- First-class **secure wallet isolation templates** for any agent with signing/spend capabilities.

---

## 3) Implementation Opportunities (solutions per major pain point)

### Pain Point A: Scams + migration confusion (High impact, low–medium effort)
**1) Ship an “Official Migration Status” banner + bot command**
- Implement:
  - A pinned message + `/migration` command in Discord that returns:
    - migration closed date (**Feb 4, 2026**),
    - “no seed phrase ever” rule,
    - official links only.
- Impact: high; reduces repeated questions and scam surface.
- Comparable approaches:
  - Large crypto projects (e.g., L2 token bridges) use pinned “canonical bridge link” banners + slash commands to reduce phishing.

**2) Add automated anti-phishing guardrails in Discord**
- Implement:
  - Auto-delete messages containing known phishing patterns (seed phrase requests, “wallet linking required”, known scam domains).
  - Auto-DM warning to users who mention “migration” in #discussion with a link to the official policy.
- Impact: high; protects newcomers.
- Difficulty: medium (Discord moderation bots + maintained blocklist).

**3) Create a public “Known Scams” page on elizaos.github.io**
- Implement:
  - Short, linkable page with screenshots/patterns (“Support Ticket bot”, “wallet linking”).
- Impact: medium-high; improves shareability outside Discord.
- Difficulty: low.

---

### Pain Point B: Plugin init race condition / lifecycle (High impact, medium–high effort)
**1) Introduce explicit dependency injection for infrastructure (DB adapter, clients)**
- Implement:
  - Make DB adapter a **required constructor argument** (as already proposed) instead of side-effect registration during parallel `init()`.
- Impact: very high (class of bugs removed).
- Difficulty: medium–high (breaking change, but contained with migration guides).
- Comparable approaches:
  - **Kubernetes controller-runtime** and many DI-first systems avoid side effects in “init”; dependencies are wired explicitly before controllers start.

**2) Add a deterministic plugin initialization graph**
- Implement:
  - Plugins declare `provides` / `requires` and runtime topologically sorts init order; fail fast on missing providers.
- Impact: high; scales to more plugins than “manual pre-register”.
- Difficulty: high, but aligns with 2.0 refactor goals.
- Comparable approaches:
  - VS Code extensions have activation events and explicit dependencies to prevent ordering surprises.

**3) Provide a compatibility shim + deprecation window**
- Implement:
  - Continue supporting side-effect registration short-term, but emit warnings and a deadline to migrate.
- Impact: medium; reduces immediate breakage.
- Difficulty: medium.

---

### Pain Point C/D: Scheduling + version confusion (High impact, low–medium effort)
**1) Publish “Scheduling Cookbook” for 1.x and 2.x (single page)**
- Include:
  - “Post to Discord every N minutes/hours” examples
  - `plugin-cron` vs `plugin-heartbeat` decision table
  - A minimal repo or gist derived from Spartan `tsk_discord_post.ts`
  - Notes for v1.7.2 adaptation pitfalls
- Impact: high (recurring ask).
- Difficulty: low.
- Comparable approaches:
  - Home Assistant’s automation docs provide copy/paste recipes by common scenario (“every hour do X”).

**2) Create a versioned “Blessed Examples” repo**
- Implement:
  - `examples/discord-scheduler/1.x` and `examples/discord-scheduler/2.x`
  - CI to ensure examples run.
- Impact: high.
- Difficulty: medium.

**3) Add a runtime “capabilities check” at startup**
- Implement:
  - On boot, print: detected version + missing required plugins + recommended install commands.
- Impact: medium-high.
- Difficulty: medium.

---

### Pain Point E: Tokenomics & expectation setting (Medium impact, low effort)
**1) Make tokenomics FAQ explicit and non-ambiguous**
- Implement:
  - “No direct token utility currently” (if still true)
  - “Milady cloud profits → buybacks of elizaOS token (not Milady token)”
  - What milestones change token utility, if any
- Impact: medium-high (reduces repeat questions).
- Difficulty: low.

**2) Add a “Status & Shipping” changelog channel + weekly cadence**
- Implement:
  - Summarize: Eliza 2.0 alpha status, Milady app ETA (“~2 weeks from Mar 12”), Babylon rollout.
- Impact: medium.
- Difficulty: low.

---

### Pain Point F: Repo structure composability (Medium impact, medium effort)
**1) Document the branching/submodule decision and intended contributor workflow**
- Implement:
  - Rationale: why `v2.0.0` branch contains full repo; roadmap to modularization (if planned).
- Impact: medium.
- Difficulty: low.

**2) Move toward a mono-repo package graph or submodules with pinned versions**
- Implement:
  - Start with “extractable packages” (cloud services, embedding service) and publish versioned artifacts.
- Impact: medium-high for serious adopters.
- Difficulty: medium–high.
- Comparable approaches:
  - Many CNCF projects publish versioned Helm charts / modules rather than “branch as release artifact”.

---

## 4) Communication Gaps (expectations vs reality)

### Recurring expectation mismatches
- **“Migration might still be possible” vs reality:** migration is closed; users still attempt late migration and become scam targets.
- **“Token utility exists now” vs reality:** explicit answer given: no direct token use case currently; value accrual framed via cloud profits → buybacks.
- **“Plugins init deterministically” vs reality:** parallel init plus side-effect registration can break dependency availability.

### Recurring questions indicating onboarding/documentation gaps
- “How do I schedule my agent to post on Discord?”
- “Which plugin works on my version (1.7.2 vs 2.x)?”
- “What’s the official migration/support path and how do I avoid scams?”
- “How does agent discovery/registration work?” (e.g., required fields: capability slug, payment rail, price per call, endpoint)

### Specific improvements to align expectations
- Put **migration closed** and **anti-seed-phrase** warnings in:
  - Discord server welcome/onboarding
  - Docs homepage banner
  - A slash command response
- Provide a **version matrix** prominently in docs:
  - “If you are on 1.x use X; on 2.x use Y”
- Architecture docs should state explicitly:
  - “Plugins must not rely on side effects during parallel init” (until fixed)
  - Recommended pattern: explicit dependency wiring

---

## 5) Community Engagement Insights

### Power users observed (and their needs)
- **Odilitime**: driving runtime refactor, security posture (wallet isolation), code example sharing; needs structured feedback on proposals (HackMD deadline-driven).
- **lightningprox**: building open agent registry; needs standardized discovery metadata (e.g., `skill.md`) and possibly official registry interoperability.
- **Jin**: building video briefing/meta tooling; needs predictable access to structured discussion data and highlight-worthy changelogs.
- **AgenticCaesar**: implementing cron-based autonomy; needs stable scheduling primitives and guidance for long-running agents.
- **s / sb / satsbased**: answering user questions; needs better canonical docs to reduce repetitive support load.

### Newcomer questions indicating friction
- Late migration help requests (high-risk due to scams).
- Confusion about “wallet linking requirement” due to phishing.
- Basic “how do I schedule” and “which version/plugin” questions.

### Converting passive users into contributors
- Create “good first issue” sets around:
  - Docs cookbooks (scheduling, registry integration, security checklist)
  - Example repos with CI
  - Discord moderation/bot rule contributions (phishing regex, domain blocklists)
- Run a weekly “office hours” thread:
  - Collect 3 questions, answer publicly, turn into docs PRs.

---

## 6) Feedback Collection Improvements

### Effectiveness of current channels
- **Discord** is effective for rapid support, but feedback is:
  - unstructured,
  - repeated (same questions),
  - hard to convert into trackable issues/PRs.

### Suggestions for more structured, actionable feedback
1. **Add an intake form + GitHub issue templates**
   - Templates for: “Scheduling/Automation”, “Plugin lifecycle bug”, “Security/Scam report”, “Docs request”.
2. **Weekly micro-survey pinned in Discord**
   - 3 questions max (e.g., “Which version are you on?”, “Top blocker this week?”, “Did you hit a scam attempt?”).
3. **Create a single “Known Issues & Workarounds” page**
   - Include: plugin init ordering workaround, scheduling patterns, migration closure policy.

### Underrepresented segments
- Users deploying elizaOS in production environments outside Discord-centric use (web apps, internal tooling) — little direct feedback captured this week.
- Non-crypto users (who may value agent automation but are turned off by token/scam noise) — not visibly represented in these threads.

---

## Prioritized High-Impact Actions (next 2–4 weeks)

1) **Ship anti-scam + migration clarity package** (Discord `/migration` command, pinned banner, “Known Scams” docs page, moderation bot rules).  
2) **Publish a versioned Scheduling Cookbook + runnable examples** (Discord scheduled posting for 1.x and 2.x; explicitly cover `plugin-cron` vs `plugin-heartbeat`, include Spartan-derived snippet references).  
3) **Resolve plugin initialization ordering via explicit dependencies** (DB adapter as constructor argument + `requires/provides` init graph; add deprecation warnings for side-effect registration).  
4) **Create a public “Status & Shipping” weekly update** (Milady app ETA, Eliza 2.0 alpha progress, Babylon rollout) to reduce speculation-driven questions.  
5) **Stand up structured feedback intake** (GitHub templates + Discord weekly micro-survey) to convert recurring Discord questions into trackable, prioritized work.