fix(ebuild): ask ninja for the Windows test binary

[thompsondev]

Summary

On Windows, native type: test targets are linked as <name>.exe, but ebuild test asked Ninja to build <name> and then looked for that unsuffixed path. Ninja reported an unknown target; the runner reported "built, but no binary".

A second Windows bug aborted pytest collection when gcc was not installed: a skipif called subprocess.run(["gcc", "--version"]), which raises FileNotFoundError instead of returning non-zero.

Type of Change

• fix — Bug fix
• test — Add or fix tests
• docs — Documentation updated with the behavior change

Changes

• Add executable_output_path() in ebuild/build/ninja_backend.py so the Ninja edge and ebuild test use the same binary path (.exe on Windows).
• Use that path in _run_native_tests for both the Ninja target list and the binary that is executed.
• Replace the collection-time gcc skipif in tests/ebuild/test_build_dir_resolution.py with shutil.which plus OSError handling.
• Document the fix in README, CHANGELOG, and docs/compatibility.md.
• Record leftover work as T-003: ebuild package still looks for the unsuffixed binary on Windows.

Testing

• New tests added for new functionality
• pytest run on Windows (Python 3.12)
• Unit tests pass (ctest --test-dir build --output-on-failure) — not applicable; this is the Python suite
• All existing tests pass — not claimed

Command: pytest

Result: 1 failed, 557 passed, 5 skipped, exit code 1.

• Regression tests for this PR passed: test_native_runner_asks_ninja_for_the_linked_binary, test_gcc_probe_does_not_raise_when_gcc_cannot_start.
• Remaining failure (pre-existing, needs gcc on PATH): tests/unit/test_footprint.py::TestMeasure::test_measures_a_real_binary.
• Skips: no gcc, no find/cpio, Windows symlink limits.

Pre-Submission Checklist

• Code compiles without warnings (-Wall -Wextra -Werror for C) — not applicable
• All existing tests pass — see Testing; one gcc-dependent test still fails on this host
• New tests added for new functionality
• Documentation updated
• Commit messages follow <type>(<scope>): <description>
• Branch is rebased on latest master — confirm before merge

Related Issues

Fixes T-002 (Windows Ninja test-target path parsing). Leaves T-003 (ebuild package unsuffixed .exe path).

Additional Notes

ebuild package has the same Windows suffix mismatch. It was left out of this PR so the test-runner fix stays reviewable on its own.

[srpatcha]

Review — ebuild#110 "fix(ebuild): ask ninja for the Windows test binary"

head: a65206b author: thompsondev ci: none reported

Verdict: The fix is right and minimal — one helper, one source of truth, both call sites
converted. I reproduced the original bug on Linux by forcing the suffix and confirmed the fix
resolves it. The PR body is unusually honest: unchecked boxes stay unchecked, the failing test
is named, and the deferred half is filed as T-003 in three places. The one real gap is that
the new regression test is platform-gated the same way the code is, so on a POSIX runner it
passes against the unfixed code too — verified.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	tests/unit/test_golden_path_commands.py:171-213	test_native_runner_asks_ninja_for_the_linked_binary computes suffix = ".exe" if sys.platform == "win32" else "" at :193 — the same gate _exe_suffix() uses — then asserts str(build / f"t_smoke{suffix}") in runs[0]. On Linux that reduces to asserting the unsuffixed path, which is exactly what the buggy code produced. Verified: applied only the PR's test files onto origin/master, leaving commands.py:2616 at str(build_path / t.name), and ran the test — it passes against the unfixed code. A Windows-only bug's regression test does not exercise the Windows path on any runner the project has, so it will not catch the same mistake in package (finding 2) or the next call site.	Force the behaviour instead of reading the platform: monkeypatch.setattr(ninja_backend, "_exe_suffix", lambda: ".exe"), then assert the ninja argument ends with t_smoke.exe. I ran precisely that probe against both trees: master: asked for …/b/t_smoke edge t_smoke.exe -> _run_native_tests raised SystemExit: 1 this PR: asked for …/b/t_smoke.exe edge t_smoke.exe -> no failure That version fails on master and passes here, on Linux, which is what a regression test for this bug has to do. Keep the existing test as the POSIX case if you like, but the suffix assertion needs to be independent of the host.
2	Low	ebuild/cli/commands.py:2534	ebuild package still does artifact = Path(build_dir) / binaries[0].name, so on Windows it reports "No built artifact at _build\app. Run 'ebuild build' first." after a build that succeeded. Deferring it is defensible and the disclosure is genuinely good — T-003 in TASKS.md, a row in docs/compatibility.md's Known Limitations table, and a note in the body. But the reason for deferral was reviewability, and after this PR the fix is one call: executable_output_path(Path(build_dir), binaries[0].name), with the helper already imported in this module at :28-32. Grepped the package: commands.py:2534 is the only remaining unsuffixed executable path in ebuild/. That leaves §9's build → test → package sequence broken at the last step on Windows, one line short.	Either take the one-liner here, or say in the body that the deferral is deliberate now that it is a one-liner — the current wording ("left out so the test-runner fix stays reviewable on its own") was written when it was not. Whichever way, finding 1's suffix-forcing test should cover package too, or T-003 gets the same untestable fix.
3	Medium	checks.txt (empty); GitHub API	No CI has run on this head. Queried it: actions/runs?head_sha=a65206b4… returns 4 runs — Simulation Test, CI — ebuild, Auto Assign PR, CodeQL — every one status=completed, conclusion=action_required, and commits/a65206b4…/status is {"state":"pending","count":0}. The runs are queued behind fork-workflow approval. So the body's 1 failed, 557 passed, 5 skipped on Windows/Python 3.12 is unreproduced, and there is no Linux result either — which matters here, because the change is platform-conditional and the two platforms take different branches.	Maintainer action, not the author's: approve the workflow runs. Same gap ebuild#103 exists to close.
4	Low	tests/ebuild/test_build_dir_resolution.py:246-259, 277-280	_gcc_is_missing() is still evaluated at import time, as the argument to skipif. That is fine — it is now wrapped in try/except OSError, which is the actual bug fix — but the function only tests the OSError branch (test_gcc_probe_does_not_raise_when_gcc_cannot_start monkeypatches which to return a path that cannot start). The shutil.which(...) is None branch, which is the common case on a bare Windows host, has no test.	One line: a second case monkeypatching shutil.which to lambda name: None and asserting _gcc_is_missing() is True. Worth noting the change is otherwise exactly right — it brings this file into line with test_ninja_backend.py:132 and test_integration_initramfs_security.py:38, which already use shutil.which in their skipif. Those two were checked; they cannot raise. This was the only offender.

Architecture conformance

Master design §9 (eBuild as the central developer control plane; ebuild build / test /
release as one flow), §9.2 (SDK design rules — "one source of truth for CLI, VS Code and
EoStudio", "actionable diagnostics with remediation guidance"), §21 Tier 1 – Foundation,
§28 (status and claims policy). .ai/tooling.md: "Exit non-zero on failure, always."
Conforms, and it is the §9.2 fix rather than a workaround.

executable_output_path() is the right shape for this: the Ninja edge at
ninja_backend.py:251-254 and the runner at commands.py:2616, 2632 now derive the path from
one function instead of each spelling the convention out. That is "one source of truth"
applied at the level it actually bites — before this, the generator and the consumer of the
generated file each knew the naming rule independently, and they disagreed. §9.2's other rule,
actionable diagnostics, is why the old symptom was expensive: built, but no binary at _build\t_smoke names a path that was never going to exist, and points the reader at the
linker rather than at the caller.

Nothing here points up a tier. ebuild/cli importing ebuild/build is within-package and
downward. §28 is worth a positive note: the body's checklist leaves "All existing tests pass"
unchecked with "not claimed", names the pre-existing failure and its cause, and lists the
skips. That is the evidence policy being followed rather than performed, and it is rarer than
it should be.

Verified by running, on origin/master + this patch and on master alone:

git apply                                        -> clean

with ninja_backend._exe_suffix() forced to ".exe" (simulating Windows):
  master   ninja asked for  …/b/t_smoke        build.ninja edge: t_smoke.exe
           -> _run_native_tests raised SystemExit: 1      (the reported bug)
  this PR  ninja asked for  …/b/t_smoke.exe    build.ninja edge: t_smoke.exe
           -> no failure                                   (the fix)

master + this PR's test files only (source fix absent), on Linux:
  test_native_runner_asks_ninja_for_the_linked_binary -> PASSES   (finding 1)

on this head, Linux:
  test_native_runner_asks_ninja_for_the_linked_binary -> PASS
  test_gcc_probe_does_not_raise_when_gcc_cannot_start -> PASS

grep for remaining unsuffixed executable paths in ebuild/:
  commands.py:2534 only  (finding 2 / T-003)

Proposed changes

1. Make the regression test force the suffix rather than read sys.platform (finding 1). The
   probe above is the shape; it is a two-line change and it converts a test that cannot fail
   into one that does.
2. Take the one-line package fix, or restate why it is still deferred (finding 2).
3. Add the which is None case (finding 4).

No fix PR opened: findings 1, 2 and 4 all belong on this branch, and the brief forbids
touching a branch belonging to an open PR. commands.py:2534 does exist on origin/master,
but a separate PR for one line that this branch is already about would be a duplicate.

Not checked

• No CI has run on this head (finding 3). Nothing here has been verified by the project's
  own pipeline; everything above is my own execution in a scratch tree.
• Nothing was run on Windows. There is no Windows host available here, so every claim
  about Windows behaviour comes from forcing _exe_suffix() to return ".exe" on Linux. That
  exercises the path-construction logic, which is the whole of this change, but it does not
  test subprocess/ninja behaviour with real Windows paths, drive letters, or quoting.
• pytest is not installed in this environment. The two new tests and the probe were run by
  importing each module with a minimal pytest stand-in (mark as identity decorators,
  monkeypatch as a record-and-undo shim, tmp_path as a real temp dir) and calling the
  functions directly. The body's full-suite figure (1 failed, 557 passed, 5 skipped) was
  not reproduced, and neither was the named pre-existing failure
  tests/unit/test_footprint.py::TestMeasure::test_measures_a_real_binary.
• No real ninja invocation. subprocess.run was stubbed in every run above, so ninja was
  never asked to build anything — what was checked is the argv it would receive.
• ebuild package was not executed on any platform; finding 2 is from reading :2534 and the
  grep above.
• The local ebuild clone was left alone — the sync step reported it dirty (4 files, on
  branch v90). All inspection was via git archive origin/master into scratch directories,
  touching neither the working tree nor the index. origin/master was confirmed current
  against git ls-remote first.
• mergeStateStatus: BLOCKED, reviewDecision: REVIEW_REQUIRED, and the body's own unchecked
  "Branch is rebased on latest master" — not investigated.

---

Automated architecture review of a65206b40b70 — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.

[srpatcha]

Review — ebuild#110 "fix(ebuild): ask ninja for the Windows test binary"

head: c7d83d8 author: thompsondev ci: none reported (see CI)

Verdict: The fix is the right shape — one helper in the backend, consumed by the CLI — and the whole suite is green here (565 passed). But there are three places that build an executable path from a target name and this PR fixes two; the third silently suppresses the flash/RAM report on Windows. The PR body also describes a different change than the diff contains.

Findings

#	Severity	File:line	Finding	Recommended fix
1	High	ebuild/cli/commands.py:516	Third site, still unsuffixed: _report_footprint does artifact = build_path / binaries[0].name and then if not artifact.is_file(): return. On Windows the linked file is <name>.exe, so ebuild build never prints the flash/RAM report. It is the silent one of the three — the other two early exits in this function log at debug level (:522, :530), this one returns with no diagnostic, so a developer cannot tell the report is missing rather than not applicable. §9.2 lists "Per-target flash/RAM reports" as an SDK design rule and §25.2 puts memory/flash reporting in MLP scope; the function's own docstring says "A developer who has to run size themselves … is not being told". Verified by execution (see CI section): with _exe_suffix() forced to .exe, the artifact on disk is app.exe, the lookup asks for app, and the function prints nothing even with /usr/bin/size present.	artifact = executable_output_path(build_path, binaries[0].name). Confirmed to restore the report (Flash: 1.7 KB / RAM: 4.6 KB / Ready to flash.) with no other change. Add a test that forces _exe_suffix() to .exe, mirroring the two this PR already wrote — that pattern is exactly what makes this provable on a Linux host. Consider changing the bare return to a log.debug at the same time, so the next instance of this is visible.
2	Medium	pr.json body vs the diff	The body describes a smaller change than the diff contains, in three places. "Additional Notes": "ebuild package has the same Windows suffix mismatch. It was left out of this PR" — but the diff does fix it at commands.py:2533, the CHANGELOG entry documents it as fixed, and TASKS.md:61 moves T-003 into Completed. "Related Issues" still says "Leaves T-003". And "Changes" claims the fix is documented in "README, CHANGELOG, and docs/compatibility.md" — docs/compatibility.md is not in the diff (9 files, verified against origin/master). A reviewer trusting the notes skips the package change and its ripple, which rewrote two test_package_efw.py fixtures.	Rewrite Additional Notes / Related Issues to match: T-003 is fixed here, not deferred. Either add the docs/compatibility.md paragraph or drop the claim.
3	Medium	pr.json body "Testing" vs TASKS.md:61	Two contradictory suite results in one PR. Body: "1 failed, 557 passed, 5 skipped, exit code 1", with the failure attributed to test_footprint.py::TestMeasure::test_measures_a_real_binary. TASKS.md:61, added by this same diff: "Full suite run on this Windows host: 559 passed, 6 skipped, 0 failed." Both cannot describe head c7d83d8, and the body's named failure is the very test this diff adds a skipif for — so the body appears to predate its own change. Per the brief, a claim the PR itself contradicts is the finding.	Keep one figure, from one run, on this head, and name the host. The body's checklist line "All existing tests pass — not claimed" is good practice and worth keeping; it is the numbers above it that disagree.
4	Low	tests/unit/test_footprint.py:61-64 and :71-74	Two mechanisms guard the same condition and one is unreachable. The new @pytest.mark.skipif(shutil.which("gcc") is None, …) means the body only runs when gcc is on PATH, so the inner except FileNotFoundError: pytest.skip(…) can only fire if gcc disappears between collection and execution. Separately, this file's probe is the bare shutil.which("gcc") is None while tests/ebuild/test_build_dir_resolution.py:246 now has the hardened _gcc_is_missing() — two probes for one question, one of them the version this PR exists to fix.	Move _gcc_is_missing() into tests/conftest.py and use it in both files, then drop the inner try/except. One probe, one place, and the next file that needs it inherits the hardened version.

CI

checks.txt is empty and no checks are reported on fix/windows-ninja-test-target-paths. Same cause as ebuild#109, and it is not a broken workflow:

gh run list   # CI — ebuild / CodeQL / Simulation Test, event=pull_request
              # completed  action_required  0s

action_required means the runs are queued awaiting maintainer approval under this repo's outside-contributor Actions policy. ci.yml triggers on pull_request: branches: [master, main] and this PR's base is master, so the trigger is correct. A maintainer needs to click "Approve and run workflows"; nothing the author can do from the PR will produce evidence. Until then this PR's Windows claims — which are the entire point of it — cannot be checked by CI on any Windows runner.

Reproduced locally at this head (fresh worktree, venv with pytest, click, pyyaml, ninja; gcc and /usr/bin/size present):

pytest -q                                        # 565 passed in 3.57s
pytest -q -k "native_runner_asks_ninja or gcc_probe or windows_suffixed_artifact"
                                                 # 4 passed, 561 deselected

So the suite is fully green on Linux, and both _exe_suffix()-forcing tests do exercise the Windows path on a POSIX host as the docstrings claim. Neither number quoted in the PR reproduces here, which is expected across hosts — but it does mean the body's "1 failed" is not a property of the code.

Finding 1 verified by execution, both directions, with _exe_suffix() forced to .exe:

linked artifact on disk:            app.exe          (exists)
what _report_footprint looks for:   app              (does not exist)
_report_footprint output:           <nothing>
with `artifact = executable_output_path(build_path, binaries[0].name)`:
  Flash:     1.7 KB
  RAM  :     4.6 KB
  Ready to flash.

I did not open a fix PR for finding 1. It is a one-line change inside this PR's own subject area, and an autofix/ branch off master would have to add the same executable_output_path import block this branch adds, colliding with it. Per the brief, a duplicate fix is worse than none — it belongs in this PR.

Architecture conformance

Conforms, with one deviation.

• §9.2, "One source of truth for CLI, VS Code and EoStudio" — conforms, and this is the good part of the PR. The path rule now lives once, in the build backend (ninja_backend.executable_output_path), and the CLI consumes it. The dependency direction is right: ebuild/cli depends on ebuild/build, never the reverse. Exposing it as a public helper rather than leaving _exe_suffix() private is what let the writer and the two readers converge.
• §9.2, "Per-target flash/RAM reports" — deviates, via finding 1. Two of three consumers were converted.
• §21 tier placement — correct. Tier 1 ebuild, developer-platform work, no cross-tier reach. §5.1 is not engaged; no dependency direction changes and nothing points up a tier.
• .ai/reviewer.md, weakened checks — checked, and nothing here qualifies. The skipif added to test_footprint.py replaces a probe that aborted collection, and gcc is present on ubuntu-latest, so the assertion still runs on the leg that can run it. That is an environment guard, not a disabled test. Finding 4 is about the duplication, not the skip.

Proposed changes

1. Finding 1 — one line in _report_footprint, plus the .exe-forcing test. This is the change that makes the PR's own claim ("so the Ninja edge and ebuild test use the same binary path") true of every consumer rather than two of three.
2. Finding 4 — hoist _gcc_is_missing() to tests/conftest.py, use it in both files, drop the now-dead inner handler.
3. Findings 2 and 3 — reconcile the body with the diff, and quote one suite result from one run on this head.
4. Nothing else needs to move. The helper, its placement, and the two forced-suffix tests are the right design and I would not change them.

Not checked

• No Windows verification at all. Everything above is Linux/CPython 3.12. The PR's entire subject is Windows behaviour, and the _exe_suffix()-forcing tests are a good proxy but they are a proxy: they never invoke a real gcc that appends .exe, never call a real ninja against a real edge with a suffixed output, and never exercise a path with a backslash separator. CI would cover this, and CI has not run.
• ebuild package end to end was not run against a real efwtool — the test monkeypatches shutil.which to a stub, so the .exe lookup is verified but the packaging is not.
• macOS was not exercised. _exe_suffix() returns "" for anything that is not win32, which is right for Darwin, but no run confirms it.
• ruff/lint not run — not installed here.
• The TASKS.md T-003 evidence paragraph asserts that fixing package broke existing test_package_efw.py fixtures on a real Windows host and that they were repaired. The repaired fixtures pass here, but the original Windows failure that motivated the change was not reproduced.
• docs/compatibility.md content was read but not assessed for whether it should carry this note; finding 2 only reports that the body claims a change to it that is not present.

---

Automated architecture review of c7d83d86ef99 — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.

[srpatcha]

Review — ebuild#110 "fix(ebuild): ask ninja for the Windows test binary"

head: 26a767f author: thompsondev ci: none reported (checks.txt empty; mergeStateStatus: BLOCKED, reviewDecision: REVIEW_REQUIRED)

Verdict: The code fix is right and conforms — one executable_output_path() helper replaces three duplicated build_dir / name lookups so ebuild test, ebuild package and the footprint report all name the binary the Ninja edge actually links. The problems are in the claims around it: the PR body describes a smaller change than the diff contains, and TASKS.md records two tasks as Completed / "Verified by: self" in the same PR that implements them.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	pr.json body vs. ebuild/cli/commands.py:2531, 516	The PR body describes a different change than the diff. It says the package fix "was left out of this PR so the test-runner fix stays reviewable on its own" and "Leaves T-003 (ebuild package unsuffixed .exe path)" — but the diff fixes package (commands.py:2531) and _report_footprint (commands.py:516), and TASKS.md marks both done. It also claims documentation in docs/compatibility.md, which is not in files.txt. A reviewer reading the body reviews the wrong PR.	Rewrite Summary / Changes / Related Issues against the head commit: three call sites fixed, T-002/T-003/T-004 all addressed, and drop the docs/compatibility.md claim or add the file.
2	Medium	pr.json body "Testing" vs. TASKS.md:68, TASKS.md:69	Three mutually exclusive suite results are asserted for one PR: body "1 failed, 557 passed, 5 skipped, exit code 1"; T-003 "559 passed, 6 skipped, 0 failed"; T-004 "560 passed, 6 skipped, 0 failed". The body further names the remaining failure as test_footprint.py::TestMeasure::test_measures_a_real_binary — the very test this diff puts a gcc_is_missing() skipif on (tests/unit/test_footprint.py:61), so at head it skips rather than fails. None of the three runs can be matched to 26a767f4. Per brief §5, the unsupported claim is itself the finding.	Quote one pytest run taken at the head commit, with its exit code, and delete the two superseded counts.
3	Medium	TASKS.md:68-69	T-003 and T-004 are moved to Completed with Verified by: self (see PR #110 review, finding 2) by the same PR that writes the code. .ai/reviewer.md makes this the one structural role boundary: "If you implemented it, you do not approve it." T-001 directly above it records Verified by: independent reviewer, and T-002 — the older task — is still left at review. The ledger now reads as if the newer work has more sign-off than the older.	Leave T-003/T-004 at review in the active table with the evidence text intact; move them to Completed in a follow-up once a reviewer other than the author signs off, matching T-001.
4	Low	tests/unit/test_footprint.py:298	test_looks_up_the_windows_suffixed_artifact calls commands._report_footprint, which calls _selected_board() (reads Path("eos.yaml")) and _board_config() (reads Path("board.yaml")) — both relative to the pytest process CWD, and neither monkeypatched. It passes today only because the repo root ships neither file (git ls-tree origin/master → codecov.yml, mkdocs.yml only). Anyone who runs pytest from a project directory, or who adds a root eos.yaml, changes what this test measures.	Add monkeypatch.chdir(tmp_path), or monkeypatch commands._selected_board and commands._board_config directly, as the assertion only concerns the artifact path.
5	Low	tests/conftest.py:1 (new)	gcc_is_missing() is a plain helper placed in conftest.py and then imported by name (from tests.conftest import gcc_is_missing) from two test modules. It works here — tests/__init__.py exists and pytest.ini sets pythonpath = ., so pytest imports the file as tests.conftest and the explicit import binds the same module object, not a second copy — but conftest.py is pytest's fixture/hook file and importing it from test modules is the one thing its contract asks you not to do. It is also now a suite-wide root conftest holding no fixtures.	Move the function to tests/support.py (or tests/probes.py) and import from there; leave tests/conftest.py out of the PR.
6	Low	ebuild/build/ninja_backend.py:81	executable_output_path() is now the cross-module contract for "where does the linked binary land", consumed from ebuild/cli/commands.py at three sites — but it lives in the Ninja-specific backend module. commands.py already reaches for ninja_command from ebuild.build.dispatch, i.e. the CLI is written as if the backend were dispatchable. Output-path naming is a property of the toolchain/host, not of Ninja.	Not blocking, and not worth churn in this PR: put it on the eBuild backlog to move the helper to a backend-neutral module (ebuild/build/layout.py) and re-export from ninja_backend for compatibility.

Architecture conformance

Conforms. eBuild is Tier 1 — Foundation (§21), and the change stays wholly inside it; nothing is added to eos, eBoot or any product repo, and no dependency points up a tier (§5.1). Within the repo the direction is downward and inward: ebuild/cli → ebuild/build, never the reverse. eBuild remains a build-time control plane and not a runtime dependency (§5.1).

Positively aligned with §9.2, "one source of truth for CLI, VS Code and EoStudio": before this PR the rule "the linked binary is <name> + platform suffix" was encoded once in _write_ninja and then re-derived, wrongly, at three consumer sites. Collapsing them onto one function is the correct shape of the fix, and is why finding 6 is a placement nit rather than an objection.

The behaviour restored also matters for §25.1's golden path — build / test / flash on Windows — and for the §9.2 per-target flash/RAM report, which finding 4's target (_report_footprint) is: on Windows that report silently never appeared. Adding the log.debug on the missing-artifact early return (commands.py:517) brings that path in line with the function's other two exits and satisfies §9.2's "actionable diagnostics".

Proposed changes

Smallest sequence, none of it touching the code fix:

1. Rewrite the PR body — Summary, Changes, Related Issues — to describe three fixed call sites (test, package, footprint) rather than one. Drop docs/compatibility.md from the claim list or add the file (findings 1).
2. Re-run pytest at 26a767f4 and replace all three result counts with that single run and its exit code (finding 2).
3. In TASKS.md, move T-003 and T-004 back into the active table at review, keeping the evidence prose. Nothing else changes (finding 3).
4. In tests/unit/test_footprint.py::TestCLIFootprintReport, add monkeypatch.chdir(tmp_path) (finding 4).
5. git mv tests/conftest.py tests/support.py and update both importers (finding 5).

Steps 4–5 are the only code edits and neither changes product behaviour; the suite should be re-run after them, which also produces the single result step 2 needs.

Not checked

• Nothing was executed. The ebuild working tree is dirty (4 files) and the sync step left it untouched, so 26a767f4 is not in the local object store (git log 26a767f4 → bad object). Every judgement here is read from diff.patch plus origin/master at 6a22e36.
• Therefore all four suite counts in the PR are unverified — I did not reproduce any of them, including the one I recommend keeping.
• The Windows behaviour itself is unverified: no Windows host, no gcc-on-Windows link, so the .exe suffix claim is taken from _exe_suffix()'s sys.platform == "win32" test as read, not observed.
• Findings 4 and 5 were reasoned against origin/master sources (_board_config, _selected_board, pytest.ini, tests/__init__.py) — if the PR branch changed any of those outside this diff, re-check.
• CI is not "pass" and not "fail": checks.txt is empty, so no required check result was available to me at all. mergeStateStatus: BLOCKED is reported but I could not determine what blocks it.
• Whether the branch is rebased on master — the author's own checklist leaves this unticked — was not checked.

---

Automated architecture review of 26a767f4043b — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.