Build in public: what changed in ClarkCant over the last two weeks

I promised myself I'd build ClarkCant in public, and building in public means showing the messy middle, not only the launch screenshot. So here it is: what actually changed over the last two weeks, read straight from the git history, and what is still not done.

Some context first. The repository's first commit is from 16 September 2026. As of 5 October it holds 685 commits. That sounds like a lot for under three weeks, and it is. 150 of those commits carry a co-author line for Claude, an AI coding agent, which is a bit funny given everything I complain about in my minimalism essay. I don't think that makes the number impressive on its own. Commits are not features. What matters is whether a normal person using Clark feels any of it, so that's how I'll walk through it.

One thing the numbers say honestly: there are almost as many fix commits as feat commits. A lot of these two weeks was not adding things but making things tell the truth, behave the same on Windows, or stop being drawn in the wrong place. I'm fine with that ratio. That's what finishing looks like.

The rhythm isn't steady either. The first three days of the window hold over 200 commits, then four days are almost silent, then it picks up again. Building in public means showing the quiet days too.

Clark runs work in the background, and background work has a nasty habit: it finishes, or gets stuck, while you're not looking. The inbox is the answer to two questions only. What is waiting for my decision? And how did the stuff I wasn't watching turn out?

The part I care most about is the uncertain case. When a background task runs a command against something outside your machine, a push, a message, a deletion, a payment, it is now written into a ledger before it starts. If the command is cut off or times out, we don't pretend it worked and we don't quietly run it again. It becomes one inbox notice that says what is uncertain, that nothing was re-run, and that you should check the other side first. Boring. Exactly what I'd want if it were my money.

You can snooze a notice, or quiet one narrow kind of notice, and undo that later. And the inbox is not a second home screen: every item points back to its own conversation, and deciding on the inbox or on the card in the chat is the same decision.

Before, if the model you picked refused a turn, you got an error and that was that. Now Clark answers the same message on the next usable model and tells you, right under the reply, that a fallback model answered, which model you had chosen, and why it didn't. Your choice in Settings is not rewritten; the refusing model is skipped for a few minutes and then tried again. If every model refuses, the message names each one and its reason, and says your message is kept.

A smaller fix I'm weirdly proud of: after you approve a command, Clark continues with a short sentence written by the app. That sentence used to be stored as if you had typed it, so the transcript showed words in your bubble that you never wrote. It's now marked as host-written and drawn as a quiet line instead. Small thing. But a chat app that puts words in your mouth is not a chat app I'd trust.

The last commit as I write this adds slash commands that come back as command cards: /new starts a new conversation and keeps this one, /sessions lists background work and earlier conversations to reopen, /login and /logout sign in and out of AI providers inside the card, /thinking picks the thinking level, and /background runs a request beside the conversation. No settings page to hunt through. You type, or you ask, and the control appears where you already are.

The same day brought a big polish pass across 110 small commits squashed into one pull request. The ones you'll notice: a long run of working steps now folds into one line that says how many ran and how many failed, instead of twenty receipts stacked above the answer. You can choose the interface font and the code font. Markdown is marked while you type it. The desktop window reopens where you left it. And a lot of English labels in the Vietnamese interface finally speak Vietnamese.

On 2 October a set of reference apps landed: a text editor, a spreadsheet, an AI image generator, a media render tool and a map that works over an offline basemap and only fetches tiles under a policy you set. Two days later, a widget became able to declare actions it offers, and Clark can perform one for you. The spreadsheet, for example, offers to format the selection; the editor offers replace. It goes through the same gate as everything else: your execution policy, the effect ledger, and an honest answer when the widget isn't open or doesn't reply in time. That evening the same path started working when you say it out loud.

For people who want to build their own widgets, the author CLI can now pack a widget into a verified npm archive and refuses one that carries credential-shaped files. The author CLI and SDK now build as npm packages, with a release workflow that smoke-tests the exact archives first. To be clear about the three pilot apps (Quick Notes, CSV Explorer, Media Converter): they are npm-ready, not on npm yet. The publish command prints what to run; it uploads nothing by itself.

A standing request you set up in conversation can now take a labelled GitHub issue all the way to a draft pull request: work in its own worktree, run the tests, commit, push with a token the node brokers, and tell the conversation the pull request's address. If GitHub can't reach your machine, the node polls the repository instead, at most every five minutes.

Once machines can start work, you need to know which turn came from you and which didn't. Every turn now records who started it: you, an MCP client, the relay, the CLI, an automation or a paired machine. Approval cards and the activity log say who asked. By default nothing changes in how decisions are made, but you can opt in to being asked before a risky effect that a machine-started turn causes.

The README still says it on line one of the status section: this is a bootstrap, not a release. We keep a conformance ledger for the 18 scope items of the foundation beta. Ten are marked PASS. Eight are PARTIAL, and each one names what is missing.

The ones that matter most to a normal user: Google Calendar has never talked to Google, because there is no registered OAuth client and no Google account behind the tests; it runs end to end only against a stand-in API on the same machine. Live voice has never opened a real session, because there is no live provider account yet. Browser Use has only driven pages this repository serves, never a third-party site behind a login. Computer Use has no signed bundle and no container engine on the machine the tests ran on, so the native driver has never run. And installing a package through chat records an exact artifact but doesn't yet build its dependency tree.

I'd rather you read this here than discover it the hard way. None of these get marked done until a test proves them.

That's the two weeks. More fixes than I'd like to admit, a few things I'm genuinely happy with, and a clear list of what still needs the real world to prove it. If you want to push me on priorities, the survey below is the easiest way.