dry run도 검증 대상입니다
dry run이라는 이름만으로 안전이 보장되지는 않습니다. 구현 실수로 파일을 쓰거나 원격 요청을 보내고도 화면에는 계획만 출력할 수 있습니다. 따라서 미리보기 명령도 일반 실행처럼 명확한 변경 경계와 사후 확인이 필요합니다.
실행 전에 작업 트리 상태, 대상 파일의 해시, 원격 객체 수처럼 중요한 기준값을 작게 기록하세요. dry run을 실행한 뒤 같은 값을 다시 읽고 비교합니다. 출력에는 “무엇을 할 것인가”를 담되, 실제로 변경된 항목은 별도의 side-effect 목록으로 기록해 둘을 섞지 마세요.
자동화 테스트에는 최소한 세 가지 단언을 넣을 수 있습니다. 종료 상태가 성공인지, 계획 출력이 기대한 작업을 설명하는지, 그리고 파일·원격 상태·알림 수가 실행 전과 같은지 확인합니다. 이 경계를 증명하면 dry run은 단순한 친절한 옵션이 아니라 운영 전에 안전하게 판단할 수 있는 검증 도구가 됩니다.
A dry run still needs verification
The label “dry run” does not guarantee safety. An implementation bug can write a file or send a remote request while the terminal prints only a plan. Preview commands therefore need an explicit mutation boundary and a post-run check just like ordinary execution.
Before running the command, capture a small set of critical baselines such as working-tree status, hashes of target files, or counts of remote objects. Run the dry mode, then read the same values again and compare them. Let the output describe what would happen, but keep any observed side effects in a separate list so plans and mutations are never confused.
An automated check can make at least three assertions: the command exited successfully, the plan describes the expected operations, and files, remote state, and notification counts are unchanged. Proving this boundary turns dry run from a friendly option into a trustworthy decision tool before production changes.
dry run 也需要被验证
仅仅叫作“dry run”并不能保证安全。实现缺陷可能已经写入文件或发送远程请求，而终端仍只显示执行计划。因此，预览命令也应像正式执行一样，拥有明确的修改边界和运行后的核对步骤。
执行前，记录一小组关键基线，例如工作区状态、目标文件哈希或远程对象数量。运行 dry 模式后，再读取同样的数据并进行比较。输出可以说明“将要做什么”，但实际观察到的副作用必须单独列出，避免把计划与修改混为一谈。
自动化检查至少可以包含三项断言：命令成功退出，计划输出描述了预期操作，文件、远程状态和通知数量均未变化。证明这条边界后，dry run 就不再只是一个友好选项，而会成为生产变更前可信的判断工具。
dry run も検証の対象です
「dry run」という名前だけでは安全性は保証されません。実装の不具合によってファイルを書き換えたり、リモート要求を送ったりしていても、端末には計画だけが表示されることがあります。そのため、プレビューコマンドにも通常実行と同じく明確な変更境界と実行後の確認が必要です。
実行前に、作業ツリーの状態、対象ファイルのハッシュ、リモートオブジェクト数など、重要な基準値を少数記録します。dry モードの実行後に同じ値を読み直して比較してください。出力には「何をする予定か」を示し、実際に観測された副作用は別の一覧にして、計画と変更を混同しないようにします。
自動確認には少なくとも三つの条件を置けます。コマンドが正常終了したこと、計画が期待する操作を説明していること、そしてファイル・リモート状態・通知数が実行前と同じことです。この境界を証明できれば、dry run は便利なオプションではなく、本番変更前の信頼できる判断手段になります。