Expand DMG intelligence for Linux parity drift

[joshyorko]

Summary

• classify macOS/Windows gates as Linux parity drift, new upstream capability, expected platform-native behavior, unsupported platform behavior, or review-required drift
• inventory protected Linux surfaces, plugins, native binaries, bridges, feature staging, and new issue candidates with exact owner paths and recommendations
• extract raw app.asar safely for required and protected patch preflight instead of treating the archive as an extracted app
• make acceptance depend on exact required Computer Use and Read Aloud parity patch results while preserving upstream gate evidence
• document the release report tables and blocker/review semantics

Root cause

The existing intelligence report could inventory a DMG, but it did not turn platform gates, newly shipped plugins/native helpers, or Linux patch viability into a release decision. Raw DMG runs also lacked an extracted ASAR tree for patch preflight, allowing missing Linux parity to remain an indirect manual review task.

Validation

• node --test scripts/dev/upstream-dmg-intel.test.js
• syntax and protected-surface registry validation
• real 26.707 versus 26.623 DMG run against current upstream main
• the real run identifies linux-computer-use-install-flow as the exact parity blocker, reports two blocking Linux parity gates, keeps Sites/Chronicle/Skysight/Computer Use/Read Aloud surfaces present, and emits five issue candidates
• the integrated self-hosted run passes all 14 required/parity patch preflights with zero blockers

[Yo-DDV]

Hi @joshyorko, I reran this draft at fbe65b3 against the current 26.707.31428 DMG, then stacked the current #736 and #738 heads. The stacked run does pass all 14 selected preflights. I still found five blockers before this is ready.

1. The isolated preflight copy can write outside its temporary root. copyDirectoryContents() preserves symlinks at scripts/lib/upstream-dmg-intel.js:347, and the patcher later follows them when writing bundles (scripts/patches/runner.js:170). I reproduced this with a main-bundle symlink to a temporary victim outside the copy. The copied path remained a symlink and patching changed the victim's hash. Please reject symlinks in extracted input, verify containment before writes, and add a test proving the external target stays untouched.

2. A failed required patch can still produce acceptance = accepted. The child runs with --enforce-critical, but its report is filtered to PATCH_PREFLIGHTS at scripts/lib/upstream-dmg-intel.js:186; buildDecision() never checks the resulting global blocked status or child exit code (scripts/dev/upstream-dmg-intel.js:117). With all 14 selected names marked applied, an unselected linux-quit-guard marked failed-required, and child exit 1, the preflight reports blocked but exposes zero blocker findings and the final decision is accepted. Please surface every required failure, preferably from the existing required-patch policy, and gate directly on preflight status as a backstop.

3. A Computer Use gate left in the patched tree can be relabeled as covered. The new post-patch checks only run when includeComputerUsePlatformGates is true (scripts/lib/upstream-dmg-intel.js:1482), while the production caller at scripts/patch-linux-window-ui.js:56 does not enable it. The raw gate map then marks every gate for the surface as patched-linux-parity when the five patch names succeeded (scripts/lib/upstream-dmg-intel.js:1808). I reproduced a remaining macOS/Windows Computer Use gate yielding zero integrity findings and zero blockers. Please run these checks on the patched candidate and require per-gate evidence before clearing the raw gate.

4. The negated Linux pattern is classified backwards. The scanner explicitly matches process.platform!==`linux`&&process.platform!==`darwin` at scripts/lib/upstream-dmg-intel.js:1746, but classifyPlatformGate() treats any match containing the Linux literal as already-linux-enabled (scripts/lib/upstream-dmg-intel.js:1514). The expression therefore gets zero blockers, zero review items, and a "No action" recommendation even though it excludes Linux. This needs operator-aware classification plus a regression test.

5. The new Dagger section documents local tooling that is absent from the PR and main. docs/upstream-dmg-intelligence.md:236 references a missing bridge/module and Headroom function, then includes a LAN address and a contributor-specific absolute home path. Please remove that section from this PR or land the actual portable implementation with neutral configuration examples.

For context, the existing targeted suite passes 27/27, the full Node check passes 782/782, and the script smoke suite passes. These cases are outside the current coverage.

[ilysenko]

Please take this pull request out of draft status so it can be reviewed.

[avifenesh]

Solid direction — the platform-gate classification model and the isolated app.asar preflight are exactly what release triage needs, and the decision arithmetic (protectedSurfaceBlockersCount + linuxParityGateBlockersCount split) reads clean. Two things need fixing before merge, one worth a follow-up:

1. docs/upstream-dmg-intelligence.md — the "Optional Dagger MCP" section documents artifacts this PR doesn't ship and leaks personal infrastructure.

• It references scripts/codex-dmg-intel-dagger-mcp, dagger functions, dagger call verify-dmg-intel etc., but no Dagger module or bridge script is in the PR file list — readers get instructions for files that don't exist in the repo.
• It hardcodes what looks like your local setup: DAGGER_HEADROOM_PROXY_URL = "http://10.10.10.89", an OpenRouter model pin, and CODEX_DMG_INTEL_DAGGER_REPO = "/home/kdlocpanda/second_brain/...".
  Please drop the section (or move it to a gist / your fork's docs) until the module actually lands, and scrub the personal endpoints/paths either way.

2. Hardcoded patch-id sets will rot. REQUIRED_PATCH_PREFLIGHTS, LINUX_PARITY_PATCH_PREFLIGHTS, and patchPreflightOwner()'s path mapping duplicate knowledge that already lives in the patch registry and the validate-patch-report profiles. Patch ids and file layouts change frequently here (they did twice this month); when they drift, the preflight silently checks the wrong set. Deriving the required set from scripts/ci/validate-patch-report.js profiles (or the registry's ciPolicy) would keep this self-updating — fine as a follow-up if you add a cross-check test that fails when a listed id no longer exists in the registry.

Minor, non-blocking:

• writeAsar test helper hand-rolls the asar pickle format — neat, but consider a one-line comment pointing at the format spec so future editors don't "fix" the 4-byte alignment.
• buildDecision now counts every new-upstream-capability into reviewItemsCount, so any new upstream plugin flips acceptance to review — that matches the documented semantics, just confirming it's intended for the daily scheduled run too.

Validation I ran: read the full diff against current main; CI checks on the PR are green; confirmed read-aloud/read-aloud-mcp parity ids still exist in-tree so the parity preflight set is currently accurate.

[ilysenko]

Thank you for the detailed investigation and release-decision work. We consolidated the useful structured-verdict and diagnostic ideas into #834, while keeping upstream intelligence as optional evidence and deriving acceptance from the shared patch reports and release profile. I am closing this PR as superseded by #834.