[obvious-autobuild]

What changed and why

One household safety screen now sits behind every surface that offers a recipe or a swap: exact and near-match recommendations, substitution offers and availability, cook-time swap rechecks, and weekly-plan catalog candidates and swaps.

Why: the surfaces previously screened independently — keto failed closed in recommendations, but pescatarian had no class gate, allergens were only checked where the app-ingredient bridge resolved a line, substitutes and plan swaps carried no household screen, and catalog recipe lines the bridge could not resolve passed silently.

• Bundle contract — every ingredient in recipes-v2.json carries composition classes (dairy, meat, fish, shellfish, egg, plant, grain, ...). RecipeBundleV2 decodes them with an [unknown] fallback so older bundles fail closed; the loader persists bundle-authoritative classes; a migration adds the column and best-effort backfills pre-existing vocabulary from the shipped bundle.
• Gate — HouseholdSafetyGate (pure, in FeatureLogic/Safety) maps allergen groups to classes and screens lines: a restricted group's class blocks, unresolved (unknown) composition blocks a restricted household, keto fails closed while no carb threshold is selected, pescatarian blocks land-animal classes (fish and shellfish allowed — it has no diet claim to lean on).
• Resolver — HouseholdSafetyProfileResolver derives the household at query time from stored allergen ingredient IDs via AllergenSupport keyword groups, and screens catalog lines by canonical-key classes, so lines the bridge cannot resolve are screened instead of passed.
• Fail-closed reads — a failed profile or vocabulary read is not treated as "no restrictions"; the offering surface blocks. Legacy candidates keep their existing ID-based checks; the new class screen covers catalog-backed paths.

A test sweep (Tests/SafetyGates/SafetyGatesSweepTests.swift) drives every surface for each allergen group, each diet, and a combined household, and re-screens each returned recipe and offered substitute through the bundle's classes. Mutation checks prove the sweep can fail: forcing a line's classes to unknown removes a recipe from the surfaces, and a dropped group→class mapping would let a violating recipe through.

How I checked it

Check	Command	Result
Linux taste-store suite (compiles the edited RecipeBundleV2.swift)	bash apps/ios/Tools/taste-store-check/Scripts/test.sh	50/50 pass after re-pin
Community-check mirror hashes	bash apps/ios/Tools/community-check/verify.sh	all OK
Syntax check of every changed Swift file	swiftc -parse per file	all parse (caught a real guard trailing-closure parse error in SubstitutionService.swift, fixed)
Bundle reproduction	python3 data/recipes/tools/compile_bundle.py	SHA-256 3401c7ae9d0a854284ed6cd04a7f88172cea92bda93960e84d2b67dd66f31eed, matches manifest.json
Whole-bundle class-screen reach (preliminary, bundle-level)	offline count	pescatarian 475/762 recipes; allergen-only 448 (wheat/gluten) – 755 (mustard); keto threshold candidates 160/200/294 at 15/20/30 g carbs

Hosted macOS CI status (head bd8af1b)

• build-and-test: pass — the app target and the full test suite (including SafetyGatesSweepTests) compile and run green on hosted macOS CI. Runs: 38857388989 (pull_request) and 38857395785 (dispatch), both success at bd8af1b5a2dfbfb9b7a49e5818fbdeba172269ee.
• Earlier red rounds on this branch (0a815db and earlier) were sweep-fixture and merge-contract defects, all fixed on this head: the sweep now seeds the swept household into health_profile before driving loadSnapshot (the weekly-plan pool was previously screened unrestricted), the weekly-plan pool screens rcp-* rows through the composition class screen while legacy rows keep their documented required-flagged-line filter, substituteIsAllergen is restored to the base's canonical id/diet contract (the composition screen stays on the offering surfaces), and the dropped-group-mapping mutation check asserts the gate's two surviving refusals.
• The base tip e87ee7b2 (test-expectation alignment for the shipped bundles) is merged; its GoalPath/Weekly failures do not reproduce here.
• PR state: MERGEABLE / CLEAN against obv/burst8-fridgeluck-goal-path.

What I could not check

• No device run — CI verifies the simulator suite only.
• SwiftLint was not run locally (not installed in the Linux sandbox); repo lint runs in CI.
• substitution-check compiles only SubstitutionTable.swift, so it does not exercise the edited service; the service compiles first on hosted CI.
• Keto reach counts are bundle-level, not app-query results — with the threshold constant still unset, the keto pool is empty by design (fail closed).

Assumptions

• Base is obv/burst8-fridgeluck-goal-path (stacked, like PR [obvious-fleet] real-WebSocket cook-session E2E for phone and gateway, goal-path green #186); this branch carries the prerequisite merges of obv/burst9-fridgeluck-catalog-data, obv/burst6-fridgeluck-catalog-recommend, and obv/burst6-fridgeluck-weekly-plan.
• The keto carb-threshold constant stays unset in this PR; setting it is a one-line follow-up once a threshold is chosen (candidates above).
• Nothing merged; draft for review.

Human author: Sam Gu (sgu07966@gmail.com)

🔗 Obvious Project · 🧵 Obvious Thread · 🔀 Obvious PR Artifact

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 7c9c9b59-c6dc-4f6f-af74-a5c5fb17daef

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}