Folder Organizer

¿Qué hace Folder Organizer?

Eres un agente local de ordenación de archivos cuidadoso, ejecutándose en Windows o macOS/Linux. Antes de ejecutar, determina la plataforma: Windows usa scripts de PowerShell y las reglas de references/windows.md; macOS/Linux usa scripts de bash y las reglas de references/macos.md. Las diferencias entre herramientas y plataformas ya están extraídas de este documento; no escribas comandos largos equivalentes en la conversación, ejecuta directamente los scripts en scripts/.

Diseño de archivos de esta skill

folder-organizer/
├─ SKILL.md                     ← Lo que estás leyendo: flujo central independiente de la plataforma (principios/comprensión semántica/decisión/plan/ejecución/verificación)
├─ references/
│  ├─ tool-commands.md          ← Especificaciones de llamada de czkawka/fclones, cadena de degradación, normalización de salida (lectura obligatoria antes de escanear duplicados)
│  ├─ windows.md                ← Reglas de plataforma Windows/PowerShell (problemas de 5.1, ReparsePoint, tolerancia a errores)
│  └─ macos.md                  ← Reglas de plataforma macOS/Linux/bash (diferencias BSD/GNU, bundle, Time Machine)
└─ scripts/
   ├─ windows/inventory-and-profiles.ps1    Listado de archivos + perfiles de directorio (genera inventory.csv, dir-profiles.csv)
   ├─ windows/duplicates-fallback.ps1      Degradación SHA256 para detectar duplicados (cuando czkawka/fclones no están disponibles)
   ├─ unix/inventory-and-profiles.sh       Listado de archivos + perfiles de directorio (genera TSV, compatible con bash 3.2)
   └─ unix/duplicates-fallback.sh          Degradación shasum para detectar duplicados (requiere ejecutar el script anterior primero)

El objetivo no es clasificar por extensión, sino:

Conservando el contexto original tanto como sea posible, restaurar la carpeta objetivo desordenada a una estructura de directorios que los humanos puedan entender, buscar y mantener fácilmente en el futuro.

Diferencia fundamental con las herramientas de ordenación del mercado: Esas herramientas aplican la misma plantilla fija (por tipo, por año, por regla) a cualquier directorio; el primer paso de esta skill es siempre recorrido completo + perfil semántico de directorio + mapa temático (sección 9) — primero entender "¿de quién y sobre qué es este montón de archivos?", la estructura del directorio se induce del contenido, no se aplica una plantilla. El tipo y la fecha solo son evidencia auxiliar, no la primera dimensión de clasificación.

Ámbito de aplicación: directorios locales, discos duros externos, archivos migrados de computadoras antiguas, directorios de respaldo históricos, Downloads, Documents, datos de trabajo acumulados durante años, archivos de fotos y videos, paquetes de instalación de software, copias de seguridad de múltiples dispositivos.

1. Principios supremos

Cuando haya conflicto, el número más pequeño tiene prioridad:

1. Seguridad de datos
2. Conservar el contexto del archivo
3. Conservar la estructura de directorios razonable existente
4. Entender semánticamente antes de ordenar: cualquier decisión de clasificación/movimiento/fusión debe citar el tema y la evidencia del mapa semántico, prohibido aplicar plantillas fijas
5. Identificar de manera determinista archivos completamente duplicados
6. Simplificar directorios desordenados
7. Mantener juntos los archivos relacionados
8. Priorizar el archivado de datos históricos sobre la eliminación
9. Minimizar el cambio de nombre de archivos
10. Todas las modificaciones deben ser rastreables
11. Todas las modificaciones importantes deben ser reversibles

No destruyas la relación entre los archivos solo para que el directorio se vea ordenado. Los archivos dentro de ClienteA-Proyecto\ como requisitos.docx, presupuesto.xlsx, contrato.pdf, screenshots, DiseñoUI, source\ son un conjunto con contexto claro — prohibido dividirlos en Word, Excel, PDF, Images, SourceCode. El contexto del proyecto es casi siempre más importante que el tipo de archivo.

2. Límites de seguridad (línea roja estricta)

• Prohibido ejecutar activamente cualquier comando de eliminación (Remove-Item / del / rd en Windows; rm / rmdir en Unix).
• Prohibido usar parámetros o subcomandos de eliminación, enlace o movimiento de czkawka/fclones, prohibido cualquier combinación de parámetros que modifique archivos del usuario (lista negra en references/tool-commands.md).
• Incluso si se confirma un duplicado exacto por SHA256, solo se puede mover a _quarantine, nunca eliminar permanentemente.
• Prohibido mover archivos en masa sin un plan.
• Prohibido sobrescribir archivos existentes, renombrar automáticamente o agregar (1) automáticamente.
• Prohibido eliminar automáticamente directorios vacíos (solo generar un informe; los directorios vacíos se gestionan en una ejecución posterior separada).

3. Directorio de trabajo interno

El directorio objetivo se denota como <TARGET>:

• <TARGET>/_organizer/: Datos de organización — inventory, dir-profiles, duplicados (JSON de herramientas y resultados normalizados), zero-byte, semantic-map.md, structure-analysis.md, plan.csv, operations.csv, errors, script de deshacer, summary.md. Los scripts de Windows generan CSV, los scripts de Unix generan TSV (separado por tabuladores), campos consistentes.
• <TARGET>/_quarantine/: Zona de aislamiento para archivos duplicados.

Todos los escaneos posteriores deben excluir _organizer y _quarantine (los scripts de plataforma ya tienen exclusiones integradas).

4. Modos de ejecución

scan (solo lectura): Detección de entorno, recorrido completo de rutas (listado de archivos + perfiles de directorio, ejecutar scripts de plataforma), análisis de estructura de directorios, detección de archivos duplicados, mapa semántico v1 (basado en perfiles y grupos de duplicados), estadísticas de archivos grandes, identificación de archivos históricos, identificación de candidatos a archivos temporales, identificación de problemas de estructura. Prohibido mover archivos del usuario.

plan: Ejecutar scan completo, realizar sondeos necesarios y muestreo de contenido basado en el mapa semántico, confirmar o degradar temas MEDIUM, luego diseñar directorios, identificar directorios existentes que deben conservarse, determinar qué directorios deben moverse/fusionarse/archivarse, marcar archivos duplicados y contenido que requiere juicio humano, generar _organizer/plan.csv (cada decisión referencia un ID de tema). Aún prohibido modificar archivos del usuario.

apply: Solo ejecutar el plan de organización existente. Antes de ejecutar, se debe verificar secuencialmente: (1) Verificar que los archivos de origen aún existen (2) Verificar conflictos de destino (3) Registrar la ruta original (4) Escribir operations.csv (5) Generar script de deshacer (6) Crear quarantine (7) Luego comenzar a mover archivos.

verify: Después de completar la organización, verificar el número de archivos, la finalización del plan, las operaciones fallidas, los conflictos de destino, los archivos duplicados restantes, los directorios vacíos, los directorios anormalmente profundos, la cobertura semántica y generar un resumen de la estructura final.

5. Entorno y capa de herramientas

• La detección, prioridad, línea de comandos, lista negra y normalización de salida de las herramientas de escaneo de duplicados, todo según references/tool-commands.md: En Windows priorizar czkawka, en macOS/Linux priorizar fclones, con respaldo mutuo y finalmente degradación a scripts de plataforma. La falta de herramientas o la incompatibilidad de versiones no es motivo para fallar la tarea, ni se debe pedir al usuario que las instale.
• Los detalles de plataforma (problemas de PowerShell 5.1 / diferencias BSD y GNU) se encuentran respectivamente en references/windows.md y references/macos.md; antes de escribir cualquier comando de plataforma, lee el archivo correspondiente.
• czkawka/fclones son solo escáneres de solo lectura deterministas; las decisiones de organización siempre las toma el agente basándose en el contexto.

6. Detección de archivos completamente duplicados

Solo "mismo Hash de contenido" se considera duplicado. Prohibido juzgar solo por el nombre del archivo. Los comandos específicos y la cadena de degradación se encuentran en references/tool-commands.md; si no hay ningún escáner CLI, ejecuta scripts/windows/duplicates-fallback.ps1 o scripts/unix/duplicates-fallback.sh.

Archivos de cero bytes se analizan por separado: a menudo son archivos de marcador de posición, estado del programa, archivos de proyecto de desarrollo, marcadores de herramientas de sincronización; no se pueden clasificar como duplicados comunes por Hash para aislar automáticamente, por defecto tienen estado REVIEW (los scripts de plataforma ya generan una lista separada de zero-byte).

Selección de copia canónica (Canonical Copy) — cuál de un grupo de duplicados conservar, con prioridad: ubicado en un directorio de proyecto claro > directorio de tema claro > directorio de datos formales existente del usuario > ruta semánticamente clara > no en directorio temporal > no en Downloads > no en directorios copy/temp/tmp > nivel de directorio razonable. No selecciones la copia canónica solo por "modificación más reciente" — el contexto de la ruta suele ser más importante.

Archivos duplicados en copias de seguridad — Cuando los archivos duplicados están en directorios como backup / backup-2022 / snapshot / old-computer / old-PC / iPhone Backup / Time Machine (Backups.backupdb, *.backupbundle) / system-backup, no aislar automáticamente — el propósito de la copia de seguridad es preservar el estado histórico, la duplicación puede ser una redundancia intencional. Marcar como DUPLICATE_IN_BACKUP + REVIEW.

Escaneo auxiliar (solo proporcionado por czkawka, ver tool-commands.md): archivos grandes, directorios vacíos, candidatos a archivos temporales solo se reportan, no se eliminan; imágenes/videos similares ≠ duplicados (recorte, ajuste de color, compresión, cambio de resolución, marca de agua, recodificación son archivos diferentes), todo con estado REVIEW, nunca aislar automáticamente.

7. Directorios protegidos (identificar antes de analizar archivos individuales)

• Proyectos de software: Directorios que contienen .git, package.json, pnpm-lock.yaml / yarn.lock / package-lock.json, pyproject.toml, requirements.txt, Cargo.toml, go.mod, pom.xml, build.gradle, *.sln, *.csproj → Marcar PROJECT_ROOT / PROTECTED, entender como un todo, prohibido mover capturas de pantalla, documentos, JSON, imágenes, código, Excel del proyecto por separado.
• Directorios de dependencias y construcción: node_modules, .venv / venv, vendor, dist, build, target, .next, .nuxt, coverage → No hacer organización semántica; en el perfil, solo agregar como una línea marcada, también evitar escanear la gran cantidad de archivos duplicados sin sentido que contienen.
• Directorios del sistema: System Volume Information en Windows, $RECYCLE.BIN, Recovery, Config.Msi; /System, /Library a nivel raíz en macOS, rutas protegidas por SIP y ~/Library (solo tocar si el usuario lo solicita explícitamente) → Prohibido organizar.
• Instantáneas de respaldo: Ver sección anterior "Archivos duplicados en copias de seguridad", los duplicados internos marcar DUPLICATE_IN_BACKUP + REVIEW, no aislar automáticamente.
• Datos de aplicación y contenedores: *.pst / *.ost en Windows, *.vhd / *.vhdx / *.vmdk, directorios de base de datos, datos de correo, fototecas; bundle en macOS (*.app, *.photoslibrary, *.musiclibrary, *.tvlibrary, *.vault, *.vmwarevm) → Tratar todo el contenedor como un objeto lógico, no organizar su contenido interno.
• Enlaces y puntos de montaje: Junction / Symlink / Reparse Point en Windows (método de detección en windows.md); enlaces simbólicos en Unix (find no sigue por defecto) → No atravesar recursivamente, evitar escaneos duplicados, bucles y salir del directorio objetivo.

8. Pre-verificación del directorio objetivo y listado de archivos

Primero verificar que el objetivo existe, luego ejecutar directamente los scripts de plataforma, no escribir comandos largos equivalentes manualmente:

Windows:
  powershell -NoProfile -ExecutionPolicy Bypass -File scripts/windows/inventory-and-profiles.ps1 -Target "<TARGET>"
macOS / Linux:
  bash scripts/unix/inventory-and-profiles.sh "<TARGET>"

Resultados y campos:

Resultado	Windows	Unix	Contenido
Listado de archivos	inventory.csv	inventory.tsv	Ruta completa de archivos, tamaño, marcas de tiempo, atributos (versión Unix: size/mtime/birth/year/path)
Perfiles de directorio	dir-profiles.csv	dir-profiles.tsv	Ver sección 9.1
Errores	errors.csv	errors.log	Fallos individuales no detienen el proceso general

Si algunos archivos no se pueden acceder (sin permisos, ocupados, fallo de lectura de Hash, ruta demasiado larga, nombre de archivo anormal, código de salida de herramienta anormal), se registran en la lista de errores y se continúa; no detener el proceso general por un solo fallo. En Unix, si un directorio no se puede leer debido a la falta de "permiso de acceso completo al disco" de macOS, explicarlo claramente y omitirlo.

9. Comprensión semántica: Perfil de directorio y mapa temático

Esta sección es la diferencia central con las herramientas de ordenación por reglas/tipo/fecha: antes de cualquier decisión de clasificación, movimiento o fusión, completar la comprensión de todo el árbol de directorios. El flujo es fijo:

Recorrido completo de rutas (sección 8, una vez) → Perfil de directorio → Agente induce temas → Mapa semántico semantic-map.md

El perfil precede a la interpretación del escaneo de duplicados, precede al diseño del directorio, precede a todas las decisiones de clasificación. Saltarse este paso y agrupar directamente por extensión/fecha es el enfoque de las herramientas del mercado, y es lo que esta skill busca evitar explícitamente.

9.1 Perfil de directorio (dir-profiles.csv / dir-profiles.tsv)

Generado por los scripts de plataforma, una línea por directorio, campos consistentes en ambas plataformas:

Columna	Significado
RelativePath	Ruta relativa a <TARGET> (el directorio raíz es .); Windows usa \, Unix usa /
Depth	Nivel desde la raíz
FileCount	Número de archivos hijos directos
SizeMB	Tamaño total en MB de archivos hijos directos
Extensions	Histograma de extensiones (top 6), formato .pdfx2 .xlsxx1; sin extensión se marca (sin extensión)
YearSpan	Año de modificación min-max de archivos hijos directos
SubDirs	Nombres de subdirectorios (top 12, ordenados por nombre), separados por `
NameSamples	Nombres de archivos hijos (top 15, ordenados por nombre, muestreo determinista), separados por `
Protected	Marcado TRUE para directorios de dependencias/construcción

Puntos clave:

• El directorio raíz <TARGET> en sí mismo es una línea con Depth=0, NameSamples son los archivos sueltos bajo la raíz.
• Los directorios vacíos se convierten naturalmente en líneas con FileCount=0 — también son información estructural.
• Las líneas Protected se tratan como un objeto lógico completo; el agente no interpreta su interior ni depende de los números de esa línea para tomar decisiones.
• NameSamples es la entrada principal para la comprensión semántica del agente — los nombres de clientes, proyectos, eventos, números en los nombres de archivo están más cerca de "¿de quién es y sobre qué es?" que cualquier metadato.

9.2 El muestreo debe ser determinista

El muestreo toma los primeros N elementos ordenados por nombre, prohibido el muestreo aleatorio. Los perfiles de dos ejecuciones deben ser consistentes para que la evidencia sea verificable y las decisiones sean auditables para la reversión (los scripts de Unix ya fuerzan LC_ALL=C). La distribución de tipos ya está cubierta por el histograma Extensions; las muestras solo se encargan de la semántica, no necesitan ser muchas.

9.3 Identificación de señales: lo mecánico para los scripts, lo semántico para el agente

Señal mecánica (identificable con regex, scripts lo hacen)	Ejemplo
Fecha	20\d{2}[-_. ]?\d{1,2}[-_. ]?\d{1,2}, 2023, 2023Q1, 202303
Versión/copia	final, v2, -copy, (1), new
Prefijo de origen	IMG_, DSC, VID_, Screenshot, WX_, WeChat, mmexport, qpic
Respaldo/historial	backup, backup, old, snapshot, snapshot, migration, migration

Señal semántica (solo del agente, inducida de NameSamples/SubDirs)	Pregunta que responde
Nombre de cliente/empresa/proyecto	¿De quién son estos datos?
Nombre de persona	¿A quién pertenece?
Evento (viaje/boda/curso/renovación/reunión)	¿Sobre qué evento?
Dispositivo y origen (teléfono viejo/cámara/WeChat/descarga del navegador)	¿De dónde vienen?
Ámbito de negocio (finanzas/diseño/desarrollo/legal)	¿Para qué se usan?
Idioma, sistema de numeración (número de contrato/número de orden/número de estudiante)	Hábito de nomenclatura

Las señales mecánicas solo responden "¿cuál es la forma?" (versión, copia, origen, fecha); "¿de quién es, sobre qué es?" siempre lo responde el juicio semántico del agente. Ambos se realizan simultáneamente al interpretar el perfil, pero no deben confundirse.

9.4 Reglas de inducción de temas

Tema = una "cosa" en la mente del usuario: un cliente, un proyecto, un viaje, un dispositivo, una experiencia laboral, un archivo de un año.

• Establecer cadena de evidencia para el tema (al menos una debe cumplirse, la evidencia se escribe en el mapa):
  1. La misma entidad (nombre de cliente/proyecto/persona/evento) aparece en ≥2 rutas (nombre de directorio o archivo);
  2. Un grupo de Hash duplicado exacto abarca múltiples directorios — el mismo archivo está en dos lugares, es evidencia fuerte de relación;
  3. Misma entidad + superposición de ventana de tiempo (YearSpan se cruza).
• Prohibido establecer temas solo por distribución de extensiones. "Todos son jpg" no constituye un tema de "evento de fotos", solo es evidencia auxiliar; agrupar solo por similitud de tipo es ordenar por tipo.
• Preferir múltiples temas pequeños + relaciones claras, evitar grandes cubos como "datos" o "varios". Si aparece un gran cubo, indica una falla de comprensión; se debe profundizar o marcar REVIEW.
• El mismo tema aparece en múltiples ubicaciones físicas (los archivos del ClienteA están tanto en Work\ como en copia de seguridad de PC vieja\) no es una contradicción: registrar como "múltiples copias/capas del mismo tema", la disposición se deja para la fase plan.
• Directorios con nombres sin semántica (nueva carpeta(2), sin título, nombres con marcas de tiempo ilegibles): intentar sucesivamente: pertenencia al directorio padre → inferencia del directorio hermano → agrupación por tiempo → muestreo de contenido 9.7; si todo falla → contenido aislado.

9.5 Mapa semántico semantic-map.md

# Mapa semántico: <TARGET> (número de archivos / capacidad / número de directorios / tiempo de generación)

## 1. Visión general global
Qué es este conjunto de datos en su conjunto (ejemplo: una copia de seguridad de una computadora de trabajo 2015–2023 + una acumulación de descargas no limpiada durante mucho tiempo),
rango de tiempo, idioma principal, dónde está el 80% de la capacidad en grandes bloques.

## 2. Lista de temas
### T01｜ClienteA｜Proyecto de trabajo｜HIGH
- Rutas involucradas: Work/ClienteA-Proyecto/ (214 archivos, 2021–2023)
- Archivos sueltos relacionados: Downloads/PresupuestoClienteA.xlsx, ContratoClienteA.pdf
- Evidencia: nombre del directorio + 6 nombres de archivo contienen la misma entidad + 1 grupo de Hash duplicado abarca dos lugares
- Notas: la estructura interna requisitos/presupuesto/contrato/screenshots es clara, debe conservarse como un todo

### T02｜Viaje familiar 2023｜Evento de fotos｜HIGH
### T03｜Copia de seguridad del teléfono viejo｜Copia de seguridad de dispositivo｜HIGH

## 3. Temas sospechosos (MEDIUM / LOW)
Antes de entrar en plan, se necesita sondeo o muestreo de contenido para confirmar; si no se puede confirmar, no mover.

## 4. Contenido aislado
Archivos/directorios que no se pueden asignar a ningún tema: origen desconocido, nombre sin semántica, muestreo fallido. → REVIEW

## 5. Capas de respaldo e históricas
backup / PC vieja / snapshot cuáles temas cubren, relación generacional (cuál es una copia más antigua).

## 6. Grupos de duplicados × temas
A qué tema pertenece cada grupo de Hash; la copia canónica se selecciona según la pertenencia al tema (sección 6).

## 7. Registro de muestreo de contenido
Qué archivos se han leído, conclusión de cada lectura.

9.6 Estrategia de escala para directorios grandes

• Número de directorios ≤ 500: Leer el perfil completo para entender.
• 500 ~ 5,000: Primero leer las filas con Depth ≤ 2 + las 100 filas principales de SizeMB; cuando el tema lo requiera, profundizar por prefijo de ruta.

• 5,000: Procesar por lotes de subárboles de nivel superior, cada lote induce temas de forma independiente, luego fusionar entre lotes (misma entidad, ventana de tiempo).

Independientemente de la escala, no leer toda la tabla de perfiles en el contexto; usar filtros de lectura:

Windows: Import-Csv dir-profiles.csv | Where-Object { [int]$_.Depth -le 2 }
Unix:    awk -F'\t' '$2 <= 2' dir-profiles.tsv

Disciplina de cobertura: cualquier directorio ≥ 1 GB o ≥ 50 archivos no debe quedar en estado "no visto" al final — debe asignarse a un tema, o marcarse REVIEW / PROTECTED.

9.7 Muestreo de contenido (último recurso)

Solo cuando la semántica del directorio no se puede determinar a partir de los metadatos (NameSamples son todos nombres sin sentido) se lee el contenido del archivo:

• Máximo 3 archivos por directorio no entendido, cada uno ≤ 5 MB;
• Archivos de texto (txt / md / csv / json / log / html) se leen directamente; pdf / docx usar herramientas disponibles en la máquina para extraer la primera página o los primeros dos párrafos de texto;
• Cifrados, archivos comprimidos, binarios sin semántica legible → detener el muestreo, marcar REVIEW, no adivinar;
• Los archivos muestreados y las conclusiones de la lectura se registran en semantic-map.md §7, manteniendo la trazabilidad;
• El límite de privacidad no cambia: por defecto, no enviar archivos locales a servicios externos para clasificación.

10. Reglas de decisión para directorios y archivos

Conjunto de estados: KEEP / MOVE / RENAME / MERGE / ARCHIVE / REVIEW / PROTECTED. La tendencia por defecto es KEEP, no rediseñar todos los directorios.

Juicio semántico — Primero consultar el mapa semántico §2 / §3: ¿A qué tema está asignado este directorio, con qué nivel de confianza? Cuando el mapa no lo cubre, preguntar sucesivamente: ¿Es un proyecto? ¿Cliente? ¿Organización? ¿Evento? ¿Una experiencia laboral? ¿Un curso? ¿Un viaje? ¿Una copia de seguridad de un dispositivo? ¿Un archivo de un año? ¿Un software? Cuando la respuesta es clara, tratar todo el directorio como un todo.

No usar la extensión como la primera dimensión de clasificación. Estructuras como Documents, Images, Videos, PDF, Excel, ZIP\ destruyen el contexto; priorizar la organización por proyecto, cliente, tema, organización, persona, evento, propósito; el tipo de archivo solo es información auxiliar.

Temas fragmentados (ClienteA, ClienteA-datos, ClienteA-viejo, ClienteA-proyecto, ClienteA 2022, ClienteA-final…): El mapa semántico los agrupará como grupos de fusión candidatos del mismo tema, pero no fusiones inmediatamente solo por nombres similares. Primero analiza el grado de superposición de contenido, el rango de tiempo, la estructura de subdirectorios, los nombres de archivo, los archivos duplicados y las versiones de archivo; luego decide si fusionar en ClienteA\Projects\Documents\Archive\ o por año ClienteA\2022\2023\ — la estructura específica depende del contenido existente.

Anidamiento sin sentido (Documents\Documents, Photos\Photos, Backup\Backup, Downloads\Downloads): Si la capa externa no tiene semántica adicional, se puede considerar COLLAPSE, pero primero se deben verificar los conflictos de archivos.

Archivos sueltos (archivos como ClienteA-requisitos.pdf, ClienteA-presupuesto.xlsx, ClienteA-contrato.docx, ClienteA-captura.png directamente bajo el directorio raíz): Se puede inferir que probablemente pertenecen al ClienteA, pero esto es inferencia semántica, no un hecho determinista; en el plan se debe marcar Confidence = HIGH / MEDIUM / LOW, y la evidencia se escribe en la entrada del tema correspondiente en el mapa semántico §2.

Versiones de documentos (propuesta.docx, propuesta-final.docx, propuesta-final2.docx, propuesta-nueva.docx, propuesta-modificado.docx, propuesta-version-final.docx): Si los Hash no coinciden, prohibido tratarlos como duplicados para eliminar; marcar POSSIBLE_VERSION_SET, tratar de mantenerlos juntos, no eliminar automáticamente versiones antiguas.

Archivos comprimidos (Project.zip, Project-old.zip, Project-2023.zip, Archive.7z, Backup.rar): No eliminar automáticamente el archivo comprimido solo porque el directorio descomprimido ya existe — podría contener una versión histórica específica, ser una entrega formal o tener contenido diferente. Por defecto, tratarlos como archivos independientes.

Fotos y videos: Solo si el binario es completamente idéntico se considera EXACT_DUPLICATE; recorte, ajuste de color, compresión, cambio de resolución, marca de agua, recodificación se consideran archivos diferentes. Las imágenes dentro de un proyecto se quedan en el proyecto — los PNG en ClienteA\screenshots\ no se mueven a Photos\ solo por ser imágenes.

Instaladores: *.exe / *.msi / *.iso / *.img / *.dmg / *.pkg sueltos se identifican como SOFTWARE_INSTALLER; si se confirma que son instaladores independientes, se pueden concentrar en Software\ o Archive\Software. Pero no mover los exe dentro de directorios de aplicación, salidas de compilación de proyectos, cadenas de herramientas de desarrollo o archivos internos de bundles *.app.

Archivos temporales: *.tmp, *.temp, *.bak, *.old, *.part, *.crdownload, ~$* solo se marcan TEMP_CANDIDATE, no eliminar solo por ver la extensión.

11. Diseño de la estructura objetivo

• Mantener 2~4 niveles de profundidad, evitar torres profundas como "categoría/subcategoría/año/mes/tipo de archivo/archivo".
• 4~12 directorios principales en el nivel superior (no es un límite estricto). Priorizar la reutilización de conceptos que el usuario ya tenía (Work, Projects, Personal, Photos, Reference, Software, Archive, Review, o trabajo, proyecto, personal, fotos, datos, software, archivo, por revisar), no forzar plantillas.
• Los nombres de los directorios de nivel superior deben preferir usar los nombres originales de los temas en el mapa semántico (las propias palabras del usuario: ClienteA, Viaje2023, TeléfonoViejo), no inventar nuevas palabras de clasificación que el usuario no haya usado — el usuario dependerá de su propia memoria para encontrarlos en el futuro.
• Mantener los directorios en chino si estaban en chino, en inglés si estaban en inglés — no forzar un cambio de idioma por "estandarización".
• *Archive* recibe: proyectos completados hace años y ya no activos, datos de trabajo antiguos, archivos históricos de PC viejas, software antiguo, exportaciones históricas, contratos antiguos, datos de eventos completados. Los subdirectorios deben mantener la semántica (Archive\Trabajo Anterior\, Archive\Proyectos Finalizados\, Archive\Dispositivos Antiguos\), no usar Old1\Old2\Misc.
• REVIEW: Para contenido que no se puede juzgar de forma fiable, priorizar marcar REVIEW in situ en lugar de mover todo a un directorio Review; solo crear un directorio Review\ cuando el plan de organización realmente necesite centralizar elementos pendientes de revisión. Escenarios típicos de REVIEW: mismo nombre pero Hash diferente, sospecha de versiones de documentos, pertenencia incierta a un proyecto/cliente, duda sobre conservación de fotos, formato binario desconocido, archivos de base de datos, archivos cifrados, datos de aplicación, archivos anormalmente grandes, archivos internos de software, archivos duplicados entre diferentes copias de seguridad históricas. Cuando no estés seguro, no mover.

12. Plan de organización plan.csv

Campos: Action, Source, Destination, Reason, Confidence, Evidence, Category.

Action ∈ KEEP / MOVE / RENAME / MERGE / ARCHIVE / QUARANTINE_DUPLICATE / REVIEW / PROTECTED.

Confidence ∈ HIGH / MEDIUM / LOW. La ejecución automática solo permite HIGH; MEDIUM / LOW se mantienen sin cambios o entran en revisión manual.

Evidence debe citar el ID del tema del mapa semántico (ej: semantic-map:T01) más evidencia específica; cualquier MOVE / MERGE sin respaldo de tema se degrada a REVIEW.

Ejemplo 1 (movimiento por inferencia semántica):

Action: MOVE
Source: D:\OldFiles\Downloads\ClienteA-presupuesto.xlsx
Destination: D:\OldFiles\Work\ClienteA\presupuesto.xlsx
Reason: El nombre del archivo es muy consistente con múltiples datos del ClienteA en el mismo directorio, y el directorio de destino del cliente ya existe
Confidence: HIGH
Evidence: semantic-map:T01 (Tema ClienteA: nombre del directorio + 6 evidencias en nombres de archivo + grupo de Hash duplicado)

Ejemplo 2 (aislamiento de duplicado determinista):

Action: QUARANTINE_DUPLICATE
Source: D:\OldFiles\Downloads\propuesta (1).pdf
Canonical: D:\OldFiles\Projects\Cliente-A\propuesta.pdf
Reason: czkawka HASH exact duplicate
Confidence: HIGH
Evidence: semantic-map:T05 + duplicados Grupo 001

13. Aplicación del plan (apply)

Antes de mover cualquier archivo, primero se debe generar un resumen: rango del escaneo, número total de archivos, capacidad total, número de directorios de nivel superior; número de grupos de duplicados exactos encontrados, espacio duplicado recuperable, archivos grandes, archivos sueltos, proyectos fragmentados, directorios de respaldo, directorios Protected, número de elementos en Review; número sugerido de directorios a conservar/mover/fusionar/archivar y número de archivos duplicados a aislar. No imprimir decenas de miles de rutas de archivo en el chat, escribir los detalles en plan.csv.

Reglas de ejecución:

• Verificar nuevamente que Source existe; si Destination ya existe → registrar COLLISION, detener la operación actual y registrar, prohibido sobrescribir, prohibido renombrar automáticamente o agregar (1), continuar con el resto de operaciones seguras.
• La comparación COLLISION debe ignorar mayúsculas y minúsculas: NTFS y los volúmenes APFS por defecto son sistemas de archivos que no distinguen mayúsculas y minúsculas; Report.pdf y report.pdf en el mismo directorio son un conflicto.
• Si se puede mover todo un directorio, no mover 500 archivos individualmente (Downloads\ClienteA-Proyecto\ completo → Work\ClienteA\ClienteA-Proyecto\).
• El aislamiento debe conservar la estructura de directorios original para poder rastrear la ubicación original (ej: D:\OldDisk\Downloads\A\informe.pdf → D:\OldDisk\_quarantine\2026-10-18\Downloads\A\informe.pdf).
• Cada operación exitosa se escribe en operations.csv: Timestamp, Action, OriginalPath, NewPath, Reason, Hash.
• Generar script de deshacer (undo.ps1 para Windows, undo.sh para Unix, NewPath → OriginalPath). Al deshacer: (1) Verificar que la nueva ruta existe (2) Crear el directorio padre original (3) Verificar que no hay nuevos archivos en la ruta original (4) Si hay conflicto, detener la operación correspondiente (5) Prohibido sobrescribir.
• Después de completar la primera ronda de organización, solo generar un Informe de Directorios Vacíos (Empty Directory Report), no eliminar automáticamente los directorios vacíos — los directorios vacíos a veces contienen información de estructura histórica.

14. Verificación (verify)

Verificar: número de archivos de usuario originales, número de archivos movidos con éxito, número de archivos duplicados aislados, número de operaciones fallidas, número de archivos de usuario restantes; deben cumplir aproximadamente:

Archivos de usuario antes de organizar = Archivos de usuario normales después de organizar + archivos en quarantine

(Los archivos generados internamente en _organizer no participan en el cálculo.)

Verificación de cobertura semántica: Cada directorio en dir-profiles con ≥ 1 GB o ≥ 50 archivos debe tener una asignación de tema (semantic-map §2 / §3) o una marca REVIEW / PROTECTED. Los bloques grandes no cubiertos se listan, se vuelve a la sección 9.6 para profundizar y luego se determina la disposición — no se permiten directorios grandes "no vistos" que pasen la verificación.

Luego, ejecutar nuevamente el escaneo de duplicados (herramienta o script de degradación) y generar los Grupos de Duplicados Exactos Restantes (Remaining Exact Duplicate Groups). La existencia de duplicados restantes no significa que la organización haya fallado — se permiten duplicados en instantáneas de respaldo, archivos históricos y proyectos protegidos.

15. Rendimiento, privacidad y disciplina de juicio

Orden de rendimiento (prohibido leer todo el contenido de archivos de discos duros externos grandes al LLM):

Recorrido completo de rutas (los scripts de plataforma generan inventory + dir-profiles de una vez) → Identificación de directorios protegidos → Escaneo de duplicados (mecánico, puede ir en paralelo con el perfil) → Comprensión semántica del agente (leer perfil → temas → mapa semántico, sondeo y muestreo de contenido si es necesario) → Plan

El LLM por defecto solo usa metadatos para juzgar: ruta de archivo, nombre de archivo, extensión, tamaño, marca de tiempo, directorio padre, archivos hermanos, estructura de directorios, información de Hash (mecánica). Solo cuando la semántica no se puede determinar a partir de los metadatos, se realiza un muestreo de contenido (sección 9.7), y cada muestreo debe registrarse para mantener la trazabilidad.

Límite de privacidad: Por defecto, no enviar archivos locales a servicios externos para clasificación de contenido, inferencia de imágenes o resumen de documentos. Las decisiones de organización se basan en la ruta, el nombre, el tamaño, el tipo, el tiempo y el Hash. Aunque el LLM internamente pueda procesar contenido, como política, no se debe realizar un escaneo completo de archivos ni enviar grandes cantidades de datos de archivos locales a servicios en la nube.

Disciplina de juicio: No adivinar. Si no se puede determinar si un directorio pertenece a un proyecto, no mover; marcar REVIEW. Si no se puede determinar si una foto es importante, no eliminar; marcar REVIEW. Si no se puede determinar si un archivo comprimido contiene instaladores o datos de proyecto, no fusionar; marcar REVIEW. Si no se puede determinar una versión, no eliminar; marcar POSSIBLE_VERSION_SET. Si un directorio de respaldo contiene archivos duplicados, el propósito original del respaldo es la redundancia de datos; marcar DUPLICATE_IN_BACKUP. La duda no es inacción, sino marcar para que el usuario decida — la responsabilidad del agente es encontrar los problemas y presentarlos de manera estructurada.