Scenario 04: Recipe Refresh and Load

Why This Scenario Matters

The app no longer treats recipes as code-only demo objects. Recipes now live behind a file-backed catalog, and that matters for both realism and architecture.

This scenario teaches:

• how the recipe catalog behaves on startup and refresh
• what it means for the UI to use canonical loaded recipe state rather than a hidden local selection
• how invalid or missing files are handled safely

This is the clearest hands-on exercise for SLICE-003.

Operator Actions

1. Launch the app.
2. Go to the Recipe panel.
3. Observe the current available recipes list.
4. Click Refresh.
5. Select one of the available recipes.
6. Click Load Recipe.
7. Confirm that the loaded recipe label updates.
8. If you want a stronger exercise, add or remove a JSON file in the configured recipes folder and click Refresh again.

If you do not want to change files manually, you can still complete the scenario using only the existing recipe set and focusing on the load behavior.

Expected UI And State Changes

You should see:

• a visible list of valid file-backed recipes
• an empty-state message only if no valid recipes are available
• a selected recipe in the combo box
• a separate loaded recipe label that changes only after Load Recipe

That last distinction is important.

Selecting a catalog entry is not the same as loading it into canonical app state. The loaded recipe becomes the source of truth for future run guards.

What To Notice

Look for these subtleties:

• Refresh is available even when the app is disconnected because catalog refresh is not the same as machine control
• the combo-box selection can change without immediately changing the active runtime recipe
• the UI is designed to tolerate an empty or missing recipe folder rather than crashing
• diagnostics should capture skipped invalid files or missing-folder conditions

What To Inspect In Code After Running It

Start with:

• src/InspectionPrototype.Application/Services/WorkflowService.cs
• src/InspectionPrototype.Application/Services/AppStateExtensions.cs
• src/InspectionPrototype.Application/State/RecipeValidationResult.cs
• src/InspectionPrototype.Presentation/ViewModels/MainViewModel.cs

Then inspect the infrastructure side:

• the recipe catalog implementation under src/InspectionPrototype.Infrastructure
• the sample recipe files under docs/sample-recipes

Focus on:

• how refresh scans the source and projects only valid entries into AppState.RecipeCatalog
• how invalid files become diagnostics instead of app crashes
• why Load Recipe updates canonical loaded recipe state rather than relying on a UI-only selection

Troubleshooting Notes

• If the recipe list is empty, confirm that the configured recipes folder exists and that sample recipes have been provisioned.
• If you add a malformed JSON file, expect it to be skipped rather than shown as selectable.
• If the combo-box changes but the loaded recipe label does not, that is correct until you click Load Recipe.

Related Lessons And Specs

• SLICE-003: JSON Recipe File Management
• 14. Architecture Trade-offs in .NET - Real World
• 13. Testability in .NET Systems - Real World
• 06. Recipe in Industrial Machines
• 11. End-to-End Machine Architecture

Diagram Brief

• Title: Recipe catalog refresh and load
• Purpose: Show the difference between catalog discovery and loaded runtime recipe state
• Audience: newcomer learning file-backed application boundaries
• Nodes: Operator, MainWindow, MainViewModel, WorkflowService, RecipeCatalog, AppStateStore, Diagnostics Timeline
• Edges: refresh scans files and populates catalog; load promotes one validated entry into the currently loaded recipe; invalid files create diagnostics entries
• Groups: Refresh path, Load path
• Caption: The recipe catalog is an external source; the loaded recipe is the canonical runtime selection
• Destination file path: docs/diagrams/source/scenario-04-recipe-refresh-and-load.drawio