The CRD schemas vendored under schemas/crd/ are pinned to a commit that is no longer
the newest operators/config/crd/bases in
nanohype/eks-agent-platform.
> slack-knowledge-bot@0.1.0 schemas:freshness
> node scripts/sync-crd-schemas.mjs --freshness
✗ the pin 0f56302c9e2d is behind operators/config/crd/bases in nanohype/eks-agent-platform:
platform.nanohype.dev_platforms.yaml — changed upstream since the pin
agents.nanohype.dev_modelgateways.yaml — changed upstream since the pin
Nothing is broken — the vendored copies still match the commit they claim.
Adopt the newer operator API when convenient: `npm run schemas:sync -- --ref=latest`,
review the schema diff, and ship it with whatever platform.yaml change it implies.
`latest` resolves upstream when the re-vendor runs, so this line is answerable on
whatever day it is read rather than on the day it was printed.
Why this matters more than it reads. platform.yaml is validated against these
copies and against nothing else. Every bound the operator's CRD gains — a maxItems,
a pattern, an enum — is enforced here only after this pin moves. Until then CI will
pass a Platform CR the apiserver would reject, and the rejection surfaces during an
ArgoCD sync rather than on the pull request that introduced it.
Re-vendor and re-validate:
npm run schemas:sync -- --ref=latest
npm run platform:validate
latest resolves the newest commit touching operators/config/crd/bases at the moment
the re-vendor runs. This body is re-edited weekly and read on whatever day someone opens
it, so a commit id here would name the newest thing upstream for at most a week and be
presented as current for as long as the issue stayed open — and following it would
re-vendor to the wrong ref while closing an issue that should have stayed open.
Read the schema diff before merging — a new constraint upstream usually implies a
platform.yaml change here. This issue closes itself once the pin is current.
The CRD schemas vendored under
schemas/crd/are pinned to a commit that is no longerthe newest
operators/config/crd/basesinnanohype/eks-agent-platform.
Why this matters more than it reads.
platform.yamlis validated against thesecopies and against nothing else. Every bound the operator's CRD gains — a
maxItems,a
pattern, an enum — is enforced here only after this pin moves. Until then CI willpass a Platform CR the apiserver would reject, and the rejection surfaces during an
ArgoCD sync rather than on the pull request that introduced it.
Re-vendor and re-validate:
latestresolves the newest commit touchingoperators/config/crd/basesat the momentthe re-vendor runs. This body is re-edited weekly and read on whatever day someone opens
it, so a commit id here would name the newest thing upstream for at most a week and be
presented as current for as long as the issue stayed open — and following it would
re-vendor to the wrong ref while closing an issue that should have stayed open.
Read the schema diff before merging — a new constraint upstream usually implies a
platform.yamlchange here. This issue closes itself once the pin is current.