feat: add Boss Mode and Sweet Lab previews - #8
Shakeyswings wants to merge 21 commits into
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 061fdae8d9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!selection.primaryFlavorId) reasons.push("Primary flavor is required."); | ||
| if (!selection.bossFinishFlavorId) reasons.push("Boss finish flavor is required."); |
There was a problem hiding this comment.
When this validator receives a selection from a curated preset or any caller other than the current keyboard, it checks only that the primary and finish IDs are nonempty: for example, two distinct nonexistent IDs with kitchenValidated: true return valid: true. Because isBossSelectionCustomerSelectable() delegates to this result, enabling the currently blocked price would allow such an unsupported recipe to pass the selling guard; validate these IDs against BOSS_PRIMARY_FLAVORS and BOSS_FINISH_FLAVORS as is already done for finishers.
Useful? React with 👍 / 👎.
| return [ | ||
| "BOSS MODE", | ||
| `1. PRIMARY - ${selection.primaryFlavorId}`, | ||
| "2. BOSS COOK - validated re-fry profile", |
There was a problem hiding this comment.
For every completed customer preview, bossSelectionFromState() hard-codes kitchenValidated: false and then passes that selection to this renderer, which nevertheless prints validated re-fry profile. The resulting summary simultaneously says the path is not kitchen validated and describes its cook stage as validated, misleading customers about the status of arbitrary preview combinations; make this wording conditional or neutral for unvalidated selections.
Useful? React with 👍 / 👎.
| if (selection.primaryFlavorId && selection.bossFinishFlavorId && selection.primaryFlavorId === selection.bossFinishFlavorId) { | ||
| reasons.push("Primary and boss finish flavors must stay in distinct recipe positions."); | ||
| } |
There was a problem hiding this comment.
When the kitchen validates a path that applies the same flavor before and after the Boss cook stage, this equality check rejects it even though the approved architecture requires distinct roles and positions, not distinct ingredient IDs (03_approved_architecture/boss_mode/BOSS_MODE_ARCHITECTURE_PATCH_v1.md:10). The primary and finish stages already remain distinct fields in the recipe signature, and every listed finish flavor also appears in the primary pool, so this adds an unsupported restriction to otherwise valid paths.
Useful? React with 👍 / 👎.
|
Codex review |
1 participant
Current approved implementation: