Docs: drop docs/, point to the white-label guide

.env.example

@@ -14,7 +14,7 @@ NEXTAUTH_SECRET=""
 # The deployment origin. Setting it *overrides* the origin NextAuth reads off the
 # request, so scope it to production only — a preview deploy that inherited
 # production's value would believe it is production and sign the user in there.
-# Previews leave it unset and take their host from the request. See docs/deploy.md.
+# Previews leave it unset and take their host from the request. See README.md → Deploy.
 NEXTAUTH_URL="http://localhost:3000"
 # Google OAuth client (Web application). Authorized redirect URI:
 #   $NEXTAUTH_URL/api/auth/callback/google
@@ -34,11 +34,11 @@ AUTH_REDIRECT_PROXY_URL=""
 # alias by reading Netlify's DEPLOY_PRIME_URL (baked at build time by next.config.ts),
 # because the request host a preview sees is the deploy permalink, not the alias its
 # users are on. Setting AUTH_URL yourself overrides that and takes precedence over
-# NEXTAUTH_URL. See docs/deploy.md → Preview deployments.
+# NEXTAUTH_URL. See README.md → Deploy.
 #   AUTH_URL=""
 
 # --- Base44 app-factory bridge, server-only ---
-# Without these the app runs fine; only the builder is unavailable, and it says
+# Without these the app runs fine; only building apps is unavailable, and the UI says
 # so (the bridge answers 501 bridge_misconfigured).
 #
 # One Base44 account sits behind the whole integration: it owns every app your

.npmrc

@@ -1,5 +1,5 @@
 # Every dependency here is public and package-lock.json resolves them from npmjs,
 # so CI can install. Pinned because a developer machine's global ~/.npmrc may point
 # at a private registry, which npm would substitute for the lockfile host and then
-# fail on. See docs/deploy.md.
+# fail on.
 registry=https://registry.npmjs.org

CLAUDE.md

@@ -3,10 +3,10 @@
 Reference implementation of a **white-label platform built on Base44**. Base44 is the backend and
 app-factory; this repo is the shell a company wraps around it. **Sunny** is the worked example — a
 work-management product (boards / groups / items / widgets) whose users can build their own apps via
-Base44's builder, embedded here.
+Base44, from a chat panel inside the product.
 
-Read `README.md` first: it is the walkthrough, organised around the four boundaries this repo exists
-to demonstrate.
+Read `README.md` first: it lists the boundaries this repo exists to demonstrate and where each
+lives in the code.
 
 ## What this is / isn't
 
@@ -99,9 +99,6 @@ needs neither — it mints its own keypair.
 
 ## Docs
 
-- `docs/base44-identity.md` — the one-account model, the access token, and keeping builders apart
-- `docs/base44-platform-api.md` — the platform REST endpoints
-- `docs/base44-built-apps.md` — builder instructions, skills, and the callback API
-- `docs/sunny-platform-skill.md` — the skill text a built app reads, as a worked example
-- `docs/base44-webhooks.md` — inbound events: registration, signature, delivery semantics
-- `docs/deploy.md` — Netlify + Neon
+The integration guide is on the docs site, starting at
+https://docs.base44.com/developers/white-label/overview. `src/lib/sunny-platform-skill.md` is the
+skill text a built app reads, installed in the Base44 workspace; `/api/sunny` is held to it.

PREVIEW-DEPLOYS.md

@@ -1,7 +1,7 @@
 # Deploy previews: what this branch does, and what is still missing
 
-Working note for the `feat/deploy-preview-auth` branch. The durable reference is
-[`docs/deploy.md`](docs/deploy.md) → *Preview deployments*; this file is the status of the change
+Working note for the `feat/deploy-preview-auth` branch. The deploy steps are
+in the [README](README.md) → *Deploy*; this file is the status of the change
 and the list of things a human with Netlify, Neon and Google access still has to do.
 
 **State:** the code side is done and verified locally. The platform side — Netlify env vars, a
@@ -30,7 +30,7 @@ A Netlify deploy preview gets a fresh URL per pull request
 | `scripts/auth-smoke.ts`, `base44-live-check.ts`, `base44-smoke.ts`, `entity-api-smoke.ts`, `marketplace-smoke.ts`, `sunny-api-smoke.ts` | Mint through that helper instead of calling `encode()` with the v4 cookie name |
 | `netlify.toml` | `[context.deploy-preview]` and `[context.branch-deploy]` build with `npm run build` — the database-free build — so no pull request can run a migration |
 | `next.config.ts`, `src/lib/auth.ts` | Pin a preview's origin to Netlify's `DEPLOY_PRIME_URL` (the deploy *alias*) instead of deriving it from the request host, which Netlify fills with the deploy *permalink*. `next.config.ts` bakes the value in because the function's runtime env does not carry Netlify's build variables |
-| `.env.example`, `docs/deploy.md` | `AUTH_REDIRECT_PROXY_URL`, the shared-secret requirement, why `NEXTAUTH_URL` must be production-only, and the Neon-branch story |
+| `.env.example`, `README.md` | `AUTH_REDIRECT_PROXY_URL`, the shared-secret requirement, why `NEXTAUTH_URL` must be production-only, and the Neon-branch story |
 
 Nothing about the app's own behaviour changed: same session shape, same `/api/auth/callback/google`
 path, so **the existing Google OAuth client needs no new entry**.
@@ -164,11 +164,11 @@ curl -s -D- -o /dev/null -b /tmp/j -X POST --data "csrfToken=$T" "$P/api/auth/si
   that secret. If that is not acceptable, the alternative is a second Netlify site plus a second
   Google client acting as its own proxy for previews, at the cost of a separate secret to rotate.
 - **Built apps in a preview still call production's `/api/sunny`.** The `sunny-platform` skill
-  lives in the Base44 workspace and hardcodes one host (`docs/sunny-platform-skill.md`,
+  lives in the Base44 workspace and hardcodes one host (`src/lib/sunny-platform-skill.md`,
   `<SUNNY_HOST>`), so an app in a preview reads and writes **production** rows — scoped to
   its viewer, but production data all the same. Making it follow the deployment means a
-  per-environment skill, or teaching the builder instructions to inject the shell's own origin.
-- **Base44 credentials on previews or not.** Without them a preview says the builder is not
+  per-environment skill, or having `builderInstructions.ts` put the shell's own origin into the custom instructions.
+- **Base44 credentials on previews or not.** Without them a preview says app building is not
   configured and everything else works. With them, previews share the production account and
   workspace, so apps built in a preview land in production's workspace — and their `AppOwnership`
   rows land in the preview's database branch, so production will not list them. Nothing per-user