release: v1.0.25 — nested bundle kitchen routing - #90
Merged
Merged
Conversation
#87) * fix(print): route nested bundle components to the right kitchen ticket Backend PR #237 (issue #234) made OrderDto.Items ROOT-ONLY: a bundle's components and an item's add-on sides are no longer top-level rows, they hang off their parent in SideItems, to arbitrary depth. No DTO field changed, so the feed still deserializes — the printer app just stopped seeing most of the order. Kitchen routing read the top level only, in both of its steps. A "Menu Deal" whose product is FrontKitchen containing BackKitchen fries then produced NO back-kitchen ticket at all (hasBackKitchenItems was false), and the fries printed on the front kitchen's ticket instead, as a nested "+ 2x Fries" line. A live order line, silently sent to the wrong kitchen. Routing now walks the whole tree, in KitchenTicketFilter — a pure function, like FeedWatchdogDecision, so the tree walk is testable without a printer. A line goes to the kitchen it names; a line that names none (a drink, an extra sauce) is a modifier of its parent and rides with it. A parent whose kitchen differs from its component's still reaches that component's ticket, but only as context: printed parenthesised at normal size, so it doesn't read as a dish that kitchen has to make. The "does this kitchen get a ticket" question is now answered by the very thing that will be printed, rather than by a second scan beside it. Two further regressions from the same contract change, found while tracing it — both are cases of a child that used to be its own top-level row and therefore printed in full: - The kitchen receipt rendered children ONE level deep, so a grandchild in a nested bundle printed nowhere. Rendering is recursive now. - It rendered a child's name and quantity only, dropping its "NO onion" and its note. Every line now prints its own detail at its own depth. A parent's note also moved above its components: trailing them, it read as if it belonged to the last child printed. Order/OrderItem gain a clone helper each (used to build a ticket without mutating the order the history list and the UI hold) and OrderItem gains a [JsonIgnore] IsContextOnly presentation flag. No wire field added, renamed or removed — the DTO mirror is unchanged. The clone also retires CreateFilteredOrder's 28-line hand-copy, where a field added to Order would have silently vanished from every kitchen ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor(print): address Sonar findings on the kitchen-ticket renderer CreateFilteredOrder and AppendKitchenItem touch no instance state (S2325), and the item renderer's cognitive complexity was 20 against a limit of 15 (S3776) — the ingredient-customization block is now its own method, and the two redundant "not null and Any" guards before a foreach are gone. No behaviour change: same lines, same ESC/POS sequences, same order. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Ships #87: kitchen-ticket routing walks the nested item tree, so a bundle component whose kitchen differs from its parent's reaches its own kitchen instead of no kitchen at all. Deliberately released AHEAD of backend PR #237, which is what makes OrderDto.Items root-only and is still on backend `develop`. The fix is backward compatible: against today's production backend the printer feed returns SideItems: null on every order, so every line is a root with its own KitchenType and the filter reduces to exactly the old top-level `Where(KitchenType == kitchen)` — byte-identical receipts. The new nested layout only appears once the backend release lands, by which time the client workstations will already have auto-updated. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
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.
Summary
Release PR
develop→mainfor v1.0.25. Two commits:fix(print)— kitchen-ticket routing walks the nested item treechore(release)— version bump 1.0.24 → 1.0.25What ships
Backend PR piwas-21/restaurant-app-backend#237 (issue #234) made
OrderDto.Itemsroot-only: bundle components and add-on sides are no longer top-level rows, they hang off their parent inSideItems, to arbitrary depth. No DTO field changed, so the feed still deserializes — the printer app just stopped seeing most of the order.Kitchen routing read the top level only. A "Menu Deal" whose product is FrontKitchen containing BackKitchen fries produced no back-kitchen ticket at all, and printed the fries on the front kitchen's ticket. #87 routes off the whole tree (
KitchenTicketFilter), and fixes two further regressions from the same contract change: children rendered only one level deep (a grandchild printed nowhere), and a child'sNO onion/ note were dropped.Sequencing — deliberately ahead of the backend
Backend #237 is on backend
develop, notmain. The bug is not live yet; this release gets the client workstations auto-updated before the backend flips.Safe to ship early because the fix is backward compatible: against today's production backend the printer feed returns
SideItems: nullon every order (the very defect #237 fixed), so every line is a root carrying its ownKitchenTypeandKitchenTicketFilterreduces to exactly the old top-levelWhere(KitchenType == kitchen)— byte-identical receipts. The new nested layout appears only once the backend release lands.Verification
build-release.ymlon thev1.0.25tag (windows-latestjob) — that is the Windows-host verification CLAUDE.md §1 requiresOwed after this release, before the backend release
develop). This release cannot change printed output on the current prod backend, so the new layout's first appearance on paper would otherwise be in production.OrderDtocontract changes enforceable + seed the E2E bundleRelease notes
v1.0.25onmain→ publishes the Windows.exe+ Android.apktopiwas-21/printer-app-releases