~/cases

Nothing looked wrong. Progress saved, XP went up, levels advanced. Then a single `curl` command with `{"xp": 999999}` in the body granted an arbitrary level, and a second hole was worse because it was quieter: the penalty for reading a worked solution was a flag the browser volunteered, so the honest client paid it and a modified one simply did not send it.

"Only our own front end calls this endpoint." It is true right up until someone opens the network tab, and it is not a security property: it is a description of yesterday's traffic.

The API accepted the *result* from the client instead of the *event*. The browser said "I finished this lesson and it was worth N points, and by the way I did not use the solution": three claims, all trusted. Two of them were the client reporting on its own performance, which is the category of statement a server can never accept.

• Read your request bodies and ask, field by field: is this something the client *knows*, or something the client *claims*? An id is knowledge. A score is a claim.
• Attack your own endpoint with `curl` before anyone else does. It takes a minute and it is the only test that does not share the front end's assumptions.
• Look for penalties and limits specifically. A missing reward is noticed immediately; a missing penalty is noticed by nobody, which is why it survives.

• Let the client report the event and nothing else. Here the body became just the lesson id: the server reads what that lesson is worth from its own curriculum, and any `xp` field in the request is ignored.
• Make the penalty a server-side fact. Asking for the worked solution now writes a row, and the award is computed from that row, so declining to mention it changes nothing.

No symptom at all. A deliberate piece of work had stripped quiz answers and worked solutions out of the page payload, and a test asserted that no answer key could be found in it. The test passed. The suite was green for weeks.

There is nothing to find: the tests cover it. That is the trap: a green suite is evidence about the rule you wrote down, and says nothing about the rule you meant.

One field had been left in the payload on purpose, with a written justification: a hint "points at the idea rather than giving the code", and making it cost a round trip would stop people taking it. The reasoning was sound and the premise was never checked. Measuring it later: of 118 hints, 88 contained code and 15 were the reference solution written out. The exemption that had been argued for was shipping the answer.

• Find the exemptions in your own rules and check each premise separately. Anywhere a comment says "this is fine because…", the *because* is an untested claim.
• Measure the content, not the intent. Counting how many of the 118 hints actually contained code took one script and settled an argument that reasoning could not.
• Read what actually reaches the client, not what you meant to send. Fetch the page and grep it for a string only the answer contains.

• Make the test assert the thing you actually care about. The rule became "the hint must not be in the payload either", which fails loudly the day someone puts it back.
• When you write an exemption, write down how you would know it stopped being true, and then go and check that, on a schedule.

Learners in Turkey studying late in the evening lost their daily streak, or saw it fail to advance. Nobody in UTC could reproduce it, and the streak code had a passing test.

An off-by-one in the streak arithmetic: that is where the logic looks fiddly, so that is where everyone reads first. The arithmetic was correct. Reading it again, more carefully, would have cost another afternoon.

`todayStr()` computed the current date in UTC. Turkey is UTC+3, so between 00:00 and 03:00 local time the server still considered it yesterday. A learner finishing a lesson at 00:30 was recorded against the previous day: the streak either failed to advance or counted a day it should not have.

• Ask of every date in your product: whose day is this? A date is not a fact about the universe, it is a fact about a place. If your code never names a time zone, it has silently picked the server's.
• Reproduce it by moving, not by reading. Set your machine's clock into the affected window (or better, pass the time zone in as a parameter so the test can) and run the flow again.
• Suspect the boundary whenever a bug is reported by users in one country and by nobody else. Time zone, currency, decimal separator and character set all have this signature.

• Store the user's time zone and pass it into any function that decides what day it is. It became a `time_zone` column here, refreshed from the browser on every completion, so a learner who travels gets the right boundary from the next lesson onwards.
• Write the regression test in the time zone that broke, not in yours. A test that passes in UTC is what let this ship.

A learner wrote a loop with no exit and the browser tab froze: permanently. No error, no stack trace, no way to stop it. The only recovery was force-quitting the tab, which lost whatever they had typed.

A performance problem: the interpreter is slow, the machine is old, give it a moment. It never finishes, because there is nothing to wait for, but "wait a bit longer" is a very easy thing to keep believing.

The Python runtime ran on the browser's main thread, which is the same thread that draws the page and handles clicks. An endless loop there does not slow the page down; it stops the page existing. There was no timeout and no way to interrupt, because a busy main thread cannot run the code that would interrupt it.

• Ask where the untrusted code is running. "Untrusted" does not mean malicious: a beginner's first `while` loop is untrusted in exactly the sense that matters: you cannot predict whether it terminates.
• If the page stops responding to clicks rather than getting slow, you are blocking the main thread. A slow page still repaints; a blocked one does not.

• Run anything you did not write in a place you can terminate: a worker, a subprocess, a container. The fix here was a Web Worker the page can kill outright.
• Give it a deadline. Ten seconds here, after which the worker is terminated and the learner is told their code ran too long and that this usually means a loop that never ends: a message that teaches, rather than a spinner that lies.

`tsc` started failing with `Duplicate identifier` errors in files nobody had written, inside a generated directory. Deleting the directory fixed it. Days later it came back. Another time the dev server melted down entirely, panicking with `Next.js package not found` a hundred and twenty times while the page reloaded in a loop.

A broken build cache, or a bad dependency install. Both are reasonable, both are the usual answer, and deleting the cache did appear to work, which is exactly what made it take three occurrences to see the real pattern.

The project lived under a folder that a cloud drive was syncing. When sync could not resolve a change it left a second copy beside the original, named `file 2.ts`. Inside the generated types directory those copies duplicated every generated declaration, so the compiler saw each identifier twice. The same mechanism produced copies of the SQLite write-ahead log, and, on one occasion, a conflict copy of a source file was committed to git, a stale duplicate of a module from before it was rewritten.

• When an error names a file you did not write, list the directory rather than reading the file. `find . -name "* [0-9].*" -not -path "./node_modules/*"` finds conflict copies by their naming pattern.
• Ask what else writes to your project folder. An editor, a backup agent, a cloud drive and an antivirus scanner are all processes with write access that you did not think of as part of your toolchain.
• Treat "deleting the cache fixed it" as a symptom, not a fix. If you cannot say why the cache was corrupt, it will corrupt again.

• Keep code out of synced folders. This is the actual fix and it is one `mv`: the rest of this entry exists because it was postponed.
• Add the conflict-copy pattern to `.gitignore` so a duplicate can never be committed. Note that a narrow pattern is a false comfort: `* 2.*` was ignored here, and copies numbered 4 and 5 walked straight past it.

A table was renamed. Running the schema push locally printed a stack trace and stopped. Nothing was applied, nothing was broken, and the same command in a pipeline would have hung until it timed out.

The migration tool is broken, or the schema is invalid. Neither was true: the tool was working exactly as designed, and the schema was fine.

A rename is ambiguous to a schema differ: it cannot tell "this table was renamed" from "this table was dropped and a different one created". So it asked which one it was: an interactive prompt, waiting on a terminal that in a pipeline is not there.

• Read the trace for the word that names the behaviour rather than the failure. Here the frame was a prompt function, which says the tool was waiting for an answer, not that it crashed.
• Run the command the way your pipeline will: no terminal, no input. Anything that stops and waits shows up immediately instead of at 3am on a release.

• Never let a schema change reach a pipeline as a live diff. Generate the migration file, read it, commit it, and have the pipeline apply that file: the ambiguity is then resolved by a person, once, in a reviewable artefact.
• Say out loud what a rename does to existing rows before you run anything. Here the table held nothing, so dropping it was free, which is a fact worth checking rather than assuming.

A freshness check reported that 295 links in the Turkish content were missing their date stamp, while every English link was fine. A clean split down one locale, in content that had been written in both languages at the same time by the same process.

The Turkish content was written more carelessly. It is the obvious reading, it is faintly plausible, and acting on it means editing 295 lines that were never wrong.

The check was wrong. English marked dates as `(added 2026-08)` and Turkish as `(eklenme: 2026-08)`, with a colon. The pattern being searched for did not allow the colon, so it matched nothing in Turkish and everything in English. The same run also flagged two files for quoting a price without a caveat; one of them says prices are "per million tokens" and quotes no figure at all, and the other was talking about a token count.

• When a check reports an implausible number of failures, suspect the check before the content. A defect rate that lands on exactly one language, or exactly one directory, is usually a fact about your pattern.
• Open three of the reported failures by hand and read them. If they look correct to you, they are correct and your check is not.
• Verify the check catches a real failure before you trust it to report one. Introduce a violation on purpose, watch it fail, then take it back out.

• Test your tests. A check nobody has ever seen fail is a check nobody knows works, and it will happily report zero problems forever.
• Do not encode punctuation you have not surveyed. A rule written against English prose banned the semicolon; Turkish uses it normally, and it failed honest text on sight.