@sreetej510/pi-shipd-checks 0.10.9 → 0.10.11

package/README.md

@@ -146,7 +146,6 @@ 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`, solver-gap runs use `resourceProfile` initially and adapt
    on later runs (unless `projectProfiles` already overrides the repository). They upgrade when
@@ -161,21 +160,12 @@ On-Demand fallback. Spot interruptions are retried according to `fargate.maxRetr
    `/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 always uses the `medium` Fargate profile. It 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 `solution.patch`, then requires both base and new suites to pass after the solution patch. Pytest subtest totals are not treated as passing testcase records; emitted `<testcase>` statuses and explicit `SUBPASSED` records are used for the pre-solution invariant. 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