🛡️ Stop unplanned machinery at Implementor checkpoints - #808

Why

PR #807 reached 6,447 changed lines because the implementation introduced a
diagnostic language and an authority protocol that its accepted plan had not
named, then completed every downstream migration and test before returning for
feedback. The existing Implementor role says to avoid speculative abstractions,
but it does not say when unexpected machinery or scope growth must stop work.

What changes

Before:

An Implementor stops for a material product or architecture choice, but can
still interpret a broad outcome as permission to invent a generic mechanism and
prove that mechanism exhaustively before the first feedback commit.

After:

The Implementor stops before adding an unplanned language, rule engine,
protocol, framework, package boundary, generic extension point, or compatibility
mechanism. It also stops when implementation crosses a planned PR slice,
materially exceeds the plan, expands the evidence matrix, or review feedback
would harden an unaccepted abstraction.

When a plan defines reviewable slices, each slice produces its own focused
feedback commit before the next begins. One issue is no longer treated as a
reason to combine independently mergeable work.

What must stay true

• Ordinary local implementation choices remain with the Implementor; the new
  checkpoint applies to unplanned architecture and material scope growth.
• The Implementor reports the concrete conflict and considered primitives
  without implementing the proposed framework while awaiting a decision.
• The existing focused-evidence and feedback-commit contract remains unchanged.

How to verify it

git diff --check

Read .agents/implementor.md from “Do not decide around the plan” through
“Feedback commits.” The stop conditions precede working discipline, and the
slice checkpoint precedes execution of the complete frozen evidence matrix.

Scope

Included

• Implementor complexity stop conditions.
• Early feedback commits for planned reviewable slices.

Intentionally unchanged

• Planner, Architect, Reviewer, and repository-wide instructions.
• Product code, tests, specifications, dependencies, and CI.
• PR ✨ Install structural Markdown syntax from a package (#806) #807 and issue Make structural Markdown expansion extensible by installed packages #806; their cleanup follows after this policy change lands.

Risks and limitations

• Implementors may return for an architecture decision more often. That is the
  intended outcome when the alternative is silently adding an unplanned
  framework.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• Generated or mechanical changes are clearly identified.
• The description matches the final diff and test results.