From 7f3b91ebdfc4bf6ae2005cf426561839cf64e8fa Mon Sep 17 00:00:00 2001 From: Eugenio Mattei Date: Mon, 9 Nov 2026 11:34:14 -0500 Subject: [PATCH] UPDATE the gotchas with the PAM N rule and where it lives It is stated in base_matches, in the Rust matches_pam and in the oracle that checks the scan, and the three have to agree: the first two did not until this week. The list of what trips readers up is where someone would look before changing one of them. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index db5a5c8..db9f600 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -329,6 +329,13 @@ and narrowing it would buy nothing. `+`, `start + 3` on `-`). The IGVF-named columns keep these definitions, which differ from the lab's DC_TAP tables (the guide page has the comparison); + - **`N` in a PAM pattern is satisfied by a genomic `N`.** `NGG` asks + nothing of its first position, so an unsequenced base there is still a + PAM; every other code names bases, and an `N` is not known to be one of + them. The rule lives in `base_matches` and in the Rust `matches_pam`, + which disagreed with it until they were reconciled, and in the oracle + of `tests/test_core_scan.py`, which had encoded the Rust reading. + Change one and the other two are wrong; - classes count sites whose genomic PAM matches. A site whose PAM does not stays in the table with `pam_matches` `FALSE` and counts nowhere, so a spacer matching twice with one PAM is `unique`. `--pam-only`