554fe520ea
- Introduced Rule 42: No Ontology Prefixes in Slot Names to enforce clean naming conventions. - Established Rule: No Rough Edits in Schema Files to ensure structural integrity during modifications. - Implemented Rule: No Version Indicators in Names to maintain stable semantic naming. - Created Rule: Ontology Detection vs Heuristics to emphasize the importance of verifying ontology definitions. - Defined Rule 50: Ontology-to-LinkML Mapping Convention to standardize mapping practices. - Added Rule: Polished Slot Storage Location to specify directory structure for polished slot files. - Enforced Rule: Preserve Bespoke Slots Until Refactoring to prevent unintended migrations during slot updates. - Instituted Rule 56: Semantic Consistency Over Simplicity to mandate execution of revisions in slot_fixes.yaml. - Added new Genealogy Archives Registry Enrichment class with multilingual support and structured aliases.
32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
# 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.
|