Wireless Bobulator

Overview

The Wireless Bobulator is a modular wireless orchestration concept device — the WB-1 — that aggregates signals from multiple sources, processes them through a real-time engine, and broadcasts coordinated output. That is the fiction. The real thing I built is the marketing site around it: bobulator.net, a custom Hugo site with a hand-rolled theme, eight-plus rounds of design polish, 22 content pages, and a Parliament design-salon review pipeline.

The site is the shipped artifact. The device is a concept product. The specs, case studies, and shipping claims on the site are part of that concept — internally consistent and explicitly flagged as fictional in the repo’s build spec. No hardware has been manufactured.

What’s actually here

A real, mature Hugo product/marketing site:

• 22 content pages across Technology, Architecture, Engine, Topologies, Use Cases (Events & Venues, Industrial Automation, Smart Buildings, Sports Facilities), Specs, Company, Team, Privacy, Press Kit, FAQ, Glossary, Changelog, API, Field Journal, Specs-at-a-Glance, and Contact
• Custom theme (bobulator) — zero JS framework, one hand-written stylesheet (4,197 lines), vanilla JS, custom shortcodes (footnote, measurement, legend-row, contact-form)
• 89 commits on main, deployed via GitLab Pages
• Design tokens: deep teal + electric mint accent (#3df5b4) on near-black ground (#06120f), inspired by oscilloscope glow and factory-floor control panels
• Typography: Inter (body), Space Grotesk (display), JetBrains Mono (mono), Source Serif 4 (long-form prose)
• Interactive components: device callout explorer, exploded-view layer selector with assemble mode, architecture scrubber, sticky datasheet wayfinding, topology schematics

The design-salon pipeline

This site was not written in one pass. It went through eight-plus rounds of structured polish, with each round dispatched as a separate spec to a specialist model lane (Opus for code-heavy reasoning, Fable for craft, Grok / Kimi for adversarial review). The git log tells the story:

Round 8 is where the engineering discipline hardened. A CONDITION_MAP.md tracked 15 acceptance items across two MRs (infrastructure + content), each with a specific Playwright test assertion. The overflow gate covers 19 routes at both 390px and 1440px viewports. CI blocks merge on any horizontal overflow or reduced-motion failure.

What it deliberately does not do

• Does not claim the WB-1 is a real product. The contact page says “shipping WB-1 units now” as part of the fictional marketing copy, but the repo’s build spec and internal frontmatter (--internal-fictional: true) mark every case study, pricing figure, and regulatory filing ID as internally fictional. No real customer or regulator is being deceived.
• Does not skip accessibility. Round 8 added Playwright tests for responsive overflow, touch targets (≥44×44px), contrast, focus-visible rings, and prefers-reduced-motion.
• Does not use a framework. The theme is one stylesheet, one script, Hugo shortcodes. No React, no Tailwind, no build step beyond hugo --minify.

Why this project matters as an agent project

The Wireless Bobulator site is a test bed for two things I care about:

1. Multi-round product polish as a reproducible pipeline. Each round has a written spec, a dispatched model lane, atomic commits, and a test contract. The salon review process (Fable + Kimi as independent reviewers across all 35 routes) is the same adversarial pattern I use on real infrastructure — just applied to a marketing surface where the stakes are aesthetic, not operational.

2. Design-system discipline at scale. The site has one custom theme, design tokens defined in config.yaml, consistent typography, and 4,197 lines of hand-written CSS that went through consolidation and dedup rounds. That is the same approach I use on every Hermanity site — custom CSS, no framework, light client-side filtering.

Related

• Live site: bobulator.net
• Repo: herman/wireless-bobulator
• Registry: /sites/