P49 anchors follow-ups: CPT manual as a chat source, IOM page locating, MLN resolver, shared code-or-family SQL predicate #705
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Residue from the anchors slice merged as
4616d36(refs #688 #689 #690), each parked by a controller ruling during the build:pfs.cpt_sectionheading for a detected family → the corpus chunk of that edition whosesectionmetadata matches.llm/pages.py):pfs.code_guidanceresolves to the chapter item;page_srcis the FR page only.MLN\d{6,7}references are captured withitem_key=""; no resolver to bib items exists.codes && … OR families ∋ keypredicate, now hand-copied inllm/evidence.py,pfs/reaction.pyandnotebooks/code_families.py.Tag.familykeeps keys verbatim whilepfs guidance/reactionupper-case them; all 8,518 keys are uppercase today, so nothing breaks — normalise in one place.code_cited_sourcesper-collection error isolation (one failing collection returns partial results) is new behaviour worth a docstring line.Item 1 done in
da345bc(CPT manual guideline as a chat source, from pfs.cpt_section.guideline — the corpus chunks' section metadata for the EPUB editions is unusable). Items 2–6 still open. New follow-ups from the slice-3 whole-branch review: unify the three same-chunk identities (_dedupe_key, merge_sources, _reconcile_labels) on (item_key, p_id|seq); converge the code/family containment predicates on the GIN-friendly form; the golden gaps listed on #692.Status: item 1 done (
2de806d— CPT guideline as a chat source, from pfs.cpt_section since the EPUB chunks' section metadata is unusable); items 4, 5, 6 done on main (pfs.anchors.codes_array_sql / families_array_sql / code_or_family_predicate are the single definition used by llm.evidence, pfs.reaction and the notebook — the GIN-index expression can no longer drift; pfs.families.normalize_key is applied by Tag.family and the stack pfs commands; code_cited_sources documents its per-collection error isolation). Remaining: item 2 (IOM section-level page locating inside chapter PDFs via llm/pages.py) and item 3 (an MLN booklet resolver to bib items) — both need new lookup code; leaving this open for those two.Items 2 and 3 done in 6bff63b; with items 1, 4, 5, 6 already landed this closes the list.
3. MLN resolver. MLN_RE now takes the ICN/MLN product-number forms FR prose actually uses ("ICN MLN909188", "ICN 909289", "MLN006764"), and a new MLN_MATTERS_RE captures MM/SE article numbers ("MLN Matters® Number MM9603", "MLN Matters article SE1316", "MLN Matters SE 1316", bare "article 11268" → MM11268). Locators normalise to "MLN " / "MLN Matters MM". resolve_mln matches the identifier word-bounded against bib item URLs and titles (CMS files products under the number: .../eval-mgmt-serv-guide-ICN006764.pdf, .../MM9603.pdf; the CCM booklet's curated title carries MLN909188). On the current corpus the five hand families yield one MLN row (ACP → MLN 909289, unresolved: the bib copy WK8B5FVC is filed under AdvanceCarePlanning.pdf with no number in URL or title).
2. IOM section page. pfs.guidance.iom_section_page locates a section heading inside the chapter PDF attached to the resolved item, via llm.pages.locate_section: the body heading is the "30.6.4 - Title … (Rev. 11288; Issued …)" occurrence, which the table of contents lacks. Verified on the real chapters: MCPM ch.12 §30.6.4 → p.39, §30.6 → p.36; MBPM ch.15 §230.1 → p.186. GuidanceRow gains a trailing page field and pfs.code_guidance a page column (added in place by ensure_tables; legacy NULL reads 0). Located at build time on the host (the llm image has neither the storage tree nor pymupdf). The chat's guidance lines now link resolved IOM/MLN items to their CMS PDF, with #page=N when located. The hand families' two IOM citations are chapter-level today (100-02 ch.15), so page=0 there until a rule cites a section. Guidance rebuilt for ACP/APCM/CCM/PCM/TCM.