LCN Wafer Inspection

Appearance

SLICE-001: First Strong Vertical Slice ​

Goal ​

Deliver the first end-to-end vertical slice of the workstation so an operator can connect to the simulated machine, load a seeded recipe, home the stage, run an inspection, stop or abort it, inject a critical fault, and review one terminal run summary.

This slice should prove that the architecture, runtime model, and docs workflow are viable before the project expands into richer diagnostics, persistence, or more realistic simulation.

Requirements Coverage ​

This slice implements the first-slice parts of these requirement areas:

  • Section 6.7 Core Runtime Objects
  • Section 6.8 Canonical App State Model
  • Section 7.2 Machine Connection
  • Section 7.3 Recipe Loading
  • Section 7.4 Motion and Homing
  • Section 7.5 Inspection Workflow
  • Section 7.6 Telemetry Streaming
  • Section 7.7 Frame Streaming
  • Section 7.8 Fake Defect Detection
  • Section 7.9 Alarms and Faults
  • Section 7.10 Stop and Abort
  • Section 7.11 Logging and Diagnostics
  • Section 7.12 Run Summary
  • Section 8 User Interface Requirements
  • Section 9.2.1 Project Dependency Rules
  • Section 9.5 App State Management
  • Section 9.6 Streaming Pipelines
  • Section 9.10 Testability
  • Section 12 Workflow Requirements
  • Section 13 Acceptance Characteristics of the First Strong Vertical Slice

In Scope ​

  • WPF application shell with one main operator surface
  • central canonical app state owned by the application layer
  • simulated machine connection with delay and visible connection failure behavior
  • seeded recipe loading with at least one recipe containing at least 3 ordered scan points
  • motion homing and time-based moves between scan points
  • explicit workflow states and terminal outcomes
  • bounded telemetry and preview frame pipelines
  • fake defect generation associated with the current run
  • stop, abort, critical fault, acknowledgement, and recovery behavior
  • minimal diagnostics surface embedded in the main UI or a docked panel
  • exactly one run summary for each terminal run outcome
  • automated tests for guards, terminal behavior, critical fault behavior, and bounded streaming policy

Out of Scope ​

  • JSON recipe loading
  • dedicated multi-page diagnostics workspace
  • persistent storage beyond in-memory state
  • advanced image processing
  • advanced simulator profiles
  • auto-home on start
  • polished industrial styling

Canonical Contracts Used In This Slice ​

The slice must implement and use the minimum contracts named in the requirements:

  • Recipe
  • ScanPoint
  • Frame
  • InspectionResult
  • Alarm
  • RunSummary
  • canonical AppState

The slice may add supporting types such as command results or diagnostics entry records, but it must not replace the shared contract language established by the requirements.

User Journey ​

The baseline demo path for this slice is:

  1. Launch the app.
  2. Observe disconnected initial state and disabled commands other than Connect.
  3. Connect to the simulated machine.
  4. Load a seeded recipe.
  5. Home the stage.
  6. Start the run.
  7. Observe progress, stage position, telemetry, preview updates, and defect count changes during execution.
  8. End the run through normal completion, Stop, Abort, or a critical fault.
  9. Review the terminal run summary and diagnostics.

Runtime Behavior ​

Initial State ​

On launch, the canonical app state must represent:

  • disconnected machine
  • no active run
  • no loaded run summary
  • no active homing or motion
  • command availability derived from the initial state

Only commands valid for that initial state may be enabled.

Connection ​

Connection must be an application-layer operation that transitions state through:

Disconnected -> Connecting -> Connected

If connection fails, the system must:

  • return to Disconnected
  • record a diagnostics entry
  • surface the failure in a visible operator-facing way

Recipe Loading ​

Recipe loading for this slice uses in-memory seeded data only.

The application must:

  • expose at least one seeded recipe with at least 3 ordered scan points
  • show the currently loaded recipe in the UI
  • associate the selected recipe with the next run

Homing ​

The stage must support an explicit homing step before a run can begin.

For this slice:

  • Start is not valid until homing succeeds
  • homing transitions through workflow or motion homing state visibly
  • stage position updates over time rather than jumping instantly

Run Execution ​

From valid preconditions, the nominal workflow is:

Idle or Ready -> Preparing -> Running -> Completed

During the run, the application must:

  • visit recipe scan points in order
  • update progress after each completed scan point or safe step boundary
  • emit telemetry continuously while active
  • emit preview frames while streaming is active
  • generate simple inspection results and update defect counts

Streaming Policy ​

The slice must use bounded pipelines for telemetry and preview frames.

Required first-slice policy:

  • telemetry defaults to about 5 Hz
  • preview frames default to about 2 fps
  • telemetry may coalesce to latest value when consumers lag
  • preview frames should prefer recent frames over stale backlog when consumers lag
  • dropped or coalesced items must be measurable through logs, diagnostics, or counters

Stop ​

Stop means graceful operator-requested termination.

For this slice:

  • Stop is valid only while the workflow is Preparing or Running
  • no new scan point may begin after the stop request is accepted
  • the system may finish the current safe step boundary
  • the terminal workflow state is Stopped
  • the run summary must record that the run ended by stop rather than completion

Abort ​

Abort means immediate operator-requested interruption.

For this slice:

  • Abort is valid while the workflow is Preparing, Homing, Running, or Stopping
  • in-flight work must receive cancellation immediately
  • queued frame or processing work for the interrupted run may be discarded
  • the terminal workflow state is Aborted

Critical Faults And Recovery ​

The slice must support at least one injected critical fault path.

Minimum required behavior:

  • a critical fault during active work transitions the workflow to Faulted
  • active critical faults block Start, Home, and motion commands
  • acknowledgement records operator awareness but does not clear the unsafe condition
  • recovery requires both condition clearance and explicit operator action
  • fault recovery must create diagnostics entries and preserve the faulted run history

Run Summary ​

Each terminal run outcome must create exactly one terminal run summary with:

  • RunId
  • recipe name
  • start and end timestamps
  • terminal status
  • defect count
  • major alarms or failures
  • completion reason where useful

Terminal statuses allowed in this slice are:

  • Completed
  • Stopped
  • Aborted
  • Faulted

UI Expectations ​

The slice may keep the UI simple, but it must show:

  • connection status
  • current machine or workflow state
  • current recipe
  • stage position
  • run progress
  • defect count
  • active alarms
  • preview area
  • diagnostics surface
  • commands for connect, home, start, stop, abort, acknowledge, and recover or reset

Layer Boundaries ​

This slice must preserve the project boundaries named in the requirements:

  • App composes startup and dependency injection
  • Presentation projects the central app state into the UI
  • Application owns orchestration, command handling, and state transitions
  • Infrastructure owns simulator and vendor-like SDK behavior
  • Domain owns core machine and run concepts

The UI must not orchestrate the workflow or call simulator internals directly.

Acceptance Criteria ​

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

  1. The app launches into a disconnected initial state with command availability derived from canonical app state.
  2. A successful connection transitions through Disconnected -> Connecting -> Connected.
  3. A failed connection attempt returns to Disconnected and leaves visible diagnostics.
  4. Loading a seeded recipe updates the UI and stores an ordered scan plan with at least 3 scan points.
  5. Homing visibly transitions through homing state and must complete before Start becomes available.
  6. Starting from valid preconditions transitions through Preparing -> Running and visits scan points in order.
  7. The operator can observe stage position, telemetry, preview updates, and defect count changes during the run.
  8. Stop produces terminal state Stopped and prevents new scan points from beginning after the request is accepted.
  9. Abort produces terminal state Aborted without waiting for the remainder of the scan plan.
  10. Injecting a critical fault produces an active alarm, transitions the workflow to Faulted, blocks invalid commands, and preserves a run summary if the run was active.
  11. Recovery requires explicit operator action after the unsafe condition is cleared.
  12. Every terminal run outcome stores exactly one terminal run summary with status Completed, Stopped, Aborted, or Faulted.

Verification Notes ​

The implementation task for this spec must include automated verification for:

  • start precondition guards
  • stop versus abort terminal behavior
  • critical fault to Faulted transition
  • recovery guard behavior
  • bounded or coalesced streaming behavior at the application boundary

Docs-first project memory for AI-assisted implementation.

LCN Wafer Inspection Prototype