Chapter 1

Some projects begin with a perfectly rational need. And then there are those that begin because a dog figures out the games you buy him far too quickly.

This one definitely belongs to the second category.

Kiss is a Weimaraner. He is curious — very curious — and needs to be kept busy regularly. So naturally, we tried various dog puzzle toys: moving a piece, opening a compartment, operating a mechanism to get to a treat...

The problem isn't that he can't solve them.

The problem is that he can.

Once he has figured out the mechanism, what started as a problem to solve quickly turns into a procedure he simply repeats. So we started cheating. One trick is simply to hide the game somewhere in the house: Kiss then has to find it before he can even tackle the puzzle itself.

It works. But inevitably, after watching him do this often enough, an idea started to take shape.

What if the game itself could change?

Apparently, that's what Weimaraners are like

Before adopting Kiss, I had of course read quite a lot about Weimaraners: energetic, intelligent, curious, extremely close to their owner, observant, sometimes downright clingy... Reading some owners' accounts, you could almost imagine their dogs spending their days analysing how the house — and the humans living in it — worked.

To be perfectly honest, I took some of those stories with a grain of salt. Owners who are particularly passionate about a breed sometimes tend to credit it with every virtue imaginable. And the Weimaraner comes with a rather unusual image of its own: William Wegman's photographs probably have something to do with that. For decades, his Weimaraners have been staged in such remarkably human situations that they have helped shape the image of a dog that is almost... too human.

I found it amusing, but I also sometimes felt there was a small dose of self-congratulation behind some owners' stories.

Then Kiss arrived.

Let's just say I revised my opinion slightly.

And yet, this wasn't my first dog

Kiss isn't the first dog I've lived with. There were others before him, including a Rottweiler who shared my life for almost fourteen years. He too belonged to a breed historically selected for work, he too was very attached to me, and it was a wonderful experience. But a very different one.

Looking back, I think I could sum up the difference like this:

My Rottweiler wanted to be with me.

My Weimaraner wants to be with me, but he also seems to want to take part.

Or, if he can't take part, at least watch very closely what I'm doing. It is especially obvious when I start doing something he finds unusual: a strange object appears, I take something apart, I handle equipment that isn't part of the normal routine... He generally has to come and investigate. Not necessarily because he expects to get something, but simply because something is happening and apparently it concerns him too.

I don't know whether Kiss understands more than the dogs I've known before.

What I mostly feel is that he wants to understand more.

All of that is wonderful. Well, almost.

Put like that, it sounds rather appealing: a curious dog, attentive to what you're doing, eager to take part and constantly interested in his surroundings. In real life, it can be a little less poetic. When you're working on a lawnmower, for example, finding a Weimaraner nose practically inside the engine isn't necessarily the kind of technical assistance you were hoping for.

And of course, that curiosity isn't limited to whatever I'm doing. A delivery driver arrives with a parcel?

Mandatory inspection. It might be for him.

Guests enter the house? It seems perfectly obvious to Kiss that these humans have made the trip specifically to admire his canine majesty. They therefore deserve a proper welcome and, if possible, he should quickly become the centre of their attention.

It's funny when you know the dog. Much less so when the person in front of him isn't comfortable around dogs, or is simply afraid of them: an adult Weimaraner who decides to take a personal interest in you is still an imposing animal. So this is something we're working on too. Being curious doesn't mean you have to take part in everything, and not every human who walks through the door necessarily wants to interact with him.

On that last point, we clearly still have a few differences of opinion.

The keys

Kiss already communicates with us very effectively. Not with words, obviously, but he has developed several ways of making us understand what he wants, and one of them fascinates me in particular.

When he wants to go into the garden and the door is closed, he stands in front of it. Nothing remarkable so far. But if we don't notice him quickly enough, he rattles the keys hanging near the door, and it works remarkably well: the noise gets our attention almost instantly. If that first attempt doesn't produce the expected result quickly enough, we generally get a whine. And if, somehow, we still aren't looking at him, he rattles the keys again.

Obviously, it's impossible to know exactly what's going on in his head, so I'd rather stick to what we can observe. This behaviour seems to have acquired two functions. First, the keys have become an excellent way of making us turn our heads. But in this particular context, they also carry information that we have learned to interpret:

“I'm standing by this door and I want to go outside.”

And when the first attempt isn't enough, Kiss clearly has several ways of making his point.

Keys.

No result? Whine.

Still nothing?

Keys, round two.

Patience is definitely not his greatest quality. Except, curiously enough, when he decides that the task he's been given genuinely deserves his attention.

When he decides to work

We do dog training with Kiss twice a week. In terms of pure obedience, I don't think there's anything extraordinary to report: he obviously knows a whole range of commands, some more useful than others. And, incidentally, a dog that understands “left” and “right” is far more useful than you might think.

But the number of commands he knows isn't what interests me most. It's his attitude towards working. When he's in the mood, his level of involvement can be quite impressive: he can, for example, hold a static position while remaining completely focused on what he's being asked to do, even as other dogs play, move around or act silly nearby. It's the kind of thing that regularly catches the attention of people watching the sessions.

We also did training with our previous dogs, usually for about a year. At some point, the essentials had been learned and continuing no longer seemed particularly necessary. With Kiss, it feels different. We don't especially need him to learn more things.

But he seems to need to keep working.

He clearly loves these sessions and can put an enormous amount of effort into them... when he feels like it. So we keep going. Not so much because there are essential things he still needs to learn, but simply because it seems to be good for him.

Tiring out the legs isn't always enough

When talking about a high-energy dog, the natural first thought is physical activity. And of course, that matters. But living with Kiss has also made me aware of another dimension.

You also need to keep what's between the ears busy.

I'll stop fairly quickly when it comes to dog training, though: I have neither the training nor the authority to lecture anyone on the subject, and there are people infinitely more qualified than I am to explain how to meet a dog's needs properly. I can only describe what we observe with ours. Walks and physical activity matter, but training sessions, games, exercises and new things to learn seem to fulfil a different need. Kiss doesn't appear to need only physical exercise.

He also seems to enjoy having something to do with his brain.

A quick aside we could have used much earlier

Since I've ventured into dog-training territory anyway, I might as well mention a French-language resource I personally wish I'd known about from our very first dog: Esprit Dog.

What I particularly appreciate about their content is that it isn't simply a collection of recipes for getting a dog to sit, lie down or come when called. A lot of it is about understanding the dog actually standing in front of you. I'm obviously not claiming that everything they say is universal truth; it's simply a source of information I currently find interesting enough to recommend.

We've had several dogs and, over the years, received some advice from supposed specialists that we could happily have done without. Looking back, some mistakes could probably have been avoided with better information from the start.

But that's another story.

Unfortunately for English-speaking readers, Esprit Dog's content is mainly in French.

Genetics, environment... or a bit of both?

That leaves a question I obviously can't answer: why do these kinds of descriptions come up so often among Weimaraner owners?

Part of it probably comes from the traits the breed was selected for. But I also wonder whether there isn't some kind of feedback loop at work. A dog with lots of energy and a huge need for interaction almost inevitably forces its humans to spend a great deal of time with it. More activities, more training, more interaction — and therefore a huge number of opportunities to observe humans, their habits and the consequences of certain actions.

From there, how much comes from genetics? How much from the environment? How much simply from the dog's individual personality? This project certainly isn't meant to answer that question scientifically. But after being fairly sceptical when reading some owners' accounts before Kiss arrived, I find the question much more interesting today than I did back then.

So, what do we build for him?

Ultimately, the idea for this project grew out of all these observations. Conventional puzzle toys work, but once their mechanism has been understood, they quickly become repetitive.

So the goal wouldn't be to build a puzzle so complicated that Kiss can't solve it. That would probably be an excellent way to create frustration rather than stimulation. The idea would instead be to create something that can evolve.

At this stage, I haven't built anything yet. I'm imagining relatively simple, easily movable modules: buttons, sounds, different mechanisms, and a reward when the correct action is performed.

We could start with all the elements grouped together in one place: a sound, a corresponding action, a reward. Then gradually introduce other sounds and other actions. Later, perhaps move the modules around, change their positions, alter the associations, introduce multiple steps, or physically separate some of the elements.

In short, the aim would be not to build a game whose one solution Kiss has to learn, but a system that can regularly present him with a new problem to figure out. And perhaps, along the way, observe how he goes about it.

No idea what's going to happen

For now, that's exactly where the project stands: an idea, a few observations, a few possible mechanisms and a lot of questions. I don't yet know what electronics I'll use or what shape the modules will take. I don't even know whether Kiss will understand the concept I have in mind.

And it's entirely possible that after several hours of design, 3D printing, electronics and programming, he'll look at my magnificent prototype for three seconds before deciding that the cardboard box the parts arrived in is far more interesting. That would be a shame. But it would also be an answer.

So the first objective will be much more modest:

build something simple enough to find out what Kiss decides to do with it.

As for what comes next... we'll probably work that out with him.

Chapter 2

So let's start with a button

We had to start somewhere. In my original idea, the system would be modular: several independent elements, easy to move around and arrange differently depending on the game. The first of those elements would also be the most obvious: the interface between the system and Kiss. In other words, a button.

Not necessarily a button in the conventional sense, with a predefined shape or size. Simply a mechanism that Kiss could easily operate with a paw or his nose.

The constraints were fairly clear from the start. The device had to be simple, robust, inexpensive and reproducible. It had to work either placed on the floor or mounted on a wall, allowing different positions and interactions. Finally, the targets had to remain physically independent and easy enough to move that location itself could become part of the game.

3D printing was an almost obvious choice for the body of the device: it lets me design exactly the geometry I want, modify a part quickly and produce something robust without spending much.

At that point, I had barely looked at what was already available commercially. In hindsight, perhaps I should have started there. But not doing so had one advantage: no existing design was influencing me. I started from the problem and from what seemed like a logical way to solve it.

The button also needed a way to communicate with Kiss. Not with words — at least not directly. I wanted local visual feedback, able to indicate that an action was expected and then confirm that it had been detected. On the other hand, I quickly ruled out adding sound to every target. Multiplying sound sources around the house seemed like an excellent way to turn a dog game into cheerful chaos, not to mention the extra hardware, cost and complexity. If there was going to be sound, it would be handled elsewhere.

For the visual feedback, I had already used WS2812 LED rings in a prototype Home Assistant voice satellite. They're easy to drive and extremely flexible: colours, animations, different effects depending on the state of the game... I happened to have a 24-LED ring that suited the dimensions I had in mind. It would sit inside the button and remain visible through the translucent moving part, printed in white. That part would therefore serve three purposes at once: the surface Kiss presses, a mechanical component and a light diffuser.

The controller choice was just as quick: an ESP32-C6. It's inexpensive, more than powerful enough for what I need, highly flexible and, of course, has Wi-Fi. IP networking is territory I know rather well, so I had no reason to complicate things with another protocol.

Finally, “easy to move” didn't necessarily mean “battery-powered”. For this first version, USB power is perfectly acceptable, and a small power bank can always make a target autonomous later. It simply isn't a priority.

Three switches, three springs and a lot of plastic

The next step was turning the idea of a “big dog button” into something that actually worked.

For detecting a press, a mechanical microswitch seemed like the simplest solution: cheap, reliable and very easy to interface with an ESP32. Its drawback is its tiny actuation area. Kiss obviously wasn't going to aim for a precise point with the tip of a finger. The surface needed to work with an imprecise press, including near an edge, and still reliably detect it.

The solution that came naturally was three microswitches spaced 120° apart beneath the moving part. If at least one of the three contacts is activated, the button counts as pressed. There is no need to know which one, so the three normally open switches can simply be wired in parallel to a single ESP32 input. An off-centre press may tilt the plate slightly, but that doesn't matter: the switch in that area only needs to trigger.

The button then had to return to its original position. Springs were the obvious answer again: three detection points, three return points, so three springs, also evenly spaced. Choosing them was less obvious. I knew what I wanted — soft enough for Kiss to operate without effort, firm enough to give a positive return — but I had no precise reference point. A bit of research, some advice from an AI and a little common sense led me to a model that, fortunately, turned out to be exactly right.

One problem was still much less clearly defined in my head: how should the moving part be guided properly? I imagined a system of nested columns with the springs running through them. There had to be enough clearance for everything to slide despite 3D-printing tolerances, but not so much that the plate could wander sideways or jam at an angle. I also needed two stops: one to prevent the springs from pushing the moving part out of the housing, and another to limit its downward travel.

At that point, continuing to design all of this in my head was becoming less effective than simply drawing it. So I opened Fusion 360, and that's where the mechanism really began to take shape. CAD let me solve the guiding and end-stop questions, but also check that there was enough room for the three springs, three switches, ESP32-C6, LED ring and wiring.

The final mechanism is built around three printed parts.

The upper moving part is the button itself. Underneath it is the circular recess for the WS2812 ring, with three columns extending downward at 120° intervals. The springs simply sit, unfixed, inside three matching columns on the base. The larger-diameter columns on the moving part fit over those on the base: the two sets slide into one another while keeping the springs in place.

A static upper ring surrounds the moving part. It provides additional peripheral guidance and acts as the upper stop: the springs can push the button upward, but it cannot leave the housing.

Finally, the lower plate forms the main structure, guides the columns, supports the three microswitches and acts as the lower stop. A side opening allows the USB cable through.

Three printed parts, three springs, three switches. Not much more.

From CAD to plastic

Before even touching the electronics, I printed the whole assembly to check that the mechanics actually did what they were supposed to do. This was the point where I could test what Fusion 360 can't guarantee: the real clearances between printed parts, any snagging points, how it behaved under an off-centre press and, above all, how much force was needed to move the plate.

I installed the three springs and three microswitches, then assembled everything. And, rather surprisingly, it almost worked properly on the first try. The plate moved smoothly, returned correctly to position and the required force seemed about right.

Only one correction was needed, involving the microswitch actuation. Each switch has a small pivoting metal lever, and in this first version the plate had to travel slightly too far before producing a clean trigger. Rather than modify the CAD and reprint a large part for less than a millimetre, I added a small blob of hot glue at the contact points.

An extremely sophisticated fix. But an effective one: the travel became correct, and that extra thickness can simply be built into the geometry of the next version.

Two GPIOs are enough

Once the mechanics had been validated, the electronics were almost trivial.

A USB-C cable enters the housing and connects to a small USB-C breakout board, which powers both the ESP32-C6 and the LED ring. That breakout didn't even have a proper mount in the first CAD version: for now, it's held in place with... hot glue. It's a prototype.

The three normally open microswitches are wired in parallel between GPIO0 and ground. The input uses the ESP32's internal pull-up: as long as no switch is activated, it remains high; as soon as any one of them closes the circuit, it goes low. The WS2812 ring is driven by GPIO1, with a 330-ohm resistor in series on the data line.

And that's basically it: three detection points and 24 individually addressable LEDs, using a grand total of two GPIOs.

Firmware, one small step at a time

I had already worked with ESP-IDF on other projects, so sticking with that environment was the logical choice. Again, there was no reason to develop everything at once.

The first step was simply to configure GPIO0 and verify that actuating any of the three switches was correctly detected. Then I moved on to the LEDs: driving the ring, testing colours and light effects through the white cover.

At this point, the entire physical chain worked. You could press the plate, the ESP32 detected the switch and the device produced the expected visual feedback. Technically, the button was almost ready to face its alpha tester.

Except that, as it stood, it still didn't actually do anything useful.

The temporary server that may not stay temporary

Before going any further, I wanted to check one thing: did my original idea actually make sense?

I could build as many buttons as I liked, imagine treat dispensers and increasingly complex scenarios. None of it would matter if I was overestimating Kiss's abilities or, more prosaically, his willingness to take part in my experiments. So I needed a way to trigger a real game sequence.

In my head, this would be quick and temporary: a small Python quick & dirty server. My first idea was even to hard-code the IP addresses of both server and target, with a heartbeat so I could at least tell whether the button was still reachable.

Then, while writing down the few specifications I had, something became obvious: since a target had to contact the server regularly anyway, it cost almost nothing to let it register automatically. It only needed to know the server's address. At startup, it joins Wi-Fi, contacts the server and announces itself; the server then learns that it exists and knows how to reach it. Adding a second target will therefore require no configuration changes.

The server's role deliberately remained minimal: let the operator choose a target and send it a high-level command — essentially “Generate a game.” The sequence logic itself remained local to the target.

And then the quick & dirty started becoming a little less dirty. Vibe coding makes it possible today to produce small working applications very quickly. If a decent web interface, a registration mechanism and a few proper checks take hardly any more effort than a throwaway solution, why not? So the concept evolved on both sides, server and target, without turning into an over-engineered monster: it was possible to start with something reasonably clean and extensible.

The first complete validation finished late that night. At around 1:30 a.m., the button worked, the LEDs reacted, the target registered with the server and a sequence could be triggered from the interface. Without the main participant, everything looked perfect. But at 1:30 in the morning, even Kiss isn't particularly interested in wild experiments.

So the real test would have to wait until the next day.

So, we asked Kiss

The next day, during our late-afternoon walk, I rather proudly tell my wife that the alpha device is ready and that its main user will finally be able to test it. She laughs. To be fair, this isn't the first time I've turned up with a slightly far-fetched idea: some have worked rather well, others have mainly taught me things. So I can tell she's doubtful, not to say sceptical. And honestly, I have no idea what is going to happen either. The technical part works, but that's precisely no longer what this experiment needs to validate.

A few hours later, we've had dinner. Kiss hasn't eaten yet — we might as well stack the odds in our favour. I suggest that my wife join me for the first test, and the whole experiment is clearly still amusing her.

I start the Python server, head downstairs with a tablet and plug in the device. Boot light. Wi-Fi connection. The target registers with the server. Everything works. It's almost too good to be true.

Meanwhile, Kiss watches us with that mixture of curiosity and puzzlement he gets when we're doing something whose purpose completely escapes him. From the tablet, we trigger a first sequence to make sure everything still works. The target activates exactly as expected, and Kiss pays virtually no attention to it.

Perhaps my prediction at the start of the project — spending hours designing something my dog would look at for three seconds before moving on — wasn't so far off after all. Except that nobody has yet explained what we expect him to do.

I grab a few treats. I activate the target again, draw his attention to the light signal and press the button myself. The device displays the success signal. Treat. I repeat the process, then do it again, this time encouraging him to interact with the button himself.

At first, he hesitates. Then he tries. And very quickly, something clicks.

We activate the target. I ask him to press.

He presses it.

Success signal. Reward. We do it again, and he presses again. I already no longer need to physically show him what to do.

I'm delighted. My wife bursts out laughing, probably not quite for the same reason as during the walk.

One of the very first trials with Kiss. At this stage, he is still figuring out what we expect from him and we are guiding him a lot.

We continue for a few more minutes. Kiss is clearly getting into the game. The principle is still extremely simple — the button activates, we ask him to press it, he presses and gets his reward — but he takes part willingly and seems to have understood very quickly what we expect from him.

After five to ten minutes, we stop. Not because he's losing interest — quite the opposite. Our experience with Kiss has taught us that short sessions are generally more effective, and above all that it's better to finish on a success than keep going until the exercise becomes boring.

In my mind, this first experiment is already a real success. It obviously doesn't prove that Kiss understands the device's visual language: at this stage, he has mainly learned that when we ask him to press this new object, something interesting happens. But the first part of what I had imagined is genuinely starting to take shape.

And the next day?

At lunchtime the next day, I suggest to my wife that we try again. This time, the question is different: does Kiss remember what he learned the day before?

Short answer: yes. He picks up the principle of the game again very quickly.

I deliberately start as I did the day before, pairing the light signal with a verbal cue asking him to press. Then, gradually, I stop talking. The button activates, Kiss sees the signal, and I leave him to decide what he should do. Once again, he seems to grasp the process very quickly.

But something interesting is beginning to emerge: the signal given by the human seems able to gradually give way to the signal from the device itself. That is precisely one of the things I wanted to explore with this project.

Day 3: he no longer waits to be told to press

On the third day, I play another short session with Kiss. This time I'm alone with him and I'm not filming. A shame, because his behaviour has changed again.

I now no longer need to tell him to press. When the target activates, he sees the light signal and acts on his own.

Once or twice, he even tries something I hadn't really anticipated: while no sequence is active, he walks up to the button and tries to operate it with his paw. Is he genuinely trying to start a new game? Is he simply repeating an action he associates with a reward? What I can observe, however, is that nothing happens and he fairly quickly realises there is no point in insisting. His behaviour then changes: instead of pressing at random, he watches the button and waits for it to activate.

During this session, I launch 18 games. Only one ends with the planned 15-second timeout.

17 successes out of 18.

The number is fun, but ultimately it isn't what interests me most. Three days earlier, I had to draw his attention to the device, show him the action and ask him to press. Now, the verbal cue is no longer necessary: in the vast majority of cases, the target changing state is enough to trigger an action.

I still don't know exactly what Kiss associates with the light signal, and I'm going to avoid attributing reasoning to him that I can't verify. But the button is genuinely beginning to fulfil the role I imagined for it: becoming an interface between the system and the dog.

Something is missing

We then run another trial, this time with my wife, partly so we can film Kiss's progress. And this new session reveals a detail I hadn't really considered. My wife spots it fairly quickly: the game is missing a trigger signal to announce the start of a sequence.

Kiss now knows what to do when the target activates. That's no longer really the problem. But between activations, he watches us far more than he watches the button. During the previous session, when I was alone with him, this behaviour was much less of an issue: the context seemed to be enough and he monitored the device fairly naturally. With both of us around him, it becomes much more obvious, and Kiss seems to be waiting for something from us.

Not necessarily the command “press”, which he clearly no longer needs. More of a trigger. Something that tells him: “here we go again.”

That obviously doesn't mean he has lost interest in the target. Once a sequence is under way, he knows perfectly well what to do with it. But for now, the game is still an activity we do together: we guided him while he was learning, we launch the sequences, and we're still the ones handing out the reward. So his main focus of attention often remains... us.

From the system's point of view, it ultimately doesn't matter exactly what he is waiting for from us. The observation is enough: an exclusively visual signal isn't ideal for announcing the start of a new sequence if Kiss is looking somewhere else.

And, rather ironically, the solution was already part of the architecture — just intended for later. I didn't want to multiply sound sources across the different targets, and that still seems like the right decision. The future central unit, however, is supposed to have a speaker. It could therefore take on an additional role: announcing the start of a sequence with a clearly recognisable sound.

The sound wouldn't tell him where to act. It would simply tell him that he now needs to look for the information. The targets would remain responsible for the visual signal indicating where to act. The game flow would then become something like:

trigger → search → identify the target → act → confirmation → reward

It will obviously need to be tested. But that's already a new line in the specifications, one that appeared not in front of Fusion 360 or while writing code, but simply by watching Kiss play. And that's exactly what I hoped would happen when I said I wanted to build this system gradually with him.

Day 3. Kiss no longer needs to be told to press. But between activations, his attention often returns to us. Watching this session is what made us realise that the game was probably missing a signal announcing the start of a new sequence.

The result that really matters

There is, however, something more important than 17 successes out of 18, the disappearance of the verbal cue, or this new business with the trigger signal.

Kiss still seems to enjoy the game just as much.

And that was ultimately the biggest unknown in this entire first phase. The real question wasn't whether a Weimaraner could learn to press a glowing button. The risk was much simpler: spending hours designing, printing and programming a device that Kiss simply couldn't care less about.

So far, the opposite seems to be happening. He willingly takes part in the sessions, stays attentive to what is happening, and has even spontaneously tried to interact with the button while no game was active. A treat is obviously still an excellent source of motivation, but his willingness to participate is much easier to observe.

After this third day of testing, I take the button back upstairs to my office. I want to take a few photos to document the prototype, then take it apart to show what's inside. Kiss watches me very closely. Simple curiosity? Is he hoping we're going to play again? Or is he slightly concerned to see me walking away with what has apparently become “his” button?

One thing is certain: in three days, something has clearly changed. The very first time it lit up, this strange glowing object held practically no interest for him. A few short sessions later, he watches it, interacts with it spontaneously and seems happy to see it come out for another game. For a prototype whose first job was simply to find out whether Kiss would even want to take part, that's already a rather encouraging answer.

What's next

So I'm going to keep developing the project, gradually adding possibilities without trying to move faster than Kiss.

The mechanical prototype will certainly evolve further: the little hot-glue correction will end up in the CAD model, the USB-C breakout probably deserves a proper mount, and other details will inevitably emerge with use. But the mechanical principle is validated, and the next steps can gradually become more ambitious: add other elements, evolve the interactions, introduce that trigger signal and find out how far this can go. Always using the same method: short sessions, one difficulty at a time, observing what Kiss actually does and letting his reactions influence the next design choices.

After all, the goal is no longer simply to build a game for Kiss.

It is genuinely starting to be built with him.

As for the little Python server hastily written for these first tests, it was supposed to be temporary. It may not stay that way. The simple tool that lets a target register itself and be told to start a game already opens up far more possibilities than I originally expected. And in the meantime, it has given me a few ideas. Quite a few ideas, actually.

At the start of this project, I wondered whether Kiss would look at my magnificent prototype for three seconds before deciding that the cardboard box containing the parts was more interesting. Three days later, I'm definitely no longer quite sure which one of us this project is supposed to keep busy.

---

2026-10-02 — Chapter 1 revised and Chapter 2 added.