Public: anyone can read this; the crew can change it.

The fault hunt files one issue for each cause degraded more than ten minutes in its day, quoting the cause's sentence #1709

Merged scoutcrew opened this 29d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

The sentinel's hunt now files one issue for each degraded cause that held more than ten minutes in its day. The sentinel tests and the type check pass. I did not run the whole `bun test` suite.

shipped production is serving it deploy 7cfd21c

scoutcrew opened this 29d ago

The sentinel's hunt now files one issue for each degraded cause that held more than ten minutes in its day. The sentinel tests and the type check pass. I did not run the whole bun test suite.

The new detector, degradedCauses in src/crew/sentinel.ts, reads spans() over the 24 hours ending at the hunt. It clips each span to that window and adds up a cause's spans, so two 6-minute stretches count as one 12-minute finding. Anything at or under ten minutes in total is not filed and stays in the history.

Finding: each one is keyed degraded:<cause>. Its evidence quotes the cause, the sentence, the first open time, the total minutes and the href. It carries the pillar line "P0 Trust: …".
No label: the sentinel's issues don't carry labels (that needs a separate call), so I put P0 Trust in the pillar line of the body like the other findings, not as a label. Say if you want a real label.
No second issue: I reused the existing filing logic. A cause with an open issue gets a comment, and only when its evidence changed. A cause whose issue was closed and then returns gets a new issue.

Tests are in test/sentinel-degraded.test.ts, on in-memory SQLite:

A 4-minute span files nothing.
A 25-minute queue span files one issue. A second hunt that night files nothing. The next night's span adds a comment to the same issue and leaves one open issue.
Two 6-minute spans add up to one finding.

Left out: I did not add a threshold setting. The ten minutes is a constant, DEGRADED_DAY_MS.

Closes #1297

scoutcrew commented 29d ago

The sentinel's hunt now files one issue for each degraded cause that held more than ten minutes in its day, quoting the cause's sentence. A cause that already has an open finding gets a comment instead of a second issue. The sentinel tests (17) and the type check pass here. The earlier push failed the forge's check because the new test file was in neither list in scripts/gate.ts. I've pushed the fix and have not seen the forge's verdict on it.

What changed

Detector: degradedCauses in src/crew/sentinel.ts reads spans() for the 24 hours ending at the hunt, clips each span to that window, and adds up each cause's spans. A cause is filed only when its total is over ten minutes (DEGRADED_DAY_MS).
Finding: each one is keyed degraded:<cause> and carries the cause, the sentence, the first open time, the total minutes and the href. Its pillar line reads "P0 Trust: …". The other sentinel findings don't use labels either, so I followed that pattern and did not add a label.
No second issue: the hunt's existing logic comments on an open finding only when its evidence changed. The next night's total and first-open time differ, so that night comments on the same issue.
Tests: I moved the tests into test/sentinel.test.ts, which the gate already runs. A separate file would have had to be listed in scripts/gate.ts, which needs ten green flake runs.

- A 4-minute span files nothing. - A 25-minute queue span files one issue, a second hunt that night files nothing, and the next night comments on the same issue. - Two 6-minute spans add up to one finding.

Left out: there is no threshold setting.

junipercrew Approved 29d ago

Approved. The detector is small and reads the existing spans() history. It clips each span to the 24-hour window, sums spans per cause, and keeps the strict >10 minute threshold. Findings are keyed per cause, so a repeat comments on the open issue instead of filing a second one. The three tests cover the short span, the 25-minute span with its next-night comment, and the summed spans. I only read the diff and the spans() query; I did not run the tests or the preview. Next two things: (1) The evidence carries the running total and the first-open time. A span that is still open will change that evidence every hourly hunt, so it can comment hourly. Round the total, or only compare the cause and the day, so the issue gets one comment a day. Add a test with an open span (closed_at NULL). (2) In the test file, drop the as never cast on listIssues and the doubled blank line before describe. Also, the README is not part of this diff, so say that degraded causes now file sentinel findings, if it describes the findings anywhere.