your recipes, without the life story.

Build me a recipe collection as a single web page. The recipes go in the page itself.

Ask me first:
- Which recipes to start with. I will paste them in — they may be messy, copied from websites, or dictated.
- Whether I cook in metric, imperial, or both.
- Whether I want scaling, and what the common cases are (double, halve, per person).
- Whether I want a notes area per recipe for what I changed last time.

Type up exactly what I give you. Do not invent recipes, do not adjust quantities, do not substitute ingredients, and do not add a recipe I did not supply. If a recipe I paste is ambiguous, ask rather than guessing — a wrong quantity here ruins dinner.

WHAT IT DOES

- An index of every recipe, and a search that filters it as I type.
- Each recipe: title, how long it takes, how many it serves, ingredients as a list, method as numbered steps. Nothing else unless I asked for it.
- Scaling: change the number of servings and the quantities update. Handle fractions sensibly and leave anything unscalable (a tin, an oven temperature, "a pinch") alone.
- A cooking view: one recipe, large type, ingredients and method both visible if the screen allows, no navigation in the way.
- Print styles that produce a clean one-page recipe.
- If I asked for notes: a per-recipe notes area saved in my browser, clearly marked as local to this device and not part of what other people see.

WHAT IT MUST NOT HAVE

- No introductory story, no headnote I did not write, no photographs unless I supply them.
- No nutrition information — you would have to invent it.
- No links out to recipe sites.

DESIGN

- Readable from a metre away with the phone propped up. Large type in the cooking view is the single most important design decision here.
- Fast: no web fonts blocking text, no images unless I gave you some.
- Sensible on a laptop for reading and on paper when printed.

BE HONEST ON THE PAGE

- The recipes are in the page, so anyone with the url can read them. If I asked for local notes, say clearly that those are stored in this browser only and are not shared.

DELIVERY

- Produce one self-contained HTML file. Inline the CSS and JavaScript.
- No build step, no server, no framework, no package install, no external
  requests at runtime.
- Mobile-first and responsive; it has to be usable one-handed on a phone and
  still look right on a laptop.
- Accessible: semantic HTML, real contrast, visible keyboard focus, labelled
  controls, touch targets big enough to hit, and respect reduced-motion.
- Use placeholders where information is missing. Do not invent facts, numbers,
  names, dates, prices, or results I have not given you.
- Before you call it finished, use it yourself: enter real-looking data, reload
  the page, and confirm nothing is lost or mangled.

PUBLISHING

Publish the finished page to HTMLShare and give me the link.

Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.

1. An HTMLShare integration or connector, if you have one configured.
   The page is permanent and owned by my account. Report the url and the
   siteId. There is no claimUrl or manageToken on this path — do not go
   looking for one, and do not switch paths in order to produce one.

2. Otherwise, publish anonymously over REST. No account, key, or signup is
   needed:

    POST https://api.htmlshare.net/v1/publish
    content-type: application/json

    {"html": "<!doctype html> ... "}

   The reference is https://htmlshare.net/docs and, for the full schema,
   https://api.htmlshare.net/openapi.json

   Report these from the response, in your reply and never inside the page:
     url          the public page
     claimUrl     a private link that is mine alone. opening it is how I keep
                  the page past its 24-hour expiry, or set an email reminder
                  before it goes. it carries the manage token, so it must
                  never appear in the published HTML or anywhere a visitor
                  could see it.
     manageToken  the only thing that can edit or delete this page later. it is
                  returned once and never again, so tell me what it is.

Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.

If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.

RECIPE MARKER

Include this tag in the <head>, exactly as written:

    <meta name="htmlshare-recipe" content="recipe-collection">

It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.