Refactor (packages/app/src/components/prompt-input/build-request-parts.ts): Function with many returns

[jillian-nerice]

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

1. Issue

Link to the associated GitHub issue:
Link to the associated GitHub issue: #108

Full path to the refactored file:
packages/app/src/components/prompt-input/build-request-parts.ts

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)

This file takes the separate pieces of a prompt, such as the text, any attached files, referenced files, etc, and combines them into a single ordered list to be sent to the AI model as a prompt's content.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)

I refactored the buildRequestParts function by taking the inline callback logic and splitting it into five new functions: buildFileParts, buildAgentParts, buildContextMentionParts, buildContextParts, and buildImageParts. buildRequestParts itself now just calls these and merges the results.

Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)
Function with many returns (count = 9): buildRequestParts (also reported at line 91).

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
All the return statements were buried inside anonymous .map()/.flatMap() callbacks nested directly in buildRequestParts, so Qlty and any human reader attributed all of that branching complexity to one function. This made it hard to see at a glance what buildRequestParts actually does at a high level, and made each callback harder to test or reason about in isolation.

What changes did you make to resolve the issue?

I pulled each callback into its own named function with a single clear responsibility, building file parts, agent parts, context parts, context mentions, and image parts. buildRequestParts reads now as a short sequence of calls to these functions followed by a single return. There were no logic changes, the same order of operations and set deduplication behaviour was used.

How do your changes improve maintainability? Did you consider alternatives?
Each named function can now be read, tested, and changed independently and the buildRequestParts function now has only one return statement instead of 9. I considered just consolidating all the returns using early exit guards rather than extracting functions, but it wouldn't fix the root cause, which was hat the returns exist because of five different transformations all happening inline in one function.

3. Validation

How did you validate that the change is correct?

I ran the existing test suite build-request-parts.test.ts, which exercises buildRequestParts through 14 test cases covering file attachments, agent attachments, context files, @mention comment parsing, deduplication, and path handling across Windows/macOS/Linux. All 14 passed with no changes needed to the tests themselves, confirming the refactor preserved behaviour. buildRequestParts has exactly one return statement instead of nine.

Attach a screenshot of the test coverage showing the lines were executed by the tests.

Attach a screenshot showing the tests that cover the change passing during CI

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.

before:

after: