terminal-ops

Terminal Ops

Úselo cuando el usuario desee ejecución real en el 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ó.

Esta skill es intencionalmente más estrecha que una guía de codificación general. Es un flujo de trabajo operatorio para la ejecución de terminal basada en evidencia.

Pila de Skills

Incorpore estas skills nativas de ECC en el flujo de trabajo cuando sea relevante:

• verification-loop para pasos de verificación exactos después de los cambios
• tdd-workflow cuando la corrección adecuada necesite 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 releases
• knowledge-ops cuando el resultado verificado deba capturarse en el contexto duradero del proyecto

Cuándo Usar

• el usuario dice "arreglar", "depurar", "ejecutar esto", "revisar el repositorio" o "subir cambios"
• la tarea depende de la salida de comandos, el estado de git, resultados de pruebas o una corrección local verificada
• la respuesta debe distinguir entre cambiado localmente, verificado localmente, confirmado y subido

Guardarraíles

• inspeccione antes de editar
• manténgase en modo solo lectura si el usuario solo solicitó auditoría/revisión
• prefiera scripts y ayudantes locales del repositorio sobre envolturas ad hoc improvisadas
• no afirme que se ha corregido hasta que se haya vuelto a ejecutar el comando de verificación
• no afirme que se ha subido a menos que la rama realmente se haya movido upstream

Flujo de Trabajo

1. Resolver la superficie de trabajo

Determine:

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

2. Leer primero la superficie fallida

Antes de cambiar algo:

• inspeccione el error
• inspeccione el archivo o prueba
• inspeccione el estado de git
• use cualquier registro o contexto ya proporcionado antes de volver a leer a ciegas

3. Mantener la corrección estrecha

Resuelva un fallo dominante a la vez:

• use primero el comando de verificación más pequeño y útil
• solo escale a una ejecución más grande de build/prueba después de abordar el fallo local
• si un comando sigue fallando con la misma firma, detenga los reintentos amplios y reduzca el alcance

4. Reportar el estado exacto de ejecución

Use palabras de estado exactas:

• inspeccionado
• cambiado localmente
• verificado localmente
• confirmado
• subido
• bloqueado

Formato de Salida

SUPERFICIE
- repositorio
- rama
- modo solicitado

EVIDENCIA
- comando / diff / prueba que falla

ACCIÓN
- qué cambió

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

Trampas

• no trabaje desde memoria obsoleta cuando se pueda leer el estado vivo del repositorio
• no amplíe una corrección estrecha a un caos en todo el repositorio
• no use comandos destructivos de git
• no ignore trabajo local no relacionado

Verificación

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