Learning module 03 / 06
Turn scoping into an executable blueprint and deliver verifiable milestones through the six-step cycle.
A blueprint, an implementation milestone and acceptance evidence
Complete and self-check the connected workshop first, then attempt the extension with fictional or authorized material you select. Reading alone does not establish capability.
CONTEXT records facts, ARCHITECTURE constraints, AGENTS execution rules and CHANGELOG delivered changes. Break work into dependent engineering milestones; each instruction states the task, requirements, constraints and acceptance criteria.
Decompose, dispatch instructions, code, verify, decide the branch and update the blueprint. Skills divide capabilities rather than replacing these steps. Preserve work before comparing repair and rebuild costs; never lower gates to turn a failure into a pass.
Complete small task · free study
Fictional client Qinghe Equipment: operators submit fault titles; dispatchers classify and confirm assignments. Lin approves scope, Chen approves data access, and Zhou owns operations. The pilot suggests categories to dispatchers without automatic assignment. Use synthetic tickets, with no client systems or external models.
Four-part instruction: implement human review for unknown faults; unknown titles return review; no automatic assignment, network access or secret output; all five cases pass with unauthorized behavior reported separately. Blueprint facts: title input, category or rejected output; constraints: pure function and local synthetic data; M1 validation, M2 classification regression, M3 handover materials.
Independent task: perform both repairs, save 03-blueprint.md and actual terminal output. Document every six-step stage, the diff, PASS/NEEDS_FIX decision and unverified scope. If installation fails, record the error and continue role/scoping work; never claim a successful run.
After both repairs, all five cases should pass, SUMMARY failed=0 and exit code 0. Repairing only the unknown fallback leaves the secret case failing, so release remains blocked. Software checks do not establish model reliability, client-data approval or production handover.
Teaching exercise: write requirements, facts and constraints for a fictional ticket classifier. Choose one independently verifiable milestone and issue a four-part instruction. Implement it, record functional, code, architecture and security checks, and explain a PASS or NEEDS_FIX decision and next action.
Use fictional or authorized deidentified material. Keep reports, implementation and checks in your own project; this site accepts no exercise uploads and performs no online grading.
If criteria are unmet, record gaps and a correction plan, then review again with evidence. Confirm sharing permissions before instructor or peer review.
Study the full explanations, examples and exercises in these lessons, then integrate the artifacts using the connected workshop above.