Nueve issues nuevos cubriendo deudas tecnicas descubiertas tras ejecutar fn doctor por primera vez: - 0054 deploy_server: reimplementa SSH/systemd/rsync inline en lugar de usar funciones del registry (alta). - 0055 docker_tui: usa docker CLI directo via shell en lugar de docker_* del registry (alta). - 0056 audit_uses_functions: heuristica Python no detecta `from pkg.subpkg import X` (media). - 0057 audit_uses_functions: deteccion de simbolos Go con abreviaturas falla en algunos casos (baja). - 0058 kanban uses_functions sync deferido por WIP en curso (baja). - 0059 doble tracking de apps/*/app.md (fn_registry + sub-repo) inconsistencia (media). - 0060 fn doctor secrets: subcomando para audit secrets en TODOS los repos (media). - 0061 integrar notify_telegram en deploy_server + bucle reactivo (media, depende de 0054). - 0062 politica de deprecacion para 704 funciones sin consumidores (baja, research). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.6 KiB
0062 — Politica de deprecacion para funciones del registry sin consumidores
APP Metadata
| Campo | Valor |
|---|---|
| ID | 0062 |
| Estado | pendiente |
| Prioridad | baja |
| Tipo | research + policy — .claude/rules/, docs/ |
Dependencias
find_unused_functions_go_infra(existe, lista 704 funciones sin consumidores al 2026-05-07).fn doctor unused.
Contexto
Sesion 2026-05-07: el registry tiene 1066 funciones. fn doctor unused reporta 704 sin consumidores (66%). La mayoria son utilities core puras (compose2_go_core, curry2_go_core, chunk_go_core, flat_map_slice_go_core, etc.) construidas especulativamente — esperando que alguna app las consuma.
Sin politica explicita de "que hacer con unused", el registry crece sin freno. Posibles destinos:
- Mantener indefinidamente (libreria publica disponible).
- Deprecar via tag (
tags: [deprecated]) — sigue presente pero senala "no usar para codigo nuevo". - Borrar despues de N meses sin consumidor.
Decision pospuesta: cualquier eleccion afecta cientos de archivos y la velocidad de scaffold de nuevas apps que pueden recogerlas.
Objetivo
Definir y documentar una politica formal:
- Criterios cuantitativos: cuanto tiempo (en dias) sin consumidor justifica deprecar.
- Excepciones: funciones con tag
core-utilityolibrary-qualityse mantienen. - Workflow de deprecacion: tag → 90 dias → borrar.
- Hook automatico:
fn doctor unused --propose-deprecationabre proposals.
Arquitectura
Archivos afectados
- NUEVA regla
.claude/rules/unused_functions.md. - NUEVO ADR
docs/adr/0005-unused-functions-policy.md. find_unused_functions_go_infra— opcionalmente extender conAgeDaysdesdeupdated_at(ya lo tiene) y filtrar por edad.cmd/fn/doctor.go— anadir flag--older-than <days>al subcomandounused.
Tareas
Fase 1 — definir politica (humano)
1.1 Decidir umbrales: tag deprecated tras 60 dias sin consumidor; borrar tras 180 dias.
1.2 Decidir excepciones: tag core-utility exime, tag library-quality exime, dominios core puros mas tolerantes que dominios infra.
1.3 Decidir si la deprecacion es manual (humano via proposal) o automatica (cron).
Fase 2 — escribir ADR + regla
2.1 ADR 0005 con la decision, alternativas, consecuencias.
2.2 Regla .claude/rules/unused_functions.md operacional.
2.3 Update INDEX.md.
Fase 3 — extender herramienta
3.1 fn doctor unused --older-than 60 filtra por edad.
3.2 fn doctor unused --propose-deprecation crea proposals automaticas con kind=deprecate_function.
3.3 Workflow humano: revisar proposals, aprobar, agente aplica el tag.
Fase 4 — primera ronda
4.1 Correr fn doctor unused --older-than 90.
4.2 Decidir caso por caso (o lote por dominio): mantener / deprecar / borrar.
4.3 Aplicar tags. Re-indexar. Update CHANGELOG.
Riesgos
- Borrar funciones que el usuario planeaba usar pronto. Mitigacion: ventana larga (180 dias) + proposal manual antes de borrar.
- Tags desfasados: una funcion deprecated puede seguir siendo usada. Mitigacion: el indexer puede warn si una app declara una
deprecatedenuses_functions. - Deprecation como excusa para no usar (cosmica). Mitigacion: revisiones trimestrales, no que se acumule.
Decisiones de diseno
- NO borrar nunca automaticamente. Borrado siempre humano via PR/proposal aprobada.
- Tag
deprecatedes el verbo automatizable: un agente puede aplicarlo via proposal. - Para funciones nuevas creadas tras adoptar la politica, exigir que tengan al menos UN consumidor previsto al merge — sino van directo con tag
experimental.