Forem: Jun0

I built sonmat to fix this. Then sonmat had the same bug.

Jun0 — Sun, 03 May 2026 03:16:19 +0000

Another confession

In the last post, I went after the bug that every Claude Code discipline plugin seems to share: the rules live in the main session, the work happens in the workers (subagents), and the rules don't make the trip across. I named names. I quoted the maintainer of superpowers closing a related issue as "not planned." And then, with a straight face, I claimed that sonmat was different.

It really wasn't. Not yet, anyway.

For a while, sonmat had this nicely-crafted hook. Every time you opened Claude Code, it would shove 1,239 characters of discipline into additionalContext before you even said hello. "MANDATORY. Apply Break it / Cross it / Ground it. Read project memory. Watch for novel traps…" Every session, every time, before the model got a word in.

I thought this was the strong play. The hook fires before the model speaks, the instruction lands in additionalContext, the discipline can't be skipped. That was the theory.

What I didn't notice — for embarrassingly long — was that I was rebuilding, with my own hands, the exact bug I'd just spent a whole post laughing at.

How I figured it out

Here's the awkward bit: additionalContext is delivered to the main session. It is not delivered to subagents.

So picture what was actually happening. The discipline lived in the place I could see (the main session). It was completely absent from the place where the work actually got done (the workers). The main session would dutifully announce "applying Break / Cross / Ground" — and then dispatch a worker. The worker would receive a clean task with a clean context. No discipline. The worker would shrug and go, "this is simple enough, I don't need tests." The result would come back, the main session would format it confidently (still holding all 1,239 characters of rules), and I'd nod along and approve.

It was not fine.

Which is to say: the exact failure mode I'd been mocking in superpowers and karpathy-skills? Same mechanism, different label, mine.

Honestly, I only caught it kind of by accident. I'd started spinning up other CLIs for the same kind of work, and something in the output felt off. So I went poking around. Turns out, every CLI handles hooks slightly differently — different contracts, different injection points, sometimes none at all. And while I was wrestling with making the discipline survive outside Claude Code, the thing that should have been obvious inside Claude Code finally clicked: a hook that lands in one place but not another isn't a guarantee. It's a happy accident that landed in the main session.

The bug wasn't multi-CLI. The bug was that I'd been calling that happy accident a guardrail.

What changed in v0.4.0

I emptied the hook. additionalContext: 1,239 → 0.

The discipline didn't disappear — it just moved. It now lives in CLAUDE.md → discipline/core.md, the same file the agent already reads as part of its prompt context, and the same file you'd put any other instruction in. Workers spawned by the main agent inherit the same CLAUDE.md chain. So the rule lands in the same place, every layer.

The hook still runs. It just sticks to what hooks are good at. Make the .claude/sonmat/ directory. Plant a one-time ## sonmat block in your global CLAUDE.md so the discipline gets referenced. Check for updates. Side effects only. It doesn't try to shape behavior anymore.

BEFORE                                 AFTER
hooks/session-start                    hooks/session-start
  └─ additionalContext: 1,239 chars      └─ side effects only
       "MANDATORY: sonmat..."                 ├─ create .claude/sonmat/
       (delivered to main session             ├─ plant ## sonmat block
        only — workers never saw it)          └─ git pull if outdated

                                       CLAUDE.md → discipline/core.md
                                         (read by main and by every
                                          worker spawned from it.
                                          visible to the user. editable.)

Same discipline, different path. The behavior didn't get weaker — it just got honest about where it actually lives.

Four things I believe now

1. A guardrail that doesn't reach the worker is a fake guardrail.
If your "mandatory" rule is being delivered through a channel the worker doesn't subscribe to, it isn't mandatory. It's decoration. And the trap is that you can see it sitting in the main session — which is exactly why you stop checking.

2. Visibility is the contract.
A rule sitting in additionalContext is invisible to the user. You can't read it, can't edit it, can't disagree with it. A rule sitting in CLAUDE.md → core.md is just there, in the repo. The agent reads it. You read it. You can disagree with it — and that's a good thing, because that's how drift gets caught before it ships.

3. Hooks are for side effects. They are not for behavior.
Make the directory, plant the marker, pull the update. That's the job. The moment a hook starts trying to shape what the agent does, you're betting that the hook fires in every code path the agent will ever take. It doesn't. It can't.

4. "Strong" enforcement is usually fragile enforcement.
The 1,239-character injection felt powerful because it was automatic. But automatic-and-incomplete is worse than manual-and-complete — the user trusts the automation and stops looking. Moving discipline into a file the user can edit (and ignore) sounds weaker. It isn't. It's where the user actually re-enters the loop.

The hard part

Honestly, emptying the hook felt like giving up control. The hook was the place where I could make sure. If discipline lives in CLAUDE.md, the user can edit it, override core.md, even ignore the whole thing.

Which, yes, is the entire point.

A discipline the user can't see is a discipline the user can't trust. A discipline the user can't edit is a rule, not a tool — and sonmat is supposed to be a tool. Visibility is the price of trust. And there's a bonus: the discipline now reaches the workers, because the workers read the same file the user reads.

Diagnose your own setup

If you're running any Claude Code plugin that promises "guardrails," try asking three questions:

Where does the rule physically live? A hook injecting additionalContext? A skill the model has to remember to invoke? A line in CLAUDE.md?
Who actually reads it? Just the main session? Workers too? Subagents spawned from workers?
Can you see it yourself? If you can't open a file and read the rule that's supposedly governing your agent, you don't have a guardrail. You have a vibe.

I had to put my own plugin through those three questions before the answer became obvious. Doing the diagnosis in 01 was the easy part. Applying it to sonmat itself took a lot longer.

Try it

/plugin marketplace add jun0-ds/sonmat
/plugin install sonmat@sonmat

After install, the discipline lives at ~/.claude/plugins/marketplaces/sonmat/discipline/core.md. Open it. Read it. Disagree with parts of it if you want — that's actually how you'll know it's doing something real.

→ GitHub: jun0-ds/sonmat

Part of the series **Building sonmat. Previous: Your AI is confident. Your AI is wrong. You shipped it anyway.

GitHub · LinkedIn

Your AI is confident. Your AI is wrong. You shipped it anyway.

Jun0 — Fri, 01 May 2026 03:13:10 +0000

A confession

I told Claude to write tests first. Claude said "understood." Then Claude spawned a subagent. The subagent said "this is simple enough, I don't need tests." It shipped. I approved. The tests that didn't exist didn't fail. Everything looked fine.

It was not fine.

The fun part: I had three plugins installed specifically to prevent this. They were all working correctly. In the main session. Where the work wasn't happening.

The problem with being confident

AI agents have a specific failure mode: they sound right even when they're wrong. This is well-known. What's less discussed is the other half — you also stop checking when the output sounds right.

So you have two parties in a conversation. One produces confident nonsense. The other accepts it because confidence is persuasive. Nobody verifies. Errors ship.

This is not a technology problem. This is a trust problem. And every tool I tried was solving the wrong half of it.

What every plugin gets right (and then misses)

superpowers (175k stars) adds TDD, debugging, code review. Smart rules. They live in the main session. When Claude spawns a subagent — which is where the actual work happens — the subagent doesn't get them. The maintainer closed it as not planned: "this is a Claude Code platform limitation. There's not much superpowers can do."

karpathy-skills puts principles in CLAUDE.md. Subagents can't reliably read CLAUDE.md. Sometimes they claim they did. They didn't.

GSD has beautiful structure. Milestones, slices, tasks. Discipline is the user's job. The framework doesn't enforce it at the worker level.

The pattern: great rules → main session only → workers ignore them → output looks fine → it isn't.

Documented. Repeatedly. Across projects.

What I built instead

sonmat (손맛 — Korean for "mother's touch." The secret ingredient that makes the same recipe taste different.)

It does two things:

Makes the AI doubt itself. Verification discipline goes directly into every worker's prompt at dispatch time. Not a file reference. Not a hook that might fire. The actual rules, in the actual prompt. Break it, Cross it, Ground it — on every task, including the ones you don't see.

Makes you doubt the AI. Every decision surfaces with its reasoning. Not "here's the answer" but "here's the answer, here's why, and here's what I'm not sure about." When you see the reasoning, you can judge. When you only see the answer, you won't.

And the AI doubts you back. When your instruction is ambiguous or conflicts with what it sees, sonmat doesn't just comply — it asks. The same verification attitude applies in both directions.

That's the whole thing. Everything else — autonomous loops, escalation levels, domain-specific traps — is implementation detail.

Four things I believe now

1. Confidence is the worst signal.
When the model feels sure, that's exactly when it should look for counterexamples. Confidence without verification is hallucination in a suit.

2. Rules that don't reach workers are decoration.
A coding standard that exists only in the main session is a Post-it note on a door nobody walks through.

3. Autonomy without guardrails is just expensive chaos.
sonmat escalates automatically — pause, spawn worker, spawn parallel workers — when it hits surprises or repeated failures. You don't babysit. It doesn't run blind.

4. Universal rules are universally mediocre.
"Write tests first" is critical for dev, meaningless for data analysis. "One change at a time" is essential for ML, overkill for docs. sonmat loads domain-specific traps. The right advice for the right context.

The hard lesson

I wanted to add more rules. Every edge case screamed for a new rule. I resisted.

Too few rules: chaos. Too many: the agent spends its time checking boxes instead of working. The answer was a small, hard core — three verification methods — plus domain hints that activate only when relevant.

The other lesson: transparency beats enforcement. A guard that says "no" gets worked around. A colleague that says "I noticed this — your call" gets listened to. sonmat chose the second approach. For the AI and for you.

Try it

/plugin marketplace add jun0-ds/sonmat
/plugin install sonmat@sonmat

No config. Start talking.

→ GitHub: jun0-ds/sonmat

GitHub · LinkedIn

I Spent a Week Installing WSL2. The Fix Was Two Lines.

Jun0 — Tue, 31 Mar 2026 01:22:16 +0000

"WSL2? Five minutes, tops." — Me, seven days ago.

TL;DR

On Windows 11 25H2 (build 26200), enabling VirtualMachinePlatform hangs at 37.8%. Forever. The servicing stack is stuck on 24H2 (build 26100) while the OS moved to 25H2 (build 26200). Windows literally cannot service itself.

Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess

If you just want the fix, there it is. If you want to know how it took a week and 10 failed attempts to arrive at two lines of PowerShell, keep reading.

Day 1: Innocence

Simple plan. Install WSL2. Set up Ubuntu 24.04. Do actual work.

wsl --install -d Ubuntu-24.04

37.8%.

I made coffee. Came back. 37.8%.

I had lunch. Came back. 37.8%.

37.8 is now my least favorite number.

The Crime Scene


OS	Windows 11 Pro 25H2 (Build 26200.8037)
CPU	Intel Core Ultra 9 275HX
DISM version	10.0.26100.5074
Servicing stack	10.0.26100.8035

See it? OS is build 26200. Servicing stack is build 26100. The mechanic has last year's manual for this year's car. If you spotted this, you already know the ending. I did not spot this on Day 1.

Days 2-6: The Parade of Failures

GUI — Stuck. Cancel also stuck.

"Turn Windows features on/off." Checked the box. Progress bar froze.

Clicked Cancel. Cancel froze.

A cancel button that cannot be cancelled. This is the operating system from the world's most valuable company.

Task Manager. End Process. Moving on.

DISM — 37.8%

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

37.8%. We meet again.

PowerShell — Same wall, different paint

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart

Calls DISM internally. Same result. Changing the wrapper doesn't change the candy.

Uninstalled BlueStacks — Wrong suspect

Found forum posts: "Android emulators conflict with Hyper-V." I had BlueStacks 10 installed. Uninstalled it completely. Registry cleanup. Folder purge. The works.

Result: 37.8%.

BlueStacks was innocent. And now I have to reinstall it later.

Offline install from 24H2 ISO — Version mismatch

"If the download is the problem, go offline."

dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess /Source:D:\Sources\Install.wim

0x800f0912. The ISO is 24H2 (26100), the OS is 25H2 (26200). Windows refuses the source files because they're from "the wrong version." Self-compatibility is apparently optional.

Windows Update cache reset — No effect

net stop wuauserv
net stop bits
Remove-Item C:\Windows\SoftwareDistribution\Download\* -Recurse -Force
net start bits
net start wuauserv

Clean cache. Same 37.8%. Cleaning the house doesn't fix the plumbing.

Pending operations cleanup — Partial

dism /online /cleanup-image /revertpendingactions

Cleared the backlog. Feature still won't activate. Finishing your homework doesn't mean you'll pass the exam.

In-place repair install — Didn't downgrade

The nuclear option. Ran 24H2 ISO's setup.exe with "Keep personal files and apps."

40 minutes. Three reboots.

Result: OS stayed on 25H2 (26200). In-place install doesn't downgrade. But it did clean up the component store. This becomes a crucial plot point later.

Day 7: Reading the Logs (Finally Using My Brain)

A week of "try something else until it works." At this point, the question isn't what doesn't work — it's why.

Select-String -Path C:\Windows\Logs\CBS\CBS.log `
  -Pattern "Error|Failed|0x800f" -Context 2 | Select-Object -Last 20

The smoking gun:

Failed to get uup features from WU, sessionData: {
  "ModuleID":"FOD",
  "Features":[{
    "name":"Windows.HyperV.OptionalFeature.VirtualMachinePlatform.Client.Disabled~"
  }]
} [HRESULT = 0x800f0820 - CBS_E_CANCEL]

download source: 8, download time (secs): 1256, 
download status: 0x800f0820 (CBS_E_CANCEL)

1,256 seconds. Twenty-one minutes waiting for Windows Update to deliver a package it will never find.

From the DISM log, the confession:

Dism.exe version: 10.0.26100.5074
Target image: OS Version=10.0.26200.8037

The servicing stack (26100) is trying to service a newer OS (26200). It goes to Windows Update looking for FOD packages matching this combination. Those packages don't exist in the UUP catalog. So it waits. And waits. And times out at 37.8%.

A car mechanic with a 2023 catalog trying to order parts for a 2024 model. "This part number doesn't exist in our system, sir."

This is the servicing architecture of the world's largest software company.

The Fix: Use the Back Door

DISM can't download the FOD through its usual channel (UUP). But Add-WindowsCapability uses a different channel.

Same building. Front door is under construction. Back door is open. The sign only mentions the front door. Classic Windows UX.

# Step 1: Back door — install payload via alternative channel
Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"

# Step 2: Now activate using only local files (no internet needed)
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess

100%.

One hundred percent.

First three-digit number I've seen all week.

Why This Works

[Front door — BLOCKED]
DISM enable-feature
  → Needs FOD payload
  → Windows Update UUP channel
  → Servicing stack (26100) ≠ OS (26200)
  → "Part not found in catalog"
  → 21 min timeout → CBS_E_CANCEL

[Back door — OPEN]
Add-WindowsCapability  
  → Different download channel (bypasses UUP)
  → Payload installed locally ✓

DISM + /LimitAccess
  → "Internet? Don't need it."
  → Local files only
  → Success ✓

Both commands use the same Windows servicing system. But they fetch FOD packages through different channels. DISM goes through UUP, where the version mismatch kills it. Add-WindowsCapability takes a different route. The official docs don't mention this distinction. You're welcome.

If You Found This Article

You've probably already tried and failed multiple times. That means pending operations are likely piled up. Clean house first:

# Light cleanup
dism /online /cleanup-image /revertpendingactions
# → Reboot → Run the two-line fix

# If that's not enough (in-place repair)
# 24H2 ISO → setup.exe → "Keep personal files and apps"
# → Reboot → Run the two-line fix

Complete Flow (For Fresh Starts)

1. Enable virtualization in BIOS
   HP laptops: F10 → Security or Configuration → Enable VT-x
        ↓
2. Enable Hyper-V + WSL (these work fine, ironically)
   dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart
        ↓
3. Clean pending operations (if you've been trying things)
   dism /online /cleanup-image /revertpendingactions → reboot
        ↓
4. The actual fix
   Add-WindowsCapability -Online -Name "Microsoft.Windows.HyperV.VirtualMachinePlatform~~~~0.0.1.0"
   dism /online /enable-feature /featurename:VirtualMachinePlatform /all /LimitAccess
        ↓
5. Reboot → Install WSL2
   wsl --install -d Ubuntu-24.04

Is This Your Problem?

# Check version mismatch in DISM log
Get-Content C:\Windows\Logs\DISM\dism.log -Tail 100
# "version:" ≠ "image version:" → yes, this is your problem

# Check CBS log for the specific failure
Select-String -Path C:\Windows\Logs\CBS\CBS.log `
  -Pattern "Error|Failed|0x800f" -Context 2 | Select-Object -Last 20
# "CBS_E_CANCEL" → yes, this is your problem

# Verify CPU virtualization (prerequisite)
Get-CimInstance -ClassName Win32_Processor | 
  Select-Object VirtualizationFirmwareEnabled, VMMonitorModeExtensions

Summary


Symptom	VirtualMachinePlatform stuck at 37.8%
Root cause	25H2 OS (26200) + 24H2 servicing stack (26100) = FOD download mismatch
Fix	`Add-WindowsCapability` to bypass → `dism /LimitAccess` to activate
Prerequisite	Clear pending operations
Cost	One week of evenings. One wrongly accused BlueStacks. A lasting distrust of progress bars.

Lessons

Read the logs first. "Try random things until something works" is the scenic route to nowhere.
Windows Insider means signing up for this. 25H2 is a preview build. The servicing stack hasn't caught up. Now you know.
Same building, multiple doors. When DISM fails, Add-WindowsCapability exists. The docs won't tell you.
Feed your logs to AI. Nobody should read 160,000 lines of CBS log with their own eyes.

This troubleshooting session was done with Claude Code. It pulled the critical 6 lines from a 160,000-line CBS log and helped identify the Add-WindowsCapability back door. Without it, this would have ended with a format and reinstall.