Resource commands

vortexify create api normalize
vortexify create connector shop
vortexify create sync shop/orders
vortexify registry --type api --name normalize
vortexify status --type api --resource normalize
vortexify commit --type api --resource normalize
vortexify pull --type app --resource dashboard --include-dependencies

create registers a resource and retrieves its committed starter into a missing local directory. Existing local implementations are preserved. If registration succeeds but downloading or verifying the starter fails, use vortexify create TYPE NAME --resume to retrieve the registered source. Resume requires an existing registration and a missing local folder; it does not register another resource or overwrite an existing implementation. registry lists server metadata. status shows drift and dependency impact. commit saves source; pull retrieves it.

Syncs belong beneath connectors. Use connector/sync, a sync ID, or an unambiguous short name. Connector synchronization excludes nested sync source.

pull --include-dependencies recursively selects upstream resources; --include-dependents selects downstream resources. Both require --resource. They select related source without deploying or executing it.

Discover drift and select sourceCopy Anchor Link

registry --json lists server resources and includes runtime environment details for selected APIs/transforms. status --json compares local registration, source changes, upstream requirements, downstream impact, and preview freshness. Status does not execute or publish the affected resources.

Create supports API, transform, app, connector, sync, agent, and database resource types. For syncs, create sync shop/orders and create sync orders --connector shop select the owning connector. Keep connector and nested sync source commits separate.

Commit accepts --type and --resource. Pull also accepts --include-dependencies or --include-dependents with a resource selection. recover repairs an interrupted local pull from its recorded workspace state without network access.

Blueprints and design referencesCopy Anchor Link

The platform calls these examples blueprints; the CLI command group is designs:

vortexify designs catalog
vortexify designs search "inventory planning" --limit 5
vortexify designs metadata BLUEPRINT_ID --yaml
vortexify designs read BLUEPRINT_ID README.md
vortexify designs code BLUEPRINT_ID --output ./reference-design.html
vortexify designs preview BLUEPRINT_ID
vortexify designs attach BLUEPRINT_ID
vortexify designs list
vortexify designs detach BLUEPRINT_ID

Catalog and search support --industry, --solution-type, and --use-case; search accepts limits from 1 to 20. Both can print YAML with --yaml. Metadata lists available files. Read/code accept an optional relative file path; code writes decoded source by default, and --output writes a selected file locally. Preview downloads the template files into a temporary directory and prints its HTML entrypoint path.

Attach/detach saves a project design reference, helping a coding agent find the intended design. It does not create a working app or wire its backend. designs alone, or designs list, lists attached designs. These CLI operations run from a project workspace; the platform also provides organization-scoped blueprint browsing.

Source documentation and agent attachmentsCopy Anchor Link

Upload PDF, TXT, Markdown (.md or .markdown) documents to an existing connector or custom agent. Explicit selectors and JSON output are useful for coding agents:

vortexify upload file ./api-reference.md --resource-type connector --resource shop --wait --json
vortexify files connector shop --json
vortexify files preview FILE_ID --chars 4000 --json

files lists attachment IDs and bounded beginning-text previews; it is not a full-document search command. A coding agent can use these previews and search the original local documentation when it needs more detail. Wait for successful ingestion before relying on an attachment. files --chars N allows 1–4,000 characters per file, with a combined 10,000-character preview cap. files --version N reads the owner's committed attachment set; without it, working attachments are used. files preview FILE_ID --chars N reads one bounded document preview.

Custom agents built for an app can search documents attached to their own saved version. Attach documents to the agent when it needs them, then commit the agent after ingestion:

vortexify upload file ./support-guide.md --resource-type agent --resource support_assistant --wait --json
vortexify files agent support_assistant --json
vortexify commit --type agent --resource support_assistant

Create and implement support_assistant first. Uploaded documents are managed attachments; they are not Python SDK context declarations. Uploading a file to a connector does not automatically attach it to a custom agent. Saving an agent version and deploying it are separate operations.

See Custom API for an API implementation starting point and the document workflow.

Versions and dependenciesCopy Anchor Link

Local source, saved platform versions, and deployed versions are separate. Manual CLI runs and tests execute committed source in preview workflows. New commits can make preview data stale while production remains on its deployed version. Last successful preview data stays readable until rebuilt.

The local graph comes from source references. Register and commit upstream resources before their consumers. Commit validation checks producer source, not materialized output: sync/database/transform consumers can commit while upstream execution or migration is pending, running, or failed. Runtime execution still needs the required published output or schema. Table("_upload.customers") instead requires the uploaded table to exist. _upload is reserved against connector creation and renaming. The platform Overview and flow show these parsed upstream/downstream links; they describe declared dependencies rather than automatically running them. Status reports downstream impact without modifying those resources. vortexify recover resumes an interrupted pull.