draftwright 0.4.19__tar.gz → 0.4.21__tar.gz

{draftwright-0.4.19 → draftwright-0.4.21}/CHANGELOG.md

@@ -154,6 +154,23 @@
 
 ### Changed
 
+- Production recognition now consumes published `quiddity==0.2.2`. Unified section-recess
+  occurrences and their same-run patterns feed the existing pocket, channel and blind-slot
+  drawing grammar. Original occurrence ownership, independent completeness and explicit
+  unsupported/refusal outcomes follow that single aggregate (#1471).
+- Machine-readable reports and STEP inspection documents advance to schema v2 because their
+  closed producer object now names `quiddity`. The schema-v1 documents remain available for
+  existing files; readers must select the schema using `schema_version` (#1471).
+- Groove membership now retains Quiddity's body-local profile identity. Generated declarations
+  use `profile_group` to associate coaxial grooves and steps without copying provider keys.
+  Omitted steps do not cause a groove to attach to another body (#1471).
+- Known limitations in Quiddity 0.2.2: some mixed-profile/nested pockets, bore-intersected channels
+  and edge-open recesses, and pockets in cylindrical stock can lose automatic annotations.
+  Refusals remain visible in lint and evidence. Regression cases are retained as strict expected
+  failures while upstream [#536](https://github.com/pzfreo/quiddity/issues/536),
+  [#538](https://github.com/pzfreo/quiddity/issues/538) and
+  [#541](https://github.com/pzfreo/quiddity/issues/541) are open.
+
 - Accepted schema-v3 straight or circular `Blend` chains, including concave occurrences, now cross
   a dedicated end-to-end consumer path:
   `BlendFeature`, explicit `Sheet.blend(...)`, executable generated declarations, one
@@ -167,7 +184,7 @@
   also retains circular paths, while raw arbitrarily rotated circular recognition remains an
   upstream limitation (b123d-recognisers#491) (#1433; ADRs 0011, 0013–0017, 0020).
 
-- Draftwright now exactly pins the immutable `b123d-recognisers` 0.4.14 release and advances its
+- The preceding recognition update pinned the immutable `b123d-recognisers` 0.4.14 release and advanced its
   fail-closed capability and inspection joins. `Blend` schema v3 replaces the old flat cylindrical
   fields with exact `StraightBlendPath` and `CircularBlendPath` records and admits proved concave
   and toroidal occurrences; Draftwright preserves those semantics through IR, `Sheet.blend(...)`,

{draftwright-0.4.19 → draftwright-0.4.21}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: draftwright
-Version: 0.4.19
+Version: 0.4.21
 Summary: Automated technical-drawing generation for build123d
 Project-URL: Homepage, https://github.com/pzfreo/draftwright
 Project-URL: Repository, https://github.com/pzfreo/draftwright
@@ -684,13 +684,13 @@ Classifier: Programming Language :: Python :: 3.14
 Classifier: Topic :: Scientific/Engineering
 Requires-Python: <3.15,>=3.10
 Requires-Dist: antlr4-python3-runtime<4.10
-Requires-Dist: b123d-recognisers==0.4.14
 Requires-Dist: build123d-drafting-helpers>=0.14.2
 Requires-Dist: build123d<0.11,>=0.9.0; python_full_version < '3.13'
 Requires-Dist: build123d<0.12,>=0.11; python_full_version >= '3.13'
 Requires-Dist: numpy>=1.24
 Requires-Dist: pillow>=10
 Requires-Dist: pypdfium2>=4
+Requires-Dist: quiddity==0.2.4
 Requires-Dist: reportlab>=4.0
 Requires-Dist: steputils==0.1
 Requires-Dist: svglib>=1.5
@@ -1001,12 +1001,12 @@ builds on three libraries:
 
 ```
 draftwright
-    └── b123d-recognisers          — deterministic geometry recognition
+    └── quiddity          — deterministic geometry recognition
     └── build123d-drafting-helpers  — Dimension, Leader, HoleCallout, …
     └── build123d                   — CAD kernel
 ```
 
-Geometry recognition lives in the Apache-2.0 `b123d-recognisers` package. Draftwright owns
+Geometry recognition lives in the Apache-2.0 `quiddity` package. Draftwright owns
 the per-build recognition cache, record→IR conversion, drafting policy, and linting
 (`linting/`); annotation primitives (`Dimension`, `Leader`, etc.) live in
 `build123d-drafting-helpers` and can be used independently. The compiler is largely converged

{draftwright-0.4.19 → draftwright-0.4.21}/README.md

@@ -301,12 +301,12 @@ builds on three libraries:
 
 ```
 draftwright
-    └── b123d-recognisers          — deterministic geometry recognition
+    └── quiddity          — deterministic geometry recognition
     └── build123d-drafting-helpers  — Dimension, Leader, HoleCallout, …
     └── build123d                   — CAD kernel
 ```
 
-Geometry recognition lives in the Apache-2.0 `b123d-recognisers` package. Draftwright owns
+Geometry recognition lives in the Apache-2.0 `quiddity` package. Draftwright owns
 the per-build recognition cache, record→IR conversion, drafting policy, and linting
 (`linting/`); annotation primitives (`Dimension`, `Leader`, etc.) live in
 `build123d-drafting-helpers` and can be used independently. The compiler is largely converged

{draftwright-0.4.19 → draftwright-0.4.21}/docs/reference/recogniser-capabilities.md

@@ -1,6 +1,6 @@
 # Recogniser capability contract
 
-Draftwright consumes the public capability manifest installed with `b123d-recognisers`; it never
+Draftwright consumes the public capability manifest installed with `quiddity`; it never
 reads a sibling checkout or a package-private file. The matching Draftwright-owned declaration is
 implemented in `draftwright.recogniser_contract` and validated in CI.
 
@@ -14,7 +14,7 @@ library.
 Declared-feature geometry reads use a different public boundary. The installed package's
 inspection manifest format 1 is joined to the separate Draftwright-owned declaration in
 `draftwright.inspection_contract`. That contract admits inspection API major 1 and exactly the
-consumed `b123d_recognisers.inspection` symbol schemas: the five geometry readers, their public
+consumed `quiddity.inspection` symbol schemas: the five geometry readers, their public
 result/error types, the cylindrical surface parameter layout, bevel rejection reasons, and the
 semantic names and units of the Double-D tuple. It also checks the exact installed package
 version. Recognition-family policy does not leak into this smaller measurement contract, and an
@@ -59,7 +59,7 @@ Validation fails closed and names the family and boundary whenever possible:
 ## Adding or changing a recogniser
 
 For an additive field that increments an existing record schema, update the relevant Draftwright
-adapter and declaration when advancing the exact `b123d-recognisers` dependency pin. Tests must
+adapter and declaration when advancing the exact `quiddity` dependency pin. Tests must
 prove the installed schema is accepted while later schemas still fail. The package version belongs
 only in `pyproject.toml` and `uv.lock`; the capability declaration derives runtime identities from
 installed package metadata.
@@ -70,39 +70,58 @@ issue. The contract test derives package record outputs, converter registries, l
 and emitter branches independently, so copying a new name into the declaration alone cannot make CI
 pass.
 
-### Quiddity migration baseline
-
-The first [#1471](https://github.com/pzfreo/draftwright/issues/1471) migration slice tests the
-released Quiddity SectionRecess document against the existing authored pocket corpus. Quiddity is
-pinned in the development dependencies for this comparison. Production continues to use the
-existing recogniser dependency and capability declaration.
-
-The private pocket adapter in `model/detect.py` reads primitive schema-2 occurrence geometry and
-produces the existing `PocketFeature`. It admits principal-axis closed rectangles and open
-rectangular corner/edge chains, preserves the opening direction, and refuses unsupported shapes,
-sloped ends, invalid frames and malformed measurements. An open chain remains edge-anchored; its
-missing boundary is never reconstructed as a physical edge.
-
-`tests/test_issue_1471_section_recess_pockets.py` checks independently authored dimensions,
-opposed and side openings, disconnected bodies, topology variants, the existing drawing path,
-executed generated Sheet scripts and authored omission. The baseline tests for pocket patterns,
-channels and both blind-slot families remain the acceptance floor for their later adapters.
-
-This is preparation for adoption, not a new automatic detection mode. The adapter does not yet
-participate in the production registry, bind occurrence ownership or provide Quiddity-based lint.
-Its comparison drawings use the pinned provider for physical critique. The eventual cutover must
-validate result-local references, bind exact same-run occurrences, migrate patterns and explicit
-refusals, and update independent lint, reports and inspection together. A build already holding an
-aggregate must project it rather than invoke the document builder for a second recognition run.
-
-The comparison pins Quiddity 0.2.1, which fixes
-[Quiddity #505](https://github.com/pzfreo/quiddity/issues/505): support proofs now handle
-build123d 0.10 `ShapeList` boolean results. The pocket corpus exercises this public recognition
-path across the supported Python/build123d matrix before consumer adaptation.
-
-`bosses` is the fully consumed reference family. `repeating-radial-profiles` is the opposite
-reference: it remains geometry-only critique evidence for a separately authored gear declaration,
-with no inferred gear feature added to fill the table.
+### Quiddity 0.2.4 runtime contract
+
+[#1486](https://github.com/pzfreo/draftwright/pull/1486) adopts the published
+`quiddity==0.2.4` package after the migration in
+[#1471](https://github.com/pzfreo/draftwright/issues/1471). Its public `quiddity`, `quiddity.evidence` and
+`quiddity.inspection` surfaces supply recognition, exact occurrence evidence and declared geometry
+reads. There is one recognition aggregate per build; consumers project that result rather than
+calling the document builder to obtain another run.
+
+The manifest has 27 families. One `section-recesses` family replaces the former pockets, pocket
+patterns, channels, rectangular and round-bottom blind slots, passages and prismatic pockets.
+`RecognitionResult.section_recesses` contains the immutable occurrences;
+`section_recess_patterns` relates them by run-local occurrence indices; `section_recess_refusals`
+retains the provider's explicit reasons for refusing candidate geometry. The public document
+builder is a serialization front door, not another feature family or a production rescan.
+
+The shared adapter reads the published frame, profile, run interval and ends and lowers supported
+principal-axis geometry to the existing pocket, channel and blind-slot IR. It preserves the opening
+direction and edge anchoring and rejects malformed records. Supported rounded rectangular pockets
+retain their corner radius, and supported cylindrical-mouth pockets carry maximum-depth intent
+rather than an invented uniform depth. Valid profiles and end shapes outside the drafting grammar
+remain explicit unsupported outcomes, including the two-plane passage cases. Pattern members resolve
+to the original records in the same aggregate before they share a drawing owner. Missing members,
+duplicate indices, cross-body grouping and inconsistent lattice geometry fail closed.
+
+Independent pocket and pattern corpora, channel ownership tests and both blind-slot corpora check
+measurements, public declarations, executed generated code and the placed requirement ledger.
+Recognition refusals retain source provenance and contribute an unsupported outcome without a
+fabricated position. Report and inspection schema v2 name `producer.quiddity`; their v1 schemas
+remain available for existing documents.
+
+The common-part restoration checks the five rounded tuner-jig pockets and their grouped callout,
+corner radii, pitch and absolute locations; pockets cut into cylindrical stock; and the pierced
+U-channel's supported channel measurements. Automatic recognition, declared input and executed
+Sheet scripts retain the supported recess facts. These checks do not turn a successfully rendered
+part into a completeness guarantee.
+
+The preceding Draftwright 0.4.20 / Quiddity 0.2.2 release documented annotation losses for mixed
+and nested pockets ([Quiddity #536](https://github.com/pzfreo/quiddity/issues/536)), bore-intersected
+or edge-open recesses ([#538](https://github.com/pzfreo/quiddity/issues/538)), and pockets in
+cylindrical stock ([#541](https://github.com/pzfreo/quiddity/issues/541)). Those historical limitations
+must not be used to excuse the common cases restored in #1486. Conversely, recognising more source
+profiles does not imply that every profile now has a supported drafting grammar. General complex
+pockets and nonuniform passages can still produce explicit unsupported requirements.
+
+Check the source occurrence outcomes, placed requirements and lint for affected geometry.
+Regression expectations are reassessed per fixture: a restored supported case must pass, while an
+unsupported case must retain its truthful diagnostic rather than an approximate old annotation.
+Recognition, declaration, placement, reporting and coverage checks remain release gates.
+
+`bosses` remains a fully consumed reference family. `repeating-radial-profiles` remains geometry-only
+critique evidence for a separately authored gear declaration, with no inferred gear feature.
 
 ## Hole completeness evidence
 
@@ -205,11 +224,11 @@ independent score.
 
 ## Pocket completeness evidence
 
-The lone `pockets` completeness boundary is independently `supported` from
+The lone-pocket grammar within `section-recesses` is independently `supported` from
 `tests/fixtures/evaluation/corpus-pockets-v1.json`. Ten construction-authored cases contribute 13
 physical pockets, 52 parameter checks and 52 downstream checks. The corpus covers a through-slot
 negative, one off-centre pocket, an edge-anchored corner interruption, equal independent pockets,
-opposite openings, a principal side opening, a PrismaticPocket ownership negative, separate
+opposite openings, a principal side opening, an unsupported polygonal-pocket ownership negative, separate
 compound bodies and a reverse-serialized topology pair.
 
 Identity uses width/long/depth axes, opening sign and physical location; width, length, depth and
@@ -223,7 +242,7 @@ single public `location` authoring unit.
 
 ## Pocket-pattern completeness evidence
 
-The `pocket-patterns` completeness boundary is independently `supported` from
+The pocket-pattern grammar within `section-recesses` is independently `supported` from
 `tests/fixtures/evaluation/corpus-pocket-patterns-v1.json`. Seven construction-authored cases
 cover 30° linear and rectangular-grid positives, the two-member threshold, unequal-spacing
 ambiguity, a plain negative, an axis-aligned underside compound case and a reverse-serialized
@@ -260,6 +279,14 @@ its diameter is drafted once. Removing provider grooves, changing width/diameter
 corrupting declaration or generated code, or severing either measurement claim reduces the
 corresponding independent layer.
 
+Quiddity's optional `Groove.profile` key now identifies the exact body-local turned profile.
+The compiler and independent axial/step ledgers use that key and still cross-check the published
+axis line and axial band. Missing profile identity retains the geometric ambiguity refusal;
+a missing profile in an authored subset cannot redirect the groove to another coaxial body.
+Generated declarations replace the provider key with the same `profile_group` token used for the
+owning steps. The keyed nested-body and omission checks live in
+`tests/test_issue_1471_groove_profile.py`; they supplement the unchanged authored groove corpus.
+
 ## Rectangular-pad completeness evidence
 
 The `rectangular-pads` completeness boundary is independently `supported` from
@@ -535,27 +562,10 @@ position. Removing any one of those five physical facts produces
 independently authored rectangular-pad detection/parameter/downstream benchmark corpus required
 before claiming family-level completeness.
 
-## Recognisers 0.4.10 adoption and blind-slot boundary
-
-Draftwright exactly pins `b123d-recognisers==0.4.10`. The 28 family record schemas already
-consumed from 0.4.9 are unchanged. The inspection namespace remains format 1 / API major 1;
-Draftwright advances its exact package join without widening the set of inspection symbols it
-consumes. The additive `b123d_recognisers.evidence` API is public provider capability, but this
-adoption does not consume it before a concrete correspondence slice demonstrates that need.
-
-Unchanged record schemas do not mean byte-identical recognition output. The 0.4.10 provider closes
-slot-depth, subdivided paired-ramp/AngledStep, and noisy stubby-pocket gaps and fixes Double-D/Hole
-ownership, external-cone countersink false positives, Plate tie covariance, and turned-step
-translation covariance. Draftwright accepts those public aggregate outcomes: its consumer tests pin
-that an external cone no longer creates a countersink requirement and that an edge-open rectangular
-recess now yields to the dedicated blind-slot owner instead of retaining a false `Pocket` callout.
-The provider's immutable
-[0.4.10 release](https://github.com/pzfreo/b123d-recognisers/releases/tag/v0.4.10) owns the lower-level
-recognition predicates and counterexamples; Draftwright does not duplicate private provider
-algorithms to restate them.
-
-The release adds `rectangular-blind-slots` and `round-bottom-blind-slots` to the one aggregate.
-Both now have dedicated Draftwright feature types and public Sheet words. The rectangular family
+## Blind-slot drawing grammar
+
+Quiddity publishes both blind-slot shapes as `SectionRecess` occurrences in the unified inventory.
+Their consumer contracts remain distinct. Both now have dedicated Draftwright feature types and public Sheet words. The rectangular family
 uses `RectangularBlindSlotFeature` and
 `Sheet.rectangular_blind_slot(...)` declaration, generated-code round trip and solver-owned
 `OPEN SLOT width × capped-run × depth DEEP` callout. Its axes and opening signs remain structural
@@ -583,14 +593,11 @@ with exact full-record correspondence and parameter/outcome provenance under the
 rules as the rectangular family. It now participates independently in `audited_score`; ordinary
 slots, pockets, channels and rectangular blind slots do not share ownership.
 
-## Recognisers 0.4.14 adoption and path-complete Blends
+## Path-complete Blend drawing grammar
 
-Draftwright exactly pins `b123d-recognisers==0.4.14`; the provider family count remains 33 and
-the inspection API remains format 1 / major 1. The fail-closed record join now accepts `Blend`
-schema v3 with nested `StraightBlendPath` and `CircularBlendPath` schema-v1 records. It also
-accepts `PassageEnds`, `PassageSection`, and `SectionPassage` schema v2. Passage remains explicitly
-unsupported under #1245: accepting its released structural schema does not invent an IR feature,
-Sheet declaration, or completeness credit.
+Quiddity 0.2.2 retains `Blend` schema v3 with nested `StraightBlendPath` and
+`CircularBlendPath` schema-v1 records. The installed manifest and the independently declared
+consumer schemas must agree before these records can reach drawing generation.
 
 The supported Blend adapter preserves the complete discriminated path. Straight occurrences keep
 their canonical line direction and anchor; circular occurrences keep their centre, canonical
@@ -618,12 +625,13 @@ the complete canonical `axis_direction`; `Sheet.blend(...)`, generated replay an
 solver-owned `n× R` leader preserve it without pretending it is a legacy Fillet. Exact occurrence
 and measurement provenance place Blend in `audited_score`.
 
-`oriented_slots` and `oriented_slot_patterns` remain separately registered as undecided under
-#1430. Their real occurrences are visible in `unscored_recognized_families`, but contribute no
-invented requirement. The free-axis slot record retains vector width/long directions and its
-authoritative `SectionPassage` source; array/grid records retain those member identities and their
-vector lattice. Coercing either into principal-axis `SlotFeature` / `SlotPatternFeature` would
-discard that contract, so no Sheet word or completeness claim exists for them on main.
+Standalone `oriented_slots` are supported through dedicated vector-valued IR, the public
+`Sheet.oriented_slot(...)` declaration, executable generated code, two compiler-approved width/length
+requirements, and solver-owned leaders. Exact run-local identity binds each accepted record to its
+IR owner. Array/grid members are excluded by exact provider-record membership and retain the
+still-deferred `oriented-slot-patterns` policy; they are not emitted as competing singletons.
+The shared requirement ledger feeds both lint and reports. Malformed or copied pattern authority
+is refused rather than reconstructed from equal geometry.
 
 The existing schema-v1 `PairedRampStep` record is unchanged, while 0.4.12 expands provider
 recognition to shallow nonzero ramp pairs. A released shallow specimen now crosses the already
@@ -657,7 +665,7 @@ height/shoulder projection. The aggregate face-level and riser families remain s
 outcome says only that each raw evidence record is not itself an independent inferred feature or
 completeness requirement. It adds no Sheet word, IR adapter, drawing ink, or provider API.
 
-## Recognisers 0.4.9 prepared frame boundary
+## Historical: recognisers 0.4.9 prepared frame boundary
 
 Draftwright's 0.4.9 boundary accepted `RiserEvidence` v2,
 `TurnedStep`/`TurnedProfile` v2, and the nested `TurnedProfileKey` v1. These records preserve
@@ -705,51 +713,26 @@ Sheet declaration, generated code or annotation, and emits
 occurrence contributes one `unsupported` completeness requirement. Issue #1247 records this
 consumer decision.
 
-## Prismatic-pocket boundary
-
-The installed aggregate reconciles the two pocket inventories before Draftwright sees them. A
-candidate reported by both direct recognisers yields to the supported `Pocket` record;
-`RecognitionResult.prismatic_pockets` therefore contains occurrences not owned by `Pocket`.
-Draftwright consumes that aggregate policy and does not repeat provider reconciliation. This is an
-ownership statement, not a shape classification: for example, a rotated four-sided recess can
-remain a `PrismaticPocket` when the axis-paired `Pocket` recogniser does not accept it.
-
-The remaining `PrismaticPocket.section` may be any planar polygon. The rectangular pocket grammar
-`W × L × D DEEP` is false for a triangle, while an across-flats callout applies only to selected
-regular polygons and cannot represent the general record. Draftwright therefore retains the family
-disposition as `unsupported`: it creates no inferred IR feature, Sheet declaration, generated code,
-or drawing annotation. Each aggregate occurrence instead emits
-`prismatic_pocket_requirement_unsupported` at warning severity and contributes one `unsupported`
-completeness requirement. Exact mouth-to-section correlation replaces the generic unsupported-
-profile warning only for that occurrence, so an unrelated unrecognised profile remains visible.
-
-## Passage compatibility boundary
-
-The installed `b123d-recognisers==0.4.14` release contains the `passages` family introduced
-in 0.2.6. Version 0.4.0 made `SectionPassage` the authoritative physical output; 0.4.14 publishes
-its nested schema v2 and retains `Passage` as a compatibility projection. Draftwright declares all
-six public and nested record schemas exhaustively but deliberately keeps the family `unsupported`,
-with the drafting decision recorded by issue #1245. This is a truthful consumer disposition: both
-aggregate inventories remain visible, but only authoritative `section_passages` contributes an explicitly
-`unsupported` completeness requirement. Draftwright does not invent an IR feature, DSL
-declaration, generated code, or drawing annotation for either inventory.
-
-The 0.4 contract is explicit:
-
-- `SectionPassage` will be the authoritative physical output and aggregate census source;
-- legacy `Passage` values will be an accepted-only compatibility projection;
-- `recognise_passages(..., ledger=...)` will be a fail-loud unavailable compatibility operation;
-- the writer-free `recognise_passages` name will remain public but non-authoritative; and
-- rich split-junction passages can supersede a Slot claim, moving physical ownership to the
-  unsupported Passage family through `SLOT_SUPERSEDED_BY_PASSAGE`.
-
-The exact 0.4.14 pin, manifest-v2 validator and explicit unsupported inventories make that limitation
-fail-visible rather than silently treating rich passages as supported. Draftwright deliberately
-does not claim that a regular-polygon `HEX … A/F THRU` callout covers the complete line/arc section
-schema. Each authoritative `RecognitionResult.section_passages` occurrence therefore emits
-`passage_requirement_unsupported` at warning severity and contributes an `unsupported` requirement
-to the completeness component. The accepted-only legacy `.passages` projection contributes neither
-a second issue nor a second requirement. Issue #1245 records this consumer decision.
+## Unsupported polygonal-pocket and passage grammar
+
+Quiddity's unified `SectionRecess` inventory carries both supported and unsupported profile
+geometry. Draftwright selects its existing drawing grammar from the exact public section and ends;
+it does not rerun provider recognition or retain a second legacy pocket/passage inventory.
+
+A general polygonal recess has no truthful rectangular `W × L × D DEEP` callout. A general line/arc
+through-opening likewise cannot be represented by a regular-polygon `HEX … A/F THRU` callout.
+These occurrences retain the decisions recorded by #1246 and #1245: no inferred IR feature, public
+declaration, generated feature or annotation is invented. Each occurrence instead contributes one
+`unsupported` completeness outcome and its corresponding `prismatic_pocket_requirement_unsupported`
+or `passage_requirement_unsupported` warning. Exact mouth-to-section correlation can replace a
+generic unsupported-profile warning for that occurrence; unrelated unrecognised geometry remains
+visible. The old accepted-only Passage projection no longer exists and cannot add another count.
+
+Provider refusals are distinct from accepted geometry outside the drawing grammar. Each exact
+`SectionRecessRefusal` is retained with its reason and original evidence, emits
+`section_recess_recognition_refused`, and carries no fabricated feature position. A valid unmatched
+supported recess still contributes its full independent requirement count. A malformed recess
+cannot establish a trustworthy family or denominator and is rejected at intake.
 
 ## Step families introduced in recognisers 0.4.6
 

{draftwright-0.4.19 → draftwright-0.4.21}/docs/reference/sheet.md

@@ -4,8 +4,146 @@
 are documented here because they are part of normal use even though their Python names begin
 with an underscore.
 
+## Grooves on coaxial bodies
+
+When different turned bodies share an axis line, give their steps distinct `profile_group`
+values and use the owning body's value on `s.groove(..., profile_group="outer")`.
+The token associates features; it does not specify an annotation position or add a measurement.
+Generated scripts preserve this association using Draftwright-owned tokens instead of provider
+keys. A groove can still be declared when the authored set omits all of that body's steps.
+
+## Checking dimension placement rules
+
+Call `handle.dimension_ids()` to find the measurements a declared feature exposes, then
+query a measurement before choosing its placement controls:
+
+```python
+options = s.dimension_options(hole, "bore.diameter")
+# options["placements"] contains pairs accepted by the planner's placement rules.
+# None means leave that override unspecified.
+
+check = s.validate_dimension(hole, "bore.diameter", view="plan", side="left")
+if check["supported"]:
+    s.dimension(hole, "bore.diameter", view="plan", side="left")
+else:
+    print(check["issues"], check["options"])
+```
+
+Both queries return versioned JSON-ready dictionaries without recording intent, preparing the
+Sheet, recognising geometry or rendering. Use complete view/side pairs: a side supported in one
+view may be unavailable in another. The `axis` argument follows `dimension()`'s parameter-variant
+rules; full parameter ids already name their variant. Location intent currently admits no view
+or side override. Invalid references, unsupported controls and unsupported placement pairs have
+separate structured refusal codes in `validate_dimension()`; `dimension_options()` raises on an
+invalid reference.
+
+Hole-size callouts in the plan and side views accept `left` or `right`. The overall
+envelope height accepts `left` or `right` in the front view. These hints can separate
+hole sizes from vertical location dimensions without moving annotation coordinates:
+
+```python
+sheet.dimension(lower_hole, "bore.diameter", side="left")
+sheet.dimension(upper_hole, "bore.diameter", side="left")
+sheet.dimension(envelope, "height.length", side="left")
+sheet.dimension(lower_hole, "location")
+sheet.dimension(upper_hole, "location")
+```
+
+Each side belongs to its named view: the front-view height and side-view hole sizes
+occupy different boundaries. The layout reserves space for the left height and short
+step rises together before choosing scale and page. The shared solver places the
+annotations within those boundaries; generated scripts retain the authored sides.
+An explicit side is a constraint: an infeasible placement reports the affected
+measurement instead of silently choosing the opposite boundary. Repair preserves an
+authored overall-height side, including after a label adjustment.
+
+The explicit `single_dimension_placement_rules` scope means `supported` reports acceptance by
+the current planner placement rules. Both documents set `requires_build_validation: true`:
+whole-part classification can select a different renderer, so this query does not prove actual
+rendered support. For example, a boss on a turned part can use a different diameter renderer
+from a boss on a prismatic part. Agreement with other authored dimensions, visibility in an
+authored view set, available space, completeness and collision-free placement also require a
+build. Build and lint still assess the resulting Sheet. A
+query never replaces an existing dimension request. Keep the original feature handle for edits;
+these reports do not introduce persistent feature identities or new lane, route or pin controls.
+
+## Selecting a hole location component
+
+Use `location` alone to request the usual location set. To select one component of a hole
+group or pattern, pair its declared member index with the measured world axis:
+
+```python
+options = sheet.dimension_options(holes, "location")
+print(options["location_components"])  # valid member/axis pairs and their parameter ids
+sheet.dimension(holes, "location", member=1, axis="y")
+```
+
+Member indices start at zero and refer to the declared `members` tuple. A singleton hole
+has member 0. The axis is transverse to the hole's own axis: an X-directed hole can have
+Y and Z location dimensions. A bolt-circle pattern also accepts `member="centre"`.
+Both selectors are required for a fine request; invalid members or axes are refused.
+The existing `validate_dimension()` query accepts the same selectors.
+
+The coarse pattern request keeps its automatic anchor policy: the member nearest the
+datum, or the centre of a bolt circle. Adding a fine request selects that extra component
+without selecting its sibling axis. Repeating a request does not duplicate a measurement.
+Generated scripts carry the member and axis so removing one location declaration omits
+that component. Coincident dimensions can share one mark while recording every approved
+owner.
+
+These indices address one declaration and its generated script. They do not establish
+correspondence across unrelated recognition runs. The shared solver still chooses where
+to place the dimension; location selection supplies no page coordinates.
+
 ## Sheet
 
+### Comparing measurements after a declaration edit
+
+`compare_measurements()` compares named compiled measurements, including their owner,
+parameter, nominal value, tolerance, directional span and rendered claim text. Linear
+dimensions also retain their measured path lengths in model units, so exchanging labels
+between two spans cannot hide behind an unchanged label multiset. Recorded per-annotation
+spans and location components also distinguish equal-valued axes under a coarse parameter
+id. These are provenance claims; independent lint must still check physical targets.
+Reuse the feature objects in a declaration when editing placement intent:
+
+```python
+from dataclasses import replace
+from draftwright import build_drawing
+from draftwright.audit import compare_measurements
+
+original_model = sheet.model()
+edited_model = replace(
+    original_model,
+    authored_dimensions=tuple(
+        replace(request, side="left") if request.role == "height.length" else request
+        for request in original_model.authored_dimensions
+    ),
+)
+before = build_drawing(part, model=original_model)
+after = build_drawing(part, model=edited_model)
+result = compare_measurements(before, after)
+print(result["status"], result["lost"], result["changed"], result["unknown"])
+```
+
+The status is `preserved`, `changed` or `unknown`. An unresolved owner or unconfirmed
+claim prevents `preserved`. For an in-place edit, capture
+`before = drawing.measurement_snapshot()` before changing the drawing, then compare
+that snapshot with the edited drawing. Snapshots retain process-local feature references.
+
+Separately rebuilt declarations do not acquire correspondence from equal geometry or
+inventory order. If the caller knows the correspondence, pass
+`feature_pairs=((old_feature, new_feature), ...)`. Each pair must name exact owners in
+the respective snapshots and the correspondence must be one-to-one. These are caller
+assertions; the comparison checks measurement meaning under them. Output owner numbers
+are positions in the before snapshot for presentation, not durable identities.
+
+`diff_builds()` includes this result as `measurement_comparison` and detects same-kind
+substitutions between shared declared owners. A clear annotation diff can still have
+unknown measurement correspondence. Use independent `lint_summary()["quality"]`
+evidence alongside the comparison: named-measurement preservation does not establish
+physical completeness, pin preservation or release readiness.
+
 ::: draftwright.sheet.Sheet
     options:
       filters: public
@@ -156,6 +294,13 @@ explicit declaration has the same exact occurrence identity and view routing as
 record.
 Generated Sheet code preserves every field.
 
+Straight-path radius leaders target curved boundaries of the physical cylindrical patch.
+Their `at` value locates the analytic axis, not the arrow tip. If a declared support is missing
+or ambiguous, the engine reports `blend_dropped`. Physical lint reports
+`radius_leader_target_mismatch` when a placed tip misses its trimmed boundary, or
+`radius_leader_target_unverifiable` when that boundary cannot be established; these findings
+lower fidelity. Circular-path toroidal blends retain their separate tangency selection.
+
 These are part-space feature coordinates, never page positions. The annotation placement solve
 owns the final leader and label coordinates. The word is explicit-only because detached surface
 geometry cannot prove a complete chain or the provider aggregate's Fillet precedence.
@@ -303,3 +448,13 @@ with the canonical feature diameter, using the same rule as planning. A larger m
 keeps the original source value and identity in a blocked dimension; it does not replace
 the canonical value or crash planning. Generated Sheet scripts retain the blocker, and
 `authored_dim_source_unresolved` reports the withheld source dimension through lint.
+
+### Oriented through-slots
+
+`Sheet.oriented_slot(...)` declares a rectangular through-slot with explicit width, long and
+run directions and its retained passage geometry. Its two independently addressable
+measurements are `oriented_slot_width.length` and `oriented_slot_length.length`; generated
+Sheet scripts preserve those directions and the passage. The current drawing grammar requires
+both run ends to be open and perpendicular to the run. Automatic conversion rejects a source
+with a nonzero end-plane gradient, because the IR cannot retain that slope and a flat opening
+would put the leader on the wrong physical rim.

{draftwright-0.4.19 → draftwright-0.4.21}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "draftwright"
-version = "0.4.19"
+version = "0.4.21"
 description = "Automated technical-drawing generation for build123d"
 readme = "README.md"
 license = { file = "LICENSE" }
@@ -18,7 +18,7 @@ dependencies = [
     "build123d>=0.9.0,<0.11 ; python_full_version < '3.13'",
     "build123d>=0.11,<0.12 ; python_full_version >= '3.13'",
     "build123d-drafting-helpers>=0.14.2",
-    "b123d-recognisers==0.4.14",
+    "quiddity==0.2.4",
     "numpy>=1.24",
     # PNG raster export (SVG→PDF→PNG). Both permissively licensed (Pillow HPND; pypdfium2
     # Apache-2.0 wrapping Google PDFium BSD-3) and ship pre-built wheels with NO native system
@@ -81,13 +81,15 @@ include = [
 [tool.pytest.ini_options]
 testpaths = ["tests"]
 timeout = 300
-# `slow` covers the heavy end-to-end builds over the large NIST CTC fixtures
+# `slow` covers end-to-end integration builds, including the large NIST CTC fixtures
 # (minutes each), deselected by default. `smoke` is a curated, build-light subset
 # (~30 s) for a quick local "did I break something obvious" check — run it with
 # `uv run pytest -m smoke`. The default run is the full fast tier (`-m 'not slow'`,
-# ~8 min); CI owns that plus the slow tier across the OS/Python matrix.
+# runtime depends on worker count). CI runs one real-part canary before merge,
+# the full slow tier after merge, and the fast tier across its compatibility matrix.
 markers = [
-    "slow: heavy end-to-end CTC fixture builds (deselected by default)",
+    "slow: end-to-end integration builds, including CTC fixtures (deselected by default)",
+    "real_part_canary: bounded real STEP semantic/export gate, selected once in PR CI",
     "smoke: curated build-light subset for a fast local check (~30 s)",
     "unit: pure-logic inner-loop tier — constructs NO OCC geometry (enforced by conftest, #656)",
 ]
@@ -169,8 +171,6 @@ dev = [
     "pytest-split>=0.8",
     "pytest-timeout>=2",
     "pytest-xdist>=3",
-    # Released provider used by the migration parity tests; production remains on 0.4.14.
-    "quiddity==0.2.1",
     "ruff>=0.4",
     "tomli>=2; python_version < '3.11'",
 ]