Ptah Operator compatibility

Operator version to the Ptah build the operator executes, identified by the digest-pinned executorImage and the ptahVersion bound beside it. It is not the Ptah CLI a person used to build the OCI artifact. The runner is not a third axis: it is built from the operator source this row names, and the exact protocol both halves speak is in runnerProtocolVersion.

Three claims are kept apart below, because a table that blurs them turns an untested combination into an unsupported one. Declared is a promise. Verified is a measurement, with what it covered. Anything absent from both is untested, which is not the same as incompatible.

Operator Declared Ptah support Verified Documentation
edge No range is claimed. The chart ships no executor default, installation requires both a digest-pinned executorImage and the ptahVersion verified from that image's provenance, and the supported build is exactly the one the lifecycle matrix exercised. verified
v0.7.0 — The complete OCI resolution and verification, observation, planning, approval, apply, failure-recovery and convergence lifecycle against PostgreSQL and MySQL, on every supported Kubernetes minor, for both artifact formats this operator reads: application/vnd.stokaro.ptah.schema.v1 for a declared schema, whose declared rows converge on both engines, and application/vnd.stokaro.ptah.migrations.v1 for a versioned migration directory, whose history read, approval gate and applied sequence run against PostgreSQL and MySQL.		 edge guide
  • The suite builds the executor image from the verified commit rather than pulling the image the release published, so what the matrix measures is the code v0.7.0 carries and not the bytes ghcr.io/stokaro/ptah:0.7.0 serves. A reader who installs the published image runs the same source at a different build.
  • The migration machine contracts -- `migrations status --json` carrying contract_version and a per-migration record, and `migrations up --json` carrying an outcome -- reached Ptah after v0.3.0-201. A build older than the verified commit resolves and verifies a migration artifact and then refuses its own history document, so the versioned workflow needs at least this commit rather than any build that has the commands.
  • The verified scope is the operator's database support window, PostgreSQL 17.x and MySQL 8.4.x LTS. Other engines Ptah addresses are unverified here, whatever the Ptah build.
  • The published verified set is a repository document. It is not compiled into the manager, and nothing compares a running executor's ptahVersion against it, so a combination outside this set is outside what the matrix measured rather than something the operator refuses. What is refused before a database is mutated is a change of any execution component between the plan and the apply -- Ptah, the executor and runner images, the protocol version, the controller image and revision -- checked before the Job is created. What is refused after a Job has run is a runner speaking another protocol version, which is a rejected result frame rather than a prevented mutation. Pinning both the executor image and its ptahVersion at install is a requirement on whoever installs, not a check at runtime.