Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.changeset/config.json:
- Line 12: The package "@inversifyjs/http-openapi-validation" in the fixed group
has version 0.1.0 which mismatches the group's 3.0.0; open the package.json for
the `@inversifyjs/http-openapi-validation` package and change the "version" field
from "0.1.0" to "3.0.0" so it matches the other fixed-group packages referenced
in .changeset/config.json, then verify the package name
"@inversifyjs/http-openapi-validation" is unchanged and commit the updated
package.json.

In
`@packages/docs/tools/inversify-validation-code-examples/src/examples/v1/openApiValidation/apiIntroduction.int.spec.ts`:
- Around line 15-16: The afterAll teardown assumes server was set by beforeAll
and will throw if beforeAll failed early; update the afterAll blocks that
reference server (e.g., the server variable used alongside beforeAll/afterAll)
to guard the teardown by checking the server is truthy before calling its
close/shutdown method (e.g., if (server) await server.close()), and apply the
same guard to the other afterAll at the other occurrence (lines referenced
around 47-49) so teardown does not raise a secondary error when setup failed.

In
`@packages/framework/http/libraries/open-api/src/openApi/services/v3Dot1/SwaggerUiProvider.spec.ts`:
- Around line 71-87: The test suite for SwaggerUiProvider.openApiObject must
follow the Class → Method → Input → Flow describe structure and use the 'when
called, and [condition]' naming pattern; update the nested describes so the
outermost is SwaggerUiProvider, the next targets .openApiObject, then an
input-level describe (e.g., 'with optionsFixture'), and the flow-level describe
should be 'when called, and [condition]' (or simply 'when called, and no special
options' if nothing else), and keep the existing assertions using result and
optionsFixture.api.openApiObject; ensure the describe strings reference
SwaggerUiProvider and .openApiObject so the test name aligns with project
conventions.

In
`@packages/framework/http/libraries/open-api/src/openApi/services/v3Dot1/SwaggerUiProvider.ts`:
- Around line 70-72: The openApiObject getter currently returns
this.#options.api.openApiObject without verifying initialization; add a guard
using the provider's internal flag (this.#provided) to throw a clear error if
openApiObject is accessed before provide() has been called. Update the
SwaggerUiProvider class's openApiObject getter to check this.#provided and throw
a descriptive Error (e.g., "OpenAPI object not provided — call provide() first")
when false, otherwise return this.#options.api.openApiObject.

In
`@packages/framework/http/libraries/open-api/src/openApi/services/v3Dot2/SwaggerUiProvider.spec.ts`:
- Around line 71-87: The test for the SwaggerUiProvider.openApiObject getter
must follow the four-layer describe convention (Class → Method → Input → Flow);
update the spec so the top-level describe names the class (SwaggerUiProvider),
the next describes the 'openApiObject' getter, add an Input-level describe for
the fixture/input context (e.g. 'when options contains api.openApiObject'
referencing optionsFixture), and change the Flow-level describe to a descriptive
condition (e.g. 'when called and the option is present') so the it() assertion
remains the same (expect(result).toBe(optionsFixture.api.openApiObject)); keep
references to SwaggerUiProvider, openApiObject, and optionsFixture to locate the
code.

In `@packages/framework/http/libraries/openapi-validation/package.json`:
- Around line 26-27: The package.json's devDependencies entry for ajv
("devDependencies.ajv") is pinned to 8.17.1 which does not satisfy the declared
peerDependencies.ajv range (^8.18.0); update devDependencies.ajv to a version
that matches the peer range (e.g., ^8.18.0 or a specific 8.18.x/8.19.x release)
so local tests run against a supported AJV version and the peer constraint is
honored.
- Around line 12-14: The package.json pins two internal packages to fixed
versions; change the dependencies for "@inversifyjs/prototype-utils" and
"@inversifyjs/reflect-metadata-utils" to use the workspace protocol
(workspace:*) like "@inversifyjs/validation-common" so they reference the
monorepo packages; update the dependency values for the exact keys
"@inversifyjs/prototype-utils" and "@inversifyjs/reflect-metadata-utils" to
"workspace:*".

In
`@packages/framework/http/libraries/openapi-validation/src/v3Dot1/pipes/OpenApiValidationPipe.int.spec.ts`:
- Around line 285-297: The test description in OpenApiValidationPipe.int.spec.ts
is incorrect: the describe currently says "no Content-Type header" but the test
sends a 'Content-Type': 'application/json' header and actually exercises the
case where the pipe has no requestContentTypeProvider and falls back to the
OpenAPI single declared content type; update the describe string to accurately
reflect this (e.g., mention "requestContentTypeProvider undefined / falls back
to single declared content type" or "with single content type and Content-Type
header present") so the description matches the behavior exercised by the test
that uses the POST /users request and the response variable.

In
`@packages/framework/http/libraries/openapi-validation/src/v3Dot1/pipes/OpenApiValidationPipe.ts`:
- Around line 206-217: The content-type check in OpenApiValidationPipe (inside
the rawContentType !== undefined branch) compares the lowercased request media
type (baseContentType) against declaredContentTypes in their original casing
which can cause mismatches; normalize declaredContentTypes by mapping each entry
to a trimmed, lowercased form (e.g., normalizedDeclared =
declaredContentTypes.map(...) ) and use
normalizedDeclared.includes(baseContentType) for the comparison, then throw the
same InversifyValidationError (InversifyValidationErrorKind.validationFailed) if
not included and keep returning baseContentType.

In
`@packages/framework/http/libraries/openapi-validation/src/v3Dot2/pipes/OpenApiValidationPipe.int.spec.ts`:
- Around line 58-91: The promise returned for bootstrapping the Server currently
only accepts a resolve callback and throws inside the httpServer.listen
callback, which won't reject the outer Promise and lacks an 'error' listener for
listen/start failures; update the Promise signature to accept both resolve and
reject, replace the throw when address is null/string with reject(new
Error(...)), attach an httpServer.once('error', reject) before calling
httpServer.listen and remove that listener (or use httpServer.off) once the
listen callback succeeds so startup errors properly reject the outer Promise,
and ensure any listeners are cleaned up on successful resolve.

In
`@packages/framework/http/libraries/openapi-validation/src/v3Dot2/pipes/OpenApiValidationPipe.spec.ts`:
- Around line 30-49: The test claims "parameter metadata is undefined" but the
mock returns an empty array; change the mocked return of
getControllerMethodParameterMetadataList from [] to undefined
(vitest.mocked(getControllerMethodParameterMetadataList).mockReturnValueOnce(undefined))
so the OpenApiValidationPipe branch for undefined metadata is exercised; update
any related expectations/assertions in this spec (OpenApiValidationPipe.spec.ts)
to reflect the undefined-path behavior if needed.

In
`@packages/framework/http/libraries/openapi-validation/src/v3Dot2/pipes/OpenApiValidationPipe.ts`:
- Around line 206-217: OpenApiValidationPipe currently lowercases the
request-derived baseContentType but compares it against declaredContentTypes
which retain original casing, causing mismatches for differently cased media
types; update the check in the validation block (the code that computes
baseMediaType/baseContentType and uses declaredContentTypes.includes(...)) to
perform a case-insensitive comparison by normalizing declaredContentTypes (e.g.,
map to lowercase/trim) or by comparing baseContentType to each declared entry
lowercased, and keep the thrown InversifyValidationError behavior but use the
normalized values when matching.

---

Nitpick comments:
In
`@packages/framework/http/libraries/open-api/src/metadata/calculations/v3Dot1/getControllerOpenApiMetadata.spec.ts`:
- Around line 11-70: Refactor the spec for getControllerOpenApiMetadata to
follow the repository’s 4-layer describe hierarchy (Class → Method → Input →
Flow) and replace ad-hoc let fixtures with a reusable fixture class that exposes
static factory methods; specifically, wrap tests in nested describes for the
target class, the getControllerOpenApiMetadata method, the input case (metadata
present vs undefined), and the execution flow, and create a fixture class (e.g.,
ControllerFixture) with static methods to produce targetFixture and
metadataFixture; update test bodies to call
vitest.mocked(getOwnReflectMetadata).mockReturnValueOnce(...) and assert calls
and returns against controllerOpenApiMetadataReflectKey as before, but using the
new fixture class and describe structure to comply with the required pattern.

In
`@packages/framework/http/libraries/open-api/src/metadata/calculations/v3Dot1/getControllerOpenApiMetadata.ts`:
- Around line 6-13: Add JSDoc for the exported getControllerOpenApiMetadata
function: document its purpose (retrieves controller OpenAPI metadata from the
target via reflect metadata), describe the parameter `target: object` (the
controller/class whose metadata is read), mention the return type
`ControllerOpenApiMetadata | undefined` and what undefined means (no metadata
found), and reference the internal helpers/keys used (`getOwnReflectMetadata`,
`controllerOpenApiMetadataReflectKey`) for clarity; place the JSDoc immediately
above the getControllerOpenApiMetadata declaration and keep it concise and
consistent with other public API docs in the package.

In
`@packages/framework/http/libraries/open-api/src/metadata/calculations/v3Dot2/getControllerOpenApiMetadata.ts`:
- Around line 6-13: Add a JSDoc comment for the public function
getControllerOpenApiMetadata describing its purpose (retrieves controller
OpenAPI metadata via reflect metadata), document the parameter target (object)
and the return type ControllerOpenApiMetadata | undefined, and mention that it
uses getOwnReflectMetadata with controllerOpenApiMetadataReflectKey; follow the
style and wording used in the v3Dot1 counterpart to keep consistency across
versions.

In
`@packages/framework/http/libraries/openapi-validation/src/v3Dot2/pipes/OpenApiValidationPipe.ts`:
- Around line 35-233: The two implementations of OpenApiValidationPipe (v3Dot1
and v3Dot2) duplicate logic; extract the common behavior into a shared base
class or utilities and have the version-specific classes only supply differences
(types, import SCHEMA_ID, and content-type mapping). Concretely, create a
BaseOpenApiValidationPipe that contains execute, `#getOrInitAjv`, and
`#resolveContentType` logic using generic type parameters or abstract getters for
the OpenAPI object type and SCHEMA_ID, then refactor the v3Dot2
OpenApiValidationPipe to extend BaseOpenApiValidationPipe and override/implement
only the version-specific pieces (e.g., providing this.#openApiObject type,
SCHEMA_ID constant, and any type aliases), doing the same for v3Dot1 so both
implementations reuse the shared logic.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/getPath.spec.ts`:
- Around line 6-9: Add test tuples to the existing describe.each<[string,
string, string]> table (the array used in the 'having %s' test) that cover a
non-leading-slash path and an absolute URL; for example include cases like
['non-leading path', 'users', '/users'] and ['absolute url',
'http://example.com/users?name=John', '/users'] so the getPath extraction logic
(exercised by the 'having %s' test) is validated for paths without a leading
slash and for full absolute URLs with query strings.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/getPath.ts`:
- Around line 1-11: getPath currently slices absolute URLs and can return
host-prefixed values (e.g., "//host/users"); update getPath(url: string) to
normalize absolute URLs before extracting the path: detect absolute forms (start
with "http://" or "https://") and obtain the pathname (e.g., via the URL
constructor or by stripping scheme+host) then remove any query string; ensure
you still handle relative URLs and queries the same way so the function always
returns only the path portion (e.g., "/users").

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot1/getOperationObject.ts`:
- Around line 23-31: Replace the broad Record<string, ...> cast and direct
indexing of pathItemObject with a safe key check: first validate that method is
one of the OpenAPI operation keys (e.g.,
'get','put','post','delete','options','head','patch','trace') and that (method
in pathItemObject) is true, then perform a typed index into pathItemObject
(e.g., (pathItemObject as OpenApi3Dot1PathItemObject)[method as keyof
OpenApi3Dot1PathItemObject]) to assign operationObject; if the key is missing
keep throwing the existing InversifyValidationError using
InversifyValidationErrorKind.validationFailed. Ensure you use the existing
variables pathItemObject, method, and operationObject in the guard to avoid the
unsafe Record<string, ...> cast.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot1/inferContentType.ts`:
- Around line 11-21: The current inferContentType logic can throw a runtime
TypeError when requestBodyObject.content is missing or not an object and also
gives an inaccurate message when there are zero content types; update the guard
in inferContentType to first validate that requestBodyObject.content is a plain
object and that Object.keys(requestBodyObject.content) yields at least one
entry, throw an InversifyValidationError (using
InversifyValidationErrorKind.validationFailed) with a clear message for the
zero-content case, and only return contentTypes[0] when contentTypes.length ===
1; reference requestBodyObject.content, contentTypes, inferContentType,
InversifyValidationError and InversifyValidationErrorKind when making the
change.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot2/getOperationObject.spec.ts`:
- Around line 19-67: Add a unit test that covers uppercase HTTP methods:
duplicate the existing "having a pathItemObject with the method" scenario but
set methodFixture to 'GET' (uppercase) and assert
getOperationObject(openApiObjectFixture, methodFixture, pathFixture) still calls
getPathItemObject(openApiObjectFixture, pathFixture) and returns the same
operationObjectFixture; this ensures getOperationObject correctly normalizes or
handles uppercase methods when looking up pathItemObject entries.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot2/getOperationObject.ts`:
- Around line 15-31: The lookup in getOperationObject uses the raw method and a
wide Record<string, OpenApi3Dot2OperationObject> cast which hides non-operation
keys and will miss uppercase methods; normalize the incoming method to lowercase
(e.g., const methodKey = method.toLowerCase()) and use a typed key lookup
against OpenApi3Dot2PathItemObject (cast to keyof OpenApi3Dot2PathItemObject)
instead of Record<string,...> so you only access known operation properties;
keep the existing InversifyValidationError logic when the operation is
undefined.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot2/inferContentType.ts`:
- Around line 11-21: The inferContentType logic should guard for a
missing/nullable requestBodyObject.content and handle zero vs multiple entries
distinctly: first normalize contentTypes = requestBodyObject.content ?
Object.keys(requestBodyObject.content) : []; then if contentTypes.length === 1
return that value; if length === 0 throw an InversifyValidationError
(InversifyValidationErrorKind.validationFailed) with a message stating no
content type provided for method ${method}; otherwise (length > 1) throw the
existing multi-content error including contentTypes.join(', ') to preserve
current behavior.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/pipes/v3Dot2/OpenApiValidationPipe.int.spec.ts`:
- Around line 279-290: The test block "when a valid POST /users request is made
with single content type and no Content-Type header" is sending a Content-Type
header in the beforeAll fetch call, so change the fetch invocation inside that
describe/beforeAll to omit the 'Content-Type' header (remove headers or pass an
empty headers object) so the fallback/content-type inference branch is actually
exercised; ensure you update the fetch call in this spec (the beforeAll that
sets response) and keep the body as JSON stringified as-is.

---

Duplicate comments:
In
`@packages/framework/http/libraries/openapi-validation/src/validation/pipes/v3Dot2/OpenApiValidationPipe.int.spec.ts`:
- Around line 57-90: The test currently throws inside the httpServer.listen
callback and lacks an error listener, which can cause hangs; update the Promise
returned by createServer so it rejects on startup errors by attaching an
httpServer.on('error', handler) before calling httpServer.listen and calling
reject(error) from that handler, and replace the throw when address is
null/typeof string with reject(new Error(...)); ensure you remove the 'error'
listener after resolving or rejecting and keep the existing shutdown
implementation and resolve(server) behavior intact so resources are cleaned up.

---

Nitpick comments:
In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/buildCompositeValidationHandler.spec.ts`:
- Around line 19-154: Replace the outer describe labels that start with "having
..." with the repo's naming convention "when called, and [condition]" for each
scenario around buildCompositeValidationHandler: change "having non object input
params" → "when called, and given non-object input params"; "having null input
params" → "when called, and given null input params"; "having empty handler map
and object input params" → "when called, and given an empty handler map and
object input params"; and "having non handler map and object input params with
right discriminator" → "when called, and given a non-empty handler map and an
object input with the matching discriminator". Keep the inner test bodies and
the nested "when called" blocks consistent (remove or merge duplicate nested
"when called" labels if needed) and leave calls to
buildCompositeValidationHandler, ajvFixture, discriminatorHandlerPair, and
handlerMock unchanged.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/getMimeType.spec.ts`:
- Around line 6-39: Rename the outer table-driven describe.each title from
'having %s' to the standard pattern 'when called, and %s' and remove the nested
describe('when called', ...) wrapper so the beforeAll and it blocks live
directly under the outer describe; keep the getMimeType calls and expectations
unchanged so each case reads "when called, and [condition]".

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot1/getRequestBodyObject.ts`:
- Around line 39-40: Rename the misspelled variable
derreferencedRequestBodyObject to dereferencedRequestBodyObject throughout
getRequestBodyObject (update its declaration and every usage/reference),
ensuring any subsequent assignments or checks that reference
derreferencedRequestBodyObject are updated to the new name so the function
continues to compile and behave the same.

In
`@packages/framework/http/libraries/openapi-validation/src/validation/calculations/v3Dot2/getRequestBodyObject.ts`:
- Around line 39-40: Rename the misspelled variable
derreferencedRequestBodyObject to dereferencedRequestBodyObject in
getRequestBodyObject (and mirror the same rename in the v3.1 implementation),
updating all references including the declaration and usages at the noted
positions (lines referenced in the review: the initial declaration and
subsequent references around where it's used—e.g., the occurrences previously at
lines 66, 68-70, and 73) so the identifier is consistent across the file and
between versions.

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@openspec/changes/add-openapi-body-validation/proposal.md`:
- Line 13: The proposal currently states that the original `@Validate()` +
`@Body()` approach is replaced but lacks a migration note; add a concise
"Migration" subsection to the proposal that shows a before/after example
converting `@Validate()` + `@Body()` usage to the new pipe-based approach, state
the compatibility expectation (e.g., supported, deprecated, or removed) for
`@Validate()`, `@Body()`, and `PipeMetadata`, and mention any necessary steps
(e.g., updating to the new pipe that requires request context) so adopters know
how to migrate; reference the symbols `@Validate()`, `@Body()`, and
`PipeMetadata` in that subsection.

In
`@packages/framework/http/libraries/openapi-validation/src/metadata/decorators/ValidatedBody.spec.ts`:
- Around line 110-355: The tests repeat identical setup for
requestFixture/responseFixture/bodyFixture/methodFixture/urlFixture/options and
expected BodyValidationInputParam across many describe blocks; refactor by
creating a TestFixture class (e.g., BodyHandlerTestFixture) with static builders
that produce the options object (matching
CustomParameterDecoratorHandlerOptions) and expected result, and helper methods
to call handler and return result; update each describe to call the fixtures
instead of duplicating setup and keep references to handler, getMimeType,
BodyValidationInputParam, and validatedInputParamBodyType so behavior and
assertions remain unchanged.