superplan-guard

name	superplan-guard
description	Use when a fix or behavior change needs the smallest durable test, check, or proof so the contract will fail loudly if it regresses.

Regression Guarding

Overview

Every important fix or behavior change should leave behind a guard.

Trigger

Use when:

• a bug was fixed
• a workflow contract changed
• the agent asks "what test should protect this?"
• a failure revealed a missing proof path

Core Rules

• identify the exact behavior worth protecting
• add the smallest credible guard that would fail before the bug returns
• prefer the repo's existing test or verification style
• guard the contract, not the incidental implementation
• keep the guard close to the changed behavior when possible

Forbidden Behavior

• adding broad noisy tests when one focused check would do
• testing implementation trivia instead of user-visible or contract-visible behavior
• skipping the guard because the fix feels obvious

Handoff

Likely follow-ons:

• superplan-tdd when the guard should be written before the full fix
• superplan-verify when the new guard becomes part of the proof path
• superplan-postmortem when the missing guard revealed a broader process gap