Summary

Add a CI check that validates configuration files (e.g., openclaw.json, sandbox config, onboarding config) against a JSON Schema definition, catching structural errors before review.

Motivation

NemoClaw uses several configuration files that follow implicit schemas — field names, types, required keys, and valid values are enforced only at runtime or by reviewer knowledge. A schema-based validation check in CI catches typos, type mismatches, missing required fields, and unknown keys automatically. This is particularly valuable when community contributors modify config-related code or documentation examples.

Specification

Step 1: Define JSON Schemas for config files

Create JSON Schema files (e.g., in a schemas/ directory) that describe the expected structure of each configuration format used by NemoClaw. Start with the most commonly modified configs:

• openclaw.json — the main OpenClaw configuration
• Sandbox configuration — whatever structure nemoclaw onboard produces
• Any YAML/JSON config files that contributors frequently touch

Each schema should define:

• Required vs. optional fields
• Field types (string, number, boolean, array, object)
• Enum values where applicable (e.g., valid provider names, model identifiers)
• additionalProperties: false on objects where unknown keys indicate a mistake

Step 2: Validate config files in CI

Add a CI step that:

1. Finds configuration files in the repo (or in the PR diff).
2. Validates each against its corresponding JSON Schema.
3. Fails with a clear error if validation fails, showing the file, the failing field, and the expected type/value.

Step 3: Validate documentation examples

If README or docs files contain YAML/JSON code blocks that represent config examples, extract those blocks and validate them against the same schemas. This prevents documentation from drifting out of sync with the real config format.

Implementation notes

• For JSON validation: ajv-cli (npm) or Python's jsonschema library both work well.
• For YAML: parse to JSON first, then validate.
• Extracting code blocks from markdown can be done with a simple regex or a script that looks for fenced blocks tagged with json or yaml.
• Keep schemas in a schemas/ directory at the repo root so they are discoverable and can be referenced by editors (VS Code, for example, can use $schema for autocompletion).

Acceptance criteria

• At least one JSON Schema is defined for a core config file.
• CI validates config files against the schema on every PR.
• Validation errors show the file path, field path, and what was expected vs. found.
• Bonus: documentation config examples are also validated.