Build log · skool community share

We turned a mini PC into a self-healing AI Chief of Staff. Here's the whole build, start to finish.

We had a box and a vision, this is exactly how we executed it: the planning, the pre-staging, the failures, the catch that could've been bad, and the test that proved it works. Dotted-underlined terms have tooltips, prompts have copy buttons, and there's a plug you can pull at the end. Written so you can run the same play.

1Session to build it

3xPower-pull tests passed

0Human touches to recover

1Catch before first boot

The pattern behind every single stage below

Same loop, every decision, every build step, no exceptions. This is the operating system underneath the timeline, worth naming before the timeline itself.

Step 1

Sonnet 5 gathersRaw research, options, first-pass plan. Fast, cheap, wide.

Step 2

Toggle Fable 5Same thread, heavier model. "Think really hard about this plan. Look for blind spots."

Step 3

War-game itWhat's the one-shot failure? Map every way this breaks before touching hardware.

Step 4

Spar itSpar means arguing against your own plan on purpose, like a debate partner whose only job is to find the hole in it. Do that, fix what it finds, then spar again.

Step 5

Then, only then, buildBy the time hands touch keyboard or hardware, the surprises are already spent.

01The box, and the vision

A mini PC running Windows 11 Pro out of the box. The vision: wipe it and turn it into an always-on AI Chief of Staff that lives at an office, answers staff on Telegram, and heals itself if the power ever drops, no technician on call, no one touching a power button. And the Chief of Staff is only the first tenant: the same box will carry other valuable workloads over time, starting with an OCR pipeline for processing business documents. One quiet machine, several jobs.

Why a physical box instead of a VPS: data sovereignty. Business documents, client records, anything the OCR pipeline touches, stays on hardware the business physically owns, inside its own walls, under its own jurisdiction. That's the cleanest possible answer to privacy and compliance questions like GDPR: the data never left the building, there's no cloud provider in the chain of custody, and "where is our data?" has a one-word answer, here.

On-prem. The data never leaves the building.

The fork~~Rent a VPS, deploy in ten minutes~~ vs own physical box on-premises. The VPS loses the moment client documents enter the picture: sovereignty beats convenience.

02We didn't start from zero, and neither should you

Two things gave this build a massive head start. First, we'd already installed ClaudeClaw on a cloud VPS before, so the shape of the work was familiar: the runtime user, the service supervision, the secrets handling. Second, this community had already published a field-tested walkthrough for setting up ClaudeClaw on remote machines, complete with the gotchas the author bled for. We pulled that post into the planning context and let Claude incorporate its lessons directly into our plan.

Credit where it's fully due: none of this happens without Mark Kashef and what he teaches in this community. The frameworks, the field guide lineage, the whole way of thinking about agents as deployable, supervised, secured infrastructure instead of chat toys, that education is the foundation this entire build stands on. This post is us paying one rep back into the pool we've been drawing from.

The takeaway: before planning anything, feed your AI everything relevant you've done before plus the best community writeup you can find. Ten minutes of collecting prior art saves hours of rediscovering someone else's solved problems. The mistakes in those posts are mistakes you get to skip.

Prior VPS repsCommunity field guideThanks, Mark

03War-gaming, before the box even powers on

This is where the loop above earns its keep. Before touching the hardware: a full failure map. Seven named one-shot breakers, each with a mitigation decided in advance, not improvised mid-crisis.

The war-game protocol, steal itWe're about to [describe the build]. Before anything gets touched, run a pre-mortem war-game: 1. Enumerate every failure mode that could kill this in one shot: hardware, software, network, credentials, and human error. Include the boring ones. 2. For each: probability (high/medium/low), blast radius, and whether recovery is possible remotely or needs physical hands on the machine. 3. For each: one concrete mitigation we can execute BEFORE it happens, not a reaction plan for after. 4. Rank by probability times pain. Tell me which three to engineer out first and why. 5. Finally: which failure am I personally most likely to be underestimating? Argue it. Output as a table. Do not soften anything to be agreeable.

The seven, mapped in advance: BIOS needing a keyboard when you only have a mouse (buy a cheap USB keyboard first), a silent typo in the install config (validate it on your main machine before it ever touches the box), a dead CMOS battery silently resetting BIOS settings (test it, don't assume), an access token expiring mid-install (mint it at the moment of use, not before), a burned single-use network join key (mint it reusable, disable expiry after joining), a missing auth token at the worst possible step (pre-stage it in the password manager), and an SSD flaking under load (health-check it before trusting it with anything).

Then Fable 5, toggled on for this pass specifically, followed by a spar pass, then another.

The blind-spot escalation, run on the heavier modelSwitch to your deepest reasoning and re-examine this plan end to end. Attack it from these specific angles: 1. Which single assumption, if wrong, invalidates everything downstream of it? 2. Which steps secretly depend on a fixed order that the plan treats as order-independent? 3. What is the single point of failure nobody has named out loud yet? 4. What would a specialist in this exact domain wince at? 5. What are we still doing only because it was in the original plan, not because it's still the right call? Do not summarize the plan back to me. Report only what is wrong, missing, or fragile, ranked by damage. If you find nothing, say so and state what evidence would change your mind.

War-gamedSpar x2

04Finding the line between paranoid and unusable

Separate pass from the failure map: not "what breaks," but "how far should security go." The starting question was deliberately extreme, get the maximum on the table first, before negotiating it down.

The two-sided security protocolAdopt the mindset of a hostile, competent attacker with network access and occasional physical proximity. Target: [describe the system]. 1. Enumerate every attack surface: physical ports, network services, credentials at rest, credentials in transit, the update/supply chain, and the human operators. 2. For each surface: the realistic attack, the skill level it requires, and what the attacker gains if it lands. 3. Now design the paranoia-maximum defense, cost and convenience be damned. Every layer, no matter how annoying. 4. Then switch sides. For each defense layer, score the daily friction it adds for a non-technical operator, and flag every layer a stressed human would bypass or work around under pressure. 5. Recommend the final stack: keep every layer that costs nothing day to day, cut or redesign every layer a tired human will defeat. Justify each cut, because a cut without a reason is just laziness wearing a suit.

Then the same adversarial spar got pointed at that answer instead of the plan: does each layer of paranoia earn its keep, or is it a step that adds friction without closing a real risk. Maximum security that nobody can actually operate isn't secure, it's just unused, or worked around, which is worse. The target was never "as locked down as theoretically possible," it was the tightest setup that still gets used correctly every day without a technical person nearby.

The fork~~Every paranoia layer we could think of~~ vs only the layers that don't tax daily use. Zero inbound ports, no-sudo runtime user, and secrets-never-on-disk stayed. Extra approval steps and constant re-authentication got cut. Security a stressed human skips under pressure isn't security.

05A new repo, a Claude.md built the same way

New repo for the build. The instructions file for it wasn't hand-written: asked Claude to draft the Claude.md from the plan and constraints, then toggled Fable 5 to optimize it and do the finishing touches, sharpen the language, cut what didn't earn its place. Same two-model rhythm as the infrastructure decisions, just pointed at a document instead of a box.

The clarity-bar rewrite protocolRewrite these instructions so a much less capable model, or a tired human at 11 PM, can execute them start to finish with zero follow-up questions. Rules: 1. Every step names its exact command, file path, or setting. No step relies on unstated context. 2. Replace every "it", "this", and "there" with the actual noun. Ambiguous pronouns are how installs die. 3. Every step ends with a verification line: what you should see if it worked, and the most likely error if it didn't. 4. Any step that is destructive or irreversible gets a STOP line first: what to double-check before proceeding. 5. Then test your own output: role-play the least capable executor, walk every step literally, and flag each place where you would have to guess. Rewrite those until there is nothing left to guess.

Why that bar matters: if a step could be misread, it gets rewritten until it can't. Clarity is aimed at the weakest model that might ever have to run it, not the smartest one that wrote it. Bonus: instructions that clear are also the ones a tired human can follow at 11 PM.

Sonnet 5, draftFable 5, polish

06Pre-staging: the bot existed before the box did

The Chief of Staff's Telegram bot was created in BotFather before the build ever started, and its token and details went straight into the planning context. Same with the WiFi network the box would join. Result: when Claude prepared the install USB, it baked in everything the box would need on first boot, the WiFi configuration, the bot credentials wired into the deploy config, the whole initial setup, handled in advance on the main machine while the mini PC was still running its factory Windows.

The takeaway: the box should be the last thing you touch, not the first. Everything that can be prepared away from the hardware, accounts, tokens, configs, the install media itself, gets prepared away from the hardware. Box time then shrinks to: plug in, boot the USB, watch.

Bot pre-createdUSB pre-builtWiFi pre-configured

07Hardware check, and the one BIOS setting everything depends on

Before installing anything: health checks. SSD SMART self-test passed, stress test showed no thermal throttling. Then the single most important setting of the whole build, flipped while a monitor was still attached: "Restore on AC Power Loss" set to Power On in BIOS.

Why this setting is the whole ballgame: this box will live somewhere with brownouts and nobody technical nearby. Without it, any power blip leaves the box off until someone physically presses the button. With it, the box resurrects itself the moment power returns. Do this first, while you still have a screen plugged in.

08Goodbye Windows, hello Ubuntu Server, and the install fights back

Windows 11 Pro wiped, no dual-boot, no safety net. Ubuntu Server 24.04, checksum-verified, flashed to USB. Two real fights: the wildcard WiFi interface matcher in the install config silently failed, the fix was hardcoding the real interface name, wildcards are fragile, names are not. And Windows Fast Startup skipped USB boot detection on a cold power-on; a restart from inside Windows forced full detection.

Hardcode interface namesRestart, don't cold-boot, for USB

09The network decision: nothing comes in, the box only calls out

Administration rides Tailscale only. No port forwarding, no static IP, no firewall exceptions on whatever network this box sits on, ever. All admin, SSH and dashboard alike, travels the private tailnet. When the home router's client isolation blocked normal LAN SSH entirely, it didn't matter, the tailnet path never touches the LAN.

Every arrow leaves the box. None point at it.

The rule that makes deployment trivial: nobody at the destination office installs anything or configures anything. Staff reach the agent through ordinary Telegram. Tailscale lives only on the operator's own devices and the box. Moving the box to a new network is: plug it in.

The fork~~Expose the dashboard on the network~~ vs SSH tunnel only. The tunnel adds zero attack surface and dodges certificate headaches. Nothing listens on the office LAN, ever.

10Installing ClaudeClaw, standing on the community's shoulders

This is where the community field guide from stage 02 paid off, followed step by step instead of improvised: a dedicated no-sudo runtime user with lingering enabled, the agent process under Restart=always so a crash or reboot never means a silent death, a root-owned security cage that denies the agent read access to secrets and env vars even in bypass-permissions mode, and runtime-only secret resolution. The guide's hard-won gotchas were exactly the headaches we got to skip.

An attacker must win five times. The defender only once.

No-sudo runtime userRestart=alwaysRoot-owned cage

11Secrets never touch disk, this is the flex

This is how we handle secrets everywhere, not just on this box. A password manager holds a dedicated vault scoped to exactly the agent that needs it, nothing wider. A key that has to leave the vault gets minted with the narrowest permission that does the job, at the moment of use, not pre-staged and forgotten. On disk there is never a raw key, only a reference pointer to where the real value lives. The consumer process resolves that pointer at the instant it runs, so the secret exists in memory for that one process and nowhere else, not in a config file, not in a log, not in chat history.

The key is never at rest anywhere an agent can read.

Why this exists at all: an AI agent is a genuinely useful pair of hands, and also genuinely capable of being messy with secrets, printing one in an answer, writing one into a file it didn't need to touch, reading a vault wider than the task called for. That's not hypothetical, we've watched it happen in day-to-day use, more than once. So the fix isn't "be more careful," it's removing the opportunity entirely: the agent is structurally incapable of reading the raw value in the first place, enforced at the system level, not by asking it nicely.

Dedicated vault per agentReference, not raw valueRuntime-only resolution

12The catch, mid-build, before first boot

Verification caught the first access token scoped too wide, it could have read records far beyond what this box needed. Caught before the agent ever ran: the vault got re-partitioned, the token re-minted and scoped tight, the old one revoked.

The rule this confirms: never grant scope you haven't verified is minimal. Check the blast radius before first boot, not after something goes wrong. One boring verification step, done at the right moment, is worth more than every other security layer combined.

13Hardening

Default-deny inbound firewall, allowing traffic only on the tailnet interface. Network key expiry disabled for this node, nobody's re-authenticating a headless office box every 90 days. Both changes verified live, with the agent still answering afterward, harden, verify, harden, verify.

14The test that actually proves it

Anyone can claim "self-healing." The only proof: pull the plug, don't touch the power button, and watch. The bar is three clean rounds before the box ships anywhere, plus an overnight unplug to confirm the BIOS setting survives a long cold cycle. Don't take our word for it, run the test yourself:

The power-pull test, simulated

This is the exact recovery sequence the real box walks through, timed roughly to scale.

power · box running

ubuntu server · up

tailnet · joined

claudeclaw service · active (running)

telegram bot · answering

status: healthy · humans required: 0

A closed loop. No human anywhere on it.

Why this test matters more than any spec sheet: the box will sit in an office with nobody technical nearby. A brownout, a breaker trip, a cleaner unplugging a vacuum. If it doesn't come back on its own, every other design decision in this build was decoration.

15Where it stands now

Live, answering on Telegram, running a burn-in week at home before the one and only on-site step: plug into ethernet and power at the office, walk away. That's it. Everything else was decided, war-gamed, sparred, pre-staged, and tested before the box ever left the house. That's the whole point of the method: the office visit is boring because every interesting problem already happened at home.

What we'd do differently next time

Honesty section, because a build log that's all wins is a highlight reel, and highlight reels teach nothing.

Label physical objects at creation. Two lookalike USB sticks cost us twenty minutes of debugging a "BIOS problem" that was actually a wrong-stick problem. New house rule: the moment you think "I can't tell which is which," you stop and label. Masking tape costs nothing, phantom debugging costs your evening.

Don't trust wildcards in install configs. We'd have saved a full install attempt by hardcoding the WiFi interface name from the start. If the config accepts an exact value, give it an exact value.

Verify token scope at mint time, not at review time. The over-scoped token got caught, but it should never have existed. The checklist now reads: mint, then immediately list what the token can actually read, then proceed. Thirty seconds, in that order, every time.

The decision ledger, every fork on one screen

For the skimmers. Each row is a decision, the road not taken, and the reason it lost.

Chose	Over	Because
On-prem physical box	VPS	Data sovereignty: client documents never leave the building. GDPR answer is one word.
Tailscale-only admin	Port forwarding / static IP	Zero inbound ports, zero office network changes, box moves anywhere by plugging it in.
Dashboard via SSH tunnel	Exposing it on the network	Zero added attack surface, no certificate headaches.
No-sudo runtime user	Running the agent as admin	A compromised agent is boxed into an unprivileged account.
Secrets as runtime references	Keys in .env files	Agents are messy with secrets. Structural prevention beats good intentions.
Balanced hardening	Maximum paranoia	Security a stressed human skips isn't security. Keep what's free, cut what taxes daily use.
Pre-stage everything at home	Configuring on-site	The office visit should be boring. Every interesting problem happens where the tools are.

One honest disclaimer before you steal any of this: we're still learning, same as everyone here. Some of what's above is probably not the best way, it's just the best way we know so far. None of it is gospel. If you see something we got wrong, something you'd harden differently, or a simpler path to the same result, say so in the comments, that feedback is worth more to us than the likes. We wrote this to share what we learned, and the fastest way to learn more is to be corrected in public.