docs: track the oversized files as a roadmap item

The ~250-line guideline is currently broken by six source files, not the
two the last commit named from the ui section it was editing:
operations.go at 490 is the worst, and both files that were already split
once are back over.

Fixing them belongs in the next whole-project review rather than in
one-off commits. REVIEW.md item 2 already asks for exactly this sweep, and
doing all six together is what keeps the seams consistent — six separate
passes would settle the same question six ways. A split also reads as pure
movement while it is the easiest change in which to silently drop a
function, which is an argument for one careful pass rather than several
hurried ones.

The item records the seams that are visible today so the pass does not
start cold: operations.go splits along the three consecutive blocks it
already has, history_view.go's column measurement is pure and separable,
and jobs_view.go is the hard one because almost all of it is a single
constructor that has to be broken up rather than moved. The three files
barely over the line are flagged as re-measure-first, not split-on-sight.

ARCHITECTURE now points at that item instead of describing the overage in
passing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -204,9 +204,10 @@ the moment the window opens.
 
 ### `jobs_view.go` file structure
 
-The size guideline for a file in this project is ~250 lines. `src/ui/jobs_view.go`
-is split across three files along these seams; the view file itself has grown
-back over the guideline since, and is the next candidate if it grows further:
+The size guideline for a file in this project is ~250 lines.
+`src/ui/jobs_view.go` is split across three files along these seams; the view
+file itself has grown back over the guideline since — see the split item in
+[ROADMAP.md](ROADMAP.md), which tracks every file currently over it:
 
 | File | Contents |
 |------|----------|
@@ -217,8 +218,7 @@ back over the guideline since, and is the next candidate if it grows further:
 ### `settings_view.go` file structure
 
 `src/ui/settings_view.go` is split across three files the same way, once its
-own size passed the guideline. `src/ui/history_view.go` is over it too and has
-not been split:
+own size passed the guideline:
 
 | File | Contents |
 |------|----------|

docs/ROADMAP.md

@@ -81,6 +81,50 @@ Design notes / open questions:
   Service exposes import/export operations; the UI only picks the file and
   shows the outcome.
 
+### Split the files that are over the size guideline
+
+[ARCHITECTURE.md](ARCHITECTURE.md) sets a ~250-line guideline per source file
+and records the `jobs_view.go` and `settings_view.go` splits as the worked
+examples. Six non-test files are over it at 1.0.0, including both files that
+were already split once:
+
+| File | Lines |
+|------|-------|
+| `src/app/operations.go` | 490 |
+| `src/ui/jobs_view.go` | 355 |
+| `src/app/run.go` | 287 |
+| `src/ui/history_view.go` | 282 |
+| `src/ui/settings_view.go` | 277 |
+| `src/storage/store.go` | 265 |
+
+This is deliberately deferred to the next whole-project review rather than done
+piecemeal: [REVIEW.md](REVIEW.md) already asks item 2 to look for exactly this,
+a split touches every reader of the file, and doing all six in one pass keeps
+the seams consistent instead of settling them six different ways. Splitting is
+also the kind of change that reads as pure movement while quietly dropping a
+function, so it wants one careful pass, not six hurried ones.
+
+Seams visible today, as a starting point rather than a decision:
+
+- **`operations.go`** — the worst overage and the clearest split: the public
+  mutating operations (`CreateJob` … `UpdateSettings`), the `…Locked` state
+  helpers that only they call, and the pure validators and normalizers
+  (`normalizeJob`, `validateJob`, `hasFileName`, `validateConfig`) are three
+  distinct jobs already sitting in three consecutive blocks.
+- **`history_view.go`** — the column-measuring helpers (`textWidth` through
+  `historyColumnWidths`) are pure, already unit-tested, and independent of the
+  table they size.
+- **`jobs_view.go`** — nearly all of it is one `newJobsView` constructor, so the
+  split has to break that function up (list template, toolbar handlers,
+  assembly) rather than move whole functions. Larger judgement call than the
+  others.
+- **`run.go`**, **`settings_view.go`**, **`store.go`** — barely over. Worth
+  re-measuring at the time; if a pass elsewhere has shrunk them, leave them
+  alone rather than splitting for the sake of the number.
+
+Scope note: the guideline is about source files. Test files are much larger and
+that is fine — a table-driven test file grows with the cases it covers.
+
 ### Window size persistence *(frozen)*
 
 Window size is currently **not** saved on quit or close. Saving was disabled