# FAQ and support

Use the symptom-specific pages first: Build and reader issues, Editor and account issues and Publish and deployment issues. Preserve unsaved work and inspect current state before repeating actions.

# Product and installation

The editor is included but optional. To use it on your own installation, create an administrator and start its private server with the correct runtime/users-file settings. Never expose the writer process just because the public reader has a domain. Complete setup separates the installation paths.

# Writing and collaboration

Add actual static assets through the server/Git workflow and rebuild. Use Git/backups for source versions and deletion recovery. Ordinary Save, metadata revision checks and browser drafts are different mechanisms; none supplies real-time coauthoring. Capabilities and limits gives the full boundary.

# Publication and hosting

Your hosting/CI/upload process handles the reviewed artifact. DNS, TLS, private reader identity and CDN policy belong to that infrastructure. Check actual remote home/deep/404/search/assets after deployment; a local Publish success is not remote verification.

# Markdown, language and network

Remote images can contact their hosts; favicon refresh is a server fetch; clicked links contact destinations. Local library bundling is not general outbound isolation. Use Markdown lab and inspect actual final reader output rather than enabling raw HTML to repair an unrelated preview mismatch.

# Organizational guarantees

No SSO/MFA, clustered writer HA, compliance certification, immutable audit archive or unlimited-scale promise is supplied. External controls can be part of your organizational workflow, but name who owns them and test their actual behavior. Review Validation limits before treating examples or historical measurements as production evidence.

# A useful support report

Inspect existing issues in the actual repository before filing a duplicate when you have access. Verify the repository/destination rather than assuming a generic project name points to its maintainers. Include the smallest synthetic example that reproduces the failure and the actual command used. For publication, add failed stage and reported live state; for search, add query and actual target; for layout, add theme/viewport and longest problematic row.

# Keep support evidence private-safe

Never include passwords, temporary passwords, cookies, session/CSRF tokens, API keys, private user files or account-store backups. Remove real usernames, private source, unrelated paths and internal organizational context where unnecessary. Review diagnostic text and screenshot pixels before sharing. Automated redaction cannot certify arbitrary private content is safe.

Replace private values with clearly labeled synthetic data while preserving the behavior. Do not quietly change a path/role so the example no longer reproduces the error. Sharing a minimal error report does not authorize anyone to access your accounts or run production commands.

# After a repair

Reproduce the expected result, test the affected allowed/denied boundaries and inspect actual output. State which runtime/browser/environment passed and what remains untested. Keep a focused regression fixture when the engine changes. Close the issue with the actual fix and evidence, not only a successful retry.