# Name to UUID Mapping (Discovery)

Date: 2026-02-10
Branch: name-mapping

Goal: users supply UI names only; provider resolves names to UUID/ID internally in the core CRUD flow. Resource files must remain generated and template-like.

## Architecture sources
- docs/help/architecture-and-methods.md: universal core + CRUD flow, resources generated from YAML.
- docs/ARCHITECTURE_NEW.md: core in universal_rebuild/internal/core, generated resources in internal/resources_gen, shared CRUD in crud.go.
- docs/00_overview/ai_universal_provider_gen.md: core utilities include FindInstanceByDisplayName; resources generated from YAML.
- docs/ai_universal_provider_gen.md: same architecture; core utilities include FindInstanceByDisplayName.

## Mapping rule
- Input: human-readable name as shown in UI (display_name).
- Internal: resolve to instanceUid/UUID using core helper(s) and GetInstances list.
- Resource code must not implement per-resource lookup logic; mapping happens in core/CRUD and is driven by YAML metadata.

## Implications for generator
- service_params_gen should capture refSvcId / param metadata when available.
- tools/gen should use metadata to mark parameters that need name->UUID resolution.
- CRUD layer should resolve names to UUIDs for any param flagged as refSvcId or dataType uuid (when input is not already a UUID).

## Safety
- Backward compatibility: if input already looks like UUID, do not re-resolve.
- Use a single shared resolver in core; no per-resource code changes.