Skip to content
Treaty

check.failed v1

A check on a card’s arrival at a stage failed, and the card went back to returnedTo (charter 2026-11-09, a gate may be decided by checks). One per failed check. Mirrors SuperPipeline’s CheckFailedBody (apps/api/src/board/views.ts). Readers ignore properties they do not know.

CloudEvents

Section titled “CloudEvents”

Every event below carries dataschema https://raw.githubusercontent.com/SuperJackfruitLabs/treaty/main/schemas/superpipeline/check.failed.v1.json.

Body event CloudEvents type Subject
check.failed com.superjackfruit.superpipeline.check.failed.v1 evt.<workspace>.superpipeline.check.failed

The subject is the NATS subject the relay files it under; <workspace> is the board’s workspace. See the envelope and subjects.

Who sends it, who reads it

Section titled “Who sends it, who reads it”
  • Produced by SuperPipeline, through the relay.
  • Consumed by:
    • SuperExchange: Posts it to the board’s room, for the boards it carries. Receives it through the relay.
    • AgentPod: The hub’s board chat posts it, for the boards it still carries.
    • SuperDispatch: Takes it as a nudge to look at the board soon, on a board opted into scheduling. Reads nothing from its data.

Fields

Section titled “Fields”

Readers ignore properties they do not know, so a field may be added without a new version.

Field Type Required Description Constraints
event "check.failed" yes
boardId string or null yes Null only on a board not yet initialised; a carrier needs it to route the event.
cardId string yes
cardTitle string yes
stageKey string yes
arrivalId string yes The card’s arrival at the stage this check belongs to: one per arrival, so a carrier says each once.
check object yes
check.name string yes
check.provider one of "ci", "verdict" yes
check.status "failed" yes
check.detail string no What the result said.
check.url string no Where the result is.
returnedTo string or null yes The stage the card went back to; null when it could not go back and waits for a person.

Example

Section titled “Example”

From fixtures/superpipeline-events/examples.json, case “returned”:

{
  "event": "check.failed",
  "boardId": "brd_134a0ddb6d434478",
  "cardId": "crd_0f3c9a2b7d4e4a11",
  "cardTitle": "Ship the login page",
  "stageKey": "review",
  "arrivalId": "arr_7e8f9a0b1c2d3e4f",
  "check": {
    "name": "build",
    "provider": "ci",
    "status": "failed",
    "detail": "CI context \"unit\" failed on 3f2a9c1d7e5b",
    "url": "https://ci/unit/1"
  },
  "returnedTo": "build"
}

The corpus has 2 valid cases in all:

parked-no-detail 
{
  "event": "check.failed",
  "boardId": "brd_134a0ddb6d434478",
  "cardId": "crd_0f3c9a2b7d4e4a11",
  "cardTitle": "Ship the login page",
  "stageKey": "review",
  "arrivalId": "arr_7e8f9a0b1c2d3e4f",
  "check": {
    "name": "quality",
    "provider": "verdict",
    "status": "failed"
  },
  "returnedTo": null
}

Refused

Section titled “Refused”

Each of these must fail. The corpus says why:

  • the check’s status is failed
  • the provider is ci or verdict
  • returnedTo is present, null when it could not go back

Source

Section titled “Source”