## User Feedback Analysis — 2026-04-08 (based on 2026-04-07 community + GitHub activity)

### Data sources reviewed
- Discord: `💬-discussion` + `coders` channel excerpts (Apr 7)
- GitHub: new issues/PRs referenced in the Apr 1–May 1 activity snapshot and Apr 7 daily summary

---

## 1) Pain Point Categorization (top recurring 5–7)

> Note: This day’s Discord sample is heavily skewed by token-price discussion; technical feedback is concentrated in a few high-signal messages and several GitHub issues/PR reviews.

### 1. Community — Signal-to-noise collapse in main discussion (High frequency, High severity)
**What users experience**
- The `💬-discussion` channel is dominated by ELISA price speculation and negative sentiment (reported as the majority of conversation; qualitatively >80% of visible thread content).
- Multiple scammer callouts occurred (at least 2 accounts flagged by `airanna21`), creating a trust/safety burden for regulars and mods.
- Product/dev updates get buried (e.g., deployment success, ai-news work).

**Examples**
- Users repeatedly cite “95% decline” and argue about token supply vs. comps (Ai16z), crowding out support questions.
- “Multiple users were flagged as scammers” during the same period.

---

### 2. Integration — X/Twitter login failure in `plugin-twitter` (Medium frequency, High severity)
**What users experience**
- `dave_24736` reports `eliza-agent` cannot log in to X: “page not found” after multiple retries, including cookie-based attempts.
- Debugging requires version details, implying compatibility drift across versions.

**Examples**
- Discord coders: “unable to log in to X (formerly Twitter), receiving a page not found error after multiple retries even when using cookies.” (`odilitime` asks for ElizaOS + plugin-twitter versions)

---

### 3. Technical Functionality / DX — `elizaos create` fails on macOS due to Bun dependency behavior (Medium frequency, High severity)
**What users experience**
- GitHub issue #6704: `elizaos create <project>` fails with “Bun’s postinstall script was not run” on macOS (Apple Silicon), leaving no project directory because the CLI cleans up on failure.
- Root cause: `bun` listed as a runtime dependency, triggering broken postinstall expectations in certain install paths.

**Impact**
- Blocks first-run onboarding for a key segment (macOS + bun users), and failure mode is destructive (removes generated project).

---

### 4. Documentation / Project Navigation — Unclear project status & contribution entry points (Medium frequency, Medium severity)
**What users experience**
- Users ask whether “Elizok” is still active and where to contribute; answer is ad-hoc (“on GitHub”) without a canonical pointer (repo link, issues labeled “good first issue,” maintainer status).

**Examples**
- `ipadkid.eth`: “Is anything going on with Elizok still? If so I’d love to contribute.” → `odilitime`: “available on GitHub” (no structured onboarding path shared).

---

### 5. Technical Functionality / Reliability — ai-news regeneration needs fallbacks + credit monitoring (Medium frequency, Medium severity)
**What users experience**
- `dankvr` is actively rebuilding ai-news data with explicit plans for:
  - fallback models
  - monitoring credit usage
- This implies prior instability/cost surprises (credits) and brittle single-model dependence.

**Examples**
- “plans to implement fallback models and improved monitoring of credit usage.”

---

### 6. Technical Functionality / Quality — Large plugin PRs lack persistence/tests and have unsafe edge cases (Medium frequency, High severity for maintainability)
**What users experience**
- PR #6701 (`plugin-mnemopay`) reviewed as not merge-ready due to:
  - no persistence (state wiped on restart)
  - NaN reputation corruption risk
  - unsafe null casts (possible runtime crashes)
  - ambiguous action triggers (keyword conflicts)
  - unbounded memory growth
  - no tests

**Impact**
- Increases maintenance load and risks reputational damage if “official” plugins behave unreliably.

---

### 7. Platform Compatibility — Windows checkout friction due to generated artifacts (Low frequency, Medium severity)
**What users experience**
- `plugin-openrouter` PR: fixes “PGlite memory artifacts blocking Windows Git checkouts.”
- Suggests repo hygiene / `.gitignore` gaps or build artifact leakage impacting Windows contributors.

---

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

### Observed “actual usage”
1. **One-click hosted deployment is emerging as a primary onboarding path**
   - `jgonly1_89829` successfully deploys first agent on **Hatcher.host** with Groq integration, praising dashboard + live logs.
   - This indicates many users prefer *platform-style deployment* over local scaffolding (especially when local CLI is fragile).

2. **Social connector usage (X/Twitter, Discord) is a core expectation**
   - The X login break shows people are running agents as social operators; authentication stability is critical.

3. **Agents are being used for crypto/marketplace automation and “agent economies”**
   - GitHub issues propose marketplace plugins (MAXIA), token safety checks (SafeAgent), and capability token enforcement (SINT).
   - Even when token chat is noisy, it’s consistent with a user base building finance-adjacent agents and expecting guardrails.

4. **Data pipeline + content operations (ai-news) are real workloads**
   - “Regenerate a week of AI news” + fallback models/credit monitoring indicates production-like batch jobs, not just chat demos.

### Misalignment with intended/assumed usage
- The CLI (`elizaos create`) appears to be a main intended entry point, but real adoption may be shifting toward hosted deployment (Hatcher.host) due to smoother UX.
- Plugin ecosystem contributions are high-energy, but maintainership expectations (tests, persistence, safety) aren’t consistently enforced upfront.

### Feature requests that align with real usage
- **Delegation chains / scoped authority / spend limits** (GitHub issue) aligns directly with:
  - marketplace + trading plugins
  - social posting tools
  - broader “trust infrastructure” narrative

---

## 3) Implementation Opportunities (2–3 concrete solutions per major pain point)

### A) Community noise + scam risk in `💬-discussion`
**Proposals (prioritized)**
1. **Create (or enforce) separate channels for token talk and trading**
   - High impact, low effort: move price/speculation to `#token-chat` and add a pinned rule + automated reminders.
   - Similar approach: many OSS+token projects (e.g., DeFi protocols) isolate “markets” into dedicated channels to preserve support bandwidth.

2. **Add lightweight anti-scam automation**
   - Medium impact, medium effort:
     - enable link-scanning, suspicious-domain auto-delete
     - require account age / verification for posting links
     - add a `#report-scams` workflow + mod macro responses

3. **Weekly “Build & Ship” digest pinned to discussion**
   - Medium impact, low effort: a single pinned post summarizing shipping progress reduces the sense that “nothing is happening” (which fuels doomposting).

---

### B) X/Twitter login failures (plugin-twitter)
**Proposals (prioritized)**
1. **Publish a version-compatibility matrix + diagnostic command**
   - High impact, low effort:
     - `elizaos doctor` prints core version, plugin-twitter version, connector mode, auth method
     - include known breakpoints (X UI changes, cookie formats)

2. **Implement a resilient auth strategy (headless + refresh)**
   - High impact, medium effort:
     - support OAuth where possible, else standardized cookie import + automated validity checks
     - fail with explicit actionable errors (not “page not found” loops)
   - Similar approach: Playwright-based login flows + “session health checks” used in automation projects.

3. **Add an integration test that runs against a mocked X flow**
   - Medium impact, medium effort:
     - contract-test the login sequence and selectors to catch “page not found” regressions earlier.

---

### C) `elizaos create` macOS Bun failure (Issue #6704)
**Proposals (prioritized)**
1. **Remove `bun` from runtime dependencies and add preflight checks**
   - High impact, low-medium effort:
     - shift to `@types/bun` as devDependency as proposed
     - CLI should detect bun install mode and warn before running build steps.

2. **Stop deleting the generated project directory on failure**
   - High impact, low effort:
     - leave artifacts + write a `FAILED_SETUP.md` with next steps, so users can recover quickly.

3. **Provide an “--no-build” / “--skip-postinstall” scaffolding option**
   - Medium impact, medium effort:
     - generate project, install deps, but don’t build—useful for constrained environments/CI.

(Comparable patterns: Create React App / Next.js CLIs generally keep generated directories and print recovery steps rather than cleaning up destructively.)

---

### D) ai-news pipeline reliability (fallbacks + credit monitoring)
**Proposals (prioritized)**
1. **Add “budget + burn-rate” telemetry**
   - High impact, low-medium effort:
     - log per-run spend estimates
     - alert thresholds (daily cap, per-episode cap)
     - store in a simple table / JSON log + dashboard chart

2. **Implement automatic model failover policy**
   - High impact, medium effort:
     - primary model → fallback model on error/credit exhaustion
     - record failover events so quality regressions are traceable

3. **Add a reproducible replay mode**
   - Medium impact, medium effort:
     - rerun a known date range deterministically for debugging and cost prediction.

---

### E) Plugin quality gate (large PRs without persistence/tests)
**Proposals (prioritized)**
1. **Introduce a “Plugin Acceptance Checklist” enforced by CI**
   - High impact, medium effort:
     - required: tests or minimal harness, persistence story (or explicit “ephemeral” label), null safety, bounded storage, action trigger disambiguation
   - Similar approach: Homebrew / Kubernetes maintain contribution templates and CI checks that block merges without required metadata/tests.

2. **Create a “sandbox registry tier”**
   - Medium-high impact, medium effort:
     - plugins can be listed as *experimental* with warnings until they meet stability requirements.

3. **Provide reference implementations for common needs**
   - Medium impact, medium effort:
     - persistence adapter examples (SQLite/PGLite)
     - memory eviction patterns
     - action routing best practices (avoid keyword collisions)

---

## 4) Communication Gaps (expectations vs reality)

### Gap 1: “Is the project active?” perception driven by token chat dominance
- When most visible conversation is price doomposting, newcomers infer lack of development—even though multiple substantive PRs/issues exist (delegation chains, security grade, marketplace plugins).
**Fix**
- Pin a weekly engineering status + “How to contribute” quick links in high-traffic channels.

### Gap 2: Unclear ownership/status for subprojects (e.g., Elizok)
- Users want to contribute but don’t know if it’s maintained, where the repo is, or what help is needed.
**Fix**
- Add a “Project Directory” page: repo links, maintainers, status (active/paused), and `good first issue` lists.

### Gap 3: Plugin + core version drift
- The X login issue immediately turns into “which versions are you on?”, indicating recurring compatibility ambiguity.
**Fix**
- Document a supported-version window and provide `elizaos doctor` output that can be pasted into Discord/GitHub.

### Gap 4: Hosted vs local onboarding path not explicitly positioned
- Hosted deployment (Hatcher.host) is praised as smooth, while local CLI has a critical macOS failure mode.
**Fix**
- Present two official onboarding tracks:
  - “Deploy hosted in 5 minutes”
  - “Run locally (advanced)”
  with clear prerequisites and known issues.

---

## 5) Community Engagement Insights

### Power users / key contributors observed
- `odilitime`: active helper + diagnosis, points contributors to repos, involved in dev workflow PRs.
- `dankvr`: driving ai-news regeneration and operational improvements (fallbacks, credit monitoring).
- `airanna21`: actively moderating/scam-flagging.
- GitHub: high activity from `odilitime`, plus major PR authors (`NubsCarson`, `t49qnsx7qt-kpanks`).

**Power-user needs**
- Better tooling for version diagnostics and reproducible bug reports (especially for connectors like X).
- Clear plugin contribution standards to reduce review churn on large PRs.

### Common newcomer questions indicating onboarding friction
- “Is X project still active? Where can I contribute?” (Elizok)
- “How do I deploy?” (Hatcher.host question surfaced as an FAQ item)
- “Why does create fail?” (macOS bun issue)

### Converting passive users to contributors
- Add “first contribution” lanes:
  - label issues as `good first issue` + `help wanted`
  - provide a “pick a plugin to improve” program (tests, docs, compatibility fixes)
- Reward non-code contributions that address current pain:
  - docs PRs for deployment paths
  - reproductions for plugin-twitter failures
  - moderation tooling improvements

---

## 6) Feedback Collection Improvements

### Current channel effectiveness
- **Discord `💬-discussion`**: high engagement but low product signal due to token dominance and scam noise.
- **Discord `coders`**: higher signal (e.g., plugin-twitter login bug) but relies on back-and-forth for basic diagnostics.
- **GitHub issues/PRs**: high-quality technical detail (e.g., #6704 root-cause writeup), but not all users file issues.

### Improvements for more structured, actionable feedback
1. **Add Discord “bug report” prompts that generate a GitHub-ready template**
   - A bot command (e.g., `/bugreport`) that asks for:
     - core version, plugin versions, OS, connector, logs snippet
   - Then posts a formatted block users can paste into GitHub.

2. **Standardize issue templates**
   - Separate templates for: CLI install, connectors/auth, plugins, performance/cost.

3. **Add lightweight deployment telemetry (opt-in)**
   - Track which onboarding path users choose (hosted vs local) and top failure points.

### Underrepresented segments
- **Windows developers**: only surfaced indirectly via “Windows Git checkout blocked” PR; likely more friction exists but is underreported.
- **Non-crypto builders**: feedback is drowned out by token chatter; may be present but not visible in current channels.

---

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

1. **Fix `elizaos create` macOS Bun failure (#6704) + stop destructive cleanup on failure**  
   *Impact: unlocks onboarding; reduces rage-quit moments. Difficulty: low-medium.*

2. **Restore community signal: split token talk into a dedicated channel + strengthen anti-scam controls**  
   *Impact: increases support quality and contributor retention. Difficulty: low-medium.*

3. **Ship `elizaos doctor` (versions + connector diagnostics) and publish a compatibility matrix for plugin-twitter**  
   *Impact: faster support resolution; fewer repeated questions. Difficulty: medium.*

4. **Implement ai-news operational safeguards (credit monitoring + fallback models)**  
   *Impact: improved reliability/cost control for a production-like workload. Difficulty: medium.*

5. **Introduce a CI-enforced “Plugin Acceptance Checklist” + experimental tier in plugin registry**  
   *Impact: prevents unstable plugins from becoming “official” by accident; reduces maintainer load. Difficulty: medium.*