Skip to content
Treaty

dev.superpipeline.gate.decision.v1

A person’s answer to a v1 gate: an ordinary m.room.message carrying suite_event_type, one of the three GateDecision ids, and an m.reference to the gate’s message (m.in_reply_to is a quoting hint and never binds). Readers ignore properties they do not know.

How it rides

Section titled “How it rides”

An m.room.message whose content carries suite_event_type: "dev.superpipeline.gate.decision.v1".

Who sends it, who reads it

Section titled “Who sends it, who reads it”

The carrier is whichever service carries the board’s chat: AgentPod’s hub, or SuperExchange for a board that has moved to it.

Fields

Section titled “Fields”
Field Type Required Description Constraints
msgtype "m.text" no
body string yes
schema_version integer yes at least 1
gate_id string yes at least 1 character
comment string or null no
m.relates_to object yes
m.relates_to.rel_type "m.reference" yes
m.relates_to.event_id string yes at least 1 character
suite_event_type "dev.superpipeline.gate.decision.v1" yes
option_id one of "approve", "request_changes", "reject" yes

Example

Section titled “Example”

From fixtures/matrix-events/examples.json, case “an approval”:

{
  "msgtype": "m.text",
  "body": "Approved — Ship the OAuth change to staging?",
  "schema_version": 1,
  "suite_event_type": "dev.superpipeline.gate.decision.v1",
  "gate_id": "gate_4e8b",
  "option_id": "approve",
  "comment": null,
  "m.relates_to": {
    "rel_type": "m.reference",
    "event_id": "$gateEventId"
  }
}

The corpus has 2 valid cases in all:

request_changes, carrying the feedback that becomes the rework's context 
{
  "msgtype": "m.text",
  "body": "Requested changes — Ship the OAuth change to staging?",
  "schema_version": 1,
  "suite_event_type": "dev.superpipeline.gate.decision.v1",
  "gate_id": "gate_4e8b",
  "option_id": "request_changes",
  "comment": "Add a test for the refresh-token path first.",
  "m.relates_to": {
    "rel_type": "m.reference",
    "event_id": "$gateEventId"
  }
}

Refused

Section titled “Refused”

Each of these must fail. The corpus says why:

  • option_id outside GateDecision (refused by schema)
  • no m.relates_to. The answer names a gate but is bound to no question, so nothing proves the sender saw the gate they claim to answer. (refused by schema)
  • a reply relation rather than a reference. m.in_reply_to is a rendering hint any client sets when quoting; treating it as a decision binding would let an ordinary quoted reply resolve a gate. (refused by schema)
  • missing gate_id — the field resolution actually keys on (refused by schema)

Source

Section titled “Source”