probe-macos-tray-on-windows

name	probe-macos-tray-on-windows
description	Daily cross-platform health probe — compiles the macos-tray crate from the local Windows host. Expected to succeed as a stub (the crate is fully cfg-gated for non-macOS); a build failure here means a shared module or crate broke for everyone. Files structured findings to plan/issues/probe-macos-tray-on-windows-findings-<DATE>.md.

/probe-macos-tray-on-windows

Distinct from /build-macos-tray (which is the macos host's full build + sign + install + smoke + install-locally cycle, owned by the macos slot and lives at .claude/skills/build-macos-tray/SKILL.md). This skill is the windows host's daily cross-platform health probe of the same crate.

A daily probe (scheduled via /loop 24h) that compiles tillandsias-macos-tray from the windows host. The crate is cfg-gated: every macOS-only module is behind #[cfg(target_os = "macos")] and the Apple-only deps (objc2_virtualization, objc2_app_kit, etc.) live under [target.'cfg(target_os = "macos")'.dependencies] in Cargo.toml, so on Windows the build succeeds as a stub (a tiny main that exits 1 with a pointer to the spec).

The value of this loop is therefore the inverse of what I first assumed: a Windows build SUCCESS = healthy cross-platform discipline; a Windows build FAILURE = something broke in the cross-platform-shared portion of the crate (menu_disabled_v2, terminal_attach, or any shared crate the stub still pulls in like tillandsias-host-shell). That kind of failure is precisely what the linux dev box's cargo check --workspace is supposed to catch pre-merge — this loop catches it from the other host's perspective and files findings so the macos host sees them too.

Why this exists

The user explicitly asked for this loop so that:

1. Windows-side build attempts surface in the multi-host plan.
2. Other hosts (notably the macos host) see any issues that might affect them.
3. We capture a clean, reproducible "this is what the build looks like from windows today" snapshot in case a future cross-compile path becomes viable (e.g. clang-cross, an MSI'd toolchain, GitHub Actions matrix).

Treat this file as the source of truth; tune it between iterations as the cross-platform story evolves.

Working dir

C:/Users/bullo/src/tillandsias

Steps

1. Sync working tree

git fetch --all -q
B=$(git branch --show-current)
[ "$B" = "windows-next" ] || { echo "WRONG BRANCH: $B"; exit 1; }
git merge --ff-only origin/linux-next 2>&1 | tail -2

2. Attempt the build

$env:Path = "$env:USERPROFILE\.cargo\bin;$env:Path"
cargo build -p tillandsias-macos-tray --release

Capture both stdout and the cargo exit code. The build is EXPECTED to fail.

3. Classify the outcome

cargo exit	meaning	action
0	expected steady state — stub compiled on Windows; the cfg-gating is intact.	Record as baseline; no escalation.
non-zero	regression in the cross-platform-shared portion of macos-tray or one of its non-platform-gated dependency crates.	ESCALATE — find first error[...] line; surface it (see Step 5).

The shared modules + crates whose health this loop transitively pins:

• tillandsias-macos-tray::menu_disabled_v2
• tillandsias-macos-tray::terminal_attach
• tillandsias-host-shell (full crate — pulled by both modules above)
• tillandsias-control-wire (pulled by host-shell)

A failure surfaced here means at least one of those broke for everyone, not just macOS — even though only the macos-tray's daily build is the canary.

4. Findings file

Mirrors macOS's /build-macos-tray ledger pattern: one file per day, append a section per run. Path:

plan/issues/probe-macos-tray-on-windows-findings-YYYY-MM-DD.md

Header (if file does not exist):

# /probe-macos-tray-on-windows findings — YYYY-MM-DD

Generated by `/probe-macos-tray-on-windows` (the windows host's daily
cross-platform health probe of the macos-tray crate). One section per
build run. A build SUCCESS = healthy cross-platform discipline; a
FAILURE means something broke in the shared modules
(`menu_disabled_v2`, `terminal_attach`) or shared crates
(`tillandsias-host-shell`, `tillandsias-control-wire`).

trace: skills/probe-macos-tray-on-windows/SKILL.md
       skills/build-macos-tray/SKILL.md (the macos host's authoritative
       full-build skill; do NOT invoke from windows)

Then append per run:

---

### YYYYMMDDTHHMMSSZ — <SECTION_KIND>

- agent_id: <id>
- head_sha: <short SHA>
- cargo exit: <N>
- first error line: <verbatim | none>
- classification: <expected (cfg-gated stub) | UNEXPECTED: <category>>
- shared-crate impact: <none | crate <name>: <excerpt>>

**Findings**: <text>

**Cross-host visibility note**: <text | N/A>

**Next iteration ask**: <text | N/A>

SECTION_KIND: ok (exit 0, stub built cleanly), regression (exit non-zero on previously-green shared crates — ESCALATE), degraded (build succeeded with cargo warnings; surface for review).

(Legacy ledger path used for the first invocation: plan/diagnostics/build-macos-tray-from-windows-YYYY-MM-DD.md — left in place for historical reference; new runs use the path above.)

# build-macos-tray (from windows host) — YYYY-MM-DD

**Branch:** <branch> @ <short SHA>
**cargo exit:** <N>
**First error line:** <verbatim>
**Classification:** <expected: objc2_virtualization | expected: objc2_app_kit
                    | expected: linker | UNEXPECTED: <category>>
**Shared-crate impact:** <none | crate <name> error: <excerpt>>
**Action needed:**
- If classification is `expected`: none from any host. Recorded as the daily
  baseline.
- If classification is `UNEXPECTED` AND shared-crate-impact is non-none:
  ESCALATE — flag in `plan/issues/tray-convergence-coordination.md` so the
  affected host can act before their next integration cycle.

5. Conditional cross-host coordination note

If and only if Step 3 surfaced an UNEXPECTED shared-crate error: append a short entry to plan/issues/tray-convergence-coordination.md describing the error + which crate + the reproducer. Do NOT delete others' notes — append only.

6. Commit + push

git add plan/diagnostics/build-macos-tray-from-windows-YYYY-MM-DD.md
[ -f plan/issues/tray-convergence-coordination.md ] && \
  git add plan/issues/tray-convergence-coordination.md
git commit -m "diagnostics(windows-next): build-macos-tray-from-windows YYYY-MM-DD"
git push origin windows-next

7. Report

Print a 4-line summary: cargo exit, first error excerpt, classification, and whether an escalation note was filed.

Tuning log

• 2026-05-29: initial. Documents the expected-failure modes and the single case (UNEXPECTED + shared-crate-impact) that warrants escalation. The classification list will need refinement as Rust ecosystem changes — e.g. if objc2_virtualization ever ships a Windows-stub that fails differently.