diff --git a/docs/mtconnect-followup-runbook.md b/docs/mtconnect-followup-runbook.md
new file mode 100644
index 0000000..2d0f450
--- /dev/null
+++ b/docs/mtconnect-followup-runbook.md
@@ -0,0 +1,233 @@
+# MTConnect follow-up runbook
+
+Written 2026-08-11. Everything here needs a machine this box cannot reach - the
+SFLD share, the middle-man PC, or a shopfloor bay - so it is yours to run.
+
+Work in the order given. Part 1 changes what future installs get; parts 2 and 3
+fix bays that are already wrong; parts 4 and 5 are questions to answer before
+any more code is written.
+
+---
+
+## Part 1. Push the Fanuc adapter 3.25.3 to the SFLD share
+
+The staged bundle here is already on 3.25.3.0 (`sha256` starts `6e46dcd51affa9e0`).
+The live share is not. Until this is copied, new installs still get 3.23.0.0.
+
+**1.1** From the middle-man PC, with `Z:` on the dev share:
+
+```
+Z:\mtconnect-bundles\fanuc\Adapter\
+```
+
+should contain `FanucCppAdapterWinX64.exe` at **3,369,984 bytes**. Confirm before copying:
+
+```powershell
+(Get-Item Z:\mtconnect-bundles\fanuc\Adapter\FanucCppAdapterWinX64.exe).Length
+(Get-FileHash Z:\mtconnect-bundles\fanuc\Adapter\FanucCppAdapterWinX64.exe -Algorithm SHA256).Hash.Substring(0,16)
+# expect 3369984 and 6E46DCD51AFFA9E0
+```
+
+**1.2** Back up what is on the share now, then copy the three files:
+
+```powershell
+$share = '\\tsgwp00525.wjs.geaerospace.net\shared\dt\shopfloor\main\machineapps\mtconnect-bundles\fanuc\Adapter'
+Copy-Item $share\FanucCppAdapterWinX64.exe "$share\..\FanucCppAdapterWinX64-3.23.0-replaced-$(Get-Date -f yyyyMMdd).exe"
+Copy-Item Z:\mtconnect-bundles\fanuc\Adapter\FanucCppAdapterWinX64.exe $share -Force
+Copy-Item Z:\mtconnect-bundles\fanuc\Adapter\Fwlib64.dll  $share -Force
+Copy-Item Z:\mtconnect-bundles\fanuc\Adapter\fwlibe64.dll $share -Force
+```
+
+**1.3** Verify on the share:
+
+```powershell
+(Get-FileHash $share\FanucCppAdapterWinX64.exe -Algorithm SHA256).Hash.Substring(0,16)   # 6E46DCD51AFFA9E0
+```
+
+`adapter.xml` is deliberately NOT copied. The config vocabulary is identical
+between 3.23 and 3.25.3, and the share's copy carries site settings.
+
+**Rollback:** copy the `-3.23.0-replaced-` file back over `FanucCppAdapterWinX64.exe`.
+
+---
+
+## Part 2. Fix the two Makino bays
+
+Both have the agent on the machine number and the other three files still on
+`MAKINO-1`. The fixed `Update-MachineNumber.ps1` converges them.
+
+| PC | machine number |
+|---|---|
+| `G5W5V7V3ESF` | 7502 |
+| `G4H8KF33ESF` | 7506 |
+
+**2.1** On the bay, elevated PowerShell:
+
+```powershell
+. C:\GE Aerospace\lib\Update-MachineNumber.ps1     # or wherever the lib landed
+$r = Update-MTConnectVariantName -NewNumber '7502' `
+      -Root 'C:\Makino-MTConnect' `
+      -Targets @(
+        @{ Path='Agent\Devices.xml';        Kind='attr' },
+        @{ Path='Agent\Devices.EDM.xml';    Kind='attr' },
+        @{ Path='Data\AdapterDataFile.xml'; Kind='name' },
+        @{ Path='Agent\Agent.cfg';          Kind='cfg'  }
+      ) `
+      -Services @('Makino Adapter Manager','Makino MTConnect Agent')
+$r.Updated; $r.Errors
+```
+
+Use the bay's own number - do not paste 7502 onto 7506.
+
+**2.2** Verify all four agree, and nothing still says MAKINO:
+
+```powershell
+Select-String -Path C:\Makino-MTConnect\Agent\Devices.xml,`
+                    C:\Makino-MTConnect\Agent\Devices.EDM.xml,`
+                    C:\Makino-MTConnect\Data\AdapterDataFile.xml,`
+                    C:\Makino-MTConnect\Agent\Agent.cfg `
+             -Pattern 'MAKINO-\d+|7502'
+```
+
+**2.3** Confirm it is serving:
+
+```powershell
+(Invoke-WebRequest http://localhost:5000/current -UseBasicParsing).Content -match '<MTConnectDevices'
+```
+
+**Watch for:** the vendor guide says the Adapter Manager rewrites its whole
+configuration from memory when it stops. The function stops it first, but this
+has never been proven on real hardware. If the names revert after a reboot,
+stop here and tell me - that changes the approach.
+
+---
+
+## Part 3. Fix the seven Fanuc bays
+
+The agent and the adapter disagree. Three have a correct agent and a stale
+adapter; four have no agent device name at all and need looking at before any
+rename (Part 4).
+
+**Rename these three** - the map column is the authoritative number:
+
+| PC | adapter says | agent says | correct number |
+|---|---|---|---|
+| `G9N2JNZ3ESF` | 4007 | 7801 | **7801** |
+| `GG1J98Y3ESF` | 3031 | 7804 | **7804** |
+| `GC7ZN7V3ESF` | 2005 | 2006 | **2005** (per hostname map - confirm at the bay) |
+
+`GC7ZN7V3ESF` is the one to be careful with: 2005 and 2006 are a Hwacheon
+dual-spindle pair sharing a PC, and the map says 2005 while the agent says
+2006. Check the machine plate before running it.
+
+**3.1** On the bay, elevated:
+
+```powershell
+. C:\GE Aerospace\lib\Update-MachineNumber.ps1
+$r = Update-MTConnectVariantName -NewNumber '7801' `
+      -Root 'C:\MTConnect' `
+      -Targets @(
+        @{ Path='Agent\devices.xml';   Kind='attr' },
+        @{ Path='Adapter\devices.xml'; Kind='attr' },
+        @{ Path='Adapter\adapter.xml'; Kind='elem' }
+      ) `
+      -Services @('MTConnect Adapter Fanuc','MTConnect Agent Fanuc')
+$r.Updated; $r.Errors
+```
+
+**3.2** Verify the three files agree:
+
+```powershell
+Select-String -Path C:\MTConnect\Agent\devices.xml,C:\MTConnect\Adapter\devices.xml `
+              -Pattern 'name="[^"]+"' | Select-Object -First 2
+Select-String -Path C:\MTConnect\Adapter\adapter.xml -Pattern '<Device(Name|ID|UUID)>[^<]+'
+```
+
+All should read the same number. Then the HTTP probe as in 2.3 (port 5000).
+
+---
+
+## Part 4. Four Fanuc bays with no agent device name
+
+| PC | adapter says | hostname map says |
+|---|---|---|
+| `GJBJC724ESF` | 4007 | 2013 |
+| `G7QLY5X3ESF` | 3126 | 7606 |
+| `G6JLMSZ2ESF` | 4002 | 4002 |
+| `GB07T5X3ESF` | 3115 | 2001 |
+
+These are not a rename problem - the agent's `devices.xml` has no `<Device
+name=...>` at all, so the agent has nothing to serve. Do NOT run Part 3 on them.
+
+On each, collect and send back:
+
+```powershell
+Get-Service 'MTConnect*' | Select-Object Name,Status,StartType
+Get-Content C:\MTConnect\Agent\devices.xml -TotalCount 20
+Test-Path C:\MTConnect\Agent\devices.xml
+(Invoke-WebRequest http://localhost:5000/current -UseBasicParsing -TimeoutSec 5).StatusCode
+Get-Content C:\MTConnect\Agent\agent.log -Tail 30
+```
+
+Note three of the four also disagree with the hostname map on the number
+(4007 vs 2013, 3126 vs 7606, 3115 vs 2001), so these bays may have been
+re-purposed without a full reconfigure.
+
+---
+
+## Part 5. Two questions to settle
+
+**5.1 DMG Mori - do they need a bundle at all?**
+
+Five machines, all flagged `1,2,3` in the machine list, no bundle among the
+five we ship, and no captured variant. Their controllers are `DMG Mori F31i
+A5/B5` - Fanuc 31i underneath - so the Fanuc adapter may already serve them.
+
+| machine | PC |
+|---|---|
+| WJ-7401 | `G1KDN7X2ESF` |
+| WJ-7402 | `G1KCR7X2ESF` |
+| WJ-7403 | `G1HYK7X2ESF` |
+| WJ-7404 | `G1HGQ7X2ESF` |
+| WJ-7405 | `G1KLM7X2ESF` |
+
+On any one of them:
+
+```powershell
+Get-Service | Where-Object { $_.Name -match 'MTConnect|Makino|Coordinator' } |
+    Select-Object Name,Status,StartType
+Get-ChildItem C:\ -Directory | Where-Object Name -match 'MTConnect|DMG|Coordinator'
+(Invoke-WebRequest http://localhost:5000/current -UseBasicParsing -TimeoutSec 5).StatusCode
+```
+
+If they run the Fanuc bundle already, no new variant is needed and the DMG
+Coordinator MSI in the OneDrive zip can be ignored. If they collect some other
+way, or not at all, that is the answer to whether a sixth bundle is worth
+building.
+
+**5.2 Does the live v2 manifest carry the MTConnect entries?**
+
+You are on v2. The concern is that the MTConnect entries were left behind in
+the dead v1 manifest, in which case v2 bays are not getting MTConnect from the
+manifest engine at all.
+
+```powershell
+$m = Get-Content '\\tsgwp00525.wjs.geaerospace.net\shared\dt\shopfloor\main\machineapps\machineapps-manifest.json' -Raw | ConvertFrom-Json
+$m.Applications.Count
+$m.Applications | ForEach-Object { $_.Name }
+```
+
+Expect 8 applications, five of them MTConnect (fanuc, okuma, edncStandard,
+edncDualSpindle, makino). Anything less and the missing ones never made it to
+v2.
+
+---
+
+## What I still owe you
+
+- Auto-detection of controller and variant for a new machine. The inputs exist
+  (`mtconnect-bay-config.csv` has controller IP and FOCAS port per machine, the
+  machine list has the controller model, the collector already knows the machine
+  number at imaging time) - design pending.
+- The code fix is committed and pushed as `0d9c4fd` on `pxe-webapp-redesign`.
+  It changes future renames only; it does not reach out and fix these bays.