The Erektor support portal

The operator-facing edge of the Erektor Return System: where field crews get a leg serviced, request a replacement, read the procedures and check firmware.

The idea it is built around

There is no persistent Erektor. The durable things are legs, controllers and sessions; a module is just a left-plus-right leg pairing that exists in software for one session.

• Field service is replacement, not repair. Legs share no wiring or bus, so the unit of service is the whole leg, swapped from the pool.
• Every leg comes home anyway. A fault that can wait doesn’t need a truck, just a flag on the leg’s record.
• A leg has two identities. Firmware and pairing follow the electronics serial; wear, intervals and warranty follow the stamped mechanical serial.

How the site is put together

• One table drives it. data/faults.json maps every fault code to a route (fix on the floor, flag for return inspection, or dispatch a swap), and the triage, the index and the form prefills all follow it.
• Product facts live in data, not markup. Catalog, fault table and firmware manifest are JSON the pages render at runtime.
• No deploy-time build. The assembled HTML is committed, which keeps the deploy independent of a toolchain.
• A Cloudflare Worker serves the static pages and the intake and registry APIs.