Repository navigation
chore: release main - #1722
Merged
2 commits merged intoSep 26, 2026
Merged
chore: release main#17222 commits merged into
2 commits merged into
Conversation
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
caura-deploy-bot
Bot
force-pushed
the
release-please--branches--main
branch
from
September 26, 2026 16:39
2793713 to
d5a81cb
Compare
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
caura-deploy-bot
Bot
force-pushed
the
release-please--branches--main
branch
from
September 26, 2026 17:13
d5a81cb to
042a429
Compare
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
caura-deploy-bot
Bot
force-pushed
the
release-please--branches--main
branch
from
September 26, 2026 17:24
042a429 to
7696fc7
Compare
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
caura-deploy-bot
Bot
force-pushed
the
release-please--branches--main
branch
from
September 26, 2026 17:35
7696fc7 to
1b107d9
Compare
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
caura-deploy-bot
Bot
force-pushed
the
release-please--branches--main
branch
from
September 26, 2026 19:03
1b107d9 to
4f540eb
Compare
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
Signed-off-by: release-please[bot] <release-please[bot]@users.noreply.github.com>
caura-deploy-bot
Bot
force-pushed
the
release-please--branches--main
branch
from
September 26, 2026 19:10
4f540eb to
9d65875
Compare
Contributor
|
Claude Code Review — skipped: PR author 'caura-deploy-bot[bot]' is not a public member of the 'caura-ai' org |
release-please's JSON updater rewrote plugin/openclaw.plugin.json to bump the version, and re-serializing it moved the "$comment" that holds the legacy-name-ok marker onto a line of its own. The legacy-name ratchet reads markers per line, so the alias key read as a newly minted, unmarked legacy name, and the required check blocked this release. This puts the key and its marker back on one line, as on main, so the release changes only the version line in that file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Eldad Caura <eldad@caura.ai>
ghost
approved these changes
Sep 26, 2026
ghost
deleted the
release-please--branches--main
branch
September 26, 2026 21:42
Contributor
Author
|
🤖 Created releases: 🌻 |
caura-deploy-bot
Bot
added
autorelease: tagged
ghost
mentioned this pull request
ghost
pushed a commit
that referenced
this pull request
Sep 27, 2026
JSON has no comments, so a key's legacy-name marker can only live in a "$comment" member of the object the key opens. Kept on the key's own line, it does not survive a formatter. release-please re-serialises every JSON file it bumps and puts that member on the line below, so its release PR for plugin v2.23.3 (#1722) read as minting MEMCLAW_AGENT_ID, and the required check blocked it until a fixup commit put the marker back. The gate now joins a JSON key that is alone on its line, opening an object, to a "$comment" member directly below it, with one space. That is exactly the text of the one-line form, so both layouts read as the same line, and a release PR that only re-indents the key changes nothing. The marker still has to sit in that object's first member, directly below its key: a "$comment" further down, one without a marker, or the same layout outside a .json file does not exempt the key. The pair is one line everywhere else too. When the comment's reason names the brand as well, git grep also returns the comment on its own, which counted one alias twice in the exempt-line reports; it is now read only with its key. And the exempt-line report picks lines by git's diff, which calls only the comment line added when a marker is written below an existing key, so that key was exempted without being listed. A change to the comment now counts as a change to its key. On release-please's original #1722 commit (9d65875) the engine on main fails with "plugin/openclaw.plugin.json (1 -> 2)"; this one reports no new lines. It still lists the rewritten line under exempt lines written, which is a report, not a failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Eldad Caura <eldad@caura.ai>
ghost
pushed a commit
that referenced
this pull request
Sep 27, 2026
JSON has no comments, so a key's legacy-name marker can only live in a "$comment" member of the object the key opens. Kept on the key's own line, it does not survive a formatter. release-please re-serialises every JSON file it bumps and puts that member on the line below, so its release PR for plugin v2.23.3 (#1722) read as minting MEMCLAW_AGENT_ID, and the required check blocked it until a fixup commit put the marker back. The gate now joins a JSON key that is alone on its line, opening an object, to a "$comment" member directly below it, with one space. That is exactly the text of the one-line form, so both layouts read as the same line, and a release PR that only re-indents the key changes nothing. The marker still has to sit in that object's first member, directly below its key: a "$comment" further down, one without a marker, or the same layout outside a .json file does not exempt the key. The pair is one line everywhere else too. When the comment's reason names the brand as well, git grep also returns the comment on its own, which counted one alias twice in the exempt-line reports; it is now read only with its key. And the exempt-line report picks lines by git's diff, which calls only the comment line added when a marker is written below an existing key, so that key was exempted without being listed. A change to the comment now counts as a change to its key. On release-please's original #1722 commit (9d65875) the engine on main fails with "plugin/openclaw.plugin.json (1 -> 2)"; this one reports no new lines. It still lists the rewritten line under exempt lines written, which is a report, not a failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Eldad Caura <eldad@caura.ai>
ghost
pushed a commit
that referenced
this pull request
Sep 27, 2026
JSON has no comments, so a key's legacy-name marker can only live in a "$comment" member of the object the key opens. Kept on the key's own line, it does not survive a formatter. release-please re-serialises every JSON file it bumps and puts that member on the line below, so its release PR for plugin v2.23.3 (#1722) read as minting MEMCLAW_AGENT_ID, and the required check blocked it until a fixup commit put the marker back. The gate now joins a JSON key that is alone on its line, opening an object, to a "$comment" member directly below it that carries a marker, with one space. That is exactly the text of the one-line form, so both layouts read as the same line, and a release PR that only re-indents the key changes nothing. The marker still has to sit in that object's first member, directly below its key: a "$comment" further down, or the same layout outside a .json file, does not exempt the key. A "$comment" without a marker is not joined at all. It documents the key, and joining it would make every edit to that documentation read as a new line. The pair is one line everywhere else too. When the comment's reason names the brand as well, git grep also returns the comment on its own, which counted one alias twice in the exempt-line reports; it is now read only with its key. And the exempt-line report picks lines by git's diff, which calls only the comment line added when a marker is written below an existing key, so that key was exempted without being listed. A change to the comment now counts as a change to its key. On release-please's original #1722 commit (9d65875) the engine on main fails with "plugin/openclaw.plugin.json (1 -> 2)"; this one reports no new lines. It still lists the rewritten line under exempt lines written, which is a report, not a failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Eldad Caura <eldad@caura.ai>
ghost
pushed a commit
that referenced
this pull request
Sep 27, 2026
JSON has no comments, so a key's legacy-name marker can only live in a "$comment" member of the object the key opens. Kept on the key's own line, it does not survive a formatter. release-please re-serialises every JSON file it bumps and puts that member on the line below, so its release PR for plugin v2.23.3 (#1722) read as minting MEMCLAW_AGENT_ID, and the required check blocked it until a fixup commit put the marker back. The gate now joins a JSON key that is alone on its line, opening an object, to a "$comment" member directly below it that carries a marker, with one space. That is exactly the text of the one-line form, so both layouts read as the same line, and a release PR that only re-indents the key changes nothing. The marker still has to sit in that object's first member, directly below its key: a "$comment" further down, or the same layout outside a .json file, does not exempt the key. A "$comment" without a marker is not joined at all. It documents the key, and joining it would make every edit to that documentation read as a new line. The pair is one line everywhere else too. When the comment's reason names the brand as well, git grep also returns the comment on its own, which counted one alias twice in the exempt-line reports; it is now read only with its key. And the exempt-line report picks lines by git's diff, which calls only the comment line added when a marker is written below an existing key, so that key was exempted without being listed. A change to the comment now counts as a change to its key. On release-please's original #1722 commit (9d65875) the engine on main fails with "plugin/openclaw.plugin.json (1 -> 2)"; this one reports no new lines. It still lists the rewritten line under exempt lines written, which is a report, not a failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Eldad Caura <eldad@caura.ai>
eldad-caura-ai
added a commit
that referenced
this pull request
Sep 30, 2026
JSON has no comments, so a key's legacy-name marker can only live in a "$comment" member of the object the key opens. Kept on the key's own line, it does not survive a formatter. release-please re-serialises every JSON file it bumps and puts that member on the line below, so its release PR for plugin v2.23.3 (#1722) read as minting MEMCLAW_AGENT_ID, and the required check blocked it until a fixup commit put the marker back. The gate now joins a JSON key that is alone on its line, opening an object, to a "$comment" member directly below it that carries a marker, with one space. That is exactly the text of the one-line form, so both layouts read as the same line, and a release PR that only re-indents the key changes nothing. The marker still has to sit in that object's first member, directly below its key: a "$comment" further down, or the same layout outside a .json file, does not exempt the key. A "$comment" without a marker is not joined at all. It documents the key, and joining it would make every edit to that documentation read as a new line. The pair is one line everywhere else too. When the comment's reason names the brand as well, git grep also returns the comment on its own, which counted one alias twice in the exempt-line reports; it is now read only with its key. And the exempt-line report picks lines by git's diff, which calls only the comment line added when a marker is written below an existing key, so that key was exempted without being listed. A change to the comment now counts as a change to its key. On release-please's original #1722 commit (9d65875) the engine on main fails with "plugin/openclaw.plugin.json (1 -> 2)"; this one reports no new lines. It still lists the rewritten line under exempt lines written, which is a report, not a failure. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Eldad Caura <eldad@caura.ai>
eldad-caura-ai
added a commit
that referenced
this pull request
Sep 30, 2026
…1732) ## What broke The release PR for plugin v2.23.3 (#1722) failed the required **Legacy-name ratchet** check, and a fixup commit was needed before it could ship. - **Why:** JSON has no comments, so the `legacy-name-ok` marker for the `MEMCLAW_AGENT_ID` alias lives in a `"$comment"` member of the object the key opens. On main that member shares the key's line. release-please re-serialises every JSON file it bumps, which put the member on the line below. - **What the ratchet saw:** it reads markers per line, so the key read as a newly minted, unmarked legacy name, and the marked line read as removed. Nothing had changed except the layout. Any JSON formatter does the same, so this would come back at every plugin release. ## The fix For JSON files, the engine now joins two lines, with one space: - a key that is alone on its line and opens an object, and - a `"$comment"` member directly below it that carries one of this tool's markers. That joined text is exactly the one-line form, so both layouts read as the same line. The key's marker has to be in its object's first member, directly below the key. A `"$comment"` further down, or the same layout in a file that isn't `.json`, does not exempt the key. The module docstring now says where a JSON marker goes. A `"$comment"` without a marker is not joined at all. It documents the key, and joining it made every edit to that documentation read as a newly minted line. Adding or rewording one below a branded key failed the gate, where main's engine passes. No JSON file in the tree has such a pair today, so this was latent. The pair is one line everywhere else too: - **Counted once.** When the comment's reason names the brand as well, git grep also returns the comment line on its own. That counted one alias twice in the exempt-line reports. A comment read with its key is no longer counted again. Only a comment actually joined to a matched key is skipped, so a branded comment below an unbranded key still counts. - **Listed when it changes.** The exempt-line report picks lines by git's diff. When a marker is written below an existing key, git calls only the comment line added, so the key was exempted without being listed. A change to the comment now counts as a change to its key. The manifest stays as it is. The next plugin release will split the line, and that now changes nothing. ## Evidence - **Real commit:** release-please's original #1722 commit (`9d65875e`), checked against its base: | engine | result | |---|---| | main's | fails: `plugin/openclaw.plugin.json (1 -> 2)` | | this PR's | `No new lines.` | It still lists the rewritten line under "exempt line(s) written". That is a report, not a failure. - **The first review's scenarios**, where the comment's reason names the brand. Exempt lines reported, on this PR's first revision and now; the gate passes in all four runs: | scenario | written | removed | |---|---|---| | release-please's move from one line to two | 2 → 1 | 0 → 0 | | the reason edited, below its key | 1 → 1 | 2 → 1 | - **New tests:** eleven, one of them run for both layouts. - Five cases for the new behaviour fail against main's engine: a marker directly below its key; a layout change from one line to two; a comment that also names the brand, counted once; a marker added below an existing key, listed; a reworded reason below its key, reported. - A reworded reason is reported the same way on the key's line, and that case passes on main too. Rewording a reason is a change to the marker's claim, so both layouts report one line removed and one written. - Two pin the fix above: adding, and rewording, an unmarked `"$comment"` below a branded key mint nothing. They pass on main and failed on this PR's previous revision. - Three bound it and pass either way, as they should: a comment further down, a comment with no marker, a non-JSON file. - One guards the de-duplication: a branded comment below an unbranded key still fails the gate. It passes either way, and fails against a variant that skips comment lines by layout alone. - **Mutation check:** four mutants each fail exactly their own tests: no de-duplication, no diff mapping, de-duplication by layout alone, and joining any comment. - **Other checks:** - the ratchet test suite: 204 passed, 1 skipped; - `ruff check` and `ruff format --check` on `scripts/` and `tests/`, and mypy on `scripts/`. Nothing was reformatted, since this file is byte-sensitive; - the ratchet on this branch: no new lines; - the sentinel: all 35 protected strings survive. ## After merging The org-required check runs the engine pinned at `ratchet-stable`, which is currently `ccd11eb8`, identical to main's engine before this PR. Move it to this PR's merge commit, or the next plugin release fails the same way. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Eldad Caura <eldad@caura.ai> Co-authored-by: Eldad Caura <eldad@caura.ai> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This pull request was closed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 I have created a release beep boop
backend: 3.20.0
3.20.0 (2026-09-26)
Features
Bug Fixes
plugin: 2.23.3
2.23.3 (2026-09-26)
Bug Fixes
This PR was generated with Release Please. See documentation.