verify-buildlisted

# Skill: verify-build ## Quando Usar Invocada pelo `code-evaluator` na **Fase 1.1** do pipeline de review, antes de qualquer reviewer LLM. Determinística: o resultado é o veredito do compilador/test runner, não opinião de modelo. ## Inputs ```yaml branch: feat/... base: main diff_sha: <sha> strict_mode: true # se true, warnings de compilação contam como erro ``` ## Comportamento ### 1. Detectar stacks afetadas ```bash git diff --name-only $base..HEAD | tee /tmp/changed-files.txt ``` Classifica: | Padrão de arquivo | Stack | |---|---| | `*.cs`, `*.csproj`, `*.sln` | dotnet | | `*.ts`, `*.tsx`, `package.json`, `*.config.ts` | node | | `*.java`, `pom.xml` | java | | `*.py`, `pyproject.toml`, `requirements*.txt` | python | | `*.kt`, `*.kts`, `build.gradle*` | gradle | | `Dockerfile`, `*.yaml` (K8s), `.github/workflows/*.yml` | infra (build a partir do contexto) | Para cada stack detectada, executa o pipeline correspondente. Múltiplas stacks → executar em **paralelo** (jobs independentes do shell). ### 2. Pipeline .NET O rigor deve vir do **repositório**, não deste flag. `-p:TreatWarningsAsErrors=true` na linha de comando vale só para esta execução: o `dotnet build` que o humano roda na máquina dele, e o que roda em qualquer outro pipeline, continuam ignorando o aviso. O lugar da propriedade é o `Directory.Build.props` — auditado por `bash .forge/scripts/dotnet-baseline.sh --check`, que roda antes do build e emite `DOTNET-BASELINE` como finding `HIGH` quando o repo