chore: strengthen provider module docs

Add official upstream links across provider-backed modules and mark installable preset paths ready now that their source modules validate.

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

Author: jesseoue

CHANGELOG.md

@@ -15,6 +15,8 @@
 
 ### Changed
 
+- Added official upstream documentation links across provider-backed modules and cleaned duplicated Mintlify module docs.
+- Promoted installable preset manifests from `planned` to `ready` now that their source modules validate.
 - Sharpened public positioning around the API SaaS wedge: API keys, usage tracking, rate limits, credits, Stripe billing, docs, and webhooks as editable source.
 - Pointed module maintenance skills to installed shared provider, framework, database, SDK, and platform skills.
 - Standardized provider adapter registry language and replaced legacy provider wording/paths.

docs/changelog.md

@@ -17,13 +17,15 @@ This page mirrors the release changelog and keeps the latest public registry cha
 
 ### Changed
 
-1. Sharpened public positioning around the API SaaS wedge: API keys, usage tracking, rate limits, credits, Stripe billing, docs, and webhooks as editable source.
-2. Pointed module maintenance skills to installed shared provider, framework, database, SDK, and platform skills.
-3. Standardized provider adapter registry language and replaced legacy provider wording/paths.
-4. Renamed public command examples to `stackfoundry`.
-5. Updated `AGENTS.md` to match the current recipes, readiness, generated-output, and maintenance-skill model.
-6. Improved README badges, contribution controls, provider request templates, repo topics, and docs navigation for public discovery.
-7. Updated GitHub Actions dependencies for checkout, Node setup, pnpm setup, and dependency review.
+1. Added official upstream documentation links across provider-backed modules and cleaned duplicated Mintlify module docs.
+2. Promoted installable preset manifests from `planned` to `ready` now that their source modules validate.
+3. Sharpened public positioning around the API SaaS wedge: API keys, usage tracking, rate limits, credits, Stripe billing, docs, and webhooks as editable source.
+4. Pointed module maintenance skills to installed shared provider, framework, database, SDK, and platform skills.
+5. Standardized provider adapter registry language and replaced legacy provider wording/paths.
+6. Renamed public command examples to `stackfoundry`.
+7. Updated `AGENTS.md` to match the current recipes, readiness, generated-output, and maintenance-skill model.
+8. Improved README badges, contribution controls, provider request templates, repo topics, and docs navigation for public discovery.
+9. Updated GitHub Actions dependencies for checkout, Node setup, pnpm setup, and dependency review.
 
 ### Security
 

public/r/ai-saas.json

@@ -40,7 +40,7 @@
   "docs": "Installs the AI SaaS recipe from StackFoundry.",
   "meta": {
     "category": "recipe",
-    "status": "planned",
+    "status": "ready",
     "modules": [
       "drizzle-postgres",
       "api-keys",

public/r/arcjet-security.json

@@ -51,7 +51,7 @@
   "envVars": {
     "ARCJET_KEY": ""
   },
-  "docs": "# Arcjet Security Module\n\nArcjet request protection starter for bot detection, shielding, and rate limits.\n\n## Owns\n\n- `apps/web/src/lib/arcjet.ts`\n- `apps/web/src/app/api/providers/arcjet/protected/route.ts`\n- `apps/web/src/app/(console)/admin/providers/arcjet/page.tsx`\n\n## Dependencies\n\n- `@arcjet/next`\n\n## Environment\n\n- `ARCJET_KEY`\n\n## Deployment Notes\n\n- Create the provider project/resource before deploying.\n- Add the listed environment variables to preview and production.\n- Smoke-test the included route or helper after deploy.\n- Keep provider secrets out of client components and logs.\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Update source examples when provider SDK APIs change.\n- Record production-specific retry, alerting, and rollback behavior before marking stable.\n",
+  "docs": "# Arcjet Security Module\n\nArcjet request protection starter for bot detection, shielding, and rate limits.\n\n## Official Docs\n\n- [Arcjet Docs](https://docs.arcjet.com)\n\n## Owns\n\n- `apps/web/src/lib/arcjet.ts`\n- `apps/web/src/app/api/providers/arcjet/protected/route.ts`\n- `apps/web/src/app/(console)/admin/providers/arcjet/page.tsx`\n\n## Dependencies\n\n- `@arcjet/next`\n\n## Environment\n\n- `ARCJET_KEY`\n\n## Deployment Notes\n\n- Create the provider project/resource before deploying.\n- Add the listed environment variables to preview and production.\n- Smoke-test the included route or helper after deploy.\n- Keep provider secrets out of client components and logs.\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Update source examples when provider SDK APIs change.\n- Record production-specific retry, alerting, and rollback behavior before marking stable.\n",
   "meta": {
     "category": "security",
     "env": [

public/r/auth-better-auth.json

@@ -56,7 +56,7 @@
     "BETTER_AUTH_SECRET": "",
     "BETTER_AUTH_URL": ""
   },
-  "docs": "# Better Auth Module\n\nBetter Auth server config, Next.js route handler, and typed client starter.\n\n## Owns\n\n- `apps/web/src/lib/auth.ts`\n- `apps/web/src/lib/auth-client.ts`\n- `apps/web/src/app/api/auth/[...all]/route.ts`\n- `apps/web/src/app/(console)/admin/auth/better-auth/page.tsx`\n\n## Dependencies\n\n`better-auth`\n\n## Environment\n\n- `BETTER_AUTH_SECRET`\n- `BETTER_AUTH_URL`\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Keep secrets in environment variables and never commit local credentials.\n- Verify the example route or worker path before promoting this module beyond experimental.\n- Update docs, checklist, and manifest metadata when provider APIs change.\n",
+  "docs": "# Better Auth Module\n\nBetter Auth server config, Next.js route handler, and typed client starter.\n\n## Official Docs\n\n- [Better Auth Docs](https://www.better-auth.com/docs)\n\n## Owns\n\n- `apps/web/src/lib/auth.ts`\n- `apps/web/src/lib/auth-client.ts`\n- `apps/web/src/app/api/auth/[...all]/route.ts`\n- `apps/web/src/app/(console)/admin/auth/better-auth/page.tsx`\n\n## Dependencies\n\n`better-auth`\n\n## Environment\n\n- `BETTER_AUTH_SECRET`\n- `BETTER_AUTH_URL`\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Keep secrets in environment variables and never commit local credentials.\n- Verify the example route or worker path before promoting this module beyond experimental.\n- Update docs, checklist, and manifest metadata when provider APIs change.\n",
   "meta": {
     "category": "auth",
     "env": [

public/r/autumn-billing.json

@@ -46,7 +46,7 @@
   "envVars": {
     "AUTUMN_SECRET_KEY": ""
   },
-  "docs": "# Autumn Billing\n\nOptional Autumn adapter for plan attach, checkout redirects, usage billing, overages, and plan changes.\n\nAutumn should sit beside the source-owned billing modules, not replace them by default. Use `billing-core` and `usage-metering` for local product state, then map plan ids and usage features into Autumn when the app chooses Autumn for hosted billing logic.\n\n## Owns\n\n- `apps/web/src/lib/autumn/billing.ts`\n- `apps/web/src/app/(console)/admin/providers/autumn-billing/page.tsx`\n\n## Dependencies\n\n- `autumn-js`\n- `registry:billing-core`\n- `registry:usage-metering`\n\n## Environment\n\n- `AUTUMN_SECRET_KEY`\n\n## Provider Notes\n\n- Autumn's `billing.attach` flow attaches a customer to a plan and may return a `paymentUrl` for hosted checkout.\n- Keep plan ids in server-owned configuration. Do not trust plan ids, prices, or feature quantities from client input without validation.\n- Model products, plans, usage features, included amounts, and overages in Autumn before promoting this adapter.\n\n## Maintenance\n\n- Keep this module focused on the Autumn boundary.\n- Update local billing mappings when Autumn product, plan, or feature ids change.\n- Verify sandbox checkout, upgrade, downgrade, saved-payment, and cancellation paths before marking stable.\n",
+  "docs": "# Autumn Billing\n\nOptional Autumn adapter for plan attach, checkout redirects, usage billing, overages, and plan changes.\n\nAutumn should sit beside the source-owned billing modules, not replace them by default. Use `billing-core` and `usage-metering` for local product state, then map plan ids and usage features into Autumn when the app chooses Autumn for hosted billing logic.\n\n## Official Docs\n\n- [Autumn Docs](https://docs.useautumn.com)\n- [Autumn API Reference](https://docs.useautumn.com/api-reference)\n\n## Owns\n\n- `apps/web/src/lib/autumn/billing.ts`\n- `apps/web/src/app/(console)/admin/providers/autumn-billing/page.tsx`\n\n## Dependencies\n\n- `autumn-js`\n- `registry:billing-core`\n- `registry:usage-metering`\n\n## Environment\n\n- `AUTUMN_SECRET_KEY`\n\n## Provider Notes\n\n- Autumn's `billing.attach` flow attaches a customer to a plan and may return a `paymentUrl` for hosted checkout.\n- Keep plan ids in server-owned configuration. Do not trust plan ids, prices, or feature quantities from client input without validation.\n- Model products, plans, usage features, included amounts, and overages in Autumn before promoting this adapter.\n\n## Maintenance\n\n- Keep this module focused on the Autumn boundary.\n- Update local billing mappings when Autumn product, plan, or feature ids change.\n- Verify sandbox checkout, upgrade, downgrade, saved-payment, and cancellation paths before marking stable.\n",
   "meta": {
     "category": "billing",
     "env": [

public/r/autumn-entitlements.json

@@ -46,7 +46,7 @@
   "envVars": {
     "AUTUMN_SECRET_KEY": ""
   },
-  "docs": "# Autumn Entitlements\n\nOptional Autumn adapter for feature checks, metered usage, check-and-consume flows, credit balances, and upgrade context.\n\nAutumn should extend the source-owned entitlement and plan-gating modules. Keep local feature names, UI gates, and fallback behavior clear, then map them to Autumn feature ids when this provider is selected.\n\n## Owns\n\n- `apps/web/src/lib/autumn/entitlements.ts`\n- `apps/web/src/app/(console)/admin/providers/autumn-entitlements/page.tsx`\n\n## Dependencies\n\n- `autumn-js`\n- `registry:entitlements`\n- `registry:plan-gating`\n\n## Environment\n\n- `AUTUMN_SECRET_KEY`\n\n## Provider Notes\n\n- `check` returns whether a customer can use a feature. It supports required balances for metered features.\n- Use `sendEvent` only when you intentionally want check-and-consume behavior in one operation.\n- Use `track` after successful work for usage events, and include idempotency keys on retryable operations.\n- Usage-based pricing can allow overages even after included usage is consumed, so gates should handle the returned upgrade or balance context explicitly.\n\n## Maintenance\n\n- Keep feature ids, plan gates, and upgrade copy documented together.\n- Test boolean features, metered features, exhausted balances, overage paths, and idempotent retries before marking stable.\n- Keep provider secrets server-only.\n",
+  "docs": "# Autumn Entitlements\n\nOptional Autumn adapter for feature checks, metered usage, check-and-consume flows, credit balances, and upgrade context.\n\nAutumn should extend the source-owned entitlement and plan-gating modules. Keep local feature names, UI gates, and fallback behavior clear, then map them to Autumn feature ids when this provider is selected.\n\n## Official Docs\n\n- [Autumn Docs](https://docs.useautumn.com)\n\n## Owns\n\n- `apps/web/src/lib/autumn/entitlements.ts`\n- `apps/web/src/app/(console)/admin/providers/autumn-entitlements/page.tsx`\n\n## Dependencies\n\n- `autumn-js`\n- `registry:entitlements`\n- `registry:plan-gating`\n\n## Environment\n\n- `AUTUMN_SECRET_KEY`\n\n## Provider Notes\n\n- `check` returns whether a customer can use a feature. It supports required balances for metered features.\n- Use `sendEvent` only when you intentionally want check-and-consume behavior in one operation.\n- Use `track` after successful work for usage events, and include idempotency keys on retryable operations.\n- Usage-based pricing can allow overages even after included usage is consumed, so gates should handle the returned upgrade or balance context explicitly.\n\n## Maintenance\n\n- Keep feature ids, plan gates, and upgrade copy documented together.\n- Test boolean features, metered features, exhausted balances, overage paths, and idempotent retries before marking stable.\n- Keep provider secrets server-only.\n",
   "meta": {
     "category": "billing",
     "env": [

public/r/axiom-logging.json

@@ -50,7 +50,7 @@
     "AXIOM_TOKEN": "",
     "AXIOM_DATASET": ""
   },
-  "docs": "# Axiom Logging Module\n\nAxiom structured event logger and server route for deployment smoke checks.\n\n## Owns\n\n- `apps/web/src/lib/axiom/logger.ts`\n- `apps/web/src/app/api/providers/axiom/log/route.ts`\n- `apps/web/src/app/(console)/admin/providers/axiom/page.tsx`\n\n## Dependencies\n\n- `@axiomhq/js`\n\n## Environment\n\n- `AXIOM_TOKEN`\n- `AXIOM_DATASET`\n\n## Deployment Notes\n\n- Create the provider project/resource before deploying.\n- Add the listed environment variables to preview and production.\n- Smoke-test the included route or helper after deploy.\n- Keep provider secrets out of client components and logs.\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Update source examples when provider SDK APIs change.\n- Record production-specific retry, alerting, and rollback behavior before marking stable.\n",
+  "docs": "# Axiom Logging Module\n\nAxiom structured event logger and server route for deployment smoke checks.\n\n## Official Docs\n\n- [Axiom Docs](https://axiom.co/docs)\n\n## Owns\n\n- `apps/web/src/lib/axiom/logger.ts`\n- `apps/web/src/app/api/providers/axiom/log/route.ts`\n- `apps/web/src/app/(console)/admin/providers/axiom/page.tsx`\n\n## Dependencies\n\n- `@axiomhq/js`\n\n## Environment\n\n- `AXIOM_TOKEN`\n- `AXIOM_DATASET`\n\n## Deployment Notes\n\n- Create the provider project/resource before deploying.\n- Add the listed environment variables to preview and production.\n- Smoke-test the included route or helper after deploy.\n- Keep provider secrets out of client components and logs.\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Update source examples when provider SDK APIs change.\n- Record production-specific retry, alerting, and rollback behavior before marking stable.\n",
   "meta": {
     "category": "observability",
     "env": [

public/r/b2b-saas.json

@@ -99,7 +99,7 @@
   "docs": "Installs the B2B SaaS recipe from StackFoundry.",
   "meta": {
     "category": "recipe",
-    "status": "planned",
+    "status": "ready",
     "modules": [
       "drizzle-postgres",
       "api-keys",

public/r/clerk-auth.json

@@ -69,7 +69,7 @@
     "CLERK_SECRET_KEY": "",
     "CLERK_WEBHOOK_SECRET": ""
   },
-  "docs": "# Clerk Auth Module\n\nClerk sign-in/sign-up pages, middleware, server auth helper, and webhook starter.\n\n## Owns\n\n- `middleware.ts`\n- `apps/web/src/lib/clerk/authorization.ts`\n- `apps/web/src/app/(auth)/sign-in/[[...sign-in]]/page.tsx`\n- `apps/web/src/app/(auth)/sign-up/[[...sign-up]]/page.tsx`\n- `apps/web/src/app/api/webhooks/clerk/route.ts`\n- `apps/web/src/app/(console)/admin/auth/clerk/page.tsx`\n\n## Dependencies\n\n`@clerk/nextjs`\n\n## Environment\n\n- `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY`\n- `CLERK_SECRET_KEY`\n- `CLERK_WEBHOOK_SECRET`\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Keep secrets in environment variables and never commit local credentials.\n- Verify the example route or worker path before promoting this module beyond experimental.\n- Update docs, checklist, and manifest metadata when provider APIs change.\n",
+  "docs": "# Clerk Auth Module\n\nClerk sign-in/sign-up pages, middleware, server auth helper, and webhook starter.\n\n## Official Docs\n\n- [Clerk Docs](https://clerk.com/docs)\n- [Clerk Webhooks](https://clerk.com/docs/webhooks/sync-data)\n\n## Owns\n\n- `middleware.ts`\n- `apps/web/src/lib/clerk/authorization.ts`\n- `apps/web/src/app/(auth)/sign-in/[[...sign-in]]/page.tsx`\n- `apps/web/src/app/(auth)/sign-up/[[...sign-up]]/page.tsx`\n- `apps/web/src/app/api/webhooks/clerk/route.ts`\n- `apps/web/src/app/(console)/admin/auth/clerk/page.tsx`\n\n## Dependencies\n\n`@clerk/nextjs`\n\n## Environment\n\n- `NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY`\n- `CLERK_SECRET_KEY`\n- `CLERK_WEBHOOK_SECRET`\n\n## Maintenance\n\n- Keep this module focused on the provider adapter boundary.\n- Keep secrets in environment variables and never commit local credentials.\n- Verify the example route or worker path before promoting this module beyond experimental.\n- Update docs, checklist, and manifest metadata when provider APIs change.\n",
   "meta": {
     "category": "auth",
     "env": [