Terminal Ops

Use isso quando o usuário quiser execução real do 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 habilidade é intencionalmente mais restrita do que orientações gerais de codificação. É um fluxo de trabalho de operador para execução 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 as alterações
• tdd-workflow quando a correção certa 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 lançamento
• knowledge-ops quando o resultado verificado precisar ser capturado em contexto de projeto durável

Quando Usar

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

Barreiras de Proteção

• inspecionar antes de editar
• permanecer somente leitura se o usuário pediu apenas auditoria/revisão
• preferir scripts e auxiliares locais do repositório em vez de wrappers improvisados ad hoc
• não afirmar que corrigiu até que o comando de prova tenha sido executado novamente
• não afirmar que enviou a menos que o branch realmente tenha sido movido para upstream

Fluxo de Trabalho

1. Resolver a superfície de trabalho

Definir:

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

2. Ler a superfície de falha primeiro

Antes de alterar qualquer coisa:

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

3. Manter a correção pontual

Resolver uma falha dominante por vez:

• usar o menor comando de prova útil primeiro
• só escalar para uma passagem de build/teste maior após a falha local ser abordada
• se um comando continuar falhando com a mesma assinatura, parar as novas tentativas amplas e estreitar o escopo

4. Relatar o estado exato da execução

Usar palavras de status exatas:

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

Formato de Saída

SURFACE
- repo
- branch
- requested mode

EVIDENCE
- failing command / diff / test

ACTION
- what changed

STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked

Armadilhas

• não trabalhar com memória desatualizada quando o estado vivo do repositório pode ser lido
• não alargar uma correção pontual para agitação em todo o repositório
• não usar comandos git destrutivos
• não ignorar trabalho local não relacionado

Verificação

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