ai-saas-guard 0.4.0 → 0.6.0

package/README.md

@@ -51,8 +51,8 @@ The CLI is published on npm as `ai-saas-guard`, and the GitHub Action is availab
 | JSON and SARIF output | Available |
 | Composite GitHub Action | Available |
 | Project config | `.ai-saas-guard.json` rule toggles, severity overrides, and fail thresholds |
-| Versioned Action tags | `v0.4.0`, `v0` |
-| npm package | `ai-saas-guard@0.4.0` |
+| Versioned Action tags | `v0.6.0`, `v0` |
+| npm package | `ai-saas-guard@0.6.0` |
 | npm publishing | Trusted Publisher/OIDC, no long-lived publish token |
 
 ## Quick Start
@@ -170,6 +170,14 @@ If `--base` cannot be resolved, `pr-risk` emits `pr-risk.diff-unavailable` inste
 | `check-stripe` | Inspect webhook handlers and billing lifecycle coverage |
 | `check-mcp` | Inventory MCP configs and classify side effects |
 
+## Launch Readiness Checklist
+
+Use [docs/launch-readiness-checklist.md](docs/launch-readiness-checklist.md) when an app is close to inviting real users. It explains how to combine `ai-saas-guard` output with manual two-account authorization testing, Stripe webhook verification, MCP config review, Supabase policy review, deploy checks, rollback planning, and a clear reminder that this is not a full security audit.
+
+## Stripe Webhook Replay
+
+Use [docs/stripe-webhook-replay.md](docs/stripe-webhook-replay.md) after `check-stripe` flags missing signature verification, idempotency, lifecycle handlers, or entitlement updates. The cookbook maps findings to concrete `stripe listen` and `stripe trigger` commands for checkout success, failed renewal, subscription update, cancellation, refund, duplicate delivery, and out-of-order event review.
+
 ## Project Configuration
 
 Add `.ai-saas-guard.json` at the repository root to tune findings without changing scanner code. The CLI auto-loads this file from `--root` when it exists. Use `--config <file>` to point to a different JSON file.
@@ -191,7 +199,7 @@ Add `.ai-saas-guard.json` at the repository root to tune findings without changi
 
 ## GitHub Action
 
-The repo includes a composite Action. Use `v0` for the latest compatible pre-1.0 Action, a specific release tag such as `v0.4.0` for controlled upgrades, or pin a reviewed commit SHA for stricter supply-chain control:
+The repo includes a composite Action. Use `v0` for the latest compatible pre-1.0 Action, a specific release tag such as `v0.6.0` for controlled upgrades, or pin a reviewed commit SHA for stricter supply-chain control:
 
 ```yaml
 name: ai-saas-guard
@@ -320,8 +328,6 @@ Open-source core:
 
 Near-term priorities:
 
-- Stripe webhook replay cookbook
-- launch-readiness checklist content
 - false-positive suppression and rule stability labels
 - GitHub App design note for the potential hosted layer
 

package/dist/scanners/stripe.js

@@ -10,8 +10,8 @@ const criticalEvents = [
 const eventPattern = /["']((?:checkout\.session\.completed|invoice\.payment_failed|customer\.subscription\.(?:deleted|updated|created)|charge\.(?:refunded|dispute\.created)|refund\.(?:created|updated)))["']/g;
 export async function checkStripe(input) {
     const context = await resolveScanContext(input);
-    const files = context.files;
-    const webhookFiles = files.filter((file) => {
+    const runtimeFiles = context.files.filter((file) => !isDocumentationFile(file.path));
+    const webhookFiles = runtimeFiles.filter((file) => {
         const path = file.path.toLowerCase();
         const content = file.content.toLowerCase();
         return ((path.includes("stripe") && path.includes("webhook")) ||
@@ -19,7 +19,7 @@ export async function checkStripe(input) {
             content.includes("stripe-signature") ||
             content.includes("checkout.session.completed"));
     });
-    const stripeSignalFiles = files.filter((file) => !/\.(md|txt)$/i.test(file.path) && !file.path.startsWith("docs/"));
+    const stripeSignalFiles = runtimeFiles;
     const usesStripe = webhookFiles.length > 0 ||
         stripeSignalFiles.some((file) => /STRIPE_SECRET_KEY|STRIPE_WEBHOOK_SECRET|from\s+["']stripe["']|require\(["']stripe["']\)|new\s+Stripe|stripe\.webhooks|checkout\.session\.completed/i.test(`${file.path}\n${file.content}`));
     const findings = [];
@@ -164,3 +164,7 @@ function firstSnippetMatching(content, pattern) {
     const line = firstLineMatching(content, pattern);
     return line ? lineAt(content, line) : undefined;
 }
+function isDocumentationFile(path) {
+    const normalizedPath = path.replace(/\\/g, "/").toLowerCase();
+    return normalizedPath.startsWith("docs/") || /\.(md|mdx|rst|txt)$/i.test(normalizedPath);
+}

package/docs/github-action.md

@@ -2,7 +2,7 @@
 
 `ai-saas-guard` ships as a composite GitHub Action for pull request and code scanning workflows.
 
-Use `zr9959/ai-saas-guard@v0` for the latest compatible pre-1.0 Action. Use a specific tag such as `v0.4.0` or a reviewed commit SHA when reproducibility is more important than automatic minor updates.
+Use `zr9959/ai-saas-guard@v0` for the latest compatible pre-1.0 Action. Use a specific tag such as `v0.6.0` or a reviewed commit SHA when reproducibility is more important than automatic minor updates.
 
 ## PR Summary
 

package/docs/launch-readiness-checklist.md

@@ -0,0 +1,191 @@
+# Launch Readiness Checklist
+
+Use this checklist when an AI-built SaaS app is close to launch, a founder is about to invite real users, or a reviewer needs a practical pre-merge review path.
+
+This is not a full security audit, penetration test, compliance review, or proof that the app is secure. It is a founder-readable launch preflight that combines `ai-saas-guard` findings with manual verification for the most common SaaS launch blockers.
+
+## Start With The Local Preflight
+
+Run from the app repository:
+
+```bash
+npx ai-saas-guard@latest scan --root .
+npx ai-saas-guard@latest pr-risk --root . --base origin/main
+npx ai-saas-guard@latest check-supabase --root .
+npx ai-saas-guard@latest check-stripe --root .
+npx ai-saas-guard@latest check-mcp --root .
+```
+
+Treat every finding as a review queue item. The tool is read-only and local-first, so it can show where to inspect, but it cannot confirm production settings, account ownership, live Stripe dashboard state, or every possible authorization path.
+
+## Launch Blocker Rules
+
+Use these labels while reviewing:
+
+| Level | Meaning | Examples |
+| --- | --- | --- |
+| Launch blocker | Do not ship until fixed or explicitly disabled for the product. | Any user can read another tenant's data, unsigned Stripe webhooks grant access, real secrets are committed. |
+| Must verify | Shipping may be reasonable only after a named manual test passes. | Rate limits, billing lifecycle handling, storage object scope, rollback path. |
+| Follow-up | Track after launch when the current product risk is bounded. | Extra docs, sharper false-positive suppression, non-critical workflow polish. |
+
+If a finding affects auth, billing, user data, secrets, file storage, production deploy config, or MCP tools with side effects, assume it is at least "must verify" until a human has tested the exact path.
+
+## Two-Account Authorization Testing
+
+Two-account authorization testing is the fastest manual check for broken SaaS isolation.
+
+Prepare two ordinary test accounts:
+
+- User A in organization or workspace A.
+- User B in organization or workspace B.
+- At least one private object owned by each account or workspace: project, document, invoice, file, message, API key, or team member.
+
+Verify read isolation:
+
+- Log in as User A and open User A's private objects.
+- Try to load User B's object by changing route parameters, object IDs, slugs, search filters, API URLs, and browser history entries.
+- Repeat the same checks through direct API calls if the app exposes JSON routes.
+- Confirm User A receives a 403 or 404 and no object metadata leaks in the response.
+
+Verify write isolation:
+
+- As User A, try to update, delete, invite users to, export, or share User B's objects by tampering with IDs.
+- Confirm the server rejects the request, not only the UI.
+- Confirm no partial write, audit entry, billing change, storage object, notification, or background job was created.
+
+Verify tenant switching:
+
+- If a user can belong to multiple workspaces, switch active workspaces and repeat the same read/write checks.
+- Confirm server-side ownership checks use the selected tenant membership, not only a client-side workspace ID.
+
+For Supabase apps, compare these manual checks with row-level security policy evidence from `check-supabase`. RLS should protect sensitive tables even when a route, query builder, or generated client code is wrong.
+
+## Stripe Webhook Verification
+
+Stripe webhook verification is required for subscription or credit products because checkout redirects are not billing truth.
+
+Minimum checks:
+
+- The webhook route reads the raw request body.
+- The handler verifies the `Stripe-Signature` header with the server-only webhook secret before any database write.
+- The signing secret is never exposed through `NEXT_PUBLIC_*`, client bundles, public logs, issue comments, or screenshots.
+- The handler stores or dedupes `event.id`.
+- Entitlement state is updated from Stripe webhook reconciliation, not only from checkout success pages.
+
+Replay the critical billing paths with the companion cookbook:
+
+```bash
+stripe listen --forward-to localhost:3000/api/stripe/webhook
+stripe trigger checkout.session.completed
+stripe trigger invoice.payment_failed
+stripe trigger customer.subscription.updated
+stripe trigger customer.subscription.deleted
+stripe trigger charge.refunded
+```
+
+Expected evidence:
+
+- Checkout success grants the right user or tenant access only after signature verification.
+- Failed invoice creates the intended past-due or grace state.
+- Subscription updates reconcile plan, quantity, status, cancellation, and period fields.
+- Cancellation revokes or downgrades paid access.
+- Refund handling is explicit, even if the product requires manual review.
+- Duplicate delivery of the same event ID is a no-op.
+- Out-of-order events reconcile to one durable entitlement state.
+
+See [stripe-webhook-replay.md](stripe-webhook-replay.md) for the full command cookbook.
+
+## MCP Config Review
+
+MCP config review matters because local tools can turn prompt injection into filesystem, shell, database, or network side effects.
+
+Inventory every MCP server used by the app, agent, or development workflow:
+
+- Config files such as `.mcp.json`, `.cursor/mcp.json`, `claude_desktop_config.json`, or tool-specific equivalents.
+- Tool descriptions that expose shell commands, raw SQL, browser automation, filesystem writes, or deployment actions.
+- Environment variables and credentials passed to MCP servers.
+- Bind addresses and transport URLs.
+
+Review questions:
+
+- Does any MCP server bind to `0.0.0.0` or a non-localhost host?
+- Does any tool allow broad filesystem read/write access outside the intended repository?
+- Does any tool run arbitrary shell commands or raw SQL against production-like data?
+- Are credentials stored in plaintext config files?
+- Are secret-bearing config files group-readable or world-readable?
+- Can the tool mutate billing, user access, customer data, or deploy state without a human approval step?
+
+Launch blocker examples:
+
+- A production database URL is stored in an MCP config.
+- A broad filesystem tool can write outside the app repository.
+- A shell or SQL tool is exposed to untrusted prompts without environment separation.
+
+Use `check-mcp` findings as the starting inventory, then manually inspect any tool that can read secrets or change state.
+
+## Supabase And Storage
+
+For Supabase apps, launch only after the data model has an ownership story.
+
+Check:
+
+- Sensitive tables have RLS enabled.
+- Policies use `auth.uid()` or tenant membership checks tied to the row.
+- Write policies use `WITH CHECK` so users cannot insert or move rows into another tenant.
+- Storage buckets and `storage.objects` policies are scoped by owner, tenant, or object path.
+- Service-role keys stay server-only and are not used in browser code.
+
+Manual verification should still use the two-account flow above. Scanner findings can point to weak policies, but the actual product workflow determines whether access is correctly isolated.
+
+## Secrets, Env, And Deploy
+
+Before launch:
+
+- Rotate any real secret that was committed, pasted into a public issue, or printed in a public log.
+- Confirm examples use inert placeholders, not real-looking provider tokens.
+- Confirm `NEXT_PUBLIC_*` variables contain only values that are safe for browsers.
+- Check `.env.example` or deploy docs include required production variables without revealing secret values.
+- Confirm Vercel, Netlify, or other deploy settings match runtime expectations: API routes are not accidentally static, and Node-only libraries are not deployed to incompatible Edge runtimes.
+
+## CI And PR Review
+
+Minimum repository workflow:
+
+- CI runs tests on pull requests and pushes to the default branch.
+- `ai-saas-guard pr-risk` runs with enough git history to compare against the base branch.
+- SARIF or markdown output is used when reviewers need scan results in GitHub.
+- Large AI-generated pull requests are split when they combine UI, auth, database, billing, and deploy changes.
+
+Review the first files named by `pr-risk` before reviewing cosmetic changes. If a base ref is missing, fix checkout depth or fetch history before trusting the PR risk result.
+
+## Rollback And Incident Readiness
+
+Before inviting real users, define:
+
+- How to disable paid access changes without deleting customer data.
+- How to revoke or rotate leaked keys.
+- How to roll back a failed deployment.
+- How to pause new signups or billing flows.
+- Where webhook delivery failures, auth errors, and database policy denials are logged.
+- Who decides whether a finding is a launch blocker or an accepted risk.
+
+The goal is not a perfect process. The goal is that the founder can answer what happens when auth, billing, deploy, or data isolation fails on launch day.
+
+## Founder Sign-Off
+
+A launch-ready review should leave behind short evidence, not just a feeling.
+
+Use this minimal sign-off:
+
+| Area | Evidence to keep |
+| --- | --- |
+| CLI preflight | Command output or CI link for `scan` and focused checks |
+| Two-account authorization | User A/User B notes with tested object types and rejected actions |
+| Stripe | Webhook replay notes for success, failure, update, cancellation, refund, duplicate, and out-of-order paths |
+| Supabase | RLS and storage policy review notes |
+| MCP | Reviewed MCP config files and disabled or constrained risky tools |
+| Secrets | Rotation notes or confirmation that only placeholders were found |
+| Deploy | Production env and runtime checks |
+| Rollback | Known rollback command or deploy platform rollback path |
+
+If any row is blank for a product surface the app actually uses, treat it as a must-verify item before launch.

package/docs/npm-publishing.md

@@ -5,10 +5,10 @@
 ## Current State
 
 - Package name: `ai-saas-guard`
-- Current version: `0.4.0`
+- Current version: `0.6.0`
 - npm registry state: published at <https://www.npmjs.com/package/ai-saas-guard>
 - First npm-published version: `0.1.1`
-- GitHub Release: `v0.4.0`
+- GitHub Release: `v0.6.0`
 - Publish workflow: `.github/workflows/npm-publish.yml`
 - Trusted Publisher: GitHub Actions, `zr9959/ai-saas-guard`, workflow `npm-publish.yml`, allowed action `npm publish`
 - Long-lived npm publish token: not required
@@ -17,7 +17,7 @@
 
 Use GitHub Actions with npm Trusted Publisher/OIDC:
 
-1. Create and review a release tag such as `v0.4.0`.
+1. Create and review a release tag such as `v0.6.0`.
 2. Publish from the GitHub Release or run the `Publish npm` workflow manually with `ref` set to that tag.
 3. Keep `permissions.id-token: write` in the workflow so npm can exchange the GitHub Actions OIDC identity for a short-lived publish credential.
 4. Run `npm publish --access public` from the workflow. Trusted publishing automatically generates provenance for this public package from this public repository.

package/docs/project-handoff.md

@@ -39,7 +39,9 @@ Do not market it as a full pentest, full SAST platform, or proof that an app is
 Implemented surfaces:
 
 - secret-like values and risky public env exposure
+- founder-readable launch-readiness checklist for two-account authorization, Stripe webhook verification, MCP config review, Supabase, deploy, CI, and rollback checks
 - Stripe webhook signature, raw body, idempotency, and lifecycle handler heuristics
+- Stripe webhook replay cookbook for checkout, renewal failure, updates, cancellation, refunds, duplicate delivery, and out-of-order review
 - Supabase RLS, tenant membership, ownership filter, weak `WITH CHECK`, and storage object policy heuristics
 - sensitive API route heuristics
 - MCP config side-effect and secret-bearing risk inventory
@@ -99,8 +101,7 @@ GitHub Project:
 
 Current issue set:
 
-- #1 Add launch-readiness checklist content
-- #5 Write Stripe webhook replay cookbook
+- No open roadmap issues after the `v0.6.0` checklist release.
 
 CI:
 
@@ -112,7 +113,7 @@ CI:
 Publishing:
 
 - npm package: `ai-saas-guard`
-- Current release line: `v0.4.0`
+- Current release line: `v0.6.0`
 - Publish workflow: `.github/workflows/npm-publish.yml`
 - Trusted Publisher: GitHub Actions for `zr9959/ai-saas-guard`, workflow `npm-publish.yml`
 - Long-lived npm publish tokens should not be required.
@@ -139,10 +140,8 @@ Not allowed:
 
 Recommended order:
 
-1. Write Stripe webhook replay cookbook.
-2. Add launch-readiness checklist content.
-3. Improve false-positive suppression and rule stability labels.
-4. Add a GitHub App design note for the potential hosted layer.
+1. Improve false-positive suppression and rule stability labels.
+2. Add a GitHub App design note for the potential hosted layer.
 
 For every feature, keep the scanner evidence-first:
 

package/docs/stripe-webhook-replay.md

@@ -0,0 +1,206 @@
+# Stripe Webhook Replay Cookbook
+
+Use this cookbook after `ai-saas-guard check-stripe` flags missing signature checks, missing idempotency, missing lifecycle handlers, or unclear entitlement updates.
+
+It is a local test workflow for reviewers. It does not prove the production integration is secure, and it does not replace Stripe Dashboard checks, production endpoint configuration review, or two-account authorization tests.
+
+## Preconditions
+
+- Run against a sandbox or test-mode Stripe account.
+- Start the app locally with the same webhook route code that will be deployed.
+- Use fake local users and test subscriptions only.
+- Do not paste real API keys, signing secrets, customer data, or production URLs into issue comments or logs.
+- Make sure your handler verifies the `Stripe-Signature` header with Stripe's raw request body before changing billing state.
+
+Start local forwarding in one terminal:
+
+```bash
+stripe listen --forward-to localhost:3000/api/stripe/webhook
+```
+
+Copy the signing secret printed by `stripe listen` into your local server-only environment variable. Keep it out of client bundles and public logs.
+
+In another terminal, run the scanner first:
+
+```bash
+npx ai-saas-guard@latest check-stripe --root .
+```
+
+Use the findings as the review queue. Each finding should map to at least one replay below.
+
+## What To Observe
+
+For every replay, record these four facts:
+
+| Question | Expected evidence |
+| --- | --- |
+| Did the webhook return `2xx` only after verification and reconciliation? | Server log or test assertion |
+| Was the Stripe event ID stored or deduped? | `event.id` row, unique key, or idempotency log |
+| Did app entitlement state change correctly? | Plan, access, seat, credit, or subscription status row |
+| Is the user-facing state consistent after refresh? | Dashboard, gated route, API response, or account page |
+
+Entitlement reconciliation means the app derives access from Stripe's current billing truth, then writes one durable local state. Typical examples are `plan`, `subscription_status`, `current_period_end`, `cancel_at_period_end`, active seats, credit balance, or an access table keyed by user, organization, customer, or subscription.
+
+## Replay Matrix
+
+Run the commands one at a time. Watch both the `stripe listen` terminal and your app server logs.
+
+| Scenario | Command | What to verify |
+| --- | --- | --- |
+| Checkout success | `stripe trigger checkout.session.completed` | The app maps the Checkout Session to the correct user or tenant and grants access only after signature verification. |
+| Failed renewal | `stripe trigger invoice.payment_failed` | The app marks the subscription past-due, starts a grace path if intended, and does not leave unrestricted paid access forever. |
+| Subscription update | `stripe trigger customer.subscription.updated` | Plan, quantity, cancel-at-period-end, period end, and status changes reconcile into local entitlement state. |
+| Cancellation | `stripe trigger customer.subscription.deleted` | Access is revoked or downgraded deterministically for the correct customer or tenant. |
+| Refund | `stripe trigger charge.refunded` | Refund handling does not accidentally grant access, double-credit an account, or ignore a required downgrade workflow. |
+
+If a command is not available in your installed Stripe CLI, run `stripe trigger --help` or the event category help such as `stripe trigger customer.subscription --help`, then use the closest supported test event for the same billing state transition.
+
+## Checkout Success
+
+```bash
+stripe trigger checkout.session.completed
+```
+
+Review checklist:
+
+- The handler rejects unsigned requests before any database write.
+- The handler stores or checks the Stripe `event.id`.
+- The session is linked to a local user, organization, or tenant through metadata, customer ID, or subscription ID.
+- The app does not grant access only from the success redirect page.
+- Refreshing the app shows access from database state, not from a one-time URL parameter.
+
+`ai-saas-guard` findings this can validate:
+
+- `stripe.webhook.missing-signature`
+- `stripe.webhook.no-entitlement-path`
+- `stripe.webhook.missing-idempotency`
+
+## Failed Invoice
+
+```bash
+stripe trigger invoice.payment_failed
+```
+
+Review checklist:
+
+- The local subscription is not left as fully active without a documented grace policy.
+- The app records failure state in the same entitlement system used by normal access checks.
+- Customer notification or billing portal recovery is queued if that is part of the product flow.
+- A later recovery event can move the account back to the intended state without manual database edits.
+
+`ai-saas-guard` findings this can validate:
+
+- `stripe.webhook.missing-critical-event`
+- `stripe.webhook.no-entitlement-path`
+
+## Subscription Update
+
+```bash
+stripe trigger customer.subscription.updated
+```
+
+Review checklist:
+
+- Plan upgrades and downgrades update the local plan or entitlement rows.
+- Seat quantity changes do not leave stale access.
+- `cancel_at_period_end` and period boundaries are persisted if the app uses them.
+- The handler reconciles from Stripe identifiers instead of trusting a client-provided user ID.
+
+`ai-saas-guard` findings this can validate:
+
+- `stripe.webhook.missing-critical-event`
+- `stripe.webhook.no-entitlement-path`
+
+## Cancellation
+
+```bash
+stripe trigger customer.subscription.deleted
+```
+
+Review checklist:
+
+- The correct user, organization, or tenant loses paid access.
+- Shared team access is downgraded consistently, not only the account owner.
+- The app handles repeated cancellation events without throwing or creating inconsistent rows.
+- Historical records remain available only according to product policy.
+
+`ai-saas-guard` findings this can validate:
+
+- `stripe.webhook.missing-critical-event`
+- `stripe.webhook.missing-idempotency`
+
+## Refund
+
+```bash
+stripe trigger charge.refunded
+```
+
+Review checklist:
+
+- Refund handling is explicit, even if the intended action is "record and review manually."
+- Credits, invoices, or access extensions are not applied twice.
+- Refund events do not bypass subscription status checks.
+- Support/admin workflows have enough evidence to understand which customer, invoice, and subscription were involved.
+
+`ai-saas-guard` findings this can validate:
+
+- `stripe.webhook.missing-critical-event`
+- `stripe.webhook.no-entitlement-path`
+
+## Duplicate Event Replay
+
+Stripe can retry events, and the same event can reach your handler more than once. Your handler should be idempotent around the Stripe event ID and the domain object it mutates.
+
+Practical replay:
+
+```bash
+stripe trigger checkout.session.completed
+```
+
+Then replay the same captured event through your own test harness, fixture, or integration test. The important assertion is not that the Stripe CLI creates the same event twice; it is that your app has a test path where the same `event.id` is processed twice and the second attempt is a no-op.
+
+Review checklist:
+
+- `event.id` is stored with a unique constraint or equivalent dedupe guard.
+- The second delivery returns success without repeating fulfillment.
+- Access grants, invoices, credits, seats, and emails are not duplicated.
+- The handler is safe if the first attempt partially wrote state and then crashed.
+
+`ai-saas-guard` findings this can validate:
+
+- `stripe.webhook.missing-idempotency`
+
+## Out-of-Order Event Questions
+
+Stripe events should be treated as signals to reconcile state, not as a guarantee that the app saw every prior transition in the expected order.
+
+Use these questions during review:
+
+- What happens if `customer.subscription.updated` arrives before the app processed `checkout.session.completed`?
+- What happens if `invoice.payment_failed` arrives after a manual admin upgrade?
+- What happens if `customer.subscription.deleted` arrives after a refund workflow already changed local access?
+- Does the handler fetch or derive current subscription/customer state before writing final entitlement state?
+- Is the local write guarded by Stripe customer, subscription, and tenant ownership, not just by event type?
+
+When possible, add tests that call the entitlement reconciliation function directly with events in a different order. The durable result should match Stripe's current billing truth and the product's explicit grace/cancellation policy.
+
+## Minimal Acceptance Checklist
+
+Before launch or merge, a reviewer should be able to answer yes to each item:
+
+- Unsigned webhook requests are rejected before database writes.
+- Raw request body is used for signature verification.
+- Every handled event stores or dedupes `event.id`.
+- `checkout.session.completed` grants access through webhook reconciliation, not only redirect success.
+- `invoice.payment_failed` has an explicit past-due or grace behavior.
+- `customer.subscription.updated` updates plan, quantity, period, cancellation, and status fields used by access checks.
+- `customer.subscription.deleted` revokes or downgrades access for the correct user or tenant.
+- `charge.refunded` has an explicit record, downgrade, or manual review path.
+- Duplicate deliveries are no-ops after the first successful reconciliation.
+- Out-of-order events reconcile to one durable local entitlement state.
+
+## Source Links
+
+- Stripe CLI trigger docs: https://docs.stripe.com/stripe-cli/triggers
+- Stripe CLI forwarding docs: https://docs.stripe.com/stripe-cli/use-cli
+- Stripe webhook signature docs: https://docs.stripe.com/webhooks/signature

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-saas-guard",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "Repo-local launch-readiness scanner for AI-built SaaS apps.",
   "type": "module",
   "homepage": "https://github.com/zr9959/ai-saas-guard#readme",