refactor(schedule): the two legs become two functions - #293
Merged
Conversation
computeSchedule was 180 lines in which the interesting fork — which leg spends the window — sat in the middle of an if/else, writing into four `let`s declared above it and mutating the pre-ferment durations in one branch only. coldSchedule() and roomSchedule() each take what they need and return a FermentPlan: yeast percent, steps, and the two cold-bulk signals. computeSchedule now reads as three parts — read the inputs, pick the leg, assemble the answer — with the choice on one line. No `let` and no mutation left: the room leg's pre-ferment clamp returns a new list rather than reassigning the one the caller built. Behaviour is identical, which the yeast-solve and mass-balance matrices already cover exhaustively. What they did not cover is the contract the split now states outright: room mode reports null for both cold-bulk signals and cold mode reports both, which is how quality.ts tells which leg ran. Pinned. Baseline: 940 unit (+2).
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The last item from the review:
computeSchedule's cold/room split.Why
180 lines in which the interesting fork — which leg spends the window — sat in the middle of an
if/else, writing into fourlets declared above it, and mutatingprefermentDurationsMinin one branch only. Reading the cold path meant skipping past the room path and remembering which variables each had assigned.What
coldSchedule()androomSchedule()each take aPlanArgsand return aFermentPlan— yeast percent, steps, and the two cold-bulk signals.computeSchedulenow reads as three parts:No
letand no mutation left: the room leg's pre-ferment clamp returns a new list instead of reassigning the one the caller built.Behaviour
Identical. The yeast-solve and mass-balance matrices already cover both legs exhaustively — {fresh, instant, active-dry, sourdough} × {none, biga, poolish, both} × {room, cold} × {spiral, stand, hand} × ball proof — and all 940 pass unchanged, as do the 90 browser tests.
One thing the split made worth stating
Room mode returns
nullfor both cold-bulk signals; cold mode returns both.quality.tsreads exactly that to tell which leg ran, so it is a contract — and nothing checked it while the two legs shared a pair oflets. Now pinned inschedule.test.ts, including that the natural value is the desired one capped at the 48 h ceiling.Checks
940 unit (+2), 90 browser, coverage 100 %.