SDK Workflow

Full SDK Reference

For the complete command reference with all options and examples, see the ZeyOS SDK Documentation.

The ZeyOS SDK (zeysdk) is a command-line tool for developing, testing, and deploying ZeyOS applications locally. It provides a structured workflow for managing application code, synchronizing with ZeyOS instances, and validating iXML snippets.

Command reference

Command	Purpose	Typical frequency
zeysdk create <app-id>	Create new app scaffold	Once per app
zeysdk link --token <t> --url <u> <instance>	Bind local app to target instance	Once per instance
zeysdk pull [-f]	Fetch server state into local app	Before major edits
zeysdk push	Upload local changes to server	After verified changes
zeysdk compare	Inspect local/remote differences	Before sync
zeysdk sync [-f]	Synchronize local and remote files	Frequently
zeysdk run --ixml '<snippet>'	Execute iXML snippet in runtime context	Constantly during writing
zeysdk watch	Watch and auto-sync on file changes	During active development
zeysdk rollout	Deploy to instances	For releases

First-time setup

Bash

mkdir -p myproject
cd myproject
zeysdk create myapp --name "My App"
cd myapp
zeysdk link --token <token> --url <url> <instanceId>
zeysdk pull -f

Use this once, then keep the app linked for all future development.

Daily development loop

Bash

zeysdk compare
zeysdk sync
zeysdk run --ixml '<output>ok</output>'

Recommended order:

1. compare first to understand drift between local and remote.
2. sync only after reviewing expected changes.
3. run often while editing to validate snippets.

Snippet validation

Use zeysdk run --ixml for fast feedback on any iXML code:

Bash

zeysdk run --ixml '<set var="name">iXML</set><output>Hello $name</output>'

The command returns runtime diagnostics including load time, execution time, memory usage, output size, and the output payload or any parser/runtime errors. If this fails, fix parser or language assumptions before modifying service files.

Conflict and safety guidelines

• pull -f can overwrite local files — use with caution.
• sync can create conflict situations if both local and remote changed.
• compare is mandatory before any destructive or broad sync decision.

Common mistakes

• Skipping compare and assuming only local changes exist.
• Testing only at the end of a large editing session.
• Ignoring runtime error details that already explain the fix.