model-switchboard

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia en la página de su proyecto. El estado de la insignia se ve así: El nivel de insignia para el proyecto 12820 es passing Aquí se explica cómo insertarla:
Puede mostrar el estado de su insignia insertando esto en su archivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12820/badge)](https://www.bestpractices.dev/projects/12820)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/12820"><img src="https://www.bestpractices.dev/projects/12820/badge"></a>


Estos son los criterios de nivel Básico. También puede ver los criterios de nivel Plata o Oro.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos 13/13 ●

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

    A session-aware control layer that routes coding turns to an appropriate model profile before execution.

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

  • Contenido básico del sitio web del proyecto


    ¡Suficiente para una insignia!

    El sitio web del proyecto DEBE describir sucintamente qué hace el software (¿qué problema resuelve?). [description_good]
    Esto DEBE estar en un lenguaje que los usuarios potenciales puedan entender (por ejemplo, utiliza jerga mínima).

    The project uses its GitHub repository as the project website. It provides how to obtain the software (repo and npm package), how to provide feedback (GitHub Issues for bug reports and enhancements), and how to contribute (CONTRIBUTING.md with PR process and contribution requirements).


    ¡Suficiente para una insignia!

    El sitio web del proyecto DEBE proporcionar información sobre cómo: obtener, proporcionar comentarios (como informes de errores o mejoras), y contribuir al software. [interact]

    Obtain the software:
    https://github.com/hannasdev/model-switchboard
    https://www.npmjs.com/package/model-switchboard
    Provide feedback (bugs/enhancements):
    https://github.com/hannasdev/model-switchboard/issues
    Contribute:
    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) (URL requerida) [contribution]
    Se asume que los proyectos en GitHub usan "incidencias" y "pull requests" a menos que se indique lo contrario. Esta información puede ser breve, por ejemplo, indicando que el proyecto utiliza "pull requests", un gestor de incidencias o publicaciones en una lista de correo (Indíquese cuál)

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBERÍA incluir los requisitos para las contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). (URL requerida) [contribution_requirements]

    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


  • Licencia FLOSS


    ¡Suficiente para una insignia!

    El software producido por el proyecto DEBE ser publicado como FLOSS. [floss_license]
    FLOSS es software publicado de una manera que cumple con la Definición de Código Abierto o la Definición de Software Libre. Ejemplos de tales licencias incluyen CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Para nuestros propósitos, esto significa que la licencia DEBE ser: El software PUEDE también estar licenciado de otras maneras (por ejemplo, "GPLv2 o propietario" es aceptable).

    The MIT license is approved by the Open Source Initiative (OSI).


    ¡Suficiente para una insignia!

    Se SUGIERE que cualquier licencia(s) requerida(s) para el software producido por el proyecto sea aprobada por la Open Source Initiative (OSI). [floss_license_osi]
    La OSI utiliza un proceso de aprobación riguroso para determinar qué licencias son OSS.

    The MIT license is approved by the Open Source Initiative (OSI).


    ¡Suficiente para una insignia!

    El proyecto DEBE publicar la(s) licencia(s) de sus resultados en una ubicación estándar en su repositorio de código fuente. (URL requerida) [license_location]
    Una convención es publicar la licencia como un archivo de nivel superior llamado LICENSE o COPYING, que PUEDE ser seguido por una extensión como ".txt" o ".md". Una convención alternativa es tener un directorio llamado LICENSES que contenga archivo(s) de licencia; estos archivos generalmente se nombran según su identificador de licencia SPDX seguido de una extensión de archivo apropiada, como se describe en la Especificación REUSE. Tenga en cuenta que este criterio es solo un requisito para el repositorio de código fuente. NO necesita incluir el archivo de licencia al generar algo desde el código fuente (como un ejecutable, paquete o contenedor). Por ejemplo, al generar un paquete R para el Comprehensive R Archive Network (CRAN), siga la práctica estándar de CRAN: si la licencia es una licencia estándar, use la especificación de licencia corta estándar (para evitar instalar otra copia del texto) y liste el archivo LICENSE en un archivo de exclusión como .Rbuildignore. De manera similar, al crear un paquete Debian, puede poner un enlace en el archivo de derechos de autor al texto de la licencia en /usr/share/common-licenses, y excluir el archivo de licencia del paquete creado (por ejemplo, eliminando el archivo después de llamar a dh_auto_install). Alentamos a incluir información de licencia legible por máquina en formatos generados cuando sea práctico.

    Non-trivial license location file in repository: https://github.com/hannasdev/model-switchboard/blob/main/LICENSE.


  • Documentación


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar documentación básica para el software producido por el proyecto. [documentation_basics]
    Esta documentación debe estar en algún medio (como texto o video) que incluya: cómo instalarlo, cómo iniciarlo, cómo usarlo (posiblemente con un tutorial usando ejemplos), y cómo usarlo de manera segura (por ejemplo, qué hacer y qué no hacer) si eso es un tema apropiado para el software. La documentación de seguridad no necesita ser larga. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. Si el proyecto no produce software, elija "no aplicable" (N/A).

    Some documentation basics file contents found.


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar documentación de referencia que describa la interfaz externa (tanto entrada como salida) del software producido por el proyecto. [documentation_interface]
    La documentación de una interfaz externa explica a un usuario final o desarrollador cómo usarla. Esto incluiría su interfaz de programación de aplicaciones (API) si el software tiene una. Si es una biblioteca, documente las clases/tipos principales y los métodos/funciones que se pueden llamar. Si es una aplicación web, defina su interfaz URL (a menudo su interfaz REST). Si es una interfaz de línea de comandos, documente los parámetros y opciones que admite. En muchos casos es mejor si la mayor parte de esta documentación se genera automáticamente, de modo que esta documentación permanezca sincronizada con el software a medida que cambia, pero esto no es obligatorio. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. La documentación PUEDE generarse automáticamente (donde sea práctico, esta es a menudo la mejor manera de hacerlo). La documentación de una interfaz REST puede generarse usando Swagger/OpenAPI. La documentación de la interfaz del código PUEDE generarse usando herramientas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), y Doxygen (muchos). Simplemente tener comentarios en el código de implementación no es suficiente para satisfacer este criterio; necesita haber una manera fácil de ver la información sin leer todo el código fuente. Si el proyecto no produce software, elija "no aplicable" (N/A).

    https://github.com/hannasdev/model-switchboard/blob/main/docs/CLI-REFERENCE.md


  • Otro


    ¡Suficiente para una insignia!

    Los sitios del proyecto (sitio web, repositorio y URLs de descarga) DEBEN admitir HTTPS usando TLS. [sites_https]
    Esto requiere que la URL de la página de inicio del proyecto y la URL del repositorio de control de versiones comiencen con "https:", no "http:". Puede obtener certificados gratuitos de Let's Encrypt. Los proyectos PUEDEN implementar este criterio usando (por ejemplo) GitHub pages, GitLab pages, o SourceForge project pages. Si admite HTTP, le instamos a redirigir el tráfico HTTP a HTTPS.

    Given only https: URLs.


    ¡Suficiente para una insignia!

    El proyecto DEBE tener uno o más mecanismos para la discusión (incluyendo cambios propuestos y problemas) que sean buscables, permitan que los mensajes y temas sean direccionables mediante URL, permitan que nuevas personas participen en algunas de las discusiones y no requieran la instalación del lado del cliente de software propietario. [discussion]
    Ejemplos de mecanismos aceptables incluyen listas de correo archivadas, discusiones de issues y pull requests de GitHub, Bugzilla, Mantis y Trac. Los mecanismos de discusión asíncrona (como IRC) son aceptables si cumplen con estos criterios; asegúrese de que haya un mecanismo de archivo direccionable por URL. JavaScript propietario, aunque desaconsejado, está permitido.

    GitHub supports discussions on issues and pull requests.
    https://github.com/hannasdev/model-switchboard/blob/main/docs/CLI-REFERENCE.md


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA proporcionar documentación en inglés y ser capaz de aceptar informes de errores y comentarios sobre el código en inglés. [english]
    El inglés es actualmente la lengua franca de la tecnología informática; el soporte del inglés aumenta el número de diferentes desarrolladores y revisores potenciales en todo el mundo. Un proyecto puede cumplir con este criterio incluso si el idioma principal de sus desarrolladores principales no es el inglés.

    All documentation is available in English.
    Examples: https://github.com/hannasdev/model-switchboard/blob/main/LICENSE, https://github.com/hannasdev/model-switchboard/blob/main/docs/CLI-REFERENCE.md, https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    ¡Suficiente para una insignia!

    El proyecto DEBE ser mantenido. [maintained]
    Como mínimo, el proyecto debe intentar responder a informes de problemas y vulnerabilidades significativos. Un proyecto que está buscando activamente una insignia probablemente esté mantenido. Todos los proyectos y personas tienen recursos limitados, y los proyectos típicos deben rechazar algunos cambios propuestos, por lo que los recursos limitados y los rechazos de propuestas no indican por sí mismos un proyecto no mantenido.

    Cuando un proyecto sabe que ya no será mantenido, debe establecer este criterio como "No cumplido" y usar el o los mecanismos apropiados para indicar a otros que no está siendo mantenido. Por ejemplo, use "DEPRECATED" (OBSOLETO) como el primer encabezado de su README, agregue "DEPRECATED" cerca del comienzo de su página de inicio, agregue "DEPRECATED" al principio de la descripción del proyecto del repositorio de código, agregue una insignia no-maintenance-intended en su README y/o página de inicio, márquelo como obsoleto en cualquier repositorio de paquetes (por ejemplo, npm deprecate), y/o use el sistema de marcado del repositorio de código para archivarlo (por ejemplo, la configuración de "archive" de GitHub, el marcado "archived" de GitLab, el estado "readonly" de Gerrit, o el estado de proyecto "abandoned" de SourceForge). Se puede encontrar discusión adicional aquí.

    How this is satisfied:

    Regular recent releases are published, which indicates active upkeep and user-facing updates.
    https://github.com/hannasdev/model-switchboard/releases
    https://github.com/hannasdev/model-switchboard/blob/main/CHANGELOG.md
    Recent commit activity is visible on the default branch, showing the codebase is actively updated.
    https://github.com/hannasdev/model-switchboard/commits/main
    CI is configured and running on pushes/PRs, which is a strong maintenance signal (changes are continuously validated).
    https://github.com/hannasdev/model-switchboard/actions/workflows/ci.yml
    https://github.com/hannasdev/model-switchboard/actions
    Security handling is documented and current, with a defined vulnerability-report process.
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


 Control de cambios 9/9 ●

  • Repositorio público para el control de versiones de código fuente


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un repositorio público para el control de versiones de código fuente que sea legible públicamente y tenga URL. [repo_public]
    La URL PUEDE ser la misma que la URL del proyecto. El proyecto PUEDE utilizar ramas privadas (no públicas) en casos específicos, mientras que el cambio no se divulga públicamente (por ejemplo, para corregir una vulnerabilidad antes de que se revele al público).

    Repository on GitHub, which provides public git repositories with URLs.


    ¡Suficiente para una insignia!

    El repositorio fuente del proyecto DEBE rastrear qué cambios se realizaron, quién realizó los cambios y cuándo se realizaron los cambios. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    ¡Suficiente para una insignia!

    Para permitir la revisión colaborativa, el repositorio de código fuente del proyecto DEBE incluir versiones provisionales para revisión entre lanzamientos; NO DEBE incluir solo versiones finales. [repo_interim]
    Los proyectos PUEDEN optar por omitir versiones provisionales específicas de sus repositorios de código fuente públicos (por ejemplo, las que corrigen vulnerabilidades de seguridad específicas no públicas, pueden nunca ser lanzadas públicamente o incluyen material que no puede ser publicado legalmente y no están en el lanzamiento final).

    Why this criterion is satisfied:

    The repository uses pull requests with branch-based development, so changes are reviewed in interim form before release tags are created.
    The commit history on main shows many non-release commits and merged PR commits between release commits.
    Releases are generated from already-reviewed source history, not as isolated final-only drops.

    PR list (interim review artifacts): https://github.com/hannasdev/model-switchboard/pulls?q=is%3Apr+is%3Aclosed
    Main commit history (interim commits between releases): https://github.com/hannasdev/model-switchboard/commits/main
    Tags/releases (final outputs derived from reviewed history): https://github.com/hannasdev/model-switchboard/releases


    ¡Suficiente para una insignia!

    Se SUGIERE que se use software de control de versiones distribuido común (por ejemplo, git) para el repositorio de código fuente del proyecto. [repo_distributed]
    Git no se requiere específicamente y los proyectos pueden usar un software de control de versiones centralizado (como subversion) con justificación.

    Repository on GitHub, which uses git. git is distributed.


  • Numeración única de versión


    ¡Suficiente para una insignia!

    Los resultados del proyecto DEBEN tener un identificador de versión único para cada lanzamiento destinado a ser usado por los usuarios. [version_unique]
    Esto PUEDE cumplirse de diversas maneras, incluyendo IDs de commit (como el ID de commit de git o el ID de changeset de mercurial) o un número de versión (incluyendo números de versión que usan versionado semántico o esquemas basados en fechas como AAAAMMDD).

    The project uses SemVer in package metadata, with a single version value per release.
    Each release is tagged with a unique Git tag in vX.Y.Z format.
    GitHub Releases are created per tag, so each user-facing release has a unique identifier.
    Evidence URLs:

    Version in package metadata: https://github.com/hannasdev/model-switchboard/blob/main/package.json
    Unique release tags: https://github.com/hannasdev/model-switchboard/tags
    User-facing releases: https://github.com/hannasdev/model-switchboard/releases


    ¡Suficiente para una insignia!

    Se SUGIERE que se use el formato de numeración de versiones Semantic Versioning (SemVer) o Calendar Versioning (CalVer) para los lanzamientos. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro. [version_semver]
    Los proyectos generalmente deberían preferir el formato que esperan sus usuarios, por ejemplo, porque es el formato normal usado por su ecosistema. Muchos ecosistemas prefieren SemVer, y SemVer es generalmente preferido para interfaces de programación de aplicaciones (APIs) y kits de desarrollo de software (SDKs). CalVer tiende a ser usado por proyectos que son grandes, tienen un número inusualmente grande de dependencias desarrolladas independientemente, tienen un alcance en constante cambio o son sensibles al tiempo. Se SUGIERE que quienes usen CalVer incluyan un valor de nivel micro, porque incluir un nivel micro soporta ramas mantenidas simultáneamente cuando eso se vuelva necesario. Otros formatos de numeración de versiones pueden usarse como números de versión, incluyendo IDs de commit de git o IDs de changeset de mercurial, siempre que identifiquen versiones de manera única. Sin embargo, algunas alternativas (como los IDs de commit de git) pueden causar problemas como identificadores de lanzamiento, porque los usuarios pueden no ser capaces de determinar fácilmente si están actualizados. El formato de ID de versión puede no ser importante para identificar lanzamientos de software si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua).

    ¡Suficiente para una insignia!

    Se SUGIERE que los proyectos identifiquen cada lanzamiento dentro de su sistema de control de versiones. Por ejemplo, se SUGIERE que quienes usen git identifiquen cada lanzamiento usando etiquetas de git. [version_tags]

    We use Semantic Versioning style identifiers (major.minor.patch) in releases.
    Our Git tags follow vX.Y.Z.
    The package version tracks the same SemVer format.
    Evidence URLs:
    https://github.com/hannasdev/model-switchboard/tags
    https://github.com/hannasdev/model-switchboard/releases
    https://github.com/hannasdev/model-switchboard/blob/main/package.json


  • Notas de lanzamiento


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar, en cada lanzamiento, notas de lanzamiento que sean un resumen legible por humanos de los cambios principales en ese lanzamiento para ayudar a los usuarios a determinar si deben actualizar y cuál será el impacto de la actualización. Las notas de lanzamiento NO DEBEN ser la salida bruta de un registro de control de versiones (por ejemplo, los resultados del comando "git log" no son notas de lanzamiento). Los proyectos cuyos resultados no están destinados para su reutilización en múltiples ubicaciones (como el software para un solo sitio web o servicio) Y emplean entrega continua PUEDEN seleccionar "N/A". (URL requerida) [release_notes]
    Las notas de lanzamiento PUEDEN implementarse de diversas maneras. Muchos proyectos las proporcionan en un archivo llamado "NEWS", "CHANGELOG" o "ChangeLog", opcionalmente con extensiones como ".txt", ".md" o ".html". Históricamente el término "change log" significaba un registro de cada cambio, pero para cumplir con estos criterios lo que se necesita es un resumen legible por humanos. Las notas de lanzamiento PUEDEN proporcionarse mediante mecanismos del sistema de control de versiones como el flujo de trabajo GitHub Releases.

    Non-trivial release notes file in repository: https://github.com/hannasdev/model-switchboard/blob/main/CHANGELOG.md.


    ¡Suficiente para una insignia!

    Las notas de lanzamiento DEBEN identificar cada vulnerabilidad de tiempo de ejecución conocida públicamente que se corrigió en este lanzamiento y que ya tenía una asignación de CVE o similar cuando se creó el lanzamiento. Este criterio puede marcarse como no aplicable (N/A) si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica (por ejemplo, como suele ser cierto para las actualizaciones del kernel). Este criterio se aplica solo a los resultados del proyecto, no a sus dependencias. Si no hay notas de lanzamiento o no ha habido vulnerabilidades conocidas públicamente, elija N/A. [release_notes_vulns]
    Este criterio ayuda a los usuarios a determinar si una actualización dada corregirá una vulnerabilidad que es conocida públicamente, para ayudar a los usuarios a tomar una decisión informada sobre la actualización. Si los usuarios típicamente no pueden actualizar el software ellos mismos de manera práctica en sus computadoras, pero en su lugar deben depender de uno o más intermediarios para realizar la actualización (como suele ser el caso de un kernel y software de bajo nivel que está entrelazado con un kernel), el proyecto puede elegir "no aplicable" (N/A) en su lugar, ya que esta información adicional no será útil para esos usuarios. De manera similar, un proyecto puede elegir N/A si todos los destinatarios solo ejecutan la última versión (por ejemplo, es el código para un solo sitio web o servicio de internet que se actualiza constantemente a través de entrega continua). Este criterio solo se aplica a los resultados del proyecto, no a sus dependencias. Enumerar las vulnerabilidades de todas las dependencias transitivas de un proyecto se vuelve difícil de manejar a medida que aumentan y varían las dependencias, y es innecesario ya que las herramientas que examinan y rastrean dependencias pueden hacer esto de una manera más escalable.

    N/A. While the project provides release notes, no releases to date have fixed a publicly known run-time vulnerability in the project itself that had a CVE (or similar identifier) assigned at the time of release. If such a case occurs, we will explicitly list the CVE(s) in the corresponding release notes.

    https://github.com/hannasdev/model-switchboard/releases


 Informes 8/8 ●

  • Proceso de reporte de errores


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar un proceso para que los usuarios envíen informes de errores (por ejemplo, usando un rastreador de issues o una lista de correo). (URL requerida) [report_process]

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md. [osps_do_02_01]


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA usar un rastreador de issues para rastrear problemas individuales. [report_tracker]

    The project uses GitHub Issues as its issue tracker for individual bug reports and enhancement requests.
    https://github.com/hannasdev/model-switchboard/issues


    ¡Suficiente para una insignia!

    El proyecto DEBE reconocer la mayoría de los informes de errores enviados en los últimos 2-12 meses (inclusive); la respuesta no necesita incluir una solución. [report_responses]

    In the applicable 2–12 month window, there were no submitted bug reports in this repository, so there were no unacknowledged bug reports. The project’s issue tracker is public and monitored at the URL provided.
    https://github.com/hannasdev/model-switchboard/issues


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA responder a la mayoría (>50%) de las solicitudes de mejora en los últimos 2-12 meses (inclusive). [enhancement_responses]
    La respuesta PUEDE ser 'no' o una discusión sobre sus méritos. El objetivo es simplemente que haya alguna respuesta a algunas solicitudes, lo que indica que el proyecto todavía está activo. Para los propósitos de este criterio, los proyectos no necesitan contar solicitudes falsas (por ejemplo, de spammers o sistemas automatizados). Si un proyecto ya no está realizando mejoras, por favor seleccione "no cumplido" e incluya la URL que aclare esta situación a los usuarios. Si un proyecto tiende a estar abrumado por el número de solicitudes de mejora, por favor seleccione "no cumplido" y explique.

    In the applicable 2–12 month window, there were no enhancement requests submitted in the issue tracker, so there were no unanswered enhancement requests. The project issue tracker is public and monitored at the URL provided.
    https://github.com/hannasdev/model-switchboard/issues


    ¡Suficiente para una insignia!

    El proyecto DEBE tener un archivo públicamente disponible para informes y respuestas para búsquedas posteriores. (URL requerida) [report_archive]

    The project uses GitHub Issues as a publicly available, searchable archive of reports and responses, with permanent URLs for each thread.
    https://github.com/hannasdev/model-switchboard/issues


  • Proceso de informe de vulnerabilidad


    ¡Suficiente para una insignia!

    El proyecto DEBE publicar el proceso para informar vulnerabilidades en el sitio del proyecto. (URL requerida) [vulnerability_report_process]
    Los proyectos alojados en GitHub DEBERÍAN considerar habilitar el informe privado de una vulnerabilidad de seguridad. Los proyectos en GitLab DEBERÍAN considerar usar su capacidad para informar privadamente una vulnerabilidad. Los proyectos PUEDEN identificar una dirección de correo en https://PROJECTSITE/security, a menudo en la forma security@example.org. Este proceso de informe de vulnerabilidades PUEDE ser el mismo que su proceso de informe de errores. Los informes de vulnerabilidades PUEDEN ser siempre públicos, pero muchos proyectos tienen un mecanismo de informe de vulnerabilidades privado.

    The project publishes its vulnerability reporting process in SECURITY.md on the project site, including private reporting instructions via GitHub Security Advisories and the disclosure process.
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


    ¡Suficiente para una insignia!

    Si se admiten informes de vulnerabilidades privadas, el proyecto DEBE incluir cómo enviar la información de una manera que se mantenga privada. (URL requerida) [vulnerability_report_private]
    Los ejemplos incluyen un informe privado de defectos enviado en la web usando HTTPS (TLS) o un correo electrónico cifrado utilizando OpenPGP. Si los informes de vulnerabilidades son siempre públicos (por lo que nunca hay informes de vulnerabilidades privados), seleccione "no aplicable" (N/A).

    The project supports private vulnerability reporting and documents how to do so in SECURITY.md, including a direct link to create a private GitHub Security Advisory draft.
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


    ¡Suficiente para una insignia!

    El tiempo de respuesta inicial del proyecto para cualquier informe de vulnerabilidad recibido en los últimos 6 meses DEBE ser menor o igual a 14 días. [vulnerability_report_response]
    Si no ha habido vulnerabilidades reportadas en los últimos 6 meses, elija "no aplicable" (N/A).

    N/A. In the last 6 months, the project has not had publicly recorded vulnerability reports requiring an initial response-time measurement. If reports are received, our policy target is initial acknowledgment within 14 days.
    Evidence URL:
    https://github.com/hannasdev/model-switchboard/security/advisories
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


 Calidad 13/13 ●

  • Sistema de construcción funcional


    ¡Suficiente para una insignia!

    Si el software generado por el proyecto requiere ser construido para su uso, el proyecto DEBE proporcionar un sistema de compilación que pueda satisfactoriamente reconstruir automáticamente el software a partir del código fuente. [build]
    Un sistema de construcción determina qué acciones deben ocurrir para reconstruir el software (y en qué orden), y luego realiza esos pasos. Por ejemplo, puede invocar un compilador para compilar el código fuente. Si se crea un ejecutable a partir del código fuente, debe ser posible modificar el código fuente del proyecto y luego generar un ejecutable actualizado con esas modificaciones. Si el software producido por el proyecto depende de bibliotecas externas, el sistema de construcción no necesita construir esas bibliotecas externas. Si no hay necesidad de construir nada para usar el software después de modificar su código fuente, seleccione "no aplicable" (N/A).

    N/A. The project does not require a separate build step to use; it is distributed as runnable Node.js source. Users can run it directly after installing dependencies.
    https://github.com/hannasdev/model-switchboard/blob/main/package.json
    https://github.com/hannasdev/model-switchboard/blob/main/README.md


    ¡Suficiente para una insignia!

    Se SUGIERE que se utilicen herramientas comunes para construir el software. [build_common_tools]
    Por ejemplo: Maven, Ant, cmake, autotools, make o rake.

    N/A. The project does not require a separate build step for use, so build-tool selection is not applicable.


    ¡Suficiente para una insignia!

    El proyecto DEBERÍA ser construible usando solo herramientas FLOSS. [build_floss_tools]

    N/A. The project does not require a separate build step for use; it is distributed as runnable source.


  • Suite de pruebas automatizadas


    ¡Suficiente para una insignia!

    El proyecto DEBE usar al menos un conjunto de pruebas automatizado que se publique públicamente como FLOSS (este conjunto de pruebas puede mantenerse como un proyecto FLOSS separado). El proyecto DEBE mostrar claramente o documentar cómo ejecutar el conjunto(s) de pruebas (por ejemplo, a través de un script de integración continua (CI) o mediante documentación en archivos como BUILD.md, README.md, o CONTRIBUTING.md). [test]
    El proyecto PUEDE usar múltiples conjuntos de pruebas automatizadas (por ejemplo, uno que se ejecute rápidamente, versus otro que sea más exhaustivo pero requiera equipo especial). Hay muchos marcos de prueba y sistemas de soporte de pruebas disponibles, incluyendo Selenium (automatización de navegador web), Junit (JVM, Java), RUnit (R), testthat (R).

    The project uses an automated FLOSS test suite in the public repository and documents how to run it (npm test). Tests are also executed automatically in public CI on pushes and pull requests.
    Test command definition: https://github.com/hannasdev/model-switchboard/blob/main/package.json
    Public test suite files: https://github.com/hannasdev/model-switchboard/tree/main/test
    CI workflow running tests: https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml
    User-facing test invocation in docs: https://github.com/hannasdev/model-switchboard/blob/main/README.md


    ¡Suficiente para una insignia!

    Un conjunto de pruebas DEBERÍA ser invocable de forma estándar para ese lenguaje. [test_invocation]
    Ejemplos: "make check", "mvn test" o "rake test".

    The test suite is invocable in the standard Node.js ecosystem way using npm test, as documented in package.json and project documentation.
    https://github.com/hannasdev/model-switchboard/blob/main/package.json
    https://github.com/hannasdev/model-switchboard/blob/main/README.md


    ¡Suficiente para una insignia!

    Se SUGIERE que el conjunto de pruebas cubra la mayoría (o idealmente todas) las ramas de código, campos de entrada y funcionalidad. [test_most]

    The project maintains broad functional automated tests across core modules (routing, adapters, workflow, CLI, session continuity, and fuzzing), which provides substantial coverage of behavior and inputs. We continuously expand tests as new functionality is added.
    https://github.com/hannasdev/model-switchboard/tree/main/test
    https://github.com/hannasdev/model-switchboard/blob/main/package.json
    https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml


    ¡Suficiente para una insignia!

    Se SUGIERE que el proyecto implemente integración continua (donde el código nuevo o modificado se integra frecuentemente en un repositorio de código central y se ejecutan pruebas automatizadas sobre el resultado). [test_continuous_integration]

    The project implements continuous integration using GitHub Actions. On pull requests and pushes to main, CI runs automated checks including the test suite, ensuring new and changed code is continuously validated.
    https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml
    https://github.com/hannasdev/model-switchboard/actions


  • Pruebas de nueva funcionalidad


    ¡Suficiente para una insignia!

    El proyecto DEBE tener una política general (formal o no) de que a medida que se agrega nueva funcionalidad importante al software producido por el proyecto, se deben agregar pruebas de esa funcionalidad a un conjunto de pruebas automatizado. [test_policy]
    Siempre que exista una política, incluso de boca en boca, que diga que los desarrolladores deben agregar pruebas al conjunto de pruebas automatizado para la nueva funcionalidad importante, seleccione "Cumplido".

    The project has a documented policy that major new functionality must include corresponding automated tests (and bug fixes should include tests as well). This policy is defined in CONTRIBUTING and enforced through CI test execution.
    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    ¡Suficiente para una insignia!

    El proyecto DEBE tener evidencia de que la test_policy para agregar pruebas se ha cumplido en los cambios más recientes importantes al software producido por el proyecto. [tests_are_added]
    La funcionalidad importante normalmente se mencionaría en las notas de lanzamiento. No se requiere perfección, simplemente evidencia de que las pruebas se están agregando típicamente en la práctica al conjunto de pruebas automatizado cuando se agrega nueva funcionalidad importante al software producido por el proyecto.

    Recent major feature PRs include test additions in the same change set. For example, PR #24 (multi-surface advisory routing) and PR #19 (explainability and attribution) both added new source files alongside corresponding tests, demonstrating adherence to the test policy.
    https://github.com/hannasdev/model-switchboard/pull/24/files
    https://github.com/hannasdev/model-switchboard/pull/19/files


    ¡Suficiente para una insignia!

    Se SUGIERE que esta política sobre la adición de pruebas (vea test_policy) esté documentada en las instrucciones para propuestas de cambios. [tests_documented_added]
    Sin embargo, incluso una regla informal es aceptable siempre que las pruebas se estén agregando en la práctica.

    The test policy is documented in CONTRIBUTING.md under 'Test Policy', which is the instructions contributors follow when proposing changes via pull requests.
    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md#test-policy


  • Banderas de advertencia


    ¡Suficiente para una insignia!

    El proyecto DEBE habilitar una o más marcas de advertencia del compilador, un modo de lenguaje "seguro", o usar una herramienta "linter" separada para buscar errores de calidad del código o errores simples comunes, si existe al menos una herramienta FLOSS que pueda implementar este criterio en el lenguaje seleccionado. [warnings]
    Ejemplos de marcas de advertencia del compilador incluyen gcc/clang "-Wall". Ejemplos de un modo de lenguaje "seguro" incluyen JavaScript "use strict" y perl5's "use warnings". Una herramienta "linter" separada es simplemente una herramienta que examina el código fuente para buscar errores de calidad del código o errores simples comunes. Estos se habilitan típicamente dentro del código fuente o instrucciones de compilación.

    The project uses ESLint (a FLOSS linter) with eslint-plugin-security to check for code quality errors and common security vulnerabilities. Linting runs automatically in CI on every push and pull request via npm run lint.
    https://github.com/hannasdev/model-switchboard/blob/main/eslint.config.js
    https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml
    https://github.com/hannasdev/model-switchboard/blob/main/package.json


    ¡Suficiente para una insignia!

    El proyecto DEBE abordar las advertencias. [warnings_fixed]
    Estas son las advertencias identificadas por la implementación del criterio warnings. El proyecto debe corregir las advertencias o marcarlas en el código fuente como falsos positivos. Idealmente no habría advertencias, pero un proyecto PUEDE aceptar algunas advertencias (típicamente menos de 1 advertencia por 100 líneas o menos de 10 advertencias).

    All ESLint warnings have been addressed. Dynamic filesystem path warnings (detect-non-literal-fs-filename) are suppressed with a scoped config override and documented justification (paths are centrally managed and validated at the application boundary). The one no-process-exit occurrence is suppressed inline with justification at the top-level CLI entry point.
    https://github.com/hannasdev/model-switchboard/blob/main/eslint.config.js
    https://github.com/hannasdev/model-switchboard/actions (lint step shows clean)


    ¡Suficiente para una insignia!

    Se SUGIERE que los proyectos sean máximamente estrictos con las advertencias en el software producido por el proyecto, cuando sea práctico. [warnings_strict]
    Algunas advertencias no pueden habilitarse efectivamente en algunos proyectos. Lo que se necesita es evidencia de que el proyecto está esforzándose por habilitar marcas de advertencia donde pueda, de modo que los errores se detecten temprano.

    The project is maximally strict with ESLint warnings where practical. Security rules are enabled at error level, all real warnings have been addressed, and the two false-positive rule suppressions are scoped narrowly with documented justification. The lint run currently produces zero warnings.
    https://github.com/hannasdev/model-switchboard/blob/main/eslint.config.js
    https://github.com/hannasdev/model-switchboard/actions


 Seguridad 16/16 ●

 Análisis 8/8 ●


Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Hanna y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Hanna.
Entrada creada el 2026-05-12 16:00:02 UTC, última actualización el 2026-05-12 19:34:38 UTC. Última obtención de la insignia de nivel básico el 2026-05-12 18:40:46 UTC.