I would make these last three fields into a type that is embedded in the different status types.

That was the plan eventually. I wanted to let things like machine status, storage status etc emerge first so that we could make a more informed call if we wanted to introduce a top level domain status package with the aforementioned core type and any other required artefacts. Since this is the first cab off the rank, I was ok with doing it this way initially; it's only 3 attributes with no behaviour attached to them. I can introduce a suitable type here pending subsequent refactoring.

I think this would only be useful if there is common logic around status that is useful when decomposed without StatusID.

I'd prefer this to become a generic type. All statues should have the same shape.

type StatusInfo[StatusType any] struct {
	StatusID StatusType
	Message  string
	Data     map[string]string
	Since    time.Time
}

type CloudContainerStatusStatusInfo = StatusInfo[CloudContainerStatusType]
...

I was deliberately avoiding optimising too much and introducing a generic status type until we had more use cases outside this domain. We already have status in core. The types that are defined here are purely to act as parameters to the calls to state. They are not used outside the application package. They are just DTOs with no behaviour. Any changes to how status is used outside this package needs to start with core status and be done holistically.

I think the name for this type is poor.

Naming is hard. The struct holds just "core" or minimal attributes of a unit - uuid, name, life, net node uuid. Maybe "minimalUnit". I'll have a think.

coreUnit is terrible because it clashes with similarly named coreunit (which you have as an aliased package in this very file) and the concept of "core" when it comes to juju.

Something like:

• basicUnit
• minimalUnit
• unitIntrinsics

IDK. I wouldn't think about it to hard, it is an unexported concept.

I already changed to minimalUnit