What each release since 1.0.0 changed, newest first. Every entry is a summary of the README's Upgrading, which says, release by release, what a workspace sees; 1.3.1, a documentation-only patch with no section there, is summarised from its GitHub Release.
1.9.0: A newer Forge tag in status
status --json gains forge.newerTag, always present and last in forge: the remote Forge's highest vX.Y.Z tag above a workspace ref that is itself a vX.Y.Z tag, else null. The status tool of craftar mcp and craftar ui's workspace answer carry it too.
The text of status gains one line when there is such a tag. No byte sync writes, no lock, no exit code and no network call changes: the tags come from the fetch status already makes, or from the cached copy.
1.8.0: Quieter AGENTS.md, a local recipe repointed by promote
The agents-md "no AGENTS.md equivalent — skipped" warning is no longer printed for an ingredient another target of the workspace writes; it still names every ingredient no other target writes. doctor --strict can now exit 0 where that warning was its only warn.
craftar drift promote: a new variant whose base a recipe in the profile's own folder cites no longer refuses: when the profile resolves that recipe, it is repointed to the variant behind the same git gate and proof.
opencode: a remote MCP server whose headers is not an object is dropped with a warning naming the server. craftar setup: a new Forge's README advises keeping the Forge out of a workspace's git repository.
A new command, craftar setup: creates a Forge from scratch (or by importing a workspace's .claude/), makes it a git repository with one initial commit, and starts workspaces on it. It is the one craftar command that commits, only in the directory it creates or finds empty, and it never pushes. See Setup.
craftar with no arguments, in a terminal, on a machine with no registered workspace, ends its help with new here? run craftar setup; the interactive craftar init suggests it when a Forge answer names no Forge.
No other command changes; no byte changes for a workspace already in sync.
A new target, opencode (OpenCode 2 or later): agents to .opencode/agents/<name>.md with permissions derived from their tools, commands to .opencode/commands/<name>.md, MCP servers to .opencode/opencode.json; rules reach OpenCode through agents-md.
A Forge file that names opencode needs schema: 18; craftar.lock is written at schema 7 when it names it.
A workspace that does not name opencode sees no change.
cursor, copilot, agent-skills, codex and antigravity were checked by opening each tool from its CLI on a synthetic workspace; the README says what was validated, per target.
Generated bytes:copilot also writes .github/mcp.json for the Copilot CLI; claude-code leaves out an empty tools line in an agent.
One target is removed: the declared exception in the compatibility promise: its CLI no longer accepts Google login for individuals. Its name is refused in targets.
In a workspace that used it, the files the lock recorded for it are orphans: sync removes them, and keeps a hand-edited one as orphan-drift. antigravity covers the same use.
Nothing changes in what craftar writes. From here on, breaking a command, a flag, an exit code, a --json shape, the loading of a Forge schema or the reading of the lock needs a major version, and a change to generated bytes comes in a minor.