encontrar-seams

Cria/Atualiza:

• .planning/SEAM-ANALYSIS.md — relatório com deps bloqueantes, técnicas recomendadas, sequência canônica de commits

Após: o user tem plano mecânico para tornar código testável antes de invocar /caracterizar. Tipicamente 5-30 minutos por dep bloqueante; sequência de pequenos commits revertíveis.

Exemplos:

/encontrar-seams src/orders/OrderService.ts                        # análise completa
/encontrar-seams src/orders/OrderService.ts --symbol charge        # método específico
/encontrar-seams src/legacy/Client.cpp --prefer link               # forçar link seam (C++ legado)

Quando este comando é o caminho certo:

• /caracterizar falhou porque deps externas impedem isolamento
• Construtor faz I/O direto (cria conexão DB no constructor)
• Usar singleton/global hardcoded no método a testar
• Framework type complexo (HttpServletRequest, Express.Request) bloqueando teste
• Código procedural (C, COBOL, Go) onde polimorfismo não está disponível

Quando NÃO é o caminho:

• Código já é testável (deps injetadas via DI) → usar /caracterizar direto
• Código é puro (sem I/O) → não precisa break-dep
• Mudança é safe-extraction (rename, IDE-extract) → usar /refactor-seguro --mode=safe-extract

1. Parsear argumentos

TARGET_FILE=$(echo "$ARGUMENTS" | awk '{print $1}')
SYMBOL=$(echo "$ARGUMENTS" | grep -oE -- '--symbol [^ ]+' | awk '{print $2}')
PREFER=$(echo "$ARGUMENTS" | grep -oE -- '--prefer [^ ]+' | awk '{print $2}')
OUTPUT_PATH=$(echo "$ARGUMENTS" | grep -oE -- '--output [^ ]+' | awk '{print $2}')

[ -z "$OUTPUT_PATH" ] && OUTPUT_PATH=".planning/SEAM-ANALYSIS.md"
[ -z "$PREFER" ]      && PREFER="object"

if [ -z "$TARGET_FILE" ]; then
  echo "ERROR: target_file é obrigatório."
  echo "Uso: /encontrar-seams <target_file> [opções]"
  exit 1
fi

if [ ! -f "$TARGET_FILE" ]; then
  echo "ERROR: arquivo não encontrado: $TARGET_FILE"
  exit 1
fi

mkdir -p "$(dirname "$OUTPUT_PATH")"