Merge nucleic/ivory-slate-koala-w5ud into dev

Sources/NucleicCore/MacVM/MacVMEngine+MDM.swift

@@ -1054,9 +1054,20 @@ extension MacVMEngine {
             /bin/ls -l \(Self.shQuote(share)) 2>&1 || true
             echo '── frontmost app ──'
             /usr/bin/lsappinfo front 2>&1 || true
-            echo '── ManagedClient / mdmclient / profiles log (last 5m) ──'
-            sudo /usr/bin/log show --last 5m --style compact --predicate \(Self.shQuote(predicate)) \
-              2>&1 | /usr/bin/tail -c 12000 || true
+            echo '── ManagedClient / mdmclient / profiles log (last 5m, info+debug) ──'
+            # `--info --debug` is not optional here. Without them `log show` emits only Default-level
+            # messages, and a live run captured the top-level failure —
+            #   Error Domain=ConfigProfilePluginDomain Code=-323 "The certificate could not be
+            #   verified (authentication error)."
+            # — without the payload-level lines that say WHICH certificate failed, which is the one
+            # thing needed to act on it. The tail is widened to match the extra volume.
+            sudo /usr/bin/log show --last 5m --info --debug --style compact \
+              --predicate \(Self.shQuote(predicate)) 2>&1 | /usr/bin/tail -c 40000 || true
+            echo '── profile-install errors only ──'
+            sudo /usr/bin/log show --last 5m --info --debug --style compact \
+              --predicate \(Self.shQuote(predicate)) 2>&1 \
+              | /usr/bin/grep -iE 'error|fail|denied|invalid|verif|cert|payload|scep|identity' \
+              | /usr/bin/tail -c 20000 || true
             """
         guard let result = try? await runMDMGuest(target, command: command) else {
             recorder?.note("[\(label)] guest MDM state: probe could not run")

docs/MACOS_VM_MDM_DEBUG_LOG.md

@@ -596,15 +596,62 @@ now records, at every milestone and before every failure it can propagate:
   from which step notes are absent.
 - **`holdBaseOnMDMFailure` defaults to ON**, so the guest survives the failure it caused.
 
+### Run 21 — the GUI works; macOS names the error; the cause is narrowed to one thing
+
+The instrumentation paid for itself. The GUI automation completed for the first time — row
+double-clicked, **Enroll** clicked, `password landed in field=true` — and then macOS rejected the
+profile. Its own words, from the captured `ManagedClient` log:
+
+```
+ProfilesSettingsExt [ERROR] [CE] Profile installation
+(Nucleic MDM Enrollment (xyz.blakeslee.nucleic.mdm.enroll:8F054B9C-…))
+==> Error Domain=ConfigProfilePluginDomain Code=-323
+    "The certificate could not be verified (authentication error)."
+```
+
+**What this rules out, by evidence rather than inference:**
+
+- **Not the profile signature.** The pre-flight recorded `profile=plist` — the profile was unsigned
+  this time and failed identically. Run 19's conclusion that the CMS signature was the cause was
+  wrong.
+- **Not the check-in TLS, so not pinning.** The server trace shows only the pre-flight's two curl
+  probes and the post-failure reachability probe. `mdmclient` never opened a connection. The
+  rejection happens during payload validation, before any network contact.
+- **Not malformed artifacts, and not clock skew.** The preserved `staged/` copy was analysed
+  directly: the PKCS#12 MAC verifies (SHA-256, 2048 iterations; shrouded keybag PBES2 / PBKDF2-SHA256
+  / AES-256-CBC), the device identity is `CN=Nucleic macOS Guest` with `clientAuth` EKU and
+  `CA:FALSE`, its AKI matches the CA's SKI, and `openssl verify -CAfile ca.pem dev-cert.pem` returns
+  **OK**. CA `notBefore` 03:46:23Z, install at 04:49Z — guest and host clocks agree.
+
+So nothing is broken; the chain is correct **given the CA as an anchor**, and the CA is not a trusted
+anchor. The remaining question is precisely *which* payload's certificate macOS refused to verify —
+and the capture named the error without naming the payload, because `log show` omits info- and
+debug-level messages unless asked. That is now fixed (`--info --debug`, plus a filtered
+errors-only section), which is the only change made from this run.
+
+**Do not iterate this on full builds.** `revalidateBaseMDMPolicy()` re-runs the MDM pass alone against
+the existing base — minutes, not the ~15 a rebuild costs — and it is reachable at
+**Settings ▸ Virtual Machines ▸ ⋯ ▸ Re-run MDM enrollment pass**. Boot 1 already succeeds, so the base
+satisfies its preconditions.
+
 ## Open questions for the next run
 
 - ~~Does trustd honour a hand-written `Admin.plist` after a reboot?~~ **Answered by run 18: no.**
 - ~~Does `add-trusted-cert` succeed as root without the relaxation?~~ **Answered by run 16: no — it
   hangs on its authorization sheet.** The command is removed and test-guarded against return.
-- **Does pinning let the enrollment complete with the CA untrusted?** The whole question now. Expect
-  `ssl=0` in the pre-flight report — that is no longer a failure. What matters is whether the profile
-  installs and `mdmclient` opens a check-in the server accepts; the trace will show a completed TLS
-  handshake and a `PUT /checkin` instead of `-9831: unknown Cert Authority`.
+- **Which payload's certificate does macOS refuse to verify?** The single open question. The verbose
+  ManagedClient capture should name it. The candidates, and what each would imply:
+  - the **`com.apple.security.pkcs12` identity** — installing a pre-baked identity whose chain ends at
+    an untrusted anchor. If so, the documented alternative is a `com.apple.security.scep` payload plus
+    a `/scep` endpoint, which is how real MDMs issue an identity from a private CA (deferred at
+    `docs/MACOS_VM_MDM.md` §"Identity mechanism" precisely because it is ~2000 lines of ASN.1).
+  - the **`com.apple.security.root` payload** — macOS refusing to install a root from a profile in
+    this context at all.
+  - the **`com.apple.mdm` payload** validating `IdentityCertificateUUID` against a trusted anchor.
+
+  Do not guess between these. The log will say.
+- Pinning is still unexercised — nothing has reached a check-in — so it remains neither proven nor
+  disproven.
 - If pinning does not work, the fallback is a publicly trusted certificate for a real name (ACME
   through `cloud/nucleic-edge`) — but note `.internal` could not be used for that, since no public CA
   issues for a private-use TLD, so the MDM name would have to move to a real zone.