Files
fn_registry/dev/issues/0062-deprecate-unused-core-functions.md
T
egutierrez f2381b7b2b docs(issues): 0054-0062 — deudas detectadas en sesion fn doctor
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>
2026-05-07 02:16:43 +02:00

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:

  1. Mantener indefinidamente (libreria publica disponible).
  2. Deprecar via tag (tags: [deprecated]) — sigue presente pero senala "no usar para codigo nuevo".
  3. 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:

  1. Criterios cuantitativos: cuanto tiempo (en dias) sin consumidor justifica deprecar.
  2. Excepciones: funciones con tag core-utility o library-quality se mantienen.
  3. Workflow de deprecacion: tag → 90 dias → borrar.
  4. Hook automatico: fn doctor unused --propose-deprecation abre 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 con AgeDays desde updated_at (ya lo tiene) y filtrar por edad.
  • cmd/fn/doctor.go — anadir flag --older-than <days> al subcomando unused.

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 deprecated en uses_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 deprecated es 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.