@techspokes/typescript-wsdl-client 0.30.3 → 0.32.0

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,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"}
+{"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();

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/releases/v0.32.0.md

@@ -0,0 +1,33 @@
+# TypeScript WSDL Client v0.32.0
+
+## Gateway Conformance Evidence
+
+This release extends the WSDL capability conformance framework through generated Fastify gateway artifacts and runtime request checks for the current supported and partial capability rows.
+
+## What This Improves
+
+Maintainers can now verify that documented WSDL support survives the full downstream path from fixture compilation to generated client code, OpenAPI output, generated gateway code, and Fastify request handling. This makes the public support matrix more trustworthy before the project moves into the remaining generated-test and app evidence needed for 1.0.
+
+Conformance mini-projects now run under `tmp/conformance/` inside the repository, which keeps TypeScript and Node module resolution aligned with a consumer-style project while avoiding machine-specific temporary-directory behavior.
+
+## Highlights
+
+- Adds generated gateway type-check evidence for supported and partial WSDL conformance rows.
+- Adds Fastify runtime injection checks for generated gateway routes.
+- Documents `tmp/conformance/` as the architecture boundary for generated conformance projects.
+- Updates the roadmap so the next 1.0 slice is generated-test and app conformance evidence.
+
+## 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.32.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 3 shipped   | Pipeline claims are test-backed |
+| WSDL coverage matrix  | [WSDL Coverage Matrix](v1.0-wsdl-coverage-matrix.md)                         | gateway 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, gateway runtime evidence, documentation drift check, and generated support matrix are shipped. The next work is to extend relevant rows into generated-test and app 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, gateway runtime, and documentation evidence. The next work is to prove relevant rows through generated-test and app artifacts where those stages apply.
 
 ### 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 gateway runtime evidence into generated-test and app evidence.
+- Add generated-test and app checks for supported and partial WSDL rows where those surfaces are 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 3 shipped; generated-test and app 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. Phase 3 added generated gateway type-checking and Fastify runtime evidence for current supported and partial 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
@@ -172,6 +174,8 @@ When full support is clearly local, deterministic, and representable, implement
 
 ## 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.
@@ -188,19 +192,21 @@ The public evidence matrix should be generated from the registry with `npm run d
 
 ## 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.
+The Phase 1 file map is implemented. Keep these ownership boundaries in place while extending the framework.
 
-Create `test/conformance/registry.ts` for the initial capability rows. Include every priority feature from the WSDL coverage matrix.
+`test/conformance/types.ts` owns shared registry types. Keep these types out of `src/` until a public API is justified.
 
-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.
+`test/conformance/registry.ts` owns the initial capability rows. Include new priority features from the WSDL coverage matrix here before changing generator behavior.
 
-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.
+`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.
 
-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.
+`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.
 
-Create `test/conformance/fixtures/` with one minimal WSDL per initial row. Keep each fixture synthetic, deterministic, and scoped to one capability.
+`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.
 
-Modify `package.json` to add `test:conformance` with `vitest run test/conformance`.
+`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.
 
@@ -299,7 +305,7 @@ 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:
 
@@ -327,6 +333,8 @@ Acceptance criteria:
 
 ## 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:
@@ -336,16 +344,187 @@ 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.
+Phase 3 is implemented for the current supported and partial WSDL rows. Keep this section as the baseline for future gateway conformance rows.
 
-Acceptance criteria:
+Extend current supported and partial rows to generate gateways, type-check generated gateway artifacts, and test Fastify runtime behavior through `fastify.inject`. Add mock operations clients and request/response fixtures as part of each row's registry evidence.
+
+### Phase 3 Goal
+
+A supported or partial row should no longer stop at compile, client, and OpenAPI evidence when gateway behavior is relevant. The row should prove that the generated Fastify plugin can be imported, registered with a mock operations client, and exercised through HTTP injection.
+
+Diagnostic and unsupported rows must continue to stop at compile. They must not generate client, OpenAPI, or gateway artifacts after the expected diagnostic.
+
+### Phase 3 Source Files
+
+- `test/conformance/types.ts`
+- `test/conformance/registry.ts`
+- `test/conformance/runner.ts`
+- `test/conformance/conformance.test.ts`
+- `src/gateway/generateGateway.ts`
+- `test/integration/gateway-routes.test.ts`
+
+Use `test/integration/gateway-routes.test.ts` as the runtime pattern for generated plugin imports, mock clients, Fastify registration, and `fastify.inject` assertions. Keep conformance-specific helpers in `test/conformance/runner.ts`.
+
+### Phase 3 Type Model
+
+Add a small optional `gateway` expectation block to `CapabilityCase`. Keep it internal to `test/conformance/types.ts`; do not export it from `src/index.ts` and do not add a public CLI command.
+
+The initial model should stay close to the current `client` and `openapi` expectations:
+
+```ts
+export interface GatewayArtifacts {
+  clientDir: string;
+  gatewayDir: string;
+  openapiFile: string;
+  catalogFile: string;
+  compiled: CompiledCatalog;
+  doc: any;
+  routeFor: (operationId: string) => {method: string; path: string};
+  readGatewayFile: (relativePath: string) => string;
+}
+
+export interface GatewayRequestExpectation {
+  operationId: string;
+  payload: unknown;
+  mockClient: Record<string, (args: unknown) => Promise<{response: unknown; headers: unknown}>>;
+  expectedStatus: number;
+  assertBody?: (body: any) => void;
+  assertClientArgs?: (args: unknown) => void;
+}
+
+export interface GatewayExpectation {
+  outcome: "success";
+  requests?: GatewayRequestExpectation[];
+  sourceIncludes?: Array<{file: string; text: string}>;
+  assert?: (artifacts: GatewayArtifacts) => void | Promise<void>;
+}
+```
+
+This shape is a starting contract, not a generic assertion language. If implementation reveals a simpler local helper, prefer the simpler helper as long as a fresh agent can still understand how to add a new row.
+
+### Phase 3 Runner Flow
+
+`runGatewayCase` should use one temporary output root per capability row and remove it after success. If a row fails, the thrown error should include the capability ID and the generated path involved.
+
+Generated conformance projects should live under `tmp/conformance/`, not the OS temp directory. Gateway conformance generates a small TypeScript project that imports `soap`, `fastify`, `fastify-plugin`, generated JSON schemas, and generated sibling modules. Keeping that project under the repository lets normal Node and TypeScript ancestor lookup find `node_modules`, package metadata, and tool caches without brittle `paths` shims. OS temp directories remain acceptable for unit probes that do not type-check or import generated project graphs.
+
+The runner should perform these steps:
+
+1. Compile the row fixture with `loadWsdl`, `resolveCompilerOptions`, and `compileCatalog`.
+2. Generate client artifacts into `<temp>/client`.
+3. Write `<temp>/client/catalog.json` with `generateCatalog`.
+4. Type-check generated client artifacts using the existing temporary `tsconfig.json` pattern.
+5. Generate OpenAPI into `<temp>/openapi.json` with validation enabled.
+6. Generate gateway artifacts into `<temp>/gateway` with `generateGateway`.
+7. Pass `clientDir`, `catalogFile`, `versionSlug`, and `serviceSlug` to `generateGateway`.
+8. Type-check generated client and gateway artifacts together.
+9. Dynamically import `<temp>/gateway/plugin.ts`.
+10. Register the plugin with `Fastify({logger: false})` and the row's mock operations client.
+11. Resolve each request path from the generated OpenAPI operation when possible.
+12. Execute `fastify.inject` and run row-specific status and body assertions.
+
+Use stable gateway options unless a row declares a reason to override them:
+
+```ts
+await generateGateway({
+  openapiFile,
+  outDir: gatewayDir,
+  clientDir,
+  catalogFile,
+  versionSlug: "v1",
+  serviceSlug: "conformance",
+});
+```
+
+Keep service and version slugs deterministic. Do not derive slugs from temporary paths.
+
+### Phase 3 Registry Scope
+
+Add `gateway` expectations only to rows that already have successful compile, client, and OpenAPI expectations.
+
+Rows expected to receive gateway evidence in this slice:
+
+- `choice-union-simple`
+- `xs-union-simple-type`
+- `multi-binding-first-soap`
+- `external-policy-reference`
+- `deep-composition-sequence`
+- `xs-anyattribute`
+
+Rows that must not receive gateway evidence in this slice:
+
+- `abstract-complex-type`
+- `substitution-group-element`
+- `mtom-xop-attachment`
+
+### Phase 3 Assertion Guidance
+
+Every row with a `gateway` expectation should at least prove plugin import and registration. Add request assertions when HTTP behavior is part of the row's public contract.
+
+For supported rows, prefer one accepted request with a SOAP-wrapper-shaped mock response and an assertion on the generated success envelope. Add one rejected request only when the generated OpenAPI schema can express a meaningful invalid payload for that capability.
+
+For partial rows, prove the documented subset and avoid implying full support. For `xs-anyattribute`, gateway evidence should prove generation and runtime do not emit or require wildcard attribute bags. For external `PolicyReference`, gateway evidence should prove no generated inbound security requirement appears unless configured elsewhere.
+
+For multi-binding rows, assert that the gateway route calls the operation selected by the deterministic first SOAP binding behavior. Do not implement explicit binding selection in this slice.
+
+### Phase 3 Non-Goals
+
+- Do not add new WSDL feature rows.
+- Do not add a public inspector command.
+- Do not change generated gateway public APIs unless gateway evidence exposes a real bug.
+- Do not snapshot whole generated files.
+- Do not treat plugin generation alone as runtime support.
+- Do not proceed past compile for diagnostic or unsupported rows.
+
+### Phase 3 Acceptance Criteria
+
+- `CapabilityCase` supports optional gateway expectations.
+- `test/conformance/conformance.test.ts` requires gateway expectations for supported and partial rows.
+- `runGatewayCase` generates client, catalog, OpenAPI, and gateway artifacts in a row-local temp directory.
+- Generated client and gateway artifacts type-check together.
+- Generated plugins import and register successfully in Fastify.
+- Gateway request expectations run through `fastify.inject`.
+- Diagnostic and unsupported rows remain compile-terminal.
+- `npm run test:conformance` passes.
+- `npm run typecheck` passes.
+- `npm run docs:validate` passes after any support matrix or roadmap updates.
+
+### Phase 3 Test-First Sequence
+
+Start by adding the type fields, the downstream declaration guard, and the `runGatewayCase` test call. The first focused run of `npm run test:conformance` should fail because registry rows do not yet declare gateway expectations or because the runner is not implemented.
+
+Then implement the runner helper and add the smallest gateway expectations per row. Keep failures local: if one row exposes a real gateway bug, either fix the bug with focused tests or downgrade the row's public contract only when the decision framework supports that change.
+
+### Phase 3 Verification Commands
+
+Run these commands before concluding the slice:
+
+```bash
+npm run test:conformance
+npm run typecheck
+npm run docs:validate
+npm test
+```
 
-- Supported gateway rows register generated plugins successfully.
-- Valid request fixtures return expected envelopes or streams.
-- Invalid request fixtures fail with expected status codes.
-- Stream rows prove NDJSON and JSON array behavior separately.
+Run `npm run smoke:pipeline` as a final end-to-end guard if gateway generator behavior changes outside the conformance runner.
 
 ## Phase 4: Generated Test And App Evidence
 

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: gateway runtime evidence shipped; generated-test and app 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, OpenAPI, and gateway runtime evidence now prove the current supported and partial rows, and terminal rows have executable diagnostics. The remaining work is to prove generated-test and app artifacts where those surfaces are part of the contract.
+
 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,19 +16,32 @@ 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.
+- Supported and partial rows generate gateway artifacts that type-check and run through Fastify injection.
+- 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.
 
-- 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.
+## Remaining Scope
+
+- Add stage expectations for generated tests and app scaffolds where those surfaces are part of a capability contract.
+- Add generated request and response fixtures for generated-test coverage 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
 
@@ -63,16 +78,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 +99,85 @@ 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.
 
+## Gateway Runtime Evidence
+
+Phase 3 gateway runtime evidence is shipped for the current supported and partial rows. The current matrix now proves the WSDL to client to OpenAPI to Fastify path for rows that claim support or partial support.
+
+Use [Capability Conformance Framework](v1.0-capability-conformance-framework.md) as the detailed implementation baseline. This section defines the WSDL-matrix-specific shipped scope.
+
+### Phase 3 Shipped Scope
+
+- Optional `gateway` expectations exist in the conformance type model.
+- Gateway artifacts are generated from each relevant row's OpenAPI document.
+- The generated `catalog.json` is written before gateway generation.
+- Generated gateway artifacts type-check with the generated client artifacts.
+- Mock operations clients and `fastify.inject` assertions cover HTTP behavior.
+- Diagnostic and unsupported rows stop at compile.
+- The generated public support matrix remains status-focused.
+
+### Phase 3 Row Scope
+
+Rows that should gain gateway evidence:
+
+- `choice-union-simple`
+- `xs-union-simple-type`
+- `multi-binding-first-soap`
+- `external-policy-reference`
+- `deep-composition-sequence`
+- `xs-anyattribute`
+
+Rows that should stay compile-terminal:
+
+- `abstract-complex-type`
+- `substitution-group-element`
+- `mtom-xop-attachment`
+
+### Phase 3 Runtime Expectations
+
+Each gateway-enabled row should prove plugin import, plugin registration, and at least one `fastify.inject` request when route behavior is relevant. Assertions should inspect the generated success or error envelope, not just the existence of generated files.
+
+Partial rows must prove only the documented subset. `xs:anyAttribute` should not imply generated wildcard attribute bags. External `PolicyReference` should not imply fetched or enforced external policy.
+
+### Phase 3 Gotchas
+
+- Do not overclaim `supported` when gateway behavior is relevant but unproven.
+- Do not snapshot whole generated files for conformance rows; assert stable contract surfaces instead.
+- Do not 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.
+
+### Next Slice
+
+The next slice is Phase 4 generated-test and app evidence. Implement it before adding more feature rows unless a production bug requires a focused diagnostic or support decision.
+
+Work items:
+
+- Add optional generated-test expectations for rows where `--test-dir` behavior is part of the contract.
+- Generate app scaffolds for rows where app wiring is affected by the capability.
+- Type-check generated app artifacts when an app expectation is present.
+- Run generated tests only for rows that request generated-test evidence.
+- Keep diagnostic and unsupported rows stopped at compile.
+- Update public docs only when a row status or public contract changes.
+
+### Verification
+
+Run these commands before the slice is considered ready:
+
+```bash
+npm run test:conformance
+npm run typecheck
+npm run docs:validate
+npm test
+```
+
+Run `npm run smoke:pipeline` if the gateway generator or pipeline behavior changes.
+
 ## 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

@@ -11,13 +11,13 @@ The rows below are backed by committed conformance fixtures under `test/conforma
 |---|---|---|
 | `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. |
+| `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 transport is outside the 1.0 typed SOAP-to-REST contract. |
+| `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
@@ -97,9 +97,9 @@ Attribute wildcards are retained as catalog metadata on the enclosing compiled t
 These features are not currently handled. Contributions are welcome.
 
 - 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
+- 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.3",
+  "version": "0.32.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",