Eight hours away, and in the room anyway.

A concierge noticed a flight showing one day early in a list, and correct everywhere else. The list was reading a plain date, September 7, as midnight in UTC. In every US time zone, that moment is still September 6. I didn't patch the list. I changed how every date without a time is read, as a calendar day where the reader is, and pinned the tests to New York time so the bug can't come back quietly.

Concierge staff create a trip by uploading a screenshot of the flights, and a model reads it. Some trips started coming out a day too long. I proved the screens, the math, and the saving were all right, and traced it to the model itself: it was giving next-day arrivals to same-day flights, mostly long westbound flights and short hops after an overnight leg. A model like that will never be right every time, so the team's review stays the real safeguard, and the screen now warns when a date looks like one the model tends to get wrong.

While checking a new reporting screen, I watched the network panel and saw the same request go out five times on one page load. The report wasn't the problem. The shell that wraps every page in the portal changed its layout a moment after loading, so every page was being built twice. I fixed the shell, confirmed on the live site that five requests became one, and shipped it as its own change, because it touched every screen in the portal.

A rule meant to keep parts of the code apart reported zero problems, every time. I don't trust a check I've never seen fail. It had a broken pattern inside it, so it couldn't fail, while more than seventy crossings it should have caught sat in the code. The same pass found over twelve hundred lines of duplicated code that nothing used.