Actualizador diario de wiki legal (mantenimiento desatendido)

---
name: actualizador-diario-wiki-legal
description: Mantiene al dia, en forma diaria y desatendida, una wiki legal creada con la skill constructor-wiki-legal. En cada corrida detecta documentos nuevos o cambiados en las carpetas de fuentes (causas, clientes, descargas/inbox) desde la ultima vez, los ingesta a la ficha del asunto que corresponda con citas trazables, revisa plazos y audiencias proximas o vencidas, corre un lint de salud (enlaces rotos, datos superados sin marcar, fichas sin estado), deja en una cola los archivos que no puede asignar con certeza y produce un informe diario, sin tocar ni borrar nunca las fuentes. USA ESTA SKILL cuando el usuario diga "actualiza la wiki", "corre el mantenimiento diario", "que cambio en mis causas hoy", "revisa documentos nuevos", "que vence esta semana", "informe diario de la wiki", o cuando una tarea programada la dispare cada manana. Companera de constructor-wiki-legal (que crea la wiki) y de las operaciones de ingesta/consulta/lint. NO crea la wiki desde cero (eso es constructor-wiki-legal) ni descarga expedientes de tribunales ni redacta escritos.
---

# Actualizador diario de la Wiki Legal

Skill companera de `constructor-wiki-legal`. La primera crea la wiki; esta la **mantiene viva cada dia**. Pensada para correr de forma programada (cada manana) o a pedido, idealmente desatendida, pero siempre segura: solo escribe archivos `.md`, nunca toca, mueve ni borra las fuentes, y cuando duda **no inventa**: deja el archivo en una cola de pendientes para que el abogado lo asigne.

## Lo que hace una corrida diaria (resumen)

1. Localiza la wiki y lee su esquema.
2. Detecta documentos nuevos o cambiados desde la ultima corrida.
3. Ingesta los que puede asignar con certeza a un asunto; encola los dudosos.
4. Revisa plazos y audiencias (vencidos, hoy, proximos 7 dias).
5. Corre un lint de salud de la wiki.
6. Escribe un informe del dia y actualiza el estado y la bitacora.

## Reglas que nunca se rompen

1. **Fuentes inmutables.** No modificar, mover ni borrar expedientes/PDFs/documentos. Solo se escriben `.md` de la wiki.
2. **No inventar.** Si no se puede resolver el asunto (causa/cliente) de un documento con certeza, va a la **cola de pendientes**, no se adivina. Mejor encolar que asignar mal.
3. **Supersesion, no olvido.** Nada se borra. Lo superado se marca: `> SUPERADO el <fecha> por <enlace>. Se conserva por historial.`
4. **Append y trazabilidad.** En modo desatendido, preferir cambios aditivos (hito en cronologia, linea en log) y marcar lo que requiere criterio humano con `[POR REVISAR]`. Cada dato apunta a su fuente.
5. **Idempotencia.** No reprocesar lo ya procesado. El ledger de estado evita ingestar dos veces el mismo archivo (ruta + hash/mtime).
6. **Local y confidencial.** Todo en disco. No subir nada a la nube; cuidado con datos sensibles.
7. **Estilo del README.** Respetar idioma y preferencias de redaccion declaradas en el `README` de la wiki (p. ej. sin em dash).

## Flujo detallado

### Paso 0 - Preflight
- Localizar la carpeta `Wiki/` y su `README` (el esquema). Si no existe, **detenerse** y avisar: "No encuentro una wiki; primero crea una con constructor-wiki-legal". No crear estructura aqui.
- Leer el README para conocer: tipo de practica, esquema (A/B/C/D), ancla de identificacion, materias, idioma/estilo, y las carpetas de fuentes a vigilar.
- Leer el estado previo en `Wiki/_estado/ultima_corrida.md` (o crearlo desde la plantilla si es la primera corrida). De aqui sale la fecha/hora de corte y el ledger de archivos ya procesados.

### Paso 1 - Detectar cambios
Ver `references/deteccion-de-cambios.md`. En las carpetas de fuentes declaradas (causas/clientes) y en el inbox/descargas configurado:
- Listar archivos con `mtime` posterior al corte o que no esten en el ledger.
- Para cada candidato, calcular una huella estable (ruta + tamano + mtime, o hash si es barato) para idempotencia.
- Ignorar temporales y locks (`~$*`, `.~lock*`, `.tmp`, `.crdownload`).

### Paso 2 - Clasificar y resolver el asunto
Para cada documento nuevo, resolver a que asunto pertenece usando el ancla del esquema:
- **Litigio:** ID de causa (RIT/rol/expediente) en el nombre o la ruta -> ficha de esa causa.
- **Asesoria:** cliente/codigo de matter en la ruta -> ficha de ese cliente/asunto.
- Cruzar con `index.md` y las carpetas existentes.

Tres resultados posibles:
- **Asignacion cierta** -> ingestar (Paso 3).
- **Asunto conocido pero ficha inexistente** -> crear la ficha desde la plantilla del esquema y luego ingestar.
- **Dudoso** (sin ancla, ambiguo, multi-asunto) -> a la **cola de pendientes** (`assets/PLANTILLA_cola-pendientes.md`), registrando todo lo que se sabe del archivo para que el abogado lo asigne despues. No adivinar.

### Paso 3 - Ingesta segura
Por cada documento con asignacion cierta:
1. Leer la fuente (si es PDF/imagen/escaneo, convertir/transcribir primero; nunca alterar el original).
2. Resumir los puntos clave.
3. Actualizar la ficha del asunto: hito en la cronologia con fecha y cita `(fuente: archivo, p. X / fecha)`; completar la seccion que corresponda. Si algo quedo superado, aplicar supersesion.
4. Actualizar la tarjeta central, `index.md` y las paginas de entidad/materia afectadas.
5. Marcar con `[POR REVISAR]` cualquier inferencia que conviene que valide un humano.
6. Anexar al ledger del estado la huella del archivo (procesado).

### Paso 4 - Plazos y audiencias
Recorrer el frontmatter de las fichas (`plazos_criticos`, `proxima_audiencia`, fechas en cronologia) y clasificar: **vencidos**, **hoy**, **proximos 7 dias**. Esto alimenta la seccion mas util del informe. No modificar fechas; solo reportarlas.

### Paso 5 - Lint de salud
Ver `references/operaciones-lint.md` si se incluye, o el README de la wiki. Detectar y listar (proponer, no ejecutar sin aprobacion fuera de lo aditivo):
- Datos superados sin marcar; contradicciones entre paginas.
- Enlaces `[[ ]]` rotos; asuntos sin tarjeta central; materias sin pagina.
- Fichas sin `estado` o sin proxima fecha en el frontmatter.

### Paso 6 - Informe, estado y bitacora
- Escribir el informe del dia en `Wiki/_informes/<YYYY-MM-DD>.md` desde `assets/PLANTILLA_informe-diario.md`: ingestados, encolados (pendientes), plazos (vencidos/hoy/7 dias), hallazgos de lint, y acciones sugeridas para el abogado.
- Actualizar `Wiki/_estado/ultima_corrida.md`: nueva fecha/hora de corte + ledger.
- Anexar una linea a `Wiki/log.md`: `## [YYYY-MM-DD] corrida-diaria | N ingestados, M encolados, K plazos proximos.`
- En chat (o en la notificacion de la tarea programada), entregar un resumen corto: lo ingestado, lo que requiere decision del abogado y lo que vence pronto. Enlazar el informe.

## Modo desatendido vs asistido
Ver `references/modo-desatendido.md`.
- **Asistido** (el abogado esta presente): proponer y esperar aprobacion para cambios que impliquen criterio; resolver dudas preguntando.
- **Desatendido** (tarea programada, abogado ausente): hacer solo cambios aditivos y seguros; todo lo que requiera criterio se deja como `[POR REVISAR]` en la ficha o en la cola, y se reporta. Nunca borrar ni sobrescribir contenido humano.

## Programarla cada dia
Para que corra sola, crear una tarea programada (p. ej. cada manana a las 8:00) cuyo prompt sea: "Corre el mantenimiento diario de la wiki legal". Ofrecer al abogado configurarla. La corrida debe ser barata: si no hay documentos nuevos, igual revisa plazos y deja un informe corto.

## Archivos de esta skill
- `references/deteccion-de-cambios.md` - como detectar y deduplicar documentos nuevos; que ignorar.
- `references/modo-desatendido.md` - reglas de seguridad para corridas sin supervision.
- `assets/PLANTILLA_estado.md` - estado/ledger de la ultima corrida.
- `assets/PLANTILLA_informe-diario.md` - informe del dia.
- `assets/PLANTILLA_cola-pendientes.md` - cola de archivos sin asignar.

## Que NO hace
- No crea la wiki desde cero (usar constructor-wiki-legal).
- No descarga expedientes de tribunales ni de portales.
- No redacta escritos ni contratos.
- No borra, mueve ni reorganiza las fuentes.