[lastobelus]

What changed

• add a manual-only GitHub Actions workflow that builds an unsigned Intel macOS LastCode artifact from an exact installable tag and exact 40-character commit
• validate that the requested commit and installable tag agree before building
• generalize the existing macOS build helper so both arm64 and x64 artifacts use the same provenance and packaging path
• add the explicit dist:lastcode:mac:x64 package command and focused architecture tests

Why

Building and validating a desktop artifact on the machine that will run it can interfere with active provider workloads, especially on older Intel hardware. This creates a small off-host staging path: GitHub builds an artifact for one immutable LastCode target, while installation and activation remain separate and guarded.

This is a tracer for #38, not the daily scheduler or installer automation.

User impact

Maintainers can manually dispatch an Intel build for a known LastCode checkpoint or revision and download a short-lived artifact with checksums and provenance. The workflow does not install anything, restart LastCode, publish a release, change network exposure, or require signing secrets.

Validation

• pre-push LastCode quick CI passed, including formatting, lint, workspace typechecks, and all workspace test suites
• focused macOS build-helper tests passed
• script typecheck passed
• workflow and source diff pass git diff --check

Known concern

The artifact is intentionally unsigned and certificate-free. Gatekeeper/quarantine handling and drain-before-activation remain the responsibility of the external guarded installer; this workflow only stages artifacts.

Developed with Codex GPT-5.6-sol through the T3 Code Codex harness.

@codex review

💡 Codex Review

lastCode/scripts/lastcode-build-mac.ts

Lines 238 to 240 in 1a92975

	git(repoRoot, [
	"tag",
	"--annotate",

Configure a Git identity before creating the annotated tag

On a fresh GitHub-hosted macOS runner, the new Intel workflow never configures user.name or user.email, but this unconditional git tag --annotate needs a tagger identity. Consequently the build step fails with “Committer identity unknown” after producing the DMG, and the following artifact-upload step is skipped. Configure a repository-local automation identity in the workflow or provide GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL for this command.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Fixed the Git identity failure in 6f54e88 by supplying GitHub Actions bot committer identity only to the annotated-tag build step. This preserves local maintainer identity while making a fresh hosted runner deterministic.

@codex review

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 6f54e88df6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6f54e88df6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Key the build output directory by architecture

When the arm64 and x64 commands build the same installable in one checkout, both resolve outputDir from only the version and commit. The first build therefore leaves that directory present, and the second exits at the existing-output guard before this architecture-specific invocation runs. Include the architecture in the output key, or otherwise provide separate default destinations, so both newly supported artifacts can be produced without deleting or overriding the first build.

Useful? React with 👍 / 👎.