Bug Tracker — Validation Campaign¶

Last full update: 2026-04-09 Snapshot pointer: Open-bug counts are maintained continuously in 11-weekly-updates sprint closeouts; refer there for current totals between full refreshes of this document. Test Environments: VM 102/103/104 (XP), VM 108 (Win10 x32), VM 201 (Win10 x32 Alpha)

This document tracks bugs discovered during the 2026 validation campaign. Bugs are categorized by the build/version where they were discovered.

Bug Definition

A bug is any deviation from expected user experience — including code defects, misconfigurations, missing registry entries, incomplete installations, confusing UI behavior, and environmental issues. If the user encounters something unexpected or suboptimal, it gets logged here regardless of root cause. There is no such thing as an “automation bug” or “tooling bug” — there are only bugs that automation and tooling expose. The goal is to capture every friction point so the product and its deployment can be optimized.

TB11 Source-Mode Bugs (VM 108)¶

Bugs 1–18 were found on VM 108 (Win10 x32) after removing csv.vlx and switching to direct .lsp source loading.

#	Severity	Status	Title	File(s)	Commit
1	Critical	✅ Fixed	CSV.VLX overrides all source file changes	csv.mnu, csv.mns, csv.cui	Session 1
2	High	✅ Fixed	File browser shows no .dwg files	csv.lsp (`project`)	Session 1
3	High	✅ Fixed	dirchk false positive on project directories	dirchk.lsp	Session 1
4	Critical	✅ Fixed	`#\| \|#` block comments crash AutoCAD 2000 `(load)`	Multiple .lsp files	Session 1
5	Critical	✅ Fixed	`(command "open" path)` invocation/context failure in AutoCAD 2000	scr.lsp	Session 2
6	High	✅ Fixed	`dbchk` leaves SAVEAS active on unsaved drawings	csv.lsp routing	Session 2
7	Critical	✅ Fixed	VLX detection matches VLIDE runtime, skips source loading	csv.lsp	`480c6fb`
8	Medium	✅ Fixed	`cv.bat`/`cvplst.bat` creation crashes on read-only dirs	csv.lsp	`480c6fb`
9	High	✅ Fixed	Drawing type dialog asks every time (never persists)	csv.lsp	`480c6fb`
10	Medium	✅ Fixed	Tilt-Up crashes with `FILE nil` if Attach Panels not run	tiltup.lsp	`337f000`
11	Low	✅ Fixed	`Inspanel.lsp` filename capitalization confusing	inspanel.lsp	`cd130c6`
12	High	✅ Fixed	Attach Panels crashes `lselsetp nil` if no wall lines exist	inspanel.lsp	Session 3
13	High	✅ Fixed	Wall line entities missing — no recovery + TEXT regression	wall_dlg.lsp, inspanel.lsp	Session 3
14	High	✅ Fixed	tiltlist.txt ENAME serialization — entmod rejects saved data	inspanel.lsp	`401c1b1`
15	High	✅ Fixed	Tilt-Up index bug — nn vs xn for pnllst lookup	tiltup.lsp	`ad326f5`
16	Critical	✅ Fixed	conslist.txt ENAME serialization — Layout crashes on re-read	savelay.lsp	`96f693b`
17	High	✅ Fixed	Layout index bug — nn vs xn for pnllst lookup	layout.lsp	`96f693b`
18	High	✅ Fixed	`progcont` routing reconstructed — all 17 menu items route correctly	csv.lsp (L687–950)	G-series + Step 7 PASS (Mar 6–21)

Profile/Deployment Bugs (VLX Installations)¶

Bugs discovered during AutoIT validation comparing XP VMs. These are registry/profile configuration issues that affect VLX-based installations (not source-mode).

#	Version	VM	Severity	Status	Title	Registry Key
19	PB11	103	Critical	✅ Fixed	Missing menu registration causes `setvars` Function cancelled	`...\Menus\Group1, Pop13`
20	v7.0	104	Critical	✅ Workaround verified	Startup Suite VLX crash + missing Startup Suite entries	`...\.Appload\Startup` + `acaddoc.lsp`
21	v7.0	104	High	✅ Fixed	Edit Existing Drawing can’t find CSBsite1.dwg — missing Project Settings	`...\Project Settings\CV\RefSearchPath`

Deployment, Environment & Validation Bugs (VM 104)¶

Bugs 22–30 were discovered during the Feb 28, 2026 deployment and validation campaign on VM 104 (XP-TEST). These span platform quirks, deployment script issues, validation pipeline gaps, and source-mode loading failures — all exposed by automated and manual validation testing.

#	VM(s)	Severity	Status	Title	File(s)	Commit
22	104	High	✅ Fixed	Forward slashes fail through NTFS junctions on XP	`cv-menu-validation.au3`	`5ae65f8`
23	104	Low	✅ Fixed	`propertiesclose` command doesn’t exist in AutoCAD 2000	`cv-menu-validation.au3`	`5ae65f8`
24	All	Medium	✅ Fixed	Validation screenshots overwrite — stale data contamination	`cv-menu-validation.au3`	`18a503c`
25	All	High	⚠️ Known	AutoIT false positive — error dialog detected as valid CV dialog	`cv-menu-validation.au3`	—
26	104	Medium	✅ Fixed	Git not on SSH PATH — CV Update.bat fails when run remotely	`CV Update.bat`	`94ecb94`
27	104	Low	✅ Fixed	CMD echo caret escaping corrupts generated acaddoc.lsp	`CV Update.bat`	`94ecb94`
28	104	High	✅ Fixed	`csv.lsp` not loaded in source-mode — `acaddoc.lsp` only loads menu	`CV Update.bat`, `acaddoc.lsp`	`b0550d2`
29	104	Critical	✅ Fixed	`#\| \|#` block comments in `csvmenu.lsp` crash source-mode loading	`csvmenu.lsp`	`63ff0f3`
30	104	High	🔍 Investigating	`(alert)` dialog in csvmenu.lsp blocks AutoIT — drawing open fails	`csvmenu.lsp`, `acaddoc.lsp`	—

Multi-User / New Profile Bugs¶

Bugs discovered during alpha testing when non-Administrator users log in for the first time.

#	VM(s)	Severity	Status	Title	File(s)	Commit
31	201	Critical	⏸️ Stale	New user profile missing AutoCAD configuration — CV Update is per-user (HKCU)	`CV Update.bat`	—

Historical Crash Dumps & Validation Bugs¶

Bugs discovered during the March 2, 2026 validation campaign on VM 104, plus historical crash dump analysis from VM 103.

#	VM(s)	Severity	Status	Title	File(s)	Commit
32	103	Info	📋 Historical	VM 103 `acadstk.dmp` — 6 historical AutoCAD crashes (2008–2021)	`acadstk.dmp` (2 locations)	—
33	104	High	⏸️ Stale	AutoCAD crash opening CSBsite1.dwg — `acadstk.dmp` 0xC0000005 at `_WinMain@16`	`acadstk.dmp`	—
34	104	High	✅ Fixed	`cvplst` not recognized — Batch Utilities hangs waiting for `pnllist.txt`	`btch_dlg.lsp`, `csv.lsp`	c9e4056a7
35	104	High	⏸️ Stale	CSBsite1.dwg not found — site drawing open fails	`csv.lsp` (progcont routing)	—

Trace Infrastructure Bugs (G0/G1/G2 AutoIT Scripts)¶

Bugs 82–85 were discovered during the March 2026 trace campaign (G0/G1/G2 multi-VM run). These are defects in the trace automation scripts (cv-trace-g1.au3, cv-trace-g2.au3) and the tracer LISP module, exposed by running across VMs with different initialization states.

#	VM(s)	Severity	Status	Title	File(s)	Commit
82	104	High	✅ Fixed	`cv-tracer.lsp` load fails — “no function definition: FBOUNDP” on AC2000 source-mode	`cv-tracer.lsp`, `generate-cv-tracer.py`	`ce6fc3e7`
83	All	High	✅ Fixed	G1/G2 drawing open fails — `ClipPut+^v` unreliable in AC2000 command-line mode	`cv-trace-g1.au3`, `cv-trace-g2.au3`	`ce6fc3e7`
84	108	Critical	✅ Fixed	AutoCAD crashes when G1/G2 continues executing after drawing open failure	`cv-trace-g1.au3`, `cv-trace-g2.au3`	`0dd6d166`
85	108	High	✅ Fixed	G1/G2 LISP strings arrive per-word reversed — `Send(...,1)` emits `{ENTER}` as literal text	`cv-trace-g1.au3`, `cv-trace-g2.au3`	`f6b7e69`

G1 First-Run Bugs (March 20–21, 2026)¶

Bugs 86–91 were discovered during G1/G2 trace runs on VM108. G1 completed successfully with [CV-TRACE-G1-END] written. G2 completed with [CV-TRACE-G2-END] written.

#	VM(s)	Severity	Status	Title	File(s)	Commit
86	108	High	✅ Fixed	`PANATT` crashes — `bad argument type: stringp nil` on fresh panel drawing open (pc=1)	`panatt.lsp`	`4630e005`
87	108	High	✅ Fixed	`MATL_DLG` aborts with `quit / exit abort` — `(exit)` called inside open dialog context; restructured to ssget-before-load_dialog; clean `(princ)` exit	`matl_dlg.lsp`	`3e2a7c32`
88	108	Medium	✅ Fixed	G2 CSBsite1 false negative — window detection fires before 59 XREFs finish loading	`cv-trace-g2.au3`	`4630e005`
89	108	High	✅ Fixed	`(stringp x)` not defined in AutoCAD 2000 AutoLISP via `(load)` — panatt nil-key guard crash	`panatt.lsp`	`cd63f6c8`
90	108	High	✅ Fixed	`pc=262273` always routes to `slyr_dlg` (site layers) regardless of drawing type	`csv.lsp`	`cd63f6c8`
91	108	Medium	✅ Fixed	Print cleanup `layer "s" "custom"` fails on drawings without a “custom” layer → `Function cancelled`	`csv.lsp`	`7f1bbfba`
92	108	High	✅ Fixed	`progcont > 1` dispatch has no project-context guard — CV commands run in unvalidated environment (no project loaded)	`csv.lsp`	`a9146d1f`

AutoCAD 2027 Deployment Bugs (Local Dev)¶

Bugs 93+ discovered during AutoCAD 2027 (R26.0) deployment on local dev machine (Dell Latitude 5480, Win11 Pro x64).

#	VM(s)	Severity	Status	Title	File(s)	Commit
93	Local	Critical	✅ Fixed	AutoCAD 2027 crash — `coreclr.dll` ACCESS_VIOLATION (0xC0000005) during Edit Existing Drawing	`scr.lsp`	`64d8675a5`
94	Local	High	✅ Fixed	`Unknown command "DWG"` — reverted to PB11 script-file OPEN approach	`scr.lsp`	`40c3b7071`
95	Local	High	✅ Fixed	Edit Existing Drawing blocked by Bug 92 guard when on untitled drawing	`csv.lsp`	`e5ad3aa41`
96	Local	High	✅ Fixed	Default project directory points to My Documents instead of CV Project Files	`csv.lsp`	`e5ad3aa41`
97	Local	High	✅ Fixed	Drawing Setup > Existing Project getfiled never shown — while loop condition always false	`csv.lsp`	`e5ad3aa41`
98	Local	Medium	✅ Fixed	`(exit)` in `project()` silently aborts on dialog load failure — no diagnostic output	`csv.lsp`	`cb3a1a472`
99	Local	Medium	✅ Fixed	No `error` handler in `c:csv` — unhandled errors silently abort with no diagnostics	`csv.lsp`	`cb3a1a472`
100	Local	High	✅ Fixed	“Create New Project” crashes with “This drawing has no panel data” — panatt blocks new drawings	`mp_dlg.lsp`, `panatt.lsp`, `wclist.lsp`	`95730f624`
101	Local	Low	⚠️ External	AutoCAD 2027 crash on exit — `System.ExecutionEngineException` in `coreclr_shutdown` via `vl_u_crx`	None (Autodesk bug)	—
102	Local	High	✅ Fixed	New Drawing dead end — `pcr=T` unconditionally set after getfiled kills editor launch	`csv.lsp`	—
103	All	High	✅ Fixed	`cvxpproj.lsp` export naming mismatch — 19 of 21 globals exported as null	`cvxpproj.lsp`	ec97f9eb4
104	All	Critical	✅ Fixed	Project Details not persisted to XRecord — data lost on AutoCAD restart	`projdet.lsp`	ec97f9eb4
105	Local	High	✅ Fixed	`pjdll.lsp` text-mode line reader — `read-char` returns LF (10) not CR (13), lines never terminate	`pjdll.lsp`	`e16f8f898`
106	Local	High	✅ Fixed	`projdet.lsp` import gate — `csv_contractor` already filled by title block, pj.dll-only fields never imported	`projdet.lsp`	`e16f8f898`
107	Local	High	✅ Fixed	First `c:csv` call silently aborts — `error` catches panatt failure during csv_dwgtype Tier 1, masks error from `vl-catch-all-apply`	`csv.lsp`	—
108	Local	High	✅ Fixed	`matl_dlg.lsp` cond default has stray `=` operator — Materials List crashes with “too few arguments”	`matl_dlg.lsp`	—
109	Local	High	✅ Fixed	`matl_dlg.lsp` `(cons)` misplaced paren — wcl default entry crashes with “too few arguments”	`matl_dlg.lsp`	—
110	Local	High	✅ Fixed	`okcanhlp.lsp` cancel handlers missing `(done_dialog)` — 6 dialogs uncancellable, lyr_dlg while-loop traps user	`okcanhlp.lsp`	—
111	Global	High	✅ Fixed	`(command "CMD" ...)` without dash prefix opens dialog/palette mode in modern AutoCAD — arguments fall through, `error` fires silently. Affects LAYER (70), INSERT (31), BLOCK (4), HATCH (8), ARRAY (3), PURGE (1) = 117 instances across 21 files	21 `.lsp` files (both x32/x64)	—
112	Global	Medium	✅ Fixed	47 `(exit)` calls violated Rule 19. 39 eliminated via restructuring (34 automated + 5 manual). 8 safety-critical exits retained with `[CSV-ERROR]` diagnostics (makepan×4, panatt×3, cv-diag×1)	40+ `.lsp` files (both x32/x64)	—
113	Global	Medium	✅ Fixed	12 `load_dialog` calls have no error check — nil/negative return value passed to `new_dialog` unchecked	12 `.lsp` files (both x32/x64)	—
114	Local	Medium	✅ Fixed	`(findfile "acad.exe")` in `csv.lsp` used in `substr`/`strlen` with no nil guard — crashes if acad.exe not on SFSP	`csv.lsp`	—
115	Global	Medium	✅ Fixed	30 unguarded `(open ...)` calls — 13 high-risk sites guarded with `(if f (progn ...))` pattern. makepan:146 infinite busy-wait replaced. panatt:819 already guarded. 17 low-risk (logs/diag) deferred	12 `.lsp` files (both x32/x64)	—
116	Global	Medium	✅ Fixed	13 unguarded `(ssget ...)` calls — 4 critical sites guarded (nil→copy/erase/massprop). 9 low-risk mid-workflow deferred	drawpan.lsp, finpan.lsp (both x32/x64)	—
117	Local	High	⏸️ Stale	New Project (pc=262153) hits DEFAULT on blank drawing — regression from April 13	csv.lsp, projdet.lsp	—
118	Local	High	⏸️ Stale	Project Details fields show stale/default data on panel and site drawings — get_tile called after unload_dialog (Bug 101/104 confirmed in parity testing)	projdet.lsp	—
119	Local	Medium	✅ Fixed	Materials List fails: panel “no blocks found” (no INSERTs on layer 0), site “no panels loaded” (panel NOD guard rejects site drawings)	matl_dlg.lsp, csv.lsp	04ac084d8
120	Local	High	⏸️ Stale	4 panel print/layer routes still DEFAULT after Bug 111 fix — works on site but not panel. View All Layers, Print All, Print Setup, Print Select	csv.lsp, plt.lsp	—
121	Local	High	✅ Fixed	`DIMUNIT` deprecated in AutoCAD 2004+ — `DIMLUNIT`/`DIMDEC` not set, DIMLINEAR dimensions show integer inches (23’ 7”) instead of architectural fractions (23’ 6-3/4”)	`drawdim.lsp` (both x32/x64)	DFMEA-049
122	Local	Medium	✅ Fixed	`finpan.lsp` second `drawdim '("mpvar")` call crashes with `bad argument type: consp "()"` in main-panel-only test mode — aborts before title/border insert	`finpan.lsp` (both x32/x64)	DFMEA-048

Elevation-Marker Pipeline Bugs (May 5, 2026)¶

Bugs 123–128 were discovered and fixed in a single multi-day session refactoring the right-side elevation marker stack. All six trace back to four root causes documented in DFMEA-050 through DFMEA-054. Full retrospective: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor.

#	Severity	Status	Title	File(s)	DFMEA
123	High	✅ Fixed	Right-side TOC marker duplicated by RL fallback at panel-top elevation	`drawdim.lsp` (both x32/x64)	DFMEA-054
124	High	✅ Fixed	WC at 19’-11½″ stacked on top of RL at 21’-8″ — cross-pass tracker reset hides marker overlap	`drawdim.lsp`, `finpan.lsp` (both)	DFMEA-054
125	Medium	✅ Fixed	Snake-tongue artifact: `dim1` arrow tail penetrates ELEV circle on staggered markers	`drawdim.lsp` (both x32/x64)	DFMEA-053
126	High	✅ Fixed	`\X` rendering literally in entmake’d MTEXT after switching off `dim1` (dim-text-only escape in plain MTEXT context)	`drawdim.lsp` (both x32/x64)	DFMEA-053
127	High	✅ Fixed	Right-side ELEV circles tiny — asymmetric scale-fix regression during `dd-marker-r` refactor (`replace_all` matched only the unique `dd-em-x1l` left-side string)	`drawdim.lsp` (both x32/x64)	(regression)
128	High	✅ Fixed	`cv-gui-draw.lsp` silently loaded stale `drawdim.lsp` from AutoCAD’s default SFSP — `(load m)` short-name resolution bypassed `cv-base` prefix	`cv-gui-draw.lsp`	DFMEA-050

Off-Panel Entity & Layer-Routing Bugs (May 6, 2026)¶

Discovered during deep DXF analysis comparing CSB001 feature strips test vs golden. Off-panel detector script lives at scripts/cv-find-offpanel-entities.py for ongoing scans.

#	Severity	Status	Title	File(s)	DFMEA / GH
129	Medium	✅ Fixed	`drawpan.lsp` feature-strip EXPLODE creates off-panel mirror HATCHes — back-face REGIONs hatched at negative-x UCS coords, invisible to user but bloats DXF (15 ghost entities on CSB001)	`drawpan.lsp` (both x32/x64)	DFMEA-056, #168
130	Low	✅ Fixed	Layer routing: feature-strip / window / door / pilaster dim entities land on `perimeter_dim` instead of `feature_dim`; visually correct but breaks plot-style + layer-state-manager tooling	`finpan.lsp` (multi-item pass 6)	DFMEA-057, #173
131	Medium	✅ Fixed	At-panel HATCH duplicates on FEATURE layer — +10 extras after Bug 129 mirror-hatch fix; coplanar regions from EXPLODE share on-panel bbox so off-panel detector misses them	`drawpan.lsp` (both x32/x64)	DFMEA-058, #177
132	Medium	✅ Fixed	WC dim path missing 2 LEADER entities on `connections_dim` layer — visual indicator absent for connections in tight or angled regions	`weldconn.lsp`, `drawdim.lsp` wcvar	DFMEA-059, #178
—	n/a	✅ Closed (lesson learned)	Goldenrod color BYLAYER (test) vs explicit 40 (golden) — keep test’s BYLAYER convention	n/a	#170
—	n/a	✅ Closed (lesson learned)	Combined MTEXT (test) vs separate TEXT+MTEXT (golden) — keep test’s combined-MTEXT with `\P\H0.7x;<suffix>` per `dd-sfx`	n/a	#171
—	n/a	✅ Closed (lesson learned)	Title block rebuilt as exploded LINE/TEXT entities (test) vs single TITLE block reference + 25 ATTRIBs (golden) — keep test’s exploded form for user customizability	n/a	#174

Detailed Bug Reports¶

Bug 1: CSV.VLX Overrides Source Files¶

Discovered: Session 1
Severity: Critical
Symptom: All .lsp edits had no effect — AutoCAD loaded the compiled csv.vlx binary instead.
Root Cause: The menu macros in csv.mnu, csv.mns, and csv.cui referenced csv.vlx directly. AutoCAD loaded the VLX (which bundles all modules) before any source files.
Fix: Renamed csv.vlx to csv.vlx.bak. Changed all 57 menu macros (19 per file × 3 files) from csv.vlx → csv.lsp. Deleted csv.mnc/csv.mnr cache files.
Impact: Enabled all subsequent source-mode development and testing.

Bug 2: File Browser Shows No .dwg Files¶

Discovered: Session 1
Severity: High
Symptom: “Open Existing Project” file dialog showed no files.
Root Cause: getfiled in project() used " " (space) as the file filter with flag 1 (Save mode). This showed all files but made it confusing.
Fix: Changed filter to "dwg" with flag 2 (Open mode) to show only drawing files.
File: csv.lsp — project() function

Bug 3: dirchk False Positive¶

Discovered: Session 1
Severity: High
Symptom: dirchk incorrectly flagged valid project directories as AutoCAD program directories.
Root Cause: Original implementation used greedy wildcard matching that was too broad.
Fix: Rewrote dirchk.lsp with exact path matching against acaddir.
File: dirchk.lsp

Bug 4: Block Comments Crash AutoCAD 2000¶

Discovered: Session 1
Severity: Critical
Symptom: Files with #| |# block comments caused parse errors when loaded via (load "filename").
Root Cause: AutoCAD 2000’s (load) function does not support #| |# syntax. Only the Visual LISP IDE and compiled .vlx bundles parse them.
Fix: Reverted all #| |# comments back to ;; style. Added explicit ban to .github/copilot-instructions.md.
Prevention: Coding standards now prohibit #| |# block comments.

Bug 5: `(command "open" path)` Invocation/Context Failure in AutoCAD 2000¶

Discovered: Session 2
Severity: Critical
Symptom: Automated open flow sometimes created files named _.open or routed the path argument into the wrong command context.
Root Cause: Not a universal OPEN defect. Failures came from invocation/context issues: command syntax in automation and leaked active command state (especially SAVEAS after dbchk/qsave on unsaved drawings).
Fix: Corrected automation syntax (AU3/manual validation path), removed the fragile pre-open dependency in routing, and retained vla-open + vla-activate + S::STARTUP for deterministic document switching.
File: scr.lsp (document-switch path), related routing in csv.lsp
Key Insight: (command "open" ...) is stateful/context-sensitive in AutoCAD 2000 LISP automation; ActiveX/COM open is more reliable for scripted switching.

Bug 6: dbchk Leaves SAVEAS Active¶

Discovered: Session 2
Severity: High
Symptom: After dbchk ran on an unsaved Drawing.dwg, all subsequent (command ...) calls had their arguments eaten by the still-active SAVEAS dialog.
Root Cause: dbchk calls (command "qsave"). On an untitled drawing (Drawing.dwg), QSAVE triggers SAVEAS, which opens a file dialog and leaves cmdactive=1. All subsequent LISP (command ...) calls feed arguments into SAVEAS instead of their intended commands.
Fix: Removed (dbchk) call from the existing-project routing path in csv.lsp. The vla-open approach handles the document switch without needing a pre-save.
File: csv.lsp — routing block at ~line 435

Bug 7: VLX Detection Matches VLIDE Runtime¶

Discovered: Session 3 (Feb 24, 2026)
Severity: Critical
Symptom: All 93 module functions (inspanel, tiltup, site_dlg, etc.) were undefined. Site operations (Attach Panels, Tilt-Up, Detach Panels) all failed with errors.
Root Cause: The ARX detection loop matched *vlide* in addition to *csv*. The VLIDE runtime loads into the ARX list whenever vl-load-com is called (which our new scr.lsp does). With *vlide* matching, the code took the vl-acad-defun path — which does nothing without a VLX — and skipped loading all 93 .lsp source files.
Fix: Removed *vlide* from the ARX match pattern. Only *csv* is checked now.
File: csv.lsp — module loading section (~line 240)
Commit: 480c6fb

;; BEFORE (broken):
(if (or (wcmatch a "*vlide*") (wcmatch a "*csv*"))

;; AFTER (fixed):
(if (wcmatch a "*csv*")

Bug 8: FILE nil on Batch File Creation¶

Discovered: Session 3 (Feb 24, 2026)
Severity: Medium
Symptom: error: bad argument type: FILE nil during csv startup.
Root Cause: (open) returns nil when the target directory is read-only (e.g., C:\Program Files\ACAD2000\ under UAC). The code passed nil directly to (princ ... f) without checking.
Fix: Wrapped cv.bat and cvplst.bat creation in (if f ...) guards.
File: csv.lsp — batch file creation section (~lines 360-393)
Commit: 480c6fb

Bug 9: Drawing Type Dialog Asks Every Time¶

Discovered: Session 3 (Feb 24, 2026)
Severity: High
Symptom: Every time “Drawing Setup” was run on an existing site drawing, it asked “Panel or Site?” via csv_ask_dwgtype dialog — even after choosing “Site” repeatedly.
Root Cause: The csv_ask_dwgtype function was added as a fallback for drawings with no panel_list or site_list in the Named Object Dictionary. But it never persisted the choice to the dictionary, so the next run hit the same fallback.
Fix: Replaced csv_ask_dwgtype with a 4-step detection: (1) panel_list in dictionary → panel, (2) site_list in dictionary → site, (3) filename contains *SITE* → site (heuristic), (4) fallback → panel (PB11 default behavior).
File: csv.lsp — routing logic (~lines 447-457)
Commit: 480c6fb

Bug 10: Tilt-Up Crashes Without Attach Panels¶

Discovered: Session 3 (Feb 24, 2026)
Severity: Medium
Symptom: error: bad argument type: FILE nil when running “Tilt-Up Panels” from Site Options.
Root Cause: tiltup.lsp line 2 opens tiltlist.txt for reading. This file is created by inspanel.lsp (Attach Panels workflow). If Attach Panels was never run on the drawing, the file doesn’t exist and (open ...) returns nil.
Fix: Added nil check with (alert) explaining “You must Attach Panels before Tilt-Up.” Wrapped the entire function body in (if (not f) ... (progn ...)).
File: tiltup.lsp
Commit: 337f000
Note: This is also the original PB11 behavior — both versions crash without tiltlist.txt. The fix is new defensive code.

Bug 11: Inspanel.lsp Filename Capitalization¶

Discovered: Session 3 (Feb 24, 2026)
Severity: Low
Symptom: Capital I in Inspanel.lsp looks like lowercase l (lspanel) at a glance, causing confusion when reading file listings.
Root Cause: Original file was saved with capital letter. All code references use lowercase inspanel.
Fix: git mv Inspanel.lsp inspanel.lsp
Commit: cd130c6

Bug 12: Attach Panels Crashes on Missing Wall Lines¶

Discovered: Session 3 (Feb 24, 2026)
Severity: High
Symptom: error: bad argument type: lselsetp nil when running “Attach Panels” from Site Options on CSBsite1.
Root Cause: inspanel.lsp calls (ssget "x" ...) to find LINE entities on the WALLINE layer. If no wall lines exist (or the layer has no LINE entities), ssget returns nil. The code then calls (sslength nil) which crashes. Same issue exists for the panel number TEXT entities.
Fix: Added nil guards for both wls (wall lines) and nums (panel numbers) ssget results. Each shows an (alert) explaining what’s missing and returns cleanly instead of crashing.
File: inspanel.lsp
Note: This is also a PB11 bug — the original code has no nil checks on ssget results. The drawing may need wall lines drawn before panels can be attached.

Bug 13: Wall Line Entities Missing — No Recovery + TEXT Regression¶

Discovered: Session 3
Severity: High
Symptom: Attach Panels shows “No wall lines found” alert on CSBsite1. The drawing previously had panels attached, so wall lines existed at some point.
Root Cause (two issues):
1. No recovery path: When WALLINE entities are missing (erased or drawing saved without them), inspanel had no way to regenerate them. Initial attempt using walllist.txt save/restore was broken because inspanel line 33 does del *list.txt (deletes all list files) before the recovery code runs.
2. v7.0→v11 TEXT regression: In v7.0, walline() created both LINE entities and TEXT entities (panel numbers) on the WALLINE layer. In v11 (PB11/TB11), walline() was refactored to store panel numbers as XData on LINE entities only — TEXT creation was removed. But inspanel was never updated and still searches for TEXT entities on WALLINE. This is a latent PB11 bug that only manifests when walline() is called on a fresh site (or for recovery).
Fix (three parts):
1. Moved walline to top-level in wall_dlg.lsp so it can be called from inspanel (was previously nested inside wall_dlg and only defined when the dialog ran).
2. Added grdlst auto-build to walline — builds grid lookup table from sitevar if not already set (needed when called from inspanel recovery vs. from wall_dlg dialog).
3. Restored TEXT creation in walline (v7.0 behavior) — creates panel number TEXT entities at evenly-spaced positions along each wall LINE. This fixes the v7.0→v11 regression.
4. Inspanel recovery: When ssget returns nil for WALLINE entities, calls (walline) to regenerate from site dictionary data, then retries ssget. Removed broken walllist.txt approach.
Files: wall_dlg.lsp (walline refactor + TEXT creation), inspanel.lsp (walline recovery)
Related: Bug 12 (nil guard prerequisite)

Bug 14: tiltlist.txt ENAME Serialization¶

Discovered: Session 3 (Feb 24, 2026)
Severity: High
Symptom: error: extra cdrs in dotted pair when Tilt-Up reads tiltlist.txt generated by inspanel’s fast path.
Root Cause: entget returns ENAME objects in DXF group 330 (owner pointer) and XData group -3. When prin1 writes these to a text file, it serializes them as <Entity name: 7ef73060> — a string that read cannot parse back into a valid association list. The read call either fails outright or produces malformed data that entmod rejects.
Fix: Added filter to both the fast path and normal tiltlist.txt write in inspanel.lsp. Before writing, strips any association where (type (cdr p)) is 'ENAME and any group with code -3 (XData). Only serializable DXF groups (numbers, strings, lists) are written.
File: inspanel.lsp — fast path (~line 110) and normal path (~line 480)
Commit: 401c1b1

;; Filter: strip ENAME objects and XData before prin1
(foreach p (cdr x)
  (if (and (/= (type (cdr p)) 'ENAME)
           (/= (car p) -3)
      )
    (set 'tmp (cons p tmp))
  )
)

Bug 15: Tilt-Up Index Bug — nn vs xn for pnllst Lookup¶

Discovered: Session 3 (Feb 24, 2026)
Severity: High
Symptom: error: bad association list (nil (0 . "INSERT") ...) when running Tilt-Up after Layout.
Root Cause: tiltup.lsp uses a double loop to match live panel entities (pnllst) to saved tilt data (tiltlst) by block name. When a match is found, the code substitutes the live entity name from pnllst into the saved tiltlst entry. However, the code used nn (the tiltlst loop index) to index into pnllst — should have used xn (the pnllst loop index). When tiltlst has more entries than pnllst, (nth nn pnllst) returns nil, producing (nil (0 . "INSERT") ...) which entmod rejects.
Fix: Changed (assoc -1 (nth nn pnllst)) to (assoc -1 (nth xn pnllst)).
File: tiltup.lsp — line 76
Commit: ad326f5
Note: This is a latent PB11 bug — the original production code has the same error. It only triggers when tiltlst and pnllst have different sizes.

;; BEFORE (broken) — nn is tiltlst index, wrong list:
(assoc -1 (nth nn pnllst))

;; AFTER (fixed) — xn is pnllst index, correct list:
(assoc -1 (nth xn pnllst))

Bug 16: conslist.txt ENAME Serialization — Layout Crashes on Re-read¶

Discovered: Session 4 (Feb 25, 2026)
Severity: Critical
Symptom: error: extra cdrs in dotted pair on input when running “Layout Panels” a second time (with conslist.txt already present).
Root Cause: savelay.lsp stripped only the -1 entity name pair via (cdr x) but left group 330 (ENAME owner pointers like (330 . <Entity name: 1F>)) and group -3 (XData) in the output. When prin1 wrote these ENAME values to conslist.txt, (read (read-line f)) in layout.lsp could not parse the <Entity name:...> token — it is not valid Lisp syntax.
Fix: Replaced the simple (cdr x) strip with the same ENAME/XData filter used in inspanel.lsp — checks (type (cdr p)) for 'ENAME and skips groups with code -3. Only serializable DXF groups (numbers, strings, lists) are written.
File: savelay.lsp — complete rewrite with proper formatting
Commit: 96f693b
Note: This is the conslist.txt counterpart of Bug 14 (tiltlist.txt). inspanel.lsp was fixed in Bug 14 but savelay.lsp was overlooked — same root cause, different file.

;; BEFORE (broken) — strips only -1 pair, leaves ENAME/XData:
(set 'conslst (mapcar '(lambda (x) (cdr x)) pnllst))

;; AFTER (fixed) — full ENAME/XData filter:
(set 'conslst
  (mapcar
    '(lambda (x)
      (set 'tmp nil)
      (foreach p (cdr x)
        (if (and (/= (type (cdr p)) 'ENAME)
                 (/= (car p) -3)
            )
          (set 'tmp (cons p tmp))
        )
      )
      (reverse tmp)
    )
    pnllst
  )
)

Bug 17: Layout Index Bug — nn vs xn for pnllst Lookup¶

Discovered: Session 4 (Feb 25, 2026)
Severity: High
Symptom: Layout’s second-pass restore (from conslist.txt) substitutes the wrong live entity name, causing entmod to silently fail or modify the wrong panel.
Root Cause: Identical to Bug 15 (tiltup.lsp). layout.lsp uses a double loop to match live panel entities (pnllst, indexed by xn) to saved layout data (conslst, indexed by nn). When a match is found, the code substituted the live entity name using (assoc -1 (nth nn pnllst)) — but nn is the conslst index. Should be (assoc -1 (nth xn pnllst)) to get the entity from the correct list.
Fix: Changed (nth nn pnllst) to (nth xn pnllst) in the subst call.
File: layout.lsp — second-pass branch (~line 153)
Commit: 96f693b
Note: This is a latent PB11 bug — the original production code has the same error. Same pattern as Bug 15 in tiltup.lsp.

;; BEFORE (broken) — nn is conslst index, wrong list:
(assoc -1 (nth nn pnllst))

;; AFTER (fixed) — xn is pnllst index, correct list:
(assoc -1 (nth xn pnllst))

Bug 18: `progcont` Routing Missing from Source — VLX/Source Mismatch¶

Discovered: Session 4 (Feb 27, 2026)
Updated: March 1, 2026 — root cause corrected after VLX binary analysis and OCR comparison
Severity: High → Critical (upgraded — blocks all source-mode menu routing)
Status: ✅ Fixed — March 21, 2026 (routing reconstructed in csv.lsp lines 687–950; G-series validated all 17 progcont values; P0 Step 7 PASS on configs B–G)
DFMEA: BRK-04 / BRK-05 (RPN 240 — upgraded from 70) — Section 7.1, doc 31
Symptom: “Drawing Setup”, “Create New Project”, “Create New Drawing”, “Edit Existing Drawing”, “Slope Calculator”, and “Batch Utilities” all produce the same “Panel Options” dialog in source-mode. Users expect distinct operations per menu item but get the same dialog regardless.
Root Cause (corrected Mar 1, 2026): The original analysis stated “progcont is never read by any code” — this was wrong. The progcont variable IS read by the compiled VLX bytecode and correctly routes to different dialogs per value. OCR evidence from VM 102 (PB11/VLX) confirms:
- progcont 1 → “Program Options” hub dialog
- progcont 8193 → “Slope Elevation Calculator”
- progcont 262153 → “Project Details”
- progcont 262161 → file chooser “Choose a Drawing to use as a template”
- progcont 262145 → file chooser “Choose a Drawing to edit”
- progcont 262177 → “Batch UI”
The real problem is a VLX/source code mismatch: the CSV.VLX was compiled from source that was never committed to the repository. Specifically:
- VLX’s embedded md_dlg.dcl = “ConstructiVision - Program Options” with numeric button keys ("2", "8", "16", "32", "64", "128", "256", "512", "1024", "2048", "4096", "16384") mapping to progcont bitmasks
- Source md_dlg.dcl (both PB11 and TB11) = “ConstructiVision – Panel Options” with string keys ("new", "old", "val", "pal", "vgp", etc.) — a completely different, lower-level dialog
- VLX’s compiled c:csv reads progcont and routes to different dialogs per bitmask value. The source csv.lsp never reads progcont.
- The csv.mnu menu file is the authoritative source for all progcont values (17 menu items). The au3 test fixture replicates the menu macros exactly: (progn (setq progcont N)(c:csv)).
Fix Implemented: Progcont routing reconstructed in csv.lsp lines 687–950:
1. Lines 687–710: Comment block documenting all 17 progcont values
2. Lines 713–729: Named constants for 12 unique progcont values
3. Lines 730–758: Bug 92 guard (blocks dispatch without project context)
4. Lines 762–990: Complete (cond routing dispatch for each progcont value
5. Line 994: Clears progcont after dispatch to prevent stale values
Validation: G-series trace campaign (Mar 14–21) — G1 (8/8 panel), G2 (9/9 site), G3 (5/5 remaining) all dispatched correctly. P0 Step 7 passed on configs B–G (Mar 6). All 17 menu items produce their expected dialogs.
Files: csv.lsp (routing — lines 687–950), csv.mnu (progcont source of truth)

Profile/Deployment Bug Reports¶

Bug 19: Missing Menu Registration Causes `setvars` Function Cancelled¶

Build: PB11 (Production Build 11 with VLX) VM: 103 (XP-Legacy)

Discovered: Session 5 (Feb 27, 2026) — AutoIT validation test campaign
Severity: Critical
Status: Fixed
DFMEA: 19 (NEW — Profile/registry configuration)
Symptom: “Edit Existing Drawing” menu item triggers error dialog: “ConstructiVision encountered an unexpected error. Your most recent changes cannot be saved. First Exit AutoCAD and re-open it…” with call stack showing setvars → Function cancelled.
Root Cause: The AutoCAD profile’s Menus registry key was missing the Group1 and Pop13 entries that register the CSV menu. Without menu registration:
1. AutoCAD does not load the CSV menu group on startup
2. The csv.mnu file is never parsed
3. When csv; command runs via (c:csv), the VLX loads but menu-dependent initialization may differ
4. Certain code paths that rely on menu state fail with “Function cancelled”
Registry entries required:
- HKCU\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\<<Unnamed Profile>>\Menus\Group1 = CSV C:\Program Files\ConstructiVision\csv
- HKCU\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\<<Unnamed Profile>>\Menus\Pop13 = CSV POP1
Discovery Method: AutoIT automated validation comparing VM 102 (working) vs VM 103 (failing). OCR of captured screenshots revealed the error dialog. Registry diff showed missing menu entries.

Fix: Add the two registry entries via reg add:

reg add "HKCU\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\<<Unnamed Profile>>\Menus" /v Group1 /t REG_SZ /d "CSV C:\Program Files\ConstructiVision\csv" /f
reg add "HKCU\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\<<Unnamed Profile>>\Menus" /v Pop13 /t REG_SZ /d "CSV POP1" /f

Impact: Any installation where the menu registration is incomplete (e.g., profile migration, registry corruption, incomplete installer run) will exhibit this failure. The fix should be added to Configure-ConstructiVision.ps1 for automated deployment.
Validation: Re-ran AutoIT validation on VM 103 after fix — all 11 screenshots now match VM 102 baseline.

Bug 20: Startup Suite VLX Crash + Missing Startup Suite Entries¶

Build: v7.0(patch) VM: 104 (XP-TEST)

Discovered: Session 6 (Feb 28, 2026) — AutoIT validation on VM 104 (v7.0 patch)
Severity: Critical
Status: 🔧 Workaround (deferred loading via acaddoc.lsp; root cause TBD)
DFMEA: 20 (NEW — Environment-dependent VLX load crash)
Symptom: Typing csv at the AutoCAD command line returns “Unknown command ‘CSV’. Press F1 for help.” and (c:csv) returns “error: no function definition: C:CSV”. After applying Startup Suite registry fix, AutoCAD crashes (Access Violation 0xC0000005) during VLX load. Manually clicking ConstructiVision > Program Options loads the VLX successfully — the VLX itself is fine, only the Startup Suite loading timing triggers the crash.

Investigation Timeline¶

Phase 1 — Registry fix (Session 6): Identified missing Startup Suite entries (NumStartup/1Startup). Applied registry fix. AutoCAD still failed — crashed instead of loading VLX.
Phase 2 — Crash analysis (Session 7): acadstk.dmp on VM 104 Desktop revealed 3 identical crashes:
- ExceptionCode=0xC0000005 (Access Violation)
- ExceptionAddress=0x440B73
- Reading address 0x40 (null pointer + offset = null this pointer at ECX=0x0)
- StackWalk: LocalizeReservedPlotStyleStrings+533 in acad.exe
- Timestamps: Feb 27 9:48 PM, Feb 28 7:33 AM, Feb 28 7:55 AM
Phase 3 — Binary comparison: VM 102’s acadstk.dmp (5 entries from 2008–2021) showed DIFFERENT crashes (HP plotter driver, OPM, ACDB15) — no LocalizeReservedPlotStyleStrings crash ever occurred on VM 102.

Phase 4 — Binary analysis:

acad.exe MD5 comparison (all 6,795,264 bytes):

VM	MD5 Hash	Last Modified
102 (working)	`6EB94B99B9B09DE5B8BC0D6C53AFEF10`	04/10/2008
103 (working)	`6EB94B99B9B09DE5B8BC0D6C53AFEF10`	(matches)
104 (crashing)	`E3A40A5A5EE98FF67ECE4B1F4B56E8AD`	02/10/2026

Binary diff: Only 36 bytes differ, all clustered at offset 0x6452A0–0x645368 (data section). Hex dump shows this is a registration/serial data area (_R_FFFRFFFRF pattern followed by encoded serial data) — NOT executable code. PE compile timestamp is identical (0x36FA04B0 = March 25, 1999).

Phase 5 — Exe swap DISPROVEN (Session 8):
- Test A: Patched exe + NO VLX loading (NumStartup=0) → AutoCAD starts normally, no crash
- Test B: VM 102’s original exe copied to VM 104 + VLX loading enabled → SAME CRASH (0xC0000005 at 0x440B73, LocalizeReservedPlotStyleStrings+533)
- Conclusion: The 36-byte patch is NOT the cause. Both binaries crash identically. The original acad.exe was restored from backup (acad.exe.bak-patched).

Phase 6 — Environmental comparison (Session 8):

Complete registry comparison between VM 102 (working) and VM 104 (crashing):

Component	VM 102	VM 104	Match?
Startup Suite (`NumStartup`, `1Startup`)	Present	Present (after fix)	✅
Menu registration (`Group1`, `Pop13`)	Present	Present	✅
ACAD search path	Identical	Identical	✅
`acad2000.lsp`, `acad2000doc.lsp`	Original	Identical content	✅
Plotter configs (`.pc3` files)	Identical set	Identical set	✅
DLLs in ACAD2000 directory	All match	All match	✅
DefaultConfig (printer)	`Symantec Fax Starter Edition`	`Microsoft XPS Document Writer`	❌
Installed printers	7 printers (hardware drivers)	1 printer (XPS only)	❌
Plot-related registry (`PSTYLEPOLICY`, `PLOTLEGACY`, etc.)	Present	Missing (using defaults)	❌
Plot Styles folder	19 files (4 custom .ctb)	15 files (stock only)	❌

Key finding: The crash is in LocalizeReservedPlotStyleStrings — a plot subsystem function. VM 104 has minimal printer/plotter configuration (single XPS printer) vs VM 102’s 7 hardware printers. Several plot-related registry entries (PSTYLEPOLICY, PLOTLEGACY, PAPERUPDATE, PLSPOOLALERT) are present on VM 102 but missing on VM 104.

Phase 7 — Workaround (Session 8):
- Key observation: User manually clicked ConstructiVision > Program Options → VLX loaded successfully. CSV command worked. The VLX itself is fine — the crash only occurs during Startup Suite loading (very early initialization).
- Solution: Bypass Startup Suite entirely. Load VLX via acaddoc.lsp (per-document loader) which runs after AutoCAD subsystems are fully initialized.

Root Cause:
1. Missing Startup Suite entries — v7.0(patch) installation did not register CSV.VLX in the AutoCAD Startup Suite
2. Environment-dependent crash during early VLX loading — When VLX loads via Startup Suite (very early in initialization), LocalizeReservedPlotStyleStrings crashes with null pointer dereference. This crash is NOT caused by the 36-byte exe patch (disproven by testing VM 102’s unmodified binary). The suspected trigger is VM 104’s minimal printer/plot configuration — the crash function name (LocalizeReservedPlotStyleStrings) relates to the plot subsystem, and VM 104 differs significantly from VM 102 in printer setup. Root cause remains under investigation.

Fix (workaround):

Disable Startup Suite (prevent crash):

reg add "HKCU\...\Appload\Startup" /v NumStartup /t REG_SZ /d 0 /f

Deploy acaddoc.lsp to C:\Program Files\ACAD2000\support\:

;;; acaddoc.lsp - ConstructiVision deferred VLX loader
(if (not (boundp 'c:csv))
  (progn
    (load "CSV.VLX")
    (princ "\nConstructiVision loaded.\n")
  )
)
(princ)

Deploy acad.lsp to C:\Program Files\ConstructiVision\ (backup S::STARTUP loader):

;;; acad.lsp - ConstructiVision deferred VLX loader (backup)
(defun S::STARTUP ()
  (if (not (boundp 'c:csv))
    (progn (load "CSV.VLX") (princ "\nConstructiVision loaded.\n"))
  )
  (princ)
)

Original acad.exe restored — VM 102’s binary was swapped in during Session 7 but the same crash occurred, proving the 36-byte patch was not the cause. The original was restored from backup.

Files deployed on VM 104:
- C:\Program Files\ACAD2000\support\acaddoc.lsp (749 bytes) — per-document VLX loader
- C:\Program Files\ConstructiVision\acad.lsp (778 bytes) — S::STARTUP backup loader
- C:\Program Files\ACAD2000\acad.exe — original binary restored (MD5 E3A40A5A5EE98FF67ECE4B1F4B56E8AD)
- C:\Program Files\ACAD2000\acad.exe.bak-patched — backup of original
Crash dumps preserved locally:
- reports/ocr-output/vm104-feb28/acadstk.dmp (1,998 bytes, 3 crashes)
- reports/ocr-output/vm104-feb28/acadstk-manual-run.dmp (681 bytes, 1 crash with VM 102 exe)
- reports/ocr-output/vm102-acadstk.dmp (6,824 bytes, 5 historical crashes from 2008–2021)
acad.exe binaries preserved locally:
- reports/vm-compare/acad-vm102.exe — VM 102 original (MD5 6EB94B99B9B09DE5B8BC0D6C53AFEF10)
- reports/vm-compare/acad-vm104.exe — VM 104 original (MD5 E3A40A5A5EE98FF67ECE4B1F4B56E8AD)
- reports/vm-compare/acad-vm103.exe — VM 103 (matches VM 102)
Status: ✅ Workaround verified (Feb 28, 2026). User manually opened AutoCAD on VM 104 desktop, typed csv → command recognized. Ran full validation manually — all steps passed until Bug 21 (missing Project Settings). Root cause investigation (printer/plot configuration theory) TBD.
Impact: AutoCAD 2000 installations with minimal printer configuration may fail to load VLX files via the Startup Suite. The deferred loading approach (acaddoc.lsp) is more robust than the Startup Suite for environments where the plot subsystem state is unknown at startup time.
Related: Bug 19 (menu registration). Both are profile/environment configuration issues on pre-existing installations.
Lesson Learned: The Startup Suite loads VLX files very early in AutoCAD initialization — before all subsystems (especially the plot subsystem) are fully initialized. Deferred loading via acaddoc.lsp or S::STARTUP is more robust for diverse environments. Binary comparisons (hex dumps, MD5 hashes) are important for investigation but diff ≠ causation — always verify with controlled experiments.
Historical Note: The v3.60 InstallShield script (constructivision-v3.60-setup.rul lines 3640-3652) correctly writes the startup suite registry entries. The v7.0(patch) was a manual installation that skipped this step.

Bug 21: Edit Existing Drawing Can’t Find CSBsite1.dwg — Missing Project Settings¶

Build: v7.0(patch) VM: 104 (XP-TEST)

Discovered: Session 8 (Feb 28, 2026) — Manual validation on VM 104 after Bug 20 workaround
Severity: High
Status: ✅ Fixed
DFMEA: 21 (NEW — Incomplete project path configuration)
Symptom: After Bug 20 workaround succeeded (CSV command works), user ran manual validation. “Edit Existing Drawing” opened a File Open dialog, but the dialog could not navigate to CSBsite1.dwg. The file exists at C:\Program Files\ConstructiVision\Project Files\ConstructiVision Sample Building\CSBsite1.dwg but the dialog didn’t know to look in that subfolder.

Root Cause: VM 104 was missing the AutoCAD Project Settings registry entry that tells AutoCAD where to resolve project file paths. VM 102 (working) has:

HKCU\...\Profiles\<<Unnamed Profile>>\Project Settings\CV
    RefSearchPath = C:\Program Files\ConstructiVision\Project Files;
                    C:\Program Files\ConstructiVision\Project Files\ConstructiVision Sample Building

VM 104 had the Project Settings key but no CV subkey — the v7.0(patch) manual installation never created it.

Fix:

reg add "HKCU\...\Project Settings\CV" /v RefSearchPath /t REG_SZ /d "C:\Program Files\ConstructiVision\Project Files;C:\Program Files\ConstructiVision\Project Files\ConstructiVision Sample Building" /f

Impact: Without the CV project path, AutoCAD cannot resolve xref paths or navigate to project drawings from ConstructiVision dialogs. This affects any installation where the project was not registered — all manual/incomplete installations.
Related: Bugs 19, 20 — same class: incomplete profile/registry configuration on manual v7.0 installations.
Lesson Learned: The installer must register the CV project and its RefSearchPath. Add to Configure-ConstructiVision.ps1.

Bug 22: Forward Slashes Fail Through NTFS Junctions on XP¶

Affects: All builds VM: 104 (XP-TEST)

Discovered: Session 9 (Feb 28, 2026) — OCR analysis of VM 104 validation screenshots
Severity: High
Status: ✅ Fixed
DFMEA: 22 (NEW — XP junction path resolution)
Symptom: AutoCAD showed “Cannot find the specified drawing file. Please verify that the file exists.” when the AutoIT script opened CSB001.dwg in Phase 1. The file physically exists at the expected path.
Root Cause: The AutoIT validation script used forward slashes in file paths:
```
C:/Program Files/ConstructiVision/Project Files/ConstructiVision Sample Building/CSB001.dwg
```
On Windows XP, forward slashes fail to resolve through NTFS junctions. The C:\Program Files\ConstructiVision path is a junction pointing to C:\Repos\Constructivision\src\x32\PB11-00x32. Forward slashes work for regular directories but not through junctions on XP.

Proof:
```
dir "C:\Program Files\ConstructiVision\...\CSB001.dwg"  → FOUND (183,286 bytes)
dir "C:/Program Files/ConstructiVision/.../CSB001.dwg"   → File Not Found
```
Fix: Changed all drawing file paths in cv-menu-validation.au3 from forward to backslashes.
Commit: 5ae65f8
Impact: Any script or tool that uses forward-slash paths through junctions on XP will fail silently. This is an XP-specific behavior — Windows 10 handles forward slashes through junctions correctly.
Lesson Learned: Always use backslashes in file paths on XP, especially when NTFS junctions are involved. Forward-slash normalization is unreliable on legacy Windows.

Bug 23: `propertiesclose` Command Doesn’t Exist in AutoCAD 2000¶

Affects: All builds VM: 104 (XP-TEST)

Discovered: Session 9 (Feb 28, 2026) — OCR of baseline screenshot
Severity: Low
Status: ✅ Fixed
DFMEA: 23 (NEW — AutoCAD version command mismatch)
Symptom: AutoCAD command line showed Unknown command "PROPERTIESCLOSE" during Phase 1 baseline.
Root Cause: The AutoIT script sent propertiesclose to dismiss the Properties palette, but this command was introduced in AutoCAD 2004+. It does not exist in AutoCAD 2000 (R15.0).
Fix: Removed propertiesclose from the AutoIT script.
Commit: 5ae65f8
Lesson Learned: Always verify AutoCAD commands against the R15.0 command reference. Commands available in newer versions should never be assumed to exist.

Bug 24: Validation Screenshots Overwrite — Stale Data Contamination¶

Affects: Validation pipeline VM: All

Discovered: Session 9 (Feb 28, 2026) — Timestamp analysis of screenshot files
Severity: Medium
Status: ✅ Fixed
DFMEA: 24 (NEW — Validation pipeline data integrity)
Symptom: OCR analysis showed *-no-dialog.bmp files from a 7:47 AM run mixed with 3:20 PM screenshots. Stale files from a previous run that captured “no dialog found” screenshots persisted into the new run’s output directory, contaminating the results.
Root Cause: The AutoIT script wrote all screenshots to C:\CV-Validation\VM###\ with fixed filenames. If a new run produced fewer screenshots (or different screenshots), old files with the same names were overwritten but old files with different names persisted.
Fix: Added timestamped run subdirectories (run-YYYYMMDD-HHMMSS/) so each run gets a clean output directory. Added latest-run.txt pointer file for easy discovery of the most recent run.
Commit: 18a503c
Lesson Learned: Validation outputs must be immutable per-run. Never overwrite previous results — always write to a unique directory.

Bug 25: AutoIT False Positive — Error Dialog Detected as Valid CV Dialog¶

Affects: Validation pipeline VM: All

Discovered: Session 9 (Feb 28, 2026) — OCR revealed 01-csv-entry-dialog.bmp was actually the “Cannot find the specified drawing file” error dialog
Severity: High
Status: ⚠️ Known limitation
DFMEA: 25 (NEW — Validation false positive)
Symptom: AutoIT validation log reported 01-csv-entry-dialog: PASS — but OCR of the actual screenshot showed it was AutoCAD’s “Cannot find the specified drawing file” error dialog, not the ConstructiVision Program Options dialog.
Root Cause: The _WaitForAnyDialog() helper function matches ANY dialog window that appears, including error dialogs. When the drawing file wasn’t found (Bug 22), AutoCAD displayed an error dialog. AutoIT detected this error dialog and logged it as the expected CSV entry dialog.
Fix: No code fix — this is a fundamental limitation of window-title-based dialog detection. Mitigation: ALWAYS run OCR on captured screenshots after every validation run. The AutoIT log’s PASS/FAIL is unreliable and must never be trusted alone.
Impact: Any validation run analysis that only reads the AutoIT log will produce false confidence. OCR verification is mandatory.
Lesson Learned: Dialog detection by window presence is insufficient for validation. OCR-based content verification is the only reliable method. This should be enforced in the validation workflow — no run is “complete” until OCR summary is reviewed.

Bug 26: Git Not on SSH PATH — CV Update.bat Fails Remotely¶

Affects: All builds VM: 104 (XP-TEST)

Discovered: Session 9 (Feb 28, 2026) — CV Update.bat /pull failed with 'git' is not recognized
Severity: Medium
Status: ✅ Fixed
DFMEA: 26 (NEW — Remote deployment PATH issue)
Symptom: Running CV Update.bat /pull via SSH returned 'git' is not recognized as an internal or external command. Git is installed and works fine when run interactively on the VM desktop.
Root Cause: SSH sessions (Bitvise SSH Server) on XP don’t inherit the full user PATH. Git’s installation path (C:\Program Files\Git\cmd) is not in the minimal PATH used by SSH sessions.
Fix: Added set "PATH=%PATH%;C:\Program Files\Git\cmd" to CV Update.bat before any git operations. Alternatively, must prepend this when running remotely.
Commit: 94ecb94
Lesson Learned: SSH sessions have a minimal PATH. Deployment scripts must be self-contained and not rely on interactive-session PATH. Always include full paths or PATH prepends for external tools.

Bug 27: CMD Echo Caret Escaping Corrupts Generated acaddoc.lsp¶

Affects: Deployment tooling VM: 104 (XP-TEST)

Discovered: Session 9 (Feb 28, 2026) — Generated acaddoc.lsp contained literal ^( characters
Severity: Low
Status: ✅ Fixed
DFMEA: 27 (NEW — Batch file string escaping)
Symptom: The acaddoc.lsp generated by CV Update.bat’s CONFIGURE_STARTUP subroutine contained literal caret characters: ^(VLX^) instead of (VLX).
Root Cause: In CMD batch files, parentheses inside echo statements require escaping with ^ when inside if/else blocks. However, the caret escaping produced literal characters in the output file.
Fix: Removed parentheses from the LISP status message strings entirely. Changed "ConstructiVision loaded (VLX)" to "ConstructiVision loaded VLX".
Commit: 94ecb94
Lesson Learned: Batch file string escaping is fragile. When generating code via echo >>, avoid characters that need escaping (parentheses, pipes, ampersands, angle brackets). Simplify output strings rather than fighting CMD’s escaping rules.

Bug 28: `csv.lsp` Not Loaded in Source-Mode — `acaddoc.lsp` Only Loads Menu¶

Affects: TB11 source-mode VM: 104 (XP-TEST)

Discovered: Session 9 (Feb 28, 2026) — Diagnostic LISP showed c:csv unbound after startup
Severity: High
Status: ✅ Fixed
DFMEA: 28 (NEW — Incomplete source-mode loading chain)
Symptom: After deploying TB11-01x32 in source-mode (no VLX), typing csv at the command line returned Unknown command "CSV". The ConstructiVision menu appeared in the menu bar (csvmenu.lsp loaded successfully), but no ConstructiVision commands were defined.
Root Cause: The acaddoc.lsp generated by CV Update.bat’s CONFIGURE_STARTUP subroutine only loaded csvmenu.lsp in the source-mode fallback. csvmenu.lsp only loads the pull-down menu — it does NOT define c:csv or any other ConstructiVision commands. Those are defined in csv.lsp, which was never loaded.

In VLX mode, this wasn’t an issue because CSV.VLX bundles everything (menu loader + all commands). In source-mode, csvmenu.lsp and csv.lsp must be loaded separately.
Fix: Added (if (findfile "csv.lsp") (load "csv.lsp")) after the csvmenu.lsp load in the generated acaddoc.lsp.
Commit: b0550d2
Impact: Without this fix, the ConstructiVision menu is visible but every command fails with “Unknown command”. This is a 100% failure rate for source-mode installations.
Lesson Learned: Source-mode loading requires explicit loading of BOTH csvmenu.lsp (menu structure) AND csv.lsp (command definitions). VLX bundles mask this dependency.

Bug 29: `#| |#` Block Comments in `csvmenu.lsp` Crash Source-Mode Loading¶

Affects: TB11 source-mode VM: 104 (XP-TEST)

Discovered: Session 10 (Feb 28, 2026) — OCR analysis showed error: no function definition: COMMERCIAL at startup
Severity: Critical
Status: ✅ Fixed
DFMEA: 4 (Same class as Bug 4 — #| |# block comment limitation)
Symptom: AutoCAD command line showed error: no function definition: COMMERCIAL immediately at startup. All subsequent ConstructiVision commands failed with Unknown command "CSV" / no function definition: C:CSV. The word “COMMERCIAL” appeared in the copyright header text inside a #| |# block comment.
Root Cause: csvmenu.lsp contained two #| |# block comment regions:
1. Copyright header (lines 1–54): Legal text including “COMMERCIAL Computer Software”
2. Technical header (lines 56–118): Architecture documentation
AutoCAD 2000’s (load) function does not support #| |# block comment syntax. Only the Visual LISP IDE and compiled .vlx bundles parse them correctly. When csvmenu.lsp was loaded via (load "csvmenu.lsp") in acaddoc.lsp, the LISP parser treated the copyright text as executable code. It encountered COMMERCIAL as a function call → error: no function definition: COMMERCIAL.

This crashed csvmenu.lsp loading entirely. Since csvmenu.lsp never loaded, the (csvmenu) auto-execute never ran (no menu), and the subsequent csv.lsp load (Bug 28 fix) also worked but c:csv was never properly initialized because the loading chain was broken.

Why only TB source-mode: In PB builds, CSV.VLX is loaded instead. VLX compilation uses the Visual LISP compiler which handles #| |# correctly. The block comments in csvmenu.lsp were invisible in VLX mode — they only manifest when loading raw .lsp source.

Why missed in Bug 4: Bug 4 (Session 1) cleaned #| |# from “multiple .lsp files” but occurred on VM 108 (Win10) with a different set of files. The block comments in csvmenu.lsp may have been added after Session 1 (during documentation headers), or csvmenu.lsp was not included in the Session 1 cleanup scope.
Fix: Converted both #| |# block comment regions to ;;; line comments, following the project coding standard (which already bans #| |#).
Commit: 63ff0f3
Files Changed: src/x32/TB11-01x32/csvmenu.lsp, src/x64/TB11-01x64/csvmenu.lsp
Impact: Without this fix, source-mode loading is 100% broken. No menu, no commands, no functionality.
Lesson Learned: The #| |# ban in coding standards exists for exactly this reason. Every .lsp file in the repository should be audited for #| |# usage, especially after adding documentation headers.

Bug 30: `(alert)` Dialog in `csvmenu.lsp` Blocks AutoIT Validation — Drawing Open Fails¶

Affects: TB11 source-mode + AutoIT validation VM: 104 (XP-TEST)

Discovered: Session 10 (Feb 28, 2026) — After Bug 29 fix, manual validation showed “Cannot find the specified drawing file” for CSB001.dwg
Severity: High
Status: 🔍 Investigating
DFMEA: 30 (NEW — Modal dialog blocks automation timing)
Symptom: After Bugs 28 and 29 were fixed, manual AutoIT validation on VM 104 showed CSB001.dwg failing to open with “Cannot find the specified drawing file” error at Phase 00. All other phases (CSV command, dialogs, menus) worked correctly — ConstructiVision loaded successfully in source-mode.
Suspected Root Cause: When csvmenu.lsp loads successfully (post Bug 29 fix), the (csvmenu) auto-execute at the end runs immediately. This function calls (alert msg) which displays a modal dialog:

“The ConstructiVision menu has been installed.”

This alert blocks acaddoc.lsp from completing. The AutoIT script’s _HandleStartupDialog() only looks for windows titled “Startup” or “Create New Drawing” — it does NOT recognize the (alert) dialog (which has an “AutoCAD” or “AutoCAD Message” title).

Timing chain:
1. AutoCAD starts → Drawing1 opens → acaddoc.lsp runs
2. (load "csvmenu.lsp") → (csvmenu) auto-executes → (alert msg) BLOCKS
3. AutoIT: _HandleStartupDialog() looks for “Startup” — not found (7-second timeout)
4. AutoIT: Phase 1 sends (setvar "filedia" 0) → _SendToCommandLine sends Escape
5. Escape MAY dismiss the alert, but then csv.lsp starts loading (LISP evaluator busy)
6. Phase 1 sends open + {ENTER} + path — but command line may be in wrong state
7. Result: “Cannot find the specified drawing file” or garbled command
Additional factor: LISPINIT=1 (LISP reinitializes per document) means acaddoc.lsp runs AGAIN for every new document, showing the alert dialog a second time. This explains the “CSV loaded twice” observation.

Why VLX mode worked: In VLX mode, CSV.VLX is loaded by acaddoc.lsp but the VLX’s initialization may not trigger (csvmenu) auto-execute (VLX compilation behavior differs from raw source loading). Even if it does, the VLX loading is faster, changing the timing enough for AutoIT to succeed.
Proposed Fix (two-part):
1. Suppress alert in auto-load mode: Add csv_silent_load guard variable. Set it in acaddoc.lsp before loading csvmenu.lsp. In csvmenu.lsp, check the variable: use (princ) instead of (alert) when set.
2. Set LISPINIT=0 in acaddoc.lsp: Prevents LISP reinitialization per document. Variables persist, (boundp 'c:csv) guard works, no double-load.
Impact: Blocks Phase 00 (drawing open) in automated validation. All subsequent phases work because they don’t depend on the drawing open succeeding at Phase 00 timing.

Bug 31: New User Profile Missing AutoCAD Configuration — CV Update is Per-User (HKCU)¶

Affects: All builds (PB11, TB11) on Win10 VMs with multiple users VM: 201 (Alpha1 — Terry)

Discovered: Session 11 (Mar 2, 2026) — Terry logged into Alpha1 VM 201 for the first time. AutoCAD loaded but ConstructiVision did not: no menu, no CSV command, project files not found.
Severity: Critical
Status: ⏸️ Stale (not AC2027 — XP per-user HKCU install model)
DFMEA: 31 (NEW — Per-user registry configuration not propagated to new profiles)
Symptom: When a new Windows user (Terry) logs in and opens AutoCAD, ConstructiVision is completely unconfigured:
1. Startup Suite empty — no CSV.VLX or csv.lsp in AutoCAD’s Startup Suite
2. Search path missing — C:\Program Files\ConstructiVision not in AutoCAD’s support file search path
3. Project paths missing — Project Settings\CV\RefSearchPath not set, so project drawings and XRefs cannot be found
Root Cause: CV Update.bat’s CONFIGURE_STARTUP, CONFIGURE_SEARCH_PATH, and CONFIGURE_PROJECT subroutines all write to HKCU (current user) registry keys:
```
HKCU\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\<<Unnamed Profile>>\...
```
When Administrator runs CV Update, only Administrator’s HKCU is configured. When Terry logs in, his HKCU has no ConstructiVision entries because:
- AutoCAD creates a default <<Unnamed Profile>> on first run per-user
- The default profile has no knowledge of ConstructiVision
- CV Update was never run under Terry’s account
- There is no mechanism to configure all user profiles at install time
Workaround (applied manually): Chad manually configured Terry’s AutoCAD registry entries for Startup Suite, search path, and project paths.
Proposed Fix Options:
1. CV Update enumerates user profiles: Iterate HKEY_USERS SIDs and configure all loaded profiles, plus use HKLM\..\Profiles as a template for new users
2. CV Update runs under each user: Schedule CV Update to run on login for all users (via Public Desktop shortcut — already done) and auto-detect unconfigured profiles
3. First-run detection in csvmenu.lsp: Add a check in csvmenu.lsp or acaddoc.lsp that detects missing configuration and self-configures on first AutoCAD launch per user
4. Default profile template: Configure HKLM\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\<<Unnamed Profile>> at the machine level so all new users inherit the correct settings
Impact: Every new Windows user on a Win10 VM must manually run CV Update or have an administrator configure their AutoCAD profile. This is a deployment blocker for multi-user environments (alpha testers, GSCI engineers).

3-VM Comparison Results (Feb 28, 2026)¶

Full 3-VM OCR comparison after all fixes applied:

#	Screenshot	VM 104 (TB11 fresh)	VM 102 (PB11 reference)	VM 103 (v7.0 MASTER)
00	Baseline drawing	✅ CSB001.dwg loaded, “ConstructiVision loaded VLX”	✅ CSB001.dwg loaded, menus loaded	✅ CSB001 loaded
01	CSV entry dialog	✅ CV Program Options	✅ CV Program Options	✅ CV Program Options
02	Drawing setup	✅ CV Program Options	✅ CV Program Options	✅ CV Program Options
03	Slope calculator	✅ Slope Elevation Calculator	✅ Slope Elevation Calculator	✅ Slope Elevation Calculator
04	Create new project	✅ Project Details dialog	✅ Project Details dialog	✅ Project Details dialog
05	Create new drawing	✅ File browser (Sample Building)	✅ File browser (Sample Building)	✅ File browser (Sample Building)
06	Edit existing drawing	✅ File browser (Sample Building)	✅ File browser (Sample Building)	❌ Bug 19 error (`setvars Function cancelled`)
07	Batch utilities	✅ Batch UI, 24 panels (2026 dates)	✅ Batch UI, 24 panels (2007 dates)	✅ Batch UI, 24 panels (2007 dates)
10	MD panel options	✅ CV Program Options	✅ CV Program Options	✅ CV Program Options
20	Site drawing	✅ XRefs CSB053-059 resolved	✅ XRefs CSB050-059 resolved	✅ CSBsite1 loaded
21	Site dialog	✅ CV Program Options	✅ CV Program Options	✅ CV Program Options

Summary: VM 104 (TB11 fresh deploy with all fixes) matches VM 102 (PB11 reference) across all 11 test phases. Only VM 103 (v7.0 MASTER, read-only) shows an issue at phase 06 — Bug 19’s setvars error, which may need re-validation after the Feb 27 fix was applied.

Notable differences:

VM 104 shows “ConstructiVision loaded VLX” (deferred acaddoc.lsp loader message) vs VM 102 (Startup Suite, no message)
Batch panel timestamps: VM 104 = 2026 (fresh project), VM 102/103 = 2007 (original sample)
VM 103 screenshot 06 still shows Bug 19 error — needs re-run to confirm if the fix persisted

Bug 31: Multi-User Junction Conflict — CV Update Crashes Other User’s AutoCAD¶

Discovered: March 3, 2026
Severity: High
VM: 201 (Alpha tester — Tai)
Status: 📝 Logged (deferred — special case, may not be worth fixing now)
Symptom: Administrator ran CV Update.bat on VM 201 and switched the junction from PB11 to TB11. Terry was logged in simultaneously and running AutoCAD with PB11 (CSV.VLX). Terry got a fatal error in AutoCAD.
Root Cause (suspected): Two-pronged conflict:
1. Filesystem: CV Update.bat removes and recreates the C:\Program Files\ConstructiVision junction. While Terry’s AutoCAD has CSV.VLX loaded from /ConstructiVision/, the junction target changes from PB11 to TB11 mid-session. Any file access through the junction (DLL loads, XRef resolution, file dialogs, .fas/.vlx demand-loading) now resolves to TB11’s files instead of PB11’s — causing undefined behavior.
2. Registry: CV Update.bat calls :CONFIGURE_STARTUP which writes to HKCU. On a multi-user VM, this only changes Administrator’s registry. Terry’s HKCU still points to CSV.VLX in the Startup Suite — but the VLX file path now resolves through the TB11 junction. On next AutoCAD restart, Terry would load TB11’s files with PB11’s registry settings.
Impact: Fatal AutoCAD crash for concurrent user. Data loss possible if unsaved drawings were open.
Mitigation (future):
- CV Update.bat should check for running acad.exe processes and warn/abort if other users have AutoCAD open
- Consider writing registry values for ALL user profiles (HKU enumeration, as implemented in cv-p0-step1.au3)
- Add query session / query user check to detect concurrent logged-in users
- Long-term: per-user build selection rather than shared junction
Fix: Deferred. This is a multi-user edge case specific to alpha testing VMs. Production deployments will have a single user per workstation.

DFMEA Reference (Bug 31)¶

DFMEA ID: NEW (to be added to doc 31)
Failure Mode: Multi-user junction switch during active AutoCAD session
Severity: 8 (fatal crash, potential data loss)
Occurrence: 3 (rare — requires simultaneous login + build switch)
Detection: 2 (immediately obvious — crash dialog)
RPN: 48

Bug 32: Registry-Based Layout Standardization Unreliable Across VMs¶

Discovered: March 3, 2026
Severity: Medium
VM: 103, 104
Status: ✅ Fixed
Symptom: P0 Step 1 used direct registry writes (_WriteGoldenLayout via HKU enumeration) to set DockWindow.Position and other AutoCAD layout values. VM 102 accepted the values and displayed 6 command-line rows. VM 103’s active profile disappeared from the registry after AutoCAD exit (profile name resolved but key was empty on next read). VM 104’s DockWindow.Position was overwritten back to 3-row default upon AutoCAD startup — the registry values did not persist.
Root Cause: AutoCAD 2000’s registry behavior is inconsistent across VMs and profile states:
1. VM 103: The active profile’s registry key under HKCU\Software\Autodesk\AutoCAD\R15.0\ACAD-1:409\Profiles\ appeared to be ephemeral — possibly maintained in-memory by AutoCAD and flushed on exit with different values than what was written externally.
2. VM 104: AutoCAD overwrites DockWindow.Position from its internal state on startup, ignoring pre-written registry values. The 3-row default is baked into AutoCAD’s initialization sequence for that profile.
3. VM 102 worked because it already had the correct values from a previous manual configuration — the registry write was a no-op.
Fix: Abandoned registry-based approach entirely. Replaced with runtime (setenv) LISP commands sent via AutoIT’s Send() function after AutoCAD is fully running. The setenv function writes to the active profile’s registry through AutoCAD’s own API, which correctly persists values across sessions. Expanded scope from just CmdVisLines to 8 classic settings:
- CmdVisLines=6, CmdHistLines=2000, AcadClassic=1, CursorSize=100
- Background=0, ToolTips=1, Scrollbars=1, MaxArray=999999
Impact: All 3 VMs now accept layout settings reliably. The setenv approach works because AutoCAD itself manages the registry write — no external tooling races with AutoCAD’s profile manager.
Prevention: Use (setenv) or (setvar) for any AutoCAD configuration changes. Never write directly to AutoCAD’s profile registry keys from external tools — AutoCAD owns those keys and may overwrite them.
DFMEA: 32 (NEW — External registry writes to AutoCAD profile keys are unreliable)

DFMEA Reference (Bug 32)¶

DFMEA ID: NEW (to be added to doc 31)
Failure Mode: External registry writes to AutoCAD profile keys overwritten or lost
Severity: 4 (incorrect layout, not a crash — cosmetic/workflow impact)
Occurrence: 7 (happened on 2 of 3 VMs — high occurrence in practice)
Detection: 5 (requires visual inspection or screenshot comparison; log doesn’t catch it)
RPN: 140

Bug 39: Version Subtitle Not Rendering in TB progopts Dialog¶

Discovered: March 6, 2026
Severity: Medium
VM: 104, 108, 109 (all TB builds)
Status: 🔲 Open
Symptom: The ConstructiVision - Program Options dialog in TB source mode is missing the version subtitle line. Golden VM 102 (V11 Golden/VLX) shows ConstructiVision Tilt-Up and PreCast Software Version 11.00 2/4/2013 between the dialog title and the first row of buttons. All three TB VMs show nothing in that space — OCR confirmed zero matching words (no “Version”, “Tilt-Up”, “PreCast”, or “11.00” detected in any TB screenshot).
Root Cause (suspected): The deployed progopts.dcl file on VM 104 matches the repo exactly (2925 bytes, dated 03/02/2026). The DCL source includes a :row with two :text elements for the subtitle. The text is defined in the DCL but does not render visibly. Possible causes:
1. The :text elements inside the :row may be rendering at zero height or clipped by AutoCAD 2000’s DCL layout engine
2. DCL spacer_1 before/after the subtitle row may collapse the row on AutoCAD 2000
3. The subtitle :row may need explicit height or fixed_height attributes to ensure rendering
4. Difference between how AutoCAD 2000 renders the VLX’s embedded DCL vs runtime-loaded .dcl files
Evidence:
- VM 102 (V11 Golden) OCR: Constructi¥ision Til-Up and PreCast Software Version 11.00 2/4/2013 at pixel row ~734
- VM 104 (TB) OCR detail: No trace of version text — only noise characters between title bar and first button
- VM 108 (TB) OCR: Same absence — blank area between title and Create New Drawing
- VM 109 (TB) OCR: Same absence
Fix (proposed): Test DCL variants — add explicit height = 1; to the :text elements, try fixed_height = true; on the :row, or convert from two :text elements in a :row to a single :text spanning the full width. Also verify: does this work on any standalone .dcl test dialog? May be an AutoCAD 2000 DCL rendering quirk.
Impact: Cosmetic — no functionality loss. Version identification is missing from the dialog header.
DFMEA: See DFMEA Reference below.

DFMEA Reference (Bug 39)¶

DFMEA ID: NEW (to be added to doc 31)
Failure Mode: DCL :text / :row elements render at zero height in runtime-loaded dialogs
Severity: 2 (cosmetic — missing version text, no functional impact)
Occurrence: 10 (reproducible on every TB build, every VM — 3/3 TB VMs affected)
Detection: 5 (requires visual inspection or OCR comparison; not detected by au3 validation)
RPN: 100

Bug 40: Print Revision History / Print Materials List Enabled Without Project¶

Discovered: March 6, 2026
Severity: Medium
VM: 104, 108, 109 (all TB builds)
Status: ✅ Fixed (March 5, 2026)
Symptom: The progopts dialog in TB source-mode shows all 14 buttons enabled, including Print Revision History and Print Materials List, even when no project/drawing is loaded. The V11 Golden dialog on VM 102 shows a reduced set of ~8 buttons appropriate for the no-project context — the view/print buttons are not visible at all.
Root Cause: Two issues:
1. Button graying logic too narrow: progopts.lsp only disabled matlist and revhist when (not olddwg). Five more project-dependent buttons (viewall, printlay, viewsel, printsel, 3dview) were left enabled — the V11 Golden VLX hides all 7.
2. Default drawing detection too narrow: csv.lsp checked (= (getvar "dwgname") "Drawing.dwg") exactly, which misses Drawing1.dwg (Win10 AutoCAD 2000 default). When the check fails, olddwg gets set to "Drawing1.dwg" instead of nil, and no buttons get grayed.
3. Remaining gap vs V11 Golden: The V11 VLX dialog hides the 7 project-dependent buttons entirely (not shown at all). The TB progopts.dcl grays them instead. This is intentional — full parity would require multiple DCL dialog definitions selected by context, deferred to a future enhancement.
Evidence:
- VM 102 (V11 Golden) p0-04 OCR: Shows only Create New Drawing, Edit Existing Drawing, Create New Project, Batch Utilities, Change Project Search Path, Cancel, Help (no Print/View buttons)
- VM 104/108/109 (TB) p0-04 OCR: Shows all 14 buttons including Print Revision History, Print Materials List, View All Layers, Print All Layers, View Selected Layers, Print Selected Layers, Change 3D Viewpoint
Fix (applied):
1. progopts.lsp: Expanded mode_tile disable list from 2 to 7 buttons — viewall, printlay, viewsel, printsel, 3dview, matlist, revhist are all grayed when (not olddwg).
2. csv.lsp: Changed default drawing detection from exact string match "Drawing.dwg" to wildcard (wcmatch (strcase (getvar "dwgname")) "DRAWING*.DWG") to catch both Drawing.dwg (XP) and Drawing1.dwg (Win10).
3. Both x32 and x64 builds synced.
Impact: 7 project-dependent buttons now grayed on fresh startup. Buttons are visible but disabled, making it clear they require a project. Partial parity with V11 Golden (grayed vs hidden). No regressions — buttons re-enable normally when a drawing is loaded because olddwg gets set to the drawing filename.
DFMEA: Matches existing DFMEA #11 (Toggle enabled with empty data / feature left enabled without valid context). Detection (D) improved from 5→3 with the fix in place (buttons now visually indicate state).

DFMEA Reference (Bug 40)¶

DFMEA ID: 11 (existing — Toggle enabled with empty data)
Failure Mode: Buttons enabled when prerequisite data (project/drawing) not loaded
Severity: 4 (incorrect UX, non-fatal — buttons either fail gracefully or produce unexpected dialogs)
Occurrence: 10 (reproducible on every TB build fresh launch — 3/3 TB VMs)
Detection: 3 (grayed buttons now visually indicate state; OCR comparison can detect difference)
RPN: 120 (reduced from 200 — fix reduces Detection from 5→3)

Bug 41: CV Update.bat Shows “Active build: unknown” on XP¶

Discovered: March 6, 2026
Severity: Low
VM: 104 (XP)
Status: 🔲 Open
Symptom: When running CV Update.bat on VM 104 (Windows XP), the Version Manager picker displays Active build: unknown even though the junction C:\Program Files\ConstructiVision correctly points to TB11-01x32.
Root Cause: The junction target detection at line 75 uses:
```
for /f "tokens=2 delims=[]" %%j in ('dir "!JUNCTION!\.." 2^>nul ^| findstr /i "ConstructiVision"') do (
    set "JLINK=%%j"
)
```
This parses dir output to extract the junction target from bracket notation. On Windows 10, dir shows junctions as:
```
03/02/2026  12:00 PM  <JUNCTION>  ConstructiVision [C:\Repos\...\TB11-01x32]
```
On Windows XP, dir shows junctions created by Sysinternals junction.exe the same as regular directories — no <JUNCTION> tag, no bracket notation:
```
03/02/2026  12:00 PM  <DIR>  ConstructiVision
```
Since tokens=2 delims=[] finds no brackets, JLINK is never set and CURRENT remains “unknown”. The script still functions correctly (junction switching works), but the status display is wrong.

Fix (proposed): Add XP fallback detection path using junction.exe or fsutil reparsepoint query:

if "!CURRENT!"=="unknown" (
    for /f "tokens=*" %%t in ('junction "!JUNCTION!" 2^>nul ^| findstr /i "target"') do (
        echo %%t | findstr /i "TB11" >nul && set "CURRENT=%TB%"
        echo %%t | findstr /i "PB11" >nul && set "CURRENT=%PB%"
    )
)

Impact: Cosmetic only — the Version Manager shows “unknown” but still functions correctly. Users can still switch builds and pull updates. Only affects display on XP VMs where junctions were created by junction.exe.
DFMEA: See DFMEA Reference below.

DFMEA Reference (Bug 41)¶

DFMEA ID: NEW (to be added to doc 31)
Failure Mode: Junction detection via dir bracket parsing fails on XP
Severity: 1 (cosmetic — status display wrong, functionality unaffected)
Occurrence: 10 (reproducible on every XP VM)
Detection: 2 (immediately visible to user — they see “unknown”)
RPN: 20

Bug 42: Bug 40 Regression — project() Cancel Falls Through to progopts¶

Discovered: March 5, 2026
Severity: High
VM: 108 (Win10 x32) — affects all TB builds on Win10
Status: ✅ Fixed (March 5, 2026)
Regression of: Bug 40 (d43af50)
Symptom: After the Bug 40 fix, running c:csv on VM 108 (Win10, default Drawing1.dwg) shows TWO modal dialogs in sequence: first project() (“ConstructiVision – Project Options”), then progopts (“ConstructiVision - Program Options”). The au3 test fixture sends a single Escape which dismisses project(), but progopts then appears with no one to dismiss it. The dialog stays on screen, blocking all subsequent validation steps (config dumps, environment variable retrieval).
Root Cause: Bug 40’s wcmatch fix in csv.lsp changed default drawing detection from exact "Drawing.dwg" match to (wcmatch ... "DRAWING*.DWG"), which correctly identifies Drawing1.dwg (Win10 default) and sets olddwg=nil. This is correct behavior — the bug is that csv.lsp had no guard for the case where project() is called and the user cancels. When project.dcl’s Cancel button sets pnl="cancel", csv.lsp proceeded to show progopts as a second dialog. Before Bug 40, Drawing1.dwg on Win10 didn’t match the exact string check, so olddwg was non-nil, project() was never called, and the two-dialog chain couldn’t occur.
Evidence:
- VM 108 p0-step2-20260305-134631 screenshots: p0-04 shows “Project Options”, p0-04b through p0-07 show progopts stuck on screen with grayed buttons
- VM 108 p0-step2-20260305-121235 (pre-fix): p0-04 shows only progopts, p0-04b shows text window (dialog dismissed normally)
Fix (applied):
- csv.lsp: Added cancel guard after (project) call — wraps the entire routing block in (if (/= pnl "cancel") ...). When project.dcl sets pnl="cancel", the routing block (including progopts) is skipped entirely, and pnl/ld are cleaned up in the else branch.
- Used (/= pnl "cancel") instead of (not (= pnl nil)) because pnl is nil when project() was never called (real drawing open), and progopts must still appear in that case.
- Both x32 and x64 builds synced.
Impact: Fixes the two-dialog regression on Win10 default drawings. When project() is cancelled (Escape or Cancel button), csv exits cleanly without showing progopts. Normal flows (user picks New/Existing in project dialog, or real drawing open bypassing project entirely) are unaffected.
DFMEA: New failure mode — regression from incomplete guard logic in a fix.

DFMEA Reference (Bug 42)¶

DFMEA ID: NEW (to be added to doc 31)
Failure Mode: Fix introduces new dialog flow path without guard for cancel case
Severity: 6 (blocks validation — modal dialog traps UI, all subsequent tests fail)
Occurrence: 10 (reproducible on every Win10 TB build with default drawing)
Detection: 3 (OCR comparison catches stuck dialog immediately; validation log falsely reports PASS per Bug 25)
RPN: 180

Bug 43: FATAL ERROR — FILES MISSING for Non-Admin User on VM 201¶

Discovered: March 9, 2026
Severity: High
VM: 201 (Win10 x64, Alpha tester)
Status: ✅ Fixed (March 9, 2026)
Symptom: User Terry (non-admin, Remote Desktop Users group only) runs csv in AutoCAD → VLX registration/licensing code triggers FATAL ERROR -- FILES MISSING alert. Same command works fine for Administrator.
Root Cause: The compiled VLX’s registration flow (CheckPanelCredit via pcms.arx → cv.bat → wincss.exe → FATAL ERROR) requires admin-level privileges to access some resource. The exact resource was never identified — the VLX’s registration code is compiled and opaque, and the source-mode equivalent is commented out.
Investigation (exhaustive):
1. cv.bat format corrected (added rem 20260309 as first line) — no fix
2. HKLM registration data (status, lr, lic, gp, Registration blob, cssPC, cssRC) copied from VM 102 golden — no fix (hardware-locked)
3. Registry ACLs: granted BUILTIN\Users FullControl on both HKLM\SOFTWARE\ConstructiVision, Inc and HKLM\SOFTWARE\ConstructiVision keys — no fix
4. pcms.arx renamed to bypass CheckPanelCredit — no fix, restored
5. Filesystem ACLs: granted Users:(OI)(CI)M on C:\Program Files\ACAD2000\, C:\Program Files\ConstructiVision junction, and junction target (PB11-00x32) — no fix
6. “Run as Administrator” on AutoCAD while logged in as Terry → works — confirms elevation/permissions issue
Fix: Added Terry to local Administrators group (net localgroup Administrators Terry /add). Terry must log out and back in for token refresh.
Impact: Alpha testers on PB11 VLX builds must be in the Administrators group. This is a known limitation of the compiled VLX’s registration code. The modernized TB11 source-mode build does NOT have this restriction (registration code is commented out). This bug will not exist in the final distributable release.
Side effect: During investigation, Terry temporarily disappeared from Windows login screen. Added Terry to Users group as well. Root cause of login screen issue unclear but moot with admin membership.
Lesson: The compiled VLX has opaque permission requirements that cannot be reverse-engineered from recovered source alone. Process Monitor would be needed to identify the exact resource. For alpha testing, admin accounts are the pragmatic solution.

DFMEA Reference (Bug 43)¶

DFMEA ID: NEW (to be added to doc 31)
Failure Mode: VLX compiled registration code requires undocumented admin privileges
Severity: 7 (user cannot launch application — complete loss of function for that user)
Occurrence: 4 (only affects non-admin users on PB11 VLX builds; TB11 source-mode unaffected)
Detection: 2 (immediately visible — FATAL ERROR alert on every launch attempt)
RPN: 56

Bug 82: `cv-tracer.lsp` Load Fails — “no function definition: FBOUNDP” on AC2000 Source-Mode¶

Affects: Trace infrastructure — cv-tracer.lsp VM: 104 (XP, TB11); latent on all VMs depending on load order

Discovered: March 2026 — G1 run on VM 104
Severity: High
Status: ✅ Fixed (commit ce6fc3e7)
DFMEA: NEW — Tooling/trace infrastructure: Visual LISP extension availability depends on load order
Symptom: cv-tracer.lsp fails to load with ; error: no function definition: FBOUNDP. All trace instrumentation absent — subsequent G0/G1/G2 runs produce no trace output.
Root Cause: fboundp is a Visual LISP function only available after (vl-load-com) has been called. In AC2000 source-mode, whether fboundp is available depends entirely on whether any previously loaded .lsp file called vl-load-com. On VM 108, csv.lsp initialization happens to call vl-load-com incidentally, so fboundp is available when cv-tracer.lsp loads. On VM 104, the initialization path never reaches vl-load-com before cv-tracer.lsp loads — so fboundp is undefined. Non-deterministic: depends on load order, not a reproducible property of the VM.
Fix: Added (vl-load-com) to cv-tracer.lsp before the first (fboundp) call. Also added to the generate-cv-tracer.py template so regeneration preserves the fix.
Files: src/x32/TB11-01x32/cv-tracer.lsp, scripts/generate-cv-tracer.py
Commit: ce6fc3e7
Lesson: Never assume Visual LISP extensions are available in source-mode without explicitly calling (vl-load-com). Any .lsp file using fboundp, vlax-*, or similar must call (vl-load-com) at the top as self-contained bootstrap.

DFMEA Reference (Bug 82)¶

DFMEA ID: NEW — Tooling load-order dependency: Visual LISP extension availability
Failure Mode: Trace infrastructure fails silently when vl-load-com has not been called prior to cv-tracer.lsp load
Severity: 5
Occurrence: 6
Detection: 4
RPN: 120

Bug 83: G1/G2 Drawing Open Fails — `ClipPut+^v` Unreliable in AC2000 Command-Line Mode¶

Affects: Trace infrastructure — cv-trace-g1.au3, cv-trace-g2.au3 VM: All (VM 104 confirmed, VM 108 confirmed from log evidence)

Discovered: March 2026 — G1 run analysis
Severity: High
Status: ✅ Fixed (commit ce6fc3e7)
DFMEA: NEW — Tooling: AutoIT drawing-open method incompatible with AutoCAD 2000 command-line mode
Symptom: G1 sends (setvar "filedia" 0) then OPEN, then ClipPut("CSB001.dwg") + Send("^v") to supply the filename. AutoCAD does not open CSB001.dwg — clipboard paste is ignored or bare filename fails path resolution.
Root Cause: Two compounding issues: (1) Clipboard paste is unreliable in AC2000 command-line mode with filedia=0. The golden reference (reports/vm102-cv-menu-validation.au3) uses Send(fullpath, 1) (slow typing) instead. (2) Bare filename without full path fails because AutoCAD can’t find it via Search Path.
Fix: Changed $CSB001_DWG (G1) and $CSBSITE1_DWG (G2) to full junction-based paths. Replaced ClipPut()+Send("^v") with Send(fullpath & ".dwg", 1) (slow typing). Matches the golden reference exactly.
Files: scripts/acad2000/cv-trace-g1.au3, scripts/acad2000/cv-trace-g2.au3
Commit: ce6fc3e7
Lesson: Always type the full path character-by-character with Send(path, 1) for AutoCAD 2000 file opens. The golden reference (reports/vm102-cv-menu-validation.au3) is the authoritative pattern.

DFMEA Reference (Bug 83)¶

DFMEA ID: NEW — Tooling: AutoIT drawing-open method incompatible with AC2000 command-line mode
Failure Mode: ClipPut+^v fails to supply filename; drawing never opens; trace data collected from wrong drawing
Severity: 8
Occurrence: 9
Detection: 3
RPN: 216

Bug 84: AutoCAD Crashes When G1/G2 Continues Executing After Drawing Open Failure¶

Affects: Trace infrastructure — cv-trace-g1.au3, cv-trace-g2.au3 VM: VM 108 (Win10 x32, confirmed from acad.err + acadstk.dmp); latent all VMs

Discovered: March 2026 — G1 crash evidence (acad.err + acadstk.dmp)
Severity: Critical
Status: ✅ Fixed (commit 0dd6d166)
DFMEA: NEW — Tooling: script continues executing after target drawing fails to open, injecting commands into broken AutoCAD state
Symptom: After CSB001.dwg fails to open (Bug 83), G1 logged "Continuing anyway: trace will run on whatever drawing is open." and proceeded to send _SendProgcont() calls. The LISP strings injected at the wrong moment were fragmented and garbled: Drawing1 log shows "OGN(SETQ", "PRLIONCG0F0I", "262401)(9C;SECTSVVA)R9" — fragments of LISP code interpreted as AutoCAD commands. AutoCAD crashed, producing acad.err and acadstk.dmp. The crash dump was destroyed by the next pre-check before it could be collected.
Root Cause: _Fail() logs the failure but does NOT stop execution. The code path after _Fail("CSB001 title not found") continued with _Log(" Continuing anyway...") and proceeded to run all 9+ _SendProgcont() calls into an unknown AutoCAD command state.
Fix: (1) Replaced _Log("Continuing anyway...") with _Finish() in both G1 and G2. (2) Added crash dump preservation to pre-check — FileCopy dump to output dir with timestamp before FileDelete.
Files: scripts/acad2000/cv-trace-g1.au3, scripts/acad2000/cv-trace-g2.au3
Commit: 0dd6d166
Evidence: reports/vm108-step7-run3/Drawing1_1_1_5064.log — garbled commands, Unknown command "OGN(SETQ"
Lesson: Every _Fail() call at a critical gate (drawing open, title verification) MUST be followed immediately by _Finish(). The “Continuing anyway” pattern is never acceptable when the script sends keyboard input to a potentially broken application state.

DFMEA Reference (Bug 84)¶

DFMEA ID: NEW — Tooling: automation continues past failed precondition, injecting keystrokes into broken application state
Failure Mode: Script sends LISP commands to AutoCAD after drawing open fails; keystroke fragmentation crashes AutoCAD
Severity: 9
Occurrence: 10
Detection: 2
RPN: 180

Bug 85: G1/G2 `_SendProgcont` — `Send(..., 1)` Emits `{ENTER}` as Literal Text¶

Affects: Trace infrastructure — cv-trace-g1.au3, cv-trace-g2.au3 VM: VM 108 (Win10 x32)

Discovered: March 20, 2026 — G1 run (rev1/rev2/rev3 all failed due to stale script on VM; root cause identified after SCP realization)
Severity: High
Status: ✅ Fixed (commit f6b7e69, rev4)
DFMEA: NEW — Tooling: AutoIt raw/slow-mode Send() emits special-key sequences as literal characters
Symptom: All _SendProgcont calls showed the LISP command typed into the AutoCAD command line but {ENTER} appearing as the literal characters {ENTER} at the end, never submitting. AutoCAD received the whole LISP expression as text but never executed it.
Root Cause: AutoIt’s Send(text, 1) flag enables raw/slow mode — characters are sent one at a time, INCLUDING special sequences like {ENTER}, {TAB}, etc. In slow mode {ENTER} is not interpreted as the Enter key; it is sent as the six characters {, E, N, T, E, R, }. All three revisions (rev1, rev2, rev3) that attempted to fix an earlier hypothesis (LISP character reversal caused by AutoCAD Text Window BiDi input) were deployed to the repo but never reached VM108 because the VM runs scripts from C:\CV-Validation\scripts\ — an isolated copy not synced from git. All prior debugging sessions tested against the original buggy code.
Fix (rev4): Split every slow-mode send into two calls: Send(text, 1) for the LISP content, then a separate Send("{ENTER}") (no flag) for the keystroke. Applied to (setvar "filedia" 1) restore and _SendProgcont LISP expression in both G1 and G2.
Files: scripts/acad2000/cv-trace-g1.au3, scripts/acad2000/cv-trace-g2.au3
Commit: f6b7e69
Lesson: In AutoIt, Send(text, flag=1) sends ALL characters literally including {ENTER}, {TAB}, etc. Always split: Send(content, 1) then Send("{ENTER}"). Additionally, VM scripts are isolated copies at C:\CV-Validation\scripts\ — they must be updated via SCP, not git.

DFMEA Reference (Bug 85)¶

DFMEA ID: NEW — Tooling: AutoIt raw-mode Send emits control sequences as literal characters; ENTER key never fires
Failure Mode: LISP expressions typed into AutoCAD command line but never submitted; no CV functions invoked; trace data empty
Severity: 8
Occurrence: 9
Detection: 3
RPN: 216

Bug 86: `PANATT` Crashes — `bad argument type: stringp nil` on Fresh Panel Drawing Open (pc=1)¶

Affects: panatt.lsp VM: 108 (Win10 x32) — confirmed from CSB001_1_1_3767.log G1 trace run

Discovered: March 20, 2026 — G1 first successful trace run (cv-trace-g1-20260320-211127)
Severity: High
Status: ✅ Fixed — March 21, 2026 (commit 4630e005)
DFMEA: Matches existing class — progcont target called without prerequisite global state initialized

Fix History:

Ver	Date	Commit	Change	Outcome
v1	Mar 20	prior	`cdddr/cddddr` → `vl-remove-if-not` filter	Crash shifted
v2	Mar 21	prior	Nil guard expanded from 3→7 vars before convert	Crash persisted
v3	Mar 21	`1a87b4c4`	`curdir` nil → fallback to `dwgprefix`	Crash persisted
v4	Mar 21	`f7b59d9a`	Full DV1543 `error` handler; Guards 1–4	Graceful message; crash persisted
v5	Mar 21	`4630e005`	Root cause fix — key priority swap	Expected PASS

Root Cause (confirmed Mar 21 via P0–PB diagnostic trace, commit cb56dab9):

Diagnostic trace markers P0–PB were added spanning every execution stage. The Mar 21 14:58 run (CSB001_1_1_6289.log) produced:

; [P0] panatt entry
; [P1] cmds ok
; [P2] nod=set                      ← XRecord found
; [P3] post-mapcar a=set e=nil
; [P4] pv-sections=2                 ← ONLY 2 sections — should be 21
; [P5] pv-guard passed
; panatt error: bad argument type: stringp nil  ← crash in foreach

[P4] pv-sections=2 is the smoking gun. TB11 panatt was checking the "panel" Named Object Dictionary key first — before "panel_list". CSB001.dwg contains both keys:

"panel" — VLX-internal key, different DXF structure, only ~2 parseable sections via vl-remove-if-not '(lambda (x) (member (car x) '(1 2 3)))
"panel_list" — source-mode key, 1/2/3 DXF triplets, full 21 sections

With only 2 malformed sections loaded, the subsequent foreach variable expansion hit (read nil) → bad argument type: stringp nil when a section entry’s (car b) was nil. PB11 panatt only ever reads "panel_list"; it never checks "panel". This is exactly why PB11 passes on the same drawing.

Fix (v5):

Key priority swap: "panel_list" checked first; "panel" only as fallback for drawings with no panel_list. Matches PB11 behavior exactly.
panatt_nod_key variable: stores the resolved key so [P2] diagnostic reports which key was actually used (e.g. [P2] key=panel_list raw=247).
Nil-key guard in foreach: (if (stringp (car b)) ...) prevents (read nil) even if a future XRecord has a malformed entry; logs [P5-SKIP] for any skipped entry.

Impact: G1 re-run expected to show [P2] key=panel_list and pv-sections=21, with pc=1 reaching progopts/md_dlg dialog without crashing.

DFMEA Reference (Bug 86)¶

DFMEA ID: Matches existing failure mode class — progcont target function called without prerequisite global state
Failure Mode: PANATT called via progcont routing before panelvar is initialized; crashes on first string operation
Severity: 6 (function crashes, no drawing damage; error dialog shown)
Occurrence: 7 (reproducible whenever pc=1 fires without prior drawpan in session)
Detection: 3 (ACAD log shows crash; no dialog appears in G1 run)
RPN: 126

Bug 87: `MATL_DLG` — architecture requires site drawing; G1 test was using wrong drawing type¶

Affects: matl_dlg.lsp, scripts/acad2000/cv-trace-g1.au3 VM: 108 (Win10 x32) — confirmed from CSB001_1_1_3767.log G1 trace run

Discovered: March 20, 2026 — G1 first successful trace run (cv-trace-g1-20260320-211127)
Severity: High
Status: ✅ Fixed — March 21, 2026 (G1 script corrected to use CSBsite1.dwg; matl_dlg.lsp (exit) artifact also fixed separately, commit 3e2a7c32)
DFMEA: Matches existing class — matl_dlg called without required drawing structure in place
Symptom: (progn(setq progcont 263169)(c:csv)(princ)) on CSB001.dwg routes to (MATL_DLG) which shows alert “No panel blocks found in drawing.” and exits. Originally this also showed ; error: quit / exit abort (fixed in 3e2a7c32).
Root Cause (architectural): matl_dlg.lsp uses (ssget "x" '((-4 . "<and") (0 . "INSERT") (8 . "0") (-4 . "and>"))) to find panel block INSERT entities on layer "0". These INSERT entities are XREF block references placed by inspanel.lsp when panels are attached to a site drawing (e.g. CSBsite1.dwg): ```lisp ;; inspanel.lsp lines 346-400 (command “layer” … “s” “0” …) ;; current layer = 0 (command “-xref” “a” pnl-dwg-path …) ;; XREF landed on layer 0
```
Individual panel drawings (CSB001-CSB059) are the *source* files that get XREFed into the site drawing. They do NOT contain panel INSERT entities on layer `"0"` — they ARE the panel. The G1 trace script was calling pc=263169 with CSB001.dwg open, which always yields "No panel blocks found" because CSB001 is a panel detail drawing, not a site drawing.
```
Fix: scripts/acad2000/cv-trace-g1.au3 updated to open CSBsite1.dwg before calling pc=263169, then re-open CSB001.dwg for the Revision History (pc=264193) test. matl_dlg.lsp ssget filter is architecturally correct — no code change needed there.
Impact: G1 re-run on CSBsite1 expected to find 59 panel XREF INSERT entities on layer "0" and generate the materials list. Full validation still depends on whether panel XREFs were bound (XBIND) before saving CSBsite1 — accessible block definitions require XBIND in AutoCAD 2000. This is a G2 test concern if XREFs are not pre-bound.
DFMEA: Matches existing class — matl_dlg called cold without panel blocks present in expected layer/state
Symptom: (progn(setq progcont 263169)(c:csv)(princ)) routes to (MATL_DLG) which aborts with ; error: quit / exit abort. The au3 test log captures this as a failure even though the alert message correctly informs the user.
Root Cause (corrected): The original code called (load_dialog) and (new_dialog) before performing the ssget check. When no INSERT entities were found, it called:
```
(alert "No panel blocks found...")
(unload_dialog dcl_id25)
(exit)                       ;← exit inside open dialog context
```
(exit) in AutoLISP always propagates as ; error: quit / exit abort regardless of context. Since the dialog was already open when (exit) was called, this looked like a crash in the trace log even though it was an expected early-exit path. The content guard (“no panel blocks”) itself is correct — CSB001 is a bare panel drawing with geometry only; material component INSERT entities (bolts, reveals, blockouts, braces) on layer "0" are placed separately by bolt.lsp, green.lsp, drawdim.lsp, and brace.lsp after drawpan runs. CSB001 was created without any of these component blocks.

Fix: Restructured matl_dlg.lsp to perform ssget before (load_dialog). The nil-xls path now calls (alert ...) and falls through to (princ) at the function end — no dialog is ever opened, no (exit) is ever called. The non-nil path opens the dialog and processes normally.

;; Bug 87 fix: ssget runs BEFORE (load_dialog) so that when
;; no component INSERT entities exist the function exits via
;; (princ) without ever opening the dialog.
(set 'xls (ssget "x" '((-4 . "<and") (0 . "INSERT") (8 . "0") (-4 . "and>"))))
(if (not xls)
  (progn
    (alert "No panel blocks found in drawing.\nCannot generate Materials List.")
    (princ)
  )
)
(if xls
  (progn
    (set 'dcl_id25 (load_dialog "matl_dlg.dcl"))
    ...
  )
)
(princ)  ;← clean exit either path

Impact: ; error: quit / exit abort trace artifact eliminated for pc=263169. The “no panel blocks” alert still appears for bare panel drawings (correct behavior). Full Materials List with real component data remains a G2 concern — G2 requires a drawing with bolt/brace/reveal INSERT entities on layer "0".

DFMEA Reference (Bug 87)¶

DFMEA ID: Matches existing Bug 52 class — matl_dlg called cold without panel_list guard (DFMEA #13)
Failure Mode: matl_dlg ssget finds no INSERT entities on layer “0”; aborts with alert; Materials List inaccessible
Severity: 7 (core product feature — Materials List — completely unavailable)
Occurrence: 7 (reproducible when opening panel drawing cold, bypassing normal CV workflow)
Detection: 3 (alert message is visible; ACAD log shows quit / exit abort)
RPN: 147

Bug 88: G2 CSBsite1 False Negative — Window Detection Fires Before 59 XREFs Finish Loading¶

Affects: scripts/acad2000/cv-trace-g2.au3 VM: 108 (Win10 x32)

Discovered: March 21, 2026 — G2 test run
Severity: Medium (test infrastructure — false negative, not a product bug)
Status: ✅ Fixed — March 21, 2026 (commit 4630e005)
DFMEA: Matches Bug 25 class — validation false positive/negative (DFMEA #25)

Symptom: G2’s (progn(setq progcont 1)(...)) and subsequent commands execute while CSBsite1 is still loading XREFs. AutoCAD ignores keystrokes during xref resolution, resulting in progcont calls that never execute or execute against an incomplete drawing state. The test reports as if commands ran when they did not.

Root Cause: CSBsite1.dwg has 59 XREFs (CSB001–CSB059). In G2 (a cold session with no prior drawings), all 59 must be read from disk and resolved. WinWait("[REGEXPTITLE:CSBsite1]", "", 30) returns the moment the window title changes — which happens when AutoCAD starts loading the drawing, not when it finishes. The previous Sleep(1000) wait was sufficient in G1 (same-session hot cache) but completely insufficient in a cold G2 session.

From the G1 15:01:22 CSBsite1 log: 59 XREFs resolved plus “Regenerating model.” before the [CV-TRACER] initialization message appeared — empirically confirming that AutoCAD is busy for 15–20 seconds after the title change.

Fix: cv-trace-g2.au3 — Sleep(1000) after WinWait(CSBsite1) increased to Sleep(20000). Comment added explaining the 59-xref cold-start timing requirement.

Impact: G2 re-run expected to send all progcont commands into a fully-loaded CSBsite1 drawing with all 59 panel XREFs resolved and the drawing command-ready.

Bug 89: `(stringp x)` Not Defined in AutoCAD 2000 AutoLISP via `(load)`¶

Affects: src/x32/TB11-01x32/panatt.lsp VM: 108 (Win10 x32)

Discovered: March 21, 2026 — G1 run cv-trace-g1-20260321-152728
Severity: High (pc=1 panatt crashes on every CSB001 open)
Status: ✅ Fixed — March 21, 2026 (commit cd63f6c8)
DFMEA: Matches DFMEA #13 — AutoLISP version/compatibility failure

Symptom: CSB001_1_1_1192.log shows ; panatt error: no function definition: STRINGP after ; [P5] pv-guard passed. Bug 89 hit even after the v5 key-priority fix (commit 4630e005) because stringp is called in the new nil-key guard code that v5 introduced.

Root Cause: (stringp x) is not available as a built-in function when .lsp files are loaded via (load) in AutoCAD 2000 AutoLISP (non-VLIDE mode). The function IS available in the Visual LISP IDE and compiled .vlx bundles, which is why PB11 never hit this. The idiomatic AutoCAD 2000 predicate is (= (type x) 'STR).

Fix: panatt.lsp v5.1 — replaced both (stringp x) calls in the foreach guard with (= (type x) 'STR):

Line 232: (if (stringp (car b)) ...) → (if (= (type (car b)) 'STR) ...)
Line 236 (in [P5-SKIP]): (if (stringp (car a)) ...) → (if (= (type (car a)) 'STR) ...)

Impact: panatt can now execute the nil-key guard safely. Next run expected: [P2] key=panel_list raw=247+, [P4] pv-sections=21, [P6] foreach done mpe1=set.

Bug 90: `pc=262273` Always Routes to `slyr_dlg` (Site Layer Control) on Panel Drawing¶

Affects: src/x32/TB11-01x32/csv.lsp VM: 108 (Win10 x32)

Discovered: March 21, 2026 — G1 run cv-trace-g1-20260321-152728
Severity: High (wrong dialog shown on panel drawing)
Status: ✅ Fixed — March 21, 2026 (commit cd63f6c8)
DFMEA: Matches DFMEA #18 — progcont routing not conditioned on drawing type

Symptom: G1 log for pc=262273 shows Entering (LYR_DLG "slyr_dlg") on CSB001 (a panel drawing). The Site Layer Control dialog appeared; panel layer control (plyr_dlg) was never reached.

Root Cause: csv.lsp dispatch for *pc-view-select* (262273) hardcoded (lyr_dlg "slyr_dlg") and the site keylst unconditionally. The VLX checked drawing type and routed to plyr_dlg/slyr_dlg accordingly. TB11’s reconstruction only implemented the site path.

Panel keylst documented in lyr_dlg.lsp header: ("cn" "cnd" "po" "pod" "fhv" "fhvd" "gp" "gpd" "cu" "cud" "sod" "ppd" "hd" "pp").

Fix: csv.lsp — added csv_dwgtype check in *pc-view-select* dispatch:

(if (= csv_dwgtype "panel")
  (progn
    (set 'keylst '("cn" "cnd" "po" "pod" "fhv" "fhvd" "gp" "gpd"
                   "cu" "cud" "sod" "ppd" "hd" "pp"))
    (lyr_dlg "plyr_dlg")
  )
  (progn
    (set 'keylst '("s0" "sd" "sp" "sf" "sg" "sh" "sl" "sc" "scd"
                   "su" "sud" "sx" "sxd" "ss" "ssd" "st" "std"))
    (lyr_dlg "slyr_dlg")
  )
)

Impact: Panel drawings now open plyr_dlg (Panel Layer Control) for pc=262273; site drawings continue to open slyr_dlg. DFMEA #18 routing completeness improved.

Bug 91: Print Cleanup `layer "s" "custom"` Fails on Site Drawings — `Function cancelled`¶

Affects: src/x32/TB11-01x32/csv.lsp VM: 108 (Win10 x32)

Discovered: March 21, 2026 — G2 run cv-trace-g2-20260321-155922
Severity: Medium (print commands fail on any drawing without “custom” layer)
Status: ✅ Fixed — March 21, 2026 (commit 7f1bbfba)
DFMEA: Matches DFMEA #3 — drawing state assumed; no guard against missing layer

Symptom: G2 CSBsite1 log shows Cannot find layer "custom". followed by ; error: Function cancelled for all three print progcont values (pc=262401, 262465, 262657).

Root Cause: All three print dispatch cases in csv.lsp end with:

(command "layer" "t" "*" "u" "*" "on" "*" "s" "custom" "")

The “custom” layer exists on panel drawings (CSB001 has it as the current working layer in the CV layer model) but does not exist on CSBsite1. AutoCAD’s -LAYER S command emits Cannot find layer "custom". and terminates the entire (command ...) call with ; error: Function cancelled. This crashes all three print cleanup routines on site drawings.

Fix: csv.lsp — all three layer "s" "custom" calls wrapped with (tblsearch "layer" "custom") guard; falls back to "0" if ‘custom’ not present:

;; Bug 91: "custom" layer absent on site drawings → Function cancelled.
;; Use tblsearch guard; fall back to "0" if not present.
(command "layer" "t" "*" "u" "*" "on" "*"
         "s" (if (tblsearch "layer" "custom") "custom" "0") "")

Impact: Print cleanup now succeeds on both panel and site drawings. On panel drawings, behavior is identical to before (“custom” exists, gets set). On site drawings, layer 0 becomes current after print, which is appropriate.

Bug 92: `progcont > 1` Dispatch Has No Project-Context Guard¶

Discovered: 2026-03-21
Severity: High
Status: ✅ Fixed
VM: 108
File: csv.lsp
Commit: pending

Symptom: Any CV menu item with progcont > 1 (View Select Layers, Print, Materials List, etc.) can be invoked when no project is loaded — i.e., when AutoCAD has its default untitled Drawing*.dwg open. In this state curdir points to the AutoCAD install directory and olddwg is nil. All dispatch paths call (pj_name) which reads curdir to extract the project name, producing a garbage name from the ACAD install path (e.g., “ACAD2000”). Downstream operations would attempt to read/write files in the install directory.

Design Rule: CV was designed to run exclusively within a project context. A panel or site drawing’s directory IS the project. The only way to have olddwg = nil or curdir = acaddir is if AutoCAD’s default untitled drawing is active — an unvalidated environment. The VLX enforced this by requiring project + drawing selection before any menu item was usable. The progcont > 1 dispatch path bypassed this same contract that already existed in the default (pc=1) path.

Root Cause: The default path ((if (not pcr) ...)) has (if (or (= acaddir curdir) (= olddwg nil)) (project)) to trigger the New/Existing/Cancel dialog. The progcont > 1 dispatch block ran before this check with no equivalent guard.

Fix: Added a pre-check before the progcont dispatch cond. If progcont > 1, progcont ≠ 262153 (Create New Project), and (or (= acaddir curdir) (= olddwg nil)), then:

Alert: “No project is loaded. Select Drawing Setup to load or create a project.”
Set pcr T (suppress default-path fallthrough)
Clear progcont nil (prevent dispatch cond from executing)

Exception: *pc-new-project* (262153) is the entry point specifically for creating a first project when none exists — it must be allowed through.

;; Bug 92: Block progcont dispatch when no project is loaded.
(if (and progcont
         (> progcont 1)
         (/= progcont *pc-new-project*)
         (or (= acaddir curdir) (= olddwg nil))
    )
  (progn
    (alert
      (strcat
        "No project is loaded.\n\n"
        "From the ConstructiVision menu, select\n"
        "'Drawing Setup' to load or create a project."
      )
    )
    (set 'pcr T)
    (setq progcont nil)
  )
)

Impact: All CV operations now refuse gracefully when called without a valid project drawing open. Matches VLX-era design intent. Does not affect normal use (curdir is always set to the drawing’s directory for real project files).

Validation assertion: Au3 trace scripts should verify olddwg is non-nil and curdir ≠ acaddir after drawing opens (confirming the drawing-as-project invariant). This can be confirmed via trace log [CV-TRACE][PROJ] curdir=... entries when pj_name is called.

DFMEA Cross-Reference¶

Every bug should trace back to a DFMEA failure mode from doc 31, Section 9. If a bug does not match an existing DFMEA entry, a new DFMEA row must be added to capture the unpredicted failure mode.

TB11 Source-Mode Bugs (1–18)¶

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
1	—	(Build/config — not a design failure)	N/A	VLX override is a build artifact, not a design flaw
2	15	panelvar XRecord / dialog commit	Partial	File dialog filter is UX design gap
3	18	Panel/site auto-detection fragile	Yes	dirchk false positive is detection logic failure
4	—	(Toolchain — not predicted)	NEW	`#\|\|#` block comment limitation — add to DFMEA as toolchain risk
5	—	(Platform — not predicted)	NEW	`(command "open")` invocation/command-state sensitivity in automation — add as platform-specific failure mode
6	—	(Platform — not predicted)	NEW	QSAVE → SAVEAS active command leak — add as platform failure mode
7	—	(Build/config)	N/A	VLIDE ARX match is build configuration issue
8	14	cv.bat runtime generation	Yes	Antivirus / read-only path blocks .bat creation
9	18	Panel/site auto-detection fragile	Yes	Drawing type not persisted is detection logic gap
10	4	Batch script error stops everything	Partial	File nil is unhandled error in workflow sequence
11	—	(Naming convention)	N/A	Cosmetic — filename case
12	11	Toggle enabled with empty data	Partial	No wall lines but attach attempted = missing prerequisite check
13	11	Toggle enabled with empty data	Yes	Wall line entities absent, TEXT regression
14	6/9	Serialization / version migration	Yes	ENAME serialization is exactly the fragile I/O predicted
15	4	Batch/loop index error	Partial	Index mismatch in matching loop
16	6/9	Serialization / version migration	Yes	Same class as Bug 14 — conslist.txt
17	4	Batch/loop index error	Partial	Same class as Bug 15 — layout.lsp
18	13	progcont routing reconstructed	Yes	Fixed Mar 21: Full routing in csv.lsp L687–950. G-series validated all 17 values. Step 7 PASS B–G. RPN 240→48 (O: 2, D: 3 — routing verified, trace coverage)

Profile/Deployment Bugs (19–21)¶

Bug	Version	DFMEA #	DFMEA Failure Mode	Match?	Notes
19	PB11	19	Menu registration missing	NEW	Missing `Group1`/`Pop13` in profile Menus key; `setvars` undefined
20	v7.0	20	Startup Suite timing + environment	NEW	Startup Suite VLX loading crashes in `LocalizeReservedPlotStyleStrings`; crash NOT caused by 36-byte exe patch (disproven); suspected printer/plot config interaction; workaround: deferred loading via `acaddoc.lsp`
21	v7.0	21	Project path not registered	NEW	Missing `Project Settings\CV\RefSearchPath`; File Open dialog can’t find project drawings in subdirectories

Deployment, Environment & Validation Bugs (22–30)¶

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
22	22	XP junction path resolution	NEW	Forward slashes fail through NTFS junctions on XP; backslashes work; XP-specific behavior
23	23	AutoCAD version command mismatch	NEW	`propertiesclose` doesn’t exist in R15.0; added in AutoCAD 2004+
24	24	Validation pipeline data integrity	NEW	Screenshot overwrite causes stale data; fixed with timestamped run directories
25	25	Validation false positive	NEW	`_WaitForAnyDialog()` matches error dialogs; OCR verification is mandatory for every run
26	26	Remote deployment PATH issue	NEW	SSH sessions have minimal PATH; Git not found; scripts must be self-contained
27	27	Batch file string escaping	NEW	CMD caret escaping produces literal characters in echo output; avoid special chars in generated code
28	—	(Deployment — incomplete loading)	NEW	Source-mode `acaddoc.lsp` only loaded menu, not command definitions. VLX masks dependency.
29	4	`#\| \|#` block comment limitation	Yes	Same class as Bug 4 — recurrence in `csvmenu.lsp` headers added after Session 1 cleanup
30	—	(Automation — modal dialog timing)	NEW	`(alert)` from auto-executed `(csvmenu)` blocks AutoIT Phase 1 timing. LISPINIT=1 compounds issue.

Multi-User / New Profile Bugs (31+)¶

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
31	31	Per-user registry not propagated to new profiles	NEW	CV Update writes HKCU only; new users get blank AutoCAD profile with no CV configuration

Historical Crash & Validation Bugs (32+)¶

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
32	20	Startup Suite / VLX loading crash	Yes	Historical crashes on VM 103 — same 0xC0000005 class as Bug 20. Printer driver (hpltume5.dll), MText, SaveAs, and Undo crashes spanning 2008–2021
33	20	AutoCAD crash during drawing open	Yes	Same 0xC0000005 exception class. Crash at `LocalizeReservedPlotStyleStrings+533` during CSBsite1.dwg open on VM 104
34	32	cvplst.bat not on AutoCAD shell PATH	NEW	`btch_dlg` calls `(command "shell" "cvplst ...")` but cvplst.bat is in AutoCAD dir which is not necessarily on PATH when called from shell
35	33	Site drawing path resolution failure	NEW	progcont routing attempts to open CSBsite1.dwg but file path is malformed or file doesn’t exist at expected location

Detailed Bug Reports (32–35)¶

Bug 32: VM 103 Historical `acadstk.dmp` Crash Log¶

Discovered: March 2, 2026 (during VM 103 DMP inventory)
VM: 103 (XP-Legacy, MASTER COPY)
Severity: Info (historical record)
Status: 📋 Historical — no action needed, VM 103 is read-only
DFMEA: 20 (matches Startup Suite / VLX loading crash class)

Two acadstk.dmp files found on VM 103 containing 6 total crash entries spanning 13 years of production use:

Location 1: C:\Documents and Settings\Terry\Desktop\acadstk.dmp (1 entry)

#	Date (UTC)	Exception	Faulting Module	Symbols
1	2021-02-24 17:16	0xC0000005	ACDB15.dll	`AcDbMText::AcDbMText` → `AcDbWblockCloneFiler::usesReferences` → `AcDbDatabase::gsModel` → `AcDbImpObject::dwgIn`

Location 2: C:\Program Files\ACAD2000\acadstk.dmp (5 entries)

#	Date (UTC)	Exception	Faulting Module	Symbols
1	2008-04-10 17:32	0xC0000005	hpltume5.dll (HP printer driver)	Printer driver crash during process exit
2	2008-04-10 18:08	0xC0000005	hpltume5.dll (HP printer driver)	Identical to #1 — same session, ~36 min later
3	2013-01-31 20:09	0xC0000005	acad.exe	`respSdjhU3_x15+9CA` — internal AutoCAD function
4	2020-11-04 20:07	0xC0000005	acopm.arx + ACDB15.dll	`acrxEntryPoint` → `AcDbImpObject::close` → `AcDbLeader::getSplitCurves` → `acdbSaveAsDwg`
5	2021-09-15 16:39	0xC0000005	acad.exe	`acDocManagerPtr+19A34` — MDI document manager crash

Analysis:

The 2008 crashes (#1, #2) are HP printer driver crashes (hpltume5.dll) — same class as the Bug 20 Startup Suite crash which also involves printer/plot subsystem initialization. This confirms the printer driver instability pattern on XP.
The 2013 crash (#3) is a low-level AutoCAD internal crash.
The 2020 crash (#4) occurred during a SaveAs operation — acdbSaveAsDwg called through AcDbLeader::getSplitCurves, suggesting corruption in a leader/dimension entity.
The 2021 crash (#5) on Terry’s desktop and the MDI manager crash suggest document-switch instability — relevant to LISPINIT and MDI namespace management.
These crashes represent normal AutoCAD 2000 operational wear over 13 years of production use. They are valuable as a baseline crash rate for the product.

Bug 33: VM 104 AutoCAD Crash During CSBsite1.dwg Open¶

Discovered: March 2, 2026 (validation run run-20260302-164416)
VM: 104 (XP-TEST)
Severity: High
Status: ⏸️ Stale (not AC2027 — AC2000 runtime crash on VM 104)
DFMEA: 20 (matches Startup Suite / VLX loading crash class)

Symptom: During validation test 06 (Edit Existing Drawing), AutoCAD froze and had to be task-killed. An acadstk.dmp was generated on the desktop.

Crash dump analysis:

ExceptionCode=0xC0000005 (Access Violation)
ExceptionAddress=0x440B73
ExceptionInformation0=0x0 (read)
ExceptionInformation1=0x40 (address being read)
CrashTimeDateStamp=0x69A62F7B (2026-03-03 00:46 UTC)
ReferenceAddr=0x91DEC0 (_WinMain@16)
StackWalk0=LocalizeReservedPlotStyleStrings+533, acad.exe

Root Cause: Same crash signature as Bug 20 — LocalizeReservedPlotStyleStrings+533 in acad.exe. This is the same printer/plot subsystem initialization crash that occurs during Startup Suite VLX loading. The crash happened mid-validation when AutoCAD attempted to process the getfiled dialog result while multiple progcont commands were queued.

Impact: Tests 06 through 21 all failed — AutoCAD was frozen from test 06 onward. Tests 20 (site drawing) and 21 (site dialog) show “Cannot find the specified drawing file” because the open command couldn’t execute on a frozen/restarted AutoCAD.

Bug 34: `cvplst` Not Recognized — Batch Utilities Hangs¶

Discovered: March 2, 2026 (OCR of test 07 in run run-20260302-164416)
VM: 104 (XP-TEST)
Severity: High
Status: 🔲 Open
DFMEA: 32 (NEW)

Symptom: OCR of test 07 and test 10 shows:

'cvplst' is not recognized as an internal or external command,
operable program or batch file.

Root Cause: btch_dlg.lsp calls (command "shell" x) where x is cvplst "path" "pattern". The cvplst.bat file is created by csv.lsp in the AutoCAD directory (acaddir), but the shell command’s PATH may not include the AutoCAD directory. On VM 102/103, this works because the VLX mode has different PATH inheritance or because AutoCAD was installed with its directory on PATH.

After cvplst fails, btch_dlg enters the infinite wait loop (while (not f) ...) looking for pnllist.txt which will never be created. AutoCAD appears frozen.

Fix options:

Use full path: (strcat acaddir "cvplst") instead of bare cvplst
Set the shell’s working directory to acaddir before calling cvplst
Create cvplst.bat in curdir instead of acaddir

Bug 35: CSBsite1.dwg Not Found — Site Drawing Open Fails¶

Discovered: March 2, 2026 (OCR of test 20 in run run-20260302-164416)
VM: 104 (XP-TEST)
Severity: High
Status: ⏸️ Stale (not AC2027 — VLX progcont path on AC2000)
DFMEA: 33 (NEW)

Symptom: OCR of test 20 shows:

inter name of drawing to open <C:\Program Files\ConstructiVision\Project
Files\ConstructiVision Sample Building\CSB001.dwg>: C\Program
Files\ConstructiVision\Project Files\Construc} or Sannle,
[Building\CSBsitel dug

Cannot find the specified drawing file.

The path appears malformed — likely the open command received a corrupted or incomplete path string. This may be a cascading effect from the Bug 33 crash (test 06 froze AutoCAD, and subsequent tests ran against a recovering/restarted session), or it may indicate that the site drawing path is not correctly constructed by the au3 test after the crash recovery.

Impact: Tests 20 and 21 both failed. Test 21 shows only the “Cannot find the specified drawing file” error dialog instead of the expected Program Options dialog.

Trace Infrastructure Bugs (82–85)¶

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
82	—	Tooling load-order dependency: vl-load-com availability	NEW	`fboundp` unavailable until `vl-load-com` called; VM104 init path never calls it. Fixed: `(vl-load-com)` added. S=5 O=6 D=4 RPN=120
83	—	Tooling: AutoIT drawing-open method incompatible with AC2000 command-line	NEW	`ClipPut+^v` fails in `filedia=0` mode; bare filename fails path resolution. Fixed: full-path `Send(...,1)` slow-type matching golden reference. S=8 O=9 D=3 RPN=216
84	—	Tooling: automation continues past failed precondition, injecting keystrokes into broken state	NEW	G1/G2 `_Fail()` + “Continuing anyway” → `_SendProgcont()` fires into broken AC state → crash. Fixed: `_Finish()` after gate failure. S=9 O=10 D=2 RPN=180
85	—	Tooling: AutoIt raw-mode `Send()` emits `{ENTER}` as literal text; LISP never submitted	NEW	`Send(text & "{ENTER}", 1)` sends `{ENTER}` as characters. Fixed: split into `Send(text,1)` + `Send("{ENTER}")`. VM scripts isolated — must SCP, not git. S=8 O=9 D=3 RPN=216

G1 First-Run Bugs (86–87)¶

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
86	13	Progcont target function called without prerequisite global state (panelvar nil)	Yes	`PANATT` called via pc=1 before `drawpan` runs; `panelvar` nil; crashes on first string op. Same class as Bug 41/52. True root cause: `"panel"` key checked before `"panel_list"` — VLX key yields only 2 sections. Fixed v5: key priority swap. S=6 O=7 D=3 RPN=126
87	13	`matl_dlg` called cold — `(exit)` inside open dialog context; spurious trace artifact	Yes	Root cause was open-before-check pattern: `(load_dialog)` + `(new_dialog)` before ssget. Fixed: ssget moved before `(load_dialog)`; nil path uses `(princ)`. D rating improves: 3→2 (trace now shows clean exit). RPN 147→126
88	25	Validation false negative — automation timing mismatch	Yes	G2 `WinWait(CSBsite1)` returns early; 59 XREFs not yet resolved on cold session; commands execute against incomplete drawing. Fixed: `Sleep(1000)` → `Sleep(20000)`. S=4 O=5 D=2 RPN=40
89	13	AutoLISP compatibility — function not defined via `(load)` path	Yes	`(stringp x)` is VLIDE-only; not available in `(load)`-mode AutoLISP. Same toolchain compatibility class as Bug 4. Fix: `(= (type x) 'STR)`. D improves: 3→2 (test now catches this class).
90	18	Progcont routing not conditioned on drawing type	Yes	`pc-view-select` always dispatched to `slyr_dlg`; VLX checked drawing type. Fix: check `csv_dwgtype`; panel → `plyr_dlg`, site → `slyr_dlg`. Extends DFMEA #18 routing coverage.
91	3	Drawing state assumed without guard — missing layer causes unhandled error	Yes	Print cleanup assumes “custom” layer exists. CSBsite1 lacks it. `layer "s" "custom"` → `Function cancelled`. Fix: `(tblsearch "layer" "custom")` guard; fallback to “0”. S=4 O=5 D=3 RPN=60
92	34	No project-context gate on progcont dispatch — CV commands run in unvalidated environment	NEW	`progcont > 1` dispatch bypasses the `(or (= acaddir curdir) (= olddwg nil))` check that the default path uses. CV runs with garbage `curdir` (ACAD install dir). Fix: pre-check before dispatch cond; alert + block. Exception: `pc-new-project` allowed. S=5 O=3 D=3 RPN=45. Added as DFMEA row #34.

Bug 117: New Project Route (pc=262153) Hits DEFAULT on Blank Drawing — Regression¶

Discovered: April 14, 2026 (parity testing — G2-blank)
Severity: High
Status: ⏸️ Stale (not AC2027 — AC2000 VLX progcont regression)
Symptom: On a blank Drawing1.dwg, progcont=262153 (New Project) produces DEFAULT (pcr=nil) instead of ROUTED. This was PASS on April 13 (pcr=T). The projdet dialog may appear but the route handler never completes — pcr is never set to T.
User Observation: “the blank drawing one does not succeed just hitting escape, you actually have to enter a project name or the successive dialogs just say ‘no project loaded’. When you enter a project name and select new panel drawing it doesn’t actually draw the panel.”
Root Cause: Under investigation. The (= progcont *pc-new-project*) cond clause at csv.lsp:1069 should match. Inside the clause, (projdet) is called, then (set 'pcr T) at line 1099. If projdet throws an error that the csv *error* handler catches, execution terminates before pcr is set. The vl-catch-all-apply wrapper in the G2 harness sees a normal return (error handler swallowed it) → pcr=nil → DEFAULT.
Regression Window: Between April 13 and April 14 commits. Bug 111-116 changes modified project.lsp (added load_dialog guards) but NOT projdet.lsp or the csv.lsp dispatch block.
Impact: New Project flow completely broken on blank drawings. Users cannot create a first project from a fresh AutoCAD session.
DFMEA Reference: DFMEA-034 (extends — new failure path for same component)

Bug 118: Project Details Fields Show Stale/Default Data on Panel and Site¶

Discovered: April 14, 2026 (parity testing — G2-panel, G2-site)
Severity: High
Status: ⏸️ Stale (not AC2027 — AC2000 dialog routing / unload_dialog timing)
Symptom: When Edit Project Details (pc=524289) is invoked on CSB001.dwg or CSBsite1.dwg, the projdet dialog fields show stale/default values instead of the project’s actual data. This is the runtime manifestation of Bug 101 (get_tile after unload_dialog) and Bug 104 (project data not persisted to XRecord).
Root Cause: projdet.lsp line 75 calls (unload_dialog dcl_id_pd) BEFORE lines 77-85 attempt (get_tile ...) to read field values. Per AutoLISP Reference, get_tile returns nil after unload_dialog. The code has an explicit TODO comment acknowledging this: “We can’t get_tile after that. For now, the values persist only in the dialog. TODO: Read values in action_tile callback (Bug 101).”
Fix Required: Move all get_tile calls into the action_tile "accept" callback string, executing BEFORE done_dialog. Then write captured globals to NOD XRecord via the project persistence architecture (doc 44).
Impact: All 21 project detail fields (concrete PSI/PCF, contractor, superintendent, phones, email, address, schedule, notes, etc.) are volatile — lost on drawing close or AutoCAD restart.
DFMEA Reference: DFMEA-039 (RPN 210)

Bug 119: Materials List Fails — Panel “No Blocks”, Site “No Panels Loaded”¶

Discovered: April 14, 2026 (parity testing — manual observation)
Severity: Medium
Status: 🔲 Open
Symptom (panel): On CSB001.dwg, Materials List (pc=263169) routes correctly but matl_dlg shows “no panel blocks found.” The ssget filter '((-4 . "<and") (0 . "INSERT") (8 . "0") (-4 . "and>")) finds no INSERT entities on layer “0” because the template drawing has no components drawn (drawpan has not been run).
Symptom (site): On CSBsite1.dwg, Materials List shows “There is no Panel Drawing loaded.” The csv.lsp guard at line 966 checks for (dictsearch (namedobjdict) "panel") / "panel_list" / (= csv_dwgtype "panel") — all false on a site drawing. matl_dlg was designed for panel-only mode.
Root Cause: Two separate issues:
1. Panel: The “no blocks” message is technically correct for a fresh template — no blocks have been inserted yet. But the message is misleading (suggests data loss rather than “not yet configured”). Should distinguish template state vs error state.
2. Site: matl_dlg has no site-mode path. PB11’s VLX may have opened panel xrefs to gather materials. TB11 has no equivalent mechanism. The csv.lsp guard correctly blocks non-panel drawings but the message doesn’t explain what to do.
Fix Required: (1) Check for NOD panel data existence before ssget; if no panel configured, show “Panel has not been configured yet” instead of “no blocks.” (2) For site context, either implement xref-based material gathering or show “Materials List works on panel drawings — open the panel directly.”
DFMEA Reference: DFMEA-008 (materials list, RPN 140)

Bug 120: 4 Panel Print/Layer Routes Still DEFAULT After Bug 111 Fix¶

Discovered: April 14, 2026 (parity testing — G2-panel unchanged from April 13)
Severity: High
Status: ⏸️ Stale (not AC2027 — AC2000 VLX progcont routing)
Symptom: On CSB001.dwg (panel), these 4 routes produce DEFAULT (pcr=nil):
- pc=262209 (View All Layers)
- pc=262401 (Print Setup)
- pc=262465 (Print All)
- pc=262657 (Print Select)
The same 4 routes produce ROUTED on CSBsite1.dwg (site). The csv.lsp dispatch code is shared — no panel-specific guard. Bug 111 changed layer → _.-layer command syntax, which was necessary but not sufficient.
Root Cause: Under investigation. All 4 routes use (command ...) sequences (layer manipulation + QSAVE + plt). The working ROUTED routes (Slope, Batch, Materials, etc.) only call LISP dialog functions. Hypothesis: an earlier route in the G2-panel test sequence leaves state (active command, sysvar, layer lock) that breaks (command "_.-layer" ...) on panel drawings. The *error* handler catches the error, swallows it, and pcr is never set.
Key Evidence: These identical routes work on site (CSBsite1.dwg: 9/9 ROUTED including all 4 print routes). The discriminating factor is the panel auto-detect path that calls (panatt) during c:csv initialization — panatt modifies layer state, creates entities, and sets globals that may interfere.
Impact: All print functionality and View All Layers broken on panel drawings. 4 of 11 panel G2 routes.
DFMEA Reference: DFMEA-047 (extends Bug 111 — dash prefix necessary but not sufficient)

Static Analysis Sweep Summary (April 14, 2026)¶

Comprehensive static analysis of the full TB11 codebase (both x32 and x64 trees) covering all major crash-vector classes. Bugs 111–116 represent 194+ individual code fixes across both trees.

High-Risk — Fixed (Bugs 111–116)¶

Scan Class	Sites	Risk	Bug	Status
`(command "CMD" ...)` dialog-mode (no dash prefix)	117	Critical	111	✅ Fixed
`(exit)` violations (Rule 19)	47 (39 eliminated, 8 retained with diagnostics)	High	112	✅ Fixed
`load_dialog` / `new_dialog` unchecked returns	12	High	113	✅ Fixed
`findfile` nil (acad.exe path)	1	High	114	✅ Fixed
`(open ...)` nil file handle	13 high-risk (17 low-risk deferred)	High	115	✅ Fixed
`ssget` nil selection set	4 critical (9 low-risk deferred)	High	116	✅ Fixed

Already Guarded — No Action Needed¶

Scan Class	Sites	Finding
`getfiled` nil (user cancel)	19	All 19 properly guarded with `(if var ...)`
`getkword` / `getstring` / `getint`	3	Handled by `error` handler on ESC
`tblsearch` nil	12	All used as boolean tests in `if`/`and`
`(nth n list)` out-of-bounds	1028	Returns nil, no crash
`vla-` / `vlax-` COM calls	0	Clean — no .NET Core risk
`vl-*` runtime calls	356	All safe VLISP built-ins (no COM methods)
Sysvar save/restore (`filedia`, `cmdecho`, etc.)	7 functions	Properly managed by `csverror.lsp` `error` handler
Infinite `while` loops	0 remaining	makepan:146 was the only one (fixed in Bug 115)
`(command ...)` with file operations	5	Normal AutoCAD operations (`open`, `saveas`, `insert`)

Low-Risk — Deferred¶

Scan Class	Sites	Risk	Reason Deferred
`entget` nil	57	Low	Entity names come from validated enames via `ssget`/`entnext`
`eval` / `read` injection	590	Low	All operate on internal data (DXF lists, file contents)
Division by zero	677	Low	Runtime-only; divisors are geometry values from drawing entities
String-nil (`strcat`/`substr` with `cdr`/`assoc`)	18	Low	Filtered entity data guarantees expected DXF groups exist
Hardcoded paths	4	Low	`csv_help.lsp` (winhlp32), `csvdebug.lsp` (debug log), `SHOW.LSP` (R14 demo), `dirchk.lsp` (intentional guard)

Patterns & Lessons Learned¶

AutoCAD 2000 LISP Limitations¶

(command "open" ...) is context-sensitive in AutoCAD 2000 LISP automation; failures observed were invocation/command-state issues, not a universal OPEN defect
#| |# block comments are not supported by (load) — only by the Visual LISP IDE
(command "script" ...) fails when paths contain spaces
QSAVE on untitled drawings triggers SAVEAS and leaves an active command

VLX vs Source Mode¶

The VLIDE runtime (*vlide*) loads into ARX independently of csv.vlx
VLX detection must check only for *csv* in the ARX list
vl-acad-defun only works when functions are compiled into a VLX; it’s a no-op otherwise

Binary Integrity & VLX Loading¶

acad.exe binary analysis: VM 104’s exe has a 36-byte registration/serial patch at offset 0x6452A0–0x645368 (data section, _R_FFFRFFFRF pattern). This was initially suspected as the crash cause but disproven — the same crash occurs with VM 102’s unmodified binary.
File size alone is insufficient for integrity checks — two acad.exe files with identical size (6,795,264 bytes) had different MD5 hashes (binary diff ≠ causation)
Startup Suite loads VLX during very early AutoCAD initialization — before all subsystems are fully ready. Deferred loading (acaddoc.lsp or S::STARTUP) is more robust.
The LocalizeReservedPlotStyleStrings crash appears to be triggered by the environment (printer/plot configuration), not the binary. VM 104 has minimal printer setup (1 printer, XPS Document Writer) vs VM 102’s 7 hardware printers.
Always verify theories with controlled experiments: swap one variable while keeping others constant.

XP-Specific Quirks¶

Forward slashes fail through NTFS junctions on XP. dir "C:/path/through/junction/file" returns File Not Found, but dir "C:\path\through\junction\file" works. This is XP-specific — Windows 10 handles both.
SSH sessions (Bitvise SSH Server) have a minimal PATH — external tools like Git are not found unless their path is explicitly prepended.
The at command (XP task scheduler) is the only way to launch interactive processes from a non-interactive SSH session. start and wmic do not produce visible windows.

Automation & Validation Pipeline¶

Never trust AutoIT log PASS/FAIL alone. The _WaitForAnyDialog() function matches ANY window — including error dialogs. A file-not-found error appeared as the “CSV entry dialog.” OCR verification of screenshots is mandatory for every validation run.
Validation output must be immutable per-run — write to timestamped subdirectories, never overwrite previous results.
AutoCAD 2000 does not have propertiesclose — verify all commands against the R15.0 reference.
CMD batch file escaping is fragile — avoid parentheses, pipes, and special characters in echo >> output. Simplify generated code rather than fighting CMD’s escaping rules.
When generating LISP code from batch files via echo, test the output by type-ing the file — don’t assume correct escaping.

Deployment Scripts¶

SSH PATH limitations mean deployment scripts must be self-contained — prepend tool paths explicitly.
CV Update.bat now handles the full AutoCAD configuration lifecycle: search path, startup, project paths, and acaddoc.lsp generation. This replaced manual registry edits and the incomplete Configure-ConstructiVision.ps1.
The CONFIGURE_STARTUP, CONFIGURE_SEARCH_PATH, and CONFIGURE_PROJECT subroutines are idempotent and safe to re-run.

Defensive Coding¶

Always check (open ...) return value before using the file descriptor
Always check (ssget ...) return value before calling (sslength ...) — ssget returns nil when no entities match
Save entity data to text files before destructive operations — enables recovery in future runs
(entmake) can recreate entities from minimal DXF data: LINE needs (0 8 10 11), TEXT needs (0 8 10 40 1)
When refactoring data storage (e.g., XData vs TEXT entities), update ALL consumers — the v11 walline/inspanel mismatch was a latent bug
entget returns ENAME objects (group 330 owner pointer) that can’t survive prin1/read round-trip — always filter before serializing
Text file serialization is fundamentally fragile in AutoLISP — XData on entities is the proper AutoCAD 2000+ data storage approach
(getvar "dwgprefix") content depends on document context after vla-activate
S::STARTUP is the correct mechanism for post-document-switch continuation
(setvar "lispinit" 0) preserves LISP variables across MDI document switches

Test Matrix Status¶

Feature	CBSsite1	CSSsite	Panel Drawings
Manual Open	✅ Works	✅ Works	Untested
Drawing Setup Open	✅ Works	✅ Works	Untested
Xref Loading	✅ Auto	❌ No xrefs stored	N/A
Change 3D Viewpoint	✅ Works	✅ Works	Untested
Layout Panels	✅ Works	✅ Works	N/A
Attach Panels	✅ Works (fast path)	Untested	N/A
Tilt-Up Panels	✅ Works	Untested	N/A
Detach Panels	Untested	Untested	N/A
Drawing Type Detection	✅ Auto (dict)	✅ Auto (filename)	Untested
Panel Editor (md_dlg)	Untested	N/A	Untested

Bug 93: AutoCAD 2027 Crash — coreclr.dll ACCESS_VIOLATION During Edit Existing Drawing¶

Discovered: April 6, 2026 (local AutoCAD 2027 deployment)
Severity: Critical
Status: ✅ Fixed
DFMEA: 35 (NEW — COM/ActiveX interop crash in .NET Core CLR on AutoCAD 2024+)
Symptom: AutoCAD 2027 crashes to desktop when executing Edit Existing Drawing. User sees **** System Variable Changed **** (S::STARTUP firing), then the application terminates. Windows Error Reporting captures a minidump.
Root Cause: scr.lsp called (vla-open acDocs fullpath) + (vla-activate newdoc) — legacy ActiveX/COM API calls from AutoLISP. In AutoCAD 2024+ (which runs on .NET Core instead of .NET Framework), these COM interop calls trigger an ACCESS_VIOLATION (0xC0000005) inside coreclr.dll at offset 0x367BBA. The faulting module is the .NET Core CLR runtime itself, not acad.exe or any AutoLISP DLL. The exact failure point within coreclr.dll requires Autodesk/Microsoft debug symbols to decode.
Fix: Replaced (vla-open acDocs fullpath) + (vla-activate newdoc) with (setvar "filedia" 0) / (command "_.open" fullpath) / (setvar "filedia" 1). Removed dead code: vl-load-com call, acDocs and newdoc local variables. The (command "_.open" ...) approach is the Autodesk-supported document-switching mechanism and does not route through COM interop.
Impact: Edit Existing Drawing was completely broken on AutoCAD 2024+ — crash every time. Fix enables the full Edit Existing Drawing → open drawing → continuation (cv-cont.lsp + acaddoc.lsp + S::STARTUP) workflow.
Crash Evidence: reports/crash-dumps/acad2027-20260406-coreclr-0xC0000005/analysis.md — full crash analysis with exception details, faulting module, loaded modules, GPU/system context, and alternative hypotheses.
CER UUID: 44f2710f-9f20-4e18-9ccc-3b74ae08cb4e
Files: scr.lsp (both x32 and x64 builds)
Commit: 64d8675a5
Lesson Learned: Never assume crash root cause from context alone — always examine the crash dump. The crash was initially attributed to vla-activate based on Autodesk forum posts about AutoCAD 2024+ crashes with ActiveX calls; the actual faulting module was coreclr.dll (.NET Core CLR), confirming the COM-to-.NET interop path is the failure mechanism. All VLA/ActiveX automation calls in AutoLISP code should be reviewed for AutoCAD 2024+ compatibility — any of them could trigger the same coreclr.dll crash. Prefer (command ...) wrappers for document operations over VLA equivalents.

Bug 94: `Unknown command "DWG"` — scr.lsp OPEN Sub-Prompt Leak¶

Discovered: April 6, 2026 (local AutoCAD 2027 deployment)
Severity: High
Status: ✅ Fixed (v11.04 — reverted to script-file OPEN)
DFMEA: 36 (NEW — _.open sub-prompt handling difference in AutoCAD 2025+)
Symptom: After Bug 93 fix replaced vla-open with (command "_.open" fullpath), the drawing still does not open. AutoCAD prints Unknown command "DWG" to the command line. The trace shows: [CSV] opening via scr olddwg=AAAsite1.dwgUnknown command "DWG". Press F1 for help. — no newline between the trace and the error, indicating the failure is synchronous during the (command ...) call.
Root Cause: The (command "_.open" fullpath "") approach passes the OPEN command and its arguments through the LISP command function’s argument pipeline. On AutoCAD 2027 (.NET Core), this pipeline leaks “DWG” as an unknown command — likely due to the OPEN command’s prompt sequence differing from earlier versions. The trailing "" and cmdactive drain loop did not resolve the issue. Additionally, PB11-00x32/scr.lsp (the original working implementation) never used (command "_.open" ...) — it always used .SCR script files. The function is literally named scr() for this reason.
Fix: Reverted to PB11’s proven script-file mechanism (v11.04): write a .scr file with _.OPEN "fullpath" and execute via (command "_.script" scrpath). Key improvements over PB11: (1) only adds “Y” save-prompt response in SDI mode (PB11 always added it on dbmod>0, which would break MDI by sending “Y” to the filename prompt), (2) writes script to %TEMP% not curdir, (3) keeps cv-cont.lsp + acaddoc.lsp S::STARTUP continuation for MDI/LISPINIT=1 compatibility.
Impact: Edit Existing Drawing flow should now open the selected drawing. The cv-cont.lsp continuation mechanism was already working correctly.
Files: scr.lsp (both x32 and x64 builds)
Commit: 27a139588 (failed attempt), 40c3b7071 (v11.04 script-file fix)
Lesson Learned: When modifying legacy code that uses a specific mechanism (script files), understand WHY that mechanism was chosen before replacing it with a “modern” alternative. The (command "_.open" ...) approach was never the right fix — it replaced a proven script-file mechanism with an untested LISP command pipeline that behaves differently across AutoCAD versions.

Bug 95: Edit Existing Drawing Blocked by Bug 92 Guard¶

Discovered: April 6, 2026 (local AutoCAD 2027 deployment)
Severity: High
Status: ✅ Fixed
DFMEA: 34 (progcont dispatch context gate — same failure class)
Symptom: Clicking Drawing Setup → Existing Drawing → Edit Existing Drawing did nothing. The Bug 92 guard in c:csv blocked the *pc-edit-drawing* progcont value (262145) because olddwg was nil (user was on untitled Drawing1.dwg) and the guard treated nil olddwg as “no project context.”
Root Cause: The Bug 92 guard checked (and (not olddwg) (> progcont 1)) and bailed out for all progcont values > 1 when on an untitled drawing. But Edit Existing Drawing (*pc-edit-drawing* = 262145) is specifically an entry-point command that should work from an untitled drawing — its purpose is to select and open a project file.
Fix: Added *pc-edit-drawing* to the guard exemption list alongside *pc-new-project*. The guard now allows both entry-point commands to proceed without an existing project context.
Impact: Edit Existing Drawing → Open flow restored from untitled drawings.
Files: csv.lsp (both x32 and x64 builds)
Commit: e5ad3aa41

Bug 96: Default Project Directory Points to My Documents¶

Discovered: April 6, 2026 (local AutoCAD 2027 deployment)
Severity: High
Status: ✅ Fixed
DFMEA: 36 (NEW — directory derivation broken on modern AutoCAD installs)
Symptom: All getfiled dialogs (Drawing Setup, New Project, Existing Project) defaulted to C:\Users\chadw\Documents\ instead of the CV Project Files directory.
Root Cause: curdir was derived from (getvar "dwgprefix"). On an untitled Drawing1.dwg, dwgprefix returns the user’s Documents folder. The original code assumed curdir would equal acaddir (the AutoCAD program directory), but on modern installs where AutoCAD is in C:\Program Files\Autodesk\AutoCAD 2027\, the Documents folder does not match — so all directory comparison logic failed silently.
Fix: Added projdir computation that derives the CV Project Files path from (findfile "csv.lsp") — going up two directory levels from the CSV source directory. Search order: csvdir\Project Files\ → csvdir\..\..\Project Files\ → acaddir\Project Files\ → curdir fallback. When olddwg is nil (untitled drawing), curdir is overridden with projdir.
Impact: File dialogs now default to the correct project directory on all AutoCAD versions and install configurations.
Files: csv.lsp (both x32 and x64 builds)
Commit: e5ad3aa41

Bug 97: project() While Loop Condition Never True¶

Discovered: April 6, 2026 (local AutoCAD 2027 deployment)
Severity: High
Status: ✅ Fixed
DFMEA: 36 (NEW — path comparison logic assumes legacy install layout)
Symptom: Clicking “Existing Project” in the Drawing Setup dialog produced no file browser. The project() function’s while loop (while (= acaddir curdir) ...) never executed because curdir (derived from dwgprefix = My Documents) never equaled acaddir (C:\Program Files\Autodesk\AutoCAD 2027\).
Root Cause: The while loop was designed for legacy installs where CV was installed inside the AutoCAD program directory. On modern installs (separate directories, user Documents as default), the entry condition (= acaddir curdir) is always false, so the getfiled call inside the loop is never reached. The user clicks “Existing Project” and nothing happens — a complete silent failure.
Fix: Force loop entry by setting curdir to "" before the while loop, and replaced acaddir references inside the loop with projdir. This ensures the file browser always appears on first click, and subsequent cancellations default to the project directory.
Impact: Existing Project file browser now always appears when clicked.
Files: csv.lsp (both x32 and x64 builds)
Commit: e5ad3aa41

Bug 98: `(exit)` in project() Silently Aborts¶

Discovered: April 6, 2026 (code review during Bug 96/97 investigation)
Severity: Medium
Status: ✅ Fixed
Symptom: If load_dialog fails in project(), (exit) terminates the entire c:csv call chain. No error message, no command line output, no sysvar restoration.
Root Cause: Pre-existing code pattern. (exit) in AutoLISP terminates the calling LISP expression and all parents — equivalent to throwing an unhandled exception. Used here as a bail-out mechanism with no diagnostics.
Fix: Replaced (exit) with [CSV-ERROR] diagnostic output (prints the failed DCL path, findfile check result, and relevant variable state) followed by (set 'pnl "cancel") for clean bail-out. The function returns normally instead of crashing the call chain.
Impact: Dialog load failures now produce visible diagnostics instead of silent termination.
Files: csv.lsp (both x32 and x64 builds)
Commit: cb3a1a472

Bug 99: No `error` Handler in c:csv¶

Discovered: April 6, 2026 (code review during Bug 96/97 investigation)
Severity: Medium
Status: ✅ Fixed
Symptom: Any unhandled error during c:csv execution (bad argument, nil access, dialog failure, file I/O error) silently aborted the entire function. No error message reached the command line, sysvars were not restored to pre-command values.
Root Cause: Pre-existing omission. c:csv sets ~60 sysvars at entry but had no *error* handler to restore them on failure. All errors propagated to AutoCAD’s default handler, which prints a generic ; error: message but does not restore CSV-specific sysvars.
Fix: Installed comprehensive *error* handler at the top of c:csv that: (1) prints [CSV-ERROR] with the error message, (2) prints diagnostic state (curdir, olddwg, pnl, pcr, progcont, projdir, csvdir), (3) restores all modified sysvars, (4) restores the previous *error* handler. Added [CSV] c:csv finished normally trace at the end of successful execution.
Impact: All errors during CSV operations now produce visible diagnostics with full state context, and sysvars are always restored.
Files: csv.lsp (both x32 and x64 builds)
Commit: cb3a1a472
Lesson Learned: Every c: command in AutoLISP that modifies sysvars MUST install a *error* handler that restores them. This is now Copilot Rule 19. Silent failures waste entire debugging sessions.

Bug 100: “Create New Project” Crashes with “This drawing has no panel data”¶

Discovered: April 6, 2026 (user testing “Create New Project” menu item)
Severity: High
Status: ✅ Fixed
Symptom: After filling in Project Details and creating a new project folder, the application shows an alert “This drawing has no panel data” and crashes with bad argument type: FILE nil in wclist.lsp. The “Create New Project” workflow is completely blocked.
Root Cause: Two-part failure: (1) mp_dlg.lsp unconditionally called (panatt) to load panel XRecord data, even when pnl="new" (no panel exists yet). panatt’s strict guard aborts with “no panel data” alert and (exit). (2) If panatt was bypassed, wclist.lsp tried to open a weld connection list file with (open ...) which returned nil (no file exists for a new drawing), causing bad argument type: FILE nil.
Fix (v2): (1) mp_dlg.lsp skips panatt when pnl="new", calls (convert "panel") instead to initialize panel data from scratch. (2) Reverted panatt guard to strict (v1 exemption was wrong — letting code continue past panatt on a new drawing crashed downstream). (3) Added nil guard to wclist.lsp (open ...) call for defense-in-depth.
Impact: “Create New Project” → Project Details → New Drawing workflow now works end-to-end. Critical for user onboarding.
Files: mp_dlg.lsp, panatt.lsp, wclist.lsp (both x32 and x64 builds)
Commit: 95730f624
Lesson Learned: Guard at the workflow gate (mp_dlg for pnl=“new”), not at the data access point (panatt). v1 attempted to weaken panatt’s guard, which propagated nil state to downstream functions. v2 correctly skips panatt entirely for new drawings.

Bug 101: AutoCAD 2027 Crash on Exit — `System.ExecutionEngineException` in `coreclr_shutdown`¶

Discovered: April 7, 2026 (Test 1 — Create New Project succeeded, crash occurred while closing AutoCAD)
Severity: Low (crash on exit only — user data safe, no work lost)
Status: ⚠️ External (Autodesk bug — no CV code fix possible)
Symptom: After successfully completing Test 1 (New Project workflow), user closes AutoCAD 2027. AutoCAD crashes with “A software problem has caused AutoCAD to close unexpectedly” CER dialog. Minidump generated at %LOCALAPPDATA%\Autodesk\CER\...\1775583845586\.
Root Cause: System.ExecutionEngineException thrown during .NET Core CLR shutdown sequence (coreclr_shutdown / coreclr_shutdown_2). The VLISP runtime (vl_u_crx.dll, PDB: U:\develop\local\current\Release64\bin\acad\vl_u_crx.pdb) calls acedGetAcadFrame() during teardown, but the managed AutoCAD frame object has already been finalized by the .NET Core garbage collector. This is a race condition in Autodesk’s shutdown orchestration between the native VLISP runtime and the .NET Core managed layer.
Evidence from minidump:
- Exception: System.ExecutionEngineException
- Stack reference: <Module>.acedGetAcadFrame()
- CLR functions: coreclr_shutdown, coreclr_shutdown_2
- Crash thread: 32508, PID: 15740
- Application: AcCoreConsole.exe (AutoCAD 2027 R26.0, build 26.0.60.0.0)
- CER UUID: e9e9428d-68af-43ff-b51e-2aabc7d45511
CV Code Analysis: Zero CV modules in loaded module list. No vla-*/vlax-* calls executed (csv_help.lsp’s vl-load-com not invoked during Test 1). VLISP runtime loaded automatically because csv.lsp is in Startup Suite — this is normal and unavoidable.
Impact: None on user workflow. Crash occurs only during AutoCAD exit. No data loss. The CER dialog is cosmetically annoying but functionally harmless.
Workaround: None needed (crash on exit only). If persistent, user can dismiss the CER dialog or disable CER reporting.
Resolution path: File with Autodesk via CER (“Send Report” button) referencing crash UUID e9e9428d-68af-43ff-b51e-2aabc7d45511. This is the same DFMEA-035 failure class as Bug 93 but in the shutdown path rather than the runtime path.
Files: None (no CV code change needed)
Commit: N/A
Lesson Learned: Same DFMEA-035 class as Bug 93 (coreclr + VLISP interop), but in shutdown path. Confirms that the .NET Core migration in AutoCAD 2025+ has systemic issues with VLISP runtime lifecycle management. Monitor for recurrence — if it happens during save or mid-operation, severity escalates.

Bug 102: New Drawing Dead End — `pcr=T` Kills Editor Launch¶

Discovered: April 7, 2026 (Test 2 — opened AAA001.dwg, clicked ConstructiVision > New Drawing, typed Panel, clicked Cancel on getfiled)
Severity: High
Status: ✅ Fixed
Symptom: After New Drawing → Panel → Cancel on file picker, nothing happens. No panel editor dialog appears. The user is left on the current drawing with no way to draw a new panel from scratch. The command line shows [CSV] c:csv finished normally but no editor was launched.
Root Cause: The *pc-new-drawing* dispatch block (progcont=262161) in csv.lsp unconditionally set (set 'pcr T) after the getfiled call, regardless of whether the user picked a file or cancelled. pcr=T prevents the default routing block from executing, which is where Paths 2 and 4 live — the code that actually launches the panel/site editor.
Fix: Removed the unconditional (set 'pcr T). Now:
- Cancel (user wants blank drawing): pnl="autonew", pcr=nil → default routing Path 2 catches pnl="autonew" → launches (panel) or (sdwg_dlg) based on csv_dwgtype.
- Template selected: pnl="old", olddwg set, pcr=nil → default routing Path 4 catches (and olddwg (= pnl "old")) → opens drawing via (scr) → S::STARTUP fires on new document → editor launches.
- Path 2 updated: Now respects csv_dwgtype (set from csv_newdwg_type) to route to panel editor (ld="pt") or site editor (ld="st") instead of always defaulting to panel.
Impact: New Drawing workflow now works end-to-end for both cancel (blank scratch) and template selection paths, for both Panel and Site drawing types.
Files: csv.lsp (both x32 and x64 builds)
Commit: (pending)

Bug 103: `cvxpproj.lsp` Export Naming Mismatch — 19 of 21 Globals Exported as Null¶

Discovered: April 9, 2026 (parity audit of project detail variable lifecycle)
Severity: High
Status: 🔲 Open
Symptom: The cvxpproj.lsp validation export script reports null for 19 of 21 project detail runtime globals, even after the user has entered values via the Project Details dialog and the globals are populated in memory. Only concpsi and concpcf export correctly.
Root Cause: Naming mismatch between projdet_edit() and cvxp-snapshot-globals(). The projdet_edit() accept callback stores 19 of 21 values with csv_ prefix (e.g., csv_super, csv_dprec, csv_msys, csv_email). Only concpsi and concpcf use bare names. But cvxp-snapshot-globals() probes ALL variables with bare names (e.g., super, dprec, msys, email) — these bare-name globals are never set. Complete mapping of all 21 mismatches documented in Project Data Persistence Architecture.
Fix: Update cvxp-snapshot-globals() to probe csv_-prefixed names first with bare-name fallback: (or (cvxp-safe-eval 'csv_super) (cvxp-safe-eval 'super)). Also add individual csv_city/csv_state/csv_zip probes (currently only the composite csz is exported).
Impact: All project metadata export/diagnostics will report accurate values for the first time. Previously, every c:cvxpprojdebug run silently returned null for contact info, measurement system, precision, language, and page size — making validation data unreliable.
Files: scripts/validation-lsp/cvxpproj.lsp, scripts/validation-lsp/cvxpproj.schema.json
Commit: (pending)
DFMEA Reference: DFMEA-040 (RPN 400)

Bug 104: Project Details Not Persisted to XRecord — Data Lost on AutoCAD Restart¶

Discovered: April 9, 2026 (parity audit — confirmed VLX persists across restarts, TB11 source mode does not)
Severity: Critical
Status: 🔲 Open
Symptom: User opens Project Details dialog, fills in all 21 fields (concrete PSI, contractor, superintendent, phones, email, measurement system, precision, language, page size), clicks OK. Values appear to be accepted. But after closing and reopening AutoCAD on the same drawing, all fields revert to defaults or blanks. Only contractor (mpco), project location (mplo), and city/state/zip (ADD2) partially survive via title block ATTRIBs. The remaining 16 fields are completely volatile — lost every session.
Root Cause: projdet_edit() in projdet.lsp correctly captures all 21 values into globals via the action_tile "accept" callback. But the function NEVER writes those globals to any persistent storage — no XRecord, no title block update, no file write. The globals exist only in the VLISP runtime memory and are destroyed when AutoCAD closes. The PB11 VLX has compiled persistence code that does not exist in the TB11 source tree (same class of VLX/source mismatch as Bug 13/progcont routing). This was previously mis-classified as a “feature request” — it is a regression from VLX behavior.
Fix: Create a new project_list NOD dictionary key (separate from panel_list and site_list) to store all 21 project detail variables. Implementation:
1. Define pdvar alist in convert.lsp (21 variables with defaults)
2. Add csv_write-project-xrecord to projdet.lsp — called after projdet_edit accept, writes globals to NOD using DXF 1/2/3 format matching panel_list convention
3. Add csv_read-project-xrecord to projdet.lsp — called at startup and at top of projdet_edit, reads NOD project_list and sets globals
4. Wire csv_read-project-xrecord into csvmenu.lsp startup chain
Impact: All 21 project detail fields will persist across AutoCAD sessions for the first time in source mode. Achieves parity with VLX behavior. Enables reliable export via cvxpproj.lsp. Design documented in Project Data Persistence Architecture.
Files: projdet.lsp, convert.lsp, csvmenu.lsp, csv_diag.lsp
Commit: (pending)
DFMEA Reference: DFMEA-039 (RPN 210)

Bug 105: `pjdll.lsp` Text-Mode Line Reader — `read-char` Returns LF Not CR¶

Discovered: April 12, 2026 (pj.dll import testing — Project Details dialog showed empty schedule/notes/estimator)
Severity: High
Status: ✅ Fixed
Symptom: After implementing pj.dll import in pjdll.lsp, the cipher decoder returned nil for all fields. Project Details dialog showed empty schedule, notes, and estimator fields despite pj.dll containing valid encrypted data.
Root Cause: csv_pjdll-read-line-bytes used (= ch 13) (CR) as the sole line terminator. AutoLISP (open filename "r") opens files in text mode on Windows, which translates CRLF sequences to LF at the C runtime level. read-char therefore returns LF (byte 10) at line boundaries, never CR (byte 13). The line reader accumulated the entire file as one garbled line → the field-count check failed → decoder returned nil → all 58 pj.dll fields silently missing.
Fix: Changed line terminator check from (= ch 13) to (or (= ch 13) (= ch 10)) — handles both text mode (LF) and any future binary mode (CR). Ref: AutoLISP open function — text mode is default; read-char operates on translated stream.
Impact: pj.dll cipher decoder now correctly parses all 58 fields. Schedule, notes, and estimator data from pj.dll appear in Project Details dialog.
Files: pjdll.lsp
Commit: e16f8f898
Key Insight: AutoLISP has no binary file mode — (open ... "r") is always text mode on Windows. Any byte-level file reader must account for CRLF→LF translation. This affects all custom file parsers in the codebase.
DFMEA Reference: DFMEA-041 (RPN 224)

Bug 106: `projdet.lsp` Import Gate — `csv_contractor` Already Filled by Title Block¶

Discovered: April 12, 2026 (same investigation as Bug 105 — pj.dll data not appearing)
Severity: High
Status: ✅ Fixed
Symptom: Even after fixing Bug 105 (line reader), pj.dll-exclusive fields (schedule, notes, estimator) still did not appear in the Project Details dialog. The pj.dll import code never executed.
Root Cause: The pj.dll import gate in projdet.lsp checked (csv_is-empty csv_contractor) to decide whether to attempt pj.dll import. But csv_read-title-block + the mp* variable bridge already populated csv_contractor from the drawing’s title block ATTRIBs earlier in the data retrieval hierarchy (NOD XRecord → title block → runtime globals → convert defaults). By the time the pj.dll import check ran, csv_contractor was non-empty (set from title block) → the gate evaluated false → pj.dll import was skipped entirely. Fields that exist only in pj.dll (schedule, notes, estimator) were never imported.
Fix: Changed the import gate from checking csv_contractor (shared between title block and pj.dll) to checking csv_schedule, csv_notes, and csv_estimator (pj.dll-exclusive fields). Gate now reads: “try pj.dll if ANY dll-exclusive field is still empty.”
Impact: pj.dll import now correctly fires when pj.dll-exclusive data is missing, regardless of whether shared fields were already populated by higher-priority sources. Data retrieval hierarchy is now respected: NOD XRecord > title block > pj.dll > runtime globals > convert defaults.
Files: projdet.lsp
Commit: e16f8f898
Key Insight: Import gates must check fields exclusive to the data source being gated, not shared fields that may be populated by higher-priority sources in the data retrieval hierarchy. This is a general pattern for any multi-source data pipeline.
DFMEA Reference: DFMEA-042 (RPN 280)

Bug 107: First `c:csv` Call Silently Aborts — `error` Masks panatt Failure During csv_dwgtype Detection¶

Discovered: April 14, 2026 (parity testing — cv-test-trace.lsp trace output)
Severity: High
Status: ✅ Fixed
Symptom: The first invocation of c:csv after module loading appears to return normally (no error visible to vl-catch-all-apply), but pcr stays nil, progcont is not cleared, and csv_dwgtype remains nil. The second and subsequent calls work correctly.
Root Cause: On the first c:csv call, modules are freshly loaded via csvlst (98 entries). The csv_dwgtype auto-detect block (Bug 63 fix) then runs Tier 1 detection: (dictsearch (namedobjdict) "panel") matches on CSB001.dwg → calls (panatt) directly. panatt errors on uninitialized state (first call after fresh load). The CSV *error* handler (csverror.lsp) catches the error, prints diagnostics, restores sysvars, and returns via (princ). This terminates c:csv mid-execution — (set 'csv_dwgtype "panel") never runs, (setq progcont nil) at line ~1271 never runs. Critically, vl-catch-all-apply sees a NORMAL return (not an error object) because *error* intercepted the error before it could propagate. The caller has no indication that c:csv failed. On the second call, modules are already loaded AND panelvar is partially set from the first call’s panatt attempt → csv_dwgtype detection works correctly.
Fix: Wrap the (panatt) call inside the csv_dwgtype Tier 1 cond clause with vl-catch-all-apply to isolate panatt errors. If panatt errors, log a warning but still set csv_dwgtype = "panel" (the NOD check already confirmed it IS a panel drawing). This makes the Tier 1 detection resilient to panatt initialization errors without aborting c:csv.
Impact: Any caller using vl-catch-all-apply to invoke c:csv (including the au3 test fixture’s (progn (setq progcont N)(c:csv)) pattern) will now get correct routing on the first call. Eliminates the “warm-up call” requirement and fixes 4 cascading G2-panel test failures.
Files: csv.lsp
DFMEA Reference: DFMEA-043 (RPN 294)

Bug 108: `matl_dlg.lsp` Cond Default Has Stray `=` Operator — Materials List Crashes¶

Discovered: April 14, 2026 (parity testing — cv-test-diag.lsp diagnostic output)
Severity: High
Status: ✅ Fixed
Symptom: Calling (matl_dlg) on a panel drawing with any custom block names (not matched by the material code prefix patterns) crashes with error: too few arguments. The Materials List dialog never appears. Additionally, the new_dialog failure path used (exit) which silently terminated c:csv — replaced with csv_matl-ok guard-flag pattern.
Root Cause: In matl_dlg.lsp, the material code collation (mapcar ...) uses a (cond ...) to rename block name prefixes to human-readable names (PP* → Panel Prop, BP* → Blockout Prop, J_BOLT → J-Bolt, etc.). The default (catch-all) clause at line 513 (x32) / 516 (x64) reads:
```
((T = (set 'matcnt (subst (list (strcat "Custom Block,  " y) (cadr x)) x matcnt))))
```
This is malformed. The stray = between T and (set ...) causes the cond to evaluate (= single-argument) — the = function requires exactly two numeric arguments. With one argument, it throws “too few arguments”. The correct syntax is:
```
(T (set 'matcnt (subst (list (strcat "Custom Block,  " y) (cadr x)) x matcnt)))
```
The outer (( )) double-wrapping is also wrong — cond default clauses use single ( ).
Fix: Remove the stray = and fix the parenthesization of the cond default clause.
Impact: Materials List generation will work for all panel drawings, including those with custom block names not in the standard prefix table. This was the only real code bug in matl_dlg — the 15/17 PASS diagnostic confirmed all other handlers work correctly.
Files: matl_dlg.lsp
DFMEA Reference: DFMEA-044 (RPN 168)

Bug 109: `matl_dlg.lsp` `(cons)` Misplaced Paren — wcl Default Entry Crashes Materials List¶

Discovered: April 13, 2026 (parity testing — cv-test-trace.lsp bisection tracing)
Severity: High
Status: ✅ Fixed
Symptom: Materials List route (progcont=263169) fails with error: too few arguments inside matl_dlg. The error is caught by CSV’s *error* handler, which terminates c:csv mid-execution. The Materials dialog never appears. From the caller’s perspective, c:csv appears to complete normally (pcr=T from the *error* handler’s path, but no dialog shown).
Root Cause: In matl_dlg.lsp, when building the wall component list from wcl.txt, if no entry with key 0 exists in the list, the code attempts to create a default entry using (cons). The closing parenthesis is misplaced:
```
;; BUGGY (line 157 x32 / line 156 x64):
(set 'wcl (cons (list 0 " " 0.0 0.0 0.0 "" "" "" "" "" "" "" 0.0 0.0)) wcl)
;;                                                                     ^-- closes cons with 1 arg
;;                                                                         wcl is standalone
```
The ) after (list ...) closes cons with only ONE argument. wcl becomes a standalone expression (evaluates but result is discarded). (cons single-arg) throws “too few arguments” — cons requires exactly 2 arguments. The correct form is:
```
(set 'wcl (cons (list 0 " " 0.0 0.0 0.0 "" "" "" "" "" "" "" 0.0 0.0) wcl))
```
Only triggered when wcl.txt has no entry with key 0. CSB001’s wcl.txt has only keys 6 and 7 — no default entry. This is a pre-existing PB11 paren bug that was never caught because VLX test data always included a key-0 entry.
Fix: Move the misplaced closing paren from after (list ...) to after wcl so cons receives both required arguments. Applied to both x32 and x64 trees. Also fixed in same session: Bug 108 (exit) replaced with csv_matl-ok guard-flag pattern to prevent silent c:csv termination on dialog load failure.
Impact: Materials List now routes correctly on panel drawings where wcl.txt lacks a default (key 0) entry. This was the final blocker for G2-panel parity — after this fix, all 6 progcont route tests pass (6/6 ROUTED).
Files: matl_dlg.lsp
DFMEA Reference: DFMEA-045 (RPN 175)

Bug 110: `okcanhlp.lsp` Cancel Handlers Missing `(done_dialog)` — 6 Dialogs Uncancellable¶

Discovered: April 14, 2026 (G2-panel retest — CV-TEST-PANEL stuck on test 4, View Select Layers)
Severity: High
Status: ✅ Fixed
Symptom: Running G2-panel validation (CV-TEST-PANEL), the test reaches test 4 (View Select Layers, progcont=262273). The layer dialog (lyr_dlg) opens, but clicking Cancel, pressing Escape, or clicking X does nothing — the dialog is completely uncancellable. The only way to recover is taskkill /f /im acad.exe. Same pattern affects 5 other dialogs: Wall Line (wl), Non-Rect Blockout (nb), Window/Door Opening Page (wd), Weld Connections Page (wc), WC Edit (we).

Root Cause: okcanhlp.lsp is the centralized OK/Cancel/Help callback router for ConstructiVision dialogs. When a dialog registers (action_tile "cancel" "(okcanhlp $key \"ly\")"), this replaces the DCL default cancel behavior (done_dialog 0).

Ref: action_tile — AutoLISP Reference: “The default action for a cancel tile is (done_dialog 0). If no action is assigned…” — when action IS assigned, the default is replaced.

6 dialogs route cancel through okcanhlp (confirmed by grep of all action_tile "cancel" calls in TB11):

File	Code	Cancel handler before fix
`lyr_dlg.lsp`	`ly`	`(set 'pnl "cancel")` — no `done_dialog`
`wall_dlg.lsp`	`wl`	`(set 'ok nil)` — no `done_dialog`
`nb_dlg.lsp`	`nb`	empty — no `done_dialog`
`wdpage.lsp`	`wd`	empty — no `done_dialog`
`wcpage.lsp`	`wc`	empty — no `done_dialog`
`wc_edit.lsp`	`we`	`(set 'ok "0")` — no `done_dialog`

lyr_dlg.lsp is the worst case: it has a (while (/= pnl "cancel") ...) loop at line 92 that depends on start_dialog returning. Cancel sets pnl = "cancel" but never calls done_dialog, so start_dialog blocks forever and the while-loop condition is never re-evaluated.

Note: The other ~31 cancel handlers in okcanhlp are dead code — those dialogs (ch, dl, dr, fh, etc.) handle cancel directly in their own action_tile calls with (done_dialog). Only these 6 actually route through okcanhlp.

Fix: Added (done_dialog) to all 6 cancel handlers in okcanhlp.lsp. State-setting handlers keep their state changes before done_dialog. Applied to both x32 and x64 trees.
Impact: All 6 affected dialogs are now properly cancellable. The lyr_dlg while-loop now breaks correctly when the user clicks Cancel. This was the blocker for G2-panel test 4 (View Select Layers).
Files: okcanhlp.lsp
DFMEA Reference: DFMEA-046 (RPN 168)

Bug 111: `(command "CMD" ...)` Without Dash Prefix Opens Dialog/Palette Mode — Silent Failures Across Entire Codebase¶

Discovered: April 13, 2026 (parity testing — G2-panel print routes all returning DEFAULT)
Severity: High
Status: ✅ Fixed
Symptom: All 4 print/layer routes (View All Layers, Print All, Print Setup, Print Select) returned DEFAULT in G2 panel test. No ERROR caught by vl-catch-all-apply — *error* handler intercepted the error internally. pcr never set to T. No visible crash, just silent failure to execute the route.
Root Cause: Multiple AutoCAD commands changed from command-line to dialog/palette mode in AutoCAD 2006–2020+. When called via (command "CMD" ...) in AutoLISP without the dash prefix (-CMD), the dialog/palette opens and returns immediately. Arguments intended as subcommands fall through to the command processor as invalid commands, triggering *error* silently.

Affected commands and when they changed:
- LAYER → Layer Properties Manager palette (AutoCAD 2000+, modeless since 2006)
- INSERT → Insert Block palette/gallery (AutoCAD 2020+)
- BLOCK → Block Editor (AutoCAD 2006+)
- HATCH → Hatch Creation ribbon tab (AutoCAD 2011+)
- ARRAY → Associative Array (AutoCAD 2012+)
- PURGE → Purge dialog (AutoCAD 2020+)
The dash prefix (-CMD) forces command-line mode on all versions. The _. prefix ensures English command + original definition (no menu overrides).

Additionally, View All Layers used (command "expert" 5) instead of (setvar "expert" 5).
Fix: Codebase-wide bulk replace applied in two passes:
1. LAYER (_.-layer): 70 instances across 17 files — applied to both x32 and x64. -LAYER exists since AutoCAD 2000 (R15).
2. INSERT (_.-insert): 31 instances across 8 files — applied to both x32 and x64. -INSERT exists since AutoCAD R14.
3. BLOCK (_.-block): 4 instances — x64 only. -BLOCK did not exist in AutoCAD 2000.
4. HATCH (_.-hatch): 8 instances — x64 only. -HATCH did not exist in AutoCAD 2000.
5. ARRAY (_.-array): 3 instances — x64 only. -ARRAY did not exist in AutoCAD 2000.
6. PURGE (_.-purge): 1 instance — x64 only. -PURGE did not exist in AutoCAD 2000.
Total: 117 instances fixed across 21 files in both build trees.

BLOCK/HATCH/ARRAY/PURGE are x64-only because the dash-prefix variants did not exist in AutoCAD 2000 (the commands were already command-line-only in R15 — their dialog modes were added in later versions). Applying dash prefix in x32 would break AutoCAD 2000 compatibility.
Impact: 4 G2-panel print tests should flip from DEFAULT to ROUTED (7/11 → potentially 11/11). All block insertion, hatching, arraying, and purging operations now safe on AutoCAD 2027. Eliminates an entire class of silent failure across the codebase.
Files: csv.lsp, plt.lsp, md_dlg.lsp, site_dlg.lsp, grid_dlg.lsp, panatt.lsp, chamfer.lsp, drawpan.lsp, drawdim.lsp, drawdimlst.lsp, nbblock.lsp, opening.lsp, finpan.lsp, inspanel.lsp, lyr_dlg.lsp, makepan.LSP, layout.lsp, green.lsp, bolt.lsp, brace.lsp, pick.lsp, weldconn.lsp, pointmap.lsp
DFMEA Reference: DFMEA-047 (RPN 252)

Bug	DFMEA #	DFMEA Failure Mode	Match?	Notes
93	35	COM/ActiveX VLA calls crash .NET Core CLR in AutoCAD 2024+ (coreclr.dll ACCESS_VIOLATION)	NEW	New runtime incompatibility class: legacy VLA API → COM interop → .NET Core CLR crash. Fix: use `(command ...)` wrappers. S=9 O=7 D=3 RPN=189. Affects all VLA calls.
94	36	`(command "_.open" ...)` sub-prompt leaks to command line — original PB11 used .scr script files	NEW	v11.03 incorrectly replaced PB11’s .scr script-file approach with `(command "_.open" fullpath)`. The command pipeline leaks “DWG” as unknown command on ACAD 2027. Fix: revert to script-file OPEN with SDI/MDI-safe dbmod handling. S=7 O=5 D=4 RPN=140.
95	34	progcont dispatch context gate blocks valid entry-point commands	Yes	Bug 92 guard was too aggressive — blocked pc-edit-drawing from untitled Drawing1.dwg. Same failure class as DFMEA-034. Fix: exempt edit-drawing from guard.
96	36	Default directory derived from dwgprefix (My Documents) instead of CV install dir	NEW	curdir=dwgprefix on Drawing1.dwg = My Documents. All getfiled dialogs defaulted to wrong dir. Fix: derive projdir from `(findfile "csv.lsp")`.
97	36	project() while loop condition never true on modern AutoCAD — getfiled never shown	NEW	`while (= acaddir curdir)` false when curdir=My Documents. User clicks Existing Project, nothing happens. Fix: force curdir=“” before loop.
98	—	Silent failure: `(exit)` in project() terminates call chain with no diagnostic output	—	Pre-existing code debt. `(exit)` aborts c:csv entirely if dialog load fails. Fix: replaced with error msg + clean bail-out.
99	—	Silent failure: no error handler in c:csv — all errors abort silently	—	Pre-existing code debt. Fix: added error handler with [CSV-ERROR] output + sysvar restore.
100	38	Panel data initialization assumed for all mp_dlg entry paths — panatt blocks new drawings	NEW	panatt guard fires on pnl=“new” because no XRecord exists yet. Downstream wclist crashes on nil file. Fix: skip panatt for new drawings, use convert. S=7 O=6 D=5 RPN=210.
101	35	VLISP runtime (`vl_u_crx`) triggers `System.ExecutionEngineException` during `coreclr_shutdown`	Yes	Autodesk bug. Crash on exit — not during CV operation. VLISP runtime calls `acedGetAcadFrame()` during .NET Core CLR teardown; managed frame already finalized. No CV code involved. Non-blocking: user data safe, crash only on exit. S=3 O=3 D=3 RPN=27.
102	13	New Drawing `pcr=T` unconditionally set — editor never launches after getfiled	Yes	progcont dispatch for 262161 always set `pcr=T` after getfiled, bypassing default routing Paths 2/4 that launch the panel/site editor. Cancel → dead end (no editor), template → dead end (file parsed but never opened). Fix: pcr stays nil; cancel → Path 2 (autonew → editor), template → Path 4 (old → scr → editor). Path 2 now respects csv_dwgtype for Panel vs Site. S=7 O=5 D=4 RPN=140.
103	40	Export naming mismatch — `cvxp-snapshot-globals` probes bare names for `csv_`-prefixed globals	NEW	`cvxpproj.lsp` probes `super`, `dprec`, `msys` etc. but `projdet_edit` stores `csv_super`, `csv_dprec`, `csv_msys`. 19 of 21 fields always export as null. S=5 O=10 D=8 RPN=400. Fix: probe `csv_`-prefixed first with bare fallback.
104	39	Project details not persisted — `projdet_edit` writes globals but never saves to XRecord or file	NEW	21 project detail values captured by `projdet_edit` exist only as volatile runtime globals. No XRecord write, no file write, no title block update. VLX has compiled persistence code absent from TB11 source. S=7 O=10 D=3 RPN=210. Fix: add `project_list` NOD dictionary with DXF 1/2/3 format.
105	41	AutoLISP text-mode `(open "r")` returns LF not CR — line reader checks only CR, lines never terminate	NEW	`csv_pjdll-read-line-bytes` checked only CR (byte 13) as line terminator. AutoLISP `(open ... "r")` is text mode on Windows, translates CRLF→LF. `read-char` returns LF (10), not CR (13). Entire file read as one garbled line → decoder returns nil → all pj.dll fields silently missing. S=7 O=8 D=4 RPN=224. Fixed: check CR OR LF.
106	42	Import gate condition triggers on wrong field — blocks pj.dll-only data import	NEW	`projdet.lsp` pj.dll import gated on `csv_contractor` empty. But `csv_read-title-block` + mp* bridge already populated contractor from drawing title block ATTRIBs. By the time pjdll import runs, contractor is non-empty → gate skips import entirely. pj.dll-exclusive fields (schedule, notes, estimator) never filled. S=7 O=8 D=5 RPN=280. Fixed: gate on pj.dll-exclusive fields instead.
107	43	First c:csv call panatt error during csv_dwgtype Tier 1 detection — `error` masks error, c:csv silently aborts	NEW	On first c:csv, Tier 1 calls `(panatt)` after fresh module load. panatt errors on uninitialized state. CSV `error` handler catches error, terminates c:csv mid-execution. `vl-catch-all-apply` sees NORMAL return (not error). progcont never cleared, csv_dwgtype stays nil. Second call works because panelvar partially set. S=7 O=7 D=6 RPN=294. Fix: wrap panatt in `vl-catch-all-apply` inside csv_dwgtype.
108	44	matl_dlg cond default clause has stray `=` operator — “too few arguments” crash	NEW	matl_dlg.lsp line 513 (x32) / 516 (x64): `((T = (set 'matcnt ...)))`. Stray `=` makes cond default evaluate `(= single-arg)` which requires 2 arguments → “too few arguments”. Fires on any material block name not matched by prior cond clauses (custom blocks). S=7 O=8 D=3 RPN=168. Fix: remove stray `=`.
109	45	`(cons)` misplaced paren — wcl default entry initialization crashes Materials List	NEW	matl_dlg.lsp line 157 (x32) / 156 (x64): `(set 'wcl (cons (list 0 ...) ) wcl)`. Closing `)` after `(list ...)` gives `cons` only 1 arg → “too few arguments”. Only triggers when wcl.txt has no key-0 entry (e.g., CSB001). Pre-existing PB11 paren bug. S=7 O=5 D=5 RPN=175.
110	46	`okcanhlp.lsp` cancel handlers missing `(done_dialog)` — 6 dialogs uncancellable	NEW	`action_tile "cancel"` overrides DCL default `(done_dialog 0)`. If callback doesn’t call `done_dialog`, dialog stays open. 6 dialogs route cancel through okcanhlp: ly, wl, nb, wd, wc, we — none called `done_dialog`. lyr_dlg has while-loop checking `pnl`, but `start_dialog` never returns → user trapped. S=7 O=8 D=3 RPN=168. Fix: add `(done_dialog)` to all 6 cancel handlers.
111	47	`(command "CMD" ...)` without dash prefix opens dialog/palette mode — arguments fall through silently	NEW	Codebase-wide class of silent failure. AutoCAD 2006–2020+ changed LAYER, INSERT, BLOCK, HATCH, ARRAY, PURGE from command-line to dialog/palette mode. `(command "CMD" args)` opens dialog, args fall through to command processor, `error` catches silently. Fix: bulk replace to `"_.-CMD"` (command-line + English + original). 117 instances across 21 files. LAYER/INSERT: both x32+x64. BLOCK/HATCH/ARRAY/PURGE: x64 only (dash variants don’t exist in AutoCAD 2000). S=7 O=9 D=4 RPN=252.
112	48	47 `(exit)` calls violated Rule 19. Fixed: 39 eliminated via if/else restructuring + precondition guards. 7 retained with `[CSV-ERROR]` diagnostics (makepan×4 database corruption guards, panatt×3 initialization guards). 1 in cv-diag.lsp (acceptable diagnostic tool).	Yes	All 47 instances addressed across both x32/x64 trees. Automated script handled 34 dialog-load patterns. Manual restructuring for csvtech (nested if/else), btch_dlg/revision (precondition wrap), SHOW.LSP (if/else). Safety-critical exits retain `(exit)` but now print `[CSV-ERROR]` diagnostics before terminating. S=5 O=2 D=3 RPN=30 (post-fix).
113	48	12 `load_dialog` calls missing error check — nil/negative return unchecked	NEW	`load_dialog` returns negative on failure. 12 call sites pass return value directly to `new_dialog` with no guard. If DCL file missing from SFSP, `new_dialog` receives garbage → crash or silent failure. S=5 O=6 D=4 RPN=120. Fix: add `(if (or (not dcl_id) (< dcl_id 0)) ...)` guard per Rule 19 pattern.
114	48	`(findfile "acad.exe")` in csv.lsp passed to `substr`/`strlen` with no nil guard	NEW	csv.lsp line 569–570: `(substr (findfile "acad.exe") 1 (- (strlen (findfile "acad.exe")) 8))`. If findfile returns nil (non-standard install, portable ACAD, broken SFSP), `strlen` crashes with “bad argument type: stringp nil”. S=5 O=3 D=3 RPN=45. Fix: guard with nil check, fall back to `(getvar "ACADPREFIX")`.
115	48	30 unguarded `(open ...)` calls — nil file handle crashes downstream `write-line`/`read-line`/`close`	Yes	30 of 39 `(open ...)` calls store result without nil check. Downstream `(write-line str f)`, `(read-line f)`, `(close f)` crash with “bad argument type: FILE nil” if open fails. Common triggers: missing curdir, read-only directory, file locked. 9 calls already guarded with `(if (set 'f (open ...))` pattern. S=5 O=5 D=5 RPN=125. Fix: wrap open+write+close blocks in `(if f (progn ...) (princ "[CSV-ERROR]"))`.
116	48	13 unguarded `(ssget ...)` calls — nil selection set passed to `command`/`sslength`/`ssname`	Yes	13 of 22 `(ssget ...)` assignments don’t check for nil. Passing nil to `(command "copy" sol ...)` or `(command "erase" sol "")` hangs AutoCAD in interactive mode. `(sslength nil)` and `(ssname nil 0)` crash with “bad argument type”. 4 critical sites fixed (finpan copy/erase, drawpan massprop). 9 low-risk deferred (mid-workflow). S=5 O=4 D=5 RPN=100.

Bug 112 — 47 `(exit)` Calls Violate Rule 19 (Silent Termination) — ✅ Fixed¶

Discovered: Static analysis sweep, April 2026
Severity: Medium (codebase-wide code debt, degrades debuggability)
Status: ✅ Fixed — 39 of 47 eliminated via restructuring, 8 retained with [CSV-ERROR] diagnostics
Symptom: When any of 47 (exit) call sites fire, the entire calling chain terminates immediately with no diagnostic output, no sysvar restoration, and no command-line error message. Debugging requires source-level tracing to determine which (exit) fired and why.
Root Cause: Legacy coding pattern. (exit) was used as a shorthand abort in AutoLISP before structured error handling was established. Per Rule 19 of the project coding standards, (exit) is banned because it “terminates the entire calling chain with no diagnostic output.”
Fix Applied (both x32 and x64):
- 34 dialog-load guards (automated via scripts/fix-exit-guards.py): (if (not (new_dialog ...)) (exit)) restructured to (if (new_dialog ...) (progn ...dialog code...) (princ "\n[CSV-ERROR] ...")) with (unload_dialog) moved outside the if/else. Files: bp_dlg, btch_dlg, calc_dlg, ch_dlg, dl_dlg, dr_dlg, dwgnew, dwgold, fh_dlg, fs_dlg, fv_dlg, grid_dlg(×2), invar, lb_dlg, let_dlg, ll_dlg, md_dlg, mp_dlg, new, num_dlg, pl_dlg, pp_dlg, progopts, rb_dlg, revision, ro_dlg, sb_dlg, sd_dlg, sdwg_dlg, site_dlg, slab_dlg, slope_dlg, ss_dlg, tp_dlg, ts_dlg
- csvtech.lsp (2 exits → 0): Restructured into nested if/else — (if (>= dcl_id 0) (progn (if (new_dialog ...) (progn ...dialog...) (progn [CSV-ERROR])) (unload_dialog)) (progn [CSV-ERROR])). (setq result 0) fallback on either failure path.
- btch_dlg.lsp (1 exit → 0): Precondition guard wrap — (if (and curdir pnlname) (progn ...rest of function...)) with [CSV-ERROR] diagnostic on nil guard.
- revision.lsp (1 exit → 0): Precondition guard wrap — (if (and (boundp 'rev) rev (numberp rev) ...) (progn ...)) with [CSV-ERROR] diagnostic.
- SHOW.LSP (1 exit → 0): Restructured to (if (new_dialog ...) (progn ...dialog code...) (progn [CSV-ERROR] (unload_dialog))).
- makepan.LSP (4 exits RETAINED): Safety-critical database corruption guards. (exit) kept as protection against corrupted data propagation. [CSV-ERROR] diagnostics added before each exit: “database integrity check failed”, “version mismatch”, “project name mismatch”, “panel not found”.
- panatt.lsp (3 exits RETAINED): Initialization guard exits in error handler restoration blocks. (exit) kept as the outer guard of last resort. [CSV-ERROR] diagnostics added: “no panel data in drawing”, “panel dimension init failed”, “project path not determined”.
- cv-diag.lsp (1 exit): Diagnostic tool — acceptable, not a bug.
Final Count: 8 remaining (exit) calls across both trees (7 with diagnostics + 1 diagnostic tool). Down from 47 original.
Impact: Eliminates the largest class of silent failure in the codebase. Every future debugging session saved by diagnostic output pays back the refactoring cost.
DFMEA Reference: DFMEA-048 (RPN 315 → 30 post-fix)

Bug 113 — 12 Unguarded `load_dialog` Calls¶

Discovered: Static analysis sweep, April 2026
Severity: Medium (crash on missing DCL file)
Symptom: If a .dcl file is missing from the Support File Search Path, load_dialog returns a negative value. The 12 unguarded call sites pass this directly to new_dialog, which either crashes or produces undefined behavior. Combined with Bug 112 (the new_dialog nil check → (exit) pattern), the net effect is still silent termination — but these 12 don’t even get that far.
Root Cause: Inconsistent error checking. 34 load_dialog call sites DO check the return value (via new_dialog nil check). These 12 were missed.
Affected Files (all in both x32 and x64):
1. dwgnew.lsp:113 — dwgtype.dcl
2. lyr_dlg.lsp:92 — lyr_dlg.dcl
3. nb_dlg.lsp:84 — nb_dlg.dcl
4. plt.lsp:210 — plt_dlg.dcl
5. project.lsp:57 — project.dcl
6. project.lsp:95 — new.dcl
7. project.lsp:104 — new.dcl
8. wall_dlg.lsp:469 — wall_dlg.dcl
9. warning.lsp:15 — warning.dcl
10. wc_dlg.lsp:45 — wc_dlg.dcl
11. wc_edit.lsp:133 — wc_edit.dcl
12. wd_dlg.lsp:42 — wd_dlg.dcl

Fix: Add guard per Rule 19 pattern:

(set 'dcl_id (load_dialog "xxx.dcl"))
(if (or (not dcl_id) (< dcl_id 0))
  (progn
    (princ "\n[CSV-ERROR] xxx.dcl failed to load")
    (princ (strcat "\n  findfile: " (if (findfile "xxx.dcl") "found" "NOT FOUND")))
    (set 'pcr T)
  )
  (progn
    ;; ... existing dialog flow ...
  )
)

DFMEA Reference: DFMEA-048 (RPN 120)

Bug 114 — Unguarded `findfile "acad.exe"` in csv.lsp¶

Discovered: Static analysis sweep, April 2026
Severity: Medium (crash on non-standard AutoCAD install)
Symptom: csv.lsp line 569–570 calls (findfile "acad.exe") twice and passes the result directly to (strlen ...) and (substr ...). If findfile returns nil (portable AutoCAD, broken SFSP, sandboxed install), both strlen and substr crash with bad argument type: stringp nil.
Root Cause: Assumed acad.exe is always findable via AutoCAD’s Support File Search Path. This is true for standard installations but not guaranteed.
Fix: Store findfile result in acad_path, guard for nil, print [CSV-ERROR] diagnostic, set acaddir to empty string fallback. Preserves original substr/strlen arithmetic on the happy path. Also eliminates the double findfile call (was called twice — once for substr, once for strlen):
```
(set 'acad_path (findfile "acad.exe"))
(if acad_path
  (set 'acaddir
    (substr acad_path 1
      (- (strlen acad_path) 8)
    )
  )
  (progn
    (princ "\n[CSV-ERROR] acad.exe not found in search path")
    (set 'acaddir "")
  )
)
```
Applied to both x64 and x32 csv.lsp.
DFMEA Reference: DFMEA-048 (RPN 45)

Bug 115 — 30 Unguarded `(open ...)` Calls — File I/O Crash Risk¶

Discovered: Static analysis sweep, April 2026
Severity: Medium (crash on file access failure — missing directory, locked file, read-only path)
Status: ✅ Fixed (high-risk sites) — 13/30 unguarded opens guarded in both x32 and x64. Remaining 17 are low-risk (log files, diagnostic tools, already-guarded-at-runtime).
Symptom: 30 of 39 (open ...) calls store the file handle without checking for nil. Downstream (write-line str f), (read-line f), and (close f) crash with bad argument type: FILE nil if open returns nil. Common triggers: curdir is nil/empty, target directory doesn’t exist, file is locked by another process, read-mode on file that was never created.
Root Cause: AutoLISP’s open function returns nil (not an error) when a file can’t be opened. Code assumes successful open without checking.
Affected Files (30 unguarded, 9 guarded):
- Already guarded (9): drread:104, engimp:104, makepan:88, matl_dlg:140, mbread:103, panatt:778, panatt:843, updvar:669, wsbread:103
- Fixed — high-risk write-mode (12): centgrav:307✅, drawpan:545✅, dreng:309✅, inspanel:139✅, inspanel:504✅, makepan:146✅, matl_dlg:567✅, mbeng:444✅, savelay:65✅, updvar:114✅, updvar:644✅, updvar:691✅, wsbeng:311✅
- Already guarded at runtime (1): panatt:819 — has (if f (progn ... (close f))) in source
- Low-risk / deferred (17): csv:428/463/496/549 (log files), csv:586/607/1239 (log files), csvdebug:23 (diagnostic), csvtech:333 (diagnostic), btch:73, scr:142, wclist:76, layout:246 (read), pjdll:347/528 (read), tiltup:32 (read)
- Special fix — makepan:146: Replaced infinite (while (not f) ...) busy-wait loop with single open + if guard. The original loop would spin forever on invalid paths.
Fix Pattern: Wrap open→write→close blocks in (if f (progn ...write-line...close...) (princ "\n[CSV-ERROR] cannot open ...")). AutoLISP has no return, so the entire downstream block must be inside the guard.
DFMEA Reference: DFMEA-048 (RPN 125)

Bug 116 — 13 Unguarded `(ssget ...)` Calls — Nil Selection Set Crash Risk¶

Discovered: Static analysis sweep, April 2026
Severity: Medium (crash or hang if no matching entities found)
Status: ✅ Fixed (critical sites) — 4 high-risk sites guarded in both x32 and x64. 9 low-risk deferred.
Symptom: ssget returns nil when no entities match the filter. Passing nil to (command "copy" sol ...), (command "erase" sol ...), (sslength nil), or (ssname nil 0) causes crashes (bad argument type: ENAME nil) or hangs (AutoCAD enters interactive selection mode waiting for user input).
Root Cause: AutoLISP’s ssget returns nil (not empty set) when no entities match. Code assumes entities always exist.
Affected Files (13 unguarded, 9 guarded):
- Already guarded (9): csv_diag:292, drawpan:392/423/528, grid_dlg:67, matl_dlg:181, slab_dlg:63, titleblk:79, wall_dlg:51
- Fixed — critical (4 sites): finpan:303✅ (copy/erase 3DSOLID), finpan:310✅ (copy/erase INSERT), finpan:290✅ (rotate PERIMETER), drawpan:541✅ (massprop script with ssname)
- Low-risk / deferred (9): drawpan:233/283/372/401/416/484/499/511, finpan:213 — mid-workflow selections where entities should always exist (just created by preceding commands)
Fix Pattern: (if sol (progn (command "copy" sol ...) (command "erase" sol "")) (princ "\n[CSV-ERROR] ..."))
DFMEA Reference: DFMEA-048 (RPN 125)

Bug 121 — `DIMUNIT` Deprecated — Dimension Text Shows Integer Inches Instead of Architectural Fractions¶

Discovered: April 2026, main-panel parity test (GUI comparison vs golden)
Severity: High — panel width and other span dimensions display with wrong precision (e.g., 23' 7" instead of 23' 6-3/4"), corrupting panel drawings used for fabrication
Status: ✅ Fixed — drawdim.lsp entry block, commit pending
Symptom: Dimension entities on perimeter_dim and other *_dim layers display measurements in integer inches only. CSB001 panel width of 282.75” displayed as 23' 7" (rounded to nearest inch) instead of 23' 6-3/4" (correct 1/4” precision).
Root Cause: DIMUNIT was the AutoCAD 2000 system variable for dimension unit format. It was superseded by DIMLUNIT in AutoCAD 2004 and is now read-only/ignored in AutoCAD 2026. TB11’s drawdim.lsp set (setvar "dimunit" 6) (legacy Windows Desktop units) but never set DIMLUNIT or DIMDEC. In AutoCAD 2026, the DIMENSION entity format is controlled entirely by DIMLUNIT (set to whatever the current drawing/DIMSTYLE uses) and DIMDEC (precision denominator). Without explicit architectural settings, DIMLINEAR dimensions defaulted to decimal/integer output. PB11 (golden) used DIM1 + DIMASSOC=0, which formatted text via (rtos val 4 N) in LISP — the format was computed and embedded as a text string, bypassing DIMSTYLE entirely.

Fix: Added to drawdim.lsp entry block:

(setvar "dimzin" 8)   ; suppress trailing zeros in fractional inches
(setvar "dimlunit" 4) ; architectural: feet and fractional inches
(setvar "dimdec" 2)   ; 1/4" precision (2^2 = 4 denominator)

DFMEA Reference: DFMEA-049 (RPN 315 pre-fix)

Bug 122 — `finpan.lsp` Second `drawdim` Call Crashes with `consp "()"` in Main-Panel-Only Mode¶

Discovered: April 2026, during main-panel parity mode development
Severity: Medium — crashes finpan before title/border insert in test mode; no production code path impact
Status: ✅ Fixed — finpan.lsp multi-item perimeter block skipped in csv_main_only mode
Symptom: bad argument type: consp "()" error fires immediately after [DD-ENTRY] after layer-on. finpan aborts before Phase 5 (title/border insert). TITLE and BORDER blocks missing from drawing.
Root Cause: In csv_main_only=T mode, the multi-item perimeter drawdim pass was reduced from 10 items to a single-item list '("mpvar"). The first (drawdim (list "mpvar")) call succeeded (single-item path). The second call with '("mpvar") hit the same single-item path but the tier accumulators (x0lst, x1lst, etc.) were already consumed/modified by the first call, causing an internal consp nil reference. In normal production mode, this pass always has 10 items (nlst=10), taking the multi-item while-loop path which is idempotent.
Fix: Wrapped the entire multi-item perimeter block in (if (not csv_main_only) ...). In main-only mode, the first single-item drawdim call handles solid-body dimensions; the second pass (for ELEV markers and opening spans) is not needed.
DFMEA Reference: DFMEA-048 (unguarded API return values / error handling class)

Bug 123 — Right-side TOC marker duplicated by RL fallback at panel-top elevation¶

Discovered: May 5, 2026, during elevation-marker post-mortem session
Severity: High — visible defect on every panel where csv_rl_elev_r was unbound (the new fallback set it equal to csv_rl_elev_l)
Status: ✅ Fixed — dd-elev-flush filters dd-r-acc to drop entries equal to (cadr p3) so PP/RL at panel-top can no longer co-locate with the TOC structural marker.
Symptom: Two ELEV INSERTs at y=310 on the right side: one on perimeter_dim (the legitimate TOC), one on connections_dim (a PP/WC entry whose accumulator value matched panel-top). Visual: two overlapping circles at the top-right.
Root Cause: The y1lst PP-elevation pass and the y2lst WC-elevation pass appended to dd-r-acc without any “drop panel-top duplicates” filter. The pre-existing filter inside the dd-el-drawn block ran for FS/RL/DL/PL but not for the WC/PP path.
Fix: (a) y1lst filter step inside drawdim’s elevmrkr drops values equal to (cadr p3) and (cadr p1) before consing onto dd-r-acc; (b) dd-elev-flush filters again before dd-elev-multi runs, with a special case keeping the TOC entry that flush itself adds.
DFMEA Reference: DFMEA-054 (cross-pass tracker reset) — the underlying issue was that markers from different drawdim passes couldn’t see each other.
Cross-reference: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor

Bug 124 — WC at 19’-11½″ stacked on top of RL at 21’-8″ (cross-pass marker collision)¶

Discovered: May 5, 2026
Severity: High — illegible labels on every panel with both RL and WC at close elevations on the right side
Status: ✅ Fixed — moved accumulators and stagger trackers from per-elevmrkr-call scope to panel scope; new dd-elev-flush drains them once after all drawdim passes complete.
Symptom: Right-side cluster (RL 21’-8″, WC 21’-10½″, FS 21’-0″, WC 19’-11½″) collapsed within ~0.5″. Labels overlapped illegibly.
Root Cause: elevmrkr reset dd-cy-l / dd-cy-r to -99999 at function entry. finpan calls drawdim six times per panel; each call’s elevmrkr couldn’t see prior calls’ marker positions and staggered into the same y-band.
Fix: (a) dd-l-acc / dd-r-acc accumulators reset only by finpan (panel scope, not call scope); (b) elevmrkr accumulates only — does not draw immediately; (c) new dd-elev-flush (called from finpan after the last drawdim pass) sorts both accumulators ascending and runs a single unified dd-elev-multi stagger pass; (d) added y2lst ascending sort so WC at 239.5 cannot be staggered above WC at 262.5 if the latter happens to be processed first.
DFMEA Reference: DFMEA-054 (RPN 280)
Cross-reference: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor

Bug 125 — Snake-tongue artifact: `dim1` arrow tail penetrates ELEV circle on staggered markers¶

Discovered: May 5, 2026
Severity: Medium — visible on every right-side staggered marker
Status: ✅ Fixed — dd-marker-l / dd-marker-r rewrote to entmake SOLID + 3 LINEs + INSERT ELEV + MTEXT directly; no more dim1 calls per marker.
Symptom: Horizontal line passing through the ELEV circle from inside out, only visible on staggered markers (e.g. WC at +11.5″ stagger). Non-staggered markers looked fine, masking the bug for months.
Root Cause: With DIMASSOC=0 + dimblk1=elev + arg1/arg2 0.001 apart, dim1 emits a horizontal “tail” past the ELEV block. The tail length is dimasz on each side; with near-coincident defpoints it overshoots in opposite directions. With DIMASSOC=0 the result becomes a raw LINE in model space — no managed dim entity to clean up.
Fix: Replaced the csv_dim1 + dd-fixmtext-x pair inside dd-marker-l/r with explicit entmake of the four geometry primitives. The continuous through-line from xbnd to MTEXT-anchor is drawn as one LINE; the ELEV INSERT block visually masks the segment crossing the circle.
DFMEA Reference: DFMEA-053 (RPN 210)
Cross-reference: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor

Bug 126 — `\X` rendering literally in entmake’d MTEXT after switching off dim1¶

Discovered: May 5, 2026 (immediately after Bug 125 fix)
Severity: High — every marker label showed \Xwc, \XRL, \XFS etc. as literal text instead of stacked above/below
Status: ✅ Fixed — dd-sfx switched to use \P (paragraph break, universal MTEXT) instead of \X (dim-text only)
Symptom: Labels read literally e.g. 21'-10 1/2"\Xwc instead of 21'-10 1/2" (line 1) / wc (line 2 at 70% height).
Root Cause: \X is a DIMENSION-text-only formatting code that splits text above/below the dim line. It is processed when MTEXT is created by the dim1 command in dim context. When MTEXT is created via plain entmake (post-Bug-125 refactor), \X is not interpreted — it renders literally. \P (paragraph break) is the universal MTEXT line-break that works in both dim and plain contexts.
Fix: Changed (defun dd-sfx (lbl) (strcat "\\X" dd-sfx-h lbl)) to (strcat "\\P" dd-sfx-h lbl). The \H0.7x; height directive still applies to the suffix (line 2 at 70% size).
DFMEA Reference: DFMEA-053 (cascading from the dim1 bypass)
Cross-reference: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor

Bug 127 — Right-side ELEV circles tiny after entmake refactor (asymmetric scale fix)¶

Discovered: May 5, 2026 (third regression in the same Bug 125/126 chain)
Severity: High — every right-side marker showed a barely-visible 1-unit circle while left-side markers showed correct 3.33-unit circles
Status: ✅ Fixed — both dd-marker-l and dd-marker-r use dd-em-da (= dimasz) for ELEV INSERT scale group codes 41/42/43.
Symptom: Right-side circles ~10× smaller than left-side circles. User-visible “snake-tongue gone but circles tiny”.
Root Cause: When converting from csv_dim1 to direct entmake INSERT, scale was hardcoded to 1.0 in both helper functions. A subsequent replace_all Edit fixed the dd-marker-l line (matched the unique dd-em-x1l token), but the dd-marker-r line had dd-em-x1r and was identical-after-replace so the second Edit no-op’d. Asymmetry survived several test cycles.
Fix: Applied a targeted Edit to the dd-marker-r ELEV INSERT block specifically, replacing scale 1.0 with dd-em-da.
Lesson: replace_all only replaces exact matches. When two near-mirror code blocks need the same edit, edit each explicitly or factor the duplication out. This is the kind of asymmetric-edit hazard issue #151 is tracking.
DFMEA Reference: Internal regression during DFMEA-053 fix.
Cross-reference: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor

Bug 128 — `cv-gui-draw.lsp` silently loaded stale `drawdim.lsp` from AutoCAD’s default SFSP¶

Discovered: May 5, 2026
Severity: High — invisible: GUI test ran successfully but did not exercise the code under edit
Status: ✅ Fixed — cv-gui-draw.lsp load loop now uses absolute-path loading ((load (strcat cv-base m ".lsp"))), matching cv-auto-draw.lsp.
Symptom: Edits to src/x64/TB11-01x64/drawdim.lsp had no effect in the GUI test for ~hours of debugging. Headless test (cv-auto-draw) saw the changes correctly.
Root Cause: cv-gui-draw.lsp used (load m) (short name) inside its module load loop. AutoLISP load calls findfile which searches the in-memory SFSP. (setenv "ACAD" ...) updates the registry but not the in-memory SFSP for the running session, so the prepended cv-base had no effect. AutoCAD resolved short names against its default support path, which had a stale copy of drawdim.lsp. Production (csv.lsp) and cv-auto-draw.lsp (headless) didn’t hit this because production is single-rooted and headless used absolute-path loading.
Fix: Changed the cv-gui-draw.lsp load loop to (load (strcat cv-base m ".lsp")), matching the cv-auto-draw.lsp pattern. After this fix, every code change is reflected in both the headless DXF parity test and the GUI visual confirmation step.
DFMEA Reference: DFMEA-050 (RPN 336) — load-path divergence between production / headless / GUI loaders
Cross-reference: Post-Mortem — Elevation Marker / Dimension Pipeline Refactor, R26 in Risk Register (2026)

Bug 131 — At-panel HATCH duplicates on FEATURE layer (residual after Bug 129 fix)¶

Discovered: May 5, 2026 (after Bug 129 fix landed)
Severity: Medium — DXF entity bloat, invisible in GUI
Status: ✅ Fixed — Phase 3 dedupe landed in 15d83a98f
Symptom: Test DXF has 15 HATCHes on FEATURE layer vs golden’s 5 — a +10 delta. Off-panel detector at scripts/cv-find-offpanel-entities.py does NOT flag them; both copies of each duplicate sit at on-panel bboxes (positive-x, within panel bounds). User cannot see them in the GUI because they exactly overlap the visible HATCH.
Root Cause: EXPLODE on a 3D feature solid yields multiple coplanar regions per face. Bug 129 cleanup deleted the obvious mirror copies (negative-x bbox), but coplanar front-face / back-face regions project to the same on-panel bbox after UCS rotation, and the bulk-hatch loop hatches every surviving region without dedupe. Result: every visible feature HATCH has a near-perfect duplicate on top of it.
Fix: Phase 3 — post-explode-and-hatch dedupe pass in drawpan.lsp hashes each FEATURE-layer HATCH by (bbox + vertex count + pattern name) and entdels duplicates. CSB001 now produces 5 HATCH/feature, matching golden.
DFMEA Reference: DFMEA-058 (RPN 168 → ~84 after Detection drop) — on-panel HATCH duplicates
GH Issue: #175 (legacy), #177 (active tracker)

Bug 132 — WC dim path missing 2 LEADER entities on `connections_dim` layer¶

Discovered: May 5, 2026
Severity: Medium — visual indicator missing for clarity in tight / angled regions
Status: ✅ Fixed — Phase 4 LEADER + slot-9 leader-angle flip landed in d73e3aab8 + 0a28b287d + 7786f0b25
Symptom: Test DXF has 0 LEADER entities on connections_dim layer; golden has 2 LEADERs. CSB001 has weld connections at y = 0, 88, 155, 239.5, 262.5; two of these need angled leader lines connecting their label (placed in the elevation column) to the actual connection point on the panel face. In the test output the WC label sits in the elevation column with no line drawn back to the connection.
Root Cause: wcvar single-item branch in drawdim.lsp emitted ELEV markers and MTEXT but never invoked the csv_dim1 "leader" subtype that PB11/golden uses for single-insert WCs. AC2027’s deprecation of the DIM1 “leader” subcommand also meant a direct port produced only the MTEXT half (no LEADER entity).
Fix: Phase 4 emits LEADER + MTEXT directly via entmake in the wcvar single-insert branch. Slot-9 leader-angle flip (panel-half heuristic) eliminates the snaketongue fork on slots near the panel right edge in the lower half. CSB001 now produces 2 LEADER/connections_dim, matching golden.
DFMEA Reference: DFMEA-059 (RPN 150 → ~90 after Detection drop) — WC dim missing LEADER
GH Issue: #176 (legacy), #178 (active tracker)

Bug 133 — panatt pp/bp schema-variance decoder failure¶

Discovered: May 2026 (during CSB002/CSB003 parity work)
Severity: High — wrong PP/BP placement in fabricator panel book if schema isn’t detected correctly
Status: ✅ Fixed — universal last-element activation flag + pos0-based Y-formula schema detection
Symptom: PP/BP markers on CSB002 and CSB003 appeared at wrong y-coordinates, or were missing entirely. CSB001 used a manual-placement schema (pos0=2 / pos0=1) where pos1 = mpl1 - actual_y; CSB002+ panels used an auto-placement schema (pos0=0) where pos1 = actual_y directly. The original decoder only handled CSB001’s schema, so CSB002+ panels showed PP/BP at mirrored positions.
Root Cause: Two NOD XRecord schemas exist in the wild for pp/bp section rows. The original decoder hardcoded CSB001’s pos1 = mpl1 - y inversion. When CSB002 was added to the test corpus, the inversion produced negative or mirrored y-values for its rows. Activation was also schema-dependent: CSB001 used row-position markers (pos0 = 2 or 1) while CSB002+ used a universal last-element-of-row=1 flag.
Fix: Two-part decoder rewrite. (1) Activation: changed predicate to “last element of row equals 1” — works on both schemas. (2) Y-position: switch on pos0 — pos0 != 0 → mpl1 - pos1 (CSB001 schema), pos0 = 0 → pos1 (CSB002+ schema). All three CSB panels now decode correctly.
DFMEA Reference: DFMEA-060 (RPN 280) — pp/bp schema-variance decoder failure
Closing commits: 5b45a64ea, 263bc5457, 786501ff9

Bug 134 — wcvar narrow-dim leader snaketongue¶

Discovered: May 2026 (CSB003 slot 9 GUI inspection)
Severity: Low — visual artifact, not measurement error
Status: ✅ Fixed — leader-angle heuristic by panel-half
Symptom: Lower-half right-side WC slots (e.g., CSB003 slot 9 at y=155) rendered with a “snaketongue” fork: the X-edge dim’s auto-placed text floated up above the dim line (DIMTAD=1 + DIMTIX=0 on a narrow ~3.5” dim), while the WC annotation leader pointed down-left at 210° to a label below the dim line. Two labels on opposite sides of the dim line, looking like a fork around it.
Root Cause: Fixed leader angle of 210° (R-side) was correct for upper-half slots — they need to clear the PP/BP dim band that lives near the panel top. But on lower-half slots, where there’s no PP/BP band below, that downward tilt produced the fork against the dim text floating above.
Fix: Tilt the wcvar single-insert leader UP (150° R / 30° L) when the slot’s cy < mpl1/2, DOWN (210° R / 330° L) when cy >= mpl1/2. Slot 9 leader endpoint moved from (255.769, 147) to (255.769, 163), within 1.3” of the dim text at y=164.27 — both labels now read as a single cluster above the dim line.
DFMEA Reference: DFMEA-061 (RPN 180) — narrow-dim auto-leader snaketongue
Closing commits: 7786f0b25

Bug 135 — csv_dim1 leader unwanted shoulder/hook line¶

Discovered: May 2026 (during slot 33 CSB001 PP collision investigation)
Severity: Low — visual clutter, not measurement error
Status: ✅ Fixed — bypassed csv_dim1 “leader” with direct entmake LEADER + MTEXT
Symptom: WC annotation leaders had a stray ~22” horizontal LINE extending beyond the leader tip, originally intended to underline the text. On CSB001 slot 33, that shoulder collided with the PP at x=223.75. AC2027 also deprecated DIM1 LEADER entirely, so a direct port produced only the MTEXT half — neither a clean leader nor the original shoulder.
Root Cause: csv_dim1 with the “leader” subtype wraps DIM1 LEADER which historically appended a horizontal annotation shoulder to underline the text. This was visual clutter on tightly clustered embeds, and the AC2027 deprecation broke even the partial behavior.
Fix: Replace csv_dim1 “leader” calls in wcvar with direct (entmake (list '(0 . "LEADER") ...)) for the leader plus (entmake (list '(0 . "MTEXT") ...)) at the leader tip. Use attachment 71=4 (Middle-Left) for L-side / 6 (Middle-Right) for R-side. Single MTEXT at tip, no shoulder.
DFMEA Reference: DFMEA-062 (RPN 168) — csv_dim1 leader unwanted shoulder/hook
Closing commits: 70af07115, 9c5ac9da2

Bug 136 — AC2027 entlast returns rendered MTEXT not DIMENSION (latent)¶

Discovered: May 2026 (during Phase 4 wcvar X-edge dim work)
Severity: Medium — silent failure mode; latent in current code (no active path hits it post Phase 4) but high RPN because future code might
Status: ⚠️ Latent — current code bypasses the entmod-on-entlast pattern entirely; documented for future maintainers
Symptom: Phantom “diagonal leader with no label” near narrow X-edge dims. The wcvar code intended to override the DIMENSION’s group 11 (text-mid override) via (entmod (entlast)) after csv_dim1, but in AC2027 with DIMASSOC=0 the dim is decomposed into multiple entities; (entlast) returns the rendered MTEXT, not the DIMENSION metadata. The entmod silently modified the MTEXT’s group-11 (x-axis direction vector for the text), producing a leader-shaped artifact pointing at empty space where the text wasn’t.
Root Cause: AC2024+ changed how DIMASSOC=0 dimensions are decomposed. PB11 / older AC kept the DIMENSION entity as entlast after rendering. AC2027 flattens the DIMENSION block — the rendered MTEXT becomes entlast while the DIMENSION metadata is preserved further back in the entity table.
Fix: Removed all (entmod (entlast)) calls from the wcvar X-edge dim path. Text relocation is now done at csv_dim1 creation time (group 11 supplied as third argument) or skipped entirely (let DIMTAD do its job).
DFMEA Reference: DFMEA-063 (RPN 336) — AC2027 entlast returns rendered MTEXT not DIMENSION
Closing commits: Encountered during Phase 4 (70af07115 etc.); current code path no longer relies on (entlast) returning DIMENSION. Logged as latent because any future code re-introducing the pattern will silently fail.

Bug 137 — WC silent-drop on missing wcl.txt entry¶

Discovered: May 7, 2026 (59-panel CSB corpus sweep)
Severity: High — silent loss of weld-connection inserts in customer panel books; fabricator may not realize the WC was meant to be there
Status: ✅ Fixed — A6 source-code fallback landed in 1c613c30 (most-common-WC fallback + RED block + on-drawing warning TEXT + CLI [CSV-WARN])
Symptom: WC blocks (WC10/WC20/WC30/WC40/WC50/WC70/WC80/WC90 etc.) silently fail to draw on panels that reference WC types absent from the project’s wcl.txt. The 59-panel CSB sweep showed 56 of 59 panels affected, with worst-case CSB022 dropping 14 WC inserts (entire WC stack collapsed). The single-panel CSB001 baseline didn’t expose this because CSB001 only uses types covered by the wcl entries.
Reproducer: Run-BatchParity.ps1 -Panels CSB013 — pre-DXF has 11 INSERT on connections layer (WC40/WC50), post-snap has 3. Diff reports/batch-parity/CSB013-pre.dxf vs CSB013-snap.dxf shows 9 missing WC INSERTs + ~34 missing connections_dim entities.
Root Cause: weldconn.lsp:680 gates WC draw on (if (and (> x14 0) (assoc x14 wcl)) ...). When the WC type isn’t in wcl, the gate fails and the WC silently drops. The gate exists to prevent placecon from nil-dereffing on (nth N (assoc x14 wcl)) — so the gate is correct as a crash guard but accidentally drops legitimate types missing from the project’s wcl.txt.
User context (2026-05-07): In production this is testism — the dialog has no missing-type option for current customers, so users selecting from the dialog can’t trigger it. Only legacy file up-conversion can fire the bug, and few customers have legacy files. Defensive fix is still required for legacy migration safety + future-proofing.
Tactical Fix (test fixture): Expanded wcl.txt fixture in Run-BatchParity.ps1 to cover all 13 WC types in the CSB corpus (commit 322c6133d). This makes the headless test valid against actual panel data but does NOT fix production behavior — customers with sparse wcl.txt files still hit the silent-drop bug.
Production Fix (design locked, A6): Source-code fallback at weldconn.lsp:680. When type missing:
1. Fall through to the most-common WC type already present on this panel (NOT wcl key-0 default — blank geometry hides the issue in the drawing).
2. Force RED color (color 1) on the fallback INSERT and its dim entities, overriding BYLAYER inheritance.
3. Emit an on-drawing warning TEXT near the panel: WARNING: WC slot K — type N not in catalog; using <fallback> as placeholder (RED, larger than normal annotation, one TEXT per missing-type occurrence).
4. Print [CSV-WARN] WC type N not in wcl.txt; using <fallback> as placeholder for slot K to CLI.
Rejected alternatives: fall-through-to-blank (hides risk in drawing); hard-error skip-the-slot (fabricator may not notice CLI message); default to a globally-configured shop standard (adds another text-file).
Strategic Fix: Replace per-project wcl.txt with a structured global catalog (SQLite / JSON registry / cv-web data layer / XData library). See plan §“Catalog data must move out of text files”.
DFMEA Reference: DFMEA-066 (RPN 576) — top remaining engineering risk
GH Issue: #179

Bug 138 — WC summary table inflation (RETRACTED — misdiagnosis)¶

Discovered: May 7, 2026 (post-fixture re-sweep)
Status: ❌ RETRACTED 2026-05-07 — hypothesis disproved by entity diff investigation
Original symptom: Every panel that draws the WC summary table appeared to inflate by ~+34 entities; 15 panels sign-flipped from negative to positive delta with mean shift +34 after fixture expansion.
Investigation that disproved it: CSB005 entity diff showed TEXT/connections_dim went from 27 to 16 (FEWER table rows post-fix). CSB046 confirmed same direction (28 → 16). The +51 shift on CSB046–049 was composite, not table-related:
- +63 perimeter LINE (title block exploded — accepted-deviation #170/171/174)
- −25 ATTRIB layer 0 (title block ATTRIBs — same)
- +28 feature_dim entities (Phase 5 layer-routing fix now emitting where pre-DXF had nothing)
- −39 connections_dim (Phase 4 LEADER + consolidation)
Root cause of the inflation that wasn’t: The pre-DXF baselines for CSB046–049 were captured before Phase 1-9 fixes landed. Post-fix entity counts differ from pre-fix by definition. The “table inflation” framing missed this — the generator at weldconn.lsp:1004-1037 already filters via (ssget "x") and (if (> _wc_cnt 0) ...).
Real finding moved to: DFMEA-068 — pre-DXF baseline staleness. Parity sweep deltas conflate “real bug” with “fix applied since baseline”.
DFMEA Reference: DFMEA-067 retracted; see DFMEA-068 instead.
GH Issue: #180 (to be closed with retraction comment)

Bug 145 — WC L-side multi-insert ignores wcm + RL boundary¶

Discovered: May 7, 2026 (CSB022 second GUI walkthrough by user)
Severity: High — WC inserts span full panel instead of staying on their roofline; entity bloat + visual confusion
Status: ✅ Fixed in 1bb97a85e — weldconn L-side multi-insert path now reads wcrl_xend (RL segment cap) and wcm (count cap)
Symptom: CSB022 slot 25 (wcd=12.25, wcsp=30, wcm=2, wce=“Roof Line”) on the lower RL produced 9 WC50 inserts spanning x=12 to x=252 (full panel). User: “the weld connections you have on the lower roofline were suppose to stop at the end of that roof but spanned the whole panel … there should have only been 2”
Root cause: L-side multi-insert loop in weldconn.lsp:821 used (car p4) — panel right — as the cap unconditionally. R-side path already honored wcm; L-side ignored it. When a WC references a roofline, the cap should be that segment’s x_end.
Fix:
- panatt.lsp WC-on-RL decode: store wcrl_xend<N> = the segment’s x_end (looked up from panatt_rl_list at the WC’s absolute X).
- weldconn.lsp L-side multi-insert: cap = wcrl_xend if bound, else panel right. Also honor wcm count (anchor + repeats ≤ wcm).
Verification: CSB022 slot 25 now produces 2 inserts at x=12, 42 (both within left RL x=0..60 and within wcm=2 limit).
DFMEA Reference: DFMEA-074 (RPN 192 → 64 post-fix)
GH Issue: new (to be opened with batched 145/146/147/148/149/150)

Bug 146 — WC slot 7+8 schema variance: wcd=0 edge WCs render on wrong side¶

Discovered: May 7, 2026 (CSB022 second GUI walkthrough)
Severity: High — safety-critical, fabricator installs WC on wrong panel side
Status: ⚠️ Open — schema variance under investigation
Symptom: CSB022 slot 7 (WC90, wce=12) and slot 8 (WC90, wce=174.875) render on LEFT (x=6) but VLX golden has them on RIGHT (x=277.25). User: “the weld connection you have attached to the left side of the panel (2 of them) should have been on the right.”
Suspected cause: NOD row pos3=0 (decoded as L by current schema) but rendering convention for wcd=0 edge-mount WCs may differ. May need a separate field for these slots.
Fix Plan: Identify the controlling field by comparing slot 7+8 NOD row with R-side slot examples (e.g., slot 26). Possibly an “edge-flip” or “wcd=0 implies R” convention in the original VLX.
DFMEA Reference: TBD
GH Issue: new (to be opened)

Bug 147 — WC multi-insert repeats inherit anchor Y instead of slope-interpolating¶

Discovered: May 7, 2026 (CSB022 second GUI walkthrough — diff vs pre-DXF)
Severity: Medium — visual: WCs should slope along the roofline; flat row reads wrong on the panel book
Status: ⚠️ Open — needs weldconn refactor
Symptom: CSB022 slot 26 R-side multi-insert (6 WC50s on right RL) renders all at y=342.22. Pre-DXF has them sloped: y=337.73, 338.63, 339.53, 340.43, 341.33, 342.23 (one per insert position along the slope).
Root cause: Multi-insert loop computes Y once at the anchor and reuses it for all repeats. Should call csv_resolve-rl-elev per insert with that insert’s X.
Fix Plan: In weldconn multi-insert L+R loops, recompute Y per insert when wcrl_xend is set (indicating WC is on a roofline).
DFMEA Reference: TBD
GH Issue: new (to be opened)

Bug 148 — Slot 38 (expansion-joint WC) renders 1 instead of 2 inserts¶

Discovered: May 7, 2026 (CSB022 diff analysis)
Severity: Medium — missing WC at upper RL transition; could lead to fab-install error
Status: ⚠️ Open — schema investigation needed
Symptom: CSB022 slot 38 (wcd=60, wce=“Roof Line”, offset=-6.0625, wcq=0) renders 1 WC20 at y=205.94 (lower RL boundary - 6.0625). Pre-DXF has 2 WC20s: at y=205.94 (lower RL) and y=326.94 (upper RL boundary - 6.0625). The slot is meant to draw on BOTH sides of the expansion joint.
Root cause: csv_resolve-rl-elev finds ONE matching segment (the first whose range contains x=60). Boundary x values fall under multiple segments; need a “draw on both sides” semantic.
Fix Plan: Detect boundary WCs (x_abs == segment boundary) and emit two inserts, one per adjacent segment.
DFMEA Reference: TBD
GH Issue: new (to be opened)

Bug 149 — PP X-dimensions between PPs not drawn¶

Discovered: May 7, 2026 (CSB022 second GUI walkthrough)
Severity: Medium — fabricator can’t read PP spacing without manual measurement
Status: ✅ Fixed in 6be2de2af — drawdim per-row emission via panatt_pp_list
Symptom: User: “all PP are there but they lack all x dimensions between them”. CSB022 has 8 PPs in 2 rows × 4 cols (post Bug 141 fix); golden has horizontal dimension annotations between consecutive PPs in each row.
Root cause: Legacy ppvar dispatch only sets ppt1/ppt2/ppt5/ppt6 globals (canonical 4-grid), so x8lst only ever has ≤2 unique X values regardless of how many PP columns the panel actually has. dd-plate-dim emits one shared chain across all rows, which works for 2-col panels but not 4-col panels and ignores per-row X variance.
Fix: When panatt_pp_list is bound, group PPs by Y, emit one dd-plate-dim chain per row using only that row’s X positions plus panel edges. Gated on x8lst non-nil so it only fires during the points clayer pass. CSB022 now emits 5 dims per row × 2 rows = 10 PP-row dims (Δ −26 → −22).
STANDARDS-TRACE: ACI 551R-92 §2.12.3.2 (lift-point spacing); CSB001 pre-DXF (per-row chain convention with different X per row).
DFMEA Reference: TBD (will add row for “missing PP X dim chain”)
GH Issue: new (to be opened)

Bug 150 — RL X-dimension annotation missing¶

Discovered: May 7, 2026 (CSB022 second GUI walkthrough)
Severity: Low — informational; fabricator can deduce from drawing
Status: ⚠️ Open — feature not implemented
Symptom: User: “The roof lines are missing their x dimension from the nearest panel edge so we know where one stop and the other begins.” Golden shows X-distance annotation at the roofline transition point.
Fix Plan: drawpan or drawdim addition: when panatt_rl_list has multiple segments, emit a horizontal dim from nearest panel edge to the segment-transition X.
DFMEA Reference: TBD
GH Issue: new (to be opened)

Bug 155 — Slab dowel bypass shrink under-corrects vs golden + missing adaptive spacing¶

Discovered: May 8, 2026 (CSB001 GUI ruler measurement vs golden DXF extraction)
Severity: Medium — fabricator places slab dowels in wrong positions in the bypass-end segment
Status: ✅ Fixed — final rule landed in 18773c22c (count from real panel width, spacing from available zones; 18” shrink each affected side; bypass detection unit-agnostic via gap=0 OR gap≈2×other; ceil(W/sda) count for both-bypass case). User accepted on CSB001/CSB002/CSB003/CSB004. Authoritative rule chain: e30a02d58 (placement) → 18773c22c (count rule). Per-step timeout (-PerStepTimeoutSec in Run-BatchParity, e30a02d58) added to defend against future hangs.
Symptom (CSB001 first segment, bypass at left edge mpgl=0):

Dowel

Golden

TB11

Δ

1st

27.25

16.21

−11.04

2nd

39.62

34.12

−5.50

3rd

52.00

52.04

+0.04

spacing

12.37

17.92

golden compresses, TB11 uses sda=18 raw

Trailing segment (after door, 8 dowels): TB11 spacing 17.72 vs golden 17.68 — within rounding ✅. The defect is isolated to the bypass-end first segment.
Root cause: Two issues:
1. Shrink amount: Phase 2 uses mpx1 (panel thickness, 7.25”) as the shrink. Golden’s effective shrink is ~18.25”. Rule unknown — the legacy CSV manual cites “offset by the thickness of the other corner Panel” which Phase 2 interpreted as mpx1, but golden uses something larger.
2. Adaptive spacing: Golden distributes dowels evenly within the bypass segment using a tighter pitch (12.37” for CSB001 first segment), independent of the encoded sda=18. TB11 uses sda=18 fixed throughout. The trailing segment happens to also compress (17.68 vs 18) but TB11 already implements that case correctly.
Phase 2 commit message admitted this gap: “First two still trail golden’s 27.25, 39.625 — golden’s shrink rule appears to include extra clearance beyond mpx1. Exact-match refinement deferred to Phase 7 multi-panel sweep.”
Fix Plan:
1. Reverse-engineer the shrink rule by measuring it across 3+ bypass-end panels (CSB001 + 2 others). Candidate inputs: panel thickness, slab thickness, dowel cylinder depth (sdo=24), corner clearance constant.
2. Replace fixed sda placement in dowels.lsp Phase 2 segment-based pass with adaptive even-spacing within each bypass segment (pitch ≤ sda).
STANDARDS-TRACE update needed: the existing block in dowels.lsp:323 cites “Common-Practice: offset by the thickness of the other corner Panel” — refine the citation when the actual rule is identified.
DFMEA Reference: TBD (refinement of existing Phase 2 DFMEA row)
GH Issue: new (to be opened)

Dowel	Golden	TB11	Δ
1st	27.25	16.21	−11.04
2nd	39.62	34.12	−5.50
3rd	52.00	52.04	+0.04
spacing	12.37	17.92	golden compresses, TB11 uses sda=18 raw

Bug 156 — panatt section-active predicates use position-specific heuristics; break on schema-variant panels¶

Discovered: May 8, 2026 (AABA003 GUI walkthrough — items 5, 6, 7 all root-caused to this)
Severity: High — corpus-wide false positives (drawing inactive features) AND false negatives (skipping active features) on every panel whose row schema differs from CSB001/022
Status: ⚠️ Open
Symptom on AABA003:
- WC false negative (item 7): 3 active WC rows in NOD ((0 24.0 0 0 8 0 0 0 0 0 0 8 0 1 0 0 0 0 0 1) × 3) but TB11 emits 0 WCs. Predicate at panatt.lsp:553 checks pos14 == 1. AABA003’s wc rows have 20 fields; pos14=0 (false), but the LAST field (pos19) = 1 (true). Predicate misses the activation flag.
- FS false positive (items 5, 6): 4 fs rows with last field = 0 (user disabled), but predicate at panatt.lsp:612 checks pos3 > 0. AABA003’s fs rows store y-coordinate at pos3 (e.g., 86.75) — always > 0. Every fs row falsely activates → mpfh = 1 → drawpan emits feature strips and elevation markers golden doesn’t have.
Root cause: Each section’s panatt_section_active-p branch hardcodes a specific field index. CSB001/022 happened to have row schemas where those fields aligned with the activation flag. AABA003’s 20-field WC rows and 12-field fs rows shift the activation flag to the row’s last position. The universal rule already applied to pp/bp (commit 263bc545) is last element of row = activation flag.
Fix Plan:
1. Refactor every panatt_section_active-p branch to use (= (last r) 1) instead of position-specific checks. Sections to convert: wc, fs, lt, sd, dr, dl, pl, ch, bo, so. (pp, bp already universal.)
2. Verify on CSB001 (PASS preserved), CSB022 (PASS preserved), AABA003 (3 WCs appear, fs strips disappear, B/B blue dash disappears).
3. Spot-check at least one panel from each Phase B project — schema variance may exist beyond AABA003.
Resolves user items 5, 6, 7 in one fix.
DFMEA Reference: TBD (NEW row — section-activation heuristic mismatch)
GH Issue: new (to be opened)

Bug 157 — Top plate (mptp) feature gate missing from panatt_section_toggles¶

Discovered: May 8, 2026 (AABA003 GUI walkthrough — items 1, 2, 3)
Severity: High — top plate is a structural element; missing it understates panel weight, causes wrong panel height, and drops anchor hardware
Status: ⚠️ Open
Symptom on AABA003:
- Item 1: Golden has a green top plate at the panel top with embedded anchor hardware (rebar). TB11 has neither — no plate, no anchor circles.
- Item 2: Golden panel total height = 34’9.5” (417.5”). TB11 = 34’11” (419”). Δ = 1.5”, which equals the standard top plate thickness — TB11 isn’t deducting the plate from the panel structural concrete.
- Item 3: Image #1 shows ~4 vertical-orientation WCs along the top of the panel (“2/X 7 1/4 Top Plate - 1/2 X 8 AB offset 2” @ 3’-0” o.c. Max” annotation). TB11 omits these — they’re likely the anchor-bolt circles emitted by the top-plate drawing path.
Root cause: panatt_section_toggles (panatt.lsp:508) maps known section tags → master toggles. Current entries: so, bo, dr, pl, lt, ch, fs, sd, wc, pp, bp, dl. No “tp” → “mptp” entry. Even if AABA003’s NOD has a tp section (likely; the panel clearly has top-plate data), panatt’s tag scanner doesn’t recognize it and never sets mptp = "1". The drawing path at drawpan.lsp:478 is gated (if (= mptp "1") ... (princ "skip green tpvar")) — always skips.
Fix Plan:
1. Add ("tp" . "mptp") to panatt_section_toggles.
2. Add a tp decoder branch in panatt’s per-row dispatch (line ~1818 area) — schema needs reverse-engineering from AABA003 NOD.
3. Verify green function at drawpan.lsp:481 emits the plate + anchor hardware on AABA003.
4. Verify panel structural-concrete height deducts top plate thickness (resolves item 2).
5. Verify “2/X 7 1/4 Top Plate - 1/2 X 8 AB offset…” annotation emits (resolves item 3 visible text).
Resolves user items 1, 2, 3 (top plate, panel height, roofline anchor hardware).
DFMEA Reference: TBD (NEW row — top plate feature gate)
GH Issue: new (to be opened)

Bug 158 — Non-rectangular panel polygon support (right-edge tab/extrusion)¶

Discovered: May 8, 2026 (AABA003 GUI walkthrough — item 4, image #1)
Severity: High — AABA003 has a tab extruding from the top-right corner; TB11 always renders rectangular panels. This is structural geometry, not annotation.
Status: ⚠️ Open — feature gap (not a regression)
Symptom: Image #1 shows the panel’s right side has a step/tab extrusion at the top-right corner (the panel is not a clean rectangle — the right edge has a notch or extension). TB11 renders the panel as a flush rectangle.
Root cause: Panel outline drawing in drawpan / finpan assumes rectangular geometry from mpw1 (width) and mpl1 (height). Non-rectangular panel outlines require a polygon vertex list, likely encoded in mp or in a dedicated pl (panel line) section.
Fix Plan:
1. Identify the NOD section carrying non-rectangular panel polygon vertices (candidates: mp pos14/pos15 string fields, pl section, or a not-yet-decoded section).
2. Decode the polygon vertex list in panatt.
3. Refactor panel-outline drawing to handle a generic polygon, with the rectangular case as a 4-vertex degenerate.
Note: This may be a precondition for several other projects’ panels (Smartcap, Industrial Place, etc.) that haven’t been GUI-verified yet.
DFMEA Reference: TBD (NEW row — irregular panel polygon support)
GH Issue: new (to be opened)

Bug 159 — Embed Placement Key legend missing (Up/Down face boxes + RED fallback row)¶

Discovered: May 8, 2026 (AABA003 GUI walkthrough — item 8, image #3)
Severity: Low — fabricator clarity / completeness
Status: ⚠️ Open
Symptom: Image #3 shows golden’s “Embed Placement Key” legend with two boxes: “Up [Face]” (white-fill panel orientation) and “Down [Face]” (blue-fill). TB11 omits this legend entirely. The legend should also include a RED row for the silent-drop / unknown-WC fallback (Bug 137).
Fix Plan:
1. Add legend block emission to drawdimlst or finpan title-block area: two boxes + labels.
2. Conditionally include a third RED-fill row “Unknown WC (catalog miss)” when any fallback fired during the redraw (_wc_used_fallback flag from Bug 137).
DFMEA Reference: TBD
GH Issue: new (to be opened)

Bug 160 — Drawing scale mismatch (golden 3/16 vs TB11 5/32)¶

Discovered: May 8, 2026 (AABA003 GUI walkthrough — item 9)
Severity: Informational — flag only, may not be a defect
Status: ⚠️ Open — needs investigation to determine if it’s a TB11 bug or a per-panel-discretion choice
Symptom: AABA003 golden uses 3/16 plot scale; TB11 redraw uses 5/32. CSB001 may differ as well.
Investigation plan: Check how scale is set in TB11’s redraw path. If scale is hardcoded vs panel-size-dependent, document the rule. If per-panel, verify it matches golden’s choice for AABA003.
DFMEA Reference: TBD
GH Issue: new (to be opened) once severity is confirmed

Bug 161 — Left-side panel-bottom elevation marker shows literal “\X”¶

Discovered: May 8, 2026 (CSB004 GUI walkthrough)
Severity: Medium — visible cosmetic defect on every panel’s bottom-left elevation
Status: ✅ Fixed in f8461b7a1 — stripped the trailing "\\X" from the dd-marker-l call at drawdim.lsp:3066. The right-side equivalent uses csv_dim1 (DIM entity) where \X works as a stack-text directive, but the left side uses dd-marker-l which emits plain MTEXT — and \X is a dim-text-only code that renders literally in plain MTEXT (per the comment at drawdim.lsp:173).
DFMEA Reference: TBD (NEW — silent format-code mismatch between MTEXT and DIM)
GH Issue: new (to be opened)

Bug 163 — panatt NOD decoder rejects valid rows on legacy projects¶

Discovered: May 15, 2026 (corpus sweep CV-472 + feature-gap analysis doc 49)
Severity: High — entire feature sections (windows, plates, lumber blockouts, weld connections) vanish from panel books on Lowes / Segale / Smartcap / Arlington Building A; wrong fabricator output.
Status: ✅ Largely resolved (2026-05-17 corpus sweep) — Tracks A, A.2, B, C all shipped; 17 panels recovered TIMEOUT→PASS; Lowes/Portside/Waterfall clusters now PASS. Residual scope: 4 corpus FAIL panels still need per-project NOD schema work, and EVERE016 regressed (tracked CV-477).
Track A extension (2026-05-18, commit c62b1bb8a): Universal last-elem=1 fallback added to dr/sd/so/bo/fs/dl predicates. Root cause: Waterfall-style compact-decoded rows have a LEADING NIL at position 0 ((nil 0 68.0 -8.0 1 8 94.0 40.0 1) for dr), making CSB-convention pos0 checks fail. Adding the universal last-element activation marker (already used by wc/pp/bp/pl/lt) as a fallback branch picks up these rows. Verified WATER002 gained bo (beam pockets) and dr (rough doors / future openings), snap 283 KB → 309 KB. CSB001 baseline preserved (273 entities, +5 from new bo/dr).
Symptom: [COMPACT] feature OFF: <tag> -> mp<flag> (no row passed activation predicate) for sections that DO have real data, on every panel from the affected projects. Legacy golden DXF clearly rendered the features.
Root Cause: panatt.lsp:555 panatt_section_active-p was tuned to CSB001’s NOD layout where pos0 is the per-row draw-toggle. Lowes / Segale / Smartcap / Arlington Building A panels use a different schema variant — pos0 stays 0 even on active rows; the real activation flag lives at pos3 (Lowes), in the entity geometry (Segale wcvar), or elsewhere.
Concrete case (LFC028): so row 1 = (0 198.25 228.0 1 8 48.0 0 72.0 0) — pos0=0 → predicate rejects, but pos3=1 + downstream w/h at pos5/pos7 are clearly real opening data. CSB001 same-tag row has pos3=0 with same pos0=0 → legitimately disabled; pos3 is the distinguishing signal.
Affected projects (corpus sweep CV-472): Lowes FDC Centralia (~65-69%); Segale Properties 162/P152/P161 (~18-30%); Smartcap DC North Building A/B (~28-29%); Arlington Airport Building A (~51-62%).
Fix Plan — Track A (in this commit): per-tag fallback activation branches in panatt_section_active-p. so: pos0=0 with (pos3=1 OR last-elem=1 OR pos1/2/5/7 non-zero). pl/lt: pos0=0 with real downstream data. wc: nameless-recovery already in wctypes.lsp commit 947f41b0. Each branch validated on CSB001 (must not regress to false-positives) AND on the worst panel that triggered the fallback.
Fix Plan — Track C (deferred): Schema-version sniffer at top of panatt_section_active-p — detect CSB / Lowes / Segale / Arlington variant per panel and dispatch to the right per-tag decoder. Cleans up Track A’s and-or branch sprawl.
Fix Plan — Track B (Segale-specific, deferred): wcvar NOD empty + 46 WC<n> INSERTs in entity geometry — synthesize a wcvar section from entity positions before weldconn runs.
DFMEA Reference: DFMEA-072 (NEW, RPN 432) — predicate over-strictness drops valid feature rows
GH Issue: #187
JIRA: CV-475

Bug 162 — Title block panel mark (MPPN TEXT) not centered¶

Discovered: May 8, 2026 (CSB004 GUI walkthrough — “panel mark not centered”)
Severity: Medium — visible cosmetic defect; panel ID label in the title block area renders left-justified instead of centered
Status: ⚠️ Open (committed f8461b7a1 but not yet user-verified in GUI; may need iteration on entmake group order vs (command "_.text" "_J" "_C") approach)
Symptom: Golden’s MPPN appears as ATTRIB on layer “0” with center-justified group 72=1 + group 11 alignment point. TB11’s fp-tb-tc entmake’s a TEXT entity but AutoCAD silently strips groups 7/72/11 from the output (a known TEXT-subclass quirk with the “STANDARD” style and certain group orderings). Result: TEXT renders left-justified at group 10, not centered.
Fix attempted (committed): Reorder fp-titleblock.lsp:114 entmake list to match the working “work” panel-watermark pattern — explicit AcDbEntity + AcDbText subclass markers, group 50 (rotation) before group 72, no explicit group 7.
Backup approach if entmake still fails: switch fp-tb-tc to (command "_.text" "_J" "_C" ins-pt height 0 text) which lets AutoCAD generate the entity directly.
DFMEA Reference: TBD
GH Issue: new (to be opened)

Bug 154 — Phase C deferred docket (post-Phase-B work)¶

Logged: May 8, 2026 (per user direction “defer leftover Phase C work until after Phase B”)
Severity: N/A — tracking entry, not a single bug
Status: ⏸️ Phase B + Phase D shipped 2026-05-09; docket items remain parked but re-prioritized against the 1,375-panel / Tier 2 corpus. Bug 140 (was item 5) PROMOTED out of this docket to High-priority single-fix candidate after Tier 2 sweep proved corpus-wide prevalence.
Items rolled into this docket:
1. CG (Center of Gravity) investigation — centgrav.lsp parses MASSPROP text output. DFMEA-007 (RPN 180) flagged it as fragile (relies on exact text formatting; lift-safety risk if format changes). Investigation needed: confirm AC2027 MASSPROP format matches the parser; add bounds sanity-check; consider replacing text parse with vla-getmassprop (gated by csv_is-dotnet-core). User reminder 2026-05-08: this had fallen off the active task list and must be preserved.
2. Bug 147 — WC multi-insert repeats inherit anchor Y instead of slope-interpolating (CSB022 slot 26: 6 WC50s flat at y=342.22 should slope 337.73→342.23 across the inserts).
3. Bug 150 — RL X-dimension annotation missing at the segment-transition point (informational, multi-RL panels).
4. Bug 153 — Mezzanine slab dowels run full panel width instead of starting at mezzanine boundary (CSB022 SD slot 2 + bo row 6 schema).
5. Bug 140 — PP/BP block-name truncation (catalog-architecture dependent; tied to the long-running “move catalog data out of text files” track).
6. CSB008 anomaly — Δ=−92, panatt may be dropping sections on sparse-data panels (3-feature panel, no mpdr/mpwc).
Phase C re-entry plan: After Phase B’s cross-project rollup names a focus project, re-classify each item by whether it’s still load-bearing on the new corpus or if it’s CSB-specific. Re-prioritize by Severity × prevalence in the broader corpus.
DFMEA Reference: DFMEA-007 (CG/centgrav) for item 1; per-item refs above.
GH Issue: none yet (will open per item when individually scheduled)

Bug 153 — Mezzanine slab dowels run full panel width instead of starting at mezzanine boundary¶

Discovered: May 8, 2026 (CSB022 GUI walkthrough by user)
Severity: High — wrong fabricator output; mezzanine-tier dowels appear in regions where no slab attaches
Status: ⚠️ Open — bo row 6 schema unimplemented
Symptom: User: “there are slab dowels at 11’7” that on the golden are skipped until about 4’ 9” where they begin and then flow to the right until the edge of the panel. in TB11 they aren’t skipped and run the entire x line.” CSB022 SD slot 2 at sde=139” (11’7”) is a mezzanine slab dowel row. Pre-DXF emits 38 circles starting at x=57 (4’9”); TB11 emits 46 circles starting at x=3 (full panel width). Extra 8 circles span the region where the mezzanine slab does not exist.
Schema findings:
- NOD sd row 2 (CSB022): (0 139.0 6.0 24.0 3.0 1) — pos0=0 (mezzanine flag, vs slot 1’s pos0=3 for full-floor SD), sde=139, sda=6 (spacing), sdo=24, sdi=3, active=1.
- NOD bo row 6 (CSB022): (0 0 0.0 137.0 0 72 4.0 0 54.0 0.125 0 1) — pos3=137 (Y close to 139), pos8=54.0 (mezzanine left X edge), pos9=0.125 (slab thickness), pos11=1 (active). Different schema from bo rows 1–5 (slab brace points sbvar/rbvar).
- Math validates: mezzanine left edge x=54 + sdi=3 inner buffer = 57.0 = first pre-DXF dowel x position.
Root cause: Two layers:
1. panatt.lsp does not decode bo row 6 as a mezzanine span. Currently bo only feeds sbvar/rbvar slots 1–5.
2. dowels.lsp builds x1lst as panel-full-width and intersects only with fsvar/wdvar/drvar/rovar/dlvar openings. Mezzanine span is not a known intersection target.
Fix Plan:
1. Decode bo row 6 in panatt.lsp as a mezzanine span feature (extract Y, x_left, slab_thickness, active).
2. Either (a) add a new mezvar panelvar section, or (b) pass a top-level panatt_mez_list global of (y, x_left, x_right) tuples.
3. In dowels.lsp Phase 1, when iterating sdvar slot N at y=Y_sd, look up matching mezzanine row at same Y and clip x1lst to [x_left + sdi, panel_right].
4. Use sd row pos0 as gate: pos0=0 means “mezzanine SD requiring boundary clip”; pos0=3 means “full-floor SD” (current behavior preserved).
STANDARDS-TRACE plan: TCA Guidelines or ACI for mezzanine attachment dowel placement; Common-Practice fallback to “dowels span only where slab actually attaches to panel” — CSB022 pre-DXF.
DFMEA Reference: TBD (NEW row; mezzanine slab dowel boundary clip — predicted RPN moderate)
GH Issue: new (to be opened)

Bug 142 — RL elevation decoder finds only first roofline¶

Discovered: May 7, 2026 (CSB022 GUI walkthrough by user)
Severity: High — wrong roof-line elevation for multi-roofline panels (~10’ position drift for upper RL)
Status: ✅ Fixed in a96cedb83 — panatt.lsp RL-SCAN builds panatt_rl_list (list of segments). csv_rl_elev_l/r preserved as first-segment fallback for backward compat.
Symptom: CSB022 left RL drew at 17’6 7/8” (210.875”) and right RL at 17’8” (212”) instead of golden 27’9” / 28’2”. Decoder captured only first active lt row (the left/lower roofline) and drew everything from those values.
Schema: lt-section row format pos0=x_start, pos1=elev_L, pos7=elev_R, pos8=22 (RL marker), pos11=x_end (0 = panel right), pos14=active. CSB022 has 2 active rows (rows 7+8); CSB001 has 1 (row 7).
Fix: Build panatt_rl_list of (x_start, elev_l, x_end, elev_r) tuples for ALL active RL rows.
STANDARDS-TRACE: No regulation/industry standard located for multi-segment RL configurations; falls through to PB11 common-practice (contiguous lt rows with shared x-edge).
DFMEA Reference: DFMEA-071 (RPN 224 → 96 post-fix)
GH Issue: new (to be opened)

Bug 143 — drawpan handles only one roofline¶

Discovered: May 7, 2026 (CSB022 GUI walkthrough by user)
Severity: High — fabricator panel book draws single mis-elevated line for two-roofline panels
Status: ✅ Fixed in a96cedb83 — drawpan.lsp iterates panatt_rl_list and emits one DASHED LINE per segment. Legacy single-RL fallback preserved when list is unbound.
Symptom: CSB022 user observed: “the roof line does not run the whole length of the panel but instead starts at 4’11 3/4” and end on the right edge of the panel” — single line drawn from csv_rl_elev_l to csv_rl_elev_r, both pulled from the lower roofline data.
Verification: CSB022 snap now shows two distinct DASHED lines: (0, 210.88) → (60, 212.00) and (60, 333.00) → (278.5, 338.00).
DFMEA Reference: DFMEA-072 (RPN 144 → 60 post-fix)
GH Issue: new (to be opened)

Bug 144 — WCs at roofline elevation scrambled¶

Discovered: May 7, 2026 (CSB022 GUI walkthrough by user)
Severity: High — WCs that should sit on upper RL stuck at lower RL elevation; safety-critical (welder installs at wrong height)
Status: ✅ Fixed in a96cedb83 — WC-on-RL slot decoder now calls csv_resolve-rl-elev helper with the WC’s absolute X position. Helper does per-segment lookup with linear slope interpolation.
Symptom: CSB022 user observed: “the WCs at the roofline and expansion joint were supposed to look like [image] but instead of being placed on the roofline they were just stuck at 17’11 3/8”” — all WCs with wce="Roof Line" sentinel resolved to csv_rl_elev_l + 4.5" (lower RL + offset), regardless of which segment their X position fell under.
Fix: New helper csv_resolve-rl-elev (x_abs offset) finds the RL segment whose X-extent contains x_abs, interpolates linearly between elev_L and elev_R for sloped segments, adds the offset.
Verification: CSB022 slot 26 (R-side multi-insert near right RL): wcd=12.25, anchor at x=266.5. Resolves to y=342.22 (= 333 + (266.5−60)/(279−60) × 5 + 4.5). Was previously 215.60 (lower RL + 4.5).
Limitation: Multi-insert repeats inherit the anchor’s resolved Y rather than recomputing per-insert via slope. Tracked as part of weldconn.lsp multi-insert refinement (separate fix).
DFMEA Reference: DFMEA-073 (RPN 360 → 120 post-fix)
GH Issue: new (to be opened)

Bug 141 — PP layout schema mismatch (per-row vs grid)¶

Discovered: May 7, 2026 (CSB022 GUI walkthrough by user)
Severity: High — wrong PP count and positions on most panels; safety-critical (lift hardware mispositioned)
Status: ✅ Fixed in b93381bce — explicit panatt_pp_list tuple list built in PP-DECODE; pick.lsp consumes list when bound, falls through to legacy grid loop otherwise. Both schemas handled natively. CSB001/002/003 PASS preserved; CSB022 PP count 4 → 8 with all positions matching pre-DXF exactly.
Symptom (CSB022): GUI rendering shows 4 PPs (only L-side); pre-DXF and golden show 8 PPs (4 L + 4 R, mirrored). User: “the PP would be correct except the code failed to put 4 on each line for a total of 8, and instead just put in 4 in the correct out locations”
Symptom (CSB001): GUI rendering shows 4 PPs at L=59” (lower) and L=59” (upper) but pre-DXF has L=59” (lower) and L=51.625” (upper). User-confirmed CSB001 visually as “perfect” — the 7.4” position discrepancy was missed.
Root cause: Two distinct NOD schemas in the wild, neither matches pick.lsp’s grid model:
- CSB001 schema (pos0=2, pos6=0): Each (elevation, side) row = 1 PP with its own L or R distance. L distance VARIES by elevation. 2 elevs × 2 sides = 4 PPs.
- CSB022 schema (pos0=0, pos6>0): Each (elevation, side) row encodes a set of PPs spaced by pos6 from start offset pos5. pos5=29 + pos6=78 → PPs at 29, 107 along the line.
Why pick.lsp grid model fails:
- pick.lsp iterates 4 cols × 4 rows checking ppt[c]="1" AND ppt[n]="1" and inserting at (ppd[c], ppe[n]).
- For CSB001: if L1=59 (lower elev) and L2=51.625 (upper elev) are placed in ppd1 and ppd3, pick.lsp draws PPs at all 4 (col, row) combinations including spurious (59, upper-elev) and (51.625, lower-elev).
- For CSB022: spacing-based expansion can’t be represented by 4 column-shared distances.
Fix attempt 2026-05-07 (reverted): Tried adding panatt_pp_ldist2/panatt_pp_rdist2 to capture second distinct distance per side. CSB001 went PASS→PARTIAL with +8 entities (4 spurious extra PPs). Reverted — schema is not “more columns at same row”.
Fix Plan (deferred — significant redesign):
- Option A: PP-DECODE emits a list of (elevation, side, distance) tuples directly. pick.lsp rewrites loop to iterate the tuple list, not a 2D grid. Removes the grid model.
- Option B: Per-row distance encoding via new globals (e.g., ppdL5-8, ppdR5-8 — L/R distance per elevation row). Keep pick.lsp grid but use new globals.
- Option C: Explicit list-of-PPs in panatt; pick.lsp just iterates and inserts.
- All three break the existing PP-DECODE / pick.lsp contract; needs careful design.
STANDARDS-TRACE: ACI 551R-92 §2.12.3.2 — pick-point grid layout for tilt-up panels, up to 16 PPs (4×4 or 2×8 by aspect ratio).
Related: Bug 142 (RL elevation), Bug 143 (two rooflines), Bug 144 (WC scrambled at roofline) — all surfaced by same CSB022 GUI walkthrough.
DFMEA Reference: DFMEA-070 (RPN 448) — top-of-list engineering risk after this issue lands
GH Issue: #183

Bug 140 — PP/BP block-name truncation + hardware geometry loss¶

Discovered: May 7, 2026 (Phase C cluster diagnosis on CSB053–059)
Severity: High (promoted 2026-05-09) — Phase D Tier 2 corpus-wide sweep proved this is universal: 100% of panels in 16 of 22 projects have block-name drift; 88–98% in the rest. Affects every legacy-file panel with PP or BP blocks; ~30+ hardware 3DSOLIDs lost per panel; material-list cross-references break.
Status: ⚠️ Open — single-fix high-leverage candidate now that Tier 2 confirmed corpus-wide prevalence (was assumed catalog-architecture-dependent and bigger scope; the truncation itself is a smaller, simpler fix that unlocks dozens of panels per project)
Symptom: TB11 source-mode produces simplified pick-point and brace-point block names: PP_<panel-thickness> (e.g., PP_11-25 for 11.25” panel) and BP_<panel-thickness>. Original VLX produced rich names encoding pick-point variant + lift-hardware type (PPEdgeZZSuperLift_III, PP7-250ZZSuperLift_III, BP7-250ZZSuper_22XX). The simplified TB11 block also has simpler geometry — the lift-hardware 3DSOLIDs that lived inside the VLX variant block are missing.
Reproducer: CSB053 pre-DXF has PPEdgeZZSuperLift_III (4 INSERTs) + 33 3DSOLID/hardware entities. TB11 redraw produces PP_11-25 (1 INSERT) + 0 3DSOLID/hardware entities. Net Δ=−33 on hardware layer, plus block-name change. CSB046 same pattern with PP7-250ZZSuperLift_III → PP_7-25.
Cluster scope: 7 panels in CSB053–059 (small-panel surplus +20/+23 cluster) PLUS 4 panels in CSB046–049 PLUS scattered occurrences in other panels with PP/BP. ~15+ panels in the CSB corpus exhibit the symptom.
Root Cause: src/x64/TB11-01x64/pick.lsp:114-123 builds the PP block name from panel thickness only:
```
(set 'x10 (rtos (distof mpx1) 2 2))   ; "7.25" → "7-25"
(set 'x10 (strcat "PP_" x10))         ; → "PP_7-25"
(command "_.-block" x10 ...)          ; create simpler block
```
The variant + lift-hardware-type fields aren’t decoded from the NOD XRecord (or wherever VLX stored them), and the block geometry is built locally rather than pulled from a master library .dwg with the rich variant geometry.
Fix Plan (decision-gated):
- Strategic (preferred): structured catalog for pick-points + brace-points (same approach as DFMEA-066 WC catalog architecture). Encode variant + hardware type as data; source-code generates names + pulls geometry from catalog. Customer-configurable.
- Tactical: extend panatt.lsp PP-DECODE / BP-DECODE to decode the variant fields, extend pick.lsp to build full block name + pull block geometry from a master library .dwg. Requires reverse-engineering VLX naming convention from pre-DXF samples — the variant data is project-specific and not in TB11 source.
- Accepted-deviation: document as known limitation. Customers needing rich pick-point blocks must keep using VLX or migrate to cv-web (Phase 10/E).
DFMEA Reference: DFMEA-069 (RPN 336)
GH Issue: #182

Bug 139 — Pre-DXF parity baseline staleness¶

Discovered: May 7, 2026 (during Bug 138 retraction analysis)
Severity: Medium — methodology issue, not a code bug; misleads engineering prioritization
Status: ✅ Fixed (infrastructure + policy) — three-tier baseline cascade in Run-BatchParity.ps1 + selective re-baseline scope policy enforced. Re-baseline applied to validated panels only.
Symptom: Per-panel pre-DXF baselines were captured before Phase 1-9 source-code fixes landed. Phase 5 layer-routing fix in particular changed which layer feature dim entities go to (perimeter_dim → feature_dim). Post-fix headless redraw produces correct entities; pre-DXF has the old layer assignments or no entities at all. Single-pass entity-count delta vs stale baseline shows large positive shifts that look like regressions but are really “fix applied since baseline”.
Reproducer: CSB046 post-fixture sweep showed Δ=+18; entity diff revealed +28 feature_dim (Phase 5 fix), +63 perimeter (exploded title block, accepted), −25 ATTRIB (same), −39 connections_dim (Phase 4 consolidation). No actual bug — all four contributors are either accepted deviations or post-fix corrections.
Root Cause: Per-panel pre-DXF strategy (commit 2e776dcf3) is sound for catching regressions, but baselines need to be regenerated after each major source-code change. Otherwise the “pre” represents a pre-fix world and the “post” represents a post-fix world, and the diff conflates real bugs with fix-induced changes.
Fix: Three-tier comparison cascade in Run-BatchParity.ps1: <panel>-expected.dxf (locked-in reference) takes priority over auto-regenerated <panel>-pre.dxf, which falls back to legacy golden/<panel>-golden.dxf. Re-baseline scope rule documented in Doc 45 §“Re-baseline policy”: only re-baseline panels that are PASS, PARTIAL, OR independently visually validated; never bulk-re-baseline a corpus with FAIL panels.
Application history:
1. 2026-05-07 (initial, ALL 59): bulk-applied without scope check → produced a misleading “59 PASS / 0 PARTIAL / 0 FAIL” report that locked 37 FAIL panels’ real defects in as the new “correct” state. User caught the issue immediately.
2. 2026-05-07 (corrected, 3 panels): kept expected.dxf only for CSB001/002/003 (user-confirmed “nearly perfect” via Phase 1-9 work). Removed the 56 incorrect expected.dxf files. Re-sweep showed 5 PASS / 17 PARTIAL / 37 FAIL — the 37 FAIL flags are preserved as legitimate defect signals (DFMEA-066, DFMEA-069, etc.).
Lesson learned: see feedback memory — re-baseline is a per-panel deliberate act, not a bulk operation. Pre-rebaseline reference: reports/batch-parity/pre-rebaseline-reference.csv preserves the 2 PASS / 20 PARTIAL / 37 FAIL distribution that preceded the initial misapplication.
DFMEA Reference: DFMEA-068 (RPN 240 → 120 after D 6→3)
GH Issue: #181 (closed in next commit)

Sprint 20 — TECT042 panel book + SO dialog parity push (Bugs 164–172)¶

These bugs were committed 2026-05-18 14:00–17:00 PT during the TECT042 panel-book delivery push. JIRA bilateral linkage went live the same day; backfill JIRA refs filed under Feature CV-480. Detailed reports kept in the JIRA issue body — only one-line entries here for cross-reference.

#	Severity	Status	Title	File(s)	Commit	DFMEA	JIRA
164	High	✅ Fixed	panatt SO per-row enable rejects TECT-schema rows — entire SO section dropped	`panatt.lsp` (panatt_section_active-p)	`c19224978`	DFMEA-074	CV-481
165	High	✅ Fixed	panatt ch section over-activates — needs last-elem=1 disjunctive escape	`panatt.lsp`	`170776d98`	DFMEA-074	CV-482
166	Low	✅ Fixed	demo-cycle stalls on File-In-Use modal + tiles stale AC handles	demo-cycle harness	`a6cc58281`+	DFMEA-075 NEW	CV-484
167	Medium	✅ Fixed	gui-draw view-apply races MCP state callback in restore-state	`cv-gui-draw.lsp` (restore-state)	`18f3c3096`	DFMEA-079 NEW	CV-485
168	High	✅ Fixed	mp_dlg ± encoding (octal \261) + mppn dir-clobber + ch over-activation	`mp_dlg.dcl`, `mp_dlg.lsp`, `panatt`	`4b1610edf`	DFMEA-074/078 N	CV-489
169	High	✅ Fixed	SO compact-record decoder field misreads (#1 format, #2 defaults, #3 q, #4 p)	`panatt.lsp`, `wd_dlg.lsp`	`084104429`	DFMEA-074	CV-490
170	Low	✅ Fixed	wd_dlg text-level drift from PB11 (label, subtitle, columns)	`wd_dlg.dcl`	`5640946d3`	DFMEA-013	CV-491
171	Low	✅ Fixed	wd_dlg combined Trim/Notch column wrong — split Drip/Future header	`wd_dlg.dcl`	`cce0670be`	DFMEA-013	CV-492
172	High	✅ Fixed	wd_dlg notch key case-collision (wdT vs wdt) + slider width + stack alignment	`wd_dlg.dcl`	`2d811a416`	DFMEA-081 NEW	CV-496
173	High	✅ Fixed	Validation/draw qsaves the SOURCE dwg — all validation paths now scratch-copy	`Run-CVAutoTest.ps1`, `Run-CVDemoCycle.ps1`	`173fe243b`,`f514b88e1`	DFMEA-082 NEW	CV-529
174	Medium	✅ Fixed	“Roof Line = Joist Bearing” note printed OUTSIDE the title block (frame shift)	`src/x64/TB11-01x64/finpan.lsp`	`0f33182eb`	DFMEA-083 NEW	CV-532
175	Medium	⏸️ Stale	x64→x32 sync silent no-op (`Get-ChildItem -Include`, no recurse → 0 files)	`Run-ParityTest.ps1`, `Run-BatchParity.ps1`	`76a4f1268`	DFMEA-055	CV-528

Companion non-bug tasks tracked in JIRA only (Sprint 20 backfill): CV-483 (revert fragile so-guard), CV-486 (gui-draw final Ready prompt — partial / deferred per memory project_deferred_massprop_cli_residue.md), CV-487 (feature.lsp clip fs strips around wdvar), CV-488 (drawdim wdvar dashed-X + inside W/H dims — new DFMEA-077), CV-493 (DIMZIN=0 + literal cleanup), CV-494 (DIMZIN in dim-style block + inline Drip/Future labels), CV-495 (L/R/T/B notch toggles per row — new DFMEA-080).

Security Bugs (Sprint 22 — Security-Focused SDLC seed)¶

Security bugs are tracked as a parallel ledger to the AutoLISP/source-mode bugs above. Each row corresponds to a RISK-NNN entry in docs-sensitive/security/risk-register.md and a row in doc 31 §9-SEC. Three ledgers, same event, three IDs each (per Security SDLC plan).

Seeded from the 2026-05-27 cv-web spike audit (10 rows). The full bug-report sections live in private Jira (CV-NNN) and docs-sensitive/security/ to avoid publishing exploit detail via the public Sphinx site.

#	Severity	Status	Title	File(s)	Commit	DFMEA	RISK	JIRA
SEC-1	Critical	🔲 Open	`/spend` non-atomic charge — race enables concurrent double-spend	`backend/supabase/functions/spend/index.ts`	—	§9-SEC-001	RISK-001	CV-637
SEC-2	Critical	🔲 Open	Sentry `sendDefaultPii: true` ships PII to third-party SaaS	`webpage/Simplestruct/cv-web/src/instrument.ts`	—	§9-SEC-002	RISK-002	CV-638
SEC-3	Critical	🔲 Open	cv-cad device-token leaks via URL fragment (referrer + history)	`webpage/Simplestruct/cv-web/src/pages/CvCadLogin.tsx`, `backend/supabase/functions/device-tokens/index.ts`	—	§9-SEC-003	RISK-003	CV-639
SEC-4	Critical	🔲 Open	Stripe webhook ignores coupon discount — over-grants tokens	`backend/supabase/functions/stripe-webhook/index.ts`	—	§9-SEC-004	RISK-004	CV-640
SEC-5	High	🔲 Open	`/checkout` accepts arbitrary SKU — no server-side allowlist	`backend/supabase/functions/checkout/index.ts`	—	§9-SEC-005	RISK-005	CV-653 (S23)
SEC-6	High	🔲 Open	`/refund` endpoint missing — Stripe refunds bypass token-ledger reversal	`backend/supabase/functions/refund/index.ts` (to create)	—	§9-SEC-006	RISK-006	CV-654 (S23)
SEC-7	High	🔲 Open	Import file-size + Zod validation gaps allow oversized / malformed `.cvpanel` payloads	`webpage/Simplestruct/cv-web/src/utils/cvpFormat.ts`, `ImportCVDialog.tsx`, `cvextract.ts`	—	§9-SEC-007	RISK-007	CV-655 (S23)
SEC-8	High	🔲 Open	Device tokens never expire — stolen token valid until manual revoke	`backend/supabase/functions/device-tokens/index.ts`, new migration	—	§9-SEC-008	RISK-008	CV-656 (S24)
SEC-9	Medium	🔲 Open	cv-web missing CSP / HSTS / X-Frame-Options / Referrer-Policy headers	CloudFront response-headers policy (Terraform `webpage/`)	—	§9-SEC-009	RISK-009	TBD (S26)
SEC-10	Medium	🔲 Open	PWA Service Worker can serve cached authenticated content to next user on shared device	`webpage/Simplestruct/cv-web/vite.config.ts`	—	§9-SEC-010	RISK-010	TBD (S27)

New Security Bugs are added by: every Pillar 2 threat-model session, every pentest finding (Sprint 33), every Pillar 9 incident retro. The same three-ledger discipline applies — Bug → DFMEA → Risk row, never two without the third.

Open Issues¶

~~VLA/ActiveX audit for AutoCAD 2024+ compatibility~~ — ✅ Completed. Full audit found zero unguarded VLA method calls in the TB11 main code path. All 44 grep matches were comments or safe VLISP built-ins (vlax-product-key, vl-load-com). Guard predicates csv_is-modern-acad and csv_is-dotnet-core added to csvcompat.lsp. Copilot Rule added to prevent future regressions.
S::STARTUP continuation not fully tested — The (command "_.open" ...) + cv-cont.lsp + S::STARTUP approach in scr.lsp has been pushed but not thoroughly tested across all workflow paths (new panel, new site, edit panel, edit site). Update: Trace confirms routing reaches scr() correctly and cv-cont.lsp is written, but the OPEN command itself fails (Bug 94) so the continuation never fires.
CSSsite missing xref definitions — CSSsite does not have panel xrefs baked into the drawing. This is a data issue, not a code issue. Running Attach Panels on CSSsite would fix it.
Panel drawing workflow untested — All testing so far has been on site drawings. The panel editor path (md_dlg) needs validation.
~~Missing _. prefix on (command ...) calls~~ — Static analysis found 667 bare (command "CMD" ...) calls across 42 unique command names without the _. (English + original) prefix. These work correctly on English AutoCAD but would fail on localized (non-English) AutoCAD installations. Not an active bug for the current English-only deployment, but logged as tech debt for future internationalization. Top offenders: ucs (92), pline (73), change (64), text (56), extrude (55).
XData refactor planned — Replace fragile text file serialization (tiltlist.txt, conslist.txt) with XData stored on INSERT entities. See XData Refactor Plan — Eliminate Text File Serialization for full design and implementation plan. This eliminates the entire class of serialization bugs (14, 15, 16, 17) and the fragile del *list.txt cleanup.
Bug 94: _.OPEN sub-prompt leak in AutoCAD 2027 — (command "_.open" fullpath "") still produces Unknown command "DWG". The trailing empty string and cmdactive drain loop did NOT fix the issue. Root cause investigation needed: test _.OPEN interactively with filedia=0 in AutoCAD 2027 to determine the exact sub-prompt sequence. Possible causes: file format sub-prompt, SDI/MDI prompt, or the .dwg extension in the path being parsed as a separate token. This is the #1 blocking issue for the Edit Existing Drawing workflow. (DFMEA-36, RPN=140)

Bug Tracker — Validation Campaign¶

TB11 Source-Mode Bugs (VM 108)¶

Profile/Deployment Bugs (VLX Installations)¶

Deployment, Environment & Validation Bugs (VM 104)¶

Multi-User / New Profile Bugs¶

Historical Crash Dumps & Validation Bugs¶

Trace Infrastructure Bugs (G0/G1/G2 AutoIT Scripts)¶

G1 First-Run Bugs (March 20–21, 2026)¶

AutoCAD 2027 Deployment Bugs (Local Dev)¶

Elevation-Marker Pipeline Bugs (May 5, 2026)¶

Off-Panel Entity & Layer-Routing Bugs (May 6, 2026)¶

Detailed Bug Reports¶

Bug 1: CSV.VLX Overrides Source Files¶

Bug 2: File Browser Shows No .dwg Files¶

Bug 3: dirchk False Positive¶

Bug 4: Block Comments Crash AutoCAD 2000¶

Bug 5: (command "open" path) Invocation/Context Failure in AutoCAD 2000¶

Bug 6: dbchk Leaves SAVEAS Active¶

Bug 7: VLX Detection Matches VLIDE Runtime¶

Bug 8: FILE nil on Batch File Creation¶

Bug 9: Drawing Type Dialog Asks Every Time¶

Bug 10: Tilt-Up Crashes Without Attach Panels¶

Bug 11: Inspanel.lsp Filename Capitalization¶

Bug 12: Attach Panels Crashes on Missing Wall Lines¶

Bug 13: Wall Line Entities Missing — No Recovery + TEXT Regression¶

Bug 14: tiltlist.txt ENAME Serialization¶

Bug 15: Tilt-Up Index Bug — nn vs xn for pnllst Lookup¶

Bug 16: conslist.txt ENAME Serialization — Layout Crashes on Re-read¶

Bug 17: Layout Index Bug — nn vs xn for pnllst Lookup¶

Bug 18: progcont Routing Missing from Source — VLX/Source Mismatch¶

Profile/Deployment Bug Reports¶

Bug 19: Missing Menu Registration Causes setvars Function Cancelled¶

Bug 20: Startup Suite VLX Crash + Missing Startup Suite Entries¶

Investigation Timeline¶

Bug 21: Edit Existing Drawing Can’t Find CSBsite1.dwg — Missing Project Settings¶

Bug 22: Forward Slashes Fail Through NTFS Junctions on XP¶

Bug 23: propertiesclose Command Doesn’t Exist in AutoCAD 2000¶

Bug 24: Validation Screenshots Overwrite — Stale Data Contamination¶

Bug 25: AutoIT False Positive — Error Dialog Detected as Valid CV Dialog¶

Bug 26: Git Not on SSH PATH — CV Update.bat Fails Remotely¶

Bug 27: CMD Echo Caret Escaping Corrupts Generated acaddoc.lsp¶

Bug 28: csv.lsp Not Loaded in Source-Mode — acaddoc.lsp Only Loads Menu¶

Bug 29: #| |# Block Comments in csvmenu.lsp Crash Source-Mode Loading¶

Bug 30: (alert) Dialog in csvmenu.lsp Blocks AutoIT Validation — Drawing Open Fails¶

Bug 31: New User Profile Missing AutoCAD Configuration — CV Update is Per-User (HKCU)¶

3-VM Comparison Results (Feb 28, 2026)¶

Bug 31: Multi-User Junction Conflict — CV Update Crashes Other User’s AutoCAD¶

DFMEA Reference (Bug 31)¶

Bug 32: Registry-Based Layout Standardization Unreliable Across VMs¶

DFMEA Reference (Bug 32)¶

Bug 39: Version Subtitle Not Rendering in TB progopts Dialog¶

DFMEA Reference (Bug 39)¶

Bug 40: Print Revision History / Print Materials List Enabled Without Project¶

DFMEA Reference (Bug 40)¶

Bug 41: CV Update.bat Shows “Active build: unknown” on XP¶

DFMEA Reference (Bug 41)¶

Bug 42: Bug 40 Regression — project() Cancel Falls Through to progopts¶

DFMEA Reference (Bug 42)¶

Bug 43: FATAL ERROR — FILES MISSING for Non-Admin User on VM 201¶

DFMEA Reference (Bug 43)¶

Bug 82: cv-tracer.lsp Load Fails — “no function definition: FBOUNDP” on AC2000 Source-Mode¶

DFMEA Reference (Bug 82)¶

Bug 83: G1/G2 Drawing Open Fails — ClipPut+^v Unreliable in AC2000 Command-Line Mode¶

DFMEA Reference (Bug 83)¶

Bug 84: AutoCAD Crashes When G1/G2 Continues Executing After Drawing Open Failure¶

DFMEA Reference (Bug 84)¶

Bug 85: G1/G2 _SendProgcont — Send(..., 1) Emits {ENTER} as Literal Text¶

DFMEA Reference (Bug 85)¶

Bug 86: PANATT Crashes — bad argument type: stringp nil on Fresh Panel Drawing Open (pc=1)¶

DFMEA Reference (Bug 86)¶

Bug 87: MATL_DLG — architecture requires site drawing; G1 test was using wrong drawing type¶

DFMEA Reference (Bug 87)¶

Bug 88: G2 CSBsite1 False Negative — Window Detection Fires Before 59 XREFs Finish Loading¶

Bug 89: (stringp x) Not Defined in AutoCAD 2000 AutoLISP via (load)¶

Bug 90: pc=262273 Always Routes to slyr_dlg (Site Layer Control) on Panel Drawing¶

Bug 91: Print Cleanup layer "s" "custom" Fails on Site Drawings — Function cancelled¶

Bug 92: progcont > 1 Dispatch Has No Project-Context Guard¶

DFMEA Cross-Reference¶

TB11 Source-Mode Bugs (1–18)¶

Profile/Deployment Bugs (19–21)¶

Bug 5: `(command "open" path)` Invocation/Context Failure in AutoCAD 2000¶

Bug 18: `progcont` Routing Missing from Source — VLX/Source Mismatch¶

Bug 19: Missing Menu Registration Causes `setvars` Function Cancelled¶

Bug 23: `propertiesclose` Command Doesn’t Exist in AutoCAD 2000¶

Bug 28: `csv.lsp` Not Loaded in Source-Mode — `acaddoc.lsp` Only Loads Menu¶

Bug 29: `#| |#` Block Comments in `csvmenu.lsp` Crash Source-Mode Loading¶

Bug 30: `(alert)` Dialog in `csvmenu.lsp` Blocks AutoIT Validation — Drawing Open Fails¶

Bug 82: `cv-tracer.lsp` Load Fails — “no function definition: FBOUNDP” on AC2000 Source-Mode¶

Bug 83: G1/G2 Drawing Open Fails — `ClipPut+^v` Unreliable in AC2000 Command-Line Mode¶

Bug 85: G1/G2 `_SendProgcont` — `Send(..., 1)` Emits `{ENTER}` as Literal Text¶

Bug 86: `PANATT` Crashes — `bad argument type: stringp nil` on Fresh Panel Drawing Open (pc=1)¶

Bug 87: `MATL_DLG` — architecture requires site drawing; G1 test was using wrong drawing type¶

Bug 89: `(stringp x)` Not Defined in AutoCAD 2000 AutoLISP via `(load)`¶

Bug 90: `pc=262273` Always Routes to `slyr_dlg` (Site Layer Control) on Panel Drawing¶

Bug 91: Print Cleanup `layer "s" "custom"` Fails on Site Drawings — `Function cancelled`¶

Bug 92: `progcont > 1` Dispatch Has No Project-Context Guard¶

Bug 32: VM 103 Historical `acadstk.dmp` Crash Log¶

Bug 34: `cvplst` Not Recognized — Batch Utilities Hangs¶

Bug 94: `Unknown command "DWG"` — scr.lsp OPEN Sub-Prompt Leak¶

Bug 98: `(exit)` in project() Silently Aborts¶

Bug 99: No `error` Handler in c:csv¶

Bug 101: AutoCAD 2027 Crash on Exit — `System.ExecutionEngineException` in `coreclr_shutdown`¶

Bug 102: New Drawing Dead End — `pcr=T` Kills Editor Launch¶

Bug 103: `cvxpproj.lsp` Export Naming Mismatch — 19 of 21 Globals Exported as Null¶

Bug 105: `pjdll.lsp` Text-Mode Line Reader — `read-char` Returns LF Not CR¶

Bug 106: `projdet.lsp` Import Gate — `csv_contractor` Already Filled by Title Block¶

Bug 107: First `c:csv` Call Silently Aborts — `error` Masks panatt Failure During csv_dwgtype Detection¶

Bug 108: `matl_dlg.lsp` Cond Default Has Stray `=` Operator — Materials List Crashes¶

Bug 109: `matl_dlg.lsp` `(cons)` Misplaced Paren — wcl Default Entry Crashes Materials List¶

Bug 110: `okcanhlp.lsp` Cancel Handlers Missing `(done_dialog)` — 6 Dialogs Uncancellable¶

Bug 111: `(command "CMD" ...)` Without Dash Prefix Opens Dialog/Palette Mode — Silent Failures Across Entire Codebase¶

Bug 112 — 47 `(exit)` Calls Violate Rule 19 (Silent Termination) — ✅ Fixed¶

Bug 113 — 12 Unguarded `load_dialog` Calls¶

Bug 114 — Unguarded `findfile "acad.exe"` in csv.lsp¶

Bug 115 — 30 Unguarded `(open ...)` Calls — File I/O Crash Risk¶

Bug 116 — 13 Unguarded `(ssget ...)` Calls — Nil Selection Set Crash Risk¶

Bug 121 — `DIMUNIT` Deprecated — Dimension Text Shows Integer Inches Instead of Architectural Fractions¶

Bug 122 — `finpan.lsp` Second `drawdim` Call Crashes with `consp "()"` in Main-Panel-Only Mode¶

Bug 125 — Snake-tongue artifact: `dim1` arrow tail penetrates ELEV circle on staggered markers¶

Bug 126 — `\X` rendering literally in entmake’d MTEXT after switching off dim1¶

Bug 128 — `cv-gui-draw.lsp` silently loaded stale `drawdim.lsp` from AutoCAD’s default SFSP¶

Bug 132 — WC dim path missing 2 LEADER entities on `connections_dim` layer¶