Summary

What problem does this PR solve?

doctor --fix --non-interactive needed to stop auto-restarting an already-running gateway after a transient health/probe failure, but the earlier PR branch also made loaded-but-stopped gateway services stop auto-starting. Root cause: the stopped-service start prompt was marked interactive-only, so DoctorPrompter.confirmRuntimeRepair could no longer auto-approve that repair in normal non-interactive --fix mode.

Why does this matter now?

Cron, launchd, systemd timer, and other unattended doctor runs rely on stopped-service repair for gateway self-healing. Keeping restart blocked for a running service is the safety fix; blocking start for an actually stopped service removes the recovery behavior that --fix --non-interactive is supposed to provide.

What is the intended outcome?

This is a root-cause lifecycle-scoping fix: the already-running restart path remains interactive-only, while the stopped-service start path again follows the existing non-interactive repair auto-approval policy. The source-of-truth boundary is the internal gateway daemon repair flow plus DoctorPrompter repair-mode policy; this PR does not change any public API, user config, schema, protocol, migration, or provider contract.

What is intentionally out of scope?

Gateway install policy, external supervisor policy, update-in-progress repairs, restart-handoff behavior, LaunchAgent/bootstrap handling, port/probe diagnostics, and any public contract/default changes are intentionally out of scope. Related PR scan: this is an update to existing PR #94148 for issue #78217, not a new competing contract or compatibility PR.

What does success look like?

A running but temporarily unhealthy gateway is not restarted by doctor --fix --non-interactive, and a loaded but stopped gateway still reaches the start repair path under the same command.

What should reviewers focus on?

Reviewers should focus on the lifecycle split in maybeRepairGatewayDaemon: stopped-service start repair should be auto-approved by normal non-interactive --fix, while running-service restart repair should require interactive confirmation.

Linked context

Which issue does this close?

Closes #78217

Which issues, PRs, or discussions are related?

Related: #94148 existing review noted that the previous patch over-broadened the non-interactive lifecycle skip by covering stopped-service starts.

Was this requested by a maintainer or owner?

No direct maintainer request; this update addresses the review concern on the existing PR branch.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: doctor --fix --non-interactive should not restart an already-running gateway service after a transient health/probe failure, while stopped gateway services continue through the normal start-repair path described in the validation section.
• Real environment tested: Linux systemd user gateway, Node 24.16.0, OpenClaw current PR head 10b5073.
• Exact steps or command run after this patch:

  pnpm openclaw gateway status --deep
  pnpm openclaw doctor --fix --non-interactive
  pnpm openclaw gateway status --deep

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

  copied live terminal output
  before_runtime=Runtime: running (pid 1964, state active, sub running, last exit 0, reason 0)
  doctor_complete=yes
  after_runtime=Runtime: running (pid 1964, state active, sub running, last exit 0, reason 0)
  pid_unchanged=yes
  

• Observed result after fix: the copied live output shows the real running gateway kept pid 1964 before and after doctor --fix --non-interactive, and the doctor command completed without restarting that service.
• What was not tested: a real stopped systemd/launchd service auto-start end-to-end, because stopping the local gateway would interrupt the active development environment.
• Proof limitations or environment constraints: the live proof used the existing running systemd user gateway for the no-restart behavior and isolated temporary OpenClaw config/state for the doctor command so normal user config was not modified.
• Before evidence (optional but encouraged): on the previous PR head, the new stopped-service regression failed with expected "vi.fn()" to be called 1 times, but got 0 times, proving the earlier patch skipped stopped-service starts.

Tests and validation

Which commands did you run?

pnpm exec vitest run src/commands/doctor-gateway-daemon-flow.test.ts --testNamePattern "starts stopped service during non-interactive repairs"
pnpm exec vitest run src/commands/doctor-gateway-daemon-flow.test.ts --testNamePattern "skips running service restart during non-interactive repairs"
pnpm exec vitest run src/commands/doctor-gateway-daemon-flow.test.ts
pnpm openclaw gateway status --deep
pnpm openclaw doctor --fix --non-interactive
pnpm openclaw gateway status --deep

What regression coverage was added or updated?

• Updated the stopped-service non-interactive repair scenario to require the start repair path to call service.restart() once when serviceRuntime.status is stopped.
• Kept the running-service non-interactive repair scenario requiring no automatic restart when the service is already running and only health/probe status is bad.
• Guardrail rationale: these two scenarios pin the intended lifecycle split so future prompt-policy changes cannot collapse stopped start and running restart into the same non-interactive behavior.
• Full related test file result: 25 tests passed.

What failed before this fix, if known?

FAIL starts stopped service during non-interactive repairs
AssertionError: expected "vi.fn()" to be called 1 times, but got 0 times

If no test was added, why not?

A regression test was updated for the stopped-service branch and kept alongside the existing running-service restart guardrail.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes. doctor --fix --non-interactive again auto-starts a loaded but stopped gateway service, while still refusing to auto-restart a running gateway service.

Did config, environment, or migration behavior change? (Yes/No)

No.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No.

What is the highest-risk area?

Gateway service lifecycle semantics in non-interactive repair mode.

How is that risk mitigated?

The fix only removes the interactive-only flag from the stopped-service start prompt; the running-service restart prompt remains interactive-only. Regression tests cover both branches directly, and live proof shows a running gateway keeps the same PID across doctor --fix --non-interactive.

Current review state

What is the next action?

Ready for maintainer review after this PR branch update settles.

What is still waiting on author, maintainer, CI, or external proof?

No known author-side code changes remain. Remote CI and hosted ClawSweeper will need to run on the pushed head.

Which bot or reviewer comments were addressed?

• Addressed the over-broad lifecycle skip concern by preserving stopped-service auto-start while retaining interactive-only running-service restart.
• RF-001 was a ClawSweeper infrastructure failure rather than a code finding; a fresh local ClawSweeper commit review for 10b5073 reported Nothing found.