refactor: split jobs_view, drop YAML migration, update docs (T6.1-T6.4)

T6.1: split jobs_view.go into three files — jobs_view_helpers.go (pure
helpers) and jobs_view_details.go (detailsPanel struct with widget
creation, update, clear, and container methods) — bringing jobs_view.go
from 459 to ~200 lines.

T6.2: remove stale YAML upgrade note from README; drop *.yaml from
.dockerignore.

T6.3: delete YAML shadow structs (yamlConfig/yamlJob/yamlJobsFile),
importYAMLConfig/importYAMLJobs, legacy path constants, and all
YAML-import tests; run go mod tidy to remove go.yaml.in/yaml/v4.

T6.4: refresh ARCHITECTURE.md — JSON storage references, new Key Domain
Concepts section (per-job overlap policy, run-time statistics + log
seeding, persisted pause flag, jobs_view split).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -14,7 +14,7 @@ src/
   app/                  Service — sole owner of job/runtime state; emits typed Events
   scheduler/            pure timing loop; calls app.Service.RunDue on every tick
   runner/               shell command execution + log file writing + cleanup
-  storage/              YAML persistence (gosentry.yaml, jobs.yaml)
+  storage/              JSON persistence (gosentry.json, jobs.json)
   platform/
     autostart/          Manager interface + Windows (shortcut) and Linux (XDG) impls
     desktop/            display-scale helper (Linux only)
@@ -29,12 +29,12 @@ flowchart LR
     user["Desktop user"]
     ui["src/ui\nFyne windows, tabs, dialogs"]
     svc["src/app Service\nsole owner of job + runtime state"]
-    store["src/storage Store\nYAML config and jobs"]
+    store["src/storage Store\nJSON config and jobs"]
     sched["src/scheduler Scheduler\npure timing loop"]
     runner["src/runner\nshell command execution"]
     autostart["src/platform/autostart Manager\nWindows shortcut / Linux XDG"]
-    config["gosentry.yaml\napplication settings"]
-    jobs["jobs.yaml\njob definitions"]
+    config["gosentry.json\napplication settings"]
+    jobs["jobs.json\njob definitions"]
     logs["logs_dir\nper-run command output logs"]
     shell["Platform shell\ncmd.exe /C or sh -c"]
 
@@ -61,9 +61,11 @@ flowchart LR
 
 1. Startup:
    `cmd/gosentry` calls `ui.Run`, which creates an `app.Service`, opens the
-   store, loads `gosentry.yaml` and `jobs.yaml`, subscribes the UI to service
+   store, loads `gosentry.json` and `jobs.json`, subscribes the UI to service
    events, builds the main window, and calls `Service.Start` to begin the
-   scheduler loop.
+   scheduler loop. On first launch the service seeds per-job run-time statistics
+   from existing log files so the details panel reflects accumulated history
+   immediately (see §Statistics below).
 
 2. Editing settings or jobs:
    The UI calls mutating methods on `app.Service` (e.g. `CreateJob`,
@@ -79,18 +81,20 @@ flowchart LR
 
 4. Manual run:
    `Run now` in the UI calls `Service.RunNow`. The Service checks that the job
-   exists, is not already running, and that the scheduler is not paused, then
-   executes `runner.RunJob` with the `Manual` trigger.
+   exists, is not already running, and that the scheduler is not globally paused,
+   then executes `runner.RunJob` with the `Manual` trigger.
 
 5. Command execution:
    `runner.RunJob` builds the platform-specific invocation, executes the
    command through the platform shell, captures stdout and stderr, writes one
-   timestamped `.log` file, and returns a `domain.RunRecord`.
+   timestamped `.log` file, and returns a `domain.RunRecord` containing
+   `DurationMS` (wall-clock milliseconds from start to finish; 0 for
+   `StartOnly` fire-and-forget jobs).
 
 6. History update:
-   When a run goroutine completes, `Service` updates the job's runtime, saves
-   YAML, triggers log cleanup, and emits `RunRecorded`. The UI observer appends
-   the record to the History tab.
+   When a run goroutine completes, `Service` updates the job's runtime
+   (including the statistics aggregate), saves JSON, triggers log cleanup, and
+   emits `RunRecorded`. The UI observer appends the record to the History tab.
 
 7. Autostart:
    `UpdateSettings` in the Service calls `autostart.Manager.Set`. The Manager
@@ -99,6 +103,61 @@ flowchart LR
    entries pass `--start-in-tray`.
 
 8. Error surfacing:
-   Background errors (failed YAML saves, cleanup errors) are emitted as
+   Background errors (failed JSON saves, cleanup errors) are emitted as
    `ErrorOccurred` events and displayed in the UI status area, rather than
    being silently discarded.
+
+## Key Domain Concepts
+
+### Per-job overlap policy
+
+`domain.Job` carries an `OverlapPolicy` field (`json:"overlap_policy,omitempty"`).
+When non-empty it overrides the global `Config.OverlapPolicy` for that job alone.
+Empty means inherit the global default. `app.Service.RunDue` resolves the
+effective policy per job: it uses `job.OverlapPolicy` when set, otherwise falls
+back to `store.Config.OverlapPolicy`. `normalizeJob` in `app/operations.go` leaves
+the field empty on new jobs so the inherit semantics are preserved.
+
+### Run-time statistics
+
+`domain.JobRuntime` holds a rolling aggregate updated after each run:
+
+| Field | Meaning |
+|-------|---------|
+| `RunCount` | total runs recorded |
+| `FailCount` | runs that exited non-zero |
+| `LastDurationMS` | wall-clock time of the most recent run |
+| `AvgDurationMS` | mean over all runs with a recorded duration |
+| `MaxDurationMS` | longest recorded run |
+
+`runner.RunJob` measures the wall-clock start→finish and sets `DurationMS` on
+the returned `RunRecord`. `runner/logfile.go` writes a `duration` line into the
+log file header alongside the existing `state` line.
+
+On startup, `runner.SeedStats` scans each job's log files (matched by the
+`_<sanitized name>.log` suffix, bounded by `Config.MaxLogFiles`) and folds the
+parsed `state`/`duration` headers into a `runner.StatSeed` map. `NewService`
+applies those seeds to the runtime map before the first scheduler tick, so the
+details panel shows accumulated run history immediately after a restart.
+Older log files that pre-date the `duration` header are tolerated: the run is
+counted but the timing is skipped.
+
+### Persisted global pause
+
+`domain.Config` carries a `Paused bool` field (`json:"paused,omitempty"`).
+`app.Service.SetGlobalPause` writes the new value into `store.Config` and calls
+`SaveConfig`, so the paused state survives a restart. `NewService` initialises
+`s.paused` from `store.Config.Paused` and applies the paused next-run text to
+all runtimes before the first tick, ensuring the UI shows the correct state from
+the moment the window opens.
+
+### `jobs_view.go` file structure
+
+`src/ui/jobs_view.go` is split across three files to stay within the ~250-line
+size guideline:
+
+| File | Contents |
+|------|----------|
+| `jobs_view.go` | `newJobsView` — list, toolbar, button wiring, and layout |
+| `jobs_view_details.go` | `detailsPanel` struct — widget creation, `update`, `clear`, `container` |
+| `jobs_view_helpers.go` | Pure helpers — `filteredJobIndexes`, `folderOptions`, `filterValue`, `indexOfID`, `lastJobLogs` |

docs/RELEASE-0.10-TASKS.md

@@ -109,13 +109,13 @@ Done first because both share a compact, single-line record formatter.
 - [x] T4.4 — persistence + restored-paused tests
 
 ### Phase 5 — Window sizing
-- [ ] T5.1 — 720p-safe default + MinSize
+- [x] T5.1 — 720p-safe default + MinSize
 
 ### Phase 6 — Refactor + cleanup
-- [ ] T6.1 — `jobs_view.go` split
-- [ ] T6.2 — post-field-test cleanup (keep startup timing)
-- [ ] T6.3 — drop YAML→JSON migration
-- [ ] T6.4 — ARCHITECTURE.md update
+- [x] T6.1 — `jobs_view.go` split
+- [x] T6.2 — post-field-test cleanup (keep startup timing)
+- [x] T6.3 — drop YAML→JSON migration
+- [x] T6.4 — ARCHITECTURE.md update
 
 ### Phase 7 — Portable packaging
 - [ ] T7.1 — Windows `.zip`