Unfamiliar-domain tasks fail when no scoping task precedes execution

[mrhobbeys]

The failure

When a project involves auditing or investigating a system the agent hasn't seen before, the execution tasks assume knowledge the agent doesn't have. The agent either quits prematurely ("I don't have enough information to complete this") or produces shallow output that requires heavy operator correction. The operator ends up manually feeding context that should have been gathered systematically.

This happens because the task graph jumps straight from project scaffolding to execution without a dedicated step to enumerate what's actually in scope for unfamiliar domains.

How to reproduce

1. Scaffold a project that includes auditing an external system (e.g., a SaaS platform's configuration, a client's existing infrastructure, a third-party tool's workspace setup).
2. Write audit tasks that assume the agent knows the structure of the external system.
3. Execute. Observe the agent either quitting early or producing work that misses major sections because it didn't know they existed.

Expected: Agent systematically covers all relevant areas of the external system.
Actual: Agent covers what it can see from surface-level access and declares done, missing significant sections that the operator has to manually point out.

Root cause

The Dependency mechanism doesn't currently require a scoping task for unfamiliar domains. The task template assumes the task author (planner or operator) already knows the full scope. When they don't — which is common for audits, investigations, and research into systems the agent hasn't interacted with before — execution tasks are built on incomplete assumptions.

Proposed fix: Scoping Task Requirement

Add a scoping task pattern to the templates. For any project phase that involves investigating an unfamiliar system or domain:

1. The first task in the phase is always a scoping task. Its only output is a structured enumeration of what exists (e.g., "5 workspaces found, each containing these agent configurations, these automation rules, and these integration points").
2. All execution tasks in the phase depend on the scoping task. They cannot be written until the scoping task completes, because the scoping task's output defines what needs to be audited.
3. The scoping task has a verification checklist: "Did you enumerate all top-level items? Did you check for items that aren't visible from the default view? Did the operator confirm the enumeration is complete?"

This is a template-level change. Add a scoping-task-template.md to templates/ and document the pattern in DEPENDENCY.md under a new section: "Scoping dependencies for unfamiliar domains."

Mechanisms involved

• Dependency (primary) — execution tasks should depend on a scoping task that doesn't currently exist in the template set
• Verification (secondary) — the scoping task needs its own verification checklist to confirm coverage
• Atomicity (secondary) — the scoping task is a distinct unit of work with a binary done state: "scope enumerated and confirmed" or not