ci: run the build-and-test workflow on master

[srpatcha]

ci.yml watched main and develop. Neither exists — this repository's default
branch is master:

default branch: master
main:           404 Branch not found

So every push to master and every pull request against it falls outside the
trigger, and the build-and-test workflow has not run on a change since
2026-05-31.

A repository-wide rename from main to master in late May left the workflow
pointing at a branch that had gone. The same thing happened in six repositories
at once:

repo	ci.yml watched	last run
eAI	[main, develop]	2026-05-31
eNI	[main, develop]	2026-05-31
eIPC	[main, develop]	2026-05-31
eDB	[main, develop]	2026-05-31
eBrowser	[main, develop]	2026-05-31
eOffice	[main, develop]	—

eApps is the one that got it right: [main, master, develop].

The change

master is added rather than substituted, on both push and
pull_request, so a rename in either direction does not break this again. YAML
validated.

Verified on eAI first

embeddedos-org/eAI#39 is the same change, and it demonstrably works — that PR
went from a single skipped assign job to C/C++ Tests and Python Tests
actually running.

Expect the first run to be red

Three months of changes have landed here with no build or test gate. Finding out
what broke is the point of turning it back on; it is not a regression introduced
by this PR.

Worth doing next

No repository in the organisation has a required status check
(required_status_checks: null everywhere). That gap let non-compiling code
reach master in eos and an unparseable file reach master in ebuild. Once this
workflow is green again, it is the obvious candidate to mark required.

This is the third hardcoded-name failure found this week, after
embeddedos-org/ebuild#81 ("branch": "main" for repositories whose default is
master) and embeddedos-org/EoSim#16 (a lowercase repo list that found 2 of 19
on a case-sensitive filesystem).

Fixes #35

[srpatcha]

CI is running on this PR, and it immediately surfaced failures that have been
invisible since May. That is the point of the change, not a regression from it.

Same result across all six repositories where the trigger was orphaned:

repo	PR	pass	fail	first failure
eAI	#39	3	1	Python Tests
eNI	#30	7	1	Python Tests
eIPC	#31	6	1	Build & Test (Linux x86_64)
eDB	#70	5	3	Test (Python 3.10/3.11/3.12)
eBrowser	#20	3	3	Test (Python 3.10/3.11/3.12)
eOffice	#40	1	1	Lint & Type Check

Nine failing checks across six repositories, none of which anyone could see
yesterday. Most of the suites pass — the repositories are not broadly broken —
but each has at least one real problem that three months of merges walked past.

eAI's has been diagnosed (embeddedos-org/eAI#40): the test suite imports numpy,
which is declared nowhere, and ci.yml hides it with

pip install -r requirements.txt 2>/dev/null || true

where requirements.txt does not exist, so || true turns "nothing to install"
into a silent success. Worth checking whether the same line is in this
repository's workflow, since these files are near-identical across the
organisation — that one construct would also swallow a genuine pip failure.

On merging this while it is red

The red reflects reality; the green before it did not. My preference is to merge
the honest gate and fix what it finds, rather than hold the gate until the
repository is clean — the second option means the failures stay invisible for
however long that takes.

If you would rather land a green master, fix the failing check first and this
can follow. Either order works. What does not work is leaving the trigger
pointing at a branch that was deleted in May.

[srpatcha]

Review — eIPC#31 "ci: run the build-and-test workflow on master"

head: f77dd17 author: srpatcha ci: fail — Build & Test (Linux x86_64) fails; Cross-compile ARM Cortex-M4 and Create GitHub Release skipped; 6 others pass

Verdict: The two-line change is correct and I would merge it. The framing around it is not: this is not a repository whose gate went red from three months of unwatched drift. ci.yml's test job runs cmake -B build/host at the repository root, and this repository has never had a root CMakeLists.txt — git log --all --diff-filter=AD -- CMakeLists.txt is empty across the whole history. eIPC is a Go module with a C SDK in a subdirectory. So restoring the trigger restores a workflow that cannot pass as written, and Build & Test (Linux x86_64) will stay red after every fix to the Go code, because the failure is in Configure (host) before any test runs. Separately, the sweep that found six repositories missed three, and missed two non-ci.yml workflows with the identical defect — including one in eApps, the repository the body holds up as the counter-example.

I am not restating the existing comment's points (the red-vs-honest-gate argument, the required-status-checks gap, the || true pattern in eAI). Finding 3 answers the open question it left for a reviewer.

Findings

#	Severity	File:line	Finding	Recommended fix
1	High	.github/workflows/ci.yml:32-40	Build & Test (Linux x86_64) cannot pass, and not for a reason any code change will fix. The Configure (host) step runs cmake -B build/host -G Ninja … with the working directory at the repository root. There is no CMakeLists.txt there, and there never has been: git log --oneline --all --diff-filter=AD -- CMakeLists.txt returns nothing, and find . -name CMakeLists.txt -not -path './.git/*' returns exactly two, both under sdk/c/ (sdk/c/CMakeLists.txt, sdk/c/tests/CMakeLists.txt). go.mod declares module github.com/embeddedos-org/eipc, go 1.22; the top-level source directories are cmd/, core/, protocol/, transport/, services/, security/, sdk/. This is a Go repository with a C SDK subproject, and ci.yml was written for a C/CMake project rooted at the top. The body says "finding out what broke is the point of turning it back on" — but nothing broke here; the workflow never fitted. That distinction decides what the next PR has to do.	Point the C build at the subproject that has one, and add the Go gate that is missing (finding 2). Minimum viable change to ci.yml: cmake -B build/host -S sdk/c … and ctest --test-dir build/host. Keep this PR as the two-line trigger fix and do the workflow rewrite separately — they are different changes and mixing them makes the trigger fix un-revertable.
2	High	.github/workflows/ci.yml:15-58	No job in ci.yml runs go test, so the majority of the repository has no CI gate even once the trigger is fixed. The test job's steps are apt install, cmake configure, cmake build, ctest, pytest tests/, codecov. There is no actions/setup-go, no go build, no go vet, no go test — grep -n "setup-go|go test|go build|go vet" .github/workflows/ci.yml returns nothing. Meanwhile Makefile:37 defines a test target and is never invoked, and tests/ contains integration_test.go, security_test.go and stress_test.go alongside the Python suites. Git history shows this was not always so: de37d10 (2026-04-28, "fix: ensure continue-on-error on all CI jobs") shows the then-current ci.yml had setup-go, a fuzz job, and a build-c-sdk job that did cmake -B build inside sdk/c or fell back to make. 4d99ce0 (2026-05-27, "feat: production-ready v1.4.0 — real source code, real tests, CI pipelines", +147/-17 on this file) replaced it with the current CMake-at-root template. The Go gate was removed four days before the branch rename hid the result.	Add a Go job: actions/setup-go@v5 with go-version from go.mod, then go build ./..., go vet ./..., go test ./... -race. Makefile already has test, vet and lint targets — calling make test vet keeps one definition of the commands instead of two. This is the check that would actually have caught three months of drift.
3	High	.github/workflows/ci.yml:104-113	Static Analysis (cppcheck + clang-tidy) reports pass without analysing anything, and half of what its name promises is never invoked. Answering the question the existing comment left open — eIPC's ci.yml does not contain eAI's pip install -r requirements.txt 2>/dev/null || true; line 29 installs pytest pytest-cov directly, so that specific failure mode is absent here. The equivalent is worse. The cppcheck step is cppcheck --enable=all --error-exitcode=1 … -I include/ src/ with continue-on-error: true on the step. Two independent defects: (a) neither include/ nor src/ exists in this repository (ls -d include src → both "No such file or directory"; they have never existed, and the real C sources are sdk/c/src/), so cppcheck is given no input and cannot report on any file; (b) --error-exitcode=1 is explicitly asking cppcheck to fail the step, and continue-on-error: true then discards that exit code — the two lines cancel out. checks.txt shows this check green in 13s, which is about what an apt install plus a no-op costs. .ai/reviewer.md names "a verification whose result is discarded" as a finding regardless of the reason, and this is one twice over. clang-tidy is apt-installed at line 105 and never run; the job name asserts a tool that does not execute.	Point cppcheck at sdk/c/src with -I sdk/c/include (confirm those paths first), and delete continue-on-error: true so --error-exitcode=1 means something. Either add a clang-tidy step or rename the job to Static Analysis (cppcheck). If cppcheck's output is not yet clean, gate it to changed files or record a baseline — do not keep a green check that inspects nothing.
4	Medium	.github/workflows/ci.yml:76-84	Cross-compile ARM Cortex-M4 references a toolchain file that has never existed. Configure (ARM) passes -DCMAKE_TOOLCHAIN_FILE=cmake/arm-cortex-m4.cmake. There is no cmake/ directory in the repository and git log --all -- cmake/ is empty. The job currently reports skipping only because needs: test and test fails; once finding 1 is fixed it will run and fail here instead. Worth knowing now, because "fix the failing check" will otherwise look like whack-a-mole.	Add the toolchain file, or drop the job until there is an ARM target to build. A cross-compile job that has never once compiled is not evidence of portability, and §22 requires "Regular build/simulation" before a target may be called Validated.
5	Medium	PR body, the six-repo table	The sweep is incomplete: three more repositories have the same orphaned ci.yml, and two workflows other than ci.yml have it too — one of them in eApps, which the body names as the repository that "got it right". I read .github/workflows/* from origin/<default-branch> in all 20 local clones and reported every pre-jobs: branches: filter that omits master. Still orphaned on the default branch right now: eAI/.github/workflows/ci.yml [main, develop]/[main] (PR #39 open); eAI/.github/workflows/cross-platform-hal.yml [main, develop] (no PR); eApps/.github/workflows/ci-native.yml [main]/[main] (no PR — eApps/ci.yml is indeed correct, so the body's claim holds for that one file and not for the repository); eCAD-Hardware-Products/.github/workflows/ci.yml [main, develop]/[main] (no PR); embeddedos-org.github.io/.github/workflows/ci.yml [main, develop]/[main] (no PR); eosllm/.github/workflows/ci.yml [main, develop]/[main] (no PR); and this repository, which this PR fixes. eDB, eBrowser and eOffice are already clean on origin/master, so their fixes landed. Every clone's default branch is master and none has an origin/main (git show-ref refs/remotes/origin/main fails in all 20). eos-aero has no workflows on origin/master; eos-health has none on origin/main. The eCAD gap matters most: eCAD#20 and eCAD#22 in this same review batch are both about a pytest failure in a repository whose test workflow has never run, and neither PR fixes the trigger.	Extend the sweep rather than the table: for each repo, for f in .github/workflows/*; do check every pre-jobs: branches: list, not just ci.yml. Then open the four remaining PRs (eAI ×1 more, eApps, eCAD-Hardware-Products, embeddedos-org.github.io, eosllm). A repeatable check belongs in the org .github repo so the next rename cannot reopen this — that is the durable version of the "mark it required" suggestion already in the body.

Verified clean, and these are the parts of a trigger fix that most often go wrong:

• The change is additive in both places, exactly as claimed. push: branches: [master, main, develop], pull_request: branches: [master, main] — master prepended, nothing removed, tags: ["v*"] untouched. A rename in either direction now leaves a working trigger, which is the property the body says it wanted.
• The trigger fix demonstrably worked. checks.txt on this head carries Build & Test (Linux x86_64), Static Analysis (cppcheck + clang-tidy), Cross-compile ARM Cortex-M4 and Create GitHub Release — jobs from ci.yml, which by definition could not have appeared on a PR before this change. The mechanism is proven; findings 1–4 are about what it now exposes.
• It is a two-line diff in one file, with no behaviour change smuggled in. files.txt is 2+ 2- .github/workflows/ci.yml; pr.json agrees (changedFiles: 1). .ai/architect.md forbids restructuring and changing behaviour in one commit, and this PR keeps to that — which is why I would merge it rather than fold findings 1–4 into it.
• The pytest tests/ step is correctly targeted. tests/unit/, tests/functional/, tests/performance/ and tests/simulation/ all exist with __init__.py and test_*.py files, so once Configure (host) stops failing, that step has real suites to run.

Architecture conformance

Conforms. §21 places eIPC in Tier 2 — Core Platform ("Communication, security, connectivity and lifecycle"), and .github/workflows/ is §21's Infrastructure row ("Governance, release automation and documentation"). §5.1 is not engaged: no #include, import, link line, target_link_libraries entry or manifest dependency changes, and CI is host-side, never a runtime dependency. §21.1 is not engaged; nothing moves.

The design bears on the findings in two places, and in both the design is right and the repository is not, so no proposal is appended:

• §12 eIPC Redesign splits the subsystem into "EoS IPC Core" (§12.1 — queues, mailboxes, shared memory, events, local RPC) and "eIPC Fabric" (§12.2 — UART/CAN/TCP/shared transport), and closes with "Small MCUs must not be forced to carry a gateway-class communication runtime." That split is precisely what findings 1–2 leave unverified: the C SDK under sdk/c/ is the small-target side and its CMake project is never built by CI, while the Go side is the fabric/gateway side and has no gate at all. §12's central constraint has no check behind it.
• §28 Status, Evidence and Claims Policy requires Implemented to carry "Code and functional tests" and Validated to carry "Hardware/CI/test reports/benchmarks". Finding 3's green-but-vacuous static-analysis check is the case the already-appended §28.2 proposal in proposals/2026-09.md ("The evidence policy is silent on checks that verify nothing", triggers eAI#39/#41/eBoot#81) was written for. This is another instance of it, not a new gap, so I have added no duplicate proposal. Finding 4's never-run cross-compile job is §22's Validated tier asserted without the "Regular build/simulation" it requires.

Proposed changes

1. Merge this PR as-is. An honest red gate beats an invisible green one, and the existing comment already argues that; findings 1–4 are reasons the follow-up is bigger than expected, not reasons to hold this.
2. Rewrite ci.yml's test job for what this repository is: a Go job (setup-go, go build/vet/test ./... -race, or make test vet) plus a C job rooted at sdk/c (findings 1–2). This is the change that turns the gate from unpassable to meaningful.
3. Fix the static-analysis job: real paths, drop continue-on-error: true, and either run clang-tidy or stop naming it (finding 3).
4. Add cmake/arm-cortex-m4.cmake or remove the ARM job (finding 4).
5. Open the five remaining orphaned-trigger PRs and add a repeatable org-level check over all workflows, not just ci.yml (finding 5). Independent of 1–4 and the cheapest item on this list.

Order: 1 now, then 5 (it is mechanical and unblocks eCAD#20/#22's test claims), then 2–4 as one workflow rewrite. Marking the check required — already suggested in the body — must wait until after 2, or it will block every PR on a Configure (host) failure.

Not checked

• I did not read the failing run's log. The Build & Test (Linux x86_64) attribution to Configure (host) is derived from the workflow file plus the absence of a root CMakeLists.txt in the working tree and in the full history, not from the job output at actions/runs/33359520394/job/99388047193, which I did not fetch. It is the first step that must fail, but I have not excluded an earlier failure in Install dependencies.
• Nothing was built, compiled or tested. No cmake, no ctest, no go test, no pytest. I do not know whether sdk/c builds, whether the Go suites pass, or what cppcheck would say if aimed at real files. Findings 1–4 are about what the workflow can and cannot do, not about the state of the code.
• cppcheck is not installed on this host (command -v cppcheck → nothing), so finding 3(a) rests on include/ and src/ being absent rather than on an observed cppcheck error message. The conclusion that the step analyses nothing follows from the missing input path; the exact exit code and message are inferred.
• Run history is unverified. "the build-and-test workflow has not run on a change since 2026-05-31" and the per-repo "last run" column are the body's claims; I did not query the Actions API. What I did verify is the mechanism that would cause it (orphaned filters, no origin/main in any clone) and the 2026-05-27 workflow replacement in 4d99ce0 four days before that date. Whether the four runs in that window passed or failed, I do not know.
• Finding 5 covers the 20 local clones only, and reads origin/<default> as of this run's fetch. The organisation has 26 repositories by the sibling PR bodies' count, so up to six were not examined. I also matched only branches: lists appearing before jobs:; a filter inside a reusable-workflow call or a paths-only trigger would not be caught, and I did not check workflow_run, schedule or workflow_dispatch arms.
• required_status_checks: null everywhere is the body's claim about branch protection; that is org-admin state I did not query.
• mergeStateStatus: BLOCKED, mergeable: MERGEABLE, reviewDecision: REVIEW_REQUIRED. No merge attempted, nothing pushed. The clone sits on fix/ci-runs-on-master; the sync step reported it clean, I read history and file layout through git log/git show/git archive into a temp directory, and the working tree is unchanged.

---

Automated architecture review of f77dd17666d3 — 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]

Updated the PR branch in commit 76faf27 to validate the actual Go and C SDK layouts instead of assuming a root CMake project. Validation: C SDK Debug build passed, CTest passed 5/5, YAML parsing passed, and all 11 GitHub checks are green: https://github.com/embeddedos-org/eIPC/actions/runs/34420630772.

[srpatcha]

Review — eIPC#31 "ci: run the build-and-test workflow on master"

head: 76faf27 author: srpatcha ci: pass (11/11)

Verdict: Follow-up. 76faf27 resolves all four in-repo findings from the previous review — the unpassable root-CMake job, the missing Go gate, the vacuous static-analysis check and the phantom ARM toolchain — and does it by rewriting ci.yml for what this repository actually is. Two things remain: the org-wide sweep (prior finding 5) is untouched, and the rewrite quietly dropped the Python suites' only job.

Prior findings

Prior #	Status	Evidence
1 — Build & Test (Linux x86_64) cannot pass; cmake -B build/host at a root with no CMakeLists.txt	Resolved in 76faf27	The test job is gone; c-sdk runs cmake -S sdk/c -B build/c.
2 — no go test anywhere, majority of the repo ungated	Resolved in 76faf27, beyond what was asked	go job: setup-go@v5 with go-version-file: go.mod, go build ./..., go test -race ./..., go vet ./..., plus a gofmt -l gate, across ubuntu-22.04 / macos-14 / windows-2022. 36 _test.go files go from zero coverage to gated on three platforms.
3 — Static Analysis (cppcheck + clang-tidy) green without analysing anything	Resolved in 76faf27, all three parts	Paths corrected to -Isdk/c/include sdk/c/src; continue-on-error: true deleted so --error-exitcode=1 now decides the job; clang-tidy is no longer installed and the job is renamed C SDK static analysis, so the name no longer asserts a tool that never ran.
4 — Cross-compile ARM Cortex-M4 references cmake/arm-cortex-m4.cmake, which never existed	Resolved in 76faf27 by removal	The build-arm job is deleted. That was the second of the two options offered, and the right one — a job that has never compiled is not evidence of portability (§22).
5 — sweep incomplete: five more repositories, six workflows, still orphaned	Untouched — still open	Re-swept every .github/workflows/* on each clone's origin/<default> during this run. Unchanged from the last review: eAI/ci.yml [main, develop]/[main], eAI/cross-platform-hal.yml [main, develop], eApps/ci-native.yml [main]/[main], eCAD-Hardware-Products/ci.yml [main, develop]/[main], embeddedos-org.github.io/ci.yml [main, develop]/[main], eosllm/ci.yml [main, develop]/[main]. All six default to master. The eCAD note still stands: PRs about a pytest failure in a repository whose test workflow has never run.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	.github/workflows/ci.yml (base ci.yml:49-60, removed)	The Python suites lost their only job and the PR does not mention it. The old test job had Run Python tests (pytest tests/) and a codecov upload; the rewrite has go, c-sdk and static-analysis and no Python step. I grepped every one of the 14 workflows on this head for pytest — no match in any of them. Four suites are now ungated: tests/unit/test_unit_core.py, tests/functional/test_functional_e2e.py, tests/performance/test_performance_benchmarks.py, tests/simulation/test_emulation_simulation.py. In practice nothing regresses today, because that step never executed — Configure (host) failed first, which was prior finding 1 — but the rewrite was the moment to carry it across, and a removed check is a finding regardless of the reason (brief §4, .ai/reviewer.md). The previous review explicitly listed this step as "verified clean… once Configure (host) stops failing, that step has real suites to run"; it now never will.	Add a fourth job: actions/setup-python@v5, pip install pytest, pytest tests/unit tests/functional -q. Leave tests/performance and tests/simulation out of the PR gate (or mark and deselect them) so latency stays reasonable — nightly.yml is the right home for those. If dropping Python CI is deliberate, say so in the body and delete the suites; leaving them in the tree with no runner is the worst of the three options.
2	Medium	PR title and body	The PR outgrew its description. The title is still "ci: run the build-and-test workflow on master" and the body argues, at length, for a change that "adds rather than substitutes" two branch names. The diff is now 61+ 135-: three jobs replaced, two (build-arm, release) deleted. The follow-up comment describes the rewrite, but comments do not survive into the merge commit — the body does. Someone later reverting "the trigger fix" reverts the whole CI rewrite with it. .ai/architect.md says not to restructure and change behaviour in one commit, and the previous review said the same in as many words: "Keep this PR as the two-line trigger fix and do the workflow rewrite separately — mixing them makes the trigger fix un-revertable."	Least-effort fix that keeps the value: retitle to something like ci: fix the branch trigger and rewrite the workflow for the Go + C SDK layout, and rewrite the body's "## The change" section to list all five job-level changes including the two removals. Splitting is cleaner but no longer worth the churn now that CI is green on the combined change.
3	Low	.github/workflows/ci.yml:6	push: tags: ["v*"] is retained, but the release job that consumed it was deleted. Releases are correctly handled by .github/workflows/release.yml (triggers v*.*.* / v*.*.*-*, runs go test -race -v ./... then a goos/goarch build matrix), so no capability is lost — but every v* tag now also fires go, c-sdk and static-analysis here, re-running validation release.yml already does.	Either drop the tags: line, or keep it deliberately and say why in a comment.
4	Low	.github/workflows/ci.yml:12-14	cancel-in-progress: true is unconditional, so it applies to push on master as well as to PRs. Two merges in quick succession leave the first commit on master with a cancelled run and no completed CI result — which matters more than usual here, since this PR's whole argument is about master having no visible gate.	cancel-in-progress: ${{ github.ref != 'refs/heads/master' }}.

Verified clean this round, and these are the parts of a CI rewrite that usually hide a defect:

• The CMake option names are real. EIPC_SKIP_INSTALL is read at sdk/c/CMakeLists.txt:48 and EIPC_BUILD_TESTS at :89 (if(BUILD_TESTING OR EIPC_BUILD_TESTS)), so neither -D is a silently-ignored cache variable. sdk/c/tests/CMakeLists.txt defines exactly five tests — test_hmac, test_frame, test_transport, test_chat_json, test_eipc_easy — matching the "CTest passed 5/5" in the author's comment.
• --no-tests=error is on the ctest invocation. .ai/security.md calls out that ctest exits 0 when it collects nothing; this is the one line that stops the C gate becoming the next instance of prior finding 3.
• The claim "all 11 GitHub checks are green" is supported. checks.txt on this head lists 11 checks, all pass, none skipped or continue-on-error.
• Windows multi-config is handled. --config Debug appears on both cmake --build and ctest, which is what MSVC's multi-config generator needs and the usual omission.
• permissions: contents: read is new and correct — no job in this file writes anything, and release.yml carries its own contents: write.
• The go job's fail-fast: false means one platform failing still reports the others, which is what you want from a portability matrix.

Architecture conformance

Conforms, and this commit closes the gap the previous review raised. §21 places eIPC in Tier 2 — Core Platform and .github/workflows/ in the Infrastructure row; §5.1 is not engaged, since no include, import, link line or manifest dependency changes and CI is never a runtime dependency. §21.1 is not engaged; nothing moves.

The substantive point: §12 splits eIPC into EoS IPC Core (§12.1 — queues, mailboxes, shared memory, events, local RPC, for small MCUs) and eIPC Fabric (§12.2 — the gateway-class runtime over UART/CAN/TCP), closing with "Small MCUs must not be forced to carry a gateway-class communication runtime." The last review's complaint was that §12's central constraint had no check behind it — the C SDK (small-target side) was never built and the Go fabric had no gate at all. 76faf27 puts a build and test gate on both sides across three host platforms. §28's Implemented bar ("Code and functional tests") is now actually met for both halves of this repository, where before it was asserted by a workflow that could not run. No proposal appended: the one gap this touches, checks that verify nothing, is already recorded in proposals/2026-09.md (§28.2), and this commit is an instance of that proposal being fixed, not a new gap.

Proposed changes

1. Add the Python job (finding 1) — the only remaining hole in this repository's gate.
2. Retitle and rewrite the body's "## The change" section to cover the two job removals (finding 2). Do this before merge; it is the merge-commit message.
3. Findings 3 and 4 are one line each and can ride along.
4. Prior finding 5 is the highest-value item and is not in this repository. Six workflows across five repos still have the orphaned trigger. That is five mechanical PRs, and eCAD is the one to do first, since open PRs there are making test claims against a workflow that has never run. The durable version — a check in the org .github repo that fails when any workflow's pre-jobs: branches: list omits the default branch — is what stops the next rename reopening all of this.

Not checked

• Nothing was built, tested or linted by this review. No go test, no cmake, no ctest, no cppcheck, no pytest. The green CI is GitHub's result, not mine; I confirmed the workflow's option names, paths and flags against the repository contents at head 76faf27, which is a different thing from reproducing the run.
• I did not read any job log, including the passing ones. "CTest passed 5/5" is corroborated by there being exactly five add_test entries, not by the run output.
• cppcheck's output is unverified. I confirmed sdk/c/src and sdk/c/include exist and that continue-on-error is gone, so the exit code now counts. Whether the green result means cppcheck found nothing or found only suppressed categories, I did not check — --enable=warning,performance,portability is narrower than the old --enable=all, and I have not compared what that excludes.
• The sweep in prior finding 5 covers the 20 local clones only, re-read at this run's fetch. Repositories not cloned here were not examined, and I matched only branches: lists appearing before jobs: — a filter inside a reusable-workflow call, or a workflow_run/schedule arm, would not be caught.
• Whether the four Python suites currently pass. They have not run in CI since before 2026-05-31 and I did not run them, so finding 1's cost is unknown: adding the job may turn the gate red. That is the right outcome either way, and it is the same argument this PR's body already makes.
• Branch protection and required_status_checks remain org-admin state I did not query.
• No merge attempted, nothing pushed. The clone sits on fix/ci-runs-on-master, read through git show against FETCH_HEAD; the working tree is unchanged.

---

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