Milestone 9 — Walking Skeleton & Continuous Integration

“According to the grace of God given to me, like a skilled master builder I laid a foundation, and someone else is building upon it. Let each one take care how he builds upon it.” — 1 Corinthians 3:10 (ESV)

Chapter: Chapter 9 — The Walking Skeleton Week: 9 of 16 · Construction begins · you wear the developer and release engineer hats Due: End of Week 9. Late work is not penalized separately — it is deferred, into a week that has no room for it. Submit: A link to your repository at the commit tagged v0.1.0-skeleton, plus the URLs of one green CI run and one red one, in the Canvas dropbox. Where it lands in the final package: this milestone is the spine of your repository — .github/workflows/ci.yml, script/, the ## Run it section of README.md, .env.example, docs/skeleton-trace.md, and the first real commits in src/. It feeds the Week-16 rubric lines for working software, reproducibility and the clean-machine test, and engineering discipline (see Appendix C). AI policy: Open. Use an assistant to scaffold, to draft the workflow, to explain a build error. Every generated line that reaches a commit is yours — your bug, your leaked key, your answer in the Week-16 defense. Log substantive use in docs/ai-usage.md: what you asked for, what you kept, what you rejected and why.

The Setup

Eight weeks of documents are behind you, and one of them is a lie until this week.

Your technical specification says the system has a client, a route layer, a service layer, a data store, and one integration. That is a drawing. Nobody has ever seen a request go through it. In Week 6 you believed the architecture worked; you have never once observed it working. Between belief and observation there is a gap, and the gap is where capstone projects die — quietly, at the end of Week 12, when the pieces are assembled for the first time and do not fit.

So this week you close it with the thinnest possible thing. One real request, entering where a real user enters, travelling through every component you named, touching a real data store, and coming back as something a human can see. It will render one row of text. It will not impress anybody.

Then you hand it to a robot. On every push for the rest of the term, a clean machine that has never met your laptop will clone your repository, follow your setup instructions, install from your lock file, lint, test, build, and run one real request through your system. That machine is your grader, rehearsing, several hundred times, before the day it counts.

The skeleton is the foundation. Nobody praises a foundation. Everybody who skipped one paid.

Learning Targets

You will demonstrate that you can:

• Build a vertical slice that exercises every architectural component in your specification, end to end, with no mocked hops in the path.
• Structure a repository a stranger can navigate without being told anything.
• Make an environment reproducible on a machine you do not own: pinned runtime, committed lock file, externalized configuration, one-command bootstrap.
• Operate continuous integration as a working instrument — triggered automatically, capable of failing, and observed failing.
• Trace work to requirements, so that every issue answers to an identifier you baselined in Week 8.
• Handle credentials like a professional, including the recovery procedure for the mistake you hope not to make.
• Use an assistant to accelerate scaffolding while remaining accountable for every committed line.

The weekly status block — paste this into your submission comment

Every milestone submission carries these five lines. It takes two minutes, it is the same five lines every week, and it is the difference between an instructor who can help you in Week 6 and one who finds out in Week 14. Copy it into the Canvas submission comment when you submit — not into a document.

Shipped:     what actually works this week, in one line
Cut:         what I dropped or deferred, and where it went (backlog / change request / gone)
Hours:       planned N / actual N        (from docs/hours-log.csv)
Blocked on:  the one thing in my way, or "nothing"
Ship confidence: green | amber | red — if amber or red, the one thing that would move it

Say red when it is red. A red in Week 6 is a conversation and a scope cut. A red discovered in Week 15 is a grade. Nobody has ever been penalised in this course for an honest amber; the only expensive answer is the green that was not true.

Normal Tier

The bar. This is what “on pace in Week 9” means.

Required deliverables

1. A restructured repository. Documents in docs/, source folders named after the components in your technical specification, script/ (or equivalent) holding one-command verbs, no committed dependencies, no committed binary databases, no dead _backup files.
2. A walking skeleton that walks. One real request through every hop. Real data store, real table, at least one seeded row, real response, real rendered result. Any hop that is stubbed is labeled as stubbed.
3. A reproducible bootstrap. Runtime version pinned in a file, lock file committed, install performed from the lock file, configuration read from the environment, and README.md with a ## Run it section that names the prerequisite, gives the exact commands, and states what success looks like.
4. Continuous integration on every push and on every pull request into main, with the stages install → lint → test → build → smoke. Green on main.
5. Evidence that CI can fail. One deliberately red run (URL), the log line that reported it, and the commit that turned it green.
6. A smoke test committed as script/smoke, running in CI, that fails when the data store is unavailable.
7. At least eight issues, each titled with a requirement identifier, each carrying acceptance criteria, on your board.
8. docs/skeleton-trace.md completed from the template: hop table, requirement traceability rows, and the acceptance record.
9. Secrets hygiene. .gitignore present, .env.example committed with every variable the app reads, zero credentials anywhere in history, the audit output pasted into your submission notes, and a four-line rotation plan.
10. An annotated release: the commit where the skeleton first walked, tagged v0.1.0-skeleton.
11. Hours log current through Week 9, and docs/ai-usage.md carrying an entry for every generated artifact you kept.

Normal-tier rubric (out of 100)

How the Big Line Is Actually Scored

Twenty-two points ride on “the skeleton demonstrably walks.” Students consistently misjudge that line, so here is exactly what the three grades look like on the same project.

22 / 22 — it walks.

$ git clone <the repo> /tmp/fresh && cd /tmp/fresh
$ cp .env.example .env && ./script/setup
  installed 214 packages from package-lock.json
  applied 2 migrations · seeded 1 item
$ ./script/start &
$ open http://127.0.0.1:8080/pantry
  -> "oat milk — expires in 3 days"
$ sqlite3 data/dev.sqlite "update items set name='ryebread'"
$ # reload the page -> "ryebread — expires in 3 days"

That last step is the proof. The page changed because the database changed. Nothing between them was faked.

14 / 22 — it stands. The route returns real data from a real store, but the “rendered result” hop is a curl command in the README rather than anything a human sees, or one component in the middle is a pass-through that does nothing yet. Half the path is real, the claim is honest, the bones are not all connected.

6 / 22 — it is a drawing. The page is styled and impressive and the data is a hard-coded array, a fixture file, or a mock the tests inject. Often accompanied by a very good-looking commit history. This is the most common Week-9 submission and it scores near the bottom of the line, because the one thing the milestone exists to prove — that your architecture is real — has not been proved at all.

The difference between 22 and 6 is frequently two hours of work and one decision: whether you spent Tuesday on the database or on the CSS.

If You Are Behind

Some of you arrive at Week 9 with a specification that is not finished, or with Week 8’s design review still open. Triage in this order, and do not deviate:

1. CI on every push, even with a trivial test. Ninety minutes. It starts paying immediately and it never stops.
2. The data-store hop. It is the hop most likely to break your architecture, so it is the hop worth discovering early.
3. The rest of the path, far end inward.
4. Everything else — issues, traceability, the trace document.

What you must not do is spend this week finishing Week 6’s document. The specification is baselined; changes to it go through change control, in writing, while construction proceeds. A capstone that stops moving to perfect a document is a capstone that will present slides in Week 16 instead of software.

Medium Tier (+up to 25% extra credit)

Pick what fits your project. Depth here buys you time in Weeks 12 through 14.

• Deploy the skeleton now. Add a deploy stage that publishes the walking skeleton to a real URL on merge to main. It will render one row of text on the public internet, and in Week 14 you will already have the hardest part of deployment behind you. Verify the free-tier terms of whatever you deploy to before you point a pipeline at it.
• A build matrix. Run the pipeline against two runtime versions, or two operating systems. It finds the class of bug that is invisible on your machine by definition.
• Enforce the rule in the tool. Turn on branch protection or a ruleset so main cannot take a merge without a green build. The value is that it holds at 1 a.m. when your judgment does not.
• A second slice. Make a write path walk as well as a read path — create, then read back. Writes touch validation, transactions, and error handling, and they surface a different set of architectural lies.
• Cache and time it. Get the pipeline under five minutes with dependency caching, and record the before-and-after numbers in your notes. A fast pipeline is a pipeline you will keep looking at.
• Automate the boring check. Add a step that fails the build if a tracked file matches the secrets pattern from the checklist. Cheap, and it never gets tired.

Hard Tier (+up to 25% additional extra credit)

The Skeleton Memo — two to three pages, addressed to whoever inherits this project in Week 16. No assistant can write this for you, because every sentence in it requires you to own a decision.

Cover all five:

1. The hop you stubbed, and why. Name every hop that is not real yet. For each: what it would have cost to make it real this week, what you did instead, and the specific week and issue where it becomes real. Argue the tradeoff — do not just report it.
2. What the skeleton proved, and what it disproved. Your Week-6 specification made claims. Which ones did building the slice confirm? Which one did it break? If nothing broke, say so plainly and explain how you would know if you were wrong — a specification that survives first contact perfectly is either excellent or untested.
3. The re-estimate. You now have real measured hours for real work. Take three tasks from your Week-7 work breakdown, compare estimate to actual, and compute your correction factor. Then apply it to the remaining plan and state honestly whether the Week-16 scope still fits in the hours you have left. If it does not, name what you will cut and when you will decide.
4. The build-failure policy you commit to. What happens, specifically, when main goes red on a Tuesday night in Week 12? Write the rule now, when it costs nothing, and sign it.
5. The AI accounting. Which parts of this repository were generated? Quote one specific line or block you rejected, and explain what was wrong with it. That single example is what separates a student who reviewed the output from one who accepted it — and it is the question you will be asked in Week 16.

Graded on judgment and honesty. A memo that admits the plan no longer fits and says what will be cut scores higher than one that asserts everything is fine.

Submission

Tag the commit where the skeleton first walked, push the tag, and submit the repository link.

git tag -a v0.1.0-skeleton -m "The skeleton walks: one real request, end to end"
git push origin v0.1.0-skeleton

Your repository should look roughly like this by Friday (names will differ by stack; the shape should not):

your-project/
├── README.md               # includes the "## Run it" section, with what success looks like
├── LICENSE
├── CHANGELOG.md
├── .gitignore              # first in history
├── .env.example            # every variable the app reads, placeholders only
├── <lock file>             # committed
├── <runtime version file>  # .nvmrc / .python-version / .tool-versions / go.mod
├── script/                 # setup, lint, test, build, start, smoke
├── src/                    # folders named after your specification's components
├── tests/
├── docs/
│   ├── requirements.md
│   ├── architecture.md
│   ├── skeleton-trace.md   # this week's document
│   ├── ai-usage.md
│   └── adr/
└── .github/workflows/ci.yml

In the Canvas dropbox, submit: the repository link, the green run URL, the red run URL, the screen recording from Rep 12, and — if you attempted Hard tier — the memo.

Hints

• Start at the far end. Seed the row in the database first, then make the service read it, then the route, then the page. Working outward-in leaves you with a beautiful front end waiting on a back end that does not exist. Working far-end-in means every step you take is immediately observable.
• The first CI failure is almost always the install stage. That is the pipeline earning its cost on day one: it just found the thing your laptop had installed globally two years ago that nobody else has.
• If you cannot get CI green in ninety minutes, shrink the pipeline. Get checkout + install green alone. Commit. Add lint. Commit. Add test. One stage at a time is faster than debugging five at once, every time.
• Do the two-command clone test on Wednesday, not Friday. It always finds something, and Wednesday-you has time to fix it.
• Do not refactor while the skeleton is broken. Get one request through, ugly, and commit it. Then clean up. A tidy non-working system is worth nothing this week.
• Write .env.example by grepping your own code for every environment variable it reads. You will find one you forgot, and that one is the one that breaks the grader.
• Ask your assistant to review, not just to generate. “Here is my repository tree and my architecture document — where do they disagree?” is a better use of it than “scaffold me a project.”

What Mastery Looks Like

A mastered Milestone 9 is small and unglamorous and completely solid.

A stranger clones the repository, runs two commands, and within five minutes is looking at one row of real data that came out of a real database through a real service through a real route. They did not ask you a single question, because the README told them the prerequisite, the commands, and what success would look like. The repository’s folders match the architecture document, so the document reads as true. The commit history reads like a project: forty commits across the week, each one explaining why.

And on every one of those pushes, a machine somewhere ran the whole thing from scratch and said yes. There is one red run in the history, from Tuesday, made on purpose, with the fix commit right behind it — because the student wanted to know what failure looked like before failure chose the time.

Nothing about it demos well. Everything about it holds.

Coach’s Note — You are going to feel, on Friday, like you did not accomplish much. One row of text. Some YAML. A folder rename. Sit with that feeling and then look at what actually changed: you can no longer be surprised by your own architecture, and you can no longer break your project without being told within four minutes. That is not a small week. That is the week the rest of the semester becomes possible.

When You’re Done

• One real request travels every hop; no hop is faked without being labeled stub
• script/setup takes a fresh clone to runnable in one command
• Runtime version pinned in a file; lock file committed; install runs from the lock file
• README.md has a ## Run it section that says what success looks like
• CI runs on every push and every pull request into main, and main is green
• You have watched your pipeline turn red on purpose, twice, and go green again
• script/smoke passes in CI and fails with the data store stopped
• Eight or more issues, each titled with a requirement identifier, each with acceptance criteria
• docs/skeleton-trace.md complete: hops, traceability, acceptance record, honest stubs
• Secrets audit run across the full history; .env.example committed; rotation plan written
• docs/ai-usage.md updated; hours log current through Week 9
• Tagged v0.1.0-skeleton and pushed

A theological footnote. “According to the grace of God given to me, like a skilled master builder I laid a foundation, and someone else is building upon it. Let each one take care how he builds upon it” (1 Corinthians 3:10, ESV). Paul takes credit for the one part of the building nobody will ever admire, and then says the quiet thing this whole week depends on: someone else is building upon it. You are not building something you will keep. In seven weeks you will hand this repository to a stranger, and after that, in every job you ever hold, you will leave code behind you for people you will never meet. The foundation you lay is not for your comfort; it is for them. Note also what the verse asks of you — not speed, but care. Care is a property of the builder, not of the building, and in a week when a machine can pour a plausible-looking foundation in ninety seconds, care is precisely the thing that has to come from you. Take care how you build. Somebody else is going to build on it.