Styx 採用 fail-closed 原則：未標明 staging 的命令按 production 處理
Fail closed: if a command doesn't say staging, treat it as production
Styx 將無法判定為 staging 或 production 的命令視為 production。production 寫入、部署和刪除操作需額外通過 Touch ID、Windows Hello 或系統密碼驗證；作者亦建議為無法分類的輸入逐項先寫測試，並讓無害命令明確標示環境以減少提示。
If you write code that decides whether a command touches production, you will get two kinds of wrong answer. The unknown case decides which kind you get.
Treat a command you can't classify as staging, and sooner or later a production deploy runs without anyone being asked. Treat it as production, and you get an extra prompt for something harmless.
The second mistake is annoying. The first one is an incident. So in the tool I'm building, Styx, a command that doesn't say staging or production counts as production. It asks, and production writes, deploys and deletes need Touch ID, Windows Hello or your system password on top.
Three things made this workable.
Fix noisy prompts by naming the environment, not by loosening the default. If a harmless command keeps asking, make it say what it is.
Write the test for the unknown case first. One row per input you can't classify, each expecting the dangerous bucket. It's the row people forget.
Be honest about the limit. A classifier only sees commands that go through it. An agent that calls a CLI by its full path, or an SDK with a token it found on disk, never reaches it. Fail-closed is a default, not a sandbox.
When you write a classifier like this, which way does your unknown case fall?
來源：DEV Community · dev.to