Pass the CCDV-F Exam 2026: Claude Certified Developer Course

The same lesson file counts as 4,351 tokens on Claude Haiku 4.5 and 5,772 on Claude Haiku 5.5. Find out why. See what a token is, how Claude writes a reply one token at a time until it finishes or hits max_tokens, and why the context window is one budget shared by the system prompt, messages, tools, documents and the reply. Read it all in Anthropic's docs. Then count a real lesson on two tokenizers with the free token counting API, and watch a 20-token cap cut a streamed reply off mid-sentence.

By the end of this lesson you can:

• Explain tokens and next-token generation.
• Treat the context window as one budget.
• Count tokens, and know why counts differ by model.

Send the same prompt five times and get five different questions. Set temperature to 0 and the question repeats. Try that on a newer model and you get a 400 error. See how Claude picks each token from a probability distribution, what temperature, top-k and top-p change, and why identical requests can still return different text. Read the rules in Anthropic's docs, including the newer models that fix sampling. Then build a check that accepts different wording on every run and still tests what must hold.

By the end of this lesson you can:

• Explain temperature, top-p and top-k.
• Expect different outputs, and test for it.
• Steer newer models without sampling parameters.

Underneath every SDK call is one HTTP request: a method, a URL, three headers and a JSON body. Send that request yourself with curl and get HTTP 200. Drop max_tokens and get a 400, empty the key and get a 401. Then send the same request with the Python SDK and with the TypeScript SDK, and see what the SDK adds: headers, types, retries, timeouts and typed errors. Read the API overview, the errors page and the Messages API reference in Anthropic's docs, and leave able to build a valid request from model, max_tokens, system and messages.

By the end of this lesson you can:

• Read an HTTP request and its status code.
• Call Claude with curl, Python and TypeScript.
• Build a valid Messages API request.

Three turns with Claude, and on the third it quotes its first question word for word. Then a fresh call without the history has no idea. Read a whole Messages API response field by field: the content blocks, stop_reason, stop_details, usage, and the request ID from the response headers. Handle every stop reason with one match statement, and see four of them for real: end_turn, max_tokens, stop_sequence and tool_use. Check the stop reasons and refusals in Anthropic's docs, and hold a conversation on an API that remembers nothing.

By the end of this lesson you can:

• Read a response: its content, stop reason, usage and request ID.
• Handle every stop reason.
• Hold a conversation on a stateless API.

A reply stops halfway through a quiz question: the stream broke. Then the rest picks up mid-line, as if nothing happened. Read a Messages API stream as raw server-sent events, from message_start to message_stop, and let the Python SDK assemble them into the final message. Break a stream on purpose, keep the partial text, and resume it. Then run six calls at once with the async client and a semaphore that keeps three in flight, so a burst doesn't turn into 429s. Check the streaming, SDK and rate-limit pages in Anthropic's docs, and compare SSE, WebSockets and polling for a realtime feature.

By the end of this lesson you can:

• Stream a reply, event by event.
• Recover a stream that breaks partway.
• Run calls at once, with a limit.

One quiz question, four models: Haiku 5.5 answers in a second for a fraction of a cent, Opus 5.5 takes twice as long and costs over forty times as much. Which one is right depends on the job. Match a model tier to the quality, latency, cost and volume a feature needs: start efficiency-first with a Haiku and step up when your evals say so, or start capability-first and step down. List the models your key can use with the Models API, see which snapshot an alias points to, and pin the ID you tested. Then follow a model's lifecycle from active to retired, and run an upgrade check: two Haiku 4.5 habits that Haiku 5.5 rejects with a 400, the migrated request that works, and a retired model that answers 404. Check the model selection, model ID, deprecation and migration pages in Anthropic's docs.

By the end of this lesson you can:

• Match the model to the job.
• List models and pin a version.
• Upgrade without breaking things.

Thinking costs tokens you may never see. Which model to use and how hard it reasons on one request are two separate choices. Turn reasoning into request fields: adaptive thinking (thinking: {"type": "adaptive"}), the thinking display, effort (output_config.effort) and max_tokens as the hard cap. Send an easy task and a hard puzzle to Claude Haiku 5.5 at low and high effort, and read the thinking blocks and the thinking tokens in usage, billed even when the display is omitted. Then translate the exam's older words: an extended-thinking budget (budget_tokens) works on Haiku 4.5 and is a target, not a cap, while Haiku 5.5 rejects it with a 400 that names today's controls. Fast mode buys faster output on Opus at a higher price, not a smarter answer. Check the thinking, effort and fast mode pages in Anthropic's docs.

By the end of this lesson you can:

• Tell choosing a model from choosing how hard it reasons.
• Set thinking and effort, and read the cost.
• Translate the exam's older terms.

Half a cent per request sounds cheap, until a finished task takes two requests and costs a cent. Price a request from its usage: input times the input price plus output times the output price, with cache writes at 1.25 times and cache reads at a tenth of the input price. Count the tokens before you send and refuse a request that could cost too much, then log every request to a JSONL file. Write and check five quiz questions about a lesson file, and compare the cost per request with the cost per completed task. Then price one request six ways: the baseline, a cache write, a cache read, a shorter output, Claude Haiku 5.5, and low effort. The free wins come first (caching, trimming, batch for work that can wait); the tradeoffs (model tier, effort, output length) need your evals. Check the pricing, token counting, prompt caching and batch pages in Anthropic's docs.

By the end of this lesson you can:

• Count first, and log every request.
• Price the finished task, not the call.
• Pull the right lever.

Four traps, one module. The wrong answers on the exam's Model Selection and Optimization questions are rarely silly: they are real fixes for a different problem. Meet the four classic traps of this domain: retry it, make it bigger, yesterday's API, and the wrong yardstick. See each one against the docs (the Errors page, Choosing a model, the Claude Haiku 5.5 migration guide, Optimizing for cost and intelligence) and against the module's own runs: the HTTP 400 that no retry fixes, four models on one task, a thinking budget that Haiku 5.5 rejects, and the cost per completed task. Then solve one original exam-style scenario, take Module 1 home on one page, and move on to Lab 1 and the Module 1 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 1 on one page.

A one-line prompt works in a demo. In production, the reply has to be parsed, the questions have to test the skill, and a quote has to really be in the source. A production prompt puts the long input on top in its own tag, then context (who the output is for, and why), instructions written as success criteria, and a format section that says exactly what shape comes back, phrased as what to do and why, not as shouted rules. Then you measure the change with code checks over several runs instead of eyeballing one reply. In Quiz Forge, the Lab 1 prompt becomes a versioned file, version 2 adds XML tags, context, criteria and format, and a checker runs both five times. Check the prompt engineering overview and prompting best practices pages in Anthropic's docs.

By the end of this lesson you can:

• Say what you want, for whom, and why.
• Structure the prompt with XML tags.
• Constrain the output, not the model.

An instruction's place decides how much it counts, what it costs, and who it comes from. Standing operator rules go in the system prompt, written once. The user turn carries this request and its data. Text you didn't write, like a lesson file, a web page or a tool's output, is data: deliver it in a tool result or a tagged user block, never in the system prompt. Rules about a tool go in its description. A rule that starts partway through a session goes in a mid-conversation system message, which keeps the cache. For Claude Code, "always" rules go in CLAUDE.md, and on-demand procedures go in a Skill. In Quiz Forge, the standing rules move into system.md, a planted line in a lesson file is tested in three places, and a new rule is added mid-session two ways, with the cache read and write counted. Check the mid-conversation system messages, prompt-injection, tool-definition and Claude Code pages in Anthropic's docs.

By the end of this lesson you can:

• Put each instruction where it belongs.
• Write standing rules once.
• Keep untrusted text out of your instructions.

Instructions describe a format; examples show it. They're one of the most reliable ways to steer Claude's format, tone and structure, and they come with two costs: Claude can copy them, and their tokens ride along on every call. Start with zero examples and measure. When the format or tone drifts, add three to five, make them different from each other, wrap each one in example tags, and write them about other content than the input, so they teach the shape without lending a scenario. In Quiz Forge, three fresh examples go into their own prompt file, and a script counts exact quotes and copying with zero, one and three examples, then with one example about the same lesson. Check the prompting best practices and output consistency pages in Anthropic's docs.

By the end of this lesson you can:

• Pick how many examples a task needs.
• Write examples that can't be copied.
• Weigh their token cost against the gain.

When code reads Claude's reply, a format described in the prompt is only a request: one sentence before the JSON, one code fence around it, and the parser stops. Structured outputs turn the schema into a constraint. With JSON outputs, messages.parse() takes a Pydantic model, sends it as output_config.format, and returns a validated object; with strict tool use, strict: true holds a tool's input to its schema. The schema guarantees the shape, not everything: a list can't be held to exactly four items, rules across fields and facts still need code, and a refusal or max_tokens can still break it. So design the schema to leave no room: required fields, enums, fixed slots instead of open lists. In Quiz Forge, one script asks for the same two questions four ways and counts, in code, valid replies, the four-options-one-answer rule, and input tokens. Check the structured outputs and strict tool use pages in Anthropic's docs.

By the end of this lesson you can:

• Get schema-valid JSON with parse().
• Use a strict tool for valid arguments.
• Design schemas Claude fills reliably.

A reply can match its schema and still be wrong: the schema checks the shape, not the facts, and a confident quote can be stitched together from real phrases in a new order. So code decides what passes. Check stop_reason before parsing: a refusal is a normal response, not an error, so don't send the same request again; max_tokens means a cut-off reply, so fail loudly. Then parse defensively, and check the business rules the schema can't express: the number of questions, four different options, a quote found word for word in the lesson. When a reply breaks a rule, send the reasons back and ask again, at most twice, then stop with the reasons. In Quiz Forge, validate.py rechecks Lesson 2.4's replies, repair.py runs the repair loop, and tests prove each rule rejects the right thing and the loop stops at its limit. Check the reduce hallucinations, stop reasons and refusals pages in Anthropic's docs.

By the end of this lesson you can:

• Validate replies in code, and parse defensively.
• Repair invalid output, with a retry limit.
• Check claims against the source, and handle refusals.

Rewriting a prompt by feel changes three things at once and leaves no way to know which one helped. So treat the prompt like code. Measure a baseline on fixed inputs, with checks in code, and count the failures by kind. Read the biggest kind to find the pattern, change one thing aimed at it, and measure again on the same inputs. Keep the change or revert it. A few runs show a direction, not a rate. Every measured prompt is a numbered file that's never edited, with a changelog of what changed, why, and what it measured. The lesson text is untrusted input, so it gets cleaned before it goes inside its tags. In Quiz Forge, sanitize.py cleans each lesson, measure.py and failures.py measure prompt v3 and read its failed quotes, and v4 changes one sentence and is measured the same way. The lesson then checks Anthropic's docs: the prompt engineering overview, the page on success criteria and evaluations, and the page on mitigating jailbreaks.

By the end of this lesson you can:

• Diagnose a prompt from its failures.
• Change one thing, then measure.
• Sanitize inputs, and version prompts.

Four traps, one module. The wrong answers on prompt engineering and output handling questions sound like effort: shout the rule, upgrade the model, add more examples, trust the reply. Meet the four classic traps of this module: say it louder, make it bigger, more of the same, and take its word. See each one against the docs (Prompting best practices, Structured outputs, Reduce hallucinations, Define success criteria and build evaluations) and against the module's own runs: "Reply with only JSON" that produced zero valid replies, two prompts on the same model, an example Claude copied five times out of five, and a quote that code caught in a valid reply. Then solve one original exam-style scenario, take Module 2 home on one page, and move on to Lab 2 and the Module 2 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 2 on one page.

Claude can't open your library, call your API or load a web page. It can ask, with a structured request, and your code does the work. A tool is a name, a description and an input schema. When Claude wants one, the reply stops with stop_reason "tool_use" and a tool_use block (an id, the tool's name, the input). Your code runs it and sends back a tool_result with the matching tool_use_id, and the loop goes on until the stop reason is something else. In Quiz Forge, one tool is wired up by hand. Then the same tool gets a vague description and a clear one, five runs each. Last, three tools run in a loop, with one dispatch table and a tool that reaches the web under rules set in code. Check the tool-use pages in Anthropic's docs.

By the end of this lesson you can:

• Define a tool Claude calls correctly.
• Run the tool-use loop by hand.
• Dispatch calls to your own code.

A real agent asks for many things at once, and real tools fail. One reply from Claude can hold several tool_use blocks: parallel tool use. You choose how to run them, but every result goes back in one user message, matched by tool_use_id. A failure is a result too: is_error: true, with words that say what went wrong and what to try instead. With thinking on, the whole tool loop is one assistant turn, so each reply goes back exactly as Claude sent it, thinking blocks and signatures included. In Quiz Forge, the tools move into the package, run a reply's calls together, and return errors Claude can act on. The lesson then checks Anthropic's docs: parallel tool use, handling tool calls, and thinking with tool use.

By the end of this lesson you can:

• Run parallel tool calls, and return them together.
• Report failures Claude can recover from.
• Keep thinking blocks across tool turns.

Every tool loop so far looked the same: send, check the stop reason, run each call, send the results back, stop at a limit. The SDK's Tool Runner runs that loop for you. But some tools shouldn't run the moment Claude asks: a tool that changes something needs a person first, and that takes a loop of your own. Some tools don't run in your code at all: web search, web fetch and code execution are server tools, run by Anthropic, under their own rules. And every tool you define goes out with every request. In Quiz Forge, the Lesson 3.2 source check moves to the Tool Runner, a save tool waits for a person's approval, web fetch loads a docs page and refuses one Claude guessed, and 39 tools shrink to 3 loaded plus tool search. Check the tool-use pages in Anthropic's docs.

By the end of this lesson you can:

• Run the loop with the SDK Tool Runner.
• Tell client tools from server tools.
• Add approvals, and keep the tool set lean.

So far every lesson went to Claude as text. Real material isn't always text: a slide is an image, a handout is a PDF. A practice question that quotes a lesson is only useful if the quote is really there, and you can find it. And a PDF sent with every request is uploaded again every time. In Quiz Forge, a slide becomes a practice question, with its image tokens predicted and measured. Lesson 3.2 goes in as a document twice, as text and as a PDF, with citations: every claim comes back pointing to its exact passage, by characters or by page. Last, the PDF goes up once with the Files API, and later requests send only its file_id. Check the vision, PDF, citations and Files API pages in Anthropic's docs.

By the end of this lesson you can:

• Send images and PDFs in the right blocks.
• Get answers cited back to the source.
• Upload once, and reuse the file_id.

Quiz Forge writes practice questions for every lesson in the library, and nobody sits and waits for them. Yet every request so far went through the Messages API, at full price, built for someone waiting on the answer. When nobody's waiting, the Message Batches API runs the same requests asynchronously at half the price, on every token. In Quiz Forge, every lesson goes out as one batch of 15 requests, one of them broken on purpose. A check while it runs says to come back later, and the workspace's batches and files are read a page at a time. When the batch has ended, each result is matched to its lesson by custom_id, because results come back in any order, and checked in code. The broken request failed alone, and isn't billed. Check the batch processing page in Anthropic's docs.

By the end of this lesson you can:

• Choose the batch API for volume that can wait.
• Submit a batch, then collect its results by custom_id.
• Read results and lists the right way.

Four traps, one module. The wrong answers on tool and Claude API questions sound like shortcuts: run it faster, let the platform do it, write a rule, keep the loop simple. Meet the four classic traps of this module: faster means cheaper, built-in reaches anything, just tell it, and drop the thread. See each one against the docs (Batch processing, Server tools, Web fetch, Tool runner, Citations, Parallel tool use) and against the module's own runs: nine tool calls back in one second at the same price, and a batch at half price; a guessed URL that web fetch refused, and our own client tool that reached the page; a vague description that sent invalid ids five times out of five, an approval step, and citations with their pages; and a generic error, a thinking block without its signature, and batch results out of order. Then solve one original exam-style scenario, take Module 3 home on one page, and move on to Lab 3 and the Module 3 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 3 on one page.

When a job uses a model and a few tools, the tempting answer is: make it an agent. But an agent costs more, takes a different path each time, and is harder to test. This lesson draws Anthropic's line between a workflow (our code sets the path) and an agent (the model sets it), walks through the five workflow patterns, and decides with four checks: complexity, value, viability and the cost of error. Then it measures. In Quiz Forge, a meter counts every request a job sends, the same job runs three times as a workflow and three times as an agent, and the decision goes in writing with its numbers. Read Anthropic's article Building effective agents.

By the end of this lesson you can:

• Tell a workflow from an agent.
• Match the job to a workflow pattern.
• Decide with four checks, and measure.

The agent from Lesson 4.1 ran with one guard: a turn limit. A loop that runs until Claude stops has no answer for the question that matters: what if it doesn't? It could loop on a hard input, spend more than the task is worth, or save something nobody checked. This lesson builds the loop with stops you choose: done, a turn limit, a budget checked before every request against its worst case, a refusal or a reply cut off at max tokens, and a person's no right before the one step you can't undo. It also covers what task budgets do, and what they don't. In Quiz Forge, the writer agent runs four times, and each run ends a different way. Read the docs tutorial Build a tool-using agent, the Tool runner docs, and the Task budgets docs.

By the end of this lesson you can:

• Write a loop that stops on purpose.
• Bound it: turns and budgets.
• Put a person before irreversible actions.

The agent loop from Lesson 4.2 sends the whole conversation on every turn. Give it four lessons in one task, and every lesson it has read rides along on every request after that. More context isn't only more cost: as it grows, recall from it gets less accurate. This lesson covers the three levers: clear old tool results, compact older turns into a summary, or restart with a fresh context. Each has a price, and the task decides which fits. In Quiz Forge, one agent writes questions for four lessons three ways: keep everything, clear old tool results with context editing, and restart per lesson. All three are measured. Read Anthropic's article Effective context engineering for AI agents and the Context editing docs.

By the end of this lesson you can:

• Spot context bloat and drift.
• Clear, compact or restart.
• Choose by the task, and measure.

Quiz Forge has a library of fourteen lessons. Add a tutor that answers questions about any of them, and the simplest move is to paste the whole library into every request. At this size, it works. But every question pays for all of it, and the answer doesn't point at the passage it came from. This lesson covers three ways to get knowledge into context: paste it all, retrieve the passages that matter, or let the agent search for what it needs. It splits the library into chunks, scores them with BM25, a keyword score, and sends the best three as search result blocks that Claude cites. In Quiz Forge, three questions go to the library three ways, and each way's requests, tokens, cost and right answers are measured. Read Anthropic's article Introducing Contextual Retrieval and the Search results docs.

By the end of this lesson you can:

• Choose retrieval over pasting it all.
• Retrieve passages Claude can cite.
• Let the agent search for what it needs.

In Lesson 4.3, four lessons in one context grew until the agent broke. A fresh context per lesson fixed it, one lesson after another. So can one agent hand each lesson to another agent, and run them at the same time? This lesson builds that shape: a supervisor plans the job, writes a brief for each part, and hands it to a subagent with its own clean context; only a short report comes back. It covers what a brief needs, why isolation is the point, what the extra agents cost, and when the pattern fits. In Quiz Forge, the same job runs three ways: one agent, one clean agent per lesson in sequence, and a supervisor with parallel subagents. All three are measured. Read Anthropic's article How we built our multi-agent research system.

By the end of this lesson you can:

• Design a supervisor and its subagents.
• Isolate context, and write clean handoffs.
• Judge when parallel agents pay.

Every session starts empty. Run the question writer on the same lesson today and again tomorrow, and tomorrow's session has no idea which quotes today's used. This lesson gives an agent memory that outlives the conversation, two ways: Claude's memory tool, where Claude asks for file operations and your code runs them, and your own store, which your code keeps, puts in the ask and enforces. It covers where memory lives (this session, this user, or the whole project), and how to keep it from inflating every request: cap it, keep only what the next task needs, and refuse paths that escape the folder. In Quiz Forge, a safe handler for the memory tool, then three sessions of the same job, three ways: no memory, the memory tool, and our own store. All three are measured. Read Anthropic's Memory tool docs and the article Effective context engineering for AI agents.

By the end of this lesson you can:

• Persist state across sessions.
• Choose memory's scope.
• Keep memory from inflating context.

In Lesson 4.2, we wrote the agent loop by hand. The SDKs offer to write that loop for you, and Anthropic offers to run the whole thing in its own cloud. Which one should you pick? This lesson places four ways to build an agent on two axes: who supplies the harness (you or Anthropic), and who hosts it (your process or Anthropic's cloud). The manual loop, the Tool Runner, the Agent SDK and Managed Agents each give something up: convenience, per-call control, weight and context, or locality, data retention and billed running time. A decision path picks one for the job. In Quiz Forge, the same small job runs four ways, and each one's tool calls, cost and time are measured. Read Anthropic's Tool Runner, Agent SDK overview and Managed Agents overview docs.

By the end of this lesson you can:

• Compare four ways to build an agent.
• Choose self-hosted or Anthropic-hosted.
• Name what each one gives up.

Our agent loop from Lesson 4.2 is about fifty lines. Frameworks offer to write it for us, and much more: graphs, multi-agent hand-offs, typed outputs, retries. Some of that is useful, but all of it is code you don't see and packages you have to carry. This lesson places Strands Agents, LangGraph and Pydantic AI by what each takes over (the loop, the control flow, or the typed output), weighs what a framework buys against what it costs, and shows the router and planner–executor patterns as frameworks spell them. In Quiz Forge, a pip dry run measures what each framework would add to the project before installing any, and one router is built three ways: in our own code, in Pydantic AI and in LangGraph, with the tokens of each measured. Read Anthropic's article Building effective agents and the Strands Agents, LangGraph and Pydantic AI docs.

By the end of this lesson you can:

• Place three frameworks in the landscape.
• Judge what an abstraction buys and costs.
• Spot router and planner–executor patterns.

Four traps, one module. The wrong answers on agent and context questions sound like upgrades: make it an agent, give it more context, tell it in the prompt, let everything share. Meet the four classic traps of this module: make it an agent, bigger context fixes drift, ask it nicely, and share everything. See each one against the sources (Building effective agents, Effective context engineering, Contextual Retrieval, Task budgets, the multi-agent research system, the Memory tool) and against the module's own runs: a workflow and an agent passing the same job, at about a cent and 2.6 cents a run; a router that cost twice the tokens inside a framework; parallel subagents that saved time, not money; one context that ran out while a fresh context per lesson saved all four; a pasted library at 162,000 input tokens against 7,300 retrieved; a budget and a person's no that stopped the loop in code; and memory a save check enforces, scoped to its lesson. Then solve one original exam-style scenario, take Module 4 home on one page, and move on to Lab 4 and the Module 4 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 4 on one page.

In Module 4 we built an agent loop by hand. Claude Code is a finished agent harness (the loop, the tools, the permissions and the sessions), and pointed at a repository it can save an afternoon or leave a twelve-file change nobody reviewed. The difference is how you operate it. This lesson drives one real feature through explore, plan, code and commit in Claude Code, with plan mode as the gate before any edit and every edit approved by hand. It recovers an unwanted change with a checkpoint, keeps the session lean with /context, /compact and /clear, comes back to it with --continue and /resume, and chooses the permission mode by the risk of the task, including what auto mode does and doesn't guarantee. Read Claude Code's best practices and its pages on permission modes, checkpointing and commands.

By the end of this lesson you can:

• Run explore, plan, code, commit.
• Manage sessions: resume, rewind, compact, clear.
• Match the permission mode to the risk.

Every Claude Code session starts with an empty context: whatever we have to explain again, every time, costs time and drifts. This lesson moves that context into files, at the right level. It runs /init on a repository that already has a CLAUDE.md and prunes the result by hand to what Claude can't discover, moves the question rules into a path-scoped rule that loads only when Claude touches the bank, shows auto memory (the notes Claude writes for itself), and keeps personal notes in CLAUDE.local.md, out of git. Then it configures settings, a separate stack: shared rules in the committed .claude/settings.json, a personal default in .claude/settings.local.json, and proves on screen which one wins and that allow lists merge. Read Claude Code's pages on memory and settings, and the help-center article on CLAUDE.md.

By the end of this lesson you can:

• Initialize a repository and write a lean CLAUDE.md.
• Use the CLAUDE.md hierarchy, rules and auto memory.
• Configure settings scopes, and know which one wins.

Since Module 2 we've pasted the same item standard into prompts again and again, and a pasted procedure drifts a little every time. Putting all of it in CLAUDE.md would cost tokens on every request, even when nobody writes questions. This lesson gives each instruction its home, by when it loads and where it runs. It writes a skill (write-exam-item) whose description sits in context and whose body loads only when it's used, and watches Claude load it on its own. It turns a workflow into a command only a person starts (/new-items, with disable-model-invocation). And it defines a reviewer subagent with its own read-only tools, a pinned Haiku model, project memory and the skill preloaded, then plants a wrong answer key to see whether the reviewer catches it. Read Claude Code's pages on skills, subagents, model configuration and the features overview.

By the end of this lesson you can:

• Author a skill and a slash command.
• Define a subagent's tools, model and memory.
• Choose between CLAUDE.md, a rule, a skill or a subagent.

Since Lesson 5.2, our CLAUDE.md says that only the quizforge review command, after a person's yes, writes to the approved bank folder. That line is a request: Claude weighs it, and a direct enough prompt can talk it out of it. In this lesson's first run, before any hook, Claude declined on its own. The request held that time, but nothing made it hold. This lesson turns the rules that must hold every time into hooks: a PreToolUse guard that blocks writes to the approved bank folder with exit code 2, a PostToolUse hook that runs ruff on every Python file Claude edits, and a Stop hook that won't let Claude finish while the tests fail. Each hook is tested with piped JSON before any session, and then by the hook tests. Read Claude Code's hooks guide, the hooks reference and the memory page.

By the end of this lesson you can:

• Explain why a hook runs every time, while an instruction is only a request.
• Write PreToolUse, PostToolUse and Stop hooks.
• Test a hook with piped JSON before using it in a session.

Our skill, command, reviewer and hooks live in one repository's .claude/ folder. A teammate's laptop, CI and the next repository all need the same setup, and copied folders drift. This lesson packages them as plugins: a quiz-forge-tools plugin that depends on a separate qf-format plugin with a version range, both listed in a marketplace inside the repository. It validates the manifests, tags the releases, and turns the plugins on for everyone who clones the repository, through its own settings. The guard from Lesson 5.4 still holds, now from the plugin. Read Claude Code's pages on plugins, creating a plugin, plugin dependencies and managing plugins for an organization.

By the end of this lesson you can:

• Package components into a plugin.
• Declare dependencies and publish a marketplace.
• Manage plugins for a team.

A review that only happens when someone remembers doesn't happen. This lesson runs Claude Code with no one at the keyboard: claude -p with JSON output, a JSON schema for a verdict a script can parse, stream-json events, and streaming input. Then it wires the same review into GitHub Actions on a real pull request, locked down with dontAsk, an exact tool list, a turn limit and a budget. The reviewer caught the answer key we planted. On the second run it caught a flaw we hadn't planted. The merge was still a person's click. Read Claude Code's pages on running programmatically, the CLI reference, streaming input, GitHub Actions and best practices.

By the end of this lesson you can:

• Run Claude Code headless, with JSON and streaming output.
• Wire Claude Code into GitHub Actions.
• Review AI work with calibrated trust.

In Lesson 5.6 our review ran from a shell script. An application needs it as code: a typed verdict it can store, its own limits, its own log of what was read, and a way to ask a follow-up. This lesson builds that reviewer with the Claude Agent SDK, Claude Code's harness as a Python library: one query() per pending question, with the plugin's checklist skill loaded through the project's settings, read-only tools, a Python hook that confines and logs every read, a schema-checked verdict, and a session we resume to ask why. Then it removes the settings and the plugin to show what the reviewer loses. Read the Agent SDK pages on the overview, permissions, Claude Code features, skills, sessions and system prompts.

By the end of this lesson you can:

• Explain the Claude Code harness as a library.
• Build an agent with query(), tools, permissions, sessions and hooks.
• Reuse the same skills and settings in the SDK.

The same model can answer the same question differently in claude.ai, in Claude Code and through the API, because each interface hands it different instructions before your message arrives. This lesson maps what reaches the model in each one, then proves it: one question about Quiz Forge's own rule, asked six ways on Haiku 4.5. Only the paths that loaded the project's instructions knew the answer. Then it measures session hygiene: four reviews in one shared Agent SDK session against four fresh sessions, and turns "one session per item" into a rule the code enforces, with a test. claude.ai's side comes from Anthropic's docs: the system prompt release notes, projects and their memory, and Agent Skills.

By the end of this lesson you can:

• Explain how each interface reads instructions.
• Keep boundaries between users, sessions and data.
• Practice session hygiene.

A line in CLAUDE.md asks; a hook decides. The wrong answers on Claude Code and Agent SDK questions sound easy: write it in CLAUDE.md, skip the prompts, load everything, build it yourself. Meet the four classic traps of this module: put it in CLAUDE.md, turn off the brakes, keep it all in one context, and build it yourself. See each one against the sources (the memory page, the hooks guide, permission modes, the features overview, plugin dependencies, the Agent SDK overview) and against the module's own runs: Claude declining a move on its own, then a PreToolUse hook blocking it before it ran; plan mode with every edit approved; a headless review with read-only tools and a schema that failed the build in CI; a CLAUDE.md pruned from 33 lines to 20; a subagent's 20,000 tokens kept out of the conversation; one shared session growing from 13,000 to 40,000 tokens of context; and an Agent SDK reviewer reusing the plugin's skill. Then solve one original exam-style scenario, take Module 5 home on one page, and move on to Lab 5 and the Module 5 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 5 on one page.

In Module 3 we wired tools into one app by hand; every other app that needs the same system would write that code again. MCP, the Model Context Protocol, puts the integration on the system's side, once. This lesson draws its three roles (the host, one client per server, and the servers), its two layers, and its three server primitives, with who decides when each is used. Then it shows them for real: Anthropic's public Claude Code docs server added to Claude Code with one command, Claude choosing its search tool (with a permission prompt), a write tool denied, a resource the person attaches, and a short Python script that lists and calls the same server's tools with no model at all, then talks to a second server on an older protocol revision.

By the end of this lesson you can:

• Explain hosts, clients and servers.
• Tell tools, resources and prompts apart.
• Explain why MCP makes a capability reusable.

Quiz Forge's library tools (search and the quote check) lived inside one app. This lesson turns them into an MCP server with the Python SDK: a resource template for the lessons, three read-only tools with typed inputs and structured results, and a prompt for drafting items. It tests the server three ways, in memory with the SDK's own client, in the MCP Inspector's terminal and command-line clients, and in Claude Code, and then uses the same server from a small API app on Haiku 4.5. Along the way: the two rules that bite first, stdout is the wire and errors are raised, not returned.

By the end of this lesson you can:

• Expose tools, resources and prompts in Python.
• Test a server with the MCP Inspector.
• Connect it to Claude Code and an API app.

A server on one laptop helps one person; teammates, CI and production apps need it shared, reachable and able to scale. This lesson compares the transports (stdio, Streamable HTTP, and WebSocket as a custom option), the stateful way a client started talking to a server in the 2025 revision and the stateless way of the 2026 revision, and which side asks whom: the client calls the server, and the server can ask the user through elicitation, while sampling and roots are now deprecated. In the hands-on, the course-library server gains an HTTP mode and a question for the person, a curl probe shows both revisions answering from one server, Claude Code gets the server at project scope (with its approval prompt), a personal server at user scope and a name collision, and the Messages API calls a public MCP server itself with the connector, and refuses a localhost URL.

By the end of this lesson you can:

• Choose a transport, stateful or stateless.
• Know sampling, roots, elicitation and notifications.
• Set MCP scopes in Claude Code and use the API connector.

Quiz Forge now has all four kinds of capability: Anthropic's built-in tools, a custom tool, a Skill and an MCP server. Picking the wrong one has a price: a server nobody else uses, a tool copied into three apps, or a checklist pasted into every prompt. This lesson places the four options on two questions (who writes it, and where it runs), weighs them on four dials (reuse, maintenance, context cost and control), and turns that into one decision path. In the hands-on, a short script measures what each option adds to a request in tokens, Claude Code shows what it keeps in its own context, git grep shows one function behind two adapters, and the decision goes into docs/decisions.md with its numbers.

By the end of this lesson you can:

• Apply a decision rule to each option.
• Weigh reuse, maintenance, context cost and control.
• Justify the choice in a design review.

Our library server answers anyone who can reach localhost. A bank's security review asks four questions before anything ships: who is calling, with what rights, through which network path, and who can see the data. This lesson answers them the way the MCP specification and the Claude docs describe. Over HTTP, the MCP server is an OAuth resource server: it checks every token's audience, scope and expiry, and it never passes a token on. Over stdio, the process is the boundary. Private systems are reached without inbound ports, and the organization controls which servers run. In the hands-on, the library server gets a token check and proves it with four probes (401, the metadata, 200 and 421). Claude Code reaches it through a header helper, so the token stays out of every config file. The token is rotated with no reconnect, the read tools are allowlisted, and the scope a security review starts from goes into docs/security-review.md.

By the end of this lesson you can:

• Authenticate MCP connections the enterprise way.
• Reach private-network systems safely.
• Scope a modernization engagement for review.

The fix was never to open the door. The wrong answers on tools and MCP questions sound like quick wins: paste the data in, write it in the prompt, open a port, build a server. Meet the four classic traps of this module: paste the data in, hard-code it in the prompt, open it up to make it work, and build the biggest thing. See each one against the sources (who controls each MCP building block, progressive disclosure for Skills, Claude Code's headersHelper, workload identity federation, the MCP connector's limits, the authorization spec, tool use, and the stateless 2026-07-28 revision) and against the module's own runs. A resource the person attached, read in with no tool call. A custom tool costing 767 tokens on every request against a Skill's 44. A deny rule instead of a sentence. A token handed over by a helper, rotated with nothing edited. The connector refusing localhost, a foreign Origin getting a 403, and no token getting a 401. Then solve one original exam-style scenario, take Module 6 home on one page, and move on to Lab 6 and the Module 6 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 6 on one page.

At volume, some requests fail every day: a rate limit, an overloaded API, a deploy with a wrong model name, a monthly cap reached at two in the morning. Retry everything and you burn money and hide bugs. Retry nothing and you drop work. This lesson sorts every failure from the Claude API into a class with its own recovery: wait and retry, stop and alert, fix the request, or fall back. In the hands-on, we write a local mock of the Messages API and watch the SDK's own retries hit it in real time: retry-after honored to the tenth of a second, a spend cap the SDK retries anyway, and a timeout that costs 16 seconds. Then Quiz Forge gets the policy the SDK can't know: a recovery decision per error class, retries and timeouts per feature, and tests that need no network.

By the end of this lesson you can:

• Classify errors as retriable or terminal.
• Back off with retry-after and SDK settings.
• Pick a recovery for each class, refusals too.

"It didn't work" can mean a dropped connection, a 429, a bad request, a refusal, or a reply that parsed and was still wrong. Each has a different owner and a different fix, and without a request id and a trace, the team guesses. This lesson adds OpenTelemetry to Quiz Forge with one SDK middleware and one wrapper: a span per HTTP attempt, a span per model call with the GenAI attribute names, and a span per check. Then it breaks the same job in two layers and reads the trees: three red 529 attempts and no model output (the integration layer), and green 200s with a reply cut off at max_tokens (the model output). One real run is traced end to end, and its request id is followed from the trace to the usage log.

By the end of this lesson you can:

• Log requests, request IDs and usage.
• Trace calls with OpenTelemetry.
• Tell integration failures from model-output failures.

Reading three outputs after a prompt change tells you nothing about the hundredth. Without criteria, "better" is a mood, and without labels, a judge's score is a number nobody checked. This lesson builds Quiz Forge's own eval in the order that keeps it honest: what "done" means, written as numbers and committed before any eval code; code graders for every rule a program can check; reference labels with a reason for each; and an LLM judge for the judgment calls that are left. Then the judge is calibrated against the labels: a rubric change, a code check that takes a pattern off the judge, a step up to a bigger model, and one run on held-out labels it has never seen. It lands below the line we wrote, and the lesson keeps that result and says what it means.

By the end of this lesson you can:

• Define "done" as measurable criteria first.
• Build a dataset; pick code or model grading.
• Calibrate an LLM judge against labels.

An LLM app fails in more ways than ordinary code: a tool changes shape, the wiring breaks, output quality drifts after a prompt edit, or traffic doubles in exam week. No single kind of test sees all of that. This lesson gives Quiz Forge a test for each failure and a place where each one runs. The everyday suite stays offline and deterministic, with a guard that fails any test that touches the network. A contract test pins the MCP server's tools. Marked integration and end-to-end tests cross real boundaries on purpose. Lesson 7.3's eval becomes a regression gate in CI, with a spend cap, and it catches a "saving" that cut off every reply before the pull request merged. Finally, a load test against the local mock shows where more concurrency stops helping.

By the end of this lesson you can:

• Unit-test tools and MCP servers deterministically.
• Add functional, integration and end-to-end tests.
• Gate releases on evals; load-test for peak traffic.

Quiz Forge sends the same lesson again and again: one question per objective, every repair attempt, every revision after review. Paying full price for it every time is the cost lever Module 1 named. But caching only pays when the beginning of the request is identical and long enough, and when it fails, nothing tells you. This lesson shows how the cache reads a request, where the breakpoint belongs, how to choose a time to live with arithmetic, and how to catch the silent failures. In a cache lab on real requests, the same lesson is sent with the breakpoint in different places: no cache, a breakpoint that writes every time, a stable prefix that reads, a lesson under the minimum, a timestamp that cache diagnostics names, and another model. Then Quiz Forge's own generation caches the lesson, and its accounting stops undercounting.

By the end of this lesson you can:

• Put the stable prefix first.
• Place breakpoints and choose a TTL.
• Find silent cache invalidators.

A bill is the last place to find out that a feature is too expensive, too slow, or quietly worse. This lesson gives every Quiz Forge feature three budgets taken from its own usage log: cost per completed task, latency at p95, and how often the task must finish. A report holds the log against them every day and exits with an error on a breach. Then data picks the model and effort: a sweep runs the same six lessons on four routes, graded by code and by the calibrated judge, and generate moves to the cheapest route that meets the line. Finally, several agents share one budget through a ledger that reserves each request's worst case before it is sent, so agents running in parallel can't add up past the limit.

By the end of this lesson you can:

• Set cost, latency and reliability budgets.
• Route by model and effort, and share one budget between agents.
• Monitor quality in production.

A shorter reply limit to save tokens turned the eval gate red: zero of four lessons completed. Retries on every error asked a closed spend cap three times. The wrong answers on production questions sound like diligence: more retries, a stronger model, a higher limit. Meet the four classic traps of this module: retry everything, eyeball a few outputs, it's green so it's fine, and spend your way out. See each one against the sources (the spend-cap 429 with no retry-after, refusals as a normal response, measurable criteria and calibrated judges, regression evals, short bursts against a rate limit, the caching minimum and its only signal, cost per completed task) and against the module's own runs. Then solve one original exam-style scenario, take Module 7 home on one page, and move on to Lab 7 and the Module 7 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 7 on one page.

Quiz Forge reads lesson files that other people wrote, and agents read web pages, emails and tool results. Any of that text can carry instructions. This lesson starts with the question that decides the defense: who is the attacker, the user or the content? Then it attacks Quiz Forge on purpose. One hidden HTML comment in a copy of a lesson asks for every answer at A. It's measured five ways: clean, naive, with a polite line in the prompt, and hardened the way the docs describe, on Haiku 4.5 and on Haiku 5.5. Then come two controls: an injection screen, and the answer letter placed by code, so the instruction still reaches the model but no longer decides anything.

By the end of this lesson you can:

• Tell direct injection, indirect injection and jailbreaks apart.
• Keep untrusted content apart from instructions.
• Explain why a polite instruction is not a control.

A Claude app moves text between people, the API, logs and tools, and every hop is a place data can leak. This lesson follows Quiz Forge's data before protecting it. A data map counts the email addresses, phone numbers and key-shaped strings in every place the project sends or keeps text. A privacy fixture with an invented reader shows how a real person's details could ride in with a lesson. Then come three cuts: minimize before sending, redact before every write, and a seal on the approved bank, so an answer changed by hand after a person's yes is caught before the bank is used.

By the end of this lesson you can:

• Minimize, mask and redact personal data.
• Keep data from leaking across users and tools.
• Enforce who can call, see and change what.

No single check is reliable. A model can be steered, a pattern match has gaps, and a person gets tired. This lesson stacks checks that fail in different ways, then proves each one matters by switching it off. Quiz Forge's writer agent gets two switchable layers: Lesson 8.1's injection screen on every search result it reads, and the answer letter placed by code on every draft it saves. Then the agent runs on the poisoned lesson twelve times, with no layer, with one, and with both. After that, least privilege is written down: every agent's tools, with a reason for each, and everything else denied, enforced by a test. The lesson ends with a threat model and a content policy, both decided before the next feature is built.

By the end of this lesson you can:

• Layer guardrails from input to output.
• Give tools and agents the least privilege they need.
• Design for safety and content policy from the start.

Agents act. They delete files, push branches and read whatever they can reach. An instruction asks them not to; a hook decides, every time, before the action runs. This lesson writes one policy for destructive actions in Quiz Forge as a pure function, tests it as a table, and enforces it in two places: a PreToolUse hook in Claude Code and a hook callback in the Agent SDK. Both call the same function and return the same decision. You'll see how hooks sit with the permission system: deny rules hold whatever a hook says, a hook's deny holds whatever an allow rule says, and ask turns a risky step into an approval. Then Claude Code and the SDK each meet the guard, live.

By the end of this lesson you can:

• Block destructive actions with PreToolUse hooks.
• Enforce the same rules in the Agent SDK.
• Combine hooks with permissions and approvals.

To the API, a key is the whole identity of an app: whoever holds it spends your money, as you. This lesson asks three questions: who is calling, for how long, and how fast can we tell when it's not us? Quiz Forge gets a whoami that names the credential it uses (never its value) and the workspace its requests run in. A secret scan then runs in a pre-commit hook and in CI, so a key never reaches git. On camera, it stops a commit holding a fake key. Then the plan goes into writing: a key runbook with one workspace and one kind of credential per environment, and a plan to move CI to workload identity federation, so no key is stored at all.

By the end of this lesson you can:

• Manage keys across development, staging and production.
• Replace long-lived keys with workload identity.
• Set approval levels and monitor access.

With no layer in place, every answer key went where a poisoned lesson asked. With both layers on, none did. And Claude Code, asked for a recursive delete, was stopped by a hook. Each fix was a control in code, not a request. On security questions, the wrong answers sound responsible: a clear warning, a smarter model, one strong check, a carefully guarded key. Meet the four classic traps of this module: ask nicely, turn a knob on the model, one wall is enough, and one key forever. See each one against the sources (two threat models, untrusted content only in tool results, no browser agent immune, retention and redaction defaults, least privilege and defense in depth, permissions enforced by Claude Code, expiry that isn't hygiene, federation with no static secrets) and against the module's own runs. Then solve one original exam-style scenario, take Module 8 home on one page, and move on to Lab 8 and the Module 8 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 8 on one page.

Many AI projects that fail built the wrong thing well: nobody put a number on "fast", nobody asked about volume, and a compliance rule turned up at launch. This lesson takes a customer's paragraph and turns it into requirements an engineer can build and a tester can check. Functional requirements each get an acceptance test. Infrastructure requirements each get a number: latency, volume, cost, compliance and data residency. Then come two real checks before any product code. One tiny request per model shows that US-only processing rules out Claude Haiku 4.5 on the first-party API. A capacity model built from Quiz Forge's own logs shows the whole quarter costs about a dollar of generation. Finally, every requirement goes on the part of the architecture that meets it, and Claude Code, in plan mode, reviews the result without editing anything.

By the end of this lesson you can:

• Turn a business need into functional and infrastructure requirements.
• Capture latency, volume, cost, compliance and residency.
• Map requirements to an architecture.

A Claude feature is software. To reach users and stay healthy, it needs the same discipline as any other change, plus a few steps of its own: evals, and changes to prompts and models. This lesson compares three ways of moving work through a system's life (waterfall, iterative and DevOps) and the four phases they share: develop, implement, operate and maintain. Then it ships one real feature, Quiz Forge's export, all the way through. It starts with an issue, then a branch, a plan in Claude Code's plan mode that a person sends back and then accepts, and tests first with every edit approved by hand. After that come small commits, a pull request, the CI checks and a person's review, which Claude Code addresses. A person merges, and the work goes on: a runbook to operate the feature, and an issue to maintain it. At every step you can say what Claude did and what a person decided.

By the end of this lesson you can:

• Compare waterfall, iterative and DevOps life cycles.
• Ship through branches, pull requests and reviews.
• Fit Claude into each phase, with people deciding.

Code outlives its first design, and refactors and migrations are where working systems break. With Claude the typing is cheap, so the discipline around it is the job. This lesson runs a real refactor in Quiz Forge. It starts with a contract test written before any change, and that test finds a real bug: several lessons at once get a plain client with no retry policy. Claude Code then plans the refactor in plan mode and makes it one call site at a time, with the tests after each step and every edit approved by hand. After that, we read the diff, commit, and run a smoke test. Then it plans big without moving any code: a dependency map of Quiz Forge's own imports, a staged migration plan that starts with a judge, and a scope for a client's modernization engagement.

By the end of this lesson you can:

• Refactor safely, with tests written first.
• Plan a large migration in stages.
• Scope a code modernization engagement.

Many companies buy and secure their software through their cloud provider. For a Claude app, the platform decides which features you get, who handles the data, how you're billed and what your limits are. So where it runs is a requirement, not an afterthought. This lesson compares the five places Claude runs: the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud and Microsoft Foundry. It compares them by operator and data processor, features, compliance and residency, cost and procurement, and latency. Then it builds the switch into Quiz Forge: a table from the platforms' docs, one setting in the client factory, a check of what would break on each platform against the features Quiz Forge actually uses, and tests that need no cloud account. Finally it measures latency from where we are, and writes the decision down so security and procurement can sign off.

By the end of this lesson you can:

• Compare the five places Claude runs.
• Switch the client for a platform.
• Defend the choice to security and procurement.

A Claude app changes in four places at once: the code, the model, the prompts and the config. If you can't say which versions served a request, you can't debug it, and you can't undo it. This lesson treats a release as a stack: each layer has its own version and its own lock. It covers model IDs and snapshots, the model life cycle and its notice period, prompts and config as code, and plugin dependencies with version ranges. Then Quiz Forge gets its first real release. A model lock and a release manifest make it say exactly what ships, and the plugin gets a version the marketplace agrees with. Finally, the writer's model is upgraded as a release. The rule is written first, then the baseline and the candidate are run. The first candidate run is held, and the reasons turn out to be in our own code. After the fixes, the candidate ships through two pull requests, with tags, and a rollback that's one revert.

By the end of this lesson you can:

• Pin models, and version prompts and configs.
• Manage plugin dependencies with version ranges.
• Upgrade a model with evals, ship it through a pull request, and keep a one-commit rollback.

A second team shouldn't rebuild what the first one proved. But reuse fails in two ways: copies that drift apart, and shared deployments that leak data between teams. This lesson turns Quiz Forge into an accelerator: one package that any team installs, then points at its own course library with qf init. Each deployment gets its own folder, settings, prompt version, key and logs. Tests prove the boundaries hold, including one gap they found in our own code. A fleet view then reads every deployment's status, never its content. Finally, a fresh clone checks the README, and finds a gap. The lesson also covers giving back: every project documents its own contribution channel, and a good report is a minimal reproduction, with versions.

By the end of this lesson you can:

• Package an agent template, MCP server and evals.
• Contribute back through documented channels.
• Coordinate deployments across data and identity boundaries.

A newer model ran Quiz Forge's writing jobs against a rule written before the run, and the rule said hold: one job done in four. The causes were in our own code. After the fix, the same rule said ship. Newer wasn't better until the evidence said so. On Applications and Integration questions, the largest domain on the exam, the wrong answers sound modern and decisive: the newest model, the full rewrite, the famous platform, one deployment for everyone. Meet the four classic traps of this module: newest is safest, big bang, pick by brand or price, and copy-paste reuse. See each one against the sources (pinned model IDs and moving aliases, 60 days' notice, small testable increments, a strong judge before a migration, GitHub flow and protected branches, where inference_geo works, roots that aren't enforced, the project's own channel) and against the module's own runs. Then solve one original exam-style scenario, take Module 9 home on one page, and move on to Lab 9 and the Module 9 quiz.

By the end of this lesson you can:

• Spot the four classic traps.
• Know the fix each one hides.
• Hold Module 9 on one page.