Screens
A stub page exists here for every route exposed by the production
gnostikon-client app. The set is regenerated by
scripts/sync-screens.mjs
from the sibling client repo's Expo Router tree
(gnostikon-client/app/), or from a JSON endpoint when the
SCREENS_SOURCE_URL env var is set.
Coverage is the contract; depth is opportunistic. Every screen has a page so a reader who lands here from search or from a user report can confirm the screen exists and reach the live surface. Most pages start as one-line stubs and graduate to full reference as someone enriches them.
How this section relates to Client surface
Client surface is the hand-authored, deeply enriched per-screen reference — each page in that section follows Page template (visible elements, dispatched events, API endpoints consumed, related guides). Authoring is manual and slow.
This section (Screens) is the automated coverage layer. Stubs are generated from the client's route tree and refreshed on every sync run. When a screen graduates to full reference under Client surface, the stub here can stay as a coverage marker, link out to the enriched page, or be deleted — your call as the author.
Workflow
# default: read sibling ../gnostikon-client/app/
npm run sync:screens
# override source (future JSON endpoint or local dev server)
SCREENS_SOURCE_URL=https://gnostikon.heitmann.ai/_sitemap.json \
npm run sync:screens
Re-running the script against an unchanged source produces zero diff. Manual edits to a stub body are detected and preserved.
Enriching a stub
- Open the stub MDX.
- Replace the
Documentation pendingadmonition with real content. - Commit. The sync script will leave your edits alone on the next run (it only touches files that still match the pristine generated template).
For a richer template that matches the Client surface convention, copy Page template into the stub and fill in the sections.
When the client adds or removes a screen
- New screen: next
npm run sync:screenscreates the stub. - Removed screen: the sync reports the orphan stub on stderr — a human decides whether to delete the file or repurpose it. The sync never deletes content.
- Renamed screen: appears as both an orphan (old slug) and a new
stub (new slug). Move enriched content with
git mv, then delete the orphan.