feat: add grouped publisher following activity

[giodl73-repo]

Summary

• records one deduplicated activity event per eligible skill or plugin release
• coalesces repository/commit publication batches so a 50-artifact release is one activity group
• serves presentation-neutral following and inbox projections over the same grouped substrate
• paginates compact groups per followed publisher and expands a group only on demand
• re-checks current follow, publisher visibility, artifact visibility, exact-release moderation, ownership, and deletion during hydration
• removes granular events and groups in bounded, resumable deletion phases

Product shape

This PR is backend-only. following includes every followed publisher; inbox excludes publishers whose delivery preference is muted. The next PR adds private Inbox read state and UI. A future Facebook/X-style Following page can render the same groups chronologically without a second event store or migration.

This lane is independent of signed publisher-feed consumption in OpenClaw and has no trust, install, approval, email, or webhook implication.

Stack

Depends on #2950 (and transitively #2948). The branch is commit-stacked because cross-fork PRs cannot select another fork branch as their base.

Scale proof

• 50 skills from one repository commit plus one unrelated plugin produce 2 groups, not 51 inbox rows
• group previews hydrate at most 3 visible artifacts
• group expansion and cleanup remain bounded

Validation

• focused activity, follows, publication, publisher deletion, account deletion, and package visibility suites: 543 tests passed during restack
• targeted grouped projection suite passes after the final split
• schema package build and 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 22, 2026, 1:32 AM ET / 05:32 UTC.

Summary
This PR adds publisher follow controls and public follow APIs, a followed-publisher discovery view, and a pull-based publisher release-activity timeline across Convex, HTTP, UI, schemas, tests, and docs.

Reproducibility: not applicable. This PR proposes a new product capability rather than reporting broken established behavior. The missing evidence is after-fix real behavior proof, not a bug reproduction.

Review metrics: 2 noteworthy metrics.

• Feature breadth: 47 files affected; 5,549 additions and 148 deletions. The proposed social feature spans persistent storage, public APIs, backend publication paths, UI, schemas, and documentation, so dependency and product-boundary review matter before merge.
• Patch history: 19 commits. The branch contains multiple corrective iterations after collaborator review, making a fresh current-base merge and runtime proof more valuable than another isolated static pass.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦐 gold shrimp
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 proof of follow/unfollow, eligible publication activity, moderation/deletion filtering, pagination, and the rendered timeline.
• Rebase after the dependency at feat: add private publisher follow graph #2950 is resolved, then provide a current-head merge and validation refresh.
• Obtain explicit maintainer sponsorship for the public social-graph and timeline product boundary.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR body reports focused tests and static checks, but does not provide redacted after-fix live API, Convex, or browser evidence for follow/unfollow, visibility filtering, deletion handling, and the rendered timeline; add that proof and update the PR body for automatic re-review, or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• [P1] The PR creates durable follow records and public follower/following discovery endpoints; maintainers need to explicitly accept the intended privacy and product boundary before merging.
• [P1] The branch depends on the open follow-graph implementation at feat: add private publisher follow graph #2950 and is currently reported dirty against its base, so a refreshed merge result is needed before final review.
• [P1] There is no redacted after-fix live evidence showing follow/unfollow, moderation or deletion filtering, and the rendered timeline together.

Maintainer options:

1. Land in dependency order with upgrade proof
   Approve the product direction only after feat: add private publisher follow graph #2950 is resolved, this branch is rebased, and runtime evidence demonstrates existing account, publisher visibility, moderation, and deletion behavior remains safe.
2. Accept the public social-graph contract
   Maintainers may intentionally accept the new public follower/following visibility and persistent follow-state contract after documenting its privacy expectations.
3. Pause the ClawHub social feature
   Defer the timeline and profile controls if maintainers do not want ClawHub to own relationship-state privacy, retention, and support obligations.

Next step before merge

• [P1] A maintainer must choose the product and privacy boundary, and the contributor must supply real behavior proof; there is no narrow mechanical repair to dispatch safely.

Maintainer decision needed

• Question: Should ClawHub own a durable public publisher-follow graph and pull-based activity timeline as a supported product surface after the foundational follow-graph PR lands?
• Rationale: The implementation adds new persistent social state, public relationship visibility, and UI discovery behavior; correctness review cannot determine whether that product and privacy boundary is desired.
• Likely owner: Patrick-Erichsen — Their collaborator review directly covers the release-visibility and timeline-safety behavior that must remain correct if the product direction is approved.
• Options:
  • Sponsor staged pull-only discovery (recommended): Accept the no-notification social-discovery boundary, land the dependency first, then require a rebased branch and real end-to-end proof.
  • Keep publisher discovery API-only: Retain a narrower public feed/follow API direction and defer ClawHub UI controls and activity timeline until user demand is established.
  • Defer the social surface: Pause this feature and keep publisher updates limited to existing catalog and client-side watch workflows.

Security
Cleared: No concrete new security or supply-chain defect is established from the supplied patch and review history, but the public social-graph boundary remains a maintainer product and privacy decision.

Review details

Best possible solution:

Make a maintainer-approved, pull-only publisher discovery feature land in a refreshed dependency order, with durable privacy invariants and redacted live proof covering the public API and signed-in UI flows.

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

Not applicable: this PR proposes a new product capability rather than reporting broken established behavior. The missing evidence is after-fix real behavior proof, not a bug reproduction.

Is this the best way to solve the issue?

Unclear: the implementation is a coherent pull-based alternative to notification fanout, but whether ClawHub should own this durable public social surface requires explicit maintainer direction before it can be considered the best solution.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add merge-risk: 🚨 compatibility: The PR introduces persistent follow state and new public API contracts whose upgrade and long-term support behavior must be intentionally accepted.

Label justifications:

• P3: This is an optional social/discovery feature rather than a current user-facing regression or release-blocking defect.
• merge-risk: 🚨 compatibility: The PR introduces persistent follow state and new public API contracts whose upgrade and long-term support behavior must be intentionally accepted.
• merge-risk: 🚨 security-boundary: Public follower/following discovery and private follow storage expand relationship-visibility and account-data boundaries beyond the existing catalog surface.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦐 gold shrimp.
• 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 reports focused tests and static checks, but does not provide redacted after-fix live API, Convex, or browser evidence for follow/unfollow, visibility filtering, deletion handling, and the rendered timeline; add that proof and update the PR body for automatic re-review, or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Broad new feature surface: The branch adds follow-graph persistence, public HTTP routes, activity timeline storage, UI controls, API schema, specs, and tests; this is a product feature rather than a narrow bug fix. (convex/publisherFollows.ts:1, 668192815c31)
• Open dependency: The PR body identifies the publisher follow graph as a dependency, and the related implementation remains open at feat: add private publisher follow graph #2950; the final landing shape should be evaluated after that dependency is resolved and the branch is refreshed. (40345239f950)
• Prior review continuity: The latest completed ClawSweeper cycle found no remaining discrete patch defect, but required after-fix runtime proof. The supplied PR body still lists tests and static validation only, without a redacted live follow/unfollow, activity filtering, and timeline demonstration. (668192815c31)
• Maintainer review history: A collaborator reviewed release visibility, event timing, and scheduler behavior on the earlier branch; the current head includes later repair commits and should be evaluated as a refreshed product proposal rather than closed as an obsolete branch. (convex/publisherActivity.ts:1, 668192815c31)

Likely related people:

• Patrick-Erichsen: Provided the concrete collaborator review on release-visibility, activity ordering, and scheduler safety in this feature area; likely useful for routing the remaining technical review. (role: reviewer; confidence: medium; files: convex/packages.ts, convex/skills.ts, convex/publisherActivity.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.

Review history (5 earlier review cycles)

• reviewed 2026-07-04T08:26:02.356Z sha 404620ec5597570ae501554daff562629fdfa37b :: needs real behavior proof before merge. :: [P2] Gate notifications on the new release scan status
• reviewed 2026-07-07T23:46:59.981Z sha 404620ec5597570ae501554daff562629fdfa37b :: needs real behavior proof before merge. :: [P2] Gate notifications on the new release scan status
• reviewed 2026-07-08T01:25:49.395Z sha 404620ec5597570ae501554daff562629fdfa37b :: needs real behavior proof before merge. :: [P2] Gate notifications on the new release scan status
• reviewed 2026-07-09T02:13:33.774Z sha 404620ec5597570ae501554daff562629fdfa37b :: needs real behavior proof before merge. :: [P2] Gate notifications on the new release scan status
• reviewed 2026-07-21T16:57:19.056Z sha 6681928 :: needs real behavior proof before merge. :: none

[Patrick-Erichsen]

Reviewed exact head 1a780b6929e9bc16c5b6f113df192befcc5f6192. LOC: +2039/-1 (19 files). This adds durable private publisher-follow notifications and bounded continuation fanout. I found three actionable blockers; no approval submitted.

Best-fix verdict: too narrow / not merge-ready. Keep notifications discovery-only, but derive package eligibility from the inserted release, carry immutable publication time/audience eligibility through fanout, and repair the exact-head test regression. A synchronous unbounded fanout was considered and rejected because it would violate Convex transaction bounds; a durable event row or immutable eventAt passed through the existing cursor jobs is the appropriate layer.

Code read: publish callers in convex/skills.ts and convex/packages.ts; fanout/list/read paths in convex/publisherNotifications.ts; follow mutations/indexes in convex/publisherFollows.ts and convex/schema.ts; retention, HTTP/auth boundaries, tests, current origin/main, the local follow spec, and RFC 0009.

Remaining uncertainty: the PR provides no real Convex/API/browser proof, and no frontend currently consumes publisherNotifications.listMine.

[Patrick-Erichsen]

[P1] Gate backport notifications on the inserted release

For a non-latest release, this falls back to pkg.scanStatus, which describes the existing latest package rather than releaseId. A clean latest plus a newly blocked backport therefore satisfies shouldNotifyPackageFollowers and advertises content that release visibility/download paths should reject. Derive notification eligibility from the inserted release resolved scan verdict using the same source/helper as public release visibility, and add a blocked non-latest regression test.

[Patrick-Erichsen]

[P1] Snapshot publication time and audience eligibility

now is fanout-job time, while every page queries the current follow graph. A user who follows or unmutes after publication but before a delayed job runs receives the older event, and continuation pages can get different timestamps, so delayed/interleaved publications sort by worker timing rather than publication order. Pass an immutable eventAt from the publish mutation through every continuation, constrain eligible follows to the state that existed at that event (or persist an event/audience snapshot), and store that event time for ordering. Add follow/unmute-after-publish and interleaved-page tests.

[Patrick-Erichsen]

[P1] Repair the exact-head scheduler regression

This added runAfter call makes convex/skills.rateLimit.test.ts fail at the existing expect(runAfter).not.toHaveBeenCalled() assertion for static-malicious publishes. Exact-head CI run 29430178303 and a local rerun both reproduce the failure. Update that test to identify scheduled functions with getFunctionName, assert that users:autobanMalwareAuthorInternal is absent, and separately assert the expected notification schedule so the safety invariant remains covered without rejecting all scheduling.

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