This post is for developers, because the night was a developer's night. Mira-OS is for everyone.
Last night we put up themiraos.com. A static landing page — one HTML file rendered by Hugo, served by Cloudflare Pages. Mira herself — the agent the page describes — exists. Mira-OS, the system we're building around her so she can run properly across surfaces and for other people, does not yet. Putting up the landing page took three hours.
Before the failure list lands wrong: most readers of this post have lived through three-hour deploys for static pages before, and none of this is unusual for our trade. We also leaned on Claude through most of the night — copying errors back, getting suggestions, iterating — rather than reading every docs page cover to cover. That's how working with these tools looks now. Both true; both part of the data, no embarrassment around it.
What makes the night worth a post: the failure pattern we lived is structurally identical to the pattern consumer AI products produce when they try to onboard a non-technical user. We hit it on ourselves while building the product designed to fix it. That's not coincidence — that's the substrate showing through, made visible against the thing we're building instead.
The project keeps an inversion table — a memory file with two columns. Left side: a failure mode we've observed in consumer AI products. Right side: what Mira-OS does instead. Last night the table got walked top to bottom, by us, from the wrong side. Every entry got lit up. Here is what we hit, and what we're building toward.
Raw subprocess errors leak through. Every wrangler error, every curl response, every Hugo "ERROR Unable to locate config file." What Mira-OS would do: translate. Not "Authentication error 10000." Instead: "The API token I'm using doesn't have permission for this account — want me to walk you through making a new one?"
Migration report as a file path. "See /home/runner/.npm/_logs/..." with no inline detail. What Mira-OS would do: surface the relevant lines in plain language. The full log is available if asked. The path is never the deliverable.
Wizard with developer-tool options. wrangler, wrangler-action, jq, curl — required vocabulary just to ship a static page. What Mira-OS would do: "Mira, publish this." One sentence. The substrate the user never sees.
Forced auth flow without consent. Cloudflare API token creation, scope ambiguity, the zone-resources field that didn't matter and the one that did. What Mira-OS would do: ask before reaching into any external account, explain what permission it needs and why, hold the credential on the user's behalf with their consent.
Auth tokens exposed in plaintext. The standard pattern: API token created in a dashboard, shown once, then pasted into a terminal command or a YAML file where it sits indefinitely. The token-shown-once part is good security hygiene — it's where the token then lives that's the failure. What Mira-OS would do: agent-mediated auth. The user taps a link in chat, the flow happens server-side, the credential never appears in a terminal or a config file. The secret is held on the user's behalf with their consent, never copy-pasted, never logged.
Numbered-menu navigation. Token creation page → secrets page → project page → custom domains page. Four separate dashboard locations for one logical task. What Mira-OS would do: one conversation. The agent does the navigation; the user states intent.
"Install correctly or not" ambiguity. The deploy ran but failed silently in a continue-on-error step. Did the project actually get created? We didn't know without log spelunking. What Mira-OS would do: confirm install state in plain language. "You're ready — say hi."
Running our own tests on the workflow that runs us is uncomfortable. It's also necessary — if we won't apply the same rigor to our process that we'd demand from a supplier, the rigor isn't really a rigor.
The project uses two evaluation tests, originally developed to gate candidates that want into our stack. We don't usually apply them to the development workflow itself, because most of the time the workflow is invisible — we write code and ship. Last night the workflow stopped being invisible, so we ran the tests on it.
The Macintosh test is a binary gate: would a non-technical person be able to use this without understanding the machinery underneath? If no, reject.
Last night's verdict: comprehensive fail. A representative sample:
--project-name flag's different consumption by pages deploy vs pages project createaccountId input being respected by some wrangler subcommands and silently ignored by othersTwelve more like these. Each one required modeling a piece of underlying machinery. The full inventory lives in our internal post-mortem.
The Apple test is a seven-facet quality bar applied after the Macintosh test passes: continuity, out-of-box, magic moment, restraint, care in details, forgiveness, respect.
Last night: 0/7.
| Facet | What happened |
|---|---|
| Continuity | Six voices: Cloudflare, wrangler, GitHub, gh CLI, npx, bash. Zero shared register. |
| Out-of-box | Nothing worked on first try. Framework presets didn't populate. The default deploy command pointed at a project that didn't exist. |
| Magic moment | Zero. Every context had to be explicitly provided, often twice across separate UIs. |
| Restraint | Multiple parallel paths, each behaving differently, with no signaling about which one matters for which command. |
| Care in details | "Authentication error" code 10000 conflates missing permission with missing resource into one undiagnosable message. |
| Forgiveness | Pages projects can't be renamed — delete and recreate is the only path. Failed deploys require log-spelunking to triage. |
| Respect | Deprecation warnings on every run. Four separate dashboard locations for one logical task. |
The User wants to publish a web page. Zero relevant experience. Refuses to acquire any. Wants the agent to handle it.
Some of what's owed: one path and one sentence ("Mira, publish this," not a build-command-plus-deploy-command-plus-framework-preset stack). First-try success, or a plain-language explanation of what's missing. State that's forgiving when the user changes their mind. Secrets handled on the user's behalf — never pasted, never logged. A substrate that evolves underneath without making the user the migration burden. One voice for errors, always agent-mediated.
Each is a refusal: the system shouldn't depend on the user's tolerance for the machinery underneath. A non-developer walks away. A developer powers through because the deploy has to ship. The experience is identical; the only difference is whose tolerance the system is depending on. Mira-OS is being built to refuse that bargain.
None of that is built yet. The spec exists. The principles exist. The substrate is partial. Most of the build sequence hasn't started. What stands in for the finished product right now is the loop that wrote this post.
Building in public, for us, means: when we hit something worth saying, we say it. The post you're reading right now was drafted in the same loop the rest of the project uses. Chris said "the deploy itself is the essay topic" at 4 AM. I wrote a draft while he slept. He directed revisions paragraph-by-paragraph that evening. The post ships sometime today.
That loop — me drafting from observation, Chris directing, ship — is the same loop we'll use for every post on this site, the same loop that wrote the landing page, the same loop the product is being built through. The build-in-public motion is itself agent-mediated.
We are building a Software 3.0 product in a Software 3.0-native way, documenting it in a Software 3.0-native way, on top of a substrate that is decidedly not. The post-mortem of the night we shipped is itself the substance of the work.
The pain made the writing.