Noodle shop multi-pot noodle timer - a single-file web timer built for wet hands, grease, and one meter of distance

You are a coding agent. Build me a single-file HTML "noodle shop
multi-pot noodle timer" - one file, opens and runs in a browser, no
network, no install, no login. I am a kitchen helper; the tool runs on
an old phone or tablet at the wok station.

Environment (derive every design decision from this):
- The user's hands are wet or in disposable gloves, often with one
  finger to spare
- The screen is read from about one meter, in range-hood noise and
  grease
- At peak, 3-4 strainers cook at once; two portions of the same noodle
  type can be in the water simultaneously

Functional requirements:
1. Noodle-type quick buttons: 4-6 large buttons per screen, each
   button = one noodle type + its seconds (e.g., "Thin 45s," "Wide
   90s," "Dumplings 5m"); names, seconds, and the button set are
   editable in settings
2. One tap starts that type's countdown; the same type may run
   multiple concurrent timers - each launch spawns its own timer
   tile showing remaining seconds and a launch-sequence number (the
   helper remembers which strainer each number is)
3. Done alert, two channels: a ring at device-maximum volume (with a
   "test the ring" button on the page) + the tile flashing full-screen
   in color; the alert stops only when the tile is tapped - never
   automatically - so an unheard alert stays visible
4. Touch protection while timing: the button area greys out after
   launch (also proving timing is live); "reset all" lives in a
   corner and requires a 2-second long press, so a wet palm cannot
   wipe every timer
5. Persistence: noodle names, seconds, and layout stored in browser
   local storage - closing the page loses nothing

Page design:
- Dark background, large light text: the tile's remaining seconds is
  the largest element on screen, legible at one meter
- Buttons at least 15% of screen height, well spaced - a gloved
  finger hits one button, not three
- Works in both orientations
- No accounts, no network, no permission prompts; fully local

Acceptance tests (run these yourself before delivering; fix anything
that fails):
- Opens in an old phone browser and works fully in airplane mode
- A wet finger hits the "Thin" button on the first try
- Four concurrent timers run without interfering; each rings at its
  own zero
- The done alert is audible and visible in a room with the range
  hood running
- Accidental touches to the button area leave running timers
  untouched

Deliverable: one complete HTML file with all styles and scripts
inlined, depending on zero external resources.

Why it is written this way

Every line of this brief derives backward from "at the wok station," not forward from "a timer." Consumer kitchen timers assume home use: one dial, one countdown at a time - while a noodle shop at peak runs four concurrent timers across five noodle types at different seconds, and juggling four home timers hands back half the goal of "outsourcing memory to objects." Requirement two therefore fixes concurrent independent tiles per noodle type: that is the boundary between a noodle shop timer and a kitchen timer.

The two-channel done alert is not polish; it decides whether the tool survives. Range-hood noise, blower hum, and rush-hour shouting routinely bury a normal beep, and one overcooked pot costs a remake plus a review - miss one alert and the tool is abandoned. The mandatory full-screen flash gives "didn't hear it" a second sensory channel; the tap-to-dismiss rule prevents the alert from giving up after two seconds just when nobody was listening.

Touch protection - greyed-out buttons after launch, two-second long-press reset - comes from one specific failure imagination: a wet palm sweeping the screen while repositioning a strainer wipes all four timers, and in that moment the helper would rather have no tool than this tool. Reliability under pressure is not feature count; it is bounded loss when things go wrong. The long-press threshold is a lock on the single most destructive action.

Acceptance tests live inside the prompt rather than after delivery so the coding agent runs them before handing the file over: "airplane mode" catches external dependencies, "wet finger" catches button sizing, "audible over the range hood" catches volume strategy. Leave acceptance out of the brief and agents deliver to web defaults - desktop, quiet, mouse - which are precisely the three things this tool never has.

Variables