@techspokes/typescript-wsdl-client 0.39.0 → 1.0.1

package/docs/releases/v1.0.1.md

@@ -0,0 +1,38 @@
+# TypeScript WSDL Client v1.0.1
+
+## Reliable npmjs Publication for the Stable Contract
+
+Version 1.0.1 delivers the stable contract intended for 1.0 with corrected npm 12 package validation and an npmjs-only release path.
+
+## What This Improves
+
+Maintainers can publish with the tested npm 12 toolchain without the package-content validator rejecting npm's package-keyed JSON output. The validator remains compatible with npm 11 for local and maintenance workflows.
+
+Package delivery now has one authoritative registry. The guarded release workflow publishes only to npmjs with provenance and no longer grants or uses GitHub Packages capability.
+
+## Highlights
+
+- Preserves the stable TypeScript, OpenAPI, Fastify, app, test-generation, and programmatic contracts.
+- Accepts the package manifest formats emitted by npm 11 and npm 12.
+- Pins the tested npm release used by publication automation.
+- Publishes packages only to npmjs with provenance.
+- Removes the legacy GitHub Packages distribution and prevents recreation.
+- Keeps the abandoned `v1.0.0` candidate and marker as immutable release evidence.
+
+## Upgrade Notes
+
+No generated-code or runtime migration is required relative to `0.40.1`. Consumers must continue using Node.js 24 or newer.
+
+Version `1.0.0` was permanently abandoned before npmjs publication. Install `1.0.1` as the first supported stable package.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated with npm 11 and npm 12.
+- The npm publication lifecycle passed with npm 12 in dry-run mode.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v1.0.1`.

package/docs/roadmap/README.md

@@ -1,6 +1,6 @@
 # Version 1.0 Roadmap Plan
 
-Detailed plan for moving `@techspokes/typescript-wsdl-client` from the current `0.x` line to a stable `1.0.0` release.
+Completed plan for moving `@techspokes/typescript-wsdl-client` from the `0.x` line to the stable `1.0.0` release.
 
 See the root [README.md](../../README.md) for project overview and the root [ROADMAP.md](../../ROADMAP.md) for the public roadmap summary.
 
@@ -8,20 +8,20 @@ See the root [README.md](../../README.md) for project overview and the root [ROA
 
 This plan turns the 1.0 roadmap into implementation slices that can be picked up independently. Each slice has its own plan document with scope, testing strategy, acceptance gates, and release implications.
 
-The plan is optimized for preserving quality. The contract and compatibility baselines now exist, choice union mode is shipped, JSON array streaming is shipped, `xs:anyAttribute` wildcard bags are shipped, the conformance framework is wired into validation gates, and IDE-owned TypeScript diagnostics were aligned with the scoped test layout in `0.39.0`. The remaining readiness work is to review the explicit partial, diagnostic, and unsupported capability decisions, then run the final release candidate gate pass.
+The plan preserves the stable 1.0 contract. Choice union mode, JSON array streaming, `xs:anyAttribute` wildcard bags, stage-specific conformance, executable unsupported diagnostics, and repeatable release gates shipped before or with `1.0.0`.
 
 ## Route Summary
 
 | Slice                 | Document                                                                     | Status            | Outcome                         |
 |-----------------------|------------------------------------------------------------------------------|-------------------|---------------------------------|
-| Contract audit        | [Contract Audit](v1.0-contract-audit.md)                                     | baseline complete | Public surfaces match behavior  |
+| Contract audit        | [Contract Audit](v1.0-contract-audit.md)                                     | complete          | Public surfaces match behavior  |
 | OpenAPI compatibility | [OpenAPI Fastify Compatibility](v1.0-openapi-fastify-compatibility.md)       | baseline complete | Schema strategy is proven       |
 | Choice union mode     | [Choice Union Mode](v1.0-choice-union-mode.md)                               | complete          | Implemented in `0.26.0`         |
 | JSON array streaming  | [JSON Array Streaming](v1.0-json-array-streaming.md)                         | complete          | Implemented in `0.28.0`         |
 | Conformance framework | [Capability Conformance Framework](v1.0-capability-conformance-framework.md) | gate wired        | Pipeline claims are test-backed |
 | WSDL coverage matrix  | [WSDL Coverage Matrix](v1.0-wsdl-coverage-matrix.md)                         | baseline complete | Public support is test-backed |
 | `xs:anyAttribute` bag | [`xs:anyAttribute` Wildcard Bag](v1.0-xs-anyattribute-wildcard-bag.md)        | complete          | Implemented in `0.36.0`         |
-| Release candidate     | [Release Candidate Gates](v1.0-release-candidate-gates.md)                   | next              | 1.0 release is repeatable       |
+| Release candidate     | [Release Candidate Gates](v1.0-release-candidate-gates.md)                   | complete          | 1.0 release is repeatable       |
 
 ## Execution Order
 
@@ -47,7 +47,7 @@ The registry, fixture strategy, compile runner, client evidence, OpenAPI evidenc
 
 ### Slice 6: WSDL Coverage Matrix
 
-The WSDL matrix rows now exist as conformance registry entries with compile, client, OpenAPI, gateway runtime, generated-test, app, documentation, and release-gate evidence. The next work is to keep those rows current, confirm the remaining partial and terminal rows are accepted 1.0 decisions, and prepare release candidate gates.
+The WSDL matrix rows now exist as conformance registry entries with compile, client, OpenAPI, gateway runtime, generated-test, app, documentation, and release-gate evidence. Version `0.40.1` accepts the remaining partial and terminal rows as the 1.0 boundary. Keep those rows current while preparing release candidate gates.
 
 ### Slice 7: xs:anyAttribute Wildcard Bag
 
@@ -57,11 +57,11 @@ The [`xs:anyAttribute` wildcard bag plan](v1.0-xs-anyattribute-wildcard-bag.md)
 
 Run the release candidate gates after feature work and documentation have converged. This slice validates docs, tests, generated examples, package contents, skill artifact, release notes, and provenance workflow readiness.
 
-## Remaining Before 1.0
+## 1.0 Release State
 
-- Confirm each remaining partial, diagnostic, and unsupported matrix row is an accepted 1.0 decision.
-- Confirm `docs/supported-patterns.md` still matches the generated matrix.
-- Run the release-candidate gates.
+- Public contract surfaces are audited against implementation and tests.
+- Capability boundaries are documented and backed by executable evidence.
+- Release metadata and the final candidate pass release preflight before tagging.
 
 ## Quality Principles
 

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

@@ -125,7 +125,7 @@ Third-party suites can inform future rows:
 
 The conformance framework should be designed so its fixtures can later seed a standalone public project, tentatively named `wsdl-conformance-fixtures`.
 
-The public fixture project would be an experimental, curated corpus of small WSDL and XSD fixtures for SOAP client and code-generation tools. It should not claim to be an official standards suite. It should provide practical, source-backed examples for valid, partial, diagnostic, unsupported, recovery, and real-world-compatible behaviors.
+The public fixture project would be an experimental, curated corpus of small WSDL and XSD fixtures for SOAP client and code-generation tools. It should not claim to be an official standards' suite. It should provide practical, source-backed examples for valid, partial, diagnostic, unsupported, recovery, and real-world-compatible behaviors.
 
 The public corpus should preserve clean licensing and clear provenance. Do not copy external corpora wholesale. Prefer original minimized fixtures derived from standards, profiles, and observed real-world patterns.
 
@@ -152,11 +152,11 @@ The corpus should be explainable. Each fixture should say what behavior it exerc
 
 ## Decision Framework
 
-Use this framework before changing a capability from `research` to a final status. The decision should optimize for truthful generation, deterministic output, and maintainable SOAP modernization rather than broad standards completeness.
+Use this framework before changing a capability from `research` to a final status. The decision should optimize for truthful generation, deterministic output, and maintainable SOAP modernization rather than broad standards' completeness.
 
 First decide whether the construct is important enough for this project. Favor support when the feature is common in WSDLs, important for enterprise modernization, or already required by existing generated outputs. Favor deferral when the feature is rare, can be worked around, or requires a runtime contract outside the current product surface.
 
-Then decide whether the construct can be modeled honestly in `catalog.json`. If the catalog can represent the shape without losing semantics, support or partial support may be appropriate. If the catalog would hide polymorphism, transport behavior, binary parts, external network policy, or runtime ambiguity, prefer a diagnostic or unsupported decision.
+Then decide whether the construct can be modeled honestly in `catalog.json`. If the catalog can represent the shape without losing semantics, support or partial support may be appropriate. If the catalog hid polymorphism, transport behavior, binary parts, external network policy, or runtime ambiguity, prefer a diagnostic or unsupported decision.
 
 Then check downstream stages. A `supported` row must work through every relevant stage. A feature that compiles but cannot be represented in generated TypeScript, OpenAPI, gateway runtime, or generated tests should be `partial` unless those stages do not apply.
 
@@ -170,7 +170,7 @@ Use these decisions:
 - `defer`: keep a fixture and rationale, but do not claim support yet.
 - `out-of-scope`: document that the feature is intentionally outside the 1.0 product contract.
 
-When full support is clearly local, deterministic, and representable, implement it rather than leaving unnecessary diagnostics. When full support would imply semantics the generator cannot preserve, prefer diagnostics over partial, misleading output.
+When full support is clearly local, deterministic, and representable, implement it rather than leaving unnecessary diagnostics. When full support would imply semantics the generator cannot preserve, prefer diagnostics to partial, misleading output.
 
 ## Phase 1 Decisions
 
@@ -437,7 +437,7 @@ The runner should perform these steps:
 7. Pass `clientDir`, `catalogFile`, `versionSlug`, and `serviceSlug` to `generateGateway`.
 8. Type-check generated client and gateway artifacts together.
 9. Dynamically import `<temp>/gateway/plugin.ts`.
-10. Register the plugin with `Fastify({logger: false})` and the row's mock operations client.
+10. Register the plugin with `Fastify({logger: false})` and the row's mock operations' client.
 11. Resolve each request path from the generated OpenAPI operation when possible.
 12. Execute `fastify.inject` and run row-specific status and body assertions.
 
@@ -547,7 +547,9 @@ Acceptance criteria:
 
 Phase 5 is implemented. Keep this section as the baseline for conformance gate ownership.
 
-`npm run test:conformance` remains the focused maintainer command for WSDL capability rows. `npm test` and `npm run ci` cover conformance through broad Vitest discovery, so release preflight does not run a duplicate full conformance pass. Release preflight instead runs a cheap `conformance-gate` script check that fails if the focused command disappears, if `npm test` becomes scoped away from `test/conformance`, or if `npm run ci` stops running the broad test command.
+`npm run test:conformance` remains the complete maintainer command for WSDL capability rows. Stage commands under `test:conformance:<stage>` provide contracts, compile, client, OpenAPI, gateway, generated-test, and app feedback without running unrelated evidence layers. `npm test` and `npm run ci` cover the canonical full suite through broad Vitest discovery, so release preflight does not run a duplicate full conformance pass. Release preflight instead runs a cheap `conformance-gate` script check that fails if the full command disappears, if `npm test` becomes scoped away from `test/conformance`, or if `npm run ci` stops running the broad test command.
+
+The complete suite generates consumer-style projects and launches nested TypeScript and Vitest processes. A maintained Windows run takes about three to four minutes. Maintainers and agents should allow at least six minutes and inspect the active process before diagnosing a quiet interval as a stall.
 
 Acceptance criteria:
 
@@ -557,9 +559,9 @@ Acceptance criteria:
 - Full conformance can run locally before `1.0.0`.
 - Release notes can cite capability IDs for behavior changes.
 
-## Phase 6: WSDL Inspector
+## Post-1.0 WSDL Inspector
 
-Build the inspector after the registry has enough stable coverage to be useful. Start with a programmatic API and internal CLI output before committing to public command semantics.
+The WSDL inspector is explicitly deferred until after `1.0.0`. Build it after the registry has enough stable coverage to be useful, starting with a programmatic API and internal CLI output before committing to public command semantics.
 
 Acceptance criteria:
 
@@ -568,13 +570,13 @@ Acceptance criteria:
 - Human output includes status, limitation, and workaround text.
 - Inspector findings link back to matrix evidence.
 
-## Open Decisions
+## Post-1.0 Decisions
 
-- Decide which inspector output format becomes public before `1.0.0`.
+- Decide whether an inspector output format should become public.
 - Decide whether docs should remain manually maintained or eventually generated from the registry.
 
 ## Release Implications
 
-This framework is 1.0 readiness infrastructure. It can ship incrementally in `0.30.x` or later patch releases as tests, docs, and diagnostics improve.
+This framework is 1.0 readiness infrastructure. Stage-specific maintainer commands ship in `0.40.1`, while the canonical full suite stays release-blocking.
 
-Do not block the first conformance slice on the WSDL inspector. The registry and runner create the durable foundation; the inspector should reuse that foundation after it proves useful.
+Do not block `1.0.0` on the WSDL inspector. The registry and runner create the durable foundation; the post-1.0 inspector should reuse that foundation after it proves useful.

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

@@ -1,6 +1,6 @@
 # Version 1.0 Contract Audit
 
-Status: baseline completed in `0.25.2`; ongoing as release hygiene.
+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`.
 
@@ -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.38.x` line. Choice union mode, JSON array streaming, conformance gate wiring, baseline WSDL coverage, wildcard attribute bags, and the dependency refresh must be treated as shipped work, while final release-candidate gates remain the active 1.0 work.
+`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
 
@@ -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.35.x` work accurately.
+- `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.

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

@@ -1,6 +1,6 @@
 # Version 1.0 Release Candidate Gates
 
-Status: remaining final release preparation for `1.0.0`.
+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.
 
@@ -33,19 +33,21 @@ Run `npm run docs:validate`. Confirm README, CLI reference, API reference, confi
 
 ### Test Gate
 
-Run `npm test`. Confirm unit, snapshot, integration, and conformance suites cover the 1.0 contract.
+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
 
-Run `npm run test:conformance` when changing capability rows or fixture-backed behavior. Confirm `npm test` and `npm run ci` keep broad Vitest discovery so `test/conformance` stays covered, and confirm release preflight reports a passing `conformance-gate` script check.
+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
 
-Run `npm run smoke:pipeline`. Confirm the canonical weather fixture still generates the full stack.
+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
 
-Run `npm run ci`. Confirm build, typecheck, docs validation, package validation, skill validation, tests, and smoke pipeline pass together.
+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
 
@@ -57,7 +59,9 @@ Run Node 24 as the supported Node.js floor and Node 26 as the current line in CI
 
 ### Release Gate
 
-Run `npm run release:preflight -- v1.0.0` during release preparation. Confirm release notes, changelog, dependency pins, conformance wiring, generated examples, CI, and skill packaging pass.
+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.
 

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

@@ -34,6 +34,16 @@ Each matrix row should have a minimal fixture, an expected support status, and a
 - 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.
@@ -159,7 +169,7 @@ Partial rows must prove only the documented subset. External `PolicyReference` s
 
 ### Next Slice
 
-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.
+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:
 
@@ -169,7 +179,7 @@ Work items:
 - 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.
+- 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