git:20260920.86ae6d3 to git:20260921.e3f6d5c

+ **The chain drives itself; the operator owns the decisions.** When a phase's exit condition is met, start the next phase's entry yourself: setup complete → evidence on the first symptom; evidence captured → the phase 2 sweep opens its ledger; ledger full → hypotheses ranked with falsifiers into phase 3's gate; gate passed → the cheapest decisive experiment, then verification, acceptance and cleanup; three refutations → back to phase 2, wider. Do not wait to be told the next step, and do not stop at a phase boundary to summarize — report compactly and continue. Ask, never guess, at the decision points that belong to the operator, and those are the only stops: unresolved target identity or an unspecified interface/session (phase 0 asks), a boot path the operator must complete (locked bootloader, missing payload demonstration — resume when done), the loop's refutation budget, anything that can destroy excluded userdata or otherwise unrecoverable state, physical hands, and pause/resume prerequisites. Everything else advances.

+

+ **Establish the target** (every later answer depends on it; every decision here is asked and user-confirmed — an existing repo, monorepo layer, staged OS image, prior context file or sibling device's choice near the project is a candidate to offer, not an answer; artifacts establish what is present, never what is wanted, and one target OS inferred from surrounding layout had to be superseded by the operator's actual selection):

+ - **Exact device identity** — marketing name, codename, SoC, regional/storage variant. Sibling variants of one name differ in panel, touch, modem; a fix researched against the wrong variant looks plausible and fails. Record sibling codenames — phase 2 enumerates their ports. On firmware-boot targets DMI/SMBIOS cannot even be trusted for the SoC generation: one family's DMI string appeared in no documentation while one marketing name spanned two SoC generations with zero portability (DT, patches, community tooling all generation-specific). Discriminate by the stock OS's CPU identity string plus per-core max frequency as tiebreaker, and verify later against the running system's board description; a "no port exists" sweep verdict must name the CPU generation it searched for, or it may be reporting the sibling's ecosystem — on one device all community port effort sat on the newer generation.

+ - **Session mechanics — every naive liveness signal false-positives.** Enumeration shows the right VID:PID for a zombie session; the exploit tool's own verifier can print success without running its stage machine on a stale session; a session contaminated by dozens of failed races reads back as pwned while untrustworthy (one session burned ~3 h this way). Working gate: a USB node number different from the one recorded at last session close, a GETSTATUS-class control transfer answered within a short timeout (timeout = zombie), and the full stage trace in the exploit log — a success line with zero stages _is_ the false-positive signature. Bound exploit attempts per session; after repeated failed races, re-enter clean DFU instead of continuing on the contaminated one.

+ - **The pwn exists only inside the live session.** An idle payload session dies on its own; "pwned then later gone" means the session died — check what re-enumerated before theorizing a physical decay (one such theory was refuted in seconds by a raw descriptor read). Pre-stage everything downstream so exploit-success → payload-load is seconds, not minutes (one 25-minute grind was dead ~9 minutes later); record node + verified state at session close.

+ - **Success announces itself as USB re-enumeration to a payload-specific PID** — the device leaves the exploit PID entirely, and different payload builds present different PIDs; watching the wrong PID reads as "loader silently does nothing" (one attempt wrongly concluded the whole approach dead). Record the expected PID map per build beside the udev rules; cover every chain stage's VID:PID up front (each stage re-enumerates). The `uaccess` tag can silently grant nothing (logind seat mismatch) — fall back to a deterministic group rule; and a newly installed rule does not apply to the already-plugged node, which is exactly the mid-chain node — replug or manual chgrp before the session continues. Interactive payload-console clients block forever without piped stdin: drive them as `printf '…\n' | client`.

+ - **Never diagnose device state from a host tool's parsed rendering of a USB string descriptor** — read the raw descriptor with an oversized buffer. Host tools, and even the exploit suite itself, have read a truncated serial with the payload marker cut off, concluded "not pwned", and re-exploited an already-pwned session on every attempt; the misdiagnosis fed a physical "pwn decay" theory for hours before a raw-byte read retired it. The wrapper-corrupts-evidence rule extends into descriptor space, and the corrupting reader can be your own tool.

+ - **Mine a working project's boot scripts for the success signal and undocumented prerequisite steps** — do not derive the flow from docs alone. A sibling project's flash script yielded steps no documentation mentioned (an explicit reset between exploit and payload load, missed by every doc-derived attempt). Pre-register the falsifier for the first tethered boot: one clean-session roll with a re-enumeration-poll timeout and named fallback flows.

+ - **Chain binaries get full provenance or the chain is unreproducible.** Third-party CI-built and locally built payloads that no package manager provides: per-file origin (exact feed/zip), SHA-256, local build recipe with the pinned source revision; the tool environment defaults to the hashed copies via variables so no invocation silently picks up an untracked binary.

+ - **Entitlement-gated refusal is not absence.** A readable retail OS may refuse its own diagnostic surfaces — an empty registry dump or a named storage-info failure proves the surface exists but is gated; the verdict is "unknown, evidence-backed", not "not exposed". Capture stdout and stderr as sibling files so refusals are first-class evidence, run every stock-side diagnostic **before** exploit work starts (the payload environment is the fallback surface and only exists after the chain works), and pre-register standing operational facts the stock OS already revealed — one end-of-life battery (cycle count + corroborating brown-out panic) became "expect spontaneous shutdowns, keep tethered, treat uncommanded power loss as routine" before any chain work; a capacity field returning a constant is a stub, not data.

+ - **Filesystem encryption is a phase 0 gate, before wipe/resize decisions.** Record per-volume encryption status; the other OS can never read the recovery key for Linux and a resize of an encrypted volume fails until decryption fully completes (measured 10–60 min for a half-full 256 GB SSD). Record only _that a key was exported and where_ — never the key. Record the wipe-vs-dual-boot decision and which partitions (e.g. factory recovery images) are intentionally forfeited before any destructive step.

+ - **The stock OS is the pre-install control channel.** Its built-in ssh server replaces per-iteration operator hands: streaming harvests (driver/firmware stores, ACPI dumps) and even staging boot files onto the install medium, hashes verified host-side. The session's elevation follows the stock OS's own UAC configuration — know which you have. `wmic`-era tools are gone on current builds (use the OS's current management API). Do not route transfers through the install medium: its data partitions may be unreadable from the stock OS and its system partition may reject writes without elevation.

+ - **Harvest the Linux firmware before the wipe.** On Windows-on-ARM targets the WLAN/BT/modem/DSP/GPU firmware lives in the driver store (`System32/DriverStore/FileRepository`) and is unobtainable afterwards — harvest filtered by SoC-number substring (one device: 99 package dirs, 726 MB / 1083 files), keep duplicate retained versions, file with dirlist + hashes + a README mapping each payload to its future firmware-path consumer, marked "reference only, not a restore source".

+ - **Harvest the ACPI board authority from the stock OS** with the platform's dump/disassemble toolchain; if the toolchain mirrors are unreachable, the binaries ship inside GUI utilities. Disassemble the DSDT naming _every_ SSDT so cross-table externals resolve. Then read absences as architecture: zero battery/AC method objects means the whole power path runs through an embedded controller on a bus the SoC dtsi may not even instantiate — and a mainline driver whose binding names this SoC may never have been tested on it: bindings text ≠ hardware validation.

+ - **Map physical connector → controller wiring from the stock OS before writing any DT node**: with the device you will boot from plugged into the port you intend to use, walk the device's parent chain up to the first ACPI node — that instance names the owning controller (confirm its MMIO base in the DSDT). The same pass classifies unwired controllers: present-and-healthy-with-no-devices = dead on this board. One board's convention-based port guess cost two boot rounds before the stock-OS walk resolved the ports differently.

+ - **Record what the backup route excludes by design, with counts and the size expectation.** Unencrypted mobile-OS backups omit the credential store entirely and never include app binaries — a large-storage device yielding a few hundred megabytes and ~a thousand files is success, not truncation. A coverage record without the by-design exclusions gets a good backup re-diagnosed as failed.

+ - **Prose holds no volatile numbers — the artifact does.** Hand-copied hashes, counts and ratios drift the moment the next flash or run lands, and a stale hand-copied hash is worse than none: it reads as a mismatch and invites a pointless reflash (one project was bitten three times; one stale pair survived six sessions after being called out). Point at the authority — the verify tool, the ledger, the build file — and query it. The same goes for derived indexes: a convenience enumeration in prose that has gone stale is deleted rather than re-synced, because a wrong index is how a wrong patch gets quoted.

+ - **Confirm what is flashed by reading back** — never notes or build logs. `iflag=direct` so the read doesn't perturb. Size-only comparisons prove nothing (boot images are padded). Hash the payload. But validate the readback method itself once against known content: on one host kernel `iflag=direct` against USB storage returned a deterministic _wrong_ buffer for any freshly written image — the hazard that would have condemned good media. Verify install media cross-method (drop caches, buffered `cmp` device-vs-image, plus a hash of a file read back through a mount), and condemn hardware only on physical evidence — mid-write bus dropout, re-enumeration as a different identity-less device, disagreement across independent reads — never on a hash mismatch alone.

+ - **Attribute arch-only crashes by running the same pinned revision on the other architecture.** Same closure/revision crashing on x86_64 ⇒ upstream or packaging (miscompile class); running clean past the faulting constructor ⇒ port/display-stack specific. Strip variables before layer fixes: confirm the fault reproduces with no display stack (minimal platform), decode the core from its thread + file notes (a null vtable disassembly names the layer). Three single-layer fixes were refuted on one crash before the cross-arch run pointed at the build.

+ - **Decompose the compositing tax before any "GPU is slow" conclusion.** Matched-scene ladder, cheapest first: raw EGL surface → direct KMS (compositor stopped; the DRM-master voiding condition named and verified every run) → composited session. Check compositor CPU% to rule out starvation, A/B compositors, and verify direct-scanout engagement mechanically — compositor CPU time frozen while exactly one KMS plane is bound (it engages only for a single opaque fullscreen client with chrome hidden on some stacks). Perceived smoothness can be frame pacing, not throughput.

+ - **Long multi-session hunts need infrastructure, not memory.** Commit the smallest deterministic reproducer as a tool with a measured pass count; reconcile the incident-numbering ledger before comparing counts across sessions; pre-register predictions per experiment batch; and read back what the instrument actually received before trusting a control — one post-fix run whose gate parameter was silently dropped produced a withdrawn row (the printed received-range exposed it) and a corrected rerun reversed the conclusion. A sha256-pinned evidence manifest plus an offline replay tool that re-derives recorded metrics from the private captures closes the loop: drift is fatal, conflicts are the output.

+ - **Verification harnesses: a missing answer is a FAIL, never a silent pass.** Empty output, timeout or transport failure on a required probe = FAIL (or an explicitly modeled skip); exit nonzero when required evidence is missing; capture the producer's exit status _before_ filtering (failed log acquisition is not a clean zero-match); set pipefail so a pipeline with a failing producer fails; bound cleanup so it preserves the original failure classification and reports its own uncertainty separately. Never kill by process-name pattern — a matcher can self-match or catch an unrelated process.

+ **The sweep self-starts.** Once that precondition holds, open the sweep ledger and begin — no operator prompt, no named sources, no permission needed. Waiting to be told "search X" or "use wigolo" is a protocol failure: invoking the companion skills and walking every family below is the sweep's own first act, not a response to a request. This section is executable as written; the `/source-sweep` and `/port-research` commands are convenience entry points, not triggers.

+

+ **Run it as a ledger, not a stroll.** One row per open question × source family: consulted revision/query, finding + applicability, or a recorded gap (source + access failure). A question closes only when every applicable family row for it carries a finding or a recorded gap — the first plausible hit closes nothing, because an unconsulted family silently truncates the evidence the eventual hypothesis rests on. Keep the ledger in the project's research notes so the next session inherits coverage instead of re-searching.

+

+ 2. **Look up the target platform, userspace libs and tools** — current docs, not recalled APIs. Consult the selected OS release's docs, implementation, hardware adaptations, contribution rules, plus relevant projects discovered during research (`find-docs` per item; else the project's docs over the web). The named families below are research destinations, not a compatibility list or exhaustive set. Android-app compatibility is a target capability, not an afterthought: enumerate the candidate layers (waydroid, Android-runtime ports such as lepton, and peers), gate each on its kernel requirements — binder, PSI/memfd, GPU stack — against the exact kernel configuration being built, **and on CPU architecture features, not just kernel requirements**: one image statically emitted ARMv8.1+ LSE atomics and SIGILL'd on ARMv8.0 cores, which have no kernel emulation — kernel-compatible, every binary dead. Root-cause from the faulting instruction in the core dump, reproduce in a plain chroot to exonerate the container machinery, and verify the binder mount's fstype naming against the kernel tree. Then race the survivors on the device and benchmark the winner against the native session: one port measured the Android container faster than the phone session it ran under.

+ 3. **Web research across every source family** — fan out one parallel subagent per family by default; a serial sweep stops at the first plausible hit and silently drops the families after it. Invoke `wigolo` for the sweep (cache matters); else plain web search. All of these, in order:

+ - **GPL-published OEM kernel.** An exact release for this device usually exists: OEM open-source portal (Samsung, Sony, Xiaomi, Fairphone, OnePlus/OPPO, Motorola), GitHub/GitLab mirrors, XDA archives when portals die. Select the tarball matching phase 0's `/proc/version` — they differ. Compliance varies: treat the tree as an oracle to mine (board dts + defconfig; out-of-tree touch/panel/charger/modem drivers with register sequences and firmware handshakes), not something that builds. No exact release? A sibling's usually carries the SoC dtsi — but better is **the stock DTB pulled off the device** (`dd` untouched boot slot, scan `d00dfeed`, `dtc -I dtb -O dts`): ground truth for this board, has corrected wrong sibling-SoC guesses including a SMMU stream ID. Classes with no OEM drop at all: the stock crash log's verbatim kernel fingerprint maps onto the open-source kernel's release tags and becomes the phase 2 oracle — bulk-harvest the crash-log store early, it also yields the OS upgrade history and corroborating hardware events (one battery verdict leaned on a captured brown-out panic).

+ **Diff the reserved-memory map region-by-region against the downstream/vendor tree before hunting unexplained single-CPU hard lockups.** An under-reserved firmware window backed by XPU protection, handed to the buddy allocator by the SoC dtsi, makes a CPU store never return: no tick, no IPI, silent under NMI, with RCU stalls and IPI failures as secondary noise — and fresh page-cache workloads hit it while `O_DIRECT` (the same few pages) does not, which reads as a workload bug rather than a map bug. One board was 28 MiB short; MemTotal delta matched the shortfall exactly, and ~340 expected wedges at the old rate went to zero post-fix. The proposed mechanism must retro-explain the whole incident ledger and list what it still fails to explain; adopt the vendor map only as a separately verified change — moving a region can break a working peripheral.

+

+ - **Firmware-boot bring-up has its own gates — check each delivery link before building.** The bootloader's DTB-injection command is refused under kernel lockdown — disable Secure Boot first and verify the toggle path works on the first boot; the distro's automatic-DTB database may not carry the device even when the SoC is supported (one had two entries for the SoC, both the other vendor); a generic dtbloader's device list must be checked per device. Plan installed-boot DT persistence (loader-spec `devicetree` field + same cmdline) at install time, not just the live path; echo each loader stage so failures are visible at the menu, not inferred from silence. **Never hand-author a memory node**: the EFI stub overrides memory from the firmware map, and a wrong fixed `reg` silently poisons memblock — instant, console-less death indistinguishable from every other silent failure; upstream firmware-boot DTs for the same SoC ship no memory node at all. **Separate delivery from content when a hand-authored DTB dies silently**: boot the same kernel+initrd with a sibling board's known-good DTB — a _different_ failure signature proves the handoff works and isolates the fault to board-DT content. **One-shot boot-menu selection is BootNext semantics**: any early reset lands in the default OS, so "rebooted back into the stock install" is the expected crash outcome on a dual-boot firmware target, not evidence against the entry or the media. **Declare the verdict surface before the first boot on a serial-less device**: bare `earlycon` activates UART autodetect and prints nothing where no UART exists (identical silent death, with earlycon set); if the boot-menu render proved the firmware console works, the firmware framebuffer is the early-console candidate — and dmesg-over-network is the verdict surface, not the screen. **Run the non-destructive falsifier ladder on stock live media before any port work**: boot menu + unsigned-media boot; Secure Boot state and toggle; the boot _menu render itself is a free display test_ that answers the installer-display question and can demote the panel to a stretch goal; keep a stock-firmware, no-DTB entry as a known-behavior baseline. Kill gate: menu or toggle failure ⇒ research the firmware first.

+ - **Before suspend experiments, prove the wake source standalone and abandon the watchdog.** Arm the RTC alarm +30 s _without_ suspending and require the alarm interrupt count to increment; mind time-base skew — NTP-corrected wall clock vs unsynced/read-only RTC (one device "slept" exactly its wall-clock timeout against a +75 s alarm). Mainline watchdog drivers stop the watchdog in late suspend by design, so successful entry is unrecoverable from the watchdog — it is not a safety net. A USB-only control channel makes suspend a one-way trip until operator hands, even when resume works.

+ - **Remote-processor shared memory is DMA-API territory, and remove-entry is not ownership-end.** Stage with `dma_alloc_coherent` (pages + IOVA + cache discipline, `dma_wmb` before the doorbell), never vmap, manual IOMMU maps or assumed contiguity; a driver's remove callback running does not prove the remote processor finished with the RAM — retain the backing until the unmap is acknowledged; a timeout does not establish ownership end. Validate packet builders by executing the construction on the host and inspecting the receiver-visible wire fields: the driver's logged address is not the wire address, and one double-counted header had the receiver reading zeros.

+ - **Preserve vendor read-only hardware policies.** A PMIC RTC whose writes the hardware rejects stays read-only: enabling writes yields a denied-write flood and does not fix the epoch discrepancy — withdraw the property. A DT overlay remove/reload is not an idempotent reset (refcount underflow) — between overlay candidates, preserve evidence and reboot.

+ Before writing, recheck phase 0's handset/transport mapping, product, slot. **Stage the first rootfs where removal is the escape hatch.** Removable media first — card pull is a zero-flash exit and was the _primary_ hatch on one port; keep the stock OS on the untouched slot as the recovery OS; whitelist flash writes to the boot/verification images on one slot; record the known-good image path before each variant; fail the build loudly as the boot image approaches its partition size. **A deployment is a state machine.** Separately observe: artifact preparation, transfer/installation, next-boot selection, live activation (where supported), boot. Map to the target's actual update model; do not invent profiles/slots/live activation where absent. No earlier state proves a later one. Nix-style: a closure present ≠ activation; a matching profile symlink does not prove activation completed; an explicit activation request reruns even when nothing needed copying. Only a separately observed reboot marks booted — never flash or reboot to make recorded states agree. After the authorized deployment: readback, required reboot through an available channel, identify running kernel/modules/system. Recheck boot-time init + runtime functions: one upgrade lost sound-card registration to module coldplug ordering though later manual init worked. Service readiness, silent playback, operator-confirmed acoustics are separate results; retain deferred/untested criteria explicitly. Revalidation honesty lives in the host-side gotchas: a required probe's empty output, timeout or transport failure is a **FAIL, never a SKIP**, never a silent pass — and a verification tool must never trigger an implicit build for a missing image argument.