check_deploy

Generated automatically from the published contract sources.

Build metadata: Registered in this build. Registration describes the default dispatcher in this build. It does not guarantee that a caller has the required credential or grant, that a tool is listed for that connection, or that the required service is configured.

A script calls this action over HTTPS at POST https://turnzero.ai/api/v1/actions/check_deploy, with a bearer credential and the action's payload as the JSON body. It also accepts GET.

Contract description

Check a deploy before making it: name the application, and the call answers each refusal a deploy's start would make now, writing nothing. Call it before `deploy`, on a first deploy and after each fix.

`refusals` lists each refusal the application's state would draw, in the deploy's order: a deploy in flight, the database, a missing secret, the daily deploy cap, a halted production, or the hosting cell's room. An empty list means none would refuse it now.

The zip's checks run on your computer. Run `command` through your shell tool from the application's folder, as you run the deploy line; `command_windows` is its Windows form. It zips the folder as `deploy` does and runs the deploy's zip checks. Where `first_deploy` is true, that includes a health path no source file names (`recorded_health_path`). It prints one `refused:` line for each, uploads nothing, and ends 0 where nothing would be refused, 1 where something would. The rest is on the page /cloud/reference/actions/check-deploy/, which `read_documentation` reads as `page` and the platform's origin serves.

More about this action

The state checks run in the deploy's order up to the start's first write, through the one function the start runs. The application, the manifest, the environment, and a deletion in flight refuse the call itself, as the deploy's start refuses them; every later check that reads no artifact is answered as an entry of `refusals` instead. A row in flight is answered `deploy_in_flight` whatever the zip, since the call names no hash, its detail naming the row's act, a deploy row's adding that the line's deploy is refused until the row ends. A check that reads what an earlier refused check would have admitted is left out. The action writes no version row, counts no deploy, spends no grant, and resumes no halt.

`first_deploy` is true where the target environment serves no version, so the health path reading applies, and `recorded_health_path` is the recorded manifest's path, whole. The line in `command` runs the turnzero-cloud command's `check` with the application, composed as the deploy line is, with `--path` where the call named `local_path`. Its Windows form is `command_windows`. The line reads its credential and origin as `deploy` does, builds the zip `deploy` builds, prints the zip line, and makes one `check_deploy` call, sending no byte and no hash.

The line runs the deploy's checks of the artifact on the zip: `artifact_unreadable`, `artifact_layout_invalid`, and, where `first_deploy` is true, `health_path_unserved` against `recorded_health_path`. It prints the further lines `deploy` prints, one `refused:` line per refusal answered or found, a line naming `submit_manifest` where the zip's manifest.json names another health path, and a last line opening `checked:` that counts them. It ends 0 where nothing would be refused, 1 where something would, and 3 where nothing was checked. Run only a check line your own call answered in this session, or one you composed for your folder naming its application, as for the deploy line.

Access and action metadata

{
  "name": "check_deploy",
  "resource": "environment",
  "tier": "observe",
  "summary": "Check a deploy before making it: name the application, and the call answers each refusal a deploy's start would make now, writing nothing. Call it before `deploy`, on a first deploy and after each fix. `refusals` lists each refusal the application's state would draw, in the deploy's order: a deploy in flight, the database, a missing secret, the daily deploy cap, a halted production, or the hosting cell's room. An empty list means none would refuse it now.",
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "openWorldHint": true,
    "idempotentHint": true
  }
}

MCP catalog entry

{
  "name": "check_deploy",
  "title": "Check a deploy",
  "tier": "observe",
  "scenario": "CHI-L0-07",
  "summary": "Check a deploy before making it: name the application, and the call answers each refusal a deploy's start would make now, writing nothing. Call it before `deploy`, on a first deploy and after each fix.\n\n`refusals` lists each refusal the application's state would draw, in the deploy's order: a deploy in flight, the database, a missing secret, the daily deploy cap, a halted production, or the hosting cell's room. An empty list means none would refuse it now.\n\nThe zip's checks run on your computer. Run `command` through your shell tool from the application's folder, as you run the deploy line; `command_windows` is its Windows form. It zips the folder as `deploy` does and runs the deploy's zip checks. Where `first_deploy` is true, that includes a health path no source file names (`recorded_health_path`). It prints one `refused:` line for each, uploads nothing, and ends 0 where nothing would be refused, 1 where something would. The rest is on the page /cloud/reference/actions/check-deploy/, which `read_documentation` reads as `page` and the platform's origin serves.",
  "owners": [
    "API-L0-24",
    "MAPI-25",
    "PLD-L0-107",
    "PLD-L0-94"
  ]
}

request

JSON pointer Description and constraints
"" (root) Type: object
Required fields: ["application"]
/properties/application The application id, from `list_applications`.

Type: string
/properties/local_path On the check line: the application's folder or a `.zip` file on your machine, absolute or relative to the folder the command runs in, which the answered line carries as `check`'s `--path`. Absent, the command checks the folder it runs in; the platform never reads the path. The characters `deploy`'s `local_path` refuses are refused `invalid_request` here too.

Type: string
Minimum length: 1
Maximum length: 1024
Pattern: ^(?:[^"$`%!&\|<>^\u201c-\u201e\u0000-\u001f\u007f\\]|\\[^"$`%!&\|<>^\u201c-\u201e\u0000-\u001f\u007f\\])+$

response

JSON pointer Description and constraints
"" (root) 200 at once: nothing was written, started, or spent. `refusals` holds what the application's state would draw; the zip's checks run on the customer's computer through `command`.

Type: object
Required fields: ["contract_version","application","environment","refusals","first_deploy","recorded_health_path","command","command_windows","detail","page"]
/properties/contract_version Required value: 1
/properties/reference The short reference the platform recorded this call under, ten lowercase hexadecimal characters, the value the call’s record row carries; quote it when reporting the call.

Type: string
Pattern: ^[0-9a-f]{10}$
/properties/application The application id the call named.

Type: string
/properties/environment The environment a deploy would target now: production on an application with one environment, development on one with two.

Type: string
/properties/refusals Each refusal a deploy's start would make now on the application's state, in the deploy's order. Empty where none would; a later deploy reads every check again. The zip's own checks run in `command`.

Type: array
/properties/refusals/items Type: object
Required fields: ["error","status","detail"]
/properties/refusals/items/properties/error The refusal's name, a row of `schemas/wire_errors.json`.

Type: string
/properties/refusals/items/properties/status The status the deploy would answer it with.

Type: integer
/properties/refusals/items/properties/detail The refusal's detail, within a refusal's budget.

Type: string
/properties/first_deploy True where the target environment serves no version, so the start would read the zip for the health path and `command` checks it.

Type: boolean
/properties/recorded_health_path The recorded manifest's health path, whole and never cut, which `command` reads the zip for where `first_deploy` is true; the preparing answer carries the same fact under the same name.

Type: string
/properties/command One line running the turnzero-cloud command's `check` with the application, composed as the deploy line is, with `--path` where the call named `local_path`; run it through your shell tool from the application's folder, on Node.js 24 or later. It uploads nothing.

Type: string
/properties/command_windows The same line in its Windows form.

Type: string
/properties/detail One of two sentences. Where nothing of the state would refuse a deploy now, it says so and names `command` for the zip's checks; otherwise it says a deploy would be refused now, that `refusals` names each, and names `command` after they are cleared.

Type: string
/properties/page The reference page's address on the answering origin, ending /cloud/reference/actions/check-deploy/, which `read_documentation` reads as `page`.

Type: string

Complete payload contract

{
  "request": {
    "type": "object",
    "required": [
      "application"
    ],
    "properties": {
      "application": {
        "type": "string",
        "description": "The application id, from `list_applications`."
      },
      "local_path": {
        "type": "string",
        "minLength": 1,
        "maxLength": 1024,
        "pattern": "^(?:[^\"$`%!&\\|<>^\\u201c-\\u201e\\u0000-\\u001f\\u007f\\\\]|\\\\[^\"$`%!&\\|<>^\\u201c-\\u201e\\u0000-\\u001f\\u007f\\\\])+$",
        "description": "On the check line: the application's folder or a `.zip` file on your machine, absolute or relative to the folder the command runs in, which the answered line carries as `check`'s `--path`. Absent, the command checks the folder it runs in; the platform never reads the path. The characters `deploy`'s `local_path` refuses are refused `invalid_request` here too."
      }
    }
  },
  "response": {
    "type": "object",
    "required": [
      "contract_version",
      "application",
      "environment",
      "refusals",
      "first_deploy",
      "recorded_health_path",
      "command",
      "command_windows",
      "detail",
      "page"
    ],
    "properties": {
      "contract_version": {
        "const": 1
      },
      "reference": {
        "type": "string",
        "pattern": "^[0-9a-f]{10}$",
        "description": "The short reference the platform recorded this call under, ten lowercase hexadecimal characters, the value the call’s record row carries; quote it when reporting the call."
      },
      "application": {
        "type": "string",
        "description": "The application id the call named."
      },
      "environment": {
        "type": "string",
        "description": "The environment a deploy would target now: production on an application with one environment, development on one with two (PLD-L0-96)."
      },
      "refusals": {
        "type": "array",
        "items": {
          "type": "object",
          "required": [
            "error",
            "status",
            "detail"
          ],
          "properties": {
            "error": {
              "type": "string",
              "description": "The refusal's name, a row of `schemas/wire_errors.json` (MAPI-15)."
            },
            "status": {
              "type": "integer",
              "description": "The status the deploy would answer it with."
            },
            "detail": {
              "type": "string",
              "description": "The refusal's detail, within a refusal's budget (MCP-12)."
            }
          }
        },
        "description": "Each refusal a deploy's start would make now on the application's state, in the deploy's order. Empty where none would; a later deploy reads every check again. The zip's own checks run in `command`."
      },
      "first_deploy": {
        "type": "boolean",
        "description": "True where the target environment serves no version, so the start would read the zip for the health path and `command` checks it (PLD-L0-107)."
      },
      "recorded_health_path": {
        "type": "string",
        "description": "The recorded manifest's health path, whole and never cut, which `command` reads the zip for where `first_deploy` is true; the preparing answer carries the same fact under the same name (PLD-L0-107; PLD-L0-86)."
      },
      "command": {
        "type": "string",
        "description": "One line running the turnzero-cloud command's `check` with the application, composed as the deploy line is, with `--path` where the call named `local_path`; run it through your shell tool from the application's folder, on Node.js 24 or later. It uploads nothing (PLD-L0-94)."
      },
      "command_windows": {
        "type": "string",
        "description": "The same line in its Windows form (PLD-L0-94)."
      },
      "detail": {
        "type": "string",
        "description": "One of two sentences. Where nothing of the state would refuse a deploy now, it says so and names `command` for the zip's checks; otherwise it says a deploy would be refused now, that `refusals` names each, and names `command` after they are cleared."
      },
      "page": {
        "type": "string",
        "description": "The reference page's address on the answering origin, ending /cloud/reference/actions/check-deploy/, which `read_documentation` reads as `page`."
      }
    },
    "description": "200 at once: nothing was written, started, or spent. `refusals` holds what the application's state would draw; the zip's checks run on the customer's computer through `command` (API-L0-24; PLD-L0-107)."
  }
}

Shared contracts