Generated CRUD and custom business behavior

Use Mettada where behavior is declarative and repeatable: fields, basic relationships, validation, CRUD endpoints, migrations, seeders, and contract-backed workspace structure. Use consumer code where the behavior expresses domain policy or coordinates multiple operations.

A practical boundary

Concern	Starting point
Standard record listing and editing	Entity + workspace specs
Belongs-to selector and reference validation	Entity relationship metadata
Due-date reminders or status transitions	Consumer service and tests
Captured prices and payment balance rules	Consumer service + transactional endpoint
Dashboard aggregates and domain-specific widgets	Consumer endpoint and UI
Custom authorization	Consumer policies/middleware and backend tests

The AlterationManager pilot demonstrates this boundary: entity CRUD and workspace contracts are generated, while work queues, status transitions, payment invariants, and dashboard metrics are application-owned. Its APIs enforce permissions; the UI alone is not an authorization boundary.

Safe sync loop

Edit specs, not generated artifacts.
Run mettada:lint and resolve structural and cross-reference errors.
Run mettada:sync and inspect the resulting diff.
Review migration safety, authorization, and generated endpoint behavior.
Run consumer tests and build the frontend.

Keep durable customizations outside generated paths. Do not patch generated files in place and expect those edits to survive another sync.