feat: rename skills/skiff to pouch and move ACK state under .pouch

Use ~/.pouch, the pouch CLI, and .pouch.yaml as the SSOT container.
Keep the inner skills/ packages, and store ACK project state in
.pouch/ack instead of docs/ack.

skills/ack/references/adoption-checklist.md

@@ -3,8 +3,8 @@
 ## 安装与初始化
 
 - [ ] ACK Skill 已全局安装或安装到当前项目。
-- [ ] 已运行 `skiff init ack --project <project-root>`。
-- [ ] `docs/ack/` 只包含项目自己的 `project.md`、`tasks.yaml`、`knowledge.yaml` 与
+- [ ] 已运行 `pouch init ack --project <project-root>`。
+- [ ] `.pouch/ack/` 只包含项目自己的 `project.md`、`tasks.yaml`、`knowledge.yaml` 与
       默认关闭的 `delivery.yaml`。
 - [ ] 旧项目缺少 `knowledge.yaml` 时，只补空文件及缺失的
       `project.knowledgeFile` 指针，没有重跑初始化或覆盖其它项目状态。
@@ -16,8 +16,8 @@
 - [ ] `project.md` 只保存项目差异，不复制 Skill 的通用规范。
 - [ ] `tasks.yaml` 的 `project.overlayFile` 指向实际覆盖层。
 - [ ] `tasks.yaml` 的 `project.knowledgeFile` 固定为
-      `docs/ack/knowledge.yaml`。
-- [ ] 新项目的 `project.deliveryFile` 固定为 `docs/ack/delivery.yaml`，顶层有
+      `.pouch/ack/knowledge.yaml`。
+- [ ] 新项目的 `project.deliveryFile` 固定为 `.pouch/ack/delivery.yaml`，顶层有
       `deliveryRuns: []`；旧项目未采用交付能力时可无这两项。
 - [ ] 技术栈、运行、构建、单测和集成测试命令均来自项目证据。
 - [ ] Coordinator、Developer、Test 的模型档位和升级规则已明确。
@@ -26,7 +26,7 @@
 - [ ] `allowedWorktrees` 已废弃（v0.19 起），新任务板不配置；worker 默认在
       `--project-root` 工作，其它 worktree 由 launcher 按同 git 仓库且已注册约束放行。
 - [ ] `tasks.yaml` 不需要保存 `repoPath` 或 `devWorktree`；项目状态从当前
-      `--project-root/docs/ack/` 推导，worker 路径由 `--worktree` 显式指定。
+      `--project-root/.pouch/ack/` 推导，worker 路径由 `--worktree` 显式指定。
 
 ## 路径权限
 
@@ -110,6 +110,6 @@
       blocked/failed/leftover、未完成任务或未解决环境事件的终端保留且不设 TTL。
 
 首次接入建议选择一个低风险问题跑完整闭环。项目差异写回
-`docs/ack/project.md`；通用问题回流到 ACK Skill 的 `references/`、`templates/`
+`.pouch/ack/project.md`；通用问题回流到 ACK Skill 的 `references/`、`templates/`
 或 `scripts/`，并更新 `VERSION`。项目特有、跨任务复用且已经验证的经验才写入
-`docs/ack/knowledge.yaml`。
+`.pouch/ack/knowledge.yaml`。

skills/ack/references/delivery.md

@@ -2,8 +2,8 @@
 
 本文件定义可选的 `verified -> validation_ready/review_ready/released` 交付阶段。开发、独立复测和
 Coordinator 终检仍由 ACK 原有闭环负责；只有选中的任务全部 `verified` 后才能进入
-交付。项目配置位于 `docs/ack/delivery.yaml`，运行证据写入
-`docs/ack/tasks.yaml.deliveryRuns`。
+交付。项目配置位于 `.pouch/ack/delivery.yaml`，运行证据写入
+`.pouch/ack/tasks.yaml.deliveryRuns`。
 
 ## 1. 配置与授权不是一回事
 
@@ -54,7 +54,7 @@ channel、environment 或 source revision 漂移时重新确认。
 
 ## 3.1 测试环境与发版写在同一份契约
 
-`docs/ack/delivery.yaml` 是测试环境部署和版本发布的唯一文档。不要另写操作手册，
+`.pouch/ack/delivery.yaml` 是测试环境部署和版本发布的唯一文档。不要另写操作手册，
 也不要把其中一项写进 `project.md`。用户用自然语言说明「怎么布测试环境」或
 「怎么发版」时，Coordinator 把两者都维护进这份文件的 `intents`、entrypoint、
 artifact、environment 和 profile。
@@ -85,7 +85,7 @@ intents:
 
    ```bash
    python3 <ack-skill-dir>/scripts/validate_delivery.py \
-     docs/ack/delivery.yaml --tasks docs/ack/tasks.yaml \
+     .pouch/ack/delivery.yaml --tasks .pouch/ack/tasks.yaml \
      --project-root <project-root>
    ```
 

skills/ack/references/feishu-bug-intake.md

@@ -9,7 +9,7 @@
 
 ## 项目配置与 Base 结构
 
-`docs/ack/tasks.yaml` 的 `project.bugIntake` 必须声明 `provider: feishu-base`、
+`.pouch/ack/tasks.yaml` 的 `project.bugIntake` 必须声明 `provider: feishu-base`、
 `workflow: clarified-writeback-v1`、显式 `profile`、`baseToken`、`tableId`、`viewId` 和字段映射：
 
 ```yaml
@@ -34,8 +34,8 @@ fields:
 调整当前 view 的可见字段，不删除旧列：
 
 ```bash
-python3 <ack-skill-dir>/scripts/feishu_bug_intake.py schema-plan docs/ack/tasks.yaml
-python3 <ack-skill-dir>/scripts/feishu_bug_intake.py schema-apply docs/ack/tasks.yaml \
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py schema-plan .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py schema-apply .pouch/ack/tasks.yaml \
   --expected-schema-fingerprint <schemaFingerprint>
 ```
 
@@ -68,11 +68,11 @@ locale；调用者环境中的凭据和运行时注入变量不会传入。不
 ## 读取与整理
 
 ```bash
-python3 <ack-skill-dir>/scripts/feishu_bug_intake.py check docs/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py check .pouch/ack/tasks.yaml
 tmpdir=$(mktemp -d)
-python3 <ack-skill-dir>/scripts/feishu_bug_intake.py fetch docs/ack/tasks.yaml \
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py fetch .pouch/ack/tasks.yaml \
   --output-dir "$tmpdir"
-python3 <ack-skill-dir>/scripts/feishu_bug_intake.py plan docs/ack/tasks.yaml \
+python3 <ack-skill-dir>/scripts/feishu_bug_intake.py plan .pouch/ack/tasks.yaml \
   --output-dir "$tmpdir"
 ```
 
@@ -101,7 +101,7 @@ Coordinator 对每条 Bug：
 
 ```bash
 python3 <ack-skill-dir>/scripts/feishu_bug_intake.py write-draft \
-  docs/ack/tasks.yaml --record-id <record-id> \
+  .pouch/ack/tasks.yaml --record-id <record-id> \
   --expected-source-ref <sourceRef> \
   --expected-draft-revision <draftRevision> --input <draft.json>
 ```
@@ -120,7 +120,7 @@ python3 <ack-skill-dir>/scripts/feishu_bug_intake.py write-draft \
 
 ```bash
 python3 <ack-skill-dir>/scripts/feishu_bug_intake.py import-approved \
-  docs/ack/tasks.yaml --record-id <record-id> \
+  .pouch/ack/tasks.yaml --record-id <record-id> \
   --expected-source-ref <approved-sourceRef> \
   --expected-draft-revision <approvedDraftRevision>
 ```
@@ -135,7 +135,7 @@ python3 <ack-skill-dir>/scripts/feishu_bug_intake.py import-approved \
 
 ```bash
 python3 <ack-skill-dir>/scripts/feishu_bug_intake.py mark-imported \
-  docs/ack/tasks.yaml --record-id <record-id> --task-id <ack-task-id> \
+  .pouch/ack/tasks.yaml --record-id <record-id> --task-id <ack-task-id> \
   --expected-source-ref <approved-sourceRef> \
   --expected-draft-revision <approvedDraftRevision>
 ```

skills/ack/references/init-new-project.md

@@ -9,10 +9,10 @@
 
 1. 目标项目根目录。
 2. ACK Skill 已全局安装或安装到当前项目。
-3. `skiff` 命令可用。
+3. `pouch` 命令可用。
 
-不要覆盖已有的 `docs/ack/project.md`、`docs/ack/tasks.yaml`、
-`docs/ack/knowledge.yaml`、`docs/ack/delivery.yaml`、`AGENTS.md` 或其它 Agent
+不要覆盖已有的 `.pouch/ack/project.md`、`.pouch/ack/tasks.yaml`、
+`.pouch/ack/knowledge.yaml`、`.pouch/ack/delivery.yaml`、`AGENTS.md` 或其它 Agent
 指令文件。ACK 不会自动
 修改 `AGENTS.md`、`CLAUDE.md` 或其它 Agent 指令文件。不要把 token、`.env`
 内容或其它私有配置写入 ACK 项目状态。
@@ -22,19 +22,19 @@
 在目标项目执行：
 
 ```bash
-skiff init ack
+pouch init ack
 ```
 
 或显式指定项目：
 
 ```bash
-skiff init ack --project <project-root>
+pouch init ack --project <project-root>
 ```
 
 命令从 ACK Skill 自带的 `templates/` 生成：
 
 ```text
-docs/ack/
+.pouch/ack/
 ├── project.md
 ├── tasks.yaml
 ├── knowledge.yaml
@@ -47,24 +47,24 @@ docs/ack/
 ### 旧项目补充知识库
 
 旧项目已经有 `project.md` 和 `tasks.yaml`、但没有 `knowledge.yaml` 时，不要重跑
-`skiff init ack`。先检查现有文件并向用户报告缺失项；用户授权后，只从
-`templates/knowledge.template.yaml` 生成 `docs/ack/knowledge.yaml`，替换项目名和
+`pouch init ack`。先检查现有文件并向用户报告缺失项；用户授权后，只从
+`templates/knowledge.template.yaml` 生成 `.pouch/ack/knowledge.yaml`，替换项目名和
 当前时间，保留 `entries: []`。如果现有任务板缺少
 `project.knowledgeFile`，同一次授权只补
-`knowledgeFile: docs/ack/knowledge.yaml`，不改写其它项目状态。生成后运行任务板、
+`knowledgeFile: .pouch/ack/knowledge.yaml`，不改写其它项目状态。生成后运行任务板、
 知识库和跨文件引用校验。
 
 ### 旧项目补充交付配置
 
 `delivery.yaml` 对旧项目是可选能力；缺少它不会影响三角色开发与验证闭环。只有用户
 明确要求配置项目交付时，才从 `templates/delivery.template.yaml` 生成文件，同时在
-任务板补 `project.deliveryFile: docs/ack/delivery.yaml` 与顶层
+任务板补 `project.deliveryFile: .pouch/ack/delivery.yaml` 与顶层
 `deliveryRuns: []`。首次生成保持 `enabled: false`，按 `delivery.md` 展示并确认
-解析结果后才启用。不要重跑 `skiff init ack`，也不要改写已有任务或知识。
+解析结果后才启用。不要重跑 `pouch init ack`，也不要改写已有任务或知识。
 
 ## 完善项目覆盖层
 
-编辑 `docs/ack/project.md`，填入：
+编辑 `.pouch/ack/project.md`，填入：
 
 - 项目名、技术栈、运行命令和 Base URL。
 - Coordinator、Developer、Test 的实际模型档位。
@@ -76,7 +76,7 @@ docs/ack/
 
 ## 完善任务板
 
-编辑 `docs/ack/tasks.yaml`：
+编辑 `.pouch/ack/tasks.yaml`：
 
 - `ackVersion` 使用 ACK Skill 的合法 SemVer `VERSION`；从 `0.10.0` 起
   `project.orchestration` 与顶层 `workerReceipts` 必须同时存在。
@@ -84,10 +84,10 @@ docs/ack/
   自动补交付配置。
 - `updatedAt` 使用当前带时区时间。
 - `project.name` 使用真实值；`overlayFile` 和 `knowledgeFile` 使用项目内相对路径。
-  ACK 从命令行 `--project-root` 下固定的 `docs/ack/` 布局解析项目状态，不把
+  ACK 从命令行 `--project-root` 下固定的 `.pouch/ack/` 布局解析项目状态，不把
   `repoPath` 或 `devWorktree` 绝对路径写入任务板。旧任务板中的这两个字段仅兼容读取，
   不再参与路径绑定。
-- 新项目的 `project.deliveryFile` 固定为 `docs/ack/delivery.yaml`，并保留顶层
+- 新项目的 `project.deliveryFile` 固定为 `.pouch/ack/delivery.yaml`，并保留顶层
   `deliveryRuns: []`。旧项目只有在采用交付能力时才补这两个字段。
 - `allowedWorktrees` 已废弃（v0.19 起），新任务板不生成该字段；worker 默认在
   `--project-root` 工作。模型 allowlist、profiles 和 defaults 使用项目实际允许值。
@@ -100,7 +100,7 @@ docs/ack/
 
 ## 初始化项目知识
 
-新项目的 `docs/ack/knowledge.yaml` 保持 `verificationRegistry: {}` 与
+新项目的 `.pouch/ack/knowledge.yaml` 保持 `verificationRegistry: {}` 与
 `entries: []`。不要从聊天、README、issue 或单次失败中猜测并激活知识。
 
 项目运行 ACK 后，Developer 和 Test 可以通过回报提名 `knowledgeCandidates`；
@@ -116,7 +116,7 @@ candidate 留在任务证据中，不会被派发。只有 Test 独立验证且
 
 ## 初始化项目交付
 
-新项目的 `docs/ack/delivery.yaml` 保持 `enabled: false`、空能力表、空 profile，以及
+新项目的 `.pouch/ack/delivery.yaml` 保持 `enabled: false`、空能力表、空 profile，以及
 `intents.testEnvironment: null` 与 `intents.release: null`。
 不要根据 README 或 CI 自动推断并启用发布/部署。用户用自然语言说明测试环境或发版
 方式后，Coordinator 按 `delivery.md` 把两者都写入这一份契约：`intents` 指向对应
@@ -128,10 +128,10 @@ profile，工具 target 与仓库脚本分开引用。配置中不保存 shell
 Agent 从当前 `SKILL.md` 解析 ACK Skill 目录后运行：
 
 ```bash
-python3 <ack-skill-dir>/scripts/validate_tasks.py docs/ack/tasks.yaml
-python3 <ack-skill-dir>/scripts/validate_knowledge.py docs/ack/knowledge.yaml --tasks docs/ack/tasks.yaml
-python3 <ack-skill-dir>/scripts/validate_delivery.py docs/ack/delivery.yaml \
-  --tasks docs/ack/tasks.yaml --project-root <project-root>
+python3 <ack-skill-dir>/scripts/validate_tasks.py .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_knowledge.py .pouch/ack/knowledge.yaml --tasks .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_delivery.py .pouch/ack/delivery.yaml \
+  --tasks .pouch/ack/tasks.yaml --project-root <project-root>
 ```
 
 同时确认：
@@ -139,8 +139,8 @@ python3 <ack-skill-dir>/scripts/validate_delivery.py docs/ack/delivery.yaml \
 - `project.md`、`tasks.yaml`、`knowledge.yaml` 和 `delivery.yaml` 没有未替换的
   `<...>` 占位符。
 - `project.overlayFile` 指向真实文件。
-- `project.knowledgeFile` 指向 `docs/ack/knowledge.yaml`。
-- 新项目的 `project.deliveryFile` 指向 `docs/ack/delivery.yaml`；交付默认关闭。
+- `project.knowledgeFile` 指向 `.pouch/ack/knowledge.yaml`。
+- 新项目的 `project.deliveryFile` 指向 `.pouch/ack/delivery.yaml`；交付默认关闭。
 - Developer 与 Test 的验证命令可执行。
 - `project.orchestration` 的 profile/allowlist/defaults 通过校验，自动模式只允许
   `read-only` 或 `workspace-write`；旧任务板未迁移时保持手动模式。

skills/ack/references/kickoff.md

@@ -9,7 +9,7 @@
 **你（发起编排的强模型会话）就是 Coordinator (PM) / 产品。** 你负责写文档、拆任务、
 编排、终检，**不亲自写代码、不亲自跑测试**。开发和测试是另起的 worker agent；
 具体 CLI、模型、reasoning effort 和执行模式的机器事实源是
-`docs/ack/tasks.yaml` 的 `project.orchestration`。`docs/ack/project.md` 只解释项目
+`.pouch/ack/tasks.yaml` 的 `project.orchestration`。`.pouch/ack/project.md` 只解释项目
 差异，不能提供另一套启动命令。
 
 ---
@@ -20,9 +20,9 @@
 我要做一个新需求：<一句话需求>。
 你作为 ack 的 Coordinator(PM)，按 ACK Skill 的 references 规范执行：
 
-1. 先读 docs/ack/project.md，并用 `scripts/select_tasks.py docs/ack/tasks.yaml`
+1. 先读 .pouch/ack/project.md，并用 `scripts/select_tasks.py .pouch/ack/tasks.yaml`
    读取有预算的 project、summary 和可工作任务；已知任务时传 `--task-id`，不要把
-   完整 tasks.yaml 注入上下文。校验 docs/ack/knowledge.yaml 并用
+   完整 tasks.yaml 注入上下文。校验 .pouch/ack/knowledge.yaml 并用
    `scripts/select_knowledge.py` 只读取当前任务相关的 active 条目，再读
    references/roles-and-permissions.md、closed-loop.md、optimization-method.md。
    如果 tasks.yaml 声明 project.deliveryFile，再读取 delivery.yaml 与
@@ -30,7 +30,7 @@
 2. 写产品文档到 docs/（PRD / 交互 / 验收），把需求拆成任务，每个任务的验收写成可观测信号（可见文本 / API 结果 / 交互结果）。
 3. 按任务 scope 从 knowledge.yaml 推荐 active 知识，确认后把固定 revision 的
    knowledgeRefs 写入任务；不要派发 candidate 或全量知识库。
-4. 把任务写进 docs/ack/tasks.yaml（只有你写），校验 tasks.yaml 和 knowledge.yaml。
+4. 把任务写进 .pouch/ack/tasks.yaml（只有你写），校验 tasks.yaml 和 knowledge.yaml。
 5. 先把「产品文档 + 任务拆分 + 验收信号 + 适用知识引用」给我确认；若启用了交付，
    同时列明本次 profile、目标、停止点与审批步骤。不要急着派发或交付。
 6. 我确认后，按 ack 闭环循环：先用 `scripts/launch_worker.py` 校验结构化
@@ -51,15 +51,15 @@
 ## 第 1 步：Coordinator 产出（确认前）
 
 1. 产品文档 → `docs/PRD-<feature>.md` 等（Coordinator R/W）。
-2. 任务板 → `docs/ack/tasks.yaml`，每条任务带 `expected` + `verification`，验收写成可观测信号（见 `optimization-method.md` §1）。
-3. 项目知识 → 从 `docs/ack/knowledge.yaml` 按 component、path、dependency、version
+2. 任务板 → `.pouch/ack/tasks.yaml`，每条任务带 `expected` + `verification`，验收写成可观测信号（见 `optimization-method.md` §1）。
+3. 项目知识 → 从 `.pouch/ack/knowledge.yaml` 按 component、path、dependency、version
    和 tag 推荐 `active` 条目，Coordinator 确认后写入固定 revision 的显式
    `knowledgeRefs`。candidate 不参与选择。
 4. 校验结构与引用：
 
 ```bash
-python3 <ack-skill-dir>/scripts/validate_tasks.py docs/ack/tasks.yaml
-python3 <ack-skill-dir>/scripts/validate_knowledge.py docs/ack/knowledge.yaml --tasks docs/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_tasks.py .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/validate_knowledge.py .pouch/ack/knowledge.yaml --tasks .pouch/ack/tasks.yaml
 ```
 
    `project.orchestration` 是 worker profile 的机器 SSOT；未知字段、非 allowlist 模型、
@@ -68,8 +68,8 @@ python3 <ack-skill-dir>/scripts/validate_knowledge.py docs/ack/knowledge.yaml --
    读取任务上下文使用：
 
 ```bash
-python3 <ack-skill-dir>/scripts/select_tasks.py docs/ack/tasks.yaml
-python3 <ack-skill-dir>/scripts/select_tasks.py docs/ack/tasks.yaml \
+python3 <ack-skill-dir>/scripts/select_tasks.py .pouch/ack/tasks.yaml
+python3 <ack-skill-dir>/scripts/select_tasks.py .pouch/ack/tasks.yaml \
   --task-id <ack-task-id>
 ```
 

skills/ack/references/model-routing.md

@@ -66,7 +66,7 @@ profile 升级时不得复用旧 worker，Test 也不得使用 Developer 的强
 
 ### 机器事实源
 
-worker 路由的机器可读事实只保存在 `docs/ack/tasks.yaml` 的
+worker 路由的机器可读事实只保存在 `.pouch/ack/tasks.yaml` 的
 `project.orchestration`。`project.md` 可以解释项目为何选某个档位，但不能另写一份
 完整启动命令或覆盖机器配置。字段结构以 `templates/tasks.schema.json` 为准。
 
@@ -135,12 +135,12 @@ python3 <ack-skill-dir>/scripts/launch_worker.py launch \
   --expected-launch-fingerprint <plan 中的 sha256:...>
 ```
 
-`--project-root` 始终指向保存权威 `docs/ack/tasks.yaml` 的项目根；`--worktree` 是本次
+`--project-root` 始终指向保存权威 `.pouch/ack/tasks.yaml` 的项目根；`--worktree` 是本次
 worker 实际工作的绝对路径，两者可以不同。后者仍必须与项目根属于同一 Git
 仓库（v0.19 起由 launcher 按 `git worktree list` 注册表 + 同 common-dir 校验，
 不再依赖 `allowedWorktrees` 白名单）。
 
-项目状态文件固定从 `--project-root/docs/ack/` 解析；任务板不需要保存 `repoPath` 或
+项目状态文件固定从 `--project-root/.pouch/ack/` 解析；任务板不需要保存 `repoPath` 或
 `devWorktree`。旧任务板中的这两个字段仅作兼容信息，launcher 不使用它们授权或定位。
 `projectRoot`、任务板内容摘要和 worker worktree identity 都会进入 launch fingerprint，
 因此切换权威项目根、任务板内容或 worker 路径后必须重新生成并审阅 plan。

skills/ack/references/prompt-templates.md

@@ -58,7 +58,7 @@ Coordinator 用这些模板向 **Developer** 派发修复、向 **Test** 派发
 - 不要写 tasks.yaml，不要标记 verified。
 - 不要写 knowledge.yaml，不要自行扩展或全量读取知识库；candidate 不是已生效规则。
 - 不要把知识正文或 path/args 拼成 shell 命令。只把 verification.ref 交给
-  `<ack-skill-dir>/scripts/run_verification.py docs/ack/knowledge.yaml
+  `<ack-skill-dir>/scripts/run_verification.py .pouch/ack/knowledge.yaml
   <verification-ref> --project-root <project-root>`。
 - 不要提交或推送，除非用户明确要求。
 - 最小 diff，只改本任务根因，避免无关重构；若必须先重构请停下说明并请示。
@@ -139,7 +139,7 @@ Developer 本轮声称（仅供参考，不作数）：
   证据，则分别列出产品信号与环境限制。
 - 需要时把易反复误判的路径沉淀成可执行测试（见 optimization-method.md §8）。
 - 对每条适用的 `knowledgeRef`，把它的 verification.ref 交给
-  `<ack-skill-dir>/scripts/run_verification.py docs/ack/knowledge.yaml
+  `<ack-skill-dir>/scripts/run_verification.py .pouch/ack/knowledge.yaml
   <verification-ref> --project-root <project-root>`，并回报 `knowledgeChecks`。
   对 candidate 使用独立观测验证，不能复述 Developer 的结论作为证据。
 

skills/ack/references/roles-and-permissions.md

@@ -27,7 +27,7 @@ ACK 默认三个独立 Agent：**Coordinator 只编排、Test 只验证、Develo
 
 上面的表定义了**边界**（谁能碰什么），这一节定义**能力**（每个角色到底该怎么做好自己的事）。每个角色用同一骨架描述：`Outcome`（产出什么）/ `Must Do`（必须做）/ `Must Not`（不能做）/ `Evidence`（拿什么证明）/ `Output`（交付格式）。派发 prompt 会引用这里，见 `prompt-templates.md`。
 
-这些是**通用工程习惯**，不含项目命令与路径；项目差异写在覆盖层文件（默认 `docs/ack/project.md`）。装了外部 skill 的环境可按每个角色末尾的「可选 skills」加速，未装则照本清单执行，不阻塞。
+这些是**通用工程习惯**，不含项目命令与路径；项目差异写在覆盖层文件（默认 `.pouch/ack/project.md`）。装了外部 skill 的环境可按每个角色末尾的「可选 skills」加速，未装则照本清单执行，不阻塞。
 
 ### Coordinator (PM)：拆解与终检
 
@@ -97,7 +97,7 @@ ACK 默认三个独立 Agent：**Coordinator 只编排、Test 只验证、Develo
 
 ## 路径权限模板
 
-目标项目在自己的**覆盖层文件**中填入实际路径（模板见 `templates/project.template.md`；覆盖层默认 `docs/ack/project.md`，路径记在 `tasks.yaml` 的 `project.overlayFile`）。
+目标项目在自己的**覆盖层文件**中填入实际路径（模板见 `templates/project.template.md`；覆盖层默认 `.pouch/ack/project.md`，路径记在 `tasks.yaml` 的 `project.overlayFile`）。
 
 | 路径 | Coordinator | Test | Developer | 说明 |
 |------|:-----------:|:----:|:---------:|------|