I didn't write OpenClaw. I didn't design the upstream speech model that Cadence uses. And I didn't spend six months building those systems from scratch before I could start on the part that I actually needed.
I cloned the repo and built what I wanted on top of it.
This isn't a framework choice or a philosophy. It's a practical way to get something built when the part that matters to you sits on top of infrastructure someone else already solved. The mechanism is straightforward — clone a repo, keep your changes additive, credit the upstream — but there are traps in it that you won't see until you've shipped something and it breaks in production.
The on-device assistant: someone else's bugs, in my stack
I built an on-device AI assistant as a plugin on top of OpenClaw, an open-source multi-channel personal-assistant gateway with an MIT license. OpenClaw handled the plumbing — desktop app, plugin loader, model interface — and I wrote the layer on top: periodic nudges for hydration and bedtime, light conversation, and read-only access to a personal notes vault for context. It was designed to run locally on my Windows machine, and it passed every security and correctness gate I threw at it.
Then I ran it.
A global configuration setting in the gateway silently stripped 13 of my assistant's tools before my own per-agent allow-list was even consulted. I only found it by reading a gateway log line. Separately, an SDK-imported function was a silent no-op end to end because the plugin loader compiled it into a separate module instance from the one the running gateway actually read. I left a code comment: "a parallel universe the real gateway never reads."
Both bugs were platform-level. Neither one was mine. And neither one appeared in the documentation.
The desktop app's login screen stuck after two rounds of fixes aimed at window focus and cached JavaScript. The real cause: a CSS rule gave the token overlay display: flex with no override to hide it, so it was painted permanently from the initial HTML parse in every build. The app was connecting successfully behind an overlay that only looked broken. Every earlier check had inspected a DOM property that read as fine instead of what pixels were actually on screen. The fix was one CSS rule.
That one was mine.
The project ran as a gated multi-phase workflow: Architecture Review → Security Review → Implementation Plan → MVP build and verification, each phase its own document with a "Status: Complete" header. At install time I ran a scripted manual gate: the plugin registered, the local model answered a probe, shell access was denied at the tool layer, and a vault escape-probe suite passed 7 of 7 checks. A protected key file refused, path-escape attempts rejected, absolute out-of-vault paths blocked, root listing hid infrastructure, and search never surfaced key material.
The project produced 5,798 lines of source code and zero automated tests. It saw four active build days across an 11-day span, then 55 days of silence. I abandoned it because it was a resource hog and had a really hard time with continuity. It was intended to give me periodic nudges to promote productivity, but it typically failed to provide value unless I was babysitting it, which defeated the purpose.
Every security check passed. What killed it was something none of those checks measured.
Cadence: a model is not a product
I'm dyslexic — the eye skips, autocorrects, and fills in what it expects to see. Proofreading by ear works around that. I asked a coding agent to get an open-source speech model running, expecting it to work out of the box.
I ended up designing all of the features I was expecting the tool to ship with, before I understood what I was actually working with.
The opening prompt was 1,105 lines and its ninth line forbade the agent from writing any code. It asked instead for a repo audit, a product spec, architecture decisions, a phased roadmap, design requirements, and a handoff prompt for a separate design agent. All six deliverables exist. The resulting design went through a 19-entry reconciliation ledger grading each feature Essential/Beneficial/Decorative, and roughly half were rejected.
Cadence is the result: a fully local, proofread-by-ear desktop app that turns a folder of Markdown files into narration that highlights each paragraph as it's read. It runs entirely on my laptop — no account, no subscription, no cloud upload. Status: shipped, to an audience of one. It has never left my machine.
The core is Electron with a Python/FastAPI sidecar. Documents parse into content-addressed blocks so highlighting, notes, change detection and audio caching all line up on the same units. When a manuscript is revised, only changed paragraphs re-render and notes follow the text that moved, flagged for review rather than silently reattached when a match is uncertain. The roadmap was built across three consecutive days in July, with two later single days adding project management and a notes export.
Before I trusted it, I attacked the riskiest component first. The diff-and-reconcile engine, the part that decides which paragraphs changed and where notes should follow, got three confirmed bugs, each fixed with a regression test, before it was declared safe to build on.
Then a Windows quirk failed silently. A hidden file attribute on an entire project folder made every chapter show as stale and refuse to regenerate. The JSON writes kept succeeding so the app looked fine while the audio never updated, and the worker couldn't log the failure either. Both are fixed.
Cadence now runs 368 backend tests — 305 test functions expanded by parametrization. It has rendered 2,995 segments across two real projects (1,869 + 1,126), zero failed. A 63,000-word manuscript produced 6.94 hours of narration in 98.2 minutes of GPU time, 1,869 segments, zero failed. All 51 of Adroit's knowledge-base documents are fully narrated, 2.51 hours of audio.
The upstream speech model itself is not named in any of that. It's described only as "an open-source speech model," and it stays that way.
The rules that came out of it
Credit the upstream. OpenClaw gets named. The speech model gets described but not named, because sensitivity rules for that project say so. Either way, the thing you started from gets acknowledged. This isn't a license requirement — both were MIT — it's just the correct way to describe what you built.
Keep your changes additive. I didn't fork OpenClaw and gut its architecture. I wrote a plugin that ran inside it. When Cadence needed a feature the upstream model didn't have, I built a layer on top instead of modifying the model's internals. Additive changes mean you can pull upstream fixes, and you're not maintaining a permanent fork.
Know which bugs are theirs. When the login screen stuck, I burned two rounds of fixes on window focus and cached JavaScript before I found the CSS rule. When the plugin loader silently ignored my SDK import, I didn't know whether I was calling it wrong or the gateway was broken. The vault escape probes all passed, but the global config stripped my tools before my own allow-list ran, and I only found it in a log line. You can't fix their bugs in your layer, and you can't always tell which bugs are theirs until you've shipped and it breaks.
Test the actual behavior, not the documentation. UI state claims require pixel evidence — a screenshot — not a DOM property that reads as fine. A function that looks correct in the SDK might be a no-op in the running gateway. A config setting might silently override your own. The documentation tells you what's supposed to happen. The tests tell you what actually happens.
A model is not a product. The speech model worked. It did not ship with a manuscript manager, a diff engine, note-taking, or paragraph-level caching. Those are product features, and I built them. The agent writes the code, tests and documentation; the human directs, decides, and validates. This is true whether you're building on top of someone else's repo or starting from scratch.
Starting from someone else's repo buys you time. It does not buy you a working product, and it does not absolve you of knowing what you're running. You still own the thing you ship, and you still own every bug in it — even the ones that aren't yours.
The full build pages, test counts, and all the other receipts are on the site.