When an environment has no stored staged patch, environmentStagedChanges is non-nullable, so it returns a synthetic EnvironmentPatch built at request time. That object is not persisted. It has status: STAGED, appliedAt: null and empty contents. Because it is never stored, it does not appear in environmentPatches and cannot be resolved through environmentPatch(id:). You can tell it apart from a real patch by its id: the synthetic object carries the literal placeholder <empty>, while a real record always has a UUID. A real staged record, including one emptied by Discard, does appear in environmentPatches and keeps its original createdAt.

To check for pending changes, read the change count from the patch contents. The public EnvironmentPatch type has no count field, so an empty patch(decryptVariables: false) is the authoritative signal. The dashboard uses this same signal to decide whether to show the staged-changes bar. The contents cover service instance fields (including create and delete flags), volumes, buckets, groups, shared variables (including unsets) and the private-networking toggle, so an empty patch also means no variable changes are staged. status, appliedAt, timestamps and whether a record exists do not establish anything on their own.

We can't confirm from here what unmergedChangesCount returning null means, or exactly what configEtag versions. Don't treat either one as evidence that nothing is staged. Gate on the empty patch contents.

Thank you. We are evaluating the official IaC saved-plan workflow as an alternative to staged patch commits. Before relying on it for a protected deployment, could a human maintainer confirm:

1. Does Environment.configEtag change for every pending staged edit, including sealed-variable updates and unsets, or only for applied IaC configuration? Are Environment.config(decryptVariables: false) and configEtag read from one consistent snapshot?
2. When environmentApplyChangeSet receives baseConfigEtag, can it apply or merge pre-existing staged changes outside the reviewed changeSet? What supported workflow guarantees that only the saved, reviewed changes are applied and rejects any concurrent staged edit?
3. What supported mechanism binds that reviewed configuration to the exact application commit or immutable image digest actually deployed, and rejects a changed code artifact? Does the same optimistic-concurrency guarantee cover deployment, or only configuration application?

We have read the saved-plan documentation and CLI v5.49.6 implementation. We are not treating unmergedChangesCount: null or changing synthetic patch timestamps as proof of no pending changes.