Hotpot restaurant equipment technician - remote repair triage tool: have a coding agent build a single-file page where the floor crew just taps answers, and you know what parts to bring before you drive over

You are a coding agent. Build me a single-file HTML "remote repair
triage" tool for a hotpot restaurant technician to judge faults
remotely; the floor staff open it in a phone browser - no network,
no installs, no external resources of any kind.

Part 1 - Core flow
1. The staffer picks the equipment type (list maintained by the
   technician: e.g., induction burner / gas burner / four-door
   cooler / freezer room / ice machine / dish machine / exhaust
   fan)
2. The tool walks the technician's pre-built question chain, one
   question per screen, exactly three buttons: yes / no / don't
   know
3. Answers end in one of three lanes, each with its display:
   Lane A [self-help first]: step-by-step instructions for
   zero-risk actions (check the outlet, reset the breaker, wait
   out a defrost cycle), max three lines per step; if it fails
   anyway, prompt to switch to lane B
   Lane B [visit needed]: the tool assembles the repair message
   - equipment name / the chain of symptoms (all the staffer's
   answers) / self-help already tried / the photo checklist the
   technician preset (e.g., "nameplate close-up," "alarm code
   display") - one tap copies it, the staffer pastes it to the
   technician in chat
   Lane C [shut down now]: safety-class symptoms (gas smell /
   tingling shock / strange noise or smoke / visible refrigerant
   leak) - show power-and-gas shutdown steps first, then the
   repair hotline (technician preset)

Part 2 - Rule structure (all maintained by the technician on a
"rules" tab; the tool ships empty)
- Question chains: one chain per device, each question with two
  branches (yes jumps where, no jumps where); "don't know"
  always takes the more conservative branch
- Three lane endpoints: A / B / C, attached to chain ends
- The maintenance UI supports adding devices, editing questions
  and branches, and assigning endpoints
- One exception: C-trigger questions (gas smell, shock, smoke
  class) jump straight to lane C from any device's chain, and
  this jump rule cannot be deleted by the technician

Part 3 - Error handling
- Chain loops (questions jumping forever without an endpoint):
  detect and reject at save time
- Orphan questions no path reaches: list them as warnings at
  save time
- The staffer's session saves nothing on exit - triage is
  one-shot, no state
- Every "don't know" branch must be set explicitly; unset
  questions fall back to "jump to the conservative lane C
  branch" at save time, flagged on the maintenance page

Part 4 - Data
- Device list, question chains, and hotline in localStorage,
  with JSON export and import for backup (switching phones
  must not lose the rules library)
- Staffer page and maintenance page are two tabs of the same
  file; the maintenance entry stays unobtrusive (staffers
  should not wander in)

Interface: the staffer path uses big buttons, big text, one
question per screen (answerable one-handed in the rush); the
maintenance page is desktop-first. Deliver one complete HTML
file with all CSS and JS inlined, plus a usage note under two
hundred words, in Chinese only.

Why it is written this way

The tool's entire value lives in "the staffer doesn't have to describe, only answer." The biggest information loss in a repair call is the open question - "what do you mean, not cooling?" asked mid-rush gets back "I mean it's not cooling." Freezing the technician's follow-ups into a yes/no chain drops the staffer's answering cost to one tap, and the information actually goes up: every question answered means the path is complete. So this is not really a "fault diagnoser" - it is the technician's experience translated into a questionnaire the staffer can finish. The diagnosis is still the technician's; the tool just guarantees the raw material arrives complete.

The chains and rules ship empty and are built entirely by the technician - same rationale as the cost-card and vocabulary tools, but harder: fault trees grow on specific equipment models. The same "burner won't light" branches completely differently on a commercial induction unit versus a gas range, and a prefilled generic tree steers the staffer toward a fault that doesn't exist. In the repair scenario the accuracy bought by maintenance cost is rigid - one wrong branch sends the technician across town with the wrong parts, and the tool's credibility resets to zero.

The three-lane order is a safety design: C-trigger questions (gas smell, shock, smoke) reach lane C directly from any chain, undeletably - that is the tool's fuse. Safety symptoms are low-probability in the distribution of equipment problems, but their costs are asymmetric: a wrong A or B lane call wastes time; a wrong C lane call bets on an accident. So "don't know" takes the conservative branch, occasional false shutdowns are accepted, and safety symptoms never queue behind diagnosis steps. This is the one place maintainability yields to safety.

The assembled repair message, copy-pasted into the crew chat, respects how restaurants actually communicate - nobody installs a ticketing system for repairs; the group chat is the ticketing system. The most valuable line in the assembled text is "self-help already tried": it answers the technician's mandatory "did you reset it?" before it's asked, and spares the staffer the same basic question on every call - both sides arrive prepared for the visit.

Variables