Exercise 3: A Fifth Change — Dependency Update — Possible Solution
====================================================================

THE NEW CHANGE
------------------------------
    {'name': 'update a dependency version with no code changes',
     'actual_work_minutes': 3}

RESULTS
------------------------------
    Heavy process: 3min work + 120min process = 123min total (40.0x)
    Scaled process: 3min work + 5min process = 8min total (1.67x)

FULL COMPARISON TABLE
------------------------------
    typo fix (2min):              heavy=122min (60.0x), scaled=7min (2.50x)
    dependency update (3min):     heavy=123min (40.0x), scaled=8min (1.67x)
    variable rename (5min):       heavy=125min (24.0x), scaled=10min (1.00x)
    input validation (25min):     heavy=145min (4.8x),  scaled=65min (1.60x)
    payment integration (480min): heavy=600min (0.2x),  scaled=600min (0.25x)

The dependency update lands between the typo fix and the variable
rename in both overhead ratio and absolute cost - closest in kind to
the typo fix (both are genuinely trivial, low-risk changes where a
fixed heavy process produces an extreme overhead ratio: 60x and 40x
respectively).

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the chapter's own scaled-process logic generalizes
cleanly to a change type it didn't originally consider: a dependency
bump is exactly the shape of low-effort, low-risk work the light-touch
tier (5 minutes) was designed for, and applying it here produces the
same order-of-magnitude improvement (40.0x down to 1.67x) the chapter
already demonstrated for the typo fix and variable rename. It's worth
noting a real caveat this exercise's own numbers don't capture: not
every dependency update is actually low-risk (a major-version bump
with breaking changes is a different animal from a patch release), so
a real process would need to distinguish those cases rather than
treating "dependency update" as uniformly trivial - the review tier
should scale with actual risk, not just a category label.