fix: don't hide all cooking matches behind default near-miss tolerance - #355
Merged
Merged
Conversation
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: Cursor <cursoragent@cursor.com>
5 tasks
touchthesun
added a commit
that referenced
this pull request
Aug 12, 2026
…lerance (#356) Same bug as #355, in the manufacturing MatchView: the near-miss tolerance filter can hide every facility (default tolerance is 1 missing requirement), but the slider that lets a user raise it was only rendered inside the already-filtered results branch — so once everything was filtered out, there was no way to see or reveal the hidden facilities, just a blank "No matches found". Split the empty-state check the same way as the cooking fix: "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. Co-authored-by: maker-nathan <nathan@makernet.work> Co-authored-by: Cursor <cursoragent@cursor.com>
touchthesun
added a commit
that referenced
this pull request
Aug 13, 2026
…ration (#358) * fix: raise selected-option text contrast to WCAG AA muted-foreground (#737373) is tuned for the default surface. On the indigo-tinted *selected* surfaces it fell below the 4.5:1 AA threshold: RecipePicker selected option 3.84:1 on bg-indigo-100 DomainPanel selected radio blurb 4.24:1 on bg-indigo-50 DesignPicker already carried this fix, with a comment naming the same 3.84 figure. RecipePicker was copied from it when the cooking domain landed and the fix did not carry across; DomainPanel is the same class of defect on a lighter tint. Both found by the Slice 0 characterization specs, whose a11y assertions run axe over the cooking surfaces for the first time. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test: add Slice 0 characterization baseline for the frontend revamp The incoming frontend contribution (binaryLady/OHM, 163 commits ahead of merge-base c3572e3) is not just a design revamp: it bundles a Vite -> Next.js migration, Python backend changes, CI policy changes, and an optional Supabase site layer. It also predates our last 19 commits and modifies every pre-existing e2e spec (-122 lines), so the fork's own tests cannot serve as the safety net for integrating it. This is the contract that integration is verified against, authored on main before anything lands. See notes/frontend-revamp-integration-plan.md. e2e/cooking-domain.spec.ts 8 specs for the cooking domain, which the fork predates entirely and whose Next app/ shell has no recipe or kitchen route. Git merges DomainPanel/useDomainPreference cleanly regardless: the files arrive, the wiring does not, and nothing would notice. e2e/near-miss-tolerance.spec.ts Regression cover for #355/#356 in both domains. The behaviour has unit cover already, but those tests mount through MemoryRouter -- the category the fork's playbook flags for a harness rewrite under the App Router. These are black-box, so they keep proving the fix while the unit tests are re-hosted. src/test/baselineFreeze.test.ts + e2e/baseline.manifest.json sha256 freeze over the 14 pre-existing specs, a11y.ts, and the two above. Not immutability -- editing one is a deliberate behaviour change that must be stated rather than ride along inside a large refactor. Re-bless with `npm run baseline:bless`. harness/proxy-contract.mjs 10 checks against the real container, which no existing suite touches: the mocked lane stubs the API in the browser, so the proxy is never in the path. The fork replaces nginx with Next route handlers, so the guarantees nginx holds today need an executable record. Speaks only HTTP, so the same assertions run unchanged against the Next image. `npm run contract:proxy`. Both new suites were verified RED, not merely green: reintroducing the #356 bug fails the tolerance spec (and correctly leaves the empty-result spec passing), and touching a frozen spec fails the guard by name. Unit tests 350 -> 368. frontend-ready and make ready both green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: maker-nathan <nathan@makernet.work> Co-authored-by: Claude Opus 5 <noreply@anthropic.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
Now that cooking-domain matches carry a real requirement-coverage explanation (#354), the near-miss tolerance filter in
CookingMatchViewactually does something — and recipes with several ingredients/tools routinely exceed the default tolerance of 1 missing requirement. Every kitchen was silently filtered out, showing a blank "No matches found" with no way to reveal them, because the tolerance slider was only rendered inside the already-filtered results branch.Same underlying pattern exists in
MatchView.tsx(manufacturing) — it wasn't hit there because it depends on a facility having enough missing requirements to exceed tolerance, but it's the identical bug. Flagging but not touching it here to keep this change scoped to the reported issue; happy to follow up if wanted.Test plan
CookingMatchView.test.tsxreproduces the bug (fails onmain, passes after the fix)npm run typechecknpm run lintnpx vitest run src/features/match(74/74 passing)npm run buildMade with Cursor