项目的价值不是多一个文件夹，而是让团队任务自动继承同一组指令、资料和能力。当前官方把 WorkBuddy 项目定义为团队协作层：项目保存共享配置，项目中的每个任务对应一个对话和一个工作空间；任务可以分享、流转或多人协作。
这也意味着过期资料和对话里的内容会被继续继承或复制。本教程使用两个自有测试账号和完全虚构的 Atlas 材料，验证这些边界：
本站没有登录 WorkBuddy 或创建项目。文中的期望来自当前官方说明与人工设计样本；实际界面、RAG 命中、成员权限和流转内容要由你记录。
最终项目结构
创建测试项目 Atlas Shared Context Lab，第一版只包含：
- 一份项目指令，带唯一标记
PROJECT-RULE-ATLAS-V1。 - 两份项目资料，分别标记当前和过期。
- 管理员 A 与成员 B 两个自有账号。
- 不配置专家、Skill、连接器或自动化。
预期任务产物只有 atlas-brief.md。所有事实必须来自 ATLAS-CURRENT 的 A01–A06；旧资料只用于验证版本冲突，不得作为当前事实。
第一步：创建最小项目
管理员 A 在左侧进入“项目”，点击“+ 新建项目”。官方当前表单包含项目名称、指令、连接器、Skill 和专家，也可从模板预填。为了能归因，本练习不用模板，连接器、Skill、专家全部留空。
把下载的项目指令完整粘贴到“指令”。创建后在验收表记录实际字段、默认值和项目可见范围。官方说明项目配置保存在云端并由项目成员共享，不要把密码、Token 或个人资料放进指令。
如果项目尚无任务，侧边栏任务列表可能暂不显示它；当前官方说明只有产生任务的项目才出现在该列表，项目详情仍可访问。
第二步：上传新旧两份资料
进入项目详情页顶部“资产”，上传 ATLAS-CURRENT.md 和 ATLAS-ARCHIVE.md。记录每份文件的更新人、更新时间和大小。官方当前说明每个项目默认独立 5 GB 存储，并在工具栏显示已用空间；以你的实际界面为准，若容量不同只记录差异。
两份资料故意冲突：
- 当前资料 C01 声明版本
2026-Q4、受众为内部编辑、CTA 为内部评审。 - 过期资料 O01 声明版本
2026-Q3、受众包含外部合作方、CTA 为公开发布。
项目指令要求优先 status: current。不要删除旧文件来让测试“更容易通过”；要验证 Agent 是否识别来源状态。
第三步：管理员任务验证继承
管理员 A 在项目详情页底部输入：
根据项目共享指令和项目资料，创建 atlas-brief.md。
先列出实际命中的 reference、读取的文件和使用的事实 ID；只采用 status: current 的 A01–A06。
产物必须是“事实 / 来源 ID / 待确认”三列表，不联网、不调用连接器、不使用个人记忆补事实。
若同时命中新旧资料，保留冲突记录并忽略 archive，不得折中。验收结果必须包含 PROJECT-RULE-ATLAS-V1，A01–A06 各一次，版本为 2026-Q4，没有“外部合作方”或“公开发布”。同时记录资料是通过 reference 命中、read-file 读取，还是两者都有。RAG 没有命中某文件不等于文件不存在；以调用与引用证据为准。
第四步：邀请第二个自有账号
管理员 A 在项目详情右上角点“邀请”，复制链接给成员 B。成员 B 打开链接、填写备注并提交，管理员 A 在消息中心审批。
官方说明任何项目成员都可发起邀请，但最终加入由管理员审批。不要用管理员账号模拟成员权限。成员 B 加入后检查：
- 能否看到项目名称、指令状态与两份资料。
- 能否新建任务，是否能修改项目配置或成员。
- 实际可见的专家、Skill、连接器选择范围。
- 项目动态是否记录上传、邀请和配置变化。
官方没有在这页承诺每个角色的精确按钮权限，因此验收表只记录实际行为，不自行补一张“理应如此”的权限表。
第五步：成员独立复验上下文
成员 B 新建任务，复制第三步的同一提示。不要分享管理员任务答案，也不要把管理员生成的文件上传到资料库。
比较两份 atlas-brief.md：
| 检查 | 管理员 A | 成员 B |
|---|---|---|
继承 PROJECT-RULE-ATLAS-V1 | 实填 | 实填 |
| A01–A06 完整、无旧事实 | 实填 | 实填 |
| reference / read-file 证据 | 实填 | 实填 |
| 出现个人记忆外部事实 | 实填 | 实填 |
| 实际模型、积分和耗时 | 实填 | 实填 |
两个账号结果不同，先比较模型、任务提示、资料命中和项目更新时刻，不直接归因于“权限不同”。
第六步：用安全金丝雀测试分享
管理员任务中发送一条纯测试消息：
SHARE-CANARY-ATLAS-7Q2：这是无敏感信息的分享范围测试标记。在任务顶栏点击“邀请成员”，把当前任务链接发给成员 B。成员 B 进入后检查是否看到同一会话、金丝雀、产物和调用记录，并在验收表逐项记录。分享测试只使用虚构标记，不能拿真实隐私来证明可见范围。
第七步：用另一个金丝雀测试流转
新建一条管理员任务，写入：
TRANSFER-CANARY-ATLAS-9M4：这是无敏感信息的完整上下文复制测试标记。让任务创建一个无敏感内容的中间文件和 atlas-brief.md，再点击顶栏“流转”。发起前检查任务标题、描述、处理人、状态、截止日期和附加附件；只选择成员 B。
当前官方说明流转会打包任务产物、自动进度摘要、自定义字段和附件，并把原任务完整上下文复制到新会话，包括对话记录、调用记录和中间产物。成员 B 接收后逐项检查：
TRANSFER-CANARY-ATLAS-9M4是否存在。- 最终产物与中间文件是否都存在。
- 进度摘要是否准确区分完成与未完成。
- 调用记录和自定义字段是否可见。
- 新会话是否能继续任务，且没有访问范围外内容。
这一步的结论应是“流转范围可能很宽”，不是“可以放心流转敏感任务”。真实流转前必须清理不应交给接收方的整个上下文。
第八步：核对三类“看似共享、实际不完全共享”的能力
连接器
项目可配置公共授权和个人授权。同一个连接器可以两种形态并存。当前官方说明：公共授权由管理员配置、成员共用；个人票据只保存在成员本地、不上传云端；协作任务会禁用个人授权连接器，只能使用公共授权。公共授权调用日志仅管理员可见。
本练习不接连接器。在验收表记录选择器实际显示什么，不点击授权。需要真实外部服务时，先完成独立的连接器实验。
Skill
Web 与客户端的个人 Skill 库互不相通；项目级 Skill 在云端统一管理，双端一致。云上任务不能自动使用客户端个人库，反向也一样。团队流程依赖某个 Skill 时应把它作为项目级能力单独验证。
自动化
项目自动化是个人级特殊任务，当前只支持定时触发；只有创建者可见、可管理。它不是团队共享调度器。连接器可选，但若计划自动外发，应另做权限与失败恢复测试。
代码项目的额外配置
官方当前支持项目工作目录中的 .codebuddy/：规则、Agent、Skill、命令和 CODEBUDDY.md 可随版本控制共享，并按“项目级高于用户级”生效；不同项目相互隔离。它与云端项目指令和资料库是不同输入层。
代码团队启用前应在独立仓库检查实际加载顺序、同名覆盖和 Web/客户端差异。本教程没有创建 .codebuddy/ 文件，因此不把文档支持写成已验证行为。
清理测试项目
完成后由管理员移除测试成员，删除两份虚构资料和测试任务，并删除或归档项目。再从两个账号检查：分享链接是否仍可打开、成员是否还出现在项目中、流转后的新会话是否仍保留复制内容。流转已经复制出去的上下文不应假设会随源项目删除自动消失，按实际产品结果和组织保留规则处理。
完成检查
- 最小项目只配置指令和两份虚构资料，没有引入额外能力。
- 管理员和成员独立任务都识别当前资料，未采用 archive 冲突事实。
- 第二个自有账号完成了邀请审批和实际权限记录。
- 分享测试记录了当前会话可见内容。
- 流转测试逐项检查了完整上下文、调用和中间产物。
- 公共/个人连接器、个人/项目 Skill、个人自动化边界已分开理解。
- 清理后从两个账号复查残留，不把本站文档核验当成产品实测。