Comparing changes

## Summary Adding an architecture test to try and prevent LLMs from fetching data from the client, and giving some guidance on what to do instead.

## What Adds `.github/actionlint.yaml` declaring our Blacksmith runner labels. [actionlint](https://github.com/rhysd/actionlint) has no way to know about self-hosted or third-party runner labels, so it flagged every `runs-on:` in the repo as unknown. That was **38 of the 43 findings** across `.github/` — enough noise to bury the 5 real ones and make the tool close to useless locally. With the config, the same run reports **5 findings, all genuine**: - `docker-aliases.yml`, `docker-publish.yml` ×2, `reef-docker-publish.yml` — `unexpected key "queue" for "concurrency" section` - `reef-docker-publish.yml:195` — shellcheck `SC2329`, function never invoked Those are pre-existing and left alone here; this PR is only about making them visible. ## Labels declared Collected from the whole of `.github/`: ``` blacksmith-2vcpu-ubuntu-2404 blacksmith-4vcpu-ubuntu-2404 blacksmith-4vcpu-ubuntu-2404-arm blacksmith-4vcpu-windows-2025 blacksmith-6vcpu-macos-26 blacksmith-8vcpu-ubuntu-2404 ``` The file carries the one-liner for regenerating that list, since it needs a new entry whenever we add a runner size: ``` grep -rhoE '\bblacksmith-[a-z0-9.-]+' .github/ | sort -u ``` ## Scope actionlint isn't currently wired into CI anywhere, so this changes nothing about what runs on a PR — it only affects local and editor invocations. Happy to add a CI job in a follow-up if we want the 5 remaining findings enforced rather than merely visible. Based on `main`, independent of #2193. https://claude.ai/code/session_01CkhwFPaGGcHq3YnFkBythS

## What The `notify-release` job posts the promoted release's changelog to Discord. It's the last job in the release workflow and nothing depends on it, but until now any failure — an unset webhook secret, a transient Discord outage, a hung request — turned an otherwise successful release run red. Delivery is strictly a nice-to-have, so this makes it degrade rather than fail. ## How - **Job level**: `continue-on-error: true`, so even an unexpected failure (runner death, `gh` blowing up in a way the script doesn't anticipate) leaves the run green. By this point the release is already published and promoted. - **Step level**: each fallible operation now emits a `::warning::` annotation and exits cleanly, so the reason shows up in the run summary instead of being buried in a red log. Covered cases: - missing/empty `DISCORD_CHANGELOG_WEBHOOK` — previously `curl` would fail on an empty URL - the release lookup failing - payload construction failing - the webhook rejecting the post - **`--max-time 30`** on the `curl`, so a hung webhook can't hold a runner open indefinitely. The existing comment about keeping delivery in its own job so a failed webhook can be retried still holds — re-running `notify-release` on its own remains the recovery path, and it now reports a soft failure rather than sinking the release. ## Testing Workflow YAML parses, `bash -n` is clean on the extracted script, and `actionlint` reports nothing on the changed lines (its only output is the pre-existing unknown-`blacksmith-*`-runner-label warnings across the whole file, from there being no local `actionlint.yaml` runner config). https://claude.ai/code/session_01CkhwFPaGGcHq3YnFkBythS

## Intent The React Router frontend shell was called Reef. This renames it to Coral UI so the product surface and the repository agree on one name. The rename is total by design. There are no external users of the `REEF_*` environment variables, and our own deployments are updated alongside this change, so nothing here keeps the old spellings alive: no fallback reads, no deprecation warnings, no regression guards naming retired variables, and no "formerly named" notes. Outside the release changelogs, which keep their history, the only remaining matches for `reef` in the tree are five lines that are not the product name — the `freeform` substring (three lines in two files) and two lines of coral-reef brand metaphor that refer to the project rather than to this app (`release.yml`'s Discord release footer, one line of the Groq source README). A name collision had to be resolved first: `apps/ui/package.json` already declared `"name": "coral-ui"`, though `apps/ui` is a different app — the UI compiled into the CLI binary. Coral UI takes the name; `apps/ui` vacates to `coral-embedded-ui`. `AGENTS.md` now spells out which app is which, because the two directory names are easy to confuse. ## What it enables - One name for the app across the directory, npm package, identifiers, environment, cookies, image, docs, and CI. - A published image at `ghcr.io/withcoral/coral-ui` that matches the product. - CI that still guards the app: the `paths:` filters moved with the directory, so the checks and image jobs keep triggering. This one mattered — `validate.yml` treats a skipped job as success, so a stale filter would have quietly stopped guarding `main` while pull requests kept going green. ## Contributor and agent behavior that changes - Coral UI verification commands move from `--prefix apps/reef` to `--prefix apps/coral-ui`. - Docker targets are `make coral-ui-docker-{build,smoke,test}`. - `AGENTS.md`'s repo map and rules now distinguish `apps/coral-ui` (standalone server, npm package `coral-ui`) from `apps/ui` (compiled into the CLI binary, npm package `coral-embedded-ui`). ## Usage examples ```bash # Verification gates npm run check --prefix apps/coral-ui npm run typecheck --prefix apps/coral-ui npm test --prefix apps/coral-ui npm run build --prefix apps/coral-ui npm run test:server --prefix apps/coral-ui # Docker make coral-ui-docker-build # was: make reef-docker-build make coral-ui-docker-smoke # was: make reef-docker-smoke make coral-ui-docker-test # was: make reef-docker-test docker pull ghcr.io/withcoral/coral-ui:latest ``` Environment, for a hosted deployment: ```bash CORAL_UI_AUTH_MODE=required # was REEF_AUTH_MODE CORAL_UI_AUTH_ISSUER=https://coral.example.com CORAL_UI_PUBLIC_URL=https://coral-ui.example.com CORAL_UI_SESSION_SECRET=... ``` ## Breaking changes | Surface | Before | After | |---|---|---| | Environment | `REEF_*` (20 variables: 13 runtime, 7 CI-internal) | `CORAL_UI_*`, no fallback | | Session cookie | `reef_session` | `coral_ui_session` | | CSRF cookie | `reef_session_csrf` | `coral_ui_session_csrf` | | OAuth transaction cookie | `reef_oauth` | `coral_ui_oauth` | | Sidebar cookie | `reef_sidebar_collapsed` | `coral_ui_sidebar_collapsed` | | Published image | `ghcr.io/withcoral/reef` | `ghcr.io/withcoral/coral-ui` | | Make targets | `make reef-docker-*` | `make coral-ui-docker-*` | | CI job names | `Reef checks`, `Reef image` | `Coral UI checks`, `Coral UI image` | Cookie renames sign out existing sessions on deploy. Three items need action outside this pull request: 1. **Environments must be updated in the same step as the upgrade.** A deployment left on `REEF_AUTH_MODE=required` fails at startup rather than serving traffic — `server.js` forces `NODE_ENV=production`, which makes an unset `CORAL_UI_AUTH_MODE` throw, and the container entrypoint requires the variable outright. The failure mode is an outage, not an unauthenticated console. 2. **The GHCR package is created private on first publish.** Nothing in CI sets visibility, and the old package's setting does not carry over, so `ghcr.io/withcoral/coral-ui` must be made public before external pulls work. The old `reef` package keeps its tags and is not deleted. The publish workflow's "resolve existing immutable version" step handles the resulting `HTTP 404` explicitly, so the first run builds instead of failing. 3. **Branch protection may name the old required checks.** The job IDs and display names changed. The aggregate `validate` job is documented in the workflow as the single required status check, which should contain this, but branch protection lives outside the repo and is worth confirming before merge. ## Review notes This is 653 files, far past the usual size guidance. It is a rename and cannot be split without leaving intermediate commits that do not build — the directory move, import paths, and CI path filters have to land together. The diff breaks down as 567 byte-identical renames, 53 renames that also carry content edits, 23 modified files, and 5 add/delete pairs that are renames git scored below its similarity threshold. The 567 can be scrolled past; the other 81 are the reviewable surface. Worth reading rather than scrolling: - `docker/coral-ui-publish.test.mjs` and `docker/coral-ui-image.test.mjs` — these assert on literal workflow and Dockerfile content, including regex-escaped paths. They are what caught the mechanical sweep over-renaming assertions whose targets were meant to keep their names. - `.github/workflows/validate.yml` — the `paths:` filters and the aggregate gate. - `apps/coral-ui/app/auth/` — the cookie and environment renames. Verified: `make rust-checks` (fmt, clippy, 2585 tests, doc), Coral UI check / typecheck / 385 tests / build / 7 server smoke tests, desktop 8 + 34 tests, and the 12 Docker contract tests. Also confirmed the renamed Make targets resolve against files that exist, both renamed shell scripts pass `sh -n`, and every workflow diff is line-for-line symmetric.

🤖 I have created a release *beep* *boop* --- ## [0.13.0](v0.12.0...v0.13.0) (2026-08-17) ### ⚠ BREAKING CHANGES * **coral-ui:** rename Reef to Coral UI ([#2183](#2183)) ### Code Refactoring * **coral-ui:** rename Reef to Coral UI ([#2183](#2183)) ([554bc17](554bc17)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). --------- Co-authored-by: coral-release-bot[bot] <269256696+coral-release-bot[bot]@users.noreply.github.com> Co-authored-by: release-please[bot] <release-please[bot]@users.noreply.github.com>

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Aug 17, 2026

This comparison is taking too long to generate.

Uh oh!