# Reference patch — 01-reference-books-go-out-overnight

The answer key for how the reference absorbs this change, and the thing that makes `budget.json`
reproducible. **Never shipped to the candidate.**

1. **Add** `ReferenceShelfLoanPeriod.java` (in this directory) to `reference/src/`. New file, so
   `measureChange` charges nothing for it.
2. **Change one line** in `reference/src/LibraryFactory.java`, in `standard()`:

   ```diff
   -                new FixedLoanPeriod(LOAN_PERIOD),
   +                new ReferenceShelfLoanPeriod(new FixedLoanPeriod(LOAN_PERIOD)),
   ```

`FixedLoanPeriod` is decorated, not deleted. Three weeks is still stated once, in the factory, and
the new rule says only what is new — so ending it is the same line in reverse and the lending
shelves never move.

Measured: `reference_diff = 2` (1 added, 1 removed, one file touched), so
`diff_budget = max(3, 2 + ceil(2/2)) = 3`.

The curveball suite (6 tests) is green after the patch, and **so is the base suite (17 tests)**.
That matters here: nothing in the base suite asserts a due date for the dictionary, because the
reference shelf's terms were never part of the base requirement. Only the lending shelves' three
weeks were, and they have not changed.

## Where the requirement landed, and where it did not

`Library` was not opened. That is the measurement: the class that runs the desk, checks the rules,
finds a copy and mints the loan has no opinion about how long a book may be kept, so a change to
lending terms cannot reach it.

Two things made it a one-liner:

- **`LoanPolicy` separates "how long may this be kept" from the act of lending.** They collapse
  naturally — `borrowedAt.plus(Duration.ofDays(21))` inside `borrow()` is one line and obviously
  correct — and that one line is exactly where this requirement would have had to go, next to the
  eligibility checks and the copy allocation it has nothing to do with. Worse, the next variation
  (a week for new releases, a term for staff) would have gone there too, and the method that lends
  would slowly become the method that knows every lending term the library has ever had.
- **`Section` was on the catalogue card from the start.** The requirement is "reference books are
  different", and the catalogue already knew which ones those were. Had the section not existed,
  this change would have needed a new field on `Title` — a contract change — and an edit to every
  line that constructs one.

**The judgement call worth defending: `Section` earns its place by being data, not behaviour.** The
tempting move in the base design is to put the loan period *on* the enum —
`REFERENCE(Duration.ofDays(3))` — which reads beautifully and is wrong for a reason worth being able
to state: this requirement is then an edit to the enum, the next one (new releases, which are not a
section) does not fit at all, and a section that carries a lending term cannot be used by two
branches that lend differently. The section says where the book sits. What that implies is a policy.

## What this costs without the seam

With the due date computed inline in the lending method, the change is:

- a branch on the section inside `borrow()`, in the class that must not break, immediately above the
  code that checks the borrowing limit and finds a free copy
- and the next lending term after this one goes in the same place, so the second such requirement
  costs the same again rather than nothing

The reference's cost is two lines, and neither of them is in a class that does anything at all when
a book is lent.
