Compatibility Surface

Use this page when a tool, CI gate, or wrapper needs the command surface ota intends to keep stable.

The goal here is not to memorize every command. It is to show which stable command families wrappers and integrations can safely depend on.

Use these when the question is whether a repo is valid, ready, or needs an ordered remediation path.

This is the stable surface for readiness gates, diagnosis wrappers, and support flows that need actionable findings instead of task execution.

ota validateota doctorota checkota diffota explain

Use these when the question is what can run, what ota would execute, and what ota would prepare before execution starts.

This is the stable surface for runtime wrappers, execution previews, receipts, and backend-aware automation.

ota workflowsota tasksota servicesota envota execution planota runota upota receiptota clean

Use these when the question is how contracts or policy packs are initialized, inferred, reviewed, compared, or governed.

This is the stable surface around authoring and org-policy workflows, not runtime execution itself.

ota initota detectota policyota policy initota policy reviewota agentsota skills installota extensionsota annotationsota completionota self-updateota upgrade

Use these when the integration boundary is the workspace instead of one repo at a time.

This is the stable surface for multi-repo readiness, execution, refresh, receipt, and drift orchestration.

ota workspace validateota workspace doctorota workspace checkota workspace explainota workspace tasksota workspace listota workspace execution planota workspace runota workspace upota workspace refreshota workspace statusota workspace receiptota workspace initota workspace detectota workspace diff

Depend on commands, exit behavior, JSON keys, and deterministic ordering, not prose.

Treat repo command names and subcommands as a stable wrapper surface, not as incidental copy.

Use this when the integration boundary is one repo and the wrapper depends on stable repo command names rather than prose wording.

ota validateota doctorota runota upota diffota explain

Treat workspace commands as their own stable orchestration surface instead of assuming they mirror repo commands loosely.

Use this when the integration boundary is the workspace itself and the wrapper depends on stable workspace command names instead of inferred repo symmetry.

ota workspace validateota workspace doctorota workspace runota workspace upota workspace receiptota workspace explain

Depend on JSON top-level shape and key meaning when automation consumes ota output.

Use JSON output as the machine contract even when human wording evolves, because prose can tighten while key meaning should stay stable.

Depend on stable ordering for list and receipt-style outputs so wrappers and reviewers see the same result.

Rely on deterministic ordering for inventory, workspace, and receipt views when downstream tools diff, cache, or annotate ota output.

• command availability and names
• exit behavior and JSON top-level shape
• key meaning for machine-readable output
• deterministic ordering for list outputs
• clear human status lines such as VALID, READY, or NOT READY

• a CI integration reads ota doctor --json
• a wrapper tool depends on the order of ota tasks
• a support team needs to know whether a new command output is a breaking change
• a maintainer wants to keep compatibility gates honest