Quick Reference: Domain 2 — Applications and Integration

2.1 Understanding Requirements

Functional = what the system does.
Non-functional = how well or under what constraints it operates.
Performance includes measurable latency and throughput requirements.
Scalability concerns increasing workload and concurrency.
Availability describes the expected ability of the service to remain operational.
Security requirements influence authentication, authorization, encryption, and auditing.
Cost constraints can influence model, caching, batching, and architecture decisions.
Convert vague requirements into measurable acceptance criteria.
Architecture decisions should be derived from requirements.
Clarify missing requirements before implementation.

If the question says...	The answer is likely...
The system must do X.	Functional requirement.
The system must respond within Y seconds.	Performance requirement.
The system must support Z concurrent users.	Scalability/capacity requirement.
The system must remain available for a defined percentage of time.	Availability requirement.
The system must protect sensitive customer data.	Security/privacy requirement.
The requirement says 'fast' without a measurable target.	Clarify and define measurable acceptance criteria.

Trap	Correct answer
Choosing a Claude model before clarifying the actual requirements.	First identify quality, latency, scale, cost, and capability requirements; then evaluate model options.
Treating latency as a functional feature.	Latency is generally a performance/non-functional requirement.
Assuming scalability and availability mean the same thing.	Scalability concerns workload/capacity; availability concerns whether the service remains operational.
Accepting vague requirements such as 'make it fast'.	Translate vague goals into measurable requirements and acceptance criteria.
Ignoring external-system requirements for Claude tools.	Tool integrations introduce requirements around authentication, authorization, errors, validation, and external-system behavior.

Life cycle: requirements, design, implement, verify, release, operate, change, retire.
A successful HTTP call only shows that implementation can reach the API.
Verification uses the acceptance criteria from 2.1.
Operation watches latency, errors, spend, and quality.
A model upgrade or a prompt edit re-enters review and verification.
Retire a model id or prompt by removing the live path, not by commenting it.

If the question says...	The answer is likely...
"the demo looked good"	That is not verification against the criteria
"swap the model id, it is the same family"	Treat it as a change and evaluate it
"edit the live system prompt"	Version it and verify it
"the job is done because status is 200"	Check the output against the requirement
"users are live and the eval set is old"	Operate, and refresh the evaluation

Trap	Correct answer
Ending the life cycle at the first successful call.	Release is followed by operation and by controlled change.
Choosing the model before the requirement is measurable.	Requirements come first. Task 2.1.
Calling an unpinned model upgrade a no-op.	Public notes treat it as a behavior change that needs evaluation.

The client stores history. Each Messages call resends it.
end_turn stops. tool_use means your code runs the tool and sends a user turn back. max_tokens is truncation.
Streaming lowers perceived latency, not token cost.
Vision and other media are content blocks on the message.
Batch when nobody is waiting and the item does not need a multi-turn tool loop.
Cache the stable prefix first. Variable content last.

If the question says...	The answer is likely...
"someone is waiting"	Messages API, stream if they watch tokens
"overnight and no tool follow-up"	Message Batches
"batch this tool loop"	Messages API. Batch does not continue across tool turns
"the cache never hits"	The variable text is in front of the stable prefix
"first block is text so we are done"	Branch on stop_reason
"the API remembers the chat"	It does not. Resend the messages

Trap	Correct answer
Choosing batch because it is cheaper while a user is watching.	Ask who is waiting first. Cost follows.
Expecting streaming to cut the bill.	It changes when tokens arrive.
Putting the user document before the cached policy.	The prefix must be stable.
Reading a prose sentence as the end of the turn.	stop_reason is the signal.

If the question says...	The answer is likely...
"400 on invalid JSON, retry"	Fix the body. Do not retry it
"429 or timeout"	Limited retry
"prompt edited in a dashboard"	Put it in version control
"one function does the call, the parse, and the write"	Split them
"run these documents strictly in series"	Only if each one needs the previous result

Trap	Correct answer
Catching every error and retrying.	A malformed request stays malformed.
Assuming the model text is already a parsed object.	Parse it, then check the shape.
Leaving the prompt out of the pull request.	Reviewers cannot see the behavior change.

Code, Desktop, claude.ai, and the API do not share instructions or tools automatically.
Untrusted text stays out of the system prompt.
A schema is the shape your code parses. Prose is not a schema.
Stale tool results stay in a resumed session. Start a new one with a summary.
A team plugin is a declared dependency. A personal plugin is not the design.
Owning the loop means the API or an SDK, and it means you store history.

If the question says...	The answer is likely...
"the email says to ignore the rules"	Keep it out of the instruction channel
"the next step needs a field"	A schema the client checks
"the file moved since the last tool result"	New session, plus a summary
"it works on my Claude Code install"	The plugin or the CLAUDE.md may be local
"port this chat prompt to the API"	Re-home instructions, tools, and history. It is not a copy

Trap	Correct answer
Putting a customer document in the system prompt so it is seen first.	That makes it an instruction. Pass it as user content.
Resuming after the files change and asking for a re-read.	The old tool result is still in the history.
Assuming a Code plugin exists on the API.	On the API the tool is code you ship.

Project CLAUDE.md is shared. User CLAUDE.md is not.
CLAUDE.md files are concatenated. They do not override each other.
settings.json has precedence. This repo's lesson order is managed, local, project, user.
A must-hold rule is settings or a hook. CLAUDE.md is guidance.
Pin the model id. Version the prompt in git.
A required plugin is a project dependency with a version.

If the question says...	The answer is likely...
"clone does not see the convention"	It is in user CLAUDE.md. Move it to the project
"the inner CLAUDE.md should replace the root"	They are concatenated
"the push must never happen"	settings.json or a hook, not only CLAUDE.md
"quality changed and git is clean"	The model alias or the prompt is unpinned
"works with the plugin on my laptop"	Declare the plugin for the team

Trap	Correct answer
More specific CLAUDE.md wins.	Files are combined. There is no single winner.
A clear sentence in CLAUDE.md blocks a tool.	Enforcement is settings or a hook.
Team rules in ~/.claude/CLAUDE.md.	A clone never receives that file.
A floating model alias in production.	Pin the id you evaluated.