Website Gitbook

Build the website and publish the GitBook handbook

The upgraded website keeps the supplied React and TanStack application and adds a searchable documentation route. The handbook's Markdown files are the content source. A generator produces the reader data and copies downloadable Markdown into public docs-source. This means the website reader and GitBook import can share one reviewed text collection instead of drifting into separate manuals.

Work in the website checkout

Install the pinned JavaScript dependencies, generate docs and run the project's checks. The upgraded package includes scripts for documentation generation and validation. Keep the package lock committed so another developer can reproduce installation. The supplied archive's lockfile needed repair because a clean install reported missing entries; this is a website dependency issue, not an Android wallet change.

npm ci
npm run docs:generate
npm run docs:check
npm run typecheck
npm run build

A successful website build does not build EdgeORE's Android APK. Likewise, a documentation word count is not a product qualification score. Preserve separate reports for source checks, reader behavior and Android evidence. If a hosting platform injects its own preview or branding bridge, preserve the required platform files unless the owner changes deployment settings through the supported route.

Import into GitBook

Commit docs/book, its SUMMARY.md and the repository's .gitbook.yaml. In the owner's GitBook account, create or select a space and configure Git sync with the repository and branch that contain these files. The configuration points root to docs/book, with README.md as the entry page and SUMMARY.md as the navigation structure. Review the imported hierarchy before publishing the space.

Use a dedicated branch or an agreed sync policy if editors will write in GitBook and GitHub. Two-way editing can create conflicts, especially when generated files are mixed with authored Markdown. Treat the Markdown chapters as authored source and the website data as generated output. Re-run generation after text changes. Do not manually edit the generated JSON and expect GitBook to receive those edits.

Review before publication

Open every chapter, check code fences and tables, and inspect relative links. The generator validates the inventory and measures the authored chapter text. Navigation should work on mobile, search should provide a meaningful empty result and copied code should remain exact. Where links point to moving upstream documentation, review them when dependencies change. A valid URL today does not freeze an external API forever.

Configure the GitBook space title, description, owner contact and access policy. No GitBook account or published space is created by this archive alone. The correct handoff wording is GitBook-ready handbook, with publication available after the owner connects Git sync. If a hosted website is deployed separately, record its deployment result instead of claiming an edited ZIP is already live.

Maintain the collection

When the Android candidate changes, update status, source identity, commands and acceptance criteria together. Keep historical evidence pinned rather than rewriting it to match the latest branch. Add new tutorials only after deciding whether they describe released behavior, an experiment or a specification. This maintenance rule lets a long handbook remain useful rather than becoming a twenty-thousand-word source of stale claims.

---

Wiki home · Qualification updates · Sources and credits