Skip to main content

​
CI-Failure Triage

A failed check leaves you with a log to scroll. Somewhere in thousands of lines is the assertion that failed, the stack frame that threw, or the type error that broke the build — and the job of triage is to find it and say, in plain terms, what went wrong and where. When a build goes red, Sigilix does that read for you. It pulls the failing job’s logs, reads them against the diff that triggered the run, and posts a grounded, inline root-cause comment in file:line terms — anchored to the change that most likely caused the failure, not a copy-paste of the raw log.
CI-failure triage is one of the pipelines the dispatcher routes to. It fires on a check-failure event and writes back to the PR thread, where the developer already is.

​
Log dump vs. grounded root cause

The difference is where the reading happens. Without triage, the log is handed to you and you do the reading. With triage, Sigilix reads the log, correlates it to the diff, and hands you the conclusion. 
# What you'd normally scroll:
FAIL src/billing/discount.test.ts
  ● applyDiscount › clamps negative subtotals to zero

    expected 0, received -150

      46 |   it('clamps negative subtotals to zero', () => {
      47 |     const result = applyDiscount(100, 250);
    > 48 |     expect(result).toBe(0);
         |                    ^
      49 |   });

    at Object.<anonymous> (src/billing/discount.test.ts:48:20)
  ...
  847 more lines

# What Sigilix posts inline on the diff:

**CI-failure root cause** · `jest` job failed

`src/billing/discount.ts:48` — `applyDiscount` returns `subtotal - couponValue`
without clamping at zero. With `applyDiscount(100, 250)` it returns `-150`,
which fails the assertion `expect(result).toBe(0)` in
`src/billing/discount.test.ts:48`.

This is caused by the change to `applyDiscount` in this PR (line 48), which
removed the `Math.max(0, …)` clamp.

Evidence:
- Test output: `expected 0, received -150`
- Diff: clamp removed at `src/billing/discount.ts:48`
The inline comment lands on the diff line responsible, so the fix is one click from the failure.

​
Grounding is enforced on this path

A model asked “why did this build fail?” will always produce a fluent answer — and a fluent wrong answer is worse than a log dump, because it sends the developer down the wrong trail. CI-failure triage is the path where that risk is highest, so it is the path where grounding is enforced.
1

Read the failure, not a vibe

Triage reads the actual job logs — the failing assertion, the stack trace, the compiler error — not a summary of what kind of job it was.
2

Correlate to the diff

The failure evidence is cross-referenced against the change that triggered the run, so the root cause is attributed to a specific line in the PR where possible.
3

Require a citation

The output must cite the failure evidence — the log line and/or the diff line that justify the root cause. A root cause that cannot point at the evidence behind it does not post.
4

Post inline, anchored

The grounded result is posted as an inline comment on the responsible line, with its evidence attached.
This is the same grounding discipline the review path applies through the believability pipeline: a claim that can’t be anchored to cited evidence is suppressed rather than emitted. For CI triage, the evidence is the failure log and the diff — not a confidently-wrong root cause.

​
What it reads

Sigilix reads the logs of the check that failed — test output, build/compile errors, linter output, and stack traces — to locate the concrete failure rather than restating that “the job failed.”
The failure is read against the change under review. This is what lets triage say “caused by the change at line N” instead of just “something is failing” — it correlates the failure to the code that moved.
When the failing line calls into code outside the diff, Sigilix expands context through the code graph so the root cause accounts for the real call path, not just the line that threw.
Prior triage and review history on the repo inform the read — recurring failure shapes and previously-seen causes are part of the context the pipeline reasons against.

​
What you get back

A single inline comment on the PR, attached to the line most likely responsible, containing:
  1. The root cause in file:line terms — what failed and where.
  2. The link to the diff — which change in this PR caused it.
  3. The evidence — the log line and diff line that ground the conclusion.
Because it posts inline rather than as a wall of text, the path from “build is red” to “here’s the line to fix” is short.

How triage works

The shared architecture behind both triage paths.

Issue triage

The other triage path — Linear and Jira issue triage.

The Believability Pipeline

The grounding discipline that keeps triage from emitting confidently-wrong causes.

GitHub

The permissions that let Sigilix read workflow runs and post on the PR.