Update OpenAPI spec

[Destiner]

This PR updates the OpenAPI spec generated from rhinestonewtf/orchestrator@597e9bf21a0f150ae21c5c64aaffc9184a1d3d88.

[rhinestone-kevin]

Trivial change — approved without a full review.

[greg-rhinestone]

🤖 Greg · ✅ LGTM

Updates the generated orchestrator OpenAPI mirror from rhinestonewtf/orchestrator@89e01d7, removing the stale x-feature-flags quote header from the contract.

Risk: Low - generated spec sync with a tiny header-only contract delta.

[rhinestone-kevin]

Trivial change — approved without a full review.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

Generated orchestrator spec provenance moved forward and the effective contract delta remains the tiny quote-header cleanup: x-feature-flags stays removed from the generated OpenAPI surface. No new schema issue found.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

Generated orchestrator spec provenance advanced to rhinestonewtf/orchestrator@00ad6de, and the effective schema delta is still just the removal of the stale x-feature-flags quote header. No new contract issue found.

[rhinestone-kevin]

Trivial change — approved without a full review.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

Generated orchestrator spec now tracks rhinestonewtf/orchestrator@d500f94, adding vbUSDC/vbETH to the quote access-list and fee-token enums from the shared-configs bump; no new contract issue found.

[rhinestone-kevin]

Trivial change — approved without a full review.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

No effective orchestrator.json change since the last Greg review; the spec still contains the already-reviewed quote header cleanup and vbUSDC/vbETH enum additions.

[rhinestone-kevin]

Approve — updates the Orchestrator OpenAPI spec; no blockers found.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

New head adds generated KEY_SCOPE_DENIED 403 schema coverage from the orchestrator provenance commit. Previous feedback had no unresolved items.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

New head only adds generated quote token enum coverage for USD, pathUSD, and USDC.e from the orchestrator shared-configs 1.6.4 sync. Previous feedback had no unresolved items.

[rhinestone-kevin]

Comment — updates generated Orchestrator OpenAPI spec; one question on the removed feature-flags header.

[rhinestone-kevin]

question — This removes the documented x-feature-flags header from POST /quotes; if existing consumers still use it to opt into gated quote behavior, regenerated clients will lose that contract. Is the orchestrator change intentionally retiring this header?

[rhinestone-kevin]

Approve — Large diff, focusing on orchestrator spec; no blockers found.

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

Direct orchestrator.json content is unchanged from the previous Greg-reviewed head 66dc706, despite the refreshed PR head/provenance commit. No new contract surface to review.

[rhinestone-kevin]

Comment — large diff, focusing on orchestrator.json; one question on 403 error contracts.

[rhinestone-kevin]

question — This new 403 response is described as API key scope denial, but its schema below still accepts VALIDATION_ERROR, INSUFFICIENT_LIQUIDITY, and the generic server/client error codes as valid 403 bodies. Is the intended 403 contract only KEY_SCOPE_DENIED, or should clients really treat every existing error shape as possible under this status?

[greg-rhinestone]

🤖 Greg · 🔄 Re-review · ✅ LGTM

Direct orchestrator.json content is unchanged from the previous Greg-reviewed head 28bfbf8, despite the refreshed provenance commit rhinestonewtf/orchestrator@b8427ad. No new contract surface to review.

[rhinestone-kevin]

Comment — Large diff, focusing on orchestrator spec; one unresolved question on error status contracts.

[rhinestone-kevin]

question — This same error union is still being added to every status-specific error response: here KEY_SCOPE_DENIED is accepted by the 400 schema, and the same shape also appears under the 403 and 500 schemas. Prior 403 thread asked whether scope denial should be the only 403 contract; if the answer is yes, generated clients should not also see scope denial as a valid 400 or 500 body.

[rhinestone-kevin]

Comment — Large diff, focusing on orchestrator spec; one unresolved question on error status contracts.

[rhinestone-kevin]

question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same error shape is also present under the new 403 and 500 schemas; the prior 403/status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.

[rhinestone-kevin]

Trivial change — approved without a full review.

[rhinestone-kevin]

Comment — Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question — The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403, 404, and 500 responses. If scope denial is meant to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment — Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question — The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403, 404, and 500 responses across the generated spec. If scope denial is meant to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment — Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question — The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403, 404, and 500 responses across the generated spec. If scope denial is meant to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403, 404, and 500 responses across the generated spec. If scope denial is meant to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403, 404, and 500 responses across the generated spec. If scope denial is meant to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403, 404, and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403, 404, and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403, 404, and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403, 404, and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403, 404, and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403 and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.

[rhinestone-kevin]

Comment - Large diff, focusing on generated orchestrator spec; the prior status-specific error contract question remains unresolved.

[rhinestone-kevin]

question - The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union is also used for 403 and 500 responses across the generated spec. If scope denial is intended to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.