## User Feedback Analysis — 2026-04-27 (based on aggregated feedback through 2026-04-26)

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

#### A. Documentation — **Architecture & planning concepts are unclear (HTN/HTM, “HTN-lite vs full HTN”)**
- **What users report**
  - Confusion about what HTN is, what’s actually implemented in ElizaOS v2, and what the upgrade path looks like (“uncertainty about specific implementation details”).
  - Terminology collisions (HTN vs HTM) required ad-hoc clarification in the coders channel.
- **Evidence / quantification**
  - In the 2026-04-25 FAQ, **2/3 questions (67%)** centered on HTN/HTM definitions and HTN implementation expectations.
- **Who it affects most**
  - Agent builders and plugin authors trying to adopt planning/goal decomposition features (higher severity due to architectural coupling and long-term design decisions).

#### B. Documentation / Communication — **Roadmap/timelines feel vague (v3 release, degenai updates)**
- **What users report**
  - Repeated “when will X ship?” questions about **v3** and **degenai** updates; no date provided for v3.
- **Evidence / quantification**
  - In the 2026-04-26 FAQ, **2/5 questions (40%)** were timeline-related (v3 release + degenai updates).
- **Who it affects most**
  - Newcomers and business evaluators who need predictability for adoption decisions.

#### C. Technical Functionality — **Broken / outdated external link (Milady Play Store link in GitHub repo)**
- **What users report**
  - The Milady Play Store link from the GitHub repository returns “item not available.”
- **Evidence / quantification**
  - Appears as a discrete, repeated callout in the 2026-04-26 Discord report and FAQ; it also generated an explicit action item (“Fix non-functional link”).
- **Who it affects most**
  - Users trying to access the app distribution channel; high severity because it blocks install/validation and reduces trust.

#### D. Integration — **Payments & token utility create design friction (don’t force token-only flows)**
- **What users report**
  - Strong desire for token utility, but concern that token-gating payments will create UX friction.
  - Competing proposals: “accept any payment method → buyback token” vs “pay fees in USDC or token with discounts + buyback/burn.”
- **Evidence**
  - 2026-04-26: shawmakesmagic explicitly frames token-specific utility as a UX risk and advocates “pay with what you have” + revenue buyback.
  - 2026-04-24: quanteliza proposes dual-fee currency (USDC/ELIZAOS) + discount + buyback/burn; odilitime calls token payments via x402 “lowest-hanging fruit.”
- **Who it affects most**
  - Plugin developers and anyone building paid agent services; also impacts onboarding conversion for non-crypto-native users.

#### E. UX/UI — **Workflow/automation feedback loops were previously opaque (long generation times, unclear progress)**
- **What users experience**
  - Workflow generation and complex LLM tasks can take long enough that users need clearer progress and fewer “is it stuck?” moments.
- **Evidence**
  - Development notes highlight mitigations landed/underway: a **6-stage progress UI**, validate-and-repair predeploy pass, and increased streaming timeout to **180s** for complex workloads.
- **Who it affects most**
  - Users building automations (n8n/workflow surfaces) and anyone running complex tool-use chains.

#### F. Performance / Reliability — **Long-running or heavy contexts can degrade responsiveness**
- **What users experience (implicit via fixes)**
  - Need for longer streaming timeouts (90s → 180s) suggests frequent overruns on realistic workloads.
  - Anti-hallucination defenses and prompt/keyword extraction work implies reliability issues in workflow deployment and planning outputs.
- **Evidence**
  - 2026-04-26 engineering summary explicitly calls out increased timeouts and validateAndRepair anti-hallucination defenses.

#### G. Community / Onboarding — **Discord organization and role/layout expectations are under-specified**
- **What users report**
  - Requests for “layout feedback” and role management discussion, but little structured follow-through in the captured discussion.
  - Working groups were updated and “steering bumps” granted, which is positive but can be confusing to newcomers without a clear “how to participate” path.
- **Evidence**
  - 2026-04-24: role/layout feedback requested; working group updates announced.

---

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

#### Observed “actual usage”
1. **Agent monetization and agent-to-agent commerce are becoming first-class**
   - Users are actively building marketplaces and paid agent services:
     - `@elisym/plugin-elizaos-elisym` demo: Nostr discovery + Solana settlement + paid request flow (Claude desktop → Eliza agent).
2. **Payments are being treated as an infrastructure primitive, not an app feature**
   - x402 and multi-chain payment rails are discussed as core enablers for plugins and agent services (and as the path to token utility).
3. **Automation/workflow building is a key adoption driver**
   - Significant work is landing around triggers, runtime events, workflow generation UX, validation/repair, and Telegram triggers.

#### Mismatch vs intended/communicated usage
- Users expect **clear token utility mechanics** (discounts, burns, fee routing), but core messaging emphasizes **minimizing friction** and “accept any payment method.”
- Users expect **release-date clarity** for v3/degenai, but communication remains “nearing completion”/“imminent.”

#### Emerging / unexpected use cases
- **Decentralized capability discovery (Nostr) for agents** is a notable direction—closer to “agent services registry + payments” than a typical plugin marketplace.
- **Business-facing integration via Eliza Cloud** indicates adoption beyond hobbyist experimentation, increasing the need for SLA-like reliability and clearer onboarding.

#### Feature requests aligning with usage
- Dual-currency protocol fees (USDC or ELIZAOS token) + discounts + buyback/burn aligns with:
  - Marketplace monetization needs
  - Frictionless onboarding for non-token holders
  - Sustainable token economics without hard-gating features

---

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

#### 1) HTN / planning docs ambiguity (Documentation) — **High impact, low–medium difficulty**
**Proposed solutions**
1. **Ship an “HTN in ElizaOS” doc pack** (impact: high; difficulty: low)
   - One page each:
     - “What HTN is” (with ElizaOS-specific definitions)
     - “What’s implemented today (v2)” (exact APIs, examples)
     - “HTN-lite → full HTN roadmap” (what changes, what stays stable)
2. **Add 2–3 runnable examples** (impact: high; difficulty: medium)
   - Example: “goal decomposition for scheduling + travel booking” leveraging LifeOps.
   - Example: “agent marketplace job: fetch trending repos” mirroring the Elisym demo.
3. **Glossary enforcement in docs + code comments** (impact: medium; difficulty: low)
   - A lightweight glossary prevents HTN/HTM conflation and reduces repeated Discord explanations.
**Comparable approaches**
- LangChain and Temporal both reduce conceptual ambiguity by pairing “concept pages” with “copy/paste quickstarts” and a glossary.

#### 2) Roadmap/timeline vagueness (Communication) — **High impact, low difficulty**
**Proposed solutions**
1. **Public “Now / Next / Later” roadmap page** updated weekly (impact: high; difficulty: low)
   - Include v3, app launch, degenai, and Cloud milestones with confidence levels.
2. **Release candidate checklist + status indicator** (impact: high; difficulty: low)
   - “v3: ✅ feature-complete / ⏳ regression tests / ⏳ docs / ⏳ release cut”
3. **Single pinned Discord “shipping updates” thread** (impact: medium; difficulty: low)
   - Reduces repeated questions and keeps answers canonical.
**Comparable approaches**
- Many open-source projects (e.g., Kubernetes SIG updates, Rust release train comms) use predictable cadence updates + confidence levels to align expectations.

#### 3) Broken Milady Play Store link (Technical Functionality) — **Medium impact, very low difficulty**
**Proposed solutions**
1. **Automated link checking in CI** for docs/README and key distribution links (impact: high; difficulty: low)
2. **In-repo “Distribution” section** listing canonical app links + last verified date (impact: medium; difficulty: low)
3. **Fallback channel** (APK direct download, alternative store link, or “not available in region” note) (impact: medium; difficulty: low–medium)
**Comparable approaches**
- Documentation sites commonly run link-check workflows (e.g., GitHub Actions link checkers) to prevent “dead link” regressions.

#### 4) Token utility vs friction (Integration / Product) — **High impact, medium difficulty**
**Proposed solutions**
1. **Default: accept “any payment method,” optional token perks** (impact: high; difficulty: medium)
   - Implement dual payment rails:
     - Pay with USDC/fiat rails where possible
     - Pay with ELIZAOS token for discounts (opt-in)
2. **Plugin-level payment policy templates** (impact: high; difficulty: medium)
   - A standard config: `paymentMethods`, `discounts`, `buybackPolicy`, `receipts`.
3. **Transparent receipts + fee routing dashboard** (impact: medium; difficulty: medium)
   - Show: “You paid with X; protocol bought back Y ELIZAOS; burned Z.”
**Comparable approaches**
- Early Binance/BNB-style fee discounts worked because they were **optional and clearly beneficial**, not mandatory gates. Stripe’s success similarly reflects “pay with what users already have” rather than imposing a single instrument.

#### 5) Workflow generation UX + long-running tasks (UX/Performance) — **High impact, medium difficulty**
**Proposed solutions**
1. **Make progress UI actionable** (impact: high; difficulty: medium)
   - Each stage should explain what’s happening (e.g., “Validating credentials…”) and offer “View logs / Cancel / Retry.”
2. **Expose “expected time” ranges per operation** (impact: medium; difficulty: low)
   - E.g., workflow generation: “typically 10–30s; can take up to 180s for complex models.”
3. **Post-run summaries for automations** (impact: medium; difficulty: medium)
   - After deploy: “What was created, what credentials were injected, what was repaired.”
**Comparable approaches**
- n8n and GitHub Actions both reduce perceived latency by surfacing stage-based execution logs and explicit “current step” UX.

---

### 4) Communication Gaps (expectations vs reality)

1. **Token utility expectations**
   - Expectation: token must be required to use the product.
   - Reality (per shawmakesmagic): forcing token utility risks friction; preferred is “accept anything → buyback.”
   - Improvement: publish a **token utility principles** doc (what will *not* be done: hard-gating basics; what *will* be done: optional discounts, buyback/burn mechanics, plugin payment support).

2. **Release readiness**
   - Expectation: “v3 is near” implies imminent release date.
   - Reality: no date, and multiple moving parts (app, Cloud integration, pending reviews).
   - Improvement: communicate “near” as a **state** (feature complete vs QA vs release candidate).

3. **Planning feature maturity**
   - Expectation: “HTN added” implies stable, documented interfaces.
   - Reality: community members explicitly noted uncertainty about implementation details.
   - Improvement: publish “experimental vs stable” labels for planning APIs.

---

### 5) Community Engagement Insights

#### Power users (and what they need)
- **shawmakesmagic**: needs a way to communicate token strategy and roadmap without repeated Q&A; benefits from canonical docs and a shipping updates cadence.
- **odilitime**: pushing payment methods (x402 token support) and community ops; needs a clear integration target (specs + acceptance criteria).
- **thirti.eth**: providing deep architectural context; would benefit from converting explanations into official docs.
- **igor.peregudov** (Elisym): building real monetization flows; needs stable payment hooks, service discovery conventions, and example-based integration guidance.
- **quanteliza**: tokenomics design proposals; needs a formal RFC process to move ideas from Discord into reviewable specs.

#### Newcomer signals / onboarding friction
- **waiser0165 (Dev School Student)** asks about degenai updates; **valleybeyond7991** flags broken app link—both indicate newcomers rely heavily on Discord for basic navigation and status.

#### Converting passive users to contributors
- Create “good first contribution” buckets around:
  - Docs: HTN/HTM glossary, roadmap page updates
  - QA: link verification, app install validation across regions
  - Examples: “paid agent service” templates (Nostr/Solana/x402)

---

### 6) Feedback Collection Improvements

#### Current channel effectiveness
- **Discord**: great for fast signal, but feedback is unstructured (questions recur; decisions and answers get buried).
- **GitHub**: better for actionable work, but many user-facing expectations (release timing, conceptual understanding) don’t become issues.

#### Improvements
1. **Weekly structured feedback prompt in Discord** (low effort)
   - A pinned form with categories (Docs/UX/Bugs/Payments/Integrations) + “steps to reproduce” for issues.
2. **RFC intake for economics + platform architecture** (medium effort)
   - Lightweight template: motivation, UX impact, security implications, rollout plan.
3. **In-app feedback hooks (when app ships/near ships)** (medium effort)
   - For workflow generation: “Was this progress indicator helpful?” + collect timing/perceived latency.

#### Underrepresented segments
- **Business/Cloud customers**: we see “Eliza Cloud is taking business,” but almost no direct feedback is captured here. Add a channel for:
  - Integration pain, onboarding time, auth/consent UX, billing clarity.
- **Non-crypto-native users**: token/payment discussions dominate; ensure feedback from users who prefer fiat/subscriptions is gathered explicitly.

---

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

1. **Fix and prevent broken distribution links**
   - Patch the Milady Play Store link and add CI link-checking for key docs/distribution endpoints.

2. **Publish a canonical “Roadmap + Shipping Updates” surface**
   - “Now/Next/Later” with confidence levels; pin it in Discord and link it in README/docs.

3. **Ship “HTN in ElizaOS” documentation + runnable examples**
   - Clarify current v2 reality, what “HTN-lite” means, and what “full HTN” would change; include 2 runnable examples.

4. **Define a friction-minimizing payments/token utility spec**
   - Document principles (“pay with what you have”), implement optional token discounts + clear buyback/burn receipts; provide plugin templates.

5. **Make long-running automation operations feel reliable**
   - Extend progress UI to include actionable controls (cancel/retry/logs) and publish expected duration ranges (especially for 180s streaming paths).