Commit Graph
3 Commits
Author SHA1 Message Date
nikolaandClaude Opus 5.5 7f5b4846ef Show which legs a transfer cannot pair, and what would pair them
The transfers screen counted unpaired legs per definition but never said
which transactions they were; finding them meant retyping the definition
into the builder. A ⚠ row now opens onto its legs, newest first, each
naming the missing side and what that side would have had to be:

  revolut → ?  arriving leg  +250.00 in other matching *FROM REVOLUT*,
                             dated 2026-02-01 to 2026-02-11

That description comes from transfers.Engine.Want, next to
bestCounterpart, so it is stated in the terms the pairing actually uses:
the other half of the definition, the window, and the amount -- exact,
widened only by the definition's own tolerance, and "any amount" across
currencies, where amounts are not compared. When the other account has
nothing imported at all, the line says so, since that is the usual cause.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 19:43:13 +02:00
nikolaandClaude Opus 5.5 ec8a844441 Remove the TUI; the web app is the frontend
money serve covers every screen the TUI had, so keeping both meant every
behaviour change landing twice. internal/tui goes, and with it bubbletea,
bubbles and lipgloss. `money` with no command now runs serve, the way it
used to open the TUI, and `money tui` is an unknown command.

Three invariants in CLAUDE.md were covered only by TUI tests. Two already
had web counterparts; TestPairedLegsAreNotUntagged is ported to the API:
a paired leg is neither listed as untagged nor offered to the rule
builder, while an unpaired one still is.

README's screen sections now describe the browser, which kept the
behaviour and changed only the controls. CLAUDE.md names the web
equivalents of the TUI functions its invariants pointed at, drops the tab
completion rule that only bubbles' textinput needed, and says how to test
the web app instead of how to drive a terminal.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 18:51:54 +02:00
nikolaandClaude Opus 5.5 6faf99719a Serve the TUI's screens as a web app
money serve puts the seven screens in a browser: accounts, transactions, the
report with its period axis and sort, the rule builder with its live preview
and edit-in-place, the rules list, the transfer builder with its tolerance
preview, and the transfers list. Import and retag are buttons in the header.
It is one binary: the page is plain HTML, CSS and JavaScript embedded with
go:embed, with no framework and no build step.

It is a second frontend, not a second implementation. Amounts are formatted on
the server, the rule preview is matched by glob.Match there, and the transfer
preview runs transfers.Analyze, so the browser only lays out answers and
cannot drift from the TUI on what a rule catches or what a pair costs.

The server outlives hand edits to rules.toml in a way the TUI does not, so
retag and import re-read it first, as a fresh `money retag` or `money import`
would, and the overview says when the file on disk no longer matches what the
index was derived from. Edits and deletes still go by position, but carry the
rule they showed and are refused unless rules.toml still holds exactly that
there; a position from a stale tab could otherwise name a different rule. An
edit takes the type pattern from the rule on disk, never from the request.

There is no authentication, by request. It listens on loopback unless --addr
says otherwise, and writes must be sent as JSON so a cross-site form cannot
post to it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 09:48:56 +02:00