Chorus v0.23.0: 把同事请进来，把协作记清楚

一台主机，几个 Agent，Chorus 已经跑起来了。接下来要把同事请进项目，问题就从“服务怎么启动”变成了“账号怎么开、密码怎么设、离开团队后怎么收回访问”。如果还没接入统一身份系统，这些事也需要有地方处理。

开始一起工作后，还有另一类小麻烦：活动记录里的操作者对不上，改了一段描述又通知了原来的被提及者，方案里的任务看着齐全，依赖却连到了不存在的任务。

Chorus v0.23.0 把工作区本地账号管理补进来，也把人和 Agent 协作中的身份记录、通知和提交检查理得更清楚。

先让每个人有自己的账号

v0.22.2 解决了在自有主机上部署 Chorus 的一部分问题。v0.23.0 往前走一步：不接 OIDC，也可以在工作区内管理本地用户。

超级管理员可以创建本地认证工作区并初始化首位工作区管理员。之后，工作区管理员负责邀请成员、生成密码重置链接、停用和删除账号。成员通过邀请链接设置自己的密码，不需要由管理员代设再转交。

账号管理和项目授权是两回事。有了工作区账号，不代表自动获得所有私有项目的权限，项目和项目组仍按各自的访问规则管理。

收回访问也不只是把列表里的状态改成“停用”。账号变更会撤销旧会话和失效链接，已建立的事件流也会重新检查访问资格。系统还会阻止移除最后一位有效的工作区管理员，避免把工作区留在无人可管理的状态。

加入项目后，可以在设置中修改自己的显示名，也可以随机生成 Personas 头像，预览满意后再保存。刷新页面或重新登录后，选择仍会保留；已自定义的显示名不会再被登录时同步的名称覆盖。

头像预览和保存是分开的。多试几个不影响当前头像，取消就回到已保存的版本。

名字和头像方便认人，活动记录则要回答“这一步是谁做的”。本版修复了任务状态变化中的操作者归属，让相关记录保留实际发起操作的用户或 Agent，并正确显示 Admin 身份。

任务描述里的 @mention 也少了一次不必要的打扰：编辑描述时，只通知这次新增的被提及者，不再因为加了一个新名字，就把原来的人一起通知一遍。

一份方案可以有完整的说明，也可以列出很多任务，却仍然无法执行。比如任务 A 等待 B，B 又等待 A；或者 A 的依赖指向一个已经删掉的草稿。

本版的 Proposal 校验会检查三类问题：不存在的依赖、自我依赖、循环依赖。这些属于阻止提交的错误，需要先修正。

另外，任务草稿可以声明用途：实现、验证、文档或其他。这样才能进一步问一句：这份方案里，究竟有没有人负责实现？

这里没有靠标题猜测，也没有把旧方案一刀切拦住。未声明用途时，校验会提示无法判断实现覆盖；声明了用途却没有实现任务时，会给出警告，提醒确认实现工作是否已经由现有任务承担。这两项是提示和警告，不是阻止提交的错误。

Agent 写完代码、报告进展，再提交验收，本来是一条顺序清楚的流程。但如果报告进展时已经把任务改成 to_verify，接着又调用提交验收，就会撞上状态不匹配。

本版同步修正了各端技能的提交指引：进展汇报不要抢先切换到待验收状态，让提交步骤完成这次转换。

Pi 还增加了可选的提交前检查。设置 CHORUS_SUBMIT_GATE=warn 可以获得提醒，设为 block 则会拦下缺少最新状态读取或有效校验结果的提交。默认关闭，不改变现有使用方式。

它检查的是调用顺序，不替代服务端校验。任务提交前要读取该任务的最新状态；Proposal 校验后如果又改了草稿，就需要重新校验，而不是拿上一次的结果继续提交。

部署从单实例扩展到多实例后，如果每个进程各自记录登录尝试次数，请求落到不同实例，就会碰到不同的计数器。

v0.23.0 在配置 Redis 时共享认证限流计数。Redis 不可用或响应超时时，会退回单实例内存限流并记录告警，不让登录请求一直等下去；超时命令也不会在连接恢复后重放，避免把同一次尝试重复计数。

未配置 Redis 的部署仍使用内存限流。它适合单实例，但不能提供跨实例的统一额度。

本版七套插件和四个 npm 发布包统一到 0.23.0，TRAE 继续与 Codex 共用插件包。

从请同事加入，到辨认操作者，再到检查方案和提交结果，这一版补的是协作过程里那些需要反复确认的小事。服务跑起来之后，让每个人用自己的身份参与，让记录能说清楚发生了什么，也让 Agent 在交出结果前多做一次检查。