feat(#452): doctor reports sandbox tier + opt-in auto-start — completes The Scientist (PR 3/3)#464
Conversation
…tart - detectContainerRuntime now probes `docker/podman info` (daemon REACHABLE), not `--version` (binary installed). A present binary with a stopped daemon used to make runInSandbox spawn `docker run`, hit a connection error, and mis-record it as a test FAILURE — now it correctly degrades to 'unverified'. - detectInstalledRuntime keeps the `--version` check so auto-start can tell 'installed but stopped' (startable) from 'not installed' (nothing to start). - runtimeStartCommand: platform-aware engine boot (open -a Docker / Docker Desktop / podman machine start; null on linux system daemons). - startContainerRuntime: OPT-IN, bounded auto-start — launches the engine then polls readiness with a HARD timeout so a gate never hangs on a booting GUI. Fully injectable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- sandboxTierCheck (pure, exported) answers 'are my test results real or self-reported?': container-verified (PASS) when a runtime is ready and a command is configured; WARN for ready-but-no-command, installed-but-stopped (with the exact start hint), no-runtime, or disabled — never a false green. - checkSandboxTier wires it into runDoctor after the config checks. - doctor --start-runtime (or RSTACK_SANDBOX_AUTOSTART=1) opts into the bounded auto-start; never launches an engine otherwise. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
sandboxTierCheck verdicts (PASS/WARN across ready/no-command/stopped/absent/ disabled + auto-start note), detectInstalledRuntime, platform-aware runtimeStartCommand, and the injectable bounded startContainerRuntime (not-installed / already-running / becomes-ready / times-out / no-start-path). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Review limit reached
Next review available in: 4 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
#464) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2 participants
#452 PR 3/3 —
doctorreports the active sandbox tier + opt-in bounded auto-start (closes #452)The final piece. PR 1 built the sandbox; PR 2 wired it into the gate; PR 3 makes the enforcement strength visible to operators and answers the "what if Docker isn't running?" question you raised.
What changed
doctornow reports the sandbox execution tier — the honest answer to "are my test results real or self-reported?":container-verified (docker/podman): a runtime is ready and an authoritative command is configured →sdlc_validateruns it and authors evidence from the real exit code.unverified— never a false green.doctor --start-runtime, orRSTACK_SANDBOX_AUTOSTART=1) — if the engine is installed but stopped, launch it (open -a Docker/ Docker Desktop /podman machine start) and poll readiness with a hard timeout. It never launches an engine otherwise — no hidden GUI launch mid-gate (exactly the concern you flagged).detectContainerRuntimenow probesdocker/podman info(daemon reachable), not--version(binary installed). Previously a present binary with a stopped daemon maderunInSandboxspawndocker run, hit "Cannot connect to the Docker daemon," and mis-record that connection error as a test FAILURE. Now it correctly degrades tounverified.detectInstalledRuntimekeeps the--versioncheck so auto-start can tell stopped (startable) from not installed.Posture (unchanged, your sign-off)
Confined-only executes · no-runtime → honest
unverified· network OFF · auto-upgrade to container when present. Auto-start is opt-in and bounded.Verification
git diff --checkclean.tests/sandbox-doctor-452.test.js: tier verdicts, readiness-vs-installed detection, platform-aware start commands, and the injectable bounded auto-start (not-installed / already-running / becomes-ready / times-out / no-start-path) — all without a real daemon.This closes #452 and the sandbox trilogy
PR 1 (core) + PR 2 (validate wiring) + PR 3 (tier + auto-start) = The Scientist is complete: untrusted code runs confined, the gate uses the real exit code, the Critic gets the real logs, and operators can see exactly how strong verification is on their machine.
Next in epic #450: #453 — Quality & Risk Index, riding on this real execution signal. That closes the autonomy epic.
Closes #452