namht-runbooklisted

# namht-runbook — turn the Knowledge Base into something you can act on at 2am A Knowledge Base explains **how the system works**. A runbook answers a different question: **what do I do right now?** The two are not the same document and should not be written the same way. The KB is read while you think; the runbook is read while something is on fire — by someone who may not have built this, at an hour when they are not at their best. That difference drives every rule below: **imperative, exact, and honest about what it doesn't know.** ## Inputs - **Scope** — one service/app (best), or a module. A runbook for "everything" helps nobody; if the repo holds several deployables, ask which one, or produce one file per service. - `knowledge-base/` — required for the business half. Missing → say so and point at `/namht-scan`; you can still produce the operational half from config, at lower confidence. ## Where the evidence comes from Read **both** halves, and cite files for everything: | Section | Ground it in | |---|---| | What this service is, who it serves | KB `04-business-domain`, `06-modules`, `01-project-structure` | | Dependencies that can take it down | KB `14-integrations`, `17-async-events`, `08-database-schema` | | Deploy / rollback | `.github/workflows/`, `.gitlab-ci.yml`, `Jenkinsfile`, `Dockerfile`, k8s manifests, `helm/`, `terraform/`, `Procfile`, deploy scripts in `package.json`/`Makefile` | | Health & readiness | actual health endpoints in the code, k8s prob