Writing an Exsport page

How to add or update a page in this section. The rules keep every page findable and checkable for staleness later. They match the INACT contributing guide; what differs is that Exsport is one product across many repos, not one codebase forked per client.

Before you write

• Check the code, not your memory. Every non-obvious claim points at a file, an entity, an env var or a resolver. If you cannot point at it, write a > **TODO:** line instead of a guess. A thin honest page beats a full page with three wrong lines.
• Say which repo. A feature usually spans backend + a frontend. Name the repo for each file you cite (def-exsport-backend, def-exsport-frontend-storefront, def-exsport-frontend-admin).
• Check that the path is live. Some things exist but are not wired: product/journal/voucher create is REST, not the (commented-out) GraphQL mutation; the admin dashboard is a stub; admin orders have no mutations. Say so.
• Both locales, every time. English under src/exsport/, Bahasa Indonesia under src/id/exsport/, same structure, and a sidebar entry in both locales in src/.vitepress/config.mjs. A page is not done until both exist.

The frontmatter

---
last_verified: 2026-09-15
verified_on: [def-exsport-backend, def-exsport-frontend-storefront]
sources:
  - src/orders/services/orders.service.ts
  - src/app/checkout/shipping/page.tsx
---

verified_on lists the repos the claims were checked against, by GitHub slug. sources are repo-relative paths; because Exsport spans repos, a page's sources can come from more than one repo. The staleness tool matches each source against every configured Exsport repo and reports which one changed. Update last_verified whenever you re-check the page.

The sections, in this order

For a feature page:

1. A short overview: what the feature is, which backend module and which frontends.
2. An ::: info How this page was verified box: when, which repos, what was read.
3. The model: entities/tables involved (the names are @Entity({ name })).
4. Backend: resolvers (CMS vs front*), REST controllers, services, third-party calls.
5. Storefront and/or Admin: routes and the files behind them.
6. Gotchas: dead paths, REST-not-GraphQL writes, simulator effects, event side-effects.
7. Related: neighbouring pages.

For a system page (environments, database, API, third parties) adapt the headings; keep the verification box and the gotchas. For a repo page, follow the existing eight: stack, run, layout, structural facts, branch model.

Marking a one-off

::: warning Storefront only
The cart is a context, not a `/cart` route.
:::

Use ::: danger for something that fails or misleads, ::: warning for a difference, ::: tip for a reading aid.

Language

English page first, then the Bahasa Indonesia page. Domain and technical terms stay in English in both: GraphQL, resolver, entity, cart, checkout, voucher, flash sale, webhook, and every table, column, function and env-var name. Short sentences. Say the main point first.

Checking a page later

Run the staleness tool (scripts/doc-staleness.py exsport, or a repo filter like exsport backend) to see which pages are behind the code, then open the code, confirm each claim, fix the text, and bump last_verified. The update-docs skill wraps this.