Un repositorio no es simplemente «un proyecto». Construye algo, y lo que construye decide qué prácticas es razonable esperar de él. De una biblioteca publicada se espera que no incluya un archivo de bloqueo de dependencias: las versiones que fija las ignora cualquiera que la instale. De la aplicación que está a su lado en el catálogo se espera lo contrario, porque las versiones que fija son exactamente lo que se despliega. Juzgar a ambas con una sola regla implica leer mal a una de ellas.
Hasta la versión de métricas 2.3.0 un único indicador indirecto sustituía a la pregunta: si el repositorio publica un paquete en un registro. Con ese criterio, toda herramienta de línea de comandos en PyPI se lee como biblioteca, y toda aplicación que de paso publique un paquete auxiliar, también.
Todas las lecturas que la evidencia sostiene
La clasificación es multietiqueta. Que un software sea a la vez biblioteca publicada y herramienta ejecutable es el caso ordinario, no una contradicción que resolver: ripgrep es un crate y un binario, esbuild es un paquete npm y un ejecutable. Por eso un repositorio conserva todas las lecturas que su evidencia sostiene.
Se responden tres preguntas de forma independiente, y un repositorio puede responder que sí a más de una:
| Pregunta | Cierto para | Qué vuelve razonable esperar |
|---|---|---|
| Se consume como código | biblioteca, framework, SDK, cliente de API, middleware, controlador | Una interfaz estable, un registro de cambios, un versionado en el que otro software pueda apoyarse |
| Se ejecuta como programa | herramienta de línea de comandos, interfaz de terminal, aplicación de escritorio y móvil, interfaz web, servicio de red, bot de chat, servidor MCP | Dependencias fijadas, higiene de despliegue y configuración |
| Se instala en un anfitrión | complemento, extensión, tema, herramientas de editor | El anfitrión aporta el modelo de confianza y el ritmo de publicación |
Donde se aplican ambas, se aplican ambas: un híbrido debe cumplir las obligaciones de cada lectura que porta, nunca la más laxa.
Las etiquetas
| Se consume como código | Se ejecuta como programa | Se instala en un anfitrión |
|---|---|---|
| Biblioteca | Herramienta de línea de comandos | Complemento |
| Framework | Interfaz de terminal | Extensión |
| SDK | Aplicación de escritorio | Tema |
| Cliente de API | Aplicación móvil | Herramientas de editor |
| Middleware | Interfaz web | |
| Controlador | Servicio de red | |
| Bot de chat | ||
| Servidor MCP |
Cuaderno es una etiqueta propia y no pertenece a ninguno de los tres grupos: lo lee y lo ejecuta una persona, nada lo importa y no se instala en ningún sitio.
Cómo se llega a la respuesta
La evidencia se ordena según hasta dónde puede confiarse en ella, y ninguna señal débil aislada produce una etiqueta.
| Evidencia | Ejemplos | Peso |
|---|---|---|
| Declarada en un manifiesto de compilación | una entrada bin de npm, un punto de entrada console_scripts, <OutputType>Exe</OutputType>, el type de Composer, el <packaging> de Maven, un objetivo [lib] de Cargo | Decisivo |
| Declarada por el registro | un tipo de Packagist, un tipo de paquete de NuGet, una categoría de crates.io | Fuerte |
| Dependencias declaradas | un framework web, un analizador de argumentos de CLI, un cliente de plataforma de chat | Moderado |
| Estructura del árbol de archivos | cmd/…/main.go, src-tauri/, un chart de Helm, un manifiesto de extensión de navegador | De apoyo |
| Temas del repositorio y palabras clave del registro | cli, wordpress-plugin, self-hosted | Débil — autoasignado |
| La descripción del repositorio | «a CLI for…», «a library for…» | Débil — autoasignado |
Los dos primeros son los más fuertes porque no son opiniones: quien escribe <OutputType>Exe</OutputType> no está describiendo el software; de otro modo la compilación no funcionaría. Un tema es una opinión, y que dos coincidan es el mínimo que sostiene algo.
La evidencia también opera en sentido contrario. Un paquete de Cargo con publish = false, un type de Composer igual a project, una herramienta de .NET, un war de Maven: cada uno descarta ser algo en lo que otro software pueda apoyarse, tenga el repositorio el aspecto que tenga.
Cuando no hay respuesta
Tres situaciones no producen clasificación, y las tres son ordinarias:
- El informe es anterior a la versión de métricas 2.3.0. Todo informe almacenado se reclasificó a partir de los hechos que ya contenía, pero la evidencia de los manifiestos se recoge durante un análisis, de modo que los informes reunidos antes solo llevan los niveles más débiles y obtendrán la lectura completa en la próxima inspección del repositorio.
- La evidencia no responde a la pregunta. Muchos repositorios no publican manifiesto, no llevan temas informativos y se describen en una prosa que no afirma nada estructural.
- La respuesta sería una conjetura. Donde hay señales pero son demasiado débiles para cruzar el umbral, no se afirma nada.
En los tres casos el informe simplemente no muestra clasificación. La ausencia nunca se presenta como un hallazgo, no se puntúa nada sobre ella, y un repositorio sin clasificación no queda marcado, ni relegado, ni penalizado de ninguna forma.
Repositorios que construyen varias cosas
Un monorepo que aloja un servicio desplegable junto a tres bibliotecas publicadas no es un artefacto, y reducirlo a una única respuesta perdería el hecho de que ambas lecturas son ciertas. Por eso cada manifiesto se clasifica por sus propias declaraciones y el repositorio porta la unión.
Conviene enunciar una consecuencia con claridad: la etiqueta principal de un repositorio así es la mejor sustentada, y en un monorepo grande puede ser una herramienta de compilación publicada en lugar del producto por el que se conoce al proyecto. La etiqueta principal existe para la presentación y para agrupar repositorios comparables; nunca es la base de una decisión de puntuación.
Qué afecta hoy
Nada. A partir de la versión de métricas 2.3.0 la clasificación se publica como dato — metrics.classification en cada informe, junto con la evidencia que la produjo — y ninguna métrica la lee. Conectarla con las métricas que dependen de ella, empezando por la expectativa sobre los archivos de bloqueo, es un cambio aparte y quedará registrado en las versiones de la metodología cuando ocurra.