DEV Community: Mikhail Predtetchenski

One markdown file, three sites: what broke the first time my crosspost ran

Mikhail Predtetchenski — Sun, 01 Nov 2026 02:31:03 +0000

Case file

Incident: Oct 30–31, 2026
Symptom: the publishing pipeline for this log was built on Oct 24–25 and had never sent a single post. The night the first real post went out, it broke in four separate places.
Evidence: a dry run that sent /build-log/images/... paths to dev.to and Hashnode unchanged; a Cross-post run that died at npm ci with Missing: @emnapi/core@1.11.3 from lock file; Hashnode FAILED: fetch failed in the log of a run that still finished green.
Cause: four assumptions nobody had tested live. Relative URLs only resolve on my site. The lockfile came from a newer npm than the GitHub runner uses. Hashnode's old API host now redirects to a paid-API notice. And the script treated "a site rejected this post" as a log line, not a failure.
Fix: five small PRs between 12:29 and 2:04 AM CT on Oct 31: #17 (absolute URLs), #18 (lockfile), #19 (Hashnode endpoint), #20 (re-run the post) and #21 (fail the run).
Prevention: tests for the URL rewriting that run before every cross-post, a lockfile made with the runner's npm, and a run that goes red when any site rejects a post. The next post, the AMD boot loop one, went to all three sites on its first try.
Lesson: a pipeline that has never run isn't done. It's a draft.

The story

The idea was simple. I write each post once, as a markdown file in a public GitHub repo. When I merge it, a GitHub Action builds the site on GitHub Pages, and a second job sends the same file to dev.to and Hashnode with a canonical link pointing back to the site. No copy-pasting, no "which version is the real one."

That got built on Oct 24–25. The first pull request merged at 2:27 AM CT on Oct 25, and the cross-post job ran right away. Its entire output was No content entries to cross-post. There weren't any posts yet. So for about a week I had a pipeline that had "run" exactly once and done nothing. My old draft of this post said it plainly: the auto-publish has never actually run.

There was one detour back then that I'm keeping in the story. Hashnode's GraphQL API had started requiring a Pro plan, and my first reaction was to drop Hashnode to drafts only. Then I looked at the price, asked "Unless mistaken, $5/mo on Hashnode should work for API work?", and it did. I upgraded, added the two Hashnode secrets, and the sender went back in. I also asked whether I needed a separate "publisher bot." The answer was no: publishing is the same steps every time, and fixed steps belong in code. My merge is the approval, and the Action ships it.

Then on the night of Oct 30 I finally had a real post to send: the "how it started" retro. HQ, the Grok Bot I do most of my work with, was getting it ready, and the first problem got caught before anything went live. The retro's diagrams were linked as /build-log/images/how-it-started/.... That works on my site. On dev.to it would point at dev.to. The script was sending the markdown untouched. That became #17, which parses the markdown and rewrites site-relative links and images to full URLs before sending, without touching code blocks. It went through a lot of review rounds (Copilot and Cursor Bugbot both found real edge cases) and merged at 12:29 AM.

The Cross-post run for that merge failed within seconds. Not on dev.to, not on Hashnode, but on npm ci:

npm error `npm ci` can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync.
npm error Missing: @emnapi/core@1.11.3 from lock file
npm error Missing: @emnapi/runtime@1.11.3 from lock file

Fixing break one had caused break two. #17 added a markdown parser, and the lockfile that came with it was written by a newer npm than the one the runner gets with Node 22. #18 regenerated it with Node 22.23.4 and npm 10.9.9, the same versions CI uses, and merged at 1:13 AM.

At 1:38 AM I merged the retro itself. The run went green. dev.to had the post. Hashnode didn't. Buried in the log was one line: Hashnode FAILED: fetch failed. Hashnode had retired gql.hashnode.com. It now answers every request with a 301 to a notice about paid API access, and my sender refuses redirects on purpose, so every call failed before it reached the API. Hashnode's own CLI uses gql-beta.hashnode.com, and a read-only test query with my token worked there. #19 was a one-line endpoint change, merged at 1:53 AM.

But merging a script fix doesn't re-send anything, because the job only sends posts whose files changed in that push. So #20 added one trailing newline to the retro, which doesn't change how it renders, just to make it count as changed. That merged at 1:55 AM, and this run is the one I was waiting for: dev.to updated the existing article in place (no duplicate), and Hashnode published the post.

That left the part that bugged me most. The 1:38 AM run had been green with a failed site in it. If I hadn't read the log, I'd never have known. The Hashnode sender returned { failed: true } instead of throwing, and the main script just moved on. #21 counts those results as failures. The other sites still get their turn, but the run ends red and GitHub emails me. Merged at 2:04 AM.

The real test came a couple of hours later. At 4:21 AM I merged the AMD boot loop post, and its run created it on dev.to and Hashnode on the first try, then committed both ids to sync-state.json. Nobody touched anything. That's the whole point.

These days the roles are simple. GitHub is the source: the posts, the code, and the PRs where the reviewers argue. Linear is the backlog of post ideas and fixes. Notion holds private session transcripts that never get published. X, LinkedIn and Facebook get drafts that I post myself.

Do it yourself

My code is all in the public repo, github.com/mikepred/build-log. This is the shape of it.

1. One file per post, with a canonical URL. Mine live in content/YYYY-MM-DD-slug.md:

---
title: "One markdown file, three sites"
date: 2026-10-31
tags: [github-actions, astro, devto, hashnode]  , 4 max, dev.to's limit
summary: "Used as the meta description, dev.to description and Hashnode subtitle."
canonical_url: "https://<you>.github.io/<repo>/<slug>/"
---

Pick the canonical URL once and never change it. dev.to and Hashnode both use it to find the existing copy.

2. Build the site from the repo. I use Astro, deployed to GitHub Pages by its own workflow (deploy.yml) on every push to main. That one doesn't know cross-posting exists, so a broken cross-post never blocks the site.

3. Cross-post from a second workflow, and keep it on a short leash. In crosspost.yml, ignore the files that shouldn't trigger it, run the tests before sending anything, and pass secrets only to the step that needs them:

on:
  push:
    branches: [main]
    paths-ignore:
      - sync-state.json   # the state commit shouldn't start another run
      - 'log/**'          # running-log notes are site-only

# ...
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test
      - name: Publish changed entries
        env:
          DEVTO_API_KEY: ${{ secrets.DEVTO_API_KEY }}
          HASHNODE_TOKEN: ${{ secrets.HASHNODE_TOKEN }}
          HASHNODE_PUBLICATION_ID: ${{ secrets.HASHNODE_PUBLICATION_ID }}
          BEFORE_SHA: ${{ github.event.before }}
        run: node scripts/crosspost.mjs

The script diffs BEFORE_SHA against the pushed commit and only sends posts in content/ that changed. Each platform is one small file in scripts/senders/ with the same four exports (id, disabledReason, plan, publish), so adding or dropping a site is one file.

4. Make every send safe to repeat. Before creating anything, look for the existing copy. My dev.to sender checks the stored id, then looks for an article with the same canonical_url, and only creates one if neither exists. Hashnode does the same with originalArticleURL. The ids go into sync-state.json, keyed by slug, and the workflow commits that file back with [skip ci] in the message. That's why re-sending the retro updated dev.to instead of duplicating it.

5. Rewrite site-relative URLs before sending. On your site, /build-log/images/x.svg is fine. Anywhere else it's broken. Rewrite links and images under your base path to absolute URLs in the copy you send, and leave code blocks alone:

before: ![Diagram](/build-log/images/how-it-started/team-timeline.svg)
after:  ![Diagram](https://mikepred.github.io/build-log/images/how-it-started/team-timeline.svg)

Test it. Mine has tests for nested HTML, inline code inside link text, lookalike paths like /build-logs, and code blocks inside lists, and the workflow runs them before every cross-post.

6. Make the lockfile with the runner's npm. npm ci refuses a lockfile that's out of sync with what its npm expects. If your workflow uses node-version: 22, regenerate the lockfile with Node 22's npm (10.x), not whatever newer npm you have locally:

node -v   # v22.x, same major as the workflow
npm -v    # 10.x
npm install --package-lock-only
npm ci && npm test

7. Fail the run when any site rejects a post. Keep going so the other sites still get their copy, but don't let the run finish green:

if (remote?.failed) {
  // The sender already logged the details. Count it so the run ends red.
  failures.push(`${sender.id} ${entry.file}: ${remote.message ?? 'failed'}`);
  continue;
}
// ...after every post and every sender:
if (failures.length > 0) {
  throw new ScriptError(`${failures.length} cross-post send failed.`);
}

A missing secret is different. That sender is skipped with a warning, so a copy of the repo without those accounts still gets a clean run. If every sender is skipped, the script warns and exits 0.

8. Dry-run before the first real merge. My script has a mode that builds every request and prints it, with no network and no state written:

node scripts/crosspost.mjs --dry-run content/2026-10-31-one-markdown-file-three-sites.md

That's how #17 got checked: the retro's diagram paths came out relative before the fix and absolute after it. A dry run can't catch the other three, though: npm on the runner, a retired endpoint and a hidden failure only show up on a real run. So plan to watch the first one.

Caveats

Hashnode's API needs a Pro plan, and its old host gql.hashnode.com now redirects. Mine uses gql-beta.hashnode.com, the host its official CLI uses.
Editing a copy on dev.to or Hashnode doesn't stick. The next time that post's file changes, the repo version overwrites it.
dev.to strips tags down to letters and numbers, so github-actions shows up there as githubactions.

Giving my Grok Bot assistant admin rights without switching off UAC

Mikhail Predtetchenski — Sun, 01 Nov 2026 02:28:15 +0000

Case file

Incident: Oct 24, 2026
Symptom: dr eggbot, one of my Grok Bot assistants, runs PowerShell on my PC from a normal, non-elevated terminal. Every admin step came back to me as "paste this into an admin window."
Evidence: restore points, HKLM registry writes, bcdedit and SYSTEM scheduled tasks all need an elevated session. A Windows rebuild is mostly those.
Tempting fix: SSH to my own machine as an admin. On Windows, an SSH session for an admin account runs fully elevated with no UAC prompt, and the private key would sit in my profile, where anything running as me could use it.
Fix: a fixed menu of five elevated scheduled tasks under \WinSetup\. Each one runs a script from a folder only admins can change. My normal account can start the tasks but can't edit them, and the runner refuses any action that isn't on the list.
Prevention: adding or changing an action means rerunning the installer from an admin window. That one paste is my approval step.
Lesson: give the assistant verbs, not a shell, and test the boundary from the account it actually runs as. Bonus lesson from the first real run: read the tool's own log before you blame a hang on it.

The story

I was rebuilding my Windows 11 setup with dr eggbot. It runs PowerShell on my PC, but its terminal isn't elevated, so every admin-only step turned into a command for me to copy into an admin window. After a few of those I asked the obvious question: can we set up an SSH key so you can run these yourself?

It could, but dr eggbot explained the catch before building anything. You turn on Windows' built-in OpenSSH server, authorize a key, and the assistant runs ssh to localhost. Windows gives an admin account's SSH session a fully elevated token with no UAC prompt. That part is the point. The problem is where the key lives: in my profile, so the assistant's terminal can read it. That means anything running as me, whether a sketchy installer, a bad package or the assistant itself, could pick up that key and get admin without a prompt. It's UAC switched off in all but name.

So I had three options: full SSH admin, a short list of admin jobs, or keep pasting. I asked whether the short-list version could handle something like Enable-ComputerRestore. It could, as long as that job was on the list. What it can't do is run a brand-new admin command on the spot. Anything new means updating the protected copy of the scripts, and that takes one paste from me in an admin window. I decided that paste was a feature. It's my approval step. I went with the short list.

Here's what dr eggbot built:

A folder, C:\ProgramData\WinSetupAdmin, that only Administrators and SYSTEM can write to. Everyone else can read and run what's in it.
A runner.ps1 in that folder that accepts exactly one of a fixed set of actions and refuses anything else: RestorePoint, Tweaks, Apps and SaveDumps at first, plus Check, which came later.
One scheduled task per action under \WinSetup\. Each runs the runner elevated, as me, only while I'm signed in, and only when something starts it. No triggers, no schedule.
A permission on each task that lets my normal account start it and read it, but not change it.
A log for every run, written inside the protected folder, that dr eggbot can read afterward.

I pasted the installer once, from an admin window. Then dr eggbot started the RestorePoint task from its own non-elevated terminal, and it worked: a fresh restore point, exit 0.

A working menu only proves half of it, though. The other half is whether the normal account can quietly change what the menu does. So dr eggbot tried, from the same account it runs as. Writing a new file into the folder: blocked. Appending a line to runner.ps1: blocked. Re-registering a task with a changed definition: access denied. It can start the tasks. It can't change what they do.

Coda: the hang that wasn't winget

The first real job was applying my tweaks script through the Tweaks task. The registry changes landed, but the task sat at "Running" for more than five minutes with nothing in its log past the header. The script's last step was winget configure --enable, so we blamed winget. A hidden task has no console, and winget probably wanted one. We moved that step into its own process with a time limit, reran it, and it came back clean in two seconds. Case closed, I thought.

It wasn't. When dr eggbot finally read winget's own log, winget hadn't done anything on either attempt. I'd passed --enable together with --disable-interactivity, and winget rejects that combination: "Option '--enable' and '--disable' cannot be used with other arguments." It quit within milliseconds, both times. On the first run, the thing actually hanging was PowerShell, still waiting on the inline | Out-Null pipe after winget had exited. Why that pipe stayed open is still unproven. The "clean" rerun was only clean because Start-Process doesn't pipe output, and the feature I wanted was never turned on.

The real fix was the right flag (--enable on its own) plus running winget as its own process. On the next run winget's log showed "Leaf command succeeded: root:configure," and the task finished in about six seconds. The time limit is now five minutes, because --enable can download from the Store. It's insurance, not the fix, and it has never fired.

That run turned up one more bug. The tweaks script has a check mode that reports drift, and when it ran without admin it called a SYSTEM-owned task "missing" because it couldn't see it. Now it says "not checked (needs admin)."

Which raised a fair question: hadn't I just given it admin? Sort of. It could apply settings through the menu, but it couldn't read admin-only state back to confirm them. So we added a fifth action, Check. It's read-only and runs the drift check elevated. I reran the installer (one more paste, one more approval), dr eggbot started Check itself, and it came back "All settings match." with exit 0. It verified admin-only settings without getting any broader admin.

Do it yourself

This assumes your everyday account is an administrator under UAC, which is the Windows default, and that you're comfortable reading PowerShell. The scripts are trimmed versions of mine. Keep your working copies in a folder such as %USERPROFILE%\WinSetup. The installer copies them into the protected folder; that copy is the only one the tasks ever run.

1. Decide on the menu. Write down the admin jobs you actually want the assistant to run, as verbs. Mine are RestorePoint, Tweaks (my settings script), Apps (install from a list), SaveDumps (the crash-dump copy from my boot loop post) and Check (a read-only drift report). Anything that takes free-form input, like "run this command" or "install this package name," doesn't belong on the list. That's a shell with extra steps.

2. Write the runner (runner.ps1). It accepts one action from a fixed list and logs everything.

param([Parameter(Mandatory)][ValidateSet('RestorePoint','Tweaks','Apps','SaveDumps','Check')][string]$Action)
# The task starts a fresh -NoProfile process, so nothing upstream sets this. Without it, a failed registry write
# is a non-terminating error, the catch below never sees it, and the log still says exit 0.
$ErrorActionPreference = 'Stop'
# Load modules only from system folders. The per-user module folder is writable by anything running as you.
$env:PSModulePath = "$env:ProgramFiles\WindowsPowerShell\Modules;$env:SystemRoot\System32\WindowsPowerShell\v1.0\Modules"
$root = $PSScriptRoot
$logs = Join-Path $root 'logs'; New-Item $logs -ItemType Directory -Force | Out-Null
Start-Transcript -Path (Join-Path $logs ('{0}-{1:yyyyMMdd-HHmmss}.log' -f $Action, (Get-Date))) | Out-Null
$code = 0
try {
  switch ($Action) {
    'RestorePoint' {
      Enable-ComputerRestore -Drive 'C:\'
      New-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore' -Name SystemRestorePointCreationFrequency -Value 0 -PropertyType DWord -Force | Out-Null
      Checkpoint-Computer -Description 'WinSetup: manual restore point' -RestorePointType MODIFY_SETTINGS
    }
    'Tweaks'    { & (Join-Path $root '01-tweaks.ps1') }
    'Apps'      { & (Join-Path $root '02-apps.ps1') }          # installs only what's in apps.json, which lives in this folder too
    'SaveDumps' { & (Join-Path $root 'save-dumps.ps1') }
    'Check'     { & (Join-Path $root '01-tweaks.ps1') -Check } # read-only drift report
  }
} catch { $code = 1; "ERROR: $($_.Exception.Message)" }
"RESULT: $Action exit $code"
Stop-Transcript | Out-Null
exit $code

$ErrorActionPreference = 'Stop' turns every error into one the catch sees, so a failed step can't end in a log that says exit 0. The scripts the runner calls inherit it too. If one of them is meant to shrug off an error, say so on that line with -ErrorAction Continue.

Every script the runner calls sits next to it in the protected folder. If an action called a script somewhere your normal account can write, that action would be "run whatever is in that file," as admin.

3. Write the installer (install-admin-tasks.ps1). It locks the folder, copies the scripts in and registers one task per action. Rerun it whenever you change a script or the menu.

$ErrorActionPreference = 'Stop'
$id = [Security.Principal.WindowsIdentity]::GetCurrent()
if (-not ([Security.Principal.WindowsPrincipal]$id).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) { throw 'Run this from an admin PowerShell.' }
$src = $PSScriptRoot; $dst = 'C:\ProgramData\WinSetupAdmin'
$user = $id.Name; $sid = $id.User.Value
$actions = 'RestorePoint','Tweaks','Apps','SaveDumps','Check'

# The check the installer trusts: stop at any link, and if anyone but Administrators or SYSTEM owns, or can change,
# anything under $path. The walk is hand-rolled because Get-ChildItem -Recurse in Windows PowerShell follows junctions.
$trusted = 'S-1-5-32-544','S-1-5-18'
$change  = [int][Security.AccessControl.FileSystemRights]'Write, Delete, DeleteSubdirectoriesAndFiles, ChangePermissions, TakeOwnership' -bor 0x50000000   # + generic all/write
function Assert-Locked($path) {
  $queue = New-Object Collections.Queue; $queue.Enqueue((Get-Item -LiteralPath $path -Force))
  while ($queue.Count) {
    $item = $queue.Dequeue()
    if ($item.Attributes -band [IO.FileAttributes]::ReparsePoint) { throw "Link found: $($item.FullName). Delete the folder and rerun." }
    $itemAcl = Get-Acl -LiteralPath $item.FullName
    if ($trusted -notcontains $itemAcl.GetOwner([Security.Principal.SecurityIdentifier]).Value) { throw "Not owned by Administrators: $($item.FullName). Delete the folder and rerun." }
    foreach ($r in $itemAcl.GetAccessRules($true, $true, [Security.Principal.SecurityIdentifier])) {
      if ($r.AccessControlType -eq 'Allow' -and $trusted -notcontains $r.IdentityReference.Value -and ([int]$r.FileSystemRights -band $change)) {
        throw "$($r.IdentityReference.Value) can change $($item.FullName). Delete the folder and rerun."
      }
    }
    if ($item.PSIsContainer) { Get-ChildItem -LiteralPath $item.FullName -Force | ForEach-Object { $queue.Enqueue($_) } }
  }
}

# Unregister the old tasks before touching the folder, so a run that stops below never leaves tasks pointing at a folder
# that might not be locked (say, one you deleted and someone else recreated).
Get-ScheduledTask -TaskPath '\WinSetup\' -ErrorAction SilentlyContinue | Unregister-ScheduledTask -Confirm:$false

# A new folder is created already locked, in one step: owner Administrators and one complete permission list
# (Administrators + SYSTEM full control, Users read and run, nothing inherited), so nothing can be planted in it first.
# An existing folder is never re-permissioned (that would push the new list into whatever is inside). It's only reused
# if it already passes the check; otherwise delete it and rerun.
$acl = New-Object Security.AccessControl.DirectorySecurity
$acl.SetSecurityDescriptorSddlForm('O:BAD:PAI(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;0x1200a9;;;BU)')
if (Test-Path -LiteralPath $dst) { Assert-Locked $dst } else { [void][IO.Directory]::CreateDirectory($dst, $acl) }

# Delete and re-copy each script rather than overwrite it, so the new file inherits the list above instead of keeping old grants.
foreach ($f in 'runner.ps1','01-tweaks.ps1','02-apps.ps1','apps.json','save-dumps.ps1') {
  $target = Join-Path $dst $f
  if (Test-Path -LiteralPath $target) { Remove-Item -LiteralPath $target -Force }
  Copy-Item -LiteralPath (Join-Path $src $f) -Destination $target
  icacls $target /setowner '*S-1-5-32-544' | Out-Null
}
Assert-Locked $dst   # check the result instead of trusting it; no tasks get registered if this throws

$ps  = "$env:SystemRoot\System32\WindowsPowerShell\v1.0\powershell.exe"   # full path, not a PATH lookup
$svc = New-Object -ComObject 'Schedule.Service'; $svc.Connect()
$principal = New-ScheduledTaskPrincipal -UserId $user -LogonType Interactive -RunLevel Highest
$settings  = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -ExecutionTimeLimit (New-TimeSpan -Hours 2) -MultipleInstances IgnoreNew
foreach ($a in $actions) {
  $act = New-ScheduledTaskAction -Execute $ps -Argument "-NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File `"$dst\runner.ps1`" -Action $a"
  Register-ScheduledTask -TaskPath '\WinSetup\' -TaskName $a -Action $act -Principal $principal -Settings $settings -Force | Out-Null
  # Admins + SYSTEM full control; your account may read and start the task, not edit it. Without this flag,
  # Task Scheduler quietly adds its own Allow entry for the account the task runs as, which is you.
  $TASK_DONT_ADD_PRINCIPAL_ACE = 0x10
  $svc.GetFolder('\WinSetup').GetTask($a).SetSecurityDescriptor("D:(A;;FA;;;BA)(A;;FA;;;SY)(A;;FRFX;;;$sid)", $TASK_DONT_ADD_PRINCIPAL_ACE)
  # Read the stored list back: anyone but Administrators or SYSTEM with more than read and run fails the install.
  $readRun = 0x1200A9 -bor 0xA0000000   # FRFX, plus generic read/execute
  $stored  = New-Object Security.AccessControl.RawSecurityDescriptor ($svc.GetFolder('\WinSetup').GetTask($a).GetSecurityDescriptor(4))
  foreach ($ace in $stored.DiscretionaryAcl) {
    if ($ace.AceQualifier -eq 'AccessAllowed' -and 'S-1-5-32-544','S-1-5-18' -notcontains $ace.SecurityIdentifier.Value -and ($ace.AccessMask -band -bnot $readRun)) {
      Unregister-ScheduledTask -TaskPath '\WinSetup\' -TaskName $a -Confirm:$false
      throw "Task $a gives $($ace.SecurityIdentifier.Value) more than read and run. Unregistered it."
    }
  }
}
Get-ScheduledTask -TaskPath '\WinSetup\' | Select-Object TaskName, State

A few notes on what those lines do:

The folder's permissions are written as one complete list (the SDDL string O:BAD:PAI(...)), at the moment the folder is created, and each script is deleted and copied in fresh so it inherits that list. icacls /grant:r alone only swaps the entries it names, so an old write grant for your account would survive a rerun, and so would your ability to swap the scripts the tasks run.
Nothing privileged walks the folder or changes permissions on anything already inside it. Applying a permission list to an existing folder pushes it down into everything inside, and a junction planted in there could point that change at some other folder. So the installer only creates the folder locked, reuses one only if it's already locked, and touches nothing but the files it names. The check walks everything without following links. It refuses to register any tasks if it finds a link, an owner other than Administrators or SYSTEM, or anyone else who can change something. On a folder an older version left behind, that can mean deleting it and rerunning. The old tasks are unregistered before any of this, so a run that stops partway leaves no task pointing at the folder until a rerun gets all the way through.
-RunLevel Highest with -LogonType Interactive means the task gets your full admin token, but only while you're signed in.
The SDDL string at the end is the task's own permission list: FA (full access) for Administrators (BA) and SYSTEM (SY), and only FRFX (read and run) for your account. Flag 0x10 (TASK_DONT_ADD_PRINCIPAL_ACE) matters here. Without it, Task Scheduler adds its own Allow entry for the account the task runs as, and here that's you, so the stored list isn't the one you wrote. The installer then reads each task's list back and unregisters the task and stops if anyone but Administrators or SYSTEM has more than read and run.
-ExecutionPolicy Bypass is PowerShell's script-signing setting, not UAC. It's there so the task can run unsigned local scripts. The real protection is that only admins can change those scripts.

4. Install it from an admin window. Open PowerShell with Run as administrator and run:

powershell -NoProfile -ExecutionPolicy Bypass -File "$env:USERPROFILE\WinSetup\install-admin-tasks.ps1"

You should see the five tasks listed as Ready.

5. Start a task from your normal account (a regular, non-elevated PowerShell window), then read its log:

Start-ScheduledTask -TaskPath '\WinSetup\' -TaskName 'Check'
Start-Sleep 10
Get-ChildItem C:\ProgramData\WinSetupAdmin\logs | Sort-Object LastWriteTime | Select-Object -Last 1 | Select-String 'RESULT'

You want RESULT: Check exit 0. Open the whole log if it says anything else.

6. Test the boundary from your normal account. All three should print "blocked." If any prints "ALLOWED," stop and fix the permissions before you hand the menu to anything.

try { Set-Content C:\ProgramData\WinSetupAdmin\probe.txt 'x' -EA Stop; 'WRITE ALLOWED (bad)' } catch { 'write blocked' }
try { Add-Content C:\ProgramData\WinSetupAdmin\runner.ps1 '#' -EA Stop; 'EDIT ALLOWED (bad)' } catch { 'edit blocked' }
$svc = New-Object -ComObject Schedule.Service; $svc.Connect()
try { $d = $svc.GetFolder('\WinSetup').GetTask('Check').Definition; $d.RegistrationInfo.Description = 'probe'
      $svc.GetFolder('\WinSetup').RegisterTaskDefinition('Check', $d, 4, $null, $null, 3) | Out-Null; 'TASK EDIT ALLOWED (bad)' } catch { 'task edit blocked' }

7. Run external tools as their own process, with a time limit, and check the exit code. If one misbehaves, read the tool's own log before you blame it. In my tweaks script that looks like this:

# --enable must be the only option; adding --disable-interactivity makes winget exit with a usage error
$wg = Start-Process winget -ArgumentList 'configure','--enable' -WindowStyle Hidden -PassThru
if (-not $wg.WaitForExit(300000)) { $wg.Kill(); 'winget configure --enable timed out after 5 min (skipped)' }
elseif ($wg.ExitCode -ne 0) { "winget configure --enable exited with $($wg.ExitCode); check winget's log" }

winget writes its logs under %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir.

Caveats

This narrows what silent admin can do; it doesn't sandbox anything. Anything running as you can start these five tasks, so make sure every action is something you'd be fine with it starting at any time. Microsoft doesn't treat UAC as a security boundary either, so think of this as shrinking the blast radius from "anything" to "five verbs."
The menu is only as narrow as the scripts behind it. "Apps" really means "install whatever is in apps.json," which is why the list lives in the protected folder too.
Watch what the scripts call. winget resolves through a per-user folder, so any action that runs it trusts that folder. Keep the list of outside tools short.
Changing anything means rerunning the installer elevated. That's the approval step, and it's on purpose.
Undo everything from an admin window: Get-ScheduledTask -TaskPath '\WinSetup\' | Unregister-ScheduledTask -Confirm:$false; Remove-Item C:\ProgramData\WinSetupAdmin -Recurse

My OneDrive's problem was 322,219 files, not 268 GB

Mikhail Predtetchenski — Sat, 31 Oct 2026 23:36:27 +0000

Case file

Incident: Oct 25, 2026
Symptom: I wanted a folder plan for OneDrive. Instead I had a growing audit-tool spec, scripts with bugs, a 218 MB report I couldn't use, and later OneDrive saying "there are too many files in your "OneDrive" folder."
Evidence: the fixed audit counted 322,219 files and 105,150 folders (267.82 GB). All but 14 files were online-only. One local code repo held 296,714 of those files but only about 2.4 GB.
Cause: a code repo with git worktrees and node_modules was syncing inside OneDrive. Getting there took longer than it should have because the audit's scope kept growing (classifiers, clustering, checkpoints, ZIP packaging) before any version had produced an inventory I could use. Separately, the duplicate step crawled on that many files, most likely because of Group-Object.
Fix: narrowed the job to "fix the existing script and get one complete run." Rewrote the audit (never download online-only files, log errors, write output outside OneDrive, Dictionary grouping, progress bars), then deleted the repo.
Prevention: keep code repos out of OneDrive, check item counts and not just GB (Microsoft recommends syncing no more than 300,000 items), and ask for the smallest script that answers the question before adding features.
Lesson: fix and run the narrow thing first. One honest full run answered what the spec was designing around. And OneDrive cares about how many items it tracks; size was never the issue.

The story

This started as a cleanup, not a coding project. I asked Microsoft 365 Copilot to help me redo how my files are organized, starting with OneDrive, because I wanted to cut down the mental clutter of never knowing where anything lives. It proposed PARA (Projects, Areas, Resources, Archive). I wanted to keep the folders Windows already ships with, like Documents, Pictures, Music, and Videos, so we settled on a hybrid: Windows' libraries for media, and PARA-style folders next to them for everything else.

To design that hierarchy, Copilot wanted an inventory, and it laid out options from a folder list up to "Option 3: Full Digital Archaeology." It actually recommended the middle one. I picked Option 3. Then I asked whether it could see any content or metadata, and it described levels of visibility up to content previews. Then I asked for one script that pulled everything. So I said yes to a lot of the scope myself.

After that, each turn added more. The first script had a typo, so I asked Copilot to fix it and review the rest before writing a new one. It came back with a plan for "a production-grade audit script," and noted that a truly comprehensive one "gets large quickly (500-1000+ lines if done cleanly)," with SHA256 verification, ZIP packaging, parallel hashing, and Git and Obsidian detection. I asked it to plan v2 before writing it. The plan added a classifier, topic and project clustering, privacy levels, and a resume and checkpoint strategy. Copilot itself suggested freezing the scope there, and I agreed: "Freeze it. Write the ps1." It said a script that size should be a file, not a chat message, and told me the exact request to send for a downloadable .ps1. I sent it. The v2 it delivered came labeled as a "v2-alpha," with 13 features listed as still missing.

So I took v2 to QA bot, one of my own Grok Bot assistants at the time (it was later rebuilt as Inspector, which is part of how it started), with a narrower question: would this actually run? It would, but it had problems:

It saved its report to $HOME\Desktop. With my Desktop backed up to OneDrive, that isn't my real Desktop, so I'd never have seen the report. And the obvious fix, the real Desktop, is inside OneDrive, where the report would show up in its own scan.
The content-preview option ran Get-Content on online-only files, which makes OneDrive quietly download every one of them.
$ErrorActionPreference='SilentlyContinue' meant anything it couldn't read just vanished from the counts.
-HashDuplicates was declared and never used.
If nothing was a duplicate, it never wrote the duplicates CSV.

I got a fixed v3 back and showed it to Copilot. Its review was fair. It called v3 "a significant improvement over the version I generated" and singled out the output-outside-OneDrive fix and the cloud-only handling. Then it proposed a v3-beta, said again it would likely run 500-1000+ lines, and generated it. That one also came with a list of what was missing, including checkpoint/resume and memory optimizations for libraries over 100,000 files.

v3-beta ran. While it did, I asked Copilot what upload size it could handle. It said it didn't have "a published hard limit" and gave rough ranges. The output came to 218 MB. The biggest pieces were Files.csv at about 80 MB and AgeAnalysis.csv at about 59 MB. Copilot's read of that output was accurate: it called AgeAnalysis.csv a "redundant data explosion; essentially re-listing every file" that should have been a few-KB summary. It also guessed my OneDrive held around 100,000 files. The real number turned out to be more than three times that.

At that point I had a lot of plans and still no hierarchy, so I changed approach. I went back to QA bot with one job: get one complete run I could trust.

It went through v3-beta. The new reports were genuinely good: empty folders, folders with more than 1,000 files, folder sizes, files older than five years, and common words in file names. But v3-beta had also broken things that already worked. The preview switch did nothing again. Scan errors were collected and never written anywhere. Duplicate hashing hashed every single file instead of only same-size ones, built its list with $hashed += (which copies the whole array on every add), and flagged every empty file as a duplicate of every other one. The folder tree, the age breakdown, and the total size dropped out of the summary. And its CSV-safety function rewrote real file names that start with - or @. So we kept v3 as the base and merged Copilot's five reports in properly. That was v3.1.

v3.1 ran, and then it seemed to stop. The output folder had 12 files, then sat there. Task Manager showed pwsh at 2.6 GB of memory. Twelve minutes later it was still going. The 12th file was the file-name topics report, which meant it was on the duplicate step, and that step used Group-Object Name, Length across every file. Group-Object gets very slow at that scale, so it was the likely culprit. v3.2 swapped it for a plain Dictionary keyed on name and size. It also added a live progress bar to the scan and every long step, plus a "Done in hh:mm:ss" line, so I'd never again be staring at a silent window wondering whether it was dead.

v3.2 finished in about 11 minutes with zero skipped paths. On this run the duplicate step took about a minute.

The numbers:

322,219 files in 105,150 folders, 267.82 GB
322,205 of those files online-only, so the scan read metadata and downloaded nothing
Pictures: about 251 GB, including 78 GB in just 13 Google Takeout zips
Top file types by count: .html, .pf_fragment, .js, .ts

That last line didn't look like my stuff. It was one local code repo, git worktrees and their node_modules included, with 296,714 files. That's about 92% of every file in my OneDrive, and it took up only about 2.4 GB, less than 1% of the space.

I'd already decided all code could leave OneDrive, so the repo got deleted. Deleting the files locally took about two and a half minutes. An empty top folder stayed behind because another app still had it open. That was the easy part.

A few hours later I asked why it was still deleting files. It wasn't my delete. It was OneDrive telling the cloud about every one of those roughly 297,000 deletions. Then OneDrive popped up: "there are too many files in your "OneDrive" folder." QA bot explained that the warning is about how many items OneDrive tracks, not about storage. Microsoft recommends syncing no more than 300,000 items, files and folders together, and says performance can suffer past that. It's a guideline, not a hard cap, but my audit had counted about 427,000. Once the deletions finished syncing I'd be down to about 25,000 files. When I wrote this up that morning, more than three hours after the delete, OneDrive was still working through them.

So the 268 GB number I'd been worried about was mostly photos, and that's a normal storage problem. The thing actually slowing OneDrive down was a 2.4 GB folder. No classifier or clustering engine found that. A script that finished, and a summary I actually read, did.

Do it yourself

These snippets are trimmed from my v3.2 script. Run them in order in one PowerShell window (Windows PowerShell 5.1 or PowerShell 7, no admin needed), since each step uses variables from the one before. Steps 1 to 6 only read OneDrive (step 3 writes one error CSV outside it). Step 7 deletes.

1. Find OneDrive and keep the report out of it. With Known Folder Move on, $HOME\Desktop is the old, unused folder. [Environment]::GetFolderPath('Desktop') returns the Desktop you actually see, which may be inside OneDrive, so check before writing there.

foreach ($candidate in @($env:OneDrive, $env:OneDriveCommercial, $env:OneDriveConsumer)) {
    if ($candidate -and (Test-Path -LiteralPath $candidate)) { $OneDrivePath = $candidate; break }
}
$desktop = [Environment]::GetFolderPath('Desktop')
$inOneDrive = $desktop -and $desktop.StartsWith($OneDrivePath.TrimEnd('\') + '\', [StringComparison]::OrdinalIgnoreCase)
if ($desktop -and -not $inOneDrive) { $OutputDir = $desktop } else { $OutputDir = $env:USERPROFILE }

2. Flag online-only files instead of opening them.

$RecallOnDataAccess = 0x400000
$RecallOnOpen       = 0x40000
function Test-CloudOnly($Item) {
    $a = [int]$Item.Attributes
    return (($a -band $RecallOnDataAccess) -ne 0) -or (($a -band $RecallOnOpen) -ne 0) -or
           (($a -band [int][IO.FileAttributes]::Offline) -ne 0)
}

Skip hashing and previews for anything this returns $true for.

3. Scan with errors logged and a live count. Do not use Get-ChildItem -Recurse on Windows PowerShell 5.1: it follows directory junctions and directory symlinks, which can count the same files twice (for example pnpm-style node_modules links) or walk outside OneDrive. That wasn't what inflated my count; the repo really had that many files. PowerShell 7 only follows them if you pass -FollowSymlink. This walk lists every item, including the link folder itself, and descends into every folder except junctions and symlinks. It checks LinkType rather than the ReparsePoint attribute because online-only OneDrive folders are reparse points too, and skipping those would leave their contents out of the count.

$scanErrors = @()
$allList = New-Object 'System.Collections.Generic.List[object]'
$dirs = New-Object 'System.Collections.Generic.Queue[string]'
$dirs.Enqueue($OneDrivePath)
while ($dirs.Count -gt 0) {
    $dir = $dirs.Dequeue()
    Get-ChildItem -LiteralPath $dir -Force -ErrorAction SilentlyContinue -ErrorVariable +scanErrors |
        ForEach-Object {
            $allList.Add($_)
            if ($allList.Count % 2000 -eq 0) {
                Write-Progress -Activity 'Scanning OneDrive' -Status "$($allList.Count) items"
            }
            if ($_.PSIsContainer -and $_.LinkType -notin 'Junction', 'SymbolicLink') {
                $dirs.Enqueue($_.FullName)
            }
        }
}
Write-Progress -Activity 'Scanning OneDrive' -Completed
$fileRows = @($allList | Where-Object { -not $_.PSIsContainer })
$scanErrors | ForEach-Object { [pscustomobject]@{ Path = $_.TargetObject; Error = $_.Exception.Message } } |
    Export-Csv (Join-Path $OutputDir 'onedrive-scan-errors.csv') -NoTypeInformation
"Skipped paths: $($scanErrors.Count)"

SilentlyContinue is fine here because -ErrorVariable still collects every skipped path, and the CSV shows you what's missing from the counts.

4. Group duplicates with a Dictionary, not Group-Object.

$byNameSize = New-Object 'System.Collections.Generic.Dictionary[string,System.Collections.Generic.List[object]]' ([System.StringComparer]::OrdinalIgnoreCase)
foreach ($f in $fileRows) {
    $key = $f.Name + '|' + $f.Length
    $list = $null
    if (-not $byNameSize.TryGetValue($key, [ref]$list)) {
        $list = New-Object 'System.Collections.Generic.List[object]'
        $byNameSize[$key] = $list
    }
    $list.Add($f)
}
$dupeGroups = @($byNameSize.Values | Where-Object { $_.Count -gt 1 })
"Name + size matches: $($dupeGroups.Count) groups"

5. If you hash, hash only files that share a size with another file. Empty files all "match" each other, and online-only files would download, so leave both out.

$sizeCount = @{}
foreach ($f in $fileRows) { $sizeCount[[long]$f.Length] = 1 + [int]$sizeCount[[long]$f.Length] }
$toHash = @($fileRows | Where-Object { $_.Length -gt 0 -and $sizeCount[[long]$_.Length] -gt 1 -and -not (Test-CloudOnly $_) })
"Files worth hashing: $($toHash.Count)"

6. Count items, not just gigabytes. Files plus folders is the number Microsoft's 300,000-item sync recommendation is about.

$folderCount = $allList.Count - $fileRows.Count
$gb = ($fileRows | Measure-Object Length -Sum).Sum / 1GB
'{0:N0} files + {1:N0} folders = {2:N0} items, {3:N2} GB' -f $fileRows.Count, $folderCount, $allList.Count, $gb

No script handy? Right-click the OneDrive folder in File Explorer, pick Properties, and read the Contains line. That's Microsoft's own quick check, and it counts the local folder only.

7. Deleting a big folder. I used rd with the long-path prefix. Close anything that has the folder open first (editors, terminals, dev servers).

$repo = Join-Path $OneDrivePath 'path\to\the-repo'   # set this to the exact folder
cmd.exe /c rd /s /q "\\?\$repo"

Caveats

Start small. Ask for (or write) the smallest script that answers your actual question, run it on the whole thing, and only then add features. Classification, clustering, and checkpoints can wait until a full run shows you need them.
Reading an online-only file's contents (previews, Get-FileHash, Get-Content) downloads it. On a mostly cloud OneDrive, that can mean a lot of downloading.
rd /s /q doesn't ask, and it skips the Windows Recycle Bin. Double-check $repo first.
Deletions inside OneDrive still sync to the OneDrive recycle bin online. You can restore from there for 30 days on a personal account (93 on work or school, unless an admin changed it). Don't count on it as a backup.
Deleting locally is quick. Syncing hundreds of thousands of deletions to the cloud can take hours. Leave OneDrive running, and don't re-run the audit until it says it's up to date.
The 300,000-item number is Microsoft's performance guideline, not a hard limit. Past it, expect slow syncing, not lost files.
The scan holds every item in memory. Mine had pwsh at 2.6 GB with about 427,000 items.
Junction and symlink folders still appear in the inventory once. Their targets are not walked, so linked folders are not counted twice and a link out of OneDrive is not followed. Online-only cloud folders are walked normally.

Windows Update pushed an AMD chipset driver over mine and broke boot

Mikhail Predtetchenski — Sat, 31 Oct 2026 09:21:28 +0000

Case file

Symptom: after a fresh Windows 11 Pro install plus Gigabyte chipset drivers, Windows Update ran, the PC restarted, and it got stuck in a boot loop that ended in Automatic Repair.
Evidence: SrtTrail.txt said "a recent driver update installation could be preventing Windows from starting." Update history showed "AMD - System 20.50.0.0" installed at 3:07 AM.
Likely cause: Windows Update installed its own AMD driver for the CPU's PCIe root ports on top of the vendor chipset package. No dump or boot log survived from the failed boots, but the repair log, the timing and the rollback all point there.
Fix: Startup Repair uninstalled that driver on its own; Continue booted normally.
Prevention: ExcludeWUDriversInQualityUpdate = 1, plus crash-evidence settings: keep dumps, AutoReboot off, boot logging, and a startup task that copies dumps aside. Settings verified live; the copy task hasn't had a crash to catch yet.
Lesson: run Windows Update before vendor drivers, or block its drivers entirely.

The story

I'd just reinstalled Windows 11 Pro on my desktop (Ryzen 9 5900X on a Gigabyte X570 AORUS MASTER, RTX 5070 Ti). I did the responsible-adult thing and installed the chipset drivers straight from Gigabyte's site, then the NVIDIA Studio driver. Then I ran Windows Update. In hindsight, that probably should have been step one.

A couple of updates went in, the PC restarted, and then nothing. Black screen. I honestly thought I wasn't even getting POST. I hard-shut it down, tried again, same thing, and after a few rounds Windows gave up and showed "Automatic Repair" with something about SrtTrail.txt. It cycled like that until it dropped me at a recovery screen, where I just hit Continue and Windows loaded like nothing had happened.

It worked, but I wanted to know why, so I had dr eggbot, the Grok Bot I was working with that night, pull three things: the Startup Repair log, the Windows Update history, and the boot and crash events from the System log.

The repair log was the jackpot. It listed exactly one cause: "a recent driver update installation could be preventing Windows from starting." Update history filled in the rest. At 3:07 AM, Windows Update had installed "AMD - System 20.50.0.0," a driver for the CPU's PCIe root ports, right on top of the Gigabyte package I'd just put on. Startup Repair's fix was to uninstall it, which is why Continue worked. Checking afterward, those root ports were back on Microsoft's standard driver, Device Manager had no problem devices, and my Gigabyte AMD drivers were still in place.

One correction to my own story: a Windows driver can't stop the board from POSTing. Most likely the hang came right after POST while the screen was still dark, and my hard shutdowns are what kicked off Automatic Repair after a couple of tries.

There was a side quest. Earlier that night, after the first batch of updates (Realtek, Intel Bluetooth, Logitech), Windows had blue-screened with 0x4E PFN_LIST_CORRUPT. That one usually means a misbehaving driver, and less often RAM, and the logs alone couldn't say which. The event log said a dump had been saved to C:\Windows\Minidump. I went to look. Empty. I ran a search of the other places Windows sometimes stashes a copy, from an admin window. Nothing. The dump was gone, and I dropped it: one crash in the middle of a big driver shuffle, and it hadn't come back. If another 0x4E shows up, a memory test is next.

The real fix is boring: stop Windows Update from sending drivers at all. I install mine from Gigabyte and NVIDIA anyway. That's one policy value, ExcludeWUDriversInQualityUpdate. I set it by hand on this PC, and it's also in my tweaks script so a fresh install never repeats this. Security and feature updates still come through. Later that morning, Bench Tech, a PC-maintenance Grok Bot built to look after this machine, ran its first health check and confirmed the block was still on.

Losing that dump bugged me, though, so I asked the follow-up question: if this happens again, how do I catch the evidence before it disappears? It turns out that in a boot loop, Windows holds the crash data in the page file and only writes it out as a dump file on the next successful boot. So the setup now (confirmed with the script's own check, which came back "All settings match."):

keeps the memory dump even when disk space is low, and saves an automatic memory dump (MEMORY.DMP) alongside the small one
stays on the blue screen instead of instantly rebooting, so I can take a phone photo of the stop code
turns on boot logging, so if a boot hangs with no blue screen, ntbtlog.txt gives me something to compare against a good boot
runs a startup task a minute after every boot that copies any new dump into a folder cleanup tools don't touch

Do it yourself

These are PowerShell commands. Anything that writes to HKLM, bcdedit, or registers a SYSTEM task needs an elevated PowerShell window.

1. Read the Startup Repair log.

Get-Content C:\Windows\System32\LogFiles\Srt\SrtTrail.txt

Look for the root cause line. Mine named "a recent driver update installation." If you're still stuck in recovery, open Troubleshoot > Advanced options > Command Prompt and run type C:\Windows\System32\LogFiles\Srt\SrtTrail.txt instead (that's cmd, not PowerShell). In recovery the Windows drive can have a different letter, so try D: if C: doesn't have it.

2. Check what Windows Update installed, and when.

$s = New-Object -ComObject Microsoft.Update.Session; $h = $s.CreateUpdateSearcher()
$h.QueryHistory(0,25) | ForEach-Object { '{0:yyyy-MM-dd HH:mm}  result={1}  {2}' -f $_.Date.ToLocalTime(), $_.ResultCode, $_.Title }

Line the timestamps up against your failed boot. result=2 means it installed, 3 installed with errors, 4 failed.

3. Look for an earlier bugcheck.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001; ProviderName='Microsoft-Windows-WER-SystemErrorReporting'} -MaxEvents 3 -EA SilentlyContinue | ForEach-Object { $_.TimeCreated; $_.Message }

4. Stop Windows Update from installing drivers. This is the same as the Group Policy "Do not include drivers with Windows Updates."

$wu = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
if (-not (Test-Path $wu)) { New-Item -Path $wu -Force | Out-Null }
New-ItemProperty -Path $wu -Name ExcludeWUDriversInQualityUpdate -Value 1 -PropertyType DWord -Force | Out-Null

5. Keep crash evidence.

$cc = 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl'
New-ItemProperty $cc -Name CrashDumpEnabled -Value 7 -PropertyType DWord -Force | Out-Null      # automatic memory dump (MEMORY.DMP + minidump)
New-ItemProperty $cc -Name AlwaysKeepMemoryDump -Value 1 -PropertyType DWord -Force | Out-Null  # don't delete MEMORY.DMP when disk space is low
New-ItemProperty $cc -Name AutoReboot -Value 0 -PropertyType DWord -Force | Out-Null            # stay on the blue screen so you can read the stop code
bcdedit /set '{current}' bootlog yes          # writes C:\Windows\ntbtlog.txt at boot

Reading ntbtlog.txt takes a little care. Every boot adds its own section to the end (a version line, then a timestamp), so cut out just the failed boot's section first. Its last few lines are leads, not a verdict. The log records what Windows decided to load ("Loaded driver" / "Did not load driver"), not which driver hung. A better test: drop the "Did not load driver" lines from the failed boot's section and from a Safe Mode boot's section, then compare the two. Drivers that only load in the normal boot are your suspects. If the failed boot has no section at all, or an empty one, the hang came before Windows could write the log to disk, and the log can't help with that one.

6. Copy dumps aside at every startup. Create the folder first (New-Item C:\ProgramData\WinSetup -ItemType Directory -Force), then save this as C:\ProgramData\WinSetup\save-dumps.ps1:

$vault = 'C:\CrashVault'
New-Item $vault -ItemType Directory -Force | Out-Null
Get-ChildItem 'C:\Windows\Minidump\*.dmp' -ErrorAction SilentlyContinue | ForEach-Object {
  $dest = Join-Path $vault $_.Name
  if (-not (Test-Path $dest)) { Copy-Item $_.FullName $dest }
}
$mem = Get-Item 'C:\Windows\MEMORY.DMP' -ErrorAction SilentlyContinue
if ($mem) {
  $dest = Join-Path $vault ('MEMORY-{0:yyyyMMdd-HHmmss}.DMP' -f $mem.LastWriteTime)
  if (-not (Test-Path $dest)) { Copy-Item $mem.FullName $dest }
}

Then register it to run as SYSTEM one minute after boot:

$act  = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-NoProfile -ExecutionPolicy Bypass -File "C:\ProgramData\WinSetup\save-dumps.ps1"'
$trig = New-ScheduledTaskTrigger -AtStartup; $trig.Delay = 'PT1M'
Register-ScheduledTask -TaskName 'SaveCrashDumps' -Action $act -Trigger $trig -User 'SYSTEM' -RunLevel Highest -Force | Out-Null

Caveats

With the driver policy on, you own driver updates. Get chipset and GPU drivers from the vendor yourself.
Dumps only land after a successful boot. The startup task catches them then, before cleanup can.
MEMORY.DMP can be several GB; the script names each copy by timestamp so it isn't re-copied every boot.
ntbtlog.txt keeps growing while boot logging is on.
With AutoReboot off, the PC sits on the blue screen until you restart it. Photograph the stop code and any driver name first.

How it started: nine bots in a week, then back to one

Mikhail Predtetchenski — Sat, 31 Oct 2026 06:38:54 +0000

Case file

Symptom: I wanted AI help with my PC and my projects, and a public record of it, without designing a whole system up front or tracking everything by hand.
Evidence: one week, one Windows PC, and a pile of chats: one bot on the first night, three by sunrise, seven by the next morning, nine by the end. Fourteen draft entries sat in pull requests, none of them merged.
Cause: every bot was added for a real reason, but each one was another chat to visit, another set of instructions to keep current, and another place for work to get stuck. And I had the team architect minting new bots before I fully understood what we were building.
Fix: on October 30, 2026 I deleted the whole team and handed the build log to one bot, HQ. It's my main workbench, and this log is a byproduct of the work I do there.
Prevention: the rules the team taught me stay, even with one bot: evidence before structure, one job per role with written anti-jobs, a checker that owns no code, a second round of arguing, real fixes as the only content, code for anything with no judgment in it, and respect for how much context one bot can hold.
Lesson: the team was the scaffolding. The rules are what I'm keeping.

The story

Night one: Patient Zero

At 1:59 AM on Saturday, October 24, I opened a chat with dr eggbot, a Grok Bot whose whole job is designing other Grok Bots, and gave it a strange first message:

Let's consider you "Patient Zero." I don't yet know what kind of bot I want or need yet. It will emerge at your discretion based on what I ask of you.

I didn't want to spec out a team I'd never used. dr eggbot turned that into a rule: when the same kind of ask came back a few times, it would tell me which bot it should become, and I'd say yes or no.

Ten minutes later my freshly reinstalled Windows 11 PC became "Patient One," and the night turned into real work: setup scripts I could rerun, a boot loop caused by a Windows Update driver, crash dumps that actually stick around, and a small menu of admin tasks the assistant could start but not edit. Around 4:21 AM I added a side note: I wanted all this to turn into a public journal, a portfolio, without tracking it by hand. By 5:23 AM dr eggbot had made the first new bot, Case Notes, which turns real sessions into entries and never publishes anything itself.

At 6:16 AM I asked whether there was enough for a bot to run the build-log sessions. I was half expecting a do-anything worker. dr eggbot said no to that and yes to something narrower: nearly every case so far had been my PC, and "a general 'do any session' bot would just duplicate me." At 6:18 AM Bench Tech existed, with one machine to look after and a list of things it must never do without my yes: restarts, BIOS, firmware, driver installs, apps I didn't ask for.

Then I nearly added a third bot for no reason. Should Case Notes draft and publish, or should a publisher bot do that? dr eggbot said publishing "is fixed steps with no judgment in them, so code does it more reliably than a bot." The bot I was tempted to add turned out to be a GitHub Action. By sunrise I had three bots, each with one job.

Night two: lanes

By early Sunday I had five: dr eggbot, Bench Tech, Case Notes, and two I was still testing.

One was QA bot. It came from a marketplace template built to gate production deploys, and I'd been using it to check PowerShell that Microsoft 365 Copilot wrote for me. When I tried to say what it was for, the honest word was "confusing." Sorting that out gave me a rule: bots that write code are makers, one bot checks, and the checker owns no code. QA bot was rebuilt as Inspector: verdict first, findings marked proven or reasoned, a minimal patch handed back and never applied.

The other was Grok Sparring. It takes a question to Grok on grok.com, pushes back on the first answer, and brings back one settled answer plus a list of what nobody verified. In one night of four rounds, Grok reversed itself once, dropped a bad idea once, and cited sources nobody had checked. Every bit of the value was in round two.

At 3:50 AM, with five bots and a dozen open threads, I typed that I was "jumping between things, getting confused, and getting a little frustrated with myself." dr eggbot's answer is the line I remember most from the whole week:

getting lost isn't a you problem. there's just no one bot whose job is the big picture.

So the big picture got a lane. Front Desk tracked and routed work but couldn't create bots. dr eggbot stretched from "bot minter" to "team architect." Stacks became the librarian for private notes. Every bot got the same two standing rules: off-scope asks get a short answer plus a quiet note to the architect, and half-formed ideas get parked with Stacks. By 4:45 AM it was, in the team page's own words, "seven bots, split into lanes: one front door, three makers, one checker, one second opinion, and an architect."

The rest of the week

The last two showed up the way the rest did, some on the same day and some spread over a few days. I honestly don't remember the exact order. One was Student Discount Finder. The other was Hermes Agent Fixer. Neither came from a pile of repeated asks. I just liked the idea that every bot should have its own lane, so that when one conversation got long, the history wouldn't be stuck in one place and another bot could pick it up.

The build log itself came out of that week too. A PRD I'd been handed for an "autonomous content engine" wanted ten channels, affiliate links, daily posts "even when no article is released," and 50 articles in six months. It got called what it was, a content farm. What survived is one markdown file per real problem, a pull request, and my merge as the only approval. My own words from that session are basically this log's mission statement: "Errors come up through some course of work, the process of fixing it becomes the content."

By the end of the week the team had drafted fourteen entries. All of them were still open pull requests. None had shipped.

October 30: back to one

On October 30, 2026 I deleted all nine bots.

What tipped it: I had the librarian, Stacks, start working with the debate partner, Grok Sparring, to go outside the platform and ask for more revisions to my Obsidian vault. What came back were revisions I couldn't follow. When I can't follow what my own bots did to my own notes, there are too many of them.

The work moves to one bot, HQ. It's my main workbench: I do the actual work there, and this build log is a byproduct of that work instead of a separate team's job. Its first act was a survey of what the team left behind: an Astro site that had never published a post, fourteen draft pull requests, and a cross-posting pipeline that had never run. The plan: a running log page, this retro, then the three drafts closest to done, then archive the rest as attempt #1.

Deleting the team doesn't mean the week was wasted. Nearly every rule I'd keep came out of a specific moment with a specific bot. I just don't need nine chats to follow them. Less is more.

Do it yourself

These are the seven rules I'm keeping. They work with one assistant or with ten.

1. Evidence before you add a bot. Start with one general assistant and tell it the rule:

I don't know what bots I need yet. Do the work yourself.
When the same kind of ask comes back two or three times,
tell me which bot it should become, and I'll say yes or no.
Don't suggest a bot on a single ask.

When it proposes one, ask what asks it's counting. "Nearly every case was this one PC" is evidence. "You might want..." isn't. The flip side: if the asks stop coming, the bot shouldn't exist anymore either.

2. One job per bot, with written anti-jobs. For every bot (or every role, if you only have one bot), write one line for its job and a short list of what it never does:

Role	One job	Never does
PC tech	keeps one Windows PC healthy	restarts, BIOS, firmware, or driver installs without a yes
Writer	drafts entries from real sessions	publishes or merges on its own; invents steps or numbers
Checker	reviews code and scripts	applies, pushes, merges, or deploys
Second opinion	pressure-tests a question with another AI	acts on that AI's advice

3. Makers and one checker. Whoever writes the code owns it and is the only one who changes it. The checker owns nothing and reviews everything: verdict first, each finding marked proven or reasoned, a minimal patch handed back and never applied. A bot checking its own work misses things.

4. Argue for a second round. Don't act on a first answer. Push back with specifics (your own rules, its sources, the smallest version that would work), then keep a short list of what nobody verified:

Here's your answer. Push on it:
- Does it break any rule you set in the same answer?
- Which sources did you actually check?
- What's the smallest version of this that would work?
Give me one settled answer, what changed, and what's still unverified.

5. The process of fixing is the content. If you want your work to double as a portfolio, publish the real problem and the real fix, one entry per case, and make your own merge the only approval. No daily filler, no affiliate links, no fifty-articles goal.

6. Code over bots for deterministic jobs. If a step has no judgment in it, like publishing on merge or cross-posting, use a CI job or a script. A bot in that spot is one more thing that can go wrong.

7. Don't underestimate context. Know how much one bot can hold and still be useful before another has to take over. A long conversation slowly stops being useful, and that limit arrives sooner than you'd think. Splitting into bots doesn't fix it either: you just get more places to lose track. Plan for the handoff (a short written summary, a log, a pull request) before you need it.

Caveats

"Two or three asks" is a judgment call. Count on purpose.
More bots means more instructions to keep in sync, and more chats to check. Every split has a cost; the rules above are worth more than the count.
If you share bot instructions publicly, strip out machine names, usernames, and folder paths first.