[rtorcato-bot]

🤖 Automated — @Woz 🐝 (Buzz agent) via ai-loop.

What changed

• scripts/sync-changelog.mjs is replaced with the canonical repo-tooling script. I ran repo-tooling copy docusaurus-sync-changelog with v3.12.1, the version on main, and the result was blob ed2bcaf, identical to browser-common's copy. The script builds the page from the GitHub Releases API and falls back to CHANGELOG.md when the API can't be reached.
• Two edits on top of canonical, both needed for Changesets (please check these):
  • A Changesets release body starts at ### Patch Changes and has no package or version heading. Emitted verbatim, as canonical does, the page would be a run of unlabelled "Minor Changes" blocks. Bodies that don't open with a #/## heading now get ## <release name> (<date>), e.g. ## @rtorcato/react-common@0.3.0 (2026-07-15). semantic-release bodies already open with their own heading, so they're left untouched, and the change is safe to upstream.
  • I removed "generated by semantic-release" from the frontmatter description and the footer, because it isn't true here.
• CHANGELOG.md (the GitLab-era fossil, step 3): I kept it rather than deleting it. The footer links to it as "anything older than the first GitHub Release", and it's the offline fallback. It now opens with a note pointing at GitHub Releases, and says the 1.0.0 entry is pre-migration history from gitlab.com/rtorcato/common-react, unrelated to the npm versions. Deleting it is the owner's call.
• .github/workflows/docs.yml (step 4) now also triggers on release: types: [published]. RELEASE_TOKEN is a PAT, so releases created by the changesets action do fire the event. A release run's ref is the tag, though, and the github-pages environment only allows main (Stinger, fix round 1). So on a release event only a new redispatch job runs: with actions: write, it calls gh workflow run docs.yml --ref <default branch>. GITHUB_TOKEN may trigger workflow_dispatch. build and deploy skip on the release event and run in the dispatched run on main. That avoids widening the Pages deployment policy, and it doesn't touch release.yml (chore(deps): upgrade repo-tooling to v5 and move the release job into release.yml #192). The Build docs step also gets GITHUB_TOKEN to lift the 60/hr API limit.
  • When two packages publish at once, the pages concurrency group can drop a pending duplicate. At least one dispatched build still runs after the releases are published.

Verification

• Online: pnpm --filter @rtorcato/react-common-docs build passes. build/docs/changelog/index.html lists all 5 real releases (react-common 0.2.0/0.3.0, shadcn-ui 1.6.0/1.7.0/1.7.1), newest first, each with a package@version heading, and the footer links to Releases.
• Offline (step 3): with fetch stubbed to throw, the script logs the fallback and renders the labelled CHANGELOG.md with the "may be out of date" banner.
• Biome is clean on the script, and pnpm verify passes.

Notes

• Canonical moved out of repo-tooling in v5 (to @rtorcato/shared-docs, feat!: move the docs-site and brand scaffolds to @rtorcato/shared-docs repo-tooling#719), so the Changesets heading fix is worth upstreaming there. Otherwise the next copy will drop it.
• No changeset: this changes docs and tooling only, not a published package.

Closes #180

[rtorcato-bot]

🤖 Automated security review — @Warden 🐝 (Buzz agent) via ai-loop.

PASS — sync-changelog.mjs calls only api.github.com, using GITHUB_REPOSITORY. Release bodies go into a .md page, and with markdown.format: 'detect' those are rendered as CommonMark, not MDX, so release text can't run JSX at build time. The docs workflow's GITHUB_TOKEN is contents: read, and checkout already exposes the same token to the job. The release: published trigger runs the default branch's workflow. No dependency changes.

Before merging

Nothing.

[rtorcato-bot]

🤖 Automated review — @Stinger 🐝 (Buzz agent) via ai-loop.

Changes. The script is sound: drafts and empty bodies are filtered, results are sorted by date, the synthetic ## pkg@version (date) heading only applies when there's no heading, and it falls back to the file offline. But the new release: published trigger can't deploy. A release run's ref is the tag (refs/tags/@rtorcato/react-common@…), and the github-pages environment only allows branch main, so deploy is rejected on every release.

Before merging

• Either the owner adds a @rtorcato/* tag policy to github-pages, or drop the trigger and have release.yml run gh workflow run docs.yml --ref main after publishing. The second option overlaps #192.

[rtorcato-bot]

🤖 Automated security review — @Warden 🐝 (Buzz agent) via ai-loop.

PASS — I re-reviewed at 94be720. The new redispatch job sets job-level permissions: actions: write, which replaces the top-level set, so it gets nothing else. It runs only on release events, has no checkout, and uses a single fixed gh workflow run command. GITHUB_REPOSITORY and the default branch come in through env:, not ${{ }} in the script, so there's no injection path. The deploy stays on main under the github-pages branch policy.

Before merging

Nothing.

[rtorcato-bot]

🤖 Automated review — @Stinger 🐝 (Buzz agent) via ai-loop.

Pass for 94be720. This fixes my deploy finding. On release, only redispatch runs, and build (and so deploy) skips. A workflow_dispatch sent with GITHUB_TOKEN is one of the events GitHub still lets start a run, and it runs on main, which github-pages allows. With pages concurrency and no cancelling, two package releases at once still end in a deploy that sees both. CI green.

Before merging

Nothing.