No, there isn't such a word.
How planning is done
Such a word doesn't exist, and neither does the "master plan" you are envisioning. What exists instead is a menu, plus recipes, plus conventions or ad-hoc decisions.
First think of a situation where a caterer works for a big event, there is the need to orchestrate many people preparing, cooking and serving. These people are all professionals, and don't really need much information to get their jobs done.
- The single most important thing to be planned and written down is the menu. It is just a list of dish names written in the order of serving. But really, not even the order is needed, since it is determined by convention.
- A recipe will be available somewhere for each menu item, but for a high stakes event with professional cooks, they will probably not risk using too many dishes that are new to the cooks, so the cooks will likely know many of the dishes by heart and consult the recipe for these only cursory or not at all. Recipes may also be written down only as a list of ingredients, assuming that the list plus the name of the dish plus the cook's knowledge is sufficient to prepare the meal properly.
- Somebody will have to take care of the logistics and create a shopping list (it probably has some other name in a large commercial operation), which will not contain all items needed, only the ones which are not currently available in storage. And that one will be used by those who are buying the food, not by the cooks or servers.
- A prep plan as moscafj suggested might be made, saying what is to be made in which order, but this is entirely optional, and is not the word you are looking for, since it is a simple timeline which doesn't encompass most of the information you asked for, it is just one further element. Cooks are sufficiently self-organizing to be able to get the meal done with everybody doing their own timeline in their head or on personal notes without the need for documenting it.
- As for serving, most of it is also determined by convention. On formal occasions, there may be a seating plan, but it is not done by the kitchen. Decoration is also part of event management, not catering. I imagine that in some rare occasions, e.g. a formal dinner at a private mansion, somebody will tell the caterer "please serve in the Villeroy Grey Pearl china, not in the Waterford" but once a server is equipped with a set of china, glassware and cutlery, there is no need to plan anything further, they know how to serve.
Other situations will involve people who are not seasoned professionals and thus don't have all the implicit knowledge, but these situatins also usually tend to be less formal, involve less cooking (fewer dishes, fewer guests, more parts such as bread being bought instead of made on the spot), and there are fewer people doing the cooking and serving, so less need to orchestrate a team. All three factors reduce the need of explicit planning. At the "easy" end of the whole thing is somebody throwing together a weekday dinner going with whatever is in the fridge, starting without a plan and making decisions while cooking. In the intermediate stages, e.g. 2-3 housewives from an extended family preparing a festive meal for a family celebration, people may do more explicit planning, but then they will also use some variation of the items listed above for the formal catering situation.
Even when these items (menu, recipes, shopping list, prep plan) are explicitely written down, nobody perceives the combination of them as one cohesive "thing", so it doesn't have a name.
Your information architecture
You give very little information about what your app is supposed to do, so I cannot give more than the most general advice. If you really need a single "entry point" for the cook/caterer, it probably have to be the menu. Since all other planning items depend on the menu (OK, the recipes don't strictly follow the menu, but the selection out of the pool of possible recipes does), it does have a bit of a "root of all things" role. So you could give the menu a more prominent role in the UI and have the user first visit the menu and from there navigate to each recipe, and possibly have the shopping list for the menu and the prep plan for the menu. Another option is to call the unifying concept an "event" and have the menu, the shopping list and the prep plan belong to the event entity, and link the recipes from the menu. I am pretty sure both will be intuitive for somebody organizing the cooking for an event.
Be sure to know that your users need these items before you invest the resources in programming them. The ability to jot down a menu will be central, but users may not care to enter a recipe for each menu item, since for many items, they are accustomed to doing them from either implicit knowledge or some existing storage system like a cherished grandma's dead-tree notebook. If the recipes are available, it can be useful to calculate a shopping list out of them, but make sure that you can deal properly with different units and with ad-hoc changes the user is making for the event ("this time, I want to make my aunt's panna cotta with strawberries instead of blueberries"). A space to enter an optional prep plan may be used under some circumstances, but find out from your users if they care for it. If they do, don't try to calculate it from information in the recipes, there are many implicit dependencies you won't be able to really place into your software. Just give them the blank space or maybe some minimal structure like time slots.
