Refactor RotIDE by domain boundaries and ownership, extracting clearer modules, headers, and workflows without changing behavior or forcing heavyweight enterprise DDD patterns.
37:["$","$L3f",null,{"content":"\n# Rotide Domain Refactor\n\nUse this when the main task is code ownership cleanup: splitting oversized modules, narrowing headers, or moving behavior to a clearer home.\n\n## First Inspect\n\n1. Read AGENTS.md, the touched modules, and references/domain-playbook.md.\n2. Name the domain and invariant boundary before moving code.\n3. Check the matching domain test file before and after the extraction.\n\n## Guardrails\n\n- Keep editorDocument canonical for writable text.\n- Keep struct erow rows derived, never authoritative.\n- Prefer domain names over technical accident names.\n- In C, “domain boundary” usually means:\n - file ownership\n - header ownership\n - state ownership\n - who is allowed to mutate what\n- Avoid umbrella headers that re-export half the system.\n- Avoid introducing abstraction layers that do not reduce real coupling.\n- Refactors should reduce cognitive load for a human reader.\n\n## References\n\n- references/domain-playbook.md\n","frontMatter":{"name":"rotide-domain-refactor","description":"Refactor RotIDE by domain boundaries and ownership, extracting clearer modules, headers, and workflows without changing behavior or forcing heavyweight enterprise DDD patterns."}}]