后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载本文围绕 ClawHub 的「组织与命名空间认领」机制展开当 org handle、包 scope、owner handle、skill slug 或包命名空间被抢占、保留、误导或存在归属争议时如何准备公开证据、规避敏感信息、选择合适的申诉渠道并最终推动 staff 做出保留、转移、改名、隔离等处置。读完本文你既能掌握提交认领申请前的完整实操清单也能理解 ClawHub 后端用reservedSlugs/reservedHandles两张保留表实现的冷却期cooldown与「 rightful owner 」回收逻辑从而在发布被命名空间已被占用拦截时定位根本原因。命名空间在 ClawHub 中的角色ClawHub 把以下五类标识符当作公开命名空间来管理owner handle发布者的个人 handle如acmeorg handle组织发布者的 handleskill slug技能的公开短名决定clawhub install slug与详情页 URLplugin 包名插件包的名称包 scope例如example-org/*这类作用域规定哪些包可以挂在该 scope 下发布。如果某个命名空间在现实世界中确实属于某个项目、品牌、包生态或组织但在 ClawHub 上已被他人认领claimed、被保留reserved、具有误导性或存在争议文档给出的处置路径是通过项目 GitHub 仓库中的Org / Namespace Claimissue 模板仓库 issue 表单请求 staff 进行公开审查。这条路径专门用于公开的、非敏感的归属权审查。文档特别强调两个不要用不要用产品内的 report举报流程处理命名空间争议不要用账户申诉account appeal表单处理命名空间认领——它们解决的是不同问题行为/安全问题 vs 归属问题。这一点在仓库的 RFC 草稿 RFC 0001: Org Claim Disputes and Account Recovery After Owner-Initiated Deletion 中同样被作为核心目标列出让组织/owner 命名空间认领、争议、以及 owner 主动删号后的恢复路径变得可预期并把公开政策与私有审查证据处理分离开。该 RFC 仍处于 Draft 状态其中列出的开放问题认领需要哪些证据、争议需要哪些证据、命名空间对应到已删/失活 owner 时如何处置正是本文档所回答的内容。何时应该提交认领申请当你认为 ClawHub staff 应当审查一个命名空间是否应该被保留reserve、转移transfer、改名rename、隐藏hide、隔离quarantine、加别名alias或以其他方式变更原因均为现实世界的归属权时就应该提交 claim。文档列举的典型场景org handle 与你的 GitHub org / 项目 / 公司 / 社区对应——例如你的项目组织在 GitHub 叫acme-corpClawHub 上同名的 org 却不是你的包 scope 应该只允许匹配的 owner 发布——如example-org/*只应由 ClawHub 上对应的example-org发布者使用skill slug 或插件包名疑似冒充某个项目impersonation品牌、商标、项目改名或包历史争议原 owner 已删除、失活或无法联系阻塞了正当命名空间持有者。文档同时划清了一条边界如果该 listing 除了归属争议之外还不安全、恶意或误导性应同时按相应的审核moderation与安全security指引走应急流程。命名空间认领表单不是紧急漏洞披露通道。对应到仓库文档就是 docs/moderation.md 与 docs/security.md 所描述的通道。提交前先确认自己能管到什么程度文档要求提交 claim 前先确认两件事第一确认你正在用与命名空间匹配的 owner 发布。对插件包而言scoped 名称如example-org/example-plugin必须以对应的example-orgowner 身份发布。这不是形式要求而是后端在包身份解析时就会校验的硬约束——在 convex/lib/packageRuntimeIdentity.ts 中可以看到若插件的 runtime id 与同一 publisher 命名空间下另一个已认领的包冲突会直接抛出 already claimed by another package in this publisher namespace 错误。第二如果你能管理当前 owner就直接自助修复不要走 claim。可自助的修复手段包括发布、改名、转移、隐藏或删除受影响资源。只有当你无法管理当前 owner、或需要 staff 裁决归属争议时才使用 claim 流程。这个能自助就不申诉的原则也和后文可能的结果一致staff 的处置空间很大但前提是确实存在需要平台介入的争议。证据准备只放公开的、非敏感的证据这是 claim 质量最关键的章节。文档要求使用公开、非敏感的证据并给出了一份有用证据清单建议逐条对照准备证据类型用途GitHub org、repo、release 或 maintainer 历史证明你在该项目生态中的真实身份与持续参与指明该命名空间的官方项目文档证明命名空间与项目的官方对应关系域名或官方邮箱域名证明证明你对品牌域/邮件域的控制权npm、PyPI、crates.io 等其他包注册中心的 scope 控制权证明跨生态的命名空间归属一致性可公开讨论的商标、品牌或项目所有权证据处理品牌/商标类争议源码仓库历史、包历史、公开的改名公告证明命名空间的历史沿革与改名事实争议的 ClawHub owner / skill / plugin / package / issue 链接精确指向被争议的对象文档还有一条容易被忽视但非常实操的要求解释每条链接分别证明了什么。目标是让 staff 无需索取任何私有凭据或密钥就能理解你与争议命名空间之间的归属关系。证据链应做到自解释。必须排除的内容不要把敏感证明放进公开 issue由于 claim 走的是公开 GitHub issue文档明确列出了严禁包含的材料API token、签名密钥、任何凭据DNS 验证 token域名归属验证挑战串私有法律文件或合同个人身份证明文件私人邮件、私有安全报告、机密客户数据。对于确实只能以私有形式呈现的敏感证据claim 表单本身提供了选项勾选敏感证据需要私有 staff 通道通过私密渠道提交而不是公开粘贴。这条设计与 RFC 0001 中公开政策与私有审查员专属检查、敏感证据处理相分离的非目标non-goal是同一思路。可能的处置结果与审查权衡根据证据强度与风险ClawHub staff 可以采取的处置包括保留命名空间reserve将该名称锁定防止被抢占转移所有权transfer ownership把资源归属转给正当持有者改名rename resource变更争议资源名称以解除混淆隐藏或隔离hide / quarantine existing listing对既有 listing 做可见性处置加别名或重定向alias or redirect要求补充证据ask for more proof驳回decline。文档明确声明命名空间审查并不保证每个看起来匹配的名称都会被判转移。staff 的裁决会综合权衡四类因素公开证据、既有使用情况、安全风险、对用户的影响。这解释了为什么证据要公开、可自解释如此重要——私有证据无法进入这个权衡过程。源码纵深ClawHub 如何保留一个命名空间上面的处置手段保留、转移、隔离、隐藏在 ClawHub 后端都有对应的数据模型与实现理解了它们你就能准确预期 claim 之后系统里实际发生了什么。reservedSlugsskill slug 的冷却期保留表在 convex/schema.ts 中定义了reservedSlugs表const reservedSlugs defineTable({ slug: v.string(), originalOwnerUserId: v.id(users), originalOwnerPublisherId: v.optional(v.id(publishers)), deletedAt: v.number(), expiresAt: v.number(), reason: v.optional(v.string()), releasedAt: v.optional(v.number()), })每个保留记录绑定被保留的 slug、原 owner用户 可选的 publisher、删除时间、过期时间保留期截止点、保留原因以及releasedAt——一旦写入即视为已释放。索引by_slug_active_deletedAt让查某 slug 当前活跃保留成为 O(1) 级别的索引查询。真正的拦截发生在发布路径上。convex/lib/reservedSlugs.ts 中的enforceReservedSlugCooldownForNewSkill是核心if ( latest.expiresAt params.now !canReleaseReservedSlugForPublisher(latest, params.ownerPublisher, params.userId) ) { throw new ConvexError(formatReservedSlugCooldownMessage(params.slug, latest.expiresAt)); }逻辑可以概括为三步查询该 slug 上最新的、与当前 publisher scope 匹配的活跃保留记录scope 匹配优先按originalOwnerPublisherId无 publisher 时退回originalOwnerUserId见reservationMatchesPublisherScope若保留期未过期expiresAt now且当前发布者无权释放它抛出Slug slug is reserved for its previous owner until ISO 时间. Please choose a different slug.错误若当前发布者就是被授权的原 ownercanReleaseReservedSlugForPublisher对 org 类型 publisher 直接放行对 user 类型要求 linked user 与原 owner 一致则把releasedAt打上当前时间戳主动释放该保留——即原主回来就能立刻收回。这张表还有两个与 claim 场景直接相关的写入函数reserveSlugForHardDeleteFinalizeL123-L163资源被硬删finalize时自动为原 owner 建立保留并把同 scope 下重复的旧保留记录批量释放releaseDuplicateActiveReservations保证一个 scope 内只有一条权威记录upsertReservedSlugForRightfulOwnerL165-L199这正是认领裁决生效后的落库动作——staff 判定某用户是 rightful owner 后该函数会把现有保留记录改写为指向 rightful owner更新originalOwnerUserId、expiresAt、reason没有记录则插入新记录随后清理重复项。对应文档里transfer ownership / reserve 的可能结果。reservedHandlesowner / org handle 的保留表handle 层有对称的模型。convex/schema.ts 中的reservedHandles表const reservedHandles defineTable({ handle: v.string(), rightfulOwnerUserId: v.id(users), reason: v.optional(v.string()), releasedAt: v.optional(v.number()), createdAt: v.number(), updatedAt: v.number(), })与reservedSlugs不同它显式以rightfulOwnerUserId命名字段——即正当持有者这与文档中deleted, inactive, or unreachable owner that blocks the rightful namespace owner 的场景直接对应handle 被保留后只有被记录的 rightful owner 可以取回。配套实现在 convex/lib/reservedHandles.ts 及其测试 convex/lib/reservedHandles.test.ts。handle 侧还有两类相关行为可以在源码中验证抢注拦截convex/publishers.ts 中用户尝试注册 handle 时若已被占用会抛出User handle handle is claimed by another user错误——这是命名空间已被 claim提示的直接来源之一已删除 org handle 的收回convex/publishers.ts 定义了内部 mutationreclaimDeletedOrgHandleInternal它要求该 publisher 处于已删除状态、无活跃 skills 或 packages且需要二次确认 tokenreclaim-deleted-org:handle完成后写入publisher.org.reclaim_deleted_handle审计事件。这对应文档Possible Outcomes 中对已删/失活 owner 的处置路径也呼应了 RFC 0001 中owner 主动删号后的恢复路径这一开放问题。从实现看申诉流程的完整闭环综合以上源码claim 文档描述的每个处置动作都有落点文档中的可能结果对应实现从源码结构看保留命名空间skill slugreserveSlugForHardDeleteFinalize/upsertReservedSlugForRightfulOwner写入reservedSlugs发布路径由enforceReservedSlugCooldownForNewSkill强制冷却保留 handlereservedHandles表 reservedHandles.ts的保留/释放逻辑转移所有权upsertReservedSlugForRightfulOwner改写originalOwnerUserIdorg 场景下reclaimDeletedOrgHandleInternal的收回与审计隐藏/隔离、改名、别名与 moderation/quarantine 能力配合见 docs/moderation.md要求补充证据/驳回审查流程本身不产生数据变更值得注意的实现细节是释放幂等所有写入函数都会先列出该 slug 的全部活跃保留然后只保留一条权威记录、把其余的releasedAt置为当前时间。这保证了即使历史上出现过重复保留记录发布路径的行为依然是确定的——这也解释了为什么 convex/skills.slugAvailability.test.ts、convex/lib/reservedSlugs.test.ts、convex/skills.reclaim.test.ts 等测试专门覆盖了 slug 可用性与保留/收回边界。遇到命名空间已被占用错误的排查顺序把文档流程与源码合起来当你的发布报命名空间已被 claim/reserved时推荐的排查顺序是确认错误文案Slug ... is reserved for its previous owner until ...说明命中了reservedSlugs冷却期见 convex/lib/reservedSlugs.ts 的formatReservedSlugCooldownMessage。此时若你就是原 owner用对应 publisher 重新发布即可自动释放保留若不是等到expiresAt或走 claim 流程。User handle ... is claimed by another user则说明 handle 层面的占用。判断你能否自助能管理当前 owner 的按文档直接发布/改名/转移/隐藏/删除不必申诉。判断该走哪条通道纯归属争议走 Org / Namespace Claim issue 模板涉及恶意/安全问题时同时按 docs/moderation.md 与 docs/security.md 的通道处理账户本身的封禁/申诉走 account appeal不要混用。按证据清单准备公开证明排除一切 token、密钥、私法文件与个人隐私材料敏感证明走表单提供的私有 staff 通道。参考更多排查细节docs/troubleshooting.md 中专门有 Publish fails because a namespace is claimed or reserved 一节与本文互为补充发布侧的完整规则见 docs/publishing.md。小结ClawHub 的命名空间认领机制是公开政策 后端保留表的组合政策层面docs/namespace-claims.md 规定了何时申诉、证据边界、敏感材料红线与结果预期实现层面reservedSlugs/reservedHandles两张表配合发布路径上的冷却期强制、publisher scope 匹配的释放判定以及 org handle 收回时的确认 token 与审计事件把保留、转移、隐藏、隔离、别名这五种裁决动作都落成了可验证的数据操作。理解这一闭环后无论是提交 claim 的一方还是被namespace claimed错误挡住发布的发布者都能准确判断自己处于流程的哪一步、以及下一步的确定动作是什么。赞分享后端前端AI 技能AI 插件搜索引擎【免费下载链接】clawhubSkill Plugin Registry for OpenClaw项目地址https://gitcode.com/gh_mirrors/mo/clawhub点击查看免费下载相关推荐终极RedwoodJS命名空间指南模块组织与CLI命名空间完整教程终极RedwoodJS命名空间指南模块组织与CLI命名空间完整教程 RedwoodJS作为现代全栈框架其命名空间系统是构建可维护大型应用的核心基础。本文将深后端前端Web框架开发工具曲境(QuJing)开发者指南核心Hook原理与WebSocket通信实现分析曲境 QuJing 开发者指南核心Hook原理与WebSocket通信实现分析 曲境QuJing是一款基于Xposed框架的安卓应用动态监控工具能够在PWinApps 完整上手指南在 Linux 桌面快速跑起 Office 与 AdobeWinApps 完整上手指南在 Linux 桌面快速跑起 Office 与 Adobe 还在为 Linux 上打不开 Excel 模板、PS 存不了工程文件而桌面应用虚拟化上一篇终极SSL/TLS安全检测工具testssl.sh完整指南下一篇终极指南百度网盘秒传链接在线转存全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考