OpenTofu vs Crossplane

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   OpenTofu—none0/10

   A direct probe of https://opentofu.org/llms.txt returned HTTP 404, and no other evidence pack items reference an llms.txt file or agent-oriented documentation format; the docs are standard human-facing pages only.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”

   proof ↗⚑ flag

   Crossplane—none0/10

   No evidence of an llms.txt file, agent-oriented documentation format, or any mention of AI-agent-consumable docs; docs-16 mentions AI systems acting on APIs but does not describe agent-oriented documentation discovery. missing for 10: llms.txt file or equivalent, agent-facing documentation format, any explicit reference to AI agents consuming docs directly.

   ⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to OpenTofu
   OpenTofu✓fullprobed9/10

   Hands-on probes confirm OpenTofu supports non-interactive, scriptable CI workflows: `-input=false`, `-auto-approve`, `-detailed-exitcode` for change detection, machine-readable JSON plan output via `tofu show -json`, and a full plan→apply→destroy loop with correct exit codes, all installable without a login/keys via brew — exactly what CI/agent automation needs. Missing for 10: no explicit vendor CI/CD integration guide (e.g., GitHub Actions/GitLab CI docs) or third-party CI pipeline examples in the evidence pack.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

   Crossplane~partialprobed6/10

   Crossplane is fundamentally a Kubernetes control-plane operator: everything is driven by declarative YAML/CRDs reconciled by controllers, which is inherently automatable via kubectl/GitOps pipelines (ArgoCD/Flux) as community evidence confirms, and the CLI itself is keyless and scriptable. However the probe shows every real operation requires a live Kubernetes cluster with Crossplane installed — there's no standalone local plan/apply loop like other CLI-first tools, meaning 'headless CI' usage requires provisioning/maintaining a cluster as a CI dependency rather than a lightweight headless binary. missing for 10: evidence of a documented CI-specific workflow/example (e.g. official GitHub Action or CI recipe), confirmation of non-interactive apply without cluster bootstrap overhead, and independent hands-on reports of running Crossplane in CI pipelines.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [community] “Many folks are using GitOps with Flux/ArgoCD to deploy their k8s apps but they can't use Terraform in the same workflow. How does Crossplane…”
   • [community] “Terraform offers small teams a common language for controlling their infrastructure...Crossplane appears to have a clear yaml syntax (easy e…”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to OpenTofu
   OpenTofu✓fullprobed9/10

   OpenTofu ships an official, documented CLI (opentofu.org/docs/cli/) and hands-on probes confirm a full headless workflow — init, plan with machine-readable JSON output, auto-approved apply, and destroy — all scriptable without interactive input, which is exactly what an AI-native/agentic caller needs. It is also a drop-in Terraform replacement, so existing agent tooling built for Terraform's CLI works unchanged. missing for 10: no first-party documentation specifically addressing AI-agent usage patterns or guardrails (e.g., rate limits, agent-specific auth flows) beyond generic CLI/JSON support.

   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

   Crossplane~partialprobed6/10

   Crossplane ships an official CLI (docs and hands-on probe confirm install via brew and working `crossplane version --client`) supporting building/testing/rendering Compositions and managing packages, but it is not framed or evidenced as an AI-native/agentic interface (no MCP integration, no agent-friendly output modes, no natural-language or automation-specific tooling beyond generic CLI usage). missing for 10: explicit AI-native design/marketing for the CLI itself, evidence of agent-friendly structured output or automation hooks, and independent corroboration beyond one hands-on probe.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”
   • [claimed-docs] “building, installing, updating and pushing Crossplane Packages”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to Crossplane
   OpenTofu~partialprobed5/10

   OpenTofu is drivable programmatically via its CLI (headless plan/apply/destroy loop, machine-readable JSON plan output) as confirmed by hands-on probes, which supports AI-native agentic automation, but there is no documented public HTTP/REST/OpenAPI API — probes for llms.txt, docs-md, and openapi/swagger endpoints all 404. missing for 10: a documented public API (REST/OpenAPI/SDK) beyond the CLI, official llms.txt or machine-readable docs endpoint, and any first-party API reference for programmatic/agentic access.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

   Crossplane✓fullprobed7/10

   Crossplane explicitly documents that it exposes 'declarative APIs that humans, automation, and AI systems can safely act on' (docs-16), and its architecture is built on the Kubernetes API server extended via CRDs/Managed Resources (docs-3, docs-13, docs-20, docs-21), which forms a standard, machine-readable, documented API surface. This is reinforced by an official CLI (probe-1, probe-2) for interacting with the control plane programmatically. missing for 10: independent/hands-on evidence of an AI agent actually driving Crossplane via the API, and more detail on API schemas/authentication for agentic use beyond marketing copy.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “It lets you design the APIs and abstractions that your users use to interact with your control planes.”
   • [claimed-docs] “there’s an RDS instance MR that extends Kubernetes with the ability to manage AWS RDS instances.”
   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round drawn
   OpenTofu—none0/10

   The evidence pack shows only CLI usage, JSON plan output, and website docs; there is no mention of any official SDK (Go, Python, REST, or agent-oriented) that AI-native developers could build against, and probes explicitly show llms.txt, docs-md, and OpenAPI endpoints returning 404. Missing for 10: any documented official SDK, API/OpenAPI spec, or programmatic library for AI agents to integrate with OpenTofu beyond the CLI.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

   Crossplane—none0/10

   Evidence describes Crossplane's function pipeline supporting multiple languages (YAML, KCL, Python, Go) and declarative APIs that 'AI systems can safely act on,' but there is no mention of an official SDK (e.g., function-sdk-go/python) or any AI-native developer tooling for building against Crossplane programmatically.

   ⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Crossplane
   OpenTofu~partialprobed4/10

   OpenTofu's CLI is fully non-interactive/keyless and scriptable (headless plan→apply→destroy verified in probes), which is a prerequisite for wiring it into cron jobs or CI/CD pipelines for autonomous runs, but there is no evidence of any built-in scheduler, trigger, webhook, or agent runtime that autonomously initiates or manages background runs on its own. missing for 10: native scheduling/trigger mechanism, evidence of autonomous (not just headless) background operation, first-party automation/orchestration features beyond CLI scriptability.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane~partialclaimed5/10

   Crossplane's control plane continuously reconciles desired state and self-corrects drift autonomously (crossplane-docs-18), and its declarative APIs are explicitly framed as actionable by automation/AI systems (crossplane-docs-16), which supports background autonomous operation of infrastructure. However, there is no evidence of AI-native 'automations' or agentic workflows being set up specifically for AI systems, scheduled/triggered agent tasks, or any AI-specific orchestration features beyond generic drift-correction and declarative reconciliation. missing for 10: explicit AI-agent-triggered automation examples, scheduling/triggers for autonomous AI tasks, evidence of AI systems actually driving Crossplane resources end-to-end, independent hands-on validation of autonomous background operation.

   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “extending its battle hardened reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just c…”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   OpenTofu—none0/10

   OpenTofu's interface is HCL configuration plus a fixed CLI command set (plan, apply, test, import, etc.); nothing in the evidence pack shows any natural-language command interface, NL parsing, or AI-native control surface — llms.txt and other AI-discovery probes even returned 404s.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane's interface is entirely declarative YAML/Compositions plus a CLI for build/test/push workflows; the closest hit is marketing copy saying APIs can be 'acted on' by AI systems, but that describes external consumers, not natural-language command input into Crossplane itself. No documentation, CLI feature, or probe shows any natural-language command interface. Missing for 10: any NL command parser, chat/agent interface, or evidence of accepting free-text instructions instead of declarative manifests.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “With Crossplane you don’t have to write a controller. Instead you configure a pipeline of functions.”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   OpenTofu—none0/10

   OpenTofu's docs are static CLI command references (plan/apply/test/import) with no interactive API explorer or runnable-example sandbox; explicit probes confirm no OpenAPI/swagger spec and no llms.txt discoverability aid.

   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”

   proof ↗⚑ flag

   Crossplane—none0/10

   No evidence of an interactive API reference with runnable examples exists in the pack; documentation is described only as static pages and CLI docs, with no mention of a live/interactive reference or embedded runnable code snippets.

   ⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   OpenTofu—none0/10

   Explicit probes confirm no OpenAPI/Swagger spec or llms.txt is available (404s at all candidate paths), and no evidence of any machine-readable API spec being offered.

   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://opentofu.org/docs/.md”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane's CRD-based schemas (crossplane-docs-13) imply an OpenAPI-compatible structure inherent to Kubernetes, but the evidence pack contains no explicit documentation or feature describing a downloadable OpenAPI or machine-readable API spec for Crossplane's Composite Resources or Providers. Missing for 10: explicit docs on exporting/downloading OpenAPI schema, CLI or API endpoint for spec retrieval, and any community/hands-on confirmation of this capability.

   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to OpenTofu
   OpenTofu~partialprobed5/10

   OpenTofu's `tofu test` command explicitly creates real infrastructure to test configuration and then destroys it, and workspaces/variables allow separate dev/staging/prod environments (multi-environment support mentioned in docs), which supports sandbox-style testing without touching production if configured with separate state/backends. However, there is no dedicated built-in sandboxing feature, no first-party guidance on isolating a sandbox from production data specifically, and no mocking/dry-run-only testing mode beyond plan preview. missing for 10: dedicated sandbox/mock-infrastructure feature, explicit doc guidance on isolating prod vs sandbox state, independent verification of test-command safety in practice.

   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”

   proof ↗⚑ flag

   Crossplane~partialprobed4/10

   Crossplane's CLI supports rendering/testing Composition Functions locally without needing a live Kubernetes cluster (crossplane-docs-7), which enables some local, production-safe testing. However, a probe shows that real plan/apply operations still require a running Kubernetes cluster with Crossplane installed, with no built-in local sandbox/preview loop for full resource provisioning — so isolating test workloads from production relies on the user provisioning a separate cluster/cloud account rather than a first-class sandbox feature. missing for 10: dedicated sandbox-mode or dry-run against real cloud providers, evidence of safe multi-tenant test isolation, and confirmation that render-only testing covers full MR/Composition behavior rather than just function outputs.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   OpenTofu—none0/10

   The evidence pack shows OpenTofu has versioned CLI output formats (e.g., plan JSON format_version) but contains no documentation of a formal API/CLI deprecation policy or version-support guarantees; the axis is applicable to an IaC tool with a CLI/JSON interface, but no evidence supports a documented deprecation policy. Missing for 10: explicit deprecation policy docs, versioning/SLA guarantees, changelog of breaking changes.

   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “official CLI documented at https://opentofu.org/docs/cli/”

   proof ↗⚑ flag

   Crossplane—none0/10

   While Crossplane exposes CRD-based APIs and has a 'Composition Revisions' feature for managing changes, the evidence pack contains no documentation of a formal API versioning scheme or deprecation policy for its own APIs (e.g., CRD version graduation, deprecation timelines, migration guides). Missing for 10: explicit deprecation policy docs, CRD version stability guarantees, migration/upgrade guidance for deprecated APIs.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to OpenTofu
   OpenTofu~partialclaimed6/10

   OpenTofu supports bulk-style operations via resource graph parallelization, for_each-driven dynamic provider/module generation, -exclude flag for scoping bulk plan/apply, and programmatic module version updates across many modules, which together enable acting on many items at once. However this is infrastructure-as-code bulk management, not an AI-native batch/agent API, and there's no evidence of a dedicated bulk API, batch job orchestration, or AI-specific tooling for mass operations. missing for 10: dedicated bulk/batch API or agent-facing interface for large-scale multi-item operations, independent hands-on evidence of bulk operations at scale, AI-native tooling specifically for orchestrating many items programmatically.

   • [github] “OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “Selectively exclude resources from operations with the -exclude flag. This provides more control during testing and rollouts, allowing you t…”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability.”
   • [claimed-docs] “Update all your modules programmatically with a single variable change. Never miss updating a module version by accident - keep your infrast…”
   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence describes Crossplane's declarative APIs, Compositions, and controller-based reconciliation, but nothing in the pack documents or demonstrates bulk/batch operations across many resources at once (e.g., batch apply, multi-resource templating at scale, or AI-driven bulk actions).

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Crossplane
   OpenTofu—none0/10

   OpenTofu's evidence pack covers CLI plan/apply/test/import workflows but shows no rule-based or event-triggered automation engine (e.g., webhooks, event listeners, policy-triggered actions) built into the tool itself.

   ⚑ flag

   Crossplane~partialclaimed6/10

   Crossplane's control-plane model is inherently reactive: it continuously watches Kubernetes resource state and automatically corrects drift, and its composition function pipelines process changes to composite resources as they occur, which functions as an implicit event-driven automation model. However, there is no evidence of an explicit rule-authoring interface (e.g., 'on event X do Y' triggers, webhooks, custom event sources) — the automation is confined to declarative reconciliation loops built into the resource model. Missing for 10: explicit event-trigger/rule definition mechanism beyond drift reconciliation, documentation of custom event sources or conditional trigger logic, and independent confirmation of this automation depth.

   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [claimed-docs] “With Crossplane you don’t have to write a controller. Instead you configure a pipeline of functions.”
   • [claimed-docs] “There’s already a Crossplane managed resource for that.”
   • [claimed-docs] “Functions - Functions extend Crossplane with new ways to configure composition”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Crossplane
   OpenTofu~partialprobed5/10

   OpenTofu's state is plain text-based (HCL) which enables version control via git, and plan files (tofu plan -out) provide a preview/review mechanism, with tofu destroy/apply providing rollback-like operations, but there's no native built-in versioning, review workflow, or rollback/history feature beyond what git or external tools (e.g. Terraform Cloud-like state history) provide. missing for 10: no first-party state history/rollback mechanism, no built-in review/approval workflow beyond plan output, no independent evidence of an audit trail or diff-based rollback UI.

   • [claimed-docs] “Version control your infrastructure with OpenTofu. Track changes, collaborate with your team, and deploy DNS configurations with a single co…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane~partialcommunity6/10

   Crossplane's Composition Revisions explicitly let you manage and track changes to Compositions, and its YAML-based Kubernetes resources are naturally committed to source control and managed via GitOps, as community members note ('clear yaml syntax... easy enough to commit to source control'). Drift correction also provides a form of automatic rollback to desired state. missing for 10: explicit documentation of a review/approval workflow (e.g., PR-gated promotion), and a clear step-by-step rollback procedure using Composition Revisions rather than just their existence.

   • [claimed-docs] “Composition Revisions - Manage changes to Compositions with revisions”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [community] “Terraform offers small teams a common language for controlling their infrastructure...Crossplane appears to have a clear yaml syntax (easy e…”
   • [community] “Many folks are using GitOps with Flux/ArgoCD to deploy their k8s apps but they can't use Terraform in the same workflow. How does Crossplane…”

   proof ↗⚑ flag

Import

1. platform-engineerImport existing cloud resources under management and generate matching configuration code

   weight 3 · round to OpenTofu
   OpenTofu~partialcommunity6/10

   OpenTofu documents `tofu import` for importing existing resources into state, and community evidence confirms `for_each` support for import blocks (bulk import). However, evidence does not show automatic configuration-code generation from imported resources (e.g., a `-generate-config-out` style feature) — missing for 10: documentation/proof of automatic config generation during import, hands-on demonstration of the full import-to-config workflow, and independent verification of accuracy for generated code.

   • [claimed-docs] “The `tofu import` command imports existing resources into OpenTofu.”
   • [community] “"for_each" implementation for "import" blocks... Well, I'm officially on board with this project. We've been told this is impossible for yea…”

   proof ↗⚑ flag

   Crossplane—none0/10

   No evidence in the pack shows a Crossplane feature for importing existing/unmanaged cloud resources or auto-generating matching Composition/Claim YAML; the docs cover installation, packages, and compositions but nothing about resource discovery or import tooling. missing for 10: an import/adopt command or workflow, generated MR/Composition code from existing infra, any docs or community reports of migrating pre-existing resources into Crossplane management.

   ⚑ flag

Migration

1. platform-engineerMigrate an existing Terraform-format codebase and its state into this tool

   weight 2 · round to OpenTofu
   OpenTofu✓fullprobed7/10

   OpenTofu explicitly positions itself as a drop-in, backwards-compatible replacement for Terraform, and community reports (including real client migrations and "s/terraform/opentofu/g") corroborate that existing Terraform configs and state can be migrated with minimal effort; hands-on probes confirm the CLI runs standard Terraform-style plan/apply/destroy workflows without modification. Missing for 10: an explicit first-party migration guide or documented state-file conversion/validation step (beyond general 'drop-in' claims), and independent verification of state-file compatibility across complex/large codebases.

   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”
   • [community] “The move towards OpenTofu is going to be a slow tide, but it is coming. It's an easy migration... We made the jump for one client, started a…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane—none0/10

   No evidence of any Terraform-state import, HCL conversion, or migration tooling in Crossplane's docs, CLI, or community discussion; Crossplane uses an entirely different declarative Kubernetes-native model with no documented path to ingest existing Terraform codebases or state files.

   ⚑ flag

Licensing

1. devops-leadRely on an open license and open governance so the tool cannot be relicensed out from under my company

   weight 3 · round to OpenTofu
   OpenTofu✓fullcommunity7/10

   OpenTofu explicitly ties its open-source guarantee to being hosted under the Linux Foundation, a neutral governance body designed to prevent unilateral relicensing — directly addressing the devops-lead's concern. Community commentary raises cultural/governance grumbles but no concrete evidence of relicensing risk or license violation, so this doesn't rise to a dispute. missing for 10: explicit license text/name (e.g., MPL 2.0) in evidence, details on governance structure (TSC, contribution/veto rules), and independent third-party corroboration of the Linux Foundation guarantee.

   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [community] “It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think i…”
   • [community] “So far it appears to be the same old thing with a different owner. Maintainers act like they own the thing and everyone else (read: the user…”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence pack contains no mention of Crossplane's license (e.g., Apache 2.0) or its governance model (e.g., CNCF graduation, foundation stewardship) — nothing here addresses licensing-governance at all. missing for 10: license identification, governance/foundation structure, any statement on relicensing protection.

   ⚑ flag

Stability

1. developerRely on documented compatibility promises and upgrade guides between releases

   weight 2 · round to OpenTofu
   OpenTofu~partialcommunity5/10

   OpenTofu publicly commits to backwards compatibility and positions itself as a drop-in replacement for Terraform, preserving existing configs/workflows, which implies a compatibility promise, but the evidence pack contains no explicit version-to-version upgrade guide documentation for OpenTofu releases themselves, and one community comment notes OpenTofu is 'already diverging from upstream,' raising uncertainty about long-term compatibility guarantees. missing for 10: dedicated upgrade-guide docs between OpenTofu minor/major releases, changelog/breaking-change policy evidence, independent confirmation of smooth upgrades across OpenTofu versions.

   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [community] “OpenTofu is already diverging from upstream but is relying on upstream providers so I'm not sure how to feel about it.”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence pack shows install/config docs, feature flags, and package management, but contains no explicit compatibility promises (e.g., API versioning policy) or dedicated upgrade/migration guides between Crossplane releases. This axis clearly applies to a platform like Crossplane, but no supporting evidence is present.

   ⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round to OpenTofu
   OpenTofu~partialprobed6/10

   OpenTofu's state and plan files are plain JSON/HCL (confirmed by the probed `tofu show -json` machine-readable output) and the project is governed as 'truly open source' under the Linux Foundation, meaning there is no proprietary lock-in and configs/state can be freely moved or forked. However, there is no explicit documentation of a dedicated 'export and leave' workflow, no discussion of migrating state to other tools, and no llms.txt/data-export interface (llms.txt 404, no OpenAPI) that would make this openness explicit for AI-native tooling. missing for 10: explicit data-export/portability docs, llms.txt or machine-readable manifest, third-party confirmation of migrating state out of OpenTofu.

   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://opentofu.org/llms.txt”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”

   proof ↗⚑ flag

   Crossplane~partialclaimed5/10

   Crossplane's resources (Compositions, Configurations, Managed Resources) are defined as plain YAML/KCL/etc. stored in Kubernetes, which is inherently portable and inspectable, and packages are designed to be portable across clusters (crossplane-docs-11, crossplane-docs-2). However there is no explicit documented 'export all data' feature or bulk-export/migration tool, and no evidence addressing exporting live state or leaving the platform cleanly. missing for 10: explicit data-export/backup tooling, documentation of exporting full state (not just config) in open formats, and any evidence of migration/exit workflow.

   • [claimed-docs] “Functions allow you to write your configuration in multiple languages, including YAML, KCL, Python, and Go.”
   • [claimed-docs] “Configurations - Portable packages of Crossplane resources”
   • [claimed-docs] “Composite Resource Definitions - Define schemas for composite resources”
   • [claimed-docs] “Composition Revisions - Manage changes to Compositions with revisions”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to OpenTofu
   OpenTofu✓fullcommunity8/10

   OpenTofu's source is publicly hosted on GitHub (opentofu-gh-1) and the manifesto explicitly commits to remaining 'Truly open source' now under the Linux Foundation (opentofu-docs-26); community discussion confirms the license is readily found in the GitHub repo even if not prominent on the marketing site (opentofu-comm-3). Missing for 10: explicit citation of the license text/name (e.g., MPL 2.0) and independent legal/audit confirmation beyond community mention.

   • [github] “OpenTofu builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources.”
   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [community] “It seems the license info is not readily available on the website. I can easily find it in the GitHub repo but not on the website. I think i…”

   proof ↗⚑ flag

   Crossplane—none0/10

   No evidence pack item mentions Crossplane's source code license, GitHub repository, or open-source licensing terms (e.g., Apache 2.0) — the pack covers only product docs, community discussion, and CLI probes. Missing for 10: license file/declaration, repository link, any statement about open-source status or license type.

   ⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Crossplane
   OpenTofu✓fullprobed8/10

   OpenTofu is fully open-source (Linux Foundation governed), can be installed and run entirely on one's own infrastructure via multiple install methods, and probes confirm a fully local, keyless CLI workflow (init/plan/apply/destroy) with no SaaS dependency — this is inherently self-hostable since it's just a binary operating on local/backend state. missing for 10: no explicit vendor documentation section titled 'self-hosting' or dedicated guide addressing enterprise/air-gapped self-hosted deployment scenarios, and no independent hands-on report specifically validating self-hosted production use at scale.

   • [claimed-docs] “You can install OpenTofu via a wide range of methods. Please select your operating system and installation method”
   • [claimed-docs] “Now that we are part of the Linux Foundation, we can guarantee that OpenTofu will remain: Truly open source”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “Backwards-compatible - so that the existing code can drive value for years to come”

   proof ↗⚑ flag

   Crossplane✓fullprobed9/10

   Crossplane is an open-source Kubernetes control-plane extension that users install and run themselves via Helm on their own cluster, with full control over feature flags, package installation, and versions (docs-4, docs-5, docs-6, docs-19, docs-22, docs-25). The probe confirms hands-on that the CLI and control plane operate entirely against a self-managed Kubernetes cluster with no forced SaaS dependency (probe-2). Missing for 10: no explicit vendor statement contrasting self-hosting vs. any managed offering, and no independent write-up specifically about self-hosting experience at scale.

   • [claimed-docs] “Install Crossplane using the Helm chart.”
   • [claimed-docs] “Enable support for real time compositions.”
   • [claimed-docs] “Enable automatic protection of Providers from deletion when they have active managed resources.”
   • [claimed-docs] “Crossplane introduces new features behind feature flags. By default alpha features are off.”
   • [claimed-docs] “Installing Crossplane enables the installation of Crossplane Provider, Function, and Configuration resources.”
   • [claimed-docs] “Install pre-release versions of Crossplane from the master Crossplane Helm channel.”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

Agent plan parsing

1. ai-native userGet machine-readable plan output (JSON) that an agent can parse to reason about a proposed change

   weight 3 · round to OpenTofu
   OpenTofu✓fullprobed9/10

   Hands-on probe confirms `tofu show -json plan.out` emits machine-readable plan JSON (format_version 1.2) with planned_values, parseable by agent tooling, alongside documented plan/apply CLI workflow supporting `-out=FILE` for later JSON conversion. missing for 10: no independent third-party corroboration beyond the single probe run.

   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane's model is continuous reconciliation (drift correction) rather than a discrete plan/apply workflow, and the probe evidence explicitly states no local plan/preview loop exists — every operation requires a live cluster. There is no documented JSON plan output or diff artifact an agent could parse.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”

   proof ↗⚑ flag

Ai infra ops

1. ai-native userHave an agent author an infrastructure change, run a plan headlessly, and present the diff for my approval

   weight 3 · round to OpenTofu
   OpenTofu✓fullprobed8/10

   Hands-on probes confirm a full headless plan→apply loop: `tofu plan -detailed-exitcode -out=plan.out` runs non-interactively and signals changes, `tofu show -json` emits machine-readable diff output parseable by agent tooling, and `tofu apply plan.out` executes the saved plan for approval-gated apply. This directly matches the story of an agent authoring changes, planning headlessly, and presenting a diff for approval. missing for 10: no first-party agent/CI orchestration example or official docs showing an approval-gate workflow built around the JSON plan output, and no independent (non-vendor) corroboration beyond the probe run.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”

   proof ↗⚑ flag

   Crossplane~partialprobed4/10

   Crossplane's CLI supports rendering/testing Compositions standalone (crossplane-docs-7) which could let an agent preview a change, but the probe explicitly found no headless local plan/preview loop — every real plan/apply requires a live Kubernetes cluster with Crossplane installed (crossplane-probe-2), unlike Terraform-style plan/diff tools. There's no documented diff-and-approve workflow tailored for agent-authored changes. missing for 10: a genuine headless 'plan' command producing a diff against live state, documented agent/approval integration, evidence of an AI agent actually driving this workflow end-to-end.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”

   proof ↗⚑ flag

Automation api

1. developerDrive deployments programmatically from my own application code rather than only through the CLI

   weight 2 · round to Crossplane
   OpenTofu—none0/10

   All evidence describes CLI commands (`tofu plan`, `apply`, `show -json`) and JSON output that can be parsed by external scripts, but there is no official SDK, Go library, or API for embedding OpenTofu operations directly in application code, and probes explicitly show no OpenAPI/API endpoints exist. This means programmatic control still requires shelling out to the CLI rather than a first-class application-integration path.

   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://opentofu.org/openapi.json, https://opentofu.org/swagger.json, https://opentofu.org/api/opena…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”

   proof ↗⚑ flag

   Crossplane~partialprobed5/10

   Crossplane exposes Kubernetes-native declarative APIs and explicitly markets itself as something 'humans, automation, and AI systems can safely act on', implying resources can be created/managed programmatically (e.g., via the Kubernetes API) rather than only via CLI. However, the evidence pack never documents an SDK, client library, or concrete example of driving Crossplane from application code — it only shows CLI tooling and YAML-based composition, and the probe confirms all real plan/apply operations require a running cluster with no programmatic preview path shown. missing for 10: explicit SDK/client-library documentation, a hands-on example of application code creating/managing Crossplane resources, and confirmation that this workflow is idiomatic (not just theoretically possible via raw Kubernetes API).

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “It lets you design the APIs and abstractions that your users use to interact with your control planes.”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “Installing Crossplane enables the installation of Crossplane Provider, Function, and Configuration resources.”

   proof ↗⚑ flag

Plan workflow

1. developerTear down an entire environment cleanly with a destroy operation

   weight 2 · round to OpenTofu
   OpenTofu✓fullprobed9/10

   OpenTofu docs explicitly describe destroy-mode planning that removes all remote objects leaving an empty state, and a hands-on probe confirms a full plan→apply→destroy loop exiting cleanly (exit 0). This directly matches the story of tearing down an environment cleanly. Missing for 10: independent (non-probe) third-party confirmation of destroy behavior at scale or with complex multi-resource environments.

   • [claimed-docs] “Destroy mode: creates a plan whose goal is to destroy all remote objects that currently exist, leaving an empty OpenTofu state.”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence pack never documents a destroy/teardown operation or workflow for Crossplane; it covers install, packages, functions, and drift-correction, but the only deletion-related item (crossplane-docs-6) is about *protecting* providers from deletion, not enabling clean teardown. No CLI or docs evidence shows a 'crossplane destroy' or cascading delete guarantee for an environment. Missing for 10: any documentation of a destroy/delete command, cascading resource cleanup behavior, or a described teardown workflow.

   • [claimed-docs] “Enable automatic protection of Providers from deletion when they have active managed resources.”
   • [claimed-docs] “building, installing, updating and pushing Crossplane Packages”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

2. devops-leadRun plan and apply non-interactively in CI using saved plan artifacts and approval flags

   weight 3 · round to OpenTofu
   OpenTofu✓fullprobed9/10

   Docs describe saving plans with `-out=FILE` and applying them via `tofu apply plan.out`, and hands-on probes confirm a full non-interactive plan→apply→destroy loop using `-input=false -auto-approve -detailed-exitcode`, matching the CI approval-flag workflow described in the story. missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions/GitLab CI snippets) showing artifact upload/download between plan and apply stages.

   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane operates as a continuously-reconciling Kubernetes control plane rather than a plan/apply tool with saved plan artifacts and approval gates; the evidence pack contains no documentation of a CI-oriented plan/apply/approve workflow. The hands-on probe explicitly notes that unlike Terraform-style tools, 'every real plan/apply operation requires a running Kubernetes cluster... no local plan/preview loop exists,' confirming the absence of this capability.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”

   proof ↗⚑ flag

3. platform-engineerPreview exactly what will change — creates, updates, and destroys — before applying

   weight 3 · round to OpenTofu
   OpenTofu✓fullprobed9/10

   OpenTofu's tofu plan command is explicitly documented to preview creates, updates, and destroys before applying, with dedicated destroy and refresh-only modes, and this was independently verified via a hands-on probe showing a real plan proposing a create, saved to a file, and later applied and destroyed successfully. Machine-readable plan JSON output further supports precise change previewing. missing for 10: independent third-party review of plan accuracy on complex multi-resource updates beyond the single-resource probe

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “Destroy mode: creates a plan whose goal is to destroy all remote objects that currently exist, leaving an empty OpenTofu state.”
   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane operates on a continuous-reconciliation model rather than an explicit plan/apply diff workflow; the CLI's `render` command only tests Composition Function output offline, and probe evidence explicitly states no local plan/preview loop exists — every real change requires a live cluster with the control plane reconciling live, not previewing creates/updates/destroys beforehand. missing for 10: any documented `crossplane plan`/diff command showing pending creates/updates/deletes, first-party guidance on previewing resource changes before applying, and independent confirmation of such a preview workflow.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”

   proof ↗⚑ flag

4. platform-engineerTarget or exclude specific resources in a plan or apply

   weight 1 · round to OpenTofu
   OpenTofu✓fullprobed8/10

   OpenTofu explicitly documents the -exclude flag for excluding resources from operations, and -target flag support is implied by drop-in Terraform compatibility plus verified hands-on plan/apply workflows. missing for 10: explicit docs/example for the -target flag itself and independent community confirmation of targeted apply usage.

   • [claimed-docs] “Selectively exclude resources from operations with the -exclude flag. This provides more control during testing and rollouts, allowing you t…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane's docs describe compositions, functions, and CLI rendering/troubleshooting, but nothing in the evidence shows a mechanism to target or exclude specific resources during a plan/apply-like operation; the probe explicitly notes there is no local plan/preview loop at all, only continuous reconciliation via a running cluster. missing for 10: any documented `--target`/`--exclude` style flag or resource-selection mechanism for plan or apply operations.

   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”
   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”

   proof ↗⚑ flag

Ai infra ops

1. ai-native userLet an agent plan and apply with least-privilege credentials and review gates so it cannot make unapproved changes

   weight 2 · round drawn
   OpenTofu~partialprobed4/10

   OpenTofu's plan/apply separation (saved plan files, machine-readable JSON output via `tofu show -json`, and exit codes) gives an agent a natural review gate where a human or policy layer can inspect a plan before `apply` executes it, as shown in probes -5/-6/-7 and docs-3/-4/-21. However, there is no evidence of built-in least-privilege credential scoping, RBAC, approval workflows, or a policy-as-code engine (Sentinel/OPA equivalent) enforcing that gate — the review step is only possible via external tooling, not something OpenTofu itself provides. Missing for 10: native policy-as-code/policy enforcement, credential scoping/RBAC features, and any documented approval-gate mechanism tied to identity or role.

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [claimed-docs] “developers can use speculative plans to verify the effect of their changes before submitting them for code review”
   • [claimed-docs] “You can use the optional `-out=FILE` option to save the generated plan to a file on disk, which you can later execute by passing the file to…”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”
   • [probe] “PROBE cli-apply (local run): `tofu apply -input=false -auto-approve plan.out` exited 0 ("Apply complete! Resources: 1 added") and `tofu dest…”

   proof ↗⚑ flag

   Crossplane~partialcommunity4/10

   Crossplane's RBAC-based control plane and 'developer only given permission to perform operations at the interface' model (comm-8, docs-17) support a least-privilege foundation, and its declarative API design is explicitly pitched as safe for AI systems to act on (docs-16), but there is no documented mechanism for agent-specific credential scoping, plan/approval review gates, or blocking unapproved applies before they take effect. missing for 10: explicit approval/review-gate workflow for AI-driven changes, agent-scoped least-privilege credential issuance, evidence of a 'plan preview' step analogous to Terraform plan, and independent validation that unauthorized changes are actually blocked.

   • [claimed-docs] “Expose declarative APIs that humans, automation, and AI systems can safely act on”
   • [claimed-docs] “extending its battle hardened reliability and security features like Role Based Access Control (RBAC) to orchestrate everything - not just c…”
   • [community] “Terraform (and cloud provider APIs) are not built for developer self-service...Crossplane flips this model by instead saying that the develo…”

   proof ↗⚑ flag

Policy

1. devops-leadEnforce policy-as-code checks that block non-compliant infrastructure changes before apply

   weight 3 · round drawn
   OpenTofu—none0/10

   The evidence pack shows OpenTofu's plan workflow and machine-readable plan JSON output (e.g., opentofu-probe-5, opentofu-probe-6) which could theoretically feed external policy engines, but there is no mention of any built-in or integrated policy-as-code framework (e.g., Sentinel, OPA/Conftest, Checkov) or documented workflow for blocking non-compliant applies. Missing for 10: any policy-as-code engine or gating mechanism, documentation of policy enforcement in CI/CD, and evidence that non-compliant plans are actually blocked before apply.

   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence pack describes Crossplane's control-plane architecture, RBAC, packages, and CLI tooling, but contains no mention of a policy-as-code engine (e.g., OPA/Gatekeeper/Kyverno integration, admission webhooks, or built-in policy checks) that blocks non-compliant infrastructure changes before apply. RBAC is referenced only as an access-control feature, not as a compliance gate.

   ⚑ flag

Languages

1. developerDefine infrastructure in a general-purpose programming language with types, loops, and IDE support

   weight 2 · round to Crossplane
   OpenTofu—none0/10

   OpenTofu's evidence pack only shows HCL-based declarative configuration (for_each loops, dynamic provider blocks) rather than a general-purpose programming language with types and IDE support; there is no mention of a CDK-like SDK (e.g., TypeScript/Python bindings) that would satisfy this story.

   ⚑ flag

   Crossplane~partialclaimed4/10

   Crossplane's core resource model (Compositions, XRDs) is YAML/CRD-based, but its Functions pipeline explicitly supports writing composition logic in general-purpose languages like Python and Go (as well as KCL), which brings type systems and IDE tooling into play (crossplane-docs-2, crossplane-docs-26). However, this applies only to the Function extension mechanism, not to defining the full infrastructure spec itself, and there's no evidence of dedicated SDKs, typed client libraries, or IDE integration for this workflow. missing for 10: dedicated general-purpose-language SDK for defining infra resources (not just functions), documented IDE/autocomplete support, type-safety examples, loop/programmatic composition examples, independent hands-on validation of this workflow.

   • [claimed-docs] “Functions allow you to write your configuration in multiple languages, including YAML, KCL, Python, and Go.”
   • [claimed-docs] “Functions - Functions extend Crossplane with new ways to configure composition”
   • [claimed-docs] “With Crossplane you don’t have to write a controller. Instead you configure a pipeline of functions.”

   proof ↗⚑ flag

Modules

1. developerConsume and publish reusable modules or components from a public registry

   weight 3 · round drawn
   OpenTofu~partialclaimed6/10

   OpenTofu's docs highlight a large public registry (23,600+ modules) and version-controlled module usage (opentofu-docs-13, opentofu-docs-24, opentofu-docs-12), confirming module consumption is core to the product. However, there is no direct evidence describing a publishing workflow for modules to the registry (e.g., versioning/publish CLI or registry submission process). missing for 10: explicit publish/versioning workflow documentation, independent confirmation of registry usability, and any hands-on evidence of publishing a module.

   • [claimed-docs] “With a thriving ecosystem of 3,900+ providers and 23,600+ modules, you can build and manage infrastructure across every cloud platform with …”
   • [claimed-docs] “With a thriving ecosystem of **3,900+ providers** and **23,600+ modules**, you can build and manage infrastructure across every cloud platfo…”
   • [claimed-docs] “Update all your modules programmatically with a single variable change. Never miss updating a module version by accident - keep your infrast…”

   proof ↗⚑ flag

   Crossplane~partialclaimed6/10

   Crossplane docs describe Providers and Configurations as portable, installable packages and the CLI supports building, installing, updating and pushing Crossplane Packages, plus a 'library of components to assemble your platform faster' — all indicating a publish/consume workflow for reusable modules. However, there is no explicit evidence of a named public registry (e.g., Upbound Marketplace) or details on registry discovery/versioning workflows. Missing for 10: explicit public registry reference/marketplace evidence, developer-facing publish workflow walkthrough, independent confirmation of module reuse via registry.

   • [claimed-docs] “building, installing, updating and pushing Crossplane Packages”
   • [claimed-docs] “Providers - Providers connect Crossplane to external APIs”
   • [claimed-docs] “Configurations - Portable packages of Crossplane resources”
   • [claimed-docs] “Use a library of components to assemble your platform faster”
   • [claimed-docs] “Installing Crossplane enables the installation of Crossplane Provider, Function, and Configuration resources.”

   proof ↗⚑ flag

Providers

1. developerManage resources across all major clouds and SaaS providers through a broad provider ecosystem

   weight 3 · round to OpenTofu
   OpenTofu✓fullcommunity9/10

   OpenTofu explicitly claims a large provider/module ecosystem (3,900+ providers, 23,600+ modules) covering every major cloud, and being Terraform-compatible means it inherits the entire Terraform provider registry ecosystem; community evidence corroborates drop-in compatibility and easy migration. Missing for 10: independent third-party audit of provider parity/coverage beyond vendor-stated numbers.

   • [claimed-docs] “With a thriving ecosystem of 3,900+ providers and 23,600+ modules, you can build and manage infrastructure across every cloud platform with …”
   • [claimed-docs] “With a thriving ecosystem of **3,900+ providers** and **23,600+ modules**, you can build and manage infrastructure across every cloud platfo…”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [community] “Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.”
   • [community] “The move towards OpenTofu is going to be a slow tide, but it is coming. It's an easy migration... We made the jump for one client, started a…”

   proof ↗⚑ flag

   Crossplane~partialcommunity6/10

   Docs confirm a package-based Provider model that connects Crossplane to external APIs (e.g. AWS RDS) and describes a 'library of components' to assemble a platform, and community discussion references AWS/GCP/Azure-style resources being managed this way, supporting a broad multi-cloud provider ecosystem claim. However, the evidence pack never enumerates specific major-cloud or SaaS provider packages (Azure, GCP, Datadog, etc.) beyond AWS RDS, nor cites a provider marketplace/registry size or independent confirmation of breadth. missing for 10: explicit list/marketplace evidence of major cloud providers (Azure, GCP) and SaaS providers, independent verification of ecosystem breadth beyond AWS example.

   • [claimed-docs] “there’s an RDS instance MR that extends Kubernetes with the ability to manage AWS RDS instances.”
   • [claimed-docs] “Providers - Providers connect Crossplane to external APIs”
   • [claimed-docs] “Use a library of components to assemble your platform faster”
   • [community] “When he asks for the DB, is he getting an RDS/CloudSQL/whatever or is it spinning up a DB on an EKS/GKE/whatever? I really don't like the la…”
   • [community] “So how is this different from AWS Operator? ... The AWS operator targets AWS resources. You can't take them, in a general sense, to minikube…”

   proof ↗⚑ flag

Config stacks

1. developerManage per-environment configuration (dev, staging, prod) as separate stacks or workspaces

   weight 2 · round to OpenTofu
   OpenTofu~partialclaimed5/10

   OpenTofu's docs explicitly mention using for_each to build 'multi-environment setups (dev/staging/prod)' via provider configuration generation, showing the product can model separate environments, and its drop-in Terraform compatibility implies inherited workspace/state-separation mechanisms. However, there is no direct documentation or probe evidence of a dedicated `tofu workspace` command, backend workspace isolation, or a 'stacks' feature being exercised, so the core mechanism developers would use for per-environment config isn't concretely demonstrated. Missing for 10: explicit `tofu workspace` command docs, evidence of stacks/state isolation per environment, and hands-on proof of switching environments.

   • [claimed-docs] “Dynamically generate provider configurations with for_each, eliminating repetitive code and improving maintainability. Perfect for multi-reg…”
   • [claimed-docs] “It serves as a drop-in replacement for Terraform, preserving your existing workflows and configurations.”
   • [claimed-docs] “It serves as a **drop-in replacement for Terraform**, preserving your existing workflows and configurations.”

   proof ↗⚑ flag

   Crossplane~partialclaimed3/10

   Crossplane has 'Environment Configs' (in-memory data stores for Compositions) and 'Configurations' as portable packages, which could be used to parameterize per-environment settings, but there is no documented workspace/stack concept analogous to Terraform workspaces for isolating dev/staging/prod as separate stacks. missing for 10: explicit dev/staging/prod workspace pattern, first-party guidance on structuring multiple environments, independent corroboration of this use case.

   • [claimed-docs] “Environment Configs - In-memory data stores for Compositions”
   • [claimed-docs] “Configurations - Portable packages of Crossplane resources”
   • [claimed-docs] “Composition Revisions - Manage changes to Compositions with revisions”

   proof ↗⚑ flag

Secrets

1. developerPass secrets and sensitive configuration into deployments without exposing them in code or logs

   weight 3 · round to OpenTofu
   OpenTofu~partialcommunity5/10

   OpenTofu supports encrypting state and plan files at rest (including AES-GCM configuration) so secrets don't leak in stored state/plan artifacts, and it is Terraform-compatible with variable-based configuration that supports sensitive input passing patterns. However, there is no direct documentation on marking variables as sensitive to suppress console/log output, no evidence of secret-manager integrations, and community commentary raises unresolved concerns about safety of checked-in encrypted state. missing for 10: explicit sensitive-variable/log-redaction documentation, secrets-manager/vault integration evidence, independent verification that logs never expose secret values.

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “Configure AES-GCM encryption method”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”
   • [community] “I'm very excited for state encryption though! Wondering how safe it is to check an encrypted state file into a public GitHub repo.”

   proof ↗⚑ flag

   Crossplane—none0/10

   Crossplane orchestrates infrastructure via Kubernetes and secret/credential handling (e.g., Provider credentials, Kubernetes Secrets) is a plausible axis for such a control plane, but the evidence pack contains no mention of secrets management, credential injection, or log redaction mechanisms. missing for 10: any documentation or community evidence of secret injection, secure credential storage, or protection from log exposure.

   ⚑ flag

Drift

1. platform-engineerDetect drift between my declared configuration and the actual cloud resources

   weight 3 · round drawn
   OpenTofu✓fullprobed8/10

   OpenTofu's `tofu plan` explicitly supports a refresh-only mode that updates state to reflect out-of-band changes without applying corrections, which is the canonical drift-detection workflow, and a hands-on probe confirms plan surfaces detected changes via -detailed-exitcode in a real run. Missing for 10: an explicit end-to-end hands-on test showing detection of an externally-modified resource (drift) specifically, and independent/community validation of drift detection accuracy.

   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “The `tofu plan` command creates an execution plan, which lets you preview the changes that OpenTofu plans to make to your infrastructure.”
   • [probe] “PROBE cli-plan (local run, macOS, OpenTofu v1.12.6): on the same minimal config used for Terraform, `tofu init -input=false` exited 0 and `t…”
   • [probe] “PROBE cli-plan-json (local run): `tofu show -json plan.out` exited 0 and emitted machine-readable plan JSON (format_version 1.2) with planne…”

   proof ↗⚑ flag

   Crossplane✓fullcommunity8/10

   Crossplane's control-plane model continuously reconciles declared desired state against actual cloud resources and self-corrects drift automatically, as documented directly ('If your software ever drifts from your desired state, the control plane automatically corrects the drift'). This is reinforced by its reconciliation-based architecture (managed resources, compositions) rather than one-off plan/apply. Missing for 10: independent hands-on verification/benchmarks of drift-detection behavior in production, and no detail on drift visibility/reporting tooling (e.g., diffing UI) beyond auto-correction.

   • [claimed-docs] “If your software ever drifts from your desired state, the control plane automatically corrects the drift.”
   • [claimed-docs] “There’s already a Crossplane managed resource for that.”
   • [claimed-docs] “there’s an RDS instance MR that extends Kubernetes with the ability to manage AWS RDS instances.”
   • [community] “Terraform is a popular tool for provisioning infrastructure...Unlike Crossplane, Terraform does not support workload portability across clou…”

   proof ↗⚑ flag

State backends

1. devops-leadEncrypt state at rest so credentials and sensitive values are not readable in plaintext state files

   weight 2 · round to OpenTofu
   OpenTofu✓fullcommunity9/10

   OpenTofu docs explicitly state built-in state and plan file encryption at rest, for both local and backend storage, with configurable methods like AES-GCM, directly addressing the story. Community sentiment even highlights excitement specifically about this state encryption feature, though the same commenter raises open questions about best practices for encrypted state handling (not a contradiction of the capability itself). missing for 10: independent hands-on verification/probe of the encryption feature actually working (only docs cited, no probe test like the plan/apply probes).

   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”
   • [claimed-docs] “Configure AES-GCM encryption method”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend. In addition, you can also use en…”
   • [community] “I'm very excited for state encryption though! Wondering how safe it is to check an encrypted state file into a public GitHub repo.”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence pack contains no mention of encryption at rest, state files, secrets handling, or etcd encryption for Crossplane's managed resource state. Crossplane stores its state as Kubernetes custom resources rather than flat state files, but no documentation here addresses how sensitive values are protected from plaintext exposure. missing for 10: any docs on etcd encryption, secret handling for provider credentials, or state-at-rest encryption guarantees.

   ⚑ flag

2. platform-engineerSafely inspect and modify state — moving, removing, or renaming resources — when refactoring

   weight 2 · round to OpenTofu
   OpenTofu~partialclaimed3/10

   The evidence pack shows related state-adjacent capabilities—`tofu import` for bringing existing resources into state, refresh-only mode for reconciling state with real infrastructure, and state encryption—but never documents the actual state-surgery commands (e.g., `tofu state mv`, `tofu state rm`, `moved` blocks) that platform engineers use for refactoring resource addresses. Missing for 10: explicit docs/examples of `state mv`/`state rm`/`moved` block workflows, safety guardrails (backups, dry-run) during state edits, and any hands-on/independent confirmation these operations work reliably.

   • [claimed-docs] “Refresh-only mode: creates a plan whose goal is only to update the OpenTofu state and any root module output values to match changes made to…”
   • [claimed-docs] “The `tofu import` command imports existing resources into OpenTofu.”
   • [claimed-docs] “OpenTofu supports encrypting state and plan files at rest, both for local storage and when using a backend.”

   proof ↗⚑ flag

   Crossplane—none0/10

   The evidence pack shows Crossplane CLI features for troubleshooting and rendering Compositions/Managed Resources, but there is no documentation or community evidence of a safe state-inspection/modification workflow (e.g., moving, renaming, or removing resources from state) analogous to Terraform's state mv/rm/import commands. Refactoring-safety for live infrastructure state is a fair axis for any IaC/control-plane tool, so absence of evidence here yields 'none' rather than 'na'.

   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”
   • [probe] “official CLI documented at https://docs.crossplane.io/cli/latest/”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

Testing

1. developerWrite automated tests for my infrastructure code and run them without touching production

   weight 2 · round to OpenTofu
   OpenTofu~partialclaimed6/10

   OpenTofu ships a native `tofu test` command that creates real infrastructure, checks assertions, then destroys it — directly enabling automated infra tests without touching production, and `tofu plan` speculative plans support pre-review verification. Evidence is first-party docs only with no independent/hands-on corroboration of the test framework's mocking or unit-test capabilities. missing for 10: independent/hands-on validation of `tofu test`, details on mock providers or isolated test environments, community confirmation of test workflow reliability.

   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “The `tofu test` command lets you test your OpenTofu configuration by creating real infrastructure and checking that the required conditions …”
   • [claimed-docs] “developers can use speculative plans to verify the effect of their changes before submitting them for code review”
   • [claimed-docs] “This ensures that `.tofu` files always take precedence over `.tf` files when both are available. This scenario can be useful for module auth…”

   proof ↗⚑ flag

   Crossplane!disputedcontradicted5/10

   Docs claim the Crossplane CLI supports 'testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane' (crossplane-docs-7), which would let developers test infra code without touching production. However, a hands-on probe explicitly found that 'unlike other tools probed here every real plan/apply operation requires a running Kubernetes cluster with the Crossplane control plane installed — no local plan/preview loop exists' (crossplane-probe-2), directly contradicting the claim of a self-contained local testing workflow. Missing for 10: independent confirmation that `crossplane render` works fully offline for realistic compositions, CI/CD test-suite examples, and reconciliation of the docs/probe discrepancy.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag

2. developerValidate and auto-format my configuration before planning

   weight 1 · round to Crossplane
   OpenTofu—none0/10

   The evidence pack covers plan, apply, test, import, and encryption commands but contains no mention of `tofu validate` or `tofu fmt` (or any auto-formatting/validation capability), so there is no evidence supporting this specific story despite the axis clearly applying to a Terraform-compatible IaC CLI. Missing for 10: any doc or probe evidence of a validate command, a fmt/auto-format command, or their integration into a pre-plan workflow.

   ⚑ flag

   Crossplane~partialprobed3/10

   The Crossplane CLI supports offline testing/rendering of Compositions without a cluster (crossplane-docs-7, crossplane-docs-8), which partially covers 'validate,' but there is no evidence of an auto-format command, and crossplane-probe-2 explicitly notes there is no local plan/preview loop — every real operation requires a live cluster, unlike a typical validate→format→plan workflow. missing for 10: dedicated auto-format tooling, an actual 'plan' equivalent step, and independent confirmation of the validate/render workflow's completeness.

   • [claimed-docs] “testing and rendering standalone Composition Functions without the need to access a Kubernetes cluster running Crossplane”
   • [claimed-docs] “troubleshooting Crossplane Compositions, Composite Resources and Managed Resources”
   • [probe] “PROBE cli-version (local run, macOS): `crossplane version --client` printed "Client Version: v2.5.0" and exited 0 after `brew install crossp…”

   proof ↗⚑ flag