Chapter 1 — Reps

These reps are not warm-ups next to the milestone. They are the milestone, built piece by piece. When you finish the last one, your engineering system is standing and Milestone 1 is mostly written.

Ground rules

• Everything lands in the repository. If a rep produces an artifact and the artifact is not committed, the rep is not done. Your grader reads Git, not your intentions.
• Log every session as you go. Each rep below is at least one row in docs/hours-log.csv, written before you close the laptop. Estimate first, then work, then record the actual.
• You do not have an idea yet, and that is fine. Nothing this week requires one. If a rep tempts you to start choosing a project, write the temptation in your notes and move on — that is Week 2.
• Write the reflections in prose. A rep is not finished until you have written the two to four sentences it asks for. Keep them in a scratch file; the milestone will ask you to pull from them.
• Amber-zone AI use gets logged the day it happens. Rep 9 sets your policy; from that moment it applies to everything, including these reps.

Standing up the shop

Rep 1 — Create the repository and scaffold it in one commit

Create the repository (private is fine; you will open it or share it at the end) and build the canonical tree from §1.5 in a single initial commit. Use placeholder files with one line of content each — <!-- Week 6 --> is enough — so Git will actually track the paths.

git init capstone && cd capstone
mkdir -p docs/adr src tests .github/workflows
for f in charter ai-usage scoping-decision requirements definition-of-done \
         architecture plan risk-register test-plan defect-log runbook handoff; do
  printf '# %s\n\nPlaceholder. See the course schedule for the week this is written.\n' "$f" > "docs/$f.md"
done
printf 'date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes\n' > docs/hours-log.csv
touch docs/adr/.gitkeep src/.gitkeep tests/.gitkeep
git add -A && git commit -m "chore: scaffold capstone repository structure"

Produce: the commit, and the output of git log --stat -1.

Reflect: Twelve of those files will not be written for months. Why is it better to create the empty slot now than to create the file in the week you need it? Answer in two sentences, in terms of what a reader of your repository sees.

Rep 2 — Write a README.md a stranger can use on day one

Your Week-1 README does five things and nothing else: says what this repository is, who owns it, what state it is in right now, how to navigate docs/, and where the hours log lives. It will be rewritten in Week 13. It must be honest today.

Here is the bad version and the good version. Write the good one.

Bad

# Capstone Project
My senior capstone project. Coming soon!

Good

# Capstone — <working title>

Senior capstone by <name>, <term>. **Status: Week 1 — engineering system only.
No application code yet.** The project idea is chosen in Week 2.

## What is here
- `docs/charter.md` — scope, constraints, non-goals, risks, working agreement
- `docs/hours-log.csv` — every work session, logged the day it happens
- `docs/ai-usage.md` — which AI tools are used on this project, and how
- `docs/` — one document per life-cycle phase; each header says the week it is written
- `src/`, `tests/` — empty until Week 9

## How to run it
Nothing to run yet. From Week 9 this section is the clean-machine setup path.

Produce: README.md, committed.

Reflect: The bad README is not shorter than the good one by much. What exactly does the good one give a reader that the bad one withholds? Name the specific question each of the good README’s five parts answers.

Rep 3 — Build the board, with a limit on it

Create the project board (GitHub Projects, or the tool you have actually committed to). Five columns: Backlog · This Week · In Progress · Blocked · Done. Set a work-in-progress limit of two on In Progress — if your tool cannot enforce it, write it in the column description and enforce it yourself.

Then create six cards for this week’s work. Each card gets an estimate, a hat, and a stopping condition. Rewrite these three bad ones before you add your own:

Produce: a screenshot or export of the board with six well-formed cards.

Reflect: Which of your six cards was hardest to give a stopping condition to? That difficulty is information — what is actually unclear about that piece of work?

The log

Rep 4 — Wire the hours log and run the report

Copy code/hours-log.csv into your repository as docs/hours-log.csv, delete the sample rows, and start logging your own. Copy code/hours_report.py into tools/ and run it:

python3 tools/hours_report.py docs/hours-log.csv

By the end of this week the log needs at least five real session rows, each with an estimate_hours value written before the session started.

Produce: the committed log, and the report output pasted into your notes.

Reflect: Look at your estimate-to-actual ratio. Is it above or below 1.0, and by how much? You have one week of data, so the number is noise — but write down what you expect it to be by Week 8, and check yourself then.

Rep 5 — Repair four garbage log rows

Below are four real-shaped bad rows. Rewrite each one so it could answer a question in Week 12. You do not need to invent the truth — invent a plausible session and log it well.

2026-09-14,,,8,,,worked on capstone,,,
2026-09-15,,,2,,,fixed stuff,,,
2026-09-16,,,3,,,research,,,
2026-09-17,,,5,,,setup,,,

For each rewrite, fill in start and end, a real hours value to the quarter hour, phase, hat, a task specific enough to search for, an estimate_hours, blocked_hours if any, and a note that would mean something to you in three months.

Produce: the four rewritten rows in your notes (not in your real log — do not pollute your real data with exercises).

Reflect: The row 2026-09-14,,,8,,,worked on capstone claims eight hours. What are three different weeks of work that row could be hiding — one good, one wasteful, one alarming? That ambiguity is why the column exists.

Rep 6 — Estimate before you work, three times

Pick three separate sessions this week. Before each one, write a single number: how many hours you think it will take. Work. Record the actual. Do not adjust the estimate afterward — the value of this rep is entirely in the discomfort.

Session          Estimate   Actual   Ratio
1 ____________   ______     ______   ______
2 ____________   ______     ______   ______
3 ____________   ______     ______   ______

Reflect: Were you wrong in a consistent direction? Almost everyone is. Write one sentence naming what kind of work you underestimate — setup, reading, writing, debugging, or waiting on someone else.

Counting the cost

Rep 7 — Five non-goals, before you have a goal

Write five things you will not do in this capstone. You have no project yet, so write them about yourself and the course: technologies you will not learn, platforms you will not target, categories of feature you will not build, quality bars you will not chase, commitments you will not add.

Rewrite these bad non-goals into good ones:

Produce: five non-goals in docs/charter.md, each specific enough that in Week 10 you could point at one and say “no.”

Reflect: Which non-goal did you hesitate to write down? Hesitation means you are still secretly planning to do it. Say why you hesitated.

Rep 8 — Map the sixteen weeks with the Hat Map

Open the SDLC Hat Map widget on the chapter page and fill this table from it, in your own words. Then answer the two questions under it.

Wk  Phase          Hat                Artifact                     Consumes from week(s)
1   ____________   ______________     __________________________   _____
...
16  ____________   ______________     __________________________   _____

1. Which two weeks would you have skipped if nobody made you do them? Read the failure text for both, out loud.
2. Which week has the most inputs? Trace its chain backward to Week 1.

Reflect: Pick the earlier of your two skip-candidates. Write three sentences describing, concretely, what your Week 14 looks like if you skip it. Be specific — name the document you would not be able to write.

The tool and the line

Rep 9 — Set your AI policy, then use it once, properly

Copy code/ai-usage-template.md into your repository as docs/ai-usage.md. Fill the policy header completely: which tools, which model versions as best you can name them, what each is for, and what it is never for.

Then do one deliberate Amber-zone use — ask an assistant to draft something you will keep, such as your .gitignore for a stack you are considering, or a first pass at your charter’s risk table. Keep some of it. Change some of it. Then write the log entry with all six columns filled.

Produce: docs/ai-usage.md with a complete policy header and at least two entries.

Reflect: In your log entry, the “What I changed” column is the one that carries the grade. Read yours. If it says “nothing,” you did not verify — go back and find the thing that is wrong, because there is always something.

Rep 10 — Make an assistant build your calendar, then find its three errors

Paste the sixteen-week table from §1.2 into an assistant and ask it to turn the course into a personal weekly calendar: fifteen hours a week, blocked into sessions, with the milestone due dates marked.

It will produce something clean and plausible in about a minute. Now find three things it got wrong. It has never met you. Candidates: it does not know your other courses’ deadlines, it does not know your job shifts, it assumes evenly distributed weeks, it does not know your institution’s break schedule, it assumes you work well in one-hour blocks, it puts construction where the syllabus does not.

Produce: the generated calendar, your corrected version, and the three errors named explicitly. Log the use in docs/ai-usage.md.

Reflect: The generated calendar was faster and better-formatted than what you would have made from scratch. It was also wrong in ways only you could see. Write two sentences on what that says about where the human belongs in this loop — and put those two sentences somewhere you will reread in Week 12.

Rep 11 — Block 240 hours on a real calendar

Open the calendar you actually use. Block your working sessions for fifteen weeks, not one. Blocks of two to three hours, not scattered singles.

Then find the two weeks that are already broken — another course’s exam, a holiday, a family obligation, a work trip — and move those hours forward into an earlier week. Not backward. Backward is how the late start happens.

Produce: a screenshot of the calendar and a line in docs/charter.md naming the two broken weeks and where their hours went.

Reflect: How many hours did you actually manage to place? If it is fewer than 225, you have just discovered the most important fact about your semester, and you found it in Week 1 instead of Week 11. What has to change?

Rep 12 — Rewrite a bad purpose statement

Here is a real-shaped bad charter purpose. Rewrite it so that a stranger could tell, at the end of the semester, whether it happened.

Bad

The purpose of this project is to create an innovative, user-friendly application that leverages modern technologies to solve real-world problems and demonstrate my skills as a software engineer.

Every clause in that sentence is unfalsifiable. Tag the defects first — unverifiable, unmeasurable, solution-biased, no user named, no stopping condition — then write yours. Aim for two or three sentences that name a user, a state of the world at the end, and a test somebody else could run.

Produce: the tagged defects and your rewritten §1 in docs/charter.md.

Reflect: Which defect was hardest to remove without shrinking the ambition? That tension — precision versus ambition — is the whole job of the business-analyst hat, and you meet it properly in Week 3.

Done? One Last Thing.

The clean-clone smoke test. Everything above is worthless if it only exists on your laptop. Prove it does not.

1. Push everything to GitHub.
2. Clone the repository fresh into a directory you have never worked in — or, better, into a cloud development environment (see Appendix A):

   git clone <your-repo-url> /tmp/capstone-check && cd /tmp/capstone-check

3. Read your own README.md as if you had never seen the project. Can you tell what this is, who owns it, what state it is in, and where to look next? If not, fix the README, not your memory.
4. Confirm the canonical tree is all there: ls -R docs.
5. Run the report from the clone:

   python3 tools/hours_report.py docs/hours-log.csv

   The total must match what you believe you worked this week. If it does not, the log is wrong — fix the log, not the belief.
6. Delete /tmp/capstone-check. It served its purpose.
7. Commit anything you fixed with the message M1: engineering system stood up.

If that loop runs clean, your engineering system exists in the only place that counts: somewhere other than your machine. That is the same test Week 13 applies to your documentation and Week 14 applies to your release, and this is the cheapest version of it you will ever run.

Up next: Milestone 1