Retrofit & PR Comments

Retrofit

sfdt retrofit pulls metadata that was changed directly in one org (e.g. an admin editing production) back into source control and forward to another org: retrieve → commit → smart-deploy.


sfdt retrofit --source prod --target uat                 # validate-only by default
sfdt retrofit --source prod --target uat --execute       # real deploy
sfdt retrofit --source prod --no-deploy                  # retrieve + commit only
sfdt retrofit --source prod --no-commit                  # retrieve only (review)
sfdt retrofit --source prod --target uat --metadata "CustomField,ValidationRule,Layout"

Steps:

Retrieve the configured metadata types from --source (reuses the org inventory + parallel-retrieve engine).
Report changed files; stop here with --no-commit.
Commit the changes (message via --commit-msg); stop here with --no-deploy.
Smart-deploy the committed delta to --target — validate-only unless --execute.

Flag	Notes
`--source <alias>`	Org to retrieve FROM (required)
`--target <alias>`	Org to deploy TO (required unless `--no-deploy`)
`--metadata <types>`	Comma-separated types (default: a common admin-changed set)
`--commit-msg <msg>`	Retrofit commit message
`--no-commit`	Retrieve only, leave changes for review
`--no-deploy`	Retrieve + commit, no deploy
`--execute`	Perform a real deploy (default: validate-only)
`--json`	Machine-readable result

Default metadata set: CustomField, ValidationRule, Layout, CustomLabel, RecordType, QuickAction, FlexiPage, CustomApplication, CompactLayout.

The deploy step uses the Smart Deploy engine, so overwrite protection and smart test selection apply.

Cross-org release check. When --source and --target run different Salesforce releases (detected best-effort from each org’s REST version list), sfdt retrofit prints a heads-up before deploying — metadata valid on one release may not deploy cleanly to another. It’s non-fatal, and skipped when a release can’t be determined; retrofit --json reports it as releaseMismatch.

Since 0.25.0: retrofit asks for confirmation even without --execute. Omitting --execute skipped only the deploy. Retrofit still retrieved metadata over your working checkout and committed the result, which is why the equivalent capability on sfdt pull was already treated as mutating. The MCP tool sfdt_retrofit now requires confirmExecution on both paths.

PR comments

sfdt pr comment posts results to the current pull request via the GitHub CLI (gh). It renders the latest audit/monitor snapshot to markdown, or posts inline text / a file.


sfdt pr comment --type monitor          # post the latest monitor snapshot
sfdt pr comment --type audit
sfdt pr comment --body "Deployed to UAT ✅"
sfdt pr comment --file notes.md --pr 42

Flag	Notes
`--type audit\|monitor`	Render the latest snapshot (default `monitor`)
`--body <text>`	Post inline text instead of a snapshot
`--file <path>`	Post a file’s contents
`--pr <id>`	Target PR number/URL (defaults to the current branch PR)
`--json`	Machine-readable result

sfdt deploy --smart --pr-comment automatically decorates the PR with the delta summary and deploy outcome.

Requires the GitHub CLI (gh) installed and authenticated (gh auth login), and GITHUB_TOKEN in CI.

Since 0.25.0: sfdt pr comment takes a PR number, not a URL. A URL names a repository as well as a pull request, so a value chosen by an AI model could post an org snapshot into a repo you do not own under your GitHub identity. The reference is now constrained to a number in the current repository, the body is redacted before it leaves the machine, and sfdt_pr_comment requires confirmExecution instead of presenting as read-only.

Surfaces

MCP — sfdt_retrofit (real deploys are confirmExecution-gated) and sfdt_pr_comment.
VS Code — Retrofit, Smart Deploy (validate), and PR Comment entries in the Commands tree.