Skip to content

SLICE-003: JSON Recipe File Management

Goal

Move recipe loading out of hard-coded seed data and into external JSON files so operators and developers can manage realistic recipe inputs without changing code.

Why This Slice

After persistent run history, the next most valuable realism upgrade is to make recipes behave like actual machine inputs instead of code-defined demo data.

This slice improves the prototype without reopening core workflow semantics:

  • recipes become external artifacts
  • validation behavior becomes explicit
  • the app gains a realistic file-backed input boundary

Requirements Coverage

This slice extends or activates these requirement areas:

  • Section 7.3 Recipe Loading
  • Section 7.11 Logging and Diagnostics
  • Section 8.1 Main Operator Screen
  • Section 8.2 Diagnostics View
  • Section 9.3 Architectural Boundaries
  • Section 9.5 App State Management
  • Section 9.10 Testability
  • Section 10.3 Observability
  • Section 10.4 Maintainability
  • Section 16 Future Expansion Areas

In Scope

  • load available recipes from JSON files in a configurable folder
  • provide an application-level recipe catalog abstraction
  • validate recipe file structure before showing a recipe as available
  • allow the operator to refresh the recipe list without restarting the app
  • load a validated file-backed recipe into canonical app state
  • surface missing folder, invalid JSON, and validation failures through diagnostics or logs
  • keep recipe loading behavior testable without launching the full UI

Out of Scope

  • in-app recipe creation or editing
  • saving recipes back to disk from the UI
  • schema version migration
  • recipe approval workflow
  • hot file watching

Runtime Behavior

Recipe Catalog

The system must treat recipes as external JSON files discovered from a configured folder.

For the first file-backed recipe slice:

  • each valid JSON file represents one recipe
  • the catalog shown in the UI should be deterministic and predictable
  • only validated recipes may be loaded into canonical app state

Startup Scan

On application startup:

  • the configured recipe folder is scanned
  • valid recipes become available to the operator
  • missing or empty folders must not crash app startup
  • missing folders or unreadable files must produce diagnostics or logs

Refresh Behavior

The operator must be able to refresh the recipe catalog without restarting the app.

After a refresh:

  • newly added valid files appear in the available recipe list
  • removed or invalid files no longer appear as available recipes
  • the currently loaded recipe may remain in app state until the operator chooses another recipe

Validation Rules

At minimum, a valid recipe must provide:

  • a recipe id
  • a non-empty recipe name
  • an ordered non-empty scan point list
  • scan points with numeric X and Y

Validation failures should be visible through diagnostics or logs and should not crash the app.

Load Semantics

When the operator loads a valid recipe:

  • canonical app state becomes the source of truth for the currently loaded recipe
  • existing start and command guard behavior must continue to use AppState.LoadedRecipe
  • no separate hidden recipe state may exist only inside the UI

UI Expectations

The UI for this slice should add or refine:

  • a visible list of available file-backed recipes
  • an explicit refresh action
  • enough metadata to distinguish recipes at a glance
  • a clear empty state when no valid recipe files are available

The UI does not need a full recipe editor for this slice.

Layer Boundaries

This slice must preserve the same architecture principles as earlier slices:

  • application defines the recipe catalog abstraction and load behavior
  • infrastructure owns file access, JSON parsing, and validation implementation
  • presentation projects catalog state from canonical app state
  • UI does not read recipe files directly

Acceptance Criteria

This slice is satisfied only if all of the following are true:

  1. On startup, valid recipe files from the configured folder appear in the available recipe list when such files exist.
  2. When the configured recipe folder is missing or empty, the app starts normally and shows an empty recipe catalog state.
  3. Invalid or unreadable recipe files are skipped and surfaced through diagnostics or logs.
  4. The operator can refresh the recipe catalog and see added or removed recipe files reflected without restarting the app.
  5. Loading a valid recipe from the catalog updates the current loaded recipe in canonical app state.
  6. Start and command guard semantics continue to depend on canonical loaded recipe state rather than hidden UI-only state.
  7. Core catalog scanning, validation, and load behavior are testable without launching the full UI.

Verification Notes

The implementation task for this spec must include verification for:

  • startup scan with valid recipe files
  • missing or empty folder behavior
  • invalid JSON and validation failure handling
  • refresh behavior after file set changes
  • successful load of a valid file-backed recipe into app state

Docs-first project memory for AI-assisted implementation.