Business requirements

PROG-01 — Status paths

PROG-01

/status.html and /status both resolve to the current status experience, with the same source data; a redirect is acceptable if it preserves the destination. Homepage/footer status navigation remains visible and usable on phone/desktop, with direct navigation, revisit/back and refresh exercised. Keep /BRD.HTML working.

PROG-02 — Derived metrics

PROG-02

Implement the D/I/H/V definitions, denominator edition, exact counts and blocked/open/unknown values above from TASKS. Demonstrate a known incomplete/blocked row stays out of completed counts, changed evidence is invalidated appropriately and percentages update deterministically. No invented current progress values.

PROG-03 — Freshness and validation

PROG-03

Hosted checks catch missing/duplicate denominator IDs, uncovered accepted requirements, inconsistent states/evidence, stale projection and meaningful changes without task updates. Display source versus deployed identity and update times clearly. Verify the hosted page against the exact assessed TASKS revision, including refresh after a real new deployment; do not promise automatic live updates before deploy.

DASH-01 — Working login entry

DASH-01

The existing public disposable demo account validates correct/incorrect credentials and establishes the scoped local demo session. Ordinary successful sign-in opens /dashboard with a clear account entry. Preserve existing same-origin pending-save/campaign return exactly once when login originated there, and provide a direct dashboard link; the new default dashboard must not break accepted intended-action return. Incorrect credentials never create a session.

DASH-02 — Session-gated route

DASH-02

Direct /dashboard access without a valid demo session redirects to the existing login flow with safe intended return; successful login returns to the dashboard. Refresh/back/history and logout cannot expose an active dashboard session after logout. Client-side demo route gating is a usability state, not secure protection for private data. No real customer data or server identity claims.

DASH-03 — Useful dashboard

DASH-03

Provide actual functioning saved-recipe access, collection create/rename/delete/organization and supported notes/personal-version entry using existing browser-local data. Reflect the same data as My Recipe Book without a divergent store. Show useful empty states and clear ways back to browse and manage collections; do not fabricate saved recipes or the missing 100-recipe corpus. Recipe-dependent acceptance remains open until real reviewed content is available.

DASH-04 — Persistence and recovery

DASH-04

Exercise save/organize/note update and refresh/back/reopen, logout and subsequent login, deliberate local clear/reset and unavailable/corrupt storage. Preserve existing logout-versus-book-clearing meaning and give truthful local-only/device-origin limits. No cloud synchronization, paid service, production authentication or new backend follows. If real identity is later wanted, retain it as a separate decision.

DASH-05 — End-to-end proof

DASH-05

Assigned QA performs real hosted clicks: guest dashboard redirect → incorrect login → correct login → working dashboard → collections/notes/saved-item interactions where real data permits → refresh/back → logout → denied dashboard access. Record exact URL/deployment/source, viewport, screenshot, result, missing-content limits and fix/recheck. Source or logged-in badge alone cannot pass.

Common progress definitions for all five sites — 1

common-progress:paragraph-1

The common comparison denominator is scope edition PROGRESS-GROUPS-1: ten groups, D=10. Use these exact IDs across all five sites:

Common progress definitions for all five sites — 2

common-progress:paragraph-2

Every applicable accepted criterion maps to one primary group, with secondary cross-references allowed but no extra denominator votes. Site-specific visual/detail criteria live under the relevant common group. A group is complete at a state only when all its applicable accepted children meet that state with evidence. Show child criterion counts for diagnosis, clearly labeled as site-specific and not comparable headline completion. Raw 61/76/121/145 row totals, headings, metadata and finding duplicates never determine the headline percentage. These equal-group percentages are coarse requirement-coverage measures, not effort-weighted estimates; display that limitation. New accepted criteria may reopen a group and reduce its percentage without regression in older work; explain the scope/evidence change and preserve the history. A genuinely new group requires an explicit new common denominator edition, not an unannounced site-local denominator change. Let D be the number of common accepted groups in that edition (10 for PROGRESS-GROUPS-1). I counts groups fully implemented in source with relevant source evidence; H counts groups whose complete implementation is evidenced on an identified hosted candidate; V counts groups with an independently observed passing recheck of that hosted implementation. Show Implemented = 100 × I/D, Deployed = 100 × H/D, Verified = 100 × V/D, each to one decimal place alongside its exact count and D. For a given assessed candidate, V ≤ H ≤ I ≤ D. Unknown, partially complete and blocked requirements never count as complete. D=0 is “not assessed”, not 100%. Verified percentage is requirement coverage, not the project owner final acceptance, product quality score or effort/time estimate.

Common progress definitions for all five sites — 3

common-progress:paragraph-3

Show open groups = D − V and blocked groups as the explicitly blocked subset of open, plus unknown/unassessed group count. Also show labeled detailed open/blocked criterion counts without using them as the cross-site percentage denominator. Blocked and unknown are subsets, not additional denominator entries. A changed affected implementation invalidates stale passing evidence until rechecked; unaffected evidence can carry only with explicit unchanged-scope binding. Source progress may describe a newer candidate than the live site, but label both identities and compare metrics within each candidate; never mix incompatible numerator evidence silently.

Common progress definitions for all five sites — 4

common-progress:paragraph-4

Generate the numbers from TASKS data, never manually type a second status percentage. Display denominator edition, updated timestamp, source revision/content digest, deployed identity and evidence time (or unknown). No self-referential containing commit hash. Static status changes become visible after the corresponding deployment and refresh; describe this honestly, with usable navigation/reload and no claim of real-time synchronization.

G01

G01

100 distinct complete original Recipe-engine/common-intake outputs, retained provenance and required review, actually integrated as static content

G02

G02

Complete articles, ingredient/technique/resource libraries, supporting guidance and relationships

G03

G03

Search/category/collection/classification, canonical routes/metadata, filtering/back/error/empty-state discovery

G04

G04

Own public identity and distinct accurate dish/ingredient/step imagery, rights, captions and responsive presentation

G05

G05

Find/decide/shop/cook/print/adapt activities, supported quantities/units/substitutions, timers/placekeeping and recovery

G06

G06

Demo login/session/dashboard, My Recipe Book/save/collections/notes/versions, persistence/reset/logout and supported sharing/return

G07

G07

Existing bounded real-email contract, consent/status, authorized transport/inbox and exact campaign return

G08

G08

NO ADS EVER, accessibility/phone/desktop quality, honest limitations and dated evidence/independent repair-recheck requirements

G09

G09

Public /BRD.HTML and /status plus /status.html, safe complete business projection, task traceability, discoverable responsive reading and independent branches

G10

G10

Derived honest progress metrics, explicit source/deployed identities, freshness and meaningful-update/coverage validation

PUB-DOC-01 — Exact BRD route

PUB-DOC-01

Hosted /BRD.HTML renders the current BRD business content as readable HTML rather than a raw download, missing route or homepage fallback. Preserve requirement meaning, headings and traceable identifiers, including latest accepted deltas. Record actual URL, deployed source identity, date, viewport and screenshot. Verify /brd.html if implemented.

PUB-DOC-02 — Safe public scope

PUB-DOC-02

Do not copy this full internal source file or doctrine directory blindly into public assets. Render an explicit public business-content projection from the current BRD: retain all accepted business requirements and honest implementation limits while excluding private operational records, credentials, private .env values, internal sensitive records and nonpublic personal information. Do not expose raw private appendices through HTML comments, downloadable sources, source maps or bundled data. Record the projection rule and any excluded internal sections for owner review without reproducing sensitive values. Privacy exclusions cannot hide an unmet business requirement or fabricate a pass.

PUB-DOC-03 — Full checklist

PUB-DOC-03

product/TASKS.md maps every currently accepted BRD requirement/criterion and applicable coverage-map obligation to an implementation row, using stable existing requirement IDs or section/anchor references. Group rows only when individual obligations and their different states remain traceable. Preserve superseded history as history, not duplicate active obligations. Include ACT-UX-01–12 and PUB-DOC-01–10. Missing work stays visible; a finished shell is not completion of its content or journeys.

PUB-DOC-04 — Honest status fields

PUB-DOC-04

Each row records actual assigned owner, source progress, hosted proof, independent review proof, gap, next action, last-updated timestamp and candidate identity. Separate planned/in progress/source complete/deployed/reviewed/accepted; use not verified or awaiting owner when appropriate, never invent an assignment or evidence. Link public-safe evidence; retain sensitive proof privately with a truthful public summary. Display meaningful status, not a cosmetic percentage inferred from checkbox count.

PUB-DOC-05 — Deterministic source

PUB-DOC-05

Generate/render BRD business content from product/BRD.md and status from product/TASKS.md through a documented deterministic transformation. Avoid a separately maintained HTML requirements copy. Identify the source revision/content digest and transformation so reviewer can compare actual source to published output and detect staleness. A generated projection is not permission to omit business scope.

PUB-DOC-06 — Update discipline

PUB-DOC-06

Every implementation commit by Codex or Mac updates relevant task progress/evidence, next action and timestamp. Meaningful changes require matching task updates; nonfunctional changes record an explicit justified no-impact disposition where applicable. Assigned instruction owner places this rule in the existing per-repo Codex/Mac entries. Preserve other writers and separate branch state; main evidence is not proof of Mac preview behavior or vice versa.

PUB-DOC-07 — Scoped validation

PUB-DOC-07

Hosted prebuild/CI validation must catch missing checklist coverage, required fields, stale generated output and meaningful implementation changes without task updates. Demonstrate both a rejected deliberately stale/missing update case and a corrected passing case in the approved hosted workflow. Check actual changed paths and task references; a changed timestamp alone does not demonstrate meaningful progress. No local application tests/builds/servers/loopback are authorized.

PUB-DOC-08 — Candidate identity

PUB-DOC-08

Avoid a document embedding the hash of the commit that contains itself. Use content digests or a prior verified source revision with explicit meaning; inject the actual deployment/source revision through CI/deployment metadata for the served candidate. Keep document update time, source identity and hosted verification time distinct. Unknown deployed identity stays unknown until Delivery supplies it.

PUB-DOC-09 — Readable discovery

PUB-DOC-09

Homepage/footer expose clearly labeled BRD and Status links. Both pages work on mobile and desktop with readable headings, wrapping tables/long links, keyboard navigation and meaningful link text. Status links to the repository product/TASKS.md at an identified source revision; a private repository link is labeled as requiring authorized access while the public status remains readable. Verify exact-case route, refresh/direct navigation, all links and privacy-safe content on the hosted candidate.

PUB-DOC-10 — Completion and handoff

PUB-DOC-10

Source or CI success alone cannot close this delta. Delivery supplies exact hosted /BRD.HTML and /status URLs, source/deployment identity and route/content proof; assigned QA independently verifies source parity, public-safe scope, checklist coverage, mobile/desktop readability and update behavior. Record finite defects and recheck repairs. Only after those exact deployed paths/proofs return does Solutions prepare the subsequent Mac prompt; no deployment or acceptance is presumed now.

100 original reviewed recipes

coverage-floor:100-original-reviewed-recipes

Existing Recipe writer/common-intake owner, Batch, Content and reviewers; distinguish 100 retained inputs from 100 distinct complete reviewed output recipes, export/lineage and actual per-site static consumption. No handmade substitute or count inflation.

Articles and learning

coverage-floor:articles-and-learning

Content/Recipe and builder: complete articles, ingredient/technique/resource libraries, before-cook/help content, useful relationships and return to the originating step.

Discovery and classification

coverage-floor:discovery-and-classification

Builder/UIUX with Batch/Content: home, search, category/collection/filter flows, all nine classification groups where supported, occasion placements, related browsing, canonical recipe identities/routes, metadata, empty/error/back states.

Identity and imagery

coverage-floor:identity-and-imagery

Visual, Content and builder: Is the Best Recipe own branding, distinct exact-dish home/major-category features, rights/alt/caption and responsive fallback; no generic illustration passed off as verified dish imagery.

Real activity and adaptation

coverage-floor:real-activity-and-adaptation

UIUX, builder and domain/technical reviewers: find, assess time/effort/ingredients/equipment, shop, mobile cook/placekeeping/checkoffs/timers/screen behavior, clean complete print, supported scaling/units/substitutions/preferences/notes/own versions and recovery. Unsupported mechanisms remain explicit gaps/proposals.

Keeping and sharing

coverage-floor:keeping-and-sharing

Builder/CRM and QA: demo login/logout, local My Recipe Book/save/organize/made-state, share/return, persistence/reset limitations and truthful privacy; no database or implied cloud account.

Bounded real email

coverage-floor:bounded-real-email

CRM/Software, existing mail owner and Delivery: fixed authorized recipient, existing finite cap/deduplication contract, actual sent/received proof and exact campaign landing return; UI simulation is not transport completion.

Ad-free quality and evidence

coverage-floor:ad-free-quality-and-evidence

All assigned implementers and independent reviewers: NO ADS EVER; accessibility/keyboard, phone/desktop, print, error/recovery, dated real user/research evidence, labeled opinions, supported alternatives and hosted screenshots/reproduction.

Public docs/status and delivery

coverage-floor:public-docs-status-and-delivery

Assigned builder/instruction owner, Delivery and QA: PUB-DOC-01–10, full per-requirement task mapping, deterministic safe projection, update validation, exact deployment/source evidence, independent Mac branch continuity and finite repair/recheck.

ACT-UX-01 — Ad-free

ACT-UX-01

No advertising anywhere in the recipe experience, including browsing, detail, cooking, printing and account/campaign return. Inspect rendered states and relevant source/integrations for ad slots, ad content and advertising scripts. Approved user-requested signup/campaign communication is governed by the existing finite mail contract; it does not authorize third-party advertising.

ACT-UX-02 — Find

ACT-UX-02

A person can find relevant recipes through the specified search, categories and collections, understand results, recover from no results and return without unnecessarily repeating choices. Demonstrate a realistic task across the real reviewed corpus, on phone and desktop.

ACT-UX-03 — Decide

ACT-UX-03

Before committing to cooking, the person can assess time, effort, ingredients and equipment using actual recipe information. Distinguish total/active/wait time where the source supports it; do not invent effort scores or equipment/time facts. Demonstrate a choice and the ability to inspect needed information without losing the candidate recipe. Missing source fields become precise content/schema gaps.

ACT-UX-04 — Shop

ACT-UX-04

Support the transition from choosing a recipe to obtaining its ingredients: understandable quantities, units and needed items, with a usable shopping workflow and return to the recipe. Demonstrate the implemented route and limits. Combined lists, pantry inference, ordering, retailer integrations or synchronizing lists are proposals unless separately supported and assigned; do not silently promise them.

ACT-UX-05 — Cook on mobile

ACT-UX-05

Demonstrate readable ingredients and steps, placekeeping, checkoffs, timers and the specified screen behavior in a realistic cooking flow with messy hands in mind. Record viewport, interaction burden and interruption/resume behavior. UI/UX must specify and verify the chosen mechanisms; no hands-free, voice, wake-lock, background-timer or cross-device guarantee follows from this requirement alone. If a browser capability is unsupported or denied, expose its actual limit and usable recovery rather than claiming success. Step/timer completion never certifies food safety.

ACT-UX-06 — Print

ACT-UX-06

Print a complete clean recipe with necessary ingredients, quantities, equipment and full instructions, readable pagination and no ads, navigation clutter or clipped steps. Inspect the actual print output/preview for the candidate, including long recipes and current supported servings/units; do not count a print button alone.

ACT-UX-07 — Modify

ACT-UX-07

Demonstrate supported scaling, unit conversion, substitutions, notes and own versions with clear distinction between the original and personal changes. Preserve original source and explain persistence/reset limits. Use supported culinary data: do not automatically scale cooking time/temperature or invent safe substitutions/conversions. Unsupported cases need explicit boundaries and an owner gap; generalized AI rewriting, cloud accounts and publishing personal versions are not implied.

ACT-UX-08 — Keep, organize, share

ACT-UX-08

Demonstrate keeping and finding a recipe in My Recipe Book, organization, notes/version retrieval, supported sharing and return. Exercise refresh, logout/reset and an unavailable share mechanism as applicable; identify actual device-local persistence and a truthful fallback. Do not imply private cloud storage, synchronization or that private local notes travel with a shared public URL.

ACT-UX-09 — Evidence and alternatives

ACT-UX-09

Every user-behavior claim cites actual dated feedback or research and a usable source link, including scope/limitations. Label design opinions, hypotheses and untested recommendations. Explain the evidence and expected activity improvement behind recommendations; when implemented, demonstrate alternatives in hosted previews and retain the comparison evidence. No fabricated interviews, invented study results or universal conclusions from one opinion.

ACT-UX-10 — Live defect proof

ACT-UX-10

For a claimed live defect, retain exact URL, observation date/time, viewport and screenshot, plus reproduction, expected/observed behavior and deployment/source identity when available. Tool failures are labeled separately from product defects. Recheck the repaired hosted candidate against the same criterion. Do not present old screenshots as current live proof.

ACT-UX-11 — Independent Mac review

ACT-UX-11

Mac Claude records gaps/recommendations and evidence under this repository's product/ on mac-claude-qa, preserving its assigned branch and authorship. Windows owners consume the scoped evidence through PO and actual writer handoff; neither side silently replaces the other's implementation or declares the other's acceptance.

ACT-UX-12 — Parallel progress

ACT-UX-12

Research and current live inspection may proceed alongside the five builds. No new research gate, forced strongest-site-first sequence or cross-site completion dependency is introduced. Record missing evidence and continue independent authorized implementation; final acceptance still requires the applicable evidence.

Current settled corrections — 1

settled:paragraph-1

- 100 retained ingredient sets, not 35. Existing Recipe writer/common intake must produce complete English original instructions and required companion fields using the established method. Content reviews/refines through the real owner loop. Same reviewed static dataset may be copied independently into all five; no database, handmade/copied recipe substitutes or fabricated receipts.

Current settled corrections — 2

settled:paragraph-2

- Public identity is exactly Is the Best Recipe with each site's own creative logo/style. Internal competitor references must not appear as public site branding, metadata, campaign or email identity. Existing Network branding is not inherited. Concise truthful demo-account/local-storage/send limits remain at relevant controls.

Current settled corrections — 3

settled:paragraph-3

- All full familiar Recipe features below remain; initial front page is intermediate. English only. Transformers/cross-family integration are NOT required now and cannot block these sites. No unrelated production identity, community-publishing or payment authority follows.

Current settled corrections — 4

settled:paragraph-4

- Real requested email is bounded to the project owner through the existing approved owner path and exact CRM contract. Demo login is public simulation, not company authentication or mail authorization. Keep secrets out of frontend bundles and records; never read private .env into model context.

Current settled corrections — 5

settled:paragraph-5

- QA loads doctrine/method, traces this BRD to actual hosted desktop/mobile visual and interaction cases, inspects pixels with browser/Vision, repairs and rechecks. No local Windows application tests/builds/servers/loopback; use hosted Vercel builds. No new daemon/schedule or model/global-auth changes.

100-recipe library

journeys:100-recipe-library

At least 100 complete distinct engine-produced recipes in this site's static artifact, with stable IDs and source/output lineage. The same reviewed dataset can be copied into each repository. Category/search/filter and collection results link to actual recipes; empty/reset/back work. Count real recipes, not duplicate cards/routes or placeholders.

Editorial learning

journeys:editorial-learning

Articles and ingredient/technique/resource pages contain useful coherent content and links to the applicable recipes and back. Technique/help returns to the exact originating cooking step without losing work. Retain provenance and rights; no empty navigation stubs.

Guest cooking

journeys:guest-cooking

Browse, read ingredients/equipment, follow steps, use supported servings/units/help/timers, then print/share/return. Scaling does not invent culinary rules or proportionally scale time/temperature. Checked steps/timer end do not prove safety.

Demo login/logout

journeys:demo-login-logout

Same the authorized verification inbox and newly generated mock-only password across all five. Correct/incorrect login, logout, expired/missing local demo state and return to intended recipe/book/campaign work. The public demo is not secure authentication and never validates company credentials.

My Recipe Book

journeys:my-recipe-book

Save/unsave, list/open, create/rename/remove collections, move/organize saved recipes and reopen supported notes/progress in browser-local storage. Explain device-only persistence concisely. Handle first-use empty book, duplicate save, storage denial/corrupt state and removal without deleting source recipes. Login return retains a pending save once; logout handling is explicit and does not falsely imply server deletion.

Sharing/printing

journeys:sharing-printing

Real browser clipboard/share/print where supported, with cancellation/denial paths and useful fallbacks. Public URLs never include local notes, credentials or email data. Printed quantities/units agree with the selected supported screen state; return preserves context.

Campaign/signup/email/return

journeys:campaign-signup-email-return

Reach a real static campaign landing, explicitly request its signup email, obtain an honest receipt state, open the delivered designed email and follow its button back to that exact site's campaign landing. Useful landing content survives fresh browser or local logout. Signup does not silently create a production account or enroll marketing.

Engine output → static consumer acceptance — 1

engine:paragraph-1

The producer is the existing Recipe engine under its actual owner and agreed common-intake method; the consumer is this site's hard-coded dataset. The owner handoff must name the admitted method/input revisions, invocation/receipt, output edition/hash, actual recipe IDs/count, content/rights disposition, qualified reviewer and allowed mockup use. Include supporting article/ingredient/technique/resource relationships and asset provenance; do not imply those records are engine-authored without evidence. Reject missing/duplicate IDs, incomplete ingredient/step/yield records, unsupported qualifications and broken references. Copy the reviewed dataset into each repo independently; no shared remote content runtime or database. Intermediate wireframes may use clearly identified placeholders but cannot pass the 100-recipe finish. Recipe/Editorial/Software review remains separate from a static manifest/count check.

Bounded real mail contract — 1

mail:paragraph-1

The actual existing mail-service owner supplies the authorized Gateway path/caller, existing approved provider, sender/template, exact recipient restriction, campaign identity and return binding. Do not invent endpoint names or deploy a new provider. Server-side enforcement fixes the allowed recipient to the authorized verification inbox; reject other recipients and caller-supplied sender/template/URL overrides. Restrict return destinations to the five approved hosts and their actual static campaign routes; preserve the originating host/path/campaign. No arbitrary redirect or credential-bearing return URL. Demo login is not authorization to operate the service.

Bounded real mail contract — 2

mail:paragraph-2

Keep provider secrets out of frontend code, static data, logs and URLs. Use owner-enforced bounded send/rate/deduplication controls so a public caller cannot turn the named-recipient route into spam. Record the exact existing control and its configured bound rather than inventing a policy value. Reuse request identity on retry; reconcile unknown delivery before another send. Handle refused, failed, pending and delivered outcomes honestly: queue/provider acceptance is not inbox delivery. The permitted verification is one named the project owner recipient, not bulk/public-recipient mail testing. Existing service-side receipts are allowed; no new mockup database is introduced to satisfy this flow.

Original 100 / COLL-01, J22

full-coverage:original-100-coll-01-j22

Select 100 retained ingredient sets; existing writer produces full English original recipe and companion records using established pattern; Content reviews/refines through correct owner loop.

Batch binds retained source identities, method/run/output/review/export. No 35-item slice, duplicate member, handmade recipe or invented qualification fills the count.

Classification / COLL-03–05/09, HOME-01

full-coverage:classification-coll-03-05-09-home-01

One primary canonical recipe URL, many ordered collections/category memberships, evidence-backed tags/filters, “Also in” and related browsing. Category membership never duplicates a recipe. Category page exists for its first included recipe; ad-hoc filter state is not a second canonical recipe.

Batch supplies actual memberships/primary category/evidence, builders render one registry across home/hubs/detail. Test multi-category recipe, filters, zero result, back and canonical consistency.

Full vocabulary / r2 working set

full-coverage:full-vocabulary-r2-working-set

Use the nine groups and exact vocabulary below. Provide meaningful coverage for relevant meal/dish/ingredient/method/effort/cuisine/occasion/style; diet only with evidence. Named collections and seasonal placements are distinct from ad-hoc filters.

Batch/Content disposition all relevant terms against the 100 retained inputs; do not create unsupported tags, certifications or empty “complete” categories. Latest explicit holiday, potluck, comfort-food and breakfast coverage must be represented in the input/selection map.

Home and features / HOME-01

full-coverage:home-and-features-home-01

Distinct actual featured recipe for home and every major section/category, suitable context and image; categories share registry. Occasion windows/order from existing accepted records, ordinary collections remain reachable.

Per-site placement→recipe ID/revision→category/occasion→asset/alt/caption mapping. Visually inspect different dishes and accurate images; no generic dish identity or universal repeated hero.

Identity/discovery / COLL-02/03/06/08

full-coverage:identity-discovery-coll-02-03-06-08

Canonical primary-category/item route, correct breadcrumbs, title/description and factual Recipe/CollectionPage/ItemList/BreadcrumbList data; useful crawlable HTML. Wrong/moved addresses give honest not-found, no fake home success.

Inspect metadata/HTML/routes and stable back/return. Preserve study noindex while retaining correct metadata; no production SEO/indexing claim. Current owner types now include primaryCategoryId, tagIds and tags; bind real reviewed values, never guess primary from array order.

Complete recipe / public parts 1–5,10–17

full-coverage:complete-recipe-public-parts-1-5-10-17

Identity/tradition wording without unsupported authenticity; description; yield/prep/cook/total; exact dish hero; 2–5 practice techniques; fixed versus judgment; supported quantities/units; grouped ingredient check-off; equipment by yield; before-you-cook article; full ordered step cards with primary required actions, cues, why/recovery, seasoning and safe parallel cues.

Writer/Content provide all fields and ingredient/step references. Do not hide missing fields behind decorative cards. Inspect full recipe, unsupported quantity, units and image fallback. Companion material uses reviewed source, not missing-data invention.

Familiar cooking / parts 7–9,18–23

full-coverage:familiar-cooking-parts-7-9-18-23

Jump controls, keep-awake opt-in where supported, check-only timers, substitutions/job/stand-ins/step changes/not-a-swap, preferences with supported changes, variations, “Make it the best”, “My best”, “Why it's the best”, “Best for [place or situation]”, local made-state and correction/parent-version meaning.

Demonstrate supported local state and return; fixed safety endpoints cannot be edited. No invented community aggregates, public member publication or unprovided AI effect. Current CRM book shape only IDs/collection labels: Batch/Software/CRM must bind additive local My-best/preferences state rather than silently omit feature or overload credentials/book shape.

Book and account / ITEM-01, current CRM

full-coverage:book-and-account-item-01-current-crm

Guest value first; disposable demo login/logout, same-origin intended-action return, device-local book save/organize/reopen/remove. Local personal versions remain truthful, never secure company accounts or cloud sync.

Correct/incorrect login, refresh, denied/corrupt storage, duplicate save, collection edits, logout/clear behavior; data does not cross origins.

Libraries/articles / LIB-01

full-coverage:libraries-articles-lib-01

Ingredient identity/forms/prep/choose/store/jobs/allergen evidence with references; technique what/why/cues/recovery/fixed/judgment/tips; the culinary collaborator’s applicable teaching retained; full related articles/resources and bidirectional recipe links. Ingredient reference pages remain distinct from main-ingredient collections; reserve ingredient/technique routes.

Reviewed companion records and actual bindings; no empty stubs. Inspect recipe→help/reference→same cooking step return. Safety claims and public/private evidence boundaries preserved.

Full print / CARD-01, PAGE-01

full-coverage:full-print-card-01-page-01

Chosen supported servings/units, full ingredients/equipment/instructions, primary safety, substitutions, practice/fixed guidance, check-at table and canonical return. Complete text preset remains; illustrated card needs its required matched ingredient/hero/every-step assets, tips/fixes and QR, never a partial card called complete.

Hosted print preview/PDF, text and illustrated applicable states, page breaks, no clipped content, image correspondence, cancel/return. No local application execution.

Signup/campaign/email / SIGNUP-01, CRM

full-coverage:signup-campaign-email-signup-01-crm

Promised useful item on screen immediately; existing bounded real mail to the project owner; exact campaign return without login wall; duplicate request still offers useful item without duplicate send. Brand is Is the Best Recipe throughout message.

Record actual request/receipt/inbox timestamps against BRD's 60-second welcome criterion; do not claim timing without measurement. Preserve fixed-recipient finite attempt ceiling and uncertainty reconciliation. Designed email/landing source branding needs CRM/Frontend update, not only documentation.

Other public parts / 24,26–30

full-coverage:other-public-parts-24-26-30

Ordinary related recipes and publication facts remain. Ads stay off. Assistant invitation/WebMCP requirements retained in coverage with exact available capability/refusal, no invented live assistant integration. Part27 transformers/cross-family integrations excluded by latest instruction.

No fake AI/counters/awards/earned badges. Record any unsupported non-transformer feature as a concrete owner gap, not silently dropped scope. Production staff CRUD, public community publishing and real identity remain outside this static demo's effect grant.

English/brand/QA supersession

full-coverage:english-brand-qa-supersession

English-only; five distinct own visual styles, same exact public name/logo; no competitor/mockup naming on public site/email identity. QA explicitly loads doctrine/method, traces this map, reviews pixels and interactions on hosted phone/desktop, repairs and rechecks.

Candidate/ref/source versions, actual visual evidence and case disposition. Concise truthful demo-control notices remain. No local builds/tests/servers.

Classification vocabulary carried from the BRD-linked r2 working set — 1

vocabulary:paragraph-1

These are the existing vocabulary entries, not new research, newly minted production categories or permission to assert unsupported claims. Main-category eligible groups are meal, dish-type, main-ingredient and method; remaining groups are changing tags/filters. Comfort-food remains a style collection, not an inferred address migration. One recipe can occur in many without being counted twice.

Classification vocabulary carried from the BRD-linked r2 working set — 2

vocabulary:paragraph-2

Named combinations in the retained source: weeknight-chicken, one-pot-pasta, sheet-pan-vegetarian, camping-one-pot. Ingredient pages and ingredient collections do not merge. Do not use “healthy” as a generic evidence-free tag; r2 deliberately uses light-and-fresh. Diet claims/certifications require actual evidence.

Classification vocabulary carried from the BRD-linked r2 working set — 3

vocabulary:paragraph-3

Occasion placement rules retained from BRD-HOME-01: en-US America/New_York calendar days, inclusive annual windows; Game Day September 1–February 15, Halloween October 1–31, Holiday table November 1–January 1 (thanksgiving/christmas/hanukkah). Active placement order Halloween → Holiday table → Game Day. Other named occasions retain their actual applicable record/date rules; no invented dates. Collections may remain browsable outside promotional placement windows. No localization work follows.

A. Meal

vocabulary:a-meal

When do you eat it?

breakfast · brunch · lunch · dinner · appetizers · snacks · sides · desserts · drinks

recipeCategory

B. Dish type

vocabulary:b-dish-type

What kind of dish is it?

soups · stews-and-chili · salads · sandwiches · tacos · pasta · noodles · rice-dishes · grain-bowls · casseroles · curries · stir-fries · pizza · breads · cakes · cookies · pies · sauces · dips

recipeCategory

C. Main ingredient

vocabulary:c-main-ingredient

What is it made from?

chicken · beef · pork · lamb · turkey · fish · shrimp · eggs · beans-and-lentils · tofu · vegetables · potatoes · mushrooms · cheese · fruit · chocolate

keywords

D. Method and equipment

vocabulary:d-method-and-equipment

How is it cooked?

one-pot · sheet-pan · skillet · slow-cooker · instant-pot · air-fryer · grill · smoker · dutch-oven · cast-iron · no-cook · baked · campfire

cookingMethod

E. Quick and easy

vocabulary:e-quick-and-easy

How much time and effort?

15-minute · 30-minute · 5-ingredient · 7-ingredient · make-ahead · freezer-friendly · batch-cooking · weeknight · beginner

totalTime (computed)

F. Diet

vocabulary:f-diet

Who can eat it?

vegetarian · vegan · gluten-free · dairy-free · egg-free · nut-free · low-carb · high-protein · kosher · halal

suitableForDiet (evidence required)

G. Cuisine

vocabulary:g-cuisine

Where is it from? It is grouped by region.

Americas: american · southern · cajun-and-creole · tex-mex · mexican · caribbean · brazilian; Europe: italian · french · spanish · greek · german · polish · british-and-irish; Middle East and Africa: middle-eastern · north-african · west-african; Asia: indian · chinese · japanese · korean · thai · vietnamese · filipino

recipeCuisine

H. Occasion and season

vocabulary:h-occasion-and-season

What is it for?

game-day · thanksgiving · christmas · hanukkah · passover · easter · ramadan-and-eid · diwali · lunar-new-year · fourth-of-july · halloween · valentines-day · birthday · potluck · picnic · camping · date-night · feeding-a-crowd · cooking-for-two · spring · summer · fall · winter

keywords

I. Style

vocabulary:i-style

What mood is it?

comfort-food · budget · family-friendly · copycat · leftovers · lunchbox · light-and-fresh

keywords

Consumer schema and handoff consequence — 1

companions:paragraph-1

Batch's v1 static corpus is an existing baseline, not permission to truncate this BRD. Current types include categoryIds/collectionIds, primaryCategoryId, tagIds and grouped tags. Featured-placement and detailed recipe-companion coverage still require their exact owner bindings. Batch/Software must publish the smallest additive typed projection or exact existing companion-file binding for those obligations, retaining stable owner identities and full reviewed data. Solutions specifies the meaning here, not an invented runtime schema. Builders can continue rendering/interaction work while that finite mapping is returned. Visual can prepare slots once selected ingredient/recipe IDs and facts exist; prose completion is not required to assign correct dish imagery. Content review and refinement remain through the actual writer owner.

October 6 the project owner correction — controlling public identity and content requirements — 1

identity:paragraph-1

This amendment supersedes conflicting language below in its named scope. Public brand on all five sites is Is the Best Recipe, with an original creative logo bearing that name and each site's independent visual style. Competitor names and design references remain internal. Remove public Mock, Recipe Mock N, design-study, mockup or competitor-copy identity from page titles, metadata, logo/navigation/footer, campaigns and email. Do not inherit the current Network brand system. Keep concise truthful demo-account, device-storage and actual send limitations beside relevant controls; no development banners or prototype footer identity.

Content finish:

identity:paragraph-2

Content finish: retain all 100 ingredient sets, not 35. The existing Recipe writer must produce complete original instructions and required companion fields using the established Recipe method; Content reviews/refines through the proper owner loop. English only. No translation/localization or transformer/cross-family integration requirement gates these sites. Preserve no-database, reviewed static intake, demo login and requested real-email scope.

Classification and featured dishes:

identity:paragraph-3

Classification and featured dishes: cover the full existing Recipe BRD vocabulary and accepted coverage, including multi-category membership, tags and collections such as holidays, potlucks, comfort food and breakfast; this list is not exhaustive. Assign a different actual recipe/dish to the homepage and each major section/category. Each feature must bind its recipe ID, exact title, corresponding permitted dish image and correct local detail destination. Generic editorial images may support a separately identified editorial story; they cannot stand in as an exact featured dish or repeat as the universal hero. Earlier Visual v2 hero assignments remain interim composition references until suitable dish-bound replacements are admitted. Do not invent a dish-image match.

Rendered acceptance:

identity:paragraph-4

Rendered acceptance: trace actual BRD requirements to page, state, hosted candidate and observed phone/desktop evidence. Inspect pixels and interactions using browser/Vision, return finite defects to the builder, and inspect the corrected hosted deployment. Source review or a planned checklist does not prove acceptance. No local Windows app build/test/server. Unavailable corpus or mail remains incomplete while layout review proceeds. Do not consume the limited real-email attempts during visual inspection; Delivery owns those verification sends.

Selected composition — 1

composition:paragraph-1

- Visual composition: near-black #111111, white, muted green #5F9F87 and very light sage #F3F7F4; elegant serif display/body with small sans utility labels. Own-brand oversized masthead, black rules, horizontal categories, wide photo with white right-inset story card. Phone moves the inset story into normal flow under the photograph. Catalog is an airy editorial grid; category/article pages have strong ruled headings and long-form rhythm with direct recipe access. My Recipe Book uses personal collection shelves and readable local notes; account actions remain modest. Campaign resembles an editorial seasonal collection, not a marketing dashboard. Print offers explicit image/notes choices without hiding required recipe text; cancellation restores the same recipe position.

Static content intake.

experience:paragraph-1

Static content intake. The assigned Recipe/Software owner supplies one reviewed export from the existing engine/common-intake path: at least 100 distinct recipe identities with complete title/description/yield, amounts, equipment, ordered instructions/cues, applicable qualified guidance, categories/collection relations, exact edition and allowed public media/resource references. Keep engine-run/input/output/review custody in internal evidence, not the public bundle. Count unique admitted recipe IDs, not translations, duplicate routes, cards or quantities. All 100 must be discoverable and open complete detail pages. Static index and browser-local state suffice; no database. Handwritten page text may describe UI but may not replace engine recipe output. An absent export is the precise content gate: named owner must return permitted caller/run path, exact export/review receipt and remaining decision, not an indefinite “engine not ready.”

Route/screen coverage proposal inside each isolated site.

experience:paragraph-2

Route/screen coverage proposal inside each isolated site. / home; /recipes searchable all-recipes catalog; /categories/[slug]; /collections/[slug]; /recipes/[slug] complete detail; /articles/[slug]; /ingredients/[slug]; /techniques/[slug]; /resources typed library; /my-recipe-book; /login; /campaigns/[slug]; recipe print mode or /recipes/[slug]/print. These are mockup-local route proposals, not new production canonical-address decisions. Every navigation reference resolves locally and consistently. Invalid slugs show a useful not-found page with catalog return. Article/ingredient/technique text comes from suitable reviewed static resources; a heading/excerpt alone is not a complete destination.

Catalog and collections.

experience:paragraph-3

Catalog and collections. Display genuine dataset-derived categories and counts; query title, ingredients and supplied tags without inventing diet/safety claims. Combine category and text filters; clear independently or reset all. Preserve filters, query and result-page context in navigable public URL state. Use pagination or explicit Load more with accurate remaining counts; every item remains reachable without an arbitrary card cap. Collection pages explain their actual selection and link to all members. No fictional popularity ranking, review count or “new today” timestamps. Saved state is a local affordance separate from public classification.

Articles and resources.

experience:paragraph-4

Articles and resources. Home and recipe related-content placements name the destination type. A full article offers direct links to the exact recipe/ingredient/technique it explains. A technique gives complete usable guidance, relevant cues and source-supported boundaries; ingredient pages distinguish identity, sold form and prep state. Open support in a page or accessible panel according to selected composition, with a clear return to the initiating recipe and step. Back restores reading context. No copied publisher article or stock credential claim. Missing resource references are removed or marked unavailable, not dead links.

My Recipe Book.

experience:paragraph-5

My Recipe Book. Local per-origin browser state contains saved recipe IDs/editions, named collections, optional notes and last supported cooking position. Empty state offers Browse recipes; save offers immediate feedback with undo. Create/rename/delete a collection; add/remove recipe membership without deleting the recipe or other collection memberships. Confirm only destructive loss of user-authored notes or a whole local book. Organize works by buttons/selectors, not drag only. Search within the book; reopening shows the exact static edition. Export/import of the local book, if offered, validates IDs and reports unavailable entries without overwriting good work. Storage denial becomes session-only state with clear action-level feedback. No cross-device claim.

Demo login.

experience:paragraph-6

Demo login. Login panel displays the named demo email and accepts the newly generated shared mock-only password through the implementation's explicitly non-secure demo mechanism. Provide show/hide password, correct labels, keyboard submit, invalid message and return-to-initiating-item. Do not use external account registration or obtain real passwords. Logged-in navigation opens My Recipe Book; logout ends the demo session and returns to a useful public page, preserving the explicitly local book unless Reset demo is deliberately chosen. The demo password may be discoverable in a public static implementation; never present it as protecting private data. No provider secrets or real credentials belong in this mechanism.

Campaign → signup → email → exact landing.

experience:paragraph-7

Campaign → signup → email → exact landing. A campaign is a complete static useful landing with its own slug/title/hero, offered recipe or collection, actual contents and one relevant continuation. The signup/request control states exactly what email will deliver, with no preselected marketing consent. For verification, only the authorized verification inbox may be sent mail. Public form behavior must not allow a client-supplied alternative recipient to reach the mail service; engineering enforces the named-recipient constraint server-side. Prefer a fixed “Send this collection to the demo inbox” action rather than soliciting arbitrary addresses that cannot be honored.

October 6 full-site expansion — controlling amendment — 8

experience:paragraph-8

On submit show pending while the actual service request is pending. On acknowledged send say the service accepted the request; only an observed mailbox receipt proves delivery. Show a safe failure with retry only after known failure; unknown outcome preserves the request and reconciles before repeating. Repeated taps reuse the same operation identity while pending. Rate-limit/cooldown and expiry wording must reflect the actual agreed service policy; UI/UX supplies no invented limits. No endless spinner, fake sent toast or automatic resubmission after reload.

October 6 full-site expansion — controlling amendment — 9

experience:paragraph-9

The email design uses own brand, clear subject tied to the named campaign, one-sentence reminder of the requested value, suitable food image with text alternative, and a primary Open [collection/campaign title] button. Its destination is the exact isolated host plus /campaigns/[slug], with only allowed public campaign context. A plain-text fallback includes the same full URL and useful description. Do not route to generic home, login wall, another mockup, production Recipe or a URL containing email/password/private book payload. The returned landing reproduces the promised selection; it remains useful signed out. If sign-in is later chosen, preserve the campaign and pending local save intention. An email link GET never sends another email, changes consent or marks an item cooked.

Cooking and print.

experience:paragraph-10

Cooking and print. All recipe steps remain readable without entering guided mode. Guided mode retains current step/ingredient marks and supports exit/re-entry. Only supplied quantity/unit outputs are selectable; full screen and print update together. Print supports complete recipe, applicable imagery and text-focused variant; record actual output page count rather than promising two pages. A browser timer is clearly local, starts only deliberately, handles pause/reset/visibility and never verifies doneness. Restored timers do not silently restart. Share uses the exact mockup recipe/campaign URL and a preview, no private notes by default.

Full-site finish.

experience:paragraph-11

Full-site finish. Every site has at least 100 engine-produced reviewed recipes plus real related article/resource destinations; all categories/collections/index/detail/book/login/cook/share/print/campaign journeys operate at their stated scope. Verify the real named-recipient email and exact landing return through the existing mail path, independently of static UI acceptance. All visible links/actions have meaningful outcomes and recovery. Hosted Vision review is phone first then desktop, against selected original pixels; exercise actual navigation and print, correct finite defects and inspect the replacement deployment. Source docs, scaffold READY and home availability cannot close this finish.

Menu/search/category

interaction:menu-search-category

Menu opens; query and selected category produce actual fixture results/count; card opens its own detail

Empty state offers clear/reset. Escape/backdrop close preserves input and returns focus. Back restores query/filter, scroll and selected item where supported

Ingredient and method

interaction:ingredient-and-method

Toggle/untoggle exact ingredient IDs; open complete help; choose previous/next/full method

Reset only ingredient marks, not recipe or entire session. Help close returns to its step; first/last steps have honest boundaries. Source text stays complete

Portions/units

interaction:portions-units

Select explicit supplied fixture output; update all relevant ingredient/equipment text and print selection

Unsupported sets unavailable with reason; never infer culinary rules or present fake network loading. Returning to base restores exact values

Save/cookbook

interaction:save-cookbook

Save/unsave local item; named collection lists correct items and opens them

Label at action “Saved on this device.” Handle unavailable/quota/malformed storage with session-only fallback. Refresh persistence only claimed where observed

Share

interaction:share

Preview recipe/title and actual isolated URL; native share where supported or copy link

Cancel returns; clipboard failure offers selectable URL. No invitation or email success claim

Cook mode/timer

interaction:cook-mode-timer

Full step, ingredients and reversible controls; a timer only for a supplied demonstration duration

Pause/reset explicit; expiry says timer ended, never food safe/done. Background behavior and restored state reported accurately. No external alert promise

Local gathering/checklist

interaction:local-gathering-checklist

Select real fixture ingredients → preview named list → add once → check/remove → return to origin

Simulation remains local; no purchase, calendar, poll or guest send. Duplicate action doesn't duplicate list rows. Preserve recipe state

Personal note/version

interaction:personal-note-version

Enter local text, preview/save, reopen/remove

Local-only scope at action; no publication or culinary approval. Don't allow safety facts to be silently replaced. Unsaved transition warns only when work would actually be lost

Print

interaction:print

Preview complete recipe and selected supplied quantities; print or cancel

Header/buttons/private marks removed, required text complete; return retains working state; meaningful alternative if print unavailable

Complete isolated interaction contract for every chosen direction — 1

interaction:paragraph-1

Every visible control needs rest/hover/focus/pressed/selected/open/disabled state where relevant, with equivalent touch use. Dialogs have accessible names and contained focus; close returns focus. Errors are adjacent and announced. No fake ratings/counters, stock-photo claims, external sends, telemetry or account effects. Reference commercial framing may be adapted to the useful Recipe action without hiding the design-study nature.

Acceptance observations to collect — 1

acceptance:paragraph-1

1. First-front-page receipt: exact repository/commit/deployment/domain; phone 320 and 390, desktop 1440; original reference and candidate side by side. Check real above-fold hierarchy, hero focal point, typography, navigation and lower content/footer, not only colors.

Acceptance observations to collect — 2

acceptance:paragraph-2

2. Phone before desktop: no document overflow, clipped text, overlay obstruction or essential hover-only controls; usable touch targets, keyboard focus, zoom, reduced motion and native reading. Reference defects are corrected, not imitated.

Acceptance observations to collect — 3

acceptance:paragraph-3

3. Exercise full browse → recipe → cook/help → save/reopen → share/print → Back loop, including empty search, reset, storage refusal and canceled actions. Distinguish local simulation from owner-backed behavior.

Acceptance observations to collect — 4

acceptance:paragraph-4

4. Actual print preview/PDF on hosted source: all steps and ingredients, selected supplied amounts, no blank/chrome-only pages or clipped rows; correct isolated return URL; color and monochrome readable.

Acceptance observations to collect — 5

acceptance:paragraph-5

5. Independent UI/UX and technical review record actual evidence/failures separately from the project owner selection. A successful build alone is not design/interaction acceptance. First-front-page finish does not close full-prototype finish.

Editorial integration append — supporting content edition 1 — 1

editorial-review:paragraph-1

The fragment contains only articles and resources, using the Article/Resource shapes above. Merge those arrays deterministically into the existing export after review, sort by stable IDs and preserve ordered blocks/paragraphs. Internal article-to-resource links already resolve. All records are reviewStatus: pending; no acceptance is fabricated. It contains no recipes, engine claims, private source paths or credentials.

Editorial integration append — supporting content edition 1 — 2

editorial-review:paragraph-2

Next gate is competent nonauthor English review plus Recipe review of scoped culinary interpretations, on this exact artifact. After accepted corrections, freeze its new hash and use the reviewed bytes in each independently copied corpus. This is actual original supporting prose, not an engine recipe substitute or a claim that every future design-specific resource destination is complete. No application build/test/server or mail effect occurred in producing it.

Editorial integration append — supporting content edition 1 — 3

editorial-review:paragraph-3

Resolve links to actual accepted output IDs/revisions and category memberships; never generate identities from slugs. White Bean-specific resources must not acquire an invented hundredth-recipe membership.

Editorial current-copy delta — English and Is the Best Recipe — 1

editorial-current:paragraph-1

English only. No public Mock/Recipe Mock N/competitor-copy branding; necessary demo-account/device-storage/send limits remain at their controls. No intrusive development banner, inherited Network brand requirement or Transformer/cross-family prerequisite. Implementers apply and verify the supplied copy in their owned public source; Editorial has not claimed a deployed change. Scoped ingredient/technique guides supplement but do not replace the complete BRD library records. Current engine outputs still need the actual writer-to-content review loop; none was present in shared100 at this editorial inspection.

Shared login — implement now in all five — 1

login-contract:paragraph-1

- Both values may be public in these five mock sources and shown by a “Demo login details” disclosure. This password was selected for this contract; it is not sourced from any real credential store and must never be used against real identity services.

Shared login — implement now in all five — 2

login-contract:paragraph-2

- Trim and lowercase username for this comparison; compare password exactly. Other input returns “Use the demo login shown here.” Never transmit password or retain typed passwords. No real signup, identity verification, password reset, grant or private-content protection results from this login.

Shared login — implement now in all five — 3

login-contract:paragraph-3

- A successful comparison sets per-origin sessionStorage['recipe-mock:session:v1'] to { "version": 1, "mockId": "recipe-mock-N", "demo": true }. Validate exact mockId/version when restoring; malformed values are discarded. No credentials in storage. Session lasts for the browser page session, survives refresh, and ends on logout or browser session closure subject to normal browser restore behavior. Do not promise secure expiry. No cross-domain shared session or cookie is needed: identical login works independently on all five.

Shared login — implement now in all five — 4

login-contract:paragraph-4

- If session storage fails, keep an in-memory demo session for this page and explain that a refresh ends it. Display “Demo account” by the account control. Never gate guest recipe reading/cooking on login.

Shared login — implement now in all five — 5

login-contract:paragraph-5

- My Recipe Book stores only fixture recipe IDs and user-selected local collection labels under per-origin localStorage['recipe-mock:book:v1'], with version/mockId validation. Show “Saved on this device.” Do not store email, password or mail receipts there. Storage failure returns an honest unsaved/in-memory state; no account-sync claim.

Shared login — implement now in all five — 6

login-contract:paragraph-6

- Logout removes only this mock's session key and in-memory session, clears password fields and hides account controls. It preserves device-local recipes and cooking progress; say so at logout. A separate “Clear saved recipes on this device” action removes only this mock's book key after an explicit user action. Never call storage.clear().

Shared login — implement now in all five — 7

login-contract:paragraph-7

- After login return to the exact same-origin recipe/collection/campaign route that initiated it, preserving usable local state. Accept only known mock routes/fixture IDs, never a supplied absolute return URL. Cancel returns to the initiating view. No silent jump to production or another mock.

Fixed campaign bindings — build these exact routes — 1

campaign-contract:paragraph-1

These are contract targets on Delivery's live canonical domains. The campaign pages themselves have not been verified live. Bind the target in server configuration, never from request input.

Fixed campaign bindings — build these exact routes — 2

campaign-contract:paragraph-2

Each landing is publicly branded Is the Best Recipe, uses its own assigned creative logo and visual direction, and presents its campaign recipe selection from the accepted engine/intake dataset. Internal mock identity must not become visible site branding. Its recipe links open real local fixture details; its My Recipe Book action follows the shared demo login flow. No invented recipe data or campaign claims are needed for the email. A fresh browser must reach the exact campaign without login, losing neither the campaign identity nor the route after optional login. Missing campaign returns a truthful unavailable state, never a home-page redirect masquerading as success. GET, mail scanning and page refresh create no send, enrollment, identity or save effect. Do not embed recipient, credentials, bearer tokens or tracking pixels in the link/body.

recipe-mock-5

campaign-contract:recipe-mock-5

welcome-5

https://recipe-mock-5.isthebestrecipe.com/campaigns/welcome-5

Your recipe collection from Is the Best Recipe

Signup/request interface and consent — 1

email-interface:paragraph-1

Use the signup treatment required by the visual design, with accurate action text “Email my demo link.” Explain at the action: “Verification is available only for the project owner. This sends one requested demo link; it does not subscribe you to updates or create a real account.” The public page may display the authorized address without accepting arbitrary recipient input. If a design requires an input, the server still admits only the exact allowlisted address; do not send refusal mail. Never infer marketing consent from login, viewing a campaign, saving a recipe, or this requested message. No drip, reminder, acquisition, production CRM mutation or third-party tracking follows.

Signup/request interface and consent — 2

email-interface:paragraph-2

The following is the proposed mock-facing adapter contract, not a claim that an existing Gateway operation already implements it. Builders can implement presentation against these states now. Delivery binds its server side to the exact approved existing owner operation.

Signup/request interface and consent — 3

email-interface:paragraph-3

POST /api/demo-email on each mock's own canonical origin; JSON only, maximum body 1 KiB, exact Origin validation and no wildcard CORS. GET refuses without effects. The deployment, not the client, binds mockId, campaignId, recipient, sender and target.

Signup/request interface and consent — 4

email-interface:paragraph-4

Reject extra fields, incorrect content type/version/purpose, or false/missing confirmation. Never accept client recipient, From, Reply-To, HTML, subject, callback/return URL, provider credentials, reset flags or idempotency overrides. Same-origin validation is defense in depth, not user authentication; the public demo password/session provides no mail authority. Mail is separately authorized by the project owner bounded verification instruction and Delivery's private server-side enablement.

Signup/request interface and consent — 5

email-interface:paragraph-5

Every response is Cache-Control: no-store with a stable enum and opaque non-secret receipt where available. Never return provider payloads, credentials, raw recipient/suppression diagnostics or claim inbox delivery from transport acceptance.

Signup/request interface and consent — 6

email-interface:paragraph-6

Example accepted response: { "version": 1, "status": "accepted", "receiptId": "opaque-owner-receipt" }. Duplicate returns the prior logical receipt. If status is unknown after provider handoff, return pending where possible and reconcile with the owner; a network error in the browser is not proof of failure and must not cause a new effect. No background retries or additional status route are required by this contract.

202

email-interface:202-accepted

accepted

“Your demo link was accepted for sending. Check your inbox.”

200

email-interface:200-already-accepted

already_accepted

“This demo link was already requested. Check your inbox.” No second send.

202

email-interface:202-pending

pending

“Your request is being checked. Please do not submit again.” No automatic POST retry.

400

email-interface:400-invalid-request

invalid_request

“The request could not be submitted.” Preserve page context.

403

email-interface:403-not-available

not_available

“Email verification is not available for this request.” No effect.

429

email-interface:429-limit-reached

limit_reached

“This demo's verification limit has been reached.” No countdown implying automatic reset.

503

email-interface:503-unavailable

unavailable

“Email is temporarily unavailable. Your demo session is unchanged.” No simulated success.

Mail owner enforcement and finite verification budget — 1

email-budget:paragraph-1

1. Recipient is server-fixed the authorized verification inbox, no CC/BCC, aliases, plus-address substitutions, additional recipients or client-controlled headers. Check the existing owner's current applicable suppression/permission immediately before dispatch. Suppressed/unknown permission is no-send, with restricted reason retained by owner. This requested verification is not newsletter consent.

Mail owner enforcement and finite verification budget — 2

email-budget:paragraph-2

2. Private server enablement defaults off until Delivery binds the appropriate approved operation and landing routes. Public source contains no provider secret or enable/reset privilege. Only Delivery manages server environment/credentials; frontend variables and static bundles never contain them. Local .env stays ignored and excluded from artifacts/context.

Mail owner enforcement and finite verification budget — 3

email-budget:paragraph-3

3. Contract verification ceiling: one provider dispatch attempt per mock and recipient for this review round; five attempts total across all five, with at most one in flight overall. There is no time-based reset or autonomous resend. Transport-unknown counts as consumed until reconciled. Cap the attempt before external handoff, not after a success response. This finite ceiling limits effects even if a public visitor triggers the exposed control during the enabled window; it is not proof that the visitor is the project owner.

Mail owner enforcement and finite verification budget — 4

email-budget:paragraph-4

4. Use the existing mail owner's durable atomic claim/receipt facility across deployments and all five mocks. The logical request identity is fixed by the owner. Bind canonical payload hash (template revision, target, recipient, sender, purpose) to it. Same key/same payload replays status; changed payload conflicts and refuses. New browser UUID, clearing storage, redeploying or altering client input must never reset the limit. Do not add a mock database or rely on browser state/server memory for effect safety.

Mail owner enforcement and finite verification budget — 5

email-budget:paragraph-5

5. Immediately disable the window when complete. Retries after a proven pre-handoff failure require Delivery reconciliation within the same logical request and retained ceiling; no hidden fresh-key bypass. Any additional verification round needs its explicit scope recorded through PO.

Mail owner enforcement and finite verification budget — 6

email-budget:paragraph-6

6. If the existing owner cannot enforce the fixed recipient, suppression, durable claim and shared ceiling, retain unavailable for the real effect and return that exact missing capability through PO. Do not expose a generic mail relay as an interim implementation. Builder work on login, campaign pages and states continues independently.

Email logo binding — October 6, revision 3 — 1

email-logo:paragraph-1

PO reports each site's original Is the Best Recipe wordmark at public/images/visual-brand-wordmark-v1-preview.png, with SVG available for the web. Email uses the PNG fallback below, not SVG. These are exact contract bindings derived from that supplied path; publication, actual pixel suitability and mail-client rendering remain Delivery/QA verification, not proof established by this document.

Email logo binding — October 6, revision 3 — 2

email-logo:paragraph-2

Bind LOGO_PNG_URL from the same internal site row as TARGET. Never fetch another site's logo, construct this from client input or replace it with the Network/competitor brand. Delivery verifies each deployed PNG is public HTTPS, returns image/png, shows the correct original wordmark, has no numbered/mock branding, and is legible at the chosen email width. Inspect actual aspect ratio and transparency against that site's email background; preserve proportions, do not stretch or crop. Use the PNG only when these suitability checks pass. Delivery owns image publication and sending.

Email logo binding — October 6, revision 3 — 3

email-logo:paragraph-3

The HTML below keeps a visible text wordmark in addition to descriptive alt text. This deliberately remains readable when remote images are blocked, return an error, are stripped by a mail client, or load slowly. No SVG, JavaScript/onerror handler, CSS background image or external font is required for brand identification. If the PNG is unsuitable/unavailable before send, omit the image element and retain the same visible text wordmark, body and exact campaign button. Do not substitute a generic logo or report an image load failure as a send failure. Plain text mail already retains the brand. QA checks images-enabled, images-blocked and unavailable-image rendering; no additional verification email or resend is authorized by this asset correction.

recipe-mock-5

email-logo:recipe-mock-5

https://recipe-mock-5.isthebestrecipe.com/images/visual-brand-wordmark-v1-preview.png

Designed email — template recipe-mock-welcome-v3 — 1

email-design:paragraph-1

Use English HTML plus text alternatives and the public subject from the table. The template below defines public wording and semantic structure; each site applies its own creative Is the Best Recipe logo, typography, color, spacing and campaign dish composition. A single inherited Network skin or five identical email designs does not satisfy the brief. Preserve accessibility, email-client readability, one exact fixed campaign destination, and the concise footer. From/display-name authorization and Reply-To remain Delivery's approved bindings; the visible brand name does not authorize a new sender identity.

Designed email — template recipe-mock-welcome-v3 — 2

email-design:paragraph-2

Before rendering, bind TARGET from the exact campaign table and FEATURED_DISH_TITLE from that campaign's actual accepted recipe record. Record its recipe ID/content revision, approved matching image/alt text and the site's design revision in the internal campaign manifest; no invented title, dish claim or generic-image substitution. The selected dish must actually appear on the linked landing and open its matching recipe. Use the accepted classification memberships for campaign grouping. No recipe selection is asserted in this contract because Content's accepted output has not been supplied here. Builders bind that output through the owner loop, not by fabricating a sample recipe.

Designed email — template recipe-mock-welcome-v3 — 3

email-design:paragraph-3

HTML-escape text substitutions. Logo/image URLs and style tokens come only from each site's vetted static asset/design manifest, never the request body. If adding a dish image, use the approved actual-dish asset with accurate alt text and a responsive email-safe presentation; the message must remain useful when images are blocked. Do not ship unresolved placeholders. The neutral colors below illustrate a readable structure only; each site's final email must match its actual independent design.

Designed email — template recipe-mock-welcome-v3 — 4

email-design:paragraph-4

Use the site's own PNG logo binding above with the exact alt text Is the Best Recipe, and retain the visible text wordmark as the reliable image-failure fallback. No “Mock”, numbered site label or competitor-copy claim belongs in logo, subject, preheader, title, heading, button or message body. Canonical hostnames remain exactly as routed; they are not display names.

Designed email — template recipe-mock-welcome-v3 — 5

email-design:paragraph-5

Changing to this template revision does not create a fresh send authorization or reset an existing idempotency receipt/verification ceiling. If a prior payload has already been claimed, Delivery reconciles that receipt and records the content revision; do not bypass a payload conflict with a new key.