CLI Project Anatomy & Config

Workspace Structure

Initializing a project with the CLI generates a highly standardized workspace structure organizing assets, logic, and configurations:

├── .aircada/               # Local cache & CLI metadata
├── dist/                   # Production distribution bundle (output)
│   └── application.js
├── src/                    # Source code root
│   └── index.ts            # Entry point for your application or plugin
├── datasets/               # Local CSV datasets directory
│   └── example-data.csv
├── package.json            # Node dependencies and project versioning
├── tsconfig.json           # TypeScript configuration rules
└── air.config.json         # Core Aircada project orchestration config

The air.config.json Specification

Every project contains a JSON orchestration config at the root defining registry links and execution types:

{
  "appId": "app_2f8k9sh3...",
  "projectId": "proj_9k3n8d1...",
  "name": "My Custom Operator",
  "appType": "PROJECT",
  "environment": "production"
}

Configuration Fields Reference

- appId [String]: Unique identifier generated during air setup (cloud registration) to represent this specific plugin/application in the global directory.

- projectId [String]: Parent Aircada Studio project context reference. Used to tie development actions to a target workspace.

- name [String]: Display name of the application or plugin.

- appType *[Enum: PROJECT | PLUGIN]*:

- PROJECT: Standard app bound to a concrete, parent Aircada Studio project.

- PLUGIN: Reusable operator/connector built to be published, distributed, and shared globally.

- environment [String]: Target platform tier (e.g., production, staging, or local for local development servers).