Description
The Git Sync 403 was not a one-field mistake, it was a class, and the repository so far has fixed one instance of it. GCV-0081 is the second instance, found by reading rather than by any control. This task is the control.
THE CLASS. This platform composes request shapes against a vendor API it cannot exercise here, Crossplane retries a rejected shape indefinitely, and a refused shape therefore becomes continuous load on a live vendor tenant. The first occurrence paged the vendor’s on-call at a weekend over a secure value their provisioning app could not read, once every three minutes, because a claim existed. Three things were missing then and are still missing.
-
NO RECORD OF WHAT THE VENDOR REFUSES, at a level anything can check. The Git Sync evidence lives in a renderer doc comment, a catalog README and a Backlog task - all prose, all discoverable only by someone already looking at that kind. A sibling API was designed against the refused shape and CEL-hardened to accept nothing else, and every gate stayed green, because no artefact states the prohibition in a form the gate can assert. What is needed is one place that names each refused shape, the exact error, the date and how it was observed, and an assertion in the gate that no composed child emits one. The existing connection test asserts the create form for that one field; the assertion needed is over every emitted child.
-
NO STATED CONSEQUENCE OF A PERMANENTLY REFUSED CHILD. The management policies are non-destructive by design, so a child that can never succeed is retried forever and no condition on the composite says so - the composite reported Synced and Ready throughout. GCV-0077 is the same family seen from the other end: this platform generates continuous vendor API load and nothing surfaces it. An operator needs to be told that the remedy for a 4xx child is to remove the claim, not to wait, and needs to be able to see that a child is in that state.
-
NO PROBING PROTOCOL, which is why the first occurrence left residue on someone’s stack. dryRun=All is IGNORED by the vendor’s secret API: two objects posted with it persisted as real resources and had to be deleted by hand. kubectl apply –dry-run=server against a real API server IS honoured, so the two behave oppositely with no indication from the vendor side, and an agent that assumes the Kubernetes semantics mutates a live tenant. Live verification is outside this repository’s evidence boundary, so what belongs here is the written protocol a consumer estate follows: never probe on a stack anything depends on, assume every call mutates, record and remove residue.
ONE DECISION TO SETTLE WHILE HERE. The connection renderer still emits a standalone secure value that duplicates the credential inside the vendor, and its stated justification is that restoring the reference form later would then be a one-line change. GCV-0074 was subsequently amended to record the create form as PERMANENT design with the vendor defect never to be filed, which removes that justification. So the platform currently writes a second copy of a private key into a live tenant for a revert that is not planned - and an unreferenced secure value whose only decrypter is the provisioning app is the same object class that appeared in the vendor’s alert. Decide whether it keeps being rendered. Removing it is a live-behaviour change on existing installations, so it is a decision with a migration note, not a deletion.
Scope boundary: this task builds the control and records the class. Fixing the instance it already found belongs to GCV-0081.
Acceptance Criteria
- #1 One artefact in this repository names every vendor request shape known to be refused, with the exact error string, the date, and whether it was observed or inferred
- #2 The gate fails if any composed child emits a shape on that list, checked across every emitted kind rather than per-field in one test
- #3 The behaviour of a permanently refused child is documented: that it is retried indefinitely, that it generates continuous load on the vendor tenant, and what an operator should do about it
- #4 An operator can tell from resource conditions that a child is failing in a way no reconcile will fix, without reading provider logs
- #5 A written protocol for verifying a vendor shape against a live stack exists, stating that the vendor’s secret API ignores dryRun and that every call must be assumed to mutate
- #6 A decision is recorded on whether the connection renderer keeps duplicating the credential as a standalone secure value, with a migration note if it stops
Definition of Done
- #1 just check passes locally
- #2 hosted Validate workflow passes on the completing commit
Implementation Plan
Wave 13: create a machine-readable refused-shape record and all-emitted-kind assertion, prove the assertion with a deliberate failing fixture, and prepare the consumer documentation packet.
AC4 evidence uses each composed child standard Synced and Ready conditions plus events; the public troubleshooting text states that the composite can remain healthy and directs operators to the child. AC6 keeps the connection standalone secure value under the frozen decision because GCV-0084 tracks restoration of reference-form support; the duplicated vendor credential is the explicit trade-off and no migration occurs in this wave.
Implementation Notes
Wave 13 terminal evidence: refusedshapes.go is the executable record for every known refused GVK/path, including exact error, evidence class, and date. TestRefusedVendorShapeAssertionCoversEveryEmittedKind and scripts/refused-shapes.sh prove all-emitted-kind coverage and the controlled failure path. Public troubleshooting and request-schema guidance cover child conditions, indefinite retries, targeted correction, and mutation-safe probing. The standalone connection secure value is retained under the frozen GCV-0084 restoration seam. Local just check and hosted Validate run 35333659147 passed at b47831ddddfd5ec10e1e699d4d8608886261becd.
Final Summary
Added an executable refused-vendor-shape registry, central post-render guard, all-emitted-kind assertion, controlled negative proof, and operator guidance for permanent 4xx failures and live probing. Retained the connection standalone secure value as an explicit restoration seam. Verified by the focused assertion, controlled failure script, full local gate, and hosted Validate run 35333659147 at b47831ddddfd5ec10e1e699d4d8608886261becd.