The Coverage line

The deliverable→story map is not left implicit. A stories file records it as one line at the end — the Coverage line, the audit that every deliverable is covered.

The line reads each deliverable once and names the stories that realize it. A scan of it tells whether the rung is covered, because a deliverable that has no covering story is visible by its absence from the line. Step through the real F6.1 line on the right; the content figure drops an entry to show what an open line looks like.

The line An open line On the Portal References

The F6.1 Coverage line · read entry by entry

Entry 1 of 7: D1→US1 — deliverable D1 is realized by US1. All seven deliverables have an entry, so the line is closed.

One line, the whole map

The deliverable→story map is recorded once, as the last line of the stories file: the Coverage line. It reads each deliverable in order and names the stories that realize it, separated by a middle dot. There is one entry per deliverable, and that is the rule the line enforces by its shape: if a deliverable is missing from the line, its absence is the signal that no story realizes it.

The line is the audit, not the work. The work was done in the stories — the Connextra sentences, the Given/When/Then, the INVEST lines. The Coverage line is the one-glance summary that lets an Operator confirm the rung is fully covered before accepting it. It is also the thing a reviewer reads first: a closed line means every deliverable has somewhere to be proven, an open one points straight at the gap.

Coverage line: The last line of a .stories.md: one entry per deliverable, mapping it to the stories that realize it.
entry: A single D→US… pair, e.g. D4→US2,US3,US5.
closed: Every deliverable has an entry — the rung is fully covered and can be accepted.
open: A deliverable has no entry — a gap; the rung is not yet coverable as done.

The line is read, not computed by hand each time. Its value is that a single scan answers one question: is every deliverable covered.

An open line — reading the gap

The hero figure read the closed F6.1 line, entry by entry. The figure below shows what happens when an entry is missing. Pick a deliverable to drop its entry from the line; the readout reports that the line is no longer closed and names the deliverable with no entry. Choose none and the line is whole again — all seven entries present, closed.

This is the practical use of the line. A deliverable with no entry is a deliverable the rung produces but no story accepts; the open line surfaces it at a glance, before a single line of code is written to it. The two figures teach different moves: the hero reads the line that is there, this one reads the gap when one entry is not.

Drop an entry · read the open line

The Coverage line is closed: all 7 deliverables have an entry.

A closed line carries one entry per deliverable; drop an entry and the line names the deliverable no story realizes — the gap is read, not guessed.

On the Portal — the real F6.1 line

On the Portal — the learning platform this course builds — the file f6.1.stories.md ends with its Coverage line. It maps the seven deliverables of the bootstrap rung to the five stories that realize them. Every deliverable appears, so the line is closed and the rung is coverable as done. The markdown below carries that line verbatim, with the two stories whose entries frame it.

# f6.1.stories.md — the Coverage line, the last line of the file (markdown, not code).
#   D1 → US1            the endpoint, served (an operator boots the app)
#   D7 → US4, US5       verification (an operator restarts, a visitor sees a clean error)

# The line itself, verbatim:
Coverage: D1→US1 · D2→US1,US3,US4 · D3→US2 · D4→US2,US3,US5 · D5→US2 · D6→US1 · D7→US4,US5.

# Seven entries, one per deliverable D1…D7 — every deliverable present, so the line is closed.

the principle

The deliverable→story map is recorded as one auditable line: a closed line covers every deliverable, an open one names the gap.

on the Portal

F6.1's Coverage line reads D1→US1 · … · D7→US4,US5 — seven entries, all present, closed; the rung is coverable as done.

The Coverage line is the rung's one-glance audit — every deliverable has an entry, or the line names the one that does not.

Recap — the line is the audit

The Coverage line is the last line of a stories file: one entry per deliverable, mapping it to the stories that realize it. A closed line covers every deliverable and the rung can be accepted; an open line names the deliverable no story realizes, before a line of code is written. The hero read the closed F6.1 line entry by entry; the content figure read the gap when one entry is dropped. Each entry leans on what the next dive reads: what a story carries on its INVEST line — the invariants it encodes and whether it is testable.

Next in A4.4: A4.4.3 · INVEST and invariants — each story's INVEST line names the invariants it encodes and whether it is testable.

References

Sources for coverage as the audit between deliverables and their checks, and where this connects in the course.

Sources

Adzic, G. — Specification by Example — the living map from requirements to the examples that check them.
Cohn, M. — User Stories Applied — stories as the units a deliverable is covered by.
Humble & Farley — Continuous Delivery — a rung accepted only when every slice it ships is covered by a check.

Related in this course

A4.4 · From stories to a .stories.md — the module hub.
A4.4.1 · Deliverable to story — the previous dive.
A4.4.3 · INVEST and invariants — the next dive.
A2.04 · Acceptance criteria — the proof each story carries.
A4 · The spec layer — the chapter.
F6 · The Portal on the web (Phoenix) — the real chapter this line covers.