Add committed, uncommitted, and all scope handling for run files with source reporting for sandbox and final patch responses.
Wire the run files page to persist scope in the URL and cache each scope independently.
Return degraded run files with the same FileDiff[] shape as live responses, using nullable contents and per-file unified patches so the web sidebar and deep links work consistently.
Replace React Router loader/action state paths with SWR query and mutation hooks.
Add targeted run and board EventSource managers that invalidate SWR keys, and refresh embedded SPA assets.
Adds `meta.stats: DiffStats` (required) to `PaginatedRunFileList` so the
Files Changed toolbar can render `+387 −104` next to the file count.
Server: refactors `list_binary_paths` into `list_diff_numstat`, which
returns the binary-path set plus aggregate `+/-` totals from a single
`git diff --numstat` invocation. The degraded patch-only response
populates the same field by counting `+`/`-` line prefixes in the
filtered patch (excluding `+++`/`---` file headers).
UI: `Toolbar` accepts `additions` / `deletions` and renders them as
mono-tabular `+387 −104` to the right of the file count. The block is
elided when the diff has 0 changes (e.g. binary-only or empty runs) so
the empty case stays clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Expose cancel, archive, and unarchive from the run detail view,
surface blocked-question context, and route run-detail and run-files
notifications through a single shared toast provider.
This also refreshes the embedded SPA bundle and marks the lifecycle
actions plan complete.
Two follow-ups from internal review:
1. deriveEmptyKind was incomplete. The full RunStatus enum (per
fabro-types/src/status.rs and apps/fabro-web/app/data/runs.ts) has
ten values — submitted, queued, starting, running, blocked,
paused, removing, succeeded, failed, dead. My decision table
covered only six and incorrectly included "partialsuccess" which
is a stage status, not a run status. Unhandled statuses
(blocked, paused, removing, dead) silently fell through to the
"diff_lost" branch, which showed users the alarmist "the diff for
this run is no longer available" copy for runs that are merely
paused or being torn down.
New table:
- submitted / queued / starting → R4(a) "starting"
- running / blocked / paused → R4(b) "no_changes" (yet — user
can refresh)
- failed / dead → R4(c1) "failed before checkpoint"
(R4b-equivalent when a degraded
patch did survive)
- succeeded / removing → R4(c2) "diff_lost" if
total_changed > 0, else R4(b)
- unknown future status → R4 "unknown" fallback
Test suite now drives each documented status through a regression
guard that asserts no known status collapses to "unknown" when a
more-specific kind should apply.
2. Loader integration tests. The `extractRequestId` unit test covers
only the extractor; nothing exercised the full fetch → body-read
→ requestId → error chain. Added 8 loader tests covering:
- 200 OK returns the parsed envelope
- 404 / 501 collapse to the empty-envelope signal (null + null)
- 500 with `request_id` in errors[0] populates error.requestId
- 500 without a request_id leaves it null
- 500 with non-JSON body still surfaces the status
- 503 populates error without requestId
- 401 surfaces as an error (no in-loader redirect — that concern
lives in apiFetch, which the Files loader deliberately bypasses
to preserve error bodies)
The tests stub globalThis.fetch; the loader already accepts the
cancellation-signal-only `request` object.
Refs docs/plans/2026-04-19-002-feat-run-files-changed-tab-plan.md §
Unit 11 R4/R5 taxonomies.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Earlier refactor to a discriminated-union loader accidentally
discarded the plan's R5 error taxonomy. `apiJsonOrNull` throws a
body-less Response on non-ok statuses, so the loader's try/catch had
no way to recover the server's error envelope or the request_id for
500s. The initial-error render then collapsed all statuses into
either `<EmptyState kind="unknown">` (401/403) or a generic
InlineErrorBanner — losing the plan-specified copy for access denied,
transient failures, and 500 with request ID.
Fixes:
- Loader now uses `fetch` directly against the API path so the
response body is preserved on non-ok statuses.
- 404/501 still collapse to `{data: null, error: null}` (the empty-
envelope signal the UI maps to R4).
- Any other non-ok parses the body as JSON, extracts request_id from
either the top-level `request_id` field or the uniform error
envelope (`errors[0].request_id` or parsed out of
`errors[0].detail`), and threads it through `error.requestId`.
- Component's `initialError` branch now applies the full R5 taxonomy:
R5(c) access denied for 401/403 with the specific copy, R5(a)
retry banner for 429/503, R5(d) "Something went wrong. Request ID:
<id>. Contact support." for 500s, and a generic retryable banner
for any other 4xx.
Adds run-files.test.ts covering extractRequestId across the three
locations request_id can show up in a server error body (top-level,
errors[0].request_id, errors[0].detail regex).
The RunFilesErrorBoundary export stays in place as defense-in-depth
for React render crashes — the loader no longer throws, but ensuring
the route always has a fallback is cheap.
Refs docs/plans/2026-04-19-002-feat-run-files-changed-tab-plan.md §
Unit 11 R5 taxonomy.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
