kempersc/glam
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
glam/.opencode/rules/linkml/preserve-bespoke-slots-until-refactoring.md
kempersc 554fe520ea Add comprehensive rules for LinkML schema management and ontology mapping 
- 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.
2026-02-15 19:20:09 +01:00

1.5 KiB
Raw Blame History

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.