Canonical Project Setup & Workspace Scaffolding

🤖

Transitioning from a high-level Dev-Planner manifest (planner.manifest.json) into a production-ready Aircada project workspace follows a standardized, automated scaffolding pipeline.

1. Canonical Workspace Directory Anatomy

Every Aircada project adheres to a strict directory layout: air.config.json (workspace ID and dev ports), datasets/ (.airpds tabular matrices), option-models/ (stripped .airpm pricing models), src/systems/ (<Name>Manager.ts singleton orchestrators), src/operators/ (<Feature>Operator.ts 3D mutators), src/components/ (React TSX customizer overlays and test panels), src/schemas/ (<Name>Schemas.ts constants and types), blueprints/ (public .airbp exports), and scripts/testing/ (Node CLI test harness).

2. Local SDK Symlinking Workflow

Because local development depends on active SDK development, all workspaces must execute 'npm run link-air' to symlink local @aircada/spec and @aircada/react packages directly. Never rely on un-linked dev registry packages.

3. Dual-Pass Compilation

Executing 'air build' triggers dual-pass compilation: Pass 1 validates TypeScript interfaces and compiles TSX UI components; Pass 2 analyzes operator decorators and registers node-graph bindings for Aircada Studio.

4. Autonomous Dev Testing & Telemetry Auditing

Agents and developers execute '/agent-dev-testing' to launch background dev servers (npm run dev -- --no-open --mode ui -k), traverse user steps in browsersubagent, and query runtime telemetry via aircada-mcp tools (querydevlogs, listdeverrorreports, getdeverrorreport). Any discovered SDK bugs or documentation gaps are immediately dispatched via submitrecommendation.