Stability

Kide is in beta. What a project builds on is listed below and changes only as described under How changes are communicated. The package’s internals may change in any release.

What is stable

Any change to these counts as breaking, even if the project still compiles.

• cms.config.ts — the shape of the config object: collections, admin, locales, integrations, images, collaboration.
• defineCollection() and fields.* — every field type, its type-specific options, and the base options (label, description, required, defaultValue, unique, translatable, condition, admin, access).
• The local API — cms.<collection>.find(), findOne(), create(), update(), delete(), deleteMany(), upsertTranslation(), and the context flags (_system, _skipSearch). deleteMany() and _skipSearch are not in the generated types yet; adding them there is not a breaking change.
• Project-owned files — the signatures of the db, email and storage adapters, the wiring in runtime.ts, and the fields/ convention for custom admin components.
• Stored data shapes — rich text and content as JSON ASTs, image fields as storagePath strings, the _-prefixed system fields.
• The kide CLI — subcommand names and their arguments (generate, push, seed, admin, reindex, describe, upgrade, restore, eject, mcp).

What may change

The managed directories (core/, admin/, routes/, middleware/, client/, platform/, internals/) belong to the package:

• Internal module layout and function signatures inside the managed directories.
• The names and contents of virtual:kide/* modules (they are the package’s private contract with its own routes).
• Admin UI components, styles and markup.
• The generated files under .generated/ (regenerated on every kide generate).
• The layout of the upgrade packet and the wording of agent-instructions.md.

If you have edited managed code in an embedded project, expect conflicts on upgrade; the upgrade packet lists them for you or an agent to resolve.

How changes are communicated

• Every release is a git tag v<version> on the template repo, with an entry in CHANGELOG.md.
• While the version is 0.x, a breaking change to anything in the stable list lands in a minor release (0.N.0) and is marked Breaking in the changelog, with what to do about it. Patch releases (0.N.x) never contain one.
• Schema changes are called out separately, because a dependency bump cannot apply them: run pnpm cms:push (see Updates & Versioning).
• Security fixes are released as soon as they are ready and noted in the changelog; see SECURITY.md for how to report one.

Road to 1.0

Kide becomes 1.0 when the 1.0 milestone is closed. The criteria there are about verification, not features: the upgrade path from the previous release checked in CI, documentation covering everything a project can configure, and a security review of the parts reachable without a session. After 1.0, breaking changes to the stable list require a major version.