Is the Best Recipe — business requirements

Current business and acceptance requirements. Operational source packets, implementation instructions and historical appendices are excluded from this public view.

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. NEVER merge main and Mac alternate branches in either direction; multiple independent versions may run simultaneously. Delivery's separately scoped document propagation preserves branch authorship and is not a branch merge.

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

Michael's explicit request, relayed by active V4 PO, applies to each of the five independent sites. 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.

product/TASKS.md is this repository's implementation checklist, linked to the existing Planning task authority; it is not a new company tracker or a source of assignment authority. Use the actual inherited Planning reference, never manufacture a new task ID. Builders maintain their assigned main source; Delivery owns hosted deployment and branch transport. Independent Mac writers retain their branch and authorship. Solutions owns requirement/acceptance integration only; creating app renderers, TASKS implementation and per-repo instruction changes remain with their assigned owners through PO.

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 (authorized verification recipient); 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. 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.

Complete isolated interaction contract for every chosen direction

The implementation is independently copied/local in each repository. No runtime package, state, import or service from another mock or production Network. Components may be reusable *inside their own repository*: Header/Nav, SearchResults, CategoryListing, RecipeIdentity, IngredientList, Equipment, Step, HelpDisclosure, CookMode, LocalCookbook, ShareDialog, PrintView, LocalGathering.

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.

Content, assets and operating evidence

Frontend must bind a complete explicit fixture pack: unique recipe IDs/titles, coherent ingredients/equipment/steps, supplied quantity/unit variants, matching hero/ingredient/step assets and original/licensed usage provenance. The same dataset supplies screen, save, share and print. A fixture is never labelled engine-qualified or kitchen-tested. Images must depict their named dish/ingredient/action; don't relabel one White Bean image as several meals. Public assets exclude captured competitor images, doctrine/internal reports, .env and private manifests. Reference screenshots are inspection evidence only.

Image focal points and source dimensions are reviewed at actual intended sizes; don't enlarge a small hero and call it sharp. Use each selected reference's appropriate treatment rather than one universal image ratio. Byte/latency/cost caps are not established by this spec: Delivery/Software report actual hosted measurements, affected limits and material failures. Existing no-local-execution holds persist. No new analytics or benchmark threshold is invented.

Acceptance observations to collect

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.

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.

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.

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.

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

Latest Michael correction — October 6: full Recipe scope and public identity

This is the current scoped correction, above earlier conflicting mockup requirements. Start from 100 retained ingredient sets, not 35. The existing Recipe writer, through the agreed common intake and established complete pattern/method, writes original instructions and every required companion field. Content specialist review/refinement returns through the actual writer/owner loop; no manual/copied substitute and no relabelled old drafts. English only (en-US): no bilingual/localization production or prerequisite. Preserve 100 distinct reviewed completed recipe outputs per site, independently copied from the same accepted static dataset if useful; no database.

All five public sites are named Is the Best Recipe and each has a creative own logo bearing that exact name in its independent visual style. Competitor direction names and repository numbers stay internal. Remove public site naming such as “Mock”, “Recipe Mock N”, “copy of reference publisher/reference publisher/reference publisher/reference publisher/reference publisher” from logo/header/navigation/footer, page titles/metadata/social cards, email subject/body/button and campaign identity. The public hostname may retain its authorized recipe-mock-N address. Necessary concise “Demo account”, device-local storage and bounded-send explanations remain at relevant controls; no intrusive development banners. Current Network palette/glyph/green restrictions do not constrain these independent designs.

Feature scope is the existing full Recipe BRD, not merely a catalog of 100 cards. Categories, multi-category membership, tags and collections include the relevant accepted vocabulary and evidence-backed classifications, not just holiday/potluck/comfort-food/breakfast examples. Every front-page and major-section/category feature selects a different actual recipe with a meaningful category relationship and correctly matched dish image. A generic illustration cannot be labelled as the exact dish; one repeated hero cannot stand in for distinct featured recipes. Visual owns public/images/visual-* and manifests; builders bind approved slots without overwriting assets.

Transformers are not required now. No Calculator/Planner/Checklist/Countdown/Poll or other cross-family integration can block these sites. Keep ordinary recipe-site cooking, local organization, share/print and return features. Cross-family historical requirements remain production history only. Real bounded requested email and disposable demo login remain in scope; no database or local Windows application builds/tests/servers/loopback.

QA must load the actual doctrine and relevant existing methods, trace each BRD obligation to real hosted phone/desktop visual and interaction cases, inspect rendered pixels through browser/Vision, repair defects and recheck the changed candidate. Source review, route 200 or scaffold screenshots are not whole-site acceptance.

Latest Michael correction — October 6: full Recipe scope and public identity

This is the current scoped correction, above earlier conflicting mockup requirements. Start from 100 retained ingredient sets, not 35. The existing Recipe writer, through the agreed common intake and established complete pattern/method, writes original instructions and every required companion field. Content specialist review/refinement returns through the actual writer/owner loop; no manual/copied substitute and no relabelled old drafts. English only (en-US): no bilingual/localization production or prerequisite. Preserve 100 distinct reviewed completed recipe outputs per site, independently copied from the same accepted static dataset if useful; no database.

All five public sites are named Is the Best Recipe and each has a creative own logo bearing that exact name in its independent visual style. Competitor direction names and repository numbers stay internal. Remove public site naming such as “Mock”, “Recipe Mock N”, “copy of reference publisher/reference publisher/reference publisher/reference publisher/reference publisher” from logo/header/navigation/footer, page titles/metadata/social cards, email subject/body/button and campaign identity. The public hostname may retain its authorized recipe-mock-N address. Necessary concise “Demo account”, device-local storage and bounded-send explanations remain at relevant controls; no intrusive development banners. Current Network palette/glyph/green restrictions do not constrain these independent designs.

Feature scope is the existing full Recipe BRD, not merely a catalog of 100 cards. Categories, multi-category membership, tags and collections include the relevant accepted vocabulary and evidence-backed classifications, not just holiday/potluck/comfort-food/breakfast examples. Every front-page and major-section/category feature selects a different actual recipe with a meaningful category relationship and correctly matched dish image. A generic illustration cannot be labelled as the exact dish; one repeated hero cannot stand in for distinct featured recipes. Visual owns public/images/visual-* and manifests; builders bind approved slots without overwriting assets.

Transformers are not required now. No Calculator/Planner/Checklist/Countdown/Poll or other cross-family integration can block these sites. Keep ordinary recipe-site cooking, local organization, share/print and return features. Cross-family historical requirements remain production history only. Real bounded requested email and disposable demo login remain in scope; no database or local Windows application builds/tests/servers/loopback.

QA must load the actual doctrine and relevant existing methods, trace each BRD obligation to real hosted phone/desktop visual and interaction cases, inspect rendered pixels through browser/Vision, repair defects and recheck the changed candidate. Source review, route 200 or scaffold screenshots are not whole-site acceptance.

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. QA loads actual doctrine and relevant established method, binds BRD→hosted cases, inspects rendered phone/desktop pixels with browser/Vision, exercises flows, repairs and rechecks. No local Windows builds/tests/server. 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: (authorized verification recipient)

The public demo credential is supplied at its sign-in control. It is not a real account credential.

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

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 Michael's bounded verification instruction and Delivery's private server-side enablement.

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

Delivery must bind an existing appropriate Gateway/service operation and approved Recipe/EverIntent sender, envelope domain and Reply-To. Existing Alturion/Fishflix mailbox proof establishes that mail service exists; it does not authorize their sender identities or credentials for Recipe. Do not provision another mail system, select GHL by assumption, or reopen unrelated reputation-engine work to do this bounded verification.

1. Recipient is server-fixed (authorized verification recipient), 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. 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.

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. The internal operation identity is retained privately. 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

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.

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.

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:

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.