docs: propose plugin update availability

[ekinnee]

What Problem This Solves

Formalizes Erick Kinnee's proposal to surface installed-plugin update availability in CLI inventory, update status, and Control UI.

Related: openclaw/openclaw#131897

Why This Change Was Made

Proposes ClawHub as the primary metadata path while preserving recorded npm sources. Defines explicit plugin refresh, shared SQLite observation ownership, 24-hour freshness, four concurrent lookups, a 15-second network budget, and JSON distinctions for eligible, excluded, stale, and unknown results. Core upgrades invalidate cached eligibility. Metadata checks must not enter installer dry-run paths.

These defaults and persistence semantics are proposed for maintainer acceptance. Exact schema, migration, and publication fencing require storage-owner review before implementation. Upgrade preflight remains separate: openclaw/openclaw#122019.

User Impact

Proposal only; no runtime behavior changes. If accepted and implemented, operators could discover plugin updates while preserving pins and distinguishing incomplete checks.

Evidence

• Parsed YAML frontmatter: status remains draft and implementation issue remains blank.
• Verified all seven required RFC sections against the repository template.
• Rendered the revised Markdown to HTML with markdown-it; no browser visual inspection or screenshot is claimed.
• Verified the original proposal, upgrade-preflight issue, and RFC PR links through live GitHub reads.
• Whitespace validation produced no diagnostics.
• Bounded independent contract review identified host-version cache invalidation, now included.
• No runtime implementation, runtime proof, or upgrade-compatibility verdict is claimed.

The required maintainer-discussion thread and RFC acceptance remain outstanding. A maintainer sponsor is needed to advance that discussion.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed October 3, 2026, 3:51 AM ET / 07:51 UTC (Revision 5).

ClawSweeper review

What this changes

Adds a draft proposal for displaying installed-plugin update availability in CLI inventory, update status, and Control UI using explicit refresh and shared retained observations.

Merge readiness

⛔ Blocked before merge - 3 items remain

Keep open: this is a coherent, distinct RFC absent from current main. Maintainer acceptance and the previously requested document-verification evidence remain outstanding.

Priority: P3
Reviewed head: eb7d01d73d9555d1280b1ac5cae9d0c8b28d8607
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦪 silver shellfish (2/6)	The proposal is focused and coherent, but its claimed document verification remains unobservable.
Proof confidence	🦪 silver shellfish (2/6)	Needs stronger real behavior proof before merge: The changed owner is the RFC document. The captured body describes rendering and link checks without observable results, leaving the prior same-head document-verification request unresolved; a rendered artifact or transcript would cover this change. No runtime schema or stored-data contract changes. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: The changed owner is the RFC document. The captured body describes rendering and link checks without observable results, leaving the prior same-head document-verification request unresolved; a rendered artifact or transcript would cover this change. No runtime schema or stored-data contract changes. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	8 items	Pinned introduced change: The complete introduced diff adds one 231-line RFC. It changes no runtime code, database schema, dependencies, workflows, or existing RFC. RFC acceptance contract: Current main requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted frontmatter before merging. The proposal correctly remains draft with a blank implementation issue; its captured body acknowledges that discussion and acceptance are outstanding. Current-main overlap check: The main tree does not contain this RFC. Hosted-feed work covers publisher discovery and notifications, rather than the proposed installed-plugin availability contract. A bounded GitHub PR listing found no merged replacement for this proposal.
Findings	None	None.
Security	None	None.

How this fits together

This repository records OpenClaw design proposals before implementation. The proposed availability owner would compare recorded plugin installations with registry metadata and provide consistent results to CLI and Control UI displays.

flowchart LR
  A[Recorded plugin installations] --> C[Explicit metadata refresh]
  B[Registry metadata] --> C
  C --> D[Source and pin comparison]
  D --> E[Retained availability observations]
  E --> F[CLI inventory and status]
  E --> G[Control UI notices]

Loading

Decision needed

Question	Recommendation
Should this RFC's explicit-refresh, shared SQLite observation, and CLI/UI presentation contract be accepted as v1, or narrowed before acceptance?	Discuss and accept the shared contract: Sponsor the required discussion and accept or amend the proposed v1 boundaries before creating implementation work.

Why: The repository requires acceptance, and the proposed refresh defaults and persistence ownership are explicitly awaiting maintainer intent.

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: The changed owner is the RFC document. The captured body describes rendering and link checks without observable results, leaving the prior same-head document-verification request unresolved; a rendered artifact or transcript would cover this change. No runtime schema or stored-data contract changes. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Complete next step (P2) - Sponsor and link the required maintainer-discussion thread, resolve RFC acceptance, and then set accepted status and the implementation issue before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Accept a single metadata-only availability contract that preserves source and pin choices, makes stale and unknown results explicit, and keeps upgrade-safety assessment separate.

Do we have a high-confidence way to reproduce the issue?

Not applicable: the branch proposes future behavior and introduces no executable bug fix.

Is this the best way to solve the issue?

Unclear pending acceptance: reusing metadata-only resolution is a maintainable direction, but the refresh interface and retained-observation contract need an explicit product decision.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 967d9aac7472.

Labels

Label changes:

• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• remove rating: 🦐 gold shrimp: Current PR rating is rating: 🦪 silver shellfish, so this older rating label is no longer current.

Label justifications:

• P3: This is a design proposal for update discoverability with no runtime change or demonstrated urgent regression.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The changed owner is the RFC document. The captured body describes rendering and link checks without observable results, leaving the prior same-head document-verification request unresolved; a rendered artifact or transcript would cover this change. No runtime schema or stored-data contract changes. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Pinned introduced change: The complete introduced diff adds one 231-line RFC. It changes no runtime code, database schema, dependencies, workflows, or existing RFC. (rfcs/0065-plugin-update-availability.md:1, eb7d01d73d95)
• RFC acceptance contract: Current main requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted frontmatter before merging. The proposal correctly remains draft with a blank implementation issue; its captured body acknowledges that discussion and acceptance are outstanding. (README.md:80, 967d9aac7472)
• Current-main overlap check: The main tree does not contain this RFC. Hosted-feed work covers publisher discovery and notifications, rather than the proposed installed-plugin availability contract. A bounded GitHub PR listing found no merged replacement for this proposal. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:548, 967d9aac7472)
• Proposed persistence is explicitly deferred: Refresh defaults and SQLite observation ownership are proposed for acceptance. Exact schema, migration, and publication fencing are deferred to implementation review; this patch introduces no stored-data contract or executable authorization change. (rfcs/0065-plugin-update-availability.md:140, eb7d01d73d95)
• Proof and re-review continuity: The captured body reports frontmatter, section, rendering, link, and whitespace checks, but supplies no observable output or rendered artifact. The previous completed review at the same head requested a rendered-RFC screenshot or verification transcript. Live inspection returned the same body and head; no runtime implementation proof is warranted for this proposal. (rfcs/0065-plugin-update-availability.md:1, eb7d01d73d95)
• Active paired product request: RFC: Surface plugin update availability in plugins list / update status / Control UI openclaw#131897 remains open under the same author and is assigned to Patrick-Erichsen. Its discussion distinguishes general availability displays from narrower pin repairs and explicitly retains this paired RFC for product acceptance.

Likely related people:

• kevinslin: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Patrick-Erichsen: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Attach a rendered-RFC screenshot or verification transcript showing formatting and link results, with private information redacted; update the PR body for automatic re-review, or ask a maintainer to comment @clawsweeper re-review.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (4 earlier review cycles)

• reviewed 2026-09-06T21:37:37.741Z sha 8835147 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-07T21:01:18.885Z sha 8835147 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-07T21:20:08.753Z sha eb7d01d :: needs real behavior proof before merge. :: none
• reviewed 2026-09-09T23:47:02.530Z sha eb7d01d :: needs real behavior proof before merge. :: none