@sreetej510/pi-shipd-checks 0.9.3 → 0.9.5

package/README.md

@@ -38,7 +38,8 @@ current checks, starts Test Quality before Solution Quality in one browser tab,
 `"Not fair"`, and the complete `details.solutionQuality.evaluation` block. Its compact UI is labeled `Quality Checks`,
 shows live elapsed time, and only displays unfair-test count, suggestion count, code-quality score, and
 comprehensiveness score. It takes no parameters. It uses one fresh headless browser tab at a time: it closes the
-browser after starting the needed jobs, checks after 5 minutes, then reopens every 90 seconds until those jobs finish. If
+browser after starting the needed jobs, checks after 5 minutes, then reopens every 90 seconds until those jobs finish, with no
+client-side overall timeout. If
 all checks are current, it uses existing reports without starting a job. Each
 browser context blocks images, fonts, and media to reduce memory use. It does not click the final orange
 challenge-submit button. Authentication comes from `SHIPD_STORAGE_STATE` or the saved state created by
@@ -142,24 +143,36 @@ On-Demand fallback. Spot interruptions are retried according to `fargate.maxRetr
    ```
 
    `cluster`, `subnetIds`, and `securityGroupId` are optional when a default VPC is available.
-   With `adaptiveResourceProfile: true`, the first run uses `resourceProfile`; later runs upgrade
-   when normalized CPU is at least 95% for more than seven minutes, downgrade when CPU is at
-   least 95% for under two minutes, and otherwise retain the profile. Only the selected next
-   profile is written to `projectProfiles`; CPU telemetry is included in `shipd_report.json` but
-   no telemetry history is retained. Set `projectProfiles` to override resources per repository:
+   With `adaptiveResourceProfile: true`, the first solver-gap or quality patch-precheck run for
+   a repository uses `resourceProfile` (unless `projectProfiles` already overrides it); later runs
+   upgrade when normalized CPU is at least 95% for more than seven
+   minutes, downgrade when CPU is at least 95% for under two minutes, and otherwise retain the
+   profile. Only the selected next profile is written to `projectProfiles`; CPU telemetry is
+   included in `shipd_report.json` for solver-gap runs, but no telemetry history is retained. Set
+   `projectProfiles` to override resources per repository:
    `{"C:/path/to/repo":"large"}`.
 
 5. Restart pi, use `/checks --config` to select the solver and reviewer models, then run
    `/checks --solver-gap-finder`. Projects need `Dockerfile`, `agent_prompt.md`,
    `solution.patch`, `test.patch`, and `test.sh`.
 
+For a Command Code subscription model, install the provider in the local pi if needed
+(`pi install npm:pi-commandcode-provider`), then authenticate it with `/login` (**Use a
+subscription** → **Command Code**) and make sure the plan includes Provider API access. Select a
+`commandcode/...` solver model. The standalone Fargate worker bundles the pinned
+`pi-commandcode-provider` package and registers it before starting solver sessions; installing a
+separate Command Code CLI or npm package in the task image is not required. The task needs
+outbound HTTPS access to the Command Code API. The runner uploads only the selected provider
+credential from the local pi auth state for the task; never put the credential in project files.
+
 Use `/analyze:on` and `/analyze:off` to control the gap-finder and solution-precheck tools per project, like HPC. The
 enabled project list is stored alongside the other settings in `~/.pi/agent/checks-config.json`.
 
-The patch precheck applies `test.patch`, requires `./test.sh base` to pass, requires every `./test.sh new` testcase to
-fail or error individually (with no suite-level error) before `solution.patch`, then requires both base and new suites to
-pass after the solution patch. A failed precheck aborts before Shipd is opened and includes the Linux platform, a human-readable phase,
-and failed/errored test names in the tool error.
+The patch precheck applies `test.patch`, creates isolated workspaces with and without `solution.patch`, and runs the
+base suites concurrently in both workspaces followed by the new suites concurrently in both workspaces. It requires
+`./test.sh base` to pass, requires every `./test.sh new` testcase to fail or error individually (with no suite-level error)
+before `solution.patch`, then requires both base and new suites to pass after the solution patch. A failed precheck aborts
+before Shipd is opened and includes the Linux platform, a human-readable phase, and failed/errored test names in the tool error.
 
 The `gap-finder` and `solution-precheck` tools are read-only and return repair recommendations; the caller changes the
 tests, prompt, or solution. Invoke them only when the user asks, never in parallel, and run repeated requests