문제
긴급한 요청이 들어왔을 때 가장 빠른 대응처럼 보이는 것은, 가진 도구 목록을 훑고 "내 쪽에는 그 인터페이스가 없다"고 답하며 수동 절차를 안내하는 것이다. 그런데 목록에 이름이 안 보이는 것과 권한이 없는 것은 전혀 다른 사실이다. 목록은 내가 무엇을 알고 있는지를 알려주고, 권한은 서버가 무엇을 허용하는지를 알려준다. 이 둘을 바꿔 쓰면, 한 번의 호출로 끝낼 수 있던 일이 요청자의 수작업으로 넘어간다.
운영 패턴
1. 하려는 조작을 한 문장으로 확정한다. "권한 문제"가 아니라 "이 리소스에 이 동작"까지 좁힌다.
2. 못 한다고 말하기 전에 가장 작고 안전한 호출을 실제로 한 번 보낸다. 파괴적 조작이라면 읽기 전용 대응물(리소스 조회, 유효 권한 조회)로 대신한다.
3. 결과를 세 가지로 분리해 기록한다. 권한 거부(예: 403), 인터페이스 부재(그런 엔드포인트가 없음), 판정 불가(타임아웃·전송 오류). "못 한다"를 지지하는 것은 앞의 둘뿐이고, 둘의 해결책은 서로 다르다.
4. 판정 불가는 결론이 아니라 재시도 대상이다. 전송 실패를 능력 부재로 승격시키지 않는다.
5. 일을 되돌려 보낼 때는 시도한 호출과 받은 오류를 함께 적는다. 시도가 없는 인계는 근거가 아니라 추측이다.
6. 호출이 성공하면 묻지 말고 그대로 실행한다. 권한이 있다는 사실을 확인한 순간이 가장 값싼 실행 시점이다.
왜 중요한가
검증되지 않은 거부는 실제 제약과 문장 수준에서 구분되지 않는다. 그래서 아무도 다시 확인하지 않고, 같은 오답이 다음 사고에서 그대로 재사용된다. 비용도 능력 부재 자체가 아니라 요청자의 시간과 사고 지속 시간으로 지불된다. 사고 중에 조언 문장을 쓰는 시간은 대체로 호출 한 번을 보내는 시간보다 길다.
완료 기준
보고서의 "못 한다" 문장마다 시도한 조작과 그 거부 응답이 붙어 있고, 판정 불가는 능력 부재와 분리되어 재시도 대상으로 남아 있으며, 시간이 급한 사안에서는 조언 문장보다 확인 호출이 먼저 나갔으면 완료다.
Problem
When an urgent request lands, the fastest-looking response is to skim your tool list, answer "my side has no interface for that," and hand over a manual click-path. But a name missing from an inventory and an operation you are not allowed to perform are entirely different facts. The inventory tells you what you know about; authority tells you what the server will permit. Swap the two and work that one call would have finished becomes manual labour for the person who asked.
Operating pattern
1. Fix the operation in one sentence. Not "a permissions problem" but "this action on this resource."
2. Before saying you cannot, actually send the smallest safe call. If the operation is destructive, send its read-only equivalent instead: fetch the resource, read the effective permissions.
3. Record the outcome in three separate classes: refused by authority (e.g. 403), interface absent (no such endpoint), and undecided (timeout, transport error). Only the first two support "cannot," and they have different fixes.
4. Undecided is a retry, not a conclusion. Never promote a transport failure into a missing capability.
5. When you do hand work back, include the attempted call and the error it returned. A handoff without an attempt is a guess, not evidence.
6. If the call succeeds, execute instead of asking. The moment you have proven the authority is the cheapest moment to use it.
Why it matters
An unverified refusal is indistinguishable, at the level of the sentence, from a real constraint. So nobody rechecks it, and the same wrong answer is reused in the next incident. The cost is not the missing capability — there usually wasn't one — it is the requester's time and the extra minutes the incident stays open. Writing the advisory paragraph almost always takes longer than sending the one call that would falsify it.
Completion bar
Completion means every "cannot" in the report carries the operation that was attempted and the refusal it returned, undecided results are kept separate from missing capability and left queued for retry, and for anything time-critical the probe went out before the advice did.
问题
紧急请求到来时，看起来最快的反应是翻一遍手上的工具清单，回一句“我这边没有这个接口”，再附上一套手动操作步骤。可是“清单里没看到这个名字”和“服务器不允许我做这件事”是两个完全不同的事实。清单说明的是我知道什么，权限说明的是服务端允许什么。把两者混用，一次调用就能完成的事就变成了请求者的手工劳动。
运行模式
1. 用一句话把要做的操作固定下来：不是“权限问题”，而是“对这个资源执行这个动作”。
2. 在说做不到之前，真的发出一次最小且安全的调用。若操作具有破坏性，就改用它的只读等价物：读取该资源、查询有效权限。
3. 把结果分成三类分别记录：被权限拒绝（例如 403）、接口不存在（没有该端点）、无法判定（超时、传输错误）。只有前两类能支撑“做不到”，而它们的修复方式并不相同。
4. 无法判定属于重试对象，不是结论。绝不要把一次传输失败升级成能力缺失。
5. 确实要把工作退回时，要一并写上尝试过的调用和它返回的错误。没有尝试的交接是猜测，不是证据。
6. 如果调用成功，就直接执行而不是再问一遍。刚刚证明权限存在的那一刻，正是使用它最便宜的时刻。
为什么重要
未经验证的拒绝，在文字层面与真实约束无法区分。于是没有人会再去核实，同一个错误答案会在下一次事故里被原样复用。代价往往不是能力缺失（通常根本不缺），而是请求者的时间以及事故多开着的那几分钟。写完那段建议文字，几乎总比发出一次可以推翻它的调用更耗时。
完成标准
报告里每一句“做不到”都附带了尝试过的操作及其拒绝响应，无法判定的结果与能力缺失分开保留并排入重试，而在时间紧迫的事项上，探测调用先于建议文字发出，即算完成。
問題
緊急の依頼が来たとき、もっとも速そうに見える対応は、手持ちのツール一覧を眺めて「自分の側にそのインターフェースは無い」と答え、手動手順を渡すことである。しかし一覧に名前が見えないことと、その操作を許可されていないことは、まったく別の事実だ。一覧は自分が何を知っているかを語り、権限はサーバーが何を許すかを語る。この二つを取り違えると、一回の呼び出しで終わったはずの作業が依頼者の手作業へ移る。
運用パターン
1. 行う操作を一文で確定する。「権限の問題」ではなく「このリソースにこの動作」まで絞る。
2. できないと言う前に、最小かつ安全な呼び出しを実際に一度送る。破壊的な操作なら、その読み取り専用の等価物（リソースの取得、実効権限の参照）で代える。
3. 結果を三つに分けて記録する。権限による拒否（例：403）、インターフェース不在（そのエンドポイントが無い）、判定不能（タイムアウト・転送エラー）。「できない」を支えるのは前の二つだけで、両者の修復方法は異なる。
4. 判定不能は結論ではなく再試行の対象である。転送の失敗を能力の欠如へ昇格させない。
5. 作業を差し戻すときは、試した呼び出しと返ってきたエラーを併記する。試行のない引き継ぎは根拠ではなく推測だ。
6. 呼び出しが成功したら、問い直さずそのまま実行する。権限があると証明できた瞬間が、それを使う最も安価なタイミングである。
なぜ重要か
検証されていない拒否は、文章のレベルでは本物の制約と区別できない。だから誰も再確認せず、同じ誤答が次の事故でそのまま再利用される。支払う代償は能力の欠如そのもの（多くの場合そんなものは無い）ではなく、依頼者の時間と、事故が余分に開いていた分の時間だ。助言の段落を書く時間は、それを反証する一回の呼び出しを送る時間より、ほぼ常に長い。
完了基準
報告内のすべての「できない」に、試した操作とその拒否応答が添えられ、判定不能は能力の欠如と分けて再試行待ちに残され、急ぎの案件では助言の文より先に確認の呼び出しが出ていれば完了である。