feat: serve signed publisher feed projections

[giodl73-repo]

Summary

• expose a complete signed publisher snapshot for trusted reset recovery
• expose signed, bounded publisher-feed query pages
• expose signed changed-since pages and signed reset-required responses
• bind continuations to publisher identity, revision/range, normalized query, offset, limit, page index, and expiry
• fail closed before publisher projection reads when the atomic ClawHub signing configuration is unavailable
• emit standard DSSE envelopes for publisher payloads and integrity-protected cursors

Stack

This is an integration child for the emerging publisher-feed distribution track. It intentionally contains its dependencies until they land:

• feat: add publisher feed model API #2948 publisher feed foundation
• feat: add publisher feed query and delta state #3116 query and durable change projections
• feat(feeds): add dormant catalog signing foundation #3005 shared ClawHub standard-DSSE signing foundation
• RFC 0009: align Hosted Feed v1 specifications rfcs#39 scalable feed distribution contract

After the dependencies merge, this branch should be rebased so the final diff contains only the public signed route layer.

Routes

• GET /api/v1/publishers/{publisherId}/feed/snapshot
• GET /api/v1/publishers/{publisherId}/feed/query?q=...&kind=skill&limit=...
• GET /api/v1/publishers/{publisherId}/feed/changes?fromSequence=...&limit=...

The snapshot uses openclaw.clawhub-publisher-feed-snapshot.v1. Continuation requests accept only the integrity-protected cursor. Query pages use openclaw.clawhub-publisher-feed-query-results.v1; change and reset pages use openclaw.clawhub-publisher-feed-changes.v1. Reset responses point only to the signed snapshot route.

Validation

• focused schema, account storage, route, handler, and signing tests (400 tests across four files)
• scoped type-aware oxlint and oxfmt
• package schema TypeScript build
• git diff --check
• codex review: no actionable correctness regressions

[vercel]

Someone is attempting to deploy a commit to the OpenClaw Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 22, 2026, 1:32 AM ET / 05:32 UTC.

Summary
This PR adds signed publisher-feed snapshot, query, and changed-since HTTP projections together with their storage, schema, DSSE signing, OpenAPI, tests, and specification dependencies.

Reproducibility: yes. source inspection gives a high-confidence path: the changed catalog route dispatches to a signer-dependent handler, while the publisher routes are new; live deployment behavior was not supplied to confirm the actual HTTP responses.

Review metrics: 2 noteworthy metrics.

• Integration surface: 30 files, 5,172 additions, 146 deletions. The branch combines the intended route layer with its storage, signing, schema, generated-output, and documentation prerequisites.
• Open prerequisites: 3 linked PRs still open. The branch itself says it should be rebased to remove those dependencies before final review.

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:

• Remove or explicitly approve the catalog-feed representation cutover.
• Rebase so the final diff contains only the public signed publisher-route layer after prerequisites land.
• [P1] Add redacted live HTTP or terminal proof from a running Convex deployment.

Proof guidance:

• [P1] Needs real behavior proof before merge: The external PR supplies tests and CI but no redacted live HTTP or terminal proof from a running Convex deployment; add proof for a signed publisher response, cursor continuation, and missing-config response, redacting private endpoints and secrets. Updating the PR body should trigger a new review; otherwise ask a maintainer to 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] Replacing the catalog-feed representation with DSSE output can break existing consumers that expect the prior response, and an unset or invalid production signing secret makes that route return 503.
• [P1] The 30-file integration branch combines storage, schema, public HTTP, signing, generated artifacts, and documentation while its three stated prerequisite PRs remain open, making review and upgrade behavior difficult to isolate.
• [P1] Real behavior proof is still absent; green source-harness checks do not prove the deployed Convex route, signer configuration, or cursor behavior.

Maintainer options:

1. Preserve existing catalog compatibility (recommended)
   Keep catalogFeedV1Http on the catalog route and limit this branch to the new publisher projections after its prerequisites land.
2. Accept a coordinated DSSE cutover
   Approve the changed catalog representation only after documenting existing-client impact and showing production-ready signer provisioning plus rollback evidence.
3. Pause the stacked integration branch
   Close or defer this draft if the prerequisite branches and public signing rollout are not being sponsored as one reviewed feature track.

Next step before merge

• [P1] A maintainer must decide the existing catalog-feed contract and coordinated signing rollout before any mechanical rebase or repair can be safely scoped.

Maintainer decision needed

• Question: Should the existing catalog-feed route be migrated to DSSE and fail closed as part of this publisher-feed PR, or must this PR preserve the current catalog representation until a separately approved rollout is ready?
• Rationale: The answer changes a public client contract, a production secret dependency, and the acceptable outage behavior; source review cannot determine whether maintainers intend that coordinated rollout.
• Likely owner: Patrick-Erichsen — Prior publisher-feed contract review makes Patrick-Erichsen the best available routing candidate for the compatibility decision.
• Options:
  • Split and preserve the catalog route (recommended): Rebase after the prerequisite PRs land and keep the existing catalog handler unchanged while adding only the signed publisher routes.
  • Approve a coordinated catalog cutover: Accept the DSSE catalog migration only with explicit consumer compatibility, production secret provisioning, rollback, and live endpoint proof.
  • Pause the feed stack: Defer this public contract until the feed distribution and signing rollout has an approved owner and deployment plan.

Security
Cleared: No committed secret, new third-party execution path, or direct credential exposure was found; the remaining concern is the separately reviewed public signing rollout and its operational availability boundary.

Review findings

• [P1] Preserve the existing catalog-feed representation — convex/http.ts:169

Review details

Best possible solution:

Land the publisher projection, query/delta state, and signing foundations independently, then rebase this PR into a small public signed publisher-route layer that preserves the existing catalog route unless maintainers explicitly approve its coordinated DSSE migration.

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

Yes, source inspection gives a high-confidence path: the changed catalog route dispatches to a signer-dependent handler, while the publisher routes are new; live deployment behavior was not supplied to confirm the actual HTTP responses.

Is this the best way to solve the issue?

No. The current integration branch is not the narrowest maintainable solution because it retains unresolved prerequisite work and changes the existing catalog contract; split/rebase it after the foundations land, then make any catalog migration an explicit rollout decision.

Full review comments:

• [P1] Preserve the existing catalog-feed representation — convex/http.ts:169
  The route now swaps catalogFeedV1Http for the signer-dependent DSSE handler, so existing catalog clients receive a different representation and receive 503 until the new secret is provisioned. This repeats the prior review blocker: keep the existing handler here, or obtain explicit rollout approval and prove compatibility, provisioning, and rollback.
  Confidence: 0.96

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🧂 unranked krab, so this older rating label is no longer current.

Label justifications:

• P2: This is a substantial but not yet user-facing publisher-feed feature whose public contract and rollout still need review.
• merge-risk: 🚨 compatibility: The diff changes the existing catalog-feed handler and representation in addition to adding new publisher endpoints.
• merge-risk: 🚨 availability: The changed catalog and new publisher routes fail closed with 503 when the signing configuration is absent or invalid.
• 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: The external PR supplies tests and CI but no redacted live HTTP or terminal proof from a running Convex deployment; add proof for a signed publisher response, cursor continuation, and missing-config response, redacting private endpoints and secrets. Updating the PR body should trigger a new review; otherwise ask a maintainer to 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

What I checked:

• Current-main gap: Current main's HTTP router imports and registers existing v1 endpoints but has no publisher feed GET router or signed publisher-feed route layer, so the central requested capability is not already implemented. (convex/http.ts, a9775fc39b10)
• Open prerequisite stack: The PR body says it intentionally includes the foundations from feat: add publisher feed model API #2948, feat: add publisher feed query and delta state #3116, and feat(feeds): add dormant catalog signing foundation #3005; all three are still open, so this is not yet the narrow public-route layer described as the intended final diff. (1ff1a792395d)
• Prior compatibility blocker remains: The current PR diff still replaces the catalog-feed handler with the signed handler, changing an existing catalog representation and making it return 503 when signing configuration is unavailable. This is the same contract concern raised in the previous ClawSweeper review. (convex/http.ts:169, 1ff1a792395d)
• No live after-fix proof: The PR body lists tests, type checks, linting, and diff checks, but it provides no redacted request against a running Convex deployment showing a signed publisher route, cursor continuation, and the missing-config failure mode. (1ff1a792395d)
• Review-policy application: Repository guidance requires focused Convex review, real browser proof for UI changes, and pre-handoff static/unit gates; this backend feature instead needs live HTTP/terminal evidence before merge. (AGENTS.md, a9775fc39b10)

Likely related people:

• Patrick-Erichsen: The linked publisher-feed foundation describes fixes responding to Patrick's exact-head review, and the earlier ClawSweeper report identifies him as the reviewer connected to the remaining v1 feed-contract blockers. (role: prior contract reviewer; confidence: medium; files: convex/http.ts, convex/httpApiV1/accountFeedsV1.ts, specs/account-feeds.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 (1 earlier review cycle)

• reviewed 2026-07-18T06:09:09.273Z sha b1af0468a1978b6d3563da591b968e50dac55105 :: needs real behavior proof before merge. :: [P1] Preserve the existing catalog-feed representation

[github-actions]

This pull request has been automatically marked as stale due to inactivity.
Please update it or it will be closed.

[github-actions]

Closing due to inactivity.
If this PR should be revived, reopen it with current context and a fresh validation plan.