BOUNDARIES — OSS ↔ Cloud

The OSS and Cloud halves of AtomPRD are intentionally separate. The boundary charter mirrors what’s enforced in code review.

The four hard rules

1. OSS never imports Cloud

OSS packages have no @atomprd-cloud/* dependency, no Cloud-specific environment variable, no awareness this repo exists. If OSS code needs an extension point, expose an interface; the Cloud injects the implementation.

2. Cloud imports OSS only via npm

When a Cloud package needs @atomprd/spec or @atomprd/cli types, depend on them with concrete npm versions. Never path-import from ../atomprd/packages/*. The exception is the dev-time parent workspace (link-dev.sh) which is local-only and never committed.

3. No code copies from OSS into `packages-pro/`

If a Pro module extends an OSS module, it imports and overrides — it does not fork.

4. Customer data never enters OSS code paths

Cloud’s PrdStore / SessionStore impls hold customer data. OSS code receives a PrdDocument value with no notion of who owns it.

License separation

Repo	License
`atomprd/` (OSS)	MIT
`atomprd-cloud/` (this)	Proprietary, all rights reserved
`senlang/`	MIT

The LICENSE file at the Cloud repo root is proprietary. Do not copy MIT-licensed text into it.

Pricing-sensitive code

Anything in packages-pro/billing/, packages-pro/prompts-production/, or app-cloud-api/src/billing/ is the most sensitive to leak. Code review must catch any accidental reference from OSS-bound files (e.g. accidental import in a shared util).

Why this discipline

Trust. Customers signing up for the Cloud rely on the OSS half remaining usable standalone. If we erode that, the OSS half loses its reason to exist.
Reversibility. Anything in OSS can be copied; anything in Cloud cannot. Decisions about which features go OSS-vs-Cloud have to be deliberate, not accidental drift.
Legal cleanliness. Per-package licensing only works if no proprietary symbol leaks into MIT code. One accidental import poisons the package.