ci(release): stop requesting a retired runner, and run the build step in bash

[Kartikey1306]

No ebuild release has ever published

Every tag this repository has cut ran for exactly one day and failed:

failure  05-28T20:33 -> 05-29T20:33  (1d)  v1.6.0
failure  05-28T19:19 -> 05-29T19:19  (1d)  v1.5.0
failure  05-27T23:39 -> 05-28T23:39  (1d)  v1.4.0
failure  05-27T22:07 -> 05-28T22:07  (1d)  v1.3.1
failure  05-27T20:30 -> 05-28T20:30  (1d)  v1.3.0
failure  05-27T18:54 -> 05-28T18:55  (1d)  v1.2.0

Publish to PyPI (OIDC) and Create Release were skipped in all six, because they need a job that never finished.

Two causes. Both are already fixed in ci.yml and were never carried across.

1. macos-13 is retired

A job requesting it is never assigned a runner and sits queued until GitHub kills it at 24h. From the most recent release run:

cibuildwheel (macos-13)        cancelled   runner NEVER ASSIGNED
cibuildwheel (windows-latest)  failure     step "Build wheels"
cibuildwheel (macos-14)        success
cibuildwheel (ubuntu-22.04-arm) success
Publish to PyPI (OIDC)         skipped
Create Release                 skipped

Dropped rather than swapped for another image: macos-14 already succeeds, and CIBW_ARCHS_MACOS: "x86_64 arm64" makes it produce the Intel wheels macos-13 was there for, so wheel coverage is unchanged.

ci.yml moved off macos-13 already, with a comment saying exactly this. This workflow did not.

2. The build step is bash, the runner is PowerShell

run: |
  python -m cibuildwheel --output-dir wheelhouse || \
    (echo "::warning::..." && pip install build && \
     python -m build --wheel --outdir wheelhouse)

A || fallback with trailing-backslash continuations — bash syntax. The matrix includes windows-latest, where the default shell is PowerShell, so that job failed in every run for this reason alone, independently of the macOS one.

ci.yml carries the same shell: bash fix for the same matrix and the same reason.

Where this came from

Chasing why CI — ebuild run #308 showed 1d 0h 0m 3s. That run is a fossil — it ran on f3c99ff, a commit superseded before #95 merged, and the three jobs that waited 24h were its macos-13 legs. Its Windows failures were real but are historical. Following the same signature into release.yml is where the live bug was.

Verified

grep -rn "macos-13" .github/workflows/   -> only the explanatory comments
python -c "yaml.safe_load(...)"          -> release.yml parses

The workflow only triggers on v*.*.* tags, so it cannot be exercised by this PR — the next tag is the test.

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[srpatcha]

Review — ebuild#106 "ci(release): stop requesting a retired runner, and run the build step in bash"

head: cebc074 author: Kartikey1306 ci: pass (checks reported; release.yml itself cannot run on a PR — it is tag-only)

Verdict: Both changes are correct and both are worth merging — this repository has never published a release, and these are two of the reasons. The run history is in fact worse than the body claims, which I checked. The finding is that the justification given for dropping macos-13 describes wheels this project does not produce: ebuild is pure Python, so cibuildwheel fails on every leg and the || fallback is what has been building the artifact all along.

Findings

#	Severity	File:line	Finding	Recommended fix
1	Medium	.github/workflows/release.yml:38-46, :64	CIBW_ARCHS_MACOS: "x86_64 arm64" is inert, and the reason given for dropping macos-13 rests on wheels that have never existed. The body says: "macos-14 builds both architectures via CIBW_ARCHS_MACOS below, so the x86_64 wheels macos-13 existed for are still produced." ebuild has no C extension — pyproject.toml declares build-backend = "setuptools.build_meta" with no ext-modules, no cmdclass and no setup.py (the root CMakeLists.txt belongs to the cross-compile job and is invisible to the Python build backend). cibuildwheel refuses to complete on a pure-Python project; that is why the step already carries || (echo "::warning::cibuildwheel failed (likely no C-extension)" && pip install build && python -m build --wheel ...), whose own text names the situation. So every leg falls through to python -m build --wheel and emits an identical ebuild-X.Y.Z-py3-none-any.whl. There are no per-architecture macOS wheels for CIBW_ARCHS_MACOS to preserve, and macos-13's wheels were the same universal file as everyone else's. The change is still right — a retired runner should go regardless — but the stated rationale is not, and the new env line adds a setting that does nothing. The larger point is what this exposes: four runners, four checkout+setup-python+pip-install cycles, producing four byte-identical wheels which download-artifact --merge-multiple then collapses back into one.	Drop the CIBW_ARCHS_MACOS line and correct the comment to say macos-13 is retired and nothing else. Then, as a follow-up: replace the whole cibuildwheel matrix with one ubuntu-latest job running python -m build, and reinstate cibuildwheel the day a C extension actually lands. That removes about eight minutes of release wall-clock and, more usefully, removes a step whose success has never meant what its name says.
2	Medium	.github/workflows/release.yml:64-69	The || fallback is a fail-open build step, and this PR is what makes it reachable on Windows. .ai/reviewer.md names "a || true on a build or test step" as a finding regardless of the reason given; this is the same shape with a worse tail, because it does not merely swallow the failure — it substitutes a different artifact and reports success. Today it fires by design on all four legs (finding 1), so the risk is latent. The day ebuild grows a C extension, a genuine platform-specific compile failure on, say, Windows will not fail the release: it will quietly publish a pure-Python wheel in place of the binary one, and pypa/gh-action-pypi-publish is configured with skip-existing: true, so the substitution will not even collide with anything. Before this PR, the Windows leg died on PowerShell before reaching the || at all; shell: bash is correct and necessary, and it is also what arms this path.	Make the fallback deliberate rather than a catch-all. Either drop cibuildwheel entirely (finding 1), or gate the fallback on the specific condition it exists for — check for a pure-Python build up front and choose the builder, rather than running one and catching whatever comes out. If the catch-all stays, it should at minimum re-emit the cibuildwheel exit status in the warning so a real failure is distinguishable from the expected one in the log.
3	Low	PR body, "No ebuild release has ever published"	Understated, and at least one earlier failure has a different signature that this PR does not address. I queried the workflow run history: the last 15 release.yml runs are all failure or cancelled, back to v1.0.2 on 2026-04-28 — not six. The body's six (v1.2.0, v1.3.0, v1.3.1, v1.4.0, v1.5.0, v1.6.0) are exactly right and all show the 24-hour queue-timeout signature. But v1.1.0 and four v1.0.0 attempts precede them with the same pattern, and v1.0.2 (2026-04-28T22:37→22:42) failed in five minutes, which is neither the macOS queue timeout nor a shell-syntax failure that takes the full job. v3.0.0 and v3.0.1 in mid-May are also failures, and are tags that sit oddly against the later v1.x series. So the two causes fixed here are real and are the current ones; they are not the whole history, and the next tag will reveal whether anything else is still in the way.	No change to the diff. Say in the body that the fix addresses the two causes visible in the recent runs and that older failures had a different signature, so the next tag is a test of these two fixes rather than proof the release path is healthy.
4	Low	.github/workflows/release.yml (whole file)	Nothing here can be exercised before it is relied upon. The body says this plainly and honestly — the workflow triggers only on v*.*.* tags, so the PR's own CI cannot run it, and the next production tag is the first execution. That is an uncomfortable place to be for a path with a 100% failure rate. There is a cheap way to get most of the confidence without a real tag.	Add workflow_dispatch: to the triggers, with the pypi and release jobs gated on github.event_name == 'push'. A maintainer can then run validate + cibuildwheel + cross-compile on demand, see the wheels land as artifacts, and confirm all four legs go green — before spending a tag on it. Small, and it converts finding 3's open question into an answered one.

Verified clean, checked rather than read:

• The patch applies to origin/master and the result parses. Extracted with git archive into /tmp/eb106; yaml.safe_load gives jobs ['validate', 'cibuildwheel', 'cross-compile', 'pypi', 'release'], cibuildwheel matrix ['ubuntu-latest', 'ubuntu-22.04-arm', 'windows-latest', 'macos-14'], and the Build wheels step carries shell: bash.
• macos-13 is gone from every workflow except in comments. grep -rn macos-13 .github/workflows/ on the patched tree returns three hits: ci.yml:27 and release.yml:38,45, all explanatory prose. That is the body's claim, confirmed.
• The six one-day failures are real, verbatim. gh api .../workflows/release.yml/runs returns failure v1.6.0 2026-05-28T20:33:18Z → 2026-05-29T20:33:36Z and the other five with the same 24h + ~20s shape. A 24-hour run that ends in failure is the signature of a job queued against an image that will never be assigned, so the diagnosis is right as well as the data.
• shell: bash is genuinely required, not defensive. The step body uses || with trailing-backslash continuations; windows-latest's default shell is PowerShell, where that is a syntax error. ci.yml already carries the identical fix with the identical comment for the identical matrix, so this is a repair of a known divergence rather than a new idea.
• Dropping the leg does not orphan an artifact name. upload-artifact uses wheels-${{ matrix.os }}, and both pypi and release download with pattern: wheels-* and merge-multiple: true — so removing one matrix value removes one artifact and breaks no reference.

Architecture conformance

Conforms. §21 Infrastructure — "governance, release automation and documentation". No runtime dependency in any direction; release.yml is release automation and §5.1 is untouched.

The design section this bears on is §23, "Release, Compatibility and LTS Model", and the org standard it bears on is STANDARDS.md's release model — "Consumers integrating with a product can pin to: a specific vX.Y.Z tag (most stable; recommended for production)." Six such tags exist for ebuild and none of them published an artifact, which is what this PR is fixing. Worth stating because it makes the change more than a CI cleanup: until it lands, the "most stable" pinning option the org documents does not resolve to anything installable for this repository.

Proposal appended — .ai/autoreview/proposals/2026-09.md, "A tag can advance the release pointer without any artifact having been produced" (§23.1). sync-release-branch.yml force-updates release on tag push with no dependency on release.yml's outcome (I read the file: on: push: tags:, and nothing else), so release has been advancing to commits whose release run failed. §23 defines channels and compatibility obligations and §28 defines evidence for feature claims; neither says what evidence a release itself requires. This is distinct from the existing §28.2 proposal, whose bullets cover checks that verify nothing — here the check is honestly red, and the release proceeds anyway because nothing consults it.

Proposed changes

1. Drop the CIBW_ARCHS_MACOS line and correct the macos-13 comment to the part that is true (finding 1). Two lines; everything else in the diff I would take as is.
2. Add workflow_dispatch: with the publishing jobs gated to push (finding 4), and run it once before the next tag.
3. Correct the "six runs" framing to what the history shows (finding 3). Body text only.
4. Follow up separately on collapsing the cibuildwheel matrix to a single python -m build job, and on the fail-open fallback (findings 1 and 2). Those are a design decision about the release pipeline rather than part of this repair.

Items 1–3 are independent and small. Item 4 should not hold this up — the repository currently cannot release at all, and that is the more urgent condition.

Not checked

• Nothing here was executed, and nothing here can be. release.yml is tag-only; I confirmed the file parses and the matrix and shell are what the diff says, and that is the limit of what is verifiable before a tag exists. Every statement about runtime behaviour — that cibuildwheel errors on a pure-Python project, that macos-13 jobs queue for 24h, that PowerShell rejects the || continuation — is reasoned from the configuration, the run history, and the step's own warning text, not observed.
• I did not open any of the failed runs' job logs. Finding 3's claim that v1.0.2 failed for a different reason rests on its five-minute duration versus the others' 24 hours, not on reading what it said. The body's per-job breakdown of the most recent run (cibuildwheel (macos-13) cancelled — runner NEVER ASSIGNED) I did not verify at job level either; the run-level conclusion and timing corroborate it but do not confirm the per-job detail.
• cibuildwheel==2.21.3's exact behaviour on a pure-Python project was not run. Finding 1 rests on the absence of ext-modules/setup.py in the repository plus the workflow's own fallback comment. If some configuration makes cibuildwheel succeed here after all, finding 1 narrows to the CIBW_ARCHS_MACOS line being untested rather than inert.
• I did not check whether any wheels exist on PyPI for ebuild. "No release has ever published" is inferred from the workflow history and from Publish to PyPI (OIDC) being needs-blocked; I did not query the index, and a wheel uploaded by hand at some point would not show up in what I looked at.
• The v3.0.0 / v3.0.1 tags sitting before the v1.x series are an oddity against STANDARDS.md's SemVer scheme and against sync-release-branch.yml force-updating release to whatever tag arrives last. I noted it and did not pursue it; it is not this PR's business and I have not established what those tags are.
• The local ebuild checkout is dirty and was skipped by the sync step, and sits on branch v90. I read origin/master through git show and git archive; the working tree was not touched, and the patched tree is under /tmp.
• mergeStateStatus: BLOCKED, mergeable: MERGEABLE, reviewDecision: REVIEW_REQUIRED. No merge attempted. release.yml is not touched by any other PR in this batch, so no conflicts here.

---

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

[srpatcha]

Review — ebuild#106 "ci(release): stop requesting a retired runner, and run the build step in bash"

head: 51fe3a9 author: Kartikey1306 ci: 14 pass, 4 pending

Verdict: The second commit closes three of the four findings from the review of cebc0744, and the builder-selection rewrite is a real improvement over the || catch-all. But the change that closes finding 4 — adding workflow_dispatch — was inserted into the middle of the push.tags list and has silently taken the pre-release tag pattern with it. On a workflow whose last fifteen runs all failed, this PR as it stands makes the trigger worse, not better.

Findings

#	Severity	File:line	Finding	Recommended fix
1	High	.github/workflows/release.yml:3-14	workflow_dispatch: was inserted between the two tag patterns, so - "v*.*.*-*" is now its value instead of a second entry under push.tags. Parsed, this head's trigger is {"push": {"tags": ["v*.*.*"]}, "workflow_dispatch": ["v*.*.*-*"]}. Two consequences, and at least one of them lands. (a) Pre-release tags no longer start the workflow. .github/STANDARDS.md names -rc.N as the org's only recognised pre-release suffix and states that release.yml recognises it; this repo's own release job handles them explicitly at :283 and :311 (--prerelease, prerelease: ${{ contains(tag,'rc') || contains(tag,'beta') }}), so the pattern is plainly meant to be there. (b) workflow_dispatch must be null or a mapping; a sequence is not valid in GitHub's workflow schema. If GitHub rejects it, the workflow does not load and no tag triggers a release — the exact inverse of this PR's purpose. The YAML parses either way, which is why yaml.safe_load in the body's verification did not catch it.	One line: push: tags: - "v*.*.*" - "v*.*.*-*" workflow_dispatch: Move the comment above workflow_dispatch: and put the tag pattern back where it belongs. Then re-check with a parse assertion rather than a bare safe_load — assert d["on"]["push"]["tags"] == ["v*.*.*", "v*.*.*-*"] and assert d["on"]["workflow_dispatch"] is None.
2	Medium	.github/workflows/release.yml:198, :242	mv wheelhouse/*.whl dist/ 2>/dev/null || true is the same fail-open shape this PR just removed from the build step, two jobs downstream. stderr is discarded and the failure is swallowed, so a cibuildwheel/build job that produced no wheel is indistinguishable from one that produced four. In pypi the next step is pypa/gh-action-pypi-publish with skip-existing: true; in release the next steps are sha256sum * over dist/ and the GitHub release creation. .ai/reviewer.md names "a || true on a build or test step" as a finding regardless of the reason given. Pre-existing rather than introduced here, but it sits directly in the release path this PR exists to repair, and leaving it means the release path still has a step that cannot report failure.	shopt -s nullglob; wheels=(wheelhouse/*.whl); [ ${#wheels[@]} -gt 0 ] || { echo "::error::no wheels were built"; exit 1; }; mv "${wheels[@]}" dist/. The 2>/dev/null was presumably there for the no-match case; making that case explicit removes the need for both it and the || true.
3	Low	.github/workflows/release.yml:55-56	The macos-13 comment still says "every leg falls through to the || python -m build --wheel below" — describing the fallback the same commit deleted. The reasoning is still correct; only the mechanism named is gone.	"…so every leg takes the python -m build branch below".
4	Low	checks.txt	Four checks are still pending on this head at bundle time: Analyze (Python), Cross-Platform (ubuntu-latest), Test (Python 3.10), Test (Python 3.11). Fourteen pass, none fail. Recording it because the brief asks for CI state, not because it is a defect.	None; re-check before merge.

Prior findings

Finding 1 (CIBW_ARCHS_MACOS inert, wrong rationale) — fixed. The env line is gone and the comment now says what is true: ebuild is pure Python, cibuildwheel cannot complete, and macos-13's wheels were the same universal file as everyone else's.

Finding 2 (the || fail-open build) — fixed, and better than the recommendation. The step now detects the C extension up front and chooses the builder rather than running one and catching whatever comes out, under set -euo pipefail. I ran the detection script against this head's pyproject.toml:

has_ext = False -> branch: python -m build

which is the correct branch for the project as it stands, and — the point of the change — a genuine cibuildwheel failure the day a C extension lands will now fail the step instead of silently substituting a pure-Python wheel. The heredoc is well-formed (EOF lands at column 0 after the YAML block scalar is dedented), tomllib is available because the job pins python-version: "3.12", and putting the python call in the if condition is the right way to keep set -e from firing on the pure-Python path.

Finding 3 (release history understated) — partly. The "last 15 runs all failed" figure made it into the new comment at :7, but the body still shows six tags and still reads as though those six are the whole history. Already raised; not repeating the detail.

Finding 4 (nothing here can be exercised before it is relied on) — addressed in intent, broken in execution. workflow_dispatch plus if: github.event_name == 'push' on pypi and release is exactly the right design: a maintainer can build and inspect artifacts without spending a tag, and a manual run cannot publish. Both if: guards are correctly placed. Finding 1 is the insertion, not the idea.

Architecture conformance

Master design §5.1 and §21: conforms. ebuild is Tier 1 – Foundation; release.yml is release infrastructure in the owning repo. No dependency direction is touched and nothing is importable from here.

§23, "Release, Compatibility and LTS Model", is the section finding 1 collides with. §23.1's channel model is Nightly -> Development -> Beta -> Stable -> Selected LTS, and .github/STANDARDS.md implements the Beta rung as -rc.N tags. Dropping v*.*.*-* from the trigger removes the only automation that turns an -rc tag into a published artifact, so the Beta channel would exist in the tag scheme and nowhere else. That is worth naming as more than a typo: the release-candidate path is a documented org obligation, and nothing in CI would have told anyone it had gone.

I have not opened a fix PR for finding 1. The defect exists only on this PR's branch — origin/master has the correct two-entry tags: list — and the brief forbids touching a branch belonging to an existing PR. There is nothing on master to fix.

Proposed changes

1. Restore - "v*.*.*-*" under push.tags and leave workflow_dispatch: with no value (finding 1). One line moved.
2. Add the parse assertion suggested above to whatever test covers this workflow, so the next edit to the trigger block cannot do this silently. tests/unit/test_ci_gate.py from #103/#104 is the natural home, though release.yml is out of that guard's current scope.
3. Replace the two mv … || true with an explicit empty check (finding 2).
4. Fix the stale comment (finding 3).

Step 1 should happen before merge. The rest can follow.

Not checked

• Nothing here was executed. release.yml triggers only on tags (and, now, dispatch), so this PR's own CI does not run it and neither did I. Every claim about runtime behaviour is from reading the file and parsing it.
• Which half of finding 1 actually lands. Whether GitHub rejects a sequence-valued workflow_dispatch outright or ignores it and simply loses the tag pattern, I cannot determine without pushing the workflow. The fix is the same either way, which is why I did not chase it further.
• Whether pypa/gh-action-pypi-publish fails on an empty dist/. It may well error on "no distribution files found", which would limit finding 2's blast radius in the pypi job. It would not help the release job, which goes on to sha256sum and create the GitHub release. I did not verify the action's behaviour.
• The six-versus-fifteen release history. Taken from the previous review, which queried the run history; I did not re-query it.
• macos-13 retirement itself. I took the body's claim at face value — but I did confirm it is gone from every workflow in this repo except explanatory comments, and I found the same retired image still pinned in four sibling repos' test matrices (eBrowser, eCAD-Hardware-Products, eDB, eosllm, each os: [ubuntu-22.04, macos-13, windows-2022]). If the retirement claim is right, one third of those repos' test matrix has not been running either. Out of scope here; worth someone's attention.
• The local ebuild clone was left alone — reported dirty by the sync step. All inspection was via git show on the fetched PR ref.

---

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

[srpatcha]

Review — ebuild#106 "ci(release): stop requesting a retired runner, and run the build step in bash"

head: 1613792 author: Kartikey1306 ci: pass (21 pass, 1 tag-gated skip)

Verdict: The trigger defect from the 51fe3a9f review is fixed — push.tags is back to
both patterns and workflow_dispatch is a null key, verified by parsing. The new
tests/unit/test_release_workflow.py is the right answer to "safe_load succeeded" being
mistaken for verification. But one of its five tests enumerates four of the workflow's five
jobs and omits the only one that would fail it, and the pypi job still cannot publish an
sdist because the step after "Build sdist" deletes it.

Prior findings

Finding 1 (workflow_dispatch absorbed the pre-release tag pattern) — fixed. Parsed at
this head:

trigger = {"push": {"tags": ["v*.*.*", "v*.*.*-*"]}, "workflow_dispatch": null}

and test_push_tags_are_exactly_the_patterns_we_mean plus
test_workflow_dispatch_is_a_null_key_not_a_value now pin both halves, which is more than
was asked for.

Finding 2 (mv … 2>/dev/null || true in the release path) — fixed in one of the two places,
and the remaining one is now excluded from the test that would catch it. See finding 1 below.

Finding 3 (stale macos-13 comment naming the deleted fallback) — fixed. The comment now
says the Build wheels step "selects python -m build on every leg".

Finding 4 (nothing here could be exercised before being relied on) — fixed.
workflow_dispatch with if: github.event_name == 'push' on both pypi and release;
both guards verified present by parsing.

Findings

#	Severity	File:line	Finding	Recommended fix
1	High	tests/unit/test_release_workflow.py:131-133	test_no_build_or_publish_step_swallows_its_exit_status iterates ("validate", "cibuildwheel", "cross-compile", "pypi"). release.yml has five jobs; the omitted one is release, and it is the only job in the workflow with offenders. Ran the PR's own _executable_lines helper over every job: validate 0, cibuildwheel 0, cross-compile 0, pypi 0, release 3 — release.yml:258 mv wheelhouse/*.whl dist/ 2>/dev/null || true, :260 ls -lh *.tar.gz 2>/dev/null || true, :266 sha256sum *.tar.gz 2>/dev/null >> SHA256SUMS.txt || true. Adding "release" to the tuple fails the test at once. The docstring says it "checks the jobs that build or ship"; release is the job that signs the artifacts and creates the GitHub release — it ships more than any other. .ai/reviewer.md asks whether a check was weakened to pass; a job list that excludes the failing job is that, whether or not it was meant as one.	Add "release" to the tuple and fix the three lines. :266 is the one that matters: a SHA256SUMS.txt that silently omits the cross-compile tarballs is a provenance defect against §15.1 ("signed metadata and package provenance") — consumers verify against that file. shopt -s nullglob; tars=(*.tar.gz); [ ${#tars[@]} -gt 0 ] && sha256sum "${tars[@]}" >> SHA256SUMS.txt if empty is genuinely acceptable there, but say so; otherwise fail.
2	Medium	.github/workflows/release.yml:189-192, 199-215	The pypi job builds an sdist and then deletes it before publishing. python -m build --sdist writes into dist/; four steps later Stage dist runs find dist -mindepth 1 -delete and moves only wheelhouse/*.whl in. Replayed the three steps with a stub sdist and a stub wheel: dist/ ends up holding ebuild-1.6.0-py3-none-any.whl and nothing else, so pypa/gh-action-pypi-publish uploads wheels with no source distribution. Pre-existing (find … -delete is context, not added), but it is inside the step this PR rewrites, and the PR exists because no release has ever published — the first one that does will be sdist-less.	Move the wheel staging before the sdist build, or drop the find … -delete and let Build sdist write into the already-staged dist/. Then extend finding 1's Stage dist test to assert the sdist survives: assert "find dist -mindepth 1 -delete" not in code or a positive check that dist/ ends up with both kinds.
3	Medium	.github/workflows/release.yml:204-208	The comment added to justify the new guard misstates the failure mode it replaces: "if no wheel was downloaded … dist/ ended up holding the sdist alone and PyPI was published with no wheels at all". find dist -mindepth 1 -delete on the line above removes the sdist first, so dist/ was empty, not sdist-only. Verified by replay: with no wheels, dist/ contents are []. The distinction matters — an empty dist/ is what pypa/gh-action-pypi-publish would have been handed, and whether it errors on that is the question the old code's blast radius turns on.	"…dist/ ended up empty and the publish step ran anyway." Same guard, accurate premise.
4	Low	tests/unit/test_release_workflow.py:43-64	_executable_lines builds a shlex lexer, calls list(lexer), catches ValueError and passes — the result is discarded and the comment stripping is done entirely by the regex on the next line. Eleven lines that read as a quote-safety check and do nothing. The docstring's claim is also wrong: "does not mistake a # inside a string for the start of a comment" — re.split(r'(?<![\\"\'])#', 'echo "a # b"') yields 'echo "a ', cutting inside the string. Verified. Harmless for this workflow, which has no such line, but the next one will not be.	Delete the shlex block, or use its output. Either soften the docstring to "splits on the first #, which is sufficient for this file", or strip comments with the lexer you already built.
5	Low	.github/workflows/release.yml:54-55	"Dropped rather than swapped: macos-14 builds both architectures via macos-14." The sentence names macos-14 as both subject and mechanism. The reasoning below it is right and well argued; this line is garbled.	"…macos-14 builds both architectures." The universal-wheel argument that follows already carries the point.
6	Low	.github/workflows/release.yml:283-288	for f in dist/* *.tar.gz; do [ -f "$f" ] || continue; cosign sign-blob … — if a glob matches nothing the literal pattern fails [ -f ] and the loop silently continues, so a release with nothing to sign produces no signatures and reports success. set -e on the line above does not help; the continue is the swallow. Not reachable today via the tag path (release needs pypi, which now hard-fails on an empty wheelhouse), which is why this is Low rather than higher.	shopt -s nullglob; files=(dist/* *.tar.gz); [ ${#files[@]} -gt 0 ] || { echo "::error::nothing to sign"; exit 1; } then loop over "${files[@]}". Same shape as the fix already applied in pypi.

Architecture conformance

Master design §23 (release channels, compatibility contract), §15.1 (signed metadata and
package provenance), §21 Tier 1 – Foundation and Infrastructure; .github/STANDARDS.md
"Tag scheme" and "Release model"; §28 (evidence policy).
Conforms.

release.yml is release infrastructure in the repository that owns it. Nothing is importable
from here and no dependency direction is touched, so §5.1 is not in play. The restored
v*.*.*-* pattern is what makes .github/STANDARDS.md's -rc.N rung reachable, and the
release job's prerelease: ${{ contains(tag,'rc') || contains(tag,'beta') }} logic
unreachable code without it — that was prior finding 1 and it is now correct.

Findings 1 and 2 both bear on §15.1 rather than on layering: a checksums manifest that
silently omits artifacts, and a published distribution missing its source form, are
provenance and reproducibility properties the design asks for at §15.1 and §28.1. Worth
naming because they read as CI hygiene and are not.

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

git apply                                     -> clean
yaml.safe_load(.github/workflows/release.yml) -> parses
  on: {"push": {"tags": ["v*.*.*", "v*.*.*-*"]}, "workflow_dispatch": null}
  pypi     if="github.event_name == 'push'"  needs=[validate, cibuildwheel]
  release  if="github.event_name == 'push'"  needs=[validate, cibuildwheel, pypi]
  -> both publishing jobs gated; a dispatch run cannot release

the PR's own _executable_lines rule, applied to every job:
  validate 0 · cibuildwheel 0 · cross-compile 0 · pypi 0 · release 3   (finding 1)

replay of pypi's Build sdist -> Download wheels -> Stage dist:
  with a wheel:    dist/ = [ebuild-1.6.0-py3-none-any.whl]   sdist gone   (finding 2)
  with no wheel:   rc=1, dist/ = []                                       (finding 3)

download-artifact blocks both carry merge-multiple: true, so wheelhouse/*.whl
is the right depth and the new guard will not misfire on a good run.

That last line is worth stating explicitly: I went looking for a one-directory-too-shallow
glob, because a hard exit 1 on wheelhouse/*.whl would turn every release red if
merge-multiple were absent. It is present at both :198 and :242. The guard is safe.

Proposed changes

1. Add "release" to the job tuple, then fix :258, :260 and :266 — :266 first
   (finding 1).
2. Reorder the pypi job so the sdist survives staging, and assert it (finding 2).
3. Correct the comment's premise (finding 3).
4. Findings 4–6 are small and can travel with the above.

No fix PR opened. Findings 1–3 live on this PR's branch or are already half-addressed by it,
and the brief forbids touching a branch belonging to an open PR; the three || true lines do
exist on origin/master, but a separate PR against them would collide with this one directly.
Better fixed here.

Not checked

• release.yml was not executed and cannot be from a pull request — it triggers on
  v*.*.* tags and, now, workflow_dispatch. Every runtime claim above comes from parsing
  the file or from replaying an individual step's shell in isolation, not from a run.
• pytest is not installed in this environment, so none of the five tests in
  test_release_workflow.py was run through pytest. Finding 1 was established by importing
  the module's own _executable_lines and applying its rule to all five jobs; findings 2 and
  3 by replaying the steps' shell verbatim.
• Whether pypa/gh-action-pypi-publish errors on an empty dist/ — still not verified,
  carried over from the previous review. It now matters less, since Stage dist fails first.
• Whether GitHub's schema rejects a sequence-valued workflow_dispatch outright — moot at
  this head, and still unverified.
• The macos-13 retirement itself is taken from the PR body. It is gone from every workflow
  in this repo bar explanatory comments. The observation from the previous review stands and
  is still unaddressed: eBrowser, eCAD-Hardware-Products, eDB and eosllm each still
  pin macos-13 in os: [ubuntu-22.04, macos-13, windows-2022]. Out of scope here.
• The local ebuild clone was left alone — the sync step reported it dirty (4 files, on
  branch v90). All inspection was via git archive origin/master into a scratch directory,
  which touches neither the working tree nor the index. origin/master was confirmed current
  against git ls-remote before I relied on it.
• mergeStateStatus: BLOCKED, reviewDecision: REVIEW_REQUIRED — not investigated.

---

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