Sync stable packaging pipeline into dev (#527 back-merge)

[mberrys]

Why

#527 was opened against stable, not dev. Nothing on dev changed when it merged, so the Windows MSI on dev is failing for exactly the reasons it was before — dev is 59 commits behind stable and still carries the manual windeployqt / linuxdeployqt staging that #527 replaced with the CMake-generated Qt deploy-script closure.

This merges stable into dev so the integration branch is on the current packaging pipeline.

Conflicts

Three files conflicted; all resolved in favour of stable, because dev's side is exactly the superseded approach:

File	Resolution
.github/workflows/WindowsInstall.yml	Keep the pull_request: trigger so packaging runs per PR instead of only on manual dispatch. dev's only change here (#509) added a comment, not a competing trigger.
.github/workflows/LinuxInstall.yml	Drop the hand-rolled Linux Deploy Qt step; qt_generate_deploy_qml_app_script stages the closure now.
scripts/ci/test_workflow_contracts.py	Take the inverted assertions that require the manual deploy tooling to be absent.

dev's own work — the gh-243 budget exhaustion corpus and the LoopLibCore budget/preflight changes behind it — merges cleanly and is preserved.

Verification

• python3 -m unittest scripts.ci.test_workflow_contracts — 16 tests, pass
• python3 scripts/agent/check-change.py --base origin/dev — changelog, source_integrity, architecture_catalog, policy_adapters and every format: check pass except one noted below. The build:* and focused_tests checks report fail only because no configured build tree exists in the agent container (/home/user/loop/build is not a directory); configuring one requires approval under the verification budget. clang_tidy is incomplete for the same reason. These are not proven and need a real build.

Known open failure — not fixed here

Windows_MSI is still expected to fail at the relocated-tree LoopEditor --quick-smoke step with exit -1073741819 (0xC0000005, access violation, no output). That failure is inherited from stable: #527's own Windows_MSI check was red on run 33830959878 when it merged. It got past the loop-default.json profile-resolution bug it was fixing and died one step later. Diagnosing it needs a Windows runner; a dispatch on this merge's SHA is the next step.

Pre-existing issue noticed

LoopLibCore/sources/pdftextlayoutgenerator.h:44 fails clang-format --dry-run --Werror on dev and on stable alike, and the file here is byte-identical to stable. Left untouched deliberately — it is a protected path and reformatting it would widen this merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_01APUGt8sqXNZwQjki6B92S3

---

Generated by Claude Code

[mberrys]

Status from my side, plus a root-cause finding on the Windows failure that I don't think has been named yet.

What I fixed

source_integrity and policy are green as of af3ef19. Both were the same cause: merging stable in combined dev's budget-exhaustion corpus with stable's Loop rename contract, surfacing five legacy tokens. working-directory: loupe in reusable-linux.yml:79 / reusable-windows.yml:92 was also what killed agent-fast / build outright (An error occurred trying to start process '/usr/bin/bash' with working directory '.../loop/loupe'. No such file or directory).

The Windows failure has changed character

It is no longer the LoopEditor --quick-smoke access violation that #527 merged with. On 16e6382 the relocated-tree smoke dies earlier:

OK: Report schema
Exception: scripts/smoke-test-install.ps1:210
PdfTool version probe failed with exit code -1073741515

-1073741515 is 0xC0000135 — STATUS_DLL_NOT_FOUND, not the 0xC0000005 access violation seen before. On run 33830959878 (#527's head) that same probe passed: OK: PdfTool reports a canonical semantic version. So the relocated tree has gone from "PdfTool loads, editor crashes" to "PdfTool cannot resolve its DLLs at all".

Why, reading the tree at 63e3f5b

The only Qt deployment left anywhere in the repo is:

LoopEditor/CMakeLists.txt:90:  qt_generate_deploy_qml_app_script(TARGET LoopEditor ...)

• CMakeLists.txt:46 still defines option(LOOP_INSTALL_QT_DEPENDENCIES ...), and WindowsInstall.yml still passes -DLOOP_INSTALL_QT_DEPENDENCIES=ON, but the install(DIRECTORY ${LOOP_QT_ROOT}/...) block that used to act on that option was deleted on stable in 784f419 ("deploy Qt closure from installed tree"). The option is now close to a no-op at the root level.
• grep -rn windeployqt .github/workflows/*.yml returns nothing — the manual staging step went away with the same change.

That leaves the entire Windows Qt runtime closure generated from one target, LoopEditor. PdfTool is a separate executable that is not a deploy-script target, so nothing guarantees its runtime dependencies are staged into usr/bin. That matches the symptom exactly: the first thing the smoke runs from the relocated tree is PdfTool.exe --version, and it fails to load.

Worth checking whether the recent install(FILES) / plugin-ordering changes shifted what lands in usr/bin, since the PdfTool probe passing on #527's head and failing now is a regression within this branch, not an inherited failure.

Not pushing

CI on 63e3f5b is still in flight and the last five commits are active work from another agent on these same files. I'm not pushing a competing fix on top of an in-flight run — say the word and I'll take it, otherwise I'll keep watching and report.

---

Generated by Claude Code

[mberrys]

agent-fast / build is still red on 7f29bd4, and my clang-format fix was necessary but not sufficient. Narrowing it down, with what I can and cannot see.

What the job actually did

From the job's step list, not the log:

• Step 33 "Build project" — success (11:32→11:39)
• Step 43 "Prove change with agent-fast" — failure, 11:39:17 → 12:13:25 (34 minutes)

So the tree compiles; the failure is inside scripts/agent/check-change.py.

What the evidence JSON shows

The tail of the emitted report is unambiguous on the checks it covers:

• focused_tests → pass — 100% tests passed, 0 tests failed out of 44
• every clang_tidy:* entry visible → pass
• the build:* entries visible (UnitTestsViewportController, UnitTestsWorkloadEnvelope) → pass
• trailer: "risk": "high", "status": "fail", comparison_base_sha: 1c0481b

status is fail only when some entry has result == "fail" (check-change.py:415). So exactly one check in the array is red, and it is above the portion I can reach.

Why I can't name it

The checks array holds roughly 70 entries — 4 leading checks, 9 format:*, ~54 build:*, 9 clang_tidy:*, focused_tests — and the clang_tidy entries embed thousands of lines of warning output each. The failing entry sits somewhere in the ~1700 log lines above the tail. The log tooling I have exposes only tail_lines, with no offset or search, so I cannot slice the middle out without pulling the entire job log.

What I could rule out locally, running the same script against the same tree at comparison_base_sha 1c0481b: changelog, source_integrity, architecture_catalog, policy_adapters and all nine format:* checks pass (clang-format 18.1.3, same major as the ubuntu-24.04 runner). Locally the build:* and focused_tests entries fail only because this container has no configured build tree, which is exactly the region that masks the CI failure from me.

So my best remaining hypothesis is a single build:<target> entry — a per-target cmake --build that "Build project" and build_ubuntu don't cover. I am not going to push a fix on a hypothesis; I've already been wrong once assuming the format gate was the whole story.

What would settle it in seconds

Opening the job and searching the "Prove change with agent-fast" output for "result": "fail" names the check directly. If someone pastes that entry here — or re-runs with the evidence artifact upload not gated behind the step succeeding — I'll take the fix from there.

Unrelated and still open: the build_windows PdfTool DLL-not-found diagnosis in my earlier comment stands.

---

Generated by Claude Code

[mberrys]

Correcting my earlier comment, and pushing the reason nobody has been able to read this crash.

PdfTool is fixed — my previous diagnosis is obsolete

On 7f29bd4 the relocated smoke gets further than it did on 16e6382:

OK: PdfTool reports a canonical semantic version
OK: PdfTool capabilities report the Loop PdfTool identity
OK: legacy editor executable absent
OK: OcrPlugin.dll absent (V1 CLI-only OCR surface, MIC-343)
Exception: scripts/smoke-test-install.ps1:309
LoopEditor native Quick startup failed with exit code -1073741819

The 0xC0000135 STATUS_DLL_NOT_FOUND on PdfTool.exe --version is gone — the recent packaging commits resolved it. So the PdfTool deploy-closure fix I proposed in #531 (comment) is no longer the right change; please disregard that recommendation. I was about to push it and stopped after re-reading the current log.

The remaining blocker is the original failure: LoopEditor --quick-smoke exiting -1073741819 (0xC0000005, access violation) — the same one #527 merged with.

Why this crash has been undiagnosable

Note what follows the colon in that message: nothing. The captured output is empty on every occurrence, even though the workflow step sets QT_DEBUG_PLUGINS=1 and QML_IMPORT_TRACE=1.

That is not the script failing to capture. LoopEditor is built WIN32_EXECUTABLE ON (LoopEditor/CMakeLists.txt:74) — a Windows GUI-subsystem binary with no console. Qt's default message handler routes qDebug/qWarning/qFatal to OutputDebugString instead of stderr when no console is attached, so 2>&1 collects nothing and the plugin and QML import traces never reach the log. Every attempt at this crash, mine included, has been working without the one output that would explain it.

What I pushed (2edd2fc)

QT_FORCE_STDERR_LOGGING=1 around the --quick-smoke invocations, saved and restored alongside the Qt variables the script already scrubs. Eight lines, no packaging or install behaviour changed — it only makes the existing failure legible, so the next Windows run should name the QML module, plugin, or fatal error behind the access violation.

Verified before pushing: python3 -m unittest discover -s scripts/ci -p 'test_*.py' — 227 tests OK; check_loop_identity passed; check-change.py --base origin/dev reports no non-environmental failures.

agent-fast / build is still red for a separate reason I could not isolate — see my previous comment; that one still needs the failing "result": "fail" entry from the job output.

---

Generated by Claude Code

[mberrys]

Found and fixed the agent-fast / build failure I asked about earlier — no need for anyone to dig out that entry.

The failing check

Exactly one of the 72 checks in the check-change.py report fails; the other 71 pass, focused_tests included at 44/44:

{
  "name": "build:LoopEditorQuick",
  "command": ["cmake", "--build", ".../build", "--target", "LoopEditorQuick", "--config", "Release"],
  "output": "gmake: *** No rule to make target 'LoopEditorQuick'.  Stop.",
  "reason": "exit code 2",
  "result": "fail",
  "duration_ms": 5
}

"Build project" succeeds in the same job. Nothing is broken — check-change.py is asked to build a target that no longer exists, and gmake refuses in 5 ms.

It's merge integration damage

• stable retired the LoopEditorQuick library in 78e275e ("rebuild the Quick unit tests without the retired LoopEditorQuick") and folded its QML module into the LoopEditor target itself (qt_add_qml_module(LoopEditor ...), LoopEditor/CMakeLists.txt:39).
• dev still defines the old target (add_library(LoopEditorQuick STATIC), LoopEditor/CMakeLists.txt:25) and still names it in agent-policy.json.

Merging the two produced a tree where the target is gone but the policy still asks for it. That is exactly why this check is green on dev and has been red on every single commit of this branch since the merge — including before any of the packaging work started.

Fix (1f2ed65)

Removed "LoopEditorQuick" from the quick module's target list in agent-policy.json. One line. No coverage lost: the QML module is built as part of LoopEditor, which stays in the list, and nothing else in the repository references the retired target.

Verified: generate-adapters.py --write reports policy and adapters current (only agent-policy.json changed content); check-change.py --base origin/dev now targets LoopEditor, LoopLibCore, LoopLibInteraction, LoopLibQuick, PdfTool, ProductQuickAccessibilitySmoke, UnitTests with policy_adapters passing and no non-environmental failures; 227 CI policy tests OK; 19 test_check_change tests OK.

Also this round

build_windows on 50a730e failed at step 13, VCPKG: Install project dependencies, before build or smoke — so neither the console fix nor QT_FORCE_STDERR_LOGGING was exercised, and the 0xC0000005 remains unproven either way. That commit touches no vcpkg input and the identical manifest succeeded on the parent commit 40 minutes earlier, so I treated it as a transient and spent the one re-run on it. If dependency install fails again on the same commit, it is real and I'll root-cause it rather than re-run.

---

Generated by Claude Code

[mberrys]

⚠️ Flagging b8a8cc4 before this merges — now that the PR is out of draft, it would ship a user-visible Windows regression, and it did not fix the failure it was written for.

What it changes

set(_loop_editor_win32_executable ON)
if(WIN32 AND LOOP_LOOP_DISTRIBUTION)
    set(_loop_editor_win32_executable OFF)
endif()

LOOP_LOOP_DISTRIBUTION is option(LOOP_LOOP_DISTRIBUTION "Loop release profile" OFF) (CMakeLists.txt:101), and it is passed =ON only by the MSI packaging build (WindowsInstall.yml:270). The ordinary Windows CI build passes =OFF (reusable-windows.yml:283).

So the condition applies to exactly one build: the release profile that produces the shipped MSI. Users who install Loop and launch the editor get a console window behind it, every launch. Dev and CI builds keep WIN32_EXECUTABLE ON and are unaffected — the polarity is inverted from what you'd want, since the shipped binary is the one that most needs to stay GUI-subsystem.

And it didn't fix the smoke

On b8a8cc4 itself, step 17 "Smoke relocated installed tree" still failed, one second in (14:33 → 15:24, job 101060439890). Build succeeded, smoke failed anyway. So the subsystem change costs a product regression and has not been shown to buy anything.

The stated rationale — "WINDOWS-subsystem binaries crash with 0xC0000005 [under QT_QPA_PLATFORM=offscreen]" — also isn't a general Qt property; GUI-subsystem Qt apps run fine on the offscreen platform. The empty diagnostics that made this look plausible are, I think, the console/stdio issue from my earlier comment rather than the subsystem itself.

Suggested alternative

The commit message notes that ProductQuickAccessibilitySmoke is already a console-subsystem binary and already loads the same Loop.Quick module. That is the natural thing to exercise Quick startup in the relocated tree — it is a test binary, so making it console-subsystem costs nothing. Keeping LoopEditor GUI-subsystem everywhere and pointing the relocated smoke at the existing console harness gets the same signal without changing what ships.

If the editor itself must be smoke-tested, gate the subsystem on a dedicated build option rather than on the release profile, so the flag that means "this is the build we ship" is never the flag that means "make it a console app".

I have not reverted it: 6f94f95 builds on top and its run is still in flight, and I would rather not blind-revert something that may be load-bearing for a green Windows build. Your call.

---

Generated by Claude Code