ci: qualify WinInspect across real Windows, Wine, ARM64, and re-intake

[mark-e-deyoung]

Purpose

Run the next affordance-substrate qualification batch on actual target substrates, not mocks/emulation-only schema fixtures.

This public-only workflow executes the sanitized WinInspect source across:

• GitHub-hosted native Windows x64;
• native Windows 11 ARM64;
• Ubuntu/Wine x64 across version tracks;
• Ubuntu ARM64 with Windows ARM64 WinInspect binaries under native ARM64 Wine where supported.

Current evidence / active blockers

• Native Windows x64 and ARM64 build and deterministic tests pass; runtime-query acceptance remains scoped to hosted runners and is not interactive native-Windows acceptance.
• Transport-falsification proved the daemon/session/loopback framing path on both GitHub-hosted windows-latest and persistent Wine. Earlier public harness/session failures are retired as current blockers for this transport/probe lane.
• The same outside-in A/B method isolates a shared CLI TCP framing defect on the public candidate: raw framed daemon.health succeeds on both Windows and Wine while the baseline CLI fails; a one-variable public experimental delta reverses both failures to PASS. This is public execution evidence/patch hypothesis, not product authority.
• Hosted Windows originally reported features.uia=false. A source-independent public probe showed COM activation changes after explicit apartment initialization. Treat that observation as mechanism evidence; authoritative implementation comparison/repair remains outside this public repository.
• Native Windows ARM64 has crossed additional public gates: native build passes, CTest passes, daemon/session and loopback framing pass, and corrected CLI health/identity/capabilities pass. Public evidence also exposed an architecture-reporting defect; authoritative repair remains outside this public repository.
• The first native ARM64 sensor attempt ended red for a harness reason and was corrected to use actual public CLI commands; that earlier exit is not ARM64 capability evidence.
• x64 MinGW builds and the actual WinInspect daemon run under Wine after narrow public experimental portability hypotheses. Those edits remain evidence/patch hypotheses until the owning authority accepts a sanitized implementation and reprojects it.
• Hosted native-Windows success does not establish WinBot Hyper-V clone lifecycle, controlled interactive desktop ownership, target UIA/input parity, driver recovery, or kill/recreate/resume.

Evidence captured

• executor OS/build/architecture/session context;
• WinInspect health and identity;
• runtime capabilities output;
• read-only top-window and bounded capture attempts;
• bounded public diagnostics;
• transport-falsification layer/result markers and one-variable A/B reversals;
• deterministic projected-source test results where applicable.

Boundaries

• Every claim is scoped to the exact hosted runner, OS/build, architecture, Wine version/track, session, and public WinInspect revision exercised.
• Cross-compilation alone is not runtime qualification.
• A successful COM activation probe is mechanism evidence, not semantic UIA parity.
• No result is generalized to other Windows versions, sessions, Wine versions, targets, architectures, or mechanisms without bridging evidence.
• This workflow uses the public repository execution plane only and introduces no paid/private compute dependency.
• Public experimental patches are evidence/patch hypotheses, not product authority. Private issue/PR coordinates, source revisions, branch names, validator internals, and repair lineage are intentionally omitted from this public record.
• No hosted-Windows result is promoted to native interactive WinBot acceptance.

This is public evidence generation, not promotion authority.

[mark-e-deyoung]

Decision-useful qualification update from real-substrate runs on 2026-09-12:

The current red matrix must not be interpreted as Wine/runtime capability failure. The lanes are stopping at distinct build/harness boundaries before Wine capability probes execute.

• Native Windows x64: MSVC build passes; CTest 3/3 passes; actual daemon reaches TCP Server listening on [10.1.0.101]:1985. The job failure is a harness race reading redirected stdout before it is flushed/populated (Get-Content -Raw returned null). This is harness evidence, not a WinInspect runtime defect and not interactive-Windows acceptance.
• Native Windows ARM64: build/tests continue to pass; current startup/probe lane is likewise a harness-stage failure, not yet capability evidence.
• x64 MinGW: the temporary <cstring> repair cleared the prior strcmp blocker. The next genuine portability defect is core/src/compress.cpp: MinGW's Compression API declarations take PVOID, while the current code passes const void* from data.data() to Compress/Decompress. This blocks the Wine x64/version lanes before runtime.
• Windows ARM64 cross-build via LLVM-MinGW: toolchain installation/targeting succeeds (aarch64-w64-windows-gnu), then -Werror stops on an unused [this] lambda capture in daemon.notify. This is a separate source/toolchain portability defect; Wine ARM64 runtime has not yet been exercised.
• Wine 10.0/10.20 historical cells currently stop during exact package acquisition; current WineHQ tracks install but then hit the x64 cross-build blocker above. No Wine-version capability frontier can be inferred yet.

Disposition impact: none. Continue to KEEP/qualify WinInspect across substrates; repair the smallest portability/harness defects and rerun. Do not add compatibility shims, infer Wine-version unsupported status, or claim native interactive Windows acceptance from these results.

[mark-e-deyoung]

Qualification harness method updated based on the latest reps. .github/workflows/transport-falsification.yml now enforces an outside-in falsification ladder and keeps native-Windows daemon startup + probe + baseline CLI + single-delta corrected CLI in one process lifetime. Both Windows and Wine lanes use loopback with firewall policy untouched and emit machine-readable-ish QUAL_LAYER / QUAL_RESULT markers for deepest layer, first blocker, causal status, and A/B reversal.

This is a harness/method correction, not a product-architecture change. The public experimental delta remains evidence/patch hypothesis; authoritative fixes still flow through private re-intake and reprojection.

[mark-e-deyoung]

Decision-quality reconciliation at exact head eaf33f0735c8af9f0a46c383cd0cd6088a31e0e9 across the parallel hosted lanes:

• transport-falsification run 34680536209 PASSes on both windows-latest and persistent Wine using the outside-in, one-process-lifetime harness;
• affordance-substrate run 34680536179 builds/tests and starts the real daemon on both hosted Windows and Wine, but then fails at the separate Query actual ... runtime capabilities step before read-only sensor probes;
• Wine-version run 34680536247 still stops in build/package-acquisition cells before runtime on most versions, while the passing transport Wine lane applies the already-qualified portability hypotheses;
• ARM64 run 34680536227 proves native Windows ARM64 build/tests PASS, but layered runtime qualification still fails; the native Ubuntu ARM64/Wine lane was cancelled after spending ~44 minutes inside the combined cross-build/runtime step.

Interpretation: do not count the x64 affordance-query failures or the current Wine-version matrix reds as WinInspect capability failures. The same-revision passing transport lane falsifies that inference; these lanes have not yet converged on the qualified harness/source-delta path. Reuse/converge on the passing transport method rather than adding another harness abstraction.

ARM64 remains a genuine independent qualification blocker: buildability is established, runtime behavior is not. Do not bridge x64 acceptance to ARM64, and do not claim interactive/native-Windows acceptance from hosted Windows.

No preserve/replace reversal is earned: KEEP/qualify WinInspect. The next useful cloud work is harness convergence plus authoritative private re-intake/reprojection of the portability deltas, then rerun the same cells.

[mark-e-deyoung]

ARM64 blocker narrowed from the completed native Windows 11 ARM64 job 103529386535 (run 34684628736):

• actual runner reports PROCESSOR_ARCHITECTURE=ARM64 / OsArchitecture=ARM 64-bit Processor;
• native ARM64 build PASS;
• CTest 3/3 PASS;
• daemon process/session + loopback listener PASS;
• raw framed daemon.health PASS;
• corrected CLI health, identity, and capabilities PASS;
• first failures occur only at read-only top and bounded capture, both as CLI communication error;
• daemon stays alive and logs no corresponding crash; capability output incorrectly reports arch=x64 and uia=false (separately tracked evidence-integrity/COM-lifecycle findings).

This changes the ARM64 qualification boundary: native ARM64 runtime/protocol/basic semantic control-plane viability is established on this hosted executor; read-only window/capture sensor behavior is not. Do not continue describing ARM64 as merely buildable or wholly runtime-unqualified.

Before attributing the two sensor failures to ARM64 backend capability, falsify the CLI transport/client path again. Current Conn::recv performs one recv() for the 4-byte header and one recv() for the entire payload rather than exact-length accumulation; top/especially capture are the first responses likely to stress larger/fragmented frames. Next smallest rep: invoke window.listTop and a bounded screen.capture with the already-proven raw Python exact-read probe on this same ARM64 executor, then compare against the CLI. If raw succeeds while CLI fails, repair the shared client receive framing instead of adding ARM64 sensor workarounds. No interactive WinBot/native acceptance is claimed.

[mark-e-deyoung]

ARM64 sensor A/B resolves backend-vs-client attribution

Corrected ARM64 sensor falsification run 34700600448 at head 84fd13be6ed3b52f554e15ca999595b2320f17de reached the intended question on GitHub-hosted native Windows 11 ARM64.

Held constant: same ARM64 daemon/process/session, loopback transport, request methods, and the already-demonstrated CLI send-length correction.

Results:

• raw exact-read daemon.health: PASS;
• raw exact-read window.listTop: PASS with a populated HWND set;
• raw exact-read bounded screen.capture (64x64): PASS with returned BMP/base64 payload;
• CLI top --tcp: FAIL (communication error);
• CLI bounded capture ... --tcp: FAIL (communication error).

Source inspection of the same head identifies the remaining client-side defect: TCP Conn::recv() calls recv() only once for the 4-byte header and once for the entire payload, then treats any positive short read as success without looping to the advertised frame length. That is not a valid TCP framing assumption and explains why small health/control responses can pass while larger window/capture responses fail. The raw probe's exact-read loop succeeds against the same daemon and responses.

Decision consequence:

• native ARM64 WinInspect window enumeration and bounded capture backends are demonstrated working on this hosted executor;
• the prior ARM64 sensor-backend blocker is retired for these two read-only surfaces;
• CLI TCP receive framing is a bounded REPAIR candidate; reuse an exact-read pattern (the existing WinBot direct client already has one) rather than introducing a new transport/client abstraction;
• the workflow's red conclusion is partly harness bookkeeping ($LASTEXITCODE remains nonzero after the intentionally observed CLI failures), not evidence that the raw ARM64 sensor path failed;
• ARM64 architecture reporting (x64 on an ARM64 runner) remains a separate evidence-integrity repair.

This is hosted ARM64 qualification evidence only. It does not establish WinBot Hyper-V/interactive native-Windows acceptance.

[mark-e-deyoung]

Authority-state update: the validated portability subset has been accepted on the owning trusted side. Exact private repository coordinates, revision identities, branch names, and repair lineage are intentionally omitted from this public record.

Do not count the public experiment patch as closure. The next public evidence step is a fresh sanitized projection followed by same-substrate replay showing the accepted portability behavior without relying on the superseded public-side patch. CLI TCP framing, TCP/TLS UIA initialization, and ARM64 architecture reporting remain separate public evidence/repair questions; no native interactive-Windows acceptance is implied.