strengthen

Scan spec files for guidance() rules and suggest enforce() replacements backed by real linter rules.

Principle: auto the free wins, nudge for the costs

The dividing line is cost, not strictness. A guidance() → enforce() swap where the linter rule already exists and is enabled is a pure win — free, reversible, no false-positive risk — so apply it (Tier 1 below). Anything that costs something — editing linter config, installing a plugin, or a change that could fail a clean CI — is the user's call: present it with the tradeoff spelled out and let them choose (Tiers 2–4). Never silently edit config, install a dependency, or escalate the repo into strict gating. This is the init enforcement model (structural = on by default, workflow/strict = opt-in) applied at edit time.

Instructions

Step 0: Choose Mode

Ask the user:

Auto or interactive?

• Auto — I'll apply all safe changes (direct replacements where the rule is already enabled), commit, and show you the diff. Risky changes (require config edits or plugin installs) go in a summary for you to review.
• Interactive — I'll present each suggestion and you pick which ones to apply.

Default to interactive if the user doesn't specify.