cross-repo-change

# Cross-repo change coordination Changes that affect both aweb (OSS) and ac (hosted SaaS) must be coordinated carefully because ac embeds aweb as a PyPI package. ## Read this first: shippability **A released client is a permanent constraint.** Once a client that sends X is in the field, the server must accept X until you can prove nothing sends it. Everything below about atomic deploys applies to **aweb ↔ ac only**. Every other consumer — the channel plugin, pi, the `aw` CLI, self-hosted servers — updates on its own schedule. A running agent keeps its loaded module until the process **restarts**, which for a long-lived agent may be never. **Default: additive only.** You may ADD an accepted shape. You may NOT: - remove an accepted shape, - make an optional field required, - reject a shape that is in the field, - narrow a type or add a stricter validator to an existing field. **The only exception:** you may narrow a contract if you can NAME every consumer and show each deploys **atomically** with this change — same image, same deploy, same instant. "We will release the client right after" is not atomic. Put the justification in the commit message. Today exactly one boundary qualifies: aweb ↔ ac. **Removal is a separate, later change.** Remove support for an old shape only after MEASURING that nothing sends it. If you cannot measure it, you cannot remove it. **Before merge, answer:** *what is deployed today, and does this still work against it?* Check against PUBLISHED ...