feat: expose publisher account feed URLs

[giodl73-repo]

Summary

• Add a Feed link to publisher profiles.
• Point it directly at the stable, machine-readable /api/v1/publishers/{publisherId}/feed endpoint from feat: add publisher feed model API #2948.
• Encode the opaque publisher id and cover the URL/helper and rendered profile contract.

Dependency

Depends on #2948 (account and publisher feed API). This is intentionally a small discoverability child and does not introduce duplicate handle-based feed pages.

Boundary

The link exposes discovery metadata only. It does not imply official, reviewed, trusted, approved, or installable status.

Validation

• bun x vitest run src/lib/ownerRoute.test.ts src/__tests__/user-profile-route.test.tsx (24 passed)
• bun x oxfmt --check src/__tests__/user-profile-route.test.tsx src/lib/ownerRoute.test.ts src/lib/ownerRoute.ts 'src/routes/user/$handle.tsx'
• bun x oxlint --type-aware src/__tests__/user-profile-route.test.tsx src/lib/ownerRoute.test.ts src/lib/ownerRoute.ts 'src/routes/user/$handle.tsx'
• git diff --check

[vercel]

@giodl73-repo 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 17, 2026, 11:33 PM ET / July 18, 2026, 03:33 UTC.

Summary
The branch adds a Feed link to publisher profiles while also introducing account and publisher feed schemas, Convex projections, HTTP routes, OpenAPI documentation, and tests.

Reproducibility: not applicable. this is a new feature rather than a report of broken existing behavior. The remaining concerns are directly observable from the proposed public contract and the collaborator's current-head review comments.

Review metrics: 1 noteworthy metric.

• Patch surface: 26 files affected; 1,910 added, 78 removed. The actual branch is a full API and schema stack, not only the small profile discoverability change described in its summary.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🧂 unranked krab
Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

• Resolve the monotonic revision, truthful pagination, and account-versus-publisher API-scope blockers.
• [P1] Rebase the resulting narrow change onto current main and show a redacted live browser/API run; updating the PR body should trigger review, or a maintainer can comment @clawsweeper re-review if needed.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body provides focused tests and static checks, but no redacted after-fix browser or live HTTP evidence from a running ClawHub instance; add proof showing the publisher profile link and its endpoint response, without private data. 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] Publishing sequence: 0 for changing feed bodies makes the advertised v1 revision contract unreliable for clients that deduplicate, cache, replay, or roll back feed state.
• [P1] Reporting nextCursor: null after bounded source scans can silently hide public publisher entries while telling clients that the feed is complete.
• [P1] The branch introduces an accounts API alongside the publisher API that its stated dependency now treats as canonical; landing both without an explicit API decision would create a long-lived compatibility surface.
• [P1] The branch currently conflicts with main, so its effective merge result has not been reviewed against current behavior.

Maintainer options:

1. Resolve the canonical feed contract first (recommended)
   Fix persisted monotonic revisions and truthful pagination, then rebase the profile-link work on the maintainer-selected publisher/account API surface.
2. Approve dual account and publisher APIs
   Accept the permanent compatibility cost only after explicitly documenting why clients need both public identity scopes and how their contracts differ.
3. Pause this stacked branch
   Do not merge the conflicted stack if the publisher-only dependency remains the preferred product direction.

Next step before merge

• [P1] A maintainer must select the permanent public API scope before the concrete contract fixes can be safely applied; proof also must come from the contributor's real setup.

Maintainer decision needed

• Question: Should ClawHub expose a permanent account-scoped public feed API in addition to the publisher-scoped feed, or keep publisher identity as the single public feed surface?
• Rationale: The branch adds both surfaces, while its declared prerequisite describes a publisher-only model; this defines a versioned public API and cannot be safely selected by an automated repair.
• Likely owner: Patrick-Erichsen — Their exact-head review establishes active technical ownership of the unresolved v1 feed-contract decisions.
• Options:
  • Keep publisher-only feeds (recommended): Land or adapt the canonical publisher-feed contract first, then retain this PR only as a narrow publisher-profile Feed-link follow-up.
  • Approve both identity scopes: Document the distinct account and publisher semantics, upgrade guarantees, and ownership of both v1 endpoint families before resolving the contract defects.
  • Pause the feed surface: Defer the public API until maintainers settle the identity and snapshot protocol direction.

Security
Cleared: The diff adds public discovery endpoints but no concrete credential, authorization, dependency, workflow, or supply-chain regression was identified in the reviewed patch.

Review findings

• [P1] Persist a monotonic feed revision — convex/accountFeeds.ts:188
• [P1] Do not mark bounded scans as terminal — convex/accountFeeds.ts:194
• [P1] Align the accounts API with the selected public feed scope — convex/http.ts:315-318

Review details

Best possible solution:

Decide whether public feeds are publisher-only or also need account-scoped endpoints; then land one coherent persisted-snapshot contract with monotonic revisions and honest continuation or capacity failure, rebase the UI link onto that contract, and show the rendered link plus a live endpoint response from a running ClawHub instance.

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

Not applicable: this is a new feature rather than a report of broken existing behavior. The remaining concerns are directly observable from the proposed public contract and the collaborator's current-head review comments.

Is this the best way to solve the issue?

No. The current stacked branch is not the narrowest maintainable path because its public API scope conflicts with the declared publisher-only dependency and its feed contract is incomplete; settle the canonical API first, then keep the profile link as a small follow-up.

Full review comments:

• [P1] Persist a monotonic feed revision — convex/accountFeeds.ts:188
  The response hardcodes sequence to 0 while generatedAt and entries are recomputed. Any client that uses the documented revision to deduplicate or validate replay will treat changed feed bodies as the same version; persist and increment a coherent publication revision before exposing this as v1.
  Confidence: 0.98
• [P1] Do not mark bounded scans as terminal — convex/accountFeeds.ts:194
  The collectors stop after three source pages, but the response reports nextCursor: null. When older public packages or skills remain beyond that cap, callers receive a successful yet silently incomplete terminal feed; return a continuation, a capacity error, or scan through completion.
  Confidence: 0.98
• [P1] Align the accounts API with the selected public feed scope — convex/http.ts:315-318
  This route adds a parallel /accounts v1 surface even though the stated prerequisite describes publisher identity as the canonical public feed model. Do not create both public API families until maintainers approve their distinct contract and compatibility obligations; otherwise keep this follow-up publisher-only.
  Confidence: 0.91

Overall correctness: patch is incorrect
Overall confidence: 0.96

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P2: This is a normal-priority new discoverability feature, but the public v1 contract must be corrected before it can safely land.
• merge-risk: 🚨 compatibility: The PR creates versioned public account and publisher feed endpoints whose identity scope and revision semantics would become client compatibility commitments.
• 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 provides focused tests and static checks, but no redacted after-fix browser or live HTTP evidence from a running ClawHub instance; add proof showing the publisher profile link and its endpoint response, without private data. 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:

• Outstanding v1 feed-contract review: A collaborator review on the current head identifies that the feed response reports sequence: 0 for every request even though its contents can change, so clients cannot distinguish revisions for replay or cache validation. (convex/accountFeeds.ts, fd30abc07ab1)
• Incomplete-feed review: The current-head review also identifies that the bounded three-page collectors can stop before older public entries while the response still declares nextCursor: null, silently presenting an incomplete result as terminal. (convex/accountFeeds.ts, fd30abc07ab1)
• Stacked dependency remains open: The PR body depends on feat: add publisher feed model API #2948, which remains open, is not a safe landed replacement, and describes a publisher-only contract rather than this branch's parallel accounts surface. (convex/http.ts, fd30abc07ab1)
• Scope and merge state: The proposed branch changes 26 files with 1,910 additions and 78 deletions, while GitHub reports its mergeability as dirty; it therefore needs an updated, narrowly scoped merge result rather than a direct landing. (src/routes/user/$handle.tsx, fd30abc07ab1)
• Repository review policy: Repository guidance requires real ClawHub-instance browser proof for UI changes and focused validation before PR handoff; the PR body provides test and static-check output only. (AGENTS.md, aaa73625ed41)

Likely related people:

• Patrick-Erichsen: Provided the two current-head P1 review comments on coherent feed revisions and truthful pagination/completeness semantics. (role: reviewer of the v1 feed contract; confidence: high; files: convex/accountFeeds.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 (3 earlier review cycles)

• reviewed 2026-07-04T01:06:43.081Z sha 72b804f431ad7cac64b50adecb2c8ab778f247cf :: needs real behavior proof before merge. :: none
• reviewed 2026-07-04T08:23:17.028Z sha 72b804f431ad7cac64b50adecb2c8ab778f247cf :: needs real behavior proof before merge. :: none
• reviewed 2026-07-06T23:36:54.206Z sha 72b804f431ad7cac64b50adecb2c8ab778f247cf :: needs real behavior proof before merge. :: none

[github-actions]

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

[Patrick-Erichsen]

This branch adds a canonical, encoded Feed link to publisher profiles, but because it still targets main it also publishes the full account-feed API from #2948. The link helper itself is sound; the included v1 feed semantics have two blocking contract gaps.

LOC: +1910/-78 (26 files)

Best-fix verdict: too early in the stack. Fix the revision and bounded-pagination semantics in #2948, then keep #2959 as the small profile-discoverability child.

Alternatives considered: Hiding only the profile link does not fix the public routes already included from #2948. Documenting this as a latest-items projection does not fix changing bodies under one revision or successful terminal responses that can omit all older public entries.

Evidence checked: current origin/main (3134a204), clean merge tree, #2948 ancestry, RFC #39 head 92846d1f, schema/spec/OpenAPI paths, account-feed collectors and tests, HTTP/cache routing, catalog-feed publication behavior, both profile routes, and the 47-test focused suite. Exact-head static/unit/types/packages/e2e/smoke/security checks pass; the unrelated inspector-version local-auth shard fails during fixture/bootstrap setup.

Remaining uncertainty: no real-browser/live-Convex proof of the new link and API was supplied, but that does not affect either deterministic blocker below.

[Patrick-Erichsen]

[P1] Give each changed feed body a monotonic revision. generatedAt and entries are recomputed on every request, but this hardcodes sequence to 0 forever. Both specs/account-feeds.md and RFC #39 define this field as the monotonic revision for cache/replay/rollback checks, and the canonical catalog feed persists and increments its sequence. A client deduplicating by sequence can therefore treat changed feed contents as the same revision. Persist and increment a coherent feed revision, or do not expose this as the stable v1 contract until that state exists.

[Patrick-Erichsen]

[P1] Do not report bounded-scan exhaustion as a terminal feed. Both source collectors stop after three pages, but this call always emits nextCursor: null; convex/accountFeeds.test.ts already demonstrates that an older public package can exist while the response is an empty, apparently complete feed. Return an opaque continuation or an explicit bounded-scan error/diagnostic (or scan to the true end) instead of a successful terminal response that silently drops discoverable entries.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: feat: expose publisher account feed URLs This is item 1/1 in the current shard. Shard 10/18.

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 this raw publisher-feed link surface rather than carrying another review unit. The preferred consumption path is the signed publisher-follow workflow tracked by openclaw/openclaw#109397 and its gateway/UI follow-ups; we can redesign explicit feed-link discovery later if real demand remains.