Skip to content

Ninaku CoreThe backend, documented as it actually runs

A modular monolith on NestJS and PostgreSQL. Every contract here is enforced by CI, and the API reference is generated from the running service — not written by hand.

NinakuNinaku

Start here

If you areStart withThen read
New to the codebaseArchitectureDomain map
Building or changing an endpointFoundation HTTP contractAPI and schema discipline
Integrating against the APIAPI referenceModule contracts
Looking for a past decisionDecisionsRoadmap

What exists today

Application Foundation is in progress, tracked in issue #13. This site documents the target contracts and the code that is actually running — it does not claim the two are already the same thing.

Today the service exposes exactly two routes:

GET /health/live
GET /health/ready

Both stay unversioned and unprefixed on purpose, because Railway's healthcheck depends on that exact path. They are also deliberately outside the data envelope: a probe is infrastructure, not business API surface. Business routes will be served under /api/v1/… as they land.

How this documentation stays honest

  • docs/generated/openapi.json is produced by npm run openapi:generate from the running application and its Zod schemas, then verified byte for byte by npm run openapi:check. It is never edited by hand.
  • The API reference renders that exact file, so it cannot drift from the service.
  • When documents disagree, authority runs in this order: automated contracts and the database manifest, then current architecture, then domain decisions, then historical evidence.
  • A change that touches architecture, schema, deployment or modules updates its owning document in the same pull request.

Application Foundation in progress. Tracked in issue #13.