Business requirements

The current business requirements and honest implementation limits, generated from the maintained source document.

Accepted progress percentages and working dashboard — October 6, 2026

Latest Michael direction through PO: each canonical site provides /status.html, keeps /status working, and shows meaningful automatically derived progress from maintained product/TASKS.md. Functional demo login must lead to a working /dashboard, not merely a logged-in badge. This finite amendment extends PUB-DOC and the existing account/book/activity requirements; all original recipes, articles, no-ads and full journeys remain in scope. Existing no-database/static public demo identity and local persistence remain; this is not secure production authentication or real customer storage. Independent versions retain distinct authorship and evidence.

Common progress definitions for all five sites

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

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 Michael's final acceptance, product quality score or effort/time estimate.

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.

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.

Traceable acceptance delta

Assigned builders maintain TASKS and implement within their file ownership; Software validates contracts/metric mechanics, Delivery deploys and supplies identity, QA independently verifies real flows. Solutions defines this delta and acceptance only. PO routes all changes. New criteria begin unverified until their actual owner evidence is bound; preserve existing source/hosted facts rather than resetting unrelated progress. Do not wait for broad research or restart the complete brief.

Accepted public BRD and implementation status — October 6, 2026

These requirements apply to each independent site. Provide the actual current product/BRD.md business requirements as readable HTML at root /BRD.HTML (case exact), plus an on-site /status page derived from product/TASKS.md. A /brd.html alias is useful but does not replace the exact required path. Homepage/footer links must make both pages easy to find. This work supplements, and never replaces or pauses, the complete Recipe experience and ACT-UX requirements below.

Public documentation and status acceptance

Mandatory checklist coverage to preserve

The following is a coverage floor, not a substitute for enumerating the complete accepted BRD. Owners below identify existing responsibilities, not new dispatches; each repo checklist must bind the actual assigned actor from PO's existing assignment.

Accepted activity UX correction — October 6, 2026

The activities and evidence obligations below are accepted requirements. Particular layouts, gestures, hardware/browser mechanisms, persistence models or advanced features proposed by Claude or another reviewer remain proposed design solutions until support and evidence are verified. Do not describe an unimplemented feature as working, remove an unmet requirement by calling it optional, or invent culinary transformations. Existing no-database architecture, original engine/common-intake content, owner review, public identity and finite real-email contract remain in force.

Traceable acceptance delta

Each ACT-UX-* criterion applies separately to this repository's exact hosted candidate and supplements the complete contract below. Each result records pass/fail/not verified, source/deployment identity, dated evidence, observed result and finite next owner/action. Source amendment alone passes none of these interaction criteria.

Ownership and result handling for this delta

UI/UX owns activity-flow specifications, dated user/research evidence and supported alternatives; builders implement within their existing file assignments. Recipe/Content owners resolve culinary facts and transformations; Software owns necessary technical contracts; Delivery supplies hosted candidate identity and approved effects; assigned QA independently exercises the criteria. Solutions maintains this BRD; PO integrates returns and unresolved decisions. None of these sentences dispatches another role or grants new provider, credential, publication or local execution authority.

Mac proposals remain proposals until evaluated against these accepted outcomes and actual support. Preserve their author/date/source, chosen or rejected alternative and reason in the existing product evidence. No minimum new research programme or new tracker is required. Current acceptance remains unverified until the actual hosted proof is supplied.

Expanded complete product contract — October 6, current

This amendment supersedes earlier optional-account, unrestricted suitable-recipe-fixture and blanket no-send wording. Builders continue now against the static architecture; missing engine output or exact mail binding is an explicit owning dependency, never permission for a substitute.

Engine output → static consumer acceptance

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

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 demo 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.

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 Michael recipient, not bulk/public-recipient mail testing. Existing service-side receipts are allowed; no new mockup database is introduced to satisfy this flow.

Scope and evidence

All listed journeys are required; visual treatment and supported optional cooking variants follow UI/UX. A competitor's missing My Recipe Book or campaign flow does not erase Michael's explicit full-site requirements. Show concise contextual demo/device-only labels; keep internal implementation explanations out of ordinary user flow. This is a full interactive static prototype with one bounded real email service, not a live production account system.

Full Recipe coverage map — builders, Batch and reviewers

Classification vocabulary carried from the BRD-linked r2 working set

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.

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.

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.

Consumer schema and handoff consequence

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 Michael correction — controlling public identity and content requirements

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: 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: 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: 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. 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

• Editorial composition: forest #2D6418, soft gray #F2F2EF, black/white and modest warm accents. Centered masthead and horizontal categories, long rounded search below; bounded feature image and card-led recipe groups. No blank advertising reserve or obstructing subscribe panel. Catalog and campaign use clear category/category-count headings and useful yield/time facts only when supplied. Recipe centers the identity above a bounded image, then explicit reversible units/servings and ingredients/method. Supporting desktop rail can hold equipment and related guides; it moves into sequence on phone. Book uses collection tabs and uncluttered saved cards. Print is a compact cookable sheet with selected units prominent and optional image.

October 6 full-site expansion — controlling amendment

This amendment controls wherever the earlier interaction table says no send, optional fixture pack, unassigned reference or first-page finish. The numbered visual bindings are selected by UI/UX under the latest PO authorization; this expanded behavior applies to all five.

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. / 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. 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. 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. 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. 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. 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 demo 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.

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.

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. 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. 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.

Full-site acceptance amendment — October 6, current

The previous front-page milestone remains intermediate. The following cases are mandatory for final mockup completion, even where a competitor does not expose the same feature. No result is passed by writing this specification.

Production audit/qualification remains separate. A candidate may be publicly visible during this expressly authorized design study while its documented full-site acceptance remains open; do not report the open cases as finished. Supporting assets/components require actual rights/license, regardless of reference resemblance.

All functional results below require actual evidence; earlier scaffold receipts are not full-site verification. Record actual evidence and reviewer disposition; do not convert this criteria table into a passed checklist. Front-page readiness, complete prototype, Michael's design acceptance and production qualification are different states.

Each optional area needs explicit applicability evidence tied to the reference/brief; unsupported visible controls cannot be silently excluded. Initial front-page milestone requires applicable A/B/D/J/K/L first-page evidence and truthful incomplete-interaction status. Full prototype completion requires all applicable cases through the entire journey. Production audit and qualification are outside both claims.

Reviewer return includes the person's outcome, exact candidate and reference, phone result first, desktop result, passed/failed/not-applicable/unrun cases, concrete defects and owner, actual operations versus simulation, and next action through PO. Source preparation is not independent verification. No local application tests/builds/server/loopback are authorized by these criteria.

Latest correction acceptance additions

Verify 100 retained-input→existing-writer→complete English-output→Content review/refinement traces, not 35, manual substitutes or a bare card count. Use PRD's full Recipe coverage map and disposition every row/feature and applicable classification; no silent omissions. Verify the front page and each major section/category have different actual featured dish IDs with appropriate memberships and correctly matched imagery. Verify “Is the Best Recipe” and a creative logo with that name on every public surface, metadata, campaign and designed email; competitor/reference/mockup names stay internal. Preserve concise truthful demo notices at controls.

English only; no bilingual/localization acceptance work. Transformers/cross-family integration are explicitly not required now and cannot hold acceptance. Other unsupported familiar Recipe features are named finite gaps, not silently dropped. Independent review binds BRD→hosted cases, inspects rendered phone/desktop pixels with browser/Vision, exercises flows, repairs and rechecks. Existing noDB/demo login/bounded real mail and full-site-not-front-page finish remain.

October 6 public-brand and content correction

This revision supersedes revision 1 public subjects, email title/preheader/wordmark/headline/button/body and campaign identification. Every public site and email uses Is the Best Recipe, with that site's own creative logo and independent style. Mock IDs, template IDs and exact route bindings remain internal implementation identifiers; do not expose them as site names, navigation labels, page metadata or email branding. Competitor references stay in internal design specifications. Do not inherit Network branding or add development banners. Keep only concise truthful demo-account, device-storage and send limitations at the relevant controls.

The content source is now 100 retained ingredient sets, with complete original English instructions and required companion fields written by the existing Recipe writer using the established pattern/method and reviewed/refined by Content through the correct owner loop. No bilingual/localization work or substitute hand-authored dataset. Campaign selection must trace the full existing Recipe BRD vocabulary for categories, multi-category membership, tags and collections; examples such as holidays, potlucks, comfort food and breakfast are not exhaustive taxonomy authority. Select different actual dishes for the front page and each major section/category; do not reuse one hero everywhere or label generic art as the exact dish. Transformers and cross-family integration are not prerequisites for this scope. This CRM artifact propagates the correction to email/campaign consumers; it does not claim to perform Recipe writing or Content acceptance.

Shared login — implement now in all five

• Username: the authorized demo inbox
• Newly chosen MOCK-ONLY password: [public demo password omitted from requirements]
• 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.
• 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.
• 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.
• 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.
• 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.
• 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().
• 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

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.

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.

Signup/request interface and consent

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 Michael. 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.

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.

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.

{ "version": 1, "purpose": "requested-demo-link", "requestConfirmed": true }

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 approved limited verification scope.

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.

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.

Mail owner enforcement and finite verification budget

Requested email uses only the approved sender and delivery service. Other sender identities are not authorized, and unavailable service must not be represented as a successful send.

1. Recipient is server-fixed the authorized demo 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. 2. Requested email remains unavailable until the approved delivery service and exact landing are ready. The public interface cannot enable or reset delivery privileges. 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 Michael. 4. Use the existing mail owner's durable atomic claim/receipt facility across deployments and all five mocks. Each authorized request has one durable identity. 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. 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. 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

Email uses this site’s original Is the Best Recipe wordmark as a suitable PNG. Public availability, correct pixels, aspect ratio and actual mail-client rendering require verification; a file reference alone does not prove them.

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.

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.

Designed email — template recipe-mock-welcome-v3

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.

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.

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.

<!doctype html>
<html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Your recipe collection from Is the Best Recipe</title></head>
<body style="margin:0;padding:0;background:#f5f2e9;color:#202b25;font-family:Arial,sans-serif;">
<div style="display:none;max-height:0;overflow:hidden;">Discover {{FEATURED_DISH_TITLE}} in your requested recipe collection.</div>
<table role="presentation" width="100%" cellspacing="0" cellpadding="0"><tr><td align="center" style="padding:32px 16px;">
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" style="max-width:560px;background:#ffffff;border-radius:12px;">
<tr><td style="padding:32px;">
<img src="{{LOGO_PNG_URL}}" alt="Is the Best Recipe" width="240" style="display:block;width:240px;max-width:100%;height:auto;border:0;margin:0 0 12px;">
<p style="margin:0 0 24px;font-size:20px;">Is the Best Recipe</p>
<h1 style="margin:0 0 16px;font-size:30px;line-height:1.2;">Make room for {{FEATURED_DISH_TITLE}}.</h1>
<p style="font-size:17px;line-height:1.6;">Michael, your requested recipe collection is ready to explore. Start with {{FEATURED_DISH_TITLE}}, find something that catches your eye and follow the recipe into the kitchen.</p>
<table role="presentation" cellspacing="0" cellpadding="0"><tr><td bgcolor="#234c39" style="border-radius:6px;"><a href="{{TARGET}}" style="display:inline-block;padding:16px 24px;color:#ffffff;font-size:17px;font-weight:bold;text-decoration:none;">Explore the collection</a></td></tr></table>
<p style="margin-top:24px;font-size:14px;line-height:1.6;">If the button does not open, use this link:<br><a href="{{TARGET}}" style="color:#234c39;word-break:break-word;">Open your collection at Is the Best Recipe</a></p>
<hr style="border:0;border-top:1px solid #deded6;margin:28px 0;">
<p style="font-size:12px;line-height:1.6;color:#56615b;">You requested this one-time email. It does not subscribe you to updates or create an account.</p>
</td></tr></table></td></tr></table></body></html>

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.

Plain text alternative:

Is the Best Recipe
Make room for {{FEATURED_DISH_TITLE}}.

Michael, your requested recipe collection is ready to explore.
Start with {{FEATURED_DISH_TITLE}}, find something that catches
your eye and follow the recipe into the kitchen.

Explore the collection: {{TARGET}}

You requested this one-time email. It does not subscribe you
to updates or create an account.

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.

Consumer changes and acceptance receipt

Each site follows the same demo login, local storage and exact return rules, with its own campaign, original brand and independent visual style. English-only content, 100 complete reviewed recipes and the full classification coverage remain required. Real mail retains the existing approved service, suppression, deduplication and finite attempt limits.

Independent review must trace the full BRD into actual hosted desktop/mobile visual and interaction cases, inspect rendered pixels using browser/Vision, repair defects and recheck. Include public title/metadata/navigation/logo/email/campaign branding, real dish-to-image-to-recipe correspondence and independent per-site visual style. Required hosted evidence per mock: deployed revision; guest access; correct/incorrect demo login; refresh and logout; storage-denied honest state; device-local save/organize behavior; exact campaign route from a fresh session; one requested mail accepted with owner receipt; actual inbox arrival and button return on phone/desktop; no account/subscription claim; repeat submission causes no second dispatch. Check recipient/URL/payload tamper refusal and suppression/limit refusal without sending to another address or generating extra mail. Aggregate evidence must demonstrate the five-attempt ceiling and no reset on redeploy. Provider acceptance, inbox delivery, campaign return and design acceptance are four separate results.

Return to recipes