api-service-scaffoldlisted

# api-service-scaffold Scaffold a new backend service that is shaped correctly from commit one: clear layers, one error model, validation at the edge, config from the environment, and a health/readiness surface an orchestrator can probe. The goal is a skeleton a team can build on for years, not a demo that has to be re-architected the first time it meets production. ## When to use - Standing up a brand-new service. - Adding a new bounded context / module to an existing monorepo (reuse the repo's conventions; this skill fills the gaps). - Rescuing a service that grew without layers — apply the target structure below incrementally. ## Non-negotiables (hold these on every scaffold) - **One error model.** Every failure leaves the domain as a typed error and is mapped to a transport status in exactly one place (the handler/middleware boundary). No `throw new Error("bad")` escaping to the client. - **Validation at the edge.** Untrusted input is parsed into a typed value object at the boundary; the core never sees a raw request body. - **Config is injected, never read deep in the tree.** One config module reads the environment once, validates it, and is passed down. No `process.env.X` / `os.environ[...]` in business logic. - **No I/O in the domain layer.** Handlers orchestrate; services hold logic; repositories own I/O. The domain is testable without a network or a database. - **Health ≠ readiness.** `/healthz` = "process is up"; `/readyz` = "dependencies reachable". Orchestrator