Ridu v0.9.0

Ridu 0.9.0

This release preserves content when fields are renamed during development, adds migration
baselining for development databases, and supports cascading hard deletes for owned documents.
It also makes generated admins independent of the application's generated SDK output path.

Changes

• Relationship and upload fields can use field.ReferenceDeleteCascade for a singular,
  unlocalized reference outside arrays and blocks. Hard-deleting its target deletes the owning
  documents through the operation engine in the same transaction. Delete hooks, each owner's
  reference policies, cycle handling, and rollback apply across all three official adapters.
• ridu migrate baseline records the committed migration prefix already represented by a
  development database, without executing migration steps. PostgreSQL, SQLite, and MongoDB reject
  schema mismatches and stop before content rewrites, transforms, and reference-index rebuilds.
• ridu dev detects possible field renames before generation and schema synchronization. An
  interactive terminal asks whether to preserve the data, records a reviewable migration, stops
  writers, and applies an accepted rename. Noninteractive reloads pause until the rename is
  resolved. SQLite now executes field renames transactionally, including retained versions and
  nested field descendants; PostgreSQL and MongoDB also preserve renamed descendants.
• Generated admin entries use the public createAdminClient export from @riducms/admin.
  Configuring a sibling or alternate generated-client path no longer breaks the admin import.
• Agent-document synchronization remembers completely deleted bundled skills as exclusions.
  Partial deletions restore missing framework-owned files, and edited files remain protected.
• The documentation-build dependency fast-uri is updated to 3.1.8 for
  GHSA-hrr3-gc8f-f4qj.

Compatibility and upgrade

Update the Go module and all Ridu npm packages to 0.9.0 together, then regenerate application
contracts with that CLI. The manifest and protocol format counters, plugin API counters, REST/SDK
operation shapes, and published migration artifact encoding remain unchanged. Generated reference
metadata now admits the additional cascade delete action. Custom store adapters need the
store.CascadeTransaction contract to support that policy.

Cascade is opt-in and applies to permanent deletion; configure it deliberately for owned data.
Existing nullify and restrict policies keep their behavior. Regenerate and review the migration
plan after changing reference policy or schema configuration.

An existing development database whose schema matches committed migrations can be adopted with
ridu migrate baseline. After baselining SQLite, further schema evolution uses migration artifacts
through ridu migrate create and ridu migrate up. Production databases continue to apply their
committed history normally and do not need baselining.

Field renames must be confirmed before values move. Review the generated artifact and rehearse
its plan against a backup. PostgreSQL and MongoDB collection renames remain supported; SQLite
supports field renames only. Renames combined with incompatible structural changes are rejected.
If applying a rename fails, preserve its artifact and follow the reported recovery steps.

For existing generated admins, the entry can import createAdminClient and mountAdmin from
@riducms/admin and pass clientFactory: createAdminClient. The application SDK remains generated
at the path selected in ridu.toml.