Improve prioritization log readability per-vartype

[riasc]

Summary

Changed

The prioritization step's log (logs/{sample}/prioritization/prioritization.log) previously emitted one [k/N] completed line per pool task (~672 per vartype on hlatest), with thin per-vartype boundaries that made it hard to spot where each vartype's work begins and ends. Three changes in workflow/scripts/prioritization/prediction.py:

• Banner header per vartype at the start of BindingAffinities.start():

  ======================================================================
    somatic.snvs
  ======================================================================
    calculate binding affinities for 672 sequences (8 alleles, epitope lengths: 8,9,10,11)...
  

• Throttle per-unit progress to ~10 messages per vartype — step = max(1, total // 10); always emits the final [total/total] line. Cadence verified at several unit counts: 5→5 lines, 12→12, 100→10, 672→11, 21504→11.
• Per-vartype closing summary replaces the bare Done:

    [somatic.snvs] done in 12.3 min
  

  with a blank line after, for visual spacing between blocks.

Combined, the prioritization log goes from ~2000 lines (672 × 3 vartypes) of progress noise to ~30 progress lines plus 3 clean section headers and 3 timing summaries.

Closes #121.

QC

• I, as a human being, have reviewed the change
• python -m py_compile workflow/scripts/prioritization/prediction.py succeeds (verified)
• snakemake --lint --configfile config/config.yaml exits 0 (verified)
• CI all green
• Eye the actual log on the next real run: confirm the per-vartype headers/closings look right and the cadence feels reasonable

[coderabbitai]

Warning

Review limit reached

@riasc, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 58 minutes and 59 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: d98ff851-5de0-4039-889b-2083bdca4532

📥 Commits

Reviewing files that changed from the base of the PR and between 39238ca and fba6716.

📒 Files selected for processing (3)

• CHANGELOG.md
• workflow/scripts/prioritization/prediction.py
• workflow/scripts/prioritization/reference.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch enhance/log-readability-121

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[riasc]

Review (Claude)

Re-read the 3 logical edits + the import time + the new t_start capture. CodeRabbit hit its review rate limit on this PR.

Verified locally

• python -m py_compile workflow/scripts/prioritization/prediction.py → rc=0.
• Throttle cadence (step = max(1, total // 10)) verified across unit counts: 5→5 / 12→12 / 100→10 / 672→11 / 21504→11 progress lines. Always emits the final [total/total].
• snakemake --lint --configfile config/config.yaml → "Congratulations, your workflow is in a good condition!"
• CI all 5 checks green.
• Edge cases: total=0 (no units) → loop doesn't execute, no progress lines, summary still prints with whatever t_start measured. total % step != 0 (e.g. 672 / 67 = 10.03…) → final [672/672] always emits via the or completed == total clause.

Findings

None. No bugs, no guideline violations. Label enhancement correct. CHANGELOG ### Changed entry added on the branch.

The remaining QC item is "Eye the actual log on the next real run" — that's a real-data confirmation only you can do; the cadence and banner placement should look right but the proof is in the file.