Regenerate Services Without Losing Business Code

Preview changes to a generated service, preserve user-owned functions and verify that existing business implementations still satisfy the new graph contracts.

Understand generated and user-owned files

Generated bindings and graph assembly are replaced during regeneration. Existing business functions and customization files are preserved unless an explicit overwrite rule owns that path. Keep manual changes out of generated files.

The ownership rule is more precise than a directory convention: generated basenames and scripts/merge-overwrite.txt participate in the decision. Read regeneration and file ownership before adding custom files.

Download a new archive and preview its changes

Commit your current workspace, change the topology and download a new ZIP from the designer. Set ARCHIVE to that file. Run the preview inside the existing workspace; inspect additions, replacements and stale files before applying it.

make merge-check ARCHIVE=/path/to/new-project.zip
make merge ARCHIVE=/path/to/new-project.zip
make merge-validate

Resolve interface changes, then test behavior

Preserving a file does not guarantee that its code still implements a changed type or callback signature. Follow merge diagnostics, update affected business functions and rerun the generated checks.

A normal merge reports stale generated files without deleting them. Do not use stale-file removal as a substitute for understanding a migration. Custom merge hooks can express repository-specific decisions.

make build
make test

Repeat the requests affected by the topology change, including an error or cancellation path.
Compare the generated graph and trace with the intended service boundaries.

Next steps

Commit → generate → merge-check → review → merge → merge-validate → test