RFC 0009 addendum: Feed observability and usage telemetry

[giodl73-repo]

Summary

Follow-up addendum to RFC 0009 covering feed observability and usage telemetry.

This keeps the telemetry discussion inside the hosted feeds RFC instead of creating a separate RFC. It clarifies that OpenClaw can reuse the existing diagnostics and OpenTelemetry pipeline, but feed measurement will not happen automatically unless clients preserve feed provenance from fetch through install and activation.

What changed

• Adds a Feed telemetry and observability addendum section to RFC 0009.
• Explains the current measurement model: diagnostics events, diagnostics bundles, diagnostics-otel, and plugin install records already exist, but they do not currently preserve feed id or revision attribution.
• Proposes feed provenance on feed-backed install records.
• Calls out lifecycle events for fetch, snapshot load, entry action, update, policy decision, and activation.
• Adds the telemetry work to the RFC 0009 rollout plan and unresolved questions.

Related implementation

• openclaw/openclaw#96194 is the first implementation slice after the hosted marketplace feed stack. It adds opt-in diagnostics timeline telemetry for the explicit hosted marketplace commands, openclaw plugins marketplace refresh and openclaw plugins marketplace entries, with bounded feed provenance and fallback fields. It intentionally avoids raw feed URLs, query strings, credentials, bearer tokens, feed bodies, package lists, and raw fallback errors.

Validation

• git diff --check
• checked no em dashes in RFC 0009

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 23, 2026, 5:06 PM ET / 21:06 UTC.

Summary
The branch adds a feed telemetry and observability addendum to RFC 0009, updates the rollout plan, and adds one unresolved telemetry question.

Reproducibility: not applicable. This PR changes an RFC design document, not a current behavior bug. The high-confidence checks are the PR diff, current RFC 0009 on main, README lifecycle guidance, and the PR discussion/proof state.

Review metrics: 1 noteworthy metric.

• RFC diff surface: 1 file changed; 56 added, 3 deleted. The patch is small and Markdown-only, so review should focus on RFC direction, privacy posture, and proof rather than runtime behavior.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add a rendered RFC screenshot, copied terminal output, or linked validation artifact with private details redacted.
• [P1] Get maintainer acceptance or narrowing of the telemetry and privacy direction before merge.

Proof guidance:

• [P1] Needs real behavior proof before merge: No after-change rendered RFC screenshot, copied command output, or linked artifact is present; the contributor should add redacted proof to the PR body so ClawSweeper can re-review, or ask a maintainer to comment @clawsweeper re-review if it does not run. 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.

Risk before merge

• [P1] Merging the addendum would set RFC direction for telemetry provenance fields, diagnostic lifecycle events, OpenTelemetry mappings, reporting questions, and privacy exclusions before explicit maintainer acceptance.
• [P1] The external contributor proof gate is still missing a rendered-document artifact, copied terminal output, or linked after-change validation evidence.

Maintainer options:

1. Accept Or Narrow Telemetry Direction (recommended)
   Maintainers can decide whether the proposed feed provenance, diagnostics, reporting, and privacy text belongs in RFC 0009 as written or needs narrowing before merge.
2. Keep As Draft Discussion
   If the telemetry and reporting model is not settled, leave the PR open as a focused RFC discussion update rather than landing the addendum now.

Next step before merge

• [P1] Maintainers need to decide the telemetry/privacy RFC direction and the contributor needs to add proof; there is no narrow automated code repair to queue.

Security
Cleared: The diff is Markdown RFC text only and introduces no executable code, dependency, workflow, credential handling, or supply-chain execution path.

Review details

Best possible solution:

Keep the addendum open until maintainers accept or narrow the feed telemetry and privacy direction, then land it with visible rendered-document or command-output validation proof.

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

Not applicable: this PR changes an RFC design document, not a current behavior bug. The high-confidence checks are the PR diff, current RFC 0009 on main, README lifecycle guidance, and the PR discussion/proof state.

Is this the best way to solve the issue?

Unclear as merge-ready: RFC 0009 is a reasonable place for a hosted-feed telemetry addendum, but maintainers still need to accept or narrow the telemetry and privacy direction before it becomes repository direction.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against 89cf322325b0.

Label changes

Label justifications:

• P3: This is a low-risk RFC documentation update with no runtime code change, but it still needs normal maintainer review before merge.
• merge-risk: 🚨 other: The concrete merge risk is RFC telemetry/privacy direction drift rather than compatibility, delivery, session, auth, security-boundary, availability, or automation breakage.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No after-change rendered RFC screenshot, copied command output, or linked artifact is present; the contributor should add redacted proof to the PR body so ClawSweeper can re-review, or ask a maintainer to comment @clawsweeper re-review if it does not run. 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

What I checked:

• Target AGENTS.md check: No AGENTS.md exists inside the openclaw/rfcs git root; the surrounding workspace AGENTS.md was read but did not provide target-repository policy for this RFC review. (89cf322325b0)
• Current main state: Current main has RFC 0009's bundled fallback rationale followed directly by the rollout plan, so the telemetry addendum is not already implemented on main. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:561, 89cf322325b0)
• PR diff surface: The PR changes only RFC 0009, adding the feed telemetry and observability section plus rollout and unresolved-question updates, with 56 additions and 3 deletions. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:565, b877bbb3af85)
• Proof review: The PR body lists validation checks but does not include copied output, a rendered-document screenshot, or a linked after-change artifact showing the updated RFC. (b877bbb3af85)
• RFC lifecycle guidance: README.md says new RFCs start as PRs and should not merge while still in draft status, so a direction-setting addendum needs maintainer acceptance before landing. (README.md:80, 89cf322325b0)
• Parent RFC provenance: RFC 0009 was introduced by the merged hosted-feeds PR at commit 89cf322; this PR is a follow-up to that merged RFC rather than a duplicate of an open proposal. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1, 89cf322325b0)

Likely related people:

• giodl73-repo: Current-main blame ties RFC 0009 to Gio's merged hosted-feeds RFC commit, and older feeds RFC history shows Gio authored earlier feed drafts. (role: prior feed RFC contributor; confidence: high; commits: 89cf322325b0, 1cd9e911af24, 2d0e47f03c1d; files: rfcs/0009-hosted-feeds-for-plugins-and-skills.md, rfcs/0006-feeds.md, rfcs/0004-feeds.md)
• Patrick-Erichsen: Patrick reviewed the parent hosted-feeds RFC with detailed ClawHub, search, source-profile, skills, regional-feed, and signing comments, and deleted the earlier feeds RFC before the rewrite landed. (role: reviewer and recent area contributor; confidence: medium; commits: e7555fdda445; files: rfcs/0006-feeds.md, rfcs/0009-hosted-feeds-for-plugins-and-skills.md)
• vincentkoc: The merged RFC 0009 commit records Vincent as co-author, and the parent PR includes Vincent's catalog source trust commit on the same RFC surface. (role: prior feed RFC co-author; confidence: medium; commits: 89cf322325b0, 439910943d1c; files: rfcs/0009-hosted-feeds-for-plugins-and-skills.md)
• kevinlin-openai: Blame ties the draft/accepted RFC lifecycle guidance that affects this addendum's merge readiness to Kevin's README and template updates. (role: RFC process contributor; confidence: high; commits: e366ea9825a4, f4fdf38f4717, bbb4058da234; files: README.md, rfcs/0000-template.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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

• 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.