Writing an INACT page

How to add or update a page in this section. The rules exist so that a reader who knows one page can find their way in every other one, and so that a page can be checked for staleness later.

Before you write

• Check the code, not your memory. Every non-obvious claim points at a file, a config key, a table or a commit. 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.
• Check the big five, not one fork: inact, ina-jadestone, ina-medco-v3, ina-jotre, ina-primaenergy. Grep each one. Differences go in the Instance differences table; what you did not check goes in verified_on.
• Check that the path is live. A function that exists can be dead: the legacy query helper throws on entry in four of the five forks. Say which paths die where.
• Both locales, every time. English under src/inact/, Bahasa Indonesia under src/id/inact/, the 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-06
verified_on: [inact, ina-jadestone, ina-medco-v3, ina-jotre, ina-timas]
sources:
  - modules/routing/routing_handler_post.php
  - templates/tracking_v2/routing_resp.htm
---

verified_on lists the repositories the claims were checked against. sources are paths relative to the master repository. Update last_verified whenever you re-check the page, even if nothing changed.

The sections, in this order

For a feature or module page:

1. A one-line module line and a short overview: what the feature is for, and what it does not do.
2. An ::: info How this page was verified box: when, on which fork, what was re-checked.
3. User flow or The screen: buttons, privileges, dialogs.
4. How it works: entry point, handler, key functions, side effects. Link code as https://github.com/binari-digital/inact/blob/main/<path>, never with line numbers.
5. Data or template contract where a file or a fixed structure is involved.
6. Database tables affected: table, operation, by whom.
7. Gotchas and known issues: silent failures, dead paths, validation quirks.
8. Instance differences: one row per fork that differs from master. If nothing differs, say "None" and name the forks checked.
9. Related: links to the neighbouring pages.

For a system page (configuration, access control, reporting) adapt the headings; keep the verification box, the tables, the gotchas and the Instance differences.

For an instance page, follow the existing six: same sections, same order.

Marking a one-off inside a page

::: warning Medco only
The "Ready to Return" tab exists only in `ina-medco-v3`.
:::

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 terms stay in English in both: MDR, Transmittal, Document Library, sign off, routing, and every table, column and function name. Short sentences. Say the main point first.

When a ticket touches a module without a page

Write the page as part of the ticket, at the level of detail the ticket needed, with the sections above. A page that maps the module and lists its dead paths is more useful than no page. Add it to both sidebars and to the plan in plans/inact-docs.md.

Checking a page later

Run through last_verified. A page older than a year, or one whose sources changed in git since that date, gets re-checked: open the code, confirm each claim, fix the text, bump the date.