Fix cooking-domain match coverage warning and add RFQ generation - #354
Merged
Conversation
Cooking matches never got a requirement_matches explanation (that block
was gated to domain == "manufacturing"), so every kitchen card showed
"Coverage unknown" regardless of how well it actually matched the
recipe. CookingMatcher already computed ingredient/tool overlap; it now
also reports which items matched vs. were missing, and the match route
turns that into a MatchExplanation so the frontend can show real
coverage ("Missing N of M requirements") instead of a bare, unexplained
confidence percentage.
Co-authored-by: Cursor <cursoragent@cursor.com>
Extends the existing RFQ generation flow (design + facility) to also cover recipe + kitchen matches, the same way manufacturing users can today. CookingMatchView gets a "Contact selected kitchens" action next to the existing selection controls; POST /api/rfq/generate now accepts a domain field and renders a recipe-flavoured RFQ (ingredients, equipment, and the match explanation from the coverage fix) when domain="cooking", leaving the manufacturing path unchanged. Co-authored-by: Cursor <cursoragent@cursor.com>
Two issues surfaced only under project-reference builds (tsc -b), not tsc --noEmit -p .: a facility fixture missing the Facility type's required manufacturing_processes field, and a mutable let captured by an msw handler that a later toMatchObject assertion narrowed to a type tsc -b's stricter incremental build considered incompatible. Switched the capture to a resolved promise instead of a polled variable, which sidesteps the narrowing entirely and is more direct besides. Co-authored-by: Cursor <cursoragent@cursor.com>
5 tasks
touchthesun
added a commit
that referenced
this pull request
Aug 12, 2026
#355) Now that cooking-domain matches carry a real requirement-coverage explanation (fixed in #354), the near-miss tolerance filter actually does something — and recipes with several ingredients/tools routinely exceed the default tolerance of 1, so every kitchen got filtered out with a blank "No matches found" empty state and no way to reveal them, since the tolerance slider itself was only rendered inside the already-filtered results branch. Split the empty-state check: "No matches found" now only fires when the API returned zero solutions. When solutions exist but are all hidden by tolerance, the slider (and hidden-count message) render with a "No matches within tolerance" message instead, so raising the slider reveals them. Co-authored-by: maker-nathan <nathan@makernet.work> Co-authored-by: Cursor <cursoragent@cursor.com>
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
2 participants
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
Two follow-ups from the live
cooking-testdeployment:explanation.requirement_matches, because that block was gated todomain == "manufacturing"inPOST /api/match.CookingMatcheralready computed ingredient/tool overlap; it now also reports which ingredients/tools matched vs. were missing, and the match route turns that into a realMatchExplanation. Kitchens now show e.g. "Missing 2 of 13 requirements" instead of an unexplained percentage.CookingMatchViewgets a "Contact selected kitchens →" action next to the existing selection controls, andPOST /api/rfq/generateaccepts adomainfield:domain="cooking"renders a recipe-flavoured RFQ (ingredients, equipment, and the match explanation from fix Harry does not have access to the Azure Non Profit Grant #1), while the existing manufacturing path is untouched.Test plan
uv run pytest tests/unit/test_cooking_matchers.py tests/unit/test_cooking_match_explanation.py tests/api/test_rfq_routes.py -vuv run pytest tests/unit tests/api(1181 passed)npx vitest runinfrontend/(348 passed, including newCookingMatchViewandRfqViewcooking-domain tests)npx tsc --noEmitinfrontend/make ready(all 11 gates pass)Made with Cursor