# CHERTTT — SELF-49 Technical Re-Verification Directive **Date:** 2026-09-14 **Target:** Claude Code working in the `cherttt.com` repository **Subject:** Re-audit SELF-49 against measured evidence, upstream OSX-KVM behavior, and Apple Simulator/Metal documentation --- ## 1. Purpose Re-open **SELF-49** and verify it technically. Do **not** defend the existing wording merely because it is already in the findings register. The current SELF-49 combines valid measurements from `chert-ios-worker` with a broader causal conclusion: > “The platform's macOS worker can BUILD iOS apps but cannot RENDER them — a QEMU guest has no GPU, and the simulator's Metal service is absent, so an app launches and paints nothing.” The measurements may be correct. The generalization may not be. The purpose of this audit is to distinguish: 1. what CHERT actually measured; 2. what upstream QEMU/OSX-KVM demonstrates; 3. what Apple documents about Simulator rendering and Metal; 4. what is an inference rather than a proven fact; 5. whether SELF-49 must be corrected from an architectural impossibility to a **current-configuration blocker**. --- ## 2. Do not change architecture during this audit This is a technical verification only. Do **not** recommend or substitute: - Khalid's Mac; - ChertOS; - an external Mac; - AWS EC2 Mac; - MacStadium; - other Apple hardware. The CHERTTT architecture decision remains: ```text Browser developer ↓ cherttt.com ↓ DigitalOcean Ubuntu host ↓ QEMU/KVM + OSX-KVM ↓ macOS ↓ Xcode + CoreSimulator ``` The question is whether **this stack is fundamentally incapable of rendering**, or whether the current configuration simply lacks a working graphics/Metal path. --- # 3. Start from the raw SELF-49 evidence Locate and inspect: ```text docs/validation-evidence/ios-worker/proof6-* ``` Locate the commit that introduced SELF-49. Reconstruct every command that produced the finding. The existing record claims the following were measured: ```text flutter build ios --simulator → success simctl install → success simctl launch → live PID iPhone Simulator → Booted iPad Simulator → Booted launchd_sim → running SpringBoard → running system_profiler → 3 MB framebuffer / No Kext Loaded Simulator logs → com.apple.metal.simulator missing Flutter application canvas → black SpringBoard startup → >20 min / unusable 4-vCPU guest load → 16.4 backboardd → high CPU 6-vCPU configurations → XNU divide-error panic ``` Verify each independently. Do not use SELF-49 itself as evidence. --- # 4. Important correction: QEMU guest ≠ “no graphics” The following proposition must **not** be assumed: ```text QEMU guest ↓ no physical GPU passthrough ↓ no graphics ↓ cannot render ``` That logic is contradicted by upstream OSX-KVM material. ## 4.1 OSX-KVM's normal boot configuration uses a virtual graphics device Upstream `OpenCore-Boot.sh` contains: ```text -device vmware-svga ``` Source: https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot.sh Therefore a QEMU macOS guest does not inherently mean “no display device.” The correct distinction is: ```text physical GPU passthrough ≠ virtual/software graphics ≠ Metal-capable GPU environment ``` These are three different capabilities. --- # 5. The “3 MB framebuffer” is NOT proof that rendering is impossible Upstream OSX-KVM PR #277 documents: > QEMU 9.2.1 > macOS Big Sur through Sequoia > Ubuntu 24.04 host > `vmware-svga` > **no GPU passthrough** > 1920×1080 @ 60 FPS It further states that macOS may report only **3–7 MB Video Memory** and that this is expected for this configuration. Source: https://github.com/kholia/OSX-KVM/pull/277 Therefore this SELF-49 evidence: ```text 3 MB framebuffer No Kext Loaded ``` cannot by itself establish: ```text macOS cannot render ``` or: ```text QEMU cannot render ``` At most, it describes the current guest's reported graphics state. ### Required Claude action Determine whether SELF-49 used the 3 MB value as causal proof. If yes, explicitly withdraw that inference. Record: ```text Measured: macOS reports 3 MB framebuffer. Not proven: 3 MB framebuffer causes the Simulator black canvas. Contrary upstream evidence: OSX-KVM reports working 1920×1080/60 FPS vmware-svga configurations while macOS still reports 3–7 MB video memory. ``` --- # 6. Apple documentation changes the actual question Apple documents that Simulator does **not** emulate the target iPhone/iPad GPU. Apple states that Simulator translates Metal calls and directs them to the **selected GPU on the host Mac**. Apple also explicitly says frameworks built on Metal, including **Core Animation and UIKit**, benefit from that acceleration in Simulator. Primary source: https://developer.apple.com/documentation/metal/developing-metal-apps-that-run-in-simulator Apple also provides a dedicated sample for configuring alternative render paths for Simulator: https://developer.apple.com/documentation/metal/supporting-simulator-in-a-metal-app Therefore the important CHERT failure is not: ```text QEMU cannot draw pixels ``` The important unresolved question is: ```text Can the nested macOS guest expose a graphics/Metal environment that CoreSimulator accepts as its host rendering device? ``` That is a substantially narrower question. --- # 7. Treat `com.apple.metal.simulator` as evidence — not yet as proven root cause SELF-49 observed: ```text failed lookup: name = com.apple.metal.simulator error = 3: No such process ``` This is significant because Apple's documentation confirms that Simulator's Metal path relies on the host Mac GPU environment. However, the log alone does not prove all of these propositions: ```text QEMU can never provide what Simulator requires. vmware-svga can never coexist with a usable Simulator path. another QEMU graphics configuration cannot solve it. GPU passthrough is the only possible solution. DigitalOcean + OSX-KVM can never render CoreSimulator. dj-06 is fundamentally impossible. ``` Unless those propositions have been separately tested or established by authoritative documentation, mark them **NOT PROVEN**. --- # 8. OSX-KVM explicitly supports GPU passthrough Upstream OSX-KVM documents GPU passthrough and tested GPU configurations. Source: https://github.com/kholia/OSX-KVM/blob/master/notes.md Upstream also provides: ```text boot-passthrough.sh ``` Source: https://github.com/kholia/OSX-KVM/blob/master/boot-passthrough.sh This does **not** mean DigitalOcean necessarily exposes a passthrough-capable GPU to this droplet. It means the theoretical statement: > “a QEMU guest has no GPU” is false as a statement about QEMU/OSX-KVM architecture. A QEMU macOS guest can have: ```text A. virtual graphics device e.g. vmware-svga B. passed-through physical GPU e.g. supported AMD GPU via VFIO C. graphics without Metal acceleration D. graphics with a GPU environment suitable for Metal ``` Claude must stop treating A–D as equivalent. --- # 9. Required capability matrix Re-test and fill this matrix from actual evidence: | Capability | Current CHERT worker | Proven? | Evidence | |---|---|---:|---| | macOS boots | | | | | macOS desktop draws | | | | | Finder draws | | | | | Terminal draws | | | | | Simulator.app window draws | | | | | iPhone device chrome draws | | | | | iPad device chrome draws | | | | | SpringBoard draws | | | | | Simulator boots | | | | | `.app` builds | | | | | `.app` installs | | | | | `.app` launches | | | | | UIKit app draws | | | | | SwiftUI app draws | | | | | Flutter app draws | | | | | `simctl io screenshot` works | | | | | Metal device exists in macOS guest | | | | | Simulator Metal service exists | | | | | browser streaming works | | | | Do not write one generic word “rendering” for multiple different layers. --- # 10. Run the decisive controls ## 10.1 Simulator screenshot For the booted simulator: ```bash xcrun simctl io screenshot /tmp/chert-simulator.png ``` Record: ```text exit code file size dimensions actual pixels captured ``` Preserve the image. If the screenshot contains valid SpringBoard/UI pixels, SELF-49's phrase “cannot render” is demonstrably too broad. If it is black, that strengthens the current-configuration finding but still does not establish architectural impossibility. --- ## 10.2 Native UIKit control Create a temporary minimal UIKit application displaying: ```text white background red rectangle CHERT UIKit Render Test ``` Build for Simulator. Install with `simctl`. Launch with `simctl`. Capture with `simctl io screenshot`. --- ## 10.3 Native SwiftUI control Create a temporary SwiftUI application displaying: ```text white background blue rectangle CHERT SwiftUI Render Test ``` Repeat the same test. --- ## 10.4 Flutter control Run the equivalent Flutter application last. This distinguishes: ```text Flutter failure from CoreSimulator failure from macOS/QEMU graphics failure ``` --- # 11. Query Metal directly Inside the macOS guest determine whether macOS sees a Metal device. Use the appropriate system profiler and/or a minimal Metal probe. At minimum collect: ```bash system_profiler SPDisplaysDataType ``` Also inspect whether the guest can obtain an `MTLDevice`. The question is not merely: ```text Does System Information show a display? ``` The question is: ```text Does macOS expose a Metal-capable device? ``` Then separately determine: ```text Does CoreSimulator expose/launch its Simulator Metal service? ``` These are not the same test. --- # 12. Inspect the actual QEMU graphics configuration Do not infer it. Capture the running QEMU command line and OSX-KVM boot configuration. Record: ```text QEMU version machine type CPU model/options vCPU topology vmware-svga present? YES/NO virtio-vga present? YES/NO SPICE/VNC configuration OpenCore version macOS version Xcode version Simulator runtime ``` Compare the graphics configuration with upstream: https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot.sh and the modern libvirt work: https://github.com/kholia/OSX-KVM/pull/274 Do not modify production blindly. First document the delta. --- # 13. Do not mix the CPU/TSC problem with the graphics problem SELF-49 also reports: ```text 4 vCPU = stable 6 vCPU = XNU divide-error panic ``` That is a separate finding. Keep these independent: ```text CPU/TSC/SMP stability ≠ macOS framebuffer ≠ Metal availability ≠ CoreSimulator rendering ≠ browser streaming ``` A 6-vCPU panic does not prove a graphics limitation. A graphics limitation does not prove the 6-vCPU panic. Record them separately. --- # 14. Required logic audit of SELF-49 For every proposition below, answer: ```text MEASURED SUPPORTED BY DOCUMENTATION INFERENCE DISPROVEN NOT PROVEN ``` ### Proposition 1 > The current CHERT worker builds iOS Simulator applications. Expected from existing evidence: **MEASURED**. ### Proposition 2 > The current CHERT worker boots CoreSimulator. Expected from existing evidence: **MEASURED**. ### Proposition 3 > The current CHERT worker installs and launches the app. Expected from existing evidence: **MEASURED**. ### Proposition 4 > The current tested Flutter application produces a black canvas. Expected from existing evidence: **MEASURED**, subject to re-verification. ### Proposition 5 > `com.apple.metal.simulator` is absent/failing. Expected from existing evidence: **MEASURED**, subject to re-verification. ### Proposition 6 > A QEMU macOS guest has no graphics capability. Expected result: **DISPROVEN** by upstream OSX-KVM. ### Proposition 7 > 3 MB reported video memory proves that the guest cannot render. Expected result: **DISPROVEN as a general inference** by OSX-KVM PR #277. ### Proposition 8 > The current CHERT guest has no working Metal environment for CoreSimulator. Likely result: **SUPPORTED BY CURRENT EVIDENCE**, but verify directly. ### Proposition 9 > QEMU/OSX-KVM can never provide a graphics environment usable by CoreSimulator. Expected result unless new authoritative evidence is found: **NOT PROVEN**. ### Proposition 10 > DigitalOcean + OSX-KVM can never implement dj-06. Expected result unless independently proven: **NOT PROVEN**. --- # 15. Required interpretation of online documentation The documentation currently establishes: ## Apple Apple Simulator has a GPU/Metal rendering architecture. It does not emulate the iPhone GPU. It translates calls to a GPU available to the host macOS environment. UIKit and Core Animation use infrastructure built on Metal. Therefore absence of a usable Simulator Metal path can plausibly explain serious rendering problems. But Apple documentation does **not** establish: ```text QEMU macOS guests can never run Simulator UI ``` Source: https://developer.apple.com/documentation/metal/developing-metal-apps-that-run-in-simulator --- ## OSX-KVM OSX-KVM's standard boot configuration contains: ```text -device vmware-svga ``` Source: https://github.com/kholia/OSX-KVM/blob/master/OpenCore-Boot.sh OSX-KVM also has documented GPU passthrough support. Source: https://github.com/kholia/OSX-KVM/blob/master/notes.md A current upstream contribution documents 1920×1080/60 FPS macOS graphical output with `vmware-svga`, no GPU passthrough, and reports that 3–7 MB displayed video memory is expected. Source: https://github.com/kholia/OSX-KVM/pull/277 Therefore: ```text QEMU guest → no GPU → cannot render ``` is not an acceptable technical conclusion. --- # 16. Correct burden of proof SELF-49 currently appears to move from: ```text CURRENT OBSERVATION Flutter app black + Simulator Metal service absent + 3 MB framebuffer ``` to: ```text ARCHITECTURAL CONCLUSION QEMU cannot render iOS apps + dj-06 cannot work + use Apple hardware or drop scope ``` That jump is not acceptable without additional proof. The scientifically valid current position is: ```text Current CHERT OSX-KVM configuration ↓ build works ↓ CoreSimulator boots ↓ install works ↓ launch works ↓ interactive app rendering currently fails ↓ Simulator Metal service appears unavailable ↓ ROOT CAUSE / REMEDIATION STILL TO BE PROVEN ``` --- # 17. Expected correction if the evidence remains unchanged If the re-test reproduces the same behavior and no stronger proof is found, SELF-49 should be rewritten approximately as: > **SELF-49 — The current CHERT DigitalOcean OSX-KVM worker successfully builds iOS Simulator applications, boots CoreSimulator devices, installs applications and launches them, but usable Simulator application rendering is currently blocked. The tested configuration reports no functioning `com.apple.metal.simulator` service and the tested application produces a black canvas. This proves a blocker in the current graphics/Metal configuration; it does not prove that QEMU/OSX-KVM or the DigitalOcean architecture is fundamentally incapable of rendering CoreSimulator. Root cause and remediation remain open.** Status: ```text CURRENT-CONFIGURATION BLOCKER ROOT CAUSE / REMEDIATION OPEN ``` Not: ```text PROVEN ARCHITECTURAL IMPOSSIBILITY ``` --- # 18. Do not drop dj-06 from this evidence alone SELF-49 must **not** be used by itself to conclude: ```text drop dj-06 ``` until one of these is proven: 1. the required CoreSimulator Metal path is technically impossible in the selected QEMU/OSX-KVM environment; or 2. the DigitalOcean virtualization layer prevents every technically viable graphics solution required by CoreSimulator; or 3. an authoritative upstream/Apple limitation explicitly establishes the incompatibility. A failed current configuration is not equivalent to any of those. --- # 19. Preserve the audit Create: ```text docs/validation-evidence/ios-worker/self49-reverification/ ``` Store: ```text 00-original-self49.md 01-provenance.txt 02-environment.txt 03-qemu-commandline.txt 04-macos-display.txt 05-metal-probe.txt 06-simulator-processes.txt 07-simulator-metal-log.txt 08-simctl-screenshot/ 09-uikit-control/ 10-swiftui-control/ 11-flutter-control/ 12-cpu-tests/ 13-upstream-comparison.md 14-logic-audit.md 15-final-verdict.md ``` Do not delete or rewrite the old `proof6-*` evidence. --- # 20. Final verdict format Return exactly one classification: ```text A — SELF-49 CORRECT AS WRITTEN B — MEASUREMENTS CORRECT, CAUSAL EXPLANATION WRONG C — CURRENT-CONFIGURATION FAILURE ONLY D — PARTIALLY DISPROVEN E — FULLY DISPROVEN F — INSUFFICIENT EVIDENCE ``` Then state separately: ```text Build: PASS / FAIL CoreSimulator boot: PASS / FAIL Install: PASS / FAIL Launch: PASS / FAIL macOS graphical output: PASS / FAIL / UNKNOWN Simulator graphical output: PASS / FAIL / UNKNOWN UIKit rendering: PASS / FAIL / UNKNOWN SwiftUI rendering: PASS / FAIL / UNKNOWN Flutter rendering: PASS / FAIL / UNKNOWN macOS Metal device: PRESENT / ABSENT / UNKNOWN Simulator Metal service: PRESENT / ABSENT / UNKNOWN Browser streaming: PASS / FAIL / NOT TESTED Fundamental QEMU limitation: PROVEN / NOT PROVEN Fundamental DO limitation: PROVEN / NOT PROVEN dj-06 impossible: PROVEN / NOT PROVEN ``` Finally, update SELF-49 only to what the evidence actually establishes. --- # 21. Governing principle **Do not convert an implementation failure into an architectural impossibility without proof.** The fact that CHERT's current worker fails to render correctly is valuable engineering evidence. The claim that QEMU/OSX-KVM fundamentally cannot render iOS Simulator applications is a different claim and requires different evidence. Keep those two claims separate.