terminal-ops

Terminal Ops

Use isto quando o usuário deseja execução real no repositório: executar comandos, inspecionar o estado do git, depurar CI ou builds, fazer uma correção pontual e relatar exatamente o que mudou e o que foi verificado.

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

Skill Stack

Puxe estas skills nativas da ECC para o fluxo de trabalho quando relevante:

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

Quando usar

• o usuário diz "corrigir", "depurar", "execute isso", "verifique o repositório" ou "envie"
• a tarefa depende de saída de comando, estado do git, resultados de teste ou uma correção local verificada
• a resposta deve distinguir entre alterado localmente, verificado localmente, commitado e enviado

Salvaguardas

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

Fluxo de Trabalho

1. Resolver a superfície de trabalho

Defina:

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

2. Ler a superfície com falha primeiro

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 comprovação útil primeiro
• só escale para uma passagem maior de build/teste depois que a falha local for tratada
• se um comando continuar falhando com a mesma assinatura, pare as repetições amplas e restrinja o escopo

4. Relatar estado exato da execução

Use palavras de status 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 ao vivo do repositório puder ser lido
• não amplie uma correção restrita para agitação em todo o repositório
• não use comandos git destrutivos
• não ignore trabalho local não relacionado

Verificação

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