Checklist labels the next available step In progress before it starts

[ashfame]

Summary

The initialization checklist labels the first incomplete, unlocked step In progress even when no operation has started. The badge currently means “next available step,” while users reasonably interpret it as “this command is actively running.”

This makes the checklist report activity that does not exist and makes it difficult to determine which operation, if any, the application is actually executing.

Environment where observed

• macOS while running the app from source.
• Observed while testing both trunk and PR Upgrade Electron and bundled Node runtime #40.
• The affected checklist calculation is unchanged by PR Upgrade Electron and bundled Node runtime #40.

Examples

Before dependency installation starts

After cloning finishes, the dependency step is incomplete and ready: true. The checklist immediately labels Install npm dependencies as In progress, even though installing is false and the user has not clicked the button.

Before the first build starts

As soon as hasNodeModules becomes true, the build step is incomplete and ready: true. The checklist labels Run first full build as In progress, even though building is false and no build child process exists.

Before the development server starts

As soon as hasBuilt becomes true, the development-server step becomes ready and is labeled In progress, even though starting and running are both false.

The partial-install bug in #42 amplifies the confusion: a non-empty but invalid node_modules/ directory can cause the build step to be labeled In progress even though no build was started and the site is not actually ready to build.

Code-level cause

Each checklist entry has only done and ready state. ready means its prerequisites are satisfied; it does not mean its operation is running: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L1370-L1434

The status calculation walks the steps and assigns current to the first step where done is false and ready is true:

let currentStepCaptured = false;
const stepItems = baseSteps.map((step) => {
  let status;
  if (step.done) {
    status = 'complete';
  } else if (!currentStepCaptured && step.ready) {
    status = 'current';
    currentStepCaptured = true;
  } else if (step.ready) {
    status = 'pending';
  } else {
    status = 'locked';
  }
  return { ...step, status };
});

Source: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L1436-L1450

The visual mapping then renders current with the label In progress: https://github.com/WordPress/experimental-wp-dev-env/blob/trunk/src/renderer/index.jsx#L1326-L1368

The component already tracks actual activity through installing, building, starting, waitingForWatch, and running, but those values are used for button spinners and server controls rather than the checklist status badge.

Actual behavior

• In progress appears before the user starts the operation.
• The label cannot distinguish “ready for you to start” from “actively executing.”
• Looking at the checklist does not reliably answer which command is running.
• A button spinner may indicate real activity while the surrounding badge carries the same label before and after that activity.

Expected behavior

In progress should be reserved for an operation with actual active state:

• dependency installation: installing === true;
• first build: building === true;
• server startup: starting === true or another explicit startup state;
• running server: use a separate Running or Completed state according to the intended wizard semantics.

The first incomplete step whose prerequisites are satisfied but whose action has not started should use a label such as Ready, Next step, or Not started.

Suggested state model

Avoid deriving process activity solely from checklist ordering. Give each step explicit semantic state, for example:

• complete: verified result exists;
• running: corresponding operation is actively executing;
• ready: prerequisites are satisfied and the user may start it;
• pending or locked: prerequisites are not satisfied;
• failed: the last attempt exited non-zero, ideally with a retry action.

The exact wording can be decided with design input, but In progress should never be produced merely because a step is the first ready incomplete item.

Interaction with other bugs

• Run first full build hides npm output and failures from the visible terminal #41 hides output when the build is triggered through the checklist, making the inaccurate activity label even harder to interpret.
• Initialization wizard treats partial npm installs as complete and prevents recovery #42 can falsely complete dependency installation and advance the “current” designation to a build that has never started.
• npm runner IPC bridge can drop early output and completion events #43 can lose early runner events, so active state should have a reliable operation lifecycle rather than being inferred from ordering or filesystem state.

Acceptance criteria

• No step displays In progress before its operation starts.
• The next actionable step has a distinct non-running label such as Ready.
• Install, build, and server steps display In progress only while their corresponding operation is active.
• A non-zero exit transitions to an explicit failed/retryable state rather than silently returning to an ambiguous label.
• Completed and locked states continue to render correctly.
• Renderer tests cover the checklist before start, during execution, after success, and after failure for each asynchronous step.