# Rule: Preserve Bespoke Slots Until Refactoring

**Identifier**: `preserve-bespoke-slots-until-refactoring`
**Severity**: **CRITICAL**

## Core Directive

**DO NOT remove or migrate "additional" bespoke slots during generic migration passes unless they are the specific target of the current task.**

## Context

When migrating a specific slot (e.g., `has_approval_date`), you may encounter other bespoke or legacy slots in the same class file (e.g., `innovation_budget`, `operating_budget`).

**YOU MUST**:
*   ✅ Migrate ONLY the specific slot you were instructed to work on.
*   ✅ Leave other bespoke slots exactly as they are.
*   ✅ Focus strictly on the current migration target.

**YOU MUST NOT**:
*   ❌ Proactively migrate "nearby" slots just because they look like they need refactoring.
*   ❌ Remove slots that seem unused or redundant without specific instruction.
*   ❌ "Clean up" the class file by removing legacy attributes.

## Rationale

Refactoring is a separate, planned phase. Mixing opportunistic refactoring with systematic slot migration increases the risk of regression and makes changes harder to review. "We will refactor those later."

## Workflow

1.  **Identify Target**: Identify the specific slot(s) assigned for migration (from `slot_fixes.yaml` or user prompt).
2.  **Execute Migration**: Apply changes ONLY for those slots.
3.  **Ignore Others**: Do not touch other slots in the file, even if they violate other rules (like Rule 39 or Rule 53). Those will be handled in their own dedicated tasks.