spec: add workflow_id / workflow_version_id to PromptRequest with x-runtime tag

[MillerMedia]

Summary

Adds two optional, nullable UUID fields to PromptRequest for runtimes that wrap workflow execution in a workflow-version entity (the hosted-cloud runtime does this; local ComfyUI does not). Both fields are tagged x-runtime: [cloud] to mark them as runtime-specific — local returns null (or omits them entirely) and that's correct behavior, not drift.

workflow_id:
  type: string
  format: uuid
  nullable: true
  x-runtime: [cloud]
  description: |
    UUID identifying a hosted-cloud workflow entity to associate with this
    job. Local ComfyUI doesn't track workflow entities and returns `null`
    (or omits the field). ...
workflow_version_id:
  type: string
  format: uuid
  nullable: true
  x-runtime: [cloud]
  description: |
    UUID identifying a hosted-cloud workflow version to associate with
    this job. Local ComfyUI returns `null` (or omits the field). ...

Why these fields belong in the OSS spec

Hosted-cloud's frontend and backend share openapi.yaml as their single source of truth via auto-generated client types. Without the fields declared here, the cloud runtime has to either hand-edit a vendored copy of openapi.yaml (drift) or maintain a separate cloud-only spec file (fork). Both produce maintenance pain. The shape that scales is: cloud-only fields live in OSS spec under their intended path, declared nullable, with an explicit x-runtime tag so local-only readers can ignore them programmatically and humans can see what each runtime populates.

About the x-runtime extension

This PR introduces x-runtime as a new vendor extension on this spec. Convention:

Tag	Meaning
x-runtime: [cloud]	Only the hosted-cloud runtime populates this field; local returns null or omits it.
x-runtime: [local]	Only local populates; cloud returns null.
(absent)	Both runtimes populate the field. This is the default for everything else in the spec.

x--prefixed properties are ignored by standard OpenAPI validators including kin-openapi. Local clients reading the spec see two extra optional nullable fields — which is forward-compatible with every existing reader.

What this does not change

1. No Python code changes. PromptRequest already accepts arbitrary optional fields (extra_data: additionalProperties: true on the same schema is a stronger guarantee). The server silently accepts and ignores both fields today.
2. No required-fields change. Both fields stay outside required, so older clients that don't know about them keep validating.
3. No nullability widening on existing fields. Other fields untouched.

Verification

1. YAML parses (yaml.safe_load).
2. kin-openapi loader.LoadFromFile accepts the modified spec.
3. openapi3filter.ValidateRequest on a PromptRequest with both fields set to null, set to a valid UUID, or omitted — all pass.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 101a6117-4632-4da8-a24f-e324b96022d0

📥 Commits

Reviewing files that changed from the base of the PR and between 35819e3 and 431abad.

📒 Files selected for processing (1)

• openapi.yaml

---

📝 Walkthrough

Walkthrough

The PR adds two optional fields to the PromptRequest schema in openapi.yaml: workflow_id and workflow_version_id. Both are nullable UUID strings annotated with x-runtime: [cloud], indicating they are populated by the hosted-cloud runtime while local ComfyUI returns null or omits them. No other request/response shapes are modified.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: adding workflow_id and workflow_version_id fields to PromptRequest with x-runtime tagging.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, explaining the purpose, rationale, and verification of the schema additions.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}