Scenario 05: Run History And Simulator Profiles

Why This Scenario Matters

This scenario ties together the last two realism upgrades:

• persisted run history from SLICE-002
• configurable simulator profiles and richer metrics from SLICE-004

It teaches a newcomer that the app is not just a one-run demo. It is a small but believable workstation with durable operational memory and configurable simulation behavior.

Operator Actions

Part A: Compare Profiles

1. Launch the app.
2. In the right-side Simulator Profile panel, note the currently active profile.
3. If the app starts on Normal, consider switching to Demo first for a more predictable connection.
4. Click Apply after selecting a profile.
5. Connect, load a recipe, home, and run one inspection to completion.

Part B: Create A Contrast Run

1. Return to an idle state.
2. Select a different simulator profile, ideally HighDefect.
3. Click Apply.
4. Run another inspection with the same recipe.
5. Compare the resulting run history rows and the Last Run Summary.

Part C: Restart Check

1. Close the app.
2. Launch it again.
3. Inspect the Run History panel before doing any new run.

Expected UI And State Changes

On Profile Change

You should see:

• the selected profile name shown clearly in the diagnostics workspace
• a diagnostics entry recording the profile change
• no silent mutation of an already running inspection

Profile changes apply only to future operations.

During Runs

You should see:

• the active run show the current profile name
• run metrics such as elapsed time, completed points, and defect breakdown update live

With HighDefect, you should usually observe a noticeably higher defect count than with Demo or Normal.

In Run History

You should see:

• newest-first ordering
• one history row per terminal run
• status, recipe, profile, start time, duration, scan-point counts, and defect breakdown

After Restart

You should see:

• previously completed runs reloaded into the history view
• Last Run Summary aligned with the newest stored run

This is the visible result of startup hydration from the file-backed run history store.

What To Inspect In Code After Running It

Start with:

• src/InspectionPrototype.Application/Services/HistoryHydrationService.cs
• src/InspectionPrototype.Application/Abstractions/IRunHistoryStore.cs
• src/InspectionPrototype.Application/Services/SimulatorProfileService.cs
• src/InspectionPrototype.Application/State/SimulatorProfile.cs
• src/InspectionPrototype.Presentation/ViewModels/MainViewModel.cs
• src/InspectionPrototype.App/appsettings.json

Focus on:

• how persisted run summaries are loaded before host startup completes
• how profile selection is loaded from configuration and projected into app state
• why profile changes affect future runs but not an in-progress active run
• how richer summary fields flow into the run history projection

Troubleshooting Notes

• If a profile change seems to have no effect, make sure you applied it while idle and then started a new run.
• If history is empty after restart, verify that at least one prior run reached a terminal state.
• If the first profile is Normal and connection fails, switch to Demo to reduce that variable during training.

Related Lessons And Specs

• SLICE-002: Persistent Run History
• SLICE-004: Operational Maturity
• 11. Background Processing in .NET - Real World
• 12. Observability in .NET Systems - Real World
• 21. High-performance .NET Systems
• 10. Motion Control Basics

Diagram Brief

• Title: Run history and simulator profiles
• Purpose: Show how profile selection affects future runs and how terminal summaries persist across restarts
• Audience: newcomer learning operational memory and simulation configuration
• Nodes: Operator, MainViewModel, SimulatorProfileService, WorkflowService, RunHistoryStore, HistoryHydrationService, AppStateStore, Run History UI
• Edges: operator selects profile; future run uses selected profile; terminal summary persists; startup hydration reloads summaries into app state and UI
• Groups: Profile selection, terminal persistence, startup hydration
• Caption: Profiles shape future runtime behavior, while persisted summaries preserve what actually happened
• Destination file path: docs/diagrams/source/scenario-05-run-history-and-profiles.drawio