Registering a reusable procedure once is convenient. Letting a project-specific adjustment change every other workflow is not. I separated the common catalog from the definition snapshot held by each project, so reuse does not silently turn a local decision into a global update.
Take a snapshot when a project first receives the definition
ProjectProgramLibrary wraps the common catalog with a project-owned programs location. Synchronization examines catalog program folders and skips a definition whose project manifest already exists. The same program identity can therefore remain discoverable while files and execution records belong to separate projects.
Directly referencing common files would simplify registration but broaden every edit. Registering a fresh identity for every workflow would make the same procedure harder to recognize. The chosen structure retains a common identity with local definitions, separating shared discovery from shared mutable execution content.
Limit transferred files and write the completion marker last
The initial transfer includes recipe, Python workflow, notebook, README and manifest. Execution journals, credentials and user files are outside that catalog-copy list. Reusing a procedure should not silently inherit the original run material along with its definition.
The manifest is copied last because the next synchronization uses its presence as a completion marker. Marking completion before the content arrives would undermine that rule. This ordering is not a fully atomic transaction across several files, and it does not prove protection against every crash or competing process. The explanation stays with the boundary implemented by the code.
A local file change does not automatically renew verification
Changing only a project recipe makes the next load reject its changed hash. The digest covers recipe bytes, workflow bytes and notebook cell types and sources. A renamed or edited definition cannot simply continue under its former verification metadata.
The peer project and common catalog retain their earlier content under the same identity. Isolation of an edit and readiness of that edit for execution are distinct conclusions. A proper change needs the relevant review and update path; preserving a local copy should not make old verification claims appear current.
Instructions and activation also belong to the project
Custom skills are imported from a common catalog only when the project has no retained skill definition. Reading a skill checks that it is enabled in that project. Catalog presence alone does not justify injecting its full instructions into every task.
The existing test edits instructions in one project while retaining the peer wording, and disables one switch while the other remains enabled. Built-in initialization follows a different path from retained custom snapshots. That distinction prevents the preservation rule from being overstated as permanent pinning of every built-in file.
Test rejection in the changed project as well as preservation
The program test first establishes separate project folders, edits one recipe and compares the peer and catalog bytes with their original content. It then requires the edited load to fail while the peer still loads the original definition. Seeing changed text in one interface would not establish those properties by itself.
This writing compares actual functions with existing test code without altering the development application or user projects. The shared module newly implements the preservation decision with in-memory textual snapshots and twenty-one tests. It supplies no file deployment or original-application verification, so the evidence for each remains distinct.
Keep common improvements available for deliberate adoption
Preserving snapshots means a common improvement is not instantly applied everywhere. Operations must still show which definition each project uses and review adoption where needed. That maintenance cost is real. A global update button can erase different workflow decisions made in individual projects.
Custom business software has the same tension: shared foundations may lead to different terminology, inputs and processing order. The reusable base and local adjustment need separate ownership and verification. Initial snapshots, change digests and project activation give that distinction concrete form rather than leaving it as an informal promise.