platform-quick-deploy

name	platform-quick-deploy
description	Deploy validated metadata to a Production Salesforce org without re-running tests. TRIGGER when the user wants to deploy to production, says 'quick deploy', 'promote', 'ship to prod', or has just validated and wants to push the change live. REQUIRES a recent `sf project deploy validate` job ID (≤10 days old, ≤3 days for --use-most-recent). DO NOT TRIGGER for sandbox/scratch deploys (use platform-metadata-deploy) or unvalidated deploys (use platform-deploy-validate first).
allowed-tools	["Bash","Read"]

Quick Deploying to Prod

Promote a validated deploy to a Production org using the job ID from a prior sf project deploy validate. No tests re-run, no components re-validated — just the promotion.

Preconditions (gate strictly)

Before doing ANYTHING, verify all four:

1. Target is Production

   sf org display --target-org <alias> --json
   

   Confirm the target really is production. The reliable check is the gate's classifier (returns production|sandbox|scratch|trial|devhub|unknown):

   sf org display --target-org <alias> --json | "${CLAUDE_PLUGIN_ROOT}/scripts/sf-deploy-gate" classify
   

   Production means isSandbox=false AND isScratch=false AND instance URL has no -- (sandbox marker) AND no test.salesforce.com AND it is not a trial/Developer Edition host (orgfarm-*, *.develop.my.salesforce.com, *.pc-rnd.*, or a trialExpirationDate in the response — these report isSandbox/isScratch as null and must not be taken for production).

   If target is NOT production (classifier returns anything other than production) → STOP and redirect to platform-metadata-deploy (which handles non-prod natively).

2. A validation exists

   • Read .sfdx/last-validation.json if it exists (left there by platform-deploy-validate)
   • OR ask the user for the job ID
   • OR fall back to --use-most-recent (validates within last 3 days)

3. Validation is fresh enough

   • Explicit --job-id: must be ≤10 days old per Salesforce's quick-deploy window
   • --use-most-recent: must be ≤3 days old
   • If the recorded createdAt exceeds the window → STOP and run platform-deploy-validate first

4. Explicit user confirmation

   • Print a confirmation block (alias, instance URL, edition, validated component count, test results) and ask: "Confirm deploy to PRODUCTION? (yes/no)"
   • Do NOT proceed without an explicit "yes"

Workflow

Step 1 — Display the production confirmation banner

Format exactly:

┌─ PRODUCTION DEPLOY ─────────────────────────────┐
│ Org alias:      <alias>                         │
│ Instance:       <instanceUrl>                   │
│ Edition:        <edition>                       │
│ Validation ID:  <jobId>                         │
│ Validated:      <createdAt> (X days ago)        │
│ Components:     <componentCount> queued         │
│ Tests:          <run>/<passed>/<failed>         │
└─────────────────────────────────────────────────┘
Confirm deploy to PRODUCTION? (yes/no)

Step 2 — Run the quick deploy

After "yes":

sf project deploy quick --job-id <id> --target-org <alias> --wait 30 --json

Or with --use-most-recent if the user opted in.

The quick deploy will:

• Promote the validated components to the org
• NOT re-run tests (per Salesforce platform behavior)
• Return final deploy status

Step 3 — Capture the deploy report

After completion, persist for audit:

mkdir -p .sfdx/deploy-history
sf project deploy report --job-id <id> --target-org <alias> --json > ".sfdx/deploy-history/<id>.json"

Surface to the user:

• ✅ Deploy succeeded — components deployed, time taken
• ⚠️ Deploy failed — error summary; recommend looking at the report

Step 4 — Post-deploy guidance

After a successful prod deploy, suggest:

• Smoke-test critical paths in the org (provide direct URLs if known)
• Monitor the prod environment for the next 30 min
• Check Setup → Deployment Status to confirm
• If anything regressed: prepare a rollback plan (re-deploy the previous version's package)

Rules

• NEVER run sf project deploy start against a Production target (always validate then quick-deploy)
• NEVER use --ignore-errors or --ignore-warnings on production
• NEVER auto-confirm — require an explicit "yes" from the user
• NEVER quick-deploy a job ID older than its validity window — re-validate instead
• ALWAYS persist the deploy report to .sfdx/deploy-history/ for the audit trail
• If the prod-check hook denies the operation, do NOT bypass it — surface the denial to the user and recommend platform-deploy-validate first