feat: add ory validate opl

[alnr]

Adds ory validate opl --file ./my-permissions.ts, a thin command over the
RelationshipAPI.CheckOplSyntax SDK call that was already vendored but unused.
It replaces the raw curl workaround from the issue and exits non-zero on
syntax errors, so it can be used as a CI/CD check before ory update opl.

$ ory validate opl --file ./namespace_config.ts
The Ory Permission Language file is valid.

$ ory validate opl --file ./broken.ts
./broken.ts:1:36: expected 'permits' or 'related', got ""
$ echo $?
1

$ ory validate opl --file ./broken.ts --format json
{"errors":[{"end":{"Line":1,"column":36},"message":"expected 'permits' or 'related', got \"\"","start":{"Line":1,"column":36}}]}

Details:

• Errors are rendered compiler-style (<source>:<line>:<column>: <message>) on
  stderr for the human-readable formats, so editors and CI log parsers pick up
  the location. The machine-readable formats print the API result verbatim, with
  the errors key always present so that jq '.errors | length' works on the
  success path too.
• --file - reads from stdin, and errors are then reported against stdin.
• --quiet silences the success message but not the syntax errors.
• An empty file is reported as valid (the SDK refuses to send a zero-length
  body, and a whitespace-only file — semantically identical — is valid).

The syntax check endpoint lives on the project's own API
(<slug>.projects.oryapis.com) rather than the Console API, and there was no
SDK-client helper for that host, so this also adds
CommandHelper.NewProjectAPIClient.

Related Issue or Design Document

Closes ory/keto#1860.

Checklist

• I have read the contributing guidelines
  and signed the CLA.
• I have referenced an issue containing the design document if my change
  introduces a new feature.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got approval (please contact
  security@ory.com) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added the necessary documentation within the code base (if
  appropriate).

Further comments

The command is mounted under the existing ory validate parent (next to
validate identity) rather than as a new top-level ory check verb, as
suggested in the issue — validate already exists and carries the same
semantics.

🤖 Generated with Claude Code

https://claude.ai/code/session_012UL5u7KWLdu8hzNTNvYq5a

Summary by CodeRabbit

• New Features

  • Added validate opl to check project namespace configuration syntax.
  • Supports file input, standard input, quiet mode, and JSON output.
  • Reports syntax errors with clear source locations and machine-readable messages.
  • Added an API client for interacting with the selected project’s API.

• Tests

  • Added coverage for valid, invalid, empty, JSON, stdin, quiet, and project-selection scenarios.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a project-scoped SDK client and registers validate opl, which reads namespace configuration files or stdin, checks OPL syntax through the Project API, formats errors, and supports table, JSON, quiet, and human-readable output modes.

Changes

Namespace configuration validation

Layer / File(s)	Summary
Project-scoped API client cmd/cloudx/client/sdks.go	Adds an authenticated SDK client targeting the selected project’s <slug>.projects API endpoint.
OPL validation command cmd/cloudx/project/validate_namespace_config.go, cmd/cloudx/validate.go	Adds source loading, syntax checking, parse-error formatting, structured output, failure handling, and validate opl registration.
Validation command coverage cmd/cloudx/project/validate_namespace_config_test.go	Tests valid, invalid, empty, stdin, JSON, quiet, and project-selection flows.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CLI
  participant CommandHelper
  participant RelationshipAPI
  CLI->>CommandHelper: Create project API client
  CommandHelper->>RelationshipAPI: Configure selected project endpoint
  CLI->>RelationshipAPI: Check OPL syntax
  RelationshipAPI-->>CLI: Return parse errors
  CLI-->>CLI: Format output and set exit status

Loading

Possibly related PRs

• ory/cli#444: Modifies the shared project HTTP client construction used by the new project-scoped API client.

Suggested reviewers: zepatrik

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR implements the requested OPL syntax check command for CI/CD and replaces the curl workaround, satisfying issue #402.
Out of Scope Changes check	✅ Passed	The changes are focused on the new validate opl command, its SDK helper, tests, and command registration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title clearly identifies the main change: adding the ory validate opl command.
Description check	✅ Passed	The description explains the feature, links the related issue, documents behavior and examples, and completes the required checklist.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/402-validate-opl

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[alnr]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[zepatrik]

There is not really a point in making this a server call, as it is not dependent on any project config or other stuff. In fact, we want to remove the endpoint eventually. Ideally, this would run locally. The only problem with that is version drift between the server and the CLI, so it might pass the CI check but the server might still reject it as invalid. Do you have an idea how to solve this with local execution?

[alnr]

There is not really a point in making this a server call, as it is not dependent on any project config or other stuff. In fact, we want to remove the endpoint eventually. Ideally, this would run locally. The only problem with that is version drift between the server and the CLI, so it might pass the CI check but the server might still reject it as invalid. Do you have an idea how to solve this with local execution?

If you want to remove this endpoint in the future but keep the ability to validate OPL without also configuring Keto with that same OPL, version drift becomes a perpetual problem.

The are ways to deal with that of course (versioning etc) but fundamentally that would require providing reasonable compatibility guarantees for OPL.

I am not opposed to that, but at that point ory/keto#1860 becomes a Keto problem.

In fact, what I think I will do is move ory/keto#1860 into ory/keto to find a design there, whether client- oder server-side. When the subcommand in keto exists, we'll import it in ory/cli.