Write refactor ledes as the change made, not the resulting state

[williamthorsen]

Problem

The lede generated for a refactor: change describes the state the codebase is in after the change rather than the change that was made. Every refactoring PR's lede is being rewritten by hand before merge.

Context

lede-voice.md Rule 1 names "refactor mechanics" among the things a sentence must not describe, and "The principle" routes refactor mechanics to ## Details. For a refactoring change the restructuring is the subject, so the rules leave the lede nothing to announce and it settles into describing the post-change system.

Rule 1 already carries three type-specific carve-outs — fix:, documentation, and agent-guidance — so a fourth has both precedent and a place to live.

Example from williamthorsen/workshop#292 (readyup|refactor, 29 modules regrouped into role directories).

Generated:

Finding a module in the readyup package now means asking what role it plays, instead of scanning a long undifferentiated list at the top of the source tree. A module that does not belong at that top level is now reported while it is being written, and each test now sits beside the code it covers.

Rewritten before merge:

Reorganizes the files in the readyup package for better usability and maintainability. Functions are now grouped by domain.

The generated version answers "how does the system work now?"; the merged version answers "what was done?".

Proposed solution

Add a refactor: carve-out to Rule 1 establishing that the restructuring is itself the outcome: the lede names what was reorganized, moved, extracted, renamed, or deleted, in change-verb voice, rather than the reader experience that follows from it.

The carve-out must settle its interaction with Rule 1's generic-puffery clause, which as written forbids "for better usability and maintainability" — the phrasing the merged example above uses.

Three consumers move together: lede-voice.md, the changelog-writer agent (which self-audits against the doctrine and cut the mechanism in the example above), and summarize-change, whose dispatch instruction directs the caller to keep outcome mechanism-free.

Acceptance criteria

Must have

• Rule 1 carries a refactor: carve-out naming the restructuring itself as the outcome.
• The carve-out states how it interacts with the generic-puffery clause.
• The carve-out carries a bad → good example pair in the format the section's other carve-outs use.
• changelog-writer and summarize-change no longer direct the subagent or its caller to strip refactor mechanics from a refactor: lede.
• Recomposing the workshop#292 lede under the revised doctrine yields a change-framed lede without hand rewriting.