Introduce explicit repro-fix, inspect, cold-start, and review-eval modes across the MCP server, CLI, and host helpers, with canonical mode-to-tool mappings, narrowed schemas, and mode-specific tool descriptions on top of the existing workspace runtime. Reposition the docs, host onramps, and use-case recipes so named modes are the primary user-facing startup story while the generic no-mode workspace-core path remains the escape hatch, and update the shared smoke runner to validate repro-fix and cold-start through mode-backed servers. Validation: UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache uv run pytest --no-cov tests/test_api.py tests/test_server.py tests/test_host_helpers.py tests/test_public_contract.py tests/test_cli.py tests/test_workspace_use_case_smokes.py; UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make check; UV_OFFLINE=1 UV_CACHE_DIR=.uv-cache make dist-check; real guest-backed make smoke-repro-fix-loop smoke-cold-start-validation outside the sandbox.
36 lines
1.1 KiB
Markdown
36 lines
1.1 KiB
Markdown
# Cold-Start Repo Validation
|
|
|
|
Recommended mode: `cold-start`
|
|
|
|
Recommended startup:
|
|
|
|
```bash
|
|
pyro host connect claude-code --mode cold-start
|
|
```
|
|
|
|
Smoke target:
|
|
|
|
```bash
|
|
make smoke-cold-start-validation
|
|
```
|
|
|
|
Use this flow when an agent needs to treat a fresh repo like a new user would:
|
|
seed it into a workspace, run the validation script, keep one long-running
|
|
process alive, probe it from another command, and export a validation report.
|
|
|
|
Chat-host recipe:
|
|
|
|
1. Create one workspace from the repo seed.
|
|
2. Run the validation command inside that workspace.
|
|
3. Start the app as a long-running service with readiness configured.
|
|
4. Probe the ready service from another command in the same workspace.
|
|
5. Export the validation report back to the host.
|
|
6. Delete the workspace when the evaluation is done.
|
|
|
|
If the named mode feels too narrow, fall back to the generic no-mode path and
|
|
then opt into `--profile workspace-full` only when you truly need the larger
|
|
advanced surface.
|
|
|
|
This recipe is intentionally guest-local and deterministic. It proves startup,
|
|
service readiness, validation, and host-out report capture without depending on
|
|
external networks or private registries.
|