Señal alta
Deriva arquitectónica
Los límites se difuminan hasta que features, código compartido e infraestructura son difíciles de razonar.
arch_sherpa Cartografía de riesgo técnico
Mapea el riesgo técnico antes de que frene la entrega.
Flutter Sherpa Suite convierte arquitectura, dependencias, disciplina de releases y deuda técnica en señales medibles para equipos Flutter y Dart.
01 / Diagnostics
Los proyectos Flutter rara vez fallan de golpe.
Se ralentizan por acumulación: límites poco claros, dependencias arriesgadas, releases inconsistentes, deuda sin documentar y debates sobre salud del código basados en opiniones en lugar de evidencias.
Elevado
Riesgo en dependencias
Una dependencia puede estar actualizada, ser popular o interna y aun así introducir riesgo de ecosistema, mantenimiento, acoplamiento o compatibilidad de plataforma.
dep_sherpa Vigilar
Fricción en releases
La intención de versión, el detalle del changelog y el comportamiento real de release dejan de coincidir.
semver_sherpa Concentrada
Deuda técnica invisible
El dolor conocido queda disperso entre comentarios, tickets y memoria en lugar de señales revisables.
techdebt_sherpa 02 / Suite
Una suite. Cuatro lentes de ingeniería.
Cada herramienta Sherpa observa una ruta distinta por el código y emite señales que el equipo puede revisar, medir y convertir en acción.
Disciplina de releases
semver_sherpa
Mantén versiones, changelogs e intención de release alineados.
$ semver_sherpa check
$ semver_sherpa release --type minor Signal Consistencia de checkpoint de release Ver en pub.dev
Control arquitectónico
arch_sherpa
Detecta la erosión de límites antes de que se convierta en un refactor que nadie quiere empezar.
$ arch_sherpa analyze --config sherpa.yaml Signal Tendencia de violaciones de límites Ver en pub.dev
Inteligencia de dependencias
dep_sherpa
Expone riesgos de dependencias, acoplamiento, ecosistema y compatibilidad de plataforma.
$ dep_sherpa scan --format json Signal Exposición de compatibilidad de plataforma Ver en pub.dev
Visibilidad de deuda técnica
techdebt_sherpa
Convierte deuda dispersa en señales visibles, revisables y priorizables.
$ techdebt_sherpa report --output markdown Signal Prioridad de foco de deuda Ver en pub.dev
Instalación
Instala una señal. Mide un riesgo.
Elige la herramienta Sherpa que encaje con el riesgo que quieres hacer visible primero.
Paquete CLI para Dart · pub.dev
semver_sherpa
Mantén alineados la intención de versión, las entradas de changelog y los checkpoints de release.
dart pub global activate semver_sherpa 03 / Signals
De opiniones a señales.
Antes
- Este módulo parece desordenado.
- Las dependencias seguramente están bien.
- Deberíamos publicar pronto.
- Sabemos que hay deuda en alguna parte.
Después
- Las violaciones de reglas arquitectónicas subieron un 18 %.
- El riesgo de dependencias se concentra en un conjunto reducido de paquetes directos y transitivos.
- El changelog y la intención de versión no coinciden.
- Los focos de deuda se concentran en tres features.
04 / Workflow
Diseñado para flujos de ingeniería, no para dashboards de vanidad.
Las señales Sherpa están pensadas para vivir donde ya se toman decisiones técnicas: terminal local, CI, revisiones e informes.
- 01 Analizar
- 02 Informar
- 03 Revisar
- 04 Actuar
- 05 Medir evolución
- Uso local por CLI
- Integración en CI
- JSON legible por máquinas
- Markdown legible por personas
- Señales técnicas revisables
05 / Teams
Pensado para equipos que se toman en serio la mantenibilidad.
- Senior Flutter engineers
- Tech leads
- Staff / principal engineers
- Equipos con foco arquitectónico
- Equipos que escalan de una app a varias
- Equipos que quieren señales objetivas de calidad técnica
06 / FAQ
Preguntas que los equipos técnicos hacen primero.
Está diseñada principalmente para proyectos Flutter y Dart, con foco en arquitectura, dependencias, disciplina de releases y mantenibilidad.
No. Complementa linters y análisis estático centrándose en señales de flujo de ingeniería, límites arquitectónicos, riesgo de dependencias, disciplina de releases y visibilidad de deuda técnica.
Las herramientas deben estar pensadas para ejecutarse tanto en local como en CI, generando salidas legibles por personas y por máquinas.
Empieza por el paquete que coincida con el riesgo más visible: releases, límites arquitectónicos, dependencias o deuda técnica. Cada herramienta está diseñada para generar una señal concreta antes de introducir un proceso más amplio.