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	Jun 3, 2026 10:15pm

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 14, 2026, 4:14 AM ET / 08:14 UTC.

Summary
The branch adds five public catalog-feed endpoints with Convex queries and HTTP handlers, feed-lane tests, schema route constants and generated outputs, plus HTTP API documentation.

Reproducibility: not applicable. This PR proposes new public feed behavior rather than reporting broken established behavior. The relevant verification requirement is after-change runtime proof from real HTTP endpoints.

Review metrics: 4 noteworthy metrics.

• Public Endpoints: 5 added. Every endpoint becomes a versioned compatibility and operational commitment for feed consumers.
• Changed Surface: 10 files, +1053/-2. The branch spans backend selection, HTTP routing, tests, generated package artifacts, and public documentation.
• Unresolved Review Findings: 4 on unchanged head. All five completed review cycles inspected the same current head SHA.
• Current-Main Feed Routes: 3 existing. The branch now overlaps a separate plugin, skill, and promotions feed contract on main.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦪 silver shellfish
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] Rebase onto current main and implement any approved lanes through the canonical stored catalog-feed publication model.
• [P1] Resolve the four unchanged findings and add fresh-contract plus upgrade-compatibility validation.
• Post redacted live curl output for the feed index and every added lane.

Proof guidance:

• [P1] Needs real behavior proof before merge: No redacted curl output, terminal transcript, runtime logs, or linked artifact demonstrates the feed index and lane JSON from a real after-change endpoint; screenshots or terminal captures are welcome, with private endpoints, keys, IP addresses, and other sensitive data redacted. After adding proof, updating the PR body should trigger review automatically; otherwise a maintainer can comment @clawsweeper re-review. 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 after conflict resolution could leave two competing public feed contracts unless the branch is explicitly rebased onto and integrated with current main's plugin, skill, and promotions feed model.
• [P1] The names official and reviewed communicate endorsement or review guarantees, but the branch derives membership from mutable metadata and moderation fields without a durable publication decision or policy version.
• [P2] A public request may query and transform as many as 5,000 live catalog entries, creating load, latency, and timeout exposure that the handler mocks do not settle.
• [P1] Existing clients could persist feed IDs, approvals, revisions, or attestations under inconsistent identities if the lane identifiers are not globally distinct and stable.
• [P1] The draft is currently dirty against main, so its actual three-way merge behavior and compatibility with the newer feed implementation remain unproven.

Maintainer options:

1. Rebase Into Canonical Publications (recommended)
   Resolve the conflicts by extending current main's stored catalog-feed implementation, preserving existing routes and adding focused compatibility and trust-policy coverage.
2. Pause Trust-Oriented Lanes
   Keep the current public feed contract unchanged until maintainers define what official and reviewed membership promises to consumers.
3. Accept Parallel Contracts
   Merge separate root lanes only if maintainers intentionally accept duplicate feed infrastructure, operational cost, and a long-term compatibility obligation.

Next step before merge

• [P1] A maintainer must decide the permanent feed and trust contract before the contributor rebases, resolves the concrete findings, and supplies live endpoint proof.

Maintainer decision needed

• Question: Should ClawHub extend its current plugin, skill, and promotions feeds with official, community, and reviewed root lanes, and what durable guarantee should each trust-oriented lane name provide?
• Rationale: The branch proposes a new public discovery and trust contract that differs from current main; code review cannot decide whether mutable metadata is sufficient for endorsement-style lanes or whether those lanes should exist at all.
• Likely owner: patrick-erichsen — Recent catalog and API history makes this contributor the strongest available routing candidate for the current feed contract and its integration boundary.
• Options:
  • Extend Canonical Feeds (recommended): Rebase and implement approved lanes through the current stored publication model with stable identities and documented policy semantics.
  • Keep Existing Lanes: Retain current main's plugin, skill, and promotions boundaries and close this draft without adding endorsement-style lanes.
  • Expose Neutral Metadata: Avoid official or reviewed feed names and expose non-endorsement catalog metadata that consumers may filter under their own policy.

Security
Needs attention: The patch promotes mutable metadata and moderation filters into public official and reviewed trust signals without a durable, policy-versioned publication decision.

Review findings

• [P1] Serve root feeds from stored publications — convex/feeds.ts:66
• [P1] Use a distinct official root feed id — convex/httpApiV1/feedsV1.ts:19
• [P2] Regenerate the Convex API references — convex/httpApiV1/feedsV1.ts:72-76

Review details

Best possible solution:

Use current main's catalog-feed publication infrastructure as the sole source of truth, adding any approved official, community, or reviewed lanes as durable, policy-versioned publications with stable unique IDs, explicit trust language, OpenAPI and generated-client coverage, compatibility tests, and live endpoint proof.

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

Not applicable: this PR proposes new public feed behavior rather than reporting broken established behavior. The relevant verification requirement is after-change runtime proof from real HTTP endpoints.

Is this the best way to solve the issue?

No. A parallel live-query implementation is not the narrowest maintainable solution now that current main has canonical catalog-feed infrastructure; approved lanes should extend that model instead.

Full review comments:

• [P1] Serve root feeds from stored publications — convex/feeds.ts:66
  Build these public documents from the canonical stored publication or snapshot model rather than querying mutable skills and packages on every request. The live-query path duplicates current main's feed infrastructure, makes revisions and attestations transient, and can publish a different trust decision from the one consumers approved.
  Confidence: 0.96
• [P1] Use a distinct official root feed id — convex/httpApiV1/feedsV1.ts:19
  Give the official lane a stable identity that cannot collide with or be derived as another root feed's identity. Feed IDs may key cached approvals, revisions, and attestations, so identity reuse can associate policy state with the wrong catalog.
  Confidence: 0.91
• [P2] Regenerate the Convex API references — convex/httpApiV1/feedsV1.ts:72-76
  Regenerate and commit the Convex API after adding feeds.rootFeed instead of bypassing it with a handwritten cast. The cast leaves generated deploy and typecheck consumers unaware of the new function contract.
  Confidence: 0.98
• [P2] Add the feed routes to the OpenAPI contract — packages/schema/src/routes.ts:22-26
  Add all five public endpoints and their response schemas to the OpenAPI source and generated output. Markdown documentation and route constants alone leave generated clients and contract validation unaware of the API.
  Confidence: 0.97

Overall correctness: patch is incorrect
Overall confidence: 0.95

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 05a798c4ba91.

Label changes

Label justifications:

• P2: This is a normal-priority public API feature with substantial compatibility and trust-policy implications but no demonstrated current production regression.
• merge-risk: 🚨 compatibility: Current main now exposes a different catalog-feed model, so merging this branch could establish parallel routes, identities, and sources of truth.
• merge-risk: 🚨 security-boundary: The proposed official and reviewed lanes turn mutable moderation metadata into public trust signals without a durable approval boundary.
• merge-risk: 🚨 availability: Each unauthenticated request may collect and transform thousands of live catalog records, creating production load and timeout risk not resolved by mocked handler tests.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No redacted curl output, terminal transcript, runtime logs, or linked artifact demonstrates the feed index and lane JSON from a real after-change endpoint; screenshots or terminal captures are welcome, with private endpoints, keys, IP addresses, and other sensitive data redacted. After adding proof, updating the PR body should trigger review automatically; otherwise a maintainer can comment @clawsweeper re-review. 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] Mutable filters overstate reviewed trust — convex/feeds.ts:25
  Reviewed membership is calculated from current flags, scan status, and verification fields, so clients may treat an entry as approved without an immutable review event or the policy version that admitted it.
  Confidence: 0.94
• [medium] Unsigned hash does not establish trust — convex/httpApiV1/feedsV1.ts:6
  A SHA-256 digest can detect document changes but does not authenticate a trusted publisher or preserve the moderation decision behind an official or reviewed classification.
  Confidence: 0.92

What I checked:

• Current-main feed implementation: Current main already contains dedicated catalog feed source, handlers, tests, OpenAPI coverage, and public routes for plugin, skill, and promotions feeds, establishing a newer canonical implementation that this branch does not use. (convex/catalogFeed.ts:1, 05a798c4ba91)
• Current public route contract: Current main defines /api/v1/feeds/plugins, /api/v1/feeds/skills, and /api/v1/feeds/promotions, while the branch independently introduces an index plus all, official, community, and reviewed routes. (packages/schema/src/routes.ts:28, 05a798c4ba91)
• Unchanged review head: The current PR head is the same SHA examined by all five previous ClawSweeper cycles, so the four previously reported findings have not been changed by contributor commits. (02d11208469f)
• Live-query publication model: The branch introduces a rootFeed query that selects directly from mutable skill and package state rather than extending current main's canonical catalog publication model. (convex/feeds.ts:66, 02d11208469f)
• Missing generated Convex reference: The new handler uses a handwritten cast for api.feeds.rootFeed, indicating that the committed Convex API references were not regenerated for the added function. (convex/httpApiV1/feedsV1.ts:72, 02d11208469f)
• Proof remains absent: The PR body reports static diff review and a Vercel deployment, but contains no redacted curl output, runtime log, terminal transcript, or linked artifact showing responses from the new endpoints. (02d11208469f)

Likely related people:

• patrick-erichsen: Recent repository history attributes multiple catalog and API changes to this contributor, making them a strong routing candidate for aligning the proposed lanes with current feed infrastructure. (role: recent API and catalog contributor; confidence: medium; commits: f78d1b2f, 12d78997, a75b84ca; files: convex/catalogFeed.ts, convex/httpApiV1/catalogFeedV1.ts, packages/schema/src/routes.ts)
• vyctorbrzezowski: Recent merged work on catalog browse semantics, URL behavior, and HTTP API evolution makes this contributor relevant to public catalog-contract compatibility. (role: adjacent catalog behavior contributor; confidence: medium; commits: f78d1b2f, 12d78997; files: convex/httpApiV1/catalogFeedV1.ts, convex/httpApiV1/openapi.ts, docs/http-api.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.

Review history (5 earlier review cycles)

• reviewed 2026-07-01T07:57:05.919Z sha 02d1120 :: needs real behavior proof before merge. :: [P1] Serve root feeds from stored publications | [P1] Use a distinct root official feed id | [P2] Regenerate the Convex API references | [P2] Add the feed routes to the OpenAPI contract
• reviewed 2026-07-04T08:21:18.734Z sha 02d1120 :: needs real behavior proof before merge. :: [P1] Serve root feeds from stored publications | [P1] Use a distinct root official feed id | [P2] Regenerate the Convex API references | [P2] Add the feed routes to the OpenAPI contract
• reviewed 2026-07-07T23:47:28.884Z sha 02d1120 :: needs real behavior proof before merge. :: [P1] Serve root feeds from stored publications | [P1] Use a distinct root official feed id | [P2] Regenerate the Convex API references | [P2] Add the feed routes to the OpenAPI contract
• reviewed 2026-07-08T01:38:32.282Z sha 02d1120 :: needs real behavior proof before merge. :: [P1] Serve root feeds from stored publications | [P1] Use a distinct official root feed id | [P2] Regenerate the Convex API references | [P2] Add the feed routes to the OpenAPI contract
• reviewed 2026-07-09T02:13:57.426Z sha 02d1120 :: needs real behavior proof before merge. :: [P1] Serve root feeds from stored publications | [P1] Use a distinct official root feed id | [P2] Regenerate the Convex API references | [P2] Add the feed routes to the OpenAPI contract

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: feat: expose ClawHub catalog feed lanes This is item 1/1 in the current shard. Shard 9/44.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[giodl73-repo]

Closing as superseded by the current signed ClawHub producer tracks (#3005, #3116, #3117, #3147, #3149, #3151, #3160, and #3163) and RFC 0009. This root-feed-lane prototype is no longer intended to merge.