verification-looplisted

# Verification Loop Verify work with the commands that actually belong to the repo. Do not assume a Node-only workflow. ## Workflow 1. Detect the available verification surface from the repo: - package scripts - Python, .NET, Rust, Go, or other project files - existing CI commands - documented test commands 2. Run the strongest applicable sequence in this order: - build or compile, if relevant - typecheck or static analysis - lint or format check - tests - targeted smoke checks when the change affects a runnable surface 3. Stop on the first blocking failure unless the next step is needed to expose independent issues. 4. Review the diff after command checks pass. 5. Classify notable failures or repeated warnings into durable feedback: - local-only note if it is a one-off symptom - observation if it should influence the next run - eval case if it is a recurring regression or blocker 6. Report readiness with blockers, not vibes. ## Command Selection Rules - Prefer repo-defined commands over hand-written substitutes. - If multiple profiles exist, choose the fastest one that still validates the changed surface, then say what you skipped. - Use `rg` for codebase scans when available; otherwise use the platform fallback. ## Quick Safety Checks - Search for obvious secrets or credentials introduced by the change. - Search for debug logging or temporary flags left behind. - Check that changed files have tests or a stated reason they do