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

[dependabot]

Bumps the metaobjects group with 6 updates:

Package	From	To
@metaobjectsdev/cli	0.20.9	0.20.11
@metaobjectsdev/codegen-ts	0.20.9	0.20.11
@metaobjectsdev/render	0.20.9	0.20.11
@metaobjectsdev/runtime-ts	0.20.9	0.20.11
@metaobjectsdev/sdk	0.20.9	0.20.11
@metaobjectsdev/metadata	0.20.9	0.20.11

Updates @metaobjectsdev/cli from 0.20.9 to 0.20.11

Release notes

Sourced from @​metaobjectsdev/cli's releases.

v0.20.11 — shared-enum cross-package + migrate PK-refuse (coordinated)

Coordinated PATCH — npm `0.20.11` · PyPI `0.20.11` · NuGet `0.20.11` · Maven Central `7.20.11`.

This cut also re-baselines the version numbers: the three semver-`0.x` registries (npm/PyPI/NuGet) now share one number (`0.20.11`), and Maven aligns its `minor.patch` to match (`7.20.11`, keeping its historical major `7`), so "the 20.11 release" maps across every registry. Going forward, coordinated releases keep the shared minor in lockstep; npm may run a patch ahead between cuts.

Shipped

• #246 — a `field.enum` may now be shared across packages (Kotlin table generator emits the cross-package shared-enum import), and a conflicting redeclaration is rejected instead of silently dropped: new cross-port loader error `ERR_ENUM_EXTENDS_VALUES_CONFLICT` (a `field.enum` that both `extends` a shared package-level abstract enum and declares its own `@values`). Loader change in all five ports; Kotlin codegen on Maven.
• #259 (sibling of #246, Kotlin codegen) — a `field.enum` inheriting `@values` through two `extends` hops (projection → entity → shared abstract) now materializes its own per-projection enum instead of generating nothing.
• #258 (npm-only, `migrate-ts` + `cli`) — `meta migrate` now refuses a primary-key move with a clear error (detect-and-refuse) instead of silently emitting an un-appliable migration that drops the PK and breaks referencing foreign keys.

No metadata vocabulary changes; byte-identical output for any model that doesn't hit the specific cross-package/two-hop enum shapes (and, for #258, any migration that isn't a primary-key move).

See CHANGELOG.md for full detail.

Changelog

Sourced from @​metaobjectsdev/cli's changelog.

Fixed — server/python/uv.lock still pinned metaobjects at 0.20.11

The 0.20.14 cut bumped pyproject.toml without regenerating the lock.

[0.20.14] — npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven 7.20.14

Scope: npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven Central 7.20.14 — coordinated at the shared patch number per the single-shared-patch policy ([0.20.13]). Every changed product file is npm-only: the migrate fix lives in @metaobjectsdev/cli, and the corrected agent-context ships via @metaobjectsdev/sdk — the only package on any registry that bundles the repo-root agent-context/ tree (the Python wheel vendors none, its build hook is a no-op; the C# dotnet meta agent-docs and the Maven AgentDocsMojo are redirect stubs to the Node CLI). PyPI, NuGet and Maven Central are version-parity bumps with no changed product file.

Fixed — the live-DB meta migrate path now advances the committed snapshot

The day-1 command meta init prints as its next step —

meta migrate --from-db --db file:dev.sqlite --dialect sqlite --slug init --apply

— created the schema but never wrote the committed reference snapshot. The very next day-2 command in the documented everyday flow (meta migrate --dialect sqlite --slug <name>, the offline incremental path) then failed with no schema snapshot on a project whose database was provably correct, and pointed the user back at the day-1 command. Recovery via meta migrate baseline --from-db worked, but the happy path should not need a recovery step.

The --apply-without---from-db variant — also documented, as "…and apply it" — had it worse: no warning at all, and because the snapshot stayed behind, the next offline diff re-emitted the already-applied change, producing a migration that fails at apply.

Root cause: the live-introspection path writes the same migration files the offline path does, but skipped the same bookkeeping. It now writes the metadata-expected schema as the snapshot — byte-identical to the nextSnapshot the offline path persists, so the two paths converge on one representation and a follow-up offline diff sees no phantom churn. Guarded on a clean run: --dry-run writes nothing, and a blocked, refused, or apply-failed run leaves the snapshot untouched rather than recording a schema the database is not in. The now-obsolete --from-db did not advance the committed snapshot warning is gone.

The snapshot advances exactly when the run wrote a migration — the rule the offline path already follows (it returns on no changes before writing). A live run that emits nothing leaves it alone: recording the target schema as already-applied with no CREATE TABLE anywhere would be the greenfield-baseline trap by another door, leaving the offline path reporting no changes forever and apply-pending provisioning an empty database. The snapshot also now carries the

... (truncated)

Commits

• eb18349 chore(release): 0.20.11 coordinated (npm/PyPI/NuGet 0.20.11 · Maven 7.20.11)
• 737d324 no-mistakes(review): Guard D1 migrate path against primary-key moves (#258)
• 272ee9d fix(#258): migrate refuses a primary-key move instead of silently dropping th...
• 83eae12 chore(release): npm 0.20.10 · PyPI 0.19.9 · NuGet 0.19.7 · Maven 7.11.7
• 9f723cc fix: derive persistability from source presence, not object subtype (#249)
• See full diff in compare view

Updates @metaobjectsdev/codegen-ts from 0.20.9 to 0.20.11

Release notes

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

v0.20.11 — shared-enum cross-package + migrate PK-refuse (coordinated)

Coordinated PATCH — npm `0.20.11` · PyPI `0.20.11` · NuGet `0.20.11` · Maven Central `7.20.11`.

This cut also re-baselines the version numbers: the three semver-`0.x` registries (npm/PyPI/NuGet) now share one number (`0.20.11`), and Maven aligns its `minor.patch` to match (`7.20.11`, keeping its historical major `7`), so "the 20.11 release" maps across every registry. Going forward, coordinated releases keep the shared minor in lockstep; npm may run a patch ahead between cuts.

Shipped

• #246 — a `field.enum` may now be shared across packages (Kotlin table generator emits the cross-package shared-enum import), and a conflicting redeclaration is rejected instead of silently dropped: new cross-port loader error `ERR_ENUM_EXTENDS_VALUES_CONFLICT` (a `field.enum` that both `extends` a shared package-level abstract enum and declares its own `@values`). Loader change in all five ports; Kotlin codegen on Maven.
• #259 (sibling of #246, Kotlin codegen) — a `field.enum` inheriting `@values` through two `extends` hops (projection → entity → shared abstract) now materializes its own per-projection enum instead of generating nothing.
• #258 (npm-only, `migrate-ts` + `cli`) — `meta migrate` now refuses a primary-key move with a clear error (detect-and-refuse) instead of silently emitting an un-appliable migration that drops the PK and breaks referencing foreign keys.

No metadata vocabulary changes; byte-identical output for any model that doesn't hit the specific cross-package/two-hop enum shapes (and, for #258, any migration that isn't a primary-key move).

See CHANGELOG.md for full detail.

Changelog

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

Fixed — server/python/uv.lock still pinned metaobjects at 0.20.11

The 0.20.14 cut bumped pyproject.toml without regenerating the lock.

[0.20.14] — npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven 7.20.14

Scope: npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven Central 7.20.14 — coordinated at the shared patch number per the single-shared-patch policy ([0.20.13]). Every changed product file is npm-only: the migrate fix lives in @metaobjectsdev/cli, and the corrected agent-context ships via @metaobjectsdev/sdk — the only package on any registry that bundles the repo-root agent-context/ tree (the Python wheel vendors none, its build hook is a no-op; the C# dotnet meta agent-docs and the Maven AgentDocsMojo are redirect stubs to the Node CLI). PyPI, NuGet and Maven Central are version-parity bumps with no changed product file.

Fixed — the live-DB meta migrate path now advances the committed snapshot

The day-1 command meta init prints as its next step —

meta migrate --from-db --db file:dev.sqlite --dialect sqlite --slug init --apply

— created the schema but never wrote the committed reference snapshot. The very next day-2 command in the documented everyday flow (meta migrate --dialect sqlite --slug <name>, the offline incremental path) then failed with no schema snapshot on a project whose database was provably correct, and pointed the user back at the day-1 command. Recovery via meta migrate baseline --from-db worked, but the happy path should not need a recovery step.

The --apply-without---from-db variant — also documented, as "…and apply it" — had it worse: no warning at all, and because the snapshot stayed behind, the next offline diff re-emitted the already-applied change, producing a migration that fails at apply.

Root cause: the live-introspection path writes the same migration files the offline path does, but skipped the same bookkeeping. It now writes the metadata-expected schema as the snapshot — byte-identical to the nextSnapshot the offline path persists, so the two paths converge on one representation and a follow-up offline diff sees no phantom churn. Guarded on a clean run: --dry-run writes nothing, and a blocked, refused, or apply-failed run leaves the snapshot untouched rather than recording a schema the database is not in. The now-obsolete --from-db did not advance the committed snapshot warning is gone.

The snapshot advances exactly when the run wrote a migration — the rule the offline path already follows (it returns on no changes before writing). A live run that emits nothing leaves it alone: recording the target schema as already-applied with no CREATE TABLE anywhere would be the greenfield-baseline trap by another door, leaving the offline path reporting no changes forever and apply-pending provisioning an empty database. The snapshot also now carries the

... (truncated)

Commits

• eb18349 chore(release): 0.20.11 coordinated (npm/PyPI/NuGet 0.20.11 · Maven 7.20.11)
• 83eae12 chore(release): npm 0.20.10 · PyPI 0.19.9 · NuGet 0.19.7 · Maven 7.11.7
• 9f723cc fix: derive persistability from source presence, not object subtype (#249)
• d9822bd fix(codegen): extend ADR-0044 collision-naming to extract/output-parser tier ...
• See full diff in compare view

Updates @metaobjectsdev/render from 0.20.9 to 0.20.11

Release notes

Sourced from @​metaobjectsdev/render's releases.

v0.20.11 — shared-enum cross-package + migrate PK-refuse (coordinated)

Coordinated PATCH — npm `0.20.11` · PyPI `0.20.11` · NuGet `0.20.11` · Maven Central `7.20.11`.

This cut also re-baselines the version numbers: the three semver-`0.x` registries (npm/PyPI/NuGet) now share one number (`0.20.11`), and Maven aligns its `minor.patch` to match (`7.20.11`, keeping its historical major `7`), so "the 20.11 release" maps across every registry. Going forward, coordinated releases keep the shared minor in lockstep; npm may run a patch ahead between cuts.

Shipped

• #246 — a `field.enum` may now be shared across packages (Kotlin table generator emits the cross-package shared-enum import), and a conflicting redeclaration is rejected instead of silently dropped: new cross-port loader error `ERR_ENUM_EXTENDS_VALUES_CONFLICT` (a `field.enum` that both `extends` a shared package-level abstract enum and declares its own `@values`). Loader change in all five ports; Kotlin codegen on Maven.
• #259 (sibling of #246, Kotlin codegen) — a `field.enum` inheriting `@values` through two `extends` hops (projection → entity → shared abstract) now materializes its own per-projection enum instead of generating nothing.
• #258 (npm-only, `migrate-ts` + `cli`) — `meta migrate` now refuses a primary-key move with a clear error (detect-and-refuse) instead of silently emitting an un-appliable migration that drops the PK and breaks referencing foreign keys.

No metadata vocabulary changes; byte-identical output for any model that doesn't hit the specific cross-package/two-hop enum shapes (and, for #258, any migration that isn't a primary-key move).

See CHANGELOG.md for full detail.

Changelog

Sourced from @​metaobjectsdev/render's changelog.

Fixed — server/python/uv.lock still pinned metaobjects at 0.20.11

The 0.20.14 cut bumped pyproject.toml without regenerating the lock.

[0.20.14] — npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven 7.20.14

Scope: npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven Central 7.20.14 — coordinated at the shared patch number per the single-shared-patch policy ([0.20.13]). Every changed product file is npm-only: the migrate fix lives in @metaobjectsdev/cli, and the corrected agent-context ships via @metaobjectsdev/sdk — the only package on any registry that bundles the repo-root agent-context/ tree (the Python wheel vendors none, its build hook is a no-op; the C# dotnet meta agent-docs and the Maven AgentDocsMojo are redirect stubs to the Node CLI). PyPI, NuGet and Maven Central are version-parity bumps with no changed product file.

Fixed — the live-DB meta migrate path now advances the committed snapshot

The day-1 command meta init prints as its next step —

meta migrate --from-db --db file:dev.sqlite --dialect sqlite --slug init --apply

— created the schema but never wrote the committed reference snapshot. The very next day-2 command in the documented everyday flow (meta migrate --dialect sqlite --slug <name>, the offline incremental path) then failed with no schema snapshot on a project whose database was provably correct, and pointed the user back at the day-1 command. Recovery via meta migrate baseline --from-db worked, but the happy path should not need a recovery step.

The --apply-without---from-db variant — also documented, as "…and apply it" — had it worse: no warning at all, and because the snapshot stayed behind, the next offline diff re-emitted the already-applied change, producing a migration that fails at apply.

Root cause: the live-introspection path writes the same migration files the offline path does, but skipped the same bookkeeping. It now writes the metadata-expected schema as the snapshot — byte-identical to the nextSnapshot the offline path persists, so the two paths converge on one representation and a follow-up offline diff sees no phantom churn. Guarded on a clean run: --dry-run writes nothing, and a blocked, refused, or apply-failed run leaves the snapshot untouched rather than recording a schema the database is not in. The now-obsolete --from-db did not advance the committed snapshot warning is gone.

The snapshot advances exactly when the run wrote a migration — the rule the offline path already follows (it returns on no changes before writing). A live run that emits nothing leaves it alone: recording the target schema as already-applied with no CREATE TABLE anywhere would be the greenfield-baseline trap by another door, leaving the offline path reporting no changes forever and apply-pending provisioning an empty database. The snapshot also now carries the

... (truncated)

Commits

• eb18349 chore(release): 0.20.11 coordinated (npm/PyPI/NuGet 0.20.11 · Maven 7.20.11)
• 83eae12 chore(release): npm 0.20.10 · PyPI 0.19.9 · NuGet 0.19.7 · Maven 7.11.7
• See full diff in compare view

Updates @metaobjectsdev/runtime-ts from 0.20.9 to 0.20.11

Release notes

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

v0.20.11 — shared-enum cross-package + migrate PK-refuse (coordinated)

Coordinated PATCH — npm `0.20.11` · PyPI `0.20.11` · NuGet `0.20.11` · Maven Central `7.20.11`.

This cut also re-baselines the version numbers: the three semver-`0.x` registries (npm/PyPI/NuGet) now share one number (`0.20.11`), and Maven aligns its `minor.patch` to match (`7.20.11`, keeping its historical major `7`), so "the 20.11 release" maps across every registry. Going forward, coordinated releases keep the shared minor in lockstep; npm may run a patch ahead between cuts.

Shipped

• #246 — a `field.enum` may now be shared across packages (Kotlin table generator emits the cross-package shared-enum import), and a conflicting redeclaration is rejected instead of silently dropped: new cross-port loader error `ERR_ENUM_EXTENDS_VALUES_CONFLICT` (a `field.enum` that both `extends` a shared package-level abstract enum and declares its own `@values`). Loader change in all five ports; Kotlin codegen on Maven.
• #259 (sibling of #246, Kotlin codegen) — a `field.enum` inheriting `@values` through two `extends` hops (projection → entity → shared abstract) now materializes its own per-projection enum instead of generating nothing.
• #258 (npm-only, `migrate-ts` + `cli`) — `meta migrate` now refuses a primary-key move with a clear error (detect-and-refuse) instead of silently emitting an un-appliable migration that drops the PK and breaks referencing foreign keys.

No metadata vocabulary changes; byte-identical output for any model that doesn't hit the specific cross-package/two-hop enum shapes (and, for #258, any migration that isn't a primary-key move).

See CHANGELOG.md for full detail.

Changelog

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

Fixed — server/python/uv.lock still pinned metaobjects at 0.20.11

The 0.20.14 cut bumped pyproject.toml without regenerating the lock.

[0.20.14] — npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven 7.20.14

Scope: npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven Central 7.20.14 — coordinated at the shared patch number per the single-shared-patch policy ([0.20.13]). Every changed product file is npm-only: the migrate fix lives in @metaobjectsdev/cli, and the corrected agent-context ships via @metaobjectsdev/sdk — the only package on any registry that bundles the repo-root agent-context/ tree (the Python wheel vendors none, its build hook is a no-op; the C# dotnet meta agent-docs and the Maven AgentDocsMojo are redirect stubs to the Node CLI). PyPI, NuGet and Maven Central are version-parity bumps with no changed product file.

Fixed — the live-DB meta migrate path now advances the committed snapshot

The day-1 command meta init prints as its next step —

meta migrate --from-db --db file:dev.sqlite --dialect sqlite --slug init --apply

— created the schema but never wrote the committed reference snapshot. The very next day-2 command in the documented everyday flow (meta migrate --dialect sqlite --slug <name>, the offline incremental path) then failed with no schema snapshot on a project whose database was provably correct, and pointed the user back at the day-1 command. Recovery via meta migrate baseline --from-db worked, but the happy path should not need a recovery step.

The --apply-without---from-db variant — also documented, as "…and apply it" — had it worse: no warning at all, and because the snapshot stayed behind, the next offline diff re-emitted the already-applied change, producing a migration that fails at apply.

Root cause: the live-introspection path writes the same migration files the offline path does, but skipped the same bookkeeping. It now writes the metadata-expected schema as the snapshot — byte-identical to the nextSnapshot the offline path persists, so the two paths converge on one representation and a follow-up offline diff sees no phantom churn. Guarded on a clean run: --dry-run writes nothing, and a blocked, refused, or apply-failed run leaves the snapshot untouched rather than recording a schema the database is not in. The now-obsolete --from-db did not advance the committed snapshot warning is gone.

The snapshot advances exactly when the run wrote a migration — the rule the offline path already follows (it returns on no changes before writing). A live run that emits nothing leaves it alone: recording the target schema as already-applied with no CREATE TABLE anywhere would be the greenfield-baseline trap by another door, leaving the offline path reporting no changes forever and apply-pending provisioning an empty database. The snapshot also now carries the

... (truncated)

Commits

• eb18349 chore(release): 0.20.11 coordinated (npm/PyPI/NuGet 0.20.11 · Maven 7.20.11)
• 83eae12 chore(release): npm 0.20.10 · PyPI 0.19.9 · NuGet 0.19.7 · Maven 7.11.7
• d9822bd fix(codegen): extend ADR-0044 collision-naming to extract/output-parser tier ...
• See full diff in compare view

Updates @metaobjectsdev/sdk from 0.20.9 to 0.20.11

Release notes

Sourced from @​metaobjectsdev/sdk's releases.

v0.20.11 — shared-enum cross-package + migrate PK-refuse (coordinated)

Coordinated PATCH — npm `0.20.11` · PyPI `0.20.11` · NuGet `0.20.11` · Maven Central `7.20.11`.

This cut also re-baselines the version numbers: the three semver-`0.x` registries (npm/PyPI/NuGet) now share one number (`0.20.11`), and Maven aligns its `minor.patch` to match (`7.20.11`, keeping its historical major `7`), so "the 20.11 release" maps across every registry. Going forward, coordinated releases keep the shared minor in lockstep; npm may run a patch ahead between cuts.

Shipped

• #246 — a `field.enum` may now be shared across packages (Kotlin table generator emits the cross-package shared-enum import), and a conflicting redeclaration is rejected instead of silently dropped: new cross-port loader error `ERR_ENUM_EXTENDS_VALUES_CONFLICT` (a `field.enum` that both `extends` a shared package-level abstract enum and declares its own `@values`). Loader change in all five ports; Kotlin codegen on Maven.
• #259 (sibling of #246, Kotlin codegen) — a `field.enum` inheriting `@values` through two `extends` hops (projection → entity → shared abstract) now materializes its own per-projection enum instead of generating nothing.
• #258 (npm-only, `migrate-ts` + `cli`) — `meta migrate` now refuses a primary-key move with a clear error (detect-and-refuse) instead of silently emitting an un-appliable migration that drops the PK and breaks referencing foreign keys.

No metadata vocabulary changes; byte-identical output for any model that doesn't hit the specific cross-package/two-hop enum shapes (and, for #258, any migration that isn't a primary-key move).

See CHANGELOG.md for full detail.

Changelog

Sourced from @​metaobjectsdev/sdk's changelog.

Fixed — server/python/uv.lock still pinned metaobjects at 0.20.11

The 0.20.14 cut bumped pyproject.toml without regenerating the lock.

[0.20.14] — npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven 7.20.14

Scope: npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven Central 7.20.14 — coordinated at the shared patch number per the single-shared-patch policy ([0.20.13]). Every changed product file is npm-only: the migrate fix lives in @metaobjectsdev/cli, and the corrected agent-context ships via @metaobjectsdev/sdk — the only package on any registry that bundles the repo-root agent-context/ tree (the Python wheel vendors none, its build hook is a no-op; the C# dotnet meta agent-docs and the Maven AgentDocsMojo are redirect stubs to the Node CLI). PyPI, NuGet and Maven Central are version-parity bumps with no changed product file.

Fixed — the live-DB meta migrate path now advances the committed snapshot

The day-1 command meta init prints as its next step —

meta migrate --from-db --db file:dev.sqlite --dialect sqlite --slug init --apply

— created the schema but never wrote the committed reference snapshot. The very next day-2 command in the documented everyday flow (meta migrate --dialect sqlite --slug <name>, the offline incremental path) then failed with no schema snapshot on a project whose database was provably correct, and pointed the user back at the day-1 command. Recovery via meta migrate baseline --from-db worked, but the happy path should not need a recovery step.

The --apply-without---from-db variant — also documented, as "…and apply it" — had it worse: no warning at all, and because the snapshot stayed behind, the next offline diff re-emitted the already-applied change, producing a migration that fails at apply.

Root cause: the live-introspection path writes the same migration files the offline path does, but skipped the same bookkeeping. It now writes the metadata-expected schema as the snapshot — byte-identical to the nextSnapshot the offline path persists, so the two paths converge on one representation and a follow-up offline diff sees no phantom churn. Guarded on a clean run: --dry-run writes nothing, and a blocked, refused, or apply-failed run leaves the snapshot untouched rather than recording a schema the database is not in. The now-obsolete --from-db did not advance the committed snapshot warning is gone.

The snapshot advances exactly when the run wrote a migration — the rule the offline path already follows (it returns on no changes before writing). A live run that emits nothing leaves it alone: recording the target schema as already-applied with no CREATE TABLE anywhere would be the greenfield-baseline trap by another door, leaving the offline path reporting no changes forever and apply-pending provisioning an empty database. The snapshot also now carries the

... (truncated)

Commits

• eb18349 chore(release): 0.20.11 coordinated (npm/PyPI/NuGet 0.20.11 · Maven 7.20.11)
• 83eae12 chore(release): npm 0.20.10 · PyPI 0.19.9 · NuGet 0.19.7 · Maven 7.11.7
• See full diff in compare view

Updates @metaobjectsdev/metadata from 0.20.9 to 0.20.11

Release notes

Sourced from @​metaobjectsdev/metadata's releases.

v0.20.11 — shared-enum cross-package + migrate PK-refuse (coordinated)

Coordinated PATCH — npm `0.20.11` · PyPI `0.20.11` · NuGet `0.20.11` · Maven Central `7.20.11`.

This cut also re-baselines the version numbers: the three semver-`0.x` registries (npm/PyPI/NuGet) now share one number (`0.20.11`), and Maven aligns its `minor.patch` to match (`7.20.11`, keeping its historical major `7`), so "the 20.11 release" maps across every registry. Going forward, coordinated releases keep the shared minor in lockstep; npm may run a patch ahead between cuts.

Shipped

• #246 — a `field.enum` may now be shared across packages (Kotlin table generator emits the cross-package shared-enum import), and a conflicting redeclaration is rejected instead of silently dropped: new cross-port loader error `ERR_ENUM_EXTENDS_VALUES_CONFLICT` (a `field.enum` that both `extends` a shared package-level abstract enum and declares its own `@values`). Loader change in all five ports; Kotlin codegen on Maven.
• #259 (sibling of #246, Kotlin codegen) — a `field.enum` inheriting `@values` through two `extends` hops (projection → entity → shared abstract) now materializes its own per-projection enum instead of generating nothing.
• #258 (npm-only, `migrate-ts` + `cli`) — `meta migrate` now refuses a primary-key move with a clear error (detect-and-refuse) instead of silently emitting an un-appliable migration that drops the PK and breaks referencing foreign keys.

No metadata vocabulary changes; byte-identical output for any model that doesn't hit the specific cross-package/two-hop enum shapes (and, for #258, any migration that isn't a primary-key move).

See CHANGELOG.md for full detail.

Changelog

Sourced from @​metaobjectsdev/metadata's changelog.

Fixed — server/python/uv.lock still pinned metaobjects at 0.20.11

The 0.20.14 cut bumped pyproject.toml without regenerating the lock.

[0.20.14] — npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven 7.20.14

Scope: npm 0.20.14 · PyPI 0.20.14 · NuGet 0.20.14 · Maven Central 7.20.14 — coordinated at the shared patch number per the single-shared-patch policy ([0.20.13]). Every changed product file is npm-only: the migrate fix lives in @metaobjectsdev/cli, and the corrected agent-context ships via @metaobjectsdev/sdk — the only package on any registry that bundles the repo-root agent-context/ tree (the Python wheel vendors none, its build hook is a no-op; the C# dotnet meta agent-docs and the Maven AgentDocsMojo are redirect stubs to the Node CLI). PyPI, NuGet and Maven Central are version-parity bumps with no changed product file.

Fixed — the live-DB meta migrate path now advances the committed snapshot

The day-1 command meta init prints as its next step —

meta migrate --from-db --db file:dev.sqlite --dialect sqlite --slug init --apply

— created the schema but never wrote the committed reference snapshot. The very next day-2 command in the documented everyday flow (meta migrate --dialect sqlite --slug <name>, the offline incremental path) then failed with no schema snapshot on a project whose database was provably correct, and pointed the user back at the day-1 command. Recovery via meta migrate baseline --from-db worked, but the happy path should not need a recovery step.

The --apply-without---from-db variant — also documented, as "…and apply it" — had it worse: no warning at all, and because the snapshot stayed behind, the next offline diff re-emitted the already-applied change, producing a migration that fails at apply.

Root cause: the live-introspection path writes the same migration files the offline path does, but skipped the same bookkeeping. It now writes the metadata-expected schema as the snapshot — byte-identical to the nextSnapshot the offline path persists, so the two paths converge on one representation and a follow-up offline diff sees no phantom churn. Guarded on a clean run: --dry-run writes nothing, and a blocked, refused, or apply-failed run leaves the snapshot untouched rather than recording a schema the database is not in. The now-obsolete --from-db did not advance the committed snapshot warning is gone.

The snapshot advances exactly when the run wrote a migration — the rule the offline path already follows (it returns on no changes before writing). A live run that emits nothing leaves it alone: recording the target schema as already-applied with no CREATE TABLE anywhere would be the greenfield-baseline trap by another door, leaving the offline path reporting no changes forever and apply-pending provisioning an empty database. The snapshot also now carries the

... (truncated)

Commits

• eb18349 chore(release): 0.20.11 coordinated (npm/PyPI/NuGet 0.20.11 · Maven 7.20.11)
• 0895da1 Merge remote-tracking branch 'origin/main' into fix/246-shared-enum-cross-pac...
• 83eae12 chore(release): npm 0.20.10 · PyPI 0.19.9 · NuGet 0.19.7 · Maven 7.11.7
• 5213418 test(#246): pin non-root-super LEGAL case for enum extends/values conflict
• bb30424 feat(#246): TS loader rejects extends-shared-enum with own values
• b58f919 feat(#246): register ERR_ENUM_EXTENDS_VALUES_CONFLICT in the cross-port error...
• 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 ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions