KitchenFlow - Raw AI Exchange Transcript

Full conversation between James and AI agent during spec generation on 2026-07-25

Initial Prompt

I’m going to try to build a gtk4 libadwaita recipe management app that is node based. I am going to try to walk users through the full process of building with opencode from within Gnome Builder. I want it to be a full end to end tutorial of how to build an app that the user has thought of live with the audience from the ground up. As such, I want to show them the first step is coming up with a detailed product specification for their application. I would like to work with you to build mine out. I want to brainstorm a detailed product specification. The inspiration is systems like comfy ui or n8n but instead focused on recipe management for chefs of all types. As in, using the comfyui visual cues for how you should cook a meal in the most efficient time possible given a recipe and make it repeatably successful for any user regardless of their experience. It tells the user to preheat to a given temperature at the ideal time to ensure the oven is ready when some other item that needs preparing is done for example. I would like to mimic that general node based flow of comfyui and n8n, but be optimized for visually representing what needs to be done in a kitchen to complete the recipe including staggard start times for different recipes, and a timer built into the recipe management system. This system could then be expanded via API to help restaurants manage their kitchens for example based upon established recipes for easily repeatable results, just like a regular user could. Can you help me plan this application including planning milestones what goals I should accomplish first and what other factors I should consider. I want to user gnome builder as my ide and flatpak builder as the general packaging system. For underlying language I am most comfortable with python, but am open to other recommendations. Right now I just want to build a general plan for this app that will be used to build an app specification, but I want to fill out the idea with you first. Can you interview me and help me structure the plan?

AI Response: 15 Clarifying Questions

I’ll help you structure a comprehensive product specification. Let me ask targeted questions to flesh out the core concept:

Core Functionality

1. Node Types & Relationships

• What specific node categories do you envision? Examples:
  • Ingredient prep (chop onions, marinate meat)
  • Cooking actions (sauté, bake, boil)
  • Equipment (oven, stovetop, blender)
  • Timing/synchronization (wait, timer, trigger)
  • Conditionals (if internal temp > X, then Y)
• Should nodes have input/output ports like ComfyUI (data flow) or be more like task dependencies (n8n workflow)?

2. Recipe Import/Creation

• How do users get recipes into the system?
  • Manual node-by-node construction?
  • Import from text URLs/recipes?
  • AI-assisted conversion from natural language?
  • Template library?

3. Real-time Execution

• During cooking mode, what does the UI show?
  • Active timer per node?
  • Visual progress indicators?
  • Next-step highlighting?
  • Pause/resume/recovery from interruptions?

Technical Architecture

4. Data Model

• Recipe as directed acyclic graph (DAG) of nodes?
• How to represent parallel vs sequential steps?
• Should there be “group” nodes (collapse multiple steps)?

5. Language/Stack Decision

• Python + GTK4/libadwaita is solid for rapid development
• Node graph rendering: gtk4-node-editor (existing), AdwGraph, or custom Canvas?
• Real-time timers: asyncio event loop vs threading?
• Persistence: JSON/YAML recipe format? SQLite for user data?

6. Flatpak Considerations

• Does the app need file system access (import/export recipes)?
• Timer notifications while app is minimized? (requires portal permissions)
• Future: camera/microphone for AI cooking assistance?

User Experience

7. Target User Tiers

• Home cooks: Simplified view, guided mode, error tolerance
• Professional chefs: Full node editor, batch cooking, scaling
• Restaurants: Multi-station coordination, inventory integration

8. Visual Design

• ComfyUI-style dark node graph (technical feel) or warmer kitchen aesthetic?
• Color coding by task type (prep=blue, cooking=orange, resting=green)?
• Animated connections showing data/ingredient flow?

9. Mobile/Tablet

• Kitchen use implies tablets/phones near cooking area
• Should there be a companion mobile view (simplified timer UI)?
• Voice commands? (hands-free operation)

Advanced Features

10. Timing Intelligence

• Should the system automatically calculate optimal start times?
  • Input: recipe steps with durations
  • Output: “Start oven at 6:15 PM, prep vegetables at 6:30 PM”
• Handle variable durations (e.g., “cook until golden” → user feedback loop)?

11. Scaling & Adaptation

• Portion scaling: automatically adjust ingredient quantities?
• Equipment constraints: “you only have 1 oven, here’s how to sequence 3 dishes”?

12. API/Restaurant Expansion

• Multi-recipe coordination (dinner service scheduling)?
• Inventory tracking integration?
• Kitchen display system (KDS) mode for professional use?

Constraints & Milestones

13. MVP Scope What’s the smallest version that demonstrates the core value?

• Option A: Static recipe graph viewer with timers (no editing)
• Option B: Full node editor but no smart scheduling
• Option C: Template-based recipes with manual timing adjustments

14. Content Strategy

• Where do initial recipe templates come from?
• Community contribution model?
• Copyright considerations for importing existing recipes?

15. Differentiation What makes this unique vs existing recipe apps (Paprika, ChefTap, etc.)?

• The visual node graph as primary interface?
• Intelligent scheduling as core feature?
• Professional-grade repeatability?

James’s Responses (Inline)

Response to Question 1: Node Types & Relationships

Node input and output should exist, but not be based upon super strict input, instead it should be based upon app settings and requirements for the recipe. For example, the user will have modifiable settings that allow them to set what equipment they have and details of that equipment such as how long they take to preheat (sane defaults should be set for these to avoid overcomplexity, but it should be easily modifiable by someone doing an initial setup or optimization of the app to conduct these settings changes. I think the node based representation is just a really nice way to visually represent how a recipe is effectively achieved, and something like this could be a good way to teach the user how to efficiently cook in the kitchen by following a few optimized recipes. If a user does not have the right equipment for a given recipe (e.g. can only be made in an air fryer and user doesnt have one) it should warn the user and have them be given some manual fallback options with a warning that this is not in alignment with the original recipe, but can be manually set to something that the user is comfortable with.

For the ingredients part, I like the idea of ingredients that require a certain state like onion (chopped) having an assumption they are starting with the base ingredient (the whole onion) and they can manually skip that step when conducting the recipe or disable that step if they always buy it prechopped. Either way the fundamental ingredient is onion and they then have a mandatory, but overridable step that says to chop them manually. Or, if they have a setting for a chopper, that should be an automatic option for their chopping step, which would be an action step. Your examples all generally sound good to me otherwise, time management will require those basic functions, conditionals will require those sorts of functions. I like input and output because it feels easier to learn to me, but honestly I dont understand n8n so maybe that is superior, can you help me understand the tradeoffs here? Also feel free to challenge any of these design decisions if they potentially have fundamental design issues. I would like to hear those concerns now.

Response to Question 2: Recipe Import/Creation

I think users should be able to import and export in json format. This would be easily expandable to support a registry system of json files in the future if the need ever arises and otherwise users can build them manually in the application using an editor. I think the format should be simple enough for an AI to be able to translate a recipe into a json that is compatible, in fact this will be a suggested route for users to take, but that is functionality for an AI app to produce and us to import, not a feature to build into the app itself. At least not right now.

Networking support should be a future goal, not something thats needed now. Right now simple import and export via json or build in app, later registries and libraries, etc should be considered.

Response to Question 3: Real-time Execution

I think users should see a zoomed in portion of the graph showing the steps underway including a clear and easy to hit button for any manual inputs from users (like the user says the step is done because the water is boiling, so they click an easy to see button on the activity node that says done when the step is completed.

Response to Question 4: Data Model

Yes a DAG is perfect as a representation. the steps happening in parallel should be highlighted and there should be a now underway or currently working status list that lists out the currently cooking recipe.

Response to Question 5: Language/Stack Decision

Lets use existing and the most already well supported options possible

Response to Question 6: Flatpak Considerations

yes timers should fire in the background. also filesystem access for import and export is great.

Response to Question 7: Target User Tiers

Lets initially target home cooks as that will be the bulk of users, but I would like to expand with features that make it more friendly for larger and more professional setups

Response to Question 8: Visual Design

A warmer kitchen aesthetic is definitely better. in fact there should be the ability to display recipes in a classic text based instruction format. if possible this should be generated from the graph just describing the inputs, outputs and details in written language.

Response to Question 9: Mobile/Tablet

yes to both, but this can be for future versions, lets put these in future releases.

Response to Question 10: Timing Intelligence

Yes, as much as possible it should be automatic, but if it requires manual inspection it should set a snooze timer with reasonable safe guesses for the initial time to check with a snoozable timer. the user should then

Response to Question 11: Scaling & Adaptation

This is difficult to say. I would be open to suggestions, but maybe having the system autoscale based upon the quantity that should be input up front. It should warn if they would require larger than what is in a standard kitchen and this can be a natural way to progress people into more advanced features if they end up needing to cook at higher scales.

Response to Question 12: API/Restaurant Expansion

All of this is nice, and yes, I would like to have an extensible enough base to be able to have these built as extensions in the future, but I do not want to target this in the initial milestones. I would like to build a solid enough base where features like this could be easily extended on top of the base structure in the future though if needed. There is no reason it should not be possible to scale to this demand if user needs require it.

Response to Question 13: MVP Scope

Let’s get the graph viewer right so let’s go with option A as the first milestone, the idea is to build a very testable framework for this base graph layer that will allow us to build and extend on top of this feature set reliably as long as tests are passed that validate the underlying layers. The graph should be the base structure the application operates over so let’s get this part right and build the editor after we get this first MVP operational and solid.

Response to Question 14: Content Strategy

Initial recipes will be ones I will manually input to get started. After establishing the initial functionality with recipes that will be developed in the MVP we can work on import/export functionality and json standardization for that process.

Response to Question 15: Differentiation

Open source, Linux first, free, extensible, convergent, looks good on mobile, tablet, and desktop formfactors, easy to use for simple recipes as one chef in a normal household or useful for a team to manage complex recipe workflows, its based upon simple intuitive design with a complex node based core that allows for flexible recipe design and maximizes repeatability by anyone to be able to mimic the workflows of the original chef creator.

Final Instructions to AI

I put together my responses inline with your questions, can you use this to draft the detailed plan for me. Ensure to make this development flow easy for flatpak-builder flathub distribution under tech.livingonlinux..json so it matches flathub conventions. Ensure that it will be released under the MIT license. Ensure that it follows the latest and most up to date Gnome 50 conventions and design philosophies and is convergent from the initial design. Ensure that a testing plan to ensure I can validate and continue to develop on top of the core graph structure is an essential part of the design. Your goal is to write the most detailed and comprehensive libadwaita open source recipe managemnt application that fits these design goals perfectly. It is to be designed in a way that is easy to maintain and extend, but ensures precise and modular development from the ground up. Output this all into a document called SPEC.md

AI’s Final Recommendation

Build a minimal node graph editor with 3 node types (prep, cook, wait), manual duration inputs, and a “play” mode that shows timers sequentially. Prove the UI paradigm works before adding AI scheduling or recipe import.

Answer what resonates/dissonates, and I’ll help structure this into a formal specification document.

This transcript was captured live during the spec generation process. The resulting SPEC.md is available in the main guide.