---
name: cross-repo-change
description: Coordinate changes that touch both the aweb OSS repo and the hosted ac repo. OSS lands first; the hosted repository owns dependency derivation and deployment.
---

# 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 ARTIFACTS — `npm pack` the
tarball and read the shipped bundle, or read the released tag — never
against your own source. Your source and the published client disagree;
that disagreement is the entire risk.

Why this section exists: on 2026-07-26 a chat mark-read change made a new
field required and explicitly rejected the old one. Every published client
sent the old field, so deploying it would have broken every client in the
world. It was faithful to the anti-pattern below, which is correct for the
cloud boundary and catastrophic for clients. The process was not ignored —
it was followed.

## Principle (aweb ↔ ac only)

The cloud imports aweb. Both deploy in the same Docker image.
There is no transition period — when the cloud pins a new aweb
version, both the old and new code deploy atomically.

This is the ONLY boundary with that property. Do not generalise it.

## Sequence

1. **Design** — agree on the contract change between OSS and cloud.
   Identify which side goes first.

2. **OSS first** — land the OSS change on aweb main after the relevant focused
   tests pass.

3. **Release OSS** — run `make release-candidate TAGS='...'` in aweb, then push
   each resulting tag separately. `docs/release.md` is authoritative. Wait for
   the exact package versions to be public.

4. **Cloud pins** — update and review `backend/pyproject.toml` and
   `backend/uv.lock` to the exact public OSS versions on AC `main`.

5. **Cloud candidate** — land the cloud-side source change on AC `main`, then
   run `make release-candidate VERSION=X.Y.Z`. Push the resulting `vX.Y.Z` tag;
   AC never publishes OSS artifacts.

6. **Verify** — cloud tests pass against the real aweb package (not
   editable/sibling source).

## Anti-patterns

- Do NOT land the cloud change before the OSS release. The cloud
  CI will fail on import errors.
- Do NOT use editable/sibling source installs as a permanent
  workaround. They mask version pinning issues.
- Do NOT accept both old and new formats "during transition" when
  both sides deploy atomically. Pick one format. **This applies to
  aweb ↔ ac and nowhere else.** Before invoking it, confirm
  every consumer of the contract deploys in that same image. If any
  consumer is a published client — channel, pi, `aw` — or a
  self-hosted server, the rule INVERTS: accept both, prefer the new
  one, and remove the old only after measuring. See "Read this
  first: shippability".
- Do NOT change a contract without enumerating what currently sends
  it. For the channel that check is small — its entire write surface
  is two calls, one of which has no body — so there is no excuse for
  skipping it.

## Hosted schema mirrors

The `ac` repository maintains its own copy of the OSS schemas. The cloud's
`migration_paths.py` points at `backend/src/aweb_cloud/migrations/aweb/`
and `migrations/server/` — NOT at the OSS package's migrations in the
installed `.venv`. So when an OSS release adds or alters a schema the
cloud uses, the cloud needs a paired mirror migration with a matching
ALTER/CREATE.

The migrations to mirror can live in DIFFERENT OSS tree subdirectories
within the same release. Easy to miss the second one when walking commit
by commit:

- `awid/src/awid_service/migrations/*.sql` → mirror in cloud as
  `migrations/aweb/`.
- `server/src/aweb/migrations/aweb/*.sql` → also mirror in cloud as
  `migrations/aweb/` (same target dir, different OSS source dir).

When reviewing a cross-repo bundle, grep ALL OSS migration trees touched
in the bundle, not just the first one you find. Pattern-blindness on the
second mirror is the failure mode.

Each mirror file should be a one-statement ALTER/CREATE matching the OSS
content, with a header comment naming the OSS source path so the lineage
is explicit.

## Example: aweb-aaje (proxy auth team_id format)

1. OSS: changed X-Team-ID validation from UUID to colon-form,
   deleted _resolve_proxy_team_id (cde8889, 0fbe3d9, 78794ff)
2. Released: aweb 1.10.1
3. Hosted repo: pinned 1.10.1 and changed the bridge to send colon-form
   (2761d0a5, 1f6e4797)
4. Both deploy together in the cloud Docker image

## Notes

- The hosted `ac` repo is cloned at `../ac` relative to the aweb
  workspace.
- Ownership and review routing live in the active team instructions
  and `aw workspace status`; do not rely on names written here.