@techspokes/typescript-wsdl-client 0.36.0 → 1.0.1

package/docs/releases/v0.37.0.md

@@ -0,0 +1,33 @@
+# TypeScript WSDL Client v0.37.0
+
+## Faster Release Publishing
+
+This release keeps the full release gate before tagging and makes the post-release package workflow more focused.
+
+## What This Improves
+
+Publishing from an already validated release tag no longer reruns the full CI, conformance, and smoke pipeline inside the package workflow. The workflow now performs the publish-specific checks needed before npm and GitHub Packages publication: build, typecheck, agent skill validation, and package contents validation.
+
+Release preflight now also verifies that the publish workflow stays targeted. This keeps the release safety boundary explicit: run full CI and conformance before pushing the tag, then run package-specific validation from the immutable tag before publishing.
+
+## Highlights
+
+- Adds `npm run release:publish-check` for targeted post-release package validation.
+- Updates the package publishing workflow to use the targeted publish check.
+- Adds release preflight coverage for the publish workflow gate.
+- Updates the 1.0 roadmap to reflect the `0.36.0` wildcard-bag baseline.
+
+## Upgrade Notes
+
+No special upgrade steps.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v0.37.0`.

package/docs/releases/v0.38.0.md

@@ -0,0 +1,35 @@
+# TypeScript WSDL Client v0.38.0
+
+## Dependency Floor Refresh
+
+This release refreshes maintained dependency floors after the merged dependency updates and keeps generated app scaffolds aligned with the package baseline.
+
+## What This Improves
+
+Developers get current dependency minimums in both the published package and newly scaffolded Fastify gateway apps. The runtime YAML dependency moves to the latest `js-yaml` patch in the current line, while the development and scaffold stack pick up the maintained Fastify, Node type, and `tsx` releases.
+
+The 1.0 roadmap remains focused on release-candidate gates. This release does not change generated SOAP, OpenAPI, or gateway behavior.
+
+## Highlights
+
+- Updates `js-yaml` to `5.2.1`.
+- Updates `fastify` to `5.9.0`.
+- Updates `@types/node` to `26.1.0`.
+- Updates `tsx` to `4.23.0`.
+- Updates generated app scaffold pins for matching dependency floors.
+- Aligns roadmap documentation with the `0.38.0` release state.
+
+## Upgrade Notes
+
+No special upgrade steps.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v0.38.0`.

package/docs/releases/v0.39.0.md

@@ -0,0 +1,35 @@
+# TypeScript WSDL Client v0.39.0
+
+## IDE And Generated Output Hygiene
+
+This release tightens the repository's TypeScript ownership model for tests, generated examples, and release scripts while keeping generated client and gateway behavior stable.
+
+## What This Improves
+
+Developers working in strict NodeNext IDEs get diagnostics that line up with the repository's actual test boundaries. Scoped TypeScript configs now own conformance tests, unit tests that import scripts, and generated example output without broadening the production `src` configuration.
+
+Generated Fastify gateway runtime metadata is emitted with less duplicated source while preserving the same response envelope behavior. Release scripts also share file helpers so future packaging and validation changes have fewer duplicated paths to maintain.
+
+## Highlights
+
+- Adds scoped TypeScript ownership for tests and generated examples.
+- Deduplicates generated gateway runtime metadata literals.
+- Keeps gateway runtime response behavior stable.
+- Refactors agent skill build and validation scripts around shared file helpers.
+- Documents intentional IDE suppressions where local inspections disagree with verified runtime behavior.
+- Polishes Markdown and consumer guidance wording.
+
+## Upgrade Notes
+
+No special upgrade steps.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v0.39.0`.

package/docs/releases/v0.40.0.md

@@ -0,0 +1,45 @@
+# TypeScript WSDL Client v0.40.0
+
+## Current Dependency Baseline
+
+This release refreshes maintained dependency floors after the merged dependency updates and keeps generated app scaffolds aligned with the package baseline.
+
+## What This Improves
+
+Developers get current compatible dependency minimums in both the published package and newly scaffolded Fastify gateway apps. The XML parser, test stack, Fastify development dependency, and Node type definitions move to their maintained releases without changing the generated SOAP, OpenAPI, or gateway contracts. TypeScript remains on the maintained 6.x line because the repository documentation validator uses compiler-library APIs not exposed by TypeScript 7.
+
+Release preparation is also more direct: run targeted checks while editing, run release preflight once on the final uncommitted candidate, then commit and tag the exact validated tree without repeating the full gates.
+
+Generated output paths are clearer. Public examples use an explicit, git-ignored `.generated/` directory, while repository automation keeps smoke output, caches, and release work isolated under owned `tmp/` subfolders.
+
+The 1.0 roadmap remains focused on confirming explicit capability decisions and completing the release-candidate gates.
+
+## Highlights
+
+- Updates `fast-xml-parser` to `5.10.0`.
+- Updates Fastify to `5.10.0`.
+- Retains TypeScript `6.0.3` compatibility in the package and generated app.
+- Updates Vitest to `4.1.10`.
+- Updates `@types/node` to `26.1.1`.
+- Updates generated app scaffold pins for matching dependency floors.
+- Confirms zero known vulnerabilities in the root package and generated app dependency trees.
+- Aligns catalog help with the actual co-located output behavior.
+- Uses `.generated/` consistently for disposable consumer output examples.
+- Prevents smoke cleanup from deleting caches and unrelated automation workspaces.
+- Keeps release preflight helper declarations aligned across tests, TypeScript, and IDE inspections.
+- Defines a single final-candidate release preflight before the release commit.
+
+## Upgrade Notes
+
+No special upgrade steps.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v0.40.0`.

package/docs/releases/v0.40.1.md

@@ -0,0 +1,34 @@
+# TypeScript WSDL Client v0.40.1
+
+## Faster Conformance Feedback Before 1.0
+
+This maintenance release makes the capability conformance suite easier to run and diagnose while closing the remaining scope decisions before the stable 1.0 release candidate.
+
+## What This Improves
+
+Maintainers and contributors can run contracts, compile, client, OpenAPI, gateway, generated-test, or app conformance independently instead of waiting for every evidence layer after a focused change. The complete release-blocking suite remains intact and now reports visible per-capability progress during its longer generated-project checks.
+
+The 1.0 boundary is also explicit. Multiple bindings retain deterministic first SOAP binding selection, external policy documents remain unresolved, abstract types and substitution groups remain diagnostic, and MTOM/XOP attachments remain outside the typed SOAP-to-REST transport contract.
+
+## Highlights
+
+- Adds stage-specific conformance commands for focused maintainer feedback.
+- Keeps all 123 capability checks in the canonical full suite.
+- Documents the expected full-suite duration and agent timeout guidance.
+- Records the accepted partial and terminal capability boundaries for 1.0.
+- Defers the public WSDL inspector until after 1.0.
+
+## Upgrade Notes
+
+No special upgrade steps. Generated client, OpenAPI, gateway, app, and runtime contracts are unchanged.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v0.40.1`.

package/docs/releases/v1.0.0.md

@@ -0,0 +1,42 @@
+# TypeScript WSDL Client v1.0.0
+
+## A Stable Typed SOAP Modernization Contract
+
+Version 1.0 declares the documented TypeScript client, OpenAPI 3.1, Fastify gateway, runnable app, test generation, and programmatic APIs stable after the complete 0.x implementation and conformance program.
+
+## What This Improves
+
+Teams can adopt the generator with an explicit compatibility baseline. Default generated behavior remains aligned with `0.40.1`, supported WSDL patterns have fixture-backed evidence through every generated stage, and unsupported polymorphic or attachment constructs stop with diagnostics instead of producing misleading contracts.
+
+The migration contract also makes opt-in behavior clear. Choice unions remain optional, NDJSON remains the default streaming format, JSON arrays remain available per operation, and multiple SOAP bindings continue using deterministic first-binding selection.
+
+Release delivery now preserves rejected candidate evidence. An annotated abandonment marker blocks draft mutation and package publication while consuming the rejected version permanently.
+
+## Highlights
+
+- Stabilizes typed SOAP clients, OpenAPI specifications, Fastify gateways, apps, and generated tests.
+- Requires Node.js 24 or newer and keeps Node 26 compatibility coverage.
+- Preserves `all-optional` as the default `xs:choice` strategy.
+- Preserves NDJSON as the default configured streaming format.
+- Carries fixture-backed conformance evidence across compile and generated consumer stages.
+- Rejects abstract types, substitution groups, and MTOM/XOP attachments with explicit diagnostics.
+- Documents deterministic multi-binding behavior and unresolved external policy references.
+- Keeps the public WSDL inspector as a post-1.0 candidate.
+- Blocks GitHub Packages and npm publication for permanently abandoned release candidates.
+
+## Upgrade Notes
+
+No intentional behavior break is introduced relative to `0.40.1`. Consumers must run Node.js 24 or newer, regenerate owned output, review the generated diff, and run their TypeScript build and tests.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Agent skill artifact was validated and packaged.
+- Release preflight passed against the target tag.
+
+## Notes
+
+Release tag: `v1.0.0`.
+
+Release candidate abandonment guards address [GitHub issue #117](https://github.com/TechSpokes/typescript-wsdl-client/issues/117).

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, and the conformance framework is wired into validation gates. 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)        | planned           | Attribute wildcard bag emitted  |
-| Release candidate     | [Release Candidate Gates](v1.0-release-candidate-gates.md)                   | next              | 1.0 release is repeatable       |
+| `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)                   | complete          | 1.0 release is repeatable       |
 
 ## Execution Order
 
@@ -47,21 +47,21 @@ 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 non-supported 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
 
-The [`xs:anyAttribute` wildcard bag plan](v1.0-xs-anyattribute-wildcard-bag.md) is the selected scoped pre-1.0 fix. It promotes the current metadata-only partial row to supported by emitting a configured wildcard attribute bag through TypeScript, OpenAPI, gateway, generated-test, app, and documentation evidence.
+The [`xs:anyAttribute` wildcard bag plan](v1.0-xs-anyattribute-wildcard-bag.md) shipped in `0.36.0`. It promoted the previous metadata-only partial row to supported by emitting a configured wildcard attribute bag through TypeScript, OpenAPI, gateway, generated-test, app, and documentation evidence.
 
 ### Slice 8: Release Candidate Gates
 
 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 partial, diagnostic, and unsupported matrix row is an accepted 1.0 decision or select one scoped fix.
-- 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.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.
+`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,11 @@ 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.
 
 ## Documentation Checklist
 
@@ -79,7 +85,7 @@ Run `npm run release:preflight -- v1.0.0` during release preparation. Confirm re
 - `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.
+- The release workflow can publish with provenance after the targeted publish check passes.
 
 ## Release Implications
 

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

@@ -1,10 +1,10 @@
 # Version 1.0 WSDL Coverage Matrix
 
-Status: baseline support registry expanded through `0.35.0`; generated-test evidence, app evidence, and validation-gate wiring shipped before `1.0.0`.
+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`. 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.
+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.
 
@@ -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