Fastify 5

F5-C06 · File paths and authorities built from request input are contained (no traversal, no Host-header URLs)

F5-C06 · Redirect targets never come straight from request input (open redirect): validate against an allow-list or keep them relative

F5-S01 · A route that consumes body, query or params declares a runtime contract for them (schema or an explicit validator)

F5-S05 · Schemas compiled by Fastify or Ajv never come from request data

F5-S15 · TypeScript casts of request.body/query/params are not validation: a route without a schema does not assert their type

F5-C05 · The user confirms trusting every proxy (trustProxy: true): X-Forwarded-* then decides request.ip, host and protocol

F5-T06 · package.json test, lint and typecheck scripts keep running real checks (no echo/exit 0, no --passWithNoTests added)

F5-T06 · Checks are not weakened to make a change pass: no blanket ts-ignore/eslint-disable, no focused tests, no no-op test or lint scripts

F5-T07 · Fastify warnings (FSTDEP, FSTWRN, FSTSEC) are fixed at their source, not suppressed process-wide

F5-C15 · One intentional error handler per scope: no second setErrorHandler on the same instance (FSTWRN004)

F5-C16 · Custom error handlers keep error statuses and never expose stacks or internal error data

F5-C17 · Not-found responses are customized with setNotFoundHandler, not by testing 404 in setErrorHandler

F5-C04 · Under handlerTimeout, outbound calls of a handler follow request.signal (the timeout does not stop work by itself)

F5-C02 · Route and parser bodyLimit overrides stay finite (no Infinity / MAX_SAFE_INTEGER)

F5-S06 · Validators, serializers and Ajv instances are built at boot, not per request inside handlers or hooks

F5-P12 · A module that exports the app or a plugin does not listen or install process handlers at import (startup owns sockets and signals)

F5-P13 · Business operations receive their inputs, not Fastify's request or reply objects

F5-P14 · Authentication and authorization checks repeated across handlers of a module move into one scoped hook

F5-P15 · A new import does not close a cycle of value imports between modules (up to three hops)

F5-P16 · Route handlers and hooks stay within the project's line budget (maxHandlerLines; off by default)

F5-C08 · Bodies are parsed by Fastify's parsers (built-in or addContentTypeParser with parseAs and bodyLimit), not by reading the raw request stream

F5-C09/C10 · Content-type parsers match precise media types (anchored regexes, no catch-all) and keep the built-in ones

F5-C18 · Routes constrained by version also send Vary: Accept-Version (caches must keep variants apart)

F5-C20 · @fastify/swagger is configured with current options: UI options belong to @fastify/swagger-ui

F5-C20 · @fastify/swagger is registered before the routes it documents, and the spec is generated after ready()

F5-S02 · A route with a request schema that returns structured data also declares its response schema

F5-S04 · Shared schemas registered with addSchema have unique $id values in a scope

F5-S07 · Schema validation stays synchronous: no $async schemas or async Ajv keywords for database or network lookups

F5-S08 · An asynchronous custom validator rejects on failure instead of resolving an { error } envelope

F5-S10 · A route with attachValidation: true branches on request.validationError before using the input

F5-S14 · Header schemas are inline (case-normalized), not external $ref (FSTSEC002)

F5-S16 · A plugin of a project using a type provider keeps it: provider-specific plugin types or withTypeProvider, not a plain FastifyPluginAsync

F5-S17 · Custom type providers implement Fastify 5's validator/serializer members, not the v4 input/output interface

F5-H01 · Plugins and hooks use one completion model: async functions take no done/next callback and never call it

F5-H02 · addHook receives a hook Fastify 5 knows; beforeHandler and other legacy names are not hooks

F5-H03 · onReady, onListen and onClose hooks do not register routes, hooks, plugins or decorators (the instance has booted)

F5-H03/H17 · onRoute observers are added before the routes they must see, and an onRoute hook adding routes guards against itself

F5-H04 · request.body is read only after parsing (preValidation or later), never in onRequest or preParsing

F5-H06 · A preParsing hook that replaces the payload returns a stream (not a string, Buffer or parsed object)

F5-H07 · A hook or handler that answers stops the chain: no done() after reply.send, and a deferred send returns reply

F5-H08 · An async handler completes once: it returns the payload or sends and returns reply, never both

F5-H09 · Every path of an async handler returns a payload, sends, throws or hijacks (no silent undefined fall-through)

F5-H10 · onError hooks observe errors: no reply.send and no error passed to done (setErrorHandler maps responses)

F5-H11 · onSend replaces the payload with a serialized value (string, Buffer, stream or null), never an object

F5-H12 · onResponse, onTimeout and onRequestAbort hooks never try to send or modify the response

F5-H13 · Raw response writes (reply.raw.write/end/writeHead) happen only after reply.hijack(), in an isolated adapter

F5-H14 · A plugin that opens pools, clients, timers or listeners releases them in an onClose (or preClose) hook

F5-H15 · listen/ready failures are handled and close completes before the process exits

F5-H16 · Readiness-critical work (connections, migrations, warm-up) runs in plugin boot or onReady, not in onListen

F5-P03 · A fastify-plugin that provides decorators declares its name, and a published plugin declares the Fastify range it supports

F5-P04/P05 · Routes are not registered directly inside a fastify-plugin wrapper (it breaks encapsulation and register prefixes do not apply)

F5-P06 · Plugins share scope through fastify-plugin, not by setting Symbol.for('skip-override') or importing Fastify's private lib/ modules

F5-P07 · Decorations happen during plugin boot (awaited), never later from a .then, timer or event callback

F5-P08 · decorateRequest/decorateReply never share an object, array, Map or Set across requests

F5-P09 · Handlers, hooks and decorators that use Fastify's this are regular functions, not arrow functions

F5-P10 · One decorator name is defined once per scope: no duplicate decorate calls, no hasDecorator guards hiding a second implementation

F5-P17 · ES modules locate plugin and route directories with import.meta.dirname, not the CommonJS __dirname/__filename

F5-X09 · Starting a new Fastify app or plugin by hand gets a hint about the official generators (once per session)

F5-X10 · The user confirms a Fastify generator run that integrates into or targets an existing, non-empty directory

F5-X12 · Fastify code uses the maintained native plugins instead of Express middleware or hand-written CORS, body parsing and security headers

F5-V01/V02/X05 · At session start, Claude learns the installed Fastify version, its bundled docs and plugins that do not match Fastify 5

F5-V04 · listen takes an options object ({ port, host }): the positional port/host signature was removed

F5-V05 · Route schemas given to the default compilers are full JSON Schemas (no v4 shorthand property maps for body, querystring, params, headers or responses)

F5-V06/V07/V12/C05 · Fastify factory options hold no option Fastify 5 removed or rejects: jsonShortHand, versioning, a logger instance in logger, hop-count trustProxy

F5-V08/V11 · Route metadata comes from routeOptions, the socket from request.socket and timing from reply.elapsedTime (request.context, routerPath, connection, getResponseTime… were removed)

F5-V09 · reply.redirect takes the destination first and the status second

F5-V10 · reply.sent is read-only: the response is taken over with reply.hijack()

F5-V12 · Route versions are constraints (constraints: { version }), not the removed version route option

F5-V13 · request.params has no prototype: no params.hasOwnProperty/toString, use Object.hasOwn

F5-V14 · reply.trailer producers are async or take the done callback (direct return was removed)

F5-V15 · A custom HEAD route is registered before the GET of the same URL, or that GET sets exposeHeadRoutes: false

F5-V16 · hasRoute receives a route definition (method + pattern), not a concrete request URL

F5-V17 · Routes use HTTP methods Fastify 5 supports, or register the WebDAV ones with addHttpMethod first

F5-V18 · addHttpMethod for a method Fastify already supports passes overrideExisting: true deliberately (FSTDEP025)

F5-V19 · request.hostname has no port since Fastify 5: the authority is request.host, the port request.port

F5-V20 · No setDefaultRoute/getDefaultRoute (removed): setNotFoundHandler, or routerOptions.defaultRoute for low-level routing

F5-V21/V22/V25/C02/C03/C07/C14/C19/S11/S12 · Factory options use routerOptions and logController, keep safe parsing and bounded inputs, and make Ajv and request-ID choices deliberate

F5-V23 · fastify.use needs a middleware adapter (@fastify/middie or @fastify/express) installed and registered; native hooks and plugins come first

F5-V24 · Middleware under @fastify/middie gets raw Node req/res: no Fastify or Express reply methods there

F5-V25 · New date-time/time formats are checked against Fastify 5's timezone requirement (hint)

F5-C01 · Route and plugin modules receive configuration through options or a decorator; process.env is read at the startup/config boundary

F5-C11 · Request work logs through request.log / fastify.log (structured, correlated), not console

F5-C12 · Logs do not dump whole requests, headers, bodies or queries (secrets reach the log store)

F5-V02 · Fastify is installed within 5.x at or above the security floor: no 3/4/6 specs, prerelease tags or ranges that cannot reach the floor

F5-V02 · package.json keeps fastify on a 5.x range that can resolve at or above the security floor

F5-V03 · A declared Node.js runtime of a Fastify project meets Fastify 5's minimum (Node 20): engines, .nvmrc, Dockerfile, CI matrices

F5-X01 · Dependencies are installed with the project's package manager (packageManager field, lockfile)

F5-X01 · No second lockfile next to another package manager's lockfile

F5-X02 · A new package.json without dependencies is initialized with the package manager

F5-X02/X03 · A new package.json comes from the package-manager initializer (or a generator), and gets its dependencies from the package manager

F5-X03 · Dependencies change through the package manager (add/remove/update), never by editing package.json by hand

Records the tool calls that run a package manager (they may rewrite package.json and lockfiles; F5-X03/X05/X06)

F5-X04 · Registry version lookups are not a step before installing

F5-X04 · Packages are installed by name: no guessed exact version, no --save-exact without a reason

F5-X05/X06 · Dependency conflicts are repaired, not masked with --force, --legacy-peer-deps or broad overrides

F5-X05 · Installs use the maintained @fastify/* package names and plugin majors compatible with Fastify 5

F5-V02/X05 · After a package-manager run, the Fastify and plugins it touched resolve to Fastify-5-compatible releases

F5-X05 · A fastify-plugin wrapper declares a Fastify range that includes 5 (a 3.x/4.x range fails at boot)

F5-X06 · Lockfiles are written by the package manager only (no hand edit, no script rewriting them)

F5-X06 · A turn that changes package.json dependencies also updates the lockfile next to it (once per stop)

F5-X07 · CI and image builds of a project with a lockfile install from it (npm ci, frozen/immutable installs)

F5-X08 · Hand edits of package.json metadata or scripts get a once-per-session hint about npm pkg set/delete

F5-T01 · Route tests run real Fastify registration through inject, not a mocked fastify module or hand-made reply objects

F5-T03 · A test that injects into or listens on a Fastify instance closes it (teardown hook or finally), even when the test fails

Records which checks (lint, typecheck, build, test) a shell call runs, from the parsed commands (F5-T06 ledger)

F5-T06 · A final message claiming passing lint, types, build or tests needs a successful run after Claude's last edit

F5-T06 · Records, per session, Claude's edits (file tools and shell writes) and the lint, typecheck, build and test runs that succeeded after them

F5-T06/S15 · A turn adds no TypeScript errors to the changed files or their importers (language server, once per stop)

F5-T06 · A turn that changed Fastify code ends only after the configured lint, typecheck and tests succeeded on the final files (once per stop)

Records the work tree when a prompt starts: the baseline of the Fastify end-of-turn checks (F5-X06, F5-T06)