[ENHANCEMENT] No mechanical signal for 'this edit exceeds the approved plan/scope' -- expose declared scope to PreToolUse hooks

[ENHANCEMENT] No mechanical signal for "this edit exceeds the approved plan/scope" -- expose declared scope to PreToolUse hooks

Companion to the behavioral issues #65951 (workflow step-skipping) and #65952 (rationalized skipping). This is the missing primitive that would let a hook catch the specific failure in #65952.

Environment

• Claude Code 2.1.140
• Model: claude-opus-4-8

Summary

Even with an approved plan, the agent makes unplanned scope changes (e.g. a refactor/decomposition not in the plan) and proceeds without re-entering planning or review. There is no harness-level notion of "declared scope," so hooks can gate which file types are edited but cannot gate whether an edit is within the approved plan.

What happened

With a locked, reviewed plan in hand, the agent decided mid-implementation to also decompose a large file (a sensible change, but outside the plan) and shipped it without the re-plan + adversarial-review step the workflow requires for scope changes. Strong CLAUDE.md rules did not prevent it; the only thing that would have is a mechanical gate, which did not exist because "scope changed" is not something a hook can currently detect -- a PreToolUse hook sees the tool input (file path, content) but has no reference to the approved plan/scope to compare against.

Impact

"Plan-then-execute" workflows can't be mechanically enforced. The agent treats a user instruction ("do X") as license to skip back into coding rather than re-entering the workflow, and there's no automated catch -- leaving the behavioral problem in #65952 unguardable.

Recommendation

1. A declared-scope primitive: let a session/plan declare the files, directories, or work units in scope, and surface that to PreToolUse hooks (e.g. an env var or a field on the tool-call event JSON) so a hook can block or warn on edits outside the declared scope.
2. Optionally, a plan-adherence signal the model itself receives when an edit target falls outside the declared plan, prompting a re-plan/confirm before acting.
3. More broadly: first-class support for treating user-defined process steps and plan scope as gateable state, not just advisory prompt text.