@techspokes/typescript-wsdl-client 0.30.0 → 0.30.3

package/README.md

@@ -232,6 +232,7 @@ See [CLI Reference](docs/cli-reference.md) for all flags and examples.
 | [Programmatic API](docs/api-reference.md) | TypeScript functions for build tools |
 | [Core Concepts](docs/concepts.md) | Flattening, $value, primitives, determinism |
 | [Architecture](docs/architecture.md) | Internal pipeline for contributors |
+| [File Naming And Path Organization](docs/file-naming-and-path-organization.md) | Contributor convention for taxonomy paths and fixture retrieval |
 | [Agent Skill Artifact](docs/agent-skill.md) | Release ZIP for consumer-project AI agents |
 | [Version 1.0 Roadmap Plan](docs/roadmap/README.md) | Conformance framework, implementation slices, and release gates for 1.0 |
 | [Streamable Responses (ADR-002)](docs/decisions/002-streamable-responses.md) | Opt-in streaming: client `AsyncIterable`, gateway NDJSON or JSON array, `x-wsdl-tsc-stream` |

package/dist/app/generateApp.js

@@ -515,7 +515,7 @@ function generatePackageJson(appDir, force) {
             soap: "^1.9.3",
         },
         devDependencies: {
-            "@types/node": "^26.0.0",
+            "@types/node": "^26.0.1",
             tsx: "^4.22.4",
             typescript: "^6.0.3",
         },

package/dist/compiler/schemaCompiler.d.ts

@@ -38,6 +38,10 @@ export type CompiledWildcard = {
     namespace?: string;
     processContents?: "lax" | "strict" | "skip";
 };
+export type CompiledAttributeWildcard = {
+    namespace?: string;
+    processContents?: "lax" | "strict" | "skip";
+};
 export type CompiledChoiceBranch = {
     name: string;
     tsType: string;
@@ -68,6 +72,7 @@ export type CompiledChoiceGroup = {
  * @property {Array<Object>} [localAttrs] - Attributes added in extension (not inherited)
  * @property {Array<Object>} [localElems] - Elements added in extension (not inherited)
  * @property {Array<Object>} [wildcards] - xs:any wildcard particles retained on the type
+ * @property {Array<Object>} [attributeWildcards] - xs:anyAttribute wildcards retained on the type
  */
 export type CompiledType = {
     name: string;
@@ -108,6 +113,7 @@ export type CompiledType = {
         doc?: string;
     }>;
     wildcards?: CompiledWildcard[];
+    attributeWildcards?: CompiledAttributeWildcard[];
     choiceGroups?: CompiledChoiceGroup[];
     localChoiceGroups?: CompiledChoiceGroup[];
 };

package/dist/compiler/schemaCompiler.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"schemaCompiler.d.ts","sourceRoot":"","sources":["../../src/compiler/schemaCompiler.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AACH,OAAO,KAAK,EAAC,eAAe,EAAC,MAAM,cAAc,CAAC;AAClD,OAAO,KAAK,EAAC,WAAW,EAAC,MAAM,yBAAyB,CAAC;AAIzD,OAAO,KAAK,EAAC,uBAAuB,EAAE,YAAY,EAAC,MAAM,yBAAyB,CAAC;AAEnF;;;;;;GAMG;AACH,MAAM,MAAM,KAAK,GAAG;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAAC;AAElD;;;;;;;;GAQG;AACH,MAAM,MAAM,gBAAgB,GAAG;IAC7B,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;IAC1B,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,eAAe,CAAC,EAAE,KAAK,GAAG,QAAQ,GAAG,MAAM,CAAC;CAC7C,CAAC;AAEF,MAAM,MAAM,oBAAoB,GAAG;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;IAC1B,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;CACrB,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;IAC1B,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,oBAAoB,EAAE,CAAC;CAClC,CAAC;AAEF;;;;;;;;;;;;;GAaG;AACH,MAAM,MAAM,YAAY,GAAG;IACzB,IAAI,EAAE,MAAM,CAAC;IACb,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,KAAK,CAAC;QACX,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,CAAC,EAAE,UAAU,GAAG,UAAU,CAAC;QAC9B,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IACH,KAAK,EAAE,KAAK,CAAC;QACX,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,EAAE,MAAM,CAAC;QACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;QAC1B,QAAQ,CAAC,EAAE,OAAO,CAAC;QACnB,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,MAAM,CAAC;IAEd,UAAU,CAAC,EAAE,KAAK,CAAC;QACjB,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,CAAC,EAAE,UAAU,GAAG,UAAU,CAAC;QAC9B,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IAEH,UAAU,CAAC,EAAE,KAAK,CAAC;QACjB,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,EAAE,MAAM,CAAC;QACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;QAC1B,QAAQ,CAAC,EAAE,OAAO,CAAC;QACnB,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IAGH,SAAS,CAAC,EAAE,gBAAgB,EAAE,CAAC;IAG/B,YAAY,CAAC,EAAE,mBAAmB,EAAE,CAAC;IACrC,iBAAiB,CAAC,EAAE,mBAAmB,EAAE,CAAC;CAC3C,CAAC;AAEF;;;;;;;;;GASG;AACH,MAAM,MAAM,aAAa,GAAG;IAC1B,IAAI,EAAE,MAAM,CAAC;IACb,EAAE,EAAE,MAAM,CAAC;IACX,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;IACjB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,KAAK,CAAC;IAChB,IAAI,CAAC,EAAE,KAAK,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,KAAK,CAAC,EAAE,mBAAmB,EAAE,CAAC;CAC/B,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,KAAK,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,CAAC,EAAE,KAAK,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,KAAK,CAAC,EAAE,mBAAmB,EAAE,CAAC;CAC/B,CAAC;AAEF,MAAM,MAAM,gBAAgB,GAAG;IAC7B,QAAQ,CAAC,EAAE,sBAAsB,EAAE,CAAC;IACpC,QAAQ,CAAC,EAAE,sBAAsB,EAAE,CAAC;IACpC,QAAQ,CAAC,EAAE,sBAAsB,EAAE,CAAC;CACrC,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;CAClB,CAAC;AAEF;;;;GAIG;AACH,MAAM,MAAM,iBAAiB,GAAG;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,CAAC,EAAE,KAAK,CAAC;IACrB,aAAa,CAAC,EAAE,KAAK,CAAC;IACtB,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;IACpB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,GAAG,CAAC,EAAE,MAAM,CAAC;IACb;;;OAGG;IACH,MAAM,CAAC,EAAE,uBAAuB,CAAC;CAClC,CAAC;AAEF;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,eAAe,GAAG;IAC5B,OAAO,EAAE,eAAe,CAAC;IACzB,KAAK,EAAE,YAAY,EAAE,CAAC;IACtB,OAAO,EAAE,aAAa,EAAE,CAAC;IACzB,IAAI,EAAE;QACJ,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC;QACnC,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;QACjD,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;QAClD,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC,CAAC;KAC/C,CAAC;IACF,UAAU,EAAE,iBAAiB,EAAE,CAAC;IAChC,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,EAAE,MAAM,CAAC;IAChB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,QAAQ,CAAC,EAAE,gBAAgB,CAAC;IAC5B,WAAW,CAAC,EAAE,mBAAmB,CAAC;CACnC,CAAC;AAwJF;;;;;;;;;GASG;AACH,wBAAgB,cAAc,CAC5B,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,eAAe,EACxB,YAAY,CAAC,EAAE,YAAY,GAC1B,eAAe,CAm9BjB"}
+{"version":3,"file":"schemaCompiler.d.ts","sourceRoot":"","sources":["../../src/compiler/schemaCompiler.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;GAUG;AACH,OAAO,KAAK,EAAC,eAAe,EAAC,MAAM,cAAc,CAAC;AAClD,OAAO,KAAK,EAAC,WAAW,EAAC,MAAM,yBAAyB,CAAC;AAIzD,OAAO,KAAK,EAAC,uBAAuB,EAAE,YAAY,EAAC,MAAM,yBAAyB,CAAC;AAEnF;;;;;;GAMG;AACH,MAAM,MAAM,KAAK,GAAG;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAA;CAAE,CAAC;AAElD;;;;;;;;GAQG;AACH,MAAM,MAAM,gBAAgB,GAAG;IAC7B,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;IAC1B,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,eAAe,CAAC,EAAE,KAAK,GAAG,QAAQ,GAAG,MAAM,CAAC;CAC7C,CAAC;AAEF,MAAM,MAAM,yBAAyB,GAAG;IACtC,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,eAAe,CAAC,EAAE,KAAK,GAAG,QAAQ,GAAG,MAAM,CAAC;CAC7C,CAAC;AAEF,MAAM,MAAM,oBAAoB,GAAG;IACjC,IAAI,EAAE,MAAM,CAAC;IACb,MAAM,EAAE,MAAM,CAAC;IACf,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;IAC1B,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,YAAY,EAAE,MAAM,CAAC;IACrB,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,WAAW,EAAE,MAAM,CAAC;CACrB,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,EAAE,MAAM,CAAC;IACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;IAC1B,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,oBAAoB,EAAE,CAAC;CAClC,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,MAAM,MAAM,YAAY,GAAG;IACzB,IAAI,EAAE,MAAM,CAAC;IACb,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,KAAK,CAAC;QACX,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,CAAC,EAAE,UAAU,GAAG,UAAU,CAAC;QAC9B,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IACH,KAAK,EAAE,KAAK,CAAC;QACX,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,EAAE,MAAM,CAAC;QACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;QAC1B,QAAQ,CAAC,EAAE,OAAO,CAAC;QACnB,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,MAAM,CAAC;IAEd,UAAU,CAAC,EAAE,KAAK,CAAC;QACjB,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,CAAC,EAAE,UAAU,GAAG,UAAU,CAAC;QAC9B,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IAEH,UAAU,CAAC,EAAE,KAAK,CAAC;QACjB,IAAI,EAAE,MAAM,CAAC;QACb,MAAM,EAAE,MAAM,CAAC;QACf,GAAG,EAAE,MAAM,CAAC;QACZ,GAAG,EAAE,MAAM,GAAG,WAAW,CAAC;QAC1B,QAAQ,CAAC,EAAE,OAAO,CAAC;QACnB,YAAY,EAAE,MAAM,CAAC;QACrB,GAAG,CAAC,EAAE,MAAM,CAAC;KACd,CAAC,CAAC;IAGH,SAAS,CAAC,EAAE,gBAAgB,EAAE,CAAC;IAG/B,kBAAkB,CAAC,EAAE,yBAAyB,EAAE,CAAC;IAGjD,YAAY,CAAC,EAAE,mBAAmB,EAAE,CAAC;IACrC,iBAAiB,CAAC,EAAE,mBAAmB,EAAE,CAAC;CAC3C,CAAC;AAEF;;;;;;;;;GASG;AACH,MAAM,MAAM,aAAa,GAAG;IAC1B,IAAI,EAAE,MAAM,CAAC;IACb,EAAE,EAAE,MAAM,CAAC;IACX,MAAM,EAAE,MAAM,CAAC;IACf,QAAQ,EAAE,MAAM,CAAC;IACjB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,OAAO,CAAC,EAAE,KAAK,CAAC;IAChB,IAAI,CAAC,EAAE,KAAK,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,KAAK,CAAC,EAAE,mBAAmB,EAAE,CAAC;CAC/B,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,CAAC,EAAE,KAAK,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,CAAC,EAAE,KAAK,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC;CACd,CAAC;AAEF,MAAM,MAAM,sBAAsB,GAAG;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,KAAK,CAAC,EAAE,mBAAmB,EAAE,CAAC;CAC/B,CAAC;AAEF,MAAM,MAAM,gBAAgB,GAAG;IAC7B,QAAQ,CAAC,EAAE,sBAAsB,EAAE,CAAC;IACpC,QAAQ,CAAC,EAAE,sBAAsB,EAAE,CAAC;IACpC,QAAQ,CAAC,EAAE,sBAAsB,EAAE,CAAC;CACrC,CAAC;AAEF,MAAM,MAAM,mBAAmB,GAAG;IAChC,KAAK,CAAC,EAAE,MAAM,EAAE,CAAC;CAClB,CAAC;AAEF;;;;GAIG;AACH,MAAM,MAAM,iBAAiB,GAAG;IAC9B,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE,MAAM,CAAC;IACnB,YAAY,CAAC,EAAE,KAAK,CAAC;IACrB,aAAa,CAAC,EAAE,KAAK,CAAC;IACtB,QAAQ,CAAC,EAAE,MAAM,EAAE,CAAC;IACpB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB,GAAG,CAAC,EAAE,MAAM,CAAC;IACb;;;OAGG;IACH,MAAM,CAAC,EAAE,uBAAuB,CAAC;CAClC,CAAC;AAEF;;;;;;;;;;;;GAYG;AACH,MAAM,MAAM,eAAe,GAAG;IAC5B,OAAO,EAAE,eAAe,CAAC;IACzB,KAAK,EAAE,YAAY,EAAE,CAAC;IACtB,OAAO,EAAE,aAAa,EAAE,CAAC;IACzB,IAAI,EAAE;QACJ,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC;QACnC,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;QACjD,SAAS,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,CAAC,CAAC;QAClD,QAAQ,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC,CAAC;KAC/C,CAAC;IACF,UAAU,EAAE,iBAAiB,EAAE,CAAC;IAChC,YAAY,EAAE,MAAM,CAAC;IACrB,OAAO,EAAE,MAAM,CAAC;IAChB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,QAAQ,CAAC,EAAE,gBAAgB,CAAC;IAC5B,WAAW,CAAC,EAAE,mBAAmB,CAAC;CACnC,CAAC;AAwJF;;;;;;;;;GASG;AACH,wBAAgB,cAAc,CAC5B,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,eAAe,EACxB,YAAY,CAAC,EAAE,YAAY,GAC1B,eAAe,CA0gCjB"}

package/dist/compiler/schemaCompiler.js

@@ -213,6 +213,30 @@ export function compileCatalog(cat, options, streamConfig) {
             }
             return { tsType: xsdToTsPrimitive(declared, options?.primitive), declared };
         }
+        const union = getFirstWithLocalName(simpleNode, "union");
+        if (union) {
+            const members = [];
+            const memberTypes = String(union["@_memberTypes"] ?? "")
+                .split(/\s+/)
+                .map(value => value.trim())
+                .filter(Boolean);
+            for (const memberType of memberTypes) {
+                const q = resolveQName(memberType, schemaNS, prefixes);
+                members.push(resolveTypeRef(q, schemaNS, prefixes));
+            }
+            for (const inlineSimple of getChildrenWithLocalName(union, "simpleType")) {
+                members.push(compileSimpleTypeNode(inlineSimple, schemaNS, prefixes));
+            }
+            if (members.length > 0) {
+                const tsTypes = Array.from(new Set(members.flatMap(member => member.tsType.split("|").map(part => part.trim()))));
+                const declared = members.map(member => member.declared).join(" | ");
+                return {
+                    tsType: tsTypes.join(" | "),
+                    declared,
+                    jsdoc: JSON.stringify({ kind: "union", members: members.map(member => member.declared) }),
+                };
+            }
+        }
         const list = getFirstWithLocalName(simpleNode, "list");
         if (list?.["@_itemType"]) {
             const q = resolveQName(list["@_itemType"], schemaNS, prefixes);
@@ -398,6 +422,17 @@ export function compileCatalog(cat, options, streamConfig) {
             recurse(node);
             return out;
         };
+        const collectAttributeWildcards = (node) => {
+            const out = [];
+            for (const a of getChildrenWithLocalName(node, "anyAttribute")) {
+                const pc = a["@_processContents"];
+                out.push({
+                    ...(a["@_namespace"] ? { namespace: a["@_namespace"] } : {}),
+                    ...(pc === "lax" || pc === "strict" || pc === "skip" ? { processContents: pc } : {}),
+                });
+            }
+            return out;
+        };
         const readOccurrence = (node) => {
             const min = node["@_minOccurs"] ? Number(node["@_minOccurs"]) : 1;
             const maxAttr = node["@_maxOccurs"];
@@ -542,12 +577,16 @@ export function compileCatalog(cat, options, streamConfig) {
             const newAttrs = collectAttributes(cnode);
             const newElems = collectParticles(outName, cnode);
             const newWildcards = collectWildcards(cnode);
+            const newAttributeWildcards = collectAttributeWildcards(cnode);
             const newChoiceGroups = collectChoiceGroups(outName, cnode);
             mergeAttrs(present.attrs, newAttrs);
             mergeElems(present.elems, newElems);
             if (newWildcards.length > 0) {
                 present.wildcards = [...(present.wildcards ?? []), ...newWildcards];
             }
+            if (newAttributeWildcards.length > 0) {
+                present.attributeWildcards = [...(present.attributeWildcards ?? []), ...newAttributeWildcards];
+            }
             const mergedChoiceGroups = mergeChoiceGroups(present.choiceGroups, newChoiceGroups);
             if (mergedChoiceGroups && mergedChoiceGroups.length > 0) {
                 present.choiceGroups = mergedChoiceGroups;
@@ -562,6 +601,7 @@ export function compileCatalog(cat, options, streamConfig) {
         // result accumulators
         const attrs = [];
         const elems = [];
+        const attributeWildcards = [];
         const choiceGroups = [];
         // Inheritance: complexContent
         const complexContent = getFirstWithLocalName(cnode, "complexContent");
@@ -582,6 +622,7 @@ export function compileCatalog(cat, options, streamConfig) {
                         // inherit base members
                         attrs.push(...baseType.attrs);
                         elems.push(...baseType.elems);
+                        attributeWildcards.push(...(baseType.attributeWildcards ?? []));
                         choiceGroups.push(...(baseType.choiceGroups ?? []));
                     }
                 }
@@ -589,9 +630,11 @@ export function compileCatalog(cat, options, streamConfig) {
                 const locals = collectAttributes(node);
                 const localElems = collectParticles(outName, node);
                 const localWildcards = collectWildcards(node);
+                const localAttributeWildcards = collectAttributeWildcards(node);
                 const localChoiceGroups = collectChoiceGroups(outName, node);
                 attrs.push(...locals);
                 elems.push(...localElems);
+                attributeWildcards.push(...localAttributeWildcards);
                 choiceGroups.push(...localChoiceGroups);
                 const result = {
                     name: outName,
@@ -603,6 +646,7 @@ export function compileCatalog(cat, options, streamConfig) {
                     localAttrs: locals,
                     localElems,
                     ...(localWildcards.length > 0 ? { wildcards: localWildcards } : {}),
+                    ...(attributeWildcards.length > 0 ? { attributeWildcards } : {}),
                     ...(choiceGroups.length > 0 ? { choiceGroups } : {}),
                     ...(localChoiceGroups.length > 0 ? { localChoiceGroups } : {}),
                 };
@@ -632,7 +676,15 @@ export function compileCatalog(cat, options, streamConfig) {
                         declaredType: r.declared,
                     }]);
                 mergeAttrs(attrs, collectAttributes(scNode));
-                const result = { name: outName, ns: schemaNS, attrs, elems, doc: typeDoc };
+                const attributeWildcards = collectAttributeWildcards(scNode);
+                const result = {
+                    name: outName,
+                    ns: schemaNS,
+                    attrs,
+                    elems,
+                    doc: typeDoc,
+                    ...(attributeWildcards.length > 0 ? { attributeWildcards } : {}),
+                };
                 compiledMap.set(key, result);
                 inProgress.delete(rawKey);
                 return result;
@@ -648,6 +700,7 @@ export function compileCatalog(cat, options, streamConfig) {
         mergeAttrs(attrs, collectAttributes(cnode));
         mergeElems(elems, collectParticles(outName, cnode));
         const wildcards = collectWildcards(cnode);
+        attributeWildcards.push(...collectAttributeWildcards(cnode));
         choiceGroups.push(...collectChoiceGroups(outName, cnode));
         const result = {
             name: outName,
@@ -656,6 +709,7 @@ export function compileCatalog(cat, options, streamConfig) {
             elems,
             doc: typeDoc,
             ...(wildcards.length > 0 ? { wildcards } : {}),
+            ...(attributeWildcards.length > 0 ? { attributeWildcards } : {}),
             ...(choiceGroups.length > 0 ? { choiceGroups } : {}),
         };
         compiledMap.set(key, result);

package/dist/compiler/shapeResolver.js

@@ -251,6 +251,10 @@ function canonicalizeType(t) {
             namespace: w.namespace ?? null,
             processContents: w.processContents ?? null,
         })),
+        attributeWildcards: (t.attributeWildcards ?? []).map((w) => ({
+            namespace: w.namespace ?? null,
+            processContents: w.processContents ?? null,
+        })),
         choiceGroups: (t.choiceGroups ?? []).map((g) => ({
             name: g.name,
             min: g.min,

package/dist/openapi/generateSchemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"generateSchemas.d.ts","sourceRoot":"","sources":["../../src/openapi/generateSchemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AACH,OAAO,KAAK,EAAgB,eAAe,EAAe,MAAM,+BAA+B,CAAC;AAEhG;;;;;;GAMG;AACH,MAAM,WAAW,sBAAsB;IACrC,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,kBAAkB,CAAC,EAAE,OAAO,CAAC;IAC7B,oBAAoB,CAAC,EAAE,OAAO,CAAC;CAChC;AAED,MAAM,MAAM,iBAAiB,GAAG,MAAM,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;AAkNpD;;;;;;;;;;;;;GAaG;AACH,wBAAgB,eAAe,CAAC,QAAQ,EAAE,eAAe,EAAE,IAAI,EAAE,sBAAsB,GAAG,iBAAiB,CA2D1G"}
+{"version":3,"file":"generateSchemas.d.ts","sourceRoot":"","sources":["../../src/openapi/generateSchemas.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;GAcG;AACH,OAAO,KAAK,EAAgB,eAAe,EAAe,MAAM,+BAA+B,CAAC;AAEhG;;;;;;GAMG;AACH,MAAM,WAAW,sBAAsB;IACrC,aAAa,CAAC,EAAE,OAAO,CAAC;IACxB,kBAAkB,CAAC,EAAE,OAAO,CAAC;IAC7B,oBAAoB,CAAC,EAAE,OAAO,CAAC;CAChC;AAED,MAAM,MAAM,iBAAiB,GAAG,MAAM,CAAC,MAAM,EAAE,GAAG,CAAC,CAAC;AAwPpD;;;;;;;;;;;;;GAaG;AACH,wBAAgB,eAAe,CAAC,QAAQ,EAAE,eAAe,EAAE,IAAI,EAAE,sBAAsB,GAAG,iBAAiB,CA2D1G"}

package/dist/openapi/generateSchemas.js

@@ -8,6 +8,10 @@ function isLiteralUnion(ts) {
     }
     return null;
 }
+function unionParts(ts) {
+    const parts = ts.split("|").map(p => p.trim()).filter(Boolean);
+    return parts.length > 1 ? parts : null;
+}
 function primitiveSchema(ts) {
     switch (ts) {
         case "string":
@@ -25,6 +29,27 @@ function primitiveSchema(ts) {
             return { $ref: `#/components/schemas/${ts}` };
     }
 }
+function schemaForUnionPart(ts) {
+    if (/^".*"$/.test(ts)) {
+        return { type: "string", enum: [ts.slice(1, -1)] };
+    }
+    return primitiveSchema(ts);
+}
+function mixedUnionSchema(ts) {
+    const parts = unionParts(ts);
+    if (!parts)
+        return null;
+    const schemas = parts.map(schemaForUnionPart);
+    const stringEnums = schemas
+        .filter((schema) => schema.type === "string" && Array.isArray(schema.enum))
+        .flatMap(schema => schema.enum);
+    const rest = schemas.filter(schema => !(schema.type === "string" && Array.isArray(schema.enum)));
+    const oneOf = [
+        ...(stringEnums.length > 0 ? [{ type: "string", enum: Array.from(new Set(stringEnums)) }] : []),
+        ...rest,
+    ];
+    return { oneOf };
+}
 function buildAliasSchema(a) {
     const lit = isLiteralUnion(a.tsType);
     if (lit) {
@@ -34,6 +59,13 @@ function buildAliasSchema(a) {
             ...(a.doc ? { description: a.doc } : {}),
         };
     }
+    const union = mixedUnionSchema(a.tsType);
+    if (union) {
+        return {
+            ...union,
+            ...(a.doc ? { description: a.doc } : {}),
+        };
+    }
     // If alias wraps primitive
     if (["string", "number", "boolean", "any"].includes(a.tsType) || a.tsType.endsWith("[]")) {
         return {
@@ -86,6 +118,10 @@ function buildComplexSchema(t, closed, knownTypeNames, aliasNames, flattenWrappe
                 if (lit) {
                     return { type: "string", enum: lit };
                 }
+                const union = mixedUnionSchema(ts);
+                if (union) {
+                    return union;
+                }
                 if (ts.endsWith("[]")) {
                     const inner = ts.slice(0, -2);
                     return { type: "array", items: refOrPrimitive(inner) };

package/docs/README.md

@@ -28,6 +28,7 @@ Human-maintained reference documents for `@techspokes/typescript-wsdl-client`. T
 - [api-reference.md](api-reference.md): programmatic TypeScript API
 - [concepts.md](concepts.md): flattening, `$value`, primitives, determinism
 - [architecture.md](architecture.md): internal pipeline for contributors
+- [file-naming-and-path-organization.md](file-naming-and-path-organization.md): contributor convention for taxonomy paths and fixture retrieval
 - [agent-skill.md](agent-skill.md): release ZIP for consumer-project AI agents
 - [roadmap/README.md](roadmap/README.md): conformance framework, implementation slices, and release gates for 1.0
 - [decisions/002-streamable-responses.md](decisions/002-streamable-responses.md): opt-in streaming design (client `AsyncIterable`, gateway NDJSON or JSON array, `x-wsdl-tsc-stream` OpenAPI extension); shipped in 0.17.0 and extended in 0.28.0
@@ -38,6 +39,7 @@ Human-maintained reference documents for `@techspokes/typescript-wsdl-client`. T
 - Each document opens with an H1 title and a one-line description.
 - Cross-reference related documents and the root README where relevant.
 - Use fenced code blocks for CLI examples; format flags as inline code (`` `--flag-name` ``).
+- Use `bash` fences for portable command examples; reserve `powershell` fences for Windows-specific commands.
 - Run `npm run docs:validate` to check local links and TypeScript fenced snippets.
 - Keep language direct and task-oriented; architecture.md targets contributors, all others target users.
 

package/docs/file-naming-and-path-organization.md

@@ -0,0 +1,207 @@
+# File Naming And Path Organization
+
+Contributor guide for naming files and organizing fixture paths. See the root [README.md](../README.md) for the authoritative documentation index.
+
+## Purpose
+
+Paths should classify files before a reader opens them. The left side of a path carries the broadest concept; each segment to the right narrows the classification until the filename states the exact artifact purpose.
+
+This convention is especially important for conformance fixtures. A maintainer should be able to search or list paths and see which WSDL, XSD, SOAP, policy, and recovery concepts already have evidence.
+
+## Authority Model
+
+This convention borrows from resource-oriented API design. REST APIs commonly use noun-based paths, hierarchy through `/`, and readable lowercase path segments.
+
+Google AIP-122 describes resource names as slash-separated paths and says collection identifiers are usually plural nouns. Zalando REST guidelines require plural resource names, kebab-case path segments, verb-free URLs, and domain-specific resource names. Microsoft Azure API guidelines prefer kebab-casing for URL path segments. REST URI naming guidance uses nouns for resources, `/` for hierarchy, and hyphens for readability.
+
+Filesystem paths are not REST APIs, but the same retrieval model applies: a path is a resource name for a contributor, a terminal command, an IDE index, and an agent.
+
+## Shell Examples
+
+Use `bash` fences for portable command examples in repository documentation and GitHub workflow notes. Use `powershell` fences only when the command is intentionally Windows-specific.
+
+Prefer `rg` for retrieval examples because agents already use it for fast file and content search. Write path filters so they tolerate `/` and `\` separators when possible.
+
+On Windows PowerShell, keep `rg` regex arguments in single quotes when the pattern contains backslashes, brackets, or alternation. The examples in this document were checked in PowerShell with single-quoted regexes. A no-match `rg` filter exits with code `1`; that is expected for negative checks such as confirming `service.wsdl` is absent.
+
+## Progressive Discovery
+
+Start broad, then narrow. A path should answer these questions from left to right:
+
+1. What repository area owns this artifact?
+2. What artifact family is this?
+3. What standards domain or product domain does it belong to?
+4. What feature family does it exercise?
+5. What exact purpose does the file serve?
+
+For conformance fixtures, this means the preferred shape is:
+
+```text
+test/conformance/fixtures/<domain>/<feature-family>/<feature-name>.<ext>
+```
+
+Use deeper nesting only when it improves retrieval. Do not create a folder level that only repeats the filename.
+
+## Folder Names
+
+Folder names are taxonomy terms. They classify a set of files.
+
+- Use lowercase kebab-case.
+- Prefer one noun per segment.
+- Prefer plural nouns when the term is naturally countable.
+- Preserve standards terms when pluralizing them would reduce clarity.
+- Avoid verbs, implementation steps, and filler words.
+- Place the broadest useful classifier on the left.
+- Add a narrower folder only when it groups multiple related files or distinguishes a standards boundary.
+
+Acceptable standards-domain folders include `wsdl`, `xsd`, `soap`, `ws-policy`, `ws-security`, `interop`, and `recovery`.
+
+Acceptable feature-family folders include `types`, `elements`, `bindings`, `policies`, `attachments`, `wildcards`, `compositors`, `sequences`, and `choices`.
+
+## File Names
+
+File names state the exact purpose and content of the artifact. They should remain useful when shown without the full path.
+
+- Use lowercase kebab-case.
+- Use general-to-specific segment order.
+- Put the broad feature classifier first.
+- Put variable-like qualifiers at the right side.
+- Keep recognized standards terms when they identify the feature.
+- Avoid filler words such as `service`, `sample`, `fixture`, and `test`.
+- Use the file extension to identify format, not the basename.
+
+Good file names classify sorted terminal output:
+
+```text
+attachment-mtom-xop.wsdl
+binding-soap-first-multi.wsdl
+choice-union-simple.wsdl
+element-substitution-group.wsdl
+policy-reference-external.wsdl
+sequence-composition-deep.wsdl
+type-complex-abstract-extension.wsdl
+type-union-simple.wsdl
+wildcard-attribute-any.wsdl
+```
+
+Avoid names that only read naturally in English but group poorly in file listings:
+
+```text
+abstract-complex-type-extension.wsdl
+any-attribute.wsdl
+deep-sequence-composition.wsdl
+mtom-xop-attachment.wsdl
+multi-binding-first-soap.wsdl
+xs-union-simple-type.wsdl
+```
+
+## Conformance Fixtures
+
+Conformance fixtures should be committed XML files, not inline strings in tests. Inline XML is acceptable only for throwaway probes or very small unit tests that do not represent a reusable fixture.
+
+The fixture path should support discovery by partial path search. A contributor should be able to search `xsd/wildcards`, `soap/attachments`, or `wsdl/bindings` and see what exists.
+
+The registry ID should remain stable for test reporting. The fixture path may use taxonomy folders and a more precise filename when that improves retrieval.
+
+## Multi-file Fixtures
+
+Use a folder when a fixture needs a root WSDL plus imported schemas or companion files. Keep the root filename aligned with the feature name.
+
+```text
+test/conformance/fixtures/xsd/wildcards/wildcard-attribute-any.wsdl
+test/conformance/fixtures/xsd/wildcards/wildcard-attribute-any-types.xsd
+test/conformance/fixtures/xsd/wildcards/wildcard-attribute-any-shared.xsd
+```
+
+Use purpose suffixes such as `types`, `messages`, `shared`, `policy`, and `binding` for companion files.
+
+## Retrieval Examples
+
+List every conformance fixture path:
+
+```bash
+rg --files test/conformance/fixtures | sort
+```
+
+Find every XSD wildcard fixture:
+
+```bash
+rg --files test/conformance/fixtures | rg '(^|[\\/])xsd[\\/]wildcards[\\/]'
+```
+
+Find whether a SOAP attachment fixture exists:
+
+```bash
+rg --files test/conformance/fixtures | rg '(^|[\\/])attachment-'
+```
+
+Use `rg` when searching by concept inside paths or XML content:
+
+```bash
+rg -n "xs:anyAttribute|wildcard-attribute" test\conformance\fixtures
+```
+
+## Agent Retrieval Playbook
+
+Agents should prefer a small number of focused file-system checks before adding or renaming fixtures. These commands are intentionally simple and use portable `rg` patterns.
+
+Check the current taxonomy shape:
+
+```bash
+rg --files test/conformance/fixtures | sort
+```
+
+Check whether a domain branch already exists:
+
+```bash
+rg --files test/conformance/fixtures | rg '(^|[\\/])xsd[\\/]types[\\/]'
+```
+
+Find fixtures by filename classifier:
+
+```bash
+rg --files test/conformance/fixtures | rg '(^|[\\/])type-'
+```
+
+Find fixtures by XML feature content:
+
+```bash
+rg -n "xs:union|xs:anyAttribute|substitutionGroup|PolicyReference" test\conformance\fixtures
+```
+
+Check whether old filler names are still present:
+
+```bash
+rg --files test/conformance/fixtures | rg '(^|[\\/])service\.wsdl'
+```
+
+Find the registry row that owns a fixture path:
+
+```bash
+rg -n "wildcard-attribute-any|type-union-simple|attachment-mtom-xop" test\conformance\registry.ts
+```
+
+Use these commands as discovery checks, not as validation gates. Repository validation still runs through `npm run docs:validate`, `npm run test:conformance`, and `npm test`.
+
+## Candidate Fixture Paths
+
+Use these paths as the target direction for the current conformance corpus:
+
+```text
+test/conformance/fixtures/xsd/compositors/choice-union-simple.wsdl
+test/conformance/fixtures/xsd/types/type-union-simple.wsdl
+test/conformance/fixtures/xsd/types/type-complex-abstract-extension.wsdl
+test/conformance/fixtures/xsd/elements/element-substitution-group.wsdl
+test/conformance/fixtures/wsdl/bindings/binding-soap-first-multi.wsdl
+test/conformance/fixtures/ws-policy/references/policy-reference-external.wsdl
+test/conformance/fixtures/xsd/sequences/sequence-composition-deep.wsdl
+test/conformance/fixtures/xsd/wildcards/wildcard-attribute-any.wsdl
+test/conformance/fixtures/soap/attachments/attachment-mtom-xop.wsdl
+```
+
+## References
+
+- [Google AIP-122 Resource Names](https://google.aip.dev/122)
+- [Zalando RESTful API Guidelines](https://opensource.zalando.com/restful-api-guidelines/)
+- [Microsoft Azure API Guidelines](https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md)
+- [REST API URI Naming Conventions](https://restfulapi.net/resource-naming/)

package/docs/releases/v0.30.1.md

@@ -0,0 +1,31 @@
+# TypeScript WSDL Client v0.30.1
+
+## Roadmap And Dependency Patch
+
+This patch release refreshes the 1.0 readiness documentation after the `0.30.0` maintenance release and advances the Node type definitions used by the package and generated app scaffold.
+
+## What This Improves
+
+Maintainers get roadmap and supported-pattern documentation that matches the current release line before starting the conformance framework work. Contributors also get clearer guidance about optional IDE MCP tooling in public-repository workflows.
+
+## Highlights
+
+- Aligns roadmap documentation with the current `0.30.x` release state.
+- Clarifies that `xs:any` wildcard metadata is retained for selected compiler and streaming workflows, but full wildcard serialization is not a typed contract.
+- Documents optional IDE MCP routing while preserving terminal-based contributor fallbacks.
+- Updates `@types/node` to 26.0.1 in both the package and generated app scaffold pins.
+
+## Upgrade Notes
+
+No special upgrade steps. Regenerate generated Fastify app scaffolds when you want new app projects to start with the updated `@types/node` pin.
+
+## Validation
+
+- CI passed.
+- NPM package contents were validated.
+- Documentation links and TypeScript fenced snippets were validated.
+- Agent skill artifact was validated and packaged.
+
+## Notes
+
+Release tag: `v0.30.1`.

package/docs/releases/v0.30.2.md

@@ -0,0 +1,30 @@
+# TypeScript WSDL Client v0.30.2
+
+## Conformance fixture foundation
+
+This patch release adds the first capability conformance fixture corpus, records `xs:anyAttribute` wildcard metadata, and documents a reusable taxonomy for fixture paths and file names.
+
+## What This Improves
+
+Maintainers now have a fixture-backed way to classify WSDL and XSD support claims before 1.0. The conformance registry makes supported, partial, diagnostic, unsupported, and research rows explicit, while taxonomy-based fixture paths make it easier to discover existing XML coverage through ordinary file-system search.
+
+## Highlights
+
+- Added Phase 1 conformance registry tests and reusable WSDL fixtures.
+- Retained `xs:anyAttribute` declarations as compiled type metadata.
+- Documented taxonomy-based fixture path organization and portable retrieval commands.
+
+## Upgrade Notes
+
+No special upgrade steps.
+
+## Validation
+
+- Dependency maintenance completed successfully.
+- Documentation validation passed.
+- Test suite passed.
+- Smoke pipeline passed.
+
+## Notes
+
+Release tag: `v0.30.2`.

package/docs/releases/v0.30.3.md

@@ -0,0 +1,33 @@
+# TypeScript WSDL Client v0.30.3
+
+## Fixture-Backed Support Evidence
+
+This patch release adds simple `xs:union` support and makes the public support matrix generated from the conformance registry.
+
+## What This Improves
+
+Developers using WSDLs with simple `xs:union` aliases now get honest TypeScript union aliases and OpenAPI `oneOf` schemas instead of an under-modeled type. Maintainers also get a generated support matrix that keeps public documentation aligned with fixture-backed conformance rows.
+
+The release process guidance now makes the tag gate explicit: development commit titles may use the next patch target, but release tags require package metadata, changelog, release notes, and preflight checks to match first.
+
+## Highlights
+
+- Simple `xs:union` aliases now compile to TypeScript unions.
+- Mixed primitive and literal unions now emit OpenAPI `oneOf` schemas.
+- The public capability evidence matrix is generated from the conformance registry.
+- Agent instructions now require release preflight before pushing release tags.
+
+## 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.30.3`.

package/docs/roadmap/README.md

@@ -1,6 +1,6 @@
 # Version 1.0 Roadmap Plan
 
-Detailed plan for moving `@techspokes/typescript-wsdl-client` from the released `0.28.x` line to a stable `1.0.0` release.
+Detailed plan for moving `@techspokes/typescript-wsdl-client` from the released `0.30.x` line to a 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,7 +8,7 @@ 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, and JSON array streaming is shipped. The remaining readiness work is WSDL coverage evidence and the final release candidate gate pass.
+The plan is optimized for preserving quality. The contract and compatibility baselines now exist, choice union mode is shipped, and JSON array streaming is shipped. The remaining readiness work is the capability conformance framework, WSDL coverage evidence, and the final release candidate gate pass.
 
 ## Route Summary
 
@@ -54,7 +54,7 @@ Run the release candidate gates after feature work and documentation have conver
 
 ## Remaining Before 1.0
 
-- Build the capability conformance registry and runner.
+- Build the capability conformance registry and compile-stage runner.
 - Build and run the WSDL feature matrix as the first conformance domain.
 - Turn unsupported or partial matrix rows into diagnostics, documentation, or scoped fixes.
 - Confirm `docs/supported-patterns.md` matches the matrix.

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

@@ -75,6 +75,8 @@ The generated test stage proves `--test-dir` emits tests that compile and pass f
 
 The documentation stage proves `docs/supported-patterns.md` agrees with the capability registry. It should prevent docs from claiming support, partial support, or non-support without a matching conformance row.
 
+The public evidence matrix in `docs/supported-patterns.md` should be generated from registry rows. The rest of the page should remain human-authored so supported-pattern explanations stay useful to readers.
+
 ## Registry Shape
 
 The first implementation should use a TypeScript manifest because tests can import it with full type safety. JSON can be added later if external tooling needs a stable data format.
@@ -89,12 +91,169 @@ interface CapabilityCase {
   featureTags: string[];
   fixture: string;
   docsAnchor?: string;
+  publicContract: string;
   stages: CapabilityStages;
 }
 ```
 
 Stage payloads should stay small and explicit. Avoid a generic assertion language in the first version; use typed expectation objects and small runner helpers instead.
 
+## Standards And External Corpus
+
+Use WSDL 1.1, SOAP 1.1, XML Schema 1.0, and WS-I Basic Profile as the authority stack for Phase 1 capability expectations.
+
+WSDL 1.1 defines the service description model used by this project: `types`, `message`, `portType`, `binding`, `port`, and `service`, plus SOAP 1.1, HTTP, and MIME binding extensions.
+
+SOAP 1.1 defines the envelope and processing model that generated clients ultimately target through `node-soap`.
+
+XML Schema 1.0 defines the schema constructs compiled into TypeScript and OpenAPI shapes. XML Schema 1.1 test suites are useful as edge-case inspiration, but the project should not imply full XML Schema 1.1 support.
+
+WS-I Basic Profile 1.1 and 1.2 define interoperability constraints across SOAP, WSDL, XML Schema, and HTTP. Treat WS-I rules as the best available profile for portable SOAP behavior, not as a complete fixture source.
+
+Do not vendor third-party WSDL or XSD corpora wholesale in Phase 1. Prefer minimized synthetic fixtures derived from standard rules and clearly cite the relevant standard or profile section in the registry row.
+
+Third-party suites can inform future rows:
+
+- W3C WSDL 2.0 Test Suite: useful for conformance-suite structure, but not directly applicable to this WSDL 1.1 generator.
+- W3C XML Schema test suite: useful for XSD edge-case discovery, but it validates schema processors rather than WSDL-to-client generation.
+- WS-I test assertions and analyzer tools: useful for interoperability rule vocabulary, but heavy and not a direct TypeScript generation oracle.
+- Apache Axis or Apache CXF sample WSDL files: useful as real-world smoke candidates when license and fixture scope are clear.
+
+## Public Fixture Corpus Direction
+
+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 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.
+
+Phase 1 should add metadata that will make extraction possible later without changing every row:
+
+- `authority`: the standard, profile, or real-world source category behind the case.
+- `provenance`: a short explanation of whether the fixture is original, minimized from a report, or inspired by a third-party example.
+- `license`: the fixture license or repository default license.
+- `fixtureKind`: one of `standards-valid`, `interop-profile`, `real-world-compatible`, `diagnostic-required`, or `recovery`.
+
+Do not publish the standalone fixture project before the internal registry has proven the metadata shape with multiple useful rows. The first public release should happen only after maintainers can explain how another tool would consume the fixtures without depending on this repository's internals.
+
+## Fixture Corpus Goals
+
+The internal corpus should serve this repository first. It should make generator behavior explicit, prevent silent miscompilation, and give maintainers a repeatable way to classify WSDL reports.
+
+The future public corpus should serve the SOAP tooling community. It should offer small, understandable fixtures that other generators, validators, and migration tools can run against or inspect.
+
+The corpus should distinguish standards conformance from product policy. A fixture can be standards-valid while unsupported by this generator, or non-ideal but common enough to justify recovery behavior.
+
+The corpus should be useful without a live network. Every fixture should be committed with local relative imports and no dependency on public SOAP endpoints.
+
+The corpus should be explainable. Each fixture should say what behavior it exercises, what source justifies the expectation, and which outcomes are acceptable.
+
+## 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.
+
+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 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.
+
+Then check implementation locality. Local schema transforms such as simple aliases, deterministic metadata retention, and documented first-choice behavior are good support candidates. Features that require broad runtime semantics, wire-protocol changes, or public API design should usually become diagnostics or explicit deferrals before 1.0.
+
+Use these decisions:
+
+- `support`: implement and prove the feature through relevant stages.
+- `partial-support`: implement the honest subset and document the limit.
+- `diagnostic`: reject or warn clearly to avoid silent miscompilation.
+- `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.
+
+## Phase 1 Decisions
+
+Phase 1 is internal test infrastructure. It must not add exports from `src/index.ts`, new public CLI commands, or new consumer-facing APIs.
+
+The first registry should live under `test/conformance/registry.ts`. It should export types and data for repository tests only. Public package exports can be reconsidered after the inspector has a stable use case.
+
+The first runner should live under `test/conformance/runner.ts`. It should execute compile-stage checks by calling `loadWsdl`, `compileCatalog`, and `resolveCompilerOptions` directly.
+
+The first Vitest entry point should be `test/conformance/conformance.test.ts`. Add `npm run test:conformance` and keep it included in `npm test` through Vitest's normal test discovery.
+
+Fixtures should live under `test/conformance/fixtures/`. Each fixture should be a committed `.wsdl` or `.xsd` file, use relative files only, and require no network access.
+
+Documentation drift checks should start as a lightweight test in `test/conformance/docs.test.ts`. The test should verify that each registry row with a `docsAnchor` points to an existing heading anchor in `docs/supported-patterns.md`.
+
+The public evidence matrix should be generated from the registry with `npm run docs:support-matrix`. The check command should fail when the generated table and committed table drift.
+
+## Phase 1 File Map
+
+Create `test/conformance/types.ts` for shared registry types. Keep these types out of `src/` until a public API is justified.
+
+Create `test/conformance/registry.ts` for the initial capability rows. Include every priority feature from the WSDL coverage matrix.
+
+Create `test/conformance/runner.ts` for compile-stage execution helpers. Resolve fixture paths relative to `test/conformance/fixtures/` and create one temporary output directory per case under the OS temp directory.
+
+Create `test/conformance/conformance.test.ts` for manifest-driven compile tests. Supported and partial rows should compile successfully; diagnostic rows should assert the error shape or explicit warning behavior.
+
+Create `test/conformance/docs.test.ts` for registry-to-docs alignment. It should validate existing heading anchors and prove that the public evidence matrix matches generated registry output.
+
+Create `test/conformance/fixtures/` with one minimal WSDL per initial row. Keep each fixture synthetic, deterministic, and scoped to one capability.
+
+Modify `package.json` to add `test:conformance` with `vitest run test/conformance`.
+
+Modify `docs/supported-patterns.md` only when the registry reveals a real mismatch. Generate only the evidence matrix from the registry in Phase 1; do not rewrite the explanatory sections from registry data.
+
+## Phase 1 Type Contract
+
+Use these internal test types as the starting point:
+
+```ts
+export type CapabilityStatus = "supported" | "partial" | "diagnostic" | "unsupported" | "research";
+
+export type CompileExpectation =
+  | { outcome: "success"; typeNames?: string[]; aliasNames?: string[]; operationNames?: string[]; diagnosticNotes?: string[] }
+  | { outcome: "error"; errorClass?: "WsdlCompilationError"; messageIncludes?: string[]; userMessageIncludes?: string[]; context?: Partial<WsdlErrorContext> }
+  | { outcome: "research"; reason: string };
+
+export interface CapabilityCase {
+  id: string;
+  title: string;
+  status: CapabilityStatus;
+  featureTags: string[];
+  fixture: string;
+  docsAnchor?: string;
+  publicContract: string;
+  decision: CapabilityDecision;
+  decisionReason: string;
+  compile: CompileExpectation;
+}
+```
+
+`docsAnchor` values should use the same heading slug rules as the repository docs validator. Phase 1 may point rows to broad section anchors such as `fully-supported`, `partially-supported`, `not-yet-supported`, or `known-edge-cases`. Add feature-level headings to `docs/supported-patterns.md` only when a broad section anchor is too ambiguous for a row.
+
+`error` expectations should assert `instanceof WsdlCompilationError` when `errorClass` is `WsdlCompilationError`. `messageIncludes` checks should inspect `error.message`, `userMessageIncludes` checks should inspect `error.toUserMessage()`, and `context` checks should inspect `error.context`.
+
+`unsupported` rows should not silently pass. They should either use an `error` compile expectation or remain `research` until a diagnostic exists.
+
+`partial` rows should compile successfully only when the limitation is explicitly documented. The row should include a `docsAnchor` and an assertion that proves the supported subset.
+
+`research` rows should not pretend to validate support. They should load the fixture only if useful, then state the unresolved decision in the registry.
+
+## Phase 1 Conventions
+
+Prefer committed fixture files over inline WSDL strings. Inline WSDL builders are useful for focused unit tests, but conformance cases should be inspectable as standalone artifacts.
+
+Use the taxonomy path convention in [File Naming And Path Organization](../file-naming-and-path-organization.md) for reusable fixtures. Put imported schemas beside the root WSDL when a capability needs multiple files.
+
+Use a runner-owned temporary directory per capability case. Do not share a module-level temp root across the suite, because conformance failures should leave case-local paths easy to inspect.
+
+Assert catalog shape through stable names and metadata. Avoid full catalog snapshots in Phase 1 because the registry should describe capability contracts, not freeze incidental serialization details.
+
+Assert diagnostics through `WsdlCompilationError` and catalog `diagnostics.notes`. Do not assert full formatted messages unless the exact text is part of the public contract.
+
+Prefer adding feature-level headings in `docs/supported-patterns.md` when a broad section anchor would make the docs check too weak. Keep those headings short and user-facing.
+
 ## Fixture Strategy
 
 Fixtures should live under a dedicated conformance fixture directory, separate from the weather smoke fixture. Each fixture should be minimal, synthetic, deterministic, and focused on one capability unless the purpose is to prove a composition case.
@@ -142,12 +301,29 @@ The inspector should not be treated as proof that generation will succeed. It is
 
 Create the capability registry, fixture directory, and a Vitest runner for compile-stage expectations. Include the existing roadmap priority rows and keep unsupported rows diagnostic or research-only until behavior is proven.
 
+Start with these capability IDs:
+
+| ID | Status | Compile expectation |
+|---|---|---|
+| `choice-union-simple` | supported | success |
+| `xs-union-simple-type` | supported | success |
+| `abstract-complex-type` | diagnostic | error or research |
+| `substitution-group-element` | diagnostic | error or research |
+| `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 |
+| `mtom-xop-attachment` | unsupported | error or research |
+
 Acceptance criteria:
 
 - The registry includes every priority row from the WSDL coverage slice.
 - Each row has a stable ID, status, fixture, and compile expectation.
 - `docs/supported-patterns.md` has matching capability IDs or anchors.
 - The runner works without network access.
+- `npm run test:conformance` passes.
+- `npm test` includes the conformance suite.
+- No Phase 1 change expands the public API.
 
 ## Phase 2: Client And OpenAPI Evidence
 
@@ -206,14 +382,12 @@ Acceptance criteria:
 
 ## Open Decisions
 
-- Decide whether the first registry lives under `test/fixtures` or `test/conformance`.
-- Decide whether conformance should be a normal `npm test` suite or a separate script at first.
 - Decide how much generated output type-checking is acceptable in CI runtime.
 - Decide which inspector output format becomes public before `1.0.0`.
 - 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.28.x` or later patch releases as tests, docs, and diagnostics improve.
+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.
 
 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.

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 released `0.28.x` line. Choice union mode and JSON array streaming must be treated as shipped work, while WSDL coverage and release-candidate gates remain the active 1.0 work.
+`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.
 
 ### 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.28.x` work accurately.
+- `ROADMAP.md` names released `0.30.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-wsdl-coverage-matrix.md

@@ -33,13 +33,13 @@ Each matrix row should have a minimal fixture, an expected support status, and a
 | Feature                    | Expected 1.0 Status     | Notes                                 |
 |----------------------------|-------------------------|---------------------------------------|
 | `xs:choice` union mode     | supported               | Implemented in `0.26.0`               |
-| `xs:union`                 | supported or diagnostic | Decide after fixture work             |
+| `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`          | diagnostic              | Current support is not full           |
+| `xs:anyAttribute`          | partial                 | Metadata retained; generated wildcard attributes deferred |
 | MTOM/XOP attachments       | unsupported diagnostic  | Keep out of 1.0 scope unless required |
 
 ## Manifest Shape

package/docs/supported-patterns.md

@@ -2,6 +2,24 @@
 
 This document lists the WSDL and XSD features handled by the generator, along with current limitations. For modeling details, see [Core Concepts](concepts.md).
 
+## Capability Evidence Matrix
+
+The rows below are backed by committed conformance fixtures under `test/conformance/fixtures/`. Status means the current product contract, not the full standards surface.
+
+<!-- support-matrix:start -->
+| Capability ID | Status | Public contract |
+|---|---|---|
+| `choice-union-simple` | supported | `xs:choice` union mode retains choice metadata and drives generated TypeScript/OpenAPI constraints. |
+| `xs-union-simple-type` | supported | Simple `xs:union` aliases compile to TypeScript unions and OpenAPI `oneOf` schemas. |
+| `abstract-complex-type` | diagnostic | Abstract complex type semantics are not modeled yet; 1.0 should reject or warn instead of treating them as concrete. |
+| `substitution-group-element` | diagnostic | Substitution groups are not expanded yet; 1.0 should avoid silent omission with a diagnostic. |
+| `multi-binding-first-soap` | partial | Multiple bindings are deterministic: the first SOAP binding is selected and all ports are documented. |
+| `external-policy-reference` | partial | Inline policy hints are detected; external `PolicyReference` documents are not fetched or resolved. |
+| `deep-composition-sequence` | supported | Deep nested sequences compile into deterministic type metadata. |
+| `xs-anyattribute` | partial | `xs:anyAttribute` is retained as catalog metadata, but generated wildcard attributes are not emitted. |
+| `mtom-xop-attachment` | unsupported | MTOM/XOP binary attachment transport is outside the 1.0 typed SOAP-to-REST contract. |
+<!-- support-matrix:end -->
+
 ## Fully Supported
 
 These patterns are handled end-to-end: WSDL parsing, TypeScript type generation, OpenAPI schema output, and gateway code generation.
@@ -9,6 +27,7 @@ These patterns are handled end-to-end: WSDL parsing, TypeScript type generation,
 - Complex types with `<xs:sequence>`, `<xs:all>`, and `<xs:choice>` compositors, including recursive nesting
 - Simple content with attributes using the `$value` pattern to preserve text content alongside attribute properties
 - Named simple type restrictions and enumerations emitted as TypeScript aliases and OpenAPI scalar schemas
+- Named `xs:union` simple types emitted as TypeScript alias unions and OpenAPI `oneOf` schemas
 - Type inheritance through `<xs:extension>` and `<xs:restriction>` on both simple and complex content
 - Nested XSD imports across multiple schema files with relative and absolute URI resolution
 - Multiple namespaces with deterministic collision resolution via PascalCase uniqueness
@@ -21,7 +40,7 @@ These patterns are handled end-to-end: WSDL parsing, TypeScript type generation,
 - Multiple WSDL ports and bindings; the first SOAP binding is selected, all ports are documented in service metadata
 - SOAP 1.1 and SOAP 1.2 binding detection
 - Streamable SOAP responses, opt-in per operation via `--stream-config` (ADR-002): client exposes `AsyncIterable<RecordType>`, gateway emits NDJSON or JSON array streams with backpressure, OpenAPI advertises the record schema via `x-wsdl-tsc-stream`
-- `xs:any` wildcard particles retained on compiled types (they used to be dropped silently) — enables honest stream-candidate detection and companion-catalog shape resolution
+- `xs:any` wildcard particles retained on compiled types for stream-candidate detection and companion-catalog shape resolution
 
 ### Named simple types and same-name elements
 
@@ -65,12 +84,19 @@ Groups are inlined into the parent type during schema compilation. The group ide
 
 List types with an `itemType` attribute are detected and generate array types (`${itemType}[]`). Lists defined with inline simple types are not handled.
 
+### xs:union
+
+Union types with `memberTypes` or inline simple type members are detected and generate TypeScript alias unions. Mixed primitive and literal unions generate OpenAPI `oneOf` schemas.
+
+### xs:anyAttribute
+
+Attribute wildcards are retained as catalog metadata on the enclosing compiled type. They are not emitted as typed attribute properties in generated TypeScript or OpenAPI schemas.
+
 ## Not Yet Supported
 
 These features are not currently handled. Contributions are welcome.
 
-- `xs:any` and `xs:anyAttribute`: unrecognized elements fall through to an untyped representation
-- `xs:union` types: only union members expressed as restriction enumerations are captured
+- Full `xs:any` serialization: arbitrary wildcard content is not emitted as a typed contract
 - Abstract types: treated as regular concrete types without substitution logic
 - Substitution groups: not resolved during schema compilation
 - MTOM/XOP binary attachments: no support for binary part handling

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@techspokes/typescript-wsdl-client",
-  "version": "0.30.0",
+  "version": "0.30.3",
   "description": "Turn legacy WSDL/SOAP services into typed TypeScript clients, OpenAPI 3.1 specs, and production-ready Fastify REST gateways. Built for enterprise SOAP modernization.",
   "keywords": [
     "wsdl",
@@ -70,6 +70,7 @@
     "test:unit": "vitest run test/unit",
     "test:snap": "vitest run test/snapshot",
     "test:integration": "vitest run test/integration",
+    "test:conformance": "vitest run test/conformance",
     "test:watch": "vitest",
     "prepublishOnly": "npm run clean && npm run build && npm run package:validate",
     "smoke:reset": "npm run clean:tmp",
@@ -80,7 +81,9 @@
     "smoke:pipeline": "npm run smoke:reset && tsx src/cli.ts pipeline --wsdl-source examples/minimal/weather.wsdl --client-dir tmp/client --openapi-file tmp/openapi.json --gateway-dir tmp/gateway --gateway-service-name weather --gateway-version-prefix v1 --openapi-format json --init-app && tsc -p tsconfig.smoke.json",
     "smoke:app": "npm run smoke:reset && tsx src/cli.ts pipeline --wsdl-source examples/minimal/weather.wsdl --client-dir tmp/client --openapi-file tmp/openapi.json --gateway-dir tmp/gateway --gateway-service-name weather --gateway-version-prefix v1 --openapi-format json --openapi-servers https://example.com/api && tsx src/cli.ts app --client-dir tmp/client --gateway-dir tmp/gateway --openapi-file tmp/openapi.json --app-dir tmp/app --port 8080 && tsc -p tsconfig.smoke.json",
     "maint:deps": "node scripts/maint-deps.mjs",
-    "docs:validate": "node scripts/validate-docs.mjs",
+    "docs:support-matrix": "tsx scripts/generate-support-matrix.ts",
+    "docs:support-matrix:check": "tsx scripts/generate-support-matrix.ts --check",
+    "docs:validate": "node scripts/validate-docs.mjs && npm run docs:support-matrix:check",
     "skill:validate": "node scripts/validate-agent-skill.mjs",
     "skill:package": "node scripts/build-agent-skill.mjs",
     "package:validate": "node scripts/validate-npm-package.mjs",
@@ -90,7 +93,7 @@
   },
   "devDependencies": {
     "@types/js-yaml": "^4.0.9",
-    "@types/node": "^26.0.0",
+    "@types/node": "^26.0.1",
     "@types/yargs": "^17.0.35",
     "fastify": "^5.8.5",
     "fastify-plugin": "^6.0.0",