BACK-633 - Show and edit modified files in the web task modal

[ivan812205]

Summary

The modifiedFiles field was added in #607 (BACK-412) and is wired through the whole stack: the markdown parser/serializer, backlog task edit --modified-files in the CLI, the plain output, the TUI task viewer, the MCP tools, and web search. The one surface that never caught up is the web task details modal: the card neither displayed the files nor offered a way to edit them.

The asymmetry is easy to reproduce today: in the web UI you can search tasks by file name — search-command-query.ts parses modifiedfiles: tokens, SideNavigation.tsx detects them as a command query, and lib/api.ts forwards them as modifiedFile params — but opening a task found that way showed no trace of the files that matched it.

This PR adds a Modified files section to TaskDetailsModal.tsx, modeled 1:1 on the existing References section right above it:

• the file paths render as a monospace list (<code>, break-all for long paths);
• each row gets a remove button revealed on hover (hidden for read-only cross-branch tasks);
• an add form (preview mode only) appends a trimmed, de-duplicated path;
• both mutations go through the existing handleInlineMetaUpdate, i.e. the same optimistic-update path References use.

No server changes were needed: PUT /api/tasks/:id already accepts modifiedFiles (src/server/index.ts), so the backend was ready and waiting. The new state is wired into the modal's form-state snapshot, the dirty-preserving refresh logic, task-switch reset, and external-update sync, same as the other list fields.

One file changed: src/web/components/TaskDetailsModal.tsx (+76).

Validation

• bun test --timeout=10000 on this branch: 2244 pass, 6 skip, 1 fail (2251 tests across 230 files).
• The single failure is Git Operations > fetch > hard-kills a timed-out Git process group even when a child holds its pipes — a pre-existing timing flake unrelated to this change: with this diff stashed, the same test fails on unmodified main as well, and it passes 5/5 consecutive isolated runs with the diff applied (failures land at ~504–508 ms against its 500 ms kill window).
• bunx tsc --noEmit: clean.

Notes

• On one full-suite run BacklogServer statistics endpoint > reconciles a selected backlog root before reading its statistics also failed once under load; it passes in isolation both with and without this diff, so it looks like the same class of environment-sensitive flake.
• This UI-only change follows the pattern of the section directly above it, so no new tests were added; the search/API/server behavior it exposes is already covered by existing suites.
• There is no backlog task for this yet — happy to add one (backlog task create) or adjust scope if you'd prefer this discussed in an issue first.

---

Maintainer follow-up (BACK-633)

Thanks @ivan812205 — the diagnosis and the diff were both right, so this was picked up and finished in place rather than reworked. Your commit is the base of the branch; the commits on top are maintainer edits.

Adding the backlog task: BACK-633 - Show and edit modified files in the web task modal, created with the CLI and committed to this branch.

Review of the original change

Verified rather than assumed:

• PUT /api/tasks/:id does apply the field (src/server/index.ts), and core normalizes it (resolveModifiedFiles in src/core/backlog.ts), so no server change was needed — correct as described.
• The refresh-preservation, task-switch reset, and external-update sync all match the sibling references handling.
• handleSave deliberately omits modifiedFiles, exactly as it omits references, so a Save in edit mode cannot clobber an inline edit. Correct as written.
• Branch was already on top of current main, so no rebase was needed.

Added: the section has to survive a large task

A finished task can list well over a hundred paths, and paths can be long enough to wrap several times. Unbounded, the section pushed Documentation, Acceptance Criteria, Plan, Notes and Comments out of reach.

• The paths list is capped (max-h-64, overflow-y-auto, overscroll-contain), following the bounded-list pattern already used by CleanupModal and DuplicateIdRepairModal. overscroll-contain keeps the inner wheel from scrolling the modal behind it.
• The heading carries the count — Modified files (130) — matching the existing Comments (n) precedent, so a capped list still announces its size without adding helper text.
• Rows use items-start with a small offset on the remove button, so on a path that wraps to three lines the control sits with the first line instead of floating in the middle of the row.
• Long paths keep your break-all wrapping rather than truncating, so no path is hidden.
• hasCreateModeEntries now counts modifiedFiles alongside references.

Measured in a throwaway project on a task seeded with 130 long paths (Chrome, 1280px):

	unbounded	capped
Section height	10508px	372px
Modal scroll height	11475px	1339px

All 130 paths stay in the DOM and the last is reachable by scrolling (list content 10392px inside a 256px box). No horizontal overflow at 1280px or at 375px, where paths wrap to six lines and the section still measures 372px. The cap is inert for ordinary tasks: a 3-path task measures an 88px list with no scrollbar.

Added: tests

src/test/web-task-details-modal-modified-files.test.tsx follows web-task-details-modal-documentation.test.tsx — five cases covering the populated list, the empty state, the heading count, a 120-path long-path case asserting every path renders inside a bounded scrolling list with later sections still present, and cross-branch read-only hiding both controls. The many-paths case was confirmed to fail when the height cap is removed.

Validation

• bunx tsc --noEmit: clean.
• bun run check .: clean.
• bun run test: 2250 pass, 6 skip, 0 fail (231 files). The git-timeout flake you hit did not reproduce.
• bun run build: succeeds.
• Live round-trip: adding a path from the modal wrote it into the task markdown and backlog task view --json reported 131; removing it from the modal returned both to 130.

One pre-existing behavior noted but deliberately not changed here: pressing Enter in the add input did not submit under synthesized key events. The References add form behaves identically, so it is shipped parity rather than a regression in this PR, and the Add button works in both.

[MrLesk]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: 60a8e92dc8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".