Documentar boundaries de ownership de artefactos y configs en cortex-dots

[barbatdev]

Objetivo

Documentar con claridad los boundaries de ownership en cortex-dots para que el repo siga siendo standalone, OSS-safe e instalable sin acceso a otros repos privados.

Alcance

Esta issue es de documentación y alineación de ownership. No implica cambios de código ni que cortex-dots deje de ser un repo independiente.

Qué se busca dejar explícito

• qué artefactos, configs y ejemplos son propios de cortex-dots
• qué artefactos pueden existir como ejemplo, referencia o adaptación local, pero no como source of truth de producto
• qué integraciones específicas de Cortex deben tratarse como boundary de ownership documentado, sin exigir acceso a repos privados
• cómo mantener la auditoría OSS para evitar leaks personales, organizacionales o privados

Áreas a revisar en la documentación

• README de instalación y alcance del repo
• documentación de artefactos/configs incluidos en cortex-dots
• aclaraciones sobre ejemplos, helpers, themes, hooks o statusline que puedan generar confusión de ownership

Resultado esperado

La documentación debe dejar claro que:

• cortex-dots sigue siendo un repo standalone de dotfiles OSS-safe
• el repo puede incluir configuraciones y ejemplos útiles por sí mismo
• cuando exista un boundary de ownership con artefactos de Cortex, ese boundary se explica como documentación, no como requisito de acceso ni de instalación
• no se presenta a cortex-dots como source of truth de artefactos product-owned de Cortex

Criterios de aceptación

• El título y la descripción de esta issue reflejan un problema de boundary/ownership documental, no de acoplamiento del repo
• El README explica qué artefactos pertenecen a cortex-dots y cuáles deben entenderse como ejemplos o no-source-of-truth respecto de Cortex
• La redacción preserva que cortex-dots sea instalable y útil sin acceso a repos privados
• La auditoría OSS sigue siendo consistente con este boundary documental

[barbatdev]

Aclaración: cortex, cortex-dotfiles y cortex-dots siguen siendo repos independientes. En particular, cortex-dots no debe depender de cortex para instalarse o usarse: tiene que seguir siendo standalone y OSS-safe para gente sin acceso a cortex. La migración trata ownership de integraciones UX de Cortex y evitar que cortex dependa de dotfiles externos; no convierte a cortex-dots en consumer obligatorio de cortex. Puede mantener configs/ejemplos propios, pero no debería ser la source of truth de artefactos product-owned de Cortex.

[barbatdev]

Sugerencia para preservar independencia de cortex-dots: evitar lenguaje de consumer/upstream. Propuestas puntuales:

• Cambiar “snapshot/consumer de dotfiles OSS-safe” por “repo standalone de dotfiles OSS-safe”.
• Cambiar “documentar la dependencia/relación con cortex” por “documentar el boundary de ownership con cortex, sin requerir acceso a cortex”.
• Cambiar “después de la migración upstream” por “después de que cortex defina ownership de esos artefactos”.
• Cambiar el criterio “README explica qué viene de cortex” por “README explica qué artefactos son propios de cortex-dots y cuáles son ejemplos/no-source-of-truth respecto de Cortex, sin requerir acceso a cortex”.
  Cortex-dots debe seguir siendo instalable y útil aunque el usuario no tenga acceso a cortex.