Prerequisites

• I searched existing issues

Feature Summary

Add runai as a value for the recipe platform criteria field — peer to the existing dynamo, kubeflow, nim, and slurm values.

Problem / Use Case

NVIDIA Run:ai is an AI workload-orchestration platform deployed on top of Kubernetes and presently isn't represented in AICR's recipe criteria taxonomy, which means:

• AICR users running Run:ai clusters cannot presently ask for a Run:ai-flavored recipe.
• Recipe authors have nowhere to anchor Run:ai-specific substrate prerequisites.
• There's not a published, versioned "what does a Run:ai-ready cluster look like" contract that an installer can call as a pre-flight.

Proposed Solution

Add runai as a peer enum value to the existing platform taxonomy. Enum-plumbing only for this issue — no operator components or leaf overlays. Mirrors the precedent in #866 (slurm enum addition).

Concretely, the same surface the slurm addition touched:

• pkg/recipe/criteria.go — CriteriaPlatformRunai constant, parser case in ParseCriteriaPlatformType, sorted slice in GetCriteriaPlatformTypes.
• pkg/recipe/criteria_test.go — table cases for runai / Runai and updated TestGetCriteriaPlatformTypes expected list.
• pkg/recipe/doc.go — Platform field docstring and the CriteriaPlatform* bullet list.
• api/aicr/v1/server.yaml — three platform enum sites (GET query param ×2, components/schemas).
• docs/user/api-reference.md, docs/user/cli-reference.md.
• docs/contributor/api-server.md, docs/contributor/validations.md.
• docs/README.md glossary Criteria row.

Success Criteria

• aicr recipe --platform runai --format yaml resolves without error and echoes platform: runai in the criteria block.
• GetCriteriaPlatformTypes() returns ["dynamo", "kubeflow", "nim", "runai", "slurm"] (alphabetic).
• All enum-listing documentation sites mention runai consistently — same audit list as the slurm precedent.
• Unit tests pass (go test -race ./pkg/recipe/...).
• make lint passes (golangci-lint, yamllint, license, agents-sync, doc filename, MDX-safe, chart-pin checks).
• Existing recipes that don't specify a platform continue to resolve identically (additive only — no behavior change for kubeflow, dynamo, nim, slurm, or the unset case).

Alternatives Considered

• Leave platform=any as the catch-all for Run:ai clusters. Works, but loses the ability to route Run:ai-specific recipes later, and forces every recipe author to bolt on "if cluster has Run:ai" logic outside the criteria mechanism.
• Wait and bundle this with the first Run:ai recipe matrix PR. Pre-reserves the enum value before any concrete recipe content lands, matching how slurm was introduced (Add Slinky slurm-operator as platform-slurm #866). Lets the recipe matrix and any operator/CRD plumbing land as follow-ups.

Component

Recipe engine / data

Priority

Important (would improve my workflow)

Compatibility / Breaking Changes

None. Additive — existing recipes, criteria queries, and CLI/API invocations are unaffected. The new enum value is opt-in via --platform runai.

Operational Considerations

• Observability: No new metrics or log lines; existing recipe_rule_match_total{status} already covers platform-based routing.
• Upgrades: Pure additive — older clients querying without --platform runai see no change. Clients that previously rejected unknown enums at the OpenAPI layer will accept runai after the server is updated; pre-update clients that send platform=runai get the existing "invalid platform type" 400.
• Documentation drift: The enum is enumerated in many files; audit checklist is in AGENTS.md (the "Enum/constant value added" bullet under Documentation updates).

Are you willing to contribute?

Yes, I'll plan to open a PR