# `fret-core`
Portable, backend-agnostic core vocabulary for the Fret workspace.
This crate is intentionally **small** and **dependency-light**. It defines:
- stable IDs (windows, nodes, pointers, resources),
- geometry and pixel units,
- the cross-platform input/event model,
- scene recording primitives (portable display list),
- portability/capability-facing service traits and snapshots (no OS bindings).
Non-goals:
- no `wgpu`, no `winit`, no platform backends,
- no async runtime coupling (Tokio, etc.),
- no UI policy (that lives in ecosystem crates).
## Module ownership map (v1)
This is a living “where should this code go?” map.
- `ids` — stable identity types (`NodeId`, `AppWindowId`, `PointerId`, `ImageId`, ...)
- `geometry` — `Px`, `Point`, `Rect`, `Size`, transforms, and geometry helpers
- `input` — portable input events (`Event`, pointer/key/IME), plus normalization helpers
- `scene` — portable scene recording (`Scene`, `SceneOp`) consumed by the renderer layer
- `semantics` — portable semantics snapshot types (A11y bridge contract surface)
- `dock` — docking model/ops/persistence vocabulary (policy lives in ecosystem)
- `viewport` — viewport mapping types used for Tier A embedding (`RenderTargetId`, mapping helpers)
- `services` — portable service traits (host-provided, backend-agnostic)
- `window` — window metrics and coordinate space vocabulary (no windowing backend here)
- `file_dialog`, `svg`, `text`, `image`, `streaming`, `render_text` — portable data/config types used across layers
- `time`, `utf`, `cursor`, `layout_direction`, `panels`, `vector_path` — small supporting modules
If you need to add something new:
1. Put it in the narrowest module that “owns” the concept.
2. Prefer a new submodule over growing an unrelated one.
3. Avoid re-exporting it from `lib.rs` unless it is part of the stable vocabulary.