feat: display nutrition data from metadata

[romainhild]

Goal

Display nutrition information stored in .cook recipe metadata in the web UI, when available. The info are in a collapsible section between the metadata pill and the recipe steps.
Two storage formats exist: flat top-level keys (hand-authored) and a nested nutrition: mapping (from imported recipes).
Display only if at least one information is available.
Display the metadata as-is, no checks, no scalings, no fetching data.

Scope

• No changes to cooklang-rs — nutrition is not a StdKey; we read it from the raw metadata map
• No changes to the CLI recipe command output — this is UI-only
• No per-serving scaling of nutrition values — values are displayed as stored
• Both builder instances in builders.rs updated for consistency

Out of scope

• Nutrition per-serving math when scaling
• Editing nutrition from the UI
• CLI text/JSON output of nutrition

Specs and implementation plans have been added in docs/

Disclaimer: The implementation has been done using Claude Code. I made the designs decisions and have reviewed the code.

[claude]

Review: feat: display nutrition data from metadata

Good implementation overall — the scope is well-controlled (UI-only, no parser/CLI changes), both storage formats are supported, and i18n is handled across all 7 locales. A few things worth addressing:

---

Issue 1: docs/superpowers/ files should not be committed

The two files added under docs/superpowers/plans/ and docs/superpowers/specs/ are internal AI tooling artifacts (implementation plans and design docs for agentic workers). They reference "superpowers:subagent-driven-development" and contain task tracking checkboxes — these are development-process artifacts, not user or contributor documentation.

Consider removing them from this PR, or extracting just the human-readable design rationale into a normal doc without the agent-specific scaffolding.

---

Issue 2: Key matching is case-sensitive

Both is_nutrition_key and the get(key) calls in extract_nutrition do exact-match lookups. A recipe with Calories: 250 or FAT: 10g will not match — those entries will leak into the generic custom metadata list instead of the nutrition section.

Suggested fix in is_nutrition_key:

fn is_nutrition_key(key: &str) -> bool {
    let lower = key.to_lowercase();
    NUTRITION_KEYS.iter().any(|&k| k == lower)
}

The lookup closures in extract_nutrition should similarly normalize before matching.

---

Issue 3: Code duplication in extract_nutrition

The nested-map and flat-key paths build an identical NutritionData struct with the same 9 fields and the same has_data check. A shared helper would keep future field additions to one place:

fn build_nutrition_data(get: impl Fn(&str) -> Option<String>) -> Option<NutritionData> {
    let data = NutritionData {
        calories: get("calories"),
        // ... all fields ...
    };
    let has_data = data.calories.is_some() || /* ... */;
    if has_data { Some(data) } else { None }
}

Then extract_nutrition calls it twice: once with a closure over the nested map, once over the flat metadata.

---

Minor: Nutrition is hidden from print view

The print:hidden class on the <details> element means users who print a recipe won't see the nutrition section. This may be intentional (keeping print layout clean), but worth a second look — many users print recipes specifically for meal planning where nutrition matters.

---

What's working well

• Option<NutritionData> correctly hides the section when no data is present
• Filtering nutrition keys from custom_metadata prevents double-display
• The collapsible <details>/<summary> approach keeps the recipe view clean
• Both the nested (nutrition: map from importer) and flat (hand-authored keys) formats are supported
• i18n is complete across all 7 locale files

The case-sensitivity issue (Issue 2) is the most likely to cause user-visible bugs and should be addressed before merging. The docs cleanup (Issue 1) and deduplication (Issue 3) are lower priority.

[crspybits]

Two initial thoughts:

1. I believe this is an end-user feature. Do some end-user docs need to be added?
2. There are a few places where there is redundancy/duplication in the code. I've called out one specific example. Happy to help with this and/or give other places where I see this. Claude can help with this too.

[crspybits]

This block of code (computing has_data) is duplicated below. If it was me writing this, I'd instead add something like the following, perhaps in templates.rs

impl NutritionData {
    pub fn has_data(&self) -> bool {
        self.calories.is_some()
            || self.protein.is_some()
            || self.fat.is_some()
            || self.saturated_fat.is_some()
            || self.carbohydrates.is_some()
            || self.fiber.is_some()
            || self.sugar.is_some()
            || self.sodium.is_some()
            || self.serving_size.is_some()
    }
}

and call that twice.