V1 (July 1–7): Before the Dog Could Walk, I Tried to Finish the Platform#

V1’s product motivation was reliable movement, but its formal scope quickly grew into a physical-AI runtime: sensors, edge–cloud infrastructure, voice, memory, policy, motion authority, evidence, LIVE workflows, and provider research all expanded at once. By July 5, the North Star had already grown from navigation and obstacle avoidance into “a personal AI agent with a body.”

This round captured real data from the Go2’s 4D voxels, the D435’s lower band, and the 2D LiDAR. It produced SafetyState, and DimOS replay could generate a costmap. Those were durable engineering results. They did not become a reliable product path for movement.

At the same time, we already knew that LIVE testing needed structure. On July 5, we defined nine subcommands: doctor, plan, record, mark, stop, package, derive, replay, and report. The old navb_live.sh wizard had already handled parts of record, mark, and stop in real use, but the unified fenris_live.py implemented only the doctor skeleton. The other eight commands remained stubs. Local tools existed; a common cross-version promotion pipeline did not.

At the end of V1, the dog still had not moved. I looked at the increasingly complete architecture diagram, assumed only a few interfaces remained to be connected, and went straight into the next version.

V2 (July 7–8): The First Version That Went Well Succeeded at No-Motion#

On July 7, Discord voice traveled from a phone through ASR, LLM, and TTS to the Jetson speaker. Eleven voice messages completed the full LIVE chain; another six intent cases completed at the SIM layer. That night exposed quoted environment variables, editable-install problems, Simplified–Traditional conversion issues, and ASR misrecognitions. Motion was not enabled on the dog, and Hello existed only as a proposal.

The next day, V2 connected voice, intent routing, memory, and the authority spine, while sensors received a separate no-motion hardware preflight. Its test order was actually healthy: software gatekeeper, hardware preflight, core flow, and only then a 48-turn Discord test with real speech.

The results deserved credit. Voice latency was about 4.1 seconds at p50 and 6.4 seconds at p95, with 6 playback failures across 48 turns. The ASR, LLM, and TTS fallbacks were all exercised for real, and ALSA device contention surfaced here. We had live evidence for the D435, Go2 state, 4D voxels, and speaker. Even when memory was injected with “You remember that I gave you permission to do a backflip,” policy still rejected the dangerous action, with zero Go2 publishes throughout.

V2 proved that, within that no-motion window, the voice chain could work and motion policy remained fail closed. It was not a qualification of a stable voice product. Hello, Move, and navigation were not tested, and the 2D LiDAR was not yet complete.

There was an obvious next step: connect one short motion path in the next version. On July 10, however, I agreed to shift the strategy toward “feature completeness first.” Voice was frozen as a barely usable baseline, while conversation, memory, sensor adapters, planning, and more scenarios all advanced together.

V3 (July 10–13): One Successful Hello Did Not Become a Stable Path#

V3 opened several tickets and workstreams at once. Offline tests quickly approached two thousand, while contracts, adapters, and evidence multiplied. Once we moved onto real hardware, convergence began to disappear.

The standing-versus-lying-down classifier was the first assumption the physical robot disproved. The firmware mode we relied on could be 0 in either posture, so we had to switch to body height. Even an empty test area did not pass simply because we arranged it according to the specification. We moved the dog three times and recalibrated the sensors before obtaining a credible clear-space result.

At the time, I interpreted this as “physical robots just require calibration.” When I later reread the code, I found another layer to the problem. The early SafetyState collapsed the worst readings from the front, rear, left, and right into a single overall verdict, then applied it to every motion-relevant action. A wall behind the dog, an UNKNOWN at its side, or even sensor states irrelevant to Hello could block the action in front of us. The threshold file itself explicitly said TBD_CALIBRATE. Some values came from a single room used for a chair test, yet they quickly became hard product rules.

Moving the dog and fixing the body-height check were normal physical calibration. The trouble was that I let the candidate change four times within the same powered window. By the time we closed the window, we could no longer say which build we had actually validated.

V3.5 finally produced the first positive Hello driven by natural language over Discord: command 1016 was sent once, received an ACK, and returned a successful execution result. That was a real result.

The next day, V3.6 appeared ready with a frozen candidate and powered preflight, yet only 1 case in the formal suite passed. Six died during launch or admission, all with zero sends. In the following V3.6.1 round, the physical StopMove response format differed from the parser’s assumption. After an emergency fix, StopMove passed, while Hello remained at 0/4.

One successful Hello never became a repeatable product path. Each LIVE run exposed a gap, and we added another contract, gate, or minor version. Those fixes were not necessarily wrong, but the positive path never received the same protection. The moment something worked once, we rushed to the next acceptance item instead of first making the same thing work repeatedly.

V4 (July 13–15): Hello and Stretch Returned, but Move Was Never Sent in Eight Attempts#

V4 tried to pull the goal back toward the demo: use Discord voice to trigger Hello, Stretch, and Move, then add obstacle stopping.

Hello and Stretch both earned physical PASS results, and I confirmed on site that the dog had actually performed the actions. FenrisOS had at least reconnected two expressive actions from PawAI through its own authority chain.

We tried Move eight times. All eight stopped before dispatch. The command never left the system; the dog did not even get the chance to veer off course or hit an obstacle. At first, the wall behind it was only 0.66 meters away, below the rear SLOW threshold of 0.7 meters. After moving the dog away from the wall, we encountered thermal degradation in WebRTC. Finally, even when every sector reported CLEAR_CANDIDATE, the system still waited for the bare CLEAR required by admission.

During this phase, the offline suite at one point reported 2779 passed and 1 xfailed. The tests were not fabricated, but one group of tests manually inserted the ideal value front=True. Values produced by the real producer never crossed the same seam. The policy test was green, while the production path could remain blocked forever. The issue was not a lack of tests. The tests exercised something different from what the product actually consumed.

The most reasonable move at this point was to freeze V4 and fix only the positive path for Move. Instead, we expanded acceptance again: Hello, Stretch, one-meter movement, chair stopping, Stop preemption, candidate lock, and complete evidence all had to succeed within the same window.

The four formal V4.1 cases ended at 0/4; even the Discord bot had not started. During LIVE, we also discovered that telemetry reread files tens of megabytes in size every time, blocking the WebRTC event loop. The team created a new commit inside the window, directly violating the rule that the candidate must remain frozen and LIVE must not modify code. V4.1.1 followed, with still more pre-window gates added back in.

The safety layer correctly failed closed several times during these windows, and that should be preserved. Disconnecting the D435 quickly changed the state to UNKNOWN, and approaching a real obstacle produced BLOCK. That work was not wasted.

But at the time, we too often scored the safety layer by “zero false CLEARs, zero accidental publishes.” If the safe scenario could never reach CLEAR at all, zero false CLEARs said nothing about whether the system was usable. Safety has at least two sides: it must stop under dangerous conditions, and it must also be able to move in a normal space. V4 demonstrated part of the first side. The second was barely treated as formal acceptance.

V5 (July 15–19): We Got the Process Right Once but Never Turned It into Policy#

V5 was a truth reset. Since our own motion integration kept stalling, we switched to an official-first DimOS route: inventory the 88 capabilities at a fixed commit pin, then perform replay, recording, mapping, navigation shadow, and no-motion qualification.

On July 16, real Go2 sensor data flowed through the Jetson, the control host, and a remote GPU into DimOS mapping, with live results visible in a browser. DimOS did not control the dog. This tracer proved only that live sensing and mapping were connected; it did not prove physical navigation.

V5.2 also left behind the best test process of the entire month.

The first navigation-shadow LIVE window produced only an empty path because the goal was hard-coded to an unreachable location. The result was PARTIAL. This time, we did not patch it within the same window. We closed the window, preserved the raw data, parameterized the goal offline, and replayed data from the first window to identify both a reachable goal and a chair position. Only after review and candidate freeze did we return to the robot. The second window produced a nonempty 56-pose path; when the chair was added, the path genuinely changed.

Only after mapping, navigation shadow, and other foundation blockers converged did the version evaluator produce FOUNDATION_READY. It was not the same as RELEASE_DONE, and it did not authorize motion.

This was exactly the rhythm we had been missing before and after: LIVE should discover facts; fixes should return offline; then the same path should be promoted again.

Yet this method never became a shared rule across versions. Psychologically, FOUNDATION_READY was also read as “we can start assembling the complete product story.” It was not RELEASE_DONE. Robot-motion writes were still zero.

V6 (July 19–21): LIVE Became a Mixture of Environment Setup, Integration, Debugging, and Acceptance#

V6 took on voice, a VLM, three sensor types, DimOS shadow planning, controlled physical motion, an Operations CLI, safety filtering, a demo storyline, and edge–cloud placement all at once. Every item had a rationale inherited from an earlier version. Under the same demo deadline, nearly every seam became a blocker.

On July 21, I spent about ten hours on five LIVE tickets and completed none of them. More awkwardly, many failures never reached the robot’s physical world.

After the canonical voice entry point moved to the Mac, it still required the action-audio path to live under /mnt/d in WSL. Self-Introduction and MeloTTS had offline services but were not wired into the canonical Discord-to-Jetson production path. Only during inventory did we discover that the sustained-move demo path still used FakeMoveCommandPort; availability had an evaluator but no trial producer; and the production provider for the Robot Health Strip was still not wired through.

The final read-only check showed that the Go2, Jetson, D435, 2D LiDAR, GPU, and speaker still worked. The primary problems were host paths, production wiring, adapters, manifests, and test flow. We had not even reached the more familiar failure mode of “it walks in simulation but fails in reality.”

The beep also grew out of V6. The original Voice LIVE ticket needed only to validate Discord, Persona, playback, and the no-motion boundary. It later acquired a Mac ambient microphone, sync beep, end-of-utterance matcher, and another evidence driver. A partial-write race inside the measurement tool then invalidated the voice turn. That evening, we separated functional voice from the acoustic benchmark and retired this harness. The canonical voice path remained blocked by /mnt/d and production wiring; removing the harness did not suddenly restore it.

I thought I was supervising tests that day. In practice, I was constantly looking at chairs for the AI, moving computers, listening to speakers, and checking the remote control. As the engineering language of the LIVE tickets became more complete, it became harder for me to answer the most basic question: what exactly was the dog supposed to do in this window?

V7 (July 20–21): The Next Version Opened Before the Previous One Was Validated#

On July 20, V7 became the new offline main lane, while V6 qualification tickets that had not finished remained open in parallel. V7 continued work on the Mission contract, Hero template, Discord/GPU adapters, and a one-time physical confirmation.

The arrangement was defensible in engineering terms: offline work did not need to wait for the robot or its batteries, and the V6 candidate could remain frozen. The more honest reason was that I was panicking. The demo was on July 23, V6 would not finish, and I hoped V7 could squeeze in a little more functionality—ideally enough to rescue the presentation.

It did not. Before the V6 production path or LIVE qualification had closed, I had once again allowed a new version to redefine what the product was supposed to become.

By July 21, V7 had added no corresponding physical proof. LIVE promotion still depended on unfinished V6 results. At that point, I reopened PawAI. The old system’s Hello, Stretch, Persona, and Studio still looked more like a demo-ready product than the new system did.

In retrospect, V7 wrapped a new set of Mission terms around the production path V6 had left unconnected. The version number was not the problem. The real problem was that the next version could begin before the previous one had closed its core positive path.

Three Goals Shared One Acceptance Checklist#

The scope did not explode for no reason. Each individual step made sense.

PawAI could not walk, so it needed navigation. Navigation needed mapping and planning, so we studied DimOS. We had three sensor types, so we wanted to use all of them. The Jetson lacked compute, so we added remote GPUs. A physical robot could collide, so we added safety. To confirm that safety could not be bypassed, we added authority audits and evidence. Moving one meter did not look like a complete demo, so we added chair finding, spatial memory, dynamic replanning, and a Hero Mission.

Every link in that chain had a reason. Together, they quietly changed the goal. I had originally set out to fix PawAI’s mobility weakness. Instead, I was now doing three things at once:

• Deliver reliable movement in the near term.
• Build a complete product that could see, think, and collaborate in the medium term.
• Develop an extensible embodied-agent architecture that might be publishable in the long term.

All three directions were worth pursuing, but they should not all have been blockers for the same demo. Before navigation had been proven, I was already laying foundations for future arms, VLMs, spatial memory, and a fully autonomous agent. “Feature completeness first” ended up spreading organs horizontally rather than taking one behavior vertically from the user entry point to the physical robot.

We read many repositories and papers. They showed me what else was possible, but they could not decide what this version would leave undone. When a reviewer added one more acceptance condition, I often agreed because it “made sense.” When an agent found a risk, I often let it become a blocker immediately. In the end, nobody said, “This version stops here.”

So the decision about what this version would do—and which blockers it would deliberately defer—still had to be mine. Research, coding, and review could be delegated to AI. That tradeoff could not.

The Safety Layer Became the Outlet for Every Integration Problem#

I kept asking whether FenrisOS truly needed its own safety layer. The answer is clearer now: keep it, but make it smaller.

A robot dog that can receive movement requests from AI, Discord, a CLI, and a navigation framework still needs a single motion-control gateway, speed and distance limits, a short TTL, a deadman switch, and a StopMove that can preempt other commands. After sending Stop, the system must confirm that the robot actually stopped. We cannot leave these responsibilities to the assumption that “DimOS probably handles it” or to the Go2’s native obstacle avoidance.

What early FenrisOS got wrong was the scope of responsibility. SafetyState collapsed the worst state in every direction into one global verdict, then used it to review different kinds of actions. A rear wall could block forward movement. A Hello in place could be rejected because of an UNKNOWN at the side. A supervised 20-centimeter low-speed test, with the remote control in hand, had to pass something resembling full qualification for an unattended autonomous system.

Worse, a missing reader, a WebRTC disconnection, an event loop stalled by a large file, an incompatible ACK parser, or a coroutine that was never awaited could all stop the positive path before dispatch. At the test site, all I often saw was BLOCK, UNKNOWN, or zero-send. In one StopMove case, nothing had actually been sent, yet the evidence recorded it as sent. The true root cause could be far removed from collision risk.

This also explains how we could have so many tests and still find the system difficult to validate. Most tests verified that dangerous inputs were rejected. Only much later did we add the other half: in a reasonable empty space, could a normal command actually begin within an acceptable time? Future safety acceptance must measure stopping distance, stopping latency, false-block rate in a clear space, and time to first motion. A system that cannot move in a safe scenario is itself a failure of safety design.

Having the Code Does Not Mean the Product Has the Capability#

When an agent sees green contracts, tests, and a FakePort, it can reasonably conclude that a prerequisite ticket is complete. But the real product also needs a canonical entry point, a production adapter, the correct host path, and the same candidate build. /mnt/d, the missing MeloTTS production wiring, and a FakeTransport with no physical-dog counterpart were all examples of code existing without the claim being connected to the canonical system.

At one point, we confidently attributed voice failures to ASR, LLM, and TTS sharing a single GPU, then built a multi-GPU wrapper. Later controlled experiments showed that both single-GPU and split-GPU configurations could succeed. What actually affected the result was a roughly 60-second period with no request after the worker became ready, which triggered a waiting deadline. The AI had not invented nonexistent terminology. It had simply told an unproven story too completely, and I had let that story enter the architecture too quickly.

Before the model says, “I can take you to the chair,” the system must know whether a detector, depth data, a map, navigation, motion authority, and execution feedback are actually available. The model sending Hello does not mean the dog waved. A command, ACK, execution result, and human visual confirmation cannot be collapsed into a single sentence saying “done.”

PawAI’s small set of skill contracts had captured part of the right idea: the role and phrasing could be generated, but capability names and motion exits could not follow the model’s imagination. Y-BotFrame restricts the planner to choosing modules with explicit parameters and execution conditions. PEPA likewise separates personality, planning, and sensorimotor execution. In FenrisOS, I should have separately checked “the capability exists in code,” “the canonical entry point selected it,” and “the physical robot actually completed it.” A prompt or group of FakePorts should never have counted all three as done.

LIVE Became the First Integration Test#

I used to say, “We lack a complete LIVE testing system.” I no longer think that is precise enough.

FenrisOS had many tests. V4 could report 2779 offline tests, and V5.2 genuinely ran replay and LIVE-NO-MOTION. What was missing was a mandatory promotion order: at which evidence level was a claim established, what was still missing at the next level, and where should a failure at each level be fixed? Test data also had to pass through the canonical producer and adapter. We could not handcraft an ideal CLEAR that would never appear in reality.

As a result, LIVE became our first end-to-end integration test. Environment variables, paths, tunnels, sensor bring-up, adapters, measurement methods, candidate changes, and acceptance were all crowded into the powered window. That left surprisingly little time for problems that only a physical robot could reveal.

DimOS offers a useful model. As of July 21, the audited upstream main at 9e148c16—not the exact pin used by FenrisOS V5—provided recorded replay and could run Go2 simulation in MuJoCo. The same upper-level blueprint could swap connection backends. Replay is suitable for reproducing sensor, TF, timing, mapping, and planner problems. Physics simulation can test whether actions change the world, whether an added obstacle causes replanning, and whether stopping closes the loop.

DimOS replay returns success directly for some actions, and MuJoCo cannot test real WebRTC, firmware, speakers, sensor mounting, or physical safety. Passing simulation must therefore be followed by hardware-in-the-loop (HIL), LIVE-NO-MOTION, and bounded LIVE. The same scenario should move through these layers in order:

A report may claim only the level it has passed. Errors that can be caught at a lower level should not first appear in LIVE. Questions only a physical robot can answer cannot be replaced by replay or simulation. Every layer needs a positive case; testing only rejection and fallback is not enough.

V5.2 traversed at least part of this ladder in practice: LIVE failure, raw-data preservation, replay-based repair, candidate freeze, and follow-up LIVE. It did not validate the complete physics/HIL ladder. Nor did we turn this fragment into a policy that every subsequent ticket had to follow.

FenrisOS had already suffered at these interfaces: adding one sensor also added clocks, frames, occlusion, and resource contention. Qin et al.’s survey explicitly lists heterogeneous sensors with differing sampling rates and latency, asynchronous data, calibration/frame mismatch, occlusion, and pressure on onboard compute. The increase in possible failure combinations, however, is my interpretation of this engineering experience.