How this works

One question, underneath everything

What can I prove for the customer right now?

Not “what technology am I studying today”. Each exercise proves exactly one operational fact, and the technology sits underneath it. You are never asked to recite what a command does. You are asked what its output proved, and just as importantly, what it did not.

That distinction is the whole method. A container that is running has not proven the application is healthy. A database that is up has not proven the application can reach it. A refused connection and a rejected login look identical to a customer and mean completely different things to you.

The loop

Every exercise runs the same seven steps.

1. Ticket. A customer symptom, in their words. Never the topic.
2. Prediction. Before you run anything, write down the layer you suspect and two likely causes. Being wrong here is the useful part.
3. Evidence. One command that proves one thing.
4. Read the output. Sort it into confirmed, disproven, and still unknown. This is the step people skip, and skipping it is how hypotheses get reported as facts.
5. What it proves. One proof sentence, one safe next step, one alternate hypothesis.
6. Wording. The customer update and the escalation note.
7. Recall. One gap, one command to repeat tomorrow.

The scratchpad on every exercise page is this loop as a form. It saves in your browser as you type and nothing is uploaded.

Every exercise has the same shape

Uniformity is deliberate. Orienting yourself in a new layout costs attention that should go to the problem.

ticket.md     the customer symptom, and nothing else
setup/        the broken state
check.sh      the assertions, and the evidence behind them
hints/        three escalating nudges
solution.md   root cause, the fix, and the words you would send

Hints escalate rather than dump. The first reframes the symptom into a provable question and names no command at all. The second points at the layer and the kind of evidence. The third gives you the commands.

The grader shows its work

tse check never just reports pass or fail. It prints the assertion, the command it ran, and the raw output it evaluated:

FAIL  Customer workflow returns their data
      $ curl -s --max-time 3 http://127.0.0.1:8100/customers
      (no output)
      Expected: {"status": "ok", "customer_count": 10} from /customers

It also grades outcomes rather than answers. There is no magic string to type. If the customer’s workflow works, you have solved it, regardless of how.

Who the design serves

This course is deliberately ADHD-friendly, and the mechanisms above are how, not a separate accommodation bolted on. A symptom-only ticket leaves no topic page to stall on. A grader that prints its evidence makes feedback immediate and concrete. A replay terminal means no environment to assemble before the interesting part. A stated time cost lets you decide up front whether today has room for it.

None of that narrows who the course is for. The same choices read as plain good design to every learner; for brains that stall on ambiguity and walls of theory, they are the difference between finishing and not finishing.

A minimum viable day

On a day with very little in the tank, this counts as progress and you should stop there without guilt:

• One ticket
• One command
• One proof sentence
• One question answered

Every exercise states its time cost before you start, so you can decide up front rather than discovering halfway through that you do not have the capacity.

The terminal on the exercise pages is a replay

Every exercise page carries a terminal you can type into. It is worth being exact about what it is, because a page that quietly invents plausible output would be the walkthrough this course exists to avoid.

Each command it knows was run against the genuinely broken system and its output captured. Nothing there is written by hand. CI re-runs every one of them against a freshly provisioned stack and fails the build if a single byte of the evidence has moved, which is the only reason the replay is worth trusting.

What it deliberately will not do:

• Grade anything. tse check states what a fixed system should look like in order to check it, so replaying that would hand over the diagnosis through the back door. Neither will it replay tse hint or tse answer.
• Invent output. A command that was not recorded gets told so plainly. If something close was recorded you are told that much and no more, because a list of the exact commands that matter is the third hint wearing a hat.
• Finish an exercise. Nothing typed into a page changes a system. That still happens in a Codespace or a local clone, and it is still the point.

Use it to see what the evidence looks like before deciding whether to set anything up. It lowers the cost of looking. It does not replace a shell.

Every exercise ends with questions

Fixing a system and being able to say what you proved are different skills, and only the second one survives into a technical round. So every exercise closes with three questions about the evidence you just gathered: what it established, what it pointedly did not, and which move earned the first look.

Answers are graded the moment you give them, and every option explains itself, the correct one included. Being told only that you were right teaches nothing, and being told only that you were wrong teaches less.

Answer them in the terminal with tse quiz, or on the exercise page itself.

If you are preparing for an interview, the spoken answer template is worth keeping alongside this. Talking through your reasoning out loud is a separate exercise from proving it, and it is optional here rather than required.