Emdash CMS User Docs Synthesis from Real Conversations
A documented mapping of recurring user questions to long-form docs and FAQ entries, with publishing priorities and editorial standards.
Why this page exists
This page records how repeated support conversations were converted into durable documentation assets.
It keeps docs strategy tied to observed user friction, not internal assumptions.
Source pain points and document placement
Pain point 1: “How should I start from an empty EmDash project?”
Observed pattern: users ask for folder planning before writing code and need architecture trade-offs up front.
Placement: long-form guide in docs/docs because the answer requires sequence, rationale, and anti-pattern analysis.
Mapped page:
docs/docs/emdash-cms-project-bootstrap-and-directory-layout.mdx
Pain point 2: “Can I deploy to Cloudflare Free plan and what exactly breaks?”
Observed pattern: users can deploy partially but fail on feature boundaries and billing language interpretation.
Placement: split between docs/docs and docs/faq:
- deployment runbook belongs to long-form docs
- billing and boundary clarifications belong to FAQ
Mapped pages:
docs/docs/emdash-cms-cloudflare-free-tier-production-playbook.mdxdocs/faq/emdash-cms-cloudflare-pricing-and-billing-faq.mdxdocs/faq/emdash-cms-cloudflare-free-plan-limitations-faq.mdx
Pain point 3: “Where should I run these commands?”
Observed pattern: command correctness is often fine, but working directory context is wrong.
Placement: FAQ, because users need fast diagnostics and short decision rules.
Mapped page:
docs/faq/emdash-cms-deployment-command-context-faq.mdx
Pain point 4: “How do I verify a deployment is really done?”
Observed pattern: users stop at route reachability and miss admin/data-path validation.
Placement: FAQ with checklist format and quick triage order.
Mapped page:
docs/faq/emdash-cms-deployment-verification-and-first-login-faq.mdx
Pain point 5: “What is Dynamic Workers actually for?”
Observed pattern: feature naming is understood, but security boundary implications are not.
Placement: architecture guide in docs/docs, because this is a model explanation, not a one-liner.
Mapped page:
docs/docs/emdash-cms-plugin-runtime-and-security-model.mdx
Publication order and rationale
Recommended release sequence:
docs/faq/emdash-cms-cloudflare-pricing-and-billing-faq.mdxdocs/docs/emdash-cms-cloudflare-free-tier-production-playbook.mdxdocs/faq/emdash-cms-cloudflare-free-plan-limitations-faq.mdxdocs/docs/emdash-cms-project-bootstrap-and-directory-layout.mdx- remaining architecture and self-hosted references
Ordering principle:
- publish highest confusion, highest support-load topics first
- then publish complete execution guides
- then publish deep architecture references
Editorial rules to keep documentation credible
Use these standards for future additions:
- lead with decision and boundary, then provide mechanism
- include success signals and failure signals for each operation
- provide rollback or fallback path for every high-impact step
- avoid abstract adjectives unless tied to measurable criteria
- write for operators under time pressure, not for marketing tone
Maintenance routine
Review this mapping monthly using three inputs:
- top repeated support questions
- failed deployment patterns from user reports
- documentation pages with high exits and low completion feedback
When a question appears in support more than twice in one month, either improve existing page diagnostics or add a targeted FAQ entry.