Chapter 38 — Capstone implementation
Lesson map
Lesson 38 published. Map, example, EX112.
flowchart TD
N0["Learning outcomes"]
N1["38.1 Building"]
N2["38.2 Self-application"]
N3["38.3 Pilot"]
N4["38.4 Problems found"]
N5["38.5 Fixes"]
N6["38.6 After fixes"]
N7["Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX112"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["38.1 Building"]
N2["38.2 Self-application"]
N3["38.3 Pilot"]
N4["38.4 Problems found"]
N5["38.5 Fixes"]
N6["38.6 After fixes"]
N7["Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]
[Learning outcomes]
|
v
[38.1 Building]
|
v
[38.2 Self-application]
|
v
[38.3 Pilot]
|
v
[38.4 Problems found]
|
v
[38.5 Fixes]
|
v
[38.6 After fixes]
|
v
[Documentation]
|
v
[Worked example] --> [Exercise EX112]
Learning outcomes
You will (1) build the secure project starter template; (2) integrate checks into CI; (3) pilot with real projects; (4) fix problems found in the pilot.
38.1 Building
Lena builds the template: CI configuration with tests, secret scanning, lockfile checks, SBOM generation, signing and provenance; an update bot configuration; a set of ASVS-based tests for sessions, headers and authorisation; and a README with setup steps.
Each part comes from practice tested at CampusEats, adjusted to work for a new project with no history. The README explains what each check does and why, using short examples, since a check that members do not understand is likely to be disabled at the first false alarm.
38.2 Self-application
The template itself follows its own rules: its dependencies are minimal and updated by the bot, and its releases are signed.
Lena reasons that a template asking projects to follow rules it breaks itself would not be trusted. Its own release verification report is published with each version, using the same format as CampusEats. When the template's scanner flagged its own documentation during the pilot, that showed the rules were genuinely applied, and the fix made the template better for everyone.
38.3 Pilot
Two student projects, a society events app and a study-room booking tool, adopt it.
The two projects differ in size and type, which tests whether the template is general enough. Lena meets each team before setup to explain the pilot and agree what will be measured, and she watches the first setup without helping unless asked, so the timing reflects what a new team would experience. Each team has a named contact for questions. Both teams agreed to share their setup times and problems.
38.4 Problems found
Setup took 2.5 hours, not under one, mainly because of signing configuration. The secret scanner flagged sample keys in the template's own documentation.
Lena records each problem with the time it cost and how the team worked around it. The signing configuration needed several manual steps that were easy to get wrong, and the flagged sample keys confused one team, who thought the template contained real secrets. Both problems would discourage adoption, so they are fixed before the template is offered more widely.
38.5 Fixes
A setup script automates signing configuration; documentation sample keys are marked and allowlisted.
The setup script asks for two values and configures the rest, and it checks the result by producing a signed test release. Sample keys are now clearly fake and listed in the scanner's allow list with a comment explaining why. Lena tests both fixes with a member who has never used the template, since she can no longer judge setup difficulty herself. The fixes are recorded in the template's change log.
38.6 After fixes
Setup time falls to 40 minutes in a third trial.
The third trial uses a new team and the updated README, timed the same way as the first two. Forty minutes is within the one-hour criterion in the proposal, and most of the remaining time is spent reading the README, which Lena considers time well spent. She records the three setup times in the evaluation and notes that one trial after fixes is a small sample. Further trials happen during the evaluation.
Documentation
The README explains each check in plain words: what it protects against, what a failure means and how to fix it. Lena tests the README by asking a first-year student to set up a project using only the document; every question the student asks becomes a new line in the README. Short, tested documentation proved as important as the checks themselves.
Code review of the template
Grace and two experienced society members review the template's CI configuration line by line, since a mistake there would spread to every project using it. They find one check that ran only on the main branch and not on pull requests; it is fixed so problems are caught before merging.
Worked example
The booking tool's team finds that the template's authorisation tests reveal that any logged-in student could cancel another student's booking. They fix it before launch, the first real flaw caught by the template.
Synthetic case. Projects and results are synthetic.
Errors and limits
Templates cannot anticipate every project's needs; leave room for customisation.
Exercises
- EX112 — Template parts. List four parts of the template. Rubric: 3 = CI checks, update bot, ASVS tests, README (four); 2 = two; 1 = one; 0 = none.
- EX113 — Pilot problems. What two problems did the pilot reveal? Rubric: 3 = setup 2.5 h due to signing; scanner flagged doc sample keys; 2 = one; 1 = vague; 0 = none.
- EX114 — First flaw. What flaw did the template catch? Rubric: 3 = any student could cancel others' bookings; 2 = partial; 1 = vague; 0 = none.
Synthesis
Build, pilot, fix and let the template prove itself on real projects.
Continue studying — chapter 38 of 40
← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →