Week 11 gave the instruction: by D2, a walking skeleton, one value crossing every interface of your project. Today, before you demonstrate it, the instruction gets its theory: where the term comes from, the arithmetic of why it works, and what exactly "end to end" means when the ends are a sensor and a phone.
One thin slice, every layer
The term is Alistair Cockburn's, from the mid-1990s: a walking skeleton is a tiny implementation of the system that performs one small end-to-end function, linking the main components together so that architecture and features can then grow in parallel. Freeman and Pryce's Growing Object-Oriented Software, Guided by Tests (2009) sharpened it into the modern rule: build the thinnest possible slice of real functionality first, through every layer, and only then start on features. The opposite strategy, perfecting one component before touching the next, feels safer and is not; it postpones exactly the work that fails.
Same hours, different shape. Both benches spent a week. The left one can demonstrate, has tested every join, and can now thicken any layer in any order. The right one has a beautiful node and four surprises waiting.
Why interfaces, not components
The argument is arithmetic, not taste. A system of n components has up to n(n − 1)/2 pairwise connections, and each connection it actually uses is a contract that can be wrong on either side. Your project has five components in the main chain, node, broker, monitor, bridge, dashboard, plus the browser; count the joins it really uses and you get six contracts. Eleven weeks of troubleshoot pages tell the same story from experience: faults cluster at joins, Wi-Fi credentials, topic spelling, payload bytes versus strings, bind addresses, firewall doors, not inside components you understand. The skeleton is simply the cheapest experiment that exercises all six contracts at once. A deep component tests zero of them.
There is a scheduling theorem hiding in that. Interface faults cost the same to fix whenever you find them, but their consequences grow with time: found this week, a wrong payload format is a ten-minute fix; found during Week 14, it stalls D4 (15 %) while every later layer that assumed the format gets reworked. Pulling all six discoveries into the cheapest week of the project is the entire strategy, and it is why D2 grades the crossing, not the polish.
Your six contracts, named
The contracts are the project. Each numbered join is an agreement between two programs, and every one of them appears in your docs/topics.md or it does not really exist. Your project's names differ; the count rarely does.
Write the contracts down, in the repo, as Week 9 taught with docs/topics.md: one line per topic and route, exact spelling, exact payload. A contract that lives in two heads diverges; one that lives in one file gets read by both programs' authors, and by the marker.
What D2 demonstrates today
Per the brief on Omnivox, which governs the deliverable's exact contents and grading, D2 is the skeleton plus the analysis that explains it. On the bench, the demonstration itself has a canonical shape, the same one every rung demo will have from now on:
Cause something real. Touch the physical world your project senses: shade the sensor, press the switch, warm the probe.
Show the value travel. The dashboard, or at minimum the firehose and a curl of your API, shows the change arriving; the rule reacts; the actuator does its one thin thing.
Name the contracts. Point at docs/topics.md and say which topic, which payload, which route just carried the value. Sixty seconds, and it proves the analysis matches the system.
Thin is the assignment, not the compromise
A skeleton with one sensor reading, one fixed rule and an LED beats one with half a dashboard and no actuator, because the first crosses six contracts and the second crosses three. Thickness is what D3, D4 and D5 are for; today, width.
Checklist for this stage
Check yourself
A pair argues their counting project has only three components, so skeletons are overkill. Count their contracts and judge.
Three components in their minds (node, Pi program, page) still means the real chain node → broker → their program → bridge or route → page → browser, because the broker and the browser are components whether or not you wrote them. That is five or six contracts: Wi-Fi plus topic, subscription plus payload, any command path, the API route, the JSON keys. The skeleton costs an afternoon; each undiscovered contract costs more. Overkill would be true only if the joins could not be wrong, and Weeks 8 to 11's troubleshoot tables are a catalogue of exactly these joins being wrong.
Why does the formula n(n − 1)/2 overstate your project's contract count, and why does the lesson survive anyway?
The formula counts every possible pair, 6 × 5/2 = 15 for six components, but a pipeline only uses neighbouring pairs plus the command return, about six. The lesson survives because the point is growth and location, not the exact count: contracts grow quickly as components are added, every used one can fail independently on either side, and your troubleshooting history locates faults at these joins. Six real contracts untested until Week 14 is the risk; fifteen was never the claim.
Your skeleton works, but only because the rule's threshold is hard-coded and the dashboard shows raw numbers without labels. Is that a D2 problem?
No, it is the definition working as intended. Hard-coded thresholds and unlabelled numbers are thinness, and thinness is what today grades, provided the value genuinely crosses every interface and the analysis names the contracts honestly. It becomes a problem only if it is still true at D4; the rung list is where "make the threshold settable from the dashboard" and "label the page" get their week, and saying so out loud in the demo is exactly the analysis D2 wants.