Capture Ends With Triage

---
name: capture-ends-with-triage
description: "Un pipeline programado que solo vuelca datos crudos obliga al humano a sintetizar, y por eso se omite. Todo capture debe cerrar con un paso de TRIAGE que diagnostique causa y siguiente accion. Aplica al construir o revisar cualquier job periodico."
metadata:
  type: reference
---

# A capture pipeline must end with a triage, not a data dump

A daily job that captures Teams threads, CI runs, PRs, tickets, and calendar into files is only half a tool. The data is there, but nobody reads ten folders every morning. The operator still has to ask "what needs me today?" by hand, which means the answer arrives late or never. A review request sits unanswered, a red build looks like noise, an @mention scrolls away.

The capture is not the deliverable. The **action digest** is.

## The rule

Every periodic capture pipeline ends with a triage step that runs last, after capture, and produces a short operator digest: what changed, what is broken, what is waiting on the operator. Persist it (`output/triage/<date>.md`) and print it.

## Triage, not a second pile of data

The trap is a digest that just relists the raw data ("here are 16 pipelines, 40 PRs, 200 messages"). That is a second thing to triage. A real triage **resolves each item to a cause and a next action**:

- A red CI pipeline is diagnosed by reading its timeline: a failed *task* (needs a code fix, point at the stage) versus an expired/rejected *approval gate* (just re-run and approve, no code change). These look identical in a status list and demand opposite responses.
- A PR is surfaced only if the operator is a reviewer who has not voted yet (an actual pending review), not every open PR.
- An @mention is the line of text, with its source, filtered to "today", so it reads in seconds.
- A work item is surfaced if it is assigned and still open.

The test: can the operator act from the digest alone, without opening the raw files? If not, it is a dump, not a triage.

## Mechanics that keep it honest

- **Runs last, as its own step** in the orchestrator, so it sees the freshly captured data and can also hit live APIs (CI, PR, ticket) for current state.
- **Exit 0 on success even when there are action items.** Having todos is not a service failure. Conflating "you have work" with "the job broke" trains the operator to ignore the signal. Action items live in the digest, not the exit code.
- **Owner-parameterized** (`TRIAGE_OWNER`, org, project in config) so the same step serves whoever runs it.
- **Diagnosis is cheap and worth it**: one extra API call per red item (its timeline/detail) turns "something is red" into "this is why and this is what you do".

## Why it matters

The recurring failure is not a missing scraper, it is a missing synthesis. When the operator asks "why didn't you tell me about X, the data was right there", the data being there is exactly the problem. Captured-but-unsynthesized is invisible. The triage is what makes the capture pay off.

Related: [[do-not-ask-to-pause]] (surface the next action, do not wait to be asked), [[verify-root-cause-before-claiming]] (diagnose the real cause, here per red item), [[reflexes-over-discipline]] (wire it as a step, do not rely on remembering to synthesize).