rn-eas-build-submit-updatelisted

# rn-eas-build-submit-update — guardrail for EAS Build / Submit / Update / Workflows ## The 5 rules (non-negotiable) 1. **3 profiles in `eas.json`**: `development` (dev client, internal), `preview` (TestFlight / Play Internal — test on real devices), `production` (the store). NEVER ship from a profile not pre-tested in preview. 2. **Credentials server-side via `eas credentials`**. NEVER commit `.p12`, `.p8`, `*.keystore`, `*.jks`, or `google-services.json` for production accounts. EAS holds them; local Apple/Google CLI never touches them. 3. **OTA only for JS-only changes**. If the diff touches `app.json` config plugins, native modules, or anything that would change `prebuild` output → it's a new build, not an Update. 4. **Channels separate environments**. `preview` channel for QA, `production` channel for end users. Ship updates to `preview` first, promote to `production` only after smoke-test. 5. **`expo-updates` config in `app.json`** is the source of truth for runtime version (`runtimeVersion: { policy: "appVersion" }` or `"sdkVersion"`). Mismatched runtime versions = OTAs ignored. ## Quick decision tree - "Build, Submit, or Update — which do I need now?" → `references/decision-tree.md` - "How do I write the eas.json profiles?" → `references/eas-json.md` - "How do credentials work — where does the cert live?" → `references/credentials.md` - "How do I set up EAS Workflows for CI?" → `references/workflows.md` - "Did the build/OTA I just shipped actually land OK — do I n