@chllming/wave-orchestration 0.5.4 → 0.6.1

package/scripts/wave.mjs

@@ -17,6 +17,7 @@ function printHelp() {
   wave project setup [options]
   wave project show [options]
   wave draft [draft options]
+  wave adhoc [adhoc options]
   wave launch [launcher options]
   wave autonomous [autonomous options]
   wave feedback [feedback options]
@@ -51,6 +52,14 @@ if (["init", "upgrade", "changelog", "doctor"].includes(subcommand)) {
     console.error(`[wave] ${error instanceof Error ? error.message : String(error)}`);
     process.exit(Number.isInteger(error?.exitCode) ? error.exitCode : 1);
   }
+} else if (subcommand === "adhoc") {
+  try {
+    const { runAdhocCli } = await import("./wave-orchestrator/adhoc.mjs");
+    await runAdhocCli(rest);
+  } catch (error) {
+    console.error(`[wave] ${error instanceof Error ? error.message : String(error)}`);
+    process.exit(Number.isInteger(error?.exitCode) ? error.exitCode : 1);
+  }
 } else if (subcommand === "launch") {
   try {
     const { runLauncherCli } = await import("./wave-orchestrator/launcher.mjs");

package/skills/README.md

@@ -0,0 +1,202 @@
+# Skills
+
+Skills are repo-owned procedural bundles that Wave attaches to agents at runtime. They capture durable operating knowledge such as coding norms, role checklists, runtime behavior, provider verification, and closure rules.
+
+Skills are not one-off prompts. They are reusable procedures with explicit routing metadata.
+
+## Bundle Layout
+
+Each skill lives under `skills/<skill-id>/`:
+
+```text
+skills/<skill-id>/
+  skill.json
+  SKILL.md
+  adapters/
+    claude.md
+    codex.md
+    opencode.md
+    local.md
+  references/
+    ...
+```
+
+- `skill.json` is required.
+- `SKILL.md` is required.
+- `adapters/` is optional and runtime-specific.
+- `references/` is optional and can be nested recursively.
+
+## `skill.json`
+
+Required fields:
+
+| Field | Purpose |
+| --- | --- |
+| `id` | Must match the directory name. |
+| `title` | Human-readable name. |
+| `description` | Short routing summary. |
+| `activation.when` | Human-readable statement of when the skill should apply. |
+
+Optional fields:
+
+| Field | Purpose |
+| --- | --- |
+| `version` | Bundle version for traceability. |
+| `tags` | Lightweight grouping tags. |
+| `activation.roles` | Restrict auto-attachment to specific roles. |
+| `activation.runtimes` | Restrict auto-attachment to specific runtimes. |
+| `activation.deployKinds` | Restrict auto-attachment to specific deploy kinds. |
+| `termination.when` | Explicit stop condition for the procedure. |
+| `permissions.network` | Declared network expectations. |
+| `permissions.shell` | Declared shell/tool expectations. |
+| `permissions.mcpServers` | Declared MCP expectations. |
+| `trust.tier` | Provenance marker such as `repo-owned`. |
+| `evalCases[]` | Deterministic routing checks exercised by `wave doctor`. |
+
+## `SKILL.md`
+
+`SKILL.md` is the canonical instruction body. Keep it:
+
+- procedural
+- reusable across many waves
+- smaller than a full reference manual
+- free of assignment-specific details
+
+Use `references/` for detailed catalogs, command inventories, and longer examples that would otherwise bloat the canonical skill.
+
+## `adapters/`
+
+Adapters are small runtime-specific overlays. Use them only when the runtime interaction materially differs.
+
+Common reasons:
+
+- Claude should prefer MCP or system-prompt-aware behavior.
+- Codex should stay terminal-first and deterministic.
+- OpenCode should lean on file attachments and direct edits.
+- Local should stay within smoke-validation limits.
+
+## `references/`
+
+Reference files are progressive-disclosure material. Wave lists them in the compact catalog and, for OpenCode, attaches them as files. The agent reads them on demand rather than paying the token cost up front.
+
+Use references for:
+
+- command catalogs
+- provider failure-mode inventories
+- longer examples
+- repo-specific extensions that do not belong in the core procedure
+
+## Resolution Model
+
+Wave stacks skills in this order:
+
+1. global `skills.base`
+2. lane `skills.base`
+3. global `skills.byRole[role]`
+4. lane `skills.byRole[role]`
+5. global `skills.byRuntime[runtime]`
+6. lane `skills.byRuntime[runtime]`
+7. global `skills.byDeployKind[kind]`
+8. lane `skills.byDeployKind[kind]`
+9. agent `### Skills`
+
+Then it filters configured skills through manifest activation:
+
+- role skills should declare their role
+- runtime skills should declare their runtime
+- provider skills should usually declare both deploy kinds and the roles that genuinely need provider context
+
+Explicit per-agent `### Skills` still force attachment. Use that only for real exceptions.
+
+## Metadata-First Delivery
+
+Wave no longer inlines every skill body into every runtime prompt by default.
+
+Generated artifacts:
+
+| File | Purpose |
+| --- | --- |
+| `skills.resolved.md` | Compact skill catalog for the active run. |
+| `skills.expanded.md` | Full canonical/debug view with `SKILL.md` bodies and adapters. |
+| `skills.metadata.json` | Structured ids, activation, permissions, hashes, paths, and artifacts. |
+| `<runtime>-skills.txt` | Runtime-specific compact projection. |
+
+Runtime behavior:
+
+| Runtime | Delivery model |
+| --- | --- |
+| Codex | Compact catalog in prompt plus bundle directories through `--add-dir`. |
+| Claude | Compact catalog appended to the generated system prompt. |
+| OpenCode | Compact catalog injected into `opencode.json`; `skill.json`, `SKILL.md`, the selected adapter, and recursive references attached via `--file`. |
+| Local | Compact catalog only. |
+
+## Validation
+
+Run:
+
+```sh
+node scripts/wave.mjs doctor --json
+```
+
+Doctor validates:
+
+- bundle existence
+- manifest schema
+- selector-key correctness
+- config-to-manifest activation consistency
+- every declared `evalCases[]`
+
+This is fail-closed. Selector typos and malformed bundles are errors, not silent no-ops.
+
+## Skill Categories
+
+Base:
+
+- `wave-core`
+- `repo-coding-rules`
+
+Role:
+
+- `role-implementation`
+- `role-integration`
+- `role-documentation`
+- `role-infra`
+- `role-deploy`
+- `role-research`
+- `role-cont-qa`
+- `role-cont-eval`
+
+Runtime:
+
+- `runtime-codex`
+- `runtime-claude`
+- `runtime-opencode`
+- `runtime-local`
+
+Provider:
+
+- `provider-railway`
+- `provider-aws`
+- `provider-kubernetes`
+- `provider-docker-compose`
+- `provider-ssh-manual`
+- `provider-custom-deploy`
+- `provider-github-release`
+
+Provider skills are configured by deploy kind, but the shipped manifests further restrict them to `deploy`, `infra`, `integration`, and `cont-qa` auto-attachment.
+
+## Creating or Updating a Skill
+
+1. Create `skills/<skill-id>/`.
+2. Add `skill.json` with at least `id`, `title`, `description`, and `activation.when`.
+3. Add `SKILL.md`.
+4. Add adapters or references only where they materially help.
+5. Register the bundle in `wave.config.json` if it should auto-attach.
+6. Add meaningful `evalCases[]`.
+7. Run `node scripts/wave.mjs doctor --json`.
+
+## Further Reading
+
+- [Skills Reference](../docs/reference/skills.md)
+- [Context7 vs Skills](../docs/concepts/context7-vs-skills.md)
+- [What Is A Wave](../docs/concepts/what-is-a-wave.md)

package/skills/provider-aws/SKILL.md

@@ -1,6 +1,117 @@
 # AWS
 
+<!-- CUSTOMIZE: Add your AWS account IDs, regions, service names, and IAM role ARNs below. -->
+
+## Core Rules
+
 - Name the exact AWS service, account, region, and resource involved.
 - Prefer explicit CLI or console-equivalent evidence for deployment and environment state.
 - Separate IAM or identity issues from workload health or rollout issues.
 - If AWS state is inferred indirectly, mark the proof gap instead of implying live verification.
+- Always include the region in verification commands. Do not rely on default region configuration.
+
+## Resource Identification
+
+Every AWS verification must specify:
+
+- **Service type** -- ECS, Lambda, EC2, S3, CloudFront, RDS, DynamoDB, SQS, SNS, etc.
+- **Account ID** -- the 12-digit AWS account number.
+- **Region** -- the AWS region (e.g., `us-east-1`, `eu-west-1`).
+- **Resource identifier** -- ARN, resource name, or resource ID depending on the service.
+
+Do not use shorthand. `the ECS service` is insufficient. `ecs service my-api in cluster prod-cluster, account 123456789012, us-east-1` is correct.
+
+## Verification Procedures
+
+### ECS (Task and Service Status)
+
+```
+aws ecs describe-services --cluster <cluster> --services <service> --region <region>
+aws ecs list-tasks --cluster <cluster> --service-name <service> --region <region>
+aws ecs describe-tasks --cluster <cluster> --tasks <task-arn> --region <region>
+```
+
+Confirm: desired count matches running count, last deployment status is PRIMARY and COMPLETED, no tasks in STOPPED state with error exit codes.
+
+### Lambda
+
+```
+aws lambda get-function --function-name <name> --region <region>
+aws lambda invoke --function-name <name> --payload '{}' /dev/stdout --region <region>
+```
+
+Confirm: function exists, runtime is expected version, last modified timestamp is recent if just deployed, invoke returns expected status code.
+
+### EC2
+
+```
+aws ec2 describe-instances --instance-ids <id> --region <region>
+```
+
+Confirm: instance state is `running`, status checks pass (system and instance), security groups and network configuration match expectations.
+
+### S3
+
+```
+aws s3 ls s3://<bucket>/ --region <region>
+aws s3api head-bucket --bucket <bucket> --region <region>
+```
+
+Confirm: bucket exists, expected objects are present, access permissions are correct.
+
+### CloudWatch Metrics
+
+```
+aws cloudwatch get-metric-statistics --namespace <ns> --metric-name <metric> --dimensions <dims> --start-time <start> --end-time <end> --period 300 --statistics Average --region <region>
+```
+
+Use for: error rate trends, latency baselines, invocation counts, and health signal confirmation.
+
+<!-- CUSTOMIZE: Add verification procedures for additional AWS services used in your project here. -->
+
+## Evidence Format
+
+When recording AWS verification, use this structure:
+
+```
+Service: <aws-service-type>
+Resource: <ARN-or-name>
+Account: <account-id>
+Region: <region>
+Verification Command: <exact-command-run>
+Result: <summary-of-output>
+Status: <healthy|degraded|failed|unknown>
+Timestamp Context: <when-verified>
+```
+
+Omit fields that were not checked. Do not fill in fields with assumed values.
+
+## IAM vs Workload Issues
+
+These are different failure domains with different owners and different fixes:
+
+### IAM / Identity Failures
+
+- Symptom: `AccessDenied`, `UnauthorizedAccess`, `AssumeRolePolicy` errors.
+- Owner: infrastructure role (the agent or team managing IAM policies and roles).
+- Fix: policy update, trust relationship change, or role assumption path correction.
+- Do not conflate with app health. A Lambda may be healthy but unable to reach S3 due to a missing IAM policy.
+
+### Workload / Application Failures
+
+- Symptom: crash loops, OOM kills, health check failures, timeout errors, application-level error responses.
+- Owner: deploy role (the agent or team managing the application code and configuration).
+- Fix: code fix, configuration change, resource scaling, or dependency resolution.
+
+When reporting failures, classify which domain the failure belongs to. If both are present, report them as separate issues with separate owners.
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - AWS account IDs: production=<id>, staging=<id>
+  - Primary regions: <comma-separated-list>
+  - Service inventory: <service-type> -> <resource-name> -> <region>
+  - IAM role ARNs: deploy-role=<arn>, infra-role=<arn>
+  - CloudWatch alarm names and thresholds
+  - Custom health check endpoints per service
+-->

package/skills/provider-aws/adapters/claude.md

@@ -0,0 +1 @@
+Prefer AWS CLI commands with `--output json` for machine-readable evidence. Use MCP tools for AWS operations when available. Record exact CLI commands and JSON output excerpts as deployment proof. Separate IAM verification from workload health checks — run both but report independently.

package/skills/provider-aws/adapters/codex.md

@@ -0,0 +1 @@
+Use AWS CLI commands with `--output json` for all verification. Network access may be restricted in sandbox — if AWS APIs are unreachable, record the access gap as deploy risk rather than inferring state. Keep CLI invocations deterministic and capture stdout for evidence.

package/skills/provider-aws/references/service-verification.md

@@ -0,0 +1,39 @@
+# AWS Service Verification Patterns
+
+Reference for verifying AWS deployment state per service type.
+
+## ECS (Elastic Container Service)
+- Task status: `aws ecs describe-tasks --cluster <cluster> --tasks <task-arn>`
+- Service status: `aws ecs describe-services --cluster <cluster> --services <service-name>`
+- Key checks: desiredCount == runningCount, no STOPPED tasks with non-zero exit code, deployment in COMPLETED state.
+- Logs: `aws logs get-log-events --log-group-name <group> --log-stream-name <stream>`
+
+## Lambda
+- Function status: `aws lambda get-function --function-name <name>`
+- Invoke test: `aws lambda invoke --function-name <name> --payload '{}' /dev/stdout`
+- Key checks: State is Active, LastUpdateStatus is Successful, invoke returns expected status code.
+
+## EC2
+- Instance status: `aws ec2 describe-instance-status --instance-ids <id>`
+- Key checks: InstanceState is running, SystemStatus and InstanceStatus are ok.
+- Connect test: Verify security groups allow expected ports.
+
+## S3
+- Bucket verification: `aws s3 ls s3://<bucket>/`
+- Key checks: Bucket exists, expected objects are present, ACLs/policies are correct.
+
+## CloudWatch
+- Metrics: `aws cloudwatch get-metric-statistics --namespace <ns> --metric-name <metric> --period 300 --statistics Average`
+- Alarms: `aws cloudwatch describe-alarms --alarm-names <name>`
+- Key checks: No ALARM state, error rate metrics within threshold.
+
+## RDS
+- Instance status: `aws rds describe-db-instances --db-instance-identifier <id>`
+- Key checks: DBInstanceStatus is available, no pending modifications.
+
+## General Pattern
+For any AWS service:
+1. Identify the resource ARN or name.
+2. Use the describe/get API to verify state.
+3. Check for pending operations or degraded status.
+4. Record the region, account, and exact command used as evidence.

package/skills/provider-aws/skill.json

@@ -1,5 +1,54 @@
 {
   "id": "provider-aws",
   "title": "AWS",
-  "description": "AWS environment and rollout norms."
+  "description": "Guides deploy verification against AWS services: resource identification, per-service health checks, IAM vs workload issue separation, and evidence recording.",
+  "activation": {
+    "when": "Attach when the wave deploy surface is AWS and the agent must reason about AWS-specific rollout or closure state.",
+    "roles": [
+      "deploy",
+      "infra",
+      "integration",
+      "cont-qa"
+    ],
+    "runtimes": [],
+    "deployKinds": [
+      "aws"
+    ]
+  },
+  "termination": "Stop when AWS service evidence is captured or the blocking surface is isolated.",
+  "permissions": {
+    "network": [
+      "amazonaws.com"
+    ],
+    "shell": [
+      "aws"
+    ],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "deploy-aws",
+      "role": "deploy",
+      "runtime": "opencode",
+      "deployKind": "aws",
+      "expectActive": true
+    },
+    {
+      "id": "infra-aws",
+      "role": "infra",
+      "runtime": "claude",
+      "deployKind": "aws",
+      "expectActive": true
+    },
+    {
+      "id": "documentation-aws",
+      "role": "documentation",
+      "runtime": "claude",
+      "deployKind": "aws",
+      "expectActive": false
+    }
+  ]
 }

package/skills/provider-custom-deploy/SKILL.md

@@ -1,5 +1,64 @@
 # Custom Deploy
 
+<!-- CUSTOMIZE: Add your custom verification commands, health endpoints, deployment scripts, and environment-specific conventions below. -->
+
+## Core Rules
+
 - Make the custom environment contract explicit before treating it as proved.
 - Name the exact verification surface, command, or operator artifact used as evidence.
 - If the environment lacks a stable verification path, record the resulting deploy risk.
+- Do not borrow verification assumptions from standard providers. Custom environments have custom proof requirements.
+- Every claim of "verified" must reference a concrete command, output, or artifact.
+
+## Contract Definition
+
+Before claiming any deploy target is verified in a custom environment, define the contract:
+
+1. **Verification surface** -- what tool, command, API, or artifact serves as the source of truth for this environment's state? Name it exactly.
+2. **Healthy signal** -- what specific output, status code, or artifact state means the deploy is healthy? Define the exact match criteria.
+3. **Degraded signal** -- what output means the deploy is running but not fully healthy? Define the boundary between degraded and healthy.
+4. **Failed signal** -- what output means the deploy has failed? Define the criteria that distinguish failure from degraded.
+5. **Unknown signal** -- if the verification surface is unreachable or returns unexpected output, the state is unknown. Do not default to healthy or failed.
+
+If any of these cannot be defined, record the gap as deploy risk before proceeding.
+
+## Verification Surface
+
+Name the exact verification mechanism:
+
+- **Command-based** -- a CLI command that returns structured output. Preferred. Record the exact command, expected output format, and how to parse healthy/degraded/failed from it.
+- **API-based** -- an HTTP endpoint that returns status. Record the URL, expected status code, expected response body or fields, and authentication method.
+- **Artifact-based** -- a file, database record, or log entry that serves as proof. Record the exact path or query, expected content, and how freshness is determined.
+- **Process-based** -- a running process or service that can be checked. Record the process name, how to check it, and what constitutes healthy state.
+
+Prefer verification surfaces with machine-readable output. If the only evidence is human-readable prose (e.g., a dashboard screenshot), record that as a proof quality limitation.
+
+If no stable verification surface exists for the custom environment, this is itself a deploy risk. Record:
+
+```
+Deploy Risk: No stable verification surface for <environment-name>.
+Attempted: <what-was-tried>
+Observed: <what-was-seen>
+Gap: <what-remains-unknown>
+```
+
+## Risk Recording
+
+When the custom environment lacks standard verification capabilities, record the full state:
+
+1. **What was attempted** -- the exact commands, API calls, or checks that were run.
+2. **What was observed** -- the exact output, including partial or ambiguous results.
+3. **What remains unknown** -- the specific questions that could not be answered.
+4. **Risk assessment** -- how the unknowns affect confidence in the deploy state. Be specific: "cannot confirm database migration ran" is useful; "some things are unclear" is not.
+
+Include this risk record in the `[deploy-status]` marker detail field or as a separate coordination record.
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Custom verification commands: <command> -> <expected-output>
+  - Health endpoints: <url> -> <expected-status> -> <expected-body>
+  - Deployment scripts: <script-path> -> <usage>
+  - Environment-specific conventions: <env-name> -> <verification-approach>
+  - Known proof gaps and accepted risk levels
+-->

package/skills/provider-custom-deploy/skill.json

@@ -1,5 +1,50 @@
 {
   "id": "provider-custom-deploy",
   "title": "Custom Deploy",
-  "description": "Fallback deploy norms for custom environments."
+  "description": "Guides custom environment verification: contract definition, verification surface identification, and deploy risk recording when standard paths are unavailable.",
+  "activation": {
+    "when": "Attach when the wave uses a custom deploy contract and the agent must make the verification surface explicit.",
+    "roles": [
+      "deploy",
+      "infra",
+      "integration",
+      "cont-qa"
+    ],
+    "runtimes": [],
+    "deployKinds": [
+      "custom"
+    ]
+  },
+  "termination": "Stop when the custom deploy contract, evidence, and residual risk are explicitly recorded.",
+  "permissions": {
+    "network": [],
+    "shell": [],
+    "mcpServers": []
+  },
+  "trust": {
+    "tier": "repo-owned"
+  },
+  "evalCases": [
+    {
+      "id": "deploy-custom",
+      "role": "deploy",
+      "runtime": "opencode",
+      "deployKind": "custom",
+      "expectActive": true
+    },
+    {
+      "id": "integration-custom",
+      "role": "integration",
+      "runtime": "claude",
+      "deployKind": "custom",
+      "expectActive": true
+    },
+    {
+      "id": "documentation-custom",
+      "role": "documentation",
+      "runtime": "claude",
+      "deployKind": "custom",
+      "expectActive": false
+    }
+  ]
 }

package/skills/provider-docker-compose/SKILL.md

@@ -1,6 +1,96 @@
 # Docker Compose
 
+<!-- CUSTOMIZE: Add your compose file paths, service names, and health check endpoints below. -->
+
+## Core Rules
+
 - Use compose file names, service names, ports, and health checks exactly.
 - Distinguish local container health from production readiness.
 - Record the exact compose commands or logs used as proof.
 - Make service dependency and readiness ordering explicit when rollout depends on it.
+- Container running is not the same as application healthy. Always verify beyond container state.
+
+## Service Identification
+
+Every Docker Compose verification must specify:
+
+- **Compose file path** -- the exact path to the compose file (e.g., `docker-compose.yml`, `docker-compose.prod.yml`, `compose.yaml`).
+- **Service names** -- exact names as defined in the compose file.
+- **Exposed ports** -- host:container port mappings for each service.
+- **Volume mounts** -- named volumes or bind mounts that carry persistent state.
+- **Network names** -- custom networks defined in the compose file, if any.
+
+Do not use shorthand. `the database service` is insufficient. `service postgres in docker-compose.yml, port 5432:5432, volume pgdata:/var/lib/postgresql/data` is correct.
+
+## Verification Procedures
+
+### Container State
+
+```
+docker compose -f <file> ps
+docker compose -f <file> ps --format json
+```
+
+Confirm: all expected services are listed, state is `running` (not `exited`, `restarting`, or `created`), health status is `healthy` if healthcheck is defined.
+
+### Service Logs
+
+```
+docker compose -f <file> logs <service> --tail=50
+docker compose -f <file> logs <service> --since 5m
+```
+
+Confirm: no fatal errors, startup completed successfully, application-level health indicators are positive.
+
+### Health Checks
+
+```
+docker compose -f <file> exec <service> <health-command>
+curl -s http://localhost:<port>/health
+```
+
+Confirm: health endpoint returns expected status code and body. If the service defines a Docker healthcheck, verify it shows `healthy` in `docker compose ps`.
+
+### Detailed Container State
+
+```
+docker inspect <container-name-or-id>
+docker inspect --format='{{.State.Health.Status}}' <container-name-or-id>
+```
+
+Use for: investigating restart reasons, checking exact health check output, verifying environment variables and mount points inside the container.
+
+<!-- CUSTOMIZE: Add project-specific verification commands or health endpoints here. -->
+
+## Local vs Production
+
+Do not conflate container state with application readiness:
+
+- **Container running** -- the process started. This does not mean it is accepting requests or connected to its dependencies.
+- **Container healthy** -- the Docker healthcheck passed. This confirms a basic liveness check but may not cover all application functionality.
+- **Application healthy** -- the application responds correctly to real requests, is connected to all dependencies, and is processing work as expected.
+- **Production ready** -- the full stack is up, all integration points are verified, and the environment matches production configuration.
+
+When reporting status, be precise about which level of health you verified. If you only confirmed container state, say so.
+
+## Dependency Ordering
+
+Compose services often depend on each other. Verify startup order:
+
+1. **`depends_on` declarations** -- confirm they are present in the compose file for services that need them.
+2. **Healthcheck-based readiness** -- `depends_on` with `condition: service_healthy` ensures the dependency is ready, not just started. Prefer this over bare `depends_on`.
+3. **Startup order verification** -- after `docker compose up`, check logs to confirm services started in the correct order and downstream services did not fail due to missing upstream dependencies.
+4. **Retry behavior** -- if a service connects to a dependency on startup, verify it has retry logic or that the dependency was healthy before the service started.
+
+When dependency ordering issues cause failures, record the exact failure chain: which service failed, which dependency was not ready, and what error appeared.
+
+## Customization
+
+<!-- CUSTOMIZE: Override or extend any section above. Common additions:
+  - Compose file paths: <comma-separated-list>
+  - Service names: <comma-separated-list>
+  - Health check endpoints: <service> -> <url>
+  - Required environment variables per service
+  - Volume backup and restore procedures
+  - Network topology notes
+-->

package/skills/provider-docker-compose/adapters/local.md

@@ -0,0 +1 @@
+The local runtime may have Docker access for compose verification. Use `docker compose ps` and `docker compose logs` when available. If Docker is not running, limit output to compose file validation and service definition review. Do not claim container health from file inspection alone.