fix: reject unsupported model envelope versions

[Chloride233]

Summary

The validator now rejects unsupported model envelope versions before validating the element spec.

This keeps schema lookup keyed by model kind. Existing v0.1.0 model envelopes still validate against the registered kind schema, while an unknown non-empty envelope version is reported on version instead of being silently accepted.

Changes

• Keep registry lookup keyed by model kind.
• Add an accepted model envelope version check, currently v0.1.0.
• Report unsupported envelope versions on the version field.
• Add tests for accepted and unsupported envelope versions.

Tests

go test ./internal/umodel/schemaspec
go test ./internal/umodel -run "TestValidate(RejectsInvalidUModelElement|AcceptsValidUModelElements|ReportsUnsupportedEnvelopeVersionOnVersionField)$"
git diff --check

[qiansheng91]

Thanks — the fix is correct and well-tested, and the compatibleVersions handling shows you caught the real subtlety (the manifest declares v0.1.0 while the kind schemas are v1.0.0).

I want to question whether the version-dispatch machinery is warranted yet. In the current tree:

• all 25 embedded schemas (data/*.expanded.yaml) declare exactly one version, all v1.0.0;
• element envelopes carry the manifest version v0.1.0, not a schema version.

So element.Version and versions[].name are different namespaces that never match for real data. Every real element runs LookupVersion(kind, "v0.1.0") → miss in versions → hit compatibleVersions → fall back to Lookup(kind). Consequences:

• the per-version index, the []*Schema refactor, and LookupVersion's version branch are never exercised by real data today;
• compatibleVersions is load-bearing and works by ignoring the version — which is the tell that matching element.Version against schema versions isn't the right model (the envelope version is the system version, not a per-schema one).

The net behavior change is "reject an element.Version that isn't empty or v0.1.0" — a good check, but expressible without the infrastructure:

s := v.registry.Lookup(element.Kind)
if s == nil {
    return Result{}, fmt.Errorf("unknown kind %q", element.Kind)
}
if element.Version != "" && !v.registry.AcceptsVersion(element.Version) {
    return Result{Errors: []Issue{{Path: "version", Reason: ...}}}, nil
}
walk(element.Spec, s.Spec, "spec", &res)

(AcceptsVersion = the accepted envelope-version set, today just v0.1.0.)

Suggestion: keep the win (reject unknown envelope versions), drop the per-version indexing until a kind actually has a second schema version — at which point we'll also need to settle whether element.Version selects a schema version or stays the manifest version, which this currently assumes away. If multi-version schemas are on the near roadmap, let's design that model explicitly first.

[Chloride233]

Thanks, I see the issue now. I had mixed the envelope version with per-kind schema versions in the first revision.

I narrowed the change to just reject unsupported model envelope versions. Schema lookup remains kind-based, and the version-dispatch machinery has been removed. I also updated the PR title and body to match the smaller scope.

[qiansheng91]

This is the right scope now, and quick turnaround — thanks. Lookups stay kind-based and it just rejects versions it doesn't recognize, which was the whole point. Looks good, merging.

One to keep in the back of your mind (nothing to change here): the accepted set now lumps the manifest envelope version in with the schema versions, so an element tagged with a schema version slips through too. Harmless until a kind actually gets a second version — that's when we'll need to pin down what the envelope version really means.