docs: refresh WD22TB4 and Pages status

docs/build-status.html

@@ -18,7 +18,7 @@ <h1>OS 9 build monitor</h1>
 <main>
 <section class="row"><div><h2>Aurora source enhancements</h2><p class="muted">The separate .20-enh1 source lane has build and later hardware receipts; its old “staged but unbooted” description is historical. Check each exact build’s receipt rather than transferring acceptance between .20, enh1 and wip2. No paired energy saving is established.</p><a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/hardware-tests/README.md">Per-build hardware receipts and gates</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/enhancements/README.md">Source and build scope</a></div><span class="state">Separate qualification lanes</span></section>
 <section class="row"><div><h2>Aurora .20 hardware freeze</h2><p class="muted">Experimental .20 packages and their scoped boot/PMP/idle/GPU/filesystem receipts remain available. .20 is the last documented persistent boot default, while the October 21 attended boot used wip2. Actual return-to-.20 recovery, full suspend and paired energy testing remain open.</p><a href="https://github.com/techmore/ElementaryOS_MSeries/releases/tag/mseries-aurora20-j314s-2026.10.18-exp1">Frozen package, source and checksums</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/hardware-tests/README.md">Tested scopes and release gates</a></div><span class="state">Experimental fallback</span></section>
-<section class="row"><div><h2>Aurora unified 7.2 trials</h2><p class="muted">October 21 wip2 booted on J314S; all three USB-C ports produced WD22TB4 picture at 1080p/60 in that scoped trial. The retained October 20–27 wip3 observations show DPTX timeouts when first plugging within about four seconds of resume; changing ports restored picture in one observed case. This suggests, but does not prove, a post-resume DCP state issue. A separate user-space monitor-profile watcher restored the saved layout in two observed same-port cycles; automatic restore was confirmed only on the later cycle after a fallback association fix. This does not qualify kernel recovery. Open wip4 revision-6 proposals <a href="https://github.com/techmore/ElementaryOS_MSeries/pull/533">#533</a> at <code>f68fd1d9</code> and <a href="https://github.com/techmore/ElementaryOS_MSeries/pull/619">#619</a> at <code>1dfb6ecc</code> have different patch lists; an owner decision is needed before either merges. At this audit, #619 head <code>1dfb6ecc</code> had diverged from current dev <code>57b143c</code>: eight commits behind and four ahead. On #619 head <code>1dfb6ecc</code>, both ARM64 candidate and unified72 build/payload-inspection jobs passed in <a href="https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40605242087">run 40605242087</a>; see the <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/1dfb6ecc43400b2051bdd7c81c3408defd45e305/mseries/aurora/unified72/review-wip4-2026-10-27.json">immutable receipt</a>. DCP KUnit, wip4 installation/arming, attended J314S boot, repeatable dock recovery, suspend, long-run stability and paired-power qualification remain open. Aurora .20 remains the documented persistent boot default. <a href="capabilities.html#kernel-wip3">Wip3 identity and qualification limits</a>.</p><a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/hardware-tests/2026-10-21-j314s-wip2-first-boot/REPORT.md">First-boot receipt</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/hardware-tests/2026-10-21-j314s-wip2-first-boot/PORT-TIMINGS.md">All-port follow-up</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/unified72/README.md">Source and remaining gates</a></div><span class="state">Rev-6 candidate conflict · wip4 unbooted</span></section>
+<section class="row"><div><h2>Aurora unified 7.2 trials</h2><p class="muted">October 21 wip2 produced WD22TB4 picture at 1080p/60 on all three USB-C ports in that scoped trial. Retained October 20–27 wip3 observations show DPTX timeouts when the dock was first plugged shortly after resume; moving ports restored picture once. This pattern is consistent with, but does not prove, a post-resume DCP state issue. wip5 revision 7 is pinned to omacom/linux-aurora <code>integration/aurora</code> at <code>2f725546d6ac6afe0bd5abfa1a844971519f0076</code> and merged in <a href="https://github.com/techmore/ElementaryOS_MSeries/pull/698">PR #698</a>. Exact-head run <a href="https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442">40866985442</a> passed the ARM64 candidate and unified72 kernel/modules/DTB build and payload inspection; the <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json">immutable receipt</a> records source and archive provenance. The J314S wip5 install record reports one boot, with internal panel, external DP, GPU, Wi-Fi and SEP working; it does not record a WD22TB4 replug or suspend/resume check. The October 30 handoff says wip5 remains running; the install record says wip4 remains the GRUB default. Dock recovery, suspend, long-run stability and paired-power qualification remain open. No wip5 dock acceptance is claimed. <a href="capabilities.html#kernel-wip3">Wip3 identity and qualification limits</a>.</p><a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/hardware-tests/2026-10-21-j314s-wip2-first-boot/REPORT.md">First-boot receipt</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/hardware-tests/2026-10-21-j314s-wip2-first-boot/PORT-TIMINGS.md">All-port follow-up</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/aurora/unified72/wip5/README.md">wip5 install and boot record</a></div><span class="state">wip5 boot recorded · dock qualification open</span></section>
 <section class="row"><div><h2>Enhanced kernel test build</h2><p class="muted">Historical Fairydust packaging work is retained separately from the current Aurora trial. A local monitor link is useful only if its service is running on your own Mac; this public page cannot tell whether that local build is active.</p><a href="http://127.0.0.1:8767/kernel.html" target="_blank" rel="noopener">Local kernel monitor ↗</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/fairydust/debian/README.md">Historical build records</a></div><span class="state">Local state unknown</span></section>
 <section class="row"><div><h2>Local Mac build</h2><p class="muted">Native assembly finished in 16m 39s and its checksum passed. Inspection found missing live-session hardware helpers; the corrected GitHub image now passes its hardware-helper payload check. The corrected ISO also passed its independent checksum and graphical VM boot check. This public page does not poll your Mac.</p><a href="http://127.0.0.1:8767/" target="_blank" rel="noopener">Live local monitor · on this Mac ↗</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/LOCAL-BUILD.md">Build records and controls</a></div><span class="state">Rebuild needed</span></section>
 <section class="row"><div><h2>Rust compositor performance</h2><p class="muted">The Rust compositor has since been used on the transformed desktop. Recent source and staged-package fixes have their own installed-versus-loaded boundaries. Retained October 19 performance samples remain unmatched, so they establish no CPU, power or latency advantage over Gala; Gala remains a rollback option.</p><a href="rust-compositor-performance.html">Measurements, dates and limits</a> · <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/dev/mseries/OS9-HANDOFF.md">Current deployment records</a></div><span class="state">Experimental · no measured win</span></section>

docs/index.html

@@ -19,7 +19,7 @@
 <body>
 <h1>ElementaryOS M-Series</h1>
 <p>Experimental port of <a href="https://github.com/elementary/os">elementary OS 9</a> (Pantheon, Ubuntu-based) to Apple Silicon Macs (M1/M2/…), informed by the maintained Apple hardware packages in <a href="https://github.com/omacom/omarchy-mac-pkgs">omacom/omarchy-mac-pkgs</a>.</p>
-<div class="banner"><strong>Status: elementary OS 9 boots to Pantheon on an M1 Pro; factory-image boot remains unverified.</strong> The October 21 attended wip2 trial showed WD22TB4 picture at 1080p/60 on all three USB-C ports. Across the retained October 20–27 wip3 observations, DPTX failures occurred when the dock was first plugged within about four seconds of resume; moving to another port restored picture in one observed case. This pattern is consistent with, but does not prove, a post-resume DCP state problem. A separate monitor-profile watcher restored the saved layout in two observed same-port cycles; automatic restore was confirmed only on the later cycle after a fallback association fix. This does not establish kernel recovery. Two open wip4 revision-6 proposals (<a href="https://github.com/techmore/ElementaryOS_MSeries/pull/533">#533</a> at <code>f68fd1d9</code> and <a href="https://github.com/techmore/ElementaryOS_MSeries/pull/619">#619</a> at <code>1dfb6ecc</code>) have different patch lists; the owner must choose before either merges. At this audit, #619 head <code>1dfb6ecc</code> had diverged from current dev <code>57b143c</code>: eight commits behind and four ahead. For #619 head <code>1dfb6ecc</code>, both ARM64 candidate and unified72 build/payload-inspection jobs passed in <a href="https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40605242087">run 40605242087</a>; see the <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/1dfb6ecc43400b2051bdd7c81c3408defd45e305/mseries/aurora/unified72/review-wip4-2026-10-27.json">immutable build receipt</a>. This is source/build evidence only: DCP KUnit, wip4 installation or arming, attended J314S boot, repeatable dock recovery, suspend, long-run stability and paired-power qualification remain open. Aurora .20 remains the documented persistent boot default. No stable ISO release is published.</div>
+<div class="banner"><strong>Status: elementary OS 9 boots to Pantheon on an M1 Pro; factory-image boot remains unverified.</strong> October 21 wip2 produced WD22TB4 picture at 1080p/60 on all three USB-C ports in one scoped trial. October 20–27 wip3 observations recorded DPTX timeouts on early post-resume dock plugs; moving ports restored picture once, which is consistent with but does not prove a DCP state issue. wip5 revision 7, pinned to omacom/linux-aurora <code>integration/aurora</code> at <code>2f725546d6ac6afe0bd5abfa1a844971519f0076</code>, merged as <a href="https://github.com/techmore/ElementaryOS_MSeries/pull/698">PR #698</a>. Exact-head <a href="https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442">ARM64 build and payload inspection</a> passed. The <a href="https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/wip5/README.md">J314S install record</a> reports one wip5 boot; WD22TB4 replug and suspend/resume remain unchecked. The Oct 30 handoff records wip5 running, while the install record keeps wip4 as GRUB default. No wip5 dock acceptance is claimed. No stable ISO release is published.</div>
 
 <p><a href="local-ai.html">Local AI on M1 Pro 32 GB: measured model comparisons, personal memory and MCP app coverage</a>.</p>
 

mseries/OS9-HANDOFF.md

@@ -37,6 +37,37 @@ Audited the linked announcement against the running wip5 host and current dev pi
 ## Rust compositor: frames for X11 windows — 2026-10-29
 
 Owner report: the WiFiman Desktop window (Electron, X11, `_MOTIF_WM_HINTS 0x2, 0x0, 0x1`, min 420x460) could not be moved or resized. The Rust compositor drew no server-side decorations at all, so X11 apps that rely on the window manager's title bar had nothing to grab. New `rust/pantheon-compositor/src/decorations.rs`: X11 windows that ask for a frame (no Motif hints, or hints with a title; normal/dialog/utility types) get a 34 px title bar above the client, an invisible 8 px resize band, and the `org.gnome.desktop.wm.preferences button-layout` buttons (close, minimize, maximize; the owner's `close,minimize,maximize:`), drawn with pango/cairo and rounded with the window corners. Drag moves, edges resize within the size hints, double-click and the maximize button toggle maximize, close sends WM_DELETE_WINDOW. Snapped/maximized framed windows are configured below the title bar; work-area fitting counts the title bar. Fixes on the way: X11 resize ignored WM_NORMAL_HINTS min/max; moving an X11 window (title bar or Super-drag) never told the client its new position. `_NET_WM_MOVERESIZE` was already routed by smithay and is now covered by the probe. Wayland windows, header-bar (CSD) X11 windows and fullscreen windows are unchanged. Verified: `mseries/pantheon-rust-compositor/ssd-probe/run.sh` (nested, 11/11 pass with a window carrying WiFiman's exact hints), 184 unit tests, activation probe 7/7. Not verified: the real WiFiman window on the M1 Pro (needs the owner's install + re-login); the real app was not started nested because its root daemon carries the owner's live VPN. Not done: `_NET_FRAME_EXTENTS`, a window shadow, frames during gesture animations.
+## WD22TB4, wip5 boot and Pages status — 2026-10-30
+
+Current `dev` is `17045e80db1f958e69048418ead12f7c0aeaa1b6`. Pages deployment
+[41058736063](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/41058736063)
+succeeded for that exact revision. The live homepage and build monitor each
+byte-match their `dev/docs` source (SHA-256 `62acac58159490406333886dae68f8eb5c4dedd6b1fe909f3b0a30c99e12b9e5`
+and `e06a2f4648cd3225872a91df7d724305ccd266adf00903a97c410edfdec624bb`).
+Those source pages still describe the older wip4 candidate; this correction is
+prepared on the current revision and remains unpublished until merge and a
+successful Pages deployment for the resulting `dev` revision.
+
+wip5 revision 7 is pinned to omacom/linux-aurora `integration/aurora` at
+`2f725546d6ac6afe0bd5abfa1a844971519f0076`; PR #698 merged on October 29.
+Exact-head CI run [40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442)
+passed the ARM64 candidate and unified72 kernel/modules/DTB build and payload
+inspection. The immutable [source/build receipt](https://github.com/techmore/ElementaryOS_MSeries/blob/4ea1ea28c5118bc558749203192eef08f042b7b2/mseries/aurora/unified72/review-wip5-2026-10-29.json)
+retains the pin and patch provenance. The [J314S install record](aurora/unified72/wip5/README.md)
+reports a first good wip5 boot on October 29, with the internal panel, external
+DP, GPU, Wi-Fi and SEP working. It does not record WD22TB4 replug or
+suspend/resume qualification. The October 30 handoff records wip5 still running;
+the install record says wip4 remains the GRUB default. This is one boot record,
+not dock acceptance or a repeatability result.
+
+Reuse the October 21 wip2 scoped result: picture at 1080p/60 on all three
+USB-C ports in one plug cycle per port. Retained October 20–27 wip3 observations
+record early post-resume DPTX timeouts and one alternate-port recovery; they do
+not qualify wip5 recovery. No new dock or hardware trial was performed for this
+status update. Dock replug/recovery, suspend, long-run stability and paired-power
+qualification remain open. Next: perform the owner-authorized wip5 dock and
+recovery checks, then update this page only from their retained receipt.
+
 ## wip4 revision 6: DP routing candidate — 2026-10-27
 
 Owner report: dock HDMI and Ethernet not working on wip3; HDMI worked after moving the dock to another port. Journals show `apple-dcp 28cc00000` timing out the DPTX validate call (-110 x6, "Type-C DPTX reconnect failed after 5 retries") on every failing boot, each time on the first plug within ~4 s of resuming from s2idle; the same dock then worked on `289c00000`. wip2 used `28cc00000` successfully; wip3 never did. Ethernet (RTL8153, `r8152`) enumerated but had no carrier this boot (it had carrier on the previous wip3 boot with the identical missing-`rtl8153b-2.fw` message), so that looks physical/cable, not kernel. Candidate: wip4 revision 6 = wip3 source + #157 + local 0002 + upstream #186 (0003-0005; #163 excluded as conflicting duplicate). Full-tree `candidate.py prepare`/`check` and 83 aurora tests pass; kernel build, KUnit and boot are NOT done. Nothing installed, staged, armed or rebooted. `thunderbolt_apple.s2idle_teardown/resume_recovery/router_sleep` remain at the default N (upstream did not test them with a real dock).

mseries/ROADMAP.md

@@ -1,3 +1,26 @@
+## WD22TB4, wip5 boot and Pages status — 2026-10-30
+
+Current `dev` is `17045e80db1f958e69048418ead12f7c0aeaa1b6`. Pages run
+[41058736063](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/41058736063)
+succeeded for that revision; live homepage and build-monitor bytes match source.
+The current `dev` pages still contain the older wip4 status, and this correction
+awaits review, merge and its own successful Pages deployment.
+
+wip5 revision 7, pinned to omacom `integration/aurora` at
+`2f725546d6ac6afe0bd5abfa1a844971519f0076`, merged in PR #698. Its exact-head
+ARM64 build and payload inspection passed in run
+[40866985442](https://github.com/techmore/ElementaryOS_MSeries/actions/runs/40866985442).
+The J314S install record reports one boot and working internal panel, external
+DP, GPU, Wi-Fi and SEP; WD22TB4 replug and suspend/resume remain unchecked.
+The October 30 handoff says wip5 remains running, and the install record says
+wip4 remains the GRUB default. Do not transfer wip2 dock picture results to wip5.
+
+The October 21 wip2 trial remains the scoped evidence for WD22TB4 picture on all
+three ports. The October 20–27 wip3 DPTX timeout and alternate-port recovery
+observations do not establish wip5 recovery. No new hardware trial was performed
+for this status update. Next: owner-authorized wip5 WD22TB4 and recovery checks;
+record dock replug, suspend/resume, stability and recovery independently.
+
 ## WD22TB4 and wip4 candidate status — 2026-10-28
 
 Current `dev` is `57b143c4afd78b0a4a0f9905e48e39632d1ecc3c`. Pages deployment