Beads 的 bd assign 命令完全指南安全地将 issue 指派给协作者【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beadsBeads 是一个为编码 Agent 提供“记忆升级”的 issue 追踪与协作工具。在多人或多 Agent协作场景中把某个 issue 指派给正确的负责人是工作流的第一步。bd assign正是为此提供的专用命令——它是bd update id --assignee name的便捷缩写。本文以仓库中的 assign.md 文档为核心结合命令的源码实现与测试用例完整讲解bd assign的语法、行为、安全围栏live-claim 防护、与bd update的关系以及代理模式下的一致性保障帮助你安全、准确地进行指派与取消指派。一、命令概述与基本用法bd assign的功能非常聚焦将一个 issue 指派给某人。官方文档原文将其定义为Shorthand for bd update --assignee .即它是bd update的 assignee 字段更新的快捷形式两者在语义上完全等价任何可以用bd update -a name完成的指派都可以用bd assign id name完成。命令语法bd assign id name [flags]命令仅接受两个位置参数参数含义id要指派的 issue ID例如bd-123name指派给谁的名字。传空字符串表示取消指派官方示例# 将 bd-123 指派给 alice bd assign bd-123 alice # 取消 bd-123 的指派 bd assign bd-123 这两个示例完整覆盖了命令的两种核心用法指派与取消指派。命令要求恰好两个参数——源码中通过Args: cobra.ExactArgs(2)见 assign.go强制校验参数个数不对会直接报错不会产生歧义操作。完整命令定义从 assign.go 的命令定义可以看出该命令的完整形态var assignCmd cobra.Command{ Use: assign id name, GroupID: issues, Short: Assign an issue to someone, Long: Assign an issue to someone. Shorthand for bd update id --assignee name. Refuses to overwrite another actors live in_progress claim without --force (bd-98s5c); issues assigned to a claim.pools alias are exempt, matching --claim. For a holder-aware transfer prefer bd update id --if-assignee holder -a new., Args: cobra.ExactArgs(2), SilenceUsage: true, SilenceErrors: true, RunE: func(cmd *cobra.Command, args []string) error { /* ... */ }, }关键信息GroupID: issues该命令归属于issues命令组与create、update、close、claim、reclaim等 issue 生命周期命令并列SilenceUsage/SilenceErrors出错时不输出冗长的用法提示错误信息由上层统一格式化处理支持--force标志和 issue ID 的 shell 补全ValidArgsFunction issueIDCompletion。二、支持的命令行标志bd assign目前暴露给用户的标志只有一个--force但它背后的安全语义却相当重要。标志类型默认值说明--forceboolfalse允许覆盖另一个 actor 的活跃 in_progress 认领live claim。仅用于已废弃的认领场景——例如 Agent 崩溃或租约过期更规范的场景应优先使用bd reclaim命令注册代码如下assign.gofunc init() { assignCmd.Flags().Bool(force, false, Allow overwriting another actors live in_progress claim (use only for abandoned claims — crashed agent, expired lease; prefer bd reclaim)) assignCmd.ValidArgsFunction issueIDCompletion rootCmd.AddCommand(assignCmd) }注意--force的适用边界它只允许覆盖别人的活跃认领而绝不是绕过一切校验的“万能钥匙”。文档与注释反复强调只有当认领显然已废弃Agent 崩溃、租约过期时才可使用且更推荐使用bd reclaim走规范化的认领转移流程。三、bd assign与bd update的关系bd assign是bd update id --assignee name的简写因此理解bd update的--assignee标志是掌握bd assign语义的前提。在 update.md 中可以看到完整的--assignee定义-a, --assignee string Assignee此外bd update还提供了几个与指派密切相关的标志构成完整的“认领/指派”工具箱--claim原子地认领 issue将 assignee 设为你自己、status 设为in_progress如果你已认领则幂等--if-assignee expected条件指派CAS仅当当前 assignee 与期望值匹配时才执行指派不匹配则非零退出且不写入任何数据--if-status expected与--if-assignee配对的 status 前置条件守卫。何时用bd assign何时用bd update -a简单指派/取消指派bd assign bd-123 alice与bd update bd-123 --assignee alice完全等价用哪个都行需要原子性保证的转移当你要把 issue 从当前持有者手中转交给他人且不希望出现“读-改-写”竞态时应使用bd update id --if-assignee holder -a new。这是持有者感知holder-aware的转移由显式命名的 CAS 守卫保障不需要--force认领场景应使用bd claim原子设置 assigneestatus而不是先 assign 再 update status。命令自身的Long描述明确建议For a holder-aware transfer prefer bd update id --if-assignee holder -a new.四、安全围栏live-claim 防篡改机制这是bd assign最核心的行为特征。命令在源码层面明确表示Refuses to overwrite another actors live in_progress claim without --force (bd-98s5c)这条规则对应的实现是validateIssueReassignableshow_unit_helpers.go它委托给集中式验证包中的validation.AssigneeNotStolenfunc validateIssueReassignable(id string, issue *types.Issue, actor, newAssignee string, poolAliases func() []string, force bool) error { return validation.AssigneeNotStolen(actor, newAssignee, poolAliases, force)(id, issue) }AssigneeNotStolen的完整判定逻辑internal/validation/issue.go如下只有以下所有条件同时成立时才会拒绝每一个条件都是刻意设计、缺一不可的func AssigneeNotStolen(actor, newAssignee string, poolAliases func() []string, force bool) IssueValidator { return func(id string, issue *types.Issue) error { if issue nil || force { return nil } if issue.Assignee || ActorMatches(issue.Assignee, actor) || ActorMatches(issue.Assignee, newAssignee) { return nil } if issue.Status ! types.StatusInProgress { return nil } if poolAliases ! nil slices.Contains(poolAliases(), issue.Assignee) { return nil } return fmt.Errorf(cannot reassign %s: held by %q (in_progress); coordinate with the holder (bd mail %s) — pass --force only if their claim is abandoned (crashed agent, expired lease), or use bd reclaim, id, issue.Assignee, issue.Assignee) } }拒绝触发的四个必要条件逐一解读issue 当前已有 assigneeissue.Assignee ! ——未指派的 issue 可以自由指派当前 assignee 既不是 actor 本人也不是要设成的新 assignee——自己编辑自己的认领、或幂等地重复断言同一持有者即使拼写不同都放行这保证了重试/重放安全当前 status 为in_progress——对open待办issue 的改派保持零摩擦派发者手动分发开放 issue、Agent 从 pool 队列取单都是高频合法操作当前 assignee 不是claim.pools别名——--claim刻意允许任何 actor 领取 pool 指派的任务如果这里不加同样的豁免--claim与-a会在同一 issue 上给出相反结论。此外身份比较使用CanonicalActor规范化后的结果而非逐字串比较因此即使 actor 或新 assignee 以不同大小写/不同层的拼写命名同一身份也不会被误判为“陌生人篡改”。失败时的错误信息当防护触发时命令输出形如cannot reassign bd-123: held by alice (in_progress); coordinate with the holder (bd mail alice) — pass --force only if their claim is abandoned (crashed agent, expired lease), or use bd reclaim错误信息给出了三条出路与持有者协调bd mail、在认领已废弃时使用--force、或走规范的bd reclaim。测试验证该围栏行为有专门的测试覆盖assign_fence_embedded_test.go嵌入式存储模式下的围栏测试覆盖“thief 无法改派他人 in_progress 认领”“--force 可覆盖”“--claim 走 pool 别名豁免”等场景assign_fence_proxied_test.go代理服务器proxied server模式下的同构测试验证两种部署形态下行为一致。测试中还能看到幂等重放语义的佐证replayer以与 holder 不同的拼写重复断言同一 assignee 依然成功——这与AssigneeNotStolen中“canonicalize 后匹配即放行”的设计一一对应。五、claim.pools 别名豁免--claim命令允许任何 actor 领取 pool 指派的任务为了让bd assign与--claim行为一致bd assign对 pool 别名也有同样的豁免。在bd assign的执行路径中pool 别名通过storeClaimPoolAliasesshow_unit_helpers.go延迟读取func storeClaimPoolAliases(ctx context.Context, st storage.DoltStorage) func() []string { return func() []string { raw, err : st.GetConfig(ctx, claim.pools) if err ! nil { return nil } return issueops.ParseClaimPools(raw) } }两点实现细节值得注意延迟求值thunkpoolAliases是一个函数而非切片在绝大多数无冲突路径上不会触发配置读取避免无谓的 I/O失败关闭fail closed若读取claim.pools配置出错返回空别名集合围栏会以“拒绝”而不是“放行”收尾——宁可拒绝也无法验证的接管绝不冒险放行。代理模式下有孪生实现uowClaimPoolAliasesshow_unit_helpers.go通过工作单元Unit of Work的事务读取同一配置。六、完整执行流程从参数到提交结合 assign.go 的RunE一次bd assign bd-123 alice的完整执行链路如下只读检查CheckReadonly(assign)——若仓库处于只读模式则拒绝写入指标埋点创建metrics.NewCommandEvent(assign)命令事件结束时上报关闭事件后由metrics.Global()提交模式分派若当前使用代理服务器模式usesProxiedServer()转交runAssignProxiedServer处理见下文解析 issueresolveAndGetIssueForMutation(ctx, store, id)将 ID 解析为具体存储并取回 issue失败或未找到均返回格式化错误可更新性校验validateIssueUpdatable(id, result.Issue)——内部使用validation.NotTemplate()拒绝修改模板 issue改派校验validateIssueReassignable(...)执行上述 live-claim 围栏写入构造updates : map[string]interface{}{assignee: assignee}并调用issueStore.UpdateIssue(...)自动提交嵌入式模式下通过commitPendingIfEmbedded(...)生成以assign为命令名、目标 issue 为关联对象的 Dolt 自动提交记录最近操作SetLastTouchedID(result.ResolvedID)——这使得后续不带 ID 的bd update/bd show默认作用于该 issue输出JSON 模式输出更新后的 issue 对象普通模式输出人读反馈例如✓ Assigned bd-123 (Fix login bug) to alice ✓ Unassigned bd-123 (Fix login bug)注意输出中空 assignee 走Unassigned分支非空走Assigned ... to ...分支且都会带上 issue 标题便于人工核对。七、代理服务器模式下的行为当bd连接代理服务器时assign不会在本地直接写存储而是转交runAssignProxiedServer(rootCtx, args, force)。这与update走--if-assignee守卫时的语义保持一致见 update.go 中对ifAssignee与 assignee 变更校验的协调逻辑。代理路径的核心价值在于事务一致性与重放安全所有写入通过工作单元Unit of Work在单个事务中完成配置读取如claim.pools也走同一事务AssigneeNotStolen的“幂等重放”设计canonicalize 后匹配即放行正是为了代理路径上重试/重放不会误伤assign_fence_proxied_test.go 验证了代理模式下 thieft、force、pool 别名等场景与嵌入式模式行为一致例如# 代理模式下偷取他人 in_progress 认领会失败 bd update id --actor thief --assignee thief # 失败 # 显式 --force 覆盖仅限废弃认领 bd update id --actor thief --assignee thief --force # 成功八、最佳实践与常见错误结合源码围栏设计与测试用例总结如下实操建议推荐做法简单指派用bd assignbd assign bd-123 alice足够表达意图语义清晰取消指派用空字符串bd assign bd-123 与文档示例一致认领任务用bd claim需要把 assignee 设为自己的同时把 status 设为in_progressbd claim一步原子完成持有人感知的转移用--if-assigneebd update id --if-assignee holder -a newCAS 保证“只在仍然归 holder 时转移”无竞态且无需--force处理废弃认领优先bd reclaim而不是--forcereclaim是规范的认领转移流程。常见错误与规避场景错误示范正确做法改派他人的活跃 in_progress 认领bd assign bd-123 bob被拒与 holder 协调或确认废弃后--force或bd reclaim误把--force当万能开关随意--force覆盖他人认领仅在 Agent 崩溃/租约过期等明确废弃场景使用需要原子转移却用两步操作先show再assign用--if-assignee holder -a new一步完成同时使用互斥守卫--force与--if-assignee同用二者互斥--if-assignee已显式命名 holder无需--force与bd update标志的对照速查需求命令指派某人bd assign id name或bd update id -a name取消指派bd assign id 或bd update id -a 原子认领assigneestatusbd update id --claim持有者感知转移CASbd update id --if-assignee holder -a new废弃认领的规范回收bd reclaim九、总结bd assign虽然只是bd update -a的缩写但它在 Beads 的 issue 协作体系中承担着明确的职责以极简语法完成指派与取消指派同时通过AssigneeNotStolen围栏杜绝“静默篡改他人活跃认领”这一最后一条未加防护的跨 actor 接管路径。理解其围栏的四个触发条件有 assignee、非本人、in_progress、非 pool 别名就能在多人/多 Agent 协作中既保持高频操作开放 issue 分发、pool 取单的零摩擦又守住认领权属的安全底线。如需深入可继续阅读命令实现cmd/bd/assign.go改派围栏与 pool 别名读取cmd/bd/show_unit_helpers.go核心验证逻辑internal/validation/issue.go嵌入式与代理模式测试cmd/bd/assign_fence_embedded_test.go、cmd/bd/assign_fence_proxied_test.go完整 update 标志说明docs/cli-reference/update.md【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Beads 的 bd assign 命令完全指南：安全地将 issue 指派给协作者
Beads 的 bd assign 命令完全指南安全地将 issue 指派给协作者【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beadsBeads 是一个为编码 Agent 提供“记忆升级”的 issue 追踪与协作工具。在多人或多 Agent协作场景中把某个 issue 指派给正确的负责人是工作流的第一步。bd assign正是为此提供的专用命令——它是bd update id --assignee name的便捷缩写。本文以仓库中的 assign.md 文档为核心结合命令的源码实现与测试用例完整讲解bd assign的语法、行为、安全围栏live-claim 防护、与bd update的关系以及代理模式下的一致性保障帮助你安全、准确地进行指派与取消指派。一、命令概述与基本用法bd assign的功能非常聚焦将一个 issue 指派给某人。官方文档原文将其定义为Shorthand for bd update --assignee .即它是bd update的 assignee 字段更新的快捷形式两者在语义上完全等价任何可以用bd update -a name完成的指派都可以用bd assign id name完成。命令语法bd assign id name [flags]命令仅接受两个位置参数参数含义id要指派的 issue ID例如bd-123name指派给谁的名字。传空字符串表示取消指派官方示例# 将 bd-123 指派给 alice bd assign bd-123 alice # 取消 bd-123 的指派 bd assign bd-123 这两个示例完整覆盖了命令的两种核心用法指派与取消指派。命令要求恰好两个参数——源码中通过Args: cobra.ExactArgs(2)见 assign.go强制校验参数个数不对会直接报错不会产生歧义操作。完整命令定义从 assign.go 的命令定义可以看出该命令的完整形态var assignCmd cobra.Command{ Use: assign id name, GroupID: issues, Short: Assign an issue to someone, Long: Assign an issue to someone. Shorthand for bd update id --assignee name. Refuses to overwrite another actors live in_progress claim without --force (bd-98s5c); issues assigned to a claim.pools alias are exempt, matching --claim. For a holder-aware transfer prefer bd update id --if-assignee holder -a new., Args: cobra.ExactArgs(2), SilenceUsage: true, SilenceErrors: true, RunE: func(cmd *cobra.Command, args []string) error { /* ... */ }, }关键信息GroupID: issues该命令归属于issues命令组与create、update、close、claim、reclaim等 issue 生命周期命令并列SilenceUsage/SilenceErrors出错时不输出冗长的用法提示错误信息由上层统一格式化处理支持--force标志和 issue ID 的 shell 补全ValidArgsFunction issueIDCompletion。二、支持的命令行标志bd assign目前暴露给用户的标志只有一个--force但它背后的安全语义却相当重要。标志类型默认值说明--forceboolfalse允许覆盖另一个 actor 的活跃 in_progress 认领live claim。仅用于已废弃的认领场景——例如 Agent 崩溃或租约过期更规范的场景应优先使用bd reclaim命令注册代码如下assign.gofunc init() { assignCmd.Flags().Bool(force, false, Allow overwriting another actors live in_progress claim (use only for abandoned claims — crashed agent, expired lease; prefer bd reclaim)) assignCmd.ValidArgsFunction issueIDCompletion rootCmd.AddCommand(assignCmd) }注意--force的适用边界它只允许覆盖别人的活跃认领而绝不是绕过一切校验的“万能钥匙”。文档与注释反复强调只有当认领显然已废弃Agent 崩溃、租约过期时才可使用且更推荐使用bd reclaim走规范化的认领转移流程。三、bd assign与bd update的关系bd assign是bd update id --assignee name的简写因此理解bd update的--assignee标志是掌握bd assign语义的前提。在 update.md 中可以看到完整的--assignee定义-a, --assignee string Assignee此外bd update还提供了几个与指派密切相关的标志构成完整的“认领/指派”工具箱--claim原子地认领 issue将 assignee 设为你自己、status 设为in_progress如果你已认领则幂等--if-assignee expected条件指派CAS仅当当前 assignee 与期望值匹配时才执行指派不匹配则非零退出且不写入任何数据--if-status expected与--if-assignee配对的 status 前置条件守卫。何时用bd assign何时用bd update -a简单指派/取消指派bd assign bd-123 alice与bd update bd-123 --assignee alice完全等价用哪个都行需要原子性保证的转移当你要把 issue 从当前持有者手中转交给他人且不希望出现“读-改-写”竞态时应使用bd update id --if-assignee holder -a new。这是持有者感知holder-aware的转移由显式命名的 CAS 守卫保障不需要--force认领场景应使用bd claim原子设置 assigneestatus而不是先 assign 再 update status。命令自身的Long描述明确建议For a holder-aware transfer prefer bd update id --if-assignee holder -a new.四、安全围栏live-claim 防篡改机制这是bd assign最核心的行为特征。命令在源码层面明确表示Refuses to overwrite another actors live in_progress claim without --force (bd-98s5c)这条规则对应的实现是validateIssueReassignableshow_unit_helpers.go它委托给集中式验证包中的validation.AssigneeNotStolenfunc validateIssueReassignable(id string, issue *types.Issue, actor, newAssignee string, poolAliases func() []string, force bool) error { return validation.AssigneeNotStolen(actor, newAssignee, poolAliases, force)(id, issue) }AssigneeNotStolen的完整判定逻辑internal/validation/issue.go如下只有以下所有条件同时成立时才会拒绝每一个条件都是刻意设计、缺一不可的func AssigneeNotStolen(actor, newAssignee string, poolAliases func() []string, force bool) IssueValidator { return func(id string, issue *types.Issue) error { if issue nil || force { return nil } if issue.Assignee || ActorMatches(issue.Assignee, actor) || ActorMatches(issue.Assignee, newAssignee) { return nil } if issue.Status ! types.StatusInProgress { return nil } if poolAliases ! nil slices.Contains(poolAliases(), issue.Assignee) { return nil } return fmt.Errorf(cannot reassign %s: held by %q (in_progress); coordinate with the holder (bd mail %s) — pass --force only if their claim is abandoned (crashed agent, expired lease), or use bd reclaim, id, issue.Assignee, issue.Assignee) } }拒绝触发的四个必要条件逐一解读issue 当前已有 assigneeissue.Assignee ! ——未指派的 issue 可以自由指派当前 assignee 既不是 actor 本人也不是要设成的新 assignee——自己编辑自己的认领、或幂等地重复断言同一持有者即使拼写不同都放行这保证了重试/重放安全当前 status 为in_progress——对open待办issue 的改派保持零摩擦派发者手动分发开放 issue、Agent 从 pool 队列取单都是高频合法操作当前 assignee 不是claim.pools别名——--claim刻意允许任何 actor 领取 pool 指派的任务如果这里不加同样的豁免--claim与-a会在同一 issue 上给出相反结论。此外身份比较使用CanonicalActor规范化后的结果而非逐字串比较因此即使 actor 或新 assignee 以不同大小写/不同层的拼写命名同一身份也不会被误判为“陌生人篡改”。失败时的错误信息当防护触发时命令输出形如cannot reassign bd-123: held by alice (in_progress); coordinate with the holder (bd mail alice) — pass --force only if their claim is abandoned (crashed agent, expired lease), or use bd reclaim错误信息给出了三条出路与持有者协调bd mail、在认领已废弃时使用--force、或走规范的bd reclaim。测试验证该围栏行为有专门的测试覆盖assign_fence_embedded_test.go嵌入式存储模式下的围栏测试覆盖“thief 无法改派他人 in_progress 认领”“--force 可覆盖”“--claim 走 pool 别名豁免”等场景assign_fence_proxied_test.go代理服务器proxied server模式下的同构测试验证两种部署形态下行为一致。测试中还能看到幂等重放语义的佐证replayer以与 holder 不同的拼写重复断言同一 assignee 依然成功——这与AssigneeNotStolen中“canonicalize 后匹配即放行”的设计一一对应。五、claim.pools 别名豁免--claim命令允许任何 actor 领取 pool 指派的任务为了让bd assign与--claim行为一致bd assign对 pool 别名也有同样的豁免。在bd assign的执行路径中pool 别名通过storeClaimPoolAliasesshow_unit_helpers.go延迟读取func storeClaimPoolAliases(ctx context.Context, st storage.DoltStorage) func() []string { return func() []string { raw, err : st.GetConfig(ctx, claim.pools) if err ! nil { return nil } return issueops.ParseClaimPools(raw) } }两点实现细节值得注意延迟求值thunkpoolAliases是一个函数而非切片在绝大多数无冲突路径上不会触发配置读取避免无谓的 I/O失败关闭fail closed若读取claim.pools配置出错返回空别名集合围栏会以“拒绝”而不是“放行”收尾——宁可拒绝也无法验证的接管绝不冒险放行。代理模式下有孪生实现uowClaimPoolAliasesshow_unit_helpers.go通过工作单元Unit of Work的事务读取同一配置。六、完整执行流程从参数到提交结合 assign.go 的RunE一次bd assign bd-123 alice的完整执行链路如下只读检查CheckReadonly(assign)——若仓库处于只读模式则拒绝写入指标埋点创建metrics.NewCommandEvent(assign)命令事件结束时上报关闭事件后由metrics.Global()提交模式分派若当前使用代理服务器模式usesProxiedServer()转交runAssignProxiedServer处理见下文解析 issueresolveAndGetIssueForMutation(ctx, store, id)将 ID 解析为具体存储并取回 issue失败或未找到均返回格式化错误可更新性校验validateIssueUpdatable(id, result.Issue)——内部使用validation.NotTemplate()拒绝修改模板 issue改派校验validateIssueReassignable(...)执行上述 live-claim 围栏写入构造updates : map[string]interface{}{assignee: assignee}并调用issueStore.UpdateIssue(...)自动提交嵌入式模式下通过commitPendingIfEmbedded(...)生成以assign为命令名、目标 issue 为关联对象的 Dolt 自动提交记录最近操作SetLastTouchedID(result.ResolvedID)——这使得后续不带 ID 的bd update/bd show默认作用于该 issue输出JSON 模式输出更新后的 issue 对象普通模式输出人读反馈例如✓ Assigned bd-123 (Fix login bug) to alice ✓ Unassigned bd-123 (Fix login bug)注意输出中空 assignee 走Unassigned分支非空走Assigned ... to ...分支且都会带上 issue 标题便于人工核对。七、代理服务器模式下的行为当bd连接代理服务器时assign不会在本地直接写存储而是转交runAssignProxiedServer(rootCtx, args, force)。这与update走--if-assignee守卫时的语义保持一致见 update.go 中对ifAssignee与 assignee 变更校验的协调逻辑。代理路径的核心价值在于事务一致性与重放安全所有写入通过工作单元Unit of Work在单个事务中完成配置读取如claim.pools也走同一事务AssigneeNotStolen的“幂等重放”设计canonicalize 后匹配即放行正是为了代理路径上重试/重放不会误伤assign_fence_proxied_test.go 验证了代理模式下 thieft、force、pool 别名等场景与嵌入式模式行为一致例如# 代理模式下偷取他人 in_progress 认领会失败 bd update id --actor thief --assignee thief # 失败 # 显式 --force 覆盖仅限废弃认领 bd update id --actor thief --assignee thief --force # 成功八、最佳实践与常见错误结合源码围栏设计与测试用例总结如下实操建议推荐做法简单指派用bd assignbd assign bd-123 alice足够表达意图语义清晰取消指派用空字符串bd assign bd-123 与文档示例一致认领任务用bd claim需要把 assignee 设为自己的同时把 status 设为in_progressbd claim一步原子完成持有人感知的转移用--if-assigneebd update id --if-assignee holder -a newCAS 保证“只在仍然归 holder 时转移”无竞态且无需--force处理废弃认领优先bd reclaim而不是--forcereclaim是规范的认领转移流程。常见错误与规避场景错误示范正确做法改派他人的活跃 in_progress 认领bd assign bd-123 bob被拒与 holder 协调或确认废弃后--force或bd reclaim误把--force当万能开关随意--force覆盖他人认领仅在 Agent 崩溃/租约过期等明确废弃场景使用需要原子转移却用两步操作先show再assign用--if-assignee holder -a new一步完成同时使用互斥守卫--force与--if-assignee同用二者互斥--if-assignee已显式命名 holder无需--force与bd update标志的对照速查需求命令指派某人bd assign id name或bd update id -a name取消指派bd assign id 或bd update id -a 原子认领assigneestatusbd update id --claim持有者感知转移CASbd update id --if-assignee holder -a new废弃认领的规范回收bd reclaim九、总结bd assign虽然只是bd update -a的缩写但它在 Beads 的 issue 协作体系中承担着明确的职责以极简语法完成指派与取消指派同时通过AssigneeNotStolen围栏杜绝“静默篡改他人活跃认领”这一最后一条未加防护的跨 actor 接管路径。理解其围栏的四个触发条件有 assignee、非本人、in_progress、非 pool 别名就能在多人/多 Agent 协作中既保持高频操作开放 issue 分发、pool 取单的零摩擦又守住认领权属的安全底线。如需深入可继续阅读命令实现cmd/bd/assign.go改派围栏与 pool 别名读取cmd/bd/show_unit_helpers.go核心验证逻辑internal/validation/issue.go嵌入式与代理模式测试cmd/bd/assign_fence_embedded_test.go、cmd/bd/assign_fence_proxied_test.go完整 update 标志说明docs/cli-reference/update.md【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考