用例（真实场景）
我在一些非标准结构的仓库上跑 Roc：仓库根不只有代码——还有设计文档、构建脚本、运维文档等功能目录，源码在子目录里，每个目录有自己的用途和禁区（例如：某些目录是构建产物会被覆盖、某些文档必须与源码同步更新）。
当前工人的行为：
- Scout 的指示是 "Inspect the repository"（开放式）——可能读 README，但不保证
- 工人 session 没有 system prompt 注入，不会自动加载仓库根的 AGENTS.md
- ticket 规格里没有「必读文件」字段（contextCandidates 是票间接力，指向前序 thread/commit，不指向项目文件）
结果：每个仓库自己的干活习惯（目录约定、命名习惯、禁区、默认验证命令）目前唯一的进口是每张票的六段规格里逐票手写（scope / nonGoals / validation）——重复、易漏、容易漂移。
现状盘点
~/.config/roc/settings.json 是用户级全局配置（cycle 日期 + skills 允许列表），管「这个人怎么用 Roc」，不管「这个仓库要求怎么干活」- 仓库级偏好目前没有载体
建议
支持仓库级工人指南：仓库根放一份指南文件（如 .agile/WORKER.md，或复用 AGENTS.md 惯例），Scout 阶段注入。内容 = 该仓库的约定：正本目录在哪、禁区在哪、命名习惯、默认 validation 命令等。
两个设计点
- 信任/安全：指南文件不应成为绕过 ticket trust 的命令注入后门——可参照 task-hooks 已有的 configHash trust 机制
- 优先级语义：票规格与指南冲突时谁赢？建议票规格（更具体）覆盖指南（更默认）
为什么值得
真实世界每个仓库都有自己的肌肉记忆。「repo 级机器可读偏好」已是行业惯例（AGENTS.md / CLAUDE.md / PR 模板）。对非标准形态的仓库（monorepo 子目录、代码与文档混合仓库），这一环是把 Roc 用到更广仓库形态上的关键。
用例（真实场景）
我在一些非标准结构的仓库上跑 Roc：仓库根不只有代码——还有设计文档、构建脚本、运维文档等功能目录，源码在子目录里，每个目录有自己的用途和禁区（例如：某些目录是构建产物会被覆盖、某些文档必须与源码同步更新）。
当前工人的行为：
结果：每个仓库自己的干活习惯（目录约定、命名习惯、禁区、默认验证命令）目前唯一的进口是每张票的六段规格里逐票手写（scope / nonGoals / validation）——重复、易漏、容易漂移。
现状盘点
~/.config/roc/settings.json是用户级全局配置（cycle 日期 + skills 允许列表），管「这个人怎么用 Roc」，不管「这个仓库要求怎么干活」建议
支持仓库级工人指南：仓库根放一份指南文件（如
.agile/WORKER.md，或复用 AGENTS.md 惯例），Scout 阶段注入。内容 = 该仓库的约定：正本目录在哪、禁区在哪、命名习惯、默认 validation 命令等。两个设计点
为什么值得
真实世界每个仓库都有自己的肌肉记忆。「repo 级机器可读偏好」已是行业惯例（AGENTS.md / CLAUDE.md / PR 模板）。对非标准形态的仓库（monorepo 子目录、代码与文档混合仓库），这一环是把 Roc 用到更广仓库形态上的关键。