Workers deployment compatibility_date transition: failed deploy triage when Workers Logs are empty

A Worker deploy that previously succeeded may fail after the compatibility_date in wrangler.toml is moved forward or after nodejs_compat_v2 is added to compatibility_flags. Workers Logs generally capture requests served by an activated Worker version, so an empty log stream can indicate that the failing deploy never reached activation, rather than a runtime exception. This creates a triage boundary: the failure may be a pre-activation configuration error, such as an invalid binding or permission issue, or it may be a post-activation behavior change caused by the compatibility transition. Because nodejs_compat_v2 requires a sufficiently recent compatibility_date and alters available Node.js APIs, the exact flag and date interaction is version-sensitive. The goal is to isolate whether the compatibility_date change itself is the boundary that broke the deploy, without assuming request logs exist for the failed version.

Which signals distinguish a compatibility_date or compatibility_flags failure that occurs before version activation from one that occurs after?

How can the required compatibility_date for nodejs_compat_v2 be confirmed against current Cloudflare documentation before a deploy attempt?

When Workers Logs contain no entries for a failed deploy, what configuration fields should be compared between the last known-good and failing versions to identify the transition point?