Skip to content

Ninaku CoreThe backend, documented as it actually runs

A modular monolith on NestJS and PostgreSQL. Every contract here is enforced by executable checks run before every merge, 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.