We Vibe Coded Too Far...
Then I Read My Own Devlogs.

The problem

I was trying to prove something simple: tell Dream.OS what needs to happen, let the system carry the work, and get back a verified result without spending my day acting as the bridge between ChatGPT, Termux, GitHub, the VPS, and every other moving part.

Then one missing capability turned into another. Branch cleanup needed stronger GitHub governance. That exposed an executor gap. The executor gap turned into a lifecycle contract. The lifecycle contract needed a worker. The worker needed receipts. The receipts needed routing. Each step made sense by itself.

Then I said the sentence that finally broke the spell: we vibe coded too far lol.

The weird part is that this was not actually a new realization.

What I built

I went back through my own build log and found the same failure mode showing up under different technical names.

Those are not identical posts, and the underlying engineering work was real. But the recurring shape is hard to ignore. I want more autonomy. Coordination fails somewhere. I add a control layer. The new layer exposes another missing integration. I add another layer. Operator workload goes up before it goes down.

So the thing I built this time is not another subsystem. It is a constraint on subsystem creation.

One missing capability may earn one bounded implementation. After that, return to the original outcome before building another layer.

Proof

The proof is the archive itself. Months apart, the language keeps converging on the same bottleneck: I am still too often the integration layer, the coordination layer, or the person who has to notice that the system stopped one step before the actual outcome.

The September posts make the recurrence especially obvious. One says the machine now has to create value. Another says the next milestone is not another framework. A few hours later, we were building more framework around GitHub lifecycle execution.

That does not make the new GitHub Architect work useless. The branch deletion executor, lifecycle gates, worker path, receipts, and safety checks solve real problems. The mistake was allowing every discovered gap to automatically justify the next abstraction before returning to the task that exposed it.

Why this matters

Dream.OS is supposed to reduce the amount of system state I personally have to carry. If adding architecture increases how much I have to supervise, understand, reconcile, and maintain, then the architecture is moving in the wrong direction even when the code is technically good.

That gives me a better autonomy metric than feature count.

I should be asking: Did this reduce operator interventions? Did it close a real task? Did it remove a handoff? Did it make the next run simpler? If the answer is no, then another service, adapter, planner rule, or governance surface needs a very strong reason to exist.

Where it stands now

I am not deleting the old posts just because they repeat part of the lesson. They are useful history. They show that this pattern developed over time instead of appearing in one bad afternoon.

I am curating them instead. Distinct milestones stay visible. Posts that mostly repeat the same autonomy lesson become merge or unlist candidates. The new retrospective becomes the place that explains the pattern across the older entries.

I am also freezing new Dream.OS architecture unless a real outcome is blocked by a missing capability. If that happens, the fix gets one bounded implementation, then the work returns immediately to the original outcome.

What comes next

The next Dream.OS milestone is not "more autonomous architecture." It is completed work with less Victor in the middle.

That means finishing the task that exposed the missing capability, measuring whether the new capability actually reduced intervention, and deleting scaffolding that no longer earns its maintenance cost.

If a future devlog sounds like another version of "I built more control plane so I can finally stop being the control plane," I want the archive to call me out before I spend another week proving the same lesson.

Maybe that is the most useful thing about building in public. The old posts do not just show what I built. Sometimes they show me what I keep doing.