Web + HTTP + APIs

The client resolves the hostname to an address and opens a connection to a port, then sends an HTTP request with a method, path, headers and possibly a body. The server matches the path to a route, the handler validates the input, application logic runs and queries the database, and the result is serialized into a response with a status code and body. The connection carries no memory of previous requests, so anything the server needs to know arrives with each one.

A 4xx status says the request was wrong: bad input, missing authentication, insufficient permission, or a resource that does not exist, and the fix belongs with the caller. A 5xx says the server failed while handling a request it accepted, and the fix belongs with you. Diagnose 4xx from the request itself, and 5xx from your own logs and stack traces for that request.

Write a Dockerfile that installs dependencies and states the command to run, build it into an image, then run the image as a container with the port mapped and the configuration supplied as environment variables. The image is the artifact and the container is the running instance. Nothing secret goes into the image, and anything written inside the container is gone when it is replaced.

The deployed environment differs in configuration, filesystem, network and often resources. Environment variables that exist on your machine may be absent there, paths and ports differ, outbound and inbound access is restricted, and the deployed instance is reachable by anyone. Most first-deploy failures are a missing environment variable or a port the platform did not expect, which is why the logs are the first place to look.

Every subject in this stage has review questions. The condition is met when you can answer them out loud, without notes and without looking anything up, in your own words rather than a recited definition. An explanation you can only give with the material open is recognition, not recall.

Complete means each exercise satisfies its stated requirements and its done-when criteria, not that you attempted it. Where an exercise says you should be able to explain or defend something, that explanation is part of completing it. A stage whose source lists no exercises meets this through its owned project milestone instead.

Works means it runs end to end from a clean checkout, on the inputs it was built for, with the failure cases it claims to handle actually handled. It is not a notebook that produced a result once. Someone else following your README should be able to run it without asking you a question.

There is something that would fail if the behaviour regressed, and you have watched it fail. That can be automated tests or a written verification procedure with recorded results, depending on what the stage produces. A test that has only ever passed is evidence of nothing.

The README says what the project is, how to install, run and test it, and why it is built the way it is: the choices you made, the alternatives you rejected, and what you deliberately left out. A list of commands with no reasoning does not meet this condition.

Delete the central piece and write it again from an empty file, without your previous version, a tutorial, or generated code in front of you. It does not have to be identical, it has to work and you have to be able to explain every line. This is the condition that separates having finished from being able.

Record a gate exam and score yourself honestly against the dimensions the roadmap defines: recall, implementation, debugging, testing and design judgment. Elapsed time, hours watched and completed resources count for nothing here. Checking the boxes without a recorded exam does not open the gate.

Ask an AI reviewer to examine the work against this stage's concepts and report foundational misunderstandings, not style. A foundational blocker is a misconception that later stages would build on, such as leakage, a broken abstraction, or an explanation that is confidently wrong. Nothing in that class may remain open when you pass.