Bakery equipment technician - the fault-triage wizard tool: pick the machine, pick the symptom, walk the decision tree, and generate a work order that carries the path you walked

Build me a single-file HTML fault-triage wizard for bakery
equipment. It opens directly in a browser, no network, no
dependencies, no install. The users are baking-zone store staff
and junior repair techs, in this scene: a machine is acting up,
they're standing next to it, one hand holds a flashlight, one
hand taps the screen.

Three-screen flow:
1. Pick the equipment: deck or rack oven, proofer, dough mixer,
   bread slicer, cooler or freezer
2. Pick the symptom: 2-4 common symptoms per machine (from the
   tree below)
3. Walk the triage: one question per screen with exactly three
   buttons - yes / no / can't do this step; each screen shows
   at top what's being checked and at bottom what that means in
   plain words for non-specialists ("look at whether the breaker
   has tripped")

Decision-tree content (start with these; extend structurally in
the same shape):
- Oven not heating: first step is always the safety check
  (power off before opening anything) -> after power-on, does
  the display light (lit = control circuit live, problem sits
  in the heating circuit; dark = check supply and breaker
  first) -> heating-element terminals by eye (power off) ->
  contactor click by ear -> the end branch reads: "points to
  element or contactor - open an outside-service ticket"
- Oven heating unevenly: fan running, by ear -> racks and trays
  blocking airflow -> re-measure spread across positions in one
  bake -> end branch: "points to fan or localized element aging
  - open a repair ticket"
- Proofer humidity wrong: water in the tray -> inlet valve
  making any sound -> drain flowing -> end branches split by
  path: no water + silent valve = points to inlet valve; water
  present + no drain = points to blocked drain, self-serviceable
- Mixer making noise: noise present running empty (yes =
  mechanical drive; no = load-related, check paddle-to-bowl
  clearance) -> belt tension by eye -> end branch: "points to
  belt or bearings - open a repair ticket"
- Slicer jamming: power off first -> turn the blade by hand,
  smooth or not -> blade sharpness and bread state (over-frozen
  or too-soft both jam) -> end branch: "adjust the thawing
  routine or change the blade - self-serviceable"
- Cooler not cooling: airflow and dust at the heat-exchange
  side by eye -> inner-wall ice blocking the air path (retest
  after defrost) -> end branch: "refrigeration circuit involved
  - outside service only; this tool provides no refrigerant
  steps"

Hard rules:
- Level one of every tree is always the safety step (power off /
  machine stopped, confirmed); no path continues without it
- Any branch touching gas, refrigerant, or main-circuit work
  terminates in outside service or the manufacturer - self-
  repair steps are never offered
- The "can't do this step" button exists honestly - a step the
  site genuinely can't perform may be skipped, and the work
  order records it as "not checked"

Work-order generation:
- At the end of a walk (or on early exit), generate a plain-text
  work order in one tap: equipment and store (typed in) /
  symptom / the triage path walked (each step's question, answer,
  or skip) / which branch it stopped on / preliminary reading /
  recommended action (self-serviceable or outside service)
- One-tap copy to clipboard, plain-text format, paste-ready for
  a chat window or the repair group

Technical requirements:
- The tree is a data structure in the JS (an array of objects):
  adding equipment, symptoms, or question wording touches data
  only, never logic - technicians must be able to maintain the
  tree themselves
- Single file, works offline, one-hand operable on a phone in
  portrait, large tap targets (usable with gloves on)
- localStorage keeps work-order history with a text export

Constraints (for the coding agent):
- No networking, database, accounts, or cloud sync
- No "probably the X has failed" probability talk - the tool
  outputs where the walk stopped and what that points to, and
  guesses at nothing
- No built-in brand or model library - the tree is generic by
  structure, and model details are typed into the work order by
  the user
- The interface never says "smart diagnosis" or "AI detection" -
  it is a carrier for triage steps, not a diagnostic engine

Why it is written this way

The longest waste in a repair response chain isn't the drive, it's the intake call: a store reports "the oven's not working," and the tech only learns on arrival that the display is dark rather than lit-and-cold - which is exactly one yes/no question. Freezing the veteran's phone questionnaire into a decision tree lets store staff walk the first half themselves, so the tech arrives already knowing "supply and breaker are excluded," and first-visit fix rates move on their own. One question, three buttons per screen is honest design for the scene: the user is crouched beside a machine holding a flashlight in one hand.

Safety on level one, and gas/refrigerant/mains routing straight to outside service, are the two hardest-drawn lines in this prompt. The tool saves intake time, not professional credentials - rotating blades, refrigerant circuits, and gas are the three domains where DIY accidents cost more than a day of downtime, so the boundary must be set by the prompt, not left to the user's judgment in the moment. The "can't do this step" button, counterintuitively, must exist and be honest: steps the site can't perform get skipped and recorded as skipped - a work order that pretends everything was checked is far more dangerous than one that says "not checked."

Keeping the tree in a data structure the technicians can edit is what decides whether this tool survives three months: triage orders differ slightly by oven brand, and every store has its own frequent failures. The tool isn't a product - it's each repair crew's own template, and extending it must not require a programmer. Work orders carrying the walked path exist for the same reason: whoever picks up the ticket (or the outside tech) sees what's already excluded and doesn't re-check supply and breaker - saving not one step, but one step on every single ticket.

Variables