Revisaur

Adds GitHub Enterprise Server (GHES) support by deriving the REST/GraphQL base URLs from the repository origin instead of hard-coding `api.github.com`. The change introduces `RepoUrl::github_api_url()` / `github_graphql_url()` plus a `scheme_ssh_as_https()` helper, a new `GitHub::from_repo_url` constructor that stores the derived REST base URL on `Remote`, and rewrites the GraphQL endpoint helper to switch between `/graphql` (dotcom) and `/api/graphql` (GHES). Tests cover dotcom, HTTPS GHES, GHES with a port, and SSH GHES origins, and the docs are updated. Overall the direction is sound, but a few concerns are worth addressing before merge: `RepoUrl::github_graphql_url` is dead code, the GraphQL helper relies on a brittle `host_str() == "api.github.com"` check that is implicitly coupled to `github_api_url`'s rewrite, and SSH origins with an explicit port silently carry the SSH port over to HTTPS.

Routine release PR for release-plz v0.3.159 generated by the release-plz bot. Bumps the package version in crates/release_plz/Cargo.toml from 0.3.158 to 0.3.159, updates the corresponding entry in Cargo.lock, and adds a CHANGELOG.md entry noting update Cargo.lock dependencies. The changes are consistent across all three files and look correct. No functional code changes.

Adds a small UsageBanner between the header and the features grid that links to the GitHub dependents page of release-plz/action. The change is small and self-contained, but a few things are worth considering:

- The text Used by 1000+ projects is hardcoded and will drift over time.
- The link points only to the action repository's dependents, which excludes crate users of release-plz/release-plz itself.
- The external link does not open in a new tab and uses inline styles instead of the existing CSS module pattern used elsewhere in the file.

## PR Review: Source-dir fallback for `git_only` mode

This PR addresses [issue #2595](https://github.com/release-plz/release-plz/issues/2595) by adding a fallback path so monorepos whose `cargo package` cannot resolve internal path dependencies are still releasable in `git_only` mode. It does three logically distinct things:

1. Includes `publish = false` packages in `release_packages` (`release.rs` + new `Project::releasable_packages`).
2. Falls back to reading package metadata from the worktree source when `run_cargo_package` fails (`next_ver.rs`).
3. Adds a source-directory comparison path in `package_compare.rs` that uses `git ls-files` and ignores known artifacts.

The direction is sensible and the new code is well-commented and tested. However there are a few concerns:

- **Filter is too broad** (`release.rs`): the filter `!input.is_publish_enabled(&p.name)` doesn't actually check `git_only` mode, so any `publish = false` package is treated as releasable. This can change behavior for users who simply have private internal crates and don't use `git_only` at all.
- **Asymmetric source/tarball comparison** (`package_compare.rs`): the source-dir branch only inspects `registry_package` for `Cargo.toml.orig`. If the local side is still a packaged tarball under `target/package/...`, `git ls-files` there will return an empty (or wrong) list, producing a spurious "different" result.
- Several **silent error/edge-case skips** in `are_source_dirs_equal` (`unwrap_or(false)` on the `Cargo.toml` compare, mismatched-symlink skip, redundant `!exists` skip).
- Minor: `releasable_packages` does an O(n·m) `Vec::contains` lookup; `is_comparable_source_file` uses `file_name()` which silently filters nested files of those names.
- Tests are useful but don't exercise the realistic case of two different worktrees, and one test name is misleading (it only verifies untracked files are ignored, not that tracked artifacts are filtered).

Nothing blocking on its own, but I'd want the broad publish-disabled filter and the asymmetric local-vs-registry comparison addressed before merge.

Small, focused fix that ensures release PR commit messages end with a trailing newline by introducing a commit_message_from_title helper and applying it consistently at all three call sites (create_pr, force_push, github_force_push). A unit test is included for the helper. The change is straightforward and well-scoped.

Minor observations:
- The helper unconditionally appends \n, so if a title ever already ends with a newline it would produce \n\n. PR titles realistically never contain newlines, so this is unlikely to matter in practice.
- The diff doesn't show github_create_release_branch's signature; if its parameter is still named title (or similar), it would now be slightly misleading since callers pass a full commit message.

Documentation-only update to website/docs/github/security.md. Bumps the pinned release-plz/action example from v0.5.50 to v0.5.128 (commit SHA updated accordingly) and adds a :::tip admonition recommending Renovate or Dependabot for keeping pinned GitHub Action commits current.

The change is small, low risk, and aligned with the surrounding guidance about pinning actions by full commit SHA. Both Renovate and Dependabot do support updating SHA-pinned actions when a comment like # v0.5.128 is present, so the recommendation is accurate.

Adds a `post_update_commands` workspace config option that runs shell commands in the temporary project root after `update()` completes but before the release PR is created. The change touches the JSON schema, the `Workspace` config (with `#[serde(default)]`), the `release_pr` CLI args, the `ReleasePrRequest` builder, the core `release_pr` flow, the website docs, and adds unit tests for both deserialization and the new `run_post_update_commands` helper.

Overall the wiring is consistent and the feature is well-scoped (only runs when there are actual updates). Main concerns:
- One of the new tests uses `touch` which is not available under `cmd /C` on Windows, so it will fail on Windows even though `cfg!(windows)` is honored elsewhere.
- `run_post_update_commands` uses the synchronous `std::process::Command` from inside the `async fn release_pr`, blocking the tokio worker for the duration of potentially long commands like `cargo fetch`.
- Stderr is silently discarded on success and stdout is only logged at `debug` level, which makes failures hard to diagnose for users running with default log levels.
- The docs say commands run in 'the project root directory', but they actually run in the temporary working copy (`tmp_project_root`). Worth clarifying so users don't expect side effects in their real checkout.

Clean addition of a `semver_check_features` config option that maps to `cargo-semver-checks` `--only-explicit-features` / `--features=...` flags.

The wiring is consistent: it follows the same `Option<Vec<String>>` + `merge` + `unwrap_or_default()` pattern used by `publish_features`, the schema and website docs are updated, and the call site in `updater.rs` is already gated by the existing `should_run_semver_check` check so features only apply when the semver check actually runs.

Minor suggestions:
- The inline doc comment (which becomes the JSON schema `description`) doesn't document the empty/`None` behavior the way `website/docs/config.md` does.
- No tests cover the new branch in `run_semver_check` that builds the `--only-explicit-features` / `--features` arguments.
- Subjective: the command is now built with a `mut cmd` variable rather than the previous chained-builder style; a small refactor could keep the chain.

## Summary

Replaces the static `release-plz-in-the-wild.md` with an `.mdx` page that renders a `FamousProjects` React component, adds a `ProjectsCounter` block on the homepage, and ships a `fetch-famous-projects.ts` script intended to populate the underlying JSON.

## Main concerns

- **Data is hand-curated, not generated.** The committed `famous-projects.json` uses round-number star counts (e.g. `27000`, `10000`, `5000`) and short names like `SurrealDB`, while the new fetch script writes `repo.full_name` (`surrealdb/surrealdb`) and real `stargazers_count` values. The two artifacts are inconsistent, and re-running the script would overwrite the curated data with a different shape. This defeats the stated purpose of "sorted by stars".
- **The fetch script is never wired into the build.** A new `fetch-famous-projects` npm script is added, but nothing in `build`, `prebuild`, or CI calls it, so the data will go stale immediately. Same problem for `ProjectsCounter`, which hardcodes `1,500+` with a comment that it must be updated manually.
- **Rate-limit risk in the fetch script.** Inside each search page the script makes one `/repos/{full_name}` call per result with no delay, only sleeping between pages. With 100 results per page that is 100 back-to-back authenticated calls, which can trip the secondary rate limit. The 1000-result cap of the search API also means "top 50 by stars" is a top-50 of an arbitrary 1000 subset, not globally.
- **Polish.** Several new files have no trailing newline (`.mdx`, both `index.tsx`, both `styles.module.css`, the JSON, and the `.ts` script), the `⭐` emoji has no accessible label, and `formatStars` produces `27.0k` rather than `27k`.

Overall, I'd recommend either (a) generating the JSON from the script and running it in CI/prebuild, or (b) keeping a curated list but dropping the script and the misleading "sorted by stars" framing.

Adds a branch Tera variable (set to the default branch) to the PR title template, with corresponding test updates.

**Concerns**
- The variable name branch is ambiguous: it is sourced from default_branch, but a user reading docs/templates could reasonably assume it is the release/source branch. Consider renaming to default_branch (or documenting clearly) to avoid surprise once the head branch is also exposed.
- The branch variable is added only to the pr_title context, not to pr_body. If the intent is to expose the branch in templates, the body template likely needs it too for consistency.
- No user-facing documentation (e.g. configuration reference for pr_name) is updated to describe the new template variable.

Adds included_authors and included_assignees filters and changes how author/assignee filters merge between global and repository scope. The implementation in loadConfig.ts, github.ts, and the type changes are coherent and well-tested for config merging. Main concern: this also changes the semantics of the existing skipped_authors from override to merge, which is a backwards-incompatible behavior change that callers cannot opt out of (a repo can no longer narrow or disable the global default skip list). Also worth adding unit tests for the new matchesPullRequestFilters runtime logic, since the added test only covers config merging.

Adds opt-in Docker sandboxing for the reviewer subprocess (`reviewer.sandbox = "docker"` + `sandbox_image`), introduces a tight container env (`KIRO_API_KEY`, `HOME` only), drops capabilities, sets `--read-only`, tmpfs `/tmp` and `HOME`, applies CPU/memory/pids limits, and adds an `install-kiro-cli` action input for skipping the host install when the image already contains the CLI.

Overall the design is sound and the security defaults are reasonable. Main concerns:

- The schema accepts `sandbox = "docker"` for both `kiro` **and** `codex`, but only `src/reviewers/kiro.ts` honors it, which can produce a silently-unsandboxed `codex` reviewer.
- The Docker test relies on `expect.arrayContaining(...)` and does not assert the security-critical flags (`--read-only`, `--user`, `--tmpfs`, `--pids-limit`, `--memory`, `--cpus`, `--workdir`, `--network`), so regressions in hardening would not be caught.
- A few smaller nits around redundant flags, environment forwarding for non-default Docker setups, and a README inaccuracy.

## Showcase landing page

Adds a fallback to a built-in `showcaseData` when `site.json` is missing, plus a marketing hero (`section.showcase-hero`) shown only in showcase mode. The fallback logic is sound: `loadSiteData` only swaps to `showcaseData` on `ENOENT` and re-throws other errors, and `isShowcase` correctly relies on reference equality so a real `site.json` with similar contents would still render normally.

A few non-blocking observations on accessibility, CSS specificity, and responsive sizing — see inline comments.

Adds bookmarkable URL state for repository, author, and assignee filters. The implementation is solid: it handles both `?key=a,b` and `?key=a&key=b` forms, validates IDs against available options, falls back to defaults for invalid input, and uses an `applyingUrlFilters` flag to avoid feedback loops while seeding the pickers from the URL on load.

A few things to consider:

- `event.detail.optionIds` is dereferenced before checking that `event.detail` itself exists.
- The new `selectFilterOptions` parameter `optionIds` shadows the outer `optionIds` helper, which makes the call site at `new Set(optionIds(...))` harder to read.
- `parseFilterParam` accepts both `__all` and `all`, but the README only documents `__all`.
- `applyUrlFilters` re-runs `updateAuthorFilterOptions` / `updateAssigneeFilterOptions` and ends up calling `applyReviewFilters` several times because the dispatched `repos:selected` / `author:selected` / `assignee:selected` handlers already do that work.
- `history.replaceState` means filter changes don't create back/forward entries; if that's a deliberate choice it's fine, just worth confirming.

Adds support for showing multiple cached reviews per PR. The backend (`src/cli/index.ts`) now selects every cached review whose `(provider, repoId, number)` matches a PR seen in the current run, and the UI (`src/site/components/ReviewApp.astro`) groups those reviews, sorts them by `reviewedAt`, and exposes a commit-picker `<select>` that toggles `hidden` on per-variant header/body fragments.

The approach is sound and the per-variant DOM toggling is consistent across the meta block and body (both keyed by `data-review-variant`). A few concerns worth addressing:

- No pruning of `state.reviews`, so the cache (and the per-PR dropdown) can grow without bound across runs.
- Each variant is fully inlined into HTML (full diff + comments JSON, URI-encoded) at SSR time, which can balloon page weight for PRs with many revisions.
- Minor: a quadratic `[...arr, item]` spread inside a `reduce`.