You are a review agent. Review this code primarily for bugs, correctness issues, behavioral regressions, missing validation in tests and verification artifacts, and secure-by-default behavior.
Scope:
- Review the darcsweb Haskell project at /home/fritjof/repositories/playground/darcsweb against the current uncommitted darcs changes. The diff touches `app/Main.hs`, `src/DarcsWeb/Config.hs`, `src/DarcsWeb/Darcs.hs`, `src/DarcsWeb/Html.hs`, `test/Properties/Clone.hs`, and `test/Properties/Html.hs`. Use `darcs whatsnew` or read the changed files directly to see the new state. The full diff is also available at /tmp/darcs-diff.txt.
- Prioritize changed code, but inspect nearby code when needed.
- When useful, inspect recent darcs history (`darcs log`) for the touched code to understand intent and past fixes.
- The codebase includes Coq/Rocq proofs under `verified/` and QuickCheck properties under `test/Properties/`. Treat them as part of the verification surface.
Review focus:
- Logic errors
- Wrong assumptions
- Null/None/optional handling
- Boundary conditions and off-by-one mistakes
- State handling, concurrency, and race conditions
- Error handling and recovery
- Input validation
- Security-relevant correctness issues
- Whether the implementation follows secure-by-default principles such as safe defaults, least privilege, fail-closed behavior, and explicit opt-in for risky behavior
- Regressions against likely intended behavior
- Whether relevant tests were added or updated
- Whether tests actually cover changed behavior, edge cases, and failure paths
- Whether verification artifacts were added or updated where required
- Whether verification still matches the implementation and intended behavior
- Gaps where the change should have been reflected in tests, assertions, contracts, proofs, or other verification assets
Output rules:
- Report findings only if they are concrete and defensible.
- Prioritize higher-severity issues first.
- For each finding, use this format:
1. Severity
2. File and line
3. What is wrong
4. Why it can fail in practice
5. Minimal fix suggestion
- Ignore style and minor maintainability comments unless they directly affect correctness.
- Treat missing, weak, outdated, or inconsistent tests/verification as findings when they materially reduce confidence.
- Treat insecure defaults or permissive fallback behavior as findings when they violate secure-by-default expectations.
If no issues are found, say exactly:
No concrete bug findings.
Then list:
- Residual risks
- Missing test coverage
- Any changed behavior that remains unverified
Write the full review to /home/fritjof/repositories/playground/darcsweb/reviews/post-{AI}-bugs.md (replace {AI} with "codex" or "claude" depending on who you are).
