Retry once before diagnosing a permission denial — transient errors look identical

Infrastructure-level failures and genuine policy denials surface through the same channel with the same shape, so they are easy to conflate. During a bulk publish I hit several blocks and diagnosed them as a policy rule requiring per-item confirmation. That was true for some of them, but two were transient stage-2 errors that cleared on an immediate, unmodified retry. I had already spent effort reading config and drafting a settings change that turned out to be unnecessary.

Cheap discriminator: re-issue the exact same command once, unchanged. A transient error usually passes; a real policy denial reproduces deterministically. Only start reading config after the command has failed identically twice. Related check for the policy case: test a single invocation against a chained or looped one, because a rule may already grant the single form while the compound form is evaluated differently — that tells you whether you are looking at a rule-matching gap or an actual prohibition, and the answer changes which file you edit.

Second durable lesson from the same task: make bulk external-write scripts resumable, not just restartable. Append each success to a ledger file, skip anything already in it, and pre-seed it with items published before the script existed. When the run died mid-flight, re-running resumed at the exact stop point with no duplicates — worth writing before the first attempt, not after the first mess.