Skip to main content

Locate Internal Docs

Start here: the User Migration module — what replaced each Shukah API the app calls, field by field, and what is still missing.

This is the internal engineering reference: handwritten guides on business rules, handoffs, and flows, written for web and mobile engineers who need to know what an endpoint does without reading the service's source.

What lives here​

  • Modules — one folder per feature area: an overview page plus one page per area.
  • Services — handoffs for the services (system-categories) feature area.

Where field-level truth lives​

Field names, types, and status codes come from each service's code and, where the service publishes one, its OpenAPI spec. Three specs are snapshotted into openapi/*.json at the repo root and committed, so a pull request shows every API change. Refresh them with the command below. Two of the three need credentials, which the root README.md documents (under "Refreshing the OpenAPI snapshots"):

npm run openapi:fetch

This site used to render those snapshots as an API section. That was switched off on 2026-10-01 to keep the site focused; the snapshots are still fetched and committed. To render them again, restore the docusaurus-plugin-openapi-docs entry, the docusaurus-theme-openapi-docs theme and docItemComponent in sites/internal/docusaurus.config.ts, plus the gen-api-docs generation step. The root README.md has the full recipe; the plugin's packages are still installed.

Where design specs and implementation plans live​

They stay in the code repos, not here. A spec or a plan describes one change, tied to the commits that made it — useful history, but a snapshot in time. This site's job is the opposite: describe the present, so a reader never has to work out whether what they're looking at is still true. Mixing the two would make that impossible to tell at a glance, so specs and plans are left where they were written and this site only links to them when relevant.