[Kartikey1306]

CI — eos and Python Unit Tests are both red on master (769191a), and both fail for the same single reason:

these suites exist in tests/ but no add_executable() in tests/CMakeLists.txt
builds them, so they never run: ['test_crypto_ed25519_loworder.c']

What happened

3aa8644 (#93, "remove duplicate test targets from tests/CMakeLists.txt") removed all four lines that build and register test_crypto_ed25519_loworder:

-# --- test_crypto_ed25519_loworder: reject keys outside the prime-order subgroup ---
-add_executable(test_crypto_ed25519_loworder test_crypto_ed25519_loworder.c)
-target_link_libraries(test_crypto_ed25519_loworder PRIVATE eos_crypto)
-add_test(NAME test_crypto_ed25519_loworder COMMAND test_crypto_ed25519_loworder)

It was not a duplicate. There was exactly one registration before that commit:

$ git show 3aa8644^:tests/CMakeLists.txt | grep -c 'add_executable(test_crypto_ed25519_loworder'
1

Why it matters

What stopped running is the suite guarding #101 — Ed25519 rejecting low-order public keys. A low-order key makes every term of the verification equation collapse to the identity regardless of the message, so a signature of all zeros verifies against any content at all.

The fix itself is still in services/crypto/src/ed25519_verify.c and still correct.

Correction (thanks @srpatcha). An earlier version of this paragraph said "nothing has been checking it since #93 merged". That is overstated, and the overstatement undersells what the restore buys. Since #120, test_pkg_trust_anchor.c:165 test_low_order_keys_are_refused_as_anchors has covered ed25519_public_key_is_usable(), so the anchor-configuration path has been guarded. What went unguarded is ed25519_verify()'s own rejection and the forgeable-message sweep.

And that substitute is host-only: test_pkg_trust_anchor sits inside if(NOT CMAKE_CROSSCOMPILING) because eos_eapp is a host-build library, so on Cross-compile ARM Cortex-M4 and Cross-compile ARM64 kernel nothing has checked low-order key rejection since 3aa8644. The suite restored here links only eos_crypto and is unconditional, so it closes that gap too - the part with no substitute. The .c file stayed in the tree the whole time, which is what made it invisible: a suite that is present but unbuilt looks exactly like a suite that passes.

The fix

Restored verbatim from 3aa8644^, in its original position before test_crypto_sha512. No other file changes.

Worth noting: the guard that caught this is tests/unit/test_cmake_test_registration.py, added recently. This is the first thing it found, and it is precisely the class it was written for.

Validation

	master	this PR
test_cmake_test_registration.py	1 failed, 4 passed	5 passed
pytest tests/	14 passed, 1 failed	15 passed
ctest suites built	38	39
ctest	—	39/39 passed
test_crypto_ed25519_loworder	not built	5/5 tests passed

CI on this head (updated)

The paragraph above describes master at 769191a; master is now feee272. On the current head the two checks this PR is about - Run Python tests and Build & Test (Linux x86_64) - are green.

Two others are red, and neither is caused by this PR: Cross-compile ARM64 kernel and Full-stack integration summary. Both are the eBoot master build failure reached through .github/workflows/eos-simulation.yml. eBoot master does not compile - no member named 'reserved' in 'eos_image_header_t', plus a duplicate point_is_identity() and a test_ed25519.c missing the data its tests iterate. Repair opened as eBoot#97; Full-stack integration summary fails downstream of it via needs:.

[srpatcha]

Review — eos#127 "fix(build): restore the low-order Ed25519 suite that #93 removed"

head: 2a26424 author: Kartikey1306 ci: pass

Verdict: Clean. Five lines, restored verbatim to their original position, and the load-
bearing claim is checkable and checks out: git show 3aa8644^:tests/CMakeLists.txt | grep -c 'add_executable(test_crypto_ed25519_loworder ' returns 1, so it was not a duplicate.
Of the four open PRs adding this registration, this is the one to take.

Two things beyond the diff, one of which nobody has raised: 3aa8644 is worse than this PR
says, and there is a second loss from the same commit still sitting in CHANGELOG.md.

Findings

#	Severity	File:line	Finding	Recommended fix
1	High	CHANGELOG.md:6 (not this diff — 3aa8644)	#93's diagnosis was false in both directions, and it is still doing damage in a second file. This PR shows the block it deleted was not a duplicate. The duplicates it claimed to be removing did not exist either: at 3aa8644^, grep -c 'add_executable(test_crypto_aes ' is 1 and grep -c 'add_executable(test_crypto_sha512 ' is 1. git show --numstat 3aa8644 is two files — CHANGELOG.md 1/1 and tests/CMakeLists.txt 0/5 — and the only thing removed from the build file was the Ed25519 block. So the add_executable cannot create target "test_crypto_aes" error quoted in that commit message cannot have come from this file at that commit. The CHANGELOG hunk is the part still unfixed: 3aa8644 overwrote the Unreleased / Fixed entry for eos_queue_send / eos_queue_receive — "A full send/recv waiter table now returns EOS_KERN_NO_MEMORY instead of blocking a task that can never be woken" — replacing it with a "Build:" entry describing the configure failure that did not happen. A real fix lost its changelog line, and a fictitious one gained one. (The test for that queue fix is test_queue_send_waiter_overflow, which #123 is separately trying to switch back on — same defect, three places.)	Second commit on this branch, or its own PR: restore the eos_queue_send / eos_queue_receive line at CHANGELOG.md:6 and delete the "Build:" entry above it. Then re-read the rest of 3aa8644's CHANGELOG context — a commit this wrong about its own subject should not be assumed right anywhere else.
2	Low	tests/CMakeLists.txt:93-97	Four open PRs add this registration, at two positions: this one restores it after test_crypto_rsa; #125, #118 and #126 insert it after test_hal_stm32f4; the comments on #126 name a #128 as well. At most one merges cleanly.	Take this one and drop the hunk from the other three. It is the original position, it keeps the test_crypto_* suites grouped, and it is the position #122 is already written against — #122's tests/CMakeLists.txt hunk carries add_executable(test_crypto_ed25519_loworder …) as its @@ -95 context line.

The diff itself has nothing wrong with it. It restores four lines and a comment verbatim,
touches no other file, links eos_crypto where ed25519_verify lives, and the validation
table in the body distinguishes before and after per check rather than asserting a bare
"tested". The note that Simulation Test and EoSim Sanity are also red on master and are
not addressed here is the right kind of scope statement — it says what was left out
instead of implying coverage. All 26 required checks pass in checks.txt for this head.

Architecture conformance

§21 — conforms. Test build configuration only, inside tests/, which is where
.ai/architect.md's target shape puts the suites. No dependency direction, tier or public
header touched.

§14.1 and .ai/security.md — this is squarely the point of both. "Reject invalid and
low-order public keys explicitly; do not assume the library did." The suite being restored
is the one proving ed25519_verify refuses a key outside the prime-order subgroup, the
all-zero encoding included — and eos_pkg.c shipped static const uint8_t eos_pkg_public_key[32] = {0}, which is one of those eight points. .ai/security.md:
"ctest exits 0 when it finds no tests at all. A security suite that silently collected
nothing is a failed check reported as green." A registered-then-deleted suite is the same
failure with an extra step, and it went unnoticed for the whole window because the .c
file never left the tree.

§28 Status, evidence and claims — worth stating plainly. Between 3aa8644 merging and
this landing, "Ed25519 rejects low-order public keys" was an Implemented claim whose
"code and functional tests" evidence did not execute. The guard in
tests/unit/test_cmake_test_registration.py is what turned that back into a visible fact,
which is the mechanism §28 needs and this repository has been building.

No master-design proposal from this PR.

Proposed changes

1. Merge as is.
2. Follow-up commit restoring the eos_queue_send / eos_queue_receive entry at
   CHANGELOG.md:6 and removing the incorrect "Build:" entry (finding 1).
3. Close #125 and drop the same hunk from #118 and #126 (finding 2).

Not checked

• I did not build or run ctest. The 5/5, 39/39, 15 passed figures are the author's;
  checks.txt is green for this head and is the independent evidence.
• I verified the history claims directly in the local clone (git show 3aa8644,
  git show --numstat 3aa8644, git show 3aa8644^:tests/CMakeLists.txt). I did not
  read tests/test_crypto_ed25519_loworder.c, so I cannot say whether its five cases
  actually cover the eight low-order points its header describes — only that they now run.
• I did not audit the rest of 3aa8644's effect beyond the two files it changed, and I did
  not look for other commits from the same cleanup series.
• Simulation Test and EoSim Sanity, correctly declared out of scope here. EoSim was
  skipped by this run's sync step as a dirty working tree, so I could not look at them
  either.

---

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

[Kartikey1306]

Closed my duplicate of this (#128) in favour of this one — same restore, and
this is the minimal version.

One thing from it worth folding in if you want it: tests/CMakeLists.txt
already carries this exact comment on a neighbouring target —

# --- test_mpu_validate: MPU region programmability ---
# Landed with the fix it guards (#109) and lost its registration to a merge,
# so the six cases stopped being compiled while the file stayed in the tree.

so a matching note here would make the pattern visible in the file rather than
only in the PR history. Suggested wording:

# Registered by #101 alongside the fix it guards, then removed by #93, whose
# base predated it: the target looked like one more duplicate to delete. It is
# the regression test for the #98 forgery -- an all-zero key accepting a
# package -- so between #93 merging and this, nothing checked that fix.

Entirely optional; the restore is correct without it.

Evidence I gathered on the duplicate, in case it is useful here: the target was
the only non-duplicate in #93's diff, and it is load-bearing — disabling the
subgroup check in services/crypto/src/ed25519_verify.c makes
test_all_zero_key_is_rejected fail, so the suite genuinely guards the #98 fix
rather than merely existing.

[srpatcha]

Review — eos#127 "fix(build): restore the low-order Ed25519 suite that #93 removed"

head: 13a8ffa author: Kartikey1306 ci: fail (2 of 28 — both inherited from eBoot master, neither caused by this PR)

Verdict: Clean, still needed, and now verified by execution rather than read. This head is a rebase — the PR's own diff against its merge-base is byte-identical to the 2a26424c I reviewed earlier (git diff <merge-base> refs/pull/127/head → tests/CMakeLists.txt | 5 +++++, nothing else). The five lines are correct and the suite they switch back on is load-bearing. Merge it.

I built it and ran it, so the author's validation table is no longer just a claim:

git worktree add --detach <tmp> refs/pull/127/head
cmake -S . -B bt -DEOS_BUILD_TESTS=ON     # rc=0
cmake --build bt -j4                      # rc=0
ctest --test-dir bt --no-tests=error      # 39/39 passed
ctest --test-dir bt -R test_crypto_ed25519_loworder --no-tests=error
                                          # Test #15 ... Passed

The 38 → 39 suite count checks out exactly: tests/CMakeLists.txt registers 37 unconditional add_test on origin/master and 38 on this head, plus the one add_test guarded by if(NOT CMAKE_CROSSCOMPILING) at tests/CMakeLists.txt:221.

The PR is still required: origin/master (feee272) ships tests/test_crypto_ed25519_loworder.c with no add_executable for it.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Low	PR body, "Why it matters"	"nothing has been checking it since #93 merged" is overstated, and the overstatement is worth correcting because it understates what the restore actually buys. I mutated ed25519_key_has_prime_order() (services/crypto/src/ed25519_verify.c:93) to return 1 and rebuilt: two suites fail, not one — test_crypto_ed25519_loworder (#15, restored here) at tests/test_crypto_ed25519_loworder.c:112 test_all_zero_key_is_rejected, and test_pkg_trust_anchor (#33, already on master since #120) at tests/test_pkg_trust_anchor.c:172 test_low_order_keys_are_refused_as_anchors. So since #120 landed, the anchor-configuration path has been guarded. What went unguarded is ed25519_verify()'s own rejection and the forgeable-message sweep.	One sentence in the body: since #120, test_pkg_trust_anchor has covered ed25519_public_key_is_usable(); what this restores is the ed25519_verify() path and the message sweep — and the cross-compiled coverage, which is the part that has no substitute (see finding 2).
2	Low	tests/CMakeLists.txt:218-222 (master, not this diff)	The substitute coverage identified above is host-only. test_pkg_trust_anchor sits inside if(NOT CMAKE_CROSSCOMPILING) because eos_eapp is a host-build library, so on Cross-compile ARM Cortex-M4 and Cross-compile ARM64 kernel nothing has checked low-order key rejection since 3aa8644. The suite this PR restores links only eos_crypto and is unconditional, so it closes that gap too. Not a defect in this PR — an argument for it, and a note for whoever reads the two suites as interchangeable.	No change here. Worth an issue: eos_pkg's trust-anchor behaviour has no cross-target test at all, which .ai/security.md ("keep target-specific hardware security adapters behind stable interfaces") and §22's Reference-tier requirements both eventually need.
3	Low	PR body vs. checks.txt	The body's CI narrative describes master at 769191a; master is now feee272 and this head's CI is different. Two checks are red — Cross-compile ARM64 kernel and Full-stack integration summary — and neither is one the body discusses. Both are the inherited eBoot master build failure (eos_image_header_t has no member named 'reserved', eBoot#94) reached through .github/workflows/eos-simulation.yml; Full-stack integration summary fails downstream via needs:. Run Python tests and Build & Test (Linux x86_64) — the two the body is about — are green on this head.	Refresh the body's first paragraph and the "Also red on master" section against feee272, or delete them; they now point a reviewer at resolved failures and away from the live ones.

Resolved since my review of 2a26424c

Recorded so nobody re-opens them:

• Prior finding 1 (High) — fixed. 3aa8644 had overwritten the Unreleased / Fixed entry for eos_queue_send / eos_queue_receive. It is back on origin/master:CHANGELOG.md:10, verbatim, and the fictitious "Build:" entry describing a configure failure that never happened is gone. Restored by #120 (769191a), not by this PR.
• Prior finding 2 (Low) — half fixed. #128 is closed by its author in favour of this PR. #125, #118, #126 and #122 still carry or are written against this hunk; this PR restores it at its original position after test_crypto_rsa, which remains the position to take.
• Still open from that review and not caused by anything here: test_queue_send_waiter_overflow (tests/test_kernel.c:159) is a function inside test_kernel.c and is not reached by tests/unit/test_cmake_test_registration.py, which only checks that each .c file has an add_executable. A test function that is compiled but never called is invisible to that guard.

Architecture conformance

§21 — conforms. Test build configuration inside tests/, which is where .ai/architect.md's target shape puts suites. No tier crossed, no dependency direction changed, no public header touched. target_link_libraries(... PRIVATE eos_crypto) links downward to the library that owns ed25519_verify.

§14.1 / .ai/security.md — this is the exact failure mode that file names first. "ctest exits 0 when it finds no tests at all. A security suite that silently collected nothing is a failed check reported as green." A suite whose .c file stays in the tree while its add_executable is deleted is that failure with one extra step of camouflage, and the mutation run above is the evidence that it was guarding something real rather than merely existing. "Reject invalid and low-order public keys explicitly; do not assume the library did" is the requirement; test #15 is its proof.

§28 — restores an Implemented claim to having evidence. Between 3aa8644 and this PR, "Ed25519 rejects low-order public keys" was asserted at §28's Implemented level, whose required evidence is "code and functional tests", while one of its two functional tests did not execute on any target and neither executed on cross targets (finding 2).

No master-design proposal from this PR.

Proposed changes

1. Merge as is. The diff is right and now independently executed; findings 1 and 3 are body text, finding 2 is a follow-up issue.
2. Correct the two body claims (findings 1, 3) — no code change, no re-run needed.
3. Drop the same hunk from #125/#118/#126 and rebase #122, so the four-way conflict at this anchor resolves onto this PR.
4. Open an issue for cross-target eos_pkg trust-anchor coverage (finding 2).
5. Separately: test_cmake_test_registration.py catches an unbuilt file but not an uncalled function — test_queue_send_waiter_overflow is the live example. Worth extending, out of scope here.

I opened no fix PR: nothing here is rated High, and the two body corrections are the author's text to change.

Not checked

• Host build only, x86_64 Linux, GCC as configured by default. I did not cross-compile, so finding 2's claim that the restored suite will build under CMAKE_CROSSCOMPILING is read from tests/CMakeLists.txt (unconditional, links only eos_crypto) — not observed.
• The 38 → 39 figure was confirmed by counting add_test in both trees and by ctest reporting 39 on this head. I did not build origin/master, so "38 on master" is arithmetic plus a grep, not a run.
• The mutation test proves the two suites detect the removal of ed25519_key_has_prime_order's body. It says nothing about whether test_crypto_ed25519_loworder.c's cases cover all eight low-order encodings, or whether the identity-rejection branch (ed25519_point_is_identity, ed25519_verify.c:81) is covered independently — I mutated the whole function, not each branch.
• I did not audit 3aa8644 beyond the two files it touched, and did not look for other commits in that cleanup series.
• The two red checks are attributed to eBoot#94 on the strength of the eos#126 investigation in this same report series; I did not re-run the eBoot build for this head. EoSim was skipped by this run's sync as a dirty tree, so its own red status is unexamined.
• tests/test_crypto_ed25519_loworder.c itself was read only at line 112, where the mutant failed.

---

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

[Kartikey1306]

Both findings are right and both are now corrected in the body. Verified them rather than taking them on trust:

Finding 1 — overstated claim. Confirmed. tests/test_pkg_trust_anchor.c:165 test_low_order_keys_are_refused_as_anchors is on master and does cover ed25519_public_key_is_usable(), so "nothing has been checking it since #93" was wrong. Body now says what actually went unguarded: ed25519_verify()'s own rejection and the message sweep.

Finding 2 — cross-target gap. Confirmed and it is the stronger half of the argument. test_pkg_trust_anchor sits inside if(NOT CMAKE_CROSSCOMPILING) at tests/CMakeLists.txt:218 because eos_eapp is host-only, so on the two cross-compile legs nothing has checked low-order rejection since 3aa8644. The restored suite links only eos_crypto and is unconditional. I have folded that into the body as the part with no substitute, and will open the issue for cross-target eos_pkg trust-anchor coverage.

Finding 3 — stale CI narrative. Corrected, and I can now name the cause you left as attributed-not-verified. The two red checks are the eBoot master build failure, and eBoot master genuinely does not compile — I reproduced it:

include/eos_image.h:135: error: no member named 'reserved' in 'eos_image_header_t'
include/eos_image.h:142: error: no member named 'reserved' in 'eos_image_header_t'
core/ed25519_verify.c:338: error: redefinition of 'point_is_identity'
tests/unit/test_ed25519.c:263: error: redefinition of 'test_ed25519_identity_key_forgery_rejected'
tests/unit/test_ed25519.c:299: error: use of undeclared identifier 'k_low_order'

Three conflict-free merges — #87 pinned reserved[] while #57 split it into tlv_len/tlv_hash; #86 and #57 each added an identical point_is_identity(); and the test merge kept tests while dropping messages[] and k_low_order[8][32]. My PRs are half of that. Repair is eBoot#97: ctest 21/21, low-order probe 0 accepted / 2048, RFC 8032 vectors still accepted.

---

On your closing note about test_cmake_test_registration.py catching an unbuilt file but not an uncalled function — that class is live in eBoot too, and worse than the eos instance. test_ed25519.c had test_ed25519_low_order_R_with_a_valid_key_is_not_a_forgery() compiled but never called (the merge kept the function, dropped its run_ call), and tests_run hardcoded to 11 while 12 tests ran, so the suite failed on its own arithmetic. Both fixed in #97, with tests_run now incremented by the macro that runs each test so it cannot drift again.

That suggests the guard's natural extension is per-TEST()-symbol rather than per-file: for these suites, every TEST(x) should have a matching run_x() in main(). Cheap to check with the same parser, and it would have caught both the eBoot case and test_queue_send_waiter_overflow. Happy to write it if you want it as a follow-up.

One correction to your "Not checked" note, offered because it changes what the mutation test proves: you mutated ed25519_key_has_prime_order(). On eBoot that function is now dead code — the verifier calls public_key_is_valid_subgroup() — though on eos the name is still the live one, so your run stands for eos. Flagging only in case the same mutation is reused across repos.

[Kartikey1306]

Built the guard you suggested at the end of your review: #134.

It closes the half this file could not reach — test_cmake_test_registration.py answers "is this file compiled?", not "is this test called?", and an uncalled test function is valid C that compiles, links, runs its suite and passes having skipped itself.

Run against master it finds exactly one instance, with no false positives, and it is the one you named:

['test_kernel.c::test_queue_send_waiter_overflow']

Calling it, it passes — so the eos_queue_send/eos_queue_receive waiter-table fix was right and simply had nothing executing against it. Good outcome, but it was luck rather than evidence, which is the argument for the guard.

Two details you may want to poke at, since a guard with false positives is worse than none:

• Occurrences are counted by bare identifier, not name(, so a function passed by address is not reported dead. test_entry in that same file is exactly that case and is correctly ignored.
• Comments are stripped first, so a name appearing only in prose does not read as a call.

Also fixed in the same commit: test_kernel.c printed a hardcoded (12/12) while thirteen tests sat in the file, so the literal agreed with the omission rather than exposing it. Counted now via a RUN() macro — the same shape eBoot#94 applied to its tests_run for the identical reason.

eBoot has no equivalent of this guard at all, and it is the repo where the class already caused a merge to drop a test. I'd port it once you're happy with the shape here.

[srpatcha]

Review — eos#127 "fix(build): restore the low-order Ed25519 suite that #93 removed"

head: 83800db author: Kartikey1306 ci: pass (26 checks, 0 failures)

Verdict: The restore is correct and I verified it byte-for-byte: the four lines in tests/CMakeLists.txt are identical to 3aa8644^ and sit in the original position before test_crypto_sha512, tests/test_crypto_ed25519_loworder.c is present on origin/master with no add_executable building it, and the CI narrative in the body is accurate down to the compiler error. But this head is not the one-hunk change the title and body describe. It carries a second commit that is the whole subject of eos#135, and the body says "No other file changes."

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	.github/workflows/eos-simulation.yml:12-20, 41, 48, 288; PR body, "The fix"	The body states "Restored verbatim from 3aa8644^, in its original position. No other file changes." The head has two commits: 13a8ffa (the restore) and 83800db "ci: pin the eBoot and ebuild checkouts instead of floating on master", which adds EBOOT_COMMIT/EBUILD_COMMIT and replaces three ref: master checkouts. That second commit is the entire subject of eos#135 — I diffed the branches: git diff pr-127 pr-135 is .github/workflows/upstream-drift.yml (146 lines) and nothing else, so #127 is a strict subset of #135. The identical pin also sits in eos#129 (d3b5852). Three open PRs carry the same CI change; the first to merge makes the others' hunk empty or conflicting, and a reviewer of #127 who trusts the body will not review the CI change at all.	Drop 83800db so this PR is the four-line restore its title claims, and let #135 carry the pin plus the drift job — or close #127 and keep #135, which contains it. Either way the body's "No other file changes" has to go. Separately: the same restore hunk is in #119, #122, #129 and #135 (and #126 adds a stray blank line at the same anchor), so whichever of those lands second conflicts on this anchor too.
2	Low	.github/workflows/eos-simulation.yml:16-19	The pin's own comment names the wrong repair: "eBoot #94 repairs it … when eBoot #94 lands, bump EBOOT_COMMIT to that merge." The PR body and your own 17:20 comment both name eBoot#97 ("Repair opened as eBoot#97", "Repair is eBoot#97"). One of the two is wrong, and the wrong one is the one that lives in the file and will be followed a month from now by someone who never reads this thread.	Name the actual repair PR in the comment, and give the pin an owner — the recorded design rule for this asks for the lift condition and a named owner in the same file (.ai/autoreview/proposals/2026-09.md, 2026-09-04 addendum).
3	Low	.github/workflows/eos-simulation.yml:19	The pin is a bare commit SHA, and .github/STANDARDS.md ("Release model") names a vX.Y.Z tag as the recommended pin for a consumer, with the release branch and master as the other two options — a raw SHA is outside the documented set, so a future maintainer will read this as sloppiness and "fix" it to a tag. It is not sloppiness, and I checked why: eBoot's newest tag v3.0.1 (35ed483, 2026-05-16) has a coherent include/eos_image.h and would build, but it does not contain a172a6d (eBoot#86) — the fix that rejects public keys outside the prime-order subgroup. Pinning eos's CI to the released tag would pin it to an eBoot that still accepts a low-order-key forgery. The SHA is the right call; the file does not say so.	One sentence in the comment: v3.0.1 was evaluated and rejected because it predates eBoot#86's subgroup fix, so no released ref is usable until eBoot tags one that contains it.

Architecture conformance

Conforms. §21 tier placement: both files are Tier-1 eos infrastructure. §5.1 dependency direction, applied to CI as the recorded proposal reads it: eos (Tier 1) consuming eBoot (Tier 1) and ebuild (Tier 1) is sibling-tier, not upward, so the direction is legal and only the ref was ever the problem. §28 evidence policy is what the restore serves — a suite present in the tree but built by nothing is an Implemented/Validated claim with no evidence behind it, and tests/unit/test_cmake_test_registration.py catching it is the guard working as intended.

The design gaps behind both halves of this branch are already recorded and no new proposal is filed: build-/CI-time cross-repo dependency direction and the released-ref rule in .ai/autoreview/proposals/2026-09.md (2026-09-03, "§5.1 governs runtime dependencies and says nothing about build- or CI-time ones", triggered in part by #119/#122), and the SHA-as-stated-exception plus mandatory drift job in the 2026-09-04 addendum triggered by #135 — which is exactly what upstream-drift.yml in #135 implements. §28's other gap, that a registration guard answers "is this file compiled?" and not "is this test called?", is what you built in #134; that is the right place for it.

Proposed changes

1. git rebase -i this branch down to 13a8ffa alone, force-push. #127 then reads as its title, and #135 keeps the CI work.
2. Fix the eBoot PR number in the workflow comment (in #135, once #127 no longer carries the file).
3. Add the v3.0.1-was-rejected sentence next to the pin.

Verified in this review

• The restore hunk is byte-identical to 3aa8644^:tests/CMakeLists.txt and in the same position. Not just "looks right" — the two extracts compare equal.
• 3aa8644^ had exactly one add_executable(test_crypto_ed25519_loworder, so #93's "remove duplicate test targets" removed a non-duplicate. Your grep -c claim reproduces.
• eBoot master genuinely does not compile, which was previously an attribution rather than a verified fact. At 22d8f8b the struct carries tlv_len (:53) and tlv_hash (:54) where reserved[30] used to be, and EOS_IMG_STATIC_ASSERT(offsetof(eos_image_header_t, reserved) == 62) (:135) and sizeof(((eos_image_header_t *)0)->reserved) == 30 (:142) survived the merge — the exact two errors in the eos ARM64 job log. Your account of the three conflict-free merges matches the source.
• The pinned a172a6d is coherent: reserved[30] present at include/eos_image.h:37, no assert referencing a member it lacks.
• The pin demonstrably works, and this is the cleanest evidence in the batch. Within six minutes on 2026-09-04, Cross-compile ARM64 kernel completed success on #127 (06:37:18), #129 (06:37:45) and #135 (06:41:27) — the three heads carrying the pin — and failure on #119 (06:35:46) and #122, the two that still float on master. Same merge base for four of the five. That is an A/B, not a coincidence of timing.

Not checked

• Nothing was built or run locally. ctest 39/39, pytest 15 passed and test_crypto_ed25519_loworder 5/5 are the author's figures; CI is green on this head across all 26 checks, which supports them but is not the same as reproducing them.
• I did not compile eBoot at a172a6d — the coherence check above is source inspection of the specific asserts that fail on master, so I can say the known breakage is absent, not that the tree builds clean.
• The EBUILD_COMMIT pin (e5d8052f…) was not examined at all; the ebuild clone under the working root is dirty, so the sync step left it untouched and that commit is not in the local object store.
• Your mutation evidence that the restored suite is load-bearing (disabling the subgroup check makes test_all_zero_key_is_rejected fail) is not reproduced.
• The cross-target coverage argument — test_pkg_trust_anchor sitting inside if(NOT CMAKE_CROSSCOMPILING) at tests/CMakeLists.txt:218 — I read the guard and it is there; I did not confirm by build that the restored target is reached on the two cross legs.

---

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