Using checkbox tree control

AGENTS.md

@@ -19,14 +19,15 @@ Core files:
 - `src/lib/feature-types.js`: feature-kind labels, geometry constraints, detail field schemas, and style defaults.
 - `src/lib/yard-features.js`: typed feature classes, stable ids, groups, parent-child relationships, schema metadata, GeoJSON export.
 - `src/data/*.js`: yard content split by domain.
-- `src/main.js`: Leaflet map, legend, popup rendering.
+- `src/main.js`: Leaflet map, visibility controls, popup rendering.
 
 Top-level exported data shape from `src/data/yard.js`:
 
 - `type: "FeatureCollection"`
-- `schemaVersion: 2`
+- `schemaVersion: 4`
 - `lifecycleFields: { plantedDate: "date", removedDate: "date" }`
 - `featureTypes: [...]`
+- `featureCategories: [...]`
 - `features: [...]`
 - `groups: [...]`
 
@@ -53,8 +54,8 @@ Each feature currently exports:
 3. Local rotation is per anchor.
    `offset(...)` reads `assumedNorthClockwiseDegrees` from the anchor point used as the origin. Do not reintroduce a global lot rotation unless there is a strong reason.
 
-4. Grouping and parent-child metadata are already part of the data model.
-   Future visibility controls should consume `groupIds` and `parentId` rather than inventing a second relationship system.
+4. Feature categories, grouping, and parent-child metadata are part of the data model.
+   Top-level visibility categories come from `featureCategories` and each feature type's `categoryId`. Visibility controls consume those schemas and `groupIds` rather than inventing a second relationship system.
 
 5. The GPKG was only a seed source.
    The app does not depend on GIS tooling at runtime.
@@ -70,14 +71,13 @@ Each feature currently exports:
 ## What is already modeled
 
 - Porch and deck are children of the main house and also part of the `House Parts` group.
-- Medora junipers are part of the `Juniper Trees` group.
+- Medora junipers are bushes in the `Junipers` group.
 - A test tree exists that is offset from the top-left lot corner using per-anchor rotation.
 
 ## Likely next steps
 
-1. Add show/hide controls driven by `yardGeoJSON.groups` and possibly `parentId`.
-2. Decide whether toggles should be by feature kind, by group, by parent object, or a combination.
-3. If closer basemap zoom fidelity matters, migrate from raster OSM tiles to a vector tile or self-hosted basemap.
+1. Decide whether parent-child feature relationships should also affect the visibility hierarchy.
+2. If closer basemap zoom fidelity matters, migrate from raster OSM tiles to a vector tile or self-hosted basemap.
 
 ## Useful validation commands