Skip to content

fix: make sdkVersion a string again and re-verify the catalog against OpenWA 0.19.0 - #102

Merged
rmyndharis merged 1 commit into
mainfrom
fix/sdkversion-string-openwa-019
Aug 15, 2026
Merged

fix: make sdkVersion a string again and re-verify the catalog against OpenWA 0.19.0#102
rmyndharis merged 1 commit into
mainfrom
fix/sdkversion-string-openwa-019

Conversation

@rmyndharis

Copy link
Copy Markdown
Owner

Four manifests sent sdkVersion as the number 1. The 2026-08-12 audit's G-44 had flagged the manifests' string "1" against PLUGIN-STANDARD.md's numeric spelling, and #100 aligned the manifests to the standard without checking which side the host agrees with. The host reads the field as a string — its ingress validation runs sdkVersion.split('.') — so a manifest carrying the number throws at load and the plugin comes up ERROR. chatwoot-adapter and supabase-otp-hook declare ingress routes, so the throw was theirs on every host since 0.7.18: a load failure, not a degraded mode. http-action and typebot-connector declare no ingress, so the host never reads the field for them today; theirs was a latent violation of the same contract.

The standard was the wrong side of the disagreement. PLUGIN-STANDARD.md now spells it "1" the way the host types it, and the catalogue gate refuses a manifest whose sdkVersion is not a string like "1" or "1.2" — the same class of check as the id rules, in the same gate. It earned its place immediately: it caught the two no-ingress manifests the host validator cannot reach, because validateIngressManifest returns early when a manifest declares no routes.

The vendored contract now carries the ingress surface. sdkVersion and the typed ingress route (PluginIngressRoute, IngressSignatureSpec, IngressResponseContract) were shipped by the host since 0.7.18 and silently omitted by every earlier alignment. A manifest field the vendored types don't carry is a field nothing checks — which is exactly how the numeric spelling reached main.

Compatibility with OpenWA 0.19.0 was verified, not assumed. Every manifest and entry point was run through the host's own load-time validators — the same validatePluginManifest, validateIngressManifest and main-entry containment the boot scanner and the installer run, taken from the v0.19.0 tag. The 0.19 breaking changes (API master-key length, removed REST endpoints, the plain-http install pin) touch no surface a plugin binds; minOpenWAVersion floors are unchanged. testedOpenWAVersion moves 0.14.0 → 0.19.0 across the catalog, with the verification method recorded in each changelog.

No released zip carried the numeric spelling — the tags predate the change — so nothing was broken in the wild; this closes the gap before a release can ship it.

Verification

  • All ten manifests pass the v0.19.0 host's load-time validation (run against the v0.19.0 tag of the host repo).
  • All ten bundles build and pass the loader contract (require + default export + no leaked handles).
  • 586 tests pass, typecheck clean, catalog regenerated and drift-free (catalog:check).

… OpenWA 0.19.0

The 2026-08-12 audit's G-44 flagged that four manifests sent sdkVersion as the string "1"
while PLUGIN-STANDARD.md spelled it as the number 1, and PR #100 aligned the manifests to
the standard without checking which side the host agrees with. The host reads the field as
a string: its ingress validation runs sdkVersion.split('.'), so a manifest carrying the
number throws at load and the plugin comes up ERROR. chatwoot-adapter and supabase-otp-hook
declare ingress routes, so the throw is theirs on every host since 0.7.18 — a load failure,
not a degraded mode. http-action and typebot-connector declare no ingress, so the host never
reads the field for them today; theirs was a latent violation of the same contract. No
released zip carried the number (the tags predate the change), so nothing was broken in the
wild — this closes the gap before a release can ship it.

The standard now spells it "1" the way the host types it, and the catalogue gate refuses a
manifest whose sdkVersion is not a string like "1" or "1.2" — the same class of check as the
id rules, in the same gate. It earned its place immediately: it caught the two no-ingress
manifests the host validator cannot reach, because validateIngressManifest returns early
when a manifest declares no routes. The vendored contract gains sdkVersion and the typed
ingress route (PluginIngressRoute, IngressSignatureSpec, IngressResponseContract), shipped
by the host since 0.7.18 and silently omitted by every earlier alignment; a manifest field
the vendored types don't carry is a field nothing checks.

Compatibility with OpenWA 0.19.0 was verified by running every manifest and entry point
through the host's own load-time validators — the same validatePluginManifest,
validateIngressManifest and main-entry containment the boot scanner and the installer run.
All ten pass, all ten bundles build and load under the loader contract, and the 0.19
breaking changes (API master-key length, removed REST endpoints, the plain-http install
pin) touch no surface a plugin binds. testedOpenWAVersion moves 0.14.0 -> 0.19.0 across
the catalog, with the verification method recorded in each changelog; minOpenWAVersion
floors are unchanged.
@rmyndharis
rmyndharis merged commit 01ee3d3 into main Aug 15, 2026
1 check passed
@rmyndharis
rmyndharis deleted the fix/sdkversion-string-openwa-019 branch August 15, 2026 08:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant