Skip to main content
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

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

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

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.