Consistent Error Handling for a Multi-Tenant SaaS API

Problem/Feature Description

A growing B2B SaaS platform exposes a Fastify REST API to its customers. Over the past year, the API has accumulated error handling written ad-hoc by different developers. Some routes return { error: 'something went wrong' } with a 500, others return { message: 'User not found' } with a 404, and a few accidentally expose internal stack traces to API consumers. Support tickets frequently reference error messages that don't match anything in the documentation.

The engineering lead wants a unified error handling layer before the next major release. The requirements are:

1. Typed error classes — errors thrown in business logic should carry a stable error code (e.g. USER_NOT_FOUND) and a consistent HTTP status code. New error types must be easy to create without duplicating boilerplate.
2. Helper methods on the reply — route handlers that need to return standard HTTP errors (not found, bad request, conflict, etc.) should be able to do so with a single concise call rather than constructing the JSON payload manually.
3. Centralised formatting — all unhandled errors must flow through one place that logs them and formats the response consistently. Internal errors (500-range) should not expose implementation details in the response body.
4. Isolated error handling for different API areas — the public customer API and the internal admin API have different error response formats, so each needs its own error handler scoped to its route group.

Build a Fastify application skeleton that demonstrates all four requirements with representative routes for a user management domain.

Output Specification

Produce the following files:

• package.json — with type: "module" and scripts
• src/app.ts — Fastify application factory that wires up error handling and route groups. Export buildApp() returning the Fastify instance
• src/errors.ts — definitions of at least three domain-specific error types (e.g. a not-found error, an unauthorised error, and a conflict error)
• src/routes/api/users.ts — a route plugin for the customer-facing API with at least GET /users/:id and POST /users. Routes should throw the typed errors defined in src/errors.ts in appropriate situations
• src/routes/admin/users.ts — a route plugin for the admin API with at least GET /admin/users and DELETE /admin/users/:id. This route group should have its own error response format (e.g. wraps the error in { error: { code, message } })
• architecture-notes.md — a short document explaining: which library is used for typed error classes, which library provides the reply helper methods, and how each error type maps to an HTTP status code