[kong]

Summary

• Sync the vendored OpenAPI contract from Kong/volcano-hosting@1c7e5a5ffcbe.
• Regenerate checked-in client or contract types with this repository's pinned tooling.

API change report

Public API

New Endpoints: 18

---

GET /connectors
POST /connectors
DELETE /connectors/{connector_id}
GET /connectors/{connector_id}
POST /issues
GET /lavaflow/connector-bindings
POST /lavaflow/connector-bindings
DELETE /lavaflow/connector-bindings/{binding_id}
GET /projects/{id}/functions/{functionId}/candidates
POST /projects/{id}/functions/{functionId}/candidates
DELETE /projects/{id}/functions/{functionId}/candidates/{candidateId}
GET /projects/{id}/functions/{functionId}/candidates/{candidateId}
GET /projects/{id}/functions/{functionId}/candidates/{candidateId}/deployments
POST /projects/{id}/functions/{functionId}/candidates/{candidateId}/deployments
POST /projects/{id}/functions/{functionId}/candidates/{candidateId}/promote
GET /projects/{id}/functions/{functionId}/serving
POST /projects/{id}/functions/{functionId}/serving/rollback
POST /realtime/v1/publish

Deleted Endpoints: 9

---

GET /lavaflow/global-skills
GET /lavaflow/skill-versions
GET /lavaflow/skills
DELETE /lavaflow/skills/{skill_id}
GET /lavaflow/skills/{skill_id}
PATCH /lavaflow/skills/{skill_id}
GET /lavaflow/slack-channels
POST /lavaflow/slack-channels
DELETE /lavaflow/slack-channels/{binding_id}

Modified Endpoints: 47

---

POST /auth/signup

• Responses changed
  • Modified response: 403
    • Description changed from 'Forbidden - Signups disabled, anon key lacks signup permission, or the
      email domain is not in allowed_email_domains. The internal
      anonymous.volcano.internal and volcano.local domains are reserved
      for the anonymous and Builder debug accounts Volcano creates, and are
      refused whatever the project allows.
      ' to 'Forbidden - Signups disabled, anon key lacks signup permission, or the
      email domain is not in allowed_email_domains. The internal
      anonymous.volcano.internal and volcano.local domains are reserved
      for anonymous accounts and for the debug accounts an earlier Builder
      created (Volcano no longer creates them), and are refused whatever the
      project allows.
      '

GET /capabilities

• Description changed from 'Lists which product capabilities accept new work in this environment. Check it
  to decide what to offer, instead of calling a route to see whether it fails.

ID	Covers
sandboxes	The Sandbox API: presets, templates, sessions, and executions
sandboxes.sessions	Starting and resuming sessions, and one-shot executions
sandboxes.custom_templates	Deploying a custom template; its validation waits while sandboxes.sessions is unavailable
sandboxes.network_isolation	Creating sessions and one-shot executions with network.egress deny_all; existing deny_all sessions work either way
sandboxes.output_not_kept	Commands that keep no output: keep_output: false on a command, and executions.keep_output: false on a session; commands that keep output work either way
issues	The Issues API: listing, reading, and updating grouped runtime errors
lavaflow	LavaFlow, which diagnoses a project's issues and opens pull requests that fix them. Here it reports only whether LavaFlow is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.merge	LavaFlow merging its fixes, with autonomy: merge. Here it reports only whether merging is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.lineage	LavaFlow following up its fixes: linking a fix's recurrence or a new issue its deploy caused to the fix, the follow-up runs, and the lineage holds. Here it reports only whether fix lineage is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.code_quality	LavaFlow Code Quality, which reviews the code each frontend production deploy changes. Here it reports only whether Code Quality is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.slack	Reporting problems to LavaFlow from Slack: installing the Volcano Slack app, connecting Slack identities, and binding channels to projects. Here it reports whether LavaFlow is released, the Slack app is set up, and Slack reports have launched in this environment; whether a project has it comes from GET /projects/{id}/capabilities
functions.response_streaming	Streaming an HTTP-mode function's response on its own URL as the function writes it
frontend_routes	Creating and changing Frontend routes; listing, deleting, and serving existing ones work either way
frontends.candidates	Creating, redeploying, promoting and rolling back to a frontend Candidate; reading, deleting and rolling back to the frontend's own runtime always work
databases.migrations	Starting migration runs and recording a baseline; reading history and runs works either way
shares	Creating, switching on and publishing shares, and forking one

A capability missing from the list is unavailable, and a capability under
another, such as sandboxes.sessions, is unavailable whenever its parent is.
While a capability is unavailable, requests that start new work answer 404
or 400 with code feature_unavailable; refresh this list when you receive
that code. Reading, deleting, and terminating what already exists keep
working unless the whole feature is absent from the environment. Every caller
in an environment gets the same answer; GET /projects/{id}/capabilities
answers for one project.

functions.response_streaming refuses nothing: while it is unavailable, a
function's own URL still answers and sends a streamed response whole, once
the function finishes, up to 6 MiB with headers; a larger one fails the
invocation. Frontend Function routes stream either way.
' to 'Lists which product capabilities accept new work in this environment. Check it
to decide what to offer, instead of calling a route to see whether it fails.

ID	Covers
sandboxes	The Sandbox API: presets, templates, sessions, and executions
sandboxes.sessions	Starting and resuming sessions, and one-shot executions
sandboxes.custom_templates	Deploying a custom template; its validation waits while sandboxes.sessions is unavailable
sandboxes.network_isolation	Creating sessions and one-shot executions with network.egress deny_all; existing deny_all sessions work either way
sandboxes.output_not_kept	Commands that keep no output: keep_output: false on a command, and executions.keep_output: false on a session; commands that keep output work either way
issues	The Issues API: listing, reading, and updating grouped runtime errors
issues.create	Writing an issue with POST /issues; written issues already recorded read and update either way
lavaflow	LavaFlow, which diagnoses a project's issues and opens pull requests that fix them. Here it reports only whether LavaFlow is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.merge	LavaFlow merging its fixes, with autonomy: merge. Here it reports only whether merging is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.lineage	LavaFlow following up its fixes: linking a fix's recurrence or a new issue its deploy caused to the fix, the follow-up runs, and the lineage holds. Here it reports only whether fix lineage is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.open_pr_ci_start	A fix a person merges, as under autonomy: open_pr, opening ready for review with LavaFlow running its CI once, unless the repository may run CI outside GitHub Actions; unavailable, such a fix opens as a draft whose commit skips CI. Here it reports only whether this is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.code_quality	LavaFlow Code Quality, which reviews the code each frontend production deploy changes. Here it reports only whether Code Quality is released in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.slack	Reporting problems to LavaFlow from Slack: installing the Volcano Slack app, connecting Slack identities, and binding channels to projects. Here it reports whether LavaFlow is released, the Slack app is set up, and Slack reports have launched in this environment; whether a project has it comes from GET /projects/{id}/capabilities
lavaflow.aikido	LavaFlow fixing the security issues Aikido finds: connecting an Aikido workspace and binding projects to it. Here it reports whether LavaFlow is released and Aikido reports have launched in this environment; whether a project has it comes from GET /projects/{id}/capabilities
functions.response_streaming	Streaming an HTTP-mode function's response on its own URL as the function writes it
frontend_routes	Creating and changing Frontend routes; listing, deleting, and serving existing ones work either way
frontends.candidates	Creating, redeploying, promoting and rolling back to a frontend Candidate; reading, deleting and rolling back to the frontend's own runtime always work
databases.migrations	Starting migration runs and recording a baseline; reading history and runs works either way
shares	Creating, switching on and publishing shares, and forking one
ai_gateway	The Volcano AI gateway: creating a key that holds ai.invoke with POST /projects/{id}/service-keys, and minting the first run token of a run; reading, regenerating and deleting existing keys, and reading, extending, revoking and minting again for a run already minted for, work either way
realtime.http_publish	Publishing a message with POST /realtime/v1/publish; while Realtime is paused it stays available, and the route answers 503 feature_paused

A capability missing from the list is unavailable, and a capability under
another, such as sandboxes.sessions, is unavailable whenever its parent is.
While a capability is unavailable, requests that start new work answer 404
or 400 with code feature_unavailable; refresh this list when you receive
that code. Reading, deleting, and terminating what already exists keep
working unless the whole feature is absent from the environment. Every caller
in an environment gets the same answer; GET /projects/{id}/capabilities
answers for one project.

functions.response_streaming refuses nothing: while it is unavailable, a
function's own URL still answers and sends a streamed response whole, once
the function finishes, up to 6 MiB with headers; a larger one fails the
invocation. Frontend Function routes stream either way.

After these, the list names each first-party app Volcano runs in this
environment, such as builder, by its own ID. Such an app is available
while it accepts new work. When only the app's own release is off, work
it already accepted continues; when first-party app mounts are off, its
mount refuses every request with 404 feature_unavailable.
'

• Responses changed
  • Modified response: 200
    • Content changed
      • Modified media type: application/json
        • Schema changed
          • Properties changed
            • Modified property: data
              • Items changed
                • Properties changed
                  • Modified property: status
                  • Extensions changed
                  • New extension: x-enum-varnames
        • Example changed from map[data:[map[id:sandboxes status:available] map[id:sandboxes.sessions status:available] map[id:sandboxes.custom_templates status:unavailable] map[id:sandboxes.network_isolation status:available] map[id:sandboxes.output_not_kept status:available] map[id:issues status:available] map[id:functions.response_streaming status:available] map[id:frontend_routes status:available] map[id:frontends.candidates status:unavailable] map[id:databases.migrations status:available] map[id:shares status:unavailable]]] to map[data:[map[id:sandboxes status:available] map[id:sandboxes.sessions status:available] map[id:sandboxes.custom_templates status:unavailable] map[id:sandboxes.network_isolation status:available] map[id:sandboxes.output_not_kept status:available] map[id:issues status:available] map[id:functions.response_streaming status:available] map[id:frontend_routes status:available] map[id:frontends.candidates status:unavailable] map[id:databases.migrations status:available] map[id:shares status:unavailable] map[id:ai_gateway status:unavailable]]]

GET /functions/resolve

• Description changed from 'Resolves a DNS-safe function name to its function ID and invocation URL within the caller's project.

SDKs use this endpoint internally to invoke by function name while routing by function ID.
Invoke the returned invoke_url as-is. It does not share a domain with the API, so a host
built from the API URL will not reach the function. When the deployment serves no public
invocation domain, as in local development, invoke_url is omitted and callers invoke
through POST /functions/{functionId}/invoke.

With Service Key:

• Allowed

With Auth User Token:

• Allowed for authenticated and public functions
• A private function answers 404, exactly as a missing one

With Anon Key:

• Requires anon key permission: functions.invoke
• Function must have visibility: public; any other answers 404
  ' to 'Resolves a DNS-safe function name to its function ID and invocation URL within the caller's project.

SDKs use this endpoint internally to invoke by function name while routing by function ID.
Invoke the returned invoke_url as-is. It does not share a domain with the API, so a host
built from the API URL will not reach the function. In local development, and when the
deployment serves no public invocation domain, invoke_url is omitted and callers invoke
through POST /functions/{functionId}/invoke. A local function's own invoke_url, for
webhook testing, is on the function resource.

With Service Key:

• Allowed

With Auth User Token:

• Allowed for authenticated and public functions
• A private function answers 404, exactly as a missing one

With Anon Key:

• Requires anon key permission: functions.invoke
• Function must have visibility: public; any other answers 404
  '
• Responses changed
  • Modified response: 200
    • Content changed
      • Modified media type: application/json
        • Schema changed
          • Properties changed
            • Modified property: invoke_url
              • Description changed from 'Canonical HTTPS endpoint for invoking this function. Use it as-is: it does not share a domain with the API, so a host derived from the API URL will not reach the function. Omitted when the deployment serves no public invocation domain, as in local development; invoke through POST /functions/{functionId}/invoke instead.' to 'Canonical HTTPS endpoint for invoking this function. Use it as-is: it does not share a domain with the API, so a host derived from the API URL will not reach the function. Omitted in local development and when the deployment serves no public invocation domain; invoke through POST /functions/{functionId}/invoke instead.'

POST /functions/{functionId}/invoke

• Description changed from 'Invoke a function. The function's visibility decides which credentials
  may call it, and the function does not run for any other. A private
  function answers every credential but a service key exactly as a
  missing one, with 404, so its name and id cannot be discovered; an anon
  key on an authenticated function gets 403. An SDK calling by name
  resolves it first through GET /functions/resolve, which answers that
  anon key with 404 instead.

With Service Key (admin/background operations, every visibility):

• Use for background jobs, webhooks, cron, admin operations
• Function receives payload only (no user context)
• Database queries bypass RLS (admin access)

With Auth User Token (user-facing, authenticated or public functions):

• Use for user-initiated actions
• Includes users from anonymous sign-ins
• Function receives payload + __volcano_auth context:

  {
    user_id: "uuid",
    email: "user@example.com",
    project_id: "uuid",
    role: "authenticated" or "anonymous"
  }

• Database queries enforce RLS (user-scoped data)

With Anon Key (public functions only):

• Requires anon key permission: functions.invoke
• Function must have visibility: public
• Function receives payload only (no __volcano_auth)

Reserved payload keys: the top-level __volcano_auth and
__volcano_http keys are reserved. Volcano removes caller-supplied
values for both before the function runs; only an auth user token adds
a server-built __volcano_auth, and only HTTP-mode ingress sets
__volcano_http: true.

Transport and CORS:

• This operation is the authenticated direct RPC endpoint and always uses the
  POST {payload: ...} contract, including for functions whose DNS ingress is
  configured in HTTP mode.
• The geo-routed DNS ingress is the function's invoke_url. It is on a
  different domain from this API, so it cannot be derived from the API host.
• RPC-mode DNS ingress accepts POST at /. HTTP-mode DNS ingress accepts GET,
  HEAD, POST, PUT, PATCH, and DELETE at / and nested paths.
• Direct and RPC-mode CORS preflight advertises POST, OPTIONS. HTTP-mode DNS
  preflight advertises GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS.
• http_auth_mode: none applies only to public HTTP-mode DNS ingress; this
  direct operation always requires a Volcano credential.

Durable functions are not invocable here. A durable function's id
answers 404, whatever its visibility, because a synchronous call would
run it with no execution record, no idempotency and no concurrency
accounting. Start one with
POST /durable-functions/{functionId}/executions.
' to 'Invoke a function. The function's visibility decides which credentials
may call it, and the function does not run for any other. A private
function answers every credential but a service key exactly as a
missing one, with 404, so its name and id cannot be discovered; an anon
key on an authenticated function gets 403. An SDK calling by name
resolves it first through GET /functions/resolve, which answers that
anon key with 404 instead.

With Service Key (admin/background operations, every visibility):

• Use for background jobs, webhooks, cron, admin operations
• Function receives payload only (no user context)
• Database queries bypass RLS (admin access)

With Auth User Token (user-facing, authenticated or public functions):

• Use for user-initiated actions
• Includes users from anonymous sign-ins
• Function receives payload + __volcano_auth context:

  {
    user_id: "uuid",
    email: "user@example.com",
    project_id: "uuid",
    role: "authenticated" or "anonymous"
  }

• Database queries enforce RLS (user-scoped data)

With Anon Key (public functions only):

• Requires anon key permission: functions.invoke
• Function must have visibility: public
• Function receives payload only (no __volcano_auth)

Reserved payload keys: the top-level __volcano_auth,
__volcano_http and __volcano_mount keys are reserved. Volcano
removes caller-supplied values for all three before the function runs;
only an auth user token adds a server-built __volcano_auth, and only
HTTP-mode ingress sets __volcano_http: true. __volcano_mount is set
only by Volcano's first-party app mounts.

Transport and CORS:

• This operation is the authenticated direct RPC endpoint and always uses the
  POST {payload: ...} contract, including for functions whose DNS ingress is
  configured in HTTP mode.
• The geo-routed DNS ingress is the function's invoke_url. It is on a
  different domain from this API, so it cannot be derived from the API host.
• RPC-mode DNS ingress accepts POST at /. HTTP-mode DNS ingress accepts GET,
  HEAD, POST, PUT, PATCH, and DELETE at / and nested paths.
• Direct and RPC-mode CORS preflight advertises POST, OPTIONS. HTTP-mode DNS
  preflight advertises GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS.
• http_auth_mode: none applies only to public HTTP-mode DNS ingress; this
  direct operation always requires a Volcano credential.

Durable functions are not invocable here. A durable function's id
answers 404, whatever its visibility, because a synchronous call would
run it with no execution record, no idempotency and no concurrency
accounting. Start one with
POST /durable-functions/{functionId}/executions.
'

• Request body changed
  • Content changed
    • Modified media type: application/json
      • Schema changed
        • Properties changed
          • Modified property: payload
            • Description changed from 'Payload to send to the function.

If invoked with auth user token, Volcano automatically injects __volcano_auth context:

{
  ...yourPayload,
  __volcano_auth: {
    user_id: "uuid",
    email: "user@example.com",
    project_id: "uuid",
    role: "authenticated" | "anonymous"
  }
}

The top-level __volcano_auth and __volcano_http keys are reserved;
Volcano removes caller-supplied values for both.
' to 'Payload to send to the function.

If invoked with auth user token, Volcano automatically injects __volcano_auth context:

{
  ...yourPayload,
  __volcano_auth: {
    user_id: "uuid",
    email: "user@example.com",
    project_id: "uuid",
    role: "authenticated" | "anonymous"
  }
}

The top-level __volcano_auth, __volcano_http and __volcano_mount
keys are reserved; Volcano removes caller-supplied values for all three.
'

POST /lavaflow/held-fix-opens

• Description changed from 'Opens the pull request for a fix LavaFlow held because the
  repository's workflows could run it with the repository's secrets
  before a person approves it (pull_request_skipped: ungated_workflows). Read the run first: send its id as run_id,
  with the diff_sha256 and held_workflows.jobs_sha256 it served, to
  say you read that diff and that list of jobs. LavaFlow opens the fix it
  saved, exactly as reviewed, past those jobs only. It writes no new
  fix.

Right before it queues the run, LavaFlow serves the diff again and
reads the workflows again. A diff served differently since you read
it, or a job list or a commit the workflows were read at that changed,
answers 409 with code run_changed; read the run again, which lists
what LavaFlow found. The response is the run, 202 while it is
queued. LavaFlow reads the workflows again before it opens the pull
request, and once more as it pushes the fix: a job you didn't read, a
new commit on a branch the workflows were read on, even one that
changes no job, or a production branch other than the one you read
them on holds the fix again with a new list.

Opening a fix lets its pull request open, nothing more. LavaFlow
starts no CI on it and never merges it, as for every fix opened past
ungated workflows; a person pushes to the branch or merges it. The
pull request's description names who opened it and lists the jobs.
One exception: when LavaFlow's read before the pull request opens
finds no job that runs the fix before a person approves it, because
the workflows were gated since you read them, the fix opens as any
other fix and follows the project's merge settings. A run whose
held_workflows lists no job opens the same way.

Only the project's owner can open a fix, as a person, while their
account is active: with a sign-in session, a volcano login token
whose sign-in is live, or a platform token that expires. Their GitHub
account must be able to push to the project's repository. A project
access token, a request made through MCP, a platform token that never
expires, and a sign-in that ended get 403 with code
person_required. Opening a fix uses one of the run's attempts: the
attempt that opens it is one of the run's, so a run held again on its
last attempt can't be opened again. It starts no new run and counts
toward no run limit.
' to 'Opens the pull request for a fix LavaFlow held because the
repository's workflows could run it with the repository's secrets
before a person approves it (pull_request_skipped: ungated_workflows). Read the run first: send its id as run_id,
with the diff_sha256 and held_workflows.jobs_sha256 it served, to
say you read that diff and that list of jobs. LavaFlow opens the fix it
saved, exactly as reviewed, past those jobs only. It writes no new
fix.

Right before it queues the run, LavaFlow serves the diff again and
reads the workflows again. A diff served differently since you read
it, or a job list or a commit the workflows were read at that changed,
answers 409 with code run_changed; read the run again, which lists
what LavaFlow found. The response is the run, 202 while it is
queued. LavaFlow reads the workflows again before it opens the pull
request, and once more as it pushes the fix: a job you didn't read, a
new commit on a branch the workflows were read on, even one that
changes no job, or a production branch other than the one you read
them on holds the fix again with a new list.

Opening a fix lets its pull request open, nothing more. LavaFlow
starts no CI on it and never merges it, as for every fix opened past
ungated workflows; a person pushes to the branch or merges it. The
pull request's description names who opened it and lists the jobs.
One exception: when LavaFlow's read before the pull request opens
finds no job that runs the fix before a person approves it, because
the workflows were gated since you read them, the fix opens as any
other fix and follows the project's merge settings. A run whose
held_workflows lists no job opens the same way.

Only the project's owner can open a fix, as a person, while their
account is active: with a volcano login token
whose sign-in is live, or a platform token that expires. Their GitHub
account must be able to push to the project's repository. A project
access token, a request made through MCP, a platform token that never
expires, and a sign-in that ended get 403 with code
person_required. Opening a fix uses one of the run's attempts: the
attempt that opens it is one of the run's, so a run held again on its
last attempt can't be opened again. It starts no new run and counts
toward no run limit.
'

• Responses changed
  • Modified response: 202
    • Content changed
      • Modified media type: application/json
        • Schema changed
          • Property 'AllOf' changed
            • Modified schema: #/components/schemas/LavaflowRunSummary
              • Required changed
                • New required property: fix_outcome
                • New required property: lineage
              • Properties changed
                • New property: fix_outcome
                • New property: fix_summary
                • New property: lineage
                • Modified property: category
                  • Property 'AllOf' changed
                  • Modified schema: #/components/schemas/LavaflowRunCategory
                  • Description changed from 'What kind of problem the run works on. bug: the project's code is wrong. performance: the code is too slow or uses too much. security: the code exposes data or access it shouldn't. improvement: the code mishandles an edge case or an outside failure. configuration: a setting, variable or manifest value is wrong or missing. dependency: a package or its version causes it. external: a service outside the project fails and no repository change is right. A Code Quality run's is its finding's, bug or improvement. Any other run's is dependency or configuration for a fix that changes only such files, else the kind its diagnosis names. New values may appear; treat an unknown value as uncategorized.' to 'What kind of problem the run works on. bug: the project's code is wrong. performance: the code is too slow or uses too much. security: the code exposes data or access it shouldn't. improvement: the code mishandles an edge case or an outside failure, or, for a reported problem's run, its reporter asked for new content or functionality (diagnosis.requested). configuration: a setting, variable or manifest value is wrong or missing. dependency: a package or its version causes it. external: a service outside the project fails and no repository change is right. A Code Quality run's is its finding's, bug or improvement. Any other run's is dependency or configuration for a fix that changes only such files, else the kind its diagnosis names. New values may appear; treat an unknown value as uncategorized.'
                • Modified property: issue
                  • Property 'AllOf' changed
                  • Modified schema: #/components/schemas/LavaflowIssueSummary
                  • Properties changed
                  • New property: severity
                  • Modified property: source
                  • Description changed from 'Where the issue came from: runtime for errors your code logged, code_quality for a LavaFlow Code Quality finding in code a deploy changed, build for deploys of one function or frontend that failed in its own build step, or report for a problem reported for the project, such as through Slack. A code_quality issue's error_type is the finding's rule, its culprit the enclosing function and file, and its event_count the scans that found it. A build issue's title is the build's first error, its error_type the tool's code, such as TS2322 or npm ETARGET, its culprit the error's file:line, its event_count the failed deploys, and its last_deployment_id the latest of them. A later deploy that builds resolves it. Deploys Volcano failed, such as a timeout or a refused build, never make one.' to 'Where the issue came from: runtime for errors your code logged, code_quality for a LavaFlow Code Quality finding in code a deploy changed, build for deploys of one function or frontend that failed in its own build step, report for a problem reported for the project, such as through Slack, or request for an issue a person wrote with POST /issues. A later deploy that builds resolves a build issue. Deploys Volcano failed, such as a timeout or a refused build, never make one.'
                  • New enum values: [request]
                • Modified property: merge
                  • Property 'AllOf' changed
                  • Modified schema: #/components/schemas/LavaflowMerge
                  • Description changed from 'Where the run's merge stands. Present for a run that may merge its fix, once its pull request opens.' to 'Where the run's merge stands. Present for a run that may merge its fix, once its pull request opens, and for a run whose fix a person merges (its autonomy is open_pr, merging was unavailable when it opened, or the run may only open a pull request) that opened ready for review: LavaFlow starts that fix's CI once, then holds it for person_merges and never merges it.'
                  • Properties changed
                  • Modified property: hold_reasons
                  • Items changed
                  • Properties changed
                  • Modified property: code
                  • Description changed from 'Why the fix is held. client_reported_commit: the fix is built on a commit Volcano can't tie to a push. path: it changes a path in human_review_paths, or deploy or infrastructure configuration Volcano always holds, such as volcano-config.yaml, Terraform files, a YAML or JSON file that declares a resource, a YAML template that mentions apiVersion or kind, a file in a Helm chart or Kustomize directory, or, in a repository too large to read in full, any file no other path reason holds. sensitive_path: it changes another path Volcano always holds: authentication or authorization code, Next.js middleware included; secret, key, certificate or cryptography files; a coding agent's instructions or settings, or Git hook configuration; CI configuration; a dependency manifest or lockfile, or a package.json change to what installs or its install scripts; or runtime, container or other configuration files. label: the pull request has the needs-human-review label. no_checks: no CI ran on it. required_check_skipped: a required check was skipped. no_required_checks: the base branch requires no check, so passing checks alone don't vouch for the fix. changes_requested: a reviewer requested changes. repository_requires_approval: the repository requires an approving review. person_commits: someone other than LavaFlow pushed to the fix's branch. rules_bypass: the Volcano GitHub App can bypass a ruleset on the base branch. unchecked_rules: the base branch has a rule LavaFlow doesn't check, such as required signatures. commit_convention: no title can meet the repository's commit convention. ungated_workflows: the fix opened past workflows that can run it with the repository's secrets before a person approves it, as the project's owner allowed, or LavaFlow couldn't check its workflows, so LavaFlow never starts its CI or merges it. lineage_undoes_parent: the fix follows up an earlier LavaFlow fix and deletes or changes lines that fix added, which could undo it. lineage_cap: the fix's lineage opened as many pull requests as it may. lineage_held: an earlier pull request in the fix's lineage was held, stopped or closed. recent_regressions: fixes LavaFlow merged in the project recently caused new errors. Other codes name a concern LavaFlow's reviewers raised. New codes may appear.' to 'Why the fix is held. client_reported_commit: the fix is built on a commit Volcano can't tie to a push. path: it changes a path in human_review_paths, or deploy or infrastructure configuration Volcano always holds, such as volcano-config.yaml, Terraform files, a YAML or JSON file that declares a resource, a YAML template that mentions apiVersion or kind, a file in a Helm chart or Kustomize directory, or, in a repository too large to read in full, any file no other path reason holds. sensitive_path: it changes another path Volcano always holds: authentication or authorization code, Next.js middleware included; secret, key, certificate or cryptography files; a coding agent's instructions or settings, or Git hook configuration; CI configuration; a dependency manifest or lockfile, or a package.json change to what installs or its install scripts; or runtime, container or other configuration files. label: the pull request has the needs-human-review label. no_checks: no CI ran on it. required_check_skipped: a required check was skipped. no_required_checks: the base branch requires no check, so passing checks alone don't vouch for the fix. changes_requested: a reviewer requested changes. repository_requires_approval: the repository requires an approving review. person_commits: someone other than LavaFlow pushed to the fix's branch. rules_bypass: the Volcano GitHub App can bypass a ruleset on the base branch. unchecked_rules: the base branch has a rule LavaFlow doesn't check, such as required signatures. On a fix a person merges it names only rules that kept LavaFlow from starting the fix's CI, such as code_scanning or workflows, or that LavaFlow couldn't read them. commit_convention: no title can meet the repository's commit convention. ungated_workflows: the fix opened past workflows that can run it with the repository's secrets before a person approves it, as the project's owner allowed, or LavaFlow couldn't check its workflows, or, when LavaFlow was about to start its CI or add it to a merge queue, a workflow could run it with those secrets before a person approves it or couldn't be read, so LavaFlow takes it no further and never merges it. A fix held for another reason before its CI starts lists it too when that check, run without starting CI, finds such a workflow or can't finish. ci_outside_actions: when LavaFlow was about to start the fix's CI, the repository could run CI, a build or a preview outside GitHub Actions: the root of the fix's tree or its base branch's holds another service's configuration, such as .travis.yml, .circleci/ or netlify.toml, which paths names, another app reported checks or statuses on the base branch, or LavaFlow couldn't read them in full. LavaFlow starts CI only when it finds no sign of CI outside GitHub Actions, so it never starts this fix's CI or merges it. lineage_undoes_parent: the fix follows up an earlier LavaFlow fix and deletes or changes lines that fix added, which could undo it. lineage_cap: the fix's lineage opened as many pull requests as it may. lineage_held: an earlier pull request in the fix's lineage was held, stopped or closed; one a person merges holds it only when closed. recent_regressions: fixes LavaFlow merged in the project recently caused new errors. no_test: the fix changes code the repository tests and adds no test, because testing it needs test infrastructure the repository doesn't have or the change has no effect a test can observe. choices_to_confirm: the fix states behavior it decides beyond stopping the error, listed in the run's choices and, on a private repository, under Choices to confirm in the pull request's description, for a person to confirm, and LavaFlow's reviewers didn't all mark each choice as needing no person. It never applies alongside person_merges: the person confirms the choices while reviewing the fix. risky_change: the fix adds or removes a line that converts a value, such as with float() or parseInt(), in a file that names a rate limit or quota, authentication or authorization, or money, so values such as NaN, Infinity or a negative number could get past a check there; paths names the files. review_notes: LavaFlow's reviewers passed the fix, but its review's last round left notes, findings below major that a later round no longer sends back for revision, such as a decision the fix makes without stating it. person_merges: a person reviews and merges the fix, because the project's autonomy is open_pr, merging was unavailable when it opened, or its run may only open a pull request; LavaFlow ran the fix's CI once first unless another reason, or the CI start's own checks, stopped it. Other codes name a concern LavaFlow's reviewers raised. New codes may appear.'
                  • Modified property: paths
                  • Description changed from 'The changed paths that matched, for a path code.' to 'The changed paths that matched, for a path code. For ci_outside_actions, the entries at the repository's root that another CI or preview service reads, whether or not the fix changes them. "" for a path that holds a control character, one of the project's secret values or a secret gitleaks detects.'
                  • Modified property: question
                  • Description changed from 'What a person decides before merging the fix, written to show as given.' to 'Why LavaFlow holds the fix and what to check before you merge it, in one or two sentences to show as given. A reviewer's reason is a question for you to answer. Reads Hidden: this field matched a secret. when it holds one of the project's secret values or a secret gitleaks detects, or when one of its paths reads "". Every question read

Report truncated; see the source commit for the complete contract diff.

Validation

• Contract generation completed in the source workflow run.
• Target repository CI validates the generated result.

[CLAassistant]

All committers have signed the CLA.

[github-actions]

⚪ P3: Show omits the choices and findings referenced by new holds

The new holds can ask users to inspect choices and review.open_findings, but LavaflowRun in internal/output/lavaflow.go displays neither. A user following the hold must discover --json to read them. Include the relevant choices and review findings in text output.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: TypeScript discovery omits the newly supported TSX entry

The contract now lists index.tsx as a compiled Node.js entry, but internal/function/typescript.go excludes .tsx, and docs/functions.md says those files are not functions. A directory containing only index.tsx is therefore skipped by CLI discovery. Extend discovery and update the guide.

_{Found by gpt-6.1-sol}

[github-actions]

🟡 P2: Turning LavaFlow on now starts runs on up to 5 existing issues, but neither enable nor the guide says so

The PATCH and PUT descriptions now say a turn-on from off by the owner starts runs for up to 5 recent open exception issues. EnableDisclosure (internal/lavaflow/lavaflow.go:342) mentions only the AI disclosure and data handling. docs/lavaflow.md:341-343 still tells users to start a run themselves for an issue recorded before LavaFlow was turned on. A user who confirms enable gets fix runs, and possibly pull requests, they were not told about. Add this to the enable disclosure and to the guide.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: show skip-reason text is outdated for pull_request_open and source_unavailable

pull_request_open now also covers a merged fix that isn't deployed yet, but show (internal/output/lavaflow.go:518) says another PR "is open. Review or close it first." source_unavailable now carries source_unavailable.reason, with specific recovery steps (uncommitted_changes, deployment_unattributed, …). show still prints one fixed piece of advice about the repository connection.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: A paused CI start on an open_pr fix prints as "paused while merging is off"

For a fix a person merges, paused now means LavaFlow's CI start is paused, whatever merging does. lavaflowMergeReason (internal/output/lavaflow.go:607) always prints "paused while merging is off", and the guide describes Merge: only under autonomy merge.

_{Found by claude-opus-5-5}

[github-actions]

🟡 P2: Handle the preview variable-write conflict in whole-project deploys

With a promoted function preview and an env-file change affecting that function, the new 409 stops variablescmd.Deploy. internal/cmd/deploy/plan.go runs this before functions, and runDeploy stops at the first error, so the whole-project deploy never reaches the function deployment that could clear the condition. Add a preflight or specific recovery guidance naming the function deployment or rollback required before retrying.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Show the choices and findings referenced by new holds

The new holds ask users to inspect choices and review.open_findings, but LavaflowRun in internal/output/lavaflow.go displays neither. Users following a hold must discover --json to read the relevant material. Include those choices and findings in text output.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Guide omits the new merge prerequisites: an App reinstall resets merge, and the base branch must require a status check

The contract now says two new things:

• Reaching the repository through another GitHub App installation, including after a reinstall of the App, changes autonomy from merge to open_pr.
• LavaFlow merges only into a base branch that requires at least one status check (line 32290).

docs/lavaflow.md:205-224 and MergeDisclosure mention only connecting another repository. Owners can lose merge, or see every fix held with no_required_checks, without knowing why.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Failed builds now count as exceptions that start runs on their own, but the help and the guide say otherwise

exception is now true for every build issue, so failed deploy builds start LavaFlow runs on their own.

The runs start help (internal/cmd/lavaflow/runs_start.go:25-27) and docs/lavaflow.md:341-342 still say runs start on their own "only for issues that hold an exception your code threw or logged".

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: New variables 409 stops volcano cloud deploy before it reaches the function step

internal/cmd/deploy/plan.go:139-146 runs the variables step before functions, and deploy.go:140-141 stops at the first error. With an env file that changes a function a promoted preview serves, the new 409 aborts the whole deploy. The deploy never reaches the function step that would clear the condition.

The resume hint then tells the user to run variables deploy again, which fails the same way.

Fix: add specific recovery guidance, or a preflight check.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Include failed builds in automatic-run guidance

Build issues now have exception: true, making them eligible for automatic LavaFlow runs. The runs start help in internal/cmd/lavaflow/runs_start.go:25 and docs/lavaflow.md:341 still describe automatic runs only for exceptions thrown or logged by application code. Include failed builds in that explanation.

_{Found by gpt-6.1-sol}

[github-actions]

🟡 P2: Turning LavaFlow on now starts runs on up to 5 existing issues, but enable and the guide don't say so

The PATCH settings description now says that turning LavaFlow on, from off, "also starts runs for up to 5 open issues with exception: true…" when the owner saves it with a live volcano login token or an expiring platform token. That is exactly what volcano cloud lavaflow enable sends.

Neither the enable help and disclosure (internal/cmd/lavaflow/enable.go:35-44, internal/lavaflow/lavaflow.go) nor the guide's "Turn it on" section (docs/lavaflow.md:90-115) mentions this. docs/lavaflow.md:342-344 still tells users to start runs themselves for issues recorded before LavaFlow was turned on.

A user who confirms enable doesn't learn that runs, and possibly pull requests, start right away. Update the disclosure and the guide.

_{Found by claude-opus-5-5}

[github-actions]

🟡 P2: Guide omits the new automatic-merge requirements

The settings contract adds two rules:

• LavaFlow "merges only into a base branch that requires at least one status check, and holds every fix with no_required_checks on any other".
• autonomy drops from merge to open_pr when the project "reaches its repository through another Volcano GitHub App installation… Reconnecting after a reinstall of the App counts as another installation."

docs/lavaflow.md:186-224 ("Merge fixes") mentions neither. Lines 216-219 name only connecting another repository as resetting merge.

Users who turn on merge against a branch without required checks, or who reinstall the App, will see every fix held, or autonomy silently back at open_pr, with no documented reason. Update the guide.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: A plain function deploy now silently takes traffic off a promoted preview

The contract now says a successful function deployment "cleared the preview pointers", so volcano cloud functions deploy, and step 3 of volcano cloud deploy, return traffic to the function's own build.

Frontends behave the opposite way: they refuse with frontend_served_by_candidate, as docs/frontends.md:287-288 documents. The CLI neither warns about this nor mentions it in docs/functions.md, so someone who promoted a preview in the dashboard can undo it unknowingly.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Guide says merges aren't counted, but stats --json now includes merge outcomes

LavaflowStats gains outcomes (LavaflowOutcomes), which stats --json now outputs because the CLI re-encodes the regenerated struct. docs/lavaflow.md:315 still says "Merges aren't counted".

Relatedly, a run's title (line 32686) can now be null when it may contain a credential, but docs/lavaflow.md:380-382 says - appears only until LavaFlow has a title.

_{Found by claude-opus-5-5}

[github-actions]

🟡 P2: Guide doesn't say a GitHub App reinstall drops merge to open_pr

The settings contract now says autonomy drops from merge to open_pr when the project reaches its repository through another Volcano GitHub App installation, and that reconnecting after a reinstall counts as another installation. docs/lavaflow.md:216-219 names only connecting another repository as resetting merge. Owners who reinstall the App will find autonomy back at open_pr with no documented reason. Add this trigger, and the need to turn merge on again, to the guide.

_{Found by claude-opus-5-5}

[github-actions]

🟡 P2: Document that a function deployment replaces the promoted preview

A successful function deployment now clears the preview pointers and returns traffic to the function's own build. This affects functions deploy and the function step of whole-project deploys, but docs/functions.md does not explain it. Document the traffic switch and its effect on preview rollback state alongside deployment behavior.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Document the separate outcome counts in stats JSON

stats --json now includes the optional outcomes object through the regenerated struct, but docs/lavaflow.md still broadly says merges aren't counted. Distinguish activity counts from outcome counts and explain unavailable coverage and null values.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Explain filtered titles in the run-list guide

The updated title filtering can return null after a diagnosis or fix exists. docs/lavaflow.md says the list shows - only until LavaFlow has a title, which no longer explains completed runs with filtered titles. Mention this additional meaning.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Merge guide misses new conditions that drop or hold merging (App reinstall, base branch without required checks)

The contract now says two things the guide doesn't:

• Reaching the repository through another Volcano GitHub App installation, including after a reinstall, drops merge back to open_pr.
• LavaFlow merges only into a base branch that requires at least one status check, and otherwise holds every fix with no_required_checks (lines 10293, 32124).

docs/lavaflow.md:186-224 names only a change of repository, and doesn't mention the required-check condition. Users may not understand why autonomy changed or why every fix is held.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Filter empty hold-reason paths before formatting

A hold reason's paths now uses "" for a path that holds a secret. internal/output/lavaflow.go:609-611 joins paths as given, so show prints () or (, a.go). Skip empty entries, or print a placeholder such as "a withheld path".

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Add recovery guidance for preview-blocked whole-project deploys

With a promoted function preview and an affected env-file change, the variables step in internal/cmd/deploy/plan.go fails before the function deployment step. runDeploy then stops, and its resume hint repeats the variables command. Explain that the function must first be deployed or rolled back, or detect this prerequisite before starting.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Filter empty hold-reason paths before formatting

The contract now permits empty entries in hold-reason paths. lavaflowMergeLines and cleanList in internal/output/lavaflow.go render these as empty parentheses or stray separators. Remove empty display paths before deciding whether to append the path suffix.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Hold-reason paths can now hold ""; filter empty paths before formatting

paths entries now read "" when hidden. lavaflowMergeLines (internal/output/lavaflow.go:609-611) joins them unfiltered, so the output can read (, src/x.ts) or (). Skip empty entries.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Filter empty hold-reason paths before formatting

The contract now permits empty entries in hold_reasons.paths. lavaflowMergeLines in internal/output/lavaflow.go checks only the slice length before formatting, producing () or empty comma-separated entries. Filter empty paths before deciding whether to append the parenthesized list.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: Repository checks can now pass or fail, but show's fallback and comment still assume they never run

LavaflowRepositoryChecks now has passed, failed and no_checks_found statuses and a commands list. lavaflowRepositoryChecks (internal/output/lavaflow.go:290-298) still says in its comment that "the API has no status for checks that ran yet". When message is empty it falls back to "The repository's tests didn't run.", whatever the status. It also never shows the failing command or its output. Base the fallback on status, and list failed commands.

_{Found by claude-opus-5-5}

[github-actions]

⚪ P3: Whole-project deploy recovery omits the preview prerequisite

With a promoted function preview and an affected env-file change, the variables step in internal/cmd/deploy/plan.go receives the new 409 before reaching function deployment. The fallback commands repeat the variables operation first. Add specific recovery guidance explaining that the function must first be deployed separately or rolled back.

_{Found by gpt-6.1-sol}

[github-actions]

⚪ P3: The required companion documentation PR is not linked

The supplied PR description and comments contain no companion documentation PR link. Root AGENTS.md requires linked updates in Kong/volcano-docs/content/cli for user-facing changes. Link updates covering LavaFlow execution changes and function-preview effects on deployment, variables, and source export.

_{Found by gpt-6.1-sol}

[github-actions]

AI review: re-assess the approach

PR author, the AI review has found P0-P2 problems in 14 rounds in a row, through c535cab, since this PR was last marked ready for review. When each fix brings new findings, the approach is usually the problem rather than the next fix, so the AI review moved this PR back to draft, where it reviews no pushes, until you decide how to go on.

Consider:

• Split it into smaller PRs that each review cleanly.
• Simplify the design, so there is less that can go wrong.
• Rethink the approach where the findings keep landing in the same place.
• Push back on findings you think are wrong: reply on each with a reason, or the follow-up work it waits for, and the next round reads it.

Coding agents: stop here and do not push another fix for these findings. Tell the author this PR did not converge after 14 AI review rounds, summarize the open findings and where they cluster, recommend one of the options above, and wait for the author's decision before changing the code or marking the PR ready for review.

Marking the PR ready for review starts a new set of 3 rounds with a review of the current head. To accept the findings as they stand, mark it ready, and once that review finishes, add the ai-review-override label.