Feature Request: Recipes as first class citizen? #516

@bsnelson I'm not completely up to date with your definition of recipe.

We have the Workflow data object that encompasses your current profile, context like beans, dose, target yield and all the data for flush, steam settings and hot water settings.
Workflow context has a free-form extras field that can be used to attach any specific data. And there is a 'description' field.

if you're using AI, the accompanying skill in repo root .agents/ folder should be able to tell you what you can do with workflows today.

It should also help you analyse your shots etc as it knows how to pull all the shot data, update it, and more.

Looking forward to hearing more

My definition of a recipe: All of the bits and bobs needed to create a drink, So: Bean, BeanBatch, Grinder, Profile at a minimum. I think Decenza adds some stuff with Water/Steam etc. - I'll confess, I manage all of that myself, so I haven't put a lot of thought into how to manage those pieces in a recipe. Basically, what NSX does today is almost exactly what I need, but it's got some opportunities with sync across devices and other things, which I'm working with him on.

The catch with Workflow in reaprime (all of this, per Claude, AI may make mistakes ;) ) is that it's intentionally only a single entity, not a full multi-row table. It seems meant to be a "this is what's loaded right now, and persists across restarts" situation. Claude says the pieces are there, but requires new table/DAO/REST surface/UI, to say nothing of migration, potential breakage for existing skins etc.

Again, I'm happy to workup a POC if you're at all interested, but I know this is a bigger one than my other PRs and issues, it's almost like a 2.x, and we're not even on 1.x :)

Side note about AI: My day job is software developer (primarily backend) and I've used AI extensively at work when doing UI work, as I - don't understand it :) It's been great, and I use it for home projects and other stuff, but... I've not really wanted or needed it to help me with making coffee on a daily basis. I've asked it for help with roast profiles on my Kaffelogic Nano 7 (with some success), but mostly, it's not something I use tactically for everyday coffee. But I definitely see where some do/would, and Decenza is clearly way down the rabbithole with it.

Thanks, that makes the intended use much clearer.

I agree that a Workflow is already very close to what both of us mean by a recipe: it contains the profile, bean batch, grinder, dose and yield targets, steam settings, hot-water settings, rinse settings and any additional context needed to reproduce a drink.

One useful addition could be optional instructions describing how to complete the drink outside the machine-controlled profile. For example:

• puck preparation
• cup preparation
• when and how to add milk or water
• stirring or swirling
• serving instructions
• any other manual step before, during or after extraction

However, I would not add typed instruction fields to the core WorkflowContext yet.

Instead, I would suggest forking NSX and using context.extras to prototype the instruction format. For example:

{
 "context": {
 "extras": {
 "nsx": {
 "instructions": [
 {
 "phase": "before",
 "title": "Prepare the puck",
 "description": "RDT, grind, WDT and tamp."
 },
 {
 "phase": "after",
 "title": "Finish the drink",
 "description": "Add steamed milk and swirl before serving."
 }
 ]
 }
 }
 }
}

That exact structure is only an example. The point of the experiment would be to discover which fields are actually useful.

Perhaps instructions only need a title and description. Perhaps skins will need phases, timing, quantities, equipment references, optional steps, completion state or conditional steps. I would rather learn that through a real implementation than prematurely establish a core schema which we later find too limited or too opinionated.

Regarding storage, I am also not convinced that workflows need a separate CRUD table.

The active workflow is the mutable working copy, but a complete copy of the workflow is also embedded in every recorded shot. That is important: once a drink has been made, the exact profile, coffee context, grinder context, targets, machine operations and extension data used for it already exist together in the shot record.

Shot history therefore already acts as a historical workflow store.

A separate workflow API surface could still be useful without introducing a new table. It could eventually support operations such as:

• retrieving the active workflow
• applying or importing a workflow
• retrieving the workflow embedded in a shot
• repeating a previous shot’s workflow
• finding recent workflows in shot history
• identifying distinct workflows from previous shots
• exporting or sharing a workflow

We should first establish which of these operations skins actually need.

A dedicated workflow table becomes more compelling if we later need independently named workflows which have never produced a shot, favourites, manual ordering, archival state, sharing metadata or cross-device synchronisation. We do not necessarily need to commit to that persistence model as part of the initial experiment.

I think there is also an important architectural difference between Decenza and Rea here.

Decenza is effectively one complete application experience. Jeff controls its direction and can define exactly what a recipe means, which fields it contains and how every screen interprets them.

Rea is intended to be a platform. Core should expose the most important shared concepts and reliable machine operations, while allowing skins and plugins to experiment and express very different levels of complexity when making a drink.

One skin may only want a profile, bean and grinder picker. Another may add guided puck preparation, water chemistry, equipment selection, detailed milk recipes or post-shot tasting feedback. Both should be able to use the same platform without core enforcing one complete interpretation of a "recipe."

NSX is a very good recipe-oriented view into Rea, but it is still only one view into the platform. Workflow-skin may be another interesting candidate, and other skin developers may have different requirements again.

My suggested approach would therefore be:

1. Fork NSX and prototype drink instructions using a namespaced value under context.extras.
2. Use the existing workflow embedded in every shot as the historical record.
3. Add API operations only where the experiment identifies a concrete need.
4. Test the format through actual daily use.
5. Share the result with Workflow-skin and other skin developers.
6. Promote only broadly useful and agreed concepts into typed core fields.

This allows us to explore the idea without a large migration, without breaking existing skins and without immediately creating a parallel Decenza-style Recipe entity.

So yes, I am interested in a POC. I would frame it as an NSX experiment built on the existing Workflow and context.extras, with a possible shared schema emerging later if other skins find it useful.

additionally, for testing and installing preview skins, there are a lot of api options, if you check rest_v1.yaml under WebUI section.

In case you would want to share the skin fork with others for testing :)

@bsnelson I decided to move this idea to a discussion, so that we're free to figure out the details. I forgot to mention that.

Did you attempt a NSX fork with the suggestions above?