Keep automatic Git commands eligible for Instapack

[Fermionic-Lyu]

insta compute connect-repo persisted automatically detected build/start commands as explicit source constraints. The Platform correctly preserved those constraints on Nixpacks, so ordinary CLI Git deployments could not select an operator-enabled Instapack builder. Leave automatic commands unset while retaining detected directory and port, repository identity, branch, and deployment options. Explicit command handling on the Platform is unchanged.

Validation: typecheck, build, lint and 1,723 tests pass. The regression fails before the fix. Independent review verified the current Platform contract; four isolated mutations restoring either command for App/public requests each fail the corresponding test. Formal staging acceptance also exercises this CLI through the normal source API.

---

Summary by cubic

Leaves automatically detected build and start commands unset in connect-repo so they no longer constrain builder selection. Previously, persisted commands forced Nixpacks, blocking CLI Git deployments from using an operator-enabled Instapack builder. Detected directory, port, repo identity, branch, and deployment options are still sent; explicit command overrides are unchanged.

^{Written for commit 1a46f11. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[agent-zhang-beihai]

Reviewed by Wang Miao

This drops buildCommand/startCommand from the connect-repo PUT body so the platform stores them as null, which is exactly the condition the build path uses to let the gateway pick Instapack instead of pinning Nixpacks. I traced it through the platform and the compute daemon and the change does what it claims, with no caller or contract left behind — approving.

For the record, what I checked: instacloud-platform src/github/build.ts:118-160 is where the two behaviours hang off these fields — a persisted command triggers a nixpacksPlan re-verification of the build branch (the failure the old comment described) and forces allowInstapack: wantBuild === null && wantStart === null to false. Omitting the fields is enough to reach null: SourceInputSchema (src/server.ts:1645-1646) makes both optional, setSource passes them through undefined, and sources.create writes blankToNull(undefined) → null. The PUT fully replaces an existing source rather than patching it (service.ts:362-377), so a service reconnected by this CLI cannot retain stale commands from an older client. The only other consumer of the stored columns is buildService.ts:135, which feeds the same build path; the flyctl lane treats absent commands as "use the Nixpacks-detected defaults" (flyBuild.ts:291-296), so legacy Fly-backed rows build identically. sourceBody has one call site, and Candidate.buildCommand/startCommand are still used by the monorepo disambiguation listing, so nothing is left dead. instacloud-compute docs/instapack-builder.md states the same contract from the other side — "Git requests carrying build/start command requirements must omit it" — and keeps Nixpacks for projects the operator has not enabled, so the nixpacks label connect-repo prints is still accurate wherever the opt-in is off. npm run typecheck and the 43 tests in test/github-connect.test.ts pass; the two rewritten assertions moved to exact toEqual, which pins the absence of both fields more tightly than the toMatchObject they replaced.

[agent-zhang-beihai]

Reviewed by Yang Dong

This stops compute connect-repo from persisting automatically detected build/start commands, allowing command-free Git builds to remain eligible for Instapack while preserving root and port selection. The request shape matches the control plane’s eligibility contract, so I would approve it.

No findings.

[jwfing]

LGTM - approved.