1## Why23The catalog already assigns stable `${packId}:${localId}` level IDs, but the4application still carries the active proof as a mutable array index while5catalog access repeatedly clones every pack and level. Pack replacement,6removal, progress updates, and win handoff can therefore resolve different7levels after the catalog changes, while ordinary UI refreshes pay a full8catalog clone cost.910## What Changes1112- Make the canonical active-level identity the existing stable global level ID,13 while retaining numeric index arguments for compatibility.14- Define catalog read boundaries that resolve one level or the active level by15 stable ID and invalidate derived views after register, replace, and remove.16- Keep existing public clone and mutation-safety guarantees for `getLevels`,17 `getLevel`, and `getPack`; add focused cache and identity tests before18 changing callers.19- Migrate application handoff, progress marking, level replacement, and pack20 removal flows to re-resolve by stable ID instead of retaining a stale index.2122This change does not alter pack IDs, local level IDs, sharing payloads, save23keys, solver state, or level ordering semantics.2425## Capabilities2627### New Capabilities2829- `stable-active-level-identity`3031### Modified Capabilities3233None.3435## Impact3637`src/catalog.js`, `src/main.js`, and their focused tests will change. Existing38catalog methods remain compatible and continue returning caller-owned data.39The implementation may add internal generation counters or immutable records,40but those details are not exposed in pack or level payloads.