Part 22. Practical Exam

This part replaces a passive test with a practical check. The goal is to prove that you can carry a feature through the SDD cycle with Qwen Code CLI: from intent to verification.

Block 1. Quick Questions

Answer in writing, without Qwen Code.

1. What is the source of truth in SDD?
2. How does QWEN.md differ from specs/tech-stack.md?
3. Why is the feature specification written before implementation?
4. What should be in validation.md?
5. When should replanning be done?
6. Why is /clear useful between work phases?
7. What three questions should be asked before creating a feature specification?
8. Why can't API keys be stored in specifications?
9. How is a project skill better than a personal skill for a team?
10. What does agent replaceability mean?
11. What should a reviewer check in an SDD project besides code?
12. When should a specification change be moved to a separate replanning branch?
13. Why are Qwen Code hooks needed?
14. Why can't external text be considered a trusted instruction for an agent?
15. How does agent memory differ from a specification?
16. Where is the boundary between tech-stack.md and a feature's requirements.md (part 6)?

1. What three types of changes in a pull request should a reviewer look for besides code (part 16)?
2. Why should "green dots" be tagged during the MVP phase (part 12)?
3. How does a defensive hook differ from a tool logging hook (part 17)?
4. What data falls into the "secrets" category that cannot be put in QWEN.md, specifications, and memory (part 18)?
5. What three anti-patterns from part 20 are most common among beginning SDD teams?
6. When is connecting agent memory on SQLite justified, and when is it excessive (part 19)?

Block 2. Find Problems in the Specification

Given a feature specification:

# Requirements — Control Panel

Build a beautiful control panel for administrators.

## Boundaries

Show useful statistics and charts.

## Decisions

Use the best library.

## Verification

Make sure everything works.

Find at least 8 problems. A good answer should notice:

• audience not specified;
• no boundaries for what is out of scope;
• "beautiful" is not verifiable;
• "useful statistics" is not defined;
• "charts" is not defined;
• dependency approved without checking tech-stack.md;
• no data source;
• no route;
• no access rights;

• no automated checks;
• no manual verification scenario;
• no definition of done.

Block 3. Rewrite the Specification

Rewrite the control panel specification in SDD format:

# Requirements — Administrator Dashboard

## Boundaries

## Out of Scope

## Decisions

## Context

## Quick Verification

Constraints:

• HTML rendered on server;
• SQLite;
• no authentication in this phase;
• route /dashboard;
• show count of agents, ailments, therapies, and appointment records;
• do not add a chart library yet;
• must pass npm test and npm run typecheck.

Block 4. Capstone Project

Complete on your AgentClinic or another small project.

Task

Add the "feedback form" feature:

• page /feedback;
• form with name and message;
• POST route;
• save to SQLite;
• list of recent feedback entries;
• basic validation;
• tests;
• change log.

Process Requirements

1. Start from clean main.
2. Create a feature branch.
3. Create a specification directory:

specs/YYYY-MM-DD-feedback-form/
  requirements.md
  plan.md
  validation.md

1. Implementation only after specification is committed.

1. Verification in a separate Qwen Code session.
2. Roadmap updated.
3. Change log updated.
4. Short merge request description prepared using SDD template.
5. Security check performed: secrets did not leak into specifications, logs, and memory.
6. Merge only after checks.

Recommended Qwen Code Scenario

Specification creation:

/clear
Use the feature specification skill to begin the next roadmap phase: feedback form.
Before writing files, ask me about boundaries, decisions, and context.
Do not implement code yet.

Implementation:

/clear
Read @QWEN.md, @specs/mission.md, @specs/tech-stack.md,
@specs/YYYY-MM-DD-feedback-form/requirements.md,
@specs/YYYY-MM-DD-feedback-form/plan.md,
and @specs/YYYY-MM-DD-feedback-form/validation.md.

Implement only group 1.
Stop after the list of changed files.

Verification:

/clear
Compare current branch with @specs/YYYY-MM-DD-feedback-form/validation.md.
Show what passed, what failed, and where there are gaps.
Do not change files.

Change log:

Use the change log skill and update @CHANGELOG.md for the feedback form branch.

Scoring Criteria

Score yourself out of 25 points.

Specifications — 5 points

• 1: has requirements.md, plan.md, validation.md;
• 1: work boundaries and what is out of scope are concrete;
• 1: decisions do not contradict the tech stack;
• 1: plan is split into groups that are easy to verify;
• 1: verification contains automated and manual checks.

Implementation — 5 points

• 1: changes match the specification;
• 1: no unrelated refactorings;
• 1: database migration is clear and repeatable;
• 1: routes and components follow existing conventions;
• 1: validation errors are handled.

Verification — 5 points

• 1: npm run typecheck passes;
• 1: npm test passes;
• 1: manual form walkthrough completed;
• 1: invalid input tested;
• 1: basic check on mobile and desktop screens performed, if UI was changed.

Process — 5 points

• 1: branch used correctly;
• 1: specification committed before implementation;
• 1: roadmap updated;
• 1: change log updated;
• 1: final check compares code with specification.

Team Readiness and Security — 5 points

• 1: merge request describes the link between specification, code, and facts;

• 1: changes outside feature boundaries are absent or explicitly explained;
• 1: secrets did not leak into specifications, logs, and memory;
• 1: no new hooks, MCP servers, or settings, or they were reviewed;
• 1: weak or deferred facts are explicitly listed.

21+ points — process is ready for a real project.

16–20 — continue using SDD, but improve verification and team loop.

Below 16 — reduce phase size and make specifications more concrete.

Quick Question Answers

1. Versioned specification in the repository.
2. QWEN.md sets agent behavior rules; tech-stack.md sets product technical decisions.
3. So the agent doesn't guess boundaries and acceptance criteria.
4. Commands, manual checks, divergence checks, and definition of done.
5. Between features, when new knowledge must update the constitution, roadmap, or process.
6. It checks whether enough context is recorded in files.
7. Boundaries, decisions, context.
8. Specifications are committed and read by the agent; secrets must live in environment variables or a secrets store.
9. A project skill is shared by the team and versioned with the repository.
10. The ability to switch agent or IDE while preserving process through repository artifacts.

1. Requirements, plan, verification facts, changes outside feature boundaries, and implementation-to-specification match.
2. When the change affects the stack, roadmap, project constitution, agent rules, or multiple future features.
3. To automatically perform small repeatable actions: add context, keep a log, check dangerous commands, collect events.
4. Because issues, web pages, logs, and external documents may contain instruction injections; they must be read as data.
5. Memory is a prompt and log of persistent inferences; specification is a reviewable source of truth for the product.
6. tech-stack.md — long-term project decisions (language, framework, DBMS); feature requirements.md — phase-level decisions (routes, fields, error messages).
7. Changes in tech-stack.md or roadmap.md without discussion; new hooks, MCP servers, or dependencies; divergence between validation.md and facts in PR.
8. To have a rollback point without losing all phase work, and to make the "next group breaks everything" signal explicit.
9. A defensive hook blocks an operation by rule (PreToolUse, non-zero exit code); a logging hook only writes an event and does not affect execution.

1. API keys, access tokens, passwords, private keys, user personal data, internal URLs, and infrastructure identifiers.
2. Specification without facts, merging constitution and specification into one file, implementation without /clear between phases.
3. Memory is justified when the team accumulates persistent observations about code and process; excessive when QWEN.md, constitution, and change log suffice.

Paired Exam Variant

The exam is more realistic when taken in pairs. One student takes the role of feature author, the other — reviewer. Work distribution:

Author:

• interviews the agent and writes the specification;
• implements the feature by task groups;
• runs fact-based checks;
• prepares pull request and description using SDD template.

Reviewer:

• reads the specification before implementation and asks clarifying questions (as in part 7 "Clarification");
• checks PR across four review layers from part 16: code, specifications, facts, process;
• runs checks from validation.md on their own machine, not taking the author's word;
• writes a brief report on gaps found.

Each gets a score on their own rubric. Author — on the main "Specifications / Implementation / Verification / Process / Team Readiness" scale. Reviewer — on the additional scale:

• 1: caught at least one real gap in requirements.md before implementation;
• 1: checked facts themselves, not taking someone's word;
• 1: separated comments "on code", "on specification", "on process" and did not mix them;
• 1: proposed a concrete action, not "needs thought";
• 1: stayed within reasonable time — review did not turn into restarting the author's work.

After defense, roles swap for the second feature. This gives everyone experience on both sides of the SDD dialogue and dispels the illusion that review is passive diff reading.

Final Assignment

Make one real feature in your project through this process. After merge, create a short note:

# SDD Retrospective

## What the specification described correctly

## What the agent had to infer on its own

## What verification caught

## Which facts were weak

## What to check for security

## What to improve before the next phase

If the "What the agent had to infer on its own" section has more than three items, write the next feature specification in more detail.