# PDR 001: Keep planning and shopping independent

- HTML version: https://robbiepalmer.me/projects/recipe-site/pdrs/001-independent-planning-and-shopping
- Project: Recipe Site
- Status: Accepted
- Opened: 2026-10-15
- Decided: 2026-10-15

## Context

Planning answers what a household intends to cook. Shopping answers what it
needs to buy now. The two activities share data, but people often start one
without the other. A shopper may open an existing list in a shop, while a cook
may plan one meal without preparing a full week or generating shopping items.

Treating Shopping as a step inside Planning makes the list harder to reach and
implies that every list starts with a meal plan. Treating Planning as a view of
Shopping creates the opposite problem.

## Decision

Plan and Shop are separate top-level destinations with stable routes:
`/recipes/planning` and `/recipes/shopping`. Neither route redirects to the
other when its data is empty. Planning starts with the smallest useful action,
"Plan one meal." Shopping opens the active household list.

The destinations share household state and link to each other when the next
action is useful. Adding a planned meal may add its missing ingredients to the
list, but it does not make Shopping part of the planning flow. Recipe pages,
Kitchen, and notifications may link directly to either destination.

A populated Plan uses a compact weekly agenda rather than a fixed
day-by-meal grid. Days with meals show their recipes, meal labels, servings,
and leftover relationships. Empty days collapse to small "plan meal" actions.
Recipe ideas stay nearby, and choosing Plan asks for a day before adding a meal
to the agenda. There is no separate add-then-place step. This keeps the plan
scannable without turning blank breakfast and lunch slots into most of the
interface.

Desktop navigation shows Recipes, Discover, Plan, Shop, Kitchen, and Log.
Mobile navigation keeps Recipes, Plan, Shop, and Kitchen one tap away and puts
Discover, Cooking log, Profile, and Settings in a labelled More sheet.
Notifications remain in the header. The short labels are "Plan" and "Shop";
page headings use "Meal plan" and "Shopping list."

Protected deep links keep their requested destination through sign-in. Route
changes use browser history, while opening or closing a menu does not.

## Consequences

Planning and Shopping own their URLs, empty and loading states, analytics, and
active navigation states. Browser Back returns to the previous destination.
The Shop badge counts unticked list items. Notification counts remain separate.

The agenda optimises for reviewing and changing meals that exist. It gives up
the uniform geometry of a calendar grid, so moving a meal between days needs an
explicit action instead of drag-and-drop between cells. Empty-state planning
still begins with one meal and grows into the same agenda.

The mobile More sheet adds one tap to less frequent destinations. It avoids a
scrolling tab bar, keeps labels readable, and leaves both household tasks in the
primary navigation.

## Evaluation

The desktop and mobile mid-fidelity prototypes cover six checks:

* Open Shopping directly and see the list without a planning prompt.
* Plan one meal without setting up a week.
* Scan a populated week without reading past empty meal slots.
* Plan or move a meal from the agenda without switching to a separate daily view.
* Return to Recipes in one action and use Browser Back to resume.
* Find each less frequent destination by its full label in More.

Revisit the mobile grouping if observed navigation shows that Discover or
Cooking log is used more often than one of the four primary destinations.

## Related records

- Project: [Recipe Site](https://robbiepalmer.me/projects/recipe-site.md)

---

Markdown index of this site: https://robbiepalmer.me/llms.txt