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.
El vocabulario es un árbol de dos niveles. El nivel superior responde a la pregunta que importa — cómo se consume el software — y un repositorio puede portar más de una rama:
| Nivel superior | Qué vuelve razonable esperar |
|---|---|
| Biblioteca — se consume como código | Una interfaz estable, un registro de cambios, un versionado en el que otro software pueda apoyarse |
| Aplicación — se ejecuta como programa | Dependencias fijadas, higiene de despliegue y configuración |
| Extensión de anfitrión — se instala en un anfitrión | El anfitrión aporta el modelo de confianza y el ritmo de publicación |
| Cuaderno | Nada de lo anterior — lo lee y lo ejecuta una persona, nada lo importa y no se instala en ningún sitio |
Donde se aplican ambas, se aplican ambas: un híbrido debe cumplir las obligaciones de cada lectura que porta, nunca la más laxa.
Los subtipos
Los subtipos existen solo donde la respuesta más fina cambia lo que cabe esperar: la modalidad de interfaz de una aplicación, o la clase de anfitrión de la que una extensión hereda su superficie de confianza.
| Aplicación | Extensión de anfitrión |
|---|---|
| Herramienta de línea de comandos | Complemento |
| Interfaz de terminal | Extensión de navegador |
| Escritorio | Extensión de editor |
| Móvil | Tema |
| Interfaz web | |
| Servicio de red | |
| Bot de chat | |
| Servidor MCP |
Biblioteca no tiene subtipos a propósito. Revisiones anteriores distinguían framework, SDK, cliente de API, middleware y controlador, y esas fronteras no existen: axios es un cliente de API y una biblioteca, flask es un framework y una biblioteca — una pregunta sin respuesta correcta. Aquello a lo que una biblioteca se conecta se registra en otro lugar, como un hecho de integración, no aquí.
La respuesta puede detenerse en el nivel superior. Un objetivo binario de Cargo y la disposición cmd/ de Go demuestran que el repositorio construye un ejecutable — no si es una herramienta de línea de comandos o un servidor. Ese repositorio se clasifica simplemente como Aplicación, y obtiene el subtipo solo cuando existe evidencia propia. Una respuesta genérica con respaldo vence a una específica que sería una conjetura.
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 clasificación. 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
Una comprobación, bajo una regla permanente. Desde la versión de métricas 2.5.0, la expectativa de lockfile del mecanismo de respaldo de la postura de seguridad lee la clasificación: un paquete publicado cuyo manifiesto declara un ejecutable cuenta como aplicación y conserva la expectativa — donde antes la sola publicación la eximía.
La regla permanente es que la puntuación lee únicamente declaraciones de manifiesto. Una etiqueta inferida de la estructura de archivos, los temas o la descripción se muestra y se registra, pero nunca mueve una puntuación — solo puede hacerlo lo que un manifiesto de compilación declara de forma explícita (una entrada bin, un punto de entrada de script de consola, un OutputType). Todo lo demás de la clasificación sigue siendo dato: metrics.classification en cada informe, junto con la evidencia que la produjo. Las conexiones futuras quedarán registradas en las versiones de la metodología a medida que lleguen.
Relacionado: ecosistemas compatibles · el índice de salud · postura de seguridad · configuración de la inspección · señales, no garantías