chore: untrack the sanitizer build trees committed in #110

[Kartikey1306]

Stacked on #116 (the master repair). Review the second commit. Merging #116 first leaves this a clean one-commit change.

bsan/ and bsan2/ are CMake build directories sitting on master. They arrived in 8a2d835 (#110):

files	1441
size	12.2 MB
compiled objects	4 (.o, a.out)
CMakeCache.txt	2, holding absolute paths from the machine that ran the build
references anywhere in the repo	0 (git grep bsan outside those trees and .gitignore)

They are mine. They are also the same mistake as the .coverage database that #75 carried to master and #79 had to remove: git add -A in a tree containing a build directory whose name no ignore pattern happened to match.

.gitignore already lists build/, build_test/, _build/, build-*/, build_coverage/, build_qemu_arm64/, build_sim/ — every one of those added after something got committed once. The list grows one incident at a time and only ever backwards. bsan*/ is added here so this particular name cannot come back, which is the only part of this that has any lasting effect.

Removed with git rm -r --cached, so anyone holding a local sanitizer build keeps the directory on disk; it is simply no longer tracked.

Validation

Contents only — no source, build or CI file is touched by the second commit, and the two are independent:

-DEOS_BUILD_TESTS=ON -DEOS_PRODUCT=vbox_test + ctest   ->  34/34 passed
git check-ignore -v bsan/CMakeCache.txt                ->  .gitignore:32:bsan*/

[srpatcha]

Review — eos#117 "chore: untrack the sanitizer build trees committed in #110"

head: 9f17366 author: Kartikey1306 ci: pass

Verdict: Clean. Every figure in the PR body is exact, the commit touches nothing but
.gitignore and the 1441 files being untracked, the merge onto current master is
conflict-free and reverts nothing, and the merged tree builds and passes 38/38. One
cosmetic redundancy in the new ignore patterns, and one thing the PR does not say about
what untracking does and does not undo.

Reviewing commit 9f17366 only. d58bac4 is #116, reviewed separately in this run.

The bundle's diff.patch is a tooling failure, not an empty PR — GitHub returned
HTTP 406: the diff exceeded the maximum number of files (300), and files.txt is
capped at 100 of 1442 entries. This review was done against the local clone.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Low	.gitignore:30-32	Three patterns are added where one suffices: bsan*/ already matches bsan/ and bsan2/, so the two specific lines are dead. Minor on its own, but this file's stated problem is that it accumulates one redundant entry per incident, and this adds two more.	Keep bsan*/ and drop bsan/ and bsan2/.
2	Low	PR body, "Removed with git rm -r --cached"	Accurate about the working tree, silent about history. The 12.2 MB and the /Users/kartikey absolute paths stay in the repository at 8a2d835 permanently, and every clone continues to download them. The PR reads as though the trees are gone; they are only untracked going forward.	Add one line saying so. No history rewrite is warranted — see below — but the next person reading this PR should not have to work that out.

Every quantitative claim in the body checks out against origin/master at feee272:

$ git ls-tree -r --long origin/master -- bsan bsan2 | awk '{n++; s+=$4} END {print n, s}'
1441   12769605          # 1441 files, 12.178 MB — body says 1441, 12.2 MB
$ git show --name-only --format= 9f17366 | wc -l
1442                     # 1441 deletions + .gitignore
$ git show --name-status --format= 9f17366 | grep -v '	bsan'
M	.gitignore            # the only non-bsan path in the commit
$ git grep -c bsan origin/master -- . ':!bsan' ':!bsan2' | wc -l
0                        # no reference anywhere else in the tree

The body's claim that "no source, build or CI file is touched by the second commit" is
therefore exactly true. That is worth stating explicitly, because a 1442-file diff cut
from a base 3 commits behind master is the shape that has caused real damage in this
repo twice — #93 dropping test_crypto_ed25519_loworder, and #94 currently proposing to
delete eight CHANGELOG entries. This one does not:

$ git merge --no-commit --no-ff pr117        # onto master feee272
Auto-merging tests/test_net.c
Automatic merge went well; stopped before committing as requested
$ git diff --cached --name-status HEAD | grep -v '	bsan'
M	.gitignore
$ git diff --cached --name-status HEAD | grep -c '	bsan'
1441

Nothing outside bsan/ changes, and no newer commit is reverted. The merged tree is
sound:

$ cmake -B build/host -DEOS_BUILD_TESTS=ON -DEOS_PRODUCT=vbox_test && cmake --build build/host -j6
# exit 0
$ ctest
100% tests passed, 0 tests failed out of 38

The body reports 34/34 for the same command; the difference is that master has gained
test targets since this branch's base, and 38 is what the current tree registers. Not a
discrepancy.

On finding 2, and on whether this needs more than untracking: I scanned every one of the
1441 committed blobs for credential-shaped content and found none.

$ git ls-tree -r --name-only origin/master -- bsan bsan2 | while read f; do
    git show "origin/master:$f"; done |
    grep -inE '(api[_-]?key|token|secret|password|BEGIN [A-Z ]*PRIVATE KEY)'
# no matches
$ git show origin/master:bsan/CMakeCache.txt | grep -oE '/(Users|home)/[A-Za-z0-9._-]+' | sort -u
/Users/kartikey

The only disclosure is the author's own username, which is already their public GitHub
handle. So git rm -r --cached is the correct and sufficient remedy here, and a history
rewrite would cost every consumer a re-clone for no security benefit. I am recording
that as reasoning, not as a finding — the brief asks for a committed secret to be
treated as Critical, and there is not one.

Architecture conformance

Conforms, and §21 is the reason this belongs here rather than anywhere else: .gitignore
is repository hygiene in the Tier 1 - Foundation repo that owns it. No include, link,
manifest or CMake edge is touched, so §5.1 is not engaged in either direction. The
untracked trees were never referenced by any build — git grep above returns nothing —
so no target loses an input.

The master design is silent on the class of defect this PR is cleaning up, and the PR
body identifies the gap precisely: "The list grows one incident at a time and only ever
backwards." §29 covers documentation architecture and §30 contributor experience, but no
section requires build output to live under a single reserved, pre-ignored prefix — so
every new build-directory name is unignored until someone commits it. That has now
happened at least three times in this repo (.coverage via #75/#79, and bsan/,
bsan2/ via #110). I have appended a proposal for it under
.ai/autoreview/proposals/2026-09.md.

Proposed changes

Merge it. Then, in whatever PR is convenient:

--- a/.gitignore
+++ b/.gitignore
-bsan/
-bsan2/
 bsan*/

The durable fix is the proposal, not another pattern: require build trees under a single
ignored prefix (build/** or an ignored out/), point the sanitizer, coverage and QEMU
presets at it, and replace the accumulated one-off patterns with that one rule. Until
that lands, bsan*/ is the right stopgap and this PR should not be held for it.

Not checked

• I did not verify that bsan/ and bsan2/ arrived in 8a2d835 (#110) specifically. I
  confirmed they are present on master and that this commit removes them; the
  attribution to #110 I took from the body.
• I did not audit the contents of the 4 committed binaries (a.out, the .dSYM
  payloads, and the .o files) beyond the text scan above. A compiled object is not
  usefully greppable, so "no credential-shaped content" is a weaker statement for those
  four files than for the other 1437.
• I did not run the sanitizer build itself, so I cannot say whether the CMake presets
  that produced bsan/ still work or where they now write.
• I reviewed the local clone because the bundle diff fetch failed with HTTP 406. I did
  not independently confirm that the GitHub PR head matches the local
  refs/pull/117/head beyond both reporting 9f17366.
• CI is green at this head; I read the check list, not the job logs.

---

Automated architecture review of 9f1736621631 — 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 — eos#117 "chore: untrack the sanitizer build trees committed in #110"

head: 9f17366 author: Kartikey1306 ci: pass

Verdict: Clean. Every figure in the PR body is exact, the commit touches nothing but
.gitignore and the 1441 files being untracked, the merge onto current master is
conflict-free and reverts nothing, and the merged tree builds and passes 38/38. One
cosmetic redundancy in the new ignore patterns, and one thing the PR does not say about
what untracking does and does not undo.

Reviewing commit 9f17366 only. d58bac4 is #116, reviewed separately in this run.

The bundle's diff.patch is a tooling failure, not an empty PR — GitHub returned
HTTP 406: the diff exceeded the maximum number of files (300), and files.txt is
capped at 100 of 1442 entries. This review was done against the local clone.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Low	.gitignore:30-32	Three patterns are added where one suffices: bsan*/ already matches bsan/ and bsan2/, so the two specific lines are dead. Minor on its own, but this file's stated problem is that it accumulates one redundant entry per incident, and this adds two more.	Keep bsan*/ and drop bsan/ and bsan2/.
2	Low	PR body, "Removed with git rm -r --cached"	Accurate about the working tree, silent about history. The 12.2 MB and the /Users/kartikey absolute paths stay in the repository at 8a2d835 permanently, and every clone continues to download them. The PR reads as though the trees are gone; they are only untracked going forward.	Add one line saying so. No history rewrite is warranted — see below — but the next person reading this PR should not have to work that out.

Every quantitative claim in the body checks out against origin/master at feee272:

$ git ls-tree -r --long origin/master -- bsan bsan2 | awk '{n++; s+=$4} END {print n, s}'
1441   12769605          # 1441 files, 12.178 MB — body says 1441, 12.2 MB
$ git show --name-only --format= 9f17366 | wc -l
1442                     # 1441 deletions + .gitignore
$ git show --name-status --format= 9f17366 | grep -v '	bsan'
M	.gitignore            # the only non-bsan path in the commit
$ git grep -c bsan origin/master -- . ':!bsan' ':!bsan2' | wc -l
0                        # no reference anywhere else in the tree

The body's claim that "no source, build or CI file is touched by the second commit" is
therefore exactly true. That is worth stating explicitly, because a 1442-file diff cut
from a base 3 commits behind master is the shape that has caused real damage in this
repo twice — #93 dropping test_crypto_ed25519_loworder, and #94 currently proposing to
delete eight CHANGELOG entries. This one does not:

$ git merge --no-commit --no-ff pr117        # onto master feee272
Auto-merging tests/test_net.c
Automatic merge went well; stopped before committing as requested
$ git diff --cached --name-status HEAD | grep -v '	bsan'
M	.gitignore
$ git diff --cached --name-status HEAD | grep -c '	bsan'
1441

Nothing outside bsan/ changes, and no newer commit is reverted. The merged tree is
sound:

$ cmake -B build/host -DEOS_BUILD_TESTS=ON -DEOS_PRODUCT=vbox_test && cmake --build build/host -j6
# exit 0
$ ctest
100% tests passed, 0 tests failed out of 38

The body reports 34/34 for the same command; the difference is that master has gained
test targets since this branch's base, and 38 is what the current tree registers. Not a
discrepancy.

On finding 2, and on whether this needs more than untracking: I scanned every one of the
1441 committed blobs for credential-shaped content and found none.

$ git ls-tree -r --name-only origin/master -- bsan bsan2 | while read f; do
    git show "origin/master:$f"; done |
    grep -inE '(api[_-]?key|token|secret|password|BEGIN [A-Z ]*PRIVATE KEY)'
# no matches
$ git show origin/master:bsan/CMakeCache.txt | grep -oE '/(Users|home)/[A-Za-z0-9._-]+' | sort -u
/Users/kartikey

The only disclosure is the author's own username, which is already their public GitHub
handle. So git rm -r --cached is the correct and sufficient remedy here, and a history
rewrite would cost every consumer a re-clone for no security benefit. I am recording
that as reasoning, not as a finding — the brief asks for a committed secret to be
treated as Critical, and there is not one.

Architecture conformance

Conforms, and §21 is the reason this belongs here rather than anywhere else: .gitignore
is repository hygiene in the Tier 1 - Foundation repo that owns it. No include, link,
manifest or CMake edge is touched, so §5.1 is not engaged in either direction. The
untracked trees were never referenced by any build — git grep above returns nothing —
so no target loses an input.

The master design is silent on the class of defect this PR is cleaning up, and the PR
body identifies the gap precisely: "The list grows one incident at a time and only ever
backwards." §29 covers documentation architecture and §30 contributor experience, but no
section requires build output to live under a single reserved, pre-ignored prefix — so
every new build-directory name is unignored until someone commits it. That has now
happened at least three times in this repo (.coverage via #75/#79, and bsan/,
bsan2/ via #110). I have appended a proposal for it under
.ai/autoreview/proposals/2026-09.md.

Proposed changes

Merge it. Then, in whatever PR is convenient:

--- a/.gitignore
+++ b/.gitignore
-bsan/
-bsan2/
 bsan*/

The durable fix is the proposal, not another pattern: require build trees under a single
ignored prefix (build/** or an ignored out/), point the sanitizer, coverage and QEMU
presets at it, and replace the accumulated one-off patterns with that one rule. Until
that lands, bsan*/ is the right stopgap and this PR should not be held for it.

Not checked

• I did not verify that bsan/ and bsan2/ arrived in 8a2d835 (#110) specifically. I
  confirmed they are present on master and that this commit removes them; the
  attribution to #110 I took from the body.
• I did not audit the contents of the 4 committed binaries (a.out, the .dSYM
  payloads, and the .o files) beyond the text scan above. A compiled object is not
  usefully greppable, so "no credential-shaped content" is a weaker statement for those
  four files than for the other 1437.
• I did not run the sanitizer build itself, so I cannot say whether the CMake presets
  that produced bsan/ still work or where they now write.
• I reviewed the local clone because the bundle diff fetch failed with HTTP 406. I did
  not independently confirm that the GitHub PR head matches the local
  refs/pull/117/head beyond both reporting 9f17366.
• CI is green at this head; I read the check list, not the job logs.

---

Automated architecture review of 9f1736621631 — 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 — eos#117 "chore: untrack the sanitizer build trees committed in #110"

head: a854714 author: Kartikey1306 ci: 2 required checks failing (pre-existing — see below)

Verdict: Clean. All 1441 tracked files under bsan/ and bsan2/ are gone from the head, nothing outside .gitignore and the stacked tests/CMakeLists.txt hunk is touched, nothing in the repository referenced either tree, the new pattern covers both without over-matching, and the tests still pass at 39/39. I checked the removed content for anything that would force a history rewrite and found none — that is the one thing worth stating explicitly, and the PR body does not.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Low	PR body	git rm -r --cached untracks; it does not reclaim. Commit 8a2d835 still carries all 1441 files and 12.2 MB, so every clone of this repository still pays for them permanently. The body explains what the flag does for a contributor's working copy ("anyone holding a local sanitizer build keeps the directory on disk") and says nothing about what it does not do for the repository, which is the thing a reader will assume from "12.2 MB". The reason this matters beyond housekeeping is that .ai/security.md requires history to be checked, not just the tip — so somebody has to answer whether a rewrite is needed. I checked, and it is not. Grepping both trees at origin/master for api_key/api-key, secret, token, password, passwd, BEGIN … PRIVATE KEY, ssh-rsa and AKIA[0-9A-Z]{16} returns nothing. The only identifying content is /Users/kartikey absolute paths in the two CMakeCache.txt files, which commit authorship already makes public.	One sentence in the body: the objects stay in history, the repository does not shrink, and no rewrite is warranted because nothing sensitive is in them. Recording that a check was run and came back clean is what stops someone proposing a force-push of master later on a suspicion.
2	Low	.gitignore:24-30	The body diagnoses the real problem — "the list grows one incident at a time and only ever backwards" — and then adds one more entry to the list. bsan*/ stops this name, and the next build directory with a name nobody anticipated lands exactly the same way. This author has been adding guards for precisely this shape elsewhere in the same batch (#114's tests/unit/test_cmake_test_registration.py, eBoot#95's test_suite_bookkeeping.py); the equivalent here is one assertion.	Add a check that fails when generated output is tracked, keyed on content rather than directory name — e.g. assert that no tracked path matches CMakeCache.txt, CMakeFiles/, *.o, *.a or compile_commands.json. That catches every future name, including the ones no pattern anticipates, and it fails in the PR that introduces the mistake rather than in the cleanup three weeks later. A proposal for the durable version of this ("Build output belongs under one reserved, pre-ignored prefix", triggered by this PR) is already in .ai/autoreview/proposals/2026-09.md; the guard is what closes the gap in the meantime.
3	Low	PR body, "Validation"	Two stale numbers from the pre-rebase tree: git check-ignore -v reports .gitignore:30, not :32, and ctest on this head is 39/39, not 34/34. Both are consequences of the stack having moved, and the same staleness appears in #114, #115 and #116 — worth fixing once across all four rather than treated as four separate slips.	Re-run and paste.
4	Low	CI	Two required checks are red: Cross-compile ARM64 kernel and Full-stack integration summary. This PR is the cleanest available proof that they are master's and not any contributor's: its entire diff against origin/master is .gitignore, the stacked tests/CMakeLists.txt hunk from #116, and the deletion of 1441 files that nothing in the repository references. The same pair fails on all four open eos heads in this run.	Nothing here. It does mean none of these four can merge on a green tree until master's ARM64 cross-compile is repaired, which is the thing actually blocking this batch.

Architecture conformance

Conforms; there is nothing for the architecture to conform to. No source, header, CMake target, workflow or manifest changes — git diff origin/master a8547147 --name-only outside bsan*/ returns exactly two paths, .gitignore and tests/CMakeLists.txt, and the latter is #116's test_crypto_ed25519_loworder registration arriving via the stack. No dependency edge is created or removed, so §5.1 is untouched, and eos remains Tier 1 Foundation (§21) with its layout unchanged.

The one design-level connection is §30's contributor experience, and it is already captured: the proposal file carries "2026-09-03 — Build output belongs under one reserved, pre-ignored prefix" with this PR as its trigger. I am not filing a second one.

Proposed changes

1. Add the two sentences from finding 1 to the body, including the negative result of the secrets grep.
2. Correct the two numbers in finding 3 (and, since the same problem runs through #114, #115 and #116, do all four at once).
3. Optional and worth more than the rest of this PR: the tracked-artifact guard in finding 2.

Nothing blocks merge. The diff is correct as it stands.

Not checked

• Not run: the two failing required checks. Cross-compile ARM64 kernel needs a cross toolchain and Full-stack integration summary needs the integration harness; I reproduced neither and did not determine the root cause on master.
• Not verified: the "12.2 MB" figure. I confirmed 1441 tracked paths under bsan*/ on origin/master and 0 on this head; I did not measure the on-disk or packed size, so the megabyte number is the author's and not mine.
• Not exhaustive: the secrets grep. It covered a fixed set of patterns (api[_-]?key, secret, token, password, passwd, BEGIN … PRIVATE KEY, ssh-rsa, AKIA[0-9A-Z]{16}) across the text of both trees. It would not find a high-entropy string with no surrounding keyword, and it did not examine the four binary objects (a.out, a.out.dSYM/…/DWARF/a.out and the two under bsan2/) beyond git's own binary detection. I did not run a dedicated secret scanner.
• Not verified: that no contributor has a branch or open PR touching bsan*/, which would conflict. I checked the tree, not other refs.
• Not checked: whether bsan*/ shadows any intended future path. It ignores any directory whose name begins with bsan at any depth; nothing matching that exists today.

Evidence

Read-only inspection of origin/master (feee272) and this head via git show/git ls-tree, plus a git archive extraction for the build; the eos checkout was clean and untouched.

tracked paths under bsan*/     origin/master -> 1441
                               this head     ->    0

changed paths vs origin/master, excluding bsan*/:
                               .gitignore
                               tests/CMakeLists.txt      (#116's hunk, via the stack)

references to "bsan" anywhere outside the two trees and .gitignore:
                               git grep -l bsan origin/master -- ':!bsan/**' ':!bsan2/**' ':!.gitignore'
                               -> empty

.gitignore pattern, checked against a scratch tree:
    git check-ignore -v bsan/CMakeCache.txt   -> .gitignore:30:bsan*/
    git check-ignore -v bsan2/x/f             -> .gitignore:30:bsan*/
    nbsan/f                                   -> not ignored (no over-match)

build, this head:
    cmake -B build/test -DCMAKE_BUILD_TYPE=Release -DEOS_BUILD_TESTS=ON \
          -DEOS_PRODUCT=vbox_test && cmake --build            -> OK
    ctest --no-tests=error                                    -> 39/39 passed
    (origin/master, same configuration                        -> 38/38; the +1 is #116's suite)

history check, both trees at origin/master:
    grep -iE 'api[_-]?key|secret|token|password|passwd|BEGIN [A-Z ]*PRIVATE KEY|ssh-rsa|AKIA[0-9A-Z]{16}'
                                                              -> no matches
    absolute paths in bsan/CMakeCache.txt                     -> /Users/kartikey

---

Automated architecture review of a8547147b1ea — 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 — eos#117 "chore: untrack the sanitizer build trees committed in #110"

head: f7a715b author: Kartikey1306 ci: 24 pass, Analyze (C/C++) pending, Create GitHub Release skipping; 0 failing

Verdict: The untracking is still clean. Verified at this head: 0 tracked paths under bsan*/ (1441 on origin/master), the only non-deleted changes are .gitignore, tests/CMakeLists.txt (the stack parent's) and the workflow, build is clean and ctest --no-tests=error is 39/39. The one change since a8547147 is f7a715b, which is a byte-identical copy of #135's cross-repo pin — the fifth open PR now carrying it. The four Lows from the previous review are unresolved.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	.github/workflows/eos-simulation.yml:11-20, :41, :48, :288	f7a715b ("ci: pin the eBoot and ebuild checkouts instead of floating on master") duplicates #135, and also #114's f43d860, #115's 4375466 and #116's 2a32e3a. Verified: git diff f7a715b1 <#135 head f34edb3> -- .github/workflows/eos-simulation.yml is empty, as it is against each of the other three. Five open PRs, one CI change, and none of the five bodies mentions it. Identical hunks merge cleanly so nothing breaks — but it is a real cost here specifically: the previous review used this PR as "the cleanest available proof" that the red ARM64 checks were master's and not any contributor's, precisely because its diff was .gitignore plus deletions. That property is now gone, and the CI-infrastructure change is being reviewed inside a PR about untracking build artifacts.	Drop f7a715b. #135 is scoped to it and has the staleness-guard commit these five copies lack; its substance is reviewed there and is not re-raised here.

Carried forward from a8547147 — unresolved

Not restated at length, because nothing about them has changed and the reasoning is on the thread already. In short: (1) the body still does not say that git rm -r --cached does not reclaim anything — commit 8a2d835 still carries all 1441 files, so no clone gets smaller — nor that the history check for secrets was run and came back clean, which is what stops someone proposing a master rewrite later on a suspicion. (2) .gitignore:30's bsan*/ stops this name and not the next one; the durable fix is a guard keyed on content rather than directory name. (3) the "Validation" block still cites .gitignore:32 (it is :30) and 34/34 (it is 39/39).

One new and useful fact for (2): I ran the proposed guard's predicate against this head — no tracked path matches CMakeCache.txt, CMakeFiles/, *.o, *.a or compile_commands.json. So the check would pass on day one and could be added in this PR without dragging any further cleanup in with it. That was not knowable before the deletions landed on this branch.

Architecture conformance

Conforms, and there is still almost nothing for the architecture to conform to. Outside the 1441 deletions the changed paths are .gitignore, tests/CMakeLists.txt (the test_crypto_ed25519_loworder registration arriving from the stack parent 13a8ffa, which is #127's commit, not this PR's) and .github/workflows/eos-simulation.yml. No source, header or CMake target changes, so no dependency edge is created or removed and §5.1 is untouched; eos remains Tier 1 — Foundation (§21) with its layout unchanged. The pin is a CI-time dependency onto two other Tier-1 repositories, so it points sideways, and the design gap it sits in is already recorded in .ai/autoreview/proposals/2026-09.md.

The one design-level connection is §30's contributor experience, and it is already captured: the proposal file carries "2026-09-03 — Build output belongs under one reserved, pre-ignored prefix" with this PR as its trigger. Not filing a second one.

Proposed changes

1. Drop f7a715b.
2. Add the two sentences from carried-forward item (1), including the negative result of the secrets grep.
3. Correct the two numbers in item (3) — and since the same staleness runs through #114, #115 and #116, do all four at once.
4. Optional and worth more than the rest of this PR: the tracked-artifact guard. It is now free of prerequisites.

Nothing blocks merge once f7a715b is dropped. The deletion itself is correct as it stands.

Not checked

• The bundle's diff.patch was unusable for this PR. GitHub returned HTTP 406: the diff exceeded the maximum number of files (300) — 1444 changed files. Everything above was read from the local clone over the range feee272..f7a715b1 (git diff --name-status, git ls-tree, git show) rather than from the bundle. Recording it so nobody reads this review as having been written against an empty diff.
• Analyze (C/C++) was still pending when the bundle was built, so I cannot report its outcome; nothing was failing. Cross-compile ARM64 kernel — red on this head's predecessor and on every open eos head in the previous run — is green here, which is what f7a715b buys.
• Cross-compile ARM Cortex-M4 is declared by two workflows (build.yml:74, ci.yml:117), so that name covers two check runs on every eos PR.
• Not verified: the "12.2 MB" figure. I confirmed 1441 tracked paths on origin/master and 0 at this head; I did not measure on-disk or packed size, so the megabyte number remains the author's.
• Not re-run: the secrets grep over the removed trees. It was run at a8547147 against a fixed pattern set and came back clean; the removed content is identical at this head (the delta is one workflow file), so I did not repeat it. It was never exhaustive — no high-entropy-without-keyword detection, and the four binary objects were not examined beyond git's own binary detection.
• Not verified: that no other contributor branch or open PR touches bsan*/ and would conflict. I checked the tree, not other refs.
• The pinned eBoot tree was not built. a172a6d exists and is an ancestor of eBoot's origin/master; I did not compile eos's kernel job against it.

Evidence

Read-only inspection of the local clone plus a git archive extraction for the build; the eos checkout was clean and was not modified.

tracked paths under bsan*/     origin/master (feee272) -> 1441
                               this head               ->    0
changed paths vs master, excluding bsan*/:
                               .github/workflows/eos-simulation.yml
                               .gitignore
                               tests/CMakeLists.txt      (#127's hunk, via the stack)
                               1441 deletions, 0 other modifications

build, this head:
    cmake -B build/test -DCMAKE_BUILD_TYPE=Release -DEOS_BUILD_TESTS=ON \
          -DEOS_PRODUCT=vbox_test && cmake --build     -> OK
    ctest --no-tests=error                             -> 39/39 passed

finding 1:
    git diff --stat a854714 f7a715b
      -> .github/workflows/eos-simulation.yml | 12 +++, 3 ---   (the entire delta)
    git diff f7a715b <#135 f34edb3> -- .github/workflows/eos-simulation.yml -> empty

the guard proposed at a8547147 would pass here:
    git ls-tree -r --name-only f7a715b1 \
      | grep -E 'CMakeCache\.txt|CMakeFiles/|\.o$|\.a$|compile_commands\.json'
      -> no matches

---

Automated architecture review of f7a715b1ab2b — 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.