draftwright 0.4.19__tar.gz → 0.4.20__tar.gz

{draftwright-0.4.19 → draftwright-0.4.20}/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.20}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: draftwright
-Version: 0.4.19
+Version: 0.4.20
 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.2
 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.20}/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.20}/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,51 @@ 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.2 runtime contract
+
+[#1471](https://github.com/pzfreo/draftwright/issues/1471) moves production recognition to the
+published `quiddity==0.2.2` package. 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. Unsupported profiles and sloped ends
+remain explicit unsupported outcomes; they receive no invented dimensions. 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 0.4.20 release includes these known Quiddity 0.2.2 limitations:
+
+- Some mixed line/arc and nested pockets, including the tuner-jig and dense #915 STEP fixtures,
+  are refused: [Quiddity #536](https://github.com/pzfreo/quiddity/issues/536).
+- Bores intersecting channel walls, floors or an edge-open recess can prevent recognition:
+  [Quiddity #538](https://github.com/pzfreo/quiddity/issues/538).
+- A pocket cut into cylindrical stock can be refused:
+  [Quiddity #541](https://github.com/pzfreo/quiddity/issues/541).
+
+These cases can lose automatic annotations that the previous provider emitted. Check recognition
+refusals and lint when using affected geometry. An explicit refusal makes the limitation visible;
+it does not establish drawing completeness. The regression cases remain in the suite as strict
+expected failures linked to the upstream issues. Other 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 +217,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 +235,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 +272,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 +555,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 +586,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 +618,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 +658,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 +706,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.20}/docs/reference/sheet.md

@@ -4,6 +4,49 @@
 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.
+
+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.
+
 ## Sheet
 
 ::: draftwright.sheet.Sheet
@@ -156,6 +199,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 +353,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.20}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "draftwright"
-version = "0.4.19"
+version = "0.4.20"
 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.2",
     "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
@@ -170,7 +170,6 @@ dev = [
     "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'",
 ]

{draftwright-0.4.19 → draftwright-0.4.20}/src/draftwright/_core.py

@@ -25,8 +25,8 @@ from types import SimpleNamespace
 from typing import TYPE_CHECKING, Literal
 
 if TYPE_CHECKING:
-    from b123d_recognisers import RecognitionResult, TurnedProfile
-    from b123d_recognisers.evidence import RecognitionEvidence
+    from quiddity import RecognitionResult, TurnedProfile
+    from quiddity.evidence import RecognitionEvidence
 
     from draftwright.compose import StripDepths
     from draftwright.recognition_ownership import RecognitionOwnership
@@ -1135,8 +1135,6 @@ class Analysis:
     patterns: list
     bosses: list  # external bosses (recognise_bosses), detected once — the one inventory (#244)
     slots: list
-    pockets: list
-    pocket_patterns: list
     pads: list  # geometry-derived rectangular-pad coverage inventory (#885)
     z_diams: list[float]
     cross_diams: list[float]

{draftwright-0.4.19 → draftwright-0.4.20}/src/draftwright/_geometry.py

@@ -18,8 +18,8 @@ from dataclasses import dataclass
 from decimal import Decimal
 from inspect import signature
 
-from b123d_recognisers import full_cylinders
-from build123d import Compound, Shape
+from build123d import Compound, GeomType, Shape
+from quiddity import full_cylinders
 
 _log = logging.getLogger(__name__)
 
@@ -53,7 +53,7 @@ _OD_FILL_MIN = 0.8
 _OD_AXIS_TOL = 0.05
 _COAXIAL_TOL = 1e-3
 
-# ``b123d-recognisers`` publishes independently quantised public measurements at six
+# ``quiddity`` publishes independently quantised public measurements at six
 # significant figures. These model-neutral bounds reconstruct the possible geometry from the
 # published decimal cells without coupling either the IR waist or linting to provider internals.
 _PROVIDER_SIGNIFICANT_FIGURES = 6
@@ -1181,3 +1181,51 @@ def _segments_cross_or_overlap(a1, a2, b1, b2) -> bool:
         if on_segment(point, first, second) and not (same(point, first) or same(point, second)):
             return True
     return False
+
+
+def _straight_blend_faces(blend, cylinders, radius, *, defining_faces=None):
+    """Use exact occurrence faces, or one unambiguous declared cylinder support."""
+    if defining_faces is not None:
+        return tuple(defining_faces)
+    origin = blend.frame.origin
+    direction = blend.axis_direction
+    length = math.hypot(*direction)
+    normal = tuple(value / length for value in direction)
+    matches = []
+    for family in cylinders:
+        for cylinder in family:
+            if abs(cylinder["diameter"] / 2 - radius) > 2e-3:
+                continue
+            if cylinder["external"] != (blend.side == "convex"):
+                continue
+            axis = cylinder["dir_xyz"]
+            alignment = abs(sum(normal[i] * axis[i] for i in range(3)))
+            delta = tuple(origin[i] - cylinder["axis_xyz"][i] for i in range(3))
+            along = sum(delta[i] * axis[i] for i in range(3))
+            radial = math.hypot(*(delta[i] - along * axis[i] for i in range(3)))
+            station = sum(origin[i] * axis[i] for i in range(3))
+            if (
+                abs(alignment - 1) <= 2e-6
+                and radial <= 2e-3
+                and cylinder["s_lo"] - 2e-3 <= station <= cylinder["s_hi"] + 2e-3
+            ):
+                matches.append(cylinder["face"])
+    return tuple(matches) if len(matches) == 1 else ()
+
+
+def _blend_profile_arcs(faces, radius):
+    """Curved boundaries of the physical cylindrical patch carrying this radius.
+
+    An oblique end trim can be a spline in 3-D while its end-on profile is still a radius
+    arc. Validate the cylinder's radius and retain the actual boundary curve, never rebuild
+    an untrimmed mathematical circle. Straight generatrices are not radius targets.
+    """
+    return tuple(
+        edge
+        for face in faces
+        if face.geom_type == GeomType.CYLINDER
+        and face.radius is not None
+        and abs(face.radius - radius) <= 2e-3
+        for edge in face.edges()
+        if edge.geom_type != GeomType.LINE
+    )