@techspokes/typescript-wsdl-client 0.34.0 → 0.36.0

package/docs/roadmap/v1.0-capability-conformance-framework.md

@@ -318,7 +318,7 @@ Start with these capability IDs:
 | `multi-binding-first-soap` | partial | success with documented behavior |
 | `external-policy-reference` | partial | success with documented limitation |
 | `deep-composition-sequence` | supported | success |
-| `xs-anyattribute` | partial | success with metadata retention |
+| `xs-anyattribute` | supported | success with wildcard attribute bag evidence |
 | `mtom-xop-attachment` | unsupported | error or research |
 
 Acceptance criteria:
@@ -481,7 +481,7 @@ Every row with a `gateway` expectation should at least prove plugin import and r
 
 For supported rows, prefer one accepted request with a SOAP-wrapper-shaped mock response and an assertion on the generated success envelope. Add one rejected request only when the generated OpenAPI schema can express a meaningful invalid payload for that capability.
 
-For partial rows, prove the documented subset and avoid implying full support. For `xs-anyattribute`, gateway evidence should prove generation and runtime do not emit or require wildcard attribute bags. For external `PolicyReference`, gateway evidence should prove no generated inbound security requirement appears unless configured elsewhere.
+For partial rows, prove the documented subset and avoid implying full support. External `PolicyReference` should not imply fetched or enforced external policy. The `xs-anyattribute` row is supported once generated TypeScript, OpenAPI, gateway, generated-test, and app evidence prove the configured wildcard attribute bag.
 
 For multi-binding rows, assert that the gateway route calls the operation selected by the deterministic first SOAP binding behavior. Do not implement explicit binding selection in this slice.
 

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

@@ -41,7 +41,7 @@ This slice prevents later work from building on ambiguous behavior. Choice union
 
 ### Roadmap State
 
-`ROADMAP.md` must reflect the current released `0.30.x` line. Choice union mode and JSON array streaming must be treated as shipped work, while capability conformance, WSDL coverage, and release-candidate gates remain the active 1.0 work.
+`ROADMAP.md` must reflect the current released `0.35.x` line. Choice union mode, JSON array streaming, conformance gate wiring, and baseline WSDL coverage must be treated as shipped work, while final release-candidate gates remain the active 1.0 work.
 
 ### Release Metadata
 
@@ -63,7 +63,7 @@ Add negative tests only for newly identified contract gaps that a follow-up slic
 
 ## Acceptance Criteria
 
-- `ROADMAP.md` names released `0.30.x` work accurately.
+- `ROADMAP.md` names released `0.35.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.

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

@@ -29,7 +29,7 @@ The release candidate gates define what must be true before tagging `v1.0.0`. Th
 
 ### 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 and JSON array streaming.
+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
 
@@ -53,7 +53,7 @@ Run the generated example freshness check through release preflight. Confirm com
 
 ### Node Gate
 
-Run the supported Node.js floor and the newest active Node.js line in CI before the release candidate is accepted.
+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
 
@@ -67,7 +67,9 @@ Run `npm run release:preflight -- v1.0.0` during release preparation. Confirm re
 - 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

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

@@ -1,25 +1,25 @@
 # Version 1.0 WSDL Coverage Matrix
 
-Status: generated-test, app evidence, and validation-gate wiring shipped before `1.0.0`.
+Status: baseline support registry expanded through `0.35.0`; generated-test evidence, app evidence, and validation-gate wiring 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`. Client, OpenAPI, gateway runtime, generated-test, and app evidence now prove the current supported and partial rows, and terminal rows have executable diagnostics. `npm test` and `npm run ci` cover the conformance suite through broad Vitest discovery, and release preflight verifies that the script wiring remains intact.
+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`. 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 should feed the conformance registry, align with `docs/supported-patterns.md`, and protect 1.0 from silent miscompilation.
+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 feature must compile and generate aligned client, OpenAPI, and gateway artifacts where applicable. An unsupported feature must fail with a clear diagnostic or be documented as intentionally out of scope.
+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 first priority WSDL fixture set.
-- `test/conformance/registry.ts` lists priority rows with status, decision, provenance, and public contract text.
+- `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.
@@ -32,7 +32,7 @@ Each matrix row should have a minimal fixture, an expected support status, and a
 
 - 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 happy path.
+- Preserve the weather smoke fixture as the canonical end-to-end demo while the copied conformance fixture proves the baseline support claim.
 
 ## Out Of Scope
 
@@ -45,6 +45,13 @@ Each matrix row should have a minimal fixture, an expected support status, and a
 
 | 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       |
@@ -52,7 +59,7 @@ Each matrix row should have a minimal fixture, an expected support status, and a
 | 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`          | partial                 | Metadata retained; generated wildcard attributes deferred |
+| `xs:anyAttribute`          | supported               | Metadata retained; wildcard attribute bag emitted |
 | MTOM/XOP attachments       | unsupported diagnostic  | Keep out of 1.0 scope unless required |
 
 ## Manifest Shape
@@ -97,8 +104,8 @@ Ensure every documented unsupported or partial feature has a corresponding matri
 ## Acceptance Criteria
 
 - The matrix includes every roadmap priority feature.
-- Supported rows have compile, client, and OpenAPI evidence when those stages apply.
-- Unsupported or diagnostic rows fail with clear diagnostics, or are explicitly deferred without support claims.
+- 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.
@@ -140,12 +147,12 @@ Rows that should stay compile-terminal:
 
 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. `xs:anyAttribute` should not imply generated wildcard attribute bags. External `PolicyReference` should not imply fetched or enforced external policy.
+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 snapshot whole generated files for conformance rows; assert stable contract surfaces instead.
+- 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.
@@ -159,8 +166,10 @@ 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.
+- Decide whether the remaining partial rows stay partial for 1.0 or need one scoped pre-1.0 fix.
 - Update public docs only when a row status or public contract changes.
 
 ### Verification