verification-gate

Verification Gate (mandatory before "done")

Agents have repeatedly reported "implementation done" while the build is red. This rule fixes that. Applies to anyone who wrote or edited source code in the current turn — main agent or subagent.

Hard rule

You MAY NOT tell the user "done", "complete", "ready", "ready to merge", or render a green-status final message until you have:

1. Detected the project type from manifests present in cwd (search recursively, not only at root — .csproj, pom.xml, build.gradle*, etc. often live in subdirs):
   • angular.json / tsconfig.json / package.json → TS/Angular
   • Cargo.toml → Rust
   • go.mod → Go
   • pyproject.toml (with mypy/pyright config) → Python
   • pom.xml → Java/Maven
   • build.gradle / build.gradle.kts → Java or Kotlin/Gradle (check settings.gradle* + presence of *.kt vs *.java to disambiguate; Kotlin Multiplatform falls under Kotlin)
   • *.sln / *.slnx / *.slnf / *.csproj / *.fsproj / *.vbproj / global.json / Directory.Build.props → .NET (C#/F#/VB). .slnx is the XML-based format (default in .NET 10 SDK, supported since 9.0.200); .slnf is a solution filter referencing a .sln/.slnx
2. Run the matching independent verification yourself (do not trust a subagent's self-report):
   • TS/Angular: npx tsc --noEmit --pretty false
   • Rust: cargo check --message-format=short
   • Go: go build ./...
   • Python: mypy . or pyright
   • Java/Maven: mvn -q -DskipTests compile (multi-module: run from repo root, Maven recurses)
   • Java/Gradle: ./gradlew --offline compileJava compileTestJava -x test (or compileKotlin for Kotlin)
   • .NET: dotnet build --nologo -clp:ErrorsOnly --no-restore (run dotnet restore first if obj/ is missing); pass the explicit path for a solution: dotnet build path/to/Solution.sln or dotnet build path/to/Solution.slnx (SDK 9.0.200+ required for .slnx)
3. When a scripts.lint entry exists in package.json, run <pm> run lint (auto-detect package manager: bun.lock/bun.lockb → bun; pnpm-lock.yaml → pnpm; yarn.lock → yarn; else npm). Lint errors are blocking — treat them exactly like build errors: fix before claiming "done".
4. When the diff changes behavior, also run the tests covering the changed files (e.g. dotnet test --filter <Class>, npx vitest related <files> --run, npx jest --findRelatedTests <files>) or use the run skill for UI changes; a compile proves nothing about behavior.
5. Paste the last ~15 lines of each command's actual output into your reply, OR explicitly state n/a — <reason>. No paraphrasing.