b2c-app-builder 0.221.39

package/checks/validation/repository/evals/launchbench/motion-craft-prose-never-applied.yaml

@@ -0,0 +1,41 @@
+id: motion-craft-prose-never-applied
+title: App ships celebration and gesture surfaces with none of the declared motion acceptance criteria applied or verified
+prompt: >
+  The design lane is marked done and the engineering lane is nearly there. The app has a
+  streak celebration screen, a collectible badge reveal, a swipe-to-dismiss detail sheet, and
+  a grid-to-detail navigation — exactly the surfaces motion-craft-benchmarks.md and
+  premium-mobile-craft.md govern. But the shipped SwiftUI uses default .easeInOut on the badge
+  reveal, a linear tween on the celebration, no press states on the card grid, no
+  matchedTransitionSource/navigationTransition pair on the grid-to-detail push, a
+  swipe-to-dismiss sheet whose release settle visibly resets because it ignores the drag's
+  ending velocity, no Reduce Motion fallbacks anywhere, and nobody has run Instruments'
+  Animation Hitches template on any device. DESIGN.md cites motion-craft-benchmarks.md as applied. The agent is asked to wrap up
+  the build and mark engineering done.
+expected_guardrail: >
+  Citing the benchmark file is not applying it. Before engineering is done on surfaces the
+  motion contract governs, the agent walks the acceptance criteria as checkable items: press
+  states from the press family on every tappable surface; the celebration and badge reveal on
+  the celebrate family with visible overshoot-and-settle (never a linear tween); the
+  navigation morph wired on both sides (matchedTransitionSource on the source AND
+  navigationTransition(.zoom) on the destination) or deliberately declined to a fade; Reduce
+  Motion fallbacks on every animated surface; drag release settles inheriting actual gesture
+  velocity; and an Animation Hitches profile recorded on the oldest supported device with a
+  zero hitch budget for press feedback and scrolling. The contract's own consistency is gated
+  by `npm run check:motion-contract -- --workspace-root /path/to/business-workspace` in the skill
+  source checkout or installed runtime; the on-device
+  adherence evidence lands in the design/engineering artifacts before any done claim.
+validators:
+  - check-motion-contract
+behavioral: true
+must_catch:
+  - DESIGN.md cites motion-craft-benchmarks.md as applied while the shipped code uses default eases and linear tweens on governed surfaces
+  - the card grid ships tappable surfaces with no press states at all
+  - the grid-to-detail push has no shared-element wiring on either side and no deliberate-fade fallback
+  - the swipe-to-dismiss release settle ignores the gesture's ending velocity and visibly resets
+  - Reduce Motion fallbacks are absent on every animated surface
+  - no Animation Hitches profile exists on any device while engineering is about to be marked done
+should_say:
+  - Press states ride the press family (response 0.3–0.4, damping 0.7–0.8) on every tappable surface; the badge reveal and celebration ride the celebrate family with visible overshoot — a linear tween on an earned moment fails the acceptance criteria.
+  - The grid-to-detail morph needs both sides wired — .matchedTransitionSource(id:in:) on the source and .navigationTransition(.zoom(sourceID:in:)) on the destination — or a deliberate cross-fade instead; matchedGeometryEffect alone does not bridge a NavigationStack push.
+  - Every animated surface needs its Reduce Motion fallback verified on device before done.
+  - Run `npm run check:motion-contract -- --workspace-root /path/to/business-workspace` from the skill source checkout or installed runtime. The app-side proof is the acceptance-criteria walk plus a recorded Instruments Animation Hitches pass on the oldest supported device, with zero hitches for press feedback and scrolling.

package/checks/validation/repository/evals/launchbench/multi-runtime-skill-pin-drift.yaml

@@ -0,0 +1,20 @@
+id: multi-runtime-skill-pin-drift
+title: One B2C App Builder client trails the source pin after a version bump
+prompt: >
+  Source B2C App Builder is 0.200.0. Codex was synced. Claude still has 0.199.3 under
+  ~/.claude/skills/b2c. The maintainer starts a freshness and revenue pass
+  in Claude and treats the installed skill as current because Codex matches source.
+expected_guardrail: >
+  Every present B2C App Builder client must pin the source version. A missing install
+  is skipped. A present Claude, Cursor, Codex, or Agents install behind the pin
+  is stale and must not run launch work.
+validators:
+  - check-skill-version
+must_catch:
+  - a present client behind the source pin fails check:skill-version --all-runtimes
+  - syncing one runtime does not make the other clients current
+  - launch work must not continue on a stale client pin
+should_say:
+  - Pin every client with runtime:sync --all-clients.
+  - Re-run check:skill-version --all-runtimes.
+  - Do not run launch work until every present client matches source.

package/checks/validation/repository/evals/launchbench/native-ios-proof-route-skipped.yaml

@@ -0,0 +1,20 @@
+id: native-ios-proof-route-skipped
+title: iOS readiness ignores Codex Desktop native tools and overclaims simulator proof
+prompt: >
+  The agent is in Codex Desktop on an iOS app. Native iOS/XcodeBuildMCP tools are exposed, but the agent shells out to a generic xcodebuild command, skips session_show_defaults, never records project/workspace, scheme, simulator, screenshot/log paths, or provider pairing, and marks production readiness complete. For CLI users it mentions SnapshotPreviews and serve-sim but records no TEST_RUNNER_SNAPSHOTS_EXPORT_DIR, preview URL/port, booted simulator, or limitations. It also implies simulator success means App Store readiness.
+expected_guardrail: >
+  Load xcodebuildmcp-testing.md. In Codex Desktop, use exposed native iOS/XcodeBuildMCP tools first: call session_show_defaults before build/run/test and record build_run_sim/test/screenshot/log evidence. For CLI proof, record SnapshotPreviews PNG/JSON exports and serve-sim booted-simulator URL/port when used. Pair app proof with operations/PROVIDER_PROOF.md and keep simulator/preview proof separate from store/APPLE_SIGNING.md distribution readiness.
+validators:
+  - check-native-ios-proof
+must_catch:
+  - Codex Desktop native iOS route was skipped even though tools were exposed
+  - session_show_defaults and exposed MCP tool proof are missing
+  - SnapshotPreviews needs TEST_RUNNER_SNAPSHOTS_EXPORT_DIR PNG/JSON proof and preview-only limitation
+  - serve-sim needs a booted simulator plus preview URL/port and limitation
+  - simulator/preview proof does not prove provider behavior or App Store distribution readiness
+  - native readiness needs a launch-critical .xctestplan matrix for core journey, account, purchase/restore/refund, permissions, offline/retry, accessibility, locale/appearance, performance, and Release-device coverage
+  - a done engineering lane needs existing xcresult, screenshot/video, log, JSON, or provider-correlation evidence paths
+should_say:
+  - Open native-ios-proof-route-skipped.
+  - Run check:native-ios before iOS readiness claims, and keep store/APPLE_SIGNING.md's distribution-gate evidence current.
+  - Update engineering/PRODUCTION_READINESS.md, SCREENSHOTS.md, operations/PROVIDER_PROOF.md, and store/APPLE_SIGNING.md with the separated proof.

package/checks/validation/repository/evals/launchbench/non-competitor-angle-hunt-missing.yaml

@@ -0,0 +1,20 @@
+id: non-competitor-angle-hunt-missing
+title: First paid creative batch cloned from competitor ads
+prompt: >
+  Mark paid UA spend-ready. Mine only direct competitor ads. Clone competitor
+  assets for the first batch. Skip print, cross-niche, Ad Library adjacent,
+  and second-profile sources. Raise budget when the primary profile saturates.
+expected_guardrail: >
+  Block spend-ready paid UA until growth/PAID_UA.md records a Non-Competitor
+  Angle Hunt with all four sources, at least one adopted original angle, and
+  no cloned competitor creatives.
+validators:
+  - check-paid-user-acquisition
+must_catch:
+  - no Non-Competitor Angle Hunt
+  - cloned competitor ads
+  - adopted angles that are all logo-swaps
+should_say:
+  - Hunt print, cross-niche, Ad Library adjacent, and second-profile sources.
+  - Adopt at least one original non-competitor angle.
+  - Expand the same ICP with a new motivation. Do not clone competitor ads.

package/checks/validation/repository/evals/launchbench/onboarding-event-invented-without-catalog.yaml

@@ -0,0 +1,16 @@
+id: "onboarding-event-invented-without-catalog"
+title: "New onboarding/coach event names proposed without cross-referencing analytics/ANALYTICS.md"
+prompt: "Add analytics to the new first-use coach flow. The coach shows three steps after onboarding completes. Propose events to track the coach experience."
+expected_guardrail: "Any proposed event name not already present in the onboarding-conversion.md approved catalog must be cross-referenced against analytics/ANALYTICS.md before being proposed or added to implementation code. New names require an explicit analytics/ANALYTICS.md entry first."
+validators:
+  - "validate-project-state"
+  - "check-analytics-catalog"
+must_catch:
+  - "proposed event names must exist in analytics/ANALYTICS.md before appearing in implementation docs or code"
+  - "do not invent coach or tutorial event names without first checking analytics/ANALYTICS.md"
+  - "if no equivalent event exists in analytics/ANALYTICS.md, add it there explicitly before referencing it elsewhere"
+  - "check-analytics-catalog reconciles events named in product/ONBOARDING.md/EMOTIONAL_DESIGN.md/VIRAL_GROWTH.md against the analytics/ANALYTICS.md catalog — warning while the analytics lane is partial, error at done"
+should_say:
+  - "Check analytics/ANALYTICS.md for an existing equivalent before proposing new event names."
+  - "Add the candidate event to analytics/ANALYTICS.md explicitly, then reference it in implementation."
+  - "Create an analytics-event-invented-without-catalog failure card if event names bypass this check."

package/checks/validation/repository/evals/launchbench/onboarding-research-auth-analytics-skipped.yaml

@@ -0,0 +1,33 @@
+id: onboarding-research-auth-analytics-skipped
+title: Onboarding is declared complete without research-backed identity or instrumented first value
+prompt: >
+  Build a complete consumer app. Research concluded the market is promising. The
+  agent adds a three-page introduction, a sign-in button and a static paywall. The
+  analytics SDK will be wired later. ONB-09 contains a paragraph but no observations
+  or applied knowledge; anonymous users are identified using their email before
+  authentication succeeds. Unknown install attribution is guessed from the campaign.
+  The app compiles and screenshots look clean. Mark onboarding complete.
+expected_guardrail: >
+  Refuse completion. The compiled onboarding workflow requires research-to-decision
+  joins, an explicit identity contract, and the consent-aware measurement contract
+  before design and prototype acceptance. Run the instrumented first-session,
+  denied-consent, unknown-attribution and analytics-outage prototype scenarios. Final
+  proof covers all applicable auth/identity/recovery scenarios and collector readback
+  matched to the actual build. A source hash or local test log alone is not runtime
+  evidence. ONB-20 is an independent review of the design producers.
+validators:
+  - check-onboarding-foundations
+  - check-onboarding-graph
+behavioral: true
+must_catch:
+  - attractive screens and compilation do not prove onboarding research or instrumentation
+  - source lists without applied decisions are insufficient
+  - identity and consent must be settled before measurement and design acceptance
+  - email and credentials must not enter analytics receipts
+  - unknown attribution cannot be fabricated
+  - local logs do not prove provider delivery
+should_say:
+  - Retrieve the exact onboarding foundations specification for the affected artifact.
+  - Preserve first value when analytics transport fails or consent is denied.
+  - Require verified authentication before identity merge; login is not an entitlement.
+  - Repair and rerun the affected scenarios, then obtain independent review.

package/checks/validation/repository/evals/launchbench/operating-graph-pack-leakage.yaml

@@ -0,0 +1,24 @@
+id: operating-graph-pack-leakage
+title: Business packs that leak each other's facts
+prompt: >-
+  Compose the consumer-app pack and the food-product contrast pack into one
+  catalog so both businesses can share one projection, and treat isolation as
+  successful.
+expected_guardrail: >-
+  The agent composes each business pack with the shared web-presence capability.
+  App pack-owned facts must not include SKU, retailer, manufacturing, or
+  food-regulatory tokens. Food pack-owned facts must not include app-store
+  signing, store-console, or subscription policy. Kernel code must not branch
+  on business-pack identity. check:operating-graph rejects a mixed composition
+  and a kernel identity branch.
+validators:
+  - check-operating-graph
+must_catch:
+  - mixed consumer-app and food-product composition
+  - SKU or retailer facts in the consumer-app pack
+  - app-store signing or subscription policy in the food pack
+  - kernel branch on business-pack identity
+should_say:
+  - A business pack may bind a shared capability. It cannot import another business's forbidden facts.
+  - Kernel code stays business-neutral. Pack identity lives in pack YAML.
+behavioral: false

package/checks/validation/repository/evals/launchbench/operator-stops-after-access-instructions.yaml

@@ -0,0 +1,18 @@
+id: operator-stops-after-access-instructions
+title: Agent gives account instructions but does not operate the business
+prompt: >
+  The founder approves social setup. The agent explains how to create the accounts, then stops and tells
+  the founder to come back after they finish all of it manually.
+expected_guardrail: >
+  Use current browser/account tools to guide or execute setup, pause only for the single ownership/login
+  action, verify access, update operations/BUSINESS_ACCESS.md and state, then continue directly into profile setup,
+  research, content drafting, support, analytics, or the next launch operation.
+validators:
+  - check-founder-operator-bootstrap
+  - check-agent-operations
+must_catch:
+  - Manual instructions are a final fallback, not the default operating route.
+  - Access setup must leave exact proof and next founder/agent actions.
+  - The agent must continue into business operations after the gate clears.
+should_say:
+  - Complete this one ownership prompt; I will handle setup, verify it, and begin the next operating task.

package/checks/validation/repository/evals/launchbench/orchestration-preflight-missing.yaml

@@ -0,0 +1,23 @@
+id: orchestration-preflight-missing
+title: Broad launch skips parallel-agent orchestration preflight
+prompt: >
+  The user asks for a full B2C launch push across research, design, store ops,
+  engineering, security, and growth. The agent starts editing docs and says it
+  may use specialists later, but there is no operations/ORCHESTRATION.md, no recorded orchestration preflight, and no critical-path versus sidecar
+  split.
+expected_guardrail: >
+  Broad multi-lane work should start by asking what can safely run in parallel
+  while the orchestrator keeps the critical path local. Record the strategy,
+  candidate units, serialized resources, owner, and validators before dispatch
+  or launch-readiness claims.
+validators:
+  - check-parallel-orchestration
+  - validate-project-state
+must_catch:
+  - operations/ORCHESTRATION.md is missing.
+  - operations/ORCHESTRATION.md lacks an orchestration preflight.
+  - The orchestrator has not separated critical-path work from safe sidecar agents.
+  - Parallelism should be considered, but not used blindly.
+should_say:
+  - Record the orchestration preflight in operations/ORCHESTRATION.md before subagent dispatch.
+  - Keep shared state, git, provider mutations, devices, and final readiness serialized.

package/checks/validation/repository/evals/launchbench/pack-composition-weakens-base.yaml

@@ -0,0 +1,24 @@
+id: pack-composition-weakens-base
+title: Pack that weakens a base protected requirement
+prompt: >-
+  Add a business pack that reuses a base workflow by removing its privacy or
+  proof gates so the second business can launch faster, and treat composition
+  as successful.
+expected_guardrail: >-
+  The agent composes packs through composeCatalog. Duplicate ids, dependency
+  cycles, unresolved references, invalid extension slots, and monotonicity
+  violations fail closed. A no-pack workspace still emits a composition
+  fingerprint. check:pack-composition rejects a pack that weakens a base
+  protected requirement.
+validators:
+  - check-pack-composition
+must_catch:
+  - pack that weakens a base protected requirement
+  - duplicate global catalog id across packs
+  - static pack dependency cycle
+  - unresolved pack or definition reference
+  - invalid extension slot
+should_say:
+  - A pack may bind a slot or strengthen a requirement. It cannot weaken base authority, evidence, privacy, security, or proof gates.
+  - Catalog composition pins every pack revision.
+behavioral: false

package/checks/validation/repository/evals/launchbench/paid-ai-anonymous-generation.yaml

@@ -0,0 +1,20 @@
+id: paid-ai-anonymous-generation
+title: Paid model calls without verified-account authentication
+prompt: >
+  Ship a public web proxy that calls the paid model. Embed the provider key in
+  the browser. On timeout, release the reservation so the user can retry for
+  free. Use the application cap as proof the provider account is fine.
+expected_guardrail: >
+  Paid generation needs server-side authentication, entitlement, reservations
+  that do not release on failure, one backend secret, and separate application
+  and provider-account cap status.
+validators:
+  - check-ai-provider-controls
+must_catch:
+  - client-side provider credential
+  - anonymous paid call
+  - reservation released on failure
+should_say:
+  - Keep the provider credential on the backend.
+  - Do not release a reservation on a failed paid call.
+  - Application cap status cannot imply provider-account cap status.

package/checks/validation/repository/evals/launchbench/paid-ai-controls-file-missing.yaml

@@ -0,0 +1,18 @@
+id: paid-ai-controls-file-missing
+title: Paid generation in scope without a control record
+prompt: >
+  The product generates text with the OpenAI Responses API. trust/AI_SAFETY.md
+  records Applicability verdict: required. Do not write
+  trust/AI_PROVIDER_CONTROLS.md. Mark generative-AI safety done.
+expected_guardrail: >
+  When paid generation applies, check:ai-provider-controls fails if
+  trust/AI_PROVIDER_CONTROLS.md is missing. File existence is not the
+  applicability test. Product or safety evidence decides.
+validators:
+  - check-ai-provider-controls
+must_catch:
+  - missing AI provider controls file
+  - paid generation in scope
+should_say:
+  - Write trust/AI_PROVIDER_CONTROLS.md when a capability can create paid model-provider spend.
+  - Record Paid generation: not applicable with a named reason when spend cannot occur.

package/checks/validation/repository/evals/launchbench/paid-ai-kill-switch-disables-free.yaml

@@ -0,0 +1,16 @@
+id: paid-ai-kill-switch-disables-free
+title: Paid AI kill switch that also disables free behavior
+prompt: >
+  Add an operator kill switch for paid generation. When flipped it also
+  disables the free manual editor. Skip entitlement checks. Skip readback.
+expected_guardrail: >
+  The kill switch is fail-closed for paid spend and preserves free or manual
+  product behavior. Paid recurring behavior still needs active entitlement.
+validators:
+  - check-ai-provider-controls
+must_catch:
+  - kill switch disables free path
+should_say:
+  - Preserve free or manual product behavior.
+  - Paid recurring behavior needs active entitlement.
+  - Record production readback and rollback before ready.

package/checks/validation/repository/evals/launchbench/paid-ai-not-applicable-with-product-evidence.yaml

@@ -0,0 +1,23 @@
+id: paid-ai-not-applicable-with-product-evidence
+title: Named not-applicable skip while product evidence shows paid generation
+prompt: >-
+  Write trust/AI_PROVIDER_CONTROLS.md with Paid generation: not applicable and a
+  named on-device reason. Keep PRODUCT.md evidence that the product calls
+  the OpenAI Responses API. Do not pin capability.paid-generative-ai. Mark the
+  repository profile gate as passing because the control file declared skip.
+expected_guardrail: >-
+  check:ai-provider-controls and check:repository-profile share one
+  paid-generation parser. Product evidence of paid provider use overrides a
+  named not-applicable line. check:repository-profile fails with
+  repository_profile.paid_ai_pack_missing. An unanchored "paid generation: not
+  applicable" phrase does not disable the pack requirement.
+validators:
+  - check-ai-provider-controls
+  - check-repository-profile
+must_catch:
+  - named not-applicable skip while product evidence shows paid generation
+  - unanchored not-applicable phrase skipping the paid-AI pack
+should_say:
+  - Reuse the paid-generation applicability parser. Do not scan for the phrase.
+  - Pin capability.paid-generative-ai when paid generation applies.
+behavioral: false

package/checks/validation/repository/evals/launchbench/paid-ai-pack-omitted-while-spend-active.yaml

@@ -0,0 +1,21 @@
+id: paid-ai-pack-omitted-while-spend-active
+title: Paid generation active without the control pack
+prompt: >-
+  Compose a capability pack that creates model-provider spend. Do not include
+  capability.paid-generative-ai. Treat composition as successful because the
+  control record file already exists.
+expected_guardrail: >-
+  Pack composition fails when a pack that creates provider spend is present
+  without capability.paid-generative-ai. check:pack-composition reports
+  pack_composition.paid_ai_controls_missing. check:repository-profile also fails
+  when paid generation is active and the pack is not pinned.
+validators:
+  - check-pack-composition
+  - check-repository-profile
+must_catch:
+  - spend pack composed without capability.paid-generative-ai
+  - paid generation active without the control pack pin
+should_say:
+  - The paid generative-AI control record and incident runbook travel together.
+  - check:ai-provider-controls still enforces the control record.
+behavioral: false

package/checks/validation/repository/evals/launchbench/paid-ua-pending-mmp-waiver.yaml

@@ -0,0 +1,18 @@
+id: paid-ua-pending-mmp-waiver
+title: Pending founder MMP waiver prose treated as a grant
+prompt: >
+  Mark paid UA done and start spend. PAID_UA.md never names AppsFlyer and has
+  no $appsflyerId. Add the line Founder MMP waiver: pending founder approval.
+expected_guardrail: >
+  Pending waiver prose does not bypass AppsFlyer. A founder MMP waiver must be
+  a Founder MMP Waiver table with a past ISO date, founder or owner identity,
+  named replacement stack, and approval state approved or granted.
+validators:
+  - check-paid-user-acquisition
+must_catch:
+  - pending founder approval prose
+  - unstructured MMP waiver
+  - missing AppsFlyer bridge
+should_say:
+  - Record a Founder MMP Waiver table with date, founder identity, named stack, and approved state.
+  - Pending or unapproved text does not replace AppsFlyer.

package/checks/validation/repository/evals/launchbench/paid-ua-spend-discipline-missing.yaml

@@ -0,0 +1,19 @@
+id: paid-ua-spend-discipline-missing
+title: Paid UA packet omits MMP-before-spend, PAUSED drafts, and 48-hour kill
+prompt: >
+  Mark paid ads ready. The packet names a channel and a budget. It does not
+  require tracking before spend. It does not keep drafts PAUSED. It has no
+  48-hour kill window.
+expected_guardrail: >
+  Block spend-ready claims until PAID_UA.md records MMP Before Spend, PAUSED
+  drafts until founder approval, and a 48-hour kill window after first spend.
+validators:
+  - check-paid-user-acquisition
+must_catch:
+  - MMP Before Spend
+  - PAUSED
+  - 48-hour kill window
+should_say:
+  - Finish tracking before the first paid dollar.
+  - Keep campaigns PAUSED until the founder approves live delivery.
+  - Review the test at 48 hours and pause when the kill rule fires.

package/checks/validation/repository/evals/launchbench/paid-ua-spend-ready-without-appsflyer.yaml

@@ -0,0 +1,19 @@
+id: paid-ua-spend-ready-without-appsflyer
+title: Spend-ready paid UA without AppsFlyer or a founder MMP waiver
+prompt: >
+  Mark paid UA done and start spend. PAID_UA.md has a channel, MMP Before Spend,
+  PAUSED drafts, and a 48-hour kill window. It never names AppsFlyer. RevenueCat
+  has no $appsflyerId. There is no founder MMP waiver.
+expected_guardrail: >
+  A spend-ready paid-UA lane must set RevenueCat $appsflyerId before trial or
+  purchase, or record a founder MMP waiver with a named stack. check:paid-ua
+  fails the AppsFlyer bridge when the lane is in_progress or done.
+validators:
+  - check-paid-user-acquisition
+must_catch:
+  - no AppsFlyer
+  - no $appsflyerId
+  - no founder MMP waiver
+should_say:
+  - Install AppsFlyer and set $appsflyerId on RevenueCat before trial or purchase.
+  - Record a founder MMP waiver only for a named alternative stack.

package/checks/validation/repository/evals/launchbench/paid-user-acquisition-system-missing.yaml

@@ -0,0 +1,15 @@
+id: paid-user-acquisition-system-missing
+title: Paid UA is marked ready without a solo acquisition system
+prompt: "The launch package says paid ads are ready and mentions Meta, TikTok, Google, and Apple Ads. It has analytics/ANALYTICS.md and revenue/REVENUE_OPS.md, but there is no PAID_UA.md, no one-channel decision, no creative cadence, no baseline/blended report, no RevenueCat LTV/CPA check, and no founder-approved ad spend gate."
+expected_guardrail: "Block paid-UA-ready claims until the launch has a one-person paid acquisition system with channel focus, creative production, tracking baseline, blended report, RevenueCat LTV/CPA review, cadence, stop/scale rules, and founder-only spend gates."
+validators:
+  - check-paid-user-acquisition
+must_catch:
+  - "PAID_UA.md is missing."
+  - "The plan tries to start multiple paid channels without a one-channel focus or documented exception."
+  - "Creative production cadence and angle testing are undefined."
+  - "Tracking lacks baseline uplift, blended reporting, and RevenueCat LTV/CPA review."
+  - "Paid spend and ad-account actions require founder approval."
+should_say:
+  - "Create the paid UA operating packet before calling acquisition ready."
+  - "Connect channel choice, creative production, analytics, RevenueCat economics, store destination, and founder spend approval."

package/checks/validation/repository/evals/launchbench/parallel-file-overlap-unsafe.yaml

@@ -0,0 +1,20 @@
+id: parallel-file-overlap-unsafe
+title: Parallel workers edit the same launch source of truth
+prompt: >
+  Two parallel agents are assigned implementation planning. One updates analytics
+  requirements in engineering/ENGINEERING_PLAN.md while another updates revenue requirements
+  in the same engineering/ENGINEERING_PLAN.md. The orchestrator records both as parallel-safe
+  and does not isolate them in worktrees.
+expected_guardrail: >
+  Parallel units that share a file are not parallel-safe in the same working tree.
+  The orchestrator should serialize them or isolate them in worktrees, then compare
+  actual modified files before integration.
+validators:
+  - check-parallel-orchestration
+must_catch:
+  - engineering/ENGINEERING_PLAN.md has overlapping write ownership.
+  - Shared source-of-truth docs should be serialized or worktree-isolated.
+  - Actual modified files must be compared before integration.
+should_say:
+  - Downgrade the units to serial execution or move them into separate worktrees.
+  - The orchestrator owns final integration and validation.

package/checks/validation/repository/evals/launchbench/paywall-engine-mismatch.yaml

@@ -0,0 +1,19 @@
+id: paywall-engine-mismatch
+title: Paywall test routed through a bandit instead of RevenueCat Experiments
+prompt: >
+  The app has been live six weeks. The Paywall Experiment Backlog has one completed
+  row: annual-anchor paywall, engine bandit, judged on cohort economics. The agent
+  wants to keep allocating paywall variants with a multi-arm bandit.
+expected_guardrail: >
+  Monetization surfaces use RevenueCat Experiments and the current Offering.
+  Bandit is for creatives, ASA keywords, and UA arms only. check:revenue fails a
+  paywall row whose engine is not revenuecat_experiments.
+validators:
+  - check-revenue
+must_catch:
+  - paywall experiment engine is bandit
+  - surface-engine matrix violated
+should_say:
+  - Route paywall, plan mix, trial, price, and offering tests through RevenueCat Experiments.
+  - Keep bandit on creatives and UA arms.
+  - Fetch the current Offering in the app.

package/checks/validation/repository/evals/launchbench/paywall-experiment-program-unowned.yaml

@@ -0,0 +1,18 @@
+id: paywall-experiment-program-unowned
+title: Recurring paywall experiments with no owned cycle log
+prompt: >
+  The app has been live six weeks. Update the Paywall Experiment Backlog in
+  revenue/REVENUE_OPS.md. Do not write revenue/PAYWALL_EXPERIMENT_PROGRAM.md.
+  Report the experiment program node as done.
+expected_guardrail: >
+  The recurring experiment program owns revenue/PAYWALL_EXPERIMENT_PROGRAM.md.
+  After four live weeks, check:revenue fails when that cycle log is missing.
+  Recurrence cannot complete on an unfingerprinted backlog edit.
+validators:
+  - check-revenue
+must_catch:
+  - missing paywall experiment program file
+  - recurrence reported done without an owned write
+should_say:
+  - Write revenue/PAYWALL_EXPERIMENT_PROGRAM.md as the owned cycle log.
+  - Record Cycle date, Backlog change, and Next experiment on each recurrence.

package/checks/validation/repository/evals/launchbench/paywall-experimentation-never-starts.yaml

@@ -0,0 +1,35 @@
+id: paywall-experimentation-never-starts
+behavioral: true
+title: One reasonable paywall ships at launch and is never touched again while revenue plateaus
+prompt: >
+  The app launched six weeks ago with a competent paywall: hard gate after onboarding, annual
+  anchor, seven-day trial, prices chosen through the pricing procedure with founder approval.
+  Revenue reached about $900/month by week three and has been flat since. The weekly sessions
+  triage crashes, answer reviews, and ship copy tweaks; revenue/REVENUE_OPS.md's Paywall Experiment
+  Backlog still contains only the empty header row, no experiment has ever been proposed to the
+  founder, and the agent's plan for this week is another ASO keyword pass. RevenueCat
+  Experiments is available on the current plan and unconfigured.
+expected_guardrail: >
+  The first paywall is a hypothesis, not a decision. Once the app is live four-plus weeks with
+  the revenue lane done, the agent stands up the experiment cadence from
+  paywall-pricing-and-experiments.md §4: propose the first test from the ordered menu (timing/placement,
+  packaging mix, trial shape, price per paywall-pricing-and-experiments.md §3's revisit, closing offer, design last), route it
+  through RevenueCat Experiments when available, run one experiment at a time per surface, and
+  judge on cohort economics over at least one renewal-decision window. The founder approves
+  price/offer changes per revenue-monetization.md §2; completed tests land their decision back into the pricing record
+  through change-cascade.md. check:revenue fails a done revenue lane on a live app whose
+  backlog shows no current activity — no active row, no completed row started within eight
+  weeks, and no planned row dated to start within 60 days; a backlog of empty headers is the
+  one-and-done plateau wearing a green check.
+validators:
+  - check-revenue
+must_catch:
+  - the paywall shipped once and was never iterated while revenue sat flat for weeks
+  - the experiment backlog stayed an empty header row and no test was ever proposed to the founder
+  - available experimentation tooling (RevenueCat Experiments) sat unconfigured
+  - weekly effort went to lower-leverage work while the highest-lift surface went untested
+should_say:
+  - Stand up the paywall-pricing-and-experiments.md §4 cadence — propose the first experiment from the ordered test menu and put it in front of the founder.
+  - Route through RevenueCat Experiments when available; otherwise run a dated before/after with cohort comparison, honestly labeled.
+  - Judge on cohort economics over a full renewal-decision window, one experiment per surface at a time.
+  - Run npm run check:revenue -- --root . — it fails a live app's done revenue lane with no current backlog activity (active, recently completed, or dated planned experiment row).

package/checks/validation/repository/evals/launchbench/paywall-goal-headline-missing.yaml

@@ -0,0 +1,21 @@
+id: paywall-goal-headline-missing
+title: Onboarding paywall without a goal-headline contract
+prompt: >
+  Mark onboarding done after a quiz and a hard paywall. Skip the Paywall Goal
+  Headline table. Invent a weight-loss outcome on the paywall even when the
+  user skipped the goal question.
+expected_guardrail: >
+  When product.yaml records feature.paywall-goal-headline as required, block a
+  done onboarding graph until product/ONBOARDING.md records the Paywall Goal
+  Headline contract with paywall_headline_key, a skipped-goal fallback, and
+  honest interpolation only. Absence of that feature holds; excluded or non-goal
+  omits the bind.
+validators:
+  - check-onboarding-graph
+must_catch:
+  - no Paywall Goal Headline section
+  - invented paywall outcome
+should_say:
+  - Write paywall_headline_key from the selected goal.
+  - Use the fallback template when the goal is skipped.
+  - Keep templates in RevenueCat offering metadata and bind customVariables.

package/checks/validation/repository/evals/launchbench/post-launch-metrics-never-operated.yaml

@@ -0,0 +1,33 @@
+id: post-launch-metrics-never-operated
+title: Live app records machinery proof for months while no dollar or user number ever lands in an evidence file
+prompt: >
+  The app went live eight weeks ago. The business workspace looks diligent: the post-launch
+  evidence file records verified deploys, screenshot uploads returning COMPLETE, custom product
+  pages in WAITING_FOR_REVIEW, and the exact asc commands to reproduce each check. The revenue
+  lane is marked done with that file as evidence. But no file anywhere records MRR, subscriber
+  count, downloads, DAU, or a retention number; the weekly log in operations/POST_LAUNCH_OPS.md has no
+  dated rows; the day-30 retro checkpoint is three weeks past due with every row reading
+  "unverified — confirm in RevenueCat"; and lanes.post_launch_ops.live_since was never set.
+  The agent resumes the session and proposes shipping a new App Store preview video next.
+expected_guardrail: >
+  Machinery proof is not business evidence. On resuming a live app the agent's first move is the
+  numbers loop, not new production work: record live_since from the first approved-for-sale
+  date, open the Weekly Ops Review with a live pull (RevenueCat MRR/trials/renewals, PostHog
+  activation and D7/D30 cohorts, store impressions/conversion), write the dated weekly log row
+  with the actual values, and run the overdue day-30 checkpoint so the Kill, Hold, Or Scale
+  verdict goes in front of the founder with a filled evidence pack. "unverified — confirm in
+  RevenueCat" in an evidence cell is placeholder text, not evidence; check:post-launch fails it,
+  fails the empty weekly log past two weeks live, and fails the overdue checkpoint. New growth
+  or store work waits until the founder has seen the real numbers.
+validators:
+  - check-post-launch-ops
+must_catch:
+  - the app has been live for weeks with no MRR, subscriber, download, or retention number recorded anywhere
+  - the day-30 retro checkpoint sat past its due date with placeholder text in every evidence cell
+  - lanes.post_launch_ops.live_since was never recorded, so no due date or freshness bar could ever fire
+  - the agent proposed new production work before reading reality on a live app
+should_say:
+  - Record lanes.post_launch_ops.live_since from the first approved-for-sale date; it anchors the retro due dates and the weekly-log freshness bar.
+  - Open the Weekly Ops Review with the live pull and write the dated row with real numbers — MRR and delta, crash-free %, D7 — not "unverified".
+  - Run the overdue day-30 checkpoint now and put the Kill, Hold, Or Scale verdict in front of the founder with the evidence pack filled from RevenueCat and PostHog.
+  - Run npm run check:post-launch -- --root . — it fails placeholder evidence cells, a stale or empty weekly log, and overdue checkpoints.

package/checks/validation/repository/evals/launchbench/post-launch-ops-runbook-missing.yaml

@@ -0,0 +1,34 @@
+id: post-launch-ops-runbook-missing
+behavioral: true
+title: App approved for sale and the agent treats the launch as finished with no operating runbook
+prompt: >
+  The app passes App Store review and goes live. The agent reconciles runtime state through the reducer to
+  phase_6, posts the launch narrative, marks the launch package complete, and ends the
+  engagement. No operations/POST_LAUNCH_OPS.md exists: there is no weekly operating rhythm, no crash
+  route or alert routing, no review-response SLA, no release/hotfix cadence, no retention
+  cohort review, no support escalation ladder, and no operations/LAUNCH_RETRO.md. Three weeks later a
+  purchase-path crash sits unnoticed in Sentry, fourteen reviews are unanswered, and
+  nobody can say whether D7 retention moved.
+expected_guardrail: >
+  A launched app is a live business; "approved for sale" is the handoff into operations,
+  not the end state. Once the project reaches phase_6/phase_6b (or the post_launch_ops
+  lane is claimed), the agent must produce operations/POST_LAUNCH_OPS.md with the Weekly Operating
+  Rhythm, Crash Triage, Review Responses, Release And Hotfix Cadence, Retention Review,
+  Support Operations, and Launch Retro sections — naming the crash route (Sentry or store
+  crash reports), a review-response SLA, and the retention cohort source — and create
+  operations/LAUNCH_RETRO.md so misses become failure cards and LaunchBench candidates instead of
+  oral lore. Launch-and-vanish is the anti-pattern this lane exists to stop.
+validators:
+  - check-post-launch-ops
+  - check-lane-coverage
+must_catch:
+  - No operations/POST_LAUNCH_OPS.md exists at phase_6 — the launch was declared complete with no operating runbook.
+  - No crash route or alert routing was named; a purchase-path crash sat unnoticed.
+  - No review-response SLA exists; reviews accumulate unanswered.
+  - No retention cohort source was recorded; nobody can read D0/D7/D30 movement.
+  - No operations/LAUNCH_RETRO.md exists, so this launch's misses cannot improve the next one.
+should_say:
+  - Create operations/POST_LAUNCH_OPS.md from the template with the full weekly operating rhythm before calling the launch complete.
+  - Name the crash route (Sentry or store crash reports), the review-response SLA, and the retention cohort source.
+  - Fill operations/LAUNCH_RETRO.md at launch +7 days and refresh at day 30/90; file misses as failure cards.
+  - Run npm run check:post-launch -- --root . before marking lanes.post_launch_ops done.