9 Commits

Author	SHA1	Message	Date
Niklas Ye	79e77fadc6	Let the release skill drive this repo, and let make drive the pipeline ... The release skill only knew repos that deploy an image through a wrapper chart. terdut-tui publishes binaries to a Gitea release and nothing else, so its first two releases were cut by hand. It now has a .release.conf saying KIND=binary, which the skill treats as gate, tag, wait for the pipeline, then check what was published. The gate had to exist as make targets for that: fmt, lint and test, the same three the other repos have. ci.yaml and release.yaml now call them instead of carrying their own copy of gofmt, vet and the tests, so a green gate locally and a green pipeline are the same code and cannot drift. The gofmt handling moved over as written, including the comment on why both of its failure modes need catching; both fail the target, checked with a misformatted file and an unparseable one. The binaries job calls make dist too. DIST_TARGETS is now the one place that says what a release contains, and dist-assets prints the names dist builds so the skill can verify the published release against a list instead of a count. The names are unchanged, and they are the self-updater's contract with every installed binary: internal/updater matches terdut-tui-<tag>-<goos>-<goarch> exactly. CLAUDE.md gains a Release section, including that the annotated tag's message is what appears on the release page. Not run in the pipeline yet: make is in the golang image, as terdut-server's CI relies on, but this repo's workflows only exercise it on the push that carries this commit, and make dist only on the next tag. A failure in the release workflow's test job stops the publish rather than shipping something unchecked.	2026-09-24 08:38:02 +02:00
Niklas Ye	f4ca0059dc	Sign in as a user instead of with an API key ... The web UI signs in with a username and password and holds a session cookie; the TUI was the only client still needing an API key pasted into a config file. It now asks for the same credentials on a form at start. What is kept between runs is the session token, not the password, in session.json under the config directory, mode 0600 and keyed by server URL so one server's token is never offered to another. It resumes on the next start; the server's sessions last 30 days and slide with use. L signs out, which ends the session on the server and deletes the saved one even if the server cannot be reached. The client attaches the cookie by hand instead of using a cookie jar: the server marks it Secure behind https, and a jar drops a Secure cookie it is given over plain http, which would break a local server for no reason. It sends no Authorization header at all, since the server judges a request carrying one on that alone and never falls back to the cookie. Writes go through the server's cross-origin guard, which lets a client that sends neither Origin nor Sec-Fetch-Site through; checked against a real v0.20.1 server for both reads and writes. A 401 from anything means the session is gone (expired, ended from the web UI, or the account disabled), so the TUI returns to the form with the reason, forgets the saved token, and drops what the last session loaded rather than showing it to whoever signs in next. A 403 is a permission and leaves the session alone. The refresh timer is started once, so signing out and in does not leave two running. An account with no password cannot sign in, and the server answers it exactly like a wrong password, so the form's message says a password must be set first. Users created only for API access hit this. Breaking: api_key in config.yaml is no longer used. It is not an error to leave it there; the form says it is ignored. API keys still exist on the server and k in Users still manages them.	2026-09-23 22:15:14 +02:00
Niklas Ye	27008086b0	Follow terdut-server into teams: switch team, per-team schedule ... terdut-server v0.12 made everything team-scoped and v0.20 is what this client now targets. Against it the old client was wrong in three ways: the schedule moved to /api/teams/{id}/schedule, GET /api/schedule/current became a list with one entry per team, and users, incidents, alerts and schedule entries all grew fields the client ignored. T steps through all teams and then each of yours. The header names what is showing, and incident and alert rows gain a Team column when more than one team can appear. team: in config.yaml picks the team to start on, by name or id; an unknown one is reported and falls back to all teams. The schedule is one team's rota, so it shows the active team, or with all teams showing the first one you own. Writes need an owner or an administrator, and the picker offers only the team's members, since the server answers 404 for anybody else. Both are checked up front and the reason goes in the status bar, rather than surfacing as a 403 after the user has picked somebody. Stats are not team-scoped by the server and stay that way here. Users shows an admin/disabled Flags column. Creating and deleting users is administrators only, and topic, keys and password work on your own row or on anyone's for an administrator; the server enforces the same rule, this only explains it before the round trip. The server has no version endpoint, so an older one is recognised by GET /api/teams answering 404, and the TUI says it needs v0.20 or later. Connecting now also loads /api/teams and /api/me with the key, which means a wrong key fails on start instead of on the first list; /healthz does not check it. There is no fallback to the pre-team paths. Rebuilding a table whose column count changes under loaded rows panicked inside bubbles, because it re-renders the old rows on SetColumns. The rows are now cleared first and the cursor put back, so a refresh still does not jump to the top. Escalation ladders, invites, integrations and the admin settings are left to the server's web UI. Checked against a real v0.20.1 server with two teams, an administrator and a plain member. Breaking: requires terdut-server v0.20.0 or later. Use terdut-tui v0.9.x with servers before v0.12.	2026-09-23 21:57:28 +02:00
Niklas Ye	4a579bdbc6	Colour themes, defaulting to gruvbox dark ... Every colour was a 256-colour ANSI index hardcoded in styles.go, so changing the palette meant editing the styles themselves. This puts a semantic token set between the two: styles name roles, a theme supplies the colours. internal/theme holds the twelve tokens, the two built-ins (gruvbox-dark, the new default, and gruvbox-light) and the loader for user themes in ~/.config/terdut-tui/themes/. A user file may 'extends:' a built-in and override only what it cares about, and may shadow a built-in name to tweak it in place. Unknown keys, malformed colours and incomplete themes are refused with a message naming what went wrong. Colours are truecolor hex now: lipgloss downsamples for 256- and 16-colour terminals and honours NO_COLOR, so themes carry no fallbacks of their own. An ANSI index is still accepted for anyone who would rather follow their terminal's own palette. The 21 package-level style vars become a Styles struct on the Model, which is what rule 3 asked for all along; the four free functions in view.go take one as their first argument. The embedded bubbles components are restyled from the same tokens — otherwise a theme would leave a pink selected row and grey help text behind. Note that the table's Cell style deliberately keeps no foreground: bubbles renders cells before wrapping the row in Selected, so a colour there cuts the selection highlight short.	2026-08-20 11:06:36 +02:00
Niklas Ye	6fdb4bbbf8	Move to Gitea: git.ryuvia.com/niklas/terdut-tui ... The module path, the CI pipeline and the self-updater all named GitHub. They now name the Gitea instance everything else already runs on. The workflows are rewritten rather than translated, for the reason recorded in ci.yaml: Gitea's runner image is ubuntu:22.04, whose nodejs is Node 12, so no JS action runs there -- actions/checkout@v4 dies with a SyntaxError before doing anything. Every step is shell and checkout is a plain clone, which this public repo needs no credential for. upload-artifact/download-artifact are JS actions too, and there is no artifact store here, so the job that builds the binaries is the job that publishes them. internal/updater keeps its release and asset types unchanged: Gitea's release payload carries the same tag_name, and its attachments the same name and browser_download_url, so only the URL, the Accept header and one error string move. The asset naming in release.yaml is load-bearing for that matching. This does strand already-installed binaries, which still poll api.github.com. The GitHub repository is left in place and untouched, so they report themselves up to date rather than erroring; its last release is the bridge, and crossing it is a one-time manual download.	2026-08-19 20:41:05 +02:00
Niklas Ye	4740687b96	feat!: stats as a section instead of an overlay ... Stats was the one full-screen view reached by a key of its own rather than by tab, and the interface was less coherent for it. It is now a section sitting third, after Alerts, and behaves like every other one: tab in, tab out, r to refresh. Three things fall out of the move. It auto-refreshes for the first time — the tick handler skips every non-dashboard mode, which is why the overlay never updated while it was open. Its error path no longer forces the queue back into view on a failed fetch, an assumption that only made sense while stats floated above the dashboard. And first-visit loading keys off a statsLoaded flag rather than slice emptiness, because the three empty slices a quiet server returns are a real answer, not a missing one; the loading placeholder is likewise suppressed once something has been drawn, so a background refresh cannot blank the page out from under whoever is reading it. The S key is gone, and with it the ability to peek at statistics from an open incident and land back on it. That round-trip was the only thing statsReturnMode bought, and it was the whole reason stats needed a mode.	2026-08-06 12:46:38 +02:00
Niklas Ye	1140d773f8	feat!: incidents as the primary object ... terdut-server v0.4.0 splits the alerts row into two objects, and the endpoints this client drove for acknowledgement, comments and archiving are gone. Pointing the same screens at the new paths would have missed the point of the split: alerts are now Alertmanager's record, read-only and carrying no human state, while the incident is the thing anyone actually works on. Incidents lead the section list and are what the client opens on. The queue shows severity, status, assignee and age, and the detail view adds what only exists server-side now: the group labels Alertmanager correlated on, the member alerts, and an append-only timeline where system events and notes are interleaved. That timeline is the whole history the server keeps — alert rows are still mutated in place — so rendering it in order matters more than styling it. Actions all move onto the incident: a/A acknowledge, s assign, z/Z snooze, c note, d delete note, x archive, R resolve. Two of those need care rather than a keybinding: - R, not r, resolves, and it asks first. The server treats a manual resolve as terminal: a later occurrence opens a new incident instead of reopening this one, and an alert that never stops firing leaves the incident closed for good. A stray keypress is not recoverable, so the prompt says what it means. - x refuses on an open incident rather than archiving it, since archiving unresolved work only hides it. Snooze is offered as the "not now" answer, and the client treats a snoozed_until in the past as not snoozed, matching the server, which sweeps nothing. Statistics lead with MTTA and MTTR, neither of which was computable before. The server sends null until something has actually been acknowledged or resolved, and that renders as — rather than 0: no data is a different claim from instant. Alerts keep a tab of their own as the raw feed — useful for asking what Alertmanager is really sending — with an Incident column replacing Ack By, and i in the detail view jumping to the incident where something can be done about it. Archived now holds archived incidents; archiving an alert is server-side housekeeping and no longer a user action. BREAKING CHANGE: requires terdut-server v0.4.0 or later. Against an older server every incident request 404s. Use terdut-tui v0.3.x with servers before v0.4.0.	2026-07-30 21:54:54 +02:00
Niklas Ye	e04cfcf433	feat: Last Seen column tracking Alertmanager re-send heartbeat ... The alert list showed only Started, which comes from Prometheus and never changes for the lifetime of an alert instance. A firing alert that started 12 days ago looked identical whether Alertmanager refreshed it 30 seconds ago or went silent a week ago. terdut-server already tracks this: the webhook upsert sets received_at on every accepted payload, including the periodic re-sends issued at repeat_interval, and its archiver treats the field as a liveness heartbeat. The field was already decoded into api.Alert.ReceivedAt and simply never rendered. Add a Last Seen column to the alert tables, rendered with the existing humanAgo helper. The Alerts and Archived tabs share alertColumns/alertRows, so both pick it up. The width budget is re-derived for five columns; the slack constant now accounts for all of bubbles' per-cell padding, so the table lands exactly on the terminal width instead of overflowing by two columns as it did with four. The detail view gains a matching Last Seen line, with the timeline labels widened to keep values aligned. Since received_at stops advancing once an alert resolves, also pull through the server's resolution_source and show it in the status header (RESOLVED · alertmanager vs RESOLVED · expiry) so a frozen timestamp is explained.	2026-07-30 08:48:53 +02:00
Niklas Ye	55ee64530b	feat: Stage 1 scaffold — config, API client, placeholder TUI ... Sets up the full project structure following the hactl/gokapi-tui architecture: strict Elm-pattern Bubbletea TUI, YAML config at ~/.config/terdut-tui/config.yaml, REST API client with Bearer auth, self-update via GitHub Releases, and a three-section tab placeholder (Alerts / Schedule / Users) that verifies server connectivity on startup.	2026-05-21 13:28:13 +02:00