chore(release): record the published-metadata corrections as a changeset (META-325)

[qmarcelle]

Closes the composition gap in META-325's acceptance: every intended public package change is mapped to an explicit Changeset or an explicit documented no-release-impact decision.

What was missing

Ten commits touched packages/ since the 0.4.4 publish. Six map cleanly to existing changesets. Two need none — the union-denominator tests and negative fixtures are not in files, and the @types/node bump is a devDependency that does not ship. One was uncovered:

Change	Landed in	Changeset
repository.url + directory, bugs.url	repository reconstruction	none
homepage to the bare canonical host	reconstruction + OSS polish	none
author to workspacejson contributors	OSS polish	none
agents-audit and aaif keywords removed	reconstruction + OSS polish	none
@workspacejson/rules description rewritten	OSS polish	none
Both package READMEs corrected	OSS polish	none
Both changelogs — 0.4.4 recorded as unreleased	OSS polish	none

All of it ships. README.md and CHANGELOG.md are both listed in files, so they are published bytes, and the manifest fields are part of the published artifact even though no runtime behavior moves. These corrections reached consumers with no release note explaining why the npm page changed.

What this adds

One changeset, patch on both packages. It does not move the version — the fixed group is taking a minor this release for reasons recorded in the accompanying changesets — and it is not meant to. The point is that the changelog records what shipped.

Written without tracker identifiers: changesets become shipped changelog entries, and check:docs fails on internal identifiers in public prose.

Verification

check:docs passes. changeset status still resolves the fixed group to minor.

Not in this PR

No Linear release wiring. Live release mutations are disabled for the 0.5.0 cut per the META-354 pilot verdict; the release will be backfilled from the verified version, commit and registry receipt after publication.

Summary by Sourcery

Enhancements:

• Record the published metadata, README, and changelog corrections for both packages as explicit patch changes.

[greptile-apps]

No reviewable files after applying ignore patterns.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sourcery-ai]

Reviewer's Guide

Adds a retrospective changeset documenting previously shipped metadata corrections for the @workspacejson/rules and @workspacejson/spec packages, ensuring the release notes and changelog accurately reflect the published tarball contents without changing runtime behavior or versioning semantics.

File-Level Changes

Change	Details	Files
Introduce a patch-level changeset capturing the previously shipped package metadata, README, and changelog corrections for both workspacejson packages.	Add a new changeset declaring patch releases for @workspacejson/rules and @workspacejson/spec tied to already-published metadata corrections. Document repository, bugs, homepage, author, keywords, description, README, and changelog fixes as a formal release note. Clarify that the changeset is metadata-only, with no impact on runtime, types, schema, or exports, and that it rides along with an existing minor release group.	.changeset/plenty-cooks-repair.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sourcery-ai]

Hey - I've left some high level feedback:

• The changeset description is quite long and mixes implementation details with historical context; consider tightening it to a shorter summary focused on what changed and why from a consumer’s perspective.
• The explanation section inside the changeset (**Why a metadata-only change gets a changeset at all.**) reads more like design rationale; you might move this kind of reasoning to an ADR or internal doc and keep the changeset itself more succinct.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The changeset description is quite long and mixes implementation details with historical context; consider tightening it to a shorter summary focused on what changed and why from a consumer’s perspective.
- The explanation section inside the changeset (`**Why a metadata-only change gets a changeset at all.**`) reads more like design rationale; you might move this kind of reasoning to an ADR or internal doc and keep the changeset itself more succinct.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}