Lifecycle — DefenseClaw

Overview

Every Rego policy source goes through four lifecycle phases: resolve → load → compile → serve. The Go engine owns runtime evaluation; the Python CLI owns authoring helpers such as policy create, policy validate, policy test, and policy edit.

Resolve

internal/policy/engine.go::New accepts a policy directory. If that directory does not contain Rego modules but has a rego/ child, resolveRegoDir uses the child directory instead. This supports both layouts:

Load

The engine reads data.json into an in-memory OPA store and reads every *.rego module in the resolved directory. A bad data.json parse or unreadable policy directory fails load before the engine is returned.

Compile

internal/policy/engine.go::Compile parses every Rego module with OPA's AST parser and compiles the module set. It does not run Rego tests. Use Testing policies for the opa test path exposed by defenseclaw policy test.

The Python validation helper adds a lighter data check before compile:

defenseclaw policy validate --rego-dir policies/rego

Serve

Evaluation methods share the same compiled store:

The sidecar exposes dry-run policy routes such as POST /policy/evaluate and POST /policy/evaluate/firewall. It does not expose a versioned policy-status route in the current route table.

Reload command

defenseclaw-gateway policy reload

The gateway command tells the sidecar to call POST /policy/reload. See Hot reload for the request path and failure behavior.

Authoring lifecycle

1. Create or edit policy data with defenseclaw policy create or defenseclaw policy edit ....
2. Validate with defenseclaw policy validate.
3. Test with defenseclaw policy test.
4. Reload a running sidecar with defenseclaw-gateway policy reload.

Related

• Writing Rego
• data.json
• Hot reload
• policy CLI