chore: standardize provider adapter registry language

Rename the adapter preset and install targets away from vendor terminology so registry docs, generated outputs, and maintenance skills consistently model providers as explicit adapters.

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: jesseoue

README.md

@@ -41,7 +41,7 @@ Install from the public registry URL when you want to consume generated registry
 
 ```bash
 pnpm stackfoundry add https://stackfoundry.dev/r/api-keys.json --target ./my-app
-pnpm stackfoundry add https://stackfoundry.dev/r/vendor-examples.json --target ./my-app
+pnpm stackfoundry add https://stackfoundry.dev/r/provider-adapters.json --target ./my-app
 pnpm stackfoundry diff https://stackfoundry.dev/r/api-keys.json --target ./my-app
 ```
 
@@ -99,7 +99,7 @@ Current source registry coverage:
 | `free-tier-saas` | Practical baseline for a free-tier product launch |
 | `vercel-native` | Vercel deployment, storage, workflows, edge config, and observability path |
 | `cloudflare-native` | Workers, D1, R2, KV, Queues, Workflows, Turnstile, and Cloudflare-native adapters |
-| `vendor-examples` | Concrete optional provider adapter examples |
+| `provider-adapters` | Concrete optional provider adapter examples |
 
 ```bash
 pnpm registry:presets
@@ -155,7 +155,7 @@ public/r/
   registry.json              # registry index
   api-keys.json              # installable registry item
   stripe-billing.json        # installable registry item
-  vendor-examples.json       # installable aggregate preset block
+  provider-adapters.json       # installable aggregate preset block
   presets/
     next-saas.json           # StackFoundry preset manifest for tooling/inspection
 ```

apps/cli/README.md

@@ -32,7 +32,7 @@ pnpm cli presets
 pnpm cli doctor
 pnpm cli build
 pnpm cli add api-keys --target /tmp/app --dry-run
-pnpm cli add preset vendor-examples --target /tmp/app --dry-run
+pnpm cli add preset provider-adapters --target /tmp/app --dry-run
 pnpm cli add https://stackfoundry.dev/r/api-keys.json --target /tmp/app --dry-run
 pnpm cli diff api-keys --target /tmp/app
 ```

apps/cli/src/cli.mjs

@@ -60,9 +60,9 @@ Examples:
   stackfoundry search webhook
   stackfoundry info stripe-billing
   stackfoundry add api-keys --target ./app
-  stackfoundry add preset vendor-examples --target ./app
+  stackfoundry add preset provider-adapters --target ./app
   stackfoundry add https://stackfoundry.dev/r/api-keys.json --target ./app
-  stackfoundry add public/r/vendor-examples.json --target ./app
+  stackfoundry add public/r/provider-adapters.json --target ./app
 `);
 }
 

apps/web/app/docs/page.tsx

@@ -691,7 +691,7 @@ $ pnpm stackfoundry add stripe-billing --target ./my-app`}</CodeBlock>
               StackFoundry is designed for normal code review. Install commands should be paired
               with diffs, env review, migration review, and focused verification. Provider modules
               document their required keys and webhook setup, but they should never introduce
-              committed secrets or lock a base preset to a vendor.
+              committed secrets or lock a base preset to one provider.
             </p>
             <div className="docs-checklist">
               <span>Read the manifest and docs before install.</span>

apps/web/app/registry/page.tsx

@@ -62,7 +62,7 @@ const featuredPresets = [
     tone: "Edge",
   },
   {
-    name: "vendor-examples",
+    name: "provider-adapters",
     title: "Adapter Examples",
     description:
       "Provider adapter examples that show integration shape without locking in the base.",

docs/maintenance.md

@@ -61,9 +61,9 @@ Generated registry blocks also embed `maintenanceSkills`, so installs from `http
 
 Module skills should explain the files owned by the module, required environment variables, deployment checks, and invariants that future maintainers must preserve. Shared technology skills should stay provider- or framework-level and avoid repeating module-specific instructions.
 
-## Vendor Blocks
+## Provider Adapter Blocks
 
-Vendor example blocks should include:
+Provider adapter modules should include:
 
 - source files owned by the integration
 - runtime and development dependencies

docs/modules.md

@@ -8,7 +8,7 @@ The first installable production modules were:
 - `api-keys`
 - `stripe-billing`
 
-The registry now includes core modules, vendor examples, and registry-compatible public blocks. Each module should be installable into an existing app as editable source code. Presets are only bundles of modules.
+The registry now includes core modules, provider adapter examples, and registry-compatible public blocks. Each module should be installable into an existing app as editable source code. Presets are only bundles of modules.
 
 ## What a Module Includes
 
@@ -113,7 +113,7 @@ The registry now includes core modules, vendor examples, and registry-compatible
 - `incident-management`
 - `data-import-export`
 
-### Vendor Examples
+### Provider Adapter Examples
 
 - `inngest-functions`
 - `trigger-dev-jobs`

docs/registry-compat.md

@@ -10,7 +10,7 @@ With the StackFoundry CLI:
 
 ```bash
 pnpm stackfoundry add https://stackfoundry.dev/r/api-keys.json --target ./my-app
-pnpm stackfoundry add https://stackfoundry.dev/r/vendor-examples.json --target ./my-app
+pnpm stackfoundry add https://stackfoundry.dev/r/provider-adapters.json --target ./my-app
 ```
 
 ## Local Development
@@ -39,7 +39,7 @@ pnpm stackfoundry add http://localhost:3000/r/api-keys.json --target /tmp/app
 - Internal module dependencies are emitted as full `https://stackfoundry.dev/r/<dependency>.json` registry URLs.
 - Env requirements are emitted as `envVars` and retained in `meta.env`.
 - Module and shared technology skills are emitted as `maintenanceSkills` so registry URL installs include maintenance guidance.
-- StackFoundry CLI can install generated module items directly, including aggregate preset blocks such as `/r/vendor-examples.json`.
+- StackFoundry CLI can install generated module items directly, including aggregate preset blocks such as `/r/provider-adapters.json`.
 - `/r/presets/*.json` files are StackFoundry preset manifests for tooling and inspection. They are intentionally not shadcn registry item documents; use `/r/<preset>.json` for installable preset payloads.
 
 ## StackFoundry Rules
@@ -48,7 +48,7 @@ pnpm stackfoundry add http://localhost:3000/r/api-keys.json --target /tmp/app
 - Module source lives in `registry/modules`; generated registry JSON lives in `public/r`.
 - Presets compose modules and can be emitted as aggregate blocks when the preset name does not collide with a module name.
 - Shared technology skills live in `registry/skills` and can be referenced by the source manifest's skill list.
-- Vendor modules should stay adapters around shared product capabilities.
+- Provider adapter modules should stay adapters around shared product capabilities.
 - Skills and checklists are part of the block, because maintainability is part of the product.
 
 ## Verification

docs/registry.md

@@ -64,7 +64,7 @@ public/r/
   drizzle-postgres.json
   api-keys.json
   stripe-billing.json
-  vendor-examples.json     # installable aggregate preset block
+  provider-adapters.json     # installable aggregate preset block
   presets/
     next-saas.json         # StackFoundry preset manifest
 ```

examples/README.md

@@ -14,4 +14,4 @@ They are intentionally small. An example should demonstrate how a module or pres
 - Do not put secrets or `.env.local` files here.
 - Prefer commands that recreate generated output over committed generated app code.
 - Keep examples aligned with `pnpm test:registry:install`.
-- If an example requires a vendor account, document required env vars and a no-account dry-run path.
+- If an example requires a provider account, document required env vars and a no-account dry-run path.