will/willtools-demo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

WillTools 2026-09-09 -- clean snapshot of the development repo for review
ci / test (push) Successful in 6m18s
Details

Browse Source 
History-free snapshot of the private development repository at cbe45c5
(2026-09-09). Code, docs and public catalogue only; no plant or job
knowledge layers, no client or job names (tools/scrub.py clean). The
intro deck is left out of this snapshot because its slide images could
not be checked for job drawings.
This commit is contained in:
will123song
2026-09-09 08:32:15 -05:00
commit 8e6ee31596
406 changed files with 223435 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/ticket-audit-wp1-12.md
+213
View File
@@ -0,0 +1,213 @@
# Twelve WP1 tickets, checked against the ticket itself
WP194, 195, 196, 199, 200, 210, 213, 214, 215, 219, 220, 412 — all design WP1.
Checked 2026-08-27 against the live model and against the twelve exported PDFs.
The instruction was to run every configuration from what the ticket prints
rather than from defaults. The ticket does carry all of it. This document is
mid-revision: the machine-read pass produced several conclusions that looking at
the rendered page then overturned, and those are marked RETRACTED rather than
deleted, because the way they went wrong is the most useful thing here.
## This audit describes a set that has since been superseded
**These twelve tickets were checked before their review, and four of them were
then corrected.** The set read here is the pre-review one; a corrected set now
exists alongside it.
This is not a warning that tickets and models drift in general -- in normal use
they agree, and no standing cross-check is wanted. It happened here only because
the audit ran while the review was still in progress: the corrections reached the
model first and the exported pages had not caught up.
What that means for a reader: a figure quoted from this document describes the
ticket as it stood before review. Two of the four corrections were to dunnage,
both turning a symmetric pair into an asymmetric one:
WP199 4'-9" / 4'-9" -> 3'-0" / 5'-0" caught here as HANDLE-DUNNAGE-OPENING
WP213 4'-7" / 4'-7" -> 4'-0" / 5'-0" NOT caught here
WP219 3'-3" / 1'-0" -> 2'-9" / 1'-6" NOT caught here
WP220 3'-3" / 1'-0" -> 2'-9" / 1'-6" NOT caught here
**One of four.** The three misses are the useful part, and section 5 keeps the
reason: for WP219 and WP220 nothing usable was extracted at all, and an item
with no data behind it produced no finding rather than a loud one. A check that
cannot see its input has not passed; it has not run.
---
## 1. RETRACTED — the ticket does print the handling positions
An earlier version of this document said the three handling notes print no
dimensions. **That was wrong, and the error was mine.** The finding came from a
text extraction of the PDF content streams; it missed those dimensions, and I
reported the absence as fact instead of as a limit of the tool that produced it.
Rendering WP210 and looking at it shows the notes fully dimensioned:
| note | printed on WP210 |
| --- | --- |
| PICKING/STRIPPING | `2'-6"` `7'-6"` … `7'-6"` `2'-6"` — four pick points |
| ERECTION | `1'-8"` — one point |
| DUNNAGE | `5'-2"` and `5'-2"` |
The `U+200E` overrides on those dimensions are real — they are in the model —
but they clearly do not blank the printed value. What they do instead is not
established, and no conclusion should be drawn from them until someone looks.
**Method note, which is the durable lesson here:** reading a drawing's text
stream is not reading the drawing. Everything in this document that came from
text extraction alone is suspect; everything that came from the rendered page is
what a person would see. Render and look.
## 2. What the ticket carries, read off the page
WP210, both sheets:
- **Title block** — MARK WP210, LENGTH 24'-11", WIDTH 8'-5", THICKNESS 8",
WEIGHT 20,950 lbs, CONCRETE f'ci 3500 / f'c 6000, QUANTITY 1, PRODUCT CODE
120008, BASE MIX 5.17 CY, FACE MIX 0.00 CY, PAGE 1 OF 2.
- **A bill of materials on sheet 1** — QTY / MARK / DESCRIPTION, twelve rows:
P106 x5, P114 x2, SP29 x1, SP30 x1, P76 x4 (erection anchor, 8 ton),
P136 x8 (4T x 4 9/16" disk anchor, QLPD4T5WG), SR393 x36, SR394 x4,
SR538 x2, SR4156 x8, SR4996 x4, SR5602 x4, and 249 of 0010001
(1/2" 270ksi low lax strand).
- **Strand count per piece**, in section A-A: `(10) 0010001 (E.L.)`, with the
transverse chain 1'-1" / 2'-0" / 1'-7" / 2'-4" and the depths 1 3/4", 4 1/2".
- **Bar spacing**, in section B-B: SR393 `(15) @ 1'-6" = 22'-6"`, and chains for
SR4156 and SR394.
- **Jacking force**: `0.70 fpu = 28.9 kips`.
- Two production notes: the chamfer rule and the post-pour threaded-embed check.
**This is where the reinforcing schedule lives.** The `LGD-MISSING` check looks
for a placed view named `STRAND PATTERN…` or `REINFORCING PATTERN…` and there is
none anywhere in the model — but the information it is looking for is on the
ticket, as a BOM table and as counts inside the section views.
## 2b. The strand-count finding was also wrong
`STR-QTY` reported "summary prints 14 strands but 10 are modelled" on WP210.
The ticket itself prints **(10)**, and the model has 10. The 14 comes from the
WP1 design summary, which covers a family of pieces. So the 14 is a design
maximum and not this piece's count, and `legend.printed_strand_count_is_per_piece`
should be **False** for this plant. The same reasoning applies to the other four
pieces flagged; each needs its own ticket read to confirm.
## 3. Real failures
**Interference — 9 of 12 fail, but it is one pattern, not nine problems.**
| piece | count | recurring pair |
| --- | --- | --- |
| WP194 | 6 | SR5602 x P136 |
| WP196 | 5 | SR5602 x P136 |
| WP199 | 6 | (pair not named in the message) |
| WP200 | 4 | SR5602 x P136 |
| WP213 | 4 | (not named) |
| WP214 | 3 | SR5602 x P136 |
| WP215 | 4 | (not named) |
| WP195 | 2 | SR5602 x P136 |
| WP219 | 1 | SR5602 x P136 |
`SR5602 x P136` accounts for 11 of the named pairs, overlapping 0.21–0.23".
SR5602 is a nested child of the P76 embed. One family pair repeating across nine
pieces is a modelling pattern to fix once.
**Strand count — 5 of 12 disagree with the DESIGN SUMMARY, not with their own ticket.** See 2b: on WP210 the ticket prints (10) and the model has 10. Listed here only so each can be confirmed against its own page.
| piece | printed | modelled |
| --- | --- | --- |
| WP200 | 14 | 6 |
| WP214 | 14 | 6 |
| WP210 | 14 | 10 |
| WP219 | 14 | 10 |
| WP220 | 14 | 10 |
**Handling — provisional, because the ticket gave nothing to run from.** These
ran on default stages with nobody having picked the inserts:
- `HANDLE-ASPECT` on WP199, WP213, WP215 (all three stages each) — short/long
0.52, two-way action starting to matter.
- `HANDLE-INSERT` on WP215 erection, twice — P136 at 2.25 ft, line force
7,835 lb.
- `HANDLE-DUNNAGE-OPENING` on WP199 transportation — dunnage at 18.10 ft lands
inside a full-depth opening. Note this used the *default* 0.21L inset, not the
ticket's 2'-6"; with 2'-6" it may or may not clear, and the ticket does not
print it.
## 4. Failures that are not real
60 of the findings across the twelve are artefacts:
**All sixty come from ONE cause, not two.** An earlier version of this section
attributed forty-eight of them to reading one sheet of a two-sheet ticket. That
was wrong, and it was measured wrong: the multi-sheet union was implemented, and
the four codes did not move.
- `LGD-MISSING` x12 — no WP sheet in this model carries a pattern-legend view.
0 of 204. The strand count lives inside `Elevation Right`
(`(14) 0010001 (E.L.)`); the jacking force lives in a note view; the schedule
is the BOM table. The check's premise does not hold for this plant.
- `FC`, `FCI`, `PCF-NOTE`, `STR-NOTE` x12 each — **all four downstream of that
same missing legend.** `read_ticket` sets `legend_text` only when a
pattern-legend view is found:
if len(t['legends']) == 1:
t['legend_text'] = _flat_text(doc, legend.Id)
With no legend view anywhere, `legend_text` stays `None`,
`parse_concrete(None)` returns nothing, and each comparison reports "in the
summary, not found on the ticket". Which sheet the tool read was never the
issue.
Verified after the union landed: WP199, WP210 and WP412 each resolve to both
`1 OF 2` and `2 OF 2`, `read_ticket` reports two sheets, and all four codes
still fire — `legends_found: 0`, `legend_text_is_none: true`.
The multi-sheet union is still correct and still needed — a ticket **is** two
sheets, and the title block, the BOM and the sections are split across them. It
just does not fix these four.
## 5. Also found
- A `U+200E` sits in the design summary text as well, and is one of the five
lines the spec reader could not interpret. It also crashed a tool that tried
to print it.
- `TICKET NOTE - WP2- STRAND JACKING FORCE` is placed on 100 WP1 sheets. The
*content* is WP1's own number, so the note is right and the name is a
leftover. Report the name; do not infer the content is wrong.
## 6. What I need from you
1. **Confirm the reading convention for the three handling notes.** On WP210 the
ticket gives picking as `2'-6"` `7'-6"` … `7'-6"` `2'-6"` (four points),
erection as a single `1'-8"`, dunnage as `5'-2"` and `5'-2"`. I can read the
numbers; what I cannot read off the page is what each is measured from, and
for erection, what a single dimension places.
2. **The `U+200E` overrides.** They are on those dimensions in the model and they
plainly do not blank the print. Are they a deliberate formatting device, or
leftovers? If leftovers, they are worth clearing — an invisible character in a
dimension override is a trap for anything that reads the model instead of the
page, which is what every check does.
3. **`printed_strand_count_is_per_piece` should be False** on the evidence of
WP210, where the ticket prints (10) and the design summary says 14. Confirm,
and I will set it and re-run — that removes the five STR-QTY findings.
4. **What is the real interference acceptance?** The check flags shared material
over 0.125". SR5602 into P136 at 0.21–0.23" on nine pieces, where SR5602 is a
nested child of the P76 embed. Modelling artefact of the nesting, or real?
5. **The BOM table is the schedule** — confirm, and the `LGD-MISSING` check gets
repointed at it instead of at a legend view that does not exist here.
## 7. Limits of this audit
- The text extraction decoded nothing usable from WP215, WP219, WP220 and
WP412 — 14 to 174 garbage characters against 2,641 for WP194. That limit is
now moot: rendering works on all of them.
- The handling results are default-stage runs. They are enough to find a
problem and not enough to sign.
- Only WP210 has been read from the rendered page. The other eleven were read
by text extraction, which is now known to miss dimensions. **Their findings
stand only until each is rendered and looked at.**
- The handling numbers above are WP210's. The earlier text pass reported 2'-6"
dunnage on WP194 and WP199 from the model rather than the page; whether those
agree with their own printed tickets is not yet checked.