El error está a una palabra del arreglo que acabas de publicar

Revisado, probado, dado por terminado — y aun así incorrecto

Hicimos tres barridos de nuestra propia plataforma en tres ocasiones distintas. Cada uno encontró defectos reales en código ya revisado, probado y publicado.

• Una comprobación de seguridad bloqueaba una forma de escribir un comando peligroso y dejaba abierta la más habitual.
• Un nombre de modelo estaba fijado a mano, así que cuatro versiones posteriores dejaron de funcionar en silencio mientras todo parecía correcto.
• Una comprobación de publicación comparaba números de versión e informaba de que todo coincidía, mientras seis paquetes habían publicado código que nadie podía instalar.

Ninguno se encontró leyendo con más atención. Cada uno se encontró preguntando en qué otro sitio aparece el mismo error, y esa pregunta se puede programar.

Qué es una rutina

Tres partes. Nada más.

La tarea

Una frase que describe qué buscar.

Límites

Restricciones sobre cómo puede responder, incluidas las que nunca deben relajarse.

Cuándo parar

La condición que termina la ejecución, para que concluya en lugar de divagar.

Sin procedimiento numerado. Decirle a un modelo que haga el paso uno y luego el dos limita el resultado a lo que imaginó quien lo escribió, y cada nueva versión del modelo estrecha más ese límite. Una rutina define qué significa terminado y deja el camino al modelo.

Cinco rutinas incluidas

Cada una nace de un defecto que esta plataforma publicó de verdad. Una rutina inventada desde cero informa de trabajo que no existe, así que todas citan el incidente que hay detrás.

• Palabra vecina

  La variante cercana que se le escapó al arreglo: el mismo error, a una palabra.

• Instrucciones obsoletas

  Indicaciones de tu proyecto que el código ya contradice.

• Policía de abstracción

  Lógica copiada entre módulos donde las copias ya se han separado.

• Código muerto

  Funciones, archivos y ajustes que nada alcanza.

• Cobertura a la deriva

  Pruebas tan débiles que seguirían pasando si se borrara el comportamiento.

Una comprobación que ejecutas es una afirmación. Una comprobación que verificamos es evidencia.

Cualquiera puede ejecutar un barrido y anotar lo que encontró. Esa nota es tu propia versión de los hechos, que es justo lo que un auditor no puede aceptar: nada en ella demuestra que no escribiste sencillamente lo que te convenía.

Enterprise Skills aporta la parte que no puedes producir tú: una huella de tu código ligada al commit exacto que se revisó, refrendada y guardada donde no depende de confiar en tu máquina. Eso es lo que responde a "demuestra que esta revisión ocurrió" meses después, ante alguien que no tiene por qué creerte.

Cualquiera puede ejecutar una comprobación. No cualquiera puede demostrar que lo hizo.

Qué incluye cada plan

Diseñado, todavía no construido

Lo siguiente está especificado y en la hoja de ruta. Hoy no está disponible en ningún plan, y la CLI lo dice en lugar de ofrecer una mejora que no compra nada.

• Registros certificados: un resultado verificado y guardado con independencia de la máquina que lo produjo.
• Historial de toda la organización y enlaces que un auditor puede abrir sin licencia.
• Un resultado de rutina que pueda bloquear un merge, y rutinas que se ejecuten en todos los repositorios a la vez.

Pruébalo

Con una licencia Pro:

enterprise-skills routine list
enterprise-skills routine show adjacent-spelling
enterprise-skills routine schedule adjacent-spelling

La primera que conviene ejecutar es el barrido de palabra vecina. Es la que más encuentra de todo lo que publicamos.