Exercise 3: A WIP-Limited Review Queue — Possible Solution
====================================================================

SETUP
------------------------------
    WIP_LIMIT_AWAITING_REVIEW = 6
    Build only produces up to what keeps "waiting" within the limit;
    Review still processes at its own real rate of 2/day.

RESULTS
------------------------------
    Day  1: built=4  (produced 4), reviewed=2,  waiting=2
    Day  2: built=8  (produced 4), reviewed=4,  waiting=4
    Day  3: built=10 (produced 2), reviewed=6,  waiting=4
    Day  4: built=12 (produced 2), reviewed=8,  waiting=4
    ...
    Day 18: built=40 (produced 2), reviewed=36, waiting=4

    Days to process all 40 of Build's own target items: 18
    Max "waiting for review" at any point: 4 (vs. unconstrained day-10
    backlog of 20)

A GENUINE SELF-STABILIZATION, NOT JUST A CAP
------------------------------
The WIP limit of 6 is never actually reached - "waiting" stabilizes at
4, not 6. Once the queue fills to 4, Build's own daily output is
automatically throttled down to exactly match Review's real capacity
(2/day), because Build can only add as many new items as the limit
still allows (WIP_LIMIT - current_waiting). The system finds its own
equilibrium slightly below the stated cap, rather than sitting pinned
against it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the real mechanism behind Kanban's own "stop starting, start
finishing" principle, made concrete: the WIP limit doesn't just
prevent the backlog from growing past some number - it forces Build's
own pace to match Review's real, sustainable rate automatically, with
no manager needing to tell Build to slow down. The unconstrained
version's own backlog of 20 by day 10 (and growing without bound
afterward) versus this version's steady 4 is the direct, measured
payoff: the same underlying capacity mismatch exists in both cases,
but only the WIP-limited version keeps it from compounding into an
ever-larger, ever-more-visible problem.