9 Commits

Include renames

Author	SHA1	Message	Date
Umut CANandClaude Opus 5	dda11755cf	fix(task-16): custom keys follow AutoCAD's simple case compare, and on COM AutoCAD routes the write ... 4fe2d96 matched custom keys with str.casefold(), but AutoCAD's key compare is a simple one-to-one case compare, not Unicode full case folding. Measured on AutoCAD 2026 (AddCustomInfo of the second spelling over the first on a scratch document, Close(False)): Project/PROJECT, Grün/GRÜN, é/É, ÿ/Ÿ, ł/Ł, σ/Σ, я/Я and dž/DŽ are one key ('Duplicate key'), while Straße/STRASSE, ẞ/ß, kelvin/Kelvin-sign, µ/Μ, σς/ΣΣ and Dž/DŽ are two keys (both stored) -- every one of those six is casefold()-equal. So with 'Straße' present, `custom={'BEFORE': 'b', 'STRASSE': 's2', 'AFTER': ...}` was routed to SetCustomByKey, AutoCAD answered 'Key not found', and the request raised with subject and BEFORE applied and AFTER never written -- the half-write class the fix claimed to close; a delete of 'STRASSE' over 'Straße' raised the same way; headlessly 'STRASSE' overwrote the 'Straße' value instead of becoming a second tag; and the validator refused {'Straße', 'STRASSE'} with a reason AutoCAD contradicts. COM no longer routes from a Python approximation. An exact spelling goes to SetCustomByKey; anything else is AddCustomInfo, and its 'Duplicate key' (excepinfo scode -2145386475, measured) falls back to SetCustomByKey. A delete is RemoveCustomByKey, and its 'Key not found' (scode -2145386476) is reported as not deleted. Any other com_error keeps propagating. The scode is matched before the English description because the HRESULT text is localised. The headless engine and the validator match on `custom_key_fold`: a per-character fold to lowercase only when lower()/upper() are single characters that round-trip and the character is one of the two; it never changes string length and reproduces every measured pair (ß, ς, µ, the Kelvin sign, Dž, ı and İ stay as they are). Docstrings in settings.py and server.py now state that rule instead of 'case-insensitive'. Tests: parametrized fold over the measured SAME / DISTINCT table (plus a pin that casefold() merges the six DISTINCT pairs, which is why 4fe2d96 regressed), validator acceptance of each DISTINCT pair, headless side-by-side storage and deletion of each pair, the fake SummaryInfo now matches by the same fold and raises pywintypes.com_error with the measured excepinfo tuples, the COM half-write scenario for each pair (no SetCustomByKey guess, 'Key not found' delete tolerated, rest of the request lands), the 'Duplicate key' fallback, and an unrelated SummaryInfo failure still raising. The scodes were measured live before the change; AutoCAD stopped answering COM (blocked in another agent's command or a modal dialog) before the post-change re-run, so that run is recorded as not done. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-21 22:04:22 +03:00
Umut CANandClaude Opus 5	4fe2d963c0	fix(task-16): custom keys mirror AutoCAD's full AddCustomInfo rule, deletes are exempt, keys match case-insensitively ... The 2b9791f fix mirrored only the characters the first review happened to measure ('=' and ';'), so `custom={'AAA': 'first', 'A:B': 'x', 'ZZZ': 'never'}` still raised from AddCustomInfo('A:B') on the live engine after subject and AAA were applied -- the same half-write for 11 other keys. Re-measured on AutoCAD 2026 by sweeping every character 0x20-0x7E through a scratch document: exactly thirteen printable characters are 'Invalid key' anywhere in a key (" * , / : ; < = > ? \ ` |); control characters, internal spaces, a no-break space and unicode are accepted; leading/trailing whitespace (space, tab, NBSP) is refused. `_CUSTOM_KEY_FORBIDDEN` is now that set, the internal-NBSP refusal (wrong: measured accepted) is gone, and the validator / tool docstrings state the measured rule instead of a closed enumeration that was false. A delete (`{key: None}`) is exempt from the AddCustomInfo syntax rules: RemoveCustomByKey never validates syntax (measured: 'Key not found', never 'Invalid key'), and 2b9791f ran the check before the None branch, so a key an ezdxf script wrote ('A=B', ' PAD ') showed in drawing_properties_get and could never be removed. The line-break rule still applies both ways. Also measured: custom keys are case-insensitive in AutoCAD (AddCustomInfo over an existing case-variant is 'Duplicate key'; SetCustomByKey and RemoveCustomByKey match either spelling and keep the stored one). The COM routing was case-sensitive, so `{'PROJECT': ...}` over 'Project' went to AddCustomInfo and failed mid-write -- the same class. Both engines now match existing keys casefolded (update in place under the stored spelling, never a second tag), and a request naming two case-variants is refused. Tests: parametrized validator sweep over all thirteen characters, the accepted set (control chars, NBSP, unicode, the other printables), the delete exemption headlessly on a DXF carrying such keys and on the fake SummaryInfo, case-variant refusal, and case-insensitive routing against a fake that raises 'Duplicate key' / 'Key not found' like AutoCAD. Confirmed live through the real ComBackend on a scratch document (Close(False)). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-21 21:37:44 +03:00
Umut CANandClaude Opus 5	2b9791fbcd	fix(task-16): custom properties refuse pre-R2004 headlessly, line breaks, and AutoCAD's invalid keys before any write ... Three header-only-write / half-write classes in drawing_properties_set: 1. Measured: ezdxf emits $CUSTOMPROPERTYTAG / $CUSTOMPROPERTY only after $LASTSAVEDBY, which does not exist before R2004, so on an R12 (AC1009) or R2000 (AC1015) document the write reported ok, drawing_properties_get echoed it from memory, and drawing_save_as (version kept) wrote nothing -- the class f3ff703 removed for CANNOSCALE. The headless engine now refuses with a ValueError naming the DXF version and "save as R2004 or newer", before custom_vars is touched; the dwgprops capability reason no longer claims custom_properties_supported unconditionally. 2. A line break in a custom key or value passed validation, ezdxf wrote it unescaped, and the saved DXF failed to reopen (DXFStructureError) -- the whole drawing lost, reported as success. Refused by name in the shared validator. 3. Measured on AutoCAD 2026: AddCustomInfo rejects keys with leading/trailing whitespace and keys containing '=', ';' or a no-break space as 'Invalid key' -- mid-write, after the summary and earlier keys were applied, as an unnamed COM error -- while the headless engine wrote them. The shared validator now mirrors those rules, so both engines refuse before writing (internal spaces, tabs, unicode and 300-char keys stay accepted, as AutoCAD accepts them). Pinned by save+reopen tests on R12/R2000 (refused, file reads back empty), R2004 (round-trips), the newline case (refused, the file still opens), and the fake-SummaryInfo COM test (no ActiveX call reaches SummaryInfo). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-21 18:45:02 +03:00
Umut CANandClaude Opus 5	10a7372ce7	feat(settings): drawing_properties_get/set — SummaryInfo on COM, custom properties on both engines ... Summary fields are refused headlessly with capability dwgprops before any write; custom properties are $CUSTOMPROPERTYTAG/$CUSTOMPROPERTY pairs and survive save + reopen. Validation is shared, by name, and never str()-coerces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-21 16:59:19 +03:00
Umut CANandClaude Opus 5	75c13196b9	fix(task-15): angle sysvars are radians on both engines; OSMODE is registry-saved and refused headlessly ... Three authored claims in SYSVAR_CATALOG were false against the engines: - HPANG said "degrees" but ActiveX GetVariable/SetVariable (and AutoLISP getvar) hold radians - measured on AutoCAD 2026 in a scratch document: SetVariable(pi/4) reads back 0.7853981633974483 on both paths. The row now says radians, like POLARANG. - ANGBASE said "radians" with both engines True, but the DXF header stores $ANGBASE in degrees (AutoCAD saved the 1.5708-radian seat value as 90.0) and ezdxf read/wrote it raw, so the two engines disagreed by a factor of 57.3. EzdxfBackend now translates that header variable at its boundary (_HEADER_DEGREE_SYSVARS): the tool speaks radians on both engines, the file keeps degrees. - OSMODE claimed engines.ezdxf True, but $OSMODE is an R12-only header variable ezdxf never exports for R2000+: a headless write reported ok: True and read back None after save + reopen. It is registry-saved in AutoCAD, so it joins _UNSAVED_SYSVARS (refused with capability: registry_sysvar; the facade's `osmode` key refuses and snapshots None headlessly, like polar / polar_angle). Headless reads of every registry-saved variable now report None instead of whatever the ezdxf template holds in memory. The gate that should have caught all three, tests/test_sysvar_catalog.py's default round-trip, wrote 56 no-ops out of 66 and never saved: it now writes a value that differs from the fresh document's for every writable ezdxf-True entry, saves, reopens and reads back from the file. Two new tests pin OSMODE's refusal and ANGBASE's radians-at-the-tool / degrees-in-the-file split. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-17 15:20:02 +03:00
Umut CANandClaude Opus 5	f3ff703144	fix(task-14): refuse CANNOSCALE on an R12 file headlessly instead of losing it at save ... Measured: an R12 (AC1009) document has no OBJECTS section, so ezdxf exports neither AcDbVariableDictionary/DICTIONARYVAR nor the seeded SCALE objects, and drawing_save_as keeps AC1009. `_set_annotation_scale` reported `ok: True, changed 1:1 -> 1:50` and the file reloaded as 1:1 -- the header-only write that vanishes on reload, the class this task exists to remove, and a breach of the backend's own R12 honesty convention (viewport_set_scale / lock). The write is now refused with a ValueError naming R12 and "save as R2000 or newer", after parse_scale (a malformed value is still named as such) and before either dictionary is touched, so a refused call leaves the root dictionary as it found it and drawing_settings still applies the sibling keys (limits / grid / ortho survive R12). The refusal is listed with the others in the contract and server docstrings. Pinned by two tests that save, reopen and read the R12 file back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-17 10:14:05 +03:00
Umut CANandClaude Opus 5	df39b21f2e	feat(settings): drawing_settings gains limits, grid/snap, ortho/polar, psltscale, annotation scale, unit formats and current styles ... Headlessly, grid/snap are stored on the active VPORT, CANNOSCALE in AcDbVariableDictionary (+ an ACAD_SCALELIST entry), and LIMMIN/LIMMAX on the model-space layout as well as the header — measured: the header alone is overwritten at save. Registry-saved variables (AUTOSNAP, POLARANG, …) are refused with capability registry_sysvar instead of vanishing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FKFStjEFzpGyLq5bMpWxTd	2026-09-16 21:14:31 +03:00
Umut CANandClaude Opus 5	ca1c79fd01	fix: seven defects an adversarial audit found, and the gates that missed them ... Every one of these was reported ok/clean to the caller while being wrong. Silently wrong numbers - selection_filter(min_area) read `entity.dxf.get("area", 0.0)` for SOLID, TRACE and HATCH, none of which carry that attribute, so every hatch measured 0.0. A 1600 mm^2 hatch was excluded by min_area=1.0 while `filtered_by` asserted the filter had run, and COM (which reads ActiveX .Area) returned a different selection for the same call. It now answers from the measurement `entity_measure` uses, so the two cannot disagree. - Every headless dimension rendered through ezdxf's bare `Standard` style: 1.0 mm text with a comma decimal marker, against ISO 3098's 2.5 mm minimum and ISO 129's point -- while the document header itself said $DIMTXT 2.5. `ezdxf.new(setup=True)` is not the fix; measured, it renders a 100 mm dimension as "10000". The attributes are now stored explicitly. - Saving writes `dimrnd = 0.0` onto the Standard style, and ezdxf applies `xround(value, dimrnd)` whenever the attribute is present at all -- `xround(33.333, 0.0)` is 33. So on any reopened file, including one this server saved, every dimension was rounded to a whole unit before DIMDEC formatted it: a 12.75 mm feature dimensioned 13. AutoCAD means DIMRND 0 as *no* rounding; the sentinel is now discarded at every load site, and a real 0.5 mm rounding is left alone. - The DIM* header fold gave out-of-range values teeth they did not have when they died in the header: dim_decimals=-1 returned ok and then killed the next dimension with `ValueError: Format specifier missing precision` from inside ezdxf, and 40 printed forty digits of float noise onto the sheet. Ranges are now AutoCAD's own (DIMDEC 0-8, DIMZIN 0-15, lengths positive). Security - security.py recorded the policy as "sanitize_command and sanitize_lisp each have exactly ONE caller ... the policy is scoped to the CHANNEL". The premise was false. `_ensure_linetype_loaded` and `ComBackend.linetype_load` build `_-LINETYPE _LOAD {name} {file}` and hand it to SendCommand, which treats a newline and ';' as segment separators -- so a `linetype=` argument carrying either injected further AutoCAD commands, and the 36-verb denylist never saw that channel. Guarded with the DXF symbol-name rule (the injection characters fall out of it rather than being enumerated) plus validate_path for the file argument, which was also the one path-taking tool reaching the filesystem unchecked. The policy comment is corrected. Gates that could not see - drawing_critique returned zero issues on a quarantined document: all seven checks wrapped their backend call in a bare `except Exception`. CLAUDE.md rule 7 makes that call the gate an agent is told to trust. Only the quarantine now escapes; an ordinary broken check still degrades. `_check_dimension_legibility` also read `_doc` directly from the event loop thread, missing the gate and performing exactly the unsynchronised access the quarantine exists to prevent. `construction_clear` answered "deleted: 0" -- there was nothing to clear -- for the same reason. - The iso128 focus checked layer lineweights only, so a sheet lettered at 1.0 mm critiqued clean. It now reads the effective dimension height and separator, header-then-style, in the order the renderer resolves. - check_doc_numbers.py derived five values it never checked, and those were the ones that had drifted. The collected-test count (README said 1274, the tree had 1369) and the A/B pass-rate and Fixed columns are now gated. - benchmarks/README.md's v1.4.0 table was impossible on its face -- 21 passing plus 5 fixed is 26, not 24 -- and contradicted the report it linked, because `ab-v1.4.0-vs-v1.5.0.json` was regenerated from a tree that already carried the dimension fixes and so never measured the v1.5.0 tag. Replaced with a real run: ab-v1.4.0-vs-v1.5.1.json, 21/26 -> 26/26. Release gate - release.yml ran one ubuntu/3.11 lane, so a Windows-only defect could reach PyPI with no Windows job having executed. That is not hypothetical: v1.5.0 shipped `except pywintypes.com_error` raising NameError wherever pywin32 is absent. It now runs the same three lanes as ci.yml, Windows included. 1368 passed, 1 xfailed. ruff clean. Tool inventory and all 16 gated document numbers match the tree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 23:07:50 +03:00
Umut CANandClaude Opus 5	b03a7615b1	release: v1.5.0 — discovery layer, honesty debt closed, Wave A ... Tool count 131 -> 154; 474 -> 1242 collected tests. The release exists for two measured reasons. A 149-tool catalog costs a client ~40,300 tokens before it has asked for anything, and a drafter searching the way drafters think -- FILLET, BPOLY, QSELECT, WBLOCK -- scored df=0 against the stock index, because those words were simply not in the data. Discovery and batching - DISCOVERY_MODE=search replaces the catalog with search_tools + call_tool, ranked over an AutoCAD command and synonym corpus (discovery/aliases.py) on top of fastmcp's BM25 index. Measured: 40,305 -> 356 tokens advertised. - cad_batch runs a step list in one round trip; fields= projects result-heavy responses. The `core` profile is gone -- discovery replaced it. Honesty debt (Tier 0) - OCS/ECS: `extrusion` appeared nowhere in this codebase, so mirrored and rotated geometry reported coordinates that were quietly wrong. backends/ocs.py translates at the backend boundary; every tool coordinate is WCS on both engines, and a tilted plane refuses rather than answering with a number that looks fine. - drawing_save_as(fmt="dwg") wrote DXF bytes to a .dwg path. drawing_audit never repaired. analysis_measure_area shoelaced points the caller typed in. - ezdxf calls gained a per-call timeout, so one hung call can no longer wedge a server whose document lock is a single asyncio.Lock. Architecture - The 1854-line backend ABC is 19 contract modules; @capability(key, reason=) makes optional methods declarative and a gate fails on undeclared holes. - 8 layout/viewport tools, CHSPACE, CAD_PROGID escape hatch. - Wave A: selection filters, boundary tracing, hatch depth, annotation objects, measurement -- 13 tools of a planned 39. The REGION and 2D-boolean family was cut on evidence: add_region() yields zero ACIS bytes and the greiner_hormann substitute loses 28.2% of the area on a square with one semicircular edge. Verified against a live AutoCAD 2026, which found four COM defects no amount of reading would have caught -- AcadPViewport has no ViewCenter, and the line that set it had been swallowed by a bare except since v1.4. Benchmark v3 (15 tasks) and what it caught - v2 scored this server 10/10, which carried no information: every task in it exercised something the server was built around. Five tasks were added because they can fail, and three did while being written -- a hatch could not be measured though the refusal listed HATCH as measurable, the boundary tools and the measure tool disagreed about the same shape (139.2177 vs 139.2699), and a circle stored as two bulged vertices measured 0.0. - Competitor reports are NOT re-scored. They are pinned v1.4 runs against v2 and were never asked these five questions; the chart shows those rows `not run`. - Correctness A/B: 21/24 -> 24/24, zero regressions. Performance, stated plainly The published v1.4 perf report was recorded on CPython 3.14 and the new one on 3.11.15, so the apparent 2-6x speedup is the interpreter, not this release. Re-measured on one interpreter, v1.5.0 is 28% slower creating entities and 22% slower on the 10k roundtrip. Fully attributed: EZDXF_CALL_TIMEOUT=0 restores v1.4.0's exact numbers. That is the deadlock fix being paid for, the knob is documented, and winning it back is on the 1.6 roadmap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 09:45:20 +03:00