raxit
CLI

raxit test / validate

raxit test and raxit validate -- check policy behavior and syntax.

raxit test runs the tests: block in security.yaml against the compiled policy — behavior checks. raxit validate checks only that security.yaml parses and conforms to schema — a faster, stable-exit-code syntax gate for CI/editors. raxit check combines validation with import resolution.

raxit test

$ raxit test
ok  1 - calc is permitted
ok  2 - unknown_tool is denied (default-deny)

2/2 passed
$ echo $?
0

A failing case reports the actual vs. expected decision and exits non-zero:

$ raxit test
FAIL 1 - calc should be denied but rule says allow (intentional failure): got "permit", want "deny"

0/1 passed, 1 failed: calc should be denied but rule says allow (intentional failure)
raxit test: 1 test case(s) failed
$ echo $?
1

This is the same gate raxit apply runs as its own step 2 — a policy that fails its tests is never applied.

raxit validate

$ raxit validate
OK
$ echo $?
0

$ raxit validate --json
{
  "ok": true,
  "exit_code": 0,
  "diagnostics": []
}

Line-anchored error example

Given a security.yaml with an unterminated flow sequence appended:

tests:
    - name: unknown_tool is denied (default-deny)
      action: unknown_tool
      expect: deny
  - this is: [unterminated
$ raxit validate --source broken.yaml
broken.yaml:17:1: error: yaml syntax: yaml: line 17: did not find expected key
$ echo $?
1

$ raxit validate --source broken.yaml --json
{
  "ok": false,
  "exit_code": 1,
  "diagnostics": [
    {
      "file": "broken.yaml",
      "line": 17,
      "col": 1,
      "severity": "error",
      "message": "yaml syntax: yaml: line 17: did not find expected key",
      "hint": "fix the YAML indentation/structure",
      "stage": "syntax"
    }
  ]
}

Every diagnostic is anchored to a file:line:col, with a stage (syntax, schema, etc.) and a plain-English hint — designed to be pasted straight into an editor's problem panel.

raxit check

$ raxit check
OK

check validates security.yaml and additionally verifies that every import: entry resolves and compiles. Add --offline to skip network-dependent import resolution.

Flags

  • --source <path> — explicit security.yaml path (default .raxit/security.yaml).
  • --json — machine-readable output, same shape shown above.
  • --offline (validate, check) — skip network-dependent checks.

Gotchas

  • raxit validate exits with a stable per-stage exit code (0/1/2/3/4) so CI and editor integrations can branch on failure stage without parsing text — use --json if you need the structured diagnostic, not exit-code inference alone.
  • raxit test checks decisions against a compiled policy; raxit validate checks syntax and schema. A file can validate cleanly and still fail its tests, or vice versa is not possible — test requires a syntactically valid file to compile in the first place.

On this page