b2c-app-builder 0.221.39

package/knowledge/trust/community-safety.md

@@ -0,0 +1,18 @@
+# Community And User Safety
+
+## Applicability
+
+Use this guide when users can create, share, discover, or message content.
+
+## Required controls
+
+Define content rules, moderation, reporting, blocking, escalation, age controls, and a support contact. Set a response target and an owner. Test abuse reporting, user blocking, appeal, and account recovery. Record the evidence and the unresolved risks.
+
+## Output
+
+Write the controls and proof in `trust/COMMUNITY_SAFETY.md`.
+
+## Sources
+
+- [Apple App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)
+- [Google Play user-generated content policy](https://support.google.com/googleplay/android-developer/answer/12923286?hl=en)

package/knowledge/trust/generative-ai-safety.md

@@ -0,0 +1,27 @@
+# Generative-AI Safety
+
+## Applicability
+
+Use this guide when the app generates text, images, audio, or video.
+
+## Required controls
+
+Define prohibited uses and the controls for input, output, reporting, enforcement, and human escalation. Record the model and provider responsibilities. Test harmful, deceptive, exploitative, and sexual-content abuse cases. Set an owner and response target for each failure class.
+
+Any product with generative or conversational AI needs a named self-harm and crisis response: detect self-harm, suicide, or crisis language in user input, and respond with an in-context crisis resource (a crisis line or local emergency guidance) instead of a generic refusal or an ordinary completion. Route to human escalation when the model provider's own safety layer does not already cover this. Test the self-harm path explicitly — a general "harmful content" test does not exercise it — and record the detection method, the response copy, and the escalation owner in `trust/AI_SAFETY.md`. `check:privacy` (`privacy-terms.md` §7, risk 10) checks that `trust/AI_SAFETY.md` names this path whenever it exists.
+
+## Escalation Signal Design
+
+Use three separate escalation triggers: an explicit human request, a policy or scope gap, and an exhausted retry budget. Frustration and an explicit human request are different signals. Never treat anger or repeated questions alone as a request for a human. Route only an explicit request straight to human escalation.
+
+## Output
+
+Write the controls and proof in `trust/AI_SAFETY.md`.
+When a capability can create paid model-provider spend, also write `trust/AI_PROVIDER_CONTROLS.md`.
+Write that file even when paid generation does not apply.
+Record `Paid generation: not applicable` plus a named reason.
+Load `paid-generative-ai-controls.md` for that cost-boundary contract.
+
+## Source
+
+- [Google Play AI-generated content policy](https://support.google.com/googleplay/android-developer/answer/14094294?hl=en)

package/knowledge/trust/paid-generative-ai-controls.md

@@ -0,0 +1,85 @@
+# Paid Generative-AI Controls
+
+Use this before any app capability can create paid model-provider spend.
+Safety content rules still live in `generative-ai-safety.md`.
+This file is the cost-boundary contract those safety rules do not carry.
+
+Write the machine-readable control record in `trust/AI_PROVIDER_CONTROLS.md`.
+Keep the human incident runbook in the same file.
+
+## Contents
+
+- 1. Control Record
+- 2. Spend Boundary
+- 3. Secret Binding
+- 4. Logging And Rotation
+- 5. Cap Status
+- 6. Outputs
+- 7. Common Failure Modes
+
+## 1. Control Record
+
+Trace every paid AI entry point to all of these controls:
+
+1. Server-side authentication. Verified identity before the first paid call.
+2. Server-side entitlement for paid or recurring behavior.
+3. Per-owner throttles and global daily and monthly ceilings.
+4. Atomic or compensating pre-call reservations.
+5. Conservative accounting for timeouts, refusals, provider errors, and invalid output.
+6. Request, context, output-token, and timeout limits.
+7. A fail-closed operator kill switch that does not disable free or manual product behavior.
+8. One approved secret runtime. No provider key in clients, public build variables, analytics, logs, or duplicated edge proxies.
+9. Prompt, response, and identity-proof logging rules.
+10. Key-rotation and suspected-exposure procedures.
+11. Separate status for application-level caps and provider-account billing caps.
+
+Size item 6 from a per-request cost model. Name each cost component: input tokens, output tokens, and cache-token reads and writes, at the provider's current published rates. Count the real token payload, or call the provider's token-counting endpoint. Never estimate token count from character count.
+
+Each business records its own founder-approved limits.
+This file does not set universal dollar values.
+
+## 2. Spend Boundary
+
+Anonymous and unverified requests cannot reach paid generation.
+A failed or malformed provider response cannot reduce recorded spend below the reservation.
+Concurrent calls cannot cross the configured daily or monthly application ceiling.
+Paid recurring behavior cannot run without active entitlement.
+
+## 3. Secret Binding
+
+The provider credential stays on the backend.
+Do not embed a key in a browser or mobile client.
+Do not put a key in public build variables.
+
+## 4. Logging And Rotation
+
+Logs and analytics exclude prompts, responses, secrets, session tokens, and identity proofs.
+A model, pricing, token-limit, or request-size change invalidates cost assumptions until review.
+
+## 5. Cap Status
+
+Application cap status and provider-account cap status are separate fields.
+One cannot imply the other.
+Unknown provider-console state stays unknown.
+
+## 6. Outputs
+
+- Control table in `trust/AI_PROVIDER_CONTROLS.md`
+- Bound paid entry points
+- Kill-switch exercise evidence that preserves the free path
+- Production readback and rollback instructions before the capability is ready
+
+Paid generation applies when product evidence shows model-provider spend.
+`check:ai-provider-controls` then requires `trust/AI_PROVIDER_CONTROLS.md`.
+A missing file is an error in that case.
+Write `Paid generation: not applicable` plus a named reason when spend cannot occur.
+A named not-applicable line does not skip the file when product evidence shows paid provider use.
+`check:repository-profile` uses the same applicability parser.
+
+## 7. Common Failure Modes
+
+- A public web proxy that reaches the model without verified-account auth
+- Failed calls that release their reservations
+- A reusable identity token that creates more sessions
+- A kill switch that also disables free or manual behavior
+- Using application cap status as proof of the provider-account cap

package/knowledge/trust/privacy-terms.md

@@ -0,0 +1,192 @@
+# Privacy And Terms Pages
+
+Use this before drafting or publishing privacy policy, terms of service, EULA, subscription terms, account deletion, privacy choices, App Store privacy answers, or Google Play Data safety answers.
+
+This is a workflow, not legal advice. Agents may research, draft, implement pages, and prepare review packets. Founder/legal approval is required before publishing final legal terms or making material privacy promises.
+
+When store submission is in scope, also load `store-console-workflow.md`. For Apple App Store listings, also load `app-store-listing-prep.md` and use `business/store/app-store-listing/app-privacy-questionnaire.html` or an equivalent interactive worksheet when the founder needs to review privacy answers. Privacy/terms work must produce the public pages and the console answers: Apple App Privacy data types, Google Play Data safety answers, account deletion URLs, reviewer access notes, and source evidence.
+
+## Contents
+
+- 1. Refresh Official Sources
+- 2. Build The Data Inventory First
+- 3. Privacy Policy Drafting Rules
+- 4. Terms/EULA Drafting Rules
+- 5. Public Pages And App Links
+- 6. Review Packet
+- 7. Legal & Privacy Risk Checklist
+
+## 1. Refresh Official Sources
+
+Always verify current requirements before drafting. Prefer official platform, regulator, and vendor docs.
+
+Baseline sources to check:
+
+- Apple App Privacy Details and App Store Connect EULA/custom license guidance for iOS.
+- Google Play User Data and Data safety requirements for Android.
+- Apple App Review Guideline 3.1.1, Google Play Payments policy, RevenueCat, Stripe, and tax/customer-portal docs when subscriptions, paid access, web checkout, or direct funnels exist.
+- FTC privacy/security guidance for mobile apps, health/wellness data, children, subscriptions, advertising, and security.
+- California CCPA/CPRA and CalOPPA guidance if the app serves U.S. consumers or California users.
+- EU/EEA GDPR transparency guidance if the app is offered to EU/EEA users.
+- Vendor docs for analytics, attribution, ads, AI providers, payment/subscription tooling, backend, email, crash reporting, and push notifications. For PostHog, refresh product analytics, web analytics, mobile SDK, anonymous vs identified events, persons/properties, feature flags/experiments, session replay privacy, surveys, and data pipeline docs when those features are used.
+
+Record checked sources, dates, and URLs in `LEGAL_REVIEW.md`. Mirror store-specific sources and final console answers in `store/STORE_CONSOLE.md` when App Store Connect or Google Play Console submission is in scope.
+
+## 2. Build The Data Inventory First
+
+Do not draft from a template first. Inventory actual data flows from code and launch docs:
+
+- Landing: email, referral code, IP/rate-limit signals, cookies/localStorage, UTM/referrer, analytics, A/B tests.
+- App account: email, auth ID, profile, subscription entitlement, support IDs.
+- User content: goals, notes, photos, journal entries, plans, messages, crew/social content.
+- Device/platform data: push token, device ID, advertising ID, precise/coarse location, contacts, calendar, camera, microphone, HealthKit/Health Connect, files/photos.
+- Backend: database tables, storage buckets, logs, edge functions, RPCs, retention jobs.
+- Analytics and ads: events, PostHog person profiles, UTM/referrer/click IDs, self-reported attribution, session replay, heatmaps, surveys, feature flags, experiments, data pipelines/destinations, pixels, ad networks.
+- Payments/subscriptions: RevenueCat/Stripe/Apple/Google identifiers, purchase history, refund status.
+- AI: prompts, outputs, model provider, model-training settings, human review, logging/retention.
+- Support/comms: email provider, CRM, feedback forms, transactional email, push providers.
+- Security: audit logs, fraud prevention, abuse reports, rate limits.
+
+For each data type, record:
+
+- source surface
+- purpose
+- whether required or optional
+- whether linked to identity
+- whether shared with a vendor
+- whether sold/shared for cross-context advertising
+- retention period
+- deletion path
+- app-store disclosure mapping
+
+## 3. Privacy Policy Drafting Rules
+
+The policy must reflect actual practices, not aspirations. Include:
+
+- effective date and last updated date
+- legal/business entity, app/site names covered, and privacy contact
+- what data is collected, grouped by user-understandable categories
+- why each category is used
+- vendors/processors and categories of recipients
+- tracking, ads, analytics, attribution, and cross-app/site sharing
+- AI processing and whether user content is used for model training
+- subscriptions/payments and what Apple/Google/Stripe/RevenueCat process
+- web checkout, web funnels, redemption links, billing portal/customer portal, tax collection, invoices/receipts, refunds, and subscription lifecycle emails when used
+- Resend or other email-provider behavior: transactional email, lifecycle automations, broadcasts/newsletters, contacts/topics/segments, unsubscribe/preference handling, open/click tracking if enabled, inbound email and attachments if used, and retention/deletion behavior
+- device permissions and just-in-time notices for sensitive/unexpected data
+- retention and deletion, stated so it is clear that account/content deletion purges stored uploads (photos, files, media) in the object store alongside the database rows, not just a hidden flag
+- account deletion and data request URL if accounts exist
+- children/age posture
+- health, biometrics, precise location, contacts, calendar, or other sensitive data sections when relevant
+- user rights by jurisdiction where applicable
+- security summary in plain language
+- international transfers where applicable
+- policy changes and contact
+
+### Optional drafting benchmark
+
+Complete the data inventory first. Then, agents may compare the draft with the [General Legal template collection](https://github.com/General-Legal/legal-templates). The collection uses CC0. It includes U.S. and GDPR-enhanced privacy policies, terms of use, cookie notices, and data-processing addenda.
+
+Use the collection to check document structure and find possible clauses. Do not use it as current law or a complete product policy. Do not copy optional text unless the product implements the stated practice. Resolve every `<mark>` placeholder. Check the jurisdiction and each material clause against current official sources. The founder or counsel makes the final legal decision.
+
+Platform must-haves:
+
+- Apple requires a publicly accessible privacy policy URL and accurate App Privacy responses, including third-party partner practices.
+- Google Play requires a privacy policy link in Play Console and in-app link/text; the policy must include developer/contact info, data accessed/collected/used/shared, parties shared with, secure handling, retention/deletion, and be active, public, non-geofenced, non-editable, and not a PDF.
+- If accounts can be created, publish a web account-deletion path and explain retained data.
+- Privacy, support, and data-deletion contact addresses must be route-tested before publishing. If using Cloudflare Email Routing, verify destination addresses, enable/connect Email Routing, configure required DNS records, and test from an external sender. Do not assume inbound forwarding also supports outbound send-as.
+
+## 4. Terms/EULA Drafting Rules
+
+Terms should match the product and payment behavior. Include:
+
+- effective date, contracting entity, and contact
+- who may use the service and age restrictions
+- account responsibilities and acceptable use
+- license to use the app/service
+- user content ownership, permissions, and removal/moderation if user content exists
+- AI-generated content/coaching disclaimers if AI is used
+- professional-advice disclaimers for health, wellness, financial, legal, education, or productivity coaching claims where relevant
+- subscription, trial, renewal, cancellation, refund, and price-change terms
+- platform billing terms: Apple/Google manage in-app purchases when used
+- intellectual property and feedback
+- third-party services
+- privacy-policy cross-reference
+- warranty disclaimer, limitation of liability, indemnity, termination, changes, governing law, dispute resolution, and severability
+
+Apple-specific:
+
+- Decide whether Apple's standard EULA is enough or a custom EULA/terms is needed.
+- If using a custom EULA in App Store Connect, keep it plain text and ensure it meets Apple's minimum terms.
+
+Subscription-specific:
+
+- Paywall, App Store/Play listing, terms, and in-app subscription management copy must agree on price, trial length, renewal cadence, cancellation, and what happens after cancellation.
+- Do not bury trial-to-paid conversion or cancellation mechanics only in terms.
+- Cancellation must be self-service and at least as easy as signing up — in-app or through the same platform (App Store, Google Play, or the account settings a subscriber already has access to) and never gated behind contacting support, a phone call, or a retention flow. This is the FTC "click to cancel" rule; several states mirror it.
+- Auto-renewal disclosure states the renewal cadence and price and commits to sending a renewal-reminder notice before the charge for any trial or renewal term state auto-renewal law covers (commonly annual-or-longer terms; California and several other states require advance notice). Do not disclose auto-renewal only in terms and skip the reminder commitment.
+- Web checkout/funnel pages must disclose the billing provider, renewal price, cancellation path, refund/support contact, and whether access is redeemed in app through RevenueCat or another entitlement system.
+
+## 5. Public Pages And App Links
+
+For launch funnels and apps, create URLs that are stable before store submission:
+
+- `/privacy` - privacy policy
+- `/terms` - terms of service or terms of use
+- `/privacy/choices` or `/data` - rights, privacy choices, and account/data deletion when applicable
+- `/delete-account` - direct account deletion instructions or request form when app accounts exist
+
+Verification:
+
+- pages return HTTP 200 on canonical domain
+- linked in footer, app settings, onboarding/paywall where relevant, App Store Connect, Play Console
+- contact emails listed on the pages receive mail and have an owner — before writing any `@yourdomain.com` address into copy, run `dig MX yourdomain.com +short` to confirm MX records exist; if none, use a tested fallback and open a `legal-contact-email-mx-unverified` failure card (see `knowledge/growth/geo-seo.md` section 4a)
+- readable on mobile
+- not blocked by robots/auth/geofencing
+- not a PDF for Google Play privacy policy
+- app-store labels/data safety answers match the pages
+
+## 6. Review Packet
+
+Before publishing final legal pages, produce `LEGAL_REVIEW.md` with:
+
+- official sources checked
+- data inventory table
+- vendors and SDKs
+- draft page paths
+- app-store disclosure mapping
+- App Store Connect App Privacy and Google Play Data safety answer mapping, with click paths and field values when submission is in scope
+- interactive App Privacy questionnaire path and unanswered/manual-review items when Apple listing prep is in scope
+- subscription and refund terms
+- account deletion flow
+- known uncertainty and legal questions
+- approval checkbox for founder/counsel
+
+Never mark legal pages final without approval. If the founder wants a fast pre-launch page, label it as a draft pending counsel review in internal docs, but do not put that disclaimer on the public policy unless counsel approves.
+
+## 7. Legal & Privacy Risk Checklist
+
+These are the concrete rejection and legal-exposure risks reviewers, app-store review, and regulators actually flag against consumer apps. Each has an owning artifact and, where it is mechanically checkable, a validator code. `check:privacy` enforces the checkable subset (rows 1, 2, 4, 5, 6, and — when the row's condition is in scope — 3, 8, 9, 10); everything else, including row 7, stays a judgment call owned by another audit pass so it is judged once, not twice.
+
+| #   | Risk                                 | Requirement                                                                                                                                                                              | Owning artifact                                                               | Validator code                                                                               |
+| --- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
+| 1   | No privacy policy                    | Publish `trust/PRIVACY.md` and `trust/TERMS.md` before launch                                                                                                                            | `trust/PRIVACY.md`, `trust/TERMS.md`                                          | `privacy.policy_missing`, `privacy.terms_missing`                                            |
+| 2   | No "we collect user data" disclosure | State plainly, in a section a reader can find, what data is collected                                                                                                                    | `trust/PRIVACY.md`                                                            | `privacy.data_collection_disclosure_missing`                                                 |
+| 3   | No AI mention in the privacy policy  | When the product generates content, disclose AI/model processing and whether user content trains a model                                                                                 | `trust/PRIVACY.md`                                                            | `privacy.ai_disclosure_missing`                                                              |
+| 4   | No third-party data collectors named | Name vendor/processor/third-party categories and what they receive                                                                                                                       | `trust/PRIVACY.md`                                                            | `privacy.third_party_disclosure_missing`                                                     |
+| 5   | Not deleting user uploads            | State the retention window, and that account/content deletion purges stored uploads, not just hides them                                                                                 | `trust/PRIVACY.md`; `engineering/TECH_SPEC.md` Data Contract retention column | `privacy.deletion_retention_missing`                                                         |
+| 6   | Storage bucket set to public         | Every storage bucket is private by default, served through RLS/security rules or signed URLs — never a bare public-read bucket (see `backend-data-contract.md` §Anti-Patterns)           | `engineering/TECH_SPEC.md` Data Contract, `trust/SECURITY.md`                 | `privacy.public_storage_bucket`                                                              |
+| 7   | Fake testimonials                    | Only real, sourced quotes with permission                                                                                                                                                | `product/experience/emotional-design/EMOTIONAL_DESIGN.md`                     | owned by `check:emotional-design` and `check:vibecoded-tells` (Tier 1) — not re-checked here |
+| 8   | Cancellation harder than signup      | Cancellation is self-service and at least as easy as signup, per §4 above                                                                                                                | `trust/TERMS.md`                                                              | `privacy.cancellation_not_self_service`                                                      |
+| 9   | Auto-renewal with no reminder        | Disclose auto-renewal terms and commit to a renewal-reminder notice before the charge, per §4 above                                                                                      | `trust/TERMS.md`                                                              | `privacy.auto_renewal_reminder_missing`                                                      |
+| 10  | AI with no self-harm response        | A product with generative or conversational AI defines a self-harm/crisis detection and response path with a real crisis resource, not a generic refusal (see `generative-ai-safety.md`) | `trust/AI_SAFETY.md`                                                          | `privacy.self_harm_response_missing`                                                         |
+
+Rows 8-9 apply only once the product sells a subscription (`lanes.revenue` in scope). Rows 3 and 10 apply only once the product generates text, images, audio, or video (`trust/AI_SAFETY.md` exists per `generative-ai-safety.md`).
+
+Run the validator:
+
+```bash
+npm run check:privacy -- --root /path/to/app
+```
+
+`check:privacy` checks for the presence of each disclosure, not its legal correctness — pair a passing run with the founder/counsel review in `LEGAL_REVIEW.md` §6. A green gate is not legal sign-off.

package/knowledge/trust/security-release-hardening.md

@@ -0,0 +1,169 @@
+# Security Release Hardening
+
+Use this before app architecture is frozen, before beta/TestFlight/store submission, before provider webhooks mutate state, or when the user asks about security hardening, Claude Security, Codex Security, OWASP MASVS, MobSF, Sentry, app integrity, threat modeling, or release readiness.
+
+Before marking this lane done, load [`provider-proof.md`](../process/provider-proof.md): provider-backed readiness needs live proof or a recorded founder-only decision in `operations/PROVIDER_PROOF.md`, never setup prose alone.
+
+Security is a launch lane, not a cleanup pass. Create or refresh `trust/SECURITY.md` early enough to influence `engineering/TECH_SPEC.md`, `engineering/ENGINEERING_PLAN.md`, `trust/PRIVACY.md`, `analytics/ANALYTICS.md`, `revenue/REVENUE_OPS.md`, `store/APPLE_SIGNING.md`, `store/STORE_CONSOLE.md`, and `engineering/PRODUCTION_READINESS.md`.
+
+## Default Output
+
+- `trust/SECURITY.md`: canonical threat model, controls, tool routing, accepted risks, and release proof.
+- `trust/security-review.html`: founder-visible rendered board showing risk, proof, and gates.
+- `state/business-state.json`: `lanes.security`, `providers.security_review`, evidence, and blockers.
+- Optional `.well-known/security.txt` or equivalent public vulnerability route when the web/app handles accounts, payments, user content, or sensitive data.
+- Optional security findings in `operations/FAILURE_CARDS.md` when risks are open.
+
+## Source Basis
+
+Refresh current docs at runtime before writing commands, claims, or setup paths:
+
+- OWASP MASVS and MASTG for mobile app controls and tests.
+- OWASP ASVS for backend/API/web funnel controls.
+- Apple Platform Security, Keychain data protection, App Transport Security, DeviceCheck, and App Attest for iOS.
+- Android security best practices, Android Keystore, Network Security Config, and Play Integrity API for Android.
+- Anthropic Claude Security and Claude Code `/security-review` docs when the user has access.
+- OpenAI Codex Security docs when the user has access.
+- MobSF docs and release notes when using local or hosted mobile scanning.
+- Sentry docs for mobile/web crash, performance, replay, PII scrubbing, release health, and alerts.
+
+Record source URLs and checked dates in `trust/SECURITY.md` and `state/business-state.json.providers.security_review.docsCheckedAt` when the route changes.
+
+## Skill And Tool Routing
+
+Use available local skills before inventing a security process:
+
+- `security-threat-model`: repository-grounded threat model, trust boundaries, assets, attacker capabilities, abuse paths, and mitigations.
+- `security-best-practices`: language/framework secure-default review for TypeScript/JavaScript, Python, and Go where supported.
+- `security-ownership-map`: sensitive-code ownership and bus-factor review when the repo has meaningful git history.
+- Sentry SDK skills: platform-specific setup for release health, crash, tracing, replay, and alert proof.
+
+Do not treat Sentry as a substitute for hardening. Sentry is monitoring and incident response; it does not prove authorization, webhook, entitlement, storage, or app-integrity controls.
+
+## Paid Tool Routing
+
+Paid or account-gated security routes require founder confirmation before fallback work:
+
+| Paid/account route                               | Use                                                           | Free or local fallback                                                       |
+| ------------------------------------------------ | ------------------------------------------------------------- | ---------------------------------------------------------------------------- |
+| Claude Security                                  | semantic security review, scheduled scans, targeted patch PRs | `security-threat-model`, `security-best-practices`, manual abuse-path review |
+| Codex Security                                   | threat-model-backed vulnerability scan, validation, patch PR  | local threat model, tests, manual code review                                |
+| GitHub Advanced Security                         | secret scanning, code scanning, dependency review             | `gitleaks`, `trufflehog`, `semgrep`, `osv-scanner`, package-manager audits   |
+| Snyk / Semgrep Cloud / Socket                    | dependency, SAST, supply-chain, malicious-package checks      | Semgrep community rules, `npm audit`, `osv-scanner`, lockfile review         |
+| MobSF Cloud or commercial mobile pentest         | APK/IPA/source static and dynamic mobile analysis             | local Docker MobSF, platform static analyzer, manual MASTG checks            |
+| Approov / Guardsquare / commercial app integrity | anti-tamper, attestation, runtime protection                  | App Attest, DeviceCheck, Play Integrity, rate limits, backend risk scoring   |
+
+Wire the chosen secret scanner as a pre-commit hook, for example `gitleaks protect --staged`. A pre-commit hook blocks a secret before the commit. A CI-only scan catches the secret only after history already holds it.
+
+Missing runtime access is not approval to use the fallback. Ask or record the blocked route in `strategy/TOOL_DECISIONS.md` and `state/business-state.json`.
+
+## trust/SECURITY.md Contract
+
+`trust/SECURITY.md` must include these sections:
+
+- Source Basis with current docs and checked dates.
+- Security Review Tool Routing with paid/account route, founder gate, selected fallback, and limitations.
+- Threat Model with assets, trust boundaries, attacker capabilities, abuse paths, and non-capabilities.
+- Data Classification with storage and logging rules.
+- Mobile Hardening for iOS and Android, marking not-applicable platform sections explicitly.
+- Authentication and Authorization, including anonymous, signed-in, subscriber, admin/support, deleted-account states.
+- Backend and API Controls: validation, authz, RLS/policies, rate limits, idempotency, retries, admin access, audit logs.
+- Revenue, Entitlements, and Abuse: RevenueCat, Stripe, app-store purchases, restores, refunds, promo grants, and webhook verification.
+- Privacy and Analytics: PostHog, session replay, survey posture, PII scrubbing, self-reported attribution, and store disclosure alignment.
+- Email and Domain Security: Resend, SPF, DKIM, DMARC, unsubscribe, inbound/reply, security alias, and webhook signing.
+- Supply Chain and Build Security: dependencies, SDK inventory, lockfiles, secret scans, signing material, CI, and generated code.
+- Monitoring and Incident Response: Sentry/release health, alerts, rollback, support escalation, store crash reports, public contact path.
+- Release Checks: command results, scanner evidence or blocked route, mobile/backend/provider evidence, and accepted risks.
+- Founder Approval Gates.
+
+Do not mark security done from prose. Security is done only when `trust/SECURITY.md`, `trust/security-review.html`, relevant scanner/review evidence, secret routing, production-readiness proof, and remaining accepted risks are all current.
+
+## Mobile Hardening Checklist
+
+For iOS:
+
+- Keychain storage for tokens and sensitive per-user values, with accessibility class chosen deliberately.
+- App Transport Security enabled; exceptions documented with owner, domain, reason, and review date.
+- App Attest or DeviceCheck considered for high-value backend actions, entitlement/reward abuse, or fraud-heavy flows.
+- Entitlements reviewed: associated domains, URL schemes, app groups, keychain access groups, push, iCloud, HealthKit, camera, location, photos, Bluetooth, contacts, notifications.
+- Deep links and universal links validate input and route only to allowed states.
+- `store/APPLE_SIGNING.md` proves Team ID, bundle ID/App ID, app record, signing, archive/export/upload/TestFlight when distribution is in scope.
+
+For Android:
+
+- Android Keystore or platform encrypted storage for tokens and sensitive values.
+- Network Security Config disallows cleartext production traffic unless a documented debug/local exception exists.
+- Play Integrity considered for high-value backend actions and enabled in observe-first mode before blocking users.
+- Exported activities/services/receivers/providers reviewed and minimized.
+- Intent/deep-link input validation and safe file/provider sharing.
+- Backup rules, signing config, ProGuard/R8/obfuscation posture, and Play Console declarations reviewed.
+
+## Backend And CRM Diagnostic Access
+
+Grant an agent role live backend or CRM read access only through a read replica, never the primary connection. A bad query then degrades a non-production system, not the live app. Scope every diagnostic API key to the object types the role needs. Keep every diagnostic query pre-written and parameterized. Do not expose raw SQL or an arbitrary query surface to the agent. A human reviews every reply before it reaches a client. This review is the control that makes the access grant acceptable.
+
+## Revenue And Entitlement Abuse
+
+Any monetized app must prove:
+
+- RevenueCat offering/product/entitlement IDs match app-store products and `revenue/REVENUE_OPS.md`.
+- App access is granted from backend/provider truth, not client-only events.
+- Stripe web checkout maps to the same entitlement as app-store purchases.
+- Webhooks verify signatures and use idempotency/replay protection before mutating entitlements — the RevenueCat and Stripe webhook setup steps live in `revenuecat-and-store-products.md` and `stripe-and-web-billing.md`; this is the security posture those steps must satisfy, not a second setup guide.
+- Restore purchases is tested end to end.
+- Refund/cancel/grace-period states are reflected in app access.
+- Support-granted entitlements record owner, reason, expiry, and rollback path.
+
+## Privacy, Analytics, And Store Alignment
+
+Security and privacy docs must agree:
+
+- `trust/SECURITY.md`, `trust/PRIVACY.md`, `analytics/ANALYTICS.md`, App Privacy answers, Google Play Data safety, and `store/STORE_CONSOLE.md` use the same SDK/data inventory.
+- Session replay and surveys include masking, sampling, consent/opt-out posture, and disclosure notes.
+- Self-reported attribution is persisted with stable keys and does not store raw sensitive data beyond the approved free-text field.
+- Sentry and analytics scrub PII where supported and do not capture raw secrets, receipts, passwords, private messages, or unsupported health/child data.
+
+## Public Security Route
+
+If the launch has accounts, payments, user content, sensitive data, or a public web funnel, include a public reporting route:
+
+- preferred: `public/.well-known/security.txt` or hosting equivalent
+- alternate: public support/security contact in privacy/support pages
+- must include contact, policy/disclosure statement, preferred language, and canonical URL when feasible
+- must not promise bug bounty, SLA, or legal terms unless the founder approved them
+
+## Validator
+
+Run:
+
+```bash
+npm run check:security -- --root /path/to/app
+```
+
+The validator checks that `trust/SECURITY.md` includes the minimum security contract, platform-specific hardening, tool-routing fallback language, revenue/webhook controls, privacy/analytics controls, email/domain security, supply-chain controls, monitoring/incident response, and founder gates. It is not a vulnerability scanner. Use it to prevent launch-package gaps, then use scanners and reviews for actual code findings.
+
+Agreement among independent reviewing agents is not proof. A 31-day, seven-target review campaign found ten independent reviewers who unanimously endorsed a padding-oracle vulnerability that did not exist. Only a proof-of-concept run killed the false finding. Close a security finding only after a deterministic check or a real proof-of-concept run confirms it.
+
+## LaunchBench Failure Mode
+
+When an agent claims an app is launch-ready without `trust/SECURITY.md`, scanner/review route, app-integrity decision, entitlement abuse controls, or incident response, add or activate a failure card:
+
+```yaml
+id: "security-release-lane-missing"
+severity: "high"
+owner: "security-architect"
+status: "open"
+next_action: "Create trust/SECURITY.md, render trust/security-review.html, run check:security, and attach scanner/review proof or founder-approved blocked route."
+validator: "npm run check:security -- --root ."
+```
+
+## Acceptance
+
+- Security lane exists in `state/business-state.json`.
+- `trust/SECURITY.md` is specific to the app, not generic boilerplate.
+- `trust/security-review.html` renders the security plan for founder review.
+- Paid security tools are used, blocked, or founder-approved for fallback.
+- Platform controls are considered for the actual platforms.
+- Monetization, backend, email, analytics, and store disclosures are covered.
+- Remaining risks have owner, reason, expiry/revisit date, and compensating control.
+- Security validator and relevant scans/reviews are recorded in `engineering/PRODUCTION_READINESS.md`.

package/knowledge/words/consumer-copy-benchmarks.md

@@ -0,0 +1,111 @@
+# Consumer Copy Benchmarks: The Live-Site Swipe-File
+
+What good consumer marketing and app copy actually looks like, distilled from a structured teardown of fifteen live consumer app surfaces (2026-08-17): wellness/habit (Headspace, Calm, Duolingo, Strava, Fabulous), newer consumer/social (Partiful, BeReal, Locket, Retro, Flighty), and utility/fintech (Cash App, Copilot Money, Monarch, 1Password, AllTrails), plus their current App Store listings and the documented paywall/onboarding case studies at growth.design. This is the words-lane counterpart to [`../design/motion-craft-benchmarks.md`](../design/motion-craft-benchmarks.md): an inspiration benchmark distilled into checkable rules, never a source to clone.
+
+Load it whenever a surface a user reads is being authored or reviewed — landing, store listing, screenshot captions, paywall, onboarding, lifecycle email, share/referral text — and when the product's voice is being established in `product/copy/COPY_BRIEF.md` and `strategy/BRAND.md`. The stable craft contract stays in [`conversion-copy.md`](./conversion-copy.md); this file is the evidence layer under it, refreshed on the source cadence in its manifest so the exemplars track what shipping consumer apps actually say.
+
+Two ground rules:
+
+- **Patterns, not clones.** Verbatim lines below are cited for study. Never reuse a benchmark brand's headline, name, or voice; derive this product's own words from its own voice-of-customer bank (`conversion-copy.md` §Voice-Of-Customer Mining).
+- **Rules are review criteria, not adjectives.** Each pattern states something a reviewer can check on the page. "Sounds consumer-grade" does not gate; "the headline's grammatical subject is the user or the outcome, not the system" does.
+
+## Contents
+
+- Sources To Refresh
+- The Consumer Register
+- Cohort Notes
+- Store Listing Rules
+- Onboarding And Paywall Rules
+- The Internal-Voice Tells (Review Layer)
+- Voice Benchmarks In The Copy Brief
+- Gates
+
+## Sources To Refresh
+
+Re-tear down these surfaces on the manifest cadence; update exemplars and, when a new tell earns hard-ban confidence, promote it into `conversion-copy.md` §Banned In App Copy so `check:app-copy` follows:
+
+- Wellness/habit cohort: `https://www.headspace.com`, `https://www.calm.com`, `https://www.duolingo.com`, `https://www.strava.com`, `https://www.thefabulous.co`
+- Consumer/social cohort: `https://partiful.com`, `https://bereal.com`, `https://locket.camera`, `https://retro.app`, `https://flighty.com`
+- Utility/fintech cohort: `https://cash.app`, `https://copilot.money`, `https://www.monarch.com`, `https://1password.com`, `https://www.alltrails.com`
+- Store-listing exemplars beyond the cohorts: `https://flo.health` (Flo's listing grounds the description-opening rule)
+- Onboarding/paywall teardowns: `https://growth.design/case-studies`
+- In-app writing standards (already carried by `conversion-copy.md`'s manifest): Apple HIG Writing, Material 3 content design
+
+## The Consumer Register
+
+Cross-cohort patterns every fifteen sites share. Each is a pass/fail review question.
+
+1. **Hero headline under 8 words; the subject is the user or the outcome.** "Calm your mind. Change your life." (Calm); "Find your next adventure" (AllTrails); "The way money should work" (Cash App). Never a category noun as subject ("Meditation Content Library").
+2. **Subhead is one sentence that operationalizes the promise in plain words**, often with a hard number: "Join over 100 million active people on Strava for free." Headline sells the feeling; subhead sells the mechanism without technical words.
+3. **Outcome before feature, everywhere above the fold.** No site leads with a mechanism. Mechanism explanation (encryption, algorithms, data sources) is deferred below the fold or into an FAQ — 1Password holds "Secret Key" until trust is already earned.
+4. **CTA = verb + what the user gets, with friction named away.** The deck-level contract already in `conversion-copy.md` §App Surface Recipes, confirmed on every landing hero studied: "Try for $0" (Headspace), "Create invite" (Partiful), "Try FREE for 14 days" (1Password). Never a bare system verb. The strongest CTAs name the object created, not the funnel step.
+5. **Social proof is either a specific large number or unpolished real voices — not both, and never vague.** "Over 2 million 5-star reviews" (Calm); Partiful ships App Store reviews with usernames, dates, and a typo intact, because the imperfection is the credibility signal. "Loved by users everywhere" is the failure mode.
+6. **Named features never stand alone.** Every proper noun (Beacon, Ebb, HabitatZero) gets a same-breath plain-language gloss. A feature name with no gloss is roadmap vocabulary leaking.
+7. **Section headers keep the hero's rhythm.** "Stress less." / "Sleep more." / "Live mindfully." (Calm). A page that switches to descriptive-spec register below the fold was written by two different mindsets, and the reader feels the seam.
+8. **Identity is signaled, never named.** Copy says "you", "your friends", "your guests" — it never describes its own audience by segment. Locket's "Reach Gen Alpha" line exists only on its partner-facing corner; consumer surfaces earn identification through vibe, not demographics.
+9. **One jab at the incumbent, thrown away.** "Evites are so last decade" (Partiful). Never a comparison table on a consumer page.
+10. **Claims are declarative, not hedged.** "Duolingo works." Hedge stacks ("designed to help support...") read as legal-review residue. Quantified claims come time-boxed with proof ("reduces stress in just 10 days", Headspace) and live in the claims ledger, or they don't ship.
+11. **Second person, contractions, spoken cadence.** "From getting paid to growing what you've got" (Cash App). Passive voice for anything the product does is a spec tell.
+12. **Sentence fragments are allowed on purpose.** "Your friends, week to week." (Retro). Complete subject-verb-object-benefit sentences everywhere is spec voice; shipped consumer copy trusts the reader.
+13. **Less copy is a valid strategy.** BeReal's hero is a headline and a two-word button. When the product photographs well, restraint outperforms explanation — the copy deck should say where words are deliberately absent.
+
+## Cohort Notes
+
+- **Wellness/habit**: imperative micro-headlines as both hero and section titles; friction-reduced trial CTAs; awards and science-origin stories as credibility ("began at Duke University's Center for Advanced Hindsight", Fabulous).
+- **Consumer/social**: near-zero hero copy; emoji as structural punctuation in headers, not decoration; persuasion displaced off the landing page entirely (Retro's /ethos manifesto); testimonials left raw.
+- **Utility/fintech (trust-heavy)**: the two-tier vocabulary strategy. Plain outcome words above the fold ("Protect the accounts that power your life", 1Password); technical precision (FDIC, encryption, institution counts) deep in the page or in the FAQ, which acts as the jargon-containment zone. Reassurance is phrased as an absence — "No ads" (Monarch), "without all the fees" (Cash App) — or as a felt state ("Peace of mind for your entire family"), not as a certification list. Small parenthetical humor offsets category anxiety ("That streaming service you forgot about? We didn't", Copilot).
+
+## Store Listing Rules
+
+From the live App Store listings of Headspace, Duolingo, Flo, Strava, and Cash App:
+
+1. **Subtitle is a second keyword field, not a tagline.** A 3-6 word noun phrase naming the outcome domain or literal features ("Track & share with friends", Strava; "Money. Debit Card. Bitcoin.", Cash App). No puns, no abstract brand language.
+2. **Description sentence one = category + differentiator; sentence two = who it's for.** "Flo is a science-backed period tracker... used by over 460 million women worldwide." Never open with mission, history, or "Welcome to".
+3. **Feature bullets: `[imperative verb + 2-4 words] – [one-sentence payoff]`.** "Move safer – share your real-time location with loved ones while outdoors." (Strava).
+4. **Section headers name the job, not the module.** "SIMPLIFIED BANKING SERVICES" (Cash App), never "Banking Module". If a header could survive unchanged inside the tech spec, it is wrong for the listing.
+5. **Close claims with a quantified, time-boxed proof point.** "Just 2 weeks of Headspace reduces anxiety." Unverified superlatives appear nowhere on top listings; specific numbers do. Every such claim needs a claims-ledger row (`conversion-copy.md`).
+6. **Screenshot captions: verb + benefit, one message per frame, legible at thumbnail size.** The house length rule is `conversion-copy.md` §Surface Recipes' 3-5 words (ASO sources tolerate up to 7; hold the tighter bar). Cut "powerful", "seamless", "all-in-one" — unearned intensifiers. A caption that only lands zoomed-in is not ready.
+
+## Onboarding And Paywall Rules
+
+From the growth.design teardowns (Headspace onboarding, Strava premium preview, Blinkist trial paywall) and the Irrational Labs Headspace experiment:
+
+1. **A personalization question's answer must visibly change a later screen.** Headspace's documented failure: collect a goal, then show a paywall with zero connection to it. Merely asking lifts perceived fit (31%→63% course starts in the Irrational Labs test even with an identical recommendation) — but a downstream screen that contradicts the stated goal breaks trust immediately.
+2. **Onboarding questions read as a person asking, not a database field.** "When do you like to walk?" not "Select goal". If the question maps 1:1 onto a backend enum and sounds like it, it's an intake form.
+3. **Paywall copy names the specific outcome or the specific fear — never the access flag.** "Talk to a coach anytime" beats "unlimited sessions"; Blinkist's +23% variant dropped the feature list and answered the one fear ("you won't get charged without warning"). "Unlock premium features" is the canonical internal-voice paywall failure.
+4. **Never stack sale mechanics on a free moment.** Strava's critique: "Upgrade" + "25% Off" + "Subscription" made a genuinely free trial read as a sales pitch. Match the language register to the actual commitment.
+5. **Low-commitment CTA on the primary button.** "Continue" and "Try it free" outperform "Start Free Trial" and "Subscribe now" in documented redesigns; transaction verbs belong to fine print.
+6. **Preview the actual content instead of listing capabilities** where possible (Clear's paywall: 20%→30% conversion by showing week one's real program).
+
+## The Internal-Voice Tells (Review Layer)
+
+The judgment-layer companion to the machine-parsed ban list in `conversion-copy.md` §Banned In App Copy. These need a reader; run them as the review pass on every user-facing surface before handoff. A surface showing two or more tells goes back to the deck. Some tells restate Consumer Register rules or `no-slop-writing.md` principles on purpose — this list is the one flat checklist a reviewer runs, so it does not make the reviewer cross-reference three files mid-pass.
+
+1. The grammatical subject of a headline or section header is the system or category, not the user or outcome.
+2. The copy names its own audience by segment ("for Gen Z creators") on a consumer surface.
+3. A feature is named without a same-breath gloss, or explained by its mechanism ("our delay-prediction algorithm") instead of its effect ("First to know. First to go.", Flighty).
+4. Access language stands in for a named outcome: "unlock premium features", "get full access", "upgrade to premium". Test: delete the sentence — if no information about what the user gets is lost, it was internal-facing.
+5. A question is shaped like the backend field it fills ("Select experience level").
+6. An answer the user gave is never referenced again on any later screen.
+7. Every feature gets equal-length treatment — a completeness checklist, not a point of view. Real pages give wildly uneven space to what the team actually cares about.
+8. Testimonials are polished, unattributed, and interchangeable. Real ones keep usernames, dates, and imperfections.
+9. CTA verbs name the billing or system event ("Subscribe now", "Submit") instead of the user's next experience ("See my plan", "Continue").
+10. Proof points are internal metrics ("99.9% uptime", "50+ sport types") instead of user-relevant outcomes.
+11. Person and address drift within one surface — "the user", "customers", and "you" in the same paragraph.
+
+## Voice Benchmarks In The Copy Brief
+
+Every new app's brand guidance anchors its voice to real, current consumer benchmarks — that is what keeps an agent from improvising internal-flavored copy when no examples are in view. The gated section lives in `product/copy/COPY_BRIEF.md` because that is the artifact `check:app-copy` already holds; `strategy/BRAND.md` stays the home of the voice and owned-vocabulary tables, and its Voice table should agree with the benchmarks chosen here. `product/copy/COPY_BRIEF.md` carries the required **Voice benchmarks** section (enforced by `check:app-copy`):
+
+- Name 2-3 live consumer apps adjacent to this product's category whose current voice this product borrows from, each with 1-2 borrowed attributes grounded in words actually on their surfaces today (re-check them; do not quote this file from memory).
+- Name at least one **anti-benchmark**: a voice this product must not sound like, with the attribute being rejected.
+- Date the teardown. When the date is older than the launch's current phase work, re-check the benchmarks before locking new copy.
+
+Pick benchmarks from this file's cohorts when the category fits, or tear down closer competitors with the same method: verbatim hero/subhead/CTA, structure, voice attributes, tells.
+
+## Gates
+
+- `check:app-copy` — the machine-parsed floor: banned internal vocabulary and placeholder shapes in the deck's copy cells and the onboarding copy column, plus the brief's required sections (presence and non-hollowness — the brief is builder-facing planning prose, so its text is not banned-term-scanned). Rule lists live in `conversion-copy.md` §Banned In App Copy; extend the list there when a tell from this file earns hard-ban confidence.
+- The Internal-Voice Tells above — the judgment ceiling: run as a review pass; the gate catches shapes, the reviewer catches voice.
+- `check:landing-funnel` — truthful-claims patterns on the public funnel.
+- Claims ledger (`conversion-copy.md`) — every quantified or comparative claim, substantiated or removed.