Review core clarification boundary

[rlippmann]

Summary

Review the architectural boundary between grammar recognition, deterministic engine repair, pending confirmation, and user/drafter-owned clarification.

This issue is a design review. It should not change behavior until the desired clarification policy has been agreed upon.

Motivation

As part of the planned 0.9 grammar extraction, the engine's clarification behavior should be audited independently of the grammar refactor.

The central question is:

When is the engine performing a uniquely recoverable, semantics-preserving repair, and when is it effectively inventing a different directive that should instead be supplied explicitly by the user or a future directive drafter?

Issue #187 is one concrete example of this broader architectural question.

Cases to review

• grammar-level premise near misses
• change premise when no premise exists
• set premise when a premise already exists
• replacement where the old item does not exist
• replacement where either item is prohibited (see Reconsider yes/no replacement-intent clarifications when either item is prohibited #187)
• any other branch where a yes/no confirmation authorizes a directive different from the one originally submitted

For each case, determine whether it is:

1. grammar recognition only
2. state-dependent conflict
3. uniquely recoverable deterministic repair
4. semantic rewrite that should be owned by the user or future directive drafter
5. ordinary clarification
6. pending yes/no confirmation

Acceptance criteria

• Document the intended clarification boundary.
• Identify which current behaviors should remain unchanged.
• Identify any behaviors recommended to change.
• Identify affected specifications, tests, regression fixtures, checkpoints, preview behavior, and conformance fixtures.
• Keep implementation work separate from the design review.