# Chapter 40: Final Comprehensive Exercise

## Lesson objectives

- **O1** Can define the condition for moving from five-stage score into five required gates (artifact: capstone decision sheet)
  - Evidence: The capstone decision sheet states the entry condition from five-stage score to five required gates
- **O2** Can construct a capstone decision sheet with branches, vetoes and accountable owners (artifact: capstone decision sheet)
  - Evidence: The capstone decision sheet contains at least one proceed branch, one stop branch and their owners
- **O3** Can determine capstone status from five stage scores and five non-compensatory gates (artifact: capstone decision sheet)
  - Evidence: The artifact contains stage scores, all five gates, red-line results and final-status rationale

## Learning paths

- **Novice**: Chapter transfer task: Can determine capstone status from five stage scores and five non-compensatory gates. Use the diagram's decision relationship to complete the first evidence item in the capstone decision sheet, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can determine capstone status from five stage scores and five non-compensatory gates. Submit the capstone decision sheet, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: capstone decision sheet
- **Diagram kind**: capstone-gates
- **Relationship semantics**: Inputs follow conditional branches into an explicit gate; stop and proceed are exclusive, and red-line failures cannot be offset by other scores.
- **Core concepts**: five-stage score · five required gates · final status

![Chapter 40 teaching diagram for the capstone decision sheet](/learning/diagrams/en/chapter-40.svg)

Follow the conditions in the capstone decision sheet and make a traceable stop-or-proceed decision at the gate.

The diagram starts with five-stage score, branches through the conditions in five required gates, and reaches a gate controlled by final status. Every case must end at stop or proceed; missing evidence and red-line failures cannot be offset by other strengths.

> **Adapted public course.** Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

## Lesson explanation

### Exercise Overview

Purpose: Verify whether the trainee can independently complete the full "AI-assisted delivery" workflow -- from requirements analysis to blueprint design, from milestone breakdown to AI-assisted implementation, and from acceptance gating to retrospective summary.

Exercise format: Given a scenario modeled on realistic business conditions, the trainee independently completes every stage. AI coding tools are used throughout, but all decisions are made by the trainee. The learner records the trainee's decision process and rationale.

Assessment dimensions: Score the five stages: requirements analysis, 20 points; blueprint design, 20; milestone breakdown and AI-assisted implementation, 30; acceptance and quality gating, 20; retrospective summary, 10. The total is 100 points. Comment on process completeness and decision soundness using evidence within the relevant stage; do not score them again separately.

### Exercise Topics (Choose One of Four)

Topic A: Enterprise internal training system. Requirements: employees can publish courses and enroll in courses; instructors can view enrollment counts; administrators can manage users and course categories. Focus areas: role permissions, enrollment state machine, simple statistical reports.

Topic B: Pet boarding appointment platform. Requirements: users can select boarding services, view available time slots, pay a deposit online, and merchants confirm orders. Focus areas: appointment conflict detection, payment state machine, asynchronous communication between merchants and users.

Topic C: Factory equipment repair reporting system. Requirements: workers can submit equipment fault work orders; repair technicians can accept orders and fill in repair records; managers can view work order statistics. Focus areas: work order state machine, repair labor-hour statistics, role division.

Topic D: Community group-buying mini program. Requirements: group leaders can initiate group buys; residents can place orders to join groups; the platform can manage products and settlement. Focus areas: group-buy state transitions, inventory deduction, group leader reconciliation.

### Completion Criteria (Grading Checklist)

The trainee must completely produce the following deliverables; a learner or independently arranged peer reviews each item against the checklist:

Stage 1: Requirements Analysis (20 points)

- □ List the core business event flow using Event Storming (in past tense);
- □ Derive commands, aggregates, and bounded contexts;
- □ Produce REQUIREMENTS.md (project overview, user roles, feature list, data entities, constraints);
- □ Record at least one "divergence record" (divergence, decision, reason, scope of impact, date).

Stage 2: Blueprint Design (20 points)

- □ Produce CONTEXT.md, fully containing seven parts: project overview, core glossary, tech stack, data model, API contracts, directory structure, milestone dependency tree;
- □ The glossary comes first and is precisely defined;
- □ The tech stack has clear recommendations + rationale + alternatives (proposing rather than asking);
- □ Milestones are "independently verifiable engineering nodes" (not vague feature points from a requirements perspective).

Stage 3: Milestone Breakdown and AI-Assisted Implementation (30 points)

- □ Each milestone is issued with an instruction containing the "four elements" (what to do / requirement details / technical constraints / acceptance criteria);
- □ Strict execution: proceed to the next milestone only after the current one is complete;
- □ During the coding phase, maintain "observation" rather than "micromanagement";
- □ Each milestone acceptance uses a structured acceptance report (functionality / code / architecture / security);
- □ Branch decisions are decisive: PASS commits, NEEDS_FIX fixes (at most twice), REBUILD rolls back and rebuilds;
- □ Analyze a supplied drift example and plan handling; record no actual incident when none occurred. Do not manufacture failures.

Stage 4: Acceptance and Quality Gating (20 points)

- □ Each milestone has an acceptance record;
- □ Preserve at least one traceable version point per milestone; commit frequency is not scored;
- □ List critical behaviors, red lines and failure branches and pass all of them; if declaring a coverage target, record the tool, scope and measured result;
- □ Upon completion, CHANGELOG.md and CONTEXT.md are updated (documentation and code mirror each other).

Stage 5: Retrospective Summary (10 points)

- □ The retrospective report answers three questions: which decisions were done well / which decisions could be better / what would be done differently if redone once;
- □ Summarize one's 3 most frequently used skills and 1 skill most desired for improvement.

### Exercise Report Template

<!-- code-example:chapter-40-E1 mode:reference -->
> **Example type: reference.** Reference fragment; it is not guaranteed to run alone. Adapt it to the lesson context, project versions and real interfaces, then validate with observed output.
```markdown
## Final Comprehensive Exercise Report

## Project Name: ______

## I. Requirements Analysis
(Attach the Event Storming event flow, REQUIREMENTS.md, and divergence records.)

## II. Blueprint Design
(Attach the full CONTEXT.md.)

## III. Milestone Execution Records
| Milestone | Instruction highlights | Acceptance result | Commit |
|--------|---------|---------|------------|
| M1 | ...... | PASS | hash1 |
| M2 | ...... | NEEDS_FIX → PASS | hash2 |
| ...... | ...... | ...... | ...... |

## IV. Architecture Drift Handling Records (If Any)
- Drift signal: ______
- Higher-level instruction: ______
- Rebuild action: ______

## V. Retrospective Summary
1. Decisions made well: ______
2. Decisions that could be better: ______
3. What I would do differently: ______
4. My 3 most frequently used skills: ______
5. The 1 skill I most want to improve: ______

## VI. Self-review or peer comments by stage
- Stage 1 · Requirements analysis: ___ / 20; evidence and comments: ______
- Stage 2 · Blueprint design: ___ / 20; evidence and comments: ______
- Stage 3 · Milestone breakdown and AI-assisted implementation: ___ / 30; evidence and comments: ______
- Stage 4 · Acceptance and quality gating: ___ / 20; evidence and comments: ______
- Stage 5 · Retrospective summary: ___ / 10; evidence and comments: ______
- Total: ___ / 100
```

### Analytic scoring anchors

This rubric supports self-study evaluation only. The site issues no completion certificate or industry qualification.

Use 18–20 / 14–17 / 10–13 / 0–9 for each 20-point stage; 27–30 / 21–26 / 15–20 / 0–14 for the 30-point stage; and 9–10 / 7–8 / 5–6 / 0–4 for the 10-point stage. The four levels are Strong, Proficient, Developing and Insufficient evidence. Score the stated artifacts rather than prose polish, template similarity or commit frequency.

A score of 60 means PASS only when all required evidence gates are present. A missing gate makes the overall state `INCOMPLETE`; any red-line failure makes it `NEEDS_FIX`, regardless of total score.

---

### Required FDE evidence: scores cannot compensate for gaps

Separately verify customer scope and data authorization, traceable real model evaluation and red lines, independent review, executable handover and recovery, and actual adoption observation. Mark every missing item unfinished. Synthetic records and self-rehearsal support foundation practice but do not establish model delivery or independent handover. Simulate payment states without collecting real payments.


## Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save `chapter-40.md` with versions, decisions, evidence and gaps.

Choose one of four capstones and submit scope, blueprint, implementation, evaluation, handover and adoption evidence. Apply 20/20/30/20/10 scoring and separate required FDE gates.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: capstone decision sheet

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

- O1: The capstone decision sheet states the entry condition from five-stage score to five required gates
- O2: The capstone decision sheet contains at least one proceed branch, one stop branch and their owners
- O3: The artifact contains stage scores, all five gates, red-line results and final-status rationale

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

Scores cannot compensate for missing scope/authorization, traceable real model evaluation and red lines, independent review, executable handover/recovery, or actual adoption or an explicitly unfinished observation. Label rule tests and self-rehearsals as basic practice. Do not require payments or manufactured architecture incidents.

### Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The capstone decision sheet, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [Forward Deployed Engineer role — San Francisco](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. This OpenAI role covers discovery, scoping, design, build, rollout, adoption and field feedback; it is not an industry-wide standard.
- [Define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) — Anthropic, 2026-09-17. Evaluation starts from observable success criteria, test cases and versioned evidence.
- [Git reference](https://git-scm.com/docs) — Git project, 2026-09-17. Versions, branches, commits and recovery operations must be verified against repository state.
- [OWASP risks for LLM applications](https://genai.owasp.org/llm-top-10/) — OWASP Foundation, 2026-09-17. Model output, sensitive information, tool permissions and human control require explicit risk boundaries.