@viraatdas/rudder 3.9.1 → 3.9.4

package/assets/skills/google-cloud/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rudder-google-cloud
-description: Use for any Google Cloud or Google API setup — creating or naming a GCP project, enabling APIs (Gmail, Calendar, Drive, Gemini, …), "Sign in with Google" / Google OAuth clients, the consent screen (app name, logo, domains, scopes, verification, test users), redirect_uri_mismatch and other OAuth errors, gcloud auth, service accounts and keys, and storing the resulting secrets. Makes sure users see the product's own name on Google's screens, never a stray project like "My First Project".
+description: Use for any Google Cloud or Google API setup — creating or naming a GCP project, enabling APIs (Gmail, Calendar, Drive, Gemini, …), "Sign in with Google" / Google OAuth clients, the consent screen (app name, logo, domains, scopes, brand verification, test users), moving sign-in to another domain, redirect_uri_mismatch and other OAuth errors, gcloud auth, service accounts and keys, and storing the resulting secrets. Makes sure users see the product's own name on Google's screens, never a stray project like "My First Project".
 ---
 
 # Google Cloud, done properly
@@ -14,6 +14,15 @@ Helper: `node <this skill dir>/scripts/gcp.mjs <command>` (Node 18+, no deps).
 It finds credentials from `gcloud`, gcloud's stored login, or ADC; run
 `whoami` first.
 
+**Google's official skills cover the rest.** This skill is the product layer
+(project naming, consent screen, OAuth client, what a user sees). For general
+`gcloud` work use Google's `gcloud` skill (check leaf syntax with `gcloud help
+<command>` before running it, `--limit`/`--filter`/`--format` on every list,
+`--quiet`, dry-run where supported) and `google-cloud-recipe-auth` for IAM,
+service accounts and ADC. Both are in the `google-cloud-developer` plugin; if
+they are not loaded: `claude plugin marketplace add google/skills && claude
+plugin install google-cloud-developer@google-plugins`.
+
 ## The rules
 
 1. **One project per product, named after the product.** Display name = the
@@ -25,7 +34,11 @@ It finds credentials from `gcloud`, gcloud's stored login, or ADC; run
 2. **The consent screen's App name is what users read**, not the project name
    and not the client name. Set it on the Branding page to the product name,
    with the product's own support email, home page, privacy and terms URLs, and
-   the product's domain as an authorized domain.
+   the product's domain as an authorized domain. **It only shows once the
+   branding is verified.** Until then Google shows the redirect URI's domain:
+   the registrable domain for your own (`app.rudder.exla.ai` → "exla.ai"), the
+   whole host for a platform one ("rudder-cloud-control.fly.dev"). See "Brand
+   verification" below.
 3. **Ask for the narrowest scopes that work.** Basic (openid/email/profile) can go
    straight to production. Sensitive (Calendar, gmail.send) need verification.
    Restricted (Gmail read/modify/compose, Drive full) need verification **and**
@@ -94,8 +107,8 @@ real sign-in in a browser and say in your report what the screen showed.
 - **Testing vs production**: in Testing only listed test users can sign in and
   refresh tokens expire after 7 days — fine for a demo, wrong for real users.
   Publish as soon as the scopes allow it.
-- **Logo**: uploading one triggers brand verification; leave it off until the
-  user is ready to verify. The name, links and domain still show.
+- **Logo**: uploading one adds a logo review to verification; leave it off
+  unless the user wants it, since basic scopes verify faster without one.
 - **Internal user type** restricts sign-in to the org's Workspace accounts — only
   right for internal tools.
 - **Verification** (sensitive/restricted scopes): needs the home page on the
@@ -113,9 +126,60 @@ real sign-in in a browser and say in your report what the screen showed.
   again) and the consent App name (Branding page). The project ID can never
   change — choose it once, deliberately.
 
+## Brand verification (getting the App name on screen)
+
+Branding page → **Verify branding**. Google checks that every **authorized
+domain** is verified in Search Console by an owner of the project, that the
+home page and privacy policy live on those domains and name the app, and that
+the support email belongs to the owner. Basic scopes: usually a few days.
+
+- **Redirect URIs must be on a domain the user owns.** Platform hosts
+  (`*.fly.dev`, `*.vercel.app`, `*.run.app`, `*.awsapprunner.com`,
+  `*.netlify.app`) can never be verified, and while they are authorized
+  domains verification fails. Serve the auth callback from the product's own
+  domain (e.g. `app.<domain>`), then remove the platform redirect URIs and
+  their authorized domains.
+- **Search Console**: add a Domain property for the apex and verify it with
+  the DNS TXT record it gives (through the DNS host's API if you have it,
+  otherwise ask the user), signed in as the same account that owns the project.
+
+## Moving sign-in to another domain
+
+Order matters. Switching the app first breaks sign-in for everyone.
+
+1. Point the new host at the app (DNS + TLS) and check it serves.
+2. Add the new redirect URI (and JS origin if used) to the Google client **and**
+   to every other provider on the same auth base URL (GitHub OAuth/App callback
+   URLs, Slack, Linear …). `check-client` must show it accepted.
+3. Make every page that STARTS a sign-in redirect to the new host before
+   starting it: the OAuth state cookie is set on the host that starts the flow
+   and must be there when the callback lands. Native shells and old CLIs keep
+   using the old address, so bounce their login pages; don't strand them.
+4. Flip the auth base URL (`BETTER_AUTH_URL`, `NEXTAUTH_URL`, …) and deploy.
+5. Real sign-in on the new host for each provider; then remove the old redirect
+   URIs and authorized domains, and verify the branding.
+
+## Keeping an existing client
+
+A client already shipped in apps (an iOS bundle, a published CLI, stored in a
+host's secrets) can stay in a misnamed project when moving it would change the
+client ID. Its consent screen can still say the product's name: set the
+Branding and verify it. Note the exception in the report; never silently.
+
+## In the browser
+
+- Google may ask for a passkey, security key or password re-auth (the URL
+  carries `rapt=`). Stop and ask the user to complete it; never type it.
+- The client page's "Last used date" lags by days. Confirm which client is live
+  from the app's own sign-in redirect (`curl -sI <login url>` → `client_id=`),
+  not from that date.
+- Settings "may take 5 minutes to a few hours"; `check-client` usually sees a
+  new redirect URI within a minute.
+
 ## Report
 
 Say which project (ID and display name), which APIs, which client (ID, never
 the secret), where the secrets live, the `check-client` result per redirect
-URI, what the real sign-in screen showed, the publishing status, and any
-verification still owed (with the user cap it implies).
+URI (including the name Google shows today), what the real sign-in screen
+showed, the publishing and brand-verification status, and any verification
+still owed (with the user cap it implies).

package/assets/skills/google-cloud/scripts/gcp.mjs

@@ -329,9 +329,15 @@ async function probe(clientId, redirect, scopes) {
   const url = new URL("https://accounts.google.com/o/oauth2/v2/auth");
   url.search = new URLSearchParams({ client_id: clientId, redirect_uri: redirect, response_type: "code", scope: scopes.join(" "), prompt: "select_account" }).toString();
   const response = await fetch(url, { redirect: "follow", headers: { "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Safari/537.36", "accept-language": "en-US" } });
-  const text = pageText(await response.text());
+  const html = await response.text();
+  const text = pageText(html);
   const error = text.match(/Error 400: (\w+)/)?.[1] ?? text.match(/Error 401: (\w+)/)?.[1] ?? text.match(/Error 403: (\w+)/)?.[1] ?? (response.url.includes("/signin/oauth/error") ? "unknown_error" : null);
-  const appName = text.match(/to continue to ([^.]+?)(?:\s+(?:Email|Forgot|Not your|Create account|Next)\b|$)/)?.[1]?.trim() ?? null;
+  // The name sits in a data-app-name attribute (seen 2026-10); the text
+  // match is the fallback for older page shapes. Unverified branding shows
+  // the redirect URI's domain here, not the App name.
+  const appName = pageText(html.match(/data-app-name="([^"]+)"/)?.[1] ?? "").trim()
+    || text.match(/to continue to ([^.]+?)(?:\s+(?:Email|Forgot|Not your|Create account|Next)\b|$)/)?.[1]?.trim()
+    || null;
   return { error, appName, finalUrl: response.url };
 }
 
@@ -364,7 +370,7 @@ async function checkClient(o) {
     }
     const nameOk = !expect || r.appName.toLowerCase() === expect.toLowerCase();
     if (!nameOk) ok = false;
-    console.log(`${nameOk ? "✓" : "✗"} ${redirect}: accepted; Google shows "continue to ${r.appName}"${nameOk ? "" : `, expected "${expect}". Fix the App name on the Branding page (it is not the project name).`}`);
+    console.log(`${nameOk ? "✓" : "✗"} ${redirect}: accepted; Google shows "continue to ${r.appName}"${nameOk ? "" : `, expected "${expect}". ${/\./.test(r.appName) ? "Google shows a domain until the branding is verified (Branding page, Verify branding)." : "Fix the App name on the Branding page (it is not the project name)."}`}`);
   }
   if (!ok) process.exit(1);
 }

package/assets/skills/namecheap/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: rudder-namecheap
+description: Use WHENEVER Namecheap comes up, and for any domain registered there (nameservers dns1/dns2.registrar-servers.com). Covers the whole account through the Namecheap API and CLI — DNS records (A/AAAA/CNAME/TXT/MX, verification records, pointing a domain or subdomain at Vercel, Netlify or a server, removing the parking page), free email forwarding (hello@ to an inbox), URL redirects, nameservers, registrar lock, domain privacy (WhoisGuard), domain list, expiry and auto-renew, contacts, availability and pricing, registering and renewing domains, transfers, account balance, and API access setup. Does the change itself and never hands the user records to type into the Namecheap dashboard.
+---
+
+# Namecheap
+
+**The rule: do it through the API, never hand the user steps for the
+dashboard.** If access is missing, the only acceptable ask is the one-time API
+setup in section 6, stated once, after everything else is done.
+
+Tool: `<this skill dir>/scripts/namecheap` (Python 3 stdlib, no installs).
+`$NC --help` and `$NC <command> --help` list every option.
+
+```bash
+NC="<this skill dir>/scripts/namecheap"
+$NC check            # credentials work + every domain in the account
+```
+
+## 1. Look before changing
+
+| Question | Command |
+|---|---|
+| Which domains, when do they expire, auto-renew, privacy, lock | `$NC domains` (`--expiring`, `--expired`, `--search TEXT`) |
+| One domain in full: status, expiry, privacy, nameservers, lock | `$NC info example.com` |
+| Where its DNS is served from (public view) | `$NC lookup example.com NS` |
+| Records Namecheap serves + email mode | `$NC list example.com` |
+| Email forwards | `$NC forward example.com` |
+| WHOIS contacts | `$NC contacts example.com` |
+| Balance | `$NC balance` |
+| Incoming transfers | `$NC transfers` |
+
+If the nameservers are not `dns1/dns2.registrar-servers.com`, records live at
+that DNS host, not at Namecheap: `*.vercel-dns.com` → `vercel dns add`;
+Netlify (`dns*.p0*.nsone.net`) → the Netlify CLI/API; Cloudflare, Route 53 →
+their CLI/API. Registrar settings (nameservers, lock, privacy, renewals) still
+belong here.
+
+## 2. DNS records: list, dry-run, then apply
+
+```bash
+$NC list example.com
+$NC set example.com --add 'CNAME app site.netlify.app.' --dry-run
+$NC set example.com --add 'CNAME app site.netlify.app.'      # backs up, writes, re-reads, verifies
+```
+
+Namecheap's `setHosts` **replaces every record on the domain**. Never call it
+with curl or any other client: one call missing the MX or TXT records silently
+breaks mail and verification. The tool merges with the live set, refuses record
+types it cannot round-trip (CAA, SRV: tell the user those need the dashboard),
+and backs up every write to `~/.config/namecheap/backups/`. Undo with
+`$NC restore <backup.json>`.
+
+| Goal | Command |
+|---|---|
+| Apex + www to Vercel (removes the parking page) | `$NC vercel example.com`, then `vercel domains add example.com <project>` and `vercel domains add www.example.com <project>` |
+| Subdomain to Vercel | `$NC vercel example.com --sub app` |
+| Verification TXT (Vercel, Google, …) | `$NC set example.com --add 'TXT _vercel "vc-domain-verify=..."'` |
+| Subdomain to Netlify / any host | `$NC set example.com --add 'CNAME app site-name.netlify.app.'` |
+| A record to a server | `$NC set example.com --add 'A api 203.0.113.7'` |
+| Redirect a name (301) | `$NC set example.com --add 'URL301 old https://new.example.com'` |
+| Third-party mail (MX) | `$NC set example.com --add 'MX @ mx1.provider.com. 1800 10'` |
+| Replace a conflicting record | add `--replace` (without it the tool refuses and shows the clash) |
+| Remove a record | `$NC set example.com --remove 'CNAME old'` (value optional) |
+| Free email forwarding | `$NC forward example.com --add hello=you@example.com` (refuses to cut off live MX mail unless `--force`) |
+
+Verify with `$NC list` (Namecheap's view, already re-read after the write) and
+`$NC lookup example.com A` (public DNS, after the TTL).
+
+## 3. Registrar settings
+
+| Goal | Command |
+|---|---|
+| Move DNS to another host (Vercel, Cloudflare, …) | `$NC nameservers example.com --set ns1.host.com ns2.host.com --yes` |
+| Back to Namecheap BasicDNS | `$NC nameservers example.com --default --yes` |
+| Transfer lock | `$NC lock example.com --on` / `--off` (off only to transfer it out) |
+| Domain privacy | `$NC privacy example.com --on` / `--off`; `$NC privacy` lists all |
+
+Switching nameservers moves the whole domain: copy the records to the new host
+first, or mail and verification break. The tool asks for `--yes` for that reason.
+
+## 4. Buying and renewing (spends money)
+
+```bash
+$NC available idea.dev other.com      # free? premium?
+$NC price dev                         # your register price; --action renew|transfer, --years N
+$NC renew example.com --years 1       # prints price + balance, charges nothing
+$NC register idea.dev --contacts-from example.com   # same: prints, charges nothing
+```
+
+Anything that charges the account does nothing without `--yes`. **Before
+adding `--yes`, tell the user the item and total and get a clear yes in chat**,
+every time; a yes for one purchase does not cover the next. Registration copies
+WHOIS contacts from a domain the user already owns and turns free privacy on.
+Premium names are refused (they need the dashboard). Payment comes from the
+account balance; if it is short, say so and stop.
+
+## 5. Report
+
+Say what changed (before → after), the backup path for record writes, what
+`lookup` shows publicly, anything still propagating, and for purchases the
+amount charged and the order id.
+
+## 6. When access is missing
+
+The tool reads `NAMECHEAP_API_USER` / `NAMECHEAP_API_KEY` (optionally
+`NAMECHEAP_USERNAME`, `NAMECHEAP_CLIENT_IP`) from the environment or
+`~/.config/namecheap/credentials.env`. On a Rudder cloud machine the environment
+comes from the Rudder secrets vault; `env | grep -c NAMECHEAP` shows whether it
+has them.
+
+If the tool prints `NO_NAMECHEAP_CREDENTIALS`, or an API error naming an IP that
+isn't whitelisted, first do everything that doesn't need Namecheap. Then send
+the user one short message with only this:
+
+1. Namecheap → Profile → Tools → **Namecheap API Access** → ON. Namecheap
+   requires a $50 balance, $50 spent in the last two years, or 20 domains.
+2. **Whitelisted IPs** → add the IP the tool printed (this machine's public
+   IPv4; only IPv4 works).
+3. Store the key once, from their computer, so every Rudder cloud machine has
+   it: `rudder cloud secrets set NAMECHEAP_API_USER <namecheap-username>` and
+   `rudder cloud secrets set NAMECHEAP_API_KEY` (prompts for the value). For
+   this machine only: `! <this skill dir>/scripts/namecheap setup <namecheap-username>`
+   (prompts for the key).
+
+Never print the key, commit it, put it in a URL or pass it as a command-line
+argument. Never sign in to the Namecheap dashboard yourself: the account
+password is the user's. A cloud machine's outbound IP can change on restart;
+when Namecheap rejects a call, the error names the new IP. Whitelist it too, or
+pin a static egress IP, which costs money and needs the user's go-ahead.