DEV Community: Jun0

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.