Grill with Docs（質問しながら文書化）

No GLOSSARY.md exists yet, so I'll create one when the first term is settled. These are the questions with no prerequisites. The rest of the design depends on your answers to them.

❓ Q1 - What is a "meal plan"?: Is a Meal Plan a persistent object a user creates, names, and keeps (for example "Week of Oct 14"), or just the user's single current week view that gets overwritten? Is it tied to a calendar week (dated) or to a generic Mon–Sun template that can be reused?

➡️ Make it a persistent, named object tied to a specific calendar week (it has a start date). Users can duplicate a past plan into a new week. That covers the template use case without a second concept.

❓ Q2 - How many meals per day?: "Pick recipes for each day" is ambiguous. Does each day hold one recipe, or several, such as breakfast, lunch, dinner, and snack slots? Can one slot hold multiple recipes, such as a main and a side?

➡️ Each day has named meal slots (breakfast, lunch, dinner, snack). A slot can hold multiple recipes, and any slot can be left empty.

❓ Q3 - Which recipes can be planned?: Can users plan only recipes from the site (their own, other users' public ones, and saved ones), or also free-text entries like "leftovers" or "eating out"? What happens to a plan when the recipe's author edits or deletes the recipe?

➡️ Only site recipes, plus a free-text "note" entry that adds nothing to the shopping list. When a recipe is edited, the plan reflects the latest version. When a recipe is deleted or made private, the plan keeps a tombstone entry, and the shopping list excludes it with a visible warning.

❓ Q4 - Servings: Recipes have a fixed yield, such as "serves 4". Can the user set a servings count per planned entry (scaling the ingredient quantities), or is every entry one cooking of the recipe as written?

➡️ Yes. Each planned entry has its own servings count, which defaults to the recipe's yield. Ingredient quantities are scaled proportionally.

❓ Q5 - Shopping list: derived or stored?: Is the Shopping List always computed live from the plan, or is it a separate object created from the plan? If it's separate, it can hold checked-off items and manual additions. If it's live, those need somewhere else to live.

➡️ Make it a separate object generated from the plan. It stores check-off state and manual extra items. Regenerating is an explicit user action that preserves checked-off and manual items where it can.

❓ Q6 - Ownership and sharing: Is a meal plan private to its owner, or can it be shared or published, for example a household co-editing one or a public "my week of meals" post? This is a recipe-sharing site, so sharing is likely to come up.

➡️ Private to the owner in v1. Others can copy a plan only via an explicit share link that creates their own copy. There is no co-editing.

I'll record the terms (Meal Plan, Meal Slot, Planned Entry, Shopping List) in GLOSSARY.md as you settle them. Ingredient merging, unit conversion, and pantry handling come in the next round, once Q4 and Q5 are settled.