CAD Architecture Philosophy

Goal

Daedalus CAD migration follows an incremental architecture split so behavior remains stable while responsibilities move out of D_Daedalus.vue.

Layered Direction

1. External format layer
   • DXF parser/serializer (D_dxfIO.ts) handles only low-level DXF tokens/entities.
2. Adapter layer
   • DXF adapter (cad-core/adapters/dxf/dxfAdapter.ts) converts between DXF entities and internal CAD entities.
3. Internal model layer
   • CAD model (cad-core/model/cadTypes.ts) is the canonical geometry contract.
4. Document state layer
   • CAD document store (stores/cadDocumentStore.ts) holds entities, viewport, active tool, layers, and selection.
5. Renderer layer
   • Renderer adapters (cad-core/renderers/*) convert CAD model to screen primitives.
6. UI orchestration layer
   • D_Daedalus.vue composes commands, tool flows, and interaction state.

Rules For Incremental Migration

• Keep existing UX and command behavior unchanged during each step.
• First mirror data from UI state to the CAD store (read-only connection).
• Then replace template math with renderer-produced primitives in small areas.
• Keep low-level file format details out of UI components.
• Keep renderer stateless and deterministic from document + viewport inputs.

Current Practical Contract

• DXF import/export in D_Daedalus.vue goes through the DXF adapter, not direct low-level mapping.
• ARC is supported end-to-end in DXF low-level and adapter mapping.
• Store integration currently starts from these read-only paths:
  • entities
  • viewport
  • active tool
• Screen-coordinate preview calculations are being moved from template worldToScreen calls to SvgRendererAdapter output.
• QuickDraw snap is now in a hybrid phase:
  • Existing domain-specific quick candidates remain for compatibility.
  • Core snapEngine candidates are merged in parallel and ranked together.
  • Snap tolerance is passed from EditorState-style settings (tolerancePx) in screen pixels.
  • In hover/commit resolution, legacy basic object snap branches are selectively suppressed and replaced by core candidates for compatible entities.
  • Legacy-only branches remain for symbol/ellipse-specific snapping behavior.

Snap Design Contract

• Snap resolves against generated candidates, not entity types directly.
• Candidate coordinates are always world-space; acceptance is screen-space distance based.
• resolveSnapCandidates is the preferred integration entry for UI layers that need candidate cycling/preview.
• resolveSnap is a convenience wrapper returning the top-ranked candidate only.

Why This Shape

• Risk reduction: large monolith can be decomposed without a full rewrite.
• Testability: adapters and renderers can be verified independently of UI events.
• Extensibility: 3D renderer abstraction can evolve without touching DXF or command logic.
• Portability: CAD model contracts are framework-agnostic.

Next Steps

1. Continue shrinking legacy candidate generation by moving remaining compatible nearest/arc paths to core entities.
2. Promote store from mirrored read-only source to authoritative document source.
3. Introduce command-side operations over CAD entities directly.
4. Add targeted tests for adapter round-trip and snap candidate ranking behavior.