skew-checklisted

# skew-check Code review checks that the new version is correct. Almost nobody checks the state every real deploy actually passes through: **vN-1 and vN running simultaneously**, sharing queues, caches, sessions, and each other's API calls — plus the mirror image, a rollback, where vN-1 comes back and meets data vN already wrote. Changes that are perfectly correct at rest break in this window: a renamed queue field old consumers can't parse, a new session format old pods can't read, an enum value old code treats as fatal. These surface as "transient errors during every rollout" that everyone learns to ignore. The discipline is one question asked systematically: **for every shared surface this diff touches, can each version read what the other writes, for the whole overlap window?** ## Step 1: inventory the shared surfaces in the diff Walk the diff and list every point where data crosses a process or time boundary: - **Queue / event messages** — anything produced to a broker or event store. Special: these *outlive the deploy* — a message written by vN-2 can be replayed next month, so compatibility here is durable, not just deploy-window. - **Cache values** — serialized objects in Redis/memcached that both versions read. - **Sessions / cookies / tokens** — old pods will receive sessions minted by new pods, and vice versa, on every request during the rollout. - **RPC/API contracts between your own services** — services deploy independently; "we updated both sides" still mea