Where is the bug in this variable-size window pseudocode that reports the shortest stretch of tokens containing all required keywords?

## The discipline being tested Finding the **shortest** contiguous stretch that satisfies a containment requirement uses the variable-size window with the shrink condition inverted: grow the right edge until the window qualifies, then — because a qualifying window might be carrying slack on its left — shrink *while it still qualifies*, tightening it as far as possible. Each moment during that shrink, the window is a verified candidate. The subtlety is entirely about **where the answer is captured**, because the shrink loop, by design, runs until it has gone one step too far. ## Tracing the broken fragment Take a support-chat transcript of tokens with required keywords `refund` and `orderid`, and the token stream: `hello refund please orderid thanks` (indices 0–4). Walk the fragment: - `right = 0..2`: the window never contains both keywords. The while never runs — but `best` is still updated each time, with lengths 1, 2, 3 of windows that satisfy nothing. `best` is already garbage. - `right = 3`: window `[0..3]` contains both keywords. The while evicts `hello` (still valid: `[1..3]`), then evicts `refund` — now `orderid` alone remains and validity is gone, so the loop exits with `left = 2`. Only *now* does the fragment record `right - left + 1 = 2`, the length of `[2..3]` = `please orderid` — an **invalid** window. The true smallest valid window ending at 3 was `[1..3]`, length 3, and it was never recorded. Two distinct defects, one placement error: 1. **Off-by-one on valid iterations.** At loop exit, the last valid window was `[left-1..right]`, length `right - left + 2`. Recording `right - left + 1` under-reports by exactly one. 2. **Garbage on never-valid iterations.** When the while condition is false from the start, the post-loop update still fires, folding lengths of non-qualifying windows into `best`. The final answer can be shorter than any window that satisfies the requirement — a silently wrong result, not a crash. ## The fix Move the record to the point where the invariant guarantees what you are measuring: ``` for right in 0..n-1: admit(tokens[right]) while windowHasAllKeywords(): best = min(best, right - left + 1) // window verified valid HERE evict(tokens[left]) left = left + 1 ``` Every recorded length now belongs to a window that the loop condition has just verified. If no window is ever valid, the update never runs and `best` keeps its `infinity` sentinel — which is itself the correct "no answer exists" signal and should be checked before reporting. A patch that keeps the record after the loop and compensates with `right - left + 2` fixes only defect 1; it still needs a guard for the never-valid case, which is why the in-loop placement is the version worth memorizing — it needs no guard at all. ## Why the record point flips with the goal The mirrored **longest-valid-window** shape shrinks while the window is *invalid*, so there the loop's exit means validity was just *restored* — and recording after the loop is exactly right. The rule that generalizes is not "record inside" or "record outside"; it is: **capture the answer at the point where the loop invariant proves the window is in the state you want to measure.** For shrink-while-valid, that point is inside the loop before the eviction; for shrink-while-invalid, it is immediately after the loop. Transplanting the record point from one variant to the other is precisely how this bug gets written by people who have seen both shapes.