fix: hide package resources when owners are banned

[vyctorbrzezowski]

Summary

When a personal account is banned or deleted, its personal package resources disappear too. Packages owned by an org stay with the org, even if an old user field still points at the banned account.

What changed

• Personal/no-publisher packages and releases are hidden when their owner is banned or deletes their account.
• Package publish tokens for those personal rows are revoked during ban/account deletion.
• packages.softDeletedReason distinguishes ban-hidden packages from account-deleted packages.
• Unban restore only restores packages hidden by the matching ban.
• Org-owned packages are preserved even when a banned user remains in a legacy ownerUserId field.

Public behavior

Personal package resources become unavailable when the owning account is banned or deleted. Ban-hidden personal package resources are restored only by the matching unban batch.

Org-owned package resources remain owned by the org and are not hidden just because one member, or a legacy ownerUserId, is sanctioned.

Policy note for maintainer review: this PR intentionally treats personal package resources as sanction-bound while preserving org-owned resources.

Behavior proof

Live Convex runtime proof from ban, delete, unban, package soft-delete, token revocation, and org-owned preservation:

$ bunx convex run --push --typecheck=disable --codegen disable proof2283:run
- Preparing Convex functions...

✔ Convex functions ready!
{
  "afterBan": {
    "packages": [
      {
        "packageId": "<personal-package>",
        "softDeletedAt": "<ban-timestamp>",
        "softDeletedReason": "user.banned"
      },
      {
        "packageId": "<org-owned-package>",
        "softDeletedAt": null,
        "softDeletedReason": null
      }
    ],
    "tokenRevokedAt": "<ban-timestamp>"
  },
  "afterUnban": {
    "packages": [
      {
        "packageId": "<personal-package>",
        "softDeletedAt": null,
        "softDeletedReason": null
      },
      {
        "packageId": "<org-owned-package>",
        "softDeletedAt": null,
        "softDeletedReason": null
      }
    ],
    "tokenRevokedAt": "<ban-timestamp>"
  },
  "deletedAfter": {
    "packages": [
      {
        "packageId": "<personal-deleted-package>",
        "softDeletedAt": "<delete-timestamp>",
        "softDeletedReason": "user.deactivated"
      }
    ],
    "tokenRevokedAt": null
  },
  "deletedRestoreResult": {
    "ok": true,
    "restoredCount": 0,
    "scheduled": false,
    "stale": true
  }
}

This proof shows a personal package hidden on ban with its publish token revoked, the org-owned package preserved, the personal package restored on matching unban, and account-deleted package state staying non-restorable.

Focused regression suite:

$ bun run test convex/packages.public.test.ts convex/packages.publisher.test.ts
Test Files  2 passed (2)
Tests       184 passed (184)

Validation

$ bun run ci:unit
Test Files  204 passed (204)
Tests       1994 passed (1994)
Statements  85.98%
Branches    75.17%
Functions   86.37%
Lines        89.48%

$ bun run ci:types-build
tsc, package typechecks, clawhub-mod typecheck, Vite build, and Nitro build passed.

Current GitHub CI for this head has packages, types-build, e2e-http, and playwright-smoke passing, with playwright-local-auth still running at the time of this update. The static job currently stops at bun audit on the existing transitive ws advisory GHSA-58qx-3vcg-4xpx.

[vercel]

@vyctorbrzezowski is attempting to deploy a commit to the Amantus Machina Team on Vercel.

A member of the Team first needs to authorize it.

[clawsweeper]

Codex review: needs maintainer review before merge.

Latest ClawSweeper review: 2026-05-23 22:51 UTC / May 23, 2026, 6:51 PM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
The PR soft-deletes personal package/plugin resources and revokes package publish tokens during ban or account deletion, restores only matching ban-hidden packages on unban, preserves org-owned packages, and updates tests, spec, UI copy, and changelog.

Reproducibility: yes. Source inspection on current main shows ban/delete flows do not touch packages or package publish tokens, while package reads already hide rows with softDeletedAt.

PR rating
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Summary: Strong runtime proof and focused regression coverage make the PR reviewable, with overall quality held to normal mergeable because the policy change needs maintainer acceptance.

Rank-up moves:

• Confirm the intended policy that personal package publish tokens stay revoked after unban and must be recreated.

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.

Real behavior proof
Sufficient (live_output): The PR body includes after-fix Convex runtime output showing ban/delete/unban package effects, token revocation, and org-owned preservation, with focused tests and CI output as support.

Risk before merge

• Merging intentionally makes banned or deactivated personal package resources unavailable and revokes personal package publish tokens, so recovered users may need to recreate publish tokens before publishing again.
• The personal-resource versus org-resource preservation rule is a moderation and authorization policy boundary that CI cannot decide for maintainers.

Maintainer options:

1. Accept the package sanction policy (recommended)
   Merge once a maintainer explicitly accepts personal package hiding, publish-token revocation, and matching-ban restore as the intended package moderation policy.
2. Hold for a different recovery policy
   Pause if maintainers want unban to restore publish capability automatically, require package-count API/CLI reporting before merge, or stage operator notice before personal packages disappear.

Next step before merge
Maintainer review should decide the package sanction and token-revocation policy before merge; I found no narrow automated repair to queue.

Security
Cleared: The diff is security-sensitive but I found no concrete supply-chain, authorization, or secret-handling regression in the proposed code path.

Review details

Best possible solution:

Land a maintainer-approved moderation policy that sanctions personal package resources, preserves org-owned resources, keeps publish tokens revoked after sanctions, and preserves the matching-ban restore invariant with regression coverage.

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

Yes. Source inspection on current main shows ban/delete flows do not touch packages or package publish tokens, while package reads already hide rows with softDeletedAt.

Is this the best way to solve the issue?

Yes, pending maintainer policy sign-off. Reusing the existing package soft-delete/search-digest path with indexed owner batches and focused token revocation is the narrowest maintainable implementation I found.

Label justifications:

• P1: The PR addresses a security-sensitive moderation gap where banned or deleted personal owners can leave package catalog resources and publish tokens active.
• merge-risk: 🚨 compatibility: Existing personal package publishing workflows can stop after merge because ban or deletion now hides packages and revokes publish tokens.
• merge-risk: 🚨 security-boundary: The diff changes marketplace resource visibility, token revocation, and unban restore behavior at an authorization and moderation boundary.
• rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🦞 diamond lobster, patch quality is 🐚 platinum hermit, and Strong runtime proof and focused regression coverage make the PR reviewable, with overall quality held to normal mergeable because the policy change needs maintainer acceptance.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes after-fix Convex runtime output showing ban/delete/unban package effects, token revocation, and org-owned preservation, with focused tests and CI output as support.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix Convex runtime output showing ban/delete/unban package effects, token revocation, and org-owned preservation, with focused tests and CI output as support.

What I checked:

• Live PR state and proof: The live PR is open and mergeable at head 352734f; the PR body includes redacted Convex runtime output for ban, delete, unban, token revocation, and org-owned preservation, plus focused test and CI command output. (352734f88b05)
• Current main gap: Current main's user ban/delete flow revokes API tokens and handles skills/comments/user state, but the inspected code path does not call package batch mutations or package publish-token revocation. (convex/users.ts:1573, c9e105fa3465)
• Current package visibility boundary: Current package read paths already hide packages/releases with softDeletedAt, so the PR's use of package soft-delete state matches the existing visibility lever. (convex/packages.ts:726, c9e105fa3465)
• Candidate package implementation: The PR adds indexed owner batch mutations for ban, unban, and account deletion, distinguishes personal ownership from org ownership, writes softDeletedReason, and revokes active package publish tokens. (convex/packages.ts:2937, 352734f88b05)
• Candidate user-flow wiring: The PR wires account deletion, manual ban, manual unban, and malware autoban through the package batch mutations, including the in-flight ban allowance before users.deletedAt is committed. (convex/users.ts:523, 352734f88b05)
• Regression coverage: The candidate tests cover package ban soft-delete, token revocation, stale batch stops, in-flight pagination, org-owned preservation, matching-ban restore, account-deletion marking, and owner self-restore denial. (convex/packages.public.test.ts:6947, 352734f88b05)

Likely related people:

• Patrick Erichsen: Current-main blame and recent history cover the central package deletion, autoban remediation, and user moderation helpers affected by this PR. (role: recent area contributor; confidence: high; commits: b753b1f7ab0e, 0c7607bd6408, 6814af95dff0; files: convex/packages.ts, convex/users.ts, convex/schema.ts)
• Peter Steinberger: Earlier history includes moderation/admin UX, HTTP moderation batches, and package/API tooling adjacent to the sanction and management-copy behavior changed here. (role: adjacent owner; confidence: medium; commits: a4b850ec3362, a24d3e98098c, f94e20d4c35f; files: convex/users.ts, convex/packages.ts, src/routes/management.tsx)
• Onur: Introduced package trusted publishing via GitHub OIDC, adjacent to the package publish-token surface this PR revokes during sanctions. (role: feature introducer; confidence: medium; commits: 8592272720fe; files: convex/packages.ts, convex/packagePublishTokens.ts, convex/schema.ts)

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

[vyctorbrzezowski]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Superseded
• Detail: A newer re-review for this item started before this run finished, so GitHub cancelled this older run. Check the latest ClawSweeper run for the current result.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26042295469
• Updated: 2026-05-18T15:17:29.180Z

[vyctorbrzezowski]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26058439498
• Updated: 2026-05-18T20:34:02.965Z

[clawsweeper]

ClawSweeper PR egg

✨ Hatched: 🥚 common Moonlit Patch Peep

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: sleeps inside passing CI.
Image traits: location green-check meadow; accessory proof snapshot camera; palette moss green and polished brass; mood curious; pose curling around a status light; shell starlit enamel shell; lighting soft underwater shimmer; background delicate sparkle particles.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Moonlit Patch Peep in ClawSweeper.

What is this egg doing here?

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.