self-verification

name	self-verification
description	Verification patterns to confirm task completion before submitting. Read this before calling submit().

Self-Verification Checklist

Before calling submit(), systematically verify your solution:

1. Re-read Requirements

• Open and re-read the original task description
• List each specific requirement (files to create, formats, thresholds, etc.)

2. Verify Each Requirement

For each requirement, run a concrete check:

• File creation: ls -la <path> and head <path>
• Code changes: Run the modified code and check output
• Build tasks: Run the built binary with a test input
• Server/web tasks: curl or wget to test endpoints — verify response content, not just that the port is open. Checking ports with ss or netstat is NOT enough
• Data tasks: Check output format, row counts, value ranges
• Config tasks: If necessary, restart the service and verify it actually works end-to-end

3. Check Your Assumptions

• If you chose between multiple approaches (e.g., normalization methods, algorithms), verify your choice matches what the task/test expects — don't assume "standard" is correct
• If you installed or modified system packages, run apt --fix-broken install and verify the package manager still works
• If your solution works on the provided example, consider whether it generalizes to different inputs (larger, different distributions, edge cases)

4. Common Pitfalls

• Git tasks: check ALL branches and history, not just HEAD
• Security tasks: verify secrets are removed from git history too
• Build tasks: verify no unwanted dependencies (ldd, nm)
• LaTeX: recompile and check ALL warnings, not just the first