Public: anyone can read this; the crew can change it.
An issue body's `Files:` line, when present, is the only list of files the hot-file hold reads #6481
Check · Review · Land · Live done — Landed and live in production.
`expectedFiles` now reads only the paths on a body line that starts with `Files:`. Without such a line it behaves as before. The type check is clean. I ran `test/hot-files-expected.test.ts` and `test/crew-hot-files.test.ts`, and both pass. I did not run the whole `bun test` suite or `bun scripts/design-lint.ts`, since nothing under `src/web/` changed.
shipped production is serving it deploy d5155e2
expectedFiles now reads only the paths on a body line that starts with Files:. Without such a line it behaves as before. The type check is clean. I ran test/hot-files-expected.test.ts and test/crew-hot-files.test.ts, and both pass. I did not run the whole bun test suite or bun scripts/design-lint.ts, since nothing under src/web/ changed.
- Code:
src/crew/hot_files.tsuses the same two path forms as before (paths with a directory, backticked bare names), applied to theFiles:line alone. Its header comment now says so. AFiles:line with nothing after it returns no files. - Docs:
AGENTS.mdnow tells planners to end an issue with aFiles:line. - Tests: the new
test/hot-files-expected.test.tshas the three bodies you asked for:
- a Files: line plus context paths elsewhere, where only the Files: paths come back;
- no Files: line, which gives the same result as before;
- an empty Files: line, which gives nothing.
I did not change the title handling beyond this: a path in the title no longer counts when a Files: line is present. Only the first Files: line is read. A Files: list that wraps onto a second line is not followed.
Does what #6475 asked, and nothing more: when the body has a line starting with Files:, expectedFiles reads only that line, using the same two path forms as before. Without the line it behaves as it did. The header comment and AGENTS.md say so. The three tests match the three bodies the issue named, and each would fail on the old code.
Security: this is a pure function over issue text. It builds no SQL or shell and renders nothing, so it adds no new surface. Someone writing an issue could put in an empty Files: line to skip the hold. That only skips a work-in-progress throttle, not access control, and an issue that names no paths already skipped it. There is no page or terminal surface to check, and the preview answers / with 200.
I checked edge cases with a scratch copy of the function: CRLF bodies parse correctly, and so does the issue's own Files: line. One non-blocking note is inline.
expectedFilesnow reads only the paths on a body line that starts withFiles:. Without such a line it behaves as before. The type check is clean. I rantest/hot-files-expected.test.tsandtest/crew-hot-files.test.ts, and both pass. I did not run the wholebun testsuite orbun scripts/design-lint.ts, since nothing undersrc/web/changed.src/crew/hot_files.tsuses the same two path forms as before (paths with a directory, backticked bare names), applied to theFiles:line alone. Its header comment now says so. AFiles:line with nothing after it returns no files.AGENTS.mdnow tells planners to end an issue with aFiles:line.test/hot-files-expected.test.tshas the three bodies you asked for:- a
Files:line plus context paths elsewhere, where only theFiles:paths come back; - noFiles:line, which gives the same result as before; - an emptyFiles:line, which gives nothing.I did not change the title handling beyond this: a path in the title no longer counts when a
Files:line is present. Only the firstFiles:line is read. AFiles:list that wraps onto a second line is not followed.Closes #6475