b2c-app-builder 0.221.39

package/catalog/generated/firstparty/knowledge/process/learning-capture.md

@@ -0,0 +1,77 @@
+# Learning Capture
+
+This contract makes the knowledge matrix self-feeding. A solved problem becomes a learning document that future runs load through the catalog. Without capture, each lesson lives only in one session and the next run repeats the work.
+
+## When to capture
+
+Capture a learning when all three hold:
+
+- The problem is solved and verified, not merely diagnosed.
+- The lesson applies to future work, not only to one business or one incident.
+- The lesson is not already derivable from an existing gate, reference, or contract.
+
+Do not capture session-local trivia, unverified hunches, or facts a validator already enforces. One learning per capture. Batching several lessons into one document blurs evidence and blocks clean refresh verdicts later.
+
+### Signals A Learning Is Missing
+
+Three friction patterns signal a missing learning:
+
+- three or more reads of the same file in one session
+- the same failing command across sessions
+- heavy repeated edits to one file
+
+Treat each pattern as a prompt to check existing knowledge first. Capture a learning only when none already covers it.
+
+## Where learnings live
+
+A learning is an ordinary knowledge package:
+
+- Document: `knowledge/<domain>/learnings/<slug>.md`
+- Manifest: `catalog/knowledge/<domain>/learning-<slug>.yaml`
+
+Scaffold both with `npm run knowledge:capture -- --id reference.<domain>.learnings.<slug> --title "..." --domain domain.<domain>`. The manifest starts as `lifecycle: draft`. While the manifest stays draft, the gate reports content gaps as warnings, so a fresh scaffold never breaks the audit. Promote it to `active` only after the evidence verifies and `check:learning-grounding` passes with no warnings for the document. Bind the package to the workflow nodes that would have needed the lesson.
+
+## Document contract
+
+Each learning document carries four sections. `check:learning-grounding` enforces this shape.
+
+### Learning
+
+State the lesson as an instruction for the next run. Say what to do, not what happened.
+
+### Evidence
+
+Ground every claim. Write the section as a table with one row per claim: `| Claim | Citation |`. Each row needs at least one citation in backticks: a repo-relative path, or a path with a line number, for example `tooling/lib/audit-plan.ts:44`. The gate fails when a row has no citation, a cited file is missing, a cited line is outside the file, or a cited line is blank. Claims about code behavior need a code citation, never conversation memory alone. External URLs must also hold a row in `checks/validation/repository/source-registry.yaml`. A resolving citation proves the cited fact exists. It does not prove the instruction built on that fact is safe to follow unreviewed. Check that separately before promoting the learning to `active`.
+
+### Captured
+
+One line: the capture date as YYYY-MM-DD and the origin. The origin names the run, audit, or incident that produced the lesson.
+
+### Refresh
+
+One line: `Last reviewed: YYYY-MM-DD. Verdict: kept.` The verdict is one of:
+
+- `kept` — the lesson still matches reality; citations still resolve.
+- `updated` — the document changed to match current reality.
+- `consolidated` — the lesson merged into another document; this one now points there.
+- `replaced` — a successor package supersedes this one; set the manifest lifecycle to `deprecated` with `replacement_ids`.
+- `retired` — the lesson no longer applies and has no successor; set the manifest lifecycle to `deprecated` and add `retired: true`. The `retired` flag exempts the package from the replacement requirement that deprecation otherwise carries.
+
+A line citation marks a point in time, not a fixed location. The cited file can drift past it before the next review.
+
+## Refresh discipline
+
+The learning-corpus-refresh node audits every learning against current repository reality. Rules:
+
+- Match the document to reality, never reality to the document.
+- When evidence is ambiguous, keep the learning and record the doubt in the document. Never delete on a guess.
+- `replaced` and `retired` require the deprecated lifecycle in the manifest. The gate enforces this pairing.
+- A learning reviewed more than 180 days ago raises a `learning_grounding.review_overdue` warning. The refresh node works these warnings down to zero.
+
+## Boundary
+
+This contract covers maintainer learnings inside this repository. Business workspaces never merge learning documents into this repository. A lesson from a live business enters here only as a rewritten, repo-grounded learning with its own evidence.
+
+### Auto-Memory boundary
+
+Claude Code's native Auto-Memory writes to a private `MEMORY.md` file. That file stays local to one user; no other session or agent reads it. A repo-wide lesson trapped there never reaches the next run. Treat a durable Auto-Memory entry about this repo as a capture trigger. Run `npm run knowledge:capture` and promote the lesson here.

package/catalog/generated/firstparty/knowledge/process/learnings/audit-runs-from-repo-root.md

@@ -0,0 +1,22 @@
+# Run The Maintainer Audit From The Repository Root
+
+## Learning
+
+Run `npm run audit` from the repository root checkout, never from an installed copy of the package. The audit picks the repo layout only when the package root carries `.git` or `.github` (ADR-0002 made the repository root the package root); the skill-layout audit silently drops every repo-only step, so a green result from an installed copy proves less than it appears to. Before claiming a merge-ready audit, confirm the run came from the root layout. Never pipe the audit through `tail` or another filter — the pipe reports the filter's exit code, not the audit's.
+
+## Evidence
+
+| Claim                                             | Citation                        |
+| ------------------------------------------------- | ------------------------------- |
+| Audit steps can be marked repo-only               | `tooling/lib/audit-plan.ts:53`  |
+| The skill layout filters repo-only steps out      | `tooling/lib/audit-plan.ts:339` |
+| check:package-parity only runs in the repo layout | `tooling/lib/audit-plan.ts:228` |
+| check:validator-docs only runs in the repo layout | `tooling/lib/audit-plan.ts:257` |
+
+## Captured
+
+Captured: 2026-08-18 — recurring maintainer failure recorded during the compound-engineering study; the skill-layout gap and the pipe-masked exit code each produced a false green audit in earlier sessions.
+
+## Refresh
+
+Last reviewed: 2026-08-18. Verdict: kept.

package/catalog/generated/firstparty/knowledge/process/provider-contracts.md

@@ -0,0 +1,49 @@
+# Provider Contracts
+
+Use this when a freshness PR changes a contracted source. Use this when a client runtime pin drifts.
+
+B2C App Builder is the platform. A skill install is a client of that platform.
+Claude, Cursor, Codex, and Agents each pin one B2C App Builder version.
+A client that trails the source pin is stale. Do not run launch work on it.
+
+## Contracts
+
+The catalog holds one YAML contract per vendor surface under `catalog/providers/`.
+Three contracts are required:
+
+- `revenuecat` — billing. Offerings, entitlements, and Experiments are required features.
+- `agent-runtime-claude` — agent runtime. Skill install and CLI support are required.
+- `apple-asc` — store CLI. It reuses the Slice 0 App Review capability receipt.
+
+Apple `asc` features must list every App Review capability id. The contract must set `capability_receipt: app_review_asc`.
+
+A contract names source-registry ids, not raw URLs. Register a new URL in `source-registry.yaml` first.
+
+## Capability delta
+
+`catalog/providers/capability-delta.yaml` is the classification ledger.
+Every contracted source must have a row. `to_hash` must match the snapshot hash.
+Use `unsnapped` when the source has no snapshot row yet.
+
+Classify each hash change:
+
+- `ignore` — page chrome or irrelevant movement
+- `docs` — reference prose must change
+- `commands` — CLI examples must change
+- `template` — launch templates must change
+- `validator` — a deterministic check must change
+- `eval` — LaunchBench coverage must change
+- `breaking` — old guidance may now harm a launch
+
+Migration is `none`, `pending`, or `complete`.
+A `breaking` row blocks revenue and provider-proof until migration is `complete`.
+`check:capability-delta` fails closed on an unclassified contracted source.
+
+## Multi-runtime pin
+
+After a version bump, sync every client.
+Run `npm run runtime:sync -- --all-clients`.
+That command writes each present unique client root.
+It fails if a present pin still trails the source.
+A missing install is a skip.
+Run `npm run check:skill-version -- --all-runtimes`.

package/catalog/generated/firstparty/knowledge/process/provider-proof.md

@@ -0,0 +1,37 @@
+# Provider Proof
+
+Use this reference before marking analytics, revenue, email, store, security, or engineering lanes done.
+
+`operations/PROVIDER_PROOF.md` is the live-evidence ledger. It separates planned provider setup from proof that the provider actually worked.
+
+## Required Providers
+
+For most B2C mobile launches, the proof ledger should cover:
+
+- PostHog event and person-property evidence.
+- RevenueCat offering, package, sandbox purchase, restore, and entitlement evidence.
+- Resend domain/DNS and test-send evidence when email is in scope.
+- App Store Connect app record, metadata, screenshot, TestFlight, or review-state evidence when store ops are in scope.
+- Sentry event, release, or alert evidence when production readiness or security is in scope.
+- MobAI or equivalent mobile E2E proof for target-user flows.
+- Doppler runtime injection proof when secrets are in scope.
+
+## Rules
+
+- Planned setup is not proof.
+- Unit tests are not provider proof unless paired with provider-side evidence.
+- Do not store secrets, raw tokens, private account screenshots, `.p8`, `.p12`, `.mobileprovision`, or credential screenshots.
+- If access is founder-only, record the gate and keep the lane partial or blocked.
+- Run `check:provider-proof` before any provider-backed readiness claim.
+
+## Minimum Ledger Shape
+
+Use `business/operations/PROVIDER_PROOF.md` as the starter. Each row needs:
+
+- provider name
+- current status
+- proof command or inspection route
+- evidence path
+- founder-only gate, if any
+
+Once a provider-backed lane is marked done, `check:provider-proof` grounds its ledger row in reality: the row must exist, its current status must read as captured evidence (not still-planned "needs ..." work), and at least one file named anywhere in the row must exist on disk. Writing the right words into the ledger without running the capture fails the gate. Backtick-quote evidence paths that contain spaces; literal pipes in the proof-command cell are fine (the whole row is scanned, not a column position).

package/catalog/generated/firstparty/knowledge/process/repository-profiles.md

@@ -0,0 +1,60 @@
+# Repository Profiles
+
+Use this when you select the kind of repository a workspace is. The profile compiles the artifact contract and the validator contract. It does not let a founder turn off a safety gate.
+
+## Vocabulary
+
+Four profile ids exist:
+
+- `app-source` — consumer app source
+- `founder-operating` — private founder operating workspace
+- `public-package` — public engine or package
+- `marketing-site` — public marketing site
+
+Without an accepted profile, the catalog applies its default validator routing. A profile is selected only when its accepted identity and revision are recorded.
+
+Launch scope (`essentials` / `full`) is a different field. Do not mix the two.
+
+## Record
+
+Record founder acceptance in reducer-owned state:
+
+```json
+{
+  "project": {
+    "repositoryProfile": {
+      "id": "founder-operating",
+      "revision": "rev-repository-profiles-2026-08-24",
+      "acceptedAt": "2026-08-24T00:00:00Z"
+    }
+  }
+}
+```
+
+The accepted value belongs in `state/business-state.json`. Incomplete profile
+identity, revision, or acceptance time fails validation. A profile cannot
+silently suppress an applicable safety or trust gate.
+
+## Mandatory gates
+
+These gates stay mandatory when the underlying capability is present:
+
+- privacy and account deletion (`check:privacy`)
+- secrets (`check:secrets`)
+- authorization (`check:security`)
+- billing (`check:revenue`)
+- provider proof (`check:provider-proof`)
+- paid generative-AI controls (`check:ai-provider-controls`)
+- release truth (`check:source-checkpoint`, and `check:apple-release-readiness` when signing is in scope)
+
+A profile cannot suppress these gates.
+
+## Inventory
+
+`check:repository-profile --write` writes `state/generated/requirement-inventory.json` and `state/generated/requirement-inventory.md`. Those files are generated projections. Do not edit them as source. Each row names the profile, pack, workflow, or capability that activated the requirement.
+
+## Paid generative-AI pack
+
+When a capability can create provider spend, composition must pin `capability.paid-generative-ai`. The pack carries the control record and the incident runbook together. `check:pack-composition` fails when a spend pack omits it.
+
+`check:repository-profile` uses the same paid-generation parser as `check:ai-provider-controls`. It reads the `Paid generation:` line from the control record or the safety file. A named not-applicable reason does not skip the pack when product files show paid provider use.

package/catalog/generated/firstparty/knowledge/process/tool-recipes/device-capture-and-proof.md

@@ -0,0 +1,100 @@
+# Device Capture And App Proof
+
+Use current tools and live data whenever possible. Treat this file as workflow, not fixed facts.
+
+Part of the [Tool Recipes](../tool-recipes.md) index. Before using any paid or account-gated tool named below, honor the **Paid Tool Decision Protocol** and **Founder-Only Gates** in that index.
+
+---
+
+## In-App Simulator, MobAI Toolbelt, Recorders, Native iOS, And CLI Simulator Capture
+
+Purpose: capture truthful app UI for App Store and Google Play screenshots, record polished demo videos, create app-preview/social proof, and compose final assets with the design system.
+
+Load `xcodebuildmcp-testing.md` first for any "run the app / check this screen / walk this flow / reproduce this bug" request: its Route Ladder starts at the in-app iOS Simulator (rung 0 — Claude Code Desktop's simulator pane or Codex with the `build-ios-apps` plugin), which needs no install and no account, and it also covers the CLI `computer-use` route, XcodeBuildMCP, SnapshotPreviews preview exports, serve-sim streaming, and Apple simulator/device command examples. Always load `mobai-toolbelt.md` before MobAI device automation, recorder skills, Android coverage, repeatable `.mob` suites, polished demo/app-preview recording, or MobAI-adjacent build/test tooling. Refresh the MobAI org and relevant repo docs before installing or naming commands.
+
+Use when:
+
+- a local iOS or Android build exists
+- store screenshots need real app state
+- review/rejection work depends on what a reviewer sees
+- screenshot copy or layout must be verified on actual device sizes
+- launch, store, Fastlane, UGC, support, or investor materials need a polished app-flow video
+
+Preferred routing:
+
+- For a single screen check, flow walk, or bug repro on a local Mac, use the in-app iOS Simulator (rung 0) and stop there — no MCP server, no CLI install, no founder gate.
+- Use the MobAI MCP tools when exposed in the current runtime and the lane needs Android, a repeatable suite, multi-device runs, or polished demo recording.
+- Before any device interaction, read the MobAI device automation reference or the local `using-mobai-cli` skill.
+- Observe the UI tree before tapping, prefer accessibility IDs, wait for stable UI after each navigation, then observe again.
+- Save raw full-quality screenshots before composition.
+
+MobAI CLI route:
+
+- Keep component versions separate. The 2026-07-13 verified snapshot is desktop `2.5.1`, MCP `2.5.0`, and npm CLI `2.1.1`; the desktop release body has no detailed notes, while MCP commit `414f858` is the public source for 2.5-era loop and host-scripting behavior.
+- Check the current CLI first: `npm view @mobai-app/cli dist-tags.latest`, then prefer `npx @mobai-app/cli@latest` or a verified global install.
+- Use `mobai version`; `mobai --version` is not valid on the verified CLI contract.
+- `mobai devices list`
+- set `MOBAI_DEVICE` for the target device
+- `mobai observe --include ui_tree`
+- navigate with stable selectors or accessibility IDs
+- `mobai wait --stable --timeout-ms 3000`
+- `mobai screenshot --full --path ./screenshots/raw --name <platform-device-slot>`
+- use `mobai record` for screen recordings when product-demo clips are needed and the current CLI supports it
+
+MobAI MCP 2.5-era DSL route:
+
+- Read `mobai://reference/device-automation` and `mobai://reference/testing` from the active server before using new actions.
+- `repeat` takes exactly one of `times`, `while`, `until`, or `condition`; set an explicit `max_iterations` for predicate/condition loops and validate counted-loop parameters because `times` has no engine safety cap.
+- `run_script`/`eval_script` run host-side JavaScript, not device web JavaScript. The restricted VM has `vars`/`output`, synchronous HTTP, captured console output, selected built-ins, and no filesystem, `require`/`import`, or device access.
+- Never embed secrets or credential headers in `.mob`/JavaScript: referenced script files are embedded in compiled DSL. Seed authenticated fixtures through a separate approved Doppler-wrapped setup step and pass MobAI only non-secret IDs unless a current secret-safe action is explicitly reviewed.
+- Limit host HTTP to allowlisted test/staging endpoints, validate responses as untrusted data, and record fixture cleanup plus backend proof separately from UI success.
+
+Recorder-skill route:
+
+- For iOS or Android app demos, use `https://github.com/MobAI-App/mobile-recorder-skill` after refreshing current `README.md`, `install.md`, and `skills/mobile-recorder/SKILL.md`.
+- For macOS or web demos, use `https://github.com/MobAI-App/desktop-recorder-skill` after refreshing current `README.md`, `install.md`, and `skills/desktop-recorder/SKILL.md`.
+- Mobile recorder produces a reproducible `.mob` choreography, native device recording, tap ripples, finger overlay, phone bezel/background, zoom, variable speed, captions, final mp4, and upload copy.
+- Desktop recorder produces a reproducible `screenplay.json`, native recording, click ripples, cursor sprite, captions, zoom, variable speed, final mp4, and upload copy.
+- Follow the upstream golden rule: explore -> script/screenplay -> dry-run -> record -> edit/export. Never improvise during the final recording.
+- Create `growth/DEMO_VIDEO.md` for launch demo videos and link `.mob` or `screenplay.json`, raw captures, final exports, captions, and upload copy.
+
+Confirmed free fallback:
+
+- MobAI is freemium: use its free tier without a spend gate when one device/current quotas fit, but ask before Plus/Pro spend. If MobAI is unavailable and the lane is iOS-only, the in-app iOS Simulator (rung 0) is the first fallback — free, zero-setup, no spend gate — and only the lost Android/suite/CI/physical-device coverage needs recording per [`paid-tool-routing.md`](../../operations/paid-tool-routing.md). Escalate to XcodeBuildMCP when the lane needs scripted builds, CI, or physical hardware, and record the Apple-only limitation either way.
+- After confirmation, load `xcodebuildmcp-testing.md` for iOS/iPadOS/macOS/tvOS/watchOS/visionOS build, run, UI automation, screenshot, video, and log workflows.
+- Refresh official XcodeBuildMCP docs and local `xcodebuildmcp --help`/`xcodebuildmcp tools` output before setup commands, CLI syntax, MCP tool names, screenshot captures, or readiness proof.
+- Use XcodeBuildMCP for Apple simulator/device captures and record the missing MobAI coverage. Use Android emulator/ADB or mark Android proof blocked for Android-only flows.
+
+In-app native iOS route (rung 0, both runtimes):
+
+- In Claude Code Desktop on a Mac (local sessions only — never cloud or SSH), state the goal plainly ("run the app in the iOS Simulator and tap through the signup flow"); the simulator pane opens itself when the app runs. Consent is per device, and screenshots of the device leave the machine — use fixture/sandbox accounts only, never a real account.
+- In Codex with the `build-ios-apps` plugin, call `session_show_defaults` before the first build/run/test, use `build_run_sim` when defaults are set, read the accessibility hierarchy before interacting, and prefer stable labels over raw coordinates.
+- Record the runtime and app version, the plan/policy gate cleared, that the session was local, the simulated device and OS, the fixture account, output paths, and the simulator-only/no-Android/no-distribution limitation in `engineering/PRODUCTION_READINESS.md`.
+
+CLI proof tools:
+
+- SnapshotPreviews (`https://github.com/getsentry/SnapshotPreviews`) supports XCTest preview checks. Link `SnapshottingTests`: `SnapshotTest` can export snapshots, while `PreviewLayoutTest` checks layout without PNG export. Use `TEST_RUNNER_SNAPSHOTS_EXPORT_DIR` for snapshot export and label the results preview-only, not app-session evidence.
+- serve-sim (`https://github.com/EvanBacon/serve-sim`) streams and controls a booted iOS Simulator in a browser. Resolve the explicitly selected executable/version before starting a local preview at `http://localhost:3200` or the chosen port. Record a specific booted simulator/UDID, actions and logs. No implicit `npx` download, webcam capture or remote exposure is authorized; streaming does not replace provider proof or App Store signing readiness.
+
+These source reviews do not certify installed tools or authorize setup. Inspect
+actual macOS, architecture, Xcode and dependency requirements before use. Keep
+preview galleries internal; no camera injection, webcam access, host-permission
+change or tunnel is implicit. Source selection never replaces runtime evidence.
+
+Record in `SCREENSHOTS.md`:
+
+- platform, device model/class, OS, app build, locale, theme, account fixture, and data fixture
+- screen path and selector path used to reach it
+- raw capture path
+- demo choreography path: `.mob` or `screenplay.json` when recording video
+- design-system frame/composition path
+- final upload path and dimensions
+- Apple display well or Google device class satisfied
+- visual QA notes and upload status
+
+Rules:
+
+- Do not use generated art as a replacement for real app UI.
+- Use Higgsfield for supporting backgrounds, mascots, icons, motion, or frame art only after the app screen is truthful.
+- Keep raw captures separate from final upload assets.
+- If capture is blocked by missing device/app access, leave the exact blocker. Continue with a clearly labeled design-system mock only after the founder approves the fallback.

package/catalog/generated/firstparty/knowledge/process/tool-recipes/engineering-and-agent-orchestration.md

@@ -0,0 +1,89 @@
+# Engineering And Agent Orchestration
+
+Use current tools and live data whenever possible. Treat this file as workflow, not fixed facts.
+
+Part of the [Tool Recipes](../tool-recipes.md) index. Before using any paid or account-gated tool named below, honor the **Paid Tool Decision Protocol** and **Founder-Only Gates** in that index.
+
+---
+
+## Compound Engineering And Agent Orchestration
+
+Purpose: turn the launch package into production-ready software without losing product, design, analytics, entitlement, or testing truth.
+
+Use `engineering-orchestration.md` before:
+
+- actual app, backend, or web-funnel implementation
+- builder/Rork/Codex/Claude handoff prompts that will create app code
+- `operations/ORCHESTRATION.md`, `AGENTS.md`, `CLAUDE.md`, `state/LAUNCH_TRACE.md`, `engineering/TECH_SPEC.md`, `engineering/ENGINEERING_PLAN.md`, or `engineering/PRODUCTION_READINESS.md`
+- deciding whether to use product brainstorm, planning, parallel agents, or worktrees
+- declaring beta, store-submission, or production readiness
+
+Load `compound-engineering-routing.md` before core engineering. It is the enforceable CE route and state contract; this section is the quick recipe.
+
+Use `parallel-agent-orchestration.md` before any subagent dispatch or multi-lane launch run. The default runtime habit should be: keep the critical path local, identify safe sidecar agents, serialize shared resources, and write the preflight before claiming speed from parallelism.
+
+Delegate:
+
+- `ce-update` in Claude Code, or a recorded local inventory/latest-release fallback, before a substantial engineering run.
+- `ce-brainstorm` after AppKittie/XPOZ/Firecrawl research when product shape, onboarding, paywall, core loop, activation, or scope still has multiple defensible directions.
+- `ce-plan` when launch docs are stable enough to become an implementation plan.
+- `ce-work` for bounded execution from a concrete plan.
+- `ce-worktree` for isolated parallel engineering lanes, PR review, or keeping a dirty main checkout safe.
+- `ce-code-review` before treating non-trivial implementation as complete.
+- `ce-test-browser` for web funnels, checkout, policy pages, support flows, dashboards, and responsive browser checks.
+- `ce-test-xcode` for iOS build/test verification where applicable.
+- `ce-proof` or `ce-demo-reel` when the founder/reviewer needs a visual proof artifact.
+- MobAI MCP or the local `using-mobai-cli` skill for serialized mobile-device E2E and store screenshot capture.
+- Use the Monitor tool to stream a long App Store Connect or Cloudflare deploy wait instead of polling manually. Monitor is unavailable on Bedrock, Vertex AI, and Foundry; poll every few minutes there instead.
+- If Compound Engineering is unavailable, record the unavailable route and equivalent fallback in `operations/ORCHESTRATION.md`, `state/business-state.json`, and `engineering/ENGINEERING_PLAN.md`; do not let agents skip directly from docs to readiness.
+
+Parallel rules:
+
+- Parallelize research, static audits, independent docs, isolated frontend/backend units, fixtures, and test-writing only after mapping each unit to create/modify/test files.
+- If two lanes touch the same file, migration state, simulator/device, git staging, release action, or final readiness decision, run them serially.
+- The orchestrator owns staging, commits, merges, project-wide suites, MobAI device ownership, production-readiness judgment, and final ship/hold decisions.
+- Instruct parallel subagents not to run project-wide suites, stage files, commit, merge, publish, submit, schedule content, or mutate shared credentials.
+- After parallel work returns, compare modified files, resolve collisions, run focused tests, then run integration/E2E checks.
+
+Record in `operations/ORCHESTRATION.md` and `state/business-state.json`:
+
+- CE availability, latest-version check, skills considered, selected route, and fallback reason if unavailable
+- selected strategy: `not_evaluated`, `inline`, `serial_subagents`, `parallel_subagents`, `worktrees`, `hybrid`, `blocked`, or `not_needed`
+- critical path kept local by the orchestrator
+- candidate units, roles, objectives, modes, files, shared resources, and safety decisions
+- spawned agents, forbidden actions, output paths, actual file collision check, and integration status
+- focused validators and full suites run after integration
+
+Record in `engineering/ENGINEERING_PLAN.md`:
+
+- product brainstorm source or skip rationale
+- requirements trace to `state/LAUNCH_TRACE.md`, `engineering/TECH_SPEC.md`, `PRODUCT.md`, `DESIGN.md`, `analytics/ANALYTICS.md`, `product/ONBOARDING.md`, `revenue/REVENUE_OPS.md`, `growth/EMAIL_OPS.md`, `trust/PRIVACY.md`, `store/APPLE_SIGNING.md`, and `store/STORE_CONSOLE.md`
+- implementation units, repo-relative paths, serial dependencies, worktree needs, safe parallel lanes, serialized resources, and subagent output contracts
+- frontend, backend, database, analytics, revenue, email, privacy, store-console, app-integrity, permission, and state-machine impacts
+- test scenarios, MobAI E2E scenarios, backend/provider verification, release gates, and blockers
+
+Record in `engineering/PRODUCTION_READINESS.md`:
+
+- build/typecheck/lint/test commands and outcomes for every touched repo
+- browser/mobile E2E evidence, including MobAI steps and screenshots where relevant
+- backend/database/provider proof for frontend actions, RevenueCat/Stripe entitlements, PostHog events, Resend sends/webhooks, and account deletion/support paths when in scope
+- release-build/staging-build proof that mocks are disabled and secrets are not bundled
+- remaining blockers and founder-only gates
+
+Rules:
+
+- `AGENTS.md` is mandatory for real app builds and builder handoffs; start from `surfaces/workspace-template/repo-agent-entrypoints/AGENTS.md` so future agents keep using `b2c` without another founder prompt. `CLAUDE.md` should start from `surfaces/workspace-template/repo-agent-entrypoints/CLAUDE.md` and point back to `AGENTS.md` instead of duplicating product truth. Keep these files as maps to source docs, active plans, validators, and failure cards.
+- Unit tests are not enough for production readiness.
+- Screenshot proof from any device route — in-app simulator, MobAI, XcodeBuildMCP — is not backend proof; pair device actions with database/provider/dashboard evidence.
+- Do not use generated builders from a prompt alone. Include repo-local instructions and artifacts so later agents can continue without reconstructing the launch logic.
+
+## Choosing MCP, CLI, Or Skill For A New Tool
+
+Ask four questions before adding a third-party tool to a workflow lane:
+
+- who is the end user
+- which model drives the call
+- does the session need call-level observability
+- does the tool's schema change often
+
+Route to a CLI recipe when a frontier model drives the tool locally against a stable, deterministic interface. Route to an MCP server when the tool needs OAuth or has no CLI equivalent. Route to an installed agent skill pack when the tool is craft or reference guidance, not a live API call.

package/catalog/generated/firstparty/knowledge/process/tool-recipes/funnel-domain-and-privacy.md

@@ -0,0 +1,142 @@
+# Funnel, Domain, And Privacy Verification
+
+Use current tools and live data whenever possible. Treat this file as workflow, not fixed facts.
+
+Part of the [Tool Recipes](../tool-recipes.md) index. Before using any paid or account-gated tool named below, honor the **Paid Tool Decision Protocol** and **Founder-Only Gates** in that index.
+
+---
+
+## Privacy And Terms Research
+
+Use `privacy-terms.md` before drafting public policy pages or store disclosures. Always refresh official sources because privacy, subscription, and platform requirements change.
+
+Minimum research set:
+
+- Apple App Privacy Details and App Store Connect EULA guidance for iOS launches
+- Google Play User Data and Data safety requirements for Android launches
+- FTC privacy/security guidance, and COPPA guidance if children or teens may be involved
+- California CCPA/CPRA and CalOPPA guidance when serving U.S. consumers
+- EU GDPR transparency guidance when offering to EU/EEA users
+- current subscription/negative-option rules when free trials, renewals, or recurring billing exist
+- vendor docs for analytics, ads, AI, payments, crash reporting, backend, email, and push providers
+
+Evidence to gather:
+
+- SDK/package list
+- app permissions and platform privacy manifests
+- backend schema/tables/buckets
+- analytics event catalog
+- payment/subscription provider behavior
+- AI provider data-use settings
+- support/email tooling
+- ad pixels and attribution tooling
+- data retention/deletion implementation
+
+Do not use generic legal-policy generators as source truth. They can help with wording only after the actual data inventory and official requirements are known.
+
+## Cloudflare Email Routing
+
+Use when a launch domain needs working inbound email aliases for support, privacy, security, press, or founder contact.
+
+Important:
+
+- Dashboard routing rules can appear active while the zone-level Email Routing status is still disabled or DNS records are not configured.
+- Cloudflare Email Routing custom addresses are inbound forwarding addresses. Do not assume they can send outbound mail as the domain.
+- Cloudflare requires destination address verification before a route can receive mail.
+- A custom address should have one current destination rule unless a Worker handles multi-destination routing.
+
+Setup:
+
+- create or verify destination address
+- create rules for `support@domain`, `privacy@domain`, and any `hello@domain`, `security@domain`, or founder alias
+- click the Email Routing connect/enable flow and add the required `MX` and `TXT` records
+- keep catch-all disabled/drop unless the founder explicitly wants a monitored catch-all
+- send test emails from an external account and verify receipt
+- record whether outbound send-as is covered by Gmail/Workspace, Cloudflare Email Service, Resend/Postmark/Mailgun, or another provider
+
+Record:
+
+- alias, destination, purpose, status, last test timestamp, and where the address is published
+- DNS status and dashboard status
+- outbound sending gap, if any
+
+Founder gates:
+
+- ask before deleting existing `MX` records or migrating mail providers
+- ask before publishing a founder personal alias
+- ask before enabling catch-all forwarding
+
+## Landing Funnel Verification
+
+Local:
+
+- install dependencies
+- run typecheck/lint/build
+- run local dev server
+- test desktop and mobile responsive views
+- test waitlist form success and error states
+- test referral URL preservation
+- verify no secrets appear in public bundles
+
+Deploy:
+
+- deploy preview
+- deploy production
+- bind custom domain
+- confirm cert/DNS status
+- HTTP check preview and canonical domain
+- verify security headers on `GET`
+- verify `robots.txt`, `sitemap.xml`, `llms.txt`, schema, OG image
+- verify the OG image shows current app stats, not stale hardcoded numbers
+- generate the OG image at build time from live content counts when the stack supports it
+- check for a stray static file at the OG-image path in the public folder
+- a static file there can silently shadow a dynamic OG-image route
+- submit a test signup against production or staging
+- verify analytics events arrive
+- remove or mark test data before public launch
+
+Useful checks:
+
+```bash
+curl -I https://example.com
+curl -s https://example.com/robots.txt
+curl -s https://example.com/llms.txt
+curl -s https://example.com/sitemap.xml
+```
+
+## Cloudflare/Supabase Waitlist Pattern
+
+Use when the launch needs a simple, measurable waitlist and referral loop.
+
+Pattern:
+
+- browser posts email/referral/source to a server endpoint
+- server rate-limits and validates input
+- server calls a Supabase RPC or equivalent backend function
+- database function creates/refetches waitlist row, generates referral code, increments referrer if valid
+- frontend reveals share link and position
+- leaderboard masks emails and never exposes PII
+
+Security posture:
+
+- RLS on
+- direct table access denied to anonymous clients
+- anonymous callers use narrow RPC functions only
+- SECURITY DEFINER functions lock `search_path`
+- extension functions schema-qualified
+- service keys stay server-side only
+- rate limits exist before public traffic
+
+## Audit Prompt Pattern
+
+For any public funnel, generate a reusable `AUDIT_PROMPT.md` with:
+
+- what the site is supposed to do
+- current live URLs
+- stack
+- brand rules
+- specific audit dimensions and output format
+- "do not recommend" constraints
+- validation URLs/tools
+
+The prompt is part of launch quality. It lets the founder send the site to another model or engineer for a focused review without re-explaining the business.