willtools-demo/docs/checklist-code-map.md

Ticket checklist → check code mapping

Rebuilt 2026-08-30 from the code (ticketchecks.py, ticketpage.py), not from the previous version of this file. The prior map (dated 08-28) had gone stale: it marked 1.1, 1.3, 5.2, 5.4 and 8.2 as missing/partial when all five now have working checks, it did not know 2.2's owner mapping had not changed, it missed that CLASH-UNREADABLE and BOM-MEMBERS had since been claimed as owners of 7.1 and 5.1 in ticketpage.CHECKLIST_ITEMS, and it predates item 4.7 entirely. Status below comes from reading the check functions and grepping for whether each finding code is actually emitted — never from what the old file, or CHECKLIST_ITEMS's say-so alone, claimed.

Status vocabulary (see the task brief this file answers to): implemented — runs and compares the thing the item describes. partial — implemented inside another path, or only half the item. missing — no code. not needed — deliberately not built; who decided and why is stated.

0 — collect the whole ticket (grade A, prose-only, not numbered)

item	code	status
Union of all sheets named the mark	read_ticket collects sheets by mark (ticketqc.py)	implemented

1 — identity

#	item	grade	code	status
1.1	Sheet name equals the piece mark	A	SHEET-NAME	implemented — check_sheet_name / ticketpage.sheet_name_matches. Built since the last map; confirmed the finding is actually emitted (ticketchecks.py:2091-2102).
1.2	Sheet design-number reduces to the piece's design	A	DSN-MATCH / DSN-SUFFIX / DSN-PREFIX	implemented (ticketqc.py:1359-1377)
1.3	Exactly one ticket set per piece	A	TICKET-SET	implemented — check_ticket_set / ticketpage.ticket_set_status, plus a second finding when the plant's TKT_SHEET_COUNT parameter disagrees with the pages actually found (ticketchecks.py:2105-2162). Built since the last map.
1.4	Every placed view name refers to this design	A B	VIEW-DSN	implemented 2026-08-30 — check_view_name_design / ticketpage.view_name_design_status, with a skip probe, and it now has a CHECKLIST_ITEMS row (it had none, so it could not even report NOT RUN). The contradiction this row used to flag is closed: the item was never assessed as "not needed" — the agent that met it had no vision capability and skipped it, which was a capability gap, not a ruling (William, 2026-08-30). Re-graded A→B: recognising a design label inside a view name needs the plant's design-token pattern (derived from nomenclature.design_number_re, no new plant fact), and the verdict is WARN-only by nature — a stale name on a correct note is a reader's trap, never a defect in the piece, so it is not worth failing a ticket over. Only tokens sharing this design's letter prefix are compared, or Elevation Top 2 reduces to TOP2 and every ticket grows a false finding.
1.5	Printed call-outs do not overlap each other	C	CALLOUT-OVERLAP (+ CALLOUT-OVERLAP-UNREAD)	implemented 2026-08-30 — check_callout_overlap + ticketpage.callout_overlap_status / rect_overlap, with a skip probe. Text-bearing annotations (text notes, tags, keynotes) on the SAME placed view whose bounding boxes intersect with positive area → WARN naming both texts and the overlap size in printed inches. Boxes are converted from view-space feet through the view's Scale (ft * 12 / scale), because inches on paper is the only unit a reader can act on; a view with no readable scale is set aside, not guessed. Text-vs-linework is deliberately out of scope and the docstring says so — a call-out over a drawn edge is the normal condition on every elevation, so flagging it would report the whole sheet. Grade C, not B: a bounding box carries the text's leading and side bearings, so it is a little larger than the ink and an intersection is a shortlist for a person, never a defect claim. Rotated annotations are set aside, never flagged — an axis-aligned box circumscribes rotated glyphs and overstates them by up to the string's length — and so are annotations whose rotation cannot be read at all (unknown ≠ zero); both land under CALLOUT-OVERLAP-UNREAD at OK severity, which is unowned by any row so it can neither decide the verdict nor vanish. Measured before building (bridge, one WP ticket): 22/22 text-note boxes non-null, 0 overlapping pairs across 7 views — quiet on a good sheet.

2 — dimensions & mass

#	item	grade	code	status
2.1	Printed length/width/depth vs modelled	B	SIZE-LENGTH / SIZE-WIDTH / SIZE-MAX-* / SIZE-MIN-*	implemented (ticketqc.py:1550-1553)
2.2	Weight three ways agree, pattern reported	A	WGT-*	implemented 2026-08-30 — check_weight_three_way now gathers all three (printed = sheet.weight; reconstructed and measured = liftexport.weight_volumes, one geometry read per ticket, no erected orientation solved) and ticketpage.weight_agreement decides. With three, weight_three_way names the odd one out (WGT-PRINTED / WGT-MODEL / WGT-READ / WGT-MIXED) — it was dead code before this, which is why the item reported a disagreement without saying which of the three disagreed. With only two readable it emits WGT-TWO-WAY, never OK, naming the pair, the missing source and why it is missing; with fewer than two the skip probe reports NOT RUN with the same reason. The panel's stored weight parameter is not one of the three (it is written down, not derived) and now has its own code, WGT-PARAM, raised only when it contradicts a derived weight — it is what liftexport.weight_check reads as stated, so a stale one stops a healthy piece at the handling gate. The handling gate itself is unchanged: still an unclassified pass/fail. 2026-09-08: a wythe with a non-constant thickness (a step or taper liftexport._openings/_reconstructed_ft3 cannot represent in a plan-view projection — WP100) used to overstate the reconstruction and report WGT-READ, blaming a fine piece for a hole in the tool. _reconstructed_ft3 now cross-checks each wythe's gross-less-openings against that same solid's own Volume, and when they disagree beyond handling.weight_tolerance with no opening to explain it, the reconstruction leg alone stands down as NOT APPLICABLE (named, with the unaccounted ft3) — the measured leg is untouched, since it never depended on the reconstruction. check_weight_three_way then compares printed vs measured through the new ticketpage.weight_agreement_no_reconstruction, which — unlike the generic two-way path — CAN return WGT-OK, because with the tool's own limitation named, two-way agreement really is the whole answer; disagreement in that state is WGT-TWO-WAY-NA, not WGT-READ.
2.3	Unit weight on ticket vs design summary	A	PCF-NOTE / PCF-MODEL	implemented (ticketqc.py:1315-1325)
2.4	Cast extras counted in weight	A	CAST-EXTRA	implemented 2026-08-30 — check_cast_extras + ticketpage.cast_extra_agreement. Not a weight comparison: a SET comparison. The counted side is liftexport.extra_cast_members — split out of extra_cast_ft3 so 2.4 reads exactly the members whose Volume fed 2.2's reconstructed_lb, and cannot drift from it. The drawn side is the ticket's words: a BOM row or a placed view's text naming a families.cast_include token. Three things it catches that 2.2 cannot: an extra the ticket names that the model does not carry (missing from all three weights, which then agree), an extra in the weight that the ticket never names, and a cast member whose Volume could not be read (drawn, and counted as nothing). BOM states respected: OK/PARTIAL judged, ABSENT judged from view text and says so, UNREADABLE/UNKNOWN stand the comparison down through the skip probe.

3 — concrete

#	item	grade	code	status
3.1	f'c ticket vs summary	A	FC	implemented
3.2	f'ci ticket vs summary	A	FCI	implemented
3.3	f'ci/f'c release ratio in band	B	FCI-RATIO	implemented, but distinguish from "not built." check_release_ratio + its skip probe (_probe_release_ratio) exist and run; on a model whose design spec carries no f'c/f'ci, the probe reports it as NOT RUN with the reason stated, not silence and not a finding. That is an input gap on this model, not missing code — matches the task brief's own framing.

4 — strand

#	item	grade	code	status
4.1	Printed strand count vs modelled	B	STR-QTY	implemented
4.2	Diameter & grade vs design	A	STR-DIA / STR-DIA-EXTRA	implemented
4.3	Jacking force on ticket vs design	A	JACK-FORCE	implemented (check_jacking_force)
4.4	Strand positions vs design chain from stated rail	B	STRAND-POS	implemented (check_strand_layout) — worth flagging: the code does not read a plant-stated "which rail is fixed" setting. _fit_chain tries the pattern read from both edges ("as modelled" / "mirrored") and keeps whichever fits the design chain better. That may be the right answer to a different, real ambiguity (a piece modelled in either orientation) but it is not what the checklist item describes (a fixed rail declared as plant knowledge) — worth the engineer's eyes, not re-graded here since it still produces a correct-looking comparison.
4.5	Debonded strands called out where design debonds	C	STRAND-CALLOUT	implemented 2026-08-30 — check_debond_callout + ticketpage.debond_callout_status. Owner's ruling: where the debond condition is met, expect a call-out; none → WARN. It CONSUMES 4.7 rather than re-deriving geometry — both items now read one _debond_requirement(t, know), cached, so they can never disagree about whether a run is short. When 4.7 could not judge, 4.5 reports NOT RUN repeating 4.7's own reason. The ticket side is strand.debond_callout_tokens (plant nomenclature, empty default → NOT RUN with that reason) matched against BOM rows and placed-view text. Stays grade C: the call-out is a bare note with no station and no strand number, so the OK says in words that it was not verified to cover these runs.
4.6	Row count & spacing plausible	A	STRAND-SPACING / STRAND-ROWS / STRAND-GRID / BED-WIDTH / BED-OFFSET	implemented
4.7	Strand debonded wherever concrete along it runs short	B	STRAND-DEBOND	implemented — landed mid-run. It was missing on my first pass; a re-check while writing this file found check_strand_debond / ticketpage.strand_debond_runs fully wired: registered in CHECKS, has a skip probe (_probe_strand_debond) that reports NOT RUN — not silence — when the plant threshold, strand positions, length, or opening geometry aren't available, and CHECKLIST_ITEMS already carries a 4.7 row owning STRAND-DEBOND. This is the race the task brief warned about: another agent was implementing this concurrently in the same two files. Confirmed present as of this read; re-run the grep below before trusting it further out.

5 — reinforcing & embeds

#	item	grade	code	status
5.1	BED PLAN callout embed exists in model	A	BOM-MEMBERS	partial, unchanged — CHECKLIST_ITEMS now names BOM-MEMBERS as this item's owner, but check_bom_members compares BOM schedule rows (quantity + mark) against assembly member counts, not the "Elevation Top" BED PLAN callout text the checklist item actually describes (that text is only read elsewhere, by check_bed_plan_reverse, for the reverse direction). So the mapping in CHECKLIST_ITEMS is a real code path, but not quite the comparison 5.1 asks for — see disagreement #2.
5.2	Embed in model appears on ticket	A	BED-REVERSE	implemented — check_bed_plan_reverse reads the "Elevation Top" view's flat text and reports model families not called out on it, excluding families declared drawings.annotation_covered_by_parent. Built since the last map. Note it is deliberately WARN-only and reports the difference, "not a verdict" per its own docstring — a defect list, no severity judgement baked in.
5.3	Face designations consistent with model side	C	—	missing — no owner code, no narrowing logic. CHECKLIST_ITEMS gives it a reason string but check_name is None.
5.4	Mesh / WWF designation vs design	A	WWF	implemented — check_wwf_designation + ticketpage.wwf_designation_status, with a skip probe that reports NOT RUN (not a silent pass) when the design's spec carries no WWF mesh token. Built since the last map.
5.5	Bar marks legible on the drawing	D	—	SPLIT 2026-08-30, on the owner's approval, and the row narrowed. It used to read "legible and unique" and carried both. Uniqueness is a comparison between the model's marks and the sheet's printed text, so it moved to 5.6 and is computed. Legibility is a property of the picture, which no query answers, so it stays here: grade D, CHECKLIST_FOR_ENGINEER = ('5.5',), FOR ENGINEER on every report so the item can never silently vanish. The vision path is unchanged — ticketvision.ESCALATIONS still carries AI-BARMARK against item 5.5, and its question text still names uniqueness alongside legibility. That overlap is deliberate: a model reading the rendered sheet is a second, independent look, never the computed answer, and section 8bis forbids it from claiming a verdict either way.
5.6	Bar marks unique, and model and print name the same bars	B	BARMARK-UNIQUE (+ BARMARK-UNREAD)	implemented 2026-08-30 — check_bar_mark_uniqueness + ticketpage.bar_mark_uniqueness_status / mark_tokens, with a skip probe. The computable half of the old 5.5. Three WARNs for three different defects: (a) two bars sharing a mark but differing in family or length — one mark naming two parts, the expensive one, because the mark is what a fabricator cuts to; (b) a printed mark no bar carries; (c) a modelled bar whose mark is never printed. A bar with no mark at all is none of the three — it is could-not-judge under BARMARK-UNREAD, and is never counted as (c), because an absent mark cannot be looked for in the printed text. Two design decisions came from a live read and overrode the spec's assumptions. First, the spec named tags' TagText; the bridge found zero IndependentTag and zero keynote elements on the specimen ticket — every printed bar call-out is a plain TextNote on a Detail view. Both paths are gathered anyway (a tag-carrying plant must not fall through to silence) but nothing depends on the tag path, and the tag-absence conclusion is one specimen on one plant and is flagged as such. Second, the printed string contains the mark and never equals it (SR324 (F.F.), SR310 (E.L.), P76 W/ SR5602 (S.I.F.)), so the match is whole-token containment — string equality would have called every call-out on every ticket an orphan. Note-view pollution is real and separable by view TYPE: Legends carry headings and the jacking-force paragraph, Detail views carry the call-outs, so Legends are excluded — a type test, needing no plant nomenclature. Marks are read instance-first then TYPE (_bar_mark), because one bar family here carries its mark only on the type; ticketqc._member_mark is deliberately not widened, since that would change what four other checks call a mark.
5.7	No bar longer than the stock it is cut from	B	BAR-LENGTH (+ BAR-LENGTH-UNREAD)	implemented 2026-08-30 — check_bar_stock_length + ticketpage.bar_stock_length_status, with a skip probe. Owner's ruling: bars come in 40 ft stock and a piece must be shorter unless other knowledge overrides. The number is published data, so it lives in knowledge/catalogue.yaml as catalogue.rebar.stock_length_ft; null → NOT RUN naming the key, never an assumed 40. Length comes from the member.length role — the plant layer names the parameter, this repository never does — and from nothing else — no geometry, no bounding box, ever: a bent bar consumes its developed length off the stick and a box only sees the folded envelope, so it understates every bent bar and would pass exactly the pieces this catches. Verified live: the parameter is on the instance and its internal unit is decimal feet. Three states, not two — over stock (WARN), under (pass), and 0.0, which 260 elements hold and which is neither a length nor an absence, so it is reported as could-not-judge alongside the bars with no parameter at all. Grouped by MARK, because the model carries 2,122 elements at or over 40 ft (max 60.00) and a per-instance report would bury every other row. The finding ships with its ruling open: a continuous or spliced run legitimately exceeds stock (the catalogue records x CONT. (SEE PLAN) LAP SPLICE) and whether these 60-footers are those is with the owner. Nothing is pre-exempted; when he rules, the fix is a list in catalogue.rebar.stock_exempt_marks — a config edit, not a code change — matched exactly, never as a substring (SR1 must not swallow SR1101), and exemptions are listed in the report rather than silently dropped. Exempt by mark, not family, deliberately unlike _is_reinforcing: one family here carries both 11 ft and 60 ft bars, so a family exemption would switch the check off. Dormant at this plant today, correctly — which members are bars is _is_reinforcing and nothing else, this plant models bars as Specialty Equipment so Revit's category says nothing, and drawings.reinforcing_families is empty, so 5.6 and 5.7 both report NOT RUN naming that key until it is filled in.

6 — handling & lifting

#	item	grade	code	status
6.1	Insert capacity vs load	A	LIFT-CAPACITY	implemented
6.2	Insert edge distances	A	LIFT-EDGE	implemented
6.3	Current handling result exists & passes	A	HANDLE-*	implemented — bundles a large family of HANDLE- codes (reuse of a reviewed result, a sweep result, or an on-the-spot run; see the extensive module notes in ticketchecks.py above check_handling_result)
6.4	Dunnage not under an opening	A	DUN-OPENING	implemented — every dunnage finding is emitted as WARN by deliberate ruling (William, 08-28), never FAIL, so opening_clearance_fail_in is inert as a severity knob (it only shapes when something is reported at all). Closed 2026-08-30 — it could not say why it said nothing. Six silent return [] paths and no skip probe, so run_all logged RAN-EMPTY and the row read NOT RUN, reason "no probe declared" — a sentence about the tool, not the piece. Every site now sets t['_dunnage_silence'] and _probe_dunnage_openings reads it (the _bed_reverse_skip pattern; the fallback is a reason and never None, since a None return would turn all six silences into a quiet OK). Exactly one path is a pass: the fall-through after the clearance loop, where the geometry was solved and every station cleared — it now emits an explicit OK ("every one of the N dunnage station(s) is at least 6" clear"), matching 4.7's flip. "No size notes found" and "notes found but no parseable feet" are NOT passes and keep reporting NOT RUN — they are failures to read the ticket, and an unread dunnage row is not a clear one. One open judgement call, named not decided: when opening_counts_only_if_through_thickness is set and every opening is a blind recess, the plant's own rule arguably answers the question and OK could be defended; it reports NOT RUN instead, because that under-claims (the safe direction) and because the sibling path — an empty opening list — genuinely cannot be judged, liftexport._openings returning [] both for a piece with no opening and for a solid it failed to read. 4.7 can tell those apart via _strand_debond_openings; this check cannot yet. Worth the owner's ruling.
6.5	DUNNAGE / ERECTION / PICKING notes say something	A B	NOTE-CONTENT	implemented 2026-08-30 — check_note_views / ticketpage.note_view_content_status, with a skip probe. Contradiction closed on the same ruling as 1.4: no census ever found nothing; the agent had no vision and skipped it. The grading question — can the API read these notes at all, or only a picture of the sheet? — was answered rather than assumed: a note view's contents are ordinary view-owned elements, so FilteredElementCollector(doc, view.Id) sees both its text notes and its graphics, and "holds nothing but its own heading" is an exact count. No vision path was needed or built. B not A because which views are the note views is plant nomenclature (notes.instruction_views, default empty → the row reads NOT RUN with that reason, never a pass). Graphics count as content, deliberately: a plant that draws its instruction would otherwise have every note view reported empty. Not built: whether a note that does say something says the right thing — that verdict would come from a model reading the rendered sheet, is not unit-testable to a fixed answer, and does not belong on the A/B/C/D ladder at all. Needs its own category first.
6.6	Odd part count carries the BED PLAN note it requires	B	PARITY-NOTE	implemented 2026-08-31 — check_parity_note / ticketpage.parity_note_status. Section 6 because the trigger is a lifting insert's count and the consequence is an erection instruction. Grade B: the count rests on a plant-declared family name and the phrase match proves only that the words are on the plan, not that they are about this part.
6.7	Minimum spacing between lifting anchors	A	LIFT-SPACING	implemented 2026-08-31 — check_lifter_anchor_spacing. ALP catalog p53, "minimum anchor spacing is 2x the published edge distance" — usually derived (2× the part's own published edge distance, reached through the plant's alias) rather than a printed number, so a part with no published edge distance to double is NOT judged and named rather than falling back to a plant-wide default.
6.8	Printed picking stations match the modelled picking inserts	B	PICK-STATIONS, PICK-UNREADABLE	implemented 2026-08-31 — check_picking_match. Reads the PICKING text-note band on the ticket sheet, recovers stations from each end, and compares them to the modelled picking inserts (handling.lifter_groups.face.families) within handling.picking_tolerance_ft. Grade B and WARN-only by ruling (Will 08-27): a mismatch is for the engineer to judge, not the tool's verdict.
6.9	Lifting-point count vs panel length (plant rule)	A	LIFT-POINTS, LIFT-POINTS-UNREAD	implemented 2026-09-02 — check_lifting_points. An MC plant rule, not published product data: owner, verbatim, "ticketqc在MC加一条check：lifting points: MC的规矩是，panel长度小于20ft则2p lifting，大于20则是4p lifting。实际上25以内都可以2p。你按照20-25给warn，25以上给fail写。" Nominal rule — under 20 ft, 2-point; 20 ft and over, 4-point — is stricter than the real ceiling, where 2-point actually holds to 25 ft, so the grey zone between the two grades WARN and only past 25 ft does a 2-point piece FAIL. 4 or more points is OK at any length; the check flags only too FEW points for the length, never too many. Both thresholds (lifters.lifting_points.two_point_max_length_ft / .two_point_absolute_max_ft) are MC plant knowledge, landed in MC's own plant layer; a layer that has not set both — any non-MC plant — gets no judgement from this rule; since 2026-09-08 the row is pulled out of the coloured table entirely, into the "Not applicable at this plant" folded section naming the missing keys (ticketchecks.PLANT_GATE_KEYS), rather than printing as an alarming NOT RUN or holding another plant's panels to MC's numbers. A "point" is counted by clustering recognised lifters by station along the panel's long axis (liftexport.rows_of, within handling.group_tolerance_ft) so that two anchors sharing one pick point are not double-counted — the same grouping Panel Lift Check's own stage logic uses, called rather than re-derived. Zero recognised lifters is 6.1's territory and this row stands down naming it rather than repeating 6.1's own sentence.
6.10	Lifting-point position vs PCI recommendation (plant rule)	A	LIFT-POS, LIFT-POS-UNREAD	implemented 2026-09-02 — check_lift_positions. DISTINCT from 6.9: 6.9 grades the COUNT of lifting points against panel length, this grades WHERE each already-counted point sits against PCI's recommended station, and never re-flags a count problem — that stays 6.9's job. An MC plant rule, owner verbatim: "follow PCI的意思是检查一下lifter的位置，如果跟PCI相差大于6" 则报WARN。很多时候没办法完全follow PCI，但是这件事儿让用户判断可行不可行。" WARN-ONLY, never FAIL, by that ruling — a miss from PCI is for the engineer to judge feasible or not, same posture as 6.8's picking-station mismatch. Two-point pieces are compared against PCI's published 0.207L / 0.793L equal-moment two-point pick — a PCI PUBLIC CONSTANT (ticketchecks.PCI_TWO_POINT_FRACTION, mirrored by panellift.pci.OPTIMAL_TWO_LINE_FRACTION), never plant knowledge. Only the 6" tolerance (lifters.lifting_points.pci_position_tolerance_in) is MC's own number, landed beside the 6.9 thresholds; a plant that has not set it gets no judgement from this rule at all. Any point count other than two stands the row down (LIFT-POS-UNREAD, naming the count) rather than guessing a 4-point (or N-point) PCI location nobody has published to this tool yet — _pci_recommended_stations is keyed by point count so a future fill-in is one new branch, never a hardcoded guess. Boundary is strict: exactly 6" off passes, 6.01" warns. Reuses 6.9's own point clustering (liftexport.rows_of) so the two checks can never disagree about how many points there are or where one sits.
6.11	Dunnage-point count vs stripping-point count (plant rule)	A	DUN-STRIP, DUN-STRIP-UNREAD	implemented 2026-09-02 — check_dunnage_stripping_match. A third MC plant rule, owner verbatim: "默认MC panels dunnage point=stripping points。4p stripping 则4p dunnage。" — by default a panel's dunnage-point count equals its stripping-point count. And: "stripping point就是face lifters位置" / "LPA开头的就是face lifter" — a stripping point is a face (back-stripping) lifter position, and the LPA-prefixed anchors are the face lifters. A DEFAULT, NOT AN ABSOLUTE RULE — WARN-ONLY, never FAIL, same posture as 6.9/6.10: a mismatch is the engineer's to judge feasible or not. Which lifters are "face" ones is read STRUCTURALLY, off the plant's own lifters.capacity_lb.<family>.usage: back_stripping tag, reached through the exact resolver lifter_capacity() uses (knowledge._longest_substring_match, longest key wins) so this row and 6.1 can never disagree about which entry a family resolves to; the bare LPA family-name prefix is a FALLBACK, used only when the resolved entry (or the absence of one) carries no usage tag at all — never overriding one that says otherwise. Stripping points (N_strip) are counted exactly like 6.9/6.10 — liftexport.rows_of clusters recognised lifters into stations within handling.group_tolerance_ft, and a station counts toward N_strip when ANY lifter sharing it is a face/stripping one. Dunnage points (N_dun) are read exactly like 6.4 reads them — via _dunnage_station_reader, factored out of check_dunnage_openings 2026-09-02 so the two checks can never quietly disagree about where the dunnage sits or why a ticket's row would not read — but unlike 6.4 this needs the count whether or not the piece has an opening, so it never gates on one. Gated on lifters.lifting_points.dunnage_matches_stripping, co-located with the 6.9/6.10 keys; a plant that has not set it gets no judgement from this row at all. Stand-downs: the MC key absent (since 2026-09-08, pulled into the "Not applicable at this plant" section naming it, not a coloured-table NOT RUN); zero recognised lifters (defers to 6.1 by name, 6.9's pattern); no lifter position readable (DUN-STRIP-UNREAD); zero face/stripping lifters identified though other lifters exist (DUN-STRIP-UNREAD, named — never a quiet 0-vs-0 pass); dunnage stations unreadable (DUN-STRIP-UNREAD, reusing 6.4's own silence reasons).

7 — interference

#	item	grade	code	status
7.1	Interference check	B	CLASH, CLASH-UNREADABLE	implemented — check_member_interference. CLASH-UNREADABLE is now explicitly claimed as an owner in CHECKLIST_ITEMS (it was in the old map's "legacy, unmapped" list — that has changed, see disagreement #3). Findings are WARN-only by deliberate ruling (Will 08-28): measured over 57 archived tickets, 157 findings, almost all reinforcing/strand/mesh crossing an anchor or embed. The engineer looked at the most frequent pair (SR701 x P106, 13 tickets / 39 findings) and called it a real problem worth warning about — do not infer the rest are noise from that fact alone; that inference was made once before and overruled.

8 — text hygiene

#	item	grade	code	status
8.1	No unresolved design-summary lines	C	SPEC-UNRESOLVED	implemented (check_spec_unresolved)
8.2	No invisible/non-printing characters	A	INVISIBLE	implemented — check_invisible / ticketpage.invisible_chars, scanning every sheet parameter string read for the ticket. Built since the last map.

---

Disagreements between ticketpage.CHECKLIST_ITEMS and ticket-checklist.md

1. Two checklist items still have no row in CHECKLIST_ITEMS: 2.4 and 4.5. (1.4 was on this list; it got its row on 2026-08-30 along with the check behind it.) (4.7 landed mid-run — see its row above and the race notice — and now has a CHECKLIST_ITEMS row.) For items with no code this means the per-ticket report has no NOT RUN row either — it cannot say "we didn't check this," it can only say nothing, which is exactly the failure mode ticket-checklist.md's closing line warns against ("A system that cannot say what it did not do cannot be measured"). Nowhere is it explained why 2.4/4.5 are absent from the table.
2. 5.1's owner code doesn't implement 5.1 as written. CHECKLIST_ITEMS names BOM-MEMBERS as 5.1's owner; the actual comparison it runs is BOM schedule rows vs. assembly member counts, not "the BED PLAN callouts exist in the model" (which reads a different view's text entirely, and is already coded — for the reverse direction — inside check_bed_plan_reverse). Not a new problem, but worth restating since the ownership claim invites reading it as more complete than it is.
3. The previous map's "legacy codes with no checklist row" list is stale on two entries. BOM-MEMBERS and CLASH-UNREADABLE were both listed there as unmapped; CHECKLIST_ITEMS now explicitly claims them as owners of 5.1 and 7.1 respectively. Removed from the unmapped list below.
4. The 1.4/6.5 "not needed" framing does not check out. CLOSED 2026-08-30 by the owner. There was no "not needed" decision to find, which is why no one could find it: the agent that met 1.4 and 6.5 had no vision capability and skipped both on that basis. A capability gap, not a ruling. Both were wanted, both were re-graded (A→B, reasons on their rows above) and both are now built. Worth keeping as a record of the failure shape: a skip with no reason attached became, one map later, a decision nobody made — the same silence-reads-as-a-verdict problem the NOT RUN row exists to prevent, one level up in the documentation.

The three gap directions

1. Checklist items with no code (missing): 4.5, 5.3. (4.7 was in this list at the start of this read; it landed mid-run — see the race notice on its row above — and is now implemented. 1.4 and 6.5 were built 2026-08-30.)

2. Checklist items covered only inside another path (partial):

• 2.2 CLOSED 2026-08-30 — the ticket report now runs the three-way itself and names the odd one out; see its row above. liftexport.weight_check is still an unclassified pass/fail gate on the handling path, which is a different thing and deliberately left alone.
• 2.4 — cast extras are folded into weight_check's reconstructed number, no standalone comparison.
• 5.1 — implemented as a BOM-table-vs-members check, not the BED-PLAN-text comparison the item describes.

3. Finding codes that answer no checklist item, verified against the current CHECKLIST_ITEMS owners (this list has shrunk since the last map — BOM-MEMBERS and CLASH-UNREADABLE are no longer in it, see disagreement #3):

• PICK-STATIONS — check_picking_match compares the ticket's PICKING diagram stations against modelled picking inserts. The checklist has no picking item (§6 covers dunnage only). Confirmed still unmapped.

• BOM-STRAND — check_bom_strand_count's BOM-linear-feet / section-print / model three-way agreement on strand count. Conceptually sits between 4.1 and 4.3 but is not named by either. Confirmed still unmapped.

• BAR-UNPAIRED — a side-output of the interference check: bars with no counterpart in another layer and no insert nearby, i.e. unexplained by the model's own symmetry logic. Confirmed still unmapped.

• LGD-MISSING (ticketqc._check_legend_identity) — re-read 2026-08-30. Two separate things were true of it and only one has been fixed.

  The original false positive is gone. It used to look for a placed view named STRAND PATTERN/REINFORCING PATTERN and FAIL when there was none, which fired on all 204 WP sheets because this plant draws no such view. Phase 2 repointed it: with legend.pattern_prefixes empty (the shipped default, and this plant's answer) it no longer asks about a legend view at all — it asks whether the ticket carries a BOM schedule, which is what this plant's tickets use instead. So it now reports the presence of the thing that actually exists.

  The residual false positive is a "could not read" reported as a defect. The FAIL branch — 'no pattern legend configured and no BOM table on the ticket' — reads t['bom_schedules'], and _read_bom_schedules swallows every per-schedule failure with a bare except Exception: continue (unnamed schedule, GetTableData throwing, zero-row body). A ticket whose BOM could not be read and a ticket with no BOM produce the identical empty dict, and the check calls both a FAIL. That is the same failure this toolchain keeps meeting, inverted: not a silent pass, but an unreadable input asserted as a finding. Fixing it means giving _read_bom_schedules a way to say "I saw N schedules and could not read them" and splitting the FAIL into LGD-MISSING (genuinely absent) and an LGD-UNREADABLE WARN. That is Revit-side gathering and not host-testable, so it is written down here rather than changed blind.

  Ownership is still open, and is an owner decision. No checklist item claims LGD-*. §4 and §5 name the strand and reinforcing values; nothing in the checklist asks "does this ticket carry a schedule drawing at all." The two candidates: fold it into 4.1/BOM-STRAND (the BOM's existence is a precondition for the strand three-way, so its absence belongs there), or retire the code entirely and let the checks that need the BOM report their own NOT RUN when it is missing. The second is cleaner and loses nothing — a BOM-less ticket would then be reported by every check that wanted it, with reasons, instead of by one orphan code nobody's row displays. Until it is decided, LGD-MISSING's verdict — OK or FAIL — never reaches the checklist table at all.

• Handling-internals bundle (unchanged): LIFT-WEIGHT, LIFT-UNKNOWN (lift-family variants of 6.1/6.2, not matched by CHECKLIST_ITEMS' exact-code owners); HANDLE-ROW-FLEX-*, HANDLE-INSERT, HANDLE-ASPECT, HANDLE-PLUMB, HANDLE-BUDGET, HANDLE-STALE, HANDLE-SWEPT-REFUSED, HANDLE-NOT-CHECKED, HANDLE-STAGE-CONFIG, HANDLE-NO-STRENGTH, HANDLE-NO-PYTHON, HANDLE-CALC-ERROR, HANDLE-UNAVAILABLE, HANDLE-WEIGHT-GATE, HANDLE-SWEEP-UNGATED (all bundle into 6.3 via the HANDLE- prefix match in checklist_states, so they are not individually unmapped, just internal detail).

• DUN-UNREADABLE, PICK-UNREADABLE — unavailability variants, same shape as CLASH-UNREADABLE was before it got claimed; these two are not claimed by any owner list and remain unmapped.

• WGT-* variants beyond WGT-OK/WGT-PRINTED (WGT-MODEL, WGT-MIXED) — not seen live yet, so "unmapped" is moot for them so far. Correction, 2026-09-08: WGT-READ is not dead code — it fired live on WP100 (_scratch/wp100_weight.md), and that was the false positive the same day's fix addresses (see 2.2 above); the claim below was wrong the day it was written, not merely stale.

• CHECK-ERROR — wrapper for any check exception, not a checklist item.

Count by grade

Counting all 31 numbered items (1.1–8.2, including 4.7; excluding the prose-only item "0"):

grade	items	implemented	partial	missing	not needed
A	21	16	3 (2.2, 2.4, 5.1)	2 (1.4, 6.5 — contested, see above)	0
B	6	6 (incl. 4.7, landed mid-run — see race notice)	0	0	0
C	3	1 (8.1)	0	2 (4.5, 5.3)	0
D	1	0	0	0	1 (5.5)
total	31	23	3	4	1

Of the 23 "implemented," two are input-dependent rather than universally green on every model — worth keeping separate from "not built":

• 3.3 (f'ci/f'c release ratio) reports NOT RUN on a design spec that carries no f'c/f'ci — the code runs, the model just doesn't have the input.
• 5.4 (mesh/WWF) reports NOT RUN when the design's spec has no WWF mesh token — same shape: code exists, this model's spec doesn't feed it.

Both would need Extract Design re-run (or the design summary populated) to move from NOT RUN to an actual verdict on this model — I did not run that; the code alone tells you the check exists and why it currently has nothing to say.

What I could not determine from the code alone

• Whether items 1.4 and 6.5 really were the subject of a "not needed" decision, and by whom. I found no such record outside the previous version of this file, and the checklist doc's own text and tally argue the opposite for 6.5. This needs the person who made that call (if it was made) to confirm it, or ticket-checklist.md to be corrected to match reality — right now the two documents disagree with each other and I have no way to arbitrate that from source alone.
• Whether 4.7's implementation (which landed mid-run while I was writing this file — see the race notice on its row) is correct against real strand and opening data. I read the code and it is coherent and matches the checklist's description (measures continuous-concrete runs between through-thickness openings per strand, using strand.debond_below_continuous_ft from plant knowledge, never defaulted), but I have not run it against a model, per the task's constraints.
• Whether check_strand_layout's "try both edges, keep the better fit" behavior (4.4) is an intentional handling of a real modelling ambiguity or a gap against the checklist's "which rail is fixed is plant knowledge, never inferred" requirement. This needs the engineer's judgment on intent, not something a static read can settle.
• Any of this against an actual open model or ticket set — I did not run Ticket QC, touch Revit, or open the bridge, per the task's constraints.