A release recorded in Atmos Pro could appear to happen before the pull request merge it released. Atmos Pro dated a release with the date of the commit it was cut from, which is earlier than the moment the release was published. Anywhere Atmos Pro picks the latest event for a commit, the merge could then win over the release, and any timeline showing both looked wrong.

Release events are now dated with the time the release was published. If GitHub does not send a usable publish time, Atmos Pro uses the time it received the notification, never the commit date. A release for a merged pull request is also never dated before that pull request's merge time, so for a given commit the release is picked as the latest event.

A stack can be enabled for Atmos Pro without a workflow for every trigger. For example, a dev stack may apply on merge but intentionally not on release. Atmos Pro used to mark such a stack as failed, which turned the whole release red even though every configured stack succeeded.

A stack that has workflows, but none for the trigger that fired, is now recorded as skipped, with a neutral note such as "No workflow configured for release/released" on the dashboard. Stacks that depend on it are skipped too and are not dispatched. In the status comment a skipped stack appears only in the table and diagram, with a skipped badge; it no longer adds a Configuration Issues or Dispatch Errors entry. Disabled and deleted stacks, and stacks that do have a workflow for the trigger, behave as before. A skipped stack never makes the overall status, check run, or comment report a failure.

A stack that is enabled but has no workflow configured for any trigger is a real misconfiguration. It is still recorded as failed with the existing "No workflow configured" error, and its dependents are still blocked by it. The status comment now lists it under Configuration Issues instead of Dispatch Errors.

The same applies when a pull request is merged and none of the enabled stacks has an apply workflow: the merge check run now finishes as neutral instead of failing with "Apply not dispatched". It still fails if a workflow was configured but not dispatched.

When a pull request is merged or closed without merging, Atmos Pro no longer posts the "merged" comment if the pull request's stacks have no pull_request workflow for that event, since nothing will run. The decision uses the workflow definitions stored with the pull request's latest event, so a workflow added only in the merge commit is not seen. If Atmos Pro cannot tell, it posts the comment as before.

A stack without a settings.pro.merge_group block no longer runs the pull_request.synchronize workflows on the merge queue. Previously a stack that applies on every PR push, such as a preview environment, also applied from the queue. Now such a stack shows as skipped for the queue event, and the queue check still completes. To run something on the queue, add merge_group.checks_requested to the stack:

settings:
  pro:
    pull_request:
      synchronize:
        workflows: *plan-wf-config
    merge_group:
      checks_requested:
        workflows: *plan-wf-config

Stacks that already define merge_group are unaffected, and so are pull request, release and drift detection runs.

atmos describe affected --upload now accepts the strings "true" and "false" for settings.pro.enabled, for example when the value is quoted or templated in your stack YAML. Before, one such value made Atmos Pro reject the whole upload with a 400 error. Any other string, such as "yes" or an unrendered template, is still rejected.

Release events recorded before this change keep their original times. They are not corrected, so older releases may still appear dated before their merge. Only releases received after this change are dated correctly.

Likewise, runs already recorded as failed for a missing workflow are not rewritten. Those whose stack has workflows for other triggers become skipped the next time the event is processed; stacks with no workflow at all stay failed.