@techspokes/typescript-wsdl-client 1.1.4 → 1.1.8

package/docs/roadmap/v1.0-choice-union-mode.md

@@ -1,90 +0,0 @@
-# Version 1.0 Choice Union Mode
-
-Status: implemented for `0.26.0`.
-
-This page records the completed `xs:choice` union support behind `--client-choice-mode union`.
-
-See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
-
-## Goal
-
-`0.26.0` completes opt-in `--client-choice-mode union` for TypeScript, OpenAPI, generated gateway schemas, generated mocks, and generated test artifacts. The existing `all-optional` mode remains the default and keeps its current generated output unless a bug is explicitly fixed.
-
-## Completed Scope
-
-- Preserved choice-group metadata during schema compilation.
-- Emitted TypeScript union types for choice groups in union mode.
-- Kept default all-optional TypeScript output stable.
-- Emitted Fastify-compatible OpenAPI schemas that reflect choice exclusivity.
-- Generated mock data that selects a valid choice branch.
-- Generated gateway tests that reject invalid branch combinations.
-- Generated gateway tests that reject missing required choice branches.
-- Updated README, CLI reference, concepts, supported patterns, generated code docs, and production docs.
-
-## Out Of Scope
-
-- Do not make union mode the default before 1.0.
-- Do not change XML runtime mapping for non-choice elements.
-- Do not solve abstract substitution groups in this slice unless required by choice fixtures.
-
-## Implementation Units
-
-### Catalog Metadata
-
-The compiler preserves catalog metadata for choice groups with stable names, branch element names, branch type names, occurrence constraints, nillable flags, and source order. This lets downstream emitters render deterministic output in both `all-optional` and `union` mode.
-
-### TypeScript Emitter
-
-In `all-optional` mode, the emitter keeps the existing interface shape. In `union` mode, it emits a base object for non-choice fields and combines it with a generated branch union.
-
-The generated union uses peer `?: never` properties so TypeScript rejects payloads containing more than one branch. Optional choice groups include an empty branch where the WSDL permits omitting all choice members.
-
-### OpenAPI Emitter
-
-The schema strategy is the one proven by [OpenAPI Fastify Compatibility](v1.0-openapi-fastify-compatibility.md). The generated request-body schema uses `oneOf` over containing-object branches with peer `not` constraints.
-
-Choice member properties remain on the containing object, required non-choice properties stay top-level, and optional choice groups get an empty branch constraint. Closed `oneOf` branches alone were avoided because AJV can remove additional properties before evaluating branch results under Fastify defaults.
-
-### Gateway And Test Emitters
-
-Generated gateway route schemas consume the new OpenAPI shape without hand edits. Generated mock clients select one choice branch in union mode.
-
-Generated validation tests include invalid multi-branch request cases and missing required-branch request cases for top-level request choice groups. Fastify rejection is covered in generated suites.
-
-## Testing Coverage
-
-### Compiler Tests
-
-Coverage asserts catalog metadata for simple, optional, required, nested, attribute-mixed, and sequence-mixed choice groups.
-
-### TypeScript Tests
-
-Coverage checks generated `types.ts` in both `all-optional` and `union` mode. Compile-only tests prove invalid multi-branch payloads fail when union mode is selected.
-
-### OpenAPI Tests
-
-Coverage checks generated schema branches and validates generated specs with the existing OpenAPI validation path.
-
-### Gateway Tests
-
-Coverage checks valid choice request bodies, invalid multi-branch request bodies, and missing required choice request bodies.
-
-### Regression Tests
-
-Snapshot coverage protects default generated output from unintended drift.
-
-## Acceptance Criteria
-
-Satisfied by `0.26.0`:
-
-- `--client-choice-mode union` changes generated output in a test-backed way.
-- `all-optional` mode remains default and stable.
-- TypeScript rejects invalid multi-branch payloads in union mode where the object model can represent exclusivity.
-- OpenAPI schemas validate with the project validator.
-- Generated Fastify routes accept valid branch payloads.
-- Generated Fastify routes reject invalid branch combinations through the selected schema strategy.
-- Docs describe both modes and their tradeoffs accurately.
-
-## Release Implications
-
-This slice shipped as the `0.26.0` user-facing feature release. It remains opt-in before 1.0, with no upgrade steps for users who keep the default mode.

package/docs/roadmap/v1.0-contract-audit.md

@@ -1,75 +0,0 @@
-# Version 1.0 Contract Audit
-
-Status: final 1.0 audit completed after `0.40.1`; ongoing as release hygiene.
-
-Plan for keeping public flags, programmatic options, docs, generated behavior, and roadmap statements aligned through `1.0.0`.
-
-See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
-
-## Goal
-
-The contract audit makes every public promise explicit before 1.0. A public promise includes CLI flags, programmatic options, configuration files, generated file shapes, documentation examples, release workflow claims, and roadmap statements.
-
-## Why This Slice Remains Active
-
-This slice prevents later work from building on ambiguous behavior. Choice union mode and JSON array streaming are shipped, so the audit now protects those contracts while WSDL coverage and release-candidate work proceed.
-
-## Ongoing Scope
-
-- Audit CLI flags in `src/cli.ts` against `docs/cli-reference.md`.
-- Audit programmatic options in exported types against `docs/api-reference.md`.
-- Audit configuration file formats against `docs/configuration.md`.
-- Audit generated output claims against snapshots and `examples/generated-output`.
-- Refresh `ROADMAP.md` so shipped work is not listed as future work.
-- Add focused tests for public behavior when the audit finds a real drift risk.
-
-## Out Of Scope
-
-- Do not expand WSDL feature support in this slice.
-- Do not change default generated output unless a contract is already wrong.
-- Do not treat release metadata gaps as feature support.
-
-## Required Findings
-
-### Choice Mode
-
-`--client-choice-mode union` is implemented in `0.26.0`. Audit passes should keep CLI docs, API docs, generated-code docs, supported-pattern docs, tests, and examples aligned with the released opt-in behavior.
-
-### JSON Array Streaming
-
-`format: "json-array"` is implemented in `0.28.0`. The audit should keep every parser, client, OpenAPI, gateway, runtime, and docs surface aligned across both stream formats.
-
-### Roadmap State
-
-`ROADMAP.md` must reflect the current `0.40.x` line. Choice union mode, JSON array streaming, conformance gate wiring, baseline WSDL coverage, wildcard attribute bags, dependency refreshes, and stage-specific conformance commands must be treated as shipped work before final release-candidate gates begin.
-
-### Release Metadata
-
-Tag gaps before `1.0.0` are not blockers by themselves. The audit should only confirm that release-preflight and release workflows catch missing metadata for the target 1.0 release.
-
-## Testing Approach
-
-### Documentation Validation
-
-Run `npm run docs:validate` after documentation changes. This verifies Markdown links and TypeScript fenced snippets.
-
-### Contract Snapshot
-
-Add or update focused tests that inspect CLI option availability and generated metadata defaults. These tests should fail only when public contract surfaces drift from documentation.
-
-### Negative Tests
-
-Add negative tests only for newly identified contract gaps that a follow-up slice can consume. These tests should be skipped or marked as expected failures only if the repository already has an accepted pattern for that.
-
-## Acceptance Criteria
-
-- `ROADMAP.md` names released `0.40.x` work accurately.
-- `docs/roadmap/README.md` links every 1.0 slice.
-- CLI, API, and configuration docs agree on required 1.0 behavior.
-- Known contract gaps are linked to implementation slices.
-- `CHANGELOG.md` has one `docs(roadmap):` entry when audit docs change.
-- `npm run docs:validate` passes.
-
-## Release Implications
-
-This slice can ship as a documentation-only minor release if no behavior changes are made. If tests are added that currently fail or are skipped, the release notes must explain that they are roadmap scaffolding rather than completed support.

package/docs/roadmap/v1.0-json-array-streaming.md

@@ -1,101 +0,0 @@
-# Version 1.0 JSON Array Streaming
-
-Status: implemented for `0.28.0`.
-
-This document records the implementation slice for `format: "json-array"` streaming for SOAP operations that already use the stream configuration model.
-
-See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
-
-## Goal
-
-`0.28.0` completes `format: "json-array"` streaming as a valid JSON array without buffering the full SOAP response. The implementation is compatible with generated clients, OpenAPI output, Fastify routes, generated tests, and production docs.
-
-## Design Direction
-
-JSON array streaming writes an opening bracket with the first record, streams comma-separated JSON records, and writes a closing bracket after the async iterable completes. The implementation preserves backpressure by converting the async iterable into a Node `Readable` stream.
-
-The key researched constraint is error timing. The helper prefetches the first record before sending the first byte, so an upstream error before the first record still returns the normal error envelope. Once the JSON array response has started, a later error truncates the response and clients must treat the JSON parse failure as a failed stream.
-
-## Completed Scope
-
-- Implemented a runtime helper for JSON array streaming.
-- Preserved existing NDJSON behavior.
-- Emitted JSON array route handlers when stream metadata says `format: "json-array"`.
-- Emitted `application/json` OpenAPI content with an array item schema.
-- Generated stream-aware mock clients and tests for JSON array operations.
-- Documented terminal-error behavior for JSON array clients.
-
-## Out Of Scope
-
-- Do not implement streaming request bodies in this slice.
-- Do not change buffered SOAP operations.
-- Do not make JSON array the default stream format.
-
-## Research Findings
-
-### First-Byte Timing
-
-Generated routes prefetch the first record before emitting the first JSON array byte. This preserves normal error envelopes for errors that happen before any record is available, with the tradeoff that response headers wait for the first upstream record.
-
-### Empty Stream Handling
-
-An empty stream returns `[]` with `application/json`. The helper emits a syntactically valid empty array without special route code.
-
-### Backpressure Handling
-
-Tests confirm that the helper does not pull from the async iterable faster than the HTTP stream can write. The coverage mirrors the existing NDJSON backpressure tests.
-
-### Terminal Error Handling
-
-Fastify surfaces stream errors after the JSON array has begun as a destroyed or reset response under inject and as a truncated response to real clients. Production docs and troubleshooting docs describe this as a failed stream.
-
-## Implementation Units
-
-### Runtime Helper
-
-Added `toJsonArray<T>(records: AsyncIterable<T>): Readable` beside `toNdjson`. The helper serializes records with `JSON.stringify`, inserts commas between records, and closes the array when iteration completes.
-
-### Gateway Emitter
-
-Generate stream route handlers that import `toJsonArray` for `json-array` operations and `toNdjson` for `ndjson` operations. The handler must set the media type from stream metadata.
-
-### OpenAPI Emitter
-
-Emit `application/json` with `schema.type = "array"` and `items` pointing at the record schema. Keep `x-wsdl-tsc-stream` metadata so downstream tooling can still identify stream operations.
-
-### Client And Test Emitters
-
-Keep the client method return shape as `StreamOperationResponse<RecordType>`. Generated tests should parse the HTTP response as a JSON array and assert record values.
-
-## Testing Approach
-
-### Unit Tests
-
-Test `toJsonArray` with empty records, one record, multiple records, string escaping, source errors, and backpressure. Mirror the existing `toNdjson` tests where possible.
-
-### OpenAPI Tests
-
-Test that JSON array operations advertise `application/json`, array schema items, and stream extension metadata.
-
-### Gateway Integration Tests
-
-Test Fastify route output for a JSON array stream operation. Assert content type, parseable JSON, and record order.
-
-### Error Tests
-
-Test errors before the first emitted record separately from errors after at least one emitted byte. The expected post-start behavior is a failed or truncated response, not a JSON error envelope.
-
-## Acceptance Criteria
-
-Satisfied by `0.28.0`:
-
-- `format: "json-array"` generates working client, OpenAPI, gateway, and tests.
-- JSON array output is parseable when the source completes normally.
-- Output is streamed incrementally and does not buffer the full response.
-- NDJSON behavior remains unchanged.
-- Terminal-error behavior is documented accurately.
-- `npm test` and `npm run smoke:pipeline` pass.
-
-## Release Implications
-
-This slice shipped as the `0.28.0` user-facing feature release. The release notes state that `json-array` can be selected per operation with `stream-config`, while NDJSON remains the default stream format.

package/docs/roadmap/v1.0-openapi-fastify-compatibility.md

@@ -1,99 +0,0 @@
-# Version 1.0 OpenAPI Fastify Compatibility
-
-Status: compatibility baseline completed for `0.26.0` choice union mode and `0.28.0` JSON array streaming.
-
-Plan for preserving Fastify compatibility as schema output evolves toward `1.0.0`.
-
-See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
-
-## Goal
-
-This slice confirms which OpenAPI 3.1 and JSON Schema constructs are safe for generated Fastify gateways. The completed findings constrain released choice union mode, released JSON array streaming, and any future schema complexity work.
-
-## Why This Slice Remains Active
-
-Fastify compatibility is part of the generated gateway contract. A TypeScript type shape can be correct while the generated OpenAPI schema is unusable for Fastify request validation or response serialization.
-
-## Scope
-
-- Maintain probes for `oneOf`, `anyOf`, and `allOf` request schemas through Fastify validation.
-- Maintain probes for generated response schemas through Fastify serialization where applicable.
-- Maintain probes for streamed routes that omit response serialization schemas.
-- Keep the response-depth safety limit aware of schema composition.
-- Document the allowed schema strategy for choice union mode.
-- Document the allowed schema strategy for JSON array streaming.
-
-## Out Of Scope
-
-- Do not change shipped choice union behavior without new compatibility evidence.
-- Do not change shipped JSON array streaming behavior without new compatibility evidence.
-- Do not change public WSDL feature coverage in this slice.
-
-## Research Questions
-
-### Choice Request Validation
-
-The research determined that `oneOf` with mutually exclusive object branches needs peer exclusion constraints for request bodies. Additional branch exclusion properties are needed to reject payloads that send more than one choice branch.
-
-### Choice Response Serialization
-
-The research determined that generated response schemas should stay conservative unless a future slice proves a stricter strategy. If Fastify serialization becomes fragile, generated route response schemas must stay conservative.
-
-### JSON Array Streaming Schema
-
-The research determined how to advertise an incrementally streamed JSON array in OpenAPI while keeping generated Fastify route schemas valid. Stream routes omit normal response serialization because the response is not a single buffered object.
-
-## Local Fastify Findings
-
-The initial probes use the current project Fastify dependency and `fastify.inject` in `test/integration/fastify-schema-compatibility.test.ts`.
-
-### Choice Request Validation
-
-Fastify's default AJV options remove additional properties when `additionalProperties: false` is present. Because of that, closed `oneOf` branch schemas are not enough for `xsd:choice`: a payload containing both choice fields can be mutated into one valid branch before the `oneOf` result is evaluated.
-
-The allowed request strategy is:
-
-- Put the choice member properties on the containing object schema.
-- Use `oneOf` for exact branch selection.
-- Add peer `not` constraints to each branch so a branch fails when another choice member is present.
-- Keep `additionalProperties: false` at the containing object level when the generator already owns the full object shape.
-
-Do not use bare `anyOf` for exclusive choices. The local probe confirms it accepts a payload containing more than one choice field when branches are open.
-
-### Choice Response Serialization
-
-Keep generated gateway response schemas conservative for this slice. The local probe confirms current envelope-style responses with `anyOf` payload branches serialize under Fastify, so no generator response-schema expansion is required before the choice implementation slice.
-
-### JSON Array Streaming Schema
-
-Keep streamed Fastify routes free of response serialization schemas. The local probe confirms a route can stream an `application/json` array body without registering a Fastify response schema. OpenAPI can advertise the array response, while generated route registration should omit the response schema for streamed handlers.
-
-### Response Schema Complexity
-
-The existing response complexity guard walks `$ref` values inside `allOf`, `anyOf`, and `oneOf`. Unit coverage now locks that behavior so future union work does not bypass the depth safety limit.
-
-## Testing Approach
-
-### Local Fastify Probes
-
-Create focused Vitest tests that instantiate Fastify, register minimal schemas, and call `fastify.inject`. These tests should use the project dependency versions rather than external assumptions.
-
-### Generator Contract Tests
-
-Once a schema strategy is chosen, add tests that assert generated OpenAPI and gateway operation schemas use only approved constructs.
-
-### Compatibility Fixtures
-
-Use small synthetic schemas for compatibility probes. Do not require WSDL fixtures until the generator implementation slices.
-
-## Acceptance Criteria
-
-- A documented schema strategy exists for choice union request bodies.
-- A documented schema strategy exists for choice union response schemas.
-- A documented schema strategy exists for JSON array stream responses.
-- Tests prove the selected strategy against local Fastify behavior.
-- Existing gateway integration tests still pass.
-
-## Release Implications
-
-This slice shipped its released findings through the choice union and JSON array streaming work. Future schema-generation changes must be paired with compatibility probes, snapshot updates, and migration notes when behavior changes.

package/docs/roadmap/v1.0-release-candidate-gates.md

@@ -1,92 +0,0 @@
-# Version 1.0 Release Candidate Gates
-
-Status: completed for the `1.0.0` final candidate.
-
-Plan for validating that `1.0.0` is repeatable, documented, test-backed, and ready to publish.
-
-See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
-
-## Goal
-
-The release candidate gates define what must be true before tagging `v1.0.0`. They turn release readiness into concrete checks rather than subjective confidence.
-
-## Scope
-
-- Verify public docs match shipped behavior.
-- Verify generated examples are current.
-- Verify package contents and agent skill artifact.
-- Verify supported Node.js coverage.
-- Verify provenance publish workflow readiness.
-- Verify release notes and changelog.
-
-## Out Of Scope
-
-- Do not add new generator features in this slice.
-- Do not accept known contract gaps as release notes caveats.
-- Do not publish `1.0.0` until all gates pass.
-
-## Required Gates
-
-### Documentation Gate
-
-Run `npm run docs:validate`. Confirm README, CLI reference, API reference, configuration docs, supported patterns, production docs, and roadmap agree on choice union mode, JSON array streaming, baseline conformance coverage, and Node support.
-
-### Test Gate
-
-Release preflight runs the broad Vitest suite through `npm run ci`. Use focused tests while developing and avoid a separate final `npm test` pass.
-
-### Conformance Gate
-
-Use the narrowest `npm run test:conformance:<stage>` command while changing one evidence layer. Run `npm run test:conformance` when changing capability rows, fixture-backed behavior, shared runner behavior, or the final candidate. Confirm `npm test` and `npm run ci` keep broad Vitest discovery so the canonical full suite stays covered, and confirm release preflight reports a passing `conformance-gate` script check.
-
-Allow at least six minutes for the full command on Windows. It generates several consumer-style projects and may stay quiet while nested TypeScript or Vitest processes run.
-
-### Smoke Gate
-
-Release preflight runs `npm run smoke:pipeline` through `npm run ci`. Use the focused smoke command while developing pipeline changes and avoid a separate final smoke pass.
-
-### CI Gate
-
-Release preflight runs `npm run ci` once for the final candidate. Do not run a separate final CI pass immediately before or after preflight.
-
-### Example Gate
-
-Run the generated example freshness check through release preflight. Confirm committed examples match regenerated output.
-
-### Node Gate
-
-Run Node 24 as the supported Node.js floor and Node 26 as the current line in CI before the release candidate is accepted. Release workflows should run on Node 24, and release preflight should fail if CI stops covering either line.
-
-### Release Gate
-
-Run `npm run release:preflight -- v1.0.0` once on the final uncommitted release tree. Confirm release notes, changelog, dependency pins, conformance wiring, generated examples, CI, and skill packaging pass, then commit the exact validated tree.
-
-Set the release version before preflight. Preflight verifies tracked release files without rewriting them and fails if any preflight step changes tracked content; generated checks and the skill ZIP remain under ignored `tmp/` and `dist/` paths.
-
-The post-release package workflow should run `npm run release:publish-check` before publishing from the tag. It must not rerun full CI because `release:preflight` is the release-blocking gate before the tag is pushed.
-
-## Documentation Checklist
-
-- README names supported 1.0 capabilities accurately.
-- CLI reference lists implemented flags only.
-- API reference lists implemented options only.
-- Configuration docs describe both stream formats.
-- Supported patterns reflects the WSDL matrix.
-- The conformance gate documents `npm run test:conformance`, broad Vitest discovery, and release preflight wiring.
-- The Node gate documents Node 24 as the package floor and Node 26 as the current-line CI check.
-- Production docs describe terminal-error behavior for both stream formats.
-- Release docs include release-preflight validation as a consumer-facing outcome.
-- Migration docs explain any behavior changes since `0.x`.
-
-## Acceptance Criteria
-
-- All required gates pass without skipped 1.0 blockers.
-- `docs/releases/v1.0.0.md` exists and follows the release note structure.
-- `CHANGELOG.md` has a dated `1.0.0` section during release preparation.
-- The package dry-run contents include required runtime templates and docs.
-- The agent skill artifact validates and packages deterministically.
-- The release workflow can publish with provenance after the targeted publish check passes.
-
-## Release Implications
-
-This slice is the final release preparation work. It should produce the `1.0.0` release commit only after all feature slices have shipped or merged into the release branch.

package/docs/roadmap/v1.0-wsdl-coverage-matrix.md

@@ -1,200 +0,0 @@
-# Version 1.0 WSDL Coverage Matrix
-
-Status: baseline support registry expanded through `0.36.0`; generated-test evidence, app evidence, validation-gate wiring, and `xs:anyAttribute` wildcard-bag support shipped before `1.0.0`.
-
-Plan for turning WSDL and XSD support claims into automated, fixture-backed evidence before 1.0. This is the first domain under the [Capability Conformance Framework](v1.0-capability-conformance-framework.md).
-
-The initial fixture-backed compile matrix shipped in `0.30.2` and `0.30.3`, with the baseline support corpus expanded in `0.35.0` and `xs:anyAttribute` promoted to supported in `0.36.0`. Client, OpenAPI, gateway runtime, generated-test, and app evidence now prove the current supported and partial rows, and terminal rows have executable diagnostics. The matrix is now the public baseline support registry. Examples remain demos, while conformance fixtures are the durable support evidence. `npm test` and `npm run ci` cover the conformance suite through broad Vitest discovery, and release preflight verifies that the script wiring remains intact.
-
-See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
-
-## Goal
-
-The project should have an automated WSDL and XSD feature matrix that proves which patterns are supported, partially supported, or rejected with diagnostics. The matrix is the conformance registry, aligns with `docs/supported-patterns.md`, and protects 1.0 from silent miscompilation.
-
-## Design Direction
-
-Each matrix row should have a minimal fixture, an expected support status, and a test that proves the status. A supported or partial feature must compile and generate aligned client, OpenAPI, gateway, generated-test, and app artifacts unless the row documents why a stage is inapplicable. An unsupported, diagnostic, or terminal feature must stop before downstream generation and fail with a clear diagnostic or be documented as intentionally out of scope.
-
-## Shipped Baseline
-
-- `test/conformance/fixtures/` contains the baseline WSDL and XSD support fixture set.
-- `test/conformance/registry.ts` lists baseline support rows with status, decision, provenance, and public contract text.
-- `test/conformance/conformance.test.ts` runs compile-stage expectations for runnable rows.
-- Supported and partial rows generate client artifacts that type-check.
-- Supported and partial rows generate validated OpenAPI specs with targeted contract assertions.
-- Supported and partial rows generate gateway artifacts that type-check and run through Fastify injection.
-- Diagnostic and unsupported rows have executable compiler error expectations.
-- `docs/supported-patterns.md` includes a generated capability evidence matrix.
-- `npm run docs:support-matrix:check` prevents support matrix drift.
-
-## Remaining Scope
-
-- Keep diagnostics executable as more unsupported rows are added.
-- Keep fixture metadata useful for a future public conformance fixture corpus.
-- Preserve the weather smoke fixture as the canonical end-to-end demo while the copied conformance fixture proves the baseline support claim.
-
-## Accepted 1.0 Boundaries
-
-The remaining partial and terminal rows are accepted for `1.0.0`. They are explicit compatibility boundaries rather than unfinished release blockers.
-
-- Abstract complex types remain compile-terminal until polymorphic instance handling is designed.
-- Substitution groups remain compile-terminal until polymorphic element expansion is designed.
-- Multi-binding WSDLs keep deterministic first SOAP binding selection without a new selection option.
-- External `PolicyReference` documents are not fetched, resolved, or enforced.
-- MTOM/XOP attachments remain outside the typed SOAP-to-REST transport contract.
-
-## Out Of Scope
-
-- Do not implement every unsupported WSDL feature in this slice.
-- Do not replace the existing weather fixture for smoke tests.
-- Do not generate the explanatory supported-pattern sections from the registry.
-- Do not add public CLI commands for the inspector until the registry evidence model stabilizes.
-
-## Priority Feature Rows
-
-| Feature                    | Expected 1.0 Status     | Notes                                 |
-|----------------------------|-------------------------|---------------------------------------|
-| Weather document-literal baseline | supported        | Canonical demo also lives in conformance |
-| Complex sequences          | supported               | Nested references, repeated fields, and optional wrappers |
-| Simple restrictions        | supported               | Enumerations, list aliases, and same-name aliases |
-| Simple content attributes  | supported               | `$value` text content and flattened attributes |
-| Documentation propagation  | supported               | Catalog, TypeScript, OpenAPI, and gateway comments |
-| SOAP binding detection     | supported               | SOAP 1.1, SOAP 1.2, and first SOAP binding behavior |
-| Relative XSD imports       | supported               | Local imports with committed companion XSDs |
-| `xs:choice` union mode     | supported               | Implemented in `0.26.0`               |
-| `xs:union`                 | supported               | Simple unions implemented after fixture work |
-| Abstract types             | diagnostic              | Avoid silent concrete treatment       |
-| Substitution groups        | diagnostic              | Avoid silent omission                 |
-| Multi-binding WSDLs        | documented behavior     | First binding or explicit selection   |
-| External `PolicyReference` | partial or diagnostic   | Inline policy already exists          |
-| Deep composition           | supported               | Prove current recursion behavior      |
-| `xs:anyAttribute`          | supported               | Metadata retained; wildcard attribute bag emitted |
-| MTOM/XOP attachments       | unsupported diagnostic  | Keep out of 1.0 scope unless required |
-
-## Manifest Shape
-
-The manifest should be small and reviewable. A JSON or TypeScript manifest is acceptable if tests can import it deterministically.
-
-```json
-{
-  "features": [
-    {
-      "id": "choice-union-simple",
-      "fixture": "choice-union-simple.wsdl",
-      "status": "supported",
-      "commands": ["compile", "client", "openapi", "gateway"]
-    }
-  ]
-}
-```
-
-## Testing Approach
-
-### Matrix Runner
-
-The existing Vitest suite reads the TypeScript registry and runs compile expectations through programmatic APIs. The next runner should generate artifacts into per-case temporary directories and avoid shelling out where direct generator APIs give better diagnostics.
-
-### Supported Feature Tests
-
-For supported rows, assert successful compilation, generated TypeScript type-checking, OpenAPI validation, and gateway schema generation when applicable.
-
-Generated client checks should verify that emitted `client.ts`, `types.ts`, `utils.ts`, and `operations.ts` type-check together. OpenAPI checks should validate the full spec and assert capability-specific schema shapes only where the shape is part of the public contract.
-
-### Diagnostic Feature Tests
-
-For diagnostic rows, assert the exact error class or user-facing message shape. Avoid brittle full-message assertions unless the message is part of the public contract.
-
-Rows marked `diagnostic` should not remain permanent `research` placeholders. If full diagnostics are not implemented in the next slice, the row should say `defer` or carry a clear unresolved decision rather than implying that diagnostic behavior already exists.
-
-### Documentation Tests
-
-Ensure every documented unsupported or partial feature has a corresponding matrix row. This can be a lightweight consistency test that compares feature IDs with anchors or explicit markers in `docs/supported-patterns.md`.
-
-## Acceptance Criteria
-
-- The matrix includes every roadmap priority feature.
-- Supported and partial rows have compile, client, OpenAPI, gateway, generated-test, and app evidence when those stages apply.
-- Unsupported, diagnostic, or terminal rows fail with clear diagnostics, or are explicitly deferred without support claims.
-- `docs/supported-patterns.md` reflects the matrix.
-- No known feature silently miscompiles in matrix coverage.
-- The matrix can run in CI or release preflight without network access.
-
-## Gateway Runtime Evidence
-
-Phase 3 gateway runtime evidence is shipped for the current supported and partial rows. The current matrix now proves the WSDL to client to OpenAPI to Fastify path for rows that claim support or partial support.
-
-Use [Capability Conformance Framework](v1.0-capability-conformance-framework.md) as the detailed implementation baseline. This section defines the WSDL-matrix-specific shipped scope.
-
-### Phase 3 Shipped Scope
-
-- Optional `gateway` expectations exist in the conformance type model.
-- Gateway artifacts are generated from each relevant row's OpenAPI document.
-- The generated `catalog.json` is written before gateway generation.
-- Generated gateway artifacts type-check with the generated client artifacts.
-- Mock operations clients and `fastify.inject` assertions cover HTTP behavior.
-- Diagnostic and unsupported rows stop at compile.
-- The generated public support matrix remains status-focused.
-
-### Phase 3 Row Scope
-
-Rows that should gain gateway evidence:
-
-- `choice-union-simple`
-- `xs-union-simple-type`
-- `multi-binding-first-soap`
-- `external-policy-reference`
-- `deep-composition-sequence`
-- `xs-anyattribute`
-
-Rows that should stay compile-terminal:
-
-- `abstract-complex-type`
-- `substitution-group-element`
-- `mtom-xop-attachment`
-
-### Phase 3 Runtime Expectations
-
-Each gateway-enabled row should prove plugin import, plugin registration, and at least one `fastify.inject` request when route behavior is relevant. Assertions should inspect the generated success or error envelope, not just the existence of generated files.
-
-Partial rows must prove only the documented subset. External `PolicyReference` should not imply fetched or enforced external policy. The `xs:anyAttribute` row is supported through generated wildcard attribute bag evidence.
-
-### Phase 3 Gotchas
-
-- Do not overclaim `supported` when gateway behavior is relevant but unproven.
-- Do not snapshoot whole generated files for conformance rows; assert stable contract surfaces instead.
-- Do not share temporary output directories across rows.
-- Do not let diagnostic or unsupported rows proceed to client, OpenAPI, or gateway generation.
-- Do not add a public inspector command in this slice.
-
-### Next Slice
-
-Version `0.40.1` adds stage-specific conformance commands and records the accepted 1.0 boundaries. After that release, the next slice is release-candidate preparation. Run it before adding more feature rows unless a production bug requires a focused diagnostic or support decision.
-
-Work items:
-
-- Keep `npm run test:conformance` as the focused command for maintainers who want only conformance checks.
-- Keep `npm test` and `npm run ci` broad enough for Vitest to discover `test/conformance`.
-- Keep release preflight's `conformance-gate` script check aligned with the package scripts.
-- Keep release preflight's Node gate aligned with the package engine, Node 24 CI coverage, Node 26 CI coverage, and Node 24 release workflows.
-- Confirm release preflight runtime remains acceptable.
-- Keep diagnostic and unsupported rows stopped at compile.
-- Preserve the accepted partial and terminal 1.0 decisions unless production evidence requires a patch.
-- Update public docs only when a row status or public contract changes.
-
-### Verification
-
-Run these commands before the slice is considered ready:
-
-```bash
-npm run test:conformance
-npm run typecheck
-npm run docs:validate
-npm test
-```
-
-Run `npm run smoke:pipeline` if the gateway generator or pipeline behavior changes.
-
-## Release Implications
-
-This slice may reveal features that should be implemented before 1.0. It may also justify explicit post-1.0 deferrals if diagnostics and documentation are strong enough.