First off, I’d make sure you need what yjs provides here. You’re asking for collab and offline first, so I’ll assume that’s a yes.
From there, since a yjs model is assembled from generic data structures, it doesn’t have many opinions on how you actually put them together. So to answer your question about changing the model: That’s all the responsibility of your application. Validation, schema changes, etc. Changing an existing field implies some kind of migration if data in the old format would cause a crash or a bad user experience. This can be really hard, so it’s best to make additive, rather than subtractive, changes to your domain model backed by yjs. Implementing a new feature by adding a ‘v2’ field, for example, rather than changing the format of an existing field. Sometimes destructive changes are unavoidable though. When a user is able to access old app code/data, and could be exposed to new users with new app code/data (and vice versa, sometimes to disastrous consequences!), you’ll run into this challenge.
One thing that’s super helpful here is looking at data migration strategies for mobile apps and more traditional desktop apps. These types of apps have been dealing with offline-first schema changes for a long time.