operaciones-terminal

Operaciones Terminal

Úsalo cuando el usuario desee ejecución real del repositorio: ejecutar comandos, inspeccionar el estado de Git, depurar CI o builds, realizar una corrección estrecha, y reportar exactamente qué cambió y qué se verificó.

Este skill es intencionalmente más estrecho que la guía de codificación general. Es un flujo de trabajo operador para ejecución de terminal basada en evidencia.

Pila de habilidades

Incorpora estos skills nativos de ECC en el flujo de trabajo cuando sean relevantes:

• verification-loop para pasos exactos de prueba después de cambios
• tdd-workflow cuando la corrección adecuada necesita cobertura de regresión
• security-review cuando estén involucrados secretos, autenticación o entradas externas
• github-ops cuando la tarea dependa de ejecuciones de CI, estado de PR o estado de lanzamiento
• knowledge-ops cuando el resultado verificado deba capturarse en el contexto duradero del proyecto

Cuándo usar

• el usuario dice "corregir", "depurar", "ejecutar esto", "revisar el repositorio" o "subirlo"
• la tarea depende de la salida de un comando, estado de Git, resultados de pruebas o una corrección local verificada
• la respuesta debe distinguir entre cambiado localmente, verificado localmente, confirmado y empujado

Barreras de protección

• inspeccionar antes de editar
• permanecer solo lectura si el usuario solicitó solo auditoría/revisión
• preferir scripts y ayudantes locales del repositorio sobre contenedores ad hoc improvisados
• no afirmar corregido hasta que se haya vuelto a ejecutar el comando de prueba
• no afirmar empujado a menos que la rama se haya movido realmente al upstream

Flujo de trabajo

1. Resolver la superficie de trabajo

Establecer:

• ruta exacta del repositorio
• rama
• estado de diff local
• modo solicitado:
  • inspeccionar
  • corregir
  • verificar
  • empujar

2. Leer primero la superficie fallida

Antes de cambiar cualquier cosa:

• inspeccionar el error
• inspeccionar el archivo o la prueba
• inspeccionar el estado de Git
• usar cualquier registro o contexto ya proporcionado antes de releer ciegamente

3. Mantener la corrección estrecha

Resolver una falla dominante a la vez:

• usar el comando de prueba más pequeño y útil primero
• solo escalar a un pase de construcción/prueba más grande después de abordar la falla local
• si un comando falla repetidamente con la misma firma, detener reintentos amplios y reducir el alcance

4. Reportar el estado exacto de ejecución

Usar palabras de estado exactas:

• inspeccionado
• cambiado localmente
• verificado localmente
• confirmado
• empujado
• bloqueado

Formato de salida

SUPERFICIE
- repositorio
- rama
- modo solicitado

EVIDENCIA
- comando fallido / diff / prueba

ACCIÓN
- qué cambió

ESTADO
- inspeccionado / cambiado localmente / verificado localmente / confirmado / empujado / bloqueado

Errores comunes

• no trabajar desde memoria obsoleta cuando se puede leer el estado vivo del repositorio
• no ampliar una corrección estrecha en un cambio generalizado del repositorio
• no usar comandos destructivos de Git
• no ignorar trabajo local no relacionado

Verificación

• la respuesta nombra el comando de prueba o prueba
• el trabajo relacionado con Git nombra la ruta del repositorio y la rama
• cualquier afirmación de empuje incluye la rama objetivo y el resultado exacto