morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[PR #2065] [MERGED] fix(native): name numeric Mach-O build-version platforms and tools #4999

New issue

Closed

opened 2026-10-31 00:57:50 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:57:50 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2065
Author: @TonyWu2333
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @morluto

Base: main ← Head: fix/macho-build-version-names

📝 Commits (2)

cdc0ad2 fix(native): name numeric Mach-O build-version platforms and tools
49f7765 fix(native): bind Mach-O build names to explicit numeric codes

📊 Changes

2 files changed (+186 additions, -2 deletions)

View changed files

📝 src/native/parsers/otool.ts (+55 -2)
📝 tests/boundary/providers/native/nativeLoadKinds.golden.test.ts (+131 -0)

📄 Description

Summary

inspect_macho reports build_metadata from otool -h -l. Non-verbose otool prints LC_BUILD_VERSION platform and tool codes as numbers, so a modern Mach-O reports platform: "1" and tool name: "3". LC_VERSION_MIN_* commands in the same field report symbolic platforms ("MACOSX", "IPHONEOS"). Callers have to know <mach-o/loader.h> to read the build platform, and the values from the two command kinds cannot be compared directly.

No linked issue: I found this while running inspect-macho against system binaries on macOS 26.5.1.

Problem and expected behavior

Before, for /bin/ls (arm64e slice):

{"platform":"1","minimum_os":"11.0","sdk":"26.5","tools":[{"name":"3","version":"1267.0"}]}

otool -lv and vtool -show-build print the same command as platform MACOS / tool LD. The normalized result should use the symbolic names too.

Change and scope

parseOtoolLoadCommands maps the platform and tool codes declared in the SDK's <mach-o/loader.h> (PLATFORM_MACOS 1 … PLATFORM_VISIONOS_EXCLAVEKIT 24, TOOL_CLANG … TOOL_METAL_FRAMEWORK) to their names without the prefix. These match otool -lv output, except that otool prints TOOL_METAL for 1024 where this uses METAL.

Unknown codes keep their printed value. A newer platform is still reported, not dropped or guessed.
Values that otool already printed symbolically pass through unchanged.
Raw load_commands[].fields still carry otool's numeric values. Only normalized build_metadata changes.

Contract and boundary impact

Semantic owner and earliest changed stage: src/native/parsers/otool.ts (collectBuild, parseBuildTools)
CLI and MCP/tool-catalog contract: no schema change. build_metadata[].platform and tools[].name remain strings; their values for known codes change from numeric to symbolic.
Provider, bridge, target-format, or platform compatibility: macOS native provider only
Evidence, artifact, provenance, or reconstruction contract: raw provenance and load-command fields unchanged
Process execution, authorization, cleanup, or containment impact: none
Generated metadata, package, or installation impact: none

Evidence and regression coverage

Tests added or updated: tests/boundary/providers/native/nativeLoadKinds.golden.test.ts: "names numeric build-version platforms and tools". It covers known and unknown platform codes, known and unknown tool codes, already-symbolic input, and unchanged raw fields.
Base reproduction or other evidence: the new test fails on 3bdc873 and passes with this change. I took the name table from the macOS 26.5 SDK loader.h and checked it against otool -lv (cctools-1040) on binaries rewritten with vtool -set-build-version for platforms 1–24 and each declared tool.
User-visible CLI/MCP output: rea inspect-macho /bin/ls --format json now reports {"platform":"MACOS","minimum_os":"11.0","sdk":"26.5","tools":[{"name":"LD","version":"1267.0"}]}
Remaining proof gaps: none known
Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

npm run test:focused -- tests/boundary/providers/native/nativeLoadKinds.golden.test.ts tests/boundary/providers/native/nativeMachoHeader.golden.test.ts tests/boundary/providers/native/nativeSelectedArchitecture.test.ts tests/boundary/providers/native/nativeReexport.golden.test.ts: 37 passed
The same new test on the base revision: fails as expected
npm run check:fast: passed
rea inspect-macho on /bin/ls, /usr/bin/ssh, /usr/libexec/sharingd, Calculator.app (macOS 26.5.1, Apple silicon): symbolic build metadata

Compatibility, safety, and release

Breaking changes or migration steps: callers that matched the numeric strings ("1", "3") in build_metadata now see "MACOS" / "LD". The raw numeric values remain in load_commands[].fields.
Real Hopper/Ghidra, browser, or OS coverage: macOS 26.5.1 native tools. No Hopper or Ghidra involvement.
Package or release metadata impact: none
Security, privacy, process, or containment review: none

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2065 **Author:** [@TonyWu2333](https://github.com/TonyWu2333) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/macho-build-version-names` --- ### 📝 Commits (2) - [`cdc0ad2`](https://github.com/morluto/rea/commit/cdc0ad2f9f60f9cb154bb60373eaa782086cea0f) fix(native): name numeric Mach-O build-version platforms and tools - [`49f7765`](https://github.com/morluto/rea/commit/49f7765b80efc9984a55d7f2b2d4d8bfb267cae8) fix(native): bind Mach-O build names to explicit numeric codes ### 📊 Changes **2 files changed** (+186 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `src/native/parsers/otool.ts` (+55 -2) 📝 `tests/boundary/providers/native/nativeLoadKinds.golden.test.ts` (+131 -0) </details> ### 📄 Description ## Summary `inspect_macho` reports `build_metadata` from `otool -h -l`. Non-verbose otool prints `LC_BUILD_VERSION` platform and tool codes as numbers, so a modern Mach-O reports `platform: "1"` and tool `name: "3"`. `LC_VERSION_MIN_*` commands in the same field report symbolic platforms (`"MACOSX"`, `"IPHONEOS"`). Callers have to know `<mach-o/loader.h>` to read the build platform, and the values from the two command kinds cannot be compared directly. No linked issue: I found this while running `inspect-macho` against system binaries on macOS 26.5.1. ## Problem and expected behavior Before, for `/bin/ls` (arm64e slice): ```json {"platform":"1","minimum_os":"11.0","sdk":"26.5","tools":[{"name":"3","version":"1267.0"}]} ``` `otool -lv` and `vtool -show-build` print the same command as `platform MACOS` / `tool LD`. The normalized result should use the symbolic names too. ## Change and scope `parseOtoolLoadCommands` maps the platform and tool codes declared in the SDK's `<mach-o/loader.h>` (`PLATFORM_MACOS` 1 … `PLATFORM_VISIONOS_EXCLAVEKIT` 24, `TOOL_CLANG` … `TOOL_METAL_FRAMEWORK`) to their names without the prefix. These match `otool -lv` output, except that otool prints `TOOL_METAL` for 1024 where this uses `METAL`. - Unknown codes keep their printed value. A newer platform is still reported, not dropped or guessed. - Values that otool already printed symbolically pass through unchanged. - Raw `load_commands[].fields` still carry otool's numeric values. Only normalized `build_metadata` changes. ## Contract and boundary impact - Semantic owner and earliest changed stage: `src/native/parsers/otool.ts` (`collectBuild`, `parseBuildTools`) - CLI and MCP/tool-catalog contract: no schema change. `build_metadata[].platform` and `tools[].name` remain strings; their values for known codes change from numeric to symbolic. - Provider, bridge, target-format, or platform compatibility: macOS native provider only - Evidence, artifact, provenance, or reconstruction contract: raw provenance and load-command fields unchanged - Process execution, authorization, cleanup, or containment impact: none - Generated metadata, package, or installation impact: none ## Evidence and regression coverage - Tests added or updated: `tests/boundary/providers/native/nativeLoadKinds.golden.test.ts`: "names numeric build-version platforms and tools". It covers known and unknown platform codes, known and unknown tool codes, already-symbolic input, and unchanged raw fields. - Base reproduction or other evidence: the new test fails on `3bdc873` and passes with this change. I took the name table from the macOS 26.5 SDK `loader.h` and checked it against `otool -lv` (cctools-1040) on binaries rewritten with `vtool -set-build-version` for platforms 1–24 and each declared tool. - User-visible CLI/MCP output: `rea inspect-macho /bin/ls --format json` now reports `{"platform":"MACOS","minimum_os":"11.0","sdk":"26.5","tools":[{"name":"LD","version":"1267.0"}]}` - Remaining proof gaps: none known - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run test:focused -- tests/boundary/providers/native/nativeLoadKinds.golden.test.ts tests/boundary/providers/native/nativeMachoHeader.golden.test.ts tests/boundary/providers/native/nativeSelectedArchitecture.test.ts tests/boundary/providers/native/nativeReexport.golden.test.ts`: 37 passed - The same new test on the base revision: fails as expected - `npm run check:fast`: passed - `rea inspect-macho` on `/bin/ls`, `/usr/bin/ssh`, `/usr/libexec/sharingd`, `Calculator.app` (macOS 26.5.1, Apple silicon): symbolic build metadata ## Compatibility, safety, and release - Breaking changes or migration steps: callers that matched the numeric strings (`"1"`, `"3"`) in `build_metadata` now see `"MACOS"` / `"LD"`. The raw numeric values remain in `load_commands[].fields`. - Real Hopper/Ghidra, browser, or OS coverage: macOS 26.5.1 native tools. No Hopper or Ghidra involvement. - Package or release metadata impact: none - Security, privacy, process, or containment review: none ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 00:57:50 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-11-01 21:42:31 +00:00

[PR #4999] [MERGED] feat(environment): export an environment manifest as an agent environment bundle #6719

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4999

No description provided.

Rows
Columns