feat: shared reference library of channels/TGs/contacts (outside any one codeplug)

[pskillen]

Problem

Operators frequently want to reuse the same building blocks across multiple codeplugs without re-entering them each time. For example:

1. A user downloads a list of, say, all repeaters in Central Scotland from a known source (e.g. RepeaterBook), or writes their own list by hand.
2. They don't want all of those in one codeplug — some belong in one project, others in a different project.
3. So we need a place to keep a reusable pool of building blocks that sits outside any single codeplug/project.
4. When the user builds a codeplug, they can either add their own project-specific items or simply pick from this shared pool.

Intended outcome

A shared reference library — a local database, held in browser LocalStorage, of reusable building blocks that exists independently of any one codeplug/project:

• Channels (first-class).
• DMR talk groups.
• DMR contacts (potentially — may be a follow-on).

Users can manage this library (import / create / edit / delete) and then reference items from it when designing any codeplug.

Core principles

1. Strictly optional

The library must be entirely optional. A user must be able to create, import, manage, and delete channels / zones / talk groups / contacts within a single codeplug without ever touching this feature. Nothing about it should get in the way of someone who just wants to work on one project.

2. Seamless and obvious when used

When a user does use the library, the integration should be seamless but unambiguous. In any list (e.g. a list of channels) it must be visually clear which items are shared (sourced from the library) and which are specific to the current project.

3. Edit-or-clone on shared items

If a user tries to edit a shared/library object in the context of a codeplug, prompt them to choose between:

• Edit the shared object — the change propagates everywhere it's referenced; or
• Clone into this codeplug — break the link and create a project-local copy that's safe to diverge.

Portability: YAML import/export of the library

The library is operator data in its own right and must be portable independently of any codeplug:

• Native YAML import/export of the library itself — a user can export the whole shared library (channels, TGs, and contacts where supported) to our native YAML format and import it into another browser/device, with identical resulting library state (mirrors the per-codeplug round-trip goal in feat: native YAML import and export #10).
• Keep this separate from per-codeplug YAML (feat: native YAML import and export #10): the library is its own document/namespace, so users can move their reusable pool around without dragging a specific project with it (and vice versa).
• Cloud read/write when implemented: once the cloud-storage tickets land, the library should be openable/savable directly to/from Dropbox (feat: read/write native YAML and CPS files directly in Dropbox #15), OneDrive (feat: read/write native YAML and CPS files directly in OneDrive #16), and Google Drive (feat: read/write native YAML and CPS files directly in Google Drive #17), just like codeplug files — so the shared pool can act as a cross-device source of truth.

Open questions / scope notes

• Reference vs. copy semantics: does a codeplug reference a library item by id (live link), or snapshot a copy at add-time? The edit-or-clone behaviour above implies live references with an explicit clone-to-detach path — confirm during planning.
• Import sources: support importing into the library from the same vendor CSV inputs we already parse (OpenGD77 Channels.csv etc.), and from native YAML (the library export above / feat: native YAML import and export #10). Bulk import (e.g. a RepeaterBook export) is a key use case.
• Identity & dedupe: channel names are case-sensitive foreign keys within a codeplug; the library needs its own stable identity so a library item and a project-local item with the same name don't collide on export.
• Storage footprint: the library is separate from per-project state but shares the LocalStorage budget — mind size limits (see feat: persist state in browser LocalStorage #9).
• Contacts: flagged as "potentially" — could be split into a follow-on once channels + TGs land.

Affected

• Shared model/state and storage layer; channel/zone/TG/contact list + edit UIs; import/export path (CSV + native YAML); cloud-storage adapters (feat: read/write native YAML and CPS files directly in Dropbox #15–feat: read/write native YAML and CPS files directly in Google Drive #17) when available.

Notes

• Privacy: library data is operator data — browser LocalStorage only (plus the user's own cloud storage via feat: read/write native YAML and CPS files directly in Dropbox #15–feat: read/write native YAML and CPS files directly in Google Drive #17), never committed to the repo. Cloud OAuth tokens stay browser-local.
• Depends on the internal data models (feat: genericise CPS import via internal data models #7) and LocalStorage persistence (feat: persist state in browser LocalStorage #9); interacts closely with the CRUD tickets (feat: CRUD channels #11 channels, feat: CRUD zones (incl. add/remove channels) #12 zones, feat: CRUD DMR talk groups and TG lists (incl. TG ↔ TGL) #13 TGs/TG lists, feat: CRUD digital contacts #14 contacts), native YAML import/export (feat: native YAML import and export #10), and cloud storage for Dropbox (feat: read/write native YAML and CPS files directly in Dropbox #15), OneDrive (feat: read/write native YAML and CPS files directly in OneDrive #16), and Google Drive (feat: read/write native YAML and CPS files directly in Google Drive #17).
• Frequency/site data imported from third-party sources (e.g. RepeaterBook) is for programming convenience and is not authoritative for emergency operations.

Workflow note (for whoever picks this up)

Likely multi-commit work: branch from origin/main, use atomic conventional commits per logical change (do not batch into one big end-of-plan commit), and open a PR linking Closes #. Pair with the docs/features / progress-tracking skills for the build log.