> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atonom.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Sync & release

> Review changes, resolve conflicts, and save tools to Atonom.

The CLI links files to remote **tool IDs** through `.atonom/scripts/.manifest.json`. Each entry records a relative path and the last synced remote SHA-256 hash. This is sync metadata, not a backup of previous script versions.

## Pull intentionally

```sh theme={null}
atonom list --json
atonom pull 42 --json
```

Use a specific ID when working on one tool. With no IDs, `pull` visits every visible Lua script tool.

Pull results include `created`, `updated`, `unchanged`, `overwritten`, `skipped-local-edits`, and `skipped-no-script`. A normal pull preserves a locally modified file. It still exits zero when files were skipped; read each result's `action`.

`pull --force` overwrites local edits. It does not merge them.

## Review and push

```sh theme={null}
atonom diff 42 --json
atonom push 42 --json
```

Diff compares the current remote body to the local file. JSON output includes the unified diff and `remote_changed_since_pull`. A changed linked file is pushed with an `expected_sha256` so the server can reject a stale update with HTTP 409.

`push` skips upload when the file matches the last synced hash. That no-op does not fetch the remote or prove it is still unchanged; use `diff` when you need a fresh comparison.

For a new local file, `--tool-id` identifies its remote target. Pulling the target first is preferable because it establishes a conflict-checking baseline. Files outside the configured scripts directory may be used with an explicit ID, but the CLI cannot remember their link in that workspace's manifest.

## Resolve a conflict without losing work

1. Preserve your local file in version control or a backup outside the scripts directory.
2. Run `atonom diff 42 --json` and inspect the remote changes.
3. Once your edits are backed up, use `atonom pull 42 --force` to refresh the file and its baseline.
4. Reapply the intended edits to that refreshed file, merging the remote changes.
5. Test again, review the new diff, and push normally.

`push --force` omits the expected hash; use it only for an intentional replacement of remote content. Do not use `run` as a shortcut around a rejected push: a default run saves without that hash check.

`get --out` also writes directly to its destination. It does not offer pull's dirty-file protection. If you use it to inspect a remote copy, choose a separate scratch path.

## Verify and enable

```sh theme={null}
atonom push 42 --json
atonom run 42 --no-save --inputs '{"qty":2,"unit_price":12.5}' --json
```

Run tests against the stored body after a successful push. A failed run does not roll back saved content. To restore a prior version, restore that version's source locally, review the diff, and push it through the same process.

The CLI does not configure schemas, tool descriptions, or enabled status. Review those in the Atonom UI and enable a newly created tool when ready. Test the owning platform agent as well as the direct CLI invocation.

## Keep environments separate

Use separate workspace roots for development, staging, and production. The manifest records a base URL, but the CLI does not enforce it as an environment guard. Verify `atonom config show` and `atonom status` before writing to a different host.

Promote source files and fixtures; re-discover and explicitly link the target environment's tool IDs. Do not copy a manifest and assume the IDs are portable. Avoid sharing a mutable scripts directory between concurrent editing agents.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.