Validate deploy numeric options before actions run

[rissrice2105-agent]

Fixes #743.

Changes

• require positive safe integers for CPU and GPU counts
• require positive finite numbers for memory and maximum hourly price
• reject NaN, Infinity, fractions for counts, non-positive values, and unsafe integers during Commander parsing
• add focused regression tests

Verification

• corepack pnpm vitest run packages/cli/src/commands/deploy.test.ts (14 passed)
• corepack pnpm --filter @profullstack/sh1pt typecheck attempted; it still fails on existing workspace/module-resolution errors unrelated to this PR

[greptile-apps]

Greptile Summary

Replaces the bare Number constructor used as Commander option parsers with two validated parser functions (parsePositiveSafeInteger for CPU/GPU counts, parsePositiveFiniteNumber for memory and max price), so invalid values are rejected at parse time with a meaningful error instead of silently becoming NaN or negative numbers in the action handler. A companion test file covers the happy path and the key rejection cases.

• parsePositiveSafeInteger rejects zero, negatives, fractions, Infinity, NaN, and integers above Number.MAX_SAFE_INTEGER for --cpu and --gpu-count.
• parsePositiveFiniteNumber rejects zero, negatives, NaN, and Infinity for --memory and --max-hourly-price.
• Both parsers currently accept hexadecimal (0x10) and scientific-notation (1e2) strings because Number() parses them silently — if strict decimal-only input is desired, an explicit format check would be needed.

Confidence Score: 4/5

Safe to merge; the validation logic is correct for all specified cases and the stub actions are unaffected.

Both parsers correctly guard against NaN, Infinity, zero, negatives, fractions, and unsafe integers. The one open question is whether hex (0x10) and scientific-notation (1e2) inputs should also be rejected — they currently pass through to the action handler with unexpected numeric values. The commands are stubs today, so there is no immediate data-loss risk, but the gap is worth addressing before these commands start making real API calls.

The two new parser functions in packages/cli/src/commands/deploy.ts around lines 4–18 deserve a second look for the hex/scientific-notation edge case.

Important Files Changed

Filename	Overview
packages/cli/src/commands/deploy.ts	Adds two exported parser functions (parsePositiveSafeInteger, parsePositiveFiniteNumber) and wires them into Commander options for --cpu, --gpu-count, --memory, and --max-hourly-price; logic is correct for the declared constraints but accepts hex/scientific-notation strings that users are unlikely to intend.
packages/cli/src/commands/deploy.test.ts	New focused regression-test file; covers valid inputs, NaN, Infinity, negative values, zero, fractions, and unsafe integers — good breadth for the new parsers.

Sequence Diagram

sequenceDiagram
    participant User as CLI User
    participant Commander as Commander.js
    participant Parser as parsePositive*
    participant Action as .action() handler

    User->>Commander: deploy quote --cpu 4 --memory 8.5
    Commander->>Parser: parsePositiveSafeInteger("4")
    Parser-->>Commander: 4
    Commander->>Parser: parsePositiveFiniteNumber("8.5")
    Parser-->>Commander: 8.5
    Commander->>Action: "opts = { cpu: 4, memory: 8.5, ... }"
    Action-->>User: [stub] deploy quote ...

    User->>Commander: deploy provision --cpu abc
    Commander->>Parser: parsePositiveSafeInteger("abc")
    Parser-->>Commander: throws InvalidArgumentError
    Commander-->>User: "error: option '--cpu <n>' argument 'abc' is invalid. must be a positive safe integer"

Loading

_{Reviews (1): Last reviewed commit: "Validate deploy numeric options" | Re-trigger Greptile}

[greptile-apps]

Hex and scientific-notation strings silently accepted

Number('0x10') → 16 and Number('1e2') → 100 both satisfy the safe-integer and finite-positive checks, so --cpu 0x10 or --gpu-count 1e2 pass validation and are forwarded to the action. A user who fat-fingers 0x or uses scientific notation by accident would get an unexpected count rather than a validation error. Adding an explicit check (/^\d+$/ for the integer parser, /^\d+(\.\d+)?$/ for the float parser) before calling Number() would close this gap without affecting normal decimal input.

[rissrice2105-agent]

CI is green for PR #744.

Verification:

• corepack pnpm vitest run packages/cli/src/commands/deploy.test.ts (14 passed)
• corepack pnpm --filter @profullstack/sh1pt typecheck was attempted and still fails on existing workspace/module-resolution errors unrelated to this PR.

uGig invoice evidence will be sent after the duplicate-invoice retry window expires.

[github-actions]

🤖 Auto-rebase: The branch was rebased successfully locally but could not be pushed to the fork. Please enable 'Allow edits from maintainers' in the PR settings, or rebase manually: git fetch upstream master && git rebase upstream/master.

[github-actions]

🤖 Auto-rebase: The branch was rebased successfully locally but could not be pushed to the fork. Please enable 'Allow edits from maintainers' in the PR settings, or rebase manually: git fetch upstream master && git rebase upstream/master.

[github-actions]

🤖 Auto-rebase: The branch was rebased successfully locally but could not be pushed to the fork. Please enable 'Allow edits from maintainers' in the PR settings, or rebase manually: git fetch upstream master && git rebase upstream/master.