feat: publish plugins with extended-stable releases#100448
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 957f7366eb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Codex review: needs maintainer review before merge. Reviewed July 5, 2026, 6:10 PM ET / 22:10 UTC. Summary PR surface: Source +88, Tests +815, Docs +61, Config +125, Other +88. Total +1177 across 31 files. Reproducibility: not applicable. this is a release feature PR rather than a bug report. The behavioral claim is source-verifiable and backed by the PR body's local Verdaccio selector matrix plus focused workflow/runtime tests. Review metrics: 1 noteworthy metric.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review detailsBest possible solution: Land one release-owner-approved extended-stable plugin policy that preserves official default install intent, keeps explicit pins and third-party installs untouched, and keeps npm tag mutation outside token-authenticated source-repo code. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a release feature PR rather than a bug report. The behavioral claim is source-verifiable and backed by the PR body's local Verdaccio selector matrix plus focused workflow/runtime tests. Is this the best way to solve the issue? Yes, conditionally: the implementation is a maintainable shared resolver and workflow-gated release path if maintainers choose the all-plugin exact-core policy. The unresolved question is policy fit versus the overlapping covered/snapshot proposals, not a line-level defect. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against ff440393da6a. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +88, Tests +815, Docs +61, Config +125, Other +88. Total +1177 across 31 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
|
@clawsweeper re-review The official ClawHub-to-npm fallback now uses the effective official update channel when deciding whether to preserve moving install intent. Commit 13c51a8 adds the |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
@clawsweeper re-review Current head 76e965e addresses both prior findings: the ClawHub fallback preserves effective extended-stable intent, and the source workflow no longer performs token-authenticated npm dist-tag mutation. All review threads are resolved, 147 runtime tests and 68 focused release tests pass, workflow validation passes, and current-head CI is green. |
|
🦞🧹 I asked ClawSweeper to review this item again. |
Live fork OIDC publication proofA fork-only canary based on this PR head (76e965e) exercised the real plugin-npm-release.yml trusted-publisher path without changing the production branch:
The workflow selected only the fork-owned canary package; it did not target or mutate any upstream @openclaw package. This proves the OIDC/tag/provenance path used by the PR while keeping the fork-only package retargeting outside the upstream change. |
Release-owner policy decisionApprove the all-plugin exact-core policy implemented by this PR: every npm-publishable official plugin is published at the extended-stable core version, eligible official default/latest intent resolves to that exact core version, and explicit pins plus third-party/non-npm sources remain unchanged. This is the selected Milestone 25.11 model and supersedes the earlier covered-plugin/monthly-snapshot implementation proposals. The current head is mergeable with green CI, resolved review threads, local Verdaccio publication/install/update proof, and the live fork OIDC/provenance proof in the preceding comment. |
* feat(release): publish plugins on extended-stable * feat(plugins): align extended-stable with core * docs: explain extended-stable plugin alignment * fix(release): make plugin convergence recoverable * fix(plugins): preserve extended-stable fallback intent * fix(release): keep plugin tag mutation credential-isolated
* feat(release): publish plugins on extended-stable * feat(plugins): align extended-stable with core * docs: explain extended-stable plugin alignment * fix(release): make plugin convergence recoverable * fix(plugins): preserve extended-stable fallback intent * fix(release): keep plugin tag mutation credential-isolated (cherry picked from commit 9d2d517)
What Problem This Solves
Extended-stable core releases could not publish and verify the matching official plugin set as one npm-only release. Operators also lacked a safe retry path for stale plugin tags, while clients following default official plugin intent could resolve a moving
latestpackage instead of the exact installed core version.Why This Change Was Made
This reuses the existing
all-publishableplugin workflow with one closedextended-stabletag override, publishes and verifies plugins before core, and binds core publication to a successful plugin run on the same branch and SHA. New tags are assigned atomically by OIDC trusted publication; token-authenticated post-publication tag mutation remains outside the source repo. At runtime, one shared resolver maps eligible official bare/latestintent to the exact core version while preserving explicit pins, third-party packages, and non-npm sources.User Impact
Release operators can publish every npm plugin in lockstep with each
.33+extended-stable core release without moving regularlatestorbetaselectors. Users installing or updating onextended-stablereceive official default-tracking plugins at the exact core version; ordinary stable releases and intentionally pinned plugins keep their existing behavior.Evidence
extended-stable=2099.4.33,latest=2099.5.1;2099.4.34,latestremained2099.5.1;latestmoved to2099.5.2, everyextended-stableremained2099.4.34.plugins update --allpreserving movingextended-stableintent after an official ClawHub-to-npm fallback.npm dist-tag addmutation.zizmor, interpolation checks, andgit diff --checkpassed.Manual verification: