Operações de Terminal

O que Operações de Terminal faz?

Use esta habilidade quando o usuário quiser execução real em um repositório: executar comandos, inspecionar estado do git, depurar CI ou builds, fazer uma correção restrita e relatar exatamente o que mudou e o que foi verificado.

Esta habilidade é intencionalmente mais restrita do que orientação geral de codificação. É um fluxo de trabalho operacional para execução de terminal baseada em evidências.

Pilha de Habilidades

Puxe estas habilidades nativas do ECC para o fluxo de trabalho quando relevante:

• verification-loop para etapas exatas de prova após alterações
• tdd-workflow quando a correção correta precisar de cobertura de regressão
• security-review quando segredos, autenticação ou entradas externas estiverem envolvidos
• github-ops quando a tarefa depender de execuções de CI, estado de PR ou status de release
• knowledge-ops quando o resultado verificado precisar ser capturado em contexto de projeto durável

Quando Usar

• o usuário disser "corrigir", "depurar", "executar isso", "verificar o repositório" ou "enviar"
• a tarefa depender da saída de comandos, estado do git, resultados de teste ou de uma correção local verificada
• a resposta precisar distinguir entre alterado localmente, verificado localmente, commitado e enviado

Salvaguardas

• inspecione antes de editar
• permaneça somente leitura se o usuário pediu apenas auditoria/revisão
• prefira scripts e auxiliares locais do repositório em vez de wrappers improvisados
• não afirme corrigido até que o comando de prova tenha sido reexecutado
• não afirme enviado a menos que o branch realmente tenha avançado no remoto

Fluxo de Trabalho

1. Resolver a superfície de trabalho

Estabeleça:

• caminho exato do repositório
• branch
• estado do diff local
• modo solicitado:
  • inspecionar
  • corrigir
  • verificar
  • enviar

2. Ler primeiro a superfície de falha

Antes de alterar qualquer coisa:

• inspecione o erro
• inspecione o arquivo ou teste
• inspecione o estado do git
• use quaisquer logs ou contexto já fornecidos antes de reler cegamente

3. Manter a correção restrita

Resolva uma falha dominante de cada vez:

• use o menor comando de prova útil primeiro
• só escale para uma passagem maior de build/teste depois que a falha local for resolvida
• se um comando continuar falhando com a mesma assinatura, pare as tentativas amplas e restrinja o escopo

4. Relatar estado exato de execução

Use palavras de estado exatas:

• inspecionado
• alterado localmente
• verificado localmente
• commitado
• enviado
• bloqueado

Formato de Saída

SUPERFÍCIE
- repositório
- branch
- modo solicitado

EVIDÊNCIA
- comando / diff / teste com falha

AÇÃO
- o que mudou

STATUS
- inspecionado / alterado localmente / verificado localmente / commitado / enviado / bloqueado

Armadilhas

• não trabalhe a partir de memória desatualizada quando o estado ativo do repositório puder ser lido
• não alargue uma correção restrita em agitação generalizada no repositório
• não use comandos git destrutivos
• não ignore trabalho local não relacionado

Verificação

• a resposta nomeia o comando de prova ou teste
• o trabalho relacionado ao git nomeia o caminho do repositório e o branch
• qualquer alegação de envio inclui o branch de destino e o resultado exato