6.3
Read-Only First
Why this exists
You now know how to read a system and read its errors. The next instinct is to start fixing things, and this lesson sits deliberately in the way of that instinct.
Because there's a category of mistake available to you now that wasn't available before: changing production data. Not breaking a page — changing numbers that other people's decisions and payslips depend on, in a way that isn't obvious and doesn't announce itself.
The idea
Investigate with tools that cannot change anything. Give yourself permission to be careless.
That's the actual benefit, and it's counterintuitive. Read-only isn't about being timid — it's about being able to poke at a live system freely, because nothing you type can hurt it. Speed comes from safety, not from confidence.
The distinction to hold:
| Reading | Changing |
|---|---|
SELECT |
UPDATE, DELETE, INSERT, DROP |
| Viewing a log | Editing a config |
git log, git diff, git show |
git push, git reset --hard |
| Opening a file | Saving a file |
Nearly every investigation is a read. You're answering "what is true right now" — how many, since when, which ones. None of that requires changing anything, and if you find yourself reaching for a write to answer a question, you've stopped investigating and started fixing.
Three habits that make this real:
Count before you look. Before running anything against real data, ask how many rows it touches. A query that should return three and returns nine thousand means you've misunderstood something — and finding that out from a count is free.
Use the safest access you have. If there's a read-only login, use it. Not because you'd misuse the other one deliberately, but because tired-at-7am you is a different person and the safest thing is not having the option.
Ask Claude for read-only explicitly. "Write me a read-only query that answers X." It will otherwise sometimes offer you a fix — helpfully, correctly, and much sooner than you want it.
The one that costs people: a DELETE or UPDATE with a wrong condition does not fail. It succeeds, quietly, on the wrong rows. There's no error to read afterwards, and often no obvious sign until someone downstream notices a number is wrong. That's why the discipline is a rule and not a judgement call.
Do
Use a real system with real data — ours, or the project from Level 5.
- Pick a genuine question you don't know the answer to. How many X since Y? Which ones are in state Z?
- Use the most read-only access available. If a read-only login exists, use it.
- Ask Claude: "Write me a read-only query that answers this. Do not change anything."
- Before running it, run a count. How many rows does this touch? Is that the order of magnitude you expected?
- Run it. Get your answer.
- Now check the answer a second way — a different query, or against something you already know is true.
- Write
read-only.md: the question · the query · the answer · how you verified it. - Last: write down the three commands or actions in this system you now know are not read-only.
Step 6 matters more here than anywhere. A read-only query can't damage anything, but it can absolutely give you a confident wrong answer — and a wrong number you then act on is its own kind of damage.
Done when
Never do
Never run a write against real data to answer a question. Questions are reads. If you're reaching for a write, you've stopped investigating and you should know that you've stopped.
Never run a DELETE or UPDATE without seeing the count of affected rows first. They don't fail on a wrong condition. They succeed on the wrong rows, silently, and there is nothing to read afterwards.
Never use the write-capable login when a read-only one exists. Not a judgement about you — a judgement about seven in the morning.