docs(alignment): replace the ✅ Aligned table with measured inventories

[Kartikey1306]

Stacked on #144 (master's Python guards are red without it, so this branch would inherit four failures that are not its own). Review 9569226..6437af8: two commits, one file.

Problem (eos #149)

docs/three-way-alignment.md said "✅ ALL ALIGNED" and, for board definitions, "25 YAML files in eos/boards/ | 25 board ports in eboot/boards/". None of those numbers was true, and nothing cross-checks the three inventories the row describes. ebuild#109 corrected this row — inside ebuild's vendored copy core/eos/docs/three-way-alignment.md, pinned to eos 5544c98, so ebuild's vendor-drift guard failed and ebuild#132 reverts it to the pin. The correction belongs here, upstream, where the pinned copy is taken from.

What changed

Every count in the status table was re-measured on 2026-09-14 against origin/master of eos (9ed6831), eBoot (221325c) and ebuild (76970c9), and the table now shows measured numbers with ⚠️ where inventories disagree or nothing compares them, and ✅ only where a comparison was actually made. Headlines:

Row	Document said	Measured
Board definitions	25 / 25 / —	eos 84 boards/*.yaml; eBoot 83 boards/*/ = 83 eboot_add_board() calls; ebuild TARGET_ARCH 14, EBOOT_BOARD 14, MCU_TO_EBOOT_BOARD 136 keys (56 distinct eboot dirs; 27 eboot dirs never targeted); EOS_BOARD_MAP 116 keys (81 distinct eos YAMLs; 3 never mapped)
Product profiles	41 / 41	48 headers, 42 config branches, 41 PRODUCT_MAP keys — seven headers with no map entry
Config generation	39 flags, one generator	34 EOS_ENABLE_* defines; across ebuild/**/*.py 29 named, 24 in common, 5 named only by ebuild and defined nowhere in eos, 10 defined in eos and never named by ebuild; two generator classes, two files
Templates	5 in ebuild/templates/	6 in templates/ at the ebuild root; eos names four of them by their ebuild new --template spelling, all of which exist; eBoot names none
Peripheral keywords	33 / 24 / 200+	33 and 24 reproduce; the ComponentDB docstring's 200+ is 114

A ## How this was measured section lists every command and the full comparison script, and every line the script prints appears verbatim in the document — re-running it reproduces the table. The document no longer claims a cross-check tool exists, because none does.

Verification

Verified: the embedded script was executed from a directory of sibling checkouts and its output diffed against the recorded output (no differences). pytest tests/unit 43 passed on this branch.

Left as is, annotated: later sections still carry the original 25-board / 41-profile figures in prose. Four sections now open with a one-line note that the status table supersedes them — Board-Level Alignment (:142), Product Profile Alignment (:176), Build System Alignment (:302; its note gives today's measured figure, 86 EBLDR_BOARD STREQUAL branches naming 83 distinct boards, the sentinel "none" appearing three times) and eboot CMakeLists.txt Board Coverage (25/25) (:344). The Documentation Alignment section carries no note; instead the two rows that graded this file and hardware-alignment.md as fully aligned are re-graded ⚠️ with the measurement date (:390–391). docs/hardware-alignment.md:51 carries the same note with the 84 / 83 / 7 numbers, so a reader who follows that link no longer lands on the old claim unwarned. (An earlier version of this paragraph claimed notes were already in place on three sections; they were on two different ones. Corrected at the commits that add them — 905c9e8, 237a37f — and 9481429 for the branch count, which an intermediate version gave as 84.)

Closing issue

Fixes #149

[srpatcha]

Review — eos#151 "docs(alignment): replace the ✅ Aligned table with measured inventories"

head: 6437af8 author: Kartikey1306 ci: pass (29 green, 0 red; Create GitHub Release and assign skipped)

Verdict: The central claim — that the embedded script reproduces the table — is true, and
I proved it: all three repositories' origin/master still sit on the SHAs the document pins,
I re-ran the recorded script from a directory of sibling checkouts, and the output diffs
zero lines against the block committed in the file. Every bash one-liner reproduces its
annotated number too. This is the right way to write an audit document and it closes eos#149
for the file it touches. Two findings: a second document in this same repo still makes the
claim this PR disproves, and the PR body mis-describes which sections were annotated.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	docs/hardware-alignment.md:51 (not in this diff)	eos#149's defect survives in a second file, in a stronger form. That line reads: "Result: 25/25 boards aligned. Every eboot board has a matching eos board definition, and every eos board has a matching eboot port." This PR's own measurements disprove the universal quantifier on both halves — 84 eos YAMLs against 83 eBoot directories, only 7 eos YAML stems sharing a name with an eBoot directory, 27 eBoot directories never targeted by MCU_TO_EBOOT_BOARD, and hiletgo-esp-wroom-32.yaml, qemu-arm64.yaml and tms570.yaml never mapped at all. I reproduced every one of those figures. eos#149 is titled for a document asserting ✅ Aligned for inventories that disagree; this PR fixes one such document and leaves another, unannotated, in the same docs/ directory — and three-way-alignment.md:386 still points a reader at it with ✅ 25 board YAMLs | ✅ 25 board ports. A reader who follows that link gets the old false claim with no warning. Rated Medium as an incomplete fix rather than Low-as-documentation, because the thing left incomplete is the exact defect the PR exists to close; a reviewer who wants to call it Low has a fair argument.	Smallest honest change, in this PR: one note under hardware-alignment.md:51 in the same shape as the two this PR already added — "Superseded: measured 2026-09-14, the full inventories are 84 / 83 and only 7 names match; see docs/three-way-alignment.md." Rewriting that document's tables is a separate job and should not grow this PR.
2	Low	PR body, "Left as is"; docs/three-way-alignment.md:342,374-390	The PR body names three sections as carrying a supersede note, and none of them does. It says "eboot CMakeLists.txt Board Coverage (25/25), the Build System table, the Documentation Alignment rows — each is now preceded by a one-line note that the top table supersedes it." The file has exactly two > notes, at :144 (Board-Level Alignment) and :178 (Product Profile Alignment) — different sections, both good, neither named in the body. ### eboot CMakeLists.txt Board Coverage (25/25) at :342 and the Documentation Alignment table at :374 have no caveat. The second one matters on its own: :387 still grades this very document ✅ profiles, boards | ✅ boards, platform enum | ✅ all maps audited, which contradicts the banner seven lines from the top of the same file — ⚠️ NOT ALIGNED — the inventories disagree and nothing cross-checks them. Per brief item 5, the unsupported claim in the body is itself the finding; the self-contradiction is the reason it is worth fixing rather than just noting.	Add the two missing notes, or correct the body to name the two sections that actually have them. Change :387's row for three-way-alignment.md from ✅ all maps audited to ⚠️ measured 2026-09-14; see the status table, and :386's row for hardware-alignment.md to ⚠️ alongside finding 1.

Two findings on a 140-line documentation change, and neither is in the measurement work — the
measurements are the part I tried hardest to break and could not.

Verification performed for this review

Run from /home/srpatcha/eos, which already holds sibling eos/, eBoot/ and ebuild/
checkouts. The script reads origin/master through git show, never the working tree, so
ebuild's dirty tree is irrelevant to the result and was not touched.

Check	Result
Do the three pinned SHAs still match origin/master?	YES — eos 9ed6831, eBoot 221325c, ebuild 76970c9, exactly as the document records. This is what makes the reproduction a fair test rather than a coincidence.
Re-ran the document's embedded Python script verbatim and diffed its stdout against the recorded output block	ZERO DIFFERENCES. All 18 recorded lines reproduce byte for byte, including the sorted lists — ['hiletgo-esp-wroom-32.yaml', 'qemu-arm64.yaml', 'tms570.yaml'], the seven headers without a PRODUCT_MAP entry, the five ebuild-only and ten eos-only EOS_ENABLE_* flags, and ['ethernet', 'gps', 'watchdog']. The claim "every line the script prints appears verbatim in the document" is Verified.
Ran each of the 22 bash one-liners against its annotated value	All reproduce. 89, 84, the other 5 (lm3s6965evb.ld, startup_stm32f407.S, stm32f407_discovery, stm32f407vg.ld, validation — five, as stated), 83/83/83, 48, 24, 34, 6, 0 for ebuild/templates/, 114, 23, 6, all four CLI defs, 38, 12, 0 tracked eboot_flash_layout.h, and the three docs that mention it.
Does the ast-based counting actually matter, or is it ceremony?	It matters. The script's own note is right: grep -c '":' over sdk_generator.py counts every quoted key in the file, not one dict's entries. Parsing with ast.literal_eval is the difference between a number and a guess, and it is why these figures are trustworthy where the previous "25 / 25" was not.
pytest tests/unit -q on this head	PASS — 43 passed

Was anything weakened? No. The diff is one markdown file, +140/−16. No test, lint rule,
assertion or permission is involved. The other ten files in files.txt are #144's, inherited
through the stack; git diff 95692266..6437af81 is docs/three-way-alignment.md and nothing
else, which matches the body's "two commits, one file".

What this PR gets right

Worth stating, because the findings above are both about what was left over. A document that
carries the commands that produced it, pins the three SHAs it measured, and can be re-run to a
zero-line diff is a different artifact from one that asserts ✅ ALL ALIGNED. That is §28's
evidence model applied to documentation: the ⚠️ markers say "measured, and they disagree", the
one ✅ is explicitly downgraded in its own cell to "a presence check on ebuild alone, not an
inventory comparison", and the document states plainly that no cross-check tool exists rather
than implying one does. Under §28's status table the old text claimed Validated with no
evidence; the new text claims exactly what it measured. The next person to touch this file can
falsify it in one command, which is the property that stops it drifting again.

Architecture conformance

Conforms, and it is the correct repository for the change. §21 places eos in Tier 1 —
Foundation, and this is eos's own document; ebuild#109's mistake was correcting the
vendored copy at ebuild/core/eos/docs/three-way-alignment.md, which is pinned to eos
5544c98 and therefore tripped ebuild's vendor-drift guard — correctly, since a vendored copy
that diverges from its pin is exactly what that guard exists to catch. Fixing it upstream, here,
and letting ebuild#132 revert its copy to the pin is the right sequence and restores the
direction the vendoring relationship depends on. §5.1 is not engaged: no include, link line,
CMake entry or manifest dependency changes, and a markdown file creates no edge. §22's hardware
support tiers are the clause the content speaks to — "Do not market all board descriptors as
equivalent hardware support" — and this change is that instruction carried out: 84 board YAMLs
are now described as 84 differently-keyed descriptors that nothing validates, not as 84
supported boards.

No architecture proposal appended. I considered one, because §22 defines five hardware
support tiers and nothing in this repository records which tier any of the 84 boards is in — but
that is a gap in the repository against the design, not a gap in the design, so it belongs in an
issue rather than in proposals/. §22 already says what should happen; nobody has done it.
That is the more useful thing this measurement exposes and it is recorded here rather than
inflated into a proposal.

Proposed changes

In this PR (both small):
  docs/hardware-alignment.md:51   add the supersede note (finding 1)
  docs/three-way-alignment.md:342 add the note the body says is there
  docs/three-way-alignment.md:386-387
                                  hardware-alignment row -> ⚠️
                                  three-way-alignment row -> ⚠️, not "all maps audited"

Merge order: #144 first (this is stacked on it).

Separate, not this PR:
  an issue for §22 — no board in eos/boards/ is assigned a hardware support tier

Not checked

• The 25-board subset tables at :142 and :176 were not re-verified row by row. The note
  at :144 asserts "all 25 YAMLs and all 25 eboot directories still exist" and explains the
  9 shorthand rows; I did not check each of the 25 rows or the 9 exceptions individually. The
  aggregate counts they sit under did reproduce.
• docs/hardware-alignment.md was read only around line 51. I did not audit its remaining
  ~290 lines, so finding 1 names one false claim in that file, not necessarily the only one.
• The prose sections after ## Data Flow Alignment (:228 onward — Verification Checklist,
  Build System Alignment, Cross-Linking Verification, Coding Convention Alignment) were skimmed
  for stale counts, not audited. :342 and :386 are what that skim found; there may be more.
• Nothing outside docs/ was checked for stale figures. A quick grep found 41 product profiles asserted in CHANGELOG.md:68,88, CONTRIBUTING.md:168 and docs/book/README.md:19
  while this PR measures 48 headers / 42 branches / 41 map keys. I did not investigate
  whether those four are wrong in context — "41 product profiles" may be a defensible statement
  about PRODUCT_MAP coverage — so this is a pointer, not a finding.
• CI checks were not reproduced. 29 green on this head; logs not read. The assign job
  shows skipping, which I did not investigate.
• I did not confirm that ebuild#132's revert and this PR leave the vendored copy consistent.
  That needs ebuild's pin to be advanced to whatever commit this lands as, and that has not
  happened yet — worth saying plainly: until someone re-pins core/UPSTREAM.yaml, ebuild's
  vendored three-way-alignment.md will still be the old ✅ ALL ALIGNED text. Closing
  eos#149 here does not by itself fix the copy ebuild ships.

---

Automated architecture review of 6437af817fd7 — 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 addressed at 905c9e8.

Finding 1 — docs/hardware-alignment.md:51 now carries a supersede note in the same shape as the two in three-way-alignment.md: the full inventories are 84 / 83, only 7 name stems match, 27 eBoot directories are never targeted, so both halves of the "every … has a matching …" sentence are false for the full inventories. The table rewrite stays a separate job, as you suggested.

Finding 2 — the body was wrong, not the file; corrected both ways. :342 (eboot CMakeLists.txt Board Coverage) now has the note the body claimed. :386 hardware-alignment row → ⚠️ 25 of 84 board YAMLs | ⚠️ 25 of 83 board ports. :387 three-way-alignment row → ⚠️ measured 2026-09-14; see the status table in all three columns, so the row no longer contradicts the banner at the top of its own file. The body's "Left as is" paragraph now names exactly the three sections that carry a note (:142, :176, :342) and says the Build System table carries none.

Verified at 905c9e8, this shell: the embedded script re-run produces output byte-identical to the recorded block (18 lines; line 11 eos yaml 84 | eboot dirs 83 | yaml stems that are eboot dirs 7, line 12 … eboot dirs never targeted 27 — every figure written into the new notes comes from there); pytest tests/unit -q → 43 passed.

Not done here, as agreed: the §22 hardware-tier issue is separate. Merge order unchanged: #144 first; review 6437af8..905c9e8 for this round.

[Kartikey1306]

Both findings are done, and the body is corrected — it had claimed notes on three sections that were on two others, which is the claim/artefact gap you flagged.

(Correction to the first version of this comment: it cited a commit that never reached the branch. Findings 1 and 2 were closed at 905c9e8, pushed by a parallel session on this account minutes before mine; my 237a37f adds only the third section.)

• Finding 1: docs/hardware-alignment.md:51 carries the supersede note with the numbers (84 / 83 / 7) directly above the "25/25" sentence (905c9e8).
• Finding 2: note on eboot CMakeLists.txt Board Coverage (25/25) — with the figure that 27 of the 83 eBoot directories are never targeted by MCU_TO_EBOOT_BOARD — and the two Documentation Alignment rows now read ⚠️ (905c9e8). The Build System table, the third section the body named, gets its note at 237a37f with a figure measured today, not copied: eboot's CMakeLists.txt has 84 EBLDR_BOARD STREQUAL "<board>" branches against the table's 25 (a first draft said 85; that included a "none" guard).

Not done: the §22 tier issue you suggest is a separate issue, as you say — not opened here.

[Kartikey1306]

Correction to my reply above, visible rather than silent: the head is now 9481429, not 905c9e8, and the range to review for this round is 6437af8..9481429 (three commits).

• 237a37f (concurrent, same author account) added the Build System note I had said was absent — so "the Build System table carries no note" in my reply and in the body was true for two minutes and is not now. All four sections that keep a superseded count now open with a note; the Documentation Alignment section still has none and instead has its two rows re-graded ⚠️ (:390–391 after the shift).
• 9481429 corrects the figure that note introduced. It said 84 EBLDR_BOARD STREQUAL "<board>" branches; measured at eBoot 221325c (the SHA the document pins), grep -c 'EBLDR_BOARD STREQUAL' CMakeLists.txt → 86, all if/elseif branches with a quoted literal; distinct literals → 84, but one is the sentinel "none" (three occurrences), so the board count is 83 — matching the 83 eBoot board directories in the status table. The note now gives both numbers with the command. The body's paragraph is rewritten to say exactly which sections carry a note and which rows were re-graded instead.

Verified at 9481429, this shell: pytest tests/unit -q → 43 passed; the embedded script's output is still byte-identical to the recorded block. CI on 9481429 is running; 237a37f was 7/7 green.

[srpatcha]

Review — eos#151 "docs(alignment): replace the ✅ Aligned table with measured inventories"

head: 9481429 author: Kartikey1306 ci: pass (29 green, 0 red; Create GitHub Release skipped)

Verdict: Follow-up review of 6437af81..9481429d (3 commits, +8/−2 across two files).
Both previous findings are resolved, and the new numeric claims are correct — I re-measured
every one of them against origin/master rather than reading the note. I also re-ran the
document's embedded script at this head and it still diffs zero lines against the recorded
output. Two new Lows, both small, both in the annotations rather than the measurements: a date
that says tomorrow, and one board name in hardware-alignment.md spelled with the wrong
separator — which is, with some irony, the exact naming mismatch this document exists to record.

Previous findings — status

#	Previous finding	Status	Evidence
1	Medium — eos#149's defect survives in docs/hardware-alignment.md:51, which asserts "Every eboot board has a matching eos board definition, and every eos board has a matching eboot port"	Resolved in 905c9e8	docs/hardware-alignment.md:52 now carries a supersede note in the same shape as the other two, and it does the thing that matters: it names both halves of the sentence as false for the full inventories rather than softening one. I re-measured its numbers against origin/master today: 84 eos/boards/*.yaml, 83 eBoot/boards/*/, and 7 YAML stems that are also eBoot directory names. All three reproduce. The note points at three-way-alignment.md, which is where the evidence is.
2	Low — the PR body named three sections as carrying a supersede note and none of them did; :387 graded this very document ✅ all maps audited, contradicting its own banner	Resolved in 905c9e8 + 237a37f + 9481429	The two missing notes now exist at three-way-alignment.md:304 (Build System Alignment) and :346 (eboot CMakeLists Board Coverage), and the Documentation Alignment rows at :390-391 are corrected: hardware-alignment.md → ⚠️ 25 of 84 board YAMLs | ⚠️ 25 of 83 board ports, and three-way-alignment.md → ⚠️ measured 2026-09-14; see the status table in all three columns. The self-contradiction with the banner is gone. 9481429 is the author catching their own arithmetic before anyone else did — the note first said 84 boards, and the correct decomposition is 86 branch lines / 84 distinct quoted literals / 3 of which are the "none" sentinel / 83 distinct board names. I ran all four counts against eBoot origin/master: 86, 84, 3, 83 — exact.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Low (P3)	docs/three-way-alignment.md:304	The new Build System note is dated 2026-09-15; everything else in the document, including the pins it depends on, is dated 2026-09-14. The file header at :9 says "Measured on 2026-09-14 against origin/master of eos, eBoot and ebuild (eos 9ed6831, eBoot 221325c, ebuild 76970c9)", and the three other supersede notes (:144, :178, :346) all say 2026-09-14. I reproduced this note's figures today, 2026-09-14, against the same eBoot 221325c — so the numbers are right and only the date is wrong. In an ordinary document this is a typo; in this one it is not, because the whole argument of the file is that every claim carries a date and a pin so the next reader can re-run it. A future date on one row invites exactly the question the format exists to prevent: was this measured against something newer than the pins at the top?	2026-09-15 → 2026-09-14.
2	Low (P3)	docs/hardware-alignment.md:126	The Architecture Alignment table names the eBoot board qemu-arm64; the directory is qemu_arm64. I checked every board name in that table's two repo columns against both repositories mechanically. The eos column is prose ("nRF52840", "RPi4", "i.MX8M"), so it does not resolve to filenames and is not expected to. The eBoot column is in directory form and every other cell resolves — rpi4, imx8m, am64x, stm32mp1, nrf52, stm32f4, stm32h7, samd51, riscv64_virt, sifive_u, esp32, x86, x86_64_efi, mips, powerpc, sparc, m68k, sh4, v850, frv, h8300, mn103, strongarm, xscale all exist. qemu-arm64 does not; eBoot/boards/qemu_arm64/ does. The port is present, so this is a spelling error rather than a missing port — and it is the hyphen-versus-underscore split that is the reason only 7 of 84 names match across the two repos, reproduced inside the table written to document it. The eos side spells it boards/qemu-arm64.yaml, which the measured status table already lists among the YAMLs EOS_BOARD_MAP never maps.	qemu-arm64 → qemu_arm64 in that cell. If you want the row to carry its own weight, qemu_arm64 (eos: qemu-arm64.yaml — names differ).

Checked and not a finding: hardware-alignment.md:144, "16/16 architectures aligned across
eos and eboot.", is not the same defect as :51 and does not need a note. :51 asserted a
universal quantifier over all boards, which the measurements falsify; :144 is scoped to the 16
rows of the table immediately above it and every one of those rows does have both columns filled.
Recording it because it looks like a survivor of the same audit and is not one.

Verification performed for this review

Detached worktree at .ai/autoreview/state/scratch/eos-151 on refs/pull/151/head. The eos
checkout was clean before and after and was not touched. All measurements read origin/master
through git show / git ls-tree, never a working tree, so ebuild's dirty tree is irrelevant
and was not touched either. Nothing was committed or pushed.

Check	Result
Do the three pinned SHAs still match origin/master?	YES — eos 9ed6831, eBoot 221325c, ebuild 76970c9, unchanged since the last review. The reproduction below is therefore still a fair test.
Re-ran the document's embedded Python script at this head and diffed stdout against the recorded 18-line output block	ZERO DIFFERENCES. The document's central property survives the three new commits.
grep -c 'EBLDR_BOARD STREQUAL' CMakeLists.txt on eBoot origin/master	86 ✅ matches the new note
Distinct quoted literals after EBLDR_BOARD STREQUAL	84 ✅
Occurrences of the "none" sentinel	3 ✅
Distinct board names excluding "none"	83 ✅ — 9481429's correction is right and the earlier 84 was wrong
eos/boards/*.yaml on origin/master	84 ✅ matches the hardware-alignment.md:52 note
eBoot/boards/*/ on origin/master	83 ✅
YAML stems that are also eBoot directory names	7 ✅
"EOS_PRODUCT is a free-form cache string whose accepted values are listed in its help text, not enumerated in CMake"	CONFIRMED — eos/CMakeLists.txt:20 is set(EOS_PRODUCT "" CACHE STRING "Target product profile (robot|vacuum|…|fitness)"), and :25-28 only upper-cases whatever it is given and defines EOS_PRODUCT_<X>. Nothing validates the value.
Every board name in hardware-alignment.md's Architecture Alignment table, both repo columns, resolved mechanically against both repositories	16 rows; one eBoot cell does not resolve — finding 2
pytest tests/unit -q on this head	PASS — 43 passed, 0.37s
Was anything weakened?	No. The diff is two markdown files, +8/−2. No test, lint rule, assertion or permission is involved. git diff 6437af81..9481429d is exactly those two files, matching the body.

Architecture conformance

Conforms; unchanged from the previous review and re-checked against the new commits. §21 places
eos in Tier 1 — Foundation, and this is eos's own documentation, which is the right repository:
ebuild#109's error was correcting the vendored copy at
ebuild/core/eos/docs/three-way-alignment.md, which is pinned and therefore tripped ebuild's
vendor-drift guard. Fixing it upstream here and letting ebuild#132 revert its copy to the pin is
the correct sequence. §5.1 is not engaged — a markdown file creates no dependency edge. §22 ("Do
not market all board descriptors as equivalent hardware support") is the clause the content
serves, and the three commits extend that further into hardware-alignment.md, which was the one
file still marketing 25 descriptors as a complete, aligned inventory. §28's evidence model is
what the whole document now satisfies: the old text claimed Validated with no evidence, the new
text states what it measured, when, and against which commits — and, as of this head, every
surviving 25/25 and ✅ Aligned block in both files is preceded by a note saying what supersedes
it.

No architecture proposal appended for this PR. As last time: §22 defines five hardware support
tiers and nothing in this repository records which tier any of the 84 boards is in. That is a gap
in the repository against the design, not a gap in the design, so it belongs in an issue. §22
already says what should happen; nobody has done it. Recording it again because it is still true
and it is the most useful thing this measurement work exposes.

Proposed changes

Both one-line, neither blocking:
  docs/three-way-alignment.md:304   2026-09-15 -> 2026-09-14          (finding 1)
  docs/hardware-alignment.md:126    qemu-arm64 -> qemu_arm64          (finding 2)

Merge order: #144 first (this is stacked on it).

Separate, not this PR:
  an issue for §22 — no board in eos/boards/ is assigned a hardware support tier
  ebuild's core/UPSTREAM.yaml still pins the pre-correction copy; see below

No fix PR opened. Both findings are in lines this branch introduces or that only make sense
alongside it, so a branch cut from origin/master — what fix-start.sh produces — would either
have nothing to patch or would conflict. Both are one-character-class edits for the author.

Not checked

• The 25-board subset tables at :142 and :176 were not re-verified row by row, nor were the
  9 shorthand exceptions the :144 note explains. The aggregate counts they sit under do reproduce.
• docs/hardware-alignment.md was audited only for board-name resolvability and for universal
  "aligned" claims. Its peripheral-coverage matrix, memory-map rows and per-board checklists
  (~150 lines) were not checked against either repository. Finding 2 is what a mechanical check
  of one table found; it is not a statement that the rest of the file is correct.
• The prose sections after ## Data Flow Alignment in three-way-alignment.md were skimmed for
  stale counts in the previous review, not audited, and I did not repeat even the skim here — the
  three new notes are where the previous skim's findings were, and they are now annotated.
• Nothing outside docs/ was checked for stale figures. The previous review's pointer stands
  unexamined: CHANGELOG.md:68,88, CONTRIBUTING.md:168 and docs/book/README.md:19 assert "41
  product profiles" while this document measures 48 headers / 42 branches / 41 map keys. Still a
  pointer, still not a finding — "41" may be a defensible statement about PRODUCT_MAP coverage.
• CI was not reproduced. 29 green on this head; logs not read.
• The vendored copy is still stale, and merging this does not fix it. ebuild's
  core/UPSTREAM.yaml pins eos 5544c98, so until someone re-pins it to whatever commit this
  lands as, ebuild/core/eos/docs/three-way-alignment.md will still ship the old ✅ ALL ALIGNED
  text. Closing eos#149 here closes it for eos, not for what ebuild vendors. I did not verify
  what re-pinning would take.
• mergeStateStatus is BLOCKED — REVIEW_REQUIRED plus the #144 stack. I did not verify
  #144 is mergeable.

---

Automated architecture review of 9481429d9017 — 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 addressed at ad8ea82.

Finding 1 — three-way-alignment.md:304 now says 2026-09-14, matching the file header and the other three notes. Your reasoning is the reason it mattered: the figures were measured against the same eBoot 221325c the pins name, so the date was the one thing that could make a reader doubt that.

Finding 2 — hardware-alignment.md:128 now reads qemu_arm64 (eos: qemu-arm64.yaml — names differ), as you suggested. While checking that the whole column resolves, the Detailed Board Inventory at :101 had the same board as `qemu-arm64/` in directory form — the only entry in that column that does not exist under eBoot/boards/ — so it is `qemu_arm64/` there too. :71 (qemu-arm64.yaml, the eos side) is correct and unchanged.

Verified at ad8ea82, this shell: every eBoot-column entry in the inventory table resolves to a directory under eBoot/boards/ (none missing); the embedded script re-run still matches the recorded 18-line block byte for byte; pytest tests/unit -q → 43 passed.

Range for this round: 9481429..ad8ea82, two files, +3/−3. Merge order unchanged — #144 first. The §22 tier issue and ebuild's core/UPSTREAM.yaml pin stay separate, as you listed.