Skip to content

test(tests): build renamed muse fixtures via symlink instead of binary copy - #3539

Open
zeeshaanahmad wants to merge 1 commit into
kunchenguid:mainfrom
zeeshaanahmad:up-muse-harness-renamed-process-symlink
Open

test(tests): build renamed muse fixtures via symlink instead of binary copy#3539
zeeshaanahmad wants to merge 1 commit into
kunchenguid:mainfrom
zeeshaanahmad:up-muse-harness-renamed-process-symlink

Conversation

@zeeshaanahmad

@zeeshaanahmad zeeshaanahmad commented Sep 2, 2026

Copy link
Copy Markdown

Intent

Fix tests/fm-muse-harness.test.sh so its renamed-process detection fixtures work on current macOS. The fixtures built a fake muse-bin- process by copying the system bash; on current macOS a copy of an Apple platform binary keeps the code signature bound to its original path, so the exec is refused and the process is SIGKILLed (exit 137) before it runs, and fm-harness.sh then reported an empty harness instead of muse. Build the renamed process without copying a signed system binary so the fixture runs on macOS and stays equivalent on Linux. The branch is based on upstream main and is contributed from a fork; the validation pipeline was run against the fork remote with the CI step skipped, because this repository's CI runs on the upstream pull request rather than on the fork.

Note for maintainers: docs/fm-test-isolation-proof.md records tests/fm-muse-harness.test.sh as a known failure under stock macOS Bash 3.2.57, dated 2026-08-28. That note may now be obsolete, since it plausibly shares this root cause, but it is frozen dated evidence that would need the isolation-proof harness re-run to re-measure, so it is deliberately left untouched here.

What Changed

  • Added a named_executable helper that symlinks to the system bash rather than copying it, so renamed-process test fixtures no longer carry an Apple code signature bound to the original path (a copy is SIGKILLed with exit 137 on current macOS before it can run).
  • Added presented_process_name and assert_process_presents_name helpers that read back the process name each renamed executable presents via ps -o comm=, guarding against the test silently passing without actually exercising the renamed-process detection path.
  • Updated make_spawn_fakebin, test_detects_versioned_process_ancestor, and test_detection_is_anchored to build their muse-bin-* and negative-case fixtures with named_executable, adding presentation assertions to the two test functions.

Risk Assessment

✅ Low: Single-file, test-only change that replaces a signed-binary copy with a symlink to fix the documented macOS SIGKILL/exit-137 fixture failure; I empirically verified on this macOS host that ps -o comm= reports the symlink's invocation path (not the SIGKILL'd copy behavior) and that basename correctly recovers the intended process name for both short and 21-char (Linux-truncation-length) names, and confirmed no other cp-of-signed-binary instances remain in this file or need parallel fixing (sibling test files already used ln -s/ln -sf). The added assert_process_presents_name guard is a genuine behavioral check (execs the real interpreter and reads its live process name) rather than a source-content assertion, and correctly handles Linux's 15-byte comm truncation via prefix matching.

Testing

Reproduced the pre-fix failure (copied signed bash gets SIGKILLed on exec, exit 137, harness reports empty instead of muse) against the base commit, then ran the full fm-muse-harness.test.sh suite against the target commit where all 25 tests pass, confirming the symlink-based renamed-process fixture (named_executable) fixes the macOS regression while the added assert_process_presents_name guard exercises the same code path on Linux equivalence. This is a CLI-only shell test suite with no rendered UI surface, so a test-transcript CLI artifact is the appropriate evidence rather than a screenshot.

Evidence: Target commit: full fm-muse-harness.test.sh run (25/25 pass)
ok - muse is detected through any versioned muse-bin ancestor
ok - muse detection does not claim unrelated muse-containing commands
... (23 more ok lines) ...
ok - muse trusts no busy record source
EXIT_CODE=0
Evidence: Base commit: reproduced pre-fix failure matching reported symptom
not ok - fm-harness.sh under process 'muse-bin-0.1.0-R708.1' reported '', expected muse
Evidence: Root-cause repro: copying signed system bash gets SIGKILLed on macOS
cp "$(command -v bash)" x; x -c 'echo ran' -> exit=137 (codesign shows Identifier=com.apple.bash bound to original path)

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

⏭️ **Rebase** - skipped

Step was skipped.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

  • bash tests/fm-muse-harness.test.sh on target commit 6839b20 — all 25 tests pass (ok), including test_detects_versioned_process_ancestor and test_detection_is_anchored
  • Manual repro: cp $(command -v bash) x; x -c 'echo ran' on macOS arm64 26.5.1 exits 137, confirming the code-signature/SIGKILL root cause described in the intent
  • git archive export of base commit 77ee3c8 + bash tests/fm-muse-harness.test.sh — fails with not ok - fm-harness.sh under process 'muse-bin-0.1.0-R708.1' reported '', expected muse, matching the exact regression symptom described in the user intent
⚠️ **Document** - 1 info
  • ℹ️ docs/fm-test-isolation-proof.md:127 - docs/fm-test-isolation-proof.md:127 records tests/fm-muse-harness.test.sh as a known failure alongside tests/fm-composer-lib.test.sh under stock macOS Bash 3.2.57 (dated 2026-08-28 admission evidence for the pure-contract-unit scheduler pool). That failure plausibly shares this exact root cause (copying the Apple-signed system bash triggers exec refusal/SIGKILL), so it may no longer reproduce after this fix. It's frozen dated verification evidence for an unrelated admission decision, not a living contract, and confirming/re-dating it would require rerunning the isolation-proof harness, which is outside this doc-only phase's scope. Flagging as a follow-up: maintainers may want to rerun bin/fm-test-isolation-proof.sh and annotate or retire that line if the failure no longer reproduces.
✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

The detection cases built their renamed muse-bin-<version> ancestor by
copying the system bash. macOS refuses to exec such a copy: it keeps
Apple's platform signature at a non-system path, so the exec is denied
and the process is SIGKILLed before it runs (verified macOS 26.5.1,
arm64: `cp /bin/bash x; x -c 'echo ran'` exits 137, while the same copy
re-signed ad hoc with `codesign -f -s -` runs).

Build the renamed executable with a symlink instead, which execs the
real interpreter while the kernel takes the process name from the
launch path, presenting the intended name to both `ps -o comm=` on
macOS and /proc/<pid>/comm on Linux. Add a guard that fails loudly if
that construction ever stops naming the process, so a negative
detection case cannot pass while silently checking nothing.

Verified failing on unpatched upstream main (8988af2) on macOS
26.5.1/arm64 with the same symptom (empty detection result); passes
with this fix.
@greptile-apps

greptile-apps Bot commented Sep 2, 2026

Copy link
Copy Markdown

Confidence Score: 5/5

The PR appears safe to merge, with the renamed-process construction explicitly validated by the affected detection tests.

The symlink preserves the process ancestry behavior required by the tests while avoiding execution of copied platform binaries, and the added guard prevents negative cases from passing against an empty or incorrectly named process.

Reviews (1): Last reviewed commit: "fix(tests): build fm-muse-harness's rena..." | Re-trigger Greptile

@kunchenguid

Copy link
Copy Markdown
Owner

Speaking as Kun's firstmate:

HEAD 6839b2035ace8a689ddb7e6ce91c318aa7b19dce — MERGEABLE/UNSTABLE. Linked #3535. workflow-zero (only tests/fm-muse-harness.test.sh). Author not blocked. Security: clean (symlink to bash for fixture naming; no product path change).

Attestation: MISSING — no head-bound no-mistakes attestation. NM 33658945585 approved/queued this pass (will fail without attestation). CI 33658945632 approved this pass and queued.

Contract-class: restore — pure test-fixture fix. Detection cases need a live renamed process because bin/fm-harness.sh reads ps -o comm=. Copying Apple platform bash is SIGKILLed on current macOS (signature/path binding); symlink execs the real interpreter while presenting the intended name on macOS and Linux. Guard fails loud if construction goes vacuous. Restores the already-intended detection coverage; product harness unchanged.

VISION (per rule, evidence = muse-harness test diff only):

  1. One captain, one interface — aligns (test-only).
  2. Authority is explicit and never inferred — aligns (no consent change).
  3. Scripts own the mechanics, agents own the judgment — aligns (fixture mechanics).
  4. A restart is a non-event — aligns (no state).
  5. Delegation with a spine — aligns (no new task shape).
  6. The fleet outlives any vendor — aligns (macOS+Linux portable fixture; avoids macOS-only codesign).
  7. Scope — aligns (field regression coverage). Closing: aligns.

This is waiting on you (the author), not a captain decision. Please git push no-mistakes to bind attestation to HEAD. Fork workflows approved after diff review (run ids 33658945632, 33658945585). When attestation MATCH + NM/CI green, this restore can auto-merge.

workflow-approvals this pass: 33658945632, 33658945585

@zeeshaanahmad zeeshaanahmad changed the title fix(tests): build fm-muse-harness's renamed process with a symlink test(tests): build renamed muse fixtures via symlink instead of binary copy Sep 2, 2026
@zeeshaanahmad

Copy link
Copy Markdown
Author

The no-mistakes pipeline has now been run against this branch, and its pr step wrote the ## Pipeline section into the description above. The attestation names this exact head, with review, test and document each completed.

The pipeline was run against the fork remote with the ci step skipped, since CI here runs on the upstream pull request rather than on the fork. The Require no-mistakes run triggered by that description update is queued as action_required, so it needs a maintainer to approve the workflow run before it can report a result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants