v0.3.0

Daem 0.3.0 adds explicit user-state migration and commit-pin changes for managed Pi Git packages. It also improves recovery guidance and fixes a Git cancellation race.

Changes

• One state location for the default user manifest. Selecting it through --manifest, the current directory or fallback now uses the same XDG state and cache roots. daem migrate state transfers existing manifest-local management without changing installed outputs. Other project manifests keep their local storage. #113
• Change managed Pi Git pins through ordinary apply. Change the full commit in source.host_source, run daem lock, review daem apply --dry-run, then authorize apply. Keep the extension ID, repository locator, target and scope unchanged. Daem records the intended transition before invoking Pi and requires both command success and fresh settings verification to complete it. #115
• More useful refusal and recovery messages. Drift, unmanaged content and pending pin changes now include relevant next steps. A missing recovery journal no longer hides an independently detected file-set fence, and verbose status no longer recommends repeating itself. #116
• Preserve Git cancellation when a stdout consumer finishes early. The fix retains completed-command and independent consumer-error precedence. #117

Upgrading

If the default user manifest has management under its former adjacent .daem directory, select that manifest and preview the transfer:

daem migrate state --dry-run
daem migrate state --yes

Pass --manifest <path> if the current directory would select another manifest. Review the preview before confirming. Resolve outstanding recovery first; recover --legacy-user-state --dry-run inspects the old apply-journal location. Interrupted state migration uses migrate state --recover, a separate recovery operation.

Migration does not move caches or rewrite installed files. Sources may need to be fetched again. Keep the relocation receipt; copying the old snapshot back is not a supported rollback. See state migration for recovery and refusal conditions.

Pi may reset or clean its checkout and run dependency scripts during a pin change. Failed or uncertain attempts retain the pending target. Retry that same target only after fresh inspection and authorization; recover cannot undo Pi's native changes. See managed Pi Git pins.

An executable rollback is not a state rollback. Earlier binaries can reject migration receipts, pending pin fields or completed-pin provenance. If that happens, reinstall the newer verified binary rather than deleting or hand-editing state.

JSON consumers must update for plan schema 13 (previously 12) and apply-result schema 20 (previously 19). These versions cover the new Pi change_pin action and pin_change disclosure, and apply even when an invocation has no pin change. The new migrate state envelope starts at version 1. Check each command's schema_version before interpreting its payload; see the CLI JSON contract. #118

Supported release targets remain macOS 26+ on Apple silicon and Linux x86-64. See installation and executable rollback.

Changes since v0.2.3

v0.2.3

Fix

Fix concurrent Git source-cache initialization on NFSv3 (#110, fixes #109). In v0.2.2, multiple Git sources in one lock command could race to create shared cache ancestors, fail with EEXIST, and leave residue that blocked the workspace.

Internal workers now coordinate publication by retained parent-directory identity and recheck the child before creating a stage. Workers reuse an existing directory without claiming cleanup ownership; unrelated parents remain independent. Actual uncertain NFS rename results still preserve their causes and candidate recovery artifacts.

Existing failed workspaces

This fix prevents new bootstrap collisions; it does not repair existing markerless .daem-tmp-* residue. If an earlier failure fenced your workspace, upgrading alone will not clear it. Preserve the residue and error output for manual analysis. Do not delete internal paths merely because their names look temporary. See NFS troubleshooting.

Support and upgrade limits

• NFSv3 support remains single-client, single-writer and trusted-path only. This change does not add cross-process or cross-node exclusion, hostile-interference protection, server-outage/reconnect/power-loss durability, or universal automatic recovery.
• Legacy mount-ID recovery requires the same boot and no unmount/remount. Complete pending recovery before reboot, remount or a kernel transition; incompatible identity schemes are refused rather than converted.
• Metadata preservation covers supported metadata exposed through the client, not invisible server-only metadata. Metadata-based revalidation detects observable drift, not every competing write or inode-reuse cycle; this also applies to local filesystems. Keep inputs and namespaces stable during a command.
• When upgrading from v0.1.0, follow the upgrade procedure before replacing the executable. Populated old state and ownership records are not migrated automatically, and old recovery journals are refused. Keep the old binary and back up your manifest and lockfile; do not edit or delete state to bypass refusal. JSON consumers should check the CLI reference.
• Installer rollback restores only the executable, not manifests, lockfiles, managed state or host changes.

The platform contract defines the support boundary. Linux 5.15/NFSv3 reproduction and regression results are reported in #110; hosted release CI does not provision NFS.

Verification

The release workflow verified both native artifacts, reproducible builds and archives, fresh installation, development-binary upgrade, offline executable rollback, and refusal of corrupt checksums and wrong binary identities. These installer checks do not establish migration of populated old state.

Install

Available for macOS 26 or newer on Apple silicon and Linux x86-64. Download the matching archive and SHA-256 sidecar below or use the installation guide.

Full changelog

v0.2.2

Changes

• Support ordinary unprivileged, single-client NFSv3 use on Linux amd64, including kernel 5.15. Artifact identity can use opaque file handles when birth time is unavailable; older kernels can use boot-bound legacy mount IDs for recovery. Fixes #107.
• Preserve candidate recovery artifacts when an NFS rename reports an uncertain result. Fix cleanup of restrictive-mode files and directories on older Linux kernels.
• Expand doctor from permission checks to disposable storage and artifact-access probes. Its check list and diagnostic details change; existing files and managed state are not probe payloads.
• Parallelize read-only visibility-domain observations during apply for large lease sets, using at most four workers. This targets latency rather than reducing validation work and can increase CPU usage. This change does not parallelize effect execution.

Support and recovery limits

These limits are part of the support contract, not promises of future capabilities:

• NFSv3 use requires one client and one writer at a time against a manifest or destination, on trusted user-controlled paths. Multi-node exclusion and hostile-interference protection are not promised.
• Legacy mount-ID recovery requires the same boot and no unmount/remount of the affected filesystems. Finish pending recovery before reboot, remount or a kernel transition. Existing unique-ID journal tokens retain their meaning; recovery refuses cross-scheme tokens rather than converting them.
• Server-outage, reconnect and power-loss durability are outside the NFS support envelope. A failed rename may already have taken effect; preserve retained stages, journals and backups if recovery refuses. Automatic recovery of every uncertain result is not guaranteed.
• Metadata preservation is limited to supported metadata exposed through the client; server-only invisible metadata is not inspected or reproduced.
• Metadata-based revalidation detects observable drift, not every competing write or inode-reuse cycle. This limitation also applies to local filesystems. Keep inputs and namespaces stable during a command.

See the platform contract and NFS troubleshooting.

Upgrade notes

If upgrading from v0.1.0, follow the upgrade procedure before replacing the executable. Populated old state and ownership records are not migrated automatically, and old recovery journals are refused. Keep your old binary and back up your manifest and lockfile. Do not edit or delete state files to bypass an upgrade error. JSON consumers should check the CLI reference.

Installer rollback restores the executable only, not your manifest, lockfile, managed state or host changes.

Verification

The release workflow verified both native artifacts, reproducible builds and archives, fresh installation, development-binary upgrade, offline executable rollback, and rejection of corrupt checksums and wrong binary identities.

Linux 5.15/NFSv3 test results are recorded in #108; the release workflow does not provision NFS. That PR also records an unexplained intermittent Git-probe failure observed before its final successful runs.

Install

Available for macOS 26 or newer on Apple silicon and Linux x86-64. Download the matching archive and SHA-256 sidecar below or follow the installation guide.

Full changelog

v0.2.1

Changes

• Support Git-backed instruction files in manifests and daem add instruction, with an explicit ref and repository-relative file path. GitHub shorthand is also supported.
• Preserve SCP-style Git addresses before GitHub shorthand expansion for instruction, skill and skill-group authoring, including usernames other than git and repositories without a .git suffix.

Local and S3 instruction manifest sources remain supported; S3 authoring remains manifest-only. No persisted-state migration is introduced.

Upgrade notes

If upgrading from v0.1.0, follow the upgrade procedure before replacing the executable. Populated old state and ownership records are not migrated automatically, and old recovery journals are refused. Keep your old binary and back up your manifest and lockfile. Do not edit or delete state files to bypass an upgrade error. JSON consumers should check the CLI reference for changes since v0.1.0.

Installer rollback restores the executable only, not your manifest, lockfile or managed state.

Install

Available for macOS 26 or newer on Apple silicon and Linux x86-64. Download the matching archive below or follow the installation guide.

Full changelog

daem v0.2.0

Before upgrading from v0.1.0

If you already use daem to manage an environment, follow the upgrade procedure before replacing the executable. Populated old state and ownership records are not migrated automatically, and old recovery journals are refused. Keep your old daem binary and back up your manifest and lockfile. Do not edit or delete state files to bypass an upgrade error.

Scripts that consume JSON output need to account for changed schema_version values and output fields. See the CLI reference.

What's new

• A standalone installer. Install an exact release, upgrade, or restore the previous executable with install.sh. It checks the download and binary identity before replacement. Rollback restores the executable only—not your manifest, lockfile, or managed state.
• MCP support for Pi. Manage project and global MCP configuration through an explicit pi-mcp-adapter provider.
• MCP environment references. Refer to environment variables without storing their values in the lockfile. Available mappings depend on the target host.
• Extension import and ordering. Import supported extensions from existing host configuration. Preview and apply Pi package precedence and OpenCode configuration-order changes.
• Clearer command feedback. Import shows progress and explains skipped resources. Repeating an already-satisfied add reports unchanged; common input errors include corrective guidance.

This release also fixes premature Git timeouts during slow local processing and includes Go runtime security fixes.

Install

Available for macOS 26 or newer on Apple silicon and Linux x86-64. Download the matching archive below or follow the installation guide.

daem v0.1.0

First public release of daem, a declarative agent environment manager.

Install

Use the checksum-verified procedure in Install, Upgrade, And Roll Back. Native release artifacts are provided for macOS 26 or newer on Apple silicon and Linux on x86-64.

Release identity

Both artifacts were built from commit 2bf957187f9f847aa87b0e807d6ca960589f1083 with Go 1.26.5 in native runners. The release workflow verified full tests, reproducible archive construction, embedded identity, fresh installation, source-build replacement, and executable rollback.

The v0.1.0 tag and attached assets are immutable. A bad release will be superseded by a new version; the existing tag and assets will not be replaced. Rollback restores only the executable and does not downgrade manifests, lockfiles, statefiles, or host mutations.

See Feature Support for the exact host and resource matrix.