feat: expose ClawHub catalog feed lanes

[giodl73-repo]

Summary

Adds ClawHub-hosted root feed lanes for clients that want a standard feed document instead of bespoke catalog queries.

The new HTTP surface exposes:

• /api/v1/feeds
• /api/v1/feeds/all
• /api/v1/feeds/official
• /api/v1/feeds/community
• /api/v1/feeds/reviewed

Each feed emits the shared feed shape used by the OpenClaw and Scout feed work: schemaVersion, feedId, root scope, deterministic entries, sourceRevision, and a SHA-256 attestation hash. The reviewed lane describes its criteria through criteria, aligned with the feed schema language used in the other stacks.

Feed lanes

• all: all public ClawHub skills and installable plugins.
• official: entries marked official by ClawHub/OpenClaw metadata.
• community: public non-official entries.
• reviewed: public entries matching current ClawHub review criteria.

Not included

• No tenant feed hosting.
• No enterprise approval workflow.
• No package safety guarantee beyond the exposed ClawHub metadata and feed attestation.
• No change to existing ClawHub search defaults.

Related stack

• OpenClaw read-only feed discovery: #87824
• OpenClaw approved feed installs: #87825
• OpenClaw feed policy conformance: #87826
• OpenClaw feed lifecycle tooling: #87827
• OpenClaw native feed search defaults: #88732
• Feeds RFC: https://github.com/giodl73-repo/rfcs/blob/feeds-rfc-draft/rfcs/0004-feeds.md

Validation

• git diff --check
• codex review --commit HEAD found and drove fixes for public feed visibility, plugin-family filtering, and skill URLs.
• codex review --uncommitted after those fixes: no actionable correctness issues.
• Not run: ClawHub focused tests, because bun is not installed in the WSL environment used for this reconstruction.

Feed PR stack

1. feat(feeds): add read-only feed discovery openclaw#87824 - read-only feed discovery
2. feat(feeds): install approved feed entries openclaw#87825 - approved feed installs
3. feat(policy): add feed catalog conformance openclaw#87826 - feed catalog policy conformance
4. feat(feeds): add feed lifecycle tooling openclaw#87827 - feed lifecycle tooling
5. feat(feeds): add native feed search defaults openclaw#88732 - native feed search defaults and policy checks
6. feat: expose ClawHub catalog feed lanes #2460 - ClawHub root feed lanes

The stack keeps OpenClaw as a feed consumer. ClawHub root feeds are producer infrastructure; enterprise or tenant feeds can be produced elsewhere using the same schema.

RFC draft: https://github.com/giodl73-repo/rfcs/blob/feeds-rfc-draft/rfcs/0004-feeds.md

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
clawhub	Ready	Preview, Comment	May 31, 2026 8:19pm

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed May 31, 2026, 4:24 PM ET / 20:24 UTC.

Summary
The branch adds a /api/v1/feeds index plus four root feed lane routes, a Convex root feed query, feed document builders/tests, docs, and schema route constants.

Reproducibility: yes. for the review findings: source inspection of head a34da07 shows rootFeed is public, feedV1Handler runs it without applyRateLimit, and skill filtering does not use the current catalog visibility guard. This is not a runtime bug report.

Review metrics: 3 noteworthy metrics.

• New public routes: 5 GET routes added. The PR creates a new public HTTP API surface that should be reviewed as a stable client contract.
• Worst-case digest reads: up to 15,000 digest rows per feed request. The root query can read 5,000 skills plus 5,000 code plugins and 5,000 bundle plugins before filtering or slicing.
• Changed surface: 10 files, +1043/-2. The change spans Convex HTTP routing, backend queries, generated schema package output, docs, and tests.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🧂 unranked krab
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 redacted live curl or terminal output for /api/v1/feeds, one full lane, and one type-filtered lane; update the PR body so ClawSweeper re-reviews, or ask a maintainer to comment @clawsweeper re-review.
• [P1] Move root feed data loading behind an internal/sanitized boundary, add read rate limiting, reuse catalog visibility rules, and add focused tests for those cases.
• Get maintainer confirmation that this public feed schema and lane semantics should be exposed before landing the API contract.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body/comments show validation claims and a Vercel deploy, but no redacted live curl output, terminal output, logs, or recording of the feed endpoints after the latest head. 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 this would create a new public ClawHub API contract while the linked OpenClaw feed stack and external RFC are still open.
• [P1] The public Convex rootFeed query can expose raw catalog digest rows outside the sanitized HTTP feed response.
• [P1] Anonymous callers can trigger large feed reads without the existing public read rate limit.
• [P1] The feed skill lane does not reuse the current catalog owner-visibility guard, so hidden or unresolved-owner skills may leak into feeds.
• [P1] The PR body and comments still lack redacted live endpoint output or equivalent real behavior proof after the latest head.

Maintainer options:

1. Fix the public feed boundary first (recommended)
   Make the data query internal or sanitized, apply the public read rate limit before querying, reuse catalog visibility guards, bound reads, and add focused tests before merge.
2. Pause until the feed contract is settled
   Keep the draft open or close/reopen later if maintainers want the OpenClaw feed stack and RFC to settle before ClawHub exposes root feeds.
3. Accept the API risk explicitly
   Maintainers could intentionally accept the current public API and read-amplification behavior, but that would need explicit ownership because CI does not settle those risks.

Next step before merge

• [P1] Human review is needed because this draft introduces a public API contract with security/availability blockers and contributor-owned runtime proof still missing.

Security
Needs attention: The diff introduces a new public API boundary with a public Convex query returning raw digest data and unrate-limited high-volume reads.

Review findings

• [P1] Make the feed data query internal — convex/feeds.ts:59
• [P1] Rate-limit feed reads before querying — convex/httpApiV1/feedsV1.ts:397-400
• [P1] Reuse the catalog skill visibility guard — convex/feeds.ts:111-112

Review details

Best possible solution:

Keep the PR open only if the feed API is intentionally approved and the implementation moves data loading behind an internal, rate-limited, sanitized boundary that reuses existing catalog visibility rules, bounds reads, and includes focused tests plus live endpoint proof.

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

Yes for the review findings: source inspection of head a34da07 shows rootFeed is public, feedV1Handler runs it without applyRateLimit, and skill filtering does not use the current catalog visibility guard. This is not a runtime bug report.

Is this the best way to solve the issue?

No. The current patch is not the narrowest maintainable solution because it exposes raw feed data through a public Convex query and skips established rate-limit and visibility boundaries; the safer path is an internal, rate-limited, sanitized feed builder with maintainer-approved contract semantics.

Full review comments:

• [P1] Make the feed data query internal — convex/feeds.ts:59
rootFeed is registered with public query(), so direct Convex callers can receive raw skillSearchDigest and packageSearchDigest rows instead of the sanitized feed document. Move this behind internalQuery/internalRefs or return only the public feed shape from any public function.
  Confidence: 0.91
• [P1] Rate-limit feed reads before querying — convex/httpApiV1/feedsV1.ts:397-400
feedV1Handler calls the root feed query without the public read rate limit used by the existing v1 catalog handlers. Anonymous requests can therefore trigger the expensive feed read path repeatedly, so apply applyRateLimit(ctx, request, 'read') before ctx.runQuery and pass the headers through responses.
  Confidence: 0.9
• [P1] Reuse the catalog skill visibility guard — convex/feeds.ts:111-112
  The feed filters skills with matchesSkillFeed, which only checks soft deletion and moderation fields, while the current catalog path also requires toPublicSkill(...) and resolved owner visibility. This can publish skills whose owners are hidden, missing, or not backfilled, so reuse the existing catalog visibility logic or an equivalent shared helper.
  Confidence: 0.86
• [P2] Bound feed reads to the requested page size — convex/feeds.ts:72-97
  Even limit=1 reads up to 5,000 skills and two 5,000-row plugin family pages before filtering and slicing. That makes the new public route much more expensive than requested; use indexed lane/type filters, pagination, or a bounded overfetch strategy tied to the requested limit.
  Confidence: 0.84

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9fc2da4dc437.

Label changes

Label justifications:

• P2: This is a normal-priority feature PR with limited blast radius until merged, but it needs public API, security, and availability review.
• merge-risk: 🚨 security-boundary: The PR exposes a new public feed contract and a public Convex query that can return raw catalog digest data outside the sanitized HTTP response.
• merge-risk: 🚨 availability: The feed handler can run large digest reads without the existing public read rate limit, so merge could add an anonymous read-amplification path.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body/comments show validation claims and a Vercel deploy, but no redacted live curl output, terminal output, logs, or recording of the feed endpoints after the latest head. 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

Security concerns:

• [high] Public query exposes raw catalog digests — convex/feeds.ts:59
rootFeed is registered as a public Convex query and returns raw digest arrays, so clients can bypass the sanitized HTTP feed response and receive internal IDs and metadata fields.
  Confidence: 0.91
• [medium] Anonymous feed reads are not rate-limited — convex/httpApiV1/feedsV1.ts:397
  The HTTP feed handler runs the root feed query without the existing read-rate limiter, which creates an availability risk for a public endpoint that can read thousands of digest rows per request.
  Confidence: 0.9

What I checked:

• Live PR state: The GitHub API reports this PR is open, draft, mergeable, and at head a34da07 with 10 files changed. (a34da07297e4)
• Current main lacks feed routes: A source search on current main only found unrelated feed wording in specs/diffing.md, so the requested ClawHub root feed API is not already implemented on main. (packages/schema/src/routes.ts:14, 9fc2da4dc437)
• Public Convex query in PR: The PR registers rootFeed with public query(), returning raw skillSearchDigest and packageSearchDigest rows to any direct Convex caller instead of limiting exposure to the sanitized HTTP feed shape. (convex/feeds.ts:59, a34da07297e4)
• Feed handler lacks read rate limit: feedV1Handler parses request parameters and immediately calls rootFeed without the applyRateLimit(ctx, request, 'read') guard used by existing public HTTP handlers. (convex/httpApiV1/feedsV1.ts:386, a34da07297e4)
• Existing public API rate-limit pattern: Current main's package list handler applies the public read rate limit before parsing and querying, which is the pattern the new feed routes should follow. (convex/httpApiV1/packagesV1.ts:1212, 875f026a2300)
• Existing skill catalog visibility guard: Current main's skill catalog path requires both toPublicSkill visibility and resolved owner visibility before publishing a skill catalog item; the PR's rootFeed only calls matchesSkillFeed. (convex/skills.ts:5385, 875f026a2300)

Likely related people:

• Patrick Erichsen: Blame shows the current v1 package routes, route constants, public read rate-limit pattern, and initial catalog visibility helpers in commit 875f026. (role: API/catalog route introducer; confidence: medium; commits: 875f026a2300; files: convex/httpApiV1/packagesV1.ts, convex/http.ts, packages/schema/src/routes.ts)
• Vyctor H. Brzezowski: Recent commits updated moderated skill file/tag guards and org publisher access checks in the same catalog visibility and package authorization area. (role: recent security and visibility contributor; confidence: medium; commits: 97023d3123f4, d854449610b1; files: convex/skills.ts, convex/packages.ts)

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.