문제
누군가 “이 명령으로 우회했다”라고 알려 주면, 그 문장은 이미 한 번 성공한 증거처럼 보인다. 그래서 검증하지 않고 여러 단계짜리 확인 배치 한가운데에 붙여 넣게 된다. 그런데 그 서브커맨드가 내 쪽 버전에 없으면 배치는 통째로 죽고, 앞에서 이미 성공했던 측정값까지 함께 버려진다. 더 나쁜 것은 그 실패가 흔히 권한 오류처럼 보인다는 점이다. 실제로는 관여한 적도 없는 자격 증명을 몇 분 동안 뒤지게 된다.
명령문은 인터페이스가 아니라 버전을 싣고 온다
도구 이름이 같아도 몇 년 차이 나는 두 빌드는 서로 다른 프로그램이다. 서브커맨드 목록, 기본값, 실패 메시지가 전부 다르다. 남에게서 온 것은 명령문 한 줄이지만, 그것을 동작하게 만든 것은 그 사람 쪽의 버전·설치 경로·인증 상태였고 그 셋은 복사되지 않는다.
동사를 먼저 한 번 때려 본다
비용은 호출 한 번이다. 도구 --version으로 빌드를 확인하고, 쓰려는 동사에 --help를 붙여 그 동사가 존재하는지 본다. 경계에서 싸게 실패하면 원인을 그대로 알려 주는 메시지를 얻고, 배치 한가운데에서 비싸게 실패하면 엉뚱한 층을 가리키는 메시지를 얻는다.
검증 안 된 단계는 순서 앞이나 바깥으로 뺀다
여러 측정을 한 번에 돌릴 때는 확인되지 않은 단계를 맨 앞에 두거나 아예 따로 돌린다. 7단계에서 죽는 배치는 1~6단계의 결과까지 같이 버린다. 순서를 바꾸는 것만으로 같은 실패가 “측정 하나 실패”로 줄어든다.
빌린 진단은 빌린 명령보다 빨리 상한다
가장 오래 검증되지 않은 채 남는 것은 명령이 아니라 원인 설명이다. 결론의 문장 형태로 도착하기 때문이다. 남의 진단을 근거로 규칙이나 문서를 만들기 전에, 그 사람의 대화를 끝까지 읽고 스스로 철회했는지 확인한다. 실제로 철회가 이미 올라와 있는데 그 앞부분만 읽고 규칙으로 굳혀 버리는 일이 일어난다.
완료 기준
스크립트에 들어간 모든 동사가 이 호스트에서 한 번씩 단독 실행된 적이 있고, 인용한 원인 설명이 그 출처의 최신 입장이며, 대응의 근거가 된 실패 메시지를 추측이 아니라 재현으로 확인했을 때 완료다.
The trap
When another operator says "this command worked around it for me," the sentence arrives looking like proof, so it goes straight into the middle of a multi-step verification run without a check of its own. If that subcommand does not exist in the build installed here, the whole batch dies and takes the measurements that had already succeeded with it. Worse, that failure usually reads as an authorization problem, so the next several minutes go into credentials that were never involved.
A demonstrated command carries a version, not an interface
Two builds of the same tool years apart are different programs: different subcommand sets, different defaults, different error text. What crossed over was one line of text; what made it work over there was that host's version, install path and auth state, and none of those three travel with the line.
Probe the verb before it enters the batch
The cost is a single call. Run the tool's version flag to see which build you actually have, then attach the help flag to the verb you intend to use and confirm the verb exists. Failing cheaply at the boundary gives you a message that names the real cause; failing expensively mid-sequence gives you a message that points at the wrong layer.
Keep unproven steps out of the middle of a sequence
When several measurements run together, put the unverified step first or run it entirely on its own. A batch that dies at step seven discards steps one through six as well, and the same defect costs one failed measurement instead of a whole run purely because of ordering.
A borrowed diagnosis ages faster than a borrowed command
The part that survives longest unexamined is not the command but the causal story attached to it, because it arrives already phrased as a conclusion. Before you build a rule, a runbook or a doc on someone else's diagnosis, read forward to the end of their thread and check whether they took it back. The expensive version of this mistake is minting durable guidance that asserts a diagnosis its own author had retracted while you were still writing.
Completion bar
You are done when every verb in the script has been run standalone at least once on this machine, the causal story you cite is the latest position of the source you took it from, and the failure message you acted on was reproduced rather than inferred.
问题
有人说“我用这条命令绕过去了”，这句话本身看起来就像证据，于是它被直接粘进多步骤的验证批处理中间。可是本机安装的版本里如果没有那个子命令，整个批处理会一起失败，连前面已经成功的测量也一并丢掉。更麻烦的是，这种失败通常长得像权限错误，于是接下来几分钟都花在根本没参与的凭据上。
命令带来的是版本，不是接口
同名工具相隔几年的两个构建其实是两个程序：子命令集合不同，默认值不同，报错文本也不同。跨过来的只有一行文本，而让它在对方那里生效的，是对方的版本、安装路径和认证状态，这三样都不会跟着过来。
先单独试一次那个子命令
代价只是一次调用。先看工具的版本，再给要用的子命令加上帮助参数，确认它确实存在。在边界上便宜地失败，得到的是直指真实原因的信息；在批处理中间昂贵地失败，得到的是指向错误层的信息。
未验证的步骤不要放在序列中间
多项测量一起跑时，把没验证过的步骤放最前面，或者干脆单独跑。第七步失败的批处理会连前六步的结果一起作废；仅仅换个顺序，同一个缺陷就从“整轮报废”缩成“一项测量失败”。
借来的诊断比借来的命令坏得更快
最久不被复查的不是命令，而是随命令一起传来的原因解释，因为它是以结论的口吻到达的。在把别人的诊断写进规则或文档之前，把对方的讨论读到最后，确认他没有收回。最贵的版本是：你还在写的时候，作者已经撤回了那个诊断，而你把它固化成了长期文档。
完成标准
脚本里每个子命令都在本机单独跑过至少一次，引用的原因解释是来源方的最新说法，作为处置依据的报错是复现出来的而不是推断出来的——满足这三条才算完成。
問題
誰かが「このコマンドで回避できた」と言うと、その一文はもう証拠のように見える。だから検証されないまま、多段の確認バッチの中ほどに貼り付けられる。しかし手元の版にそのサブコマンドが無ければバッチは丸ごと落ち、すでに成功していた測定まで一緒に捨てられる。しかもその失敗はたいてい権限エラーの顔をしているので、関与すらしていない認証情報を数分かけて探すことになる。
コマンド文字列が運ぶのはバージョンであって仕様ではない
同じ名前のツールでも数年離れた二つのビルドは別のプログラムで、サブコマンドの集合も既定値もエラー文言も違う。渡ってきたのは一行のテキストだけで、それを向こうで成立させていたのは相手側のバージョン・導入経路・認証状態であり、その三つは付いてこない。
バッチに入れる前にその動詞を一度叩く
費用は呼び出し一回だ。ツールのバージョンを確認し、使う予定のサブコマンドにヘルプを付けて存在を確かめる。境界で安く落ちれば原因をそのまま示すメッセージが得られ、途中で高く落ちれば見当違いの層を指すメッセージが返ってくる。
未検証の手順は列の中ほどに置かない
複数の測定をまとめて回すときは、未検証の手順を先頭に置くか単独で走らせる。七番目で落ちるバッチは一から六の結果も捨てる。並べ替えるだけで、同じ欠陥の代償は「一件の測定失敗」に縮む。
借りた診断は借りたコマンドより早く腐る
いちばん長く検証されずに残るのはコマンドではなく、付いてきた原因の説明だ。結論の形で届くからである。他人の診断を根拠に規則や手順書を書く前に、その人のやり取りを最後まで読み、撤回していないかを確かめる。最悪の形は、書いている最中にすでに撤回されていた診断を、長く残る文書として固めてしまうことだ。
完了の基準
スクリプト内のすべての動詞をこの環境で単独実行したことがあり、引用した原因説明が出所の最新の立場であり、対処の根拠にした失敗メッセージを推測ではなく再現で確かめている。この三つが揃って完了とする。