[napetrov]

Summary

Fixes the dokimi install step in the reusable repo-eval.yml (#113), which broke once #135 hash-pinned requirements.lock.txt.

-pip install -c .../requirements.lock.txt "dokimi @ git+...@$SHA"
+pip install --require-hashes -r .../requirements.lock.txt
+pip install --no-deps "dokimi @ git+...@$SHA"

The same change is applied to all three jobs (validate, scan, tasks check).

Evidence

Before: self / repo validate fails on #137, which touches the workflow paths: ERROR: Can't verify hashes for these requirements because we don't have a way to hash version control repositories.
After: the deps install from the hashed lock, and dokimi is installed from the pinned SHA without resolving deps. This PR's own self / * jobs exercise the change.

Merge Danger

Door: two-way.
Blast Radius: callers of repo-eval.yml. Every one of them is broken on main right now, so this fix only restores them.

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.40%. Comparing base (ac89502) to head (59856f4).
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #154   +/-   ##
=======================================
  Coverage   91.40%   91.40%           
=======================================
  Files         216      216           
  Lines       26741    26741           
  Branches     4377     4377           
=======================================
  Hits        24442    24442           
  Misses       1635     1635           
  Partials      664      664           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vchamarthi]

@exai-bot /review

[exai-bot]

Note

AI-generated review of 59856f46f687, requested by @vchamarthi, using the default review skill. It can be wrong: verify a finding before acting on it. React with a thumbs up or down on a finding to tell the bot whether it helped.
Model us.anthropic.claude-sonnet-5-5, effort default, 7 of 93 turns, 0.3 of 48 minutes, 119k in / 2k out tokens.

The change replaces the single constrained install in the three jobs (validate, scan, tasks-check) with a hash-verified install of the lock followed by pip install --no-deps of dokimi from the pinned SHA. That fixes the "can't hash a VCS requirement" failure and is correct as written; the self jobs on the PR passed. The only gap I found is documentation that now says the old thing.

Findings

1. Minor (confirmed, maintainability): Contract doc still says the lock is used "as constraints"

dokimi/docs/repo-evaluation-contract.md:897

The doc says the workflow installs dokimi "with that commit's requirements.lock.txt as constraints". After this PR the lock is installed with --require-hashes -r and dokimi is installed with --no-deps. The header comment at .github/workflows/repo-eval.yml line 16 ("through its requirements.lock.txt, every dependency") still holds, but the doc is now inaccurate. Callers reading it would not learn that every dependency is hash-verified and that dokimi itself is installed without dependency resolution.

Suggested fix:

Reword to: "installs that commit's requirements.lock.txt with --require-hashes, then dokimi @ git+...@<sha>#subdirectory=dokimi with --no-deps".

For a human reviewer

• The lock is compiled from requirements.txt plus requirements-test.txt, so the CI jobs now install test-only packages. Confirm that is acceptable, or whether a runtime-only lock is wanted.

Not verified

I did not run pip. I assumed pip install --require-hashes -r <https URL> works for a remote requirements file, and that the lock covers all of dokimi's runtime dependencies so --no-deps leaves nothing missing. The passing self jobs support both assumptions.

[vchamarthi]

LGTM,
no blockers

[xaleryb]

• Ran: the workflow's install commands at the head, plus a tampered lock, an unhashed lock and a missing ref. The last three each fail closed. repo validate, repo scan and the full suite pass.
• Open: dokimi/docs/repo-evaluation-contract.md (line 897) still says the workflow installs dokimi with requirements.lock.txt "as constraints". Observed: the merged repo-eval.yml installs the lock with --require-hashes -r, which brings in the test packages too, and then installs dokimi with --no-deps. Expected: the doc describes the two-step hashed install.
• No commits pushed. The PR has merged.
• Left for the author: a one-paragraph doc follow-up against main.