create-ailk 0.1.0

package/templates/.claude/skills/scaffold-auth/references/oauth-app-setup.md

@@ -0,0 +1,171 @@
+# OAuth + Magic-Link Setup — RUNBOOK Template
+
+The `scaffold-auth` skill writes (or merges into) `RUNBOOK.md` at the
+consumer's repo root using the per-provider sections below. Only the
+sections for providers actually activated this session are emitted.
+
+The skill **substitutes nothing** in these blocks at runtime — they're
+copy-paste ready as-is. The only per-session variation is which
+sections appear in the final runbook.
+
+---
+
+## Provider section: magic-link (Resend)
+
+```markdown
+## Auth — magic-link (Resend)
+
+Magic-link sign-in uses Resend as the email provider. Activation is
+keyed off two env vars in `.env.local`:
+
+- `AUTH_EMAIL_SERVER` — `smtp://resend:<API_KEY>@smtp.resend.com:465`
+- `AUTH_EMAIL_FROM` — verified sender address on your Resend account
+
+### One-time setup
+
+1. Sign up at <https://resend.com> (free tier is fine for development).
+2. Create an API key: <https://resend.com/api-keys>. Save it
+   somewhere safe — you'll only see it once.
+3. Use a verified sender. For development, `onboarding@resend.dev` is
+   Resend's shared dev sender and works without verification. For
+   production, verify your own sending domain in the Resend dashboard.
+
+### `.env.local` entries
+
+\`\`\`
+AUTH_EMAIL_SERVER=smtp://resend:re_yourapikeyhere@smtp.resend.com:465
+AUTH_EMAIL_FROM=onboarding@resend.dev
+\`\`\`
+
+### Rotating the API key
+
+If you rotate the Resend API key, update `AUTH_EMAIL_SERVER` in
+`.env.local` and restart the dev server.
+```
+
+---
+
+## Provider section: Google OAuth
+
+```markdown
+## Auth — Google OAuth
+
+Google sign-in is activated when both env vars are present in
+`.env.local`:
+
+- `GOOGLE_CLIENT_ID`
+- `GOOGLE_CLIENT_SECRET`
+
+### One-time setup
+
+1. Open <https://console.cloud.google.com/apis/credentials>.
+2. If you haven't yet, configure the OAuth consent screen:
+   - User type: **External** (unless you're inside a Workspace org).
+   - Fill in app name, support email, and developer contact email.
+   - Scopes are auto-populated by NextAuth at runtime — leave the
+     consent screen scope list empty.
+3. Click **Create Credentials → OAuth client ID**.
+4. Application type: **Web application**.
+5. Name: anything (e.g., "AILK dev").
+6. **Authorized redirect URIs** — add exactly:
+   `http://localhost:3000/api/auth/callback/google`
+7. Click **Create**. Copy the Client ID and Client secret from the
+   dialog (you can return to copy them later via the Credentials page).
+
+### `.env.local` entries
+
+\`\`\`
+GOOGLE_CLIENT_ID=...
+GOOGLE_CLIENT_SECRET=...
+\`\`\`
+
+### Production callback URL
+
+The `localhost` callback above is dev-only. For production, you'll
+need to add a second redirect URI to the same OAuth client (or
+create a separate prod client) of the form
+`https://<your-prod-domain>/api/auth/callback/google`. The
+`provision-config` skill or your future deploy skill will help you
+wire this when you're ready to ship.
+
+### Rotating the client secret
+
+In the Google Console, find the OAuth client, generate a new secret,
+update `GOOGLE_CLIENT_SECRET` in `.env.local`, and restart the dev
+server. The Client ID stays the same.
+```
+
+---
+
+## Provider section: GitHub OAuth
+
+```markdown
+## Auth — GitHub OAuth
+
+GitHub sign-in is activated when both env vars are present in
+`.env.local`:
+
+- `GITHUB_CLIENT_ID`
+- `GITHUB_CLIENT_SECRET`
+
+### One-time setup
+
+1. Open <https://github.com/settings/developers>.
+2. Click **New OAuth App**.
+3. Application name: anything (e.g., "AILK dev").
+4. Homepage URL: `http://localhost:3000`
+5. **Authorization callback URL** — add exactly:
+   `http://localhost:3000/api/auth/callback/github`
+6. Click **Register application**.
+7. On the resulting app page, click **Generate a new client secret**
+   and copy it immediately (GitHub shows it once).
+8. Copy the Client ID from the same page.
+
+### `.env.local` entries
+
+\`\`\`
+GITHUB_CLIENT_ID=...
+GITHUB_CLIENT_SECRET=...
+\`\`\`
+
+### Production callback URL
+
+The `localhost` callback above is dev-only. For production, either
+register a separate OAuth App with a `https://<your-prod-domain>/...`
+callback, or update this app's callback (GitHub allows multiple).
+The `provision-config` skill or your future deploy skill will help
+you wire this when you're ready to ship.
+
+### Rotating the client secret
+
+Generate a new client secret on the app's GitHub page, update
+`GITHUB_CLIENT_SECRET` in `.env.local`, and restart the dev server.
+The Client ID stays the same.
+```
+
+---
+
+## Closing section (always emitted at the end of the runbook)
+
+```markdown
+## Activation summary
+
+| Provider    | Env vars                                          | Active |
+| ----------- | ------------------------------------------------- | ------ |
+| magic-link  | `AUTH_EMAIL_SERVER` + `AUTH_EMAIL_FROM`           | <fill> |
+| Google      | `GOOGLE_CLIENT_ID` + `GOOGLE_CLIENT_SECRET`       | <fill> |
+| GitHub      | `GITHUB_CLIENT_ID` + `GITHUB_CLIENT_SECRET`       | <fill> |
+
+A provider is **active** when both required env vars are set in
+`.env.local`. The provider list is computed at server startup from env
+vars only — there are no `auth.config.ts` edits to make.
+
+To require sign-in for protected routes, set in `.env.local`:
+
+\`\`\`
+AILK_AUTH_REQUIRED=1
+\`\`\`
+
+Default (unset or `0`) is auth-disabled / public — useful while
+building.
+```

package/templates/.claude/skills/scaffold-commerce/SKILL.md

@@ -0,0 +1,310 @@
+---
+name: scaffold-commerce
+description: Wire up commerce on an AILK consumer site — either an external link to an existing storefront (Amazon, Etsy, Shopify, eBay, Gumroad, custom) via a `<MarketplaceCTA>` button, or direct payments via Stripe (test-mode only at v1). Use when the user says "let me sell something", "add a buy button", "wire up Stripe", "set up payments", "I have an Amazon store", or otherwise wants commerce wiring on their AILK site. Two-path branching — picks link vs direct first, never assumes Stripe.
+---
+
+# scaffold-commerce
+
+Add commerce to an AILK site. The first question is always: **external
+link to an existing storefront, or direct payments on this site?** Both
+paths are conversational and emit minimal, consumer-owned source.
+
+This skill is the canonical "sell stuff" entry point. Pricing UI itself
+is `scaffold-page` (#362)'s lane (you scaffold a `/pricing` page with
+that skill, then wire `lookup_key`s into it). Production webhook setup
+is `provision-config` (#367)'s lane.
+
+## When to use
+
+The user wants to sell something — physical goods, digital goods,
+subscriptions, services, courses, anything with a price. Triggers:
+
+- "let me sell something" / "I want to sell"
+- "add a buy button" / "add a buy now"
+- "wire up Stripe" / "set up payments"
+- "I have an Amazon / Etsy / Shopify / eBay / Gumroad store, link it"
+- "what's the simplest way to charge for this?"
+
+Skip this skill when:
+
+- The user wants to _design_ a pricing page (lay out tiers, copy,
+  comparison table) — that's `scaffold-page` (#362) emitting a Product
+  page. Wire `lookup_key`s afterwards from this skill's output.
+- The user wants to set up production Stripe (live mode, real webhooks).
+  Hard-blocked at v1 — sandbox-only is hook-enforced globally. Defer
+  with the same answer regardless: "v1 is test-mode only; production
+  setup is `provision-config` (#367)'s lane."
+- The user is on a non-Stripe payment processor (Lemon Squeezy, Paddle,
+  Gumroad-as-payment-processor). v1 only supports Stripe for direct
+  payments. Acknowledge and stop; future PRs will add `--provider`
+  branches.
+
+## The first question (always asked)
+
+Greet the consumer with a clear two-path branch:
+
+> "Two ways to sell on your AILK site:
+>
+> **Link to an existing store** — you already sell on Amazon, Etsy,
+> Shopify, eBay, Gumroad, or your own storefront. We add a 'Buy on
+> {marketplace}' button that links there.
+>
+> **Direct payments via Stripe** — you don't have a storefront yet, or
+> you want checkout on your own site. We create products in your
+> Stripe (test mode), wire env vars, and point you at the next steps.
+>
+> Which one?"
+
+Wait for the consumer's choice. Then run the matching path.
+
+## Link path
+
+The link path emits source the consumer owns — no env wiring, no API
+calls, no `@working-theory/ui` import.
+
+### Step 1 — Collect the inputs
+
+Ask conversationally for:
+
+1. **URL** — the storefront URL. Validate it parses as a URL. Don't
+   accept plain text; prompt again if input fails.
+2. **Button text** — defaults to "Buy on {marketplace}" where
+   `{marketplace}` is parsed from the URL hostname (e.g.,
+   `amazon.com` → "Amazon"). Consumer can override.
+3. **Optional `iconSrc`** — a path to an SVG/PNG of the marketplace
+   logo, e.g., `/logos/amazon.svg`. Optional — clean text-only buttons
+   are fine. If the consumer wants logos, point them at
+   `references/marketplace-brand-pages.md` for sourcing.
+
+### Step 2 — Emit the route template
+
+Use `templates/marketplace-cta-route.tsx.tmpl` as the starting source.
+The template defines `<MarketplaceCTA>` **inline** at the top of the
+emitted route file (not bundled in `@working-theory/ui`, not imported from a
+shared package). The consumer owns the component and can customize it.
+
+The emitted file path is the consumer's call — typical placement is
+`app/buy/page.tsx` for a dedicated landing, or inserted into an
+existing page (e.g., `app/products/[slug]/page.tsx`) as a `<MarketplaceCTA>`
+usage. Ask which.
+
+### Step 3 — Confirm and write
+
+Show the consumer the emitted file diff (or new file if standalone)
+in a single confirmation step. After approval, write.
+
+### Step 4 — No env wiring, no follow-up files
+
+The link path is self-contained. Nothing to add to `.env.local`. No
+references file write (the marketplace brand pages cheat-sheet ships
+in the skill folder; the skill points at it but doesn't copy it into
+the consumer's repo).
+
+## Direct payments path (Stripe, test-mode only at v1)
+
+The Stripe path uses the **Stripe MCP** (configured in the AILK
+consumer scaffold's `.claude/settings.json`) to create products with
+consumer-derived `lookup_key`s, writes test-mode env vars, and
+surfaces created keys for the consumer to grep when wiring pricing UI.
+
+### Step 1 — Defense-in-depth live-key check
+
+Before any other action:
+
+1. **Env detection.** Scan the consumer's `.env.local`, `.env`,
+   `.env.development`, and any `.env.example` for `sk_live_` or
+   `pk_live_`. If any match, refuse with:
+
+   > "AILK is sandbox-only at v1. I see a `sk_live_*` or `pk_live_*`
+   > value in your env files — replace it with a test-mode key from
+   > <https://dashboard.stripe.com/test/apikeys> before continuing.
+   > Production setup is `provision-config` (#367)'s lane and is
+   > deferred at v1."
+
+   Stop. No Stripe API calls fire.
+
+2. **Paste detection.** If the consumer pastes a `sk_live_` or
+   `pk_live_` value during the flow, refuse with the same message
+   and stop.
+
+This double-check is required by the brief and matches the global
+hook-enforced sandbox-only constraint.
+
+### Step 2 — Collect product inputs
+
+Ask the consumer to describe each product they want to sell. Per
+product:
+
+- **Name** — e.g., "Pro plan", "Pizza", "Online course".
+- **Price + interval** — e.g., "$29/month", "$15 one-time", "$199/year".
+- **Optional features bullet list** — surfaced in the dashboard, not
+  required for the API call.
+
+Loop until the consumer says "that's all" or equivalent.
+
+### Step 3 — Derive `lookup_key`s
+
+For each product, derive a stable, human-readable `lookup_key`:
+
+- Lowercase the name, replace spaces with underscores.
+- Append `_monthly` / `_yearly` / `_onetime` based on interval.
+- Examples:
+  - "Pro plan, $29/month" → `pro_monthly`
+  - "Annual subscription, $199/year" → `annual_yearly`
+  - "Pizza, $15 one-time" → `pizza_onetime`
+
+Show the derivations to the consumer and offer to override per-product
+before any API call.
+
+### Step 4 — Conflict handling (per product)
+
+For each product, before creating it, query the consumer's Stripe
+account for an existing product with the same `lookup_key` (use the
+Stripe MCP — `stripe.products.list({lookup_keys: [...]})` or equivalent).
+
+If one exists, **show + ask** (do not silently skip, do not refuse):
+
+```
+A product with lookup_key `pro_monthly` already exists:
+  Existing: "Pro plan" — $29/month — created 2026-04-15
+  Proposed: "Pro plan" — $29/month — new
+
+What would you like to do?
+  - Keep existing (no change)
+  - Overwrite amounts (update price, keep lookup_key)
+  - Pick a different lookup_key (e.g., `pro_monthly_v2`)
+```
+
+Wait for choice. Apply.
+
+### Step 5 — Create products + prices in Stripe
+
+For each product (after conflict resolution), use the Stripe MCP:
+
+1. **Create product:** `stripe.products.create({ name, ... })`.
+2. **Create price:** `stripe.prices.create({ product: <id>, unit_amount, currency: 'usd', recurring: { interval } | undefined, lookup_key })`.
+
+Surface created IDs in chat as you go so the consumer can verify in
+their Stripe dashboard alongside the run.
+
+### Step 6 — Write `.env.local`
+
+After all products are created, write to the consumer's `.env.local`:
+
+```
+STRIPE_SECRET_KEY=sk_test_...
+STRIPE_PUBLISHABLE_KEY=pk_test_...
+STRIPE_WEBHOOK_SECRET=
+```
+
+Use the test-mode keys from the consumer's Stripe account (the
+consumer pastes these from
+<https://dashboard.stripe.com/test/apikeys>). Leave
+`STRIPE_WEBHOOK_SECRET` empty — Step 7 fills it.
+
+### Step 7 — Webhook setup (dev-only)
+
+Tell the consumer to run, in a separate terminal:
+
+```bash
+stripe listen --forward-to localhost:3000/api/webhooks/stripe
+```
+
+The CLI prints a signing secret (`whsec_...`). Have the consumer paste
+it into `.env.local` as `STRIPE_WEBHOOK_SECRET`.
+
+Note: production webhook setup is **deferred to v2** — the consumer
+will register a permanent webhook endpoint in Stripe's dashboard
+during deploy. Point at `provision-config` (#367) or future deploy
+skill for the production handoff. Do not attempt to register a
+production webhook from this skill.
+
+### Step 8 — Write `references/lookup-keys.md`
+
+Use `references/lookup-keys-template.md` as the source. Instantiate
+with the products created this session:
+
+```markdown
+# Lookup Keys — generated by scaffold-commerce
+
+| Product  | Lookup key    | Amount | Interval |
+| -------- | ------------- | ------ | -------- |
+| Pro plan | `pro_monthly` | $29.00 | monthly  |
+| ...      | ...           | ...    | ...      |
+
+When wiring a pricing page (`scaffold-page` (#362) on a `Product` slug),
+import or reference these lookup keys. Stripe lookup keys are stable
+across price recreates — safe to hard-code in your app.
+```
+
+The consumer's filled-in `lookup-keys.md` lives in their repo (e.g.,
+project root or a `docs/` folder) — point them at `scaffold-page`
+(#362) for the pricing page that consumes these keys.
+
+### Step 9 — Closing summary
+
+Print:
+
+- Number of products created (with `lookup_key`s).
+- Path to `references/lookup-keys.md`.
+- Reminder: webhook setup is dev-only at v1; production webhook is
+  `provision-config` (#367)'s lane.
+- Pointer at `scaffold-page` (#362) for wiring pricing UI.
+- Reminder: sandbox-only at v1. Live keys are hook-blocked globally.
+
+## Output style
+
+- **Two questions, two paths.** Don't lead with Stripe assumptions.
+- **Live-key checks happen first** for the Stripe path. Always.
+- **Show + ask on conflicts.** Never silently skip or auto-overwrite.
+- **Source the consumer owns.** The link path emits inline source, not
+  an `@working-theory/ui` import. The consumer can edit any of it post-emit.
+- **`lookup_key` derivations are visible.** Show the derivation; let
+  the consumer override before any API call.
+
+## What this skill does NOT do
+
+- Live-mode Stripe anything. Hook-blocked globally; SKILL refuses.
+- Bundle marketplace logos (Amazon, Etsy, Shopify, eBay, Gumroad).
+  AILK doesn't ship those SVGs (trademark-redistribution concern). The
+  consumer drops their own SVG into `public/logos/` and passes
+  `iconSrc` to `<MarketplaceCTA>`. See
+  `references/marketplace-brand-pages.md` for official brand-kit
+  sources.
+- Build a pricing page. That's `scaffold-page` (#362).
+- Register a production webhook endpoint. That's `provision-config`
+  (#367) or future deploy skill.
+- Use `pricebook.ts` or env-var price mapping. AILK uses
+  `lookup_key`s as the source of truth — they're stable across price
+  recreates.
+- Auto-invoke other skills. Always points at the next skill by name;
+  consumer drives.
+
+## References
+
+- `references/marketplace-brand-pages.md` — links to official brand
+  kits (Amazon, Etsy, Shopify, eBay, Gumroad). Used by the link path
+  when the consumer wants logos. AILK does not bundle the SVGs.
+- `references/lookup-keys-template.md` — template the skill instantiates
+  per session, lists every product the consumer created with its
+  `lookup_key` and price.
+- `templates/marketplace-cta-route.tsx.tmpl` — emitted route source
+  the link path writes. Includes the inline `<MarketplaceCTA>`
+  component definition (not a separate package).
+
+## Coordination
+
+- **`scaffold-page` (#362)** — pricing UI. After this skill creates
+  products and surfaces `lookup_key`s, the consumer scaffolds a
+  `/pricing` page that consumes them.
+- **`provision-config` (#367)** — production webhook setup, deploy
+  config, persistent leads (related infra). v1 is dev-mode only;
+  prod webhook lives there.
+- **Stripe MCP** — used for product/price/lookup_key creation. Should
+  already be configured in `.claude/settings.json` from the consumer
+  scaffold. If missing, surface a clear "Stripe MCP not configured"
+  error and stop; do not invent the configuration.
+- **`@working-theory/stripe-client`** — wrapper for Stripe SDK. The skill does
+  not import this directly (the skill is a prompt/template, not
+  runtime code). The consumer's `apps/api/routes/checkout/sessions.ts`
+  uses it.

package/templates/.claude/skills/scaffold-commerce/references/lookup-keys-template.md

@@ -0,0 +1,71 @@
+# Lookup Keys — generated by `scaffold-commerce`
+
+This file lists every Stripe product the `scaffold-commerce` skill
+created in your test-mode account. The skill writes one row per
+product as it goes; re-running the skill appends new rows under
+"## Added by re-run YYYY-MM-DD".
+
+## How to use this file
+
+Stripe `lookup_key`s are stable identifiers — they survive price
+recreates (e.g., when you change an amount, you can keep the same
+`lookup_key`). They're the canonical reference for AILK pricing UI.
+
+When wiring a pricing page (e.g., from `scaffold-page` (#362) on a
+`Product` slug), refer to `lookup_key` in your code:
+
+```ts
+// apps/web/app/pricing/page.tsx
+const PRICING_LOOKUP_KEYS = ["pro_monthly", "team_monthly"];
+
+// Server-side fetch (apps/api):
+const prices = await stripe.prices.list({
+  lookup_keys: PRICING_LOOKUP_KEYS,
+  expand: ["data.product"],
+});
+```
+
+The pricing page renders from `prices`. If you change a price's
+amount in the Stripe dashboard later, the `lookup_key` resolves to
+the new price automatically — no app-code change needed.
+
+## Products created this session
+
+(The skill fills this table during Step 8 of the Stripe path. Empty
+on first emit; populated as products are created.)
+
+| Product    | Lookup key | Amount | Interval | Stripe ID |
+| ---------- | ---------- | ------ | -------- | --------- |
+| _none yet_ | _ -_       | _-_    | _-_      | _-_       |
+
+Example after a session that created two products:
+
+| Product   | Lookup key     | Amount     | Interval | Stripe ID        |
+| --------- | -------------- | ---------- | -------- | ---------------- |
+| Pro plan  | `pro_monthly`  | $29.00 USD | monthly  | `price_1XXXX...` |
+| Team plan | `team_monthly` | $99.00 USD | monthly  | `price_1YYYY...` |
+
+## Re-running the skill
+
+If you re-run `scaffold-commerce` and add more products:
+
+- Existing rows are not modified.
+- New products land under `## Added by re-run <DATE>` heading at the
+  end of the file.
+- Conflict-handling (skill Step 4) means existing `lookup_key`s are
+  never silently changed — you'll be asked to keep / overwrite /
+  pick a different key.
+
+## Pointers
+
+- **Pricing page UI:** `scaffold-page` (#362) on a `Product` slug.
+  Wire the `PRICING_LOOKUP_KEYS` array to point at the keys above.
+- **Production webhook:** `provision-config` (#367). Dev-mode
+  webhook is set up via `stripe listen` per skill Step 7.
+- **Sandbox-only at v1:** AILK rejects live keys (`sk_live_*`,
+  `pk_live_*`) at multiple layers. Production setup is a future
+  deploy lane.
+- **Stripe dashboard:**
+  - Test products: <https://dashboard.stripe.com/test/products>
+  - Test prices: <https://dashboard.stripe.com/test/prices>
+  - Test API keys: <https://dashboard.stripe.com/test/apikeys>

package/templates/.claude/skills/scaffold-commerce/references/marketplace-brand-pages.md

@@ -0,0 +1,83 @@
+# Marketplace Brand Pages
+
+AILK does **not** bundle marketplace logo SVGs (Amazon, Etsy, Shopify,
+eBay, Gumroad). Trademarks are not blanket-licensed for redistribution
+through third-party templates, and shipping them in the AILK template
+chain would put us in the redistribution chain.
+
+Brand recognition value is preserved via the **brand name in the
+button text** ("Buy on Amazon", "View on Etsy"). Consumers who want
+the logo too can fetch it themselves from each marketplace's official
+brand-kit page (links below) and drop it in their own `public/logos/`
+directory, then pass `iconSrc="/logos/amazon.svg"` to
+`<MarketplaceCTA>`.
+
+Each link below points at the marketplace's first-party brand-asset
+page. URLs may change; if a link breaks, search "<marketplace> brand
+guidelines" or "<marketplace> press kit" — the canonical source is
+always the marketplace's own brand site.
+
+## Amazon
+
+- **Brand assets:** <https://brand.amazon.com> (US Brand Standards)
+- **Press / logo:** <https://www.aboutamazon.com/news/company-news/press-room>
+- Notes: Amazon's brand guidelines restrict use of the smile-arrow
+  logo. The "Available at Amazon" badge is the consumer-permitted
+  affiliate-style asset.
+
+## Etsy
+
+- **Press kit:** <https://www.etsy.com/press>
+- **Logo + brand guidelines:** linked from the press page.
+- Notes: "Sell on Etsy" assets are for sellers; "Available on Etsy"
+  / "Buy on Etsy" buttons are appropriate for outbound links.
+
+## Shopify
+
+- **Brand assets:** <https://www.shopify.com/news/brand-assets> (or
+  search "Shopify brand guidelines")
+- Notes: Shopify provides logo files for partners; consumers using
+  Shopify as their backend can typically use the logo in
+  reasonable-context "Powered by Shopify" / "Buy on our Shopify
+  store" buttons.
+
+## eBay
+
+- **Brand center:** <https://partnernetwork.ebay.com/marketing-center>
+  (eBay Partner Network — affiliate context)
+- **Press / logo:** <https://www.ebayinc.com/company/press-room>
+- Notes: eBay distinguishes affiliate-context use (covered by EPN
+  assets) from general use. For "View on eBay" buttons linking to a
+  specific seller's storefront, the EPN assets apply.
+
+## Gumroad
+
+- **Brand assets:** <https://gumroad.com> (search the footer for
+  "press" or "brand"; Gumroad's logo policy is permissive for
+  outbound links to creator pages)
+- Notes: simplest of the five; Gumroad's logo and "Available on
+  Gumroad" badge are typically copyable directly from their
+  about/press surface.
+
+## Custom storefronts
+
+If the consumer has their own storefront (Webflow, Squarespace,
+Bigcartel, custom-built), they don't need a marketplace logo — a
+plain "Buy now" or "Shop" button works. The `iconSrc` prop is
+optional.
+
+## Legal note (no legal advice)
+
+- Trademarks are owned by the marketplaces. AILK does not grant
+  permission to use any marketplace logo; the consumer's use is
+  governed by each marketplace's brand guidelines.
+- For affiliate context (consumer earns a referral fee), most
+  marketplaces have explicit affiliate-asset programs (Amazon
+  Associates, eBay Partner Network, etc.) with permitted logo use.
+- For non-affiliate "I have a store there, send people to it"
+  context, the marketplace's general brand guidelines apply. When
+  in doubt, the brand name in text only — `Buy on {marketplace}`
+  — is always safe.
+
+This file is informational. Consumers responsible for compliance
+with each marketplace's brand guidelines for their specific use.