chore(deps): bump the metaobjects group with 6 updates

[dependabot]

Bumps the metaobjects group with 6 updates:

Package	From	To
@metaobjectsdev/cli	0.24.3	0.24.5
@metaobjectsdev/codegen-ts	0.24.3	0.24.5
@metaobjectsdev/render	0.24.3	0.24.5
@metaobjectsdev/runtime-ts	0.24.3	0.24.5
@metaobjectsdev/sdk	0.24.3	0.24.5
@metaobjectsdev/metadata	0.24.3	0.24.5

Updates @metaobjectsdev/cli from 0.24.3 to 0.24.5

Release notes

Sourced from @​metaobjectsdev/cli's releases.

0.24.5 / 7.24.5 — codegen ownership is the framework story

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Changelog

Sourced from @​metaobjectsdev/cli's changelog.

[0.24.5] — npm 0.24.5 · PyPI 0.24.5 · NuGet 0.24.5 · Maven 7.24.5 — 2026-08-30

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Commits

• d504409 chore(release): @​metaobjectsdev TypeScript packages 0.24.5
• 0cbb7dd refactor(codegen,cli): one dependency answer, and coverage the compiler checks
• 018e5a9 fix(cli): eject stated one project state as fact, and gate the form's directive
• 4ce87c4 fix(cli): meta init claimed a db stub it had just decided not to write
• ad2d8e7 test(cli): a project that runs meta gen cannot live in the OS tmpdir
• 61f670a refactor(codegen): the hono emit set and warn set are one predicate
• 7887cd8 test(cli): one built-CLI harness, not two copies of the fragile part
• 6cb0c32 refactor(codegen): validate template names where the value is untrusted, once
• df790c8 fix(cli): meta init stops asserting things about its own scaffold that aren't...
• bff70da fix(cli): meta eject tells you to REPLACE the import, and names the missing dep
• Additional commits viewable in compare view

Updates @metaobjectsdev/codegen-ts from 0.24.3 to 0.24.5

Release notes

Sourced from @​metaobjectsdev/codegen-ts's releases.

0.24.5 / 7.24.5 — codegen ownership is the framework story

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Changelog

Sourced from @​metaobjectsdev/codegen-ts's changelog.

[0.24.5] — npm 0.24.5 · PyPI 0.24.5 · NuGet 0.24.5 · Maven 7.24.5 — 2026-08-30

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Commits

• d504409 chore(release): @​metaobjectsdev TypeScript packages 0.24.5
• 0cbb7dd refactor(codegen,cli): one dependency answer, and coverage the compiler checks
• 697d80d feat(codegen): clientDirective — the "use client" knob (FR-040 §6.4)
• 61f670a refactor(codegen): the hono emit set and warn set are one predicate
• 6cb0c32 refactor(codegen): validate template names where the value is untrusted, once
• 11d964e test(codegen): gate all nine ejectable templates, not just the original four
• 61857d2 fix(codegen): correct entity/queries targets: swap-point to the default path ...
• 30b9ee9 docs(codegen): every reference template declares its targets: (FR-040 4.2)
• 94face5 feat(codegen): routes-hono reference template (FR-040 4.1)
• c0bc0d2 feat(codegen): per-package reference-template reader (FR-040 4.1)
• Additional commits viewable in compare view

Updates @metaobjectsdev/render from 0.24.3 to 0.24.5

Release notes

Sourced from @​metaobjectsdev/render's releases.

0.24.5 / 7.24.5 — codegen ownership is the framework story

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Changelog

Sourced from @​metaobjectsdev/render's changelog.

[0.24.5] — npm 0.24.5 · PyPI 0.24.5 · NuGet 0.24.5 · Maven 7.24.5 — 2026-08-30

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Commits

• d504409 chore(release): @​metaobjectsdev TypeScript packages 0.24.5
• 0c93be4 chore(release): @​metaobjectsdev TypeScript packages 0.24.4
• See full diff in compare view

Updates @metaobjectsdev/runtime-ts from 0.24.3 to 0.24.5

Release notes

Sourced from @​metaobjectsdev/runtime-ts's releases.

0.24.5 / 7.24.5 — codegen ownership is the framework story

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Changelog

Sourced from @​metaobjectsdev/runtime-ts's changelog.

[0.24.5] — npm 0.24.5 · PyPI 0.24.5 · NuGet 0.24.5 · Maven 7.24.5 — 2026-08-30

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Commits

• d504409 chore(release): @​metaobjectsdev TypeScript packages 0.24.5
• 4c3690a fix: eight defects found by adopting the product from scratch, twice
• 0c93be4 chore(release): @​metaobjectsdev TypeScript packages 0.24.4
• See full diff in compare view

Updates @metaobjectsdev/sdk from 0.24.3 to 0.24.5

Release notes

Sourced from @​metaobjectsdev/sdk's releases.

0.24.5 / 7.24.5 — codegen ownership is the framework story

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Changelog

Sourced from @​metaobjectsdev/sdk's changelog.

[0.24.5] — npm 0.24.5 · PyPI 0.24.5 · NuGet 0.24.5 · Maven 7.24.5 — 2026-08-30

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Commits

• d504409 chore(release): @​metaobjectsdev TypeScript packages 0.24.5
• 352f134 fix(agent-context): a context newer than the install is not stale — all four ...
• 0c93be4 chore(release): @​metaobjectsdev TypeScript packages 0.24.4
• See full diff in compare view

Updates @metaobjectsdev/metadata from 0.24.3 to 0.24.5

Release notes

Sourced from @​metaobjectsdev/metadata's releases.

0.24.5 / 7.24.5 — codegen ownership is the framework story

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Changelog

Sourced from @​metaobjectsdev/metadata's changelog.

[0.24.5] — npm 0.24.5 · PyPI 0.24.5 · NuGet 0.24.5 · Maven 7.24.5 — 2026-08-30

All four registries publish, and not one of them is a version-parity bump — each carries a changed product file of its own (npm: FR-040 + the eight-defect batch; PyPI/NuGet/Maven: columnNamingStrategy, @column, the Maven <sourceDir> fix, the C# hash-manifest anchor, and the agent-context staleness nudge in every port). That the first release under publish-what-changed publishes everything is a coincidence of what landed, not the rule reasserting itself. metamodelVersion stays 0.13: no registered vocabulary changed.

A registry now publishes only when it changed. The version-parity rule standing since 0.20.13 is retired, and this is the first release cut under its replacement — so the four registries may legitimately carry different numbers from here on.

Changed — publish what changed; converge the number when you do

docs/RELEASING.md contradicted itself five lines apart. It mandated "every release bumps all four registries, with version-parity bumps where a port has no changed file" and then stated that the conformance corpus + CAPABILITIES.json — "not a shared version" — is the coordination point. Both cannot be the rule. If the shared version is not what carries the cross-language guarantee, publishing byte-identical content to three registries to keep it aligned buys nothing; the phrase "version-parity bump" appears ten times in this file paying for it. 0.24.3 and 0.24.4 were each a single changed file in cli, and each became a four-registry event.

The new rule: a registry publishes only when it has a changed product file, and when it does it adopts the current shared minor.patch, skipping the numbers it sat out. Two carve-outs, because only ONE lockstep relaxes — the 14 npm packages still move atomically with each other (they cross-depend), and a change to expected-registry.json / metamodelVersion still forces all four, because that is the cross-port contract every port byte-matches.

A lagging version becomes information: PyPI at 0.24.4 while npm is at 0.24.7 says PyPI has had no product change since 0.24.4. Under parity that was unreadable, because every registry carried the same number whether or not anything in it had moved.

scripts/release-verify.mjs gains --registries=npm,pypi,nuget,maven so a cut verifies only what it published; without it the script reports a red ✗ for a port behaving exactly as the rule requires, and a gate that fails on correct behaviour is one people learn to run with their eyes closed. The default stays all four — forgetting the flag over-checks rather than under-checks — and a scoped run names the registries it did not check on every invocation, because a partial run printing only ✓s reads exactly like a full one.

Fixed — a context newer than the install is not stale (all five ports)

The rule above broke the agent-context staleness nudge, in every port, and the fix ships in the same release. A port now legitimately sits behind npm — while meta agent-docs, the canonical scaffolder for every port, stamps the npm version it ran from. So a Python install at 0.24.4 whose context was scaffolded by npm 0.24.7 is correct, and every port nudged it; running the suggested remedy re-stamps 0.24.7, so the advisory could never be satisfied and fired on every build forever. That is #347 exactly, reborn in four ports at once — the JVM through stalenessAcrossVersionLines, and TS / C# / Python through plain equality on their own 0.x line. One bug, three different routes.

... (truncated)

Commits

• d504409 chore(release): @​metaobjectsdev TypeScript packages 0.24.5
• fa18f81 fix(requirements): viewWeb promised a control; view.web is an abstract base
• 5c95b1d docs(spec): the capability ledger doc disagreed with the loader in three places
• 0c93be4 chore(release): @​metaobjectsdev TypeScript packages 0.24.4
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• `@dependabot ...

Description has been truncated