Release 0.3.0 · timmo001/triage

Issues now have states, so you can resolve or mute them, and see when a fixed one comes back.

Issue states

Each issue is new, ongoing, regressed, resolved or muted. Issues are new for a week after they're first seen, then ongoing.
triage resolve <issue>... resolves issues once they're fixed. If one happens again after that, it opens as regressed for a week, and decision models look at it again.
triage mute <issue>... hides an issue from decision and language models however often it happens. triage reopen <issue>... undoes either.
Add --server <url> to change a remote server's issues as the admin in TRIAGE_ADMIN_TOKEN, such as the Home Assistant app.
triage issues and the API show each issue's state, and the API has PUT /api/issues/:id/status.
The server's database is migrated on start. Existing issues start open.

collect --follow, which the agent runs, only read the current boot, because journalctl --follow does. A new agent got the last few events instead of its history, and one whose machine was off overnight skipped the end of the previous boot. It now catches up with a plain read before following.

Server image: ghcr.io/timmo001/triage:0.3.0
Home Assistant app image: ghcr.io/timmo001/triage-app:0.3.0
@timmo001/effect-triage and @timmo001/effect-triage-client 0.3.0 on npm and JSR. Issue has a state, which decodes as ongoing from older servers, and the API has the new status endpoint.

Full Changelog: 0.2.1...0.3.0