# hoody-exec Subskill ## Overview hoody-exec turns any TypeScript or JavaScript file into a live, authenticated API endpoint. Write a script, deploy it to a container via the CLI, and it becomes immediately accessible over HTTP with automatic routing, structured logging, real-time monitoring, dependency management, and OpenAPI documentation generation. The execution environment is powered by Bun for fast cold starts and native TypeScript support. ### When to Use hoody-exec | Scenario | Why hoody-exec | |---|---| | Deploy a REST API endpoint from a `.ts`/`.js` file | Script becomes an endpoint instantly — no framework boilerplate | | Webhook handler for external services | Automatic JSON parsing, structured logging, error tracking | | Data transformation or ETL pipeline | Chain scripts together, share state between them | | Scheduled background tasks | Built-in cron-style scheduling with history tracking | | System monitoring endpoint | Return structured JSON from a script, scrape via Prometheus | | Generate OpenAPI docs from code | Auto-generate specs from script type annotations and magic comments | ### How It Fits Hoody Philosophy hoody-exec embodies the Hoody principle: **every script is a service**. There is no separate framework, build step, or deployment pipeline. You write code, push it to a container, and the platform handles routing, TLS, authentication, logging, and monitoring. Scripts are isolated per container but can coordinate via shared state and script chaining. The CLI (`hoody exec`) provides the full management surface — never call HTTP endpoints directly. ### Core Capabilities - **Script management** — write, read, list, move, delete, and browse scripts as a file tree - **Next.js-style routing** — static routes, dynamic `[param]` segments, catch-all `[...slug]`, optional catch-all `[[...path]]` - **Validation pipeline** — syntax, TypeScript, dependencies, return types, magic comments, and full script validation - **Template system** — scaffold from built-in or custom templates, preview before generating - **Logging** — structured log files with list, read, stream, search, and clear operations - **Monitoring** — active requests, per-script performance, system stats, Prometheus export - **Dependency management** — bundled dependencies, install external packages, pin versions - **Shared state** — key-value store scoped to hostnames for cross-script coordination - **Scheduling** — cron-like triggers with reload and execution history - **OpenAPI generation** — auto-generate, validate, merge, and serve OpenAPI specs from scripts - **Magic comments** — script-level metadata and configuration via in-code annotations - **SDK management** — import, list, retrieve, and delete external SDKs ### Architecture Notes - Scripts are stored in the container filesystem and served by the hoody-exec runtime - The container exposes a proxy URL: `https://{projectId}-{containerId}-exec-{serviceId}.{node}.containers.hoody.com` - All script management goes through the `hoody exec` CLI command group — never use raw HTTP calls - All container-targeting commands require `-c ` or the `HOODY_CONTAINER` environment variable - Use `-o json` for machine-readable output in automation pipelines --- ## Common Workflows ### Workflow 1: Script Lifecycle Management Create, inspect, organize, and remove scripts on a container. **Step 1 — Create a new script** ``` hoody exec scripts write \ --path "api/hello.ts" \ --content 'export default function(req: Request) { return { message: "Hello, world!" }; }' \ -c my-container ``` **Step 2 — Verify the script exists by reading it back** ``` hoody exec scripts read --path "api/hello.ts" -c my-container -o json ``` **Step 3 — List all scripts on the container** ``` hoody exec scripts list -c my-container -o json ``` **Step 4 — View the full directory tree** ``` hoody exec scripts tree -c my-container -o json ``` **Step 5 — Move a script to a new path** ``` hoody exec scripts move \ --from "api/hello.ts" \ --to "api/v2/hello.ts" \ -c my-container ``` **Step 6 — Delete a script** ``` hoody exec scripts delete --path "api/v2/hello.ts" --yes -c my-container ``` **Verification**: After each step, use `hoody exec scripts list -c my-container -o json` to confirm the expected state. After a move, the old path should be absent and the new path present. --- ### Workflow 2: Script Validation Pipeline Run a full validation suite before deploying a script to production. Each validation endpoint checks a different concern. **Step 1 — Validate syntax** ``` hoody exec validate syntax \ --code 'export default function() { return { ok: true }; }' \ -c my-container -o json ``` **Step 2 — Validate TypeScript types** ``` hoody exec validate typescript \ --code 'export default function(): { ok: boolean } { return { ok: true }; }' \ -c my-container -o json ``` **Step 3 — Validate dependencies** ``` hoody exec validate dependencies \ --code 'import { z } from "zod"; export default function() { return z.string().parse("hi"); }' \ -c my-container -o json ``` **Step 4 — Validate return type against a concrete value** ``` hoody exec validate return-type \ --type-definition '{ "status": "string", "count": "number" }' \ --value '{"status": "ok", "count": 42}' \ -c my-container -o json ``` **Step 5 — Validate magic comments** ``` hoody exec validate magic-comments \ --code '// @route GET /api/data\nexport default function() { return []; }' \ -c my-container -o json ``` **Step 6 — Run full script validation (all checks combined)** ``` hoody exec validate script \ --code 'export default function() { return { ok: true }; }' \ -c my-container -o json ``` **Verification**: All validation endpoints return a JSON object with a `valid` boolean field. If `valid` is `false`, the response includes `errors` or `warnings` with details. Fix all errors before proceeding to deployment. --- ### Workflow 3: Template-Based Script Creation Scaffold scripts from built-in templates or create reusable custom templates. **Step 1 — List all available templates** ``` hoody exec templates list -c my-container -o json ``` **Step 2 — Preview a template before generating** ``` hoody exec templates preview --name "rest-api" -c my-container -o json ``` **Step 3 — Generate a script from a template** ``` hoody exec templates generate --name "rest-api" -c my-container -o json ``` This creates the script files on the container filesystem. **Step 4 — Create a custom template from your own code** ``` hoody exec templates create -c my-container -o json ``` Pass the template definition (name, files, metadata) as the request body. **Step 5 — Update an existing custom template** ``` hoody exec templates update --name "my-custom-template" -c my-container -o json ``` **Step 6 — Delete a custom template** ``` hoody exec templates delete --name "my-custom-template" --yes -c my-container ``` **Verification**: After generating from a template, use `hoody exec scripts list -c my-container` to confirm the new files appeared. Read the generated files with `hoody exec scripts read` to inspect the scaffolded code. --- ### Workflow 4: Logging and Debugging Inspect, stream, and search execution logs to diagnose issues. **Step 1 — List available log files** ``` hoody exec logs list -c my-container -o json ``` **Step 2 — Read a specific log file** ``` hoody exec logs read -c my-container -o json ``` Pass the log file identifier as a parameter. **Step 3 — Stream logs in real-time** ``` hoody exec logs stream --file "exec.log" -c my-container ``` This opens a persistent connection that outputs log lines as they are written. **Step 4 — Search logs for a pattern** ``` hoody exec logs search -c my-container -o json ``` Pass search criteria (keyword, time range, severity) as request parameters. **Step 5 — Clear all logs** ``` hoody exec logs clear --yes -c my-container ``` **Step 6 — Clear the execution cache** ``` hoody exec cache-clear -c my-container ``` Cache clearing forces recompilation of scripts on next request. Use after dependency changes or when stale compiled code causes unexpected behavior. **Verification**: After clearing logs, `hoody exec logs list -c my-container` should return an empty list. After clearing cache, the next script execution will recompile. --- ### Workflow 5: Monitoring and Health Checks Observe system behavior, track script performance, and export metrics. **Step 1 — Run a health check** ``` hoody exec health -c my-container -o json ``` Returns the runtime status of the hoody-exec service on the container. **Step 2 — Get system-wide stats** ``` hoody exec monitor stats -c my-container -o json ``` Includes uptime, request counts, error rates, and resource usage. **Step 3 — View active (in-flight) requests** ``` hoody exec monitor active-requests -c my-container -o json ``` Useful for identifying long-running or stuck requests. **Step 4 — Get per-script performance metrics** ``` hoody exec monitor performance -c my-container -o json ``` Returns execution time, call count, and error rate for each script. **Step 5 — Export metrics in Prometheus format** ``` hoody exec monitor prometheus -c my-container ``` Returns metrics in Prometheus exposition format for scraping. **Step 6 — List monitored scripts** ``` hoody exec monitor scripts -c my-container -o json ``` **Verification**: Health check should return `"status": "ok"` or equivalent. If health fails, check container status with `hoody containers list` (refer to core SKILL.md for container operations). --- ### Workflow 6: Dependency and Package Management Install, check, and manage the dependency graph for scripts. **Step 1 — List bundled (built-in) dependencies** ``` hoody exec dependencies list -c my-container -o json ``` These are pre-installed packages available without explicit installation. **Step 2 — Check if required dependencies are satisfied** ``` hoody exec dependencies check -c my-container -o json ``` Scans scripts and reports any missing or version-mismatched dependencies. **Step 3 — Install additional dependencies** ``` hoody exec dependencies add-modules -c my-container -o json ``` Pass the list of modules to install as the request body. **Step 4 — Read the current package.json** ``` hoody exec package read -c my-container -o json ``` **Step 5 — Initialize a package.json** ``` hoody exec package init -c my-container -o json ``` **Step 6 — Install packages from package.json** ``` hoody exec package install -c my-container -o json ``` **Step 7 — Update packages** ``` hoody exec package update -c my-container -o json ``` **Step 8 — Compare current vs. latest versions** ``` hoody exec package compare -c my-container -o json ``` **Step 9 — Pin dependency versions** ``` hoody exec package pin -c my-container -o json ``` Pinning locks all dependency versions to prevent unexpected upgrades. **Verification**: After installing, run `hoody exec dependencies check -c my-container` to confirm all dependencies are satisfied. After pinning, read `hoody exec package read -c my-container` to verify locked versions. --- ### Workflow 7: Routing — Resolve, Discover, and Test hoody-exec uses Next.js-style file-based routing. Scripts at `api/users/[id].ts` handle requests to `/api/users/123`. **Step 1 — Discover all registered routes** ``` hoody exec route discover -c my-container -o json ``` Returns a classified list of all routes: static, dynamic `[param]`, catch-all `[...slug]`, and optional catch-all `[[...path]]`. **Step 2 — Resolve a specific URL path to its handler script** ``` hoody exec route resolve -c my-container -o json ``` Pass the URL path as the request body. Returns the script file that would handle the request and the extracted parameters. **Step 3 — Test multiple routes in batch** ``` hoody exec route test -c my-container -o json ``` Pass an array of URL paths. Each path is resolved and the result includes which script handles it and any extracted parameters. **Verification**: After creating or moving scripts, run `hoody exec route discover -c my-container` to verify the routing table reflects the expected file structure. Use `hoody exec route resolve` with specific paths to confirm parameter extraction works correctly. --- ### Workflow 8: Shared State for Script Coordination Scripts can read and write to a shared key-value store, enabling coordination between independently executed scripts. **Step 1 — Set a shared state value** ``` hoody exec shared-state set \ --hostname "my-app.local" \ --value '{"counter": 0, "lastUpdated": "2025-01-01T00:00:00Z"}' \ -c my-container -o json ``` **Step 2 — Retrieve the shared state** ``` hoody exec shared-state get \ --hostname "my-app.local" \ -c my-container -o json ``` Returns the stored JSON value for the given hostname. **Step 3 — Clear shared state** ``` hoody exec shared-state clear \ --hostname "my-app.local" \ --yes -c my-container -o json ``` **Verification**: After `set`, immediately `get` to confirm the value was stored. After `clear`, `get` should return null or an empty result. Shared state is scoped to the hostname parameter — different hostnames maintain separate state. --- ### Workflow 9: Scheduled Execution Configure scripts to run on a schedule with full history tracking. **Step 1 — List all configured schedules** ``` hoody exec schedules list -c my-container -o json ``` **Step 2 — Manually trigger a schedule** ``` hoody exec schedules trigger -c my-container -o json ``` Pass the schedule identifier as the request body. Executes the associated script immediately, outside its normal cron schedule. **Step 3 — Reload schedules from configuration** ``` hoody exec schedules reload -c my-container -o json ``` Use after modifying schedule definitions in scripts or configuration files. **Step 4 — View schedule execution history** ``` hoody exec schedules history -c my-container -o json ``` Returns a log of past executions: timestamps, duration, status, and output. **Verification**: After triggering, check `hoody exec schedules history -c my-container` to confirm the execution appeared with a success status. After reloading, `hoody exec schedules list` should reflect any changes. --- ### Workflow 10: OpenAPI Documentation Generation Auto-generate OpenAPI specifications from script type annotations, magic comments, and schema files. **Step 1 — List user scripts with schema information** ``` hoody exec user-openapi list-user -c my-container -o json ``` Shows which scripts have associated schema definitions. **Step 2 — Generate an OpenAPI specification** ``` hoody exec user-openapi generate -c my-container -o json ``` Produces an OpenAPI spec from all annotated scripts. **Step 3 — Validate a script's schema file** ``` hoody exec user-openapi user-schema -c my-container -o json ``` Checks that the schema file for a script is valid OpenAPI. **Step 4 — Serve the generated spec** ``` hoody exec user-openapi serve -c my-container ``` Makes the spec available at a URL for consumption by Swagger UI or other tools. **Step 5 — Serve the raw schema file** ``` hoody exec user-openapi serve-schema -c my-container ``` **Step 6 — Merge multiple OpenAPI specs** ``` hoody exec user-openapi merge -c my-container -o json ``` Pass an array of spec identifiers to combine into a single unified spec. **Verification**: After generating, use `hoody exec user-openapi serve` to view the spec in a browser. After merging, validate the result with `hoody exec user-openapi user-schema` to check for conflicts. --- ### Workflow 11: Magic Comments — Script Metadata Magic comments are in-code annotations that configure routing, caching, authentication, and other behavior without separate configuration files. **Step 1 — Get the magic comments schema** ``` hoody exec magic-comments schema -c my-container -o json ``` Returns the full schema of supported magic comment directives and their allowed values. **Step 2 — Read magic comments from a script** ``` hoody exec magic-comments read -c my-container -o json ``` Pass the script path. Returns all parsed magic comments and their values. **Step 3 — Update magic comments for a single script** ``` hoody exec magic-comments update -c my-container -o json ``` Pass the script path and the updated comment values. **Step 4 — Bulk-update magic comments across multiple scripts** ``` hoody exec magic-comments bulk-update -c my-container -o json ``` Pass a list of script paths and their respective comment updates. **Verification**: After updating, read the comments back with `hoody exec magic-comments read` to confirm changes applied. Run `hoody exec validate magic-comments` to check for syntax or schema errors. --- ### Workflow 12: SDK Management Import and manage external SDKs that scripts can consume. **Step 1 — Import an SDK** ``` hoody exec sdk import -c my-container -o json ``` Pass the SDK source (URL, package name, or definition) as the request body. **Step 2 — List imported SDKs** ``` hoody exec sdk list -c my-container -o json ``` **Step 3 — Get a specific SDK by ID** ``` hoody exec sdk get --id -c my-container -o json ``` **Step 4 — Delete an SDK** ``` hoody exec sdk delete --id --yes -c my-container ``` **Verification**: After importing, `hoody exec sdk list` should show the new SDK. After deletion, it should be absent. Check `hoody exec dependencies check` to ensure scripts depending on a deleted SDK are flagged. --- ### Workflow 13: System Operations Restart the hoody-exec runtime and check restart status. **Step 1 — Initiate a server restart** ``` hoody exec system restart --yes -c my-container ``` **Step 2 — Check restart progress** ``` hoody exec system restart-status -c my-container -o json ``` Returns `"status": "restarting"` while in progress and `"status": "ready"` when complete. **Verification**: Poll `hoody exec system restart-status` until the status changes from `"restarting"` to `"ready"`. Then run `hoody exec health -c my-container` to confirm the runtime is fully operational. --- ## Advanced Operations ### Advanced Workflow 1: Full Deployment Pipeline A complete end-to-end workflow from script creation to validated, documented, monitored deployment. **Phase 1 — Scaffold and create** ``` # Preview available templates hoody exec templates list -c my-container -o json # Generate from template hoody exec templates generate --name "rest-api" -c my-container -o json # Or write a custom script directly hoody exec scripts write \ --path "api/users.ts" \ --content 'export default function(req: Request) { return { users: [] }; }' \ -c my-container ``` **Phase 2 — Validate** ``` # Syntax check hoody exec validate syntax --code '...' -c my-container -o json # TypeScript check hoody exec validate typescript --code '...' -c my-container -o json # Dependency check hoody exec validate dependencies --code '...' -c my-container -o json # Full script validation hoody exec validate script --code '...' -c my-container -o json ``` Fix any validation errors before proceeding. Validation endpoints return detailed error messages with line numbers and suggestions. **Phase 3 — Verify routing** ``` # Confirm the script is registered hoody exec route discover -c my-container -o json # Test the specific path hoody exec route resolve -c my-container -o json # Batch test multiple paths hoody exec route test -c my-container -o json ``` **Phase 4 — Generate documentation** ``` # Add magic comments for OpenAPI metadata hoody exec magic-comments update -c my-container -o json # Generate OpenAPI spec hoody exec user-openapi generate -c my-container -o json # Serve the spec hoody exec user-openapi serve -c my-container ``` **Phase 5 — Monitor** ``` # Confirm health hoody exec health -c my-container -o json # Watch for errors hoody exec logs stream --file "exec.log" -c my-container # Check performance after traffic arrives hoody exec monitor performance -c my-container -o json ``` --- ### Advanced Workflow 2: Script Chaining Scripts can call other scripts to compose multi-step workflows. This pattern enables separation of concerns — one script handles HTTP parsing, another handles business logic, a third handles data access. **Architecture**: ``` Request → api/ingest.ts → calls → internal/transform.ts → calls → internal/store.ts ``` **Steps**: 1. Write each script to its own path: ``` hoody exec scripts write --path "api/ingest.ts" --content '...' -c my-container hoody exec scripts write --path "internal/transform.ts" --content '...' -c my-container hoody exec scripts write --path "internal/store.ts" --content '...' -c my-container ``` 2. Verify the tree structure: ``` hoody exec scripts tree -c my-container -o json ``` 3. Test routing to confirm only `api/ingest.ts` is exposed externally: ``` hoody exec route discover -c my-container -o json ``` Scripts under `internal/` are not routable by default — only scripts in routable directories receive HTTP requests. 4. Use shared state to pass data between chain steps if needed: ``` hoody exec shared-state set --hostname "pipeline" --value '{"step": "ingest"}' -c my-container ``` --- ### Advanced Workflow 3: Error Recovery When script execution fails, use this systematic approach to diagnose and recover. **Step 1 — Check system health** ``` hoody exec health -c my-container -o json ``` If health is degraded, restart the runtime: ``` hoody exec system restart --yes -c my-container hoody exec system restart-status -c my-container -o json ``` **Step 2 — Search logs for errors** ``` hoody exec logs search -c my-container -o json ``` Filter by error severity or keyword. The search endpoint returns matching log entries with timestamps and stack traces. **Step 3 — Check active requests for stuck executions** ``` hoody exec monitor active-requests -c my-container -o json ``` Long-running requests may indicate infinite loops or blocked I/O. **Step 4 — Validate the failing script** ``` hoody exec validate script --code '...' -c my-container -o json ``` Syntax or type errors introduced during editing are common causes of runtime failures. **Step 5 — Check dependencies** ``` hoody exec dependencies check -c my-container -o json ``` Missing or version-conflicting dependencies cause import failures at runtime. **Step 6 — Clear cache and retry** ``` hoody exec cache-clear -c my-container ``` Stale compiled artifacts can cause unexpected behavior after code changes. Clearing forces recompilation. **Step 7 — If all else fails, restart** ``` hoody exec system restart --yes -c my-container ``` --- ### Advanced Workflow 4: Performance Optimization Use monitoring data to identify and optimize slow scripts. **Step 1 — Export baseline metrics** ``` hoody exec monitor stats -c my-container -o json ``` **Step 2 — Get per-script performance breakdown** ``` hoody exec monitor performance -c my-container -o json ``` This shows execution time percentiles, call counts, and error rates for each script. Identify scripts with high p95 latency or elevated error rates. **Step 3 — Check for resource contention** ``` hoody exec monitor active-requests -c my-container -o json ``` High concurrent request counts on a single script may indicate a bottleneck. **Step 4 — Set up Prometheus scraping** ``` hoody exec monitor prometheus -c my-container ``` Import this endpoint into your Prometheus configuration for continuous metric collection. Standard metrics include request duration histograms, request counts, and error rates. **Step 5 — Optimize and re-measure** After making changes: ``` hoody exec scripts write --path "api/slow-endpoint.ts" --content '...' -c my-container hoody exec cache-clear -c my-container hoody exec monitor performance -c my-container -o json ``` Compare the new performance data against the baseline. --- ### Advanced Workflow 5: Scheduled Task Management Set up, monitor, and manage recurring script executions. **Step 1 — Write the scheduled script** ``` hoody exec scripts write \ --path "scheduled/daily-report.ts" \ --content 'export default async function() { return { report: "generated" }; }' \ -c my-container ``` **Step 2 — Verify the schedule is registered** ``` hoody exec schedules list -c my-container -o json ``` Schedules are typically defined via magic comments in the script file or in a schedule configuration. **Step 3 — Test by triggering manually** ``` hoody exec schedules trigger -c my-container -o json ``` Pass the schedule identifier. This runs the script immediately without waiting for the cron trigger. **Step 4 — Verify execution in history** ``` hoody exec schedules history -c my-container -o json ``` Confirm the manual trigger appears with a success status and reasonable duration. **Step 5 — Reload after configuration changes** ``` hoody exec schedules reload -c my-container -o json ``` Use this after modifying cron expressions, adding new schedules, or removing old ones. --- ### Advanced Workflow 6: Multi-Container Script Deployment When deploying the same scripts across multiple containers (e.g., staging and production), use a consistent pattern. **Step 1 — Write scripts to the staging container** ``` hoody exec scripts write --path "api/endpoint.ts" --content '...' -c staging-container-id ``` **Step 2 — Validate on staging** ``` hoody exec validate script --code '...' -c staging-container-id -o json hoody exec health -c staging-container-id -o json ``` **Step 3 — Test routing on staging** ``` hoody exec route discover -c staging-container-id -o json ``` **Step 4 — Deploy to production** ``` hoody exec scripts write --path "api/endpoint.ts" --content '...' -c production-container-id ``` **Step 5 — Verify production deployment** ``` hoody exec scripts read --path "api/endpoint.ts" -c production-container-id -o json hoody exec health -c production-container-id -o json hoody exec route discover -c production-container-id -o json ``` **Tip**: Use the `HOODY_CONTAINER` environment variable to avoid repeating `-c ` in every command within a session: ``` export HOODY_CONTAINER=staging-container-id hoody exec scripts list -o json hoody exec health -o json ``` --- ## Quick Reference ### Essential Commands | Operation | Command | |---|---| | Write script | `hoody exec scripts write --path --content -c ` | | Read script | `hoody exec scripts read --path -c ` | | List scripts | `hoody exec scripts list -c ` | | Delete script | `hoody exec scripts delete --path --yes -c ` | | Script tree | `hoody exec scripts tree -c ` | | Move script | `hoody exec scripts move --from --to -c ` | | Health check | `hoody exec health -c ` | | List logs | `hoody exec logs list -c ` | | Stream logs | `hoody exec logs stream --file -c ` | | Clear cache | `hoody exec cache-clear -c ` | | System stats | `hoody exec monitor stats -c ` | | Active requests | `hoody exec monitor active-requests -c ` | | Performance | `hoody exec monitor performance -c ` | | Prometheus | `hoody exec monitor prometheus -c ` | | Discover routes | `hoody exec route discover -c ` | | Resolve route | `hoody exec route resolve -c ` | | List templates | `hoody exec templates list -c ` | | Generate from template | `hoody exec templates generate --name -c ` | | List schedules | `hoody exec schedules list -c ` | | Trigger schedule | `hoody exec schedules trigger -c ` | | Restart server | `hoody exec system restart --yes -c ` | | Restart status | `hoody exec system restart-status -c ` | ### Validation Commands | Check | Command | |---|---| | Syntax | `hoody exec validate syntax --code -c ` | | TypeScript | `hoody exec validate typescript --code -c ` | | Dependencies | `hoody exec validate dependencies --code -c ` | | Return type | `hoody exec validate return-type --type-definition --value -c ` | | Magic comments | `hoody exec validate magic-comments --code -c ` | | Full script | `hoody exec validate script --code -c ` | ### Dependency & Package Commands | Operation | Command | |---|---| | List bundled | `hoody exec dependencies list -c ` | | Check deps | `hoody exec dependencies check -c ` | | Install deps | `hoody exec dependencies add-modules -c ` | | Read package.json | `hoody exec package read -c ` | | Init package.json | `hoody exec package init -c ` | | Install packages | `hoody exec package install -c ` | | Update packages | `hoody exec package update -c ` | | Compare versions | `hoody exec package compare -c ` | | Pin versions | `hoody exec package pin -c ` | ### Shared State Commands | Operation | Command | |---|---| | Get state | `hoody exec shared-state get --hostname -c ` | | Set state | `hoody exec shared-state set --hostname --value -c ` | | Clear state | `hoody exec shared-state clear --hostname --yes -c ` | ### OpenAPI Commands | Operation | Command | |---|---| | Generate spec | `hoody exec user-openapi generate -c ` | | List user scripts | `hoody exec user-openapi list-user -c ` | | Validate schema | `hoody exec user-openapi user-schema -c ` | | Serve spec | `hoody exec user-openapi serve -c ` | | Serve schema | `hoody exec user-openapi serve-schema -c ` | | Merge specs | `hoody exec user-openapi merge -c ` | ### Magic Comments Commands | Operation | Command | |---|---| | Get schema | `hoody exec magic-comments schema -c ` | | Read comments | `hoody exec magic-comments read -c ` | | Update comments | `hoody exec magic-comments update -c ` | | Bulk update | `hoody exec magic-comments bulk-update -c ` | ### SDK Commands | Operation | Command | |---|---| | Import SDK | `hoody exec sdk import -c ` | | List SDKs | `hoody exec sdk list -c ` | | Get SDK | `hoody exec sdk get --id -c ` | | Delete SDK | `hoody exec sdk delete --id --yes -c ` | ### Authentication | Method | Example | |---|---| | Login | `hoody auth login` | | Token flag | `hoody exec health --token -c ` | | Environment variable | `export HOODY_TOKEN=` | ### Output Formats | Flag | Format | |---|---| | `-o json` | Machine-readable JSON | | `-o table` | Human-readable table (default) | | `-o yaml` | YAML output | | `-o wide` | Extended table columns | ### Global Flags | Flag | Purpose | |---|---| | `-c ` | Target container (required for all exec commands) | | `-o ` | Output format | | `--yes` | Skip confirmation prompts (required for destructive commands) | | `-t ` | API token override | | `--profile ` | Configuration profile | ### Route Types (Next.js-style) | Type | Pattern | Example Path | |---|---|---| | Static | `/api/users` | `api/users.ts` | | Dynamic | `/api/users/[id]` | `api/users/[id].ts` | | Catch-all | `/api/docs/[...slug]` | `api/docs/[...slug].ts` | | Optional catch-all | `/api/pages/[[...path]]` | `api/pages/[[...path]].ts` | ### Script Execution URL Pattern Once deployed, scripts are accessible at: ``` POST https://{projectId}-{containerId}-exec-{serviceId}.{node}.containers.hoody.com/{script-path} ``` The `{script-path}` corresponds to the file path without the extension (e.g., `api/hello.ts` is served at `/api/hello`). ### Typical Response Structure Validation responses follow this pattern: ``` { "valid": true, "errors": [], "warnings": [] } ``` Monitoring responses follow this pattern: ``` { "status": "ok", "uptime": 3600, "requests": { "total": 1500, "errors": 3 } } ```