Conformance corpus still uses `type: INTEGER` — should be NUMBER per §10

[justinmerrell]

Summary

Spec §10 defines the primitive shape vocabulary as STRING, NUMBER, BOOLEAN, JSON. The conformance corpus at least two places still uses the (now-retired) INTEGER token:

• conformance/component/v1/structural/036-public-port-on-udp-endpoint/case.yaml — line ~24: type: INTEGER on gamePort input schema.
• conformance/blueprint/v1/semantic/012-connection-type-mismatch/tree/acme-wiki/components/postgres.yaml — port output declares type: INTEGER.

Why it matters

A validator that has aligned its wire vocabulary with §10 (i.e. accepts NUMBER, rejects INTEGER) now:

• fails structural-036 structurally with ERR_INVALID_VALUE instead of the corpus's expected pass;
• silently accepts semantic-012 (the postgres component fails structural before its INTEGER↔STRING mismatch can be evaluated), producing "platform accepted the document" instead of the expected ERR_INCOMPATIBLE_TYPE.

Proposed change

Rename type: INTEGER → type: NUMBER in both fixtures. This aligns the corpus with §10's vocabulary and unblocks conformant validators.

Downstream

Filed from musher-dev/platform PR #1997, which adopted the §10 vocabulary and had to add a pin for the two cases until this lands.

/label bug conformance

[justinmerrell]

Thanks for filing this — it found a real divergence, but with the direction reversed, and the fix as proposed would have broken CI here. Details, since they matter for the platform side too.

There is no §10 vocabulary in this repository. Component §10 is Known debt; blueprint §10 and listing §10 are Security considerations. No spec.md enumerated the members anywhere — the §10 cited here belongs to musher-dev/platform.

The vocabulary lived only in the schema, as enum: ["STRING", "INTEGER", "BOOLEAN"] on $defs.ComponentValueSchema.type and $defs.BlueprintParameterValueSchema.type. NUMBER and JSON appeared nowhere in the repo, so type: NUMBER was rejected here. Renaming the two fixtures would therefore have produced exactly the two symptoms described above, mirrored:

• structural-036 is an expected: pass case; it would have failed with ERR_INVALID_VALUE.
• semantic-012 would have died structurally before reaching the ERR_INCOMPATIBLE_TYPE it exists to pin.

Verified against main before changing anything:

{ "ok": false, "phase": "structural",
  "diagnostics": [ { "code": "ERR_INVALID_VALUE",
                     "path": "/spec/contract/inputs/gamePort/schema/type" } ] }

Scope was 7 corpus hits, not 2 — blueprint/semantic/009, 012 and 019 (plus their explanatory comments) and component/structural/036 — and beyond the corpus, 3 stale uses in blueprint prose and the two schema modules themselves.

So the corpus was not out of step with the specification; it was exactly in step, and the specification was out of step with the platform. That is a reconciliation of the kind ADR 0005 and ADR 0010 handle rather than a fixture rename, and #57 does it: INTEGER withdrawn, NUMBER and JSON added, the vocabulary given a normative home in new component §6.3, and the reasoning recorded in ADR 0013.

Two things worth carrying back to platform PR #1997:

1. pattern and enum are now forbidden on a JSON value, and format is confined to STRING. One JSON value has many spellings, so a constraint written over the spelling accepts one author's formatter and rejects another's. PR #1997 carries the vocabulary but not these restrictions, so the platform is the looser of the two until it adopts them.
2. The pin for structural-036 and semantic-012 can be lifted once feat: reconcile the value-shape vocabulary — STRING, NUMBER, BOOLEAN, JSON #57 lands and you pick up the new suite commit — and note that blueprint/semantic/009 and 019 also moved, which the original pin did not cover.

Closing this as filed on a premise that does not hold here; #57 is the work, and it links back to this issue.