ENTITY_NAME in a path is a placeholder for your generated entity directory, for example product for Product. EntityName denotes its code type. Replace these with actual project names; the Article examples below illustrate an entity rather than a required project module.
Generated code can be recreated from the model. Preserve your custom files and extend SQL history through new migrations. The generation plan defines these rules; a folder name alone does not identify how a file will be updated.
| Category | Examples | On the next Generate |
|---|---|---|
| Generated code and contracts | domain/ENTITY_NAME.go, app/ENTITY_NAME/, HTTP/SQL adapters, React generated, OpenAPI |
Updated from the model. Manual edits to a tracked file may cause a conflict. Force overwrite replaces the affected file; inspect what you would lose first. |
| Custom files | backend/internal/custom/, features/ENTITY_NAME/custom/, admin/custom/vite.ts |
seed_if_missing creates a starter only when missing. Existing files are preserved and are not automatically adapted to model changes. |
| Generator SQL migrations | backend/migrations/*.sql |
Schema changes are appended as new migrations. Previous history is not regenerated like ordinary source. |
| Custom migrations | backend/migrations/custom/ |
Write SQL and register the file in backend/migrations/manifest.json to join the shared sequence. Do not rewrite an applied migration; create another migration for the next change. |
Generate changes project files. The database changes separately when migrations run. Discard ungenerated changes restores only the manifest to the last successful Generate; it does not roll back data or a running release. Explicit entity retirement may archive its custom files after a separate confirmation.