修复 AGC 开发态监听 Rust 构建目录导致的加载缓慢

在 Vite 中排除 src-tauri/target，保留业务源码与共享组件热更新。增加实际 Vite watcher 回归，验证构建目录排除及源码变更通知。同步开发运维文档和共享排障记录，关联 Issue #324。
新增定时版本调度管线并收回两条下游管线的定时与去重
2026-09-16 11:27:07 +08:00 · 2026-09-16 10:55:16 +08:00 · 2026-09-16 10:35:07 +08:00 · 2026-09-16 10:32:03 +08:00 · 2026-09-16 07:23:58 +08:00 · 2026-09-16 07:12:49 +08:00
181 changed files with 18100 additions and 2481 deletions
@@ -164,6 +164,7 @@ module.exports = {
    'server-rs/target-*',
    'apps/desktop-shell/src-tauri/target',
    'apps/ai-game-creator-shell/src/features/ui-editor/types/**',
+    'apps/ai-game-creator-shell/src/features/project-workspace/generated/**',
    'target',
    'src/main.tsx',
    'src/App.tsx',
@@ -1 +1,4 @@
+# Git 在链接工作树里执行 Hook 时会注入 GIT_DIR 等仓库定位变量，优先级高于 cwd；
+# 子进程（npm、lint-staged、测试夹具）会继承它们并写到真实仓库，故在入口统一清除。
+unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE GIT_COMMON_DIR GIT_PREFIX GIT_CONFIG_PARAMETERS GIT_CEILING_DIRECTORIES
 npm run format:staged
@@ -1 +1,4 @@
+# Git 在链接工作树里执行 Hook 时会注入 GIT_DIR 等仓库定位变量，优先级高于 cwd；
+# 钩子链（npm → check:repository-ci → 测试夹具）会继承它们并写到真实仓库，故在入口统一清除。
+unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE GIT_COMMON_DIR GIT_PREFIX GIT_CONFIG_PARAMETERS GIT_CEILING_DIRECTORIES
 npm run check:pre-push-master -- "$@"
@@ -57,6 +57,7 @@
    "react-colorful": "^5.8.0",
    "react-dom": "^19.0.0",
    "react-markdown": "^10.1.0",
+    "rehype-highlight": "^7.0.2",
    "remark-gfm": "^4.0.1",
    "vite": "^6.2.0",
    "zustand": "^5.0.14"
@@ -0,0 +1,113 @@
+import assert from 'node:assert/strict';
+import { mkdir, mkdtemp, rm, writeFile } from 'node:fs/promises';
+import { tmpdir } from 'node:os';
+import { dirname, join } from 'node:path';
+import { test } from 'node:test';
+import { setTimeout as delay } from 'node:timers/promises';
+import { fileURLToPath } from 'node:url';
+
+import { createServer, loadConfigFromFile, normalizePath } from 'vite';
+
+test(
+  'AGC 排除 Rust 构建目录且保留源码与共享组件监听',
+  { timeout: 30_000 },
+  async () => {
+    const loaded = await loadConfigFromFile(
+      { command: 'serve', mode: 'development' },
+      fileURLToPath(new URL('../vite.config.ts', import.meta.url)),
+    );
+    assert.ok(loaded);
+    assert.notEqual(loaded.config.server?.watch, null);
+    assert.notEqual(loaded.config.server?.hmr, false);
+    assert.ok(
+      [loaded.config.server?.watch?.ignored]
+        .flat()
+        .includes('**/src-tauri/target/**'),
+    );
+
+    const fixture = await mkdtemp(join(tmpdir(), 'agc-vite-watch-'));
+    const root = join(fixture, 'apps', 'ai-game-creator-shell');
+    const source = join(root, 'src', 'main.js');
+    const css = join(root, 'src', 'styles.css');
+    const shared = join(fixture, 'packages', 'shared', 'src', 'component.js');
+    const target = join(root, 'src-tauri', 'target');
+    const artifact = join(target, 'debug', 'incremental', 'cache.bin');
+    let server;
+    try {
+      for (const file of [source, css, shared, artifact]) {
+        await mkdir(dirname(file), { recursive: true });
+        await writeFile(
+          file,
+          file === css ? 'body { color: red; }' : 'export default 1;',
+        );
+      }
+      // 使用真实 Vite watcher 和实际配置，仅将扫描根替换为小型夹具；
+      // 不加载业务插件、后端或原生窗口，也不扫描开发机上的大型 target。
+      server = await createServer({
+        configFile: false,
+        envFile: false,
+        root,
+        logLevel: 'silent',
+        server: {
+          watch: loaded.config.server?.watch,
+          middlewareMode: true,
+          hmr: false,
+          fs: { allow: [fixture] },
+        },
+        optimizeDeps: { noDiscovery: true, include: [] },
+      });
+      const waitForWatchedFile = async (file) => {
+        const normalized = normalizePath(file);
+        for (let attempt = 0; attempt < 100; attempt += 1) {
+          if (
+            Object.entries(server.watcher.getWatched()).some(
+              ([directory, names]) =>
+                names.some(
+                  (name) => normalizePath(join(directory, name)) === normalized,
+                ),
+            )
+          )
+            return;
+          await delay(50);
+        }
+        assert.fail(`源码必须仍被监听：${normalized}`);
+      };
+      await waitForWatchedFile(source);
+
+      // 真实模块转换应将 root 外的共享源码加入监听。
+      await server.transformRequest(`/@fs/${normalizePath(shared)}`);
+      for (const file of [source, css, shared]) {
+        const normalized = normalizePath(file);
+        await waitForWatchedFile(file);
+        const changed = new Promise((resolve, reject) => {
+          const timer = setTimeout(() => {
+            server.watcher.off('change', onChange);
+            reject(new Error(`未收到源码变更：${normalized}`));
+          }, 5_000);
+          function onChange(path) {
+            if (normalizePath(path) !== normalized) return;
+            clearTimeout(timer);
+            server.watcher.off('change', onChange);
+            resolve();
+          }
+          server.watcher.on('change', onChange);
+        });
+        await writeFile(
+          file,
+          file === css ? 'body { color: blue; }' : 'export default 2;',
+        );
+        await changed;
+      }
+      const targetPath = normalizePath(target);
+      const targetDirectories = Object.keys(server.watcher.getWatched())
+        .map(normalizePath)
+        .filter(
+          (path) => path === targetPath || path.startsWith(`${targetPath}/`),
+        );
+      assert.deepEqual(targetDirectories, [], 'Rust target 不应创建目录监听器');
+    } finally {
+      await server?.close();
+      await rm(fixture, { recursive: true, force: true });
+    }
+  },
+);
@@ -1,4 +1,4 @@
-概念阶段定稿时，还必须创建或更新 `project/速览卡.md`。Runtime 只检查该文件是否存在，不检查内容。请使用下面的固定结构，不要加入审批操作说明或独立的决定状态段落：
+概念阶段定稿时，创建或更新 `project/速览卡.md`。下面是速览卡的参考结构；根据游戏类型、项目规模和用户要求选择字段，同类内容可以合并，项目不需要的字段可以省略，复杂项目可以增加必要字段。表格和列表中的示例行可按实际对象逐行扩展，不代表数量上限：

 # 速览卡：《游戏名》

@@ -20,7 +20,7 @@

 ## 6. 核心循环

-## 7. 目标用户
+## 7. 目标用户与情境
 - 核心用户：
 - 游戏偏好：
 - 单次游玩时长：
@@ -33,7 +33,7 @@ description: 写"美术圣经"（美术侧）分册时使用。与总纲（技
   对象（资产总清单的范围）、物品表（item_id 绑定依据，数据侧已定）、
   画风 skill（全局画风库可引用）。
 2. 本件在数据侧表结构定稿后开写（素材清单引用 item_id）。
-3. 读金样 exemplars/stardew-tdd-art-bible.md——契约表与资产状态表的登记密度以它为准（同层只读一次）。
+3. 读取金样 exemplars/stardew-tdd-art-bible.md 了解契约表与资产状态表包含的信息类型（同层只读一次）。

 ## 三、怎么写（模板即流程，按节）

@@ -34,7 +34,7 @@ description: 写"数据与配表"（数据侧）分册时使用。与总纲（
   （架构层的定性基准，在本件落成前 N 日验算）。
 2. 先读两份提取件：字段字典全套规则与验收模板已在那里成文，本件是
   项目实例化，不是重新发明。
-3. 读金样 exemplars/stardew-tdd-data.md——总清单规模、验算表与验收结论的写法以它为准（同层只读一次）。
+3. 读取金样 exemplars/stardew-tdd-data.md 了解数据清单、验算表与验收结论包含的信息类型（同层只读一次）。

 ## 三、怎么写（模板即流程，按节）

@@ -28,7 +28,7 @@ description: 写"技术实现"（程序侧）分册时使用。与总纲（技
 1. 输入齐了吗：架构层系统范围表+P0 清单（拆模块依据）、数据侧表结构契约
   （加载与校验要引用）、skill 选型卡（实现类需求先查卡，不自造轮子）。
 2. 读总纲判断立场；本件在数据侧表结构定稿后开写。
-3. 读金样 exemplars/stardew-tdd-tech.md——各节的填充密度与"实证参照"写法以它为准（同层只读一次）。
+3. 读取金样 exemplars/stardew-tdd-tech.md 了解技术实现文档包含的信息类型（同层只读一次）。

 ## 三、怎么写（模板即流程，按节）

@@ -13,10 +13,13 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 > 本文件是系统架构层唯一承载写作流程的教学件。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。

+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据游戏类型、项目规模、用户要求和顶层设计判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以压缩为最小可用架构。
+
 ## 一、这一层的判断立场
 你是架构师，切系统的刀在你手里。在这个层里你相信：
- 切分是为了**职责清晰、可独立讨论**，不是为了凑数量——每个系统必须能
-  一句话答出"删了它，什么塌"（P0 原因）。
+- 切分是为了**职责清晰、可独立讨论**，不是为了凑数量。只有确实需要独立职责、状态或数据边界的部分才拆成系统；每个实际拆出的系统应能说明删除后的影响。
 - **数据所有权唯一**：同一事实只由一个系统维护，其他系统只引用稳定 ID，
  不复制主数据。两个系统管同一件事 = 架构事故。
 - **依赖无环**是硬要求；信息呈现层只读状态、只经行动入口写入。
@@ -28,11 +31,11 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 ## 二、动笔前
 1. 顶层设计已定稿可用——把它的**系统范围表**（粗清单）和**顶层定稿约束**
   摊开当输入；切分是对粗清单的正式化（拆、并、裁都在这层做）。
-2. 读 exemplars/stardew-architecture.md 做质量锚（模仿密度，不抄内容），
+2. 读取 exemplars/stardew-architecture.md 了解内容组织方式，
   然后往 templates/architecture.md 里填。
 3. 记住顶层的核心循环图——切完必须跑覆盖检查。

-## 三、十二节总览：写什么、为什么、怎么咬合
+## 三、架构设计的组织维度：写什么、为什么、怎么咬合

 架构文档回答四个问题：
 **这个架构为什么这样切（1~3）→ 系统是什么、怎么连接（4~6）→
@@ -88,7 +91,7 @@ description: 写游戏策划案（GDD）系统架构时使用。在顶层设计
 Sxx 编号清单（核心系统通常 1-5 个，有明确要求可超出 5 个）+ 支撑层（存档/UI，不拥有核心规则）。
 P0 段五列表：
 | 系统 | 目的 | 输入 | 输出 | P0 原因 |
-→ 每行 P0 原因必须答"删了它，__ 塌"；答不出的降级或合并。
+→ 对实际拆出的系统说明删除后的影响；无法形成独立职责的部分合并，不为满足数量新增系统。

 ### 3. 系统职责
 | 系统 | 主要职责 | 不负责 → 移交谁 |
@@ -13,6 +13,10 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 > 本文件是概念层唯一承载写作流程的教学件。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。

+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据游戏类型、项目规模、用户要求和上层已定范围判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
+
 ## 一、这一层的判断立场
 你是资深游戏策划，看过上千份概念案，清楚绝大多数死在"什么都说、什么都不尖"。
 在这个层里你相信：
@@ -27,11 +31,11 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 ## 二、动笔前
 1. 拿到用户真实回答过的定调信息（参照对象、题材偏好、压力档位）。
   没有 → 先问一个定调问题，禁止自问自答充当用户。
-2. 读 exemplars/stardew-concept.md 做质量锚（模仿密度，不抄内容），
+2. 读取 exemplars/stardew-concept.md 了解内容组织方式，
   然后往 templates/concept-design.md 里填。
 3. 零参照时在文档头注明"零参照"。

-## 三、九节总览：写什么、为什么、怎么咬合
+## 三、概念设计的组织维度：写什么、为什么、怎么咬合

 概念文档回答四个问题：
 **这是什么（1~5）→ 它不是什么（6）→ 它靠什么让人一直玩（7）→
@@ -50,7 +54,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 | 6 | 不是什么 | 负面定位表：不是 X，因为 Y | 正面定义写多必然发散；负面定位用"误会方向+封死原因"收边界，比光秃的非目标锋利一档 | 2 的非目标与跑偏风险的表化展开；与 5 的防串味声明呼应 |
 | 7 | 核心张力 | 玩家持续面对的两难，两端各有代价 | 长期游玩的根本动力；没有张力，再丰富的内容玩几次就腻 | **向下接口**：每条张力必须在顶层变成取舍表里的具体决策 |
 | 8 | 边界与约束 | 本层只定什么、什么留给后面 + 规模回流 | 防止概念层越层写数值和系统（越层是下游返工之源）；给写作画线 | 保护 2 的纯度；告诉顶层"你们的地盘从哪开始" |
-| 9 | 概念定稿 | "核心不是 __ 而是 __"重述 + 给顶层的硬约束 | 收口重锤：写完九节重述一遍，检验整份文档有没有写散；把承诺变成对下的契约 | 回环呼应 1；把 8 的交接具体化成 2~4 条硬约束 |
+| 9 | 概念定稿 | "核心不是 __ 而是 __"重述 + 按需记录给顶层的约束 | 收口并检查概念是否写散；把承诺转成对下的契约 | 回环呼应 1；把边界和交接约束传给下一层 |

 咬合一图：

@@ -80,7 +84,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 **定调记录**（全项目调性真源，此节定死）：
 - 参照选择：以 __ 为主、__ 学 __（参照即定调，选完调性随之而来）。
 - 调性滑杆：压力感/战斗比重/管理深度/叙事比重/节奏，各一档。
- 调性锚 T 原则：3~7 条逐条具名（如"T2 不劝退——凡惩罚类问题默认取最轻档"）。
+- 调性锚 T 原则：按项目需要提炼并逐条具名（如"T2 不劝退——凡惩罚类问题默认取最轻档"）。
  检验：每条 T 都能当一句 IF-THEN 用——"凡__类问题默认__"；写不出口径的 T 是空话。
  → 下游每个开放问题先来这里级联批量起草，级联不了的才升级提问。
 **设计锚点（六项，争议时的仲裁原则，全部具名）**
@@ -112,8 +116,7 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 ### 7. 核心张力
 - __ 有限，但 __。
 - __ vs __（两端的代价各是什么）。
-→ 每条两端都必须有代价，只有一端的"假张力"删掉。这些是顶层取舍表的
-  种子，后面要逐条对应。
+→ 如果项目存在核心张力，保留的每条张力都应说明双方代价；没有形成有效张力时，不为了满足结构新增张力。这些是顶层取舍表的种子，后面按需对应。

 ### 8. 边界与约束
 - 概念边界放首位：本层只定幻想、用户、基调与排除方向；具体数值、
@@ -124,9 +127,9 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 ### 9. 概念定稿（收口重锤）
 这个游戏的核心不是 __，而是：
 > （一句话重述核心承诺）
-交给下一层的约束：__ 必须 __（2~4 条，顶层必须围绕它们展开）。
+交给下一层的约束：按项目需要记录，顶层据此展开。

-某节对本项目没意义 → 写一行"略，因为 __"，不硬凑。
+若某节对本项目没意义，直接省略。

 ## 五、分析文档（全局一份，按层分节）

@@ -158,4 +161,4 @@ description: 写游戏策划案（GDD）概念层时使用。把一句话游戏
 ## 七、红线（只有三条）
 1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
 2. 不越层：出现具体数值、按键、界面即删。
-3. 不凑数：写不满就说明缺什么，禁止万金油句填充。
+3. 不凑数：章节对项目有意义但信息不足时，记录已确定内容与待补问题；章节对项目无意义时，直接省略。
@@ -12,6 +12,10 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 > 本文件是系统文档层的总纲；各系统的专属写法在 `modules/system-types/` 下对应目录的 `SKILL.md`，
  专属模板在 `modules/system-types/` 对应目录的 `模板.md`。通用纪律不在各系统 skill 里重复。

+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据系统类型、实际复杂度、用户要求和架构职责判断适用项：适用项写入，同类项可合并，若某项对本系统没意义则省略；复杂系统可以拆分补充，简单系统可以压缩为最小可执行规格。
+
 ## 一、这一层的判断立场
 你是写单个系统的策划。在这个层里你相信：
 - 系统文档是**执行层**：刀已经在架构层切好——服从系统地图编号、职责表
@@ -20,7 +24,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
  防返工价值最高的几行。
 - 接口纪律：引用具名系统与具名数据，禁泛称；别家主数据只引 ID 不复制。
 - 字段定义、数值配置、表结构不归你——写交接声明，交技术文档层（数值策划）。
- 所有系统同构：读者读熟一份就能读所有份。
+- 系统文档保持基本可读的一致性，但不要求所有系统使用相同章节；结构应服从系统类型和实际行为。

 ## 二、动笔前
 1. 架构已定稿：找到本系统的 Sxx 编号、职责表行、依赖方向——这是合同。
@@ -43,7 +47,7 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 | 5 | 取舍表 | 玩家在本系统内的决策 | 张力在系统内的落地 | 概念张力→顶层取舍表→本表 |
 | 6 | 状态与规则 | 对象/状态/转换/异常，枚举表达 | 定性规则真源 | 架构职责表对齐 |
 | 7 | 数值与数据交接 | 本系统交 TDD 的数据类别+定性约束 | 分层边界 | 技术文档层承接 |
-| 8 | 反馈 | 何时/何强度/何通道 | 无反馈=没发生 | 顶层反馈四层 |
+| 8 | 反馈 | 关键结果何时、以何种方式反馈 | 让实际结果可理解 | 与本系统实际结果对应 |
 | 9 | 内部循环 | 本系统内的小循环 | 系统自己的心跳 | 顶层小循环的组成 |
 | 10 | 输入、输出与依赖 | 消费/交付/依赖谁 | 接口真源 | 架构依赖图逐边对齐 |
 | 11 | 边界与非目标 | 不负责什么→移交谁 | **防返工价值最高** | 架构职责表"不负责"列 |
@@ -57,12 +61,12 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪

 1 系统目的：若删除它，__ 会塌——一句话说不出 = 该系统不该存在。
 2 支撑体验：对应顶层目标第__条、调性原则第__条。
-3 进入与退出：常规进入/读档恢复/特殊事件后返回，三入口必写。
-4 玩家行动：≥4 个具名动词组；编排类写"安排"动词，活动类写"操作"动词。
+3 进入与退出：按本系统实际存在的入口、退出和恢复路径记录。
+4 玩家行动：记录本系统实际存在的具名动词组；编排类写"安排"动词，活动类写"操作"动词。
 5 取舍表：决策/立即收益/延迟收益/主要代价；挂顶层张力编号。
 6 状态与规则：对象-状态-转换-异常，全部枚举表达，不许整段散文。
 7 数值与数据交接：列数据类别名 + 设计侧定性约束；字段定义归 TDD。
-8 反馈：每种关键结果给独立反馈形态；失败必须说明原因和恢复路径。
+8 反馈：记录本系统关键结果的可理解反馈；存在失败时说明原因和恢复路径。
 9 内部循环：动词链；可拆单次/区域/长期三层。
 10 输入输出与依赖：引用具名系统与具名数据，禁泛称"资源"。
 11 边界与非目标：参考该类型 skill 的“三不”说明边界；建议说明字段与数值的交接边界。
@@ -100,4 +104,4 @@ description: 写单个系统的设计文档（Sxx）时的总纲——通用纪
 1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
 2. 不越层：不翻架构的案（要改走分析文档+登记表），不写字段数值（归 TDD），
  不替别的系统定规则。
-3. 不凑数：写不出"删了塌什么"、填不满的节，说明缺料——停笔说明，不硬凑。
+3. 不凑数：写不出"删了塌什么"的系统直接删除；章节对项目有意义但信息不足时，记录已确定内容与待补问题。
@@ -12,12 +12,16 @@ description: 写游戏技术文档（TDD）时使用的总纲。GDD 四层定稿
 > 本文件是 TDD 层唯一承载写作流程的教学件；各分册 SKILL 与模板配套使用。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。

+## 〇、结构适配原则
+
+本分册的文档件、章节、字段和数量是参考结构，不是固定清单。先根据当前版本的实现目标、游戏规模、运行时和用户要求判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以合并为最小施工合同。
+
 ## 〇、TDD 的完成判据（总纲）

-**TDD 是自足构建包：一个施工 agent 只看 TDD，就能做完完整游戏。**
+**TDD 是当前版本的施工合同：施工方只看 TDD，应能完成本项目实际范围内的实现。**
 GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施工看）。
-检验方式＝自足性检查（见总册）：不看 GDD 能否回答——每个系统怎么行为、
-每张表多少行内容、每个界面怎么走、每份素材什么规格。答不出的项就是缺口，
+检验方式＝按项目范围检查施工所需信息是否齐全：实际存在的系统怎么行为、
+实际使用的表和配置怎么读取、实际存在的界面怎么走、实际需要的素材什么规格。答不出的项就是缺口，
 缺口回 GDD 同步后**收编**进 TDD（带版本锁）。收编是构建期快照：GDD 定稿
 变更 → 触发对应收编节重同步（与 fast_gdd 投影同一机制，方向相反）。

@@ -36,8 +40,7 @@ GDD 是设计真源（给人看、给迭代看）；TDD 是构建真源（给施
  TDD 不擅自换运行时。
 - **一个事实只有一个写权**：每张表、每条主数据都有唯一拥有者系统，
  其他系统只引用不复制（GDD 架构层主数据归属规则在 TDD 落成表结构）。
- **验收是硬闸不是仪式**：有 blocker 禁止扩充内容——这条竞品四十轮实测
-  验证过，照抄。
+- **验收是硬闸不是仪式**：有 blocker 禁止扩充内容。
 - **先少量验证再量产**（美术）/ **先建索引再转表**（数据）——任何方向都
  不做"做完一大批才发现不对"的事。

@@ -13,6 +13,10 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 > 本文件是顶层设计唯一承载写作流程的教学件。
 > 模板与例子文件保持纯净：不含任何步骤、检验提示与标记。

+## 〇、结构适配原则
+
+本分册的章节、字段和数量是参考结构，不是固定清单。先根据游戏类型、项目规模、用户要求和概念层定稿判断适用项：适用项写入，同类项可合并，若某项对本项目没意义则省略；复杂项目可以拆分补充，简单项目可以压缩为最小可用规格。
+
 ## 一、这一层的判断立场
 你是资深游戏策划，正在写全 GDD 最重要的一份文档——概念说"凭什么成立"，
 顶层说"好玩在哪"。核心循环无趣，后面写再多系统也救不回来。在这个层里你相信：
@@ -26,11 +30,11 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定

 ## 二、动笔前
 1. 概念层 design.md 已定稿可用——顶层定位与取舍表直接从它长出来。
-2. 读 exemplars/stardew-top-design.md 做质量锚（模仿密度，不抄内容），
+2. 读取 exemplars/stardew-top-design.md 了解内容组织方式，
   然后往 templates/top-design.md 里填。
-3. 把概念层的核心张力清单摊开放在手边——取舍表必须逐条挂上编号。
+3. 把概念层已确认的核心张力作为输入；存在对应取舍时再挂上编号。

-## 三、十六节总览：写什么、为什么、怎么咬合
+## 三、顶层设计的组织维度：写什么、为什么、怎么咬合

 顶层文档回答四个问题：
 **玩家在玩什么（1~9）→ 玩家面对什么选择与后果（10~11）→
@@ -43,14 +47,14 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 |---|---|---|---|---|
 | 1 | 顶层定位与规模锚点 | 承概念定稿 + "让玩家每天都在想"念头句 + 不是X不是Y + 规模参数表（循环单位/段落/复杂度/长期主轴） | 循环单位定错全盘错；定位句防止顶层漂离概念 | 承概念层"概念定稿"；念头句是概念层玩家念头的时间维度版 |
 | 2 | 设计目标 | 几种回报、如何互相供给 | 回报并列=小游戏拼盘；互相供给才是循环 | 供给关系落到 4~5 的循环里 |
-| 3 | 核心推动力 | 动机主次 + 即时/日程/季节/长期四层推动 | 玩家"什么时候被什么推着走"的完整图谱 | 时间四层对应 10 节奏结构的四层 |
+| 3 | 核心推动力 | 按项目实际存在的即时、阶段或长期推动力组织 | 玩家"什么时候被什么推着走"的推动结构 | 与实际节奏结构对应 |
 | 4 | 大循环 | 跨较长时间的循环：文字箭头 + 核心循环图 | 长期留存的结构骨架 | 与 5、7 三层互检：大循环的每环应有小循环供血 |
-| 5 | 小循环 | 几十秒到几分钟的具名动词链 ×3+ | 真正被玩到的那层；动词链可直接复制进实现 | 检验：删掉某条，游戏是否少了一块可命名的乐趣 |
-| 6 | 资源流与输入输出 | 资源流图（来源→储存→消耗）+ 输入输出清单 + 反馈四层 | 资源是循环的血液；防白给、防废物、防套利 | 供血给 4~5 的每个循环环节 |
+| 5 | 小循环 | 按项目实际存在的局内或短周期动词链组织 | 记录真正被玩到的循环 | 按实际循环层级互检 |
+| 6 | 资源流与输入输出 | 按项目实际存在的资源流、输入输出和反馈组织 | 说明循环中的实际供给与结果 | 与实际循环环节对应 |
 | 7 | 最小体验单位 | 多短一段玩法就能体现独有乐趣 + 反馈铁律 | 原型只做这一个单位——定原型规模 | 是 5 的最小切片；14 验证标准的试验对象 |
 | 8 | 核心活动流程 | 段落表：阶段/玩家行为/**设计目的** | "玩这个游戏的一天"的可复述剧本 | 设计目的列写不出的段=该删的段 |
 | 9 | 取舍表 | 决策/立即收益/延迟收益/主要代价 | 张力的具体化——玩家决策的路口 | **逐条对应概念层核心张力**（对上接口） |
-| 10 | 节奏结构 | 日内/周内/季节/长期四层 + 情绪摆动 | 防止"一直紧张"或"一直平"；摆动才有呼吸 | 四层对应 3 的推动力四层 |
+| 10 | 节奏结构 | 按项目实际存在的时间层级和情绪变化组织 | 说明玩法节奏如何变化 | 与实际推动力层级对应 |
 | 11 | 失败与回收 | 亏损定性 + 情况/结果表 | 失败的形态决定调性——"少拿"还是"毁掉" | 对齐概念层情绪基调的边界句 |
 | 12 | 系统范围 | 系统/顶层目的/**边界** 表 | 架构层接口：系统地图的种子 | **对下接口**：架构照此拆系统 |
 | 13 | 范围与非目标 | 最小完整版本清单 + 不做清单 | 立项交付物的边界 | 承概念层"不是什么"；给 14 提供验证范围 |
@@ -96,24 +100,24 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 ### 3. 核心推动力
 - 动机主次：__。
 - 即时推动 __；日程推动 __；季节推动 __；长期推动 __。
-→ 四层都要有实指；空着的那层就是将来留存崩塌的地方。
+→ 只展开项目实际存在的时间层级；不存在的层级不设字段。

 ### 4. 大循环
 **__ → __ → __ → __ → 回到 __。**（附核心循环图）
 → 检验：断掉任何一环，后面是否塌；每一环应有对应小循环供血。

-### 5. 小循环（具名动词链 ×3+）
+### 5. 小循环（按项目实际数量）
 **__循环**：__ → __ → __ → __ → __。
 → 必须具名（"农务循环"不是"资源循环"）；动词链完整到可以直接照做。

 ### 6. 资源流与输入输出
 （资源流图：每种核心资源 来源 → 储存 → 消耗 三段全）
-主要输入 __；主要输出 __；反馈四层：立即 __ / 短期 __ / 中期 __ / 长期 __。
+主要输入 __；主要输出 __；按项目需要记录反馈层级。
 → 三问：这资源哪来的？存在哪？花在哪去？答不出=资源设计未完成。

 ### 7. 最小体验单位
 __（多短一段玩法体现独有乐趣——原型只做这一个单位）。
-单个行动必须至少提供一种清晰反馈：资源/进度/能力/关系/信息/视觉状态之一。
+保留的玩家行动应有与玩法相称的可理解反馈；反馈形式和数量按项目决定。

 ### 8. 核心活动流程（段落表）
 | 阶段 | 玩家行为 | 设计目的 |
@@ -153,7 +157,7 @@ __（多短一段玩法体现独有乐趣——原型只做这一个单位）。
 顶层当前定稿为：__（循环单位、核心结构、关键档位一句话说全）。
 后续架构必须围绕 __ 拆系统；不得 __。

-某节对本项目没意义 → 写一行"略，因为 __"，不硬凑。
+若某节对本项目没意义，直接省略。

 ## 五、分析文档（全局一份，按层分节）

@@ -187,4 +191,4 @@ __（多短一段玩法体现独有乐趣——原型只做这一个单位）。
 ## 七、红线（只有三条）
 1. 不冒充用户决定：用户没说的方向标"待确认"，正文不写死。
 2. 不越层：向上不翻概念层的案，向下不写系统内部规则与具体数值。
-3. 不凑数：写不满就说明缺什么，禁止万金油句填充。
+3. 不凑数：章节对项目有意义但信息不足时，记录已确定内容与待补问题；章节对项目无意义时，直接省略。
@@ -1,5 +1,7 @@
 ### C1 模板_系统架构.md（→ templates/architecture.md）

+本模板是参考结构，不是固定清单。只有需要独立职责、状态或数据边界的部分才拆成系统；简单项目可以合并系统和章节，复杂项目可以增加必要的系统与校验。表格中的示例行可按实际系统、风险和问题扩展，不代表数量上限。
+
 # 系统架构：《游戏名》

 ## 架构定位与目标
@@ -18,6 +20,7 @@
 |---|---|---|---|
 | S01 | __ | __ | P0 |
 | S02 | __ | __ | |
+（以上为示例，可按实际系统删减或扩充。）

 支撑层（不拥有核心规则）：__。

@@ -105,6 +108,8 @@ flowchart LR
 | 风险 | 校验方式 |
 |---|---|
 | __ | __ |
+（按实际风险逐行补充。）

 ## 开放的结构问题
 - __
+（按实际问题逐条补充。）
@@ -1,5 +1,7 @@
 ### C1 模板_概念设计.md（→ templates/concept-design.md）

+本模板是参考结构，不是固定清单。填写前按项目类型、规模和用户要求筛选章节与字段；同类内容可合并，若某节对项目没有实际意义则删除，复杂项目可增加必要内容。表格和列表中的示例项可按实际内容扩展，不代表数量上限。
+
 # 概念设计：《游戏名》

 ## 一句话概念
@@ -10,14 +12,14 @@
 ### 定调记录（全项目调性真源，级联决策的依据库）
 - 参照选择：以《__》为主（__, 学 __）；不参考 __。
 - 调性滑杆：压力感 __ / 战斗比重 __ / 管理深度 __ / 叙事比重 __ / 节奏 __。
- 调性锚（T 原则，逐条具名，下游每个开放问题先来这里级联）：
-  T1 __；T2 __；T3 __；T4 __；T5 __。
+- 调性锚（按项目需要逐条具名，下游开放问题按需从这里级联）：
+  T__ __。

 ### 设计锚点（六仲裁位）
 - 核心幻想：__。
  玩家念头："__"
 - 目标体验：__。
- 玩家动机：短期 __；长期 __。
+- 玩家动机（按项目实际存在的时间尺度填写）：__。
 - 核心循环：__ → __ → __ → __ → 回到 __。
 - 跑偏风险：__。
 - 非目标：__（详见《不是什么》）。
@@ -1,5 +1,7 @@
 ### C3 02_美术圣经/模板.md（→ templates/tdd-art-bible.md）

+本模板是美术实施的参考结构。按项目实际需要选择角色、场景、UI、动画和素材契约；没有对应资产类型时删除相应章节，复杂项目可增加必要的视觉规则。表格和资产条目可按实际内容扩展，不代表数量上限。
+
 # 美术圣经：《游戏名》

 > 状态：{drafting / reviewed / frozen}　|　定调锚：概念层@v{N} 第 2 节　|　style_id：`__`
@@ -10,7 +12,7 @@ __（一段话：从定调记录翻译的视觉气质；参考图位 __ 张）

 ## 视觉锚

- 关键词：__（3~5 个）。
+- 关键词：__（按项目需要）。
 - 禁用关键词：__。
 - 色板：主色 __ / 辅色 __ / 点缀 __（配比 __）；昼夜·天气·季节表现 __。
 - 形状语言：__。
@@ -40,6 +42,7 @@ __（承 UI 系统文档的界面清单；视觉语言与信息分层对齐）
 | 素材 | 规格（尺寸/帧数/方向数） | 命名规则 | atlas 格式 | 验收 | 绑定 |
 |---|---|---|---|---|---|
 | __ | __ | __ | __ | __ | `item_ __` / 豁免：__ |
+（以上为示例，可按实际素材删减或扩充。）

 - 绘制工艺：__（用陶泥儿 MCP 的路径与参数；封装流程）。
 - 豁免类型仅限：程序化生成 / UI 文本 / 本期不需要。
@@ -49,17 +52,19 @@ __（承 UI 系统文档的界面清单；视觉语言与信息分层对齐）
 | asset_id | 规格 | 绑定 | 状态 | 验收记录 | contract_version |
 |---|---|---|---|---|---|
 | __ | __ | `item_ __` / 豁免 | 缺失/草稿/已交付/已验收/已接入 | 技术过/视觉过 @__ | __ |
+（以上为示例，可按实际资产删减或扩充。）

 - 状态单向流转：缺失 → 草稿 → 已交付 → 已验收 → 已接入；驳回退回草稿并记原因。
 - 验收两维：技术（尺寸/透明/帧数/命名）+ 视觉（对照视觉锚）；两维都过才进"已验收"。
- 每个 gameplay 可见对象必有一行，或显式豁免——没有第三种状态。
+- 需要登记的 gameplay 可见对象有一行；不需要资产登记的对象不建立空记录。
 - 程序接入后填消费点（哪个模块加载、事件映射），`contract_version` 变更须重验收。

 ## 量产流程与验证

 1. 概念候选 __ 张 → 2. 人选方向 → 3. 锚点图 __ 张 → 4. 锁圣经 →
 5. 写契约 → 6. 小批 __ 张 → 7. 技术检查（__）→ 8. 接入程序 →
-9. 运行时截图验收（桌面/移动双视口下 __ 可辨）→ 10. 扩产。
+9. 运行时验收（按项目支持的平台）→ 10. 扩产。
+（以上为示例，可按实际流程删减或扩充。）

 ## 开放问题回执

@@ -1,5 +1,7 @@
 ### C3 03_数据与配表/模板.md（→ templates/tdd-data.md）

+本模板是数据与配表的参考结构。只有项目实际存在配置、枚举、关系或条件数据时才建立对应表和校验；简单项目可以直接写配置约定，复杂项目再拆分表结构与验算流程。表格中的示例行可按实际数据、字段和验算项扩展，不代表数量上限。
+
 # 数据与配表：《游戏名》

 > 状态：{structuring / filling / accepted}　|　基于：各系统交接节汇总　|　验收：check@{id} 最新结论 __
@@ -9,6 +11,7 @@
 | 表格组 | 建议表名 | 主要维护系统 |
 |---|---|---|
 | __ | __ | __ |
+（以上为示例，可按实际数据表删减或扩充。）

 （表格拆分是生产组织方式，不改变主数据归属。）

@@ -26,7 +29,7 @@
 |---|---|---|---|---|---|---|
 | __ | date_day / progress_flag / skill_level / schedule_open / quest_completed / __ | __ | __ | __ | active | __ |

-（复杂条件拆条件组+条件行；全项目只此一个条件入口，程序实现一次 `check(condition_id)`。）
+（存在复杂条件时再拆条件组与条件行；没有条件系统时删除本节。）

 ## 工作簿组织与建表顺序

@@ -36,6 +39,7 @@

 建表顺序：①物品表（公共 item_id）→ ②__ → ③__ → ④__ → ⑤__ → ⑥__ → ⑦__ → ⑧__。
 每完成一组查三件事：引用 ID 存在 / 条件有负责系统 / 同一数值只有一个系统维护。
+（以上为示例，可按实际表结构删减或扩充。）

 ## 表格-程序契约

@@ -54,12 +58,14 @@
 | 表 | 字段 | 默认值 | 依据 | 推翻条件 |
 |---|---|---|---|---|
 | __ | __ | __ | T__ / 台账 id | __ |
+（以上为示例，可按实际验算字段删减或扩充。）

 - 前五日闭环验算：

 | 日期 | 主目标 | 关键行动 | 主要成本 | 主要获得 | 结果 |
 |---|---|---|---|---|---|
 | 第 1 日 | __ | __ | __ | __ | __ |
+（以上为示例，可按实际循环或阶段删减或扩充。）

 - 收益链校验：`__ → __ → __ → __ → __`（逐环引 ID）。

@@ -1,5 +1,7 @@
 ### C3 模板_TDD总册.md（→ templates/tdd-master.md）

+本模板是 TDD 总册的参考结构。只建立当前项目实际需要的技术、美术、数据和索引内容；没有对应方向时不创建空分册，复杂项目可以增加施工所需的分册。表格中的示例行可按实际分册、问题和验收项扩展，不代表数量上限。
+
 # TDD 总册：《游戏名》

 > 本册是 TDD 层的封面与索引：正文在三件分册（01 技术实现 / 02 美术圣经 / 03 数据与配表），
@@ -7,19 +9,19 @@

 ## 自足性检查（TDD 的完成判据）

-> 标准：一个施工 agent 只看 TDD，能做完完整游戏。逐项模拟它必问的问题，
+> 标准：施工方只看当前 TDD，能完成项目实际范围内的实现。逐项检查当前项目真正需要的问题，
 > 答得出=过；答不出=缺口（列 GDD 来源与同步动作）。

 | # | 施工 agent 的问题 | 答案在哪 | 状态 |
 |---|---|---|---|
-| 1 | 每个系统怎么行为（规则/行动/反馈）？ | 01 收编章（@v{N}） | __ |
-| 2 | 每张表有多少行内容、文本全填了吗？ | 03 全量填充+完成度验收 | __ |
-| 3 | 每个界面长什么样、怎么走？ | 01 UI 交互规格 | __ |
-| 4 | 每份素材什么规格、谁验收过？ | 02 资产状态表（全行非缺失） | __ |
+| 1 | 实际存在的系统怎么行为？ | 01 收编章（@v{N}） | __ |
+| 2 | 实际使用的表和配置是否可施工？ | 03 数据与配表 | __ |
+| 3 | 实际存在的界面怎么走？ | 01 UI 交互规格 | __ |
+| 4 | 实际需要的素材什么规格？ | 02 资产状态表 | __ |
 | 5 | 代码怎么组织、跑在哪？ | 01 代码组织+能力边界 | __ |
 | 6 | 怎么算做完了（判据）？ | 01 里程碑+各件验收 | __ |

-全部为"过"时，TDD 进入 frozen——构建可以完全脱离 GDD 进行。
+当前项目所需检查全部为"过"时，TDD 进入 frozen——构建可以在本版本范围内脱离 GDD 进行。

 ## 三件状态

@@ -54,7 +56,7 @@

 | 件 | 最近验收 | blocker | 结论 |
 |---|---|---|---|
-| 01 | __（构建+双视口验证 @__） | __ | __ |
+| 01 | __（按项目平台验证 @__） | __ | __ |
 | 02 | __（技术+视觉两维 @__） | __ | __ |
 | 03 | __（七查 @check_id） | __ | __ |

@@ -1,9 +1,11 @@
 ### C3 01_技术实现/模板.md（→ templates/tdd-tech.md）

+本模板是技术实现的参考结构。按当前运行时、系统复杂度和用户要求选择章节；没有对应系统、界面、输入、音频或存档需求时，删除相应内容，复杂项目可增加施工所需章节。表格和系统条目可按实际实现范围扩展，不代表数量上限。
+
 # 技术实现：《游戏名》

 > 状态：{drafting / reviewed / frozen}　|　基于 GDD：架构层@v{N}　|　数据侧契约：data/contracts@v{M}
-> **目标运行时：{HTML / Unity / Godot / Cocos}（由 GDD 平台事实锁定）**　|　预览：{HTML=双视口浏览器 / 引擎=陶泥儿驱动弹窗}　|　导出：{HTML=自包含 / 引擎=陶泥儿驱动 CLI}
+> **目标运行时：{HTML / Unity / Godot / Cocos}（由 GDD 平台事实锁定）**　|　预览：{按项目平台验证 / 引擎=陶泥儿驱动弹窗}　|　导出：{HTML=自包含 / 引擎=陶泥儿驱动 CLI}

 ## 系统行为规格（收编章）

@@ -28,7 +30,7 @@

 ## 技术目标与平台事实

- 平台事实（注入，禁改）：自包含 Web · 双视口（桌面/移动）· 键鼠/触屏双输入 · 本地 HTTP 预览。
+- 平台事实（由 GDD 平台事实锁定）：__。
 - 技术目标：__（可测量，如"首屏可玩 ≤ __ 秒"）。

 ## 技术风险
@@ -39,7 +41,7 @@

 ## 运行时能力边界

-| 能力（P0 七件） | 落位（按所选运行时） | 状态（原生/自封装/受限） | 说明 |
+| 能力（按项目实际使用的能力填写） | 落位（按所选运行时） | 状态（原生/自封装/受限） | 说明 |
 |---|---|---|---|
 | 瓦片地图渲染 | __ | __ | __ |
 | 寻路 | __ | __ | __ |
@@ -85,7 +87,7 @@
 ## 构建与验证

 - 构建：__（命令/流程）。
- 验证分级：自动__（跑什么、看什么输出为过）；半自动__（双视口浏览器验证步骤）；手测__（谁试玩、观察什么）。
+- 验证分级：自动__（跑什么、看什么输出为过）；半自动__（按项目平台验证步骤）；手测__（谁试玩、观察什么）。

 ## 版本里程碑

@@ -1,5 +1,7 @@
 ### C1 模板_顶层设计.md（→ templates/top-design.md）

+本模板是参考结构，不是固定清单。填写前按项目实际存在的循环、资源、时间层级和用户要求筛选章节；同类内容可合并，若某项不存在则删除，复杂项目可增加必要内容。表格、列表和循环示例可按实际内容扩展，不代表数量上限。
+
 # 顶层设计：《游戏名》

 ## 顶层定位与规模锚点
@@ -43,6 +45,7 @@ __ → __ → __ → __ → __。

 ### __循环
 __ → __ → __ → __。
+（以上为示例，可按实际循环删减或扩充。）

 ## 资源流与输入输出

@@ -58,13 +61,14 @@ flowchart LR

 ## 最小体验单位
 __。
-单个行动必须至少提供一种清晰反馈：__。
+保留的玩家行动应有与玩法相称的可理解反馈：__。

 ## 核心活动流程

 | 阶段 | 玩家行为 | 设计目的 |
 |---|---|---|
 | __ | __ | __ |
+（按实际阶段逐行补充。）

 ## 取舍表

@@ -77,6 +81,7 @@ __。
 - 周内节奏：__。
 - 季节/章节节奏：__。
 - 长期节奏：__。
+（以上为示例，可按实际节奏层级删减或扩充。）

 整体情绪在"__"与"__"之间摆动（恢复来源：__；变化来源：__）。

@@ -103,9 +108,11 @@ __。
 | 验证点 | 成功标准 |
 |---|---|
 | __ | __ |
+（按实际验证点逐行补充。）

 ## 开放问题
 - __
+（按实际问题逐条补充。）

 ## 顶层定稿
 顶层当前定稿为：__。
@@ -13,6 +13,7 @@ Use `agc_browser_playtest` from the `agc_tools` MCP server. Do not replace it wi
 2. Inspect both desktop and mobile results, including page readiness, visible text, screenshots, console errors, exceptions, failed requests, Canvas probes, blocked actions, and interaction evidence.
 3. Compare screenshots with the user's request. Check that the active game fills its intended area, HUD elements do not cover gameplay, controls are visible, and requested platform art appears in the core experience.
 4. If evidence exposes a defect, edit the actual game files and call the tool again when that is useful. The client enforces its own execution and resource bounds; do not invent a fixed repair loop in the response.
+   Feed the structured diagnostics, console errors, failed requests, and exception text back to the same LLM repair turn before reporting the playtest as failed. Treat the evidence as debugging input and rerun the affected stage after a real code or project change.
 5. Treat browser infrastructure failure, an unloaded page, an unhandled exception, or missing evidence as a failed validation. Do not claim success from a partial result.
 6. Use game-specific reasoning for quality. Do not require a fixed board, fixed text, fixed number of slices, or a legacy harness scenario; the tool result is evidence for Codex to interpret.

@@ -27,6 +27,8 @@ For a small edit to an existing game where the brief and suitable assets are unc

 When a stage tool, command, or verification fails, retry at most three times before treating that stage as failed. Keep the retries serial and scoped to the same stage and the same input: a retry must not open a parallel path, skip ahead to a later stage, or substitute a placeholder for the missing output.

+Every repairable failure must be fed back to the current LLM as the next debugging context before the stage is considered failed. Preserve the redacted tool or command error, the stage, the attempted input, and the evidence already collected; ask the LLM to inspect the current project, make the smallest real repair, and rerun the failed stage. A client-side `isError` tool result or a failed verification is feedback for the LLM, not by itself a terminal user-facing result. Do not silently swallow the error, replace it with a placeholder, or stop after the first failed attempt. Authentication, permission, billing, project identity, corrupted history, transport loss, cancellation, and uncertain paid-operation state remain terminal safety boundaries.
+
 Only after the third attempt also fails, stop and tell the user the failure reason — which stage failed, which tool or command reported the error, what the error says, and what is still missing. A stage whose three attempts never succeeded is not complete, and its missing output cannot be reported as delivered.

 Read the referenced specialist Skills for their detailed contracts: `agc-project-structure`, `taonier-art-assets`, `agc-web-game-development`, `agc-client-projection`, and `agc-browser-playtest`.
@@ -1,6 +1,6 @@
 {
  "schemaVersion": "agc-skill-pack.v1",
-  "version": "2026-08-26.14",
+  "version": "2026-08-26.16",
  "skills": [
    {
      "name": "agc-game-production-workflow",
@@ -22,7 +22,7 @@
        "agents/openai.yaml",
        "references/workflow-contract.md"
      ],
-      "sha256": "d9d8e7e0a6bc512e0b463e0e4bd77edee1cc57f4a6965c9553e0920e38985d5c"
+      "sha256": "f25e5bd27e8fc82c61b08dc66366b5b253ee8d16d7fa72dbf2c94d2462f4e7fc"
    },
    {
      "name": "agc-project-structure",
@@ -63,7 +63,7 @@
        "agents/openai.yaml",
        "references/platform-art-contract.md"
      ],
-      "sha256": "bd1e415aac0cd0f97090296f34c67898dd731d1e177ec91a56027f9b68a88b37"
+      "sha256": "ff3e1645a35fc9bff1ef255aa7bdc2a9729843d68729589b6f2670c84b8130ec"
    },
    {
      "name": "agc-web-game-development",
@@ -98,7 +98,7 @@
        "agents/openai.yaml",
        "references/browser-evidence-contract.md"
      ],
-      "sha256": "4437cd8a927a1c79a5faf4bcd40e9946676c08a3b460ab171298cabf899f49ad"
+      "sha256": "92ecce42d6589e034d32b75bcd155c1fee34a8c7b843eea5780c0577300ed521"
    },
    {
      "name": "agc-client-projection",
--- a/Show More
+++ b/Show More