Routine imports land in your Library

Shipped

• Fixed a Builder state issue where importing a routine could briefly load the file and then get overwritten by the blank new-routine draft.
• Changed create-route imports so an imported JSON file becomes a fresh editable custom routine before saving.
• Prevented imported files from reusing exported IDs that might already exist locally as archived, deleted, active, or otherwise hidden routines.
• Reset imported routine lifecycle fields so imported routines save inactive and visible in the Library by default.
• Added regression coverage for the import overwrite case and the fresh-import identity path.
• Validated the Operator Base routine against the current strict routine validator and exercise-definition catalog.

Why

Importing a routine should feel like adding a routine, not debugging local storage.

Routine JSON files can carry useful program structure, but they can also carry stale app state: an old ID, an active flag, archive metadata, or lifecycle fields from another device. That is fine for an export file, but it is not a safe local identity when the user is trying to add something new from Plan.

Protocol now treats manual imports from the add/import flow as new local routine instances. The source file still provides the program, days, exercises, sets, anchors, and notes. The app provides a fresh local identity so Save can put it in the Library predictably.

Notes

• Existing exported files still import normally.
• Editing an existing routine can still intentionally replace that routine's contents.
• Imported routines start inactive so the user can review them before activation.
• The routine validator remains strict about exercise definitions and display names before sharing/importing authored files.

Next

• Keep tightening routine authoring around canonical exercise definitions.
• Continue turning routine import failures into deterministic validation or save-flow checks.