Exercise 1: Why the Filetype Restriction Was Removed First — Possible Solution ==================================================================== WHAT CHAPTER 8 SAYS TO REMOVE FIRST ------------------------------ Per Chapter 8's own debugging process, when a compound query returns zero results, operators should be removed "starting with whichever feels least essential to what's actually being looked for" - not removed in an arbitrary order, and not by discarding the whole query to start over. WHY THE FILETYPE RESTRICTION WAS THE LEAST ESSENTIAL CONSTRAINT HERE ------------------------------ Per the capstone's own reasoning, "GitHub issues aren't meaningfully categorized by file type in the first place." The actual goal of the search was finding a discussion thread about a specific compatibility problem - GitHub issues are typically just structured web pages, not downloadable files with a distinct format the way a PDF or spreadsheet is. Restricting by filetype in this context was never targeting something the actual desired content plausibly had, making it the constraint most likely to be silently eliminating every real result without adding any genuine precision in return. WHY THE DATE RANGE AND SITE SCOPE WERE KEPT INSTEAD ------------------------------ The site scope (site:github.com OR site:prisma.io) was central to the whole point of the search - restricting to authoritative sources rather than arbitrary blog posts, established back in Step 3. The date range was also kept deliberately, since the capstone explicitly named pooling-mode compatibility as "an actively evolving area of both projects," meaning an old result could be confidently wrong in exactly the way Chapter 5 warned about. Both of those constraints were doing real, intentional work; the filetype restriction was not. WHY THIS WORKS AS AN ANSWER ------------------------------ It applies Chapter 8's own stated priority rule (least essential first) rather than describing the fix in the abstract, and explains specifically why the filetype restriction - unlike the date range or site scope - was contributing nothing meaningful to this particular search, making it the correct candidate to remove.