@postman-cse/onboarding-bootstrap 2.3.0 → 2.5.0

package/README.md

@@ -6,7 +6,7 @@ Provisions a [Postman workspace](https://learning.postman.com/docs/collaborating
 
 Part of the [Postman API Onboarding suite](https://github.com/postman-cs/postman-api-onboarding-action).
 
-> **Standards-grounded assertion generation.** Every collection this action generates ships with executable contract tests compiled from your spec: JSON Schema (draft-07 / 2020-12) body validation with RFC-checked formats (RFC 3339 timestamps, RFC 4122 UUIDs, RFC 3986 URIs, and more), RFC 9110 `Authorization` scheme checks plus status-code requirement checks (`WWW-Authenticate` on 401, `Allow` on 405, no body on 304, `Content-Range` on 206), RFC 9457 `application/problem+json` error-body validation with RFC 8259 encoding and RFC 8288 `Link` checks, canonical proto3 JSON well-known-type validation for gRPC, version-aware SOAP 1.1/1.2 media-type and Fault-status checks, and GraphQL-over-HTTP media-type/status discipline. The full test inventory and the standard behind each check: [Generated assertions](docs/generated-assertions.md).
+> **Standards-grounded assertion generation.** Every collection this action generates ships with executable contract tests compiled from your spec. For OpenAPI: operation mapping, status-code, `Content-Type`, response-header, request/response body, parameter, security-credential, and `Content-Length` checks, with JSON Schema (draft-07 / 2020-12) body validation, dialect-exclusive keyword rejection, and RFC-checked formats (RFC 3339 timestamps, RFC 4122 UUIDs, RFC 3986 URIs, and more). Layered on top: RFC 9110 status-code, framing, and field-syntax requirements, RFC 9457 `application/problem+json` error bodies with RFC 8259 encoding and RFC 8288 `Link` checks, RFC 6265 `Set-Cookie`, RFC 6797 HSTS and security headers, WHATWG Fetch CORS, RFC 9651 structured fields, RFC 9209 typed `Proxy-Status`, RFC 9421 message signatures, RFC 9530 body digests, `Accept` negotiation, media-type conventions (NDJSON, multipart boundaries, HAL, JSON:API), authentication-scheme credential grammar, preconditions and RFC 6902 / RFC 7386 patch bodies, `Deprecation`/`Sunset` advisories, and OpenAPI links/servers resolution. Beyond REST: canonical proto3 JSON well-known-type validation for gRPC with per-streamed-message shape checks and metadata/trailer wire-conformance, version-aware SOAP 1.1/1.2 media-type and Fault-status checks, GraphQL-over-HTTP media-type/status discipline, static AsyncAPI WebSocket / Socket.IO / MQTT message validation, and static MCP server-manifest contract checks. The full test inventory and the standard behind each check: [Generated assertions](docs/generated-assertions.md) and [Multi-Protocol Contract Assertions](docs/MULTIPROTOCOL-ASSERTIONS.md).
 
 ## Which action should I use?
 
@@ -356,6 +356,8 @@ Dynamic contract failures and warnings use `CONTRACT_` error codes. Remediation
 | `CONTRACT_EXAMPLE_SCHEMA_MISMATCH` | A media-type example does not validate against its own schema. | Fix the example or the schema so the spec is self-consistent; generated requests are built from these examples. |
 | `CONTRACT_ENCODING_MISMATCH` | A generated form-body field does not match its OpenAPI encoding object: a declared multipart per-part `contentType` is missing or different, a binary-typed field was not generated as a file part, or a field declaring a JSON `contentType` carries an unparseable value. | Regenerate the collection or align the encoding object with the intended part layout. |
 | `CONTRACT_ENCODING_HEADERS_NOT_VALIDATED` | A multipart encoding object declares per-part `headers`, which Postman formdata entries cannot carry, so they are not asserted. | Validate per-part headers with dedicated tests if the server depends on them. |
+| `CONTRACT_MULTIPART_ENCODING_FIELD_UNKNOWN` | A form-body `encoding` map names a field that is not a property of the request body schema, so the encoding entry can never apply. | Rename the encoding key to a declared schema property or remove it. |
+| `CONTRACT_WELL_KNOWN_UNREGISTERED` | A path under `/.well-known/` uses a suffix that is not in the vendored IANA Well-Known URIs registry snapshot (RFC 8615). | Register the suffix, use a registered one, or move the resource out of `/.well-known/`. |
 | `CONTRACT_FORM_FIELD_SCHEMA_MISMATCH` | A generated urlencoded or multipart text value does not validate against its scalar property schema. | Fix the spec example feeding the generated body, or correct the property schema. |
 | `CONTRACT_DISCRIMINATOR_NOT_VALIDATED` | A `discriminator` has no sibling `oneOf`/`anyOf` of same-spec `$ref` members (typically allOf-parent inheritance), so its dispatch is not validated. | Restructure to the oneOf-plus-discriminator form, or rely on the still-validated composition keywords. |
 | `CONTRACT_HEADER_SCHEMA_NOT_VALIDATED` | A response header declares an object or otherwise undecodable schema, so its serialized value is checked for presence only. Arrays of scalars are split on commas and validated. | Use a scalar or array-of-scalars header schema, or validate the serialized header form with dedicated tests. |