actionlint 1.7.12 does not yet understand GitHub's self-repository
`uses: $/...` syntax (rhysd/actionlint#711) and reports it as an invalid
action format, so the previous commit turned the actionlint job red.
Add `.github/actionlint.yaml` that ignores only that message, so zizmor's
`self-repository` audit and actionlint can both pass. Drop the ignore once
actionlint supports the syntax.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Replace `uses: ./.github/actions/repomix` with `uses: $/.github/actions/repomix`
in pack-repository.yml and test-action.yml.
Why: zizmor 1.30 (pulled in by zizmor-action v0.6.3, Renovate #1846) adds
the `self-repository` audit, which flags the workspace-relative form. The
`$/` form resolves the action from the workflow's own ref instead of the
checked-out filesystem, and GitHub treats it as pinned, so it also keeps
the repo compatible with a fully-pinned actions policy.
Behavior is unchanged: both workflows call the action right after checking
out the same ref.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
learned(npm-publish): `lint` runs biome and oxlint in write mode, so the old single job published the auto-fixed tree rather than the commit provenance points at; with build packing its own checkout, a silent auto-fix would make tested and published code differ
decision(npm-publish): mirror ci.yml with `git diff --exit-code` after lint so check, build, and provenance all refer to the committed source
learned(npm-ci): `prepare` runs on `npm ci` as well as `npm pack`, and rimraf/tsc are dev dependencies, so the header comment now says which dev-only code runs rather than claiming none does
intent(npm-publish): shrink the code that can reach the package contents before publish, not only the code that can mint a publish token
decision(npm-publish): separate check job for lint/test; build runs only npm ci and npm pack, so dev-only dependencies (vitest, linters) no longer execute where the tarball is produced
rejected(npm-publish): ignore-scripts on npm ci — only esbuild has a postinstall on linux, so it removes almost nothing and would break the build
constraint(npm-publish): publish must list check in needs; the build job no longer runs lint/test, so that edge is the only gate on them
learned(npm-pack): npm pack runs prepare (npm run build) itself, so the explicit build step was redundant and is dropped
intent(mcp-registry): address PR review — `curl -f` collapsed 5xx responses and transport errors into the same branch as a genuine 404
learned(mcp-registry): that miscall defeats the re-run recovery path this check exists for, since it sends the workflow on to republish an immutable version the registry then rejects
decision(mcp-registry): read the HTTP status explicitly, treat a non-zero curl exit as a transport failure, and fail on anything that is neither 200 nor 404
constraint(mcp-registry): verified all three branches against the live registry — 200 for a published server, 404 for io.github.yamadashy/repomix@1.18.0, non-zero exit for an unresolvable host
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(supply-chain): address PR review — the publish job's whole premise is that it trusts nothing but a tarball, yet the artifact name was all that tied that tarball to the build job
decision(supply-chain): record the sha256 in the build job and check it after download; job outputs travel over the Actions control plane rather than the artifact store, so the hand-off verifies itself
learned(sha256sum): `--strict` also fails a malformed line, so a lost or empty job output fails closed instead of checking nothing — verified against GNU coreutils, including the empty-digest case
decision(npm-version): assert npm >= 11.5.1 in the publish job, since the Node version comes from .tool-versions at runtime and a comment pinning the bundled pairing would drift silently
decision(least-privilege): drop `contents: read` from the publish job — it never checks out, and a same-run artifact download authenticates with ACTIONS_RUNTIME_TOKEN
constraint(tool-versions): parse with awk on the second field, so a fallback version list or a trailing comment cannot produce a multi-line GITHUB_OUTPUT value
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
learned(actionlint): actionlint runs shellcheck over run: blocks, and SC2129 flags consecutive appends to the same file
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(supply-chain): a security review of the release workflows found that `id-token: write` puts the OIDC minting credentials in the job environment, so any code running there can exchange them for an npm publish token
learned(supply-chain): the job held that permission while running `npm ci` (~400 packages with lifecycle scripts), `npm install -g npm@latest`, the test suite and the build — one compromised dev dependency could have published a malicious repomix release carrying valid provenance
decision(supply-chain): split into a build job with no id-token that packs a tarball, and a publish job that holds the credential and runs nothing but `npm publish` on that artifact
constraint(npm-provenance): verified in the npm CLI source that provenance is derived from GitHub Actions env vars rather than a .git directory, so the publish job needs no checkout, and that `npm publish <tgz>` streams the tarball verbatim so package contents are unchanged
constraint(npm-trusted-publishing): the npm-side config matches on workflow filename, not job name, so keeping both jobs in npm-publish.yml needs no change to the trusted publisher
decision(npm-version): dropped `npm install -g npm@latest` — Node 24.15.0 bundles npm 11.12.1, past the 11.5.1 trusted-publishing floor, and a floating global install in the credentialed job was itself a fetch worth removing
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(mcp-registry): address PR review before the first publish, since server.json values are immutable once a version lands on the registry
decision(server-json): mark `--mcp` `isRequired: true` — a client rendering only the required arguments would otherwise emit bare `npx repomix`, which runs the packer and writes repomix-output.xml instead of speaking MCP over stdio
decision(server-json): add `runtimeArguments` with `-y`, matching the `npx -y repomix --mcp` in every mcp-server.md; without it npx can stall on its install prompt on a cold cache, which over stdio is indistinguishable from a server that never starts
learned(mcp-registry): confirmed against the live registry that npm-based entries express this as a positional `-y` in `runtimeArguments`, and that `mcp-publisher validate` accepts the new shape
learned(mcp-registry): verified the hand-written verify URL by hand against a real entry — `/v0.1/servers/{encodedName}/versions/{version}` returns the nested `.server.version` the workflow asserts — so the first real publish is no longer the first exercise of that path
decision(mcp-registry): retry the `npm view mcpName` check 5x10s like the registry verify step, since it runs right after npm-publish.yml and a miss there is more likely propagation lag than a genuinely absent version
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(mcp-registry): address PR review — the flag extractor only matched `.option()`, so it tracked how `--mcp` is declared rather than whether it exists
decision(cli-flags): match `new Option()` too, which brings the five addOption-declared flags (`--quiet`, `--output-file-path-style`, ...) into the set and decouples the assertion from the declaration style
learned(mcp-registry): skipping the publish for an existing version made a metadata-only edit a silent no-op — the run goes green with nothing republished, since registry versions are immutable
decision(mcp-registry): spell that out in the comment so a green run is not misread as "the description fix shipped"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(mcp-registry): address PR review — after a successful publish the workflow could not be re-run, so a verify that exhausted its retries left a permanently red run
decision(mcp-registry): probe the registry before publishing and skip the publish when the version is already there, which turns a re-run into a plain re-verify
decision(mcp-registry): assert every packageArguments value against the flags cliRun.ts declares, since that field must agree with the CLI rather than with package.json — a renamed flag would otherwise ship a server that never enters MCP mode
constraint(mcp-registry): both new assertions were checked by breaking server.json on purpose (renamed flag, mismatched name) and confirming the suite fails
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(mcp-registry): address PR review — a mcpName/server.json mismatch was only detected at publish time, after the npm version was already published and therefore immutable
decision(mcp-registry): assert the pairing in a unit test so it fails on the PR that introduces it, per the CLAUDE.md guideline to cover new features with tests
decision(mcp-registry): retry the post-publish verify instead of failing on the first miss — `mcp-publisher publish` is not repeatable, so read-after-write lag would leave a red run with no clean recovery
learned(npm-cli): `npm view <pkg> <field>` exits 0 with empty output when the field is absent and non-zero when the version is missing, so `2>/dev/null || true` masked real errors without covering any case the empty-check misses
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(mcp-registry): address PR review — dry-run could only run after the npm publish, so it could not sanity-check a server.json edit at PR time
decision(mcp-registry): always run `mcp-publisher validate` and gate the npm ownership check on !dry-run, so dry-run is a pure server.json check
learned(npm-config): min-release-age filters install-time version resolution, not `npm view` metadata reads — verified that `npm view <pkg>@<0-day-old-version>` succeeds under min-release-age=7
decision(npm-config): set npm_config_min_release_age=0 on the check anyway, since it reads a just-published version and the runner's bundled npm may differ from the local one
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
learned(mcp-registry): the search endpoint is fuzzy and `jq .` only pretty-printed it, so the step passed even when nothing was published
learned(mcp-registry): the version endpoint needs the server name percent-encoded; an unencoded slash returns 404 even for a live server
decision(mcp-registry): query /v0.1/servers/{name}/versions/{version} and assert with `jq -e` so a failed publish fails the job
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
intent(mcp-registry): list Repomix on the official MCP Registry (registry.modelcontextprotocol.io) so MCP clients can discover it
constraint(mcp-registry): ownership of the npm package is verified via `mcpName` in the published package.json, so the first registry publish must wait for the next npm release
constraint(mcp-registry): description is capped at 100 characters by the registry API; validated with `mcp-publisher validate` against production
decision(mcp-registry): separate workflow_dispatch workflow instead of a step in npm-publish, to avoid racing npm propagation and to keep a registry failure from marking the npm publish red
decision(mcp-registry): server.json version is injected from package.json at publish time so only one version needs bumping
decision(mcp-registry): mcp-publisher binary pinned to v1.8.1 with sha256 verification rather than the `latest` download the official example uses
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
intent(claude-review): consecutive pushes ran duplicate full reviews in parallel, and PRs opened as draft then marked ready were never auto-reviewed until the next push
Editorial pass on the already-published notes: drop an unverifiable
"most real projects" claim, clarify why outputPatterns matters for
remote repos, add the MCP docs link, split the Markdown-fix PR numbers
onto their bullets, and reword the processors default-deny line.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
why: The grouping comment listed only root/browser/website/scripts/
actions, but the config also groups dockerfile and nix updates, each
split into major and non-major groups.
context: Addresses CodeRabbit review feedback on #1736.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
why: Default prHourlyLimit=2 drip-feeds grouped update PRs two at a
time, requiring repeated merge rounds to drain a single Renovate run.
context: Updates are already grouped per area (root/browser/website/
scripts/actions), so unlimited concurrent PRs stays at a handful.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The scoped `npm_config_min_release_age: 0` from the previous commit does not
resolve the conflict: npm's git-dep preparation spawns a child `npm install`
that re-reads repomix's .npmrc (min-release-age=7) and adds its own --before,
which cannot coexist — and 0 still counts as "provided". CI confirmed the
website server jobs still fail with it.
decision(ci-min-release-age): keep the npm@11.4.0 downgrade (the verified-green fix, matching Dockerfile) and restore the zizmor adhoc-packages exemption
learned(min-release-age): npm_config_min_release_age=0 does not fix the git-dep --before conflict — the value counts as provided and the prep child re-reads .npmrc; only an npm that predates the flag avoids it
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Follow-up to PR review from Claude Code Review and CodeRabbit.
intent(review): reviewers flagged a fragile selector, a broader-than-necessary CI workaround, and brand-orange text spots the Lighthouse run never reached
decision(ci-min-release-age): replace the global npm@11.4.0 downgrade with a scoped `npm_config_min_release_age: 0` env on the website/server install, matching npm-publish.yml — keeps npm 12 and drops the need for the zizmor adhoc-packages exemption
decision(shiki-selector): match the comment token case-insensitively (`[style*="#6a737d" i]`) so a future Shiki casing change cannot silently reintroduce the contrast failure; current build emits uppercase and already matched (verified against docs:build + Lighthouse 100)
decision(brand-text): switch the remaining brand-orange *text* colors in the Try It tool (cli banner icon/copy, error copy/guide links, active result tab, reset button) to --brand-text; decorative border/fill oranges are left bright per the PR intent
learned(min-release-age): the repo already scopes `npm_config_min_release_age: 0` per-step in npm-publish.yml, a cleaner precedent than a self-downgrade
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The website server CI jobs fail at `npm ci` because website/server depends
on `github:yamadashy/repomix#main` (a git dependency). npm 12.0.1 prepares
git deps using `--before`, which conflicts with the repo's `min-release-age`
config, aborting the install.
intent(ci-website): unblock CI Website, which has been red on main since the npm 12.0.1 bump for every website change
decision(npm-version): downgrade to npm 11.4.0 only for the website/server install, mirroring the existing Dockerfile workaround, so npm 12 and min-release-age stay in effect for the root build
constraint(git-dep): website/server pulls repomix via github:yamadashy/repomix#main, so its npm ci always triggers the conflicting git-dep preparation
learned(npm-12): min-release-age is implemented via --before internally, so it cannot coexist with the --before npm adds when preparing a git dependency
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
intent(renovate): widen the PR window from Saturday morning only to Saturday through Sunday evening JST so updates can be reviewed across the weekend
decision(renovate-schedule): express the window in UTC ("on saturday" + "before 1pm on sunday" = Sat 9:00 - Sun 22:00 JST) instead of adding timezone: Asia/Tokyo, keeping the config locale-neutral for a global OSS project
learned(renovate-schedule): schedule only gates when the hosted Renovate app may create PRs; runs still happen on Mend's own crawl cadence within the window
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
intent(ci-lint): zizmor v0.5.7 bump (#1692) introduced the adhoc-packages audit, turning main's CI Quality red on two intentional package installs
decision(zizmor-config): file-level ignores in .github/zizmor.yml rather than inline zizmor comments — matches the existing artipacked/secrets-outside-env ignore style
constraint(repomix-action): installing repomix at a user-specified version is the action's core function, so a lockfile-based install is impossible there
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
intent(schema-update): drop the personal PAT — no new token issuance, and a long-lived PAT is a security and maintenance liability
decision(schema-token): GITHUB_TOKEN over a PAT — the main ruleset has no required status checks, so the schema PR needs no CI to be mergeable (only review + code owner approval)
rejected(schema-token): GitHub App token (create-github-app-token) — still requires issuing and storing a private key; user wants zero new credentials
constraint(actions-pr): requires pull-requests: write and the repo setting 'Allow GitHub Actions to create and approve pull requests' (enabled out-of-band)
learned(committer-token): COMMITTER_TOKEN was a leftover PAT from the removed Homebrew bump workflow (needed cross-repo push); reused here by inertia and expired ~2026-06-05, silently breaking schema delivery since then
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The repomix formula in homebrew-core is on Homebrew's autobump list, so
BrewTestBot opens the version-bump PRs automatically. The `homebrew.yml`
workflow runs `brew bump --open-pr` on each release but only prints
"Formula is autobumped so will have bump PRs opened by BrewTestBot every
~3 hours" and exits without opening a PR — every homebrew-core repomix
bump (v1.8.0 onward) is authored by @BrewTestBot, not this workflow.
Remove the no-op workflow and its zizmor ignore entry. The COMMITTER_TOKEN
secret stays as it is still used by schema-update.yml.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
renovate[bot]