What you can now build, and what the exam checks

You have a deployed tool with your instruments in it. This lesson names the transferable part, and tells you plainly what the exam will ask.

The part that was never about watchlists

Four things you can now do to any product, not just this one.

You plan before you prompt. A page of writing that says what the thing is for, what it is not, and how you will know it is done. That page is what makes a generated diff reviewable, because without a standard every change looks equally plausible.

You read what you were handed. Four questions: did it change anything I did not ask for, does it touch data fetching, what happens when it fails, can I explain it. That habit found a leaked key, twelve round trips where one would do, and a race condition in a single sixteen-line component in unit 2.

You keep secrets on one side of a line. A server-side proxy, one place that reads the key, a build you grep rather than trust, and CI that keeps checking when you stop remembering. This transfers to every API you ever integrate.

You say how old your data is. Read from the response, not from the plan name, expressed as what it supports. This is the difference between a tool you trust at 7am and a tool that is confidently wrong.

What is deliberately still missing

Your tool checks rules only when the page loads. It cannot watch overnight. Its data is as fresh as your tier allows and no fresher. It holds one list rather than a universe you can filter, and it has no memory of what a strategy would have done.

Each of those is a later course: a screener that narrows a whole market, a backtester honest about its own biases, a dashboard that composes all three, and a shipped product hardened for other people. None of them is a new kind of problem. They are this problem, deeper.

What the exam asks

Ten questions, seventy percent to pass, twenty-four hours before a retake. They are drawn from a pool several times the size of one paper, so a retake is a different paper. It is not a memory test — it is code, on fixtures, and it checks the four things above.

Expect to be asked to:

• Spot the leak. A component is shown; you identify what puts the key in the browser. "use client" next to NEXT_PUBLIC_ is the signature.
• Predict a response. Given a proxy handler and a request, say what comes back — including when the caller supplies their own api_token.
• Read the meter. Given a starting count and a sequence of page loads, say what the usage figure shows.
• Find the failure. A fetch with no res.ok check, or a single-ticker response handled as an array: name what breaks and when.
• Judge freshness. Given a timestamp and a rule, say whether the rule can fire honestly.

Nothing depends on live market state; every fixture is fixed, so the answer is the same today and next year.

Before you sit it

Two things worth doing first, both quick.

Re-read your own PLAN.md, including the wall numbers you measured. If the definition of done you wrote in unit 1 is now true, say so in the file. If it is not, note which part and why, because that sentence is the beginning of your next course.

Then look at your git log. If the messages say why rather than what, and each commit is one change you could explain, you have the habit the rest of the track depends on. If they say "update" eleven times, that is the thing to fix before course 2, where you will be rebuilding this code rather than adding to it.

Try it now

Open your PLAN.md next to your deployed tool and mark each line of your definition of done as met or not met. Then write one sentence naming the next thing you want it to do. Take that sentence into course 2 — the screener is built by rebuilding what you have, and knowing what you want from it is how you avoid starting over.