@techspokes/typescript-wsdl-client 0.30.1 → 0.31.0

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/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;AAqPF;;;;;;;;;GASG;AACH,wBAAgB,cAAc,CAC5B,GAAG,EAAE,WAAW,EAChB,OAAO,EAAE,eAAe,EACxB,YAAY,CAAC,EAAE,YAAY,GAC1B,eAAe,CA4gCjB"}

package/dist/compiler/schemaCompiler.js

@@ -143,6 +143,79 @@ function extractAnnotationDocumentation(node) {
         .join(" ");
     return normalizeDocText(merged);
 }
+function localName(name) {
+    return name.includes(":") ? name.split(":").pop() : name;
+}
+function isTruthyXmlBoolean(value) {
+    return String(value).trim().toLowerCase() === "true" || String(value).trim() === "1";
+}
+function getAttributeByLocalName(node, name) {
+    if (!node || typeof node !== "object") {
+        return undefined;
+    }
+    for (const [key, value] of Object.entries(node)) {
+        if (key.startsWith("@_") && localName(key.slice(2)) === name) {
+            return value;
+        }
+    }
+    return undefined;
+}
+function hasAttributeByLocalName(node, name) {
+    if (Array.isArray(node)) {
+        return node.some(child => hasAttributeByLocalName(child, name));
+    }
+    if (!node || typeof node !== "object") {
+        return false;
+    }
+    if (getAttributeByLocalName(node, name) !== undefined) {
+        return true;
+    }
+    return Object.entries(node)
+        .filter(([key]) => !key.startsWith("@_"))
+        .some(([, value]) => hasAttributeByLocalName(value, name));
+}
+function rejectUnsupportedSchemaConstructs(cat) {
+    for (const schema of cat.schemas) {
+        for (const element of getChildrenWithLocalName(schema.xml, "element")) {
+            const substitutionGroup = getAttributeByLocalName(element, "substitutionGroup");
+            if (substitutionGroup) {
+                throw new WsdlCompilationError(`Unsupported XSD substitution group on element "${element["@_name"] ?? "(anonymous)"}".`, {
+                    element: String(element["@_name"] ?? ""),
+                    namespace: schema.targetNS,
+                    file: cat.wsdlUri,
+                    suggestion: "Substitution groups require polymorphic element expansion. Remove the substitution group or model the accepted concrete element explicitly before generation.",
+                });
+            }
+        }
+        for (const complexType of getChildrenWithLocalName(schema.xml, "complexType")) {
+            if (isTruthyXmlBoolean(getAttributeByLocalName(complexType, "abstract"))) {
+                throw new WsdlCompilationError(`Unsupported abstract complex type "${complexType["@_name"] ?? "(anonymous)"}".`, {
+                    element: String(complexType["@_name"] ?? ""),
+                    namespace: schema.targetNS,
+                    file: cat.wsdlUri,
+                    suggestion: "Abstract complex types require polymorphic instance handling. Use a concrete type or add support for explicit abstract type diagnostics before generation.",
+                });
+            }
+        }
+        for (const element of getChildrenWithLocalName(schema.xml, "element")) {
+            if (isTruthyXmlBoolean(getAttributeByLocalName(element, "abstract"))) {
+                throw new WsdlCompilationError(`Unsupported abstract element "${element["@_name"] ?? "(anonymous)"}".`, {
+                    element: String(element["@_name"] ?? ""),
+                    namespace: schema.targetNS,
+                    file: cat.wsdlUri,
+                    suggestion: "Abstract elements require substitution or polymorphic element handling. Use a concrete element before generation.",
+                });
+            }
+        }
+        if (hasAttributeByLocalName(schema.xml, "expectedContentTypes")) {
+            throw new WsdlCompilationError("Unsupported MTOM/XOP or XML MIME attachment metadata.", {
+                namespace: schema.targetNS,
+                file: cat.wsdlUri,
+                suggestion: "Attachment payloads require MIME or binary transport semantics that are outside the typed SOAP-to-REST generation contract.",
+            });
+        }
+    }
+}
 /**
  * Compile a WSDL catalog into an internal representation (CompiledCatalog).
  * Steps:
@@ -154,6 +227,7 @@ function extractAnnotationDocumentation(node) {
  *    portType reference, then enumerate operations and their soapAction URIs.
  */
 export function compileCatalog(cat, options, streamConfig) {
+    rejectUnsupportedSchemaConstructs(cat);
     // symbol tables discovered across all schemas
     const complexTypes = new Map();
     const simpleTypes = new Map();
@@ -213,6 +287,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 +496,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 +651,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 +675,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 +696,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 +704,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 +720,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 +750,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 +774,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 +783,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.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/releases/v0.31.0.md

@@ -0,0 +1,33 @@
+# TypeScript WSDL Client v0.31.0
+
+## Conformance Evidence Moves Downstream
+
+This release extends the WSDL capability conformance framework beyond compile-only checks and adds diagnostics for unsupported schema constructs that previously risked silent miscompilation.
+
+## What This Improves
+
+Maintainers can now prove supported and partial WSDL capability rows through generated TypeScript clients and validated OpenAPI specs, not only through catalog compilation. This makes the support matrix more trustworthy and gives future gateway-runtime work a stronger base.
+
+Unsupported abstract types, substitution groups, and MTOM/XOP-style attachment metadata now fail with structured diagnostics instead of compiling into misleading contracts.
+
+## Highlights
+
+- Adds generated client type-check evidence for supported and partial WSDL conformance rows.
+- Adds OpenAPI validation and targeted schema assertions for supported and partial WSDL conformance rows.
+- Rejects abstract complex types, substitution groups, and XML MIME attachment metadata with diagnostics.
+- Updates the roadmap so the next 1.0 slice is gateway runtime conformance evidence.
+
+## Upgrade Notes
+
+WSDLs that declare abstract complex types, substitution groups, or XML MIME attachment metadata now fail during compilation with a diagnostic. This is intentional because those constructs require polymorphic or attachment transport semantics that are not part of the current typed SOAP-to-REST contract.
+
+## 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.31.0`.

package/docs/roadmap/README.md

@@ -18,8 +18,8 @@ The plan is optimized for preserving quality. The contract and compatibility bas
 | 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) | planned           | Pipeline claims are test-backed |
-| WSDL coverage matrix  | [WSDL Coverage Matrix](v1.0-wsdl-coverage-matrix.md)                         | remaining         | Feature support is test-backed  |
+| Conformance framework | [Capability Conformance Framework](v1.0-capability-conformance-framework.md) | phase 2 shipped   | Pipeline claims are test-backed |
+| WSDL coverage matrix  | [WSDL Coverage Matrix](v1.0-wsdl-coverage-matrix.md)                         | client and OpenAPI evidence shipped | Feature support is test-backed |
 | Release candidate     | [Release Candidate Gates](v1.0-release-candidate-gates.md)                   | remaining         | 1.0 release is repeatable       |
 
 ## Execution Order
@@ -42,11 +42,11 @@ JSON array streaming is complete in `0.28.0`. The default `ndjson` format remain
 
 ### Slice 5: Capability Conformance Framework
 
-Build the conformance registry, fixture strategy, stage runners, and issue-triage model. This slice turns feature claims into testable pipeline-wide capability cases.
+The registry, fixture strategy, compile runner, client evidence, OpenAPI evidence, documentation drift check, and generated support matrix are shipped. The next work is to extend relevant rows into gateway runtime evidence without expanding public APIs.
 
 ### Slice 6: WSDL Coverage Matrix
 
-Build the automated WSDL feature matrix next. The matrix should drive the remaining WSDL support, diagnostic, and deferral decisions.
+The first WSDL matrix rows now exist as conformance registry entries with compile, client, OpenAPI, and documentation evidence. The next work is to prove relevant rows through generated gateway runtime artifacts.
 
 ### Slice 7: Release Candidate Gates
 
@@ -54,9 +54,9 @@ Run the release candidate gates after feature work and documentation have conver
 
 ## Remaining Before 1.0
 
-- 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.
+- Extend the capability registry beyond OpenAPI evidence into gateway runtime evidence.
+- Add generated gateway checks for supported and partial WSDL rows where HTTP behavior is part of the contract.
+- Turn remaining unsupported, diagnostic, or partial matrix rows into diagnostics, documentation, or scoped fixes.
 - Confirm `docs/supported-patterns.md` matches the matrix.
 - Run the release-candidate gates.
 

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

@@ -1,9 +1,11 @@
 # Version 1.0 Capability Conformance Framework
 
-Status: planned before `1.0.0`.
+Status: Phase 2 shipped; gateway runtime evidence remaining before `1.0.0`.
 
 Plan for turning SOAP, WSDL, OpenAPI, gateway, app, generated-test, and documentation support claims into fixture-backed conformance evidence.
 
+Phase 1 shipped a TypeScript registry, reusable WSDL fixtures, compile-stage runner, documentation drift tests, and generated public support matrix. Phase 2 added generated client type-checking, OpenAPI validation, and executable diagnostics for terminal rows. The next slice should extend relevant rows into gateway runtime evidence before adding more feature rows.
+
 See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
 
 ## Goal
@@ -75,6 +77,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 +93,173 @@ 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 shipped in the `0.30.x` line. Keep this section as the historical baseline and as guardrails for future registry changes.
+
+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
+
+The Phase 1 file map is implemented. Keep these ownership boundaries in place while extending the framework.
+
+`test/conformance/types.ts` owns shared registry types. Keep these types out of `src/` until a public API is justified.
+
+`test/conformance/registry.ts` owns the initial capability rows. Include new priority features from the WSDL coverage matrix here before changing generator behavior.
+
+`test/conformance/runner.ts` owns 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.
+
+`test/conformance/conformance.test.ts` owns manifest-driven compile tests. Supported and partial rows should compile successfully; diagnostic rows should assert the error shape or explicit warning behavior.
+
+`test/conformance/docs.test.ts` owns registry-to-docs alignment. It should validate existing heading anchors and prove that the public evidence matrix matches generated registry output.
+
+`test/conformance/fixtures/` contains minimal WSDL fixtures. Keep each fixture synthetic, deterministic, and scoped to one capability.
+
+`package.json` exposes `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.
@@ -140,7 +305,21 @@ The inspector should not be treated as proof that generation will succeed. It is
 
 ## Phase 1: Registry And Compile Matrix
 
-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.
+The capability registry, fixture directory, and Vitest runner for compile-stage expectations are implemented. 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:
 
@@ -148,9 +327,14 @@ Acceptance criteria:
 - 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
 
+Phase 2 is implemented for the current supported and partial WSDL rows. Keep this section as the baseline for future client and OpenAPI evidence.
+
 Extend supported rows to generate clients and OpenAPI specs. Add type-check verification for generated clients and schema assertions for OpenAPI output.
 
 Acceptance criteria:
@@ -160,6 +344,22 @@ Acceptance criteria:
 - Capability-specific schema strategies are asserted where they matter.
 - Diagnostic rows stop before downstream stages.
 
+Recommended scope:
+
+- Add optional `client` and `openapi` expectation blocks to `CapabilityCase`.
+- Generate artifacts into a temporary directory owned by each capability row.
+- Emit a temporary `tsconfig.json` that includes generated client artifacts and uses repository NodeNext settings.
+- Validate OpenAPI documents through the same validator used by existing OpenAPI tests.
+- Assert public schema contracts for rows that already claim support or partial support.
+
+Skeptical review notes:
+
+- A `supported` status should not rely on compile-only evidence after this phase.
+- `diagnostic` rows currently using `research` compile expectations need either real diagnostics or clearer deferral language.
+- Whole-file snapshots would make conformance brittle; prefer targeted assertions on generated types, schemas, paths, and operation metadata.
+- The support matrix generator should remain limited to the public evidence table, not the human-authored explanatory sections.
+- Keep the inspector out of this slice unless the stage evidence reveals a stable detection model.
+
 ## Phase 3: Gateway Runtime Evidence
 
 Extend relevant rows to generate gateways and test Fastify runtime behavior through `fastify.inject`. Add mock operations clients and request/response fixtures as part of the registry.
@@ -206,8 +406,6 @@ 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.

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

@@ -1,9 +1,11 @@
 # Version 1.0 WSDL Coverage Matrix
 
-Status: remaining before `1.0.0`.
+Status: client and OpenAPI evidence shipped; gateway runtime evidence remaining before `1.0.0`.
 
 Plan for turning WSDL and XSD support claims into automated, fixture-backed evidence before 1.0. This is the first domain under the [Capability Conformance Framework](v1.0-capability-conformance-framework.md).
 
+The initial fixture-backed compile matrix shipped in `0.30.2` and `0.30.3`. Client and OpenAPI evidence now prove the current supported and partial rows, and terminal rows have executable diagnostics. The remaining work is to prove generated gateway runtime artifacts and keep public support claims tied to registry rows.
+
 See the root [README.md](../../README.md) for project overview and [Version 1.0 Roadmap Plan](README.md) for the complete 1.0 route.
 
 ## Goal
@@ -14,32 +16,44 @@ The project should have an automated WSDL and XSD feature matrix that proves whi
 
 Each matrix row should have a minimal fixture, an expected support status, and a test that proves the status. A supported feature must compile and generate aligned client, OpenAPI, and gateway artifacts where applicable. An unsupported feature must fail with a clear diagnostic or be documented as intentionally out of scope.
 
-## Scope
+## Shipped Baseline
+
+- `test/conformance/fixtures/` contains the first priority WSDL fixture set.
+- `test/conformance/registry.ts` lists priority rows with status, decision, provenance, and public contract text.
+- `test/conformance/conformance.test.ts` runs compile-stage expectations for runnable rows.
+- Supported and partial rows generate client artifacts that type-check.
+- Supported and partial rows generate validated OpenAPI specs with targeted contract assertions.
+- Diagnostic and unsupported rows have executable compiler error expectations.
+- `docs/supported-patterns.md` includes a generated capability evidence matrix.
+- `npm run docs:support-matrix:check` prevents support matrix drift.
+
+## Remaining Scope
 
-- Add a fixture directory for WSDL feature coverage.
-- Add a manifest that lists features, status, expected commands, and expected diagnostics.
-- Add Vitest coverage that reads the manifest and runs the relevant generation steps.
-- Update `docs/supported-patterns.md` from the matrix findings.
-- Include priority gaps from the roadmap.
+- Add stage expectations for generated gateway output and runtime behavior.
+- Add generated request and response fixtures where HTTP behavior is part of a capability contract.
+- Keep diagnostics executable as more unsupported rows are added.
+- Keep fixture metadata useful for a future public conformance fixture corpus.
+- Preserve the weather smoke fixture as the canonical end-to-end happy path.
 
 ## Out Of Scope
 
 - Do not implement every unsupported WSDL feature in this slice.
 - Do not replace the existing weather fixture for smoke tests.
-- Do not make docs generated from the manifest unless that is a deliberate later decision.
+- Do not generate the explanatory supported-pattern sections from the registry.
+- Do not add public CLI commands for the inspector until the registry evidence model stabilizes.
 
 ## Priority Feature Rows
 
 | Feature                    | Expected 1.0 Status     | Notes                                 |
 |----------------------------|-------------------------|---------------------------------------|
 | `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
@@ -63,16 +77,20 @@ The manifest should be small and reviewable. A JSON or TypeScript manifest is ac
 
 ### Matrix Runner
 
-Create a Vitest suite that reads the manifest and executes the requested commands through programmatic APIs where possible. CLI smoke behavior should remain covered by existing smoke scripts.
+The existing Vitest suite reads the TypeScript registry and runs compile expectations through programmatic APIs. The next runner should generate artifacts into per-case temporary directories and avoid shelling out where direct generator APIs give better diagnostics.
 
 ### Supported Feature Tests
 
 For supported rows, assert successful compilation, generated TypeScript type-checking, OpenAPI validation, and gateway schema generation when applicable.
 
+Generated client checks should verify that emitted `client.ts`, `types.ts`, `utils.ts`, and `operations.ts` type-check together. OpenAPI checks should validate the full spec and assert capability-specific schema shapes only where the shape is part of the public contract.
+
 ### Diagnostic Feature Tests
 
 For diagnostic rows, assert the exact error class or user-facing message shape. Avoid brittle full-message assertions unless the message is part of the public contract.
 
+Rows marked `diagnostic` should not remain permanent `research` placeholders. If full diagnostics are not implemented in the next slice, the row should say `defer` or carry a clear unresolved decision rather than implying that diagnostic behavior already exists.
+
 ### Documentation Tests
 
 Ensure every documented unsupported or partial feature has a corresponding matrix row. This can be a lightweight consistency test that compares feature IDs with anchors or explicit markers in `docs/supported-patterns.md`.
@@ -80,12 +98,33 @@ Ensure every documented unsupported or partial feature has a corresponding matri
 ## Acceptance Criteria
 
 - The matrix includes every roadmap priority feature.
-- Supported rows have passing fixtures.
-- Unsupported rows fail with clear diagnostics.
+- Supported rows have compile, client, and OpenAPI evidence when those stages apply.
+- Unsupported or diagnostic rows fail with clear diagnostics, or are explicitly deferred without support claims.
 - `docs/supported-patterns.md` reflects the matrix.
 - No known feature silently miscompiles in matrix coverage.
 - The matrix can run in CI or release preflight without network access.
 
+## Next Slice
+
+The next slice should implement Phase 3 gateway runtime evidence for the current registry rows before adding more feature rows. This keeps the matrix honest: support claims become pipeline evidence, while diagnostic and unsupported claims remain stopped before downstream generation.
+
+Work items:
+
+- Add optional `gateway` expectations to the conformance type model.
+- Generate gateway artifacts from each relevant row's OpenAPI document.
+- Type-check generated gateway artifacts with the generated client artifacts.
+- Add mock operations clients and `fastify.inject` assertions where request or response behavior is part of the contract.
+- Leave diagnostic and unsupported rows stopped at compile.
+- Update the generated public support matrix only when a row status or public contract changes.
+
+Gotchas:
+
+- Do not overclaim `supported` when gateway behavior is relevant but unproven.
+- Do not snapshot whole generated files for conformance rows; assert stable contract surfaces instead.
+- Do not share temporary output directories across rows.
+- Do not let diagnostic or unsupported rows proceed to client, OpenAPI, or gateway generation.
+- Do not add a public inspector command in this slice.
+
 ## Release Implications
 
 This slice may reveal features that should be implemented before 1.0. It may also justify explicit post-1.0 deferrals if diagnostics and documentation are strong enough.

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 types are rejected with a diagnostic instead of being treated as concrete. |
+| `substitution-group-element` | diagnostic | Substitution groups are rejected with a diagnostic instead of being silently omitted. |
+| `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 metadata is rejected because 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
@@ -65,15 +84,22 @@ 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.
 
-- Full `xs:any` serialization and `xs:anyAttribute`: arbitrary wildcard content is not emitted as a typed contract
-- `xs:union` types: only union members expressed as restriction enumerations are captured
-- 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
+- Full `xs:any` serialization: arbitrary wildcard content is not emitted as a typed contract
+- Abstract types: rejected with a diagnostic; no polymorphic instance handling
+- Substitution groups: rejected with a diagnostic; no polymorphic element expansion
+- MTOM/XOP binary attachments: rejected with a diagnostic; no binary part handling
 - WS-ReliableMessaging, WS-Addressing beyond basic headers
 - Custom serialization hooks for non-standard XML patterns
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@techspokes/typescript-wsdl-client",
-  "version": "0.30.1",
+  "version": "0.31.0",
   "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",