Contract discovery

To promote interoperability and enable user interfaces to build forms automatically, each interpreter SHOULD provide a way to discover its command schema and metadata. The discovery mechanism MAY be a dedicated command (for example, --describe), a separate binary (my‑interpreter-spec), or a static JSON file. The contract SHOULD include:

• A machine‑readable JSON Schema describing the structure of the Command payload, required fields, default values, data types, and allowed ranges.
• A set of human‑readable descriptions for each field.
• A declaration of idempotency for each command, if applicable.
• Indicators for which fields are sensitive and should be redacted by the Runner.
• Optionally, a dynamic form metadata descriptor conforming to a separate specification (outside the scope of this RFC). The metadata may include field ordering, grouping, select options, and dependencies.

Example discovery output for a hypothetical ping interpreter:

{
  "name": "ping-interpreter",
  "description": "Network latency and reachability test",
  "commands": {
    "default": {
      "schema": {
        "type": "object",
        "required": ["host"],
        "properties": {
          "host": {"type": "string", "description": "Target hostname or IP"},
          "count": {"type": "integer", "default": 1, "minimum": 1},
          "timeout": {"type": "integer", "default": 10},
          "packet_size": {"type": "integer", "default": 56},
          "interval": {"type": "integer", "default": 1},
          "ttl": {"type": "integer", "default": 64}
        }
      },
      "idempotent": true,
      "sensitive": []
    }
  }
}