You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
concept-persistent-ir audit, six fixes. the chapter was presenting the engine's internal Rust nucleotide struct as if it were a Python-side per-base object, with attribute names that don't exist on the Python API and a fictional MUTATED flag. (1) "A base, unpacked" card now uses the real internal field names (base, germline, germline_pos, segment, flags) and is explicitly labelled "Internal nucleotide struct (Rust)" so readers understand it's the engine's data model, not a Python handle they can dereference. (2) The fictional MUTATED flag is gone; the card now lists the real NucFlags (P_NUC, N_NUC, JUNCTION, INVERTED, INDEL_INSERTED) and notes that the discriminator for "edited base" is base != germline (no flag needed). (3) the "Why per-base provenance" pseudo-Python snippet (nuc.current_base = "G" etc., which has no real handle) is replaced with a working Python snippet that shows the actual aggregate accessors users will use: sim.bases() / sim.germline_bases() / sim.germline_position(i), labelled "Reading provenance from Python". (4) "One nucleotide, fully described" card relabelled "One nucleotide in the internal pool (illustrative)", drops the fictional extras (codon_phase, region_offset, edit_history) and the per-base allele_id, and notes that allele names resolve via sim.v_allele_id() + refdata.v_allele(...).name. (5) outcome.revision(-1).bases() — verified to raise OverflowError because negative indexing isn't supported — replaced with the explicit idiom last = outcome.revision_count() - 1; outcome.revision(last).bases(). (6) the fictional allele name 'IGHV3-23*01' (doesn't exist in current shipped configs) replaced with 'IGHVF10-G38*04', which is what the integer AlleleId 146 actually resolves to via refdata. all three rewritten code blocks smoke-tested end-to-end against the v1.1 engine: provenance read works (10 edited bases out of 388 at seed=42 with count=(5,15)), revision_count() is 14 and revision(13).bases() matches sim.bases() exactly, v_allele_id 146 maps to IGHVF10-G38*04.
<li><spanclass="pass-name">current_base</span><spanclass="pass-note">A · C · G · T · N — the base as it stands today</span></li>
101
-
<li><spanclass="pass-name">germline_base</span><spanclass="pass-note">the original base before any mutation or error</span></li>
102
-
<li><spanclass="pass-name">germline_position</span><spanclass="pass-note">where this base lived in its source allele</span></li>
100
+
<li><spanclass="pass-name">base</span><spanclass="pass-note">A · C · G · T · N — the base as it stands today</span></li>
101
+
<li><spanclass="pass-name">germline</span><spanclass="pass-note">the original base before any mutation; <code>base != germline</code> means "edited"</span></li>
102
+
<li><spanclass="pass-name">germline_pos</span><spanclass="pass-note">where this base lived in its source allele; <code>NO_GERMLINE_POS</code> for indel-inserted bases</span></li>
103
103
<li><spanclass="pass-name">segment</span><spanclass="pass-note">V · D · J · NP1 · NP2 — the structural role</span></li>
<pclass="phr-note" style="margin: 10px 0 0;">The fields above describe the <em>internal</em> Rust representation. The Python side surfaces this via aggregate accessors — see the next card.</p>
106
107
</div>
107
108
108
-
<!-- Why -->
109
+
<!-- Python aggregate accessors — what users actually call -->
<spanclass="phr-field phr-more">edited bit derived from <code>base != germline</code>; allele-name resolved via <code>sim.v_allele_id()</code> + <code>refdata.v_allele(...)</code></span>
138
141
</div>
139
142
</div>
140
143
</section>
@@ -176,7 +179,7 @@ <h2>Structure is separate from content.</h2>
0 commit comments