kdd-dependency-eol-scan

Dependency EOL Scan (Capa 3 de KDD -- vigencia de dependencias)

Produce hallazgos de vigencia de dependencias (fuera de soporte, abandonadas, o proximas a su fecha de fin de vida) en el formato de contrato que audita la Capa 3 de KDD. Esta skill NO es el gate -- es la parte creativa/no determinista (consultar el estado de vigencia real de cada dependencia y decidir su eolStatus) que el gate despues valida. Distincion central: el scanner/agente decide el estado de vigencia; el gate solo audita que el artefacto sellado cumpla forma y politica de calidad de datos.

Como kdd-compliance-scan y kdd-privacy-scan, este dominio NO vendoriza ningun sellador externo -- vos mismo escribis findings.json ya en forma final.

No es lo mismo que kdd-compliance-scan

kdd-compliance-scan audita si la LICENCIA de una dependencia es compatible con la del proyecto. Esta skill audita si la dependencia sigue VIGENTE (mantenida, con soporte activo) independientemente de su licencia. Una dependencia puede estar perfectamente licenciada (MIT) y a la vez estar sin mantenimiento hace anios. Corre las dos skills si queres cobertura completa de riesgo de dependencias -- son hallazgos independientes, en dominios (y findings.json) separados.

Cuando usarla

El usuario pide auditar si las dependencias directas de un proyecto siguen soportadas/mantenidas, y quiere el resultado gobernado por KDD (versionable, gateado en CI, con politica declarativa), no un reporte suelto en prosa.

Insumos que necesitas antes de empezar

• repo_root: raiz del repositorio a escanear.
• scan_dir: donde vas a escribir findings.json. Por defecto dependency-eol/scan dentro del repo KDD (coincide con el default de validate_dependency_eol_findings.py); si estas gobernando un repo EXTERNO, cualquier directorio disponible sirve, con tal de pasarselo explicito al gate.
• El schema completo vive en knowledge/data_models/dependency-eol/findings.schema.json -- consultalo si dudas de un campo, no adivines la forma.