--- id: PIPE-2 family: RT-PIPE level: extended profiles: [runtime] posture: normative-target added: "1.0" changed: "1.0" source: https://flowdrop.io/spec/rules/rt-pipe/pipe-2 specification: FlowDrop Workflow Specification 1.0-draft licence: CC BY 4.0 --- # PIPE-2 — The job status summary has one shape on every path *RT-PIPE (Part II) · level: extended · profiles: runtime · added in 1.0* ## The rule > **Normative.** This is the rule. > > 1. A run's `job_status_summary` is `total` followed by one integer counter per defined job status, in a fixed order, with no status omitted. > > 2. The same key set and order is published when the jobs are read successfully, when the run cannot be found, and when the read fails, the latter two all-zero. > > 3. The job API's own `status_summary` publishes that same shape. ## What it means A run with no jobs yet, and a run whose jobs could not be read at all, both report the identical set of counters a run that ran normally would report — the same keys, in the same order, only every one of them zero instead of populated. That parity is what lets a caller treat "we do not know yet" and "there is genuinely nothing" the same way it treats "there were zero of every status," rather than having to branch on which of several build paths happened to answer. The counter set itself is derived from nothing narrower than every defined job status, so a status added to the vocabulary later cannot be forgotten by one path while another remembers it. ## Example No jobs have run yet, so every counter is zero and none of the vocabulary's statuses is missing. ```json title="The zeroed summary" verdict="zeroed" {"total": 0, "idle": 0, "pending": 0, "running": 0, "completed": 0, "failed": 0, "cancelled": 0, "skipped": 0, "interrupted": 0} ``` ## Related rules - Names: PIPE-3 - Referenced by: PIPE-3 --- Rule identifiers are permanent and are never renumbered. This specification carries no implementation status: each implementation publishes its own standing against these rules. Licensed CC BY 4.0.