@max-null/dsh-jubensha

LIMITATIONS

Known limitations

- **共享工作目录**：所有 AI 玩家与 DM 观察同一个 cwd（Agent Teams 的既有边界）。所以 **本子的真相手册不得落在工作区内** —— 开局时写到工作区外，散场后归档。 - **角色本不落盘**：只经消息送达对应 agent。落盘就等于任何 agent 都能读到别人的秘密。 - **玩家看得见的比能用的多**：白名单只有 `send_message` 一个（`src/player.ts` 的 `PLAYER_TOOLS`）， 而**模型请求里实际带着 10 个**——那是 2026-10-05 抓玩家子会话的请求时数出来的（**它是实测数， 不是常量**，源码里没有那个 10）。多出来的那些是走 Team 的必然残留：Team 成员工具 9 个 （`spawn_teammate` / `list_agents` / `wait_agent` / `team_task_*` …）加上内核的 `subagent`， 全都注册在**agent 自己那层**，而 `tools.restrict` 按定义只管继承层。安全上没问题 （执行前的闸全兜住了），代价是占 prompt 空间、可能引它试一次。**「进 roster」与「工具面绝对 干净」在机制上不可兼得。** - **一局之后 teammate 名字不释放**：Team 名册是**跨进程持久**的——一个名字在一个 DM 会话里用过 一次，**重启之后也不能再用**（撞 `TEAM_MEMBER_NAME_TAKEN`），而名册本身不可移除 （`agent-team/src/roster.ts:272`）。插件给每个座位缀了**时间戳 + 随机后缀**（不是单调计数—— 计数器是进程级的，而名册不是，2026-10-05 踩了两轮才看清）绕开它，但团队名册本身是累积的。 - **玩家会出戏**：实测里玩家有几次不发台词，改发「进展（林晚侧）：已向主持人确认口径…」 这类元层面汇报。上台说明还需要更硬的约束。 - **一个会话打一局**：Team 名册一个会话最多 8 位 teammate，而条目**不可移除**（上限来自 `experimental/agent-team-profile/cordis.patch.yml` 的 `maxMembers: 8`，内核默认是 16）， 按每局 3 位 AI 玩家算**开不了三局**。约定是**一局一换会话**。（绕开 Team 直接用 `ctx.subagents.startContinuable` 也能解，但那会丢掉已验证的 Team 实践，不值。） **推论**：跨局的连续性只能靠落盘的玩家档案，不能靠会话上下文——见下。 - **封存不是物理隔离**：真相保险箱挡住的是**顺手泄漏**（发角色本必看全座位秘密那条路）， 不是"DM 看不到"。DM 是主 agent，它真要主动 `read` 本子文件，谁也拦不住。判据只有一条： **按正常工作流程带局时，答案不流经它的上下文。** 另一半仍未解决——人类玩家这一侧没有 私聊信道，会话对话就是桌面。 - **跨局的东西目前只有演员池**：局面、座位、玩家登记都随会话消失，所以「跨局记忆」现在到 「这个人记得什么」为止，还不到「这批人之间的旧账」。演员的**印象靠主持人一局结束时写** （`jubensha_actor action="note"`）——他不写，这一局就什么都不剩。