docs(agents): skill 规范化双层收口 + 席位context skill 新增 + W-NSTAR/W-TPL/W-GENLOG 设计波落档
- .agents/skills 25 件全量 frontmatter 规范化与评审修入(含 prompt-governance 大修);.claude/skills 7 件薄壳按双层方案①落位 - 新增 skill:agentic-seat-context-design(agentic 席位与 context 工程设计基线,2026-07-05 探索蒸馏) - 设计波三件落档:复杂游戏北极星件(W-NSTAR 终审稿待拍)/黄金模板规格件(W-TPL 定稿待批)/生成侧过程蒸馏回路(W-GENLOG 骨架) - protocol/在飞板/作战清单/数据飞轮 SoT/契约 prompts 索引同步;breakout 九门证据刷新 - .gitignore 补 /localagents.md 真实忽略行(该文件自声明绝不提交,此前声明未被机器执行) - 刻意不入库:nacos-data/ 与 _tier2-gen、c2v-*、amgen-* 生成产物(可重生成,忽略行格式待拍) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
lili
parent
1860be2596
commit
a207cb8d65
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: add-business-module
|
||||
description: "当在 game-cloud 后端新增一个 game-module 业务模块时使用:-api 契约 + -server 实现的双 Maven 结构、controller/service/dal 分层、错误码独占段、Flyway 迁移、两处装配、单测/集成测试与契约同步的标准步骤及踩坑表。"
|
||||
---
|
||||
|
||||
# 新增业务模块操作手册（add-business-module）
|
||||
|
||||
> 蒸馏来源：`docs/architecture/架构/README.md`（§2 后端模块地图 / §4.1 编码规范 / §11 模块开发 Checklist）、`docs/architecture/架构/README.md`（§7.10 扩展性 / SPI）。
|
||||
@ -16,8 +21,8 @@
|
||||
## 前置
|
||||
|
||||
- 已读 [`../knowledge/product-and-architecture.md`](../knowledge/product-and-architecture.md)，确认该能力**确实需要新模块**（多数 MVP 需求在既有模块加子包即可，见模块架构文档 §4 遗漏分析的判断方式）。
|
||||
- 本地中间件已起（`docker compose -f deploy/docker-compose.middleware.yml up -d`），可跑 Flyway 与集成测试（Testcontainers 依赖 Docker）。
|
||||
- 已在模块速查表（开发团队版 §2.2）与错误码段位表（开发团队版 §4.1）为新模块预留了**模块编号**与**错误码段**。
|
||||
- 中间件（MySQL/Redis/Nacos/RocketMQ）已自托管 mini-infra，连接信息见 [`docs/内网凭据与端点.md`](../../docs/内网凭据与端点.md)；本地跑 Flyway 与集成测试的 Testcontainers 仍依赖 Docker。
|
||||
- 已在模块速查表（开发团队版 §2.2）与错误码段位表（开发团队版 §4.1）为新模块预留了**模块编号**与**错误码段**。（两版《系统概要设计》——"开发团队版"/"技术决策版"——已归档 `_archive`，节号按历史读；现行规范见 [`../rules/engineering-conventions.md`](../rules/engineering-conventions.md) 与 [`docs/architecture/README.md`](../../docs/architecture/README.md)）
|
||||
|
||||
---
|
||||
|
||||
@ -28,14 +33,14 @@
|
||||
```
|
||||
game-module-{name}/
|
||||
├── game-module-{name}-api/ # 契约层：可被其他模块依赖
|
||||
│ └── src/main/java/cn/wanxiang/game/module/{name}/
|
||||
│ └── src/main/java/com/wanxiang/huijing/game/module/{name}/
|
||||
│ ├── api/ # Feign 接口（供别的模块同步调用）
|
||||
│ ├── dto/ # 模块间传输对象 DTO
|
||||
│ ├── enums/ # 枚举（状态/类型）
|
||||
│ └── enums/ErrorCodeConstants.java # 本模块错误码常量（独占一段）
|
||||
│
|
||||
└── game-module-{name}-server/ # 实现层：只本模块内部使用
|
||||
└── src/main/java/cn/wanxiang/game/module/{name}/
|
||||
└── src/main/java/com/wanxiang/huijing/game/module/{name}/
|
||||
├── controller/admin/ # 后台接口（运营/管理员，/admin/{name}/**）
|
||||
│ └── vo/ # admin 端 VO（ReqVO/RespVO/PageReqVO）
|
||||
├── controller/app/ # 产品端接口（创作者/玩家，/app/{name}/**）
|
||||
@ -45,7 +50,7 @@ game-module-{name}/
|
||||
├── dal/dataobject/ # DO（与表字段一一对应）
|
||||
├── convert/ # DO ↔ VO/DTO 转换器（MapStruct）
|
||||
├── job/ # 定时任务（如对账/聚合/清理）
|
||||
└── mq/consumer/ # RocketMQ 消费者（幂等消费）—— 远期/拆微服务才需；RocketMQ MVP 未部署，单体内跨模块通知优先同进程 -api notify-push（见下方坑表）
|
||||
└── mq/consumer/ # RocketMQ 消费者（幂等消费）—— RocketMQ 已自托管 mini-infra；单体内跨模块通知仍优先同进程 -api notify-push，真跨进程/异步才上 RocketMQ（见下方坑表）
|
||||
└── src/main/resources/
|
||||
└── db/migration/ # Flyway 迁移脚本 V{x.y.z}__{desc}.sql
|
||||
└── src/test/java/... # 单元测试 + 集成测试
|
||||
@ -64,7 +69,7 @@ game-module-{name}/
|
||||
| 3 | `-server` 实现分层 | 按 controller(admin/app)→service→dal(DO+Mapper)→convert 落地；MQ/job 按需加 | 单元测试覆盖 service |
|
||||
| 4 | Flyway 迁移 | `-server` 的 `db/migration/` 下新建 `V{x.y.z}__{desc}.sql`，如 `V1.0.0__create_game_{name}.sql`；只新增不改旧文件 | `mvn flyway:migrate -pl game-module-{name}-server` 成功 |
|
||||
| 5 | **装配＝两处**（缺任一 compile/启动失败，Wave4 实测） | **① root `game-cloud/pom.xml` 的 `<modules>` 加 `<module>game-module-{name}</module>`**（聚合定义，缺则 `mvn -pl game-module-{name} …` 报「找不到父 pom 聚合」）；**② `huijing-server/pom.xml` 加 `game-module-{name}-server` 依赖**（单体把模块编进 JAR，缺则启动无此模块、Swagger 无分组） | `mvn -pl huijing-server -am compile` 通过 + 启动后 Swagger 见分组 |
|
||||
| 6 | 模块配置（远期 Nacos） | 如有模块级配置（开关/阈值/外部 API key）：**MVP 单体走本地配置文件/环境变量**（Nacos MVP 未部署）；拆微服务后再迁 `deploy/nacos/`。 | MVP：配置项生效；远期：Nacos 控制台可见 |
|
||||
| 6 | 模块配置（Nacos 已部署 mini-infra） | 如有模块级配置（开关/阈值/外部 API key）：Nacos 已自托管 mini-infra，模块级配置可入 Nacos 配置集；简单静态项也可走本地配置文件/环境变量。 | Nacos 控制台可见 / 配置项生效 |
|
||||
| 7 | 单元测试（Service） | `XxxServiceImplTest` 继承 `BaseMockitoUnitTest`（纯 Mockito，无需 DB/Docker，照抄 project 的 `ProjectServiceImplTest`）；需真实 DB 才用 `BaseDbUnitTest`（集成阶段）。**注意：mock/verify `BaseMapper.insert/updateById` 用 `any(XxxDO.class)` 消歧，裸 `any()` 会因重载报错；`verify(...).updateById(argThat(...))` 须显式标 lambda 参数类型 `argThat((XxxDO d) -> …)`，否则同样重载歧义致 testCompile 失败（Wave4 biz 实测踩坑）** | `mvn -pl game-module-{name}/game-module-{name}-server test` 绿 |
|
||||
| 8 | 集成测试（Controller+DB） | `XxxServiceIntegrationTest`，Testcontainers 自动起 MySQL/Redis；覆盖核心 API | `mvn verify -pl game-module-{name}-server -Pintegration` 绿 |
|
||||
| 9 | Swagger/Knife4j 验证 | 启动 `huijing-server`，开 `http://localhost:48080/doc.html` 确认接口与字段自动生成正确 | doc.html 可见新模块分组 |
|
||||
@ -101,7 +106,7 @@ game-module-{name}/
|
||||
- [ ] `-server` 中建 `controller/admin/` + `controller/app/` + `service/` + `dal/mysql/` + `convert/`（按需 `job/`、`mq/consumer/`）
|
||||
- [ ] 编写 Flyway 迁移 `V{x.y.z}__{desc}.sql`（只新增，不改旧迁移）
|
||||
- [ ] **装配两处**：root `game-cloud/pom.xml` `<modules>` 注册 `<module>` + `huijing-server/pom.xml` 引入 `-server` 依赖
|
||||
- [ ] 模块级配置（如有）：MVP 走本地配置/环境变量；Nacos 为远期（MVP 未部署）
|
||||
- [ ] 模块级配置（如有）：Nacos 已自托管 mini-infra，可入 Nacos 配置集；简单静态项也可走本地配置/环境变量
|
||||
- [ ] 单元测试（Service 层）通过
|
||||
- [ ] 集成测试（Controller + DB，Testcontainers）通过
|
||||
- [ ] Swagger（Knife4j）`doc.html` 验证 API 文档自动生成
|
||||
@ -127,4 +132,4 @@ game-module-{name}/
|
||||
| `select *` / 大表无索引查询 | 慢查询、性能事故 | 必须指定字段；大表查询必须命中索引（开发团队版 §4.1） |
|
||||
| 「运营赋值类」资金（admin 赋余额/补偿）混进业务收益流水表 | 污染营收报表 gross/net 聚合 + 破坏对账锚点 | **另建专用流水表**（trade U2：`game_trade_grant`，独立 `uk_biz_no` 幂等行），账户余额仍走原子增（`balance += amount, total_income += amount` 守恒 `balance+frozen+total_withdraw=total_income`）；流水写入 + 余额增同 `@Transactional`，先写流水行（uk 防并发）再增余额，余额增 0 行抛错回滚（禁「流水已记、余额未增」半态）。范本 `AccountServiceImpl.grant` |
|
||||
| 「一用户一态」聚合域（订阅/会员）按每次操作建新行 | uk_user 撞键 / 状态分散难查 | **一行一用户 upsert**（`uk_user`，首建 insert / 已有 CAS 续期）；幂等键**内联在行**（`last_grant_biz_no`，同 bizNo 不重复延长 = 重试安全），区别于流水域的独立 uk_biz_no 行；续期叠加 `新到期=max(now,旧expire)+时长`（不丢未用时长，已过期从 now 起算）；CAS（`WHERE expire_time=读时快照`）防并发 lost-update，miss 回查重试有限轮次（禁死循环）。范本 `SubscriptionServiceImpl` |
|
||||
| 「有效期/过期态」依赖定时 job 物化 status 列 | 无 cron（MVP RocketMQ/job 多为远期）时过期态不准 | **有效性以 `expire_time>now` 查询时实时回算**（`effectiveStatus`/`active` 在 Convert 层算），落库 status 仅初始态 + 后续物化预留；不依赖定时 job 也能正确反映过期。范本 `TradeConvert.toSubscriptionVO` |
|
||||
| 「有效期/过期态」依赖定时 job 物化 status 列 | 无 cron / 定时 job 未接时过期态不准 | **有效性以 `expire_time>now` 查询时实时回算**（`effectiveStatus`/`active` 在 Convert 层算），落库 status 仅初始态 + 后续物化预留；不依赖定时 job 也能正确反映过期。范本 `TradeConvert.toSubscriptionVO` |
|
||||
|
||||
@ -1,8 +1,13 @@
|
||||
---
|
||||
name: agentic-amodel-generation
|
||||
description: "当运行或调试 amodel-gen 底层 ReAct 工具循环(read/write/list/check/build/done + 循环外 play)、或排查便宜档 cheap-worker shell-out 复用的 gen.mjs 工具面时使用:harness 文件职责、mini-desktop 运行配方、九条踩坑红线。"
|
||||
---
|
||||
|
||||
# skill:agentic A-model 游戏生成 harness(ReAct + M3,已实证)
|
||||
|
||||
> **一句话**:给模型 read/write/list/check/build/done 工具,让它**自己读 skill→读插件 api.d.ts→读范例→写多文件 LittleJS `src/`→自查 check/build→done**,harness 再跑循环外 play 出"能跑能玩"判定。**这是底层 A-model harness 手册（`gen.mjs` 及工具循环）——现行被便宜档 `cheap-worker`（AgentScope/Python）shell-out 复用**（reframe 前定位为「A-model 生成的生产形态」；旧 gamedef/factory 单次产线已废）。
|
||||
>
|
||||
> 配套:code 层手册 [`littlejs-game-dev.md`](littlejs-game-dev.md) · design 层 [`sim-business-game-design.md`](sim-business-game-design.md) · 设计权威 `../../docs/agent-specs/2026-06-21-agentic-amodel-generation-design.md`(`git show git show 8ea97234:docs/agent-specs/2026-06-21-agentic-amodel-generation-design.md`)。旧 [`cheap-model-game-generation.md`](cheap-model-game-generation.md) 的 gamedef/worker-loop 路对 A-model **已退役**,只看其通用纪律。
|
||||
> 配套:code 层手册 [`littlejs-game-dev.md`](littlejs-game-dev.md) · design 层 [`sim-business-game-design.md`](sim-business-game-design.md) · 设计权威 `2026-06-21-agentic-amodel-generation-design.md`(已删,git 定位:`git show 8ea97234:docs/agent-specs/2026-06-21-agentic-amodel-generation-design.md`)。旧 [`cheap-model-game-generation.md`](cheap-model-game-generation.md) 的 gamedef/worker-loop 路对 A-model **已退役**,只看其通用纪律。
|
||||
|
||||
---
|
||||
|
||||
|
||||
191
.agents/skills/agentic-seat-context-design.md
Normal file
191
.agents/skills/agentic-seat-context-design.md
Normal file
@ -0,0 +1,191 @@
|
||||
---
|
||||
name: agentic-seat-context-design
|
||||
description: 设计或评审生成运行时的 agent 席位划分、context 装配、prompt 结构、工具面、多 agent 协作、goal-loop 自治交付、创作者交互面时使用——需求基线 + 设计检查单(设席八问/注入五查/场景四要素)+ 第一人称需求探针方法(§10);非架构 SoT。
|
||||
---
|
||||
|
||||
# agentic 席位与 context 工程设计 —— 生成运行时多 agent 设计的需求基线
|
||||
|
||||
> **性质与来源**:2026-07-05 创始人八轮问答驱动的"模型第一人称需求探索"——让生成运行时里实际干活的 LLM 回答"你需要什么才能把游戏做好、做大、改得动",本文是收敛蒸馏。**定位 = 需求基线 + 设计检查单,不是架构 SoT**:运行时架构唯一 SoT 见 [`agentic运行时架构图说.md`](../../docs/architecture/架构/生成引擎/agentic运行时架构图说.md);据此做具体设计仍走 [`feature-design-doc.md`](./feature-design-doc.md) 产设计档 + SoT 注册表申报 + 双评审;文中标〔提案〕的机制未经实现验证,落地前逐条核实。
|
||||
> **适用**:设计/改造生成运行时的席位划分、context 装配、prompt 结构、工具面、多 agent 协作、goal-loop 自治交付、创作者交互面;评审这类设计时拿 §8 检查单当尺子。
|
||||
> **配套**:AgentScope 2.0.2 机制速查 [`agentscope-2.0-facts.md`](../knowledge/agentscope-2.0-facts.md);prompt 文本的版本化/eval 治理 [`prompt-governance.md`](./prompt-governance.md)(分工:本文管"谁在哪个座位拿到什么",它管"prompt 文本自身怎么管");九门与真玩 [`game-e2e-cdp-harness.md`](./game-e2e-cdp-harness.md);质量口径 [`游戏质量与爆火能力.md`](../../docs/architecture/架构/生成引擎/游戏质量与爆火能力.md);遥测回流 [`数据飞轮.md`](../../docs/architecture/架构/生成引擎/数据飞轮.md)。
|
||||
|
||||
## 0. 总则:席位分的是结构,不是能力
|
||||
|
||||
所有席位背后是同一类 LLM,多 agent 设计因此不是能力分工,是**结构分工**。一个"席位" = prompt 配方 + context 配方 + 工具面 + harness 策略的版本化组合,整组落在配置控制面(AgentScope per-POST 装配:改配置,下一次生成即生效,零重启)。
|
||||
|
||||
**分席四判据**(至少满足其一才配新席位):
|
||||
|
||||
1. context 食谱本质不同——要广度 / 要深度 / 要刻意致盲;
|
||||
2. 写权限必须互斥——并行工单的白名单不相交;
|
||||
3. 验证独立性——做的和查的绝不能同席("出题的 ≠ 被考的"这条九门纪律的席位版);
|
||||
4. 生命周期不同——常驻有状态 vs 按工单生灭。
|
||||
|
||||
**两条不设席戒律**:判定可确定化 → 做成门(产模型辩不过的事实;封装形态可为 MCP 工具——现状九门 = CDP harness driver + middleware 重跑 run_gates,MCP 化是主张非现状);调度可确定化 → 做成代码(队列 + workflow)。LLM 席位只放不可归约的判断。健康自检:席位数不随游戏复杂度增长,涨的只该是工单数与门数。
|
||||
|
||||
## 1. 四层结构与边界律
|
||||
|
||||
| 层 | 只装什么 | 绝不装什么 | 变更节奏 | AgentScope 落位 |
|
||||
|---|---|---|---|---|
|
||||
| **prompt(席位宪法)** | 身份与协议:职责宪章、禁区、输出工件 schema、升级协议、判断性红线 | 项目事实、工单内容、可门化/可模板化的规范 | 低频;每改 = 配置版本 + 评审 | `/agent` 配置的 prompt 部分;文本生命周期归 prompt-governance |
|
||||
| **context(本次投影)** | 事实与任务:工单六要素、冷启动简报、承重件(契约/验收/坑清单)、省略目录(未注入但可检索项的清单)、出处戳(来源/新鲜度/性质) | 聊天历史回放、其他席位的推理过程 | 每 POST 从控制面现装配 | 投影编译 = 控制面自建能力(框架现成件只是 AgentRecord 的 context_config);配方进控制面版本化 |
|
||||
| **environment(工作台)** | 能力与边界:workspace(worktree + 写白名单)、工具/MCP 白名单、按需热装 skills、预算态 | 与本工单无关的工具 schema | 按工单类型 | toolkit/session 注册 + workspace + 配额 |
|
||||
| **harness(流程壳)** | 过程控制:门判拦 finish、续修环、软预算档位、journal 写前意图、离场清账、升级事件、盲评隔离、投喂记 trace | 业务判断(不替模型想,只兜过程与验证) | 随平台演进 | middleware 洋葱 + MCP 门 + 队列协议 |
|
||||
|
||||
**边界律一句话:身份进 prompt,事实进 context,能力进 environment,过程进 harness。**串层即设计错误,四个典型味道:项目事实写死在 prompt(僵化+配置漂移);身份协议塞进 context(每次重复付 token);用 prompt 劝模型别越权(该收 environment 白名单);指望模型自觉跑门(该进 harness 强制)。
|
||||
|
||||
**工具面三则**:
|
||||
|
||||
- **能力边界优于自律**:制作人席不给代码工具,范围失控在根上被断;评审席只读 + 门;数值席只有仿真器 + 数据表。
|
||||
- **工具诱导行为**:无关工具 schema 既是注意力污染也是行为歪引(有 shell 就想用 shell)。
|
||||
- **语义化窄工具优于万能工具**:给 `snapshot()` / `checkout_baseline()` / `replay_intent()`,不给裸 git——不变量在工具层强制,模型调不出违规操作。
|
||||
|
||||
**规范注入铁律:模板承载 > 门强制 > prompt 提醒。**能烤进脚手架的规范零边际 token 且直接塑形输出(reskin write_whitelist 实证);能确定化的做门,违规被拦而不是被劝;只有判断性规范才配占 prompt。可运营指标:**prompt 里的规范条数应单调递减**——每条都该在排队迁往模板或门,赖着不走的就是技术债。
|
||||
|
||||
## 2. 席位表
|
||||
|
||||
**常驻席**(每项目一套,有状态;状态活在账本,不活在会话):
|
||||
|
||||
| 席位 | 吃什么 | 产什么 | 工具面 |
|
||||
|---|---|---|---|
|
||||
| 制作人席 | 功能台账、遥测摘要、决策日志、用户消息+现场快照 | 工单、三档确认、版本决策提案 | 台账/遥测查询、工单铸造;**无代码工具** |
|
||||
| 主设计席〔提案〕 | 系统契约、数据 schema、决策史 | 规格增量、验收标准、契约版本 | 契约注册表读写、schema 工具 |
|
||||
| 数值仿真席〔提案〕 | 数据表、仿真器输出、真实遥测曲线 | 平衡判定、调参工单 | 快进仿真器、数据表编辑;无代码写 |
|
||||
| 馆长席〔提案〕 | journal 流、坑清单增量、配方与 SoT | 蒸馏并入、索引更新、配方↔SoT 对账 | 知识库读写、对账门 |
|
||||
|
||||
**工单席**(按单生灭,无状态,可并行):
|
||||
|
||||
| 席位 | 吃什么 | 产什么 | 工具面 |
|
||||
|---|---|---|---|
|
||||
| 实现席 ×N | 单系统契约 + 白名单文件 + 品类坑清单 | 交付包(commit + 自测证据 + journal) | 白名单内写、build/test、契约查询 |
|
||||
| 内容席 | 数据表 schema + 样例 | 过校验器的数据表 | 表编辑 + 校验器;便宜档模型即可 |
|
||||
| 资产席 | 资产清单、风格锚、包体预算 | 素材 + 元数据(尺寸/锚点) | 素材生成/管理;无逻辑写 |
|
||||
| 评审席(盲) | 规格 + 工件 + 证据,**不见实现过程** | 判定书 | 只读 + 九门(现状经 harness/middleware 调用,可封 MCP) |
|
||||
| 玩家席 | persona play-spec + 可玩预览 | 体验报告(FTUE 卡点/手感) | 真玩 driver;上线后被真实遥测校准 |
|
||||
|
||||
**不设席清单**(代码/工具,不是 agent):调度排队(RocketMQ + 控制面)、九门、快进仿真器、兼容检查器、契约测试、语义版本操作、docs-gate 式对账。修复也不设席——RepairMiddleware 是实现席的会话内环。
|
||||
|
||||
**已有胚胎 → 缺口对照**(设计时先认领胚胎,别平地起楼):
|
||||
|
||||
| 席位/机制 | 已有胚胎(已落地) | 缺口 |
|
||||
|---|---|---|
|
||||
| 制作人席 | A11 调整回路两段式(判意图→计划→前端确认→执行) | 分诊矩阵、三档确认策略、用户现场快照 |
|
||||
| 实现席 | cheap-worker / tier2 worker + RepairMiddleware + write_whitelist | 工单化收窄、journal 协议 |
|
||||
| 评审席 | gate_judge middleware + 九门 | 独立 fresh 会话化、判定书 schema |
|
||||
| 玩家席 | 九门真玩 driver + play-spec | persona 化、体验报告 schema |
|
||||
| 配方版本化 | 配置控制面(yudao 版本层 + per-POST 热装配) | context 配方、工具面、skills 纳入同一治理 |
|
||||
| 投喂可观测 | 生成线 trace 已闭合(jsonl 主路;便宜档 OTLP sink 波③已通、默认关) | 把"每次装配了什么 context"记进 span |
|
||||
| 主设计席 / 数值仿真席 / 馆长席、九类工件 schema、版本卡 / 意图重放 / 兼容检查器 | 无 | 全新建〔提案〕 |
|
||||
|
||||
**同源风险**(所有席位同一 LLM,盲评只解决"被带节奏",解决不了"想不到同一处")三缓解,按有效性排:① 工具事实优先——把尽可能多的判定压进确定性工具;② 异档模型当多样性来源——关键评审席换不同家族/档位的模型(子代理成本分档的意外红利);③ 同席多镜头——正确性/契约/回归各跑一趟 fresh context。
|
||||
|
||||
## 3. 通信:星形账本中心,九类工件,禁自由对话
|
||||
|
||||
席位之间**不存在 live 群聊**;一切通信 = 从项目存储拉工件 + 向队列发工件。三个理由:可中断(对话中断即死,工件队列天然可续)、可审计(每件进 trace,"它当时知道什么"可回放)、防污染(盲评与类型化交接的前提就是不共享会话)。这也贴 AgentScope 现实:Service `/chat` 是 per-POST 的 fire-and-forget 触发(结果走 SSE 事件流),session 是单席位状态,不是聊天室。席内要查事实走注册表工具,要扩范围发升级事件,不去"找别的席聊"。
|
||||
|
||||
九类工件(全部带 schema + 出处戳〔来源 commit / 时间 / 性质:事实|推断|假设〕):
|
||||
|
||||
| 工件 | 方向 | 要点 |
|
||||
|---|---|---|
|
||||
| 工单 | 制作人 → 各席 | 六要素:目标/范围白名单/验收/预算/依赖/升级策略 |
|
||||
| 规格增量 | 主设计 → 实现/内容 | 契约变更提案 + 版本 bump + 迁移注记 |
|
||||
| 交付包 | 实现 → 评审 | commit hash + 自测证据 + journal 条目(hash 必须真实可 rev-parse,防谎报 DONE) |
|
||||
| 证据包 | 门/driver → 评审/版本卡 | 九门测量值、仿真结果、截图、真玩轨迹 |
|
||||
| 判定书 | 评审 → 制作人 | 过/不过 + 测量值 + 可行动的失败现场(不许只给门名) |
|
||||
| 升级事件 | 任意席 → 制作人 | raise_scope_change:原因 + 产品语言选项;发完干净收口,不悬挂等输入 |
|
||||
| 版本卡〔提案〕 | 制作人 → 用户 | 基线 + 已应用意图集 + 证据包 + 兼容戳 |
|
||||
| 回流工单 | 遥测 → 制作人 | 漏斗卡点/留存差 → 修复工单(数据飞轮的工单化出口) |
|
||||
| 蒸馏增量 | 各席 → 馆长 | 坑/经验条目,经查重并入,不直写知识库 |
|
||||
|
||||
## 4. context 装配六性质(注入怎么控)
|
||||
|
||||
1. **角色投影**:推送只放承重件(契约/验收/坑清单),其余给**省略目录**("还存在这些,可用 X 检索")。不给省略目录,模型会把投喂当全世界,幻觉从此长出;全推,则回到浪费读轮的老路。
|
||||
2. **刻意致盲**:评审席的 context 配方里不含实现会话的存在;修复轮给"上一版代码 + 门失败证据",不给前任心路——继承推理等于继承盲区。
|
||||
3. **单源编译**:所有投影从同一 SoT 机器生成,禁止各席各抄一份(双写必漂移)。**配方是代码,配方 bug 与代码 bug 同级**:进控制面版本化,并配机器对账(配方引用的 SoT 命题还在不在、原文变没变)。反面判例 = "传导断裂":便宜档实现入口丢了 SoT 的"轻量≠简单"命题、留着误导措辞,agent 从局部线索重建出错误世界观,连栽数轮。
|
||||
4. **出处戳**:每块注入带来源/新鲜度/性质三戳。"三天前的构建状态"与"刚跑完的门结果"必须能被区别信任。
|
||||
5. **回写分道 + 蒸馏守门**:实现席只写 journal 与坑增量、评审席只写判定、规划席只写工单,谁都不直改账本正文;蒸馏物经馆长门(查重/并入/汰旧),否则积累的不是知识库是垃圾堆。
|
||||
6. **投喂进 trace**:每次会话记录"装配了什么配方、什么版本的哪些块"。坏结果才能归因(模型不行还是喂错了),配方改进才能 A/B("给坑清单 vs 不给,过门率差多少")——context 工程从玄学变成像 D11 权重一样可校准的对象。
|
||||
|
||||
镜像原则:**配方密度随席位模型档位调**——便宜模型席位零裁量、全铺开;贵模型席位给索引让它自拉。
|
||||
|
||||
## 5. 长项目操作系统(数十天、数千次改动、随时中断)
|
||||
|
||||
长项目里上下文窗口只是"一次工时的工作台",项目必须整个活在仓库与控制面里,每次 POST 只做投影。六件,全部不活在任何会话:
|
||||
|
||||
| 件 | 回答 | 要点 |
|
||||
|---|---|---|
|
||||
| 账本 | 现在在哪 | 版本线、在飞工单、门态;冷启动简报由它生成,禁聊天回放 |
|
||||
| 工单 | 这次干什么 | 有界:目标/白名单/验收/预算;杀掉中途的席位损失有界 |
|
||||
| journal | 中断了怎么接 | 写前意图 + 完成回执;恢复 = 对账 workspace vs 日志,不是考古 diff 猜前任 |
|
||||
| 决策史 | 为什么不能乱动 | 防第 2000 次改动把第 300 次的深思设计当垃圾重构 |
|
||||
| 版本线 | 在哪条线上 | 见下方版本语义 |
|
||||
| 索引 | 去哪找 | 模块地图 + 归属索引,机器生成;工单进来先预取再干活 |
|
||||
|
||||
配套的**离场清账协议**:每工单收尾必回写账本更新 + 决策日志 + 坑增量,三样齐才算完——没有蒸馏的会话是一次性消耗(`.agents/` 纪律下沉进每个游戏工程,由 harness 强制)。
|
||||
|
||||
**版本语义**(用户看时间线,模型看基线资格,谁都不看 git log):
|
||||
|
||||
- **版本卡** = 通过验收的工单产物(缩略图 + 一句人话变更 + 证据包);数千 commit 是模型的事,用户只见几十张卡。
|
||||
- **基线资格机器戳**:"从稳定版继续"解析为"证据全绿且线上指标不劣化的最近版本",不是最近一个 tag。
|
||||
- **live 线永不直碰**:发布 = 审核门后指针切换,回退 = 指针回切,"改崩线上"在结构上不可能。
|
||||
- **回退真雷是玩家存档不是代码**:触碰持久化 schema 的工单强制登记数据版本;回退前兼容检查器自动判"新存档在旧版打不开",把选项翻成人话(迁移/重置/放弃)交用户。
|
||||
- **分叉不做 merge,做意图重放**:"把那版的宠物拿回来" = 按原工单(意图+验收)在当前基线重新实现、过同套验收。AI 重做一个功能足够便宜,合并冲突这个概念对零技能用户可以整个不存在。
|
||||
|
||||
## 6. 交互面(分诊、确认、goal-loop)
|
||||
|
||||
**三档确认,可逆性替代确认**(回退越便宜,需要事前确认的事越少):
|
||||
|
||||
- 档0 静默直做:参数级微调,进变更日志,一键可撤;
|
||||
- 档1 做完给试玩(新功能默认档):**确认的最好形式是玩预览版,不是读计划文字**;
|
||||
- 档2 先问再做,仅三类:不可逆(动线上存档/经济/付费)、贵(超预算/天数阈值)、与用户既往决定冲突(引决策史对质:"排行榜 V9 有过,你在 V11 让我去掉的,要加回来吗")。
|
||||
|
||||
**模糊请求五步**:① 现场快照先于追问(在玩哪版哪景、最近事件——"它太快了"的"它"九成是刚碰过的东西);② 模糊词落设计轴(主设计席维护"词→可调面"映射,数据驱动使"改简单"=参数提案而非代码重写);③ 遥测佐证纠偏(用户说三关难、数据说卡二关——给证据版判读,字面顺从最贵);④ 收敛按序:**试玩变体 > 选择题 > 追问,永不出开放问答**(零技能用户答不了"重力还是碰撞体积");⑤ 小步默认 + 判读入档(原话→判读→依据,积累该用户词典)。
|
||||
|
||||
**场景注册表**:交互场景清单本身是契约——每场景 = 意图类 + 路由席位 + 默认确认档 + 遥测埋点,登记进 `contracts/`(八类契约的延伸),分诊按它驱动,新场景显式增列,不在 prompt 里悄悄长(注册表真落 `contracts/` 后,下方场景族清单迁过去、本节改指针,避免双写)。场景族:立项创作 / 修改(对象:资产·数值·内容·机制·meta × 动词:改增删调回退)/ 版本操作 / 目标委托 / 诊断咨询(只读即答,不铸工单)/ 运营变现(碰钱必档2)/ 素材管理 / 打断接管。
|
||||
|
||||
**goal-loop 铁律**:goal 必须先编译成**可判定验收门 + 预算上限 + 里程碑节奏**才许进 loop——编译不出验收门的 goal 永不终止;里程碑产版本卡供用户异步试玩;仅档2事项自动暂停挂决策点;交付判定 = 门全绿 + 证据包,**绝不是模型自称完成**;用户随时打断,当前工单跑完或干净中止(journal 收口),插单分诊重排,账本无损恢复。
|
||||
|
||||
## 7. 生成游戏工程规范(舰队尺度:无数游戏、长期代改)
|
||||
|
||||
单个工程的代码结构与红线 SoT = [`littlejs-game-dev.md`](./littlejs-game-dev.md)(§1 代码结构、§7 受控面铁律),本节不复述,只提舰队尺度的增量——规范的目标函数是**冷启动定向速度、机器可校验、局部可改、跨游戏同构**,不是人类品味:
|
||||
|
||||
1. **千游一构的舰队含义**:同拓扑/同入口/同 manifest 的价值在舰队运维——批量迁移、安全补丁、横向审计变机械活,模型永远不用"学"某个项目的布局;
|
||||
2. **状态显式**:存档 schema 带版本、全局状态单一登记处——回退与兼容检查器(§5)的地基;
|
||||
3. **自描述**:模块地图机器生成不手写;**注释是写给下一个失忆的模型的信**——写"为什么不能动",不写"这行在干嘛";
|
||||
4. **回归单调增**:每修一个 bug 沉淀一个门/测试进本工程——数千次改动的质量靠累积的门,不靠第 N 个席位的小心。
|
||||
|
||||
规范本身版本化:manifest 记"本工程生于规范 v3";旧游戏按出生规范维护,升规范 = 显式舰队工单——**禁止顺手升级**(最小改动红线的舰队形态)。契约先行与数据逻辑分离已是作业手册红线,此处只强调舰队含义:§6 模糊请求处理链("改简单"=参数提案)整个站在数据表化之上。
|
||||
|
||||
## 8. 设计检查单(后续设计/评审会话按此过)
|
||||
|
||||
**新设一个席位,八问**:存在理由命中分席四判据哪条?三件套配方(prompt/context/工具面)各是什么?进不进控制面版本化?对谁刻意致盲?回写哪条道?产出工件 schema 是什么?有没有可认领的已有胚胎(§2 对照表)?框架默认注入的能力面审计过、与白名单对账了吗(AgentScope **Service 路 `get_toolkit`** 无条件并入 15 件无条件框架默认工具〔六内建 + Planning×4 + ToolStop + Team×4;另 Schedule×4 仅 session 配 chat_model_config 时条件并入〕、旁路白名单——实测教训;纯库 CLI 路 = 自装 toolkit 无此并入,cheap Service 已双补丁封口、审计口径见北极星档 §2 注入面审计节)?
|
||||
|
||||
**设计一次 context 注入,五查**:承重件清单最小了吗?省略目录给了吗?出处三戳齐吗?配方↔SoT 有机器对账吗?token 密度与席位模型档位匹配吗?
|
||||
|
||||
**设计一个交互场景,四要素**:意图类、路由席位、默认确认档、遥测埋点——登记进场景注册表了吗?
|
||||
|
||||
**任何"规范进 prompt"的提议,先问两遍**:能进模板吗?能做门吗?都不能才许进 prompt,并挂"待迁出"标。
|
||||
|
||||
## 9. 来源与效力
|
||||
|
||||
2026-07-05 创始人八轮问答(单次生成信息面 → 复杂游戏差距 → 长项目操作系统 → 范围与版本控制 → 多 agent context 控制 → 席位划分与通信 → 工具/规范/场景清单 → 四层边界),对模型第一人称需求陈述的收敛蒸馏。效力:**需求基线**——做 agentic 设计时当尺子与检查单用;它不推翻任何既有 SoT 决策;〔提案〕机制(主设计席/数值仿真席/馆长席/九类工件 schema/版本卡/意图重放/兼容检查器)落设计档时须按 [`feature-design-doc.md`](./feature-design-doc.md) 流程评审并逐条验证可行性。
|
||||
|
||||
## 10. 第一人称需求探针(方法附录,W-PROBE)
|
||||
|
||||
本文正文是一次探针的产物;本节固化方法本身,供新 agentic 子系统(审核台辅助/玩家 feed 推荐/回流环运营席/创作者对话席等)设计期复用。探针 = 创始人驱动最强可用模型,以「我就是该子系统里干活的 LLM」第一人称回答需要什么,产需求基线——设计期前置工序,产出永远是需求基线+检查单,不是架构 SoT;探针对象排期唯一登记处 = MVP 作战清单 W-PROBE 单(本节不维护清单,防双写)。
|
||||
|
||||
**问题序列模板**(八轮推进逻辑,按子系统代入;轮间改向由创始人驱动、不可省——本次实践约一半信息密度来自人的追问改向):
|
||||
|
||||
1. **单次任务信息面**:完成一次 X,你希望获得什么信息/能力?——摸清最小工作单元的需求;
|
||||
2. **最复杂标的差距**:这些够你做出〈本域最复杂标的〉吗?——用北极星级负载逼出单次视角的缺口;
|
||||
3. **长周期规模化**:项目持续数十天/随时中断再续/数千次操作/多版本交付,你需要什么?——逼出操作系统级需求(账本/journal/决策史);
|
||||
4. **范围与版本**:用户不感知工程现状、中途提新需求,范围怎么控?如何回退/签出历史版本再开新功能?——逼出确认策略与版本语义;
|
||||
5. **多 agent context**:多 agent 都用你当 LLM 时,你希望怎么控制各 agent 拿到的 context?——逼出装配性质(投影/致盲/出处);
|
||||
6. **席位与通信**:如何划分 agent、各管什么、之间通信和交付什么?——逼出分席判据与工件类型;
|
||||
7. **工具/规范/场景**:各席工具面(tools/MCP/skills)差异?模糊请求怎么办?舰队级代码规范?交互场景清单?——逼出 environment 面与交互契约;
|
||||
8. **结构与边界收口**:context/environment/harness/prompt 各自结构与边界?——逼出四层边界律,收敛成可落档结构。
|
||||
|
||||
**收敛判据**:新一轮回答不再产生新的需求类(只在细化既有类)即收敛;每轮末由创始人判断改向或加压(换更极端负载/加约束)。
|
||||
|
||||
**固化格式**:蒸馏为「需求基线+设计检查单」单文件——总则判据/结构表/检查单三件必有;未经实现验证的机制统一标〔提案〕;末节写明来源与效力(不推翻既有 SoT,落地走 feature-design 流程逐条验证);已有胚胎逐项认领(参照 §2 对照表的做法),别让基线平地起楼。
|
||||
|
||||
**交接契约**:下游设计档(feature-design)必须逐条消费基线条目并留「采/改/弃+理由」——基线是输入不是结论;设计档评审按 §8 检查单过尺(protocol §2.3);首次复用跑通「探针→基线→设计档」全链后,按真跑发现回修本节。
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: architecture-diagram-atlas
|
||||
description: "当为 docs/architecture 某领域补图说、新增系统级图、或设计档变更后据防漂移门同步 SVG/图说时使用:SVG house style、图说文档结构、三范式纪律(单源/防漂移/状态双层)、按域并行编排配方与主会话复验脚本。"
|
||||
---
|
||||
|
||||
# 架构图集生成配方(architecture diagram atlas)
|
||||
|
||||
把 `docs/architecture` 的每个领域画成"一套图 + 讲解"的图说,外加一份顶层总图叙(apex)。目标三条:① 新人看图入门;② 评审者**据图发现设计缝**;③ 图与设计档不漂移。2026-06-22 第一期(总图叙 + 7 域图说 ≈ 71 图位 / 35 SVG)实证,配方在此固化。计划稿 = `git show 8ea97234:docs/plans/2026-06-22-架构图集-目录与图清单-plan.md`;金样板 = `docs/architecture/07-运维图说.md` + 其 `assets/`。
|
||||
@ -31,7 +36,7 @@
|
||||
## 三范式纪律(本图集的硬约束)
|
||||
- **(a) 单源**:形式标「引」的图**绝不复制** README 已有的 Mermaid,只在散文里链接「见该域 README §X」。同一张图绝不存两处(复制=自造漂移面)。领域已画的图,总图叙只链不重画。
|
||||
- **(b) 防漂移**:frontmatter 记源档 commit hash;§3 状态表逐图复述状态;收口脚本比对 hash,对不上标「待复核」。
|
||||
- **(c) 状态双层**:状态码 = 现(已建)/接(待接线)/建(待建)/缓(缓做)/F(future)/废(决策史)。整图非「现」时图顶加**状态约定条**说明整图状态 + 实心/虚线含义;元素级凡 接/建/缓/future/废 一律虚线框 + 文字小标,与「现行已建」实心块一眼区分。**绝不把 future(tier2/k8s/Nacos/RocketMQ)或已废(Dify/OpenGame/玩法填参模板/15KB)画成现行。**
|
||||
- **(c) 状态双层**:状态码 = 现(已建)/接(待接线)/建(待建)/缓(缓做)/F(future)/废(决策史)。整图非「现」时图顶加**状态约定条**说明整图状态 + 实心/虚线含义;元素级凡 接/建/缓/future/废 一律虚线框 + 文字小标,与「现行已建」实心块一眼区分。**绝不把 future(k3s 迁移/SAA·Dify 可插拔适配)、在飞(tier2)或已废(OpenGame/玩法填参模板/15KB)画成现行;而 Nacos/RocketMQ 已是生产 runtime、应画「现/接」，勿再当 future。**(Dify 按 AGENTS.md 口径=最低优先级远期,非已废)
|
||||
|
||||
## 编排配方(按域并行)
|
||||
- **每域一个 opus agent**(`agentType: general-purpose`,可 Write),克隆金样板:读 计划稿+金样板 md+2 张金样板 SVG+本域源档 → 逐图产出(SVG/Mermaid/引用)→ 自检 → 汇编 md。结构化返回 `{docFile, svgFiles, figureCount, svgOk, statusDisciplineNote, singleSourceNote, selfCheck, flagsForReview}`。
|
||||
@ -73,7 +78,7 @@ md 另核:§0-3 齐、frontmatter hash 与当前 git 一致、```mermaid 块数
|
||||
|
||||
## 细颗粒 detail-图说 扩展(子树放大层)
|
||||
|
||||
域图说之外,某个子系统要逐项放大(把总览一句话带过的「九门」「skills」「源项目契约七要素」铺成逐门 / 逐工具 / 逐要素的细图),按「族」拆 detail-图说,放在该子系统目录、单源引用总览。tier2 生成引擎子树即用此法建了 8 族 32 图(见记忆 `tier2-detail-diagrams` 与 `docs/architecture/架构/生成引擎/tier2细节图说-*.md`)。
|
||||
域图说之外,某个子系统要逐项放大(把总览一句话带过的「九门」「skills」「源项目契约七要素」铺成逐门 / 逐工具 / 逐要素的细图),按「族」拆 detail-图说,放在该子系统目录、单源引用总览。tier2 生成引擎子树即用此法建了 8 族 32 图,现在位仅 `tier2细节图说-G-spike-runbook.md` 一件,余已随整理归档(git 可查)(见记忆 `tier2-detail-diagrams`)。
|
||||
|
||||
- **编排 = draw → 对抗验证 → 族汇编 pipeline(Workflow)**:每图一个 opus 子代理,先读源档取证(绝不编)→ 画 SVG → 跑共享 `/tmp/verify_svg.py <checkKey>` 自检 → 对抗评审(内容对源 / house-style / 无 AI 味 / deepen 不 duplicate,小瑕疵就地修);一族图齐后一个 opus 汇编族图说 md(防漂移 hash + 人读散文,house-style/散文铁律/deepen 规则的正反例必须随 prompt 一起传下去)。2 轮共 66 子代理实证可复用、稳定产出过门。
|
||||
- **deepen 不 duplicate**:detail 图是总览某图的逐项放大,不重画总览已有的图;承接时脚注写「(放大总览图 N)」单源引用。workflow 专设一道 `deepensNotDuplicates` 验,防换皮重画。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: cheap-model-game-generation
|
||||
description: "当需要 new-api 便宜模型成本口径、前缀缓存降本、代理旁路坑、或「模型能力画像/质量评估三层/别归模型造不出」等跨路结论时查阅:W-G1 便宜档实证。⚠️ 起新便宜档生成走 cheap-worker,勿照本篇已退役的 gamedef/factory 链路。"
|
||||
---
|
||||
|
||||
# 便宜模型直出可玩轻游戏 · L1 生成 worker 配方（W-G1 实证）
|
||||
|
||||
> **⚠️ 状态（2026-06-26）：本篇是 reframe 前的旧 W-G1 / gamedef-factory 路。** reframe（2026-06-25）已废 gamedef + 统一 AgentScope；便宜档生成已迁到 **`cheap-worker/`**（Python/AgentScope + 直写 LittleJS `src/` 多文件 + import 复用 tier2 框架层 + shell-out 现有 node 工具），不再是本篇的「裸 openai client 不引 AgentScope + `generated-factory.js` + `buildGenericHostConfig` 套壳」。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: contract-first-development
|
||||
description: "当多工位(前端/后端/SDK/AI/数据)并行开发同一交付时使用:先锁 contracts/ 八类契约、各自按契约 mock 对方接口解耦并行、最后集中联调,含 Day-0 契约清单、mock 策略、真实对接切换与联调规则。"
|
||||
---
|
||||
|
||||
# 契约先行与并行解耦联调手册（contract-first-development）
|
||||
|
||||
> 蒸馏来源：`docs/superpowers/specs/mvp-execution-spec-design.md`（§3 契约先行 / §6 并行解耦与 Mock / §8.3 联调规则）、`docs/architecture/架构/README.md`（§6 联调协议）、`docs/architecture/架构/README.md`（§7.7 API 契约与版本）。
|
||||
@ -8,6 +13,8 @@
|
||||
|
||||
## 目标
|
||||
|
||||
> **现状说明**：方法论（先锁契约 → mock 并行 → 集中联调）现行有效；文中 Day-N / WS1–5 具体数字出自已降级为视图的三周 execution spec，日常排期按 16 周主计划波次走。
|
||||
|
||||
**Day0（开发首日）半天全员锁定契约**，写入 `contracts/` 并提交 git；之后各工位基于契约 **mock 对方接口独立开发**，集中联调在 **Day11** 开始。把"等对方接口"的串行依赖，换成"对着契约并行"。
|
||||
|
||||
## 前置
|
||||
@ -66,6 +73,8 @@ Day11~Day12：集中联调（只联调、不加功能）
|
||||
| 后端新增/变更 API | **必须同步** `contracts/api-schemas/` 并通知前端（MVP spec §8.3） |
|
||||
| 契约定义顺序 | 后端**先写 `-api` 包的 VO/DTO**，前端据此定义 TS 类型（开发团队版 §6.1） |
|
||||
|
||||
> "开发团队版"/"技术决策版" = 两版《系统概要设计》，已归档 `_archive`，节号按历史读；现行规范见 [`../rules/engineering-conventions.md`](../rules/engineering-conventions.md) 与 [`docs/architecture/README.md`](../../docs/architecture/README.md)。
|
||||
>
|
||||
> API 演进规则：新增字段不算 breaking；删除/重命名字段 = 升版本（技术决策版 §7.7）。
|
||||
|
||||
---
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: doc-organizer
|
||||
description: "创始人手动触发「整理/清理文档」时使用:增量窗口体检 → fan-out 三轴分类(过期历史档/核心设计档措辞/总账)→ 编清理计划 → 对抗评审 → 创始人批准后才归档/压缩/回填;阶段一只读、批准前零文件改动。"
|
||||
---
|
||||
|
||||
# 文档整理助手（doc-organizer）
|
||||
|
||||
> **触发**：创始人**手动**（`/doc-organizer` 或"整理文档/清理文档"）。
|
||||
@ -63,10 +68,10 @@ Workflow({ scriptPath: ".agents/tools/doc-organizer-analyze.mjs",
|
||||
|
||||
## 安全红线（不可破）
|
||||
|
||||
1. **阶段一绝不改文件**；阶段二只动**已批准**清单内、文件名 ≤ 当前未完成波次的历史档；**最新日期在飞档不碰**（脚本对 `2026-06-16-*` 已硬拒归档）。
|
||||
1. **阶段一绝不改文件**；阶段二只动**已批准**清单内、文件名 ≤ 当前未完成波次的历史档；**最新日期在飞档不碰**（脚本动态取目录内最新日期档作在飞保护锚，旧硬编码日期已废，2026-06-17 改）。
|
||||
2. 破坏性操作（归档/压缩/git rm）**全程 git 跟踪可回滚**；提交前守卫核验：无外来文件、无在飞档、无 `orchestrator/*` 等未跟踪误纳。
|
||||
3. **检测自动、判断留人**：脚本只报"疑似/超标"，KEEP/ARCHIVE/改不改由 agent 据 _index+MEMORY 裁决、再由创始人批准。
|
||||
4. 白名单永留：`orchestrator/`（活工具箱）、`channel-spike/`（活 spike）、`generation-spike/`（可复现证据）。
|
||||
4. 白名单按现行路径维护：`orchestrator/` 已删（git 可查）、`channel-spike/` 已迁 `spikes/channel-spike/`、`generation-spike/` 已不存在。
|
||||
5. 多 session 共享树：push 前 fetch 核对、撞车的别人 untracked 文档先避让（见 [[multi-session-shared-tree-push-conflict]]）。
|
||||
|
||||
## 配套文件
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: drive-remote-claude-tmux
|
||||
description: "从控制机经 ssh+tmux 双向驱动远端机上交互式 Claude Code(send-keys 派活/capture-pane 读屏/专用 worktree 会话/git commit 作完成判据)时使用。⚠️ 退役候选:原前提 6c6g 大脑线已停用,去留待创始人拍;tmux 桥技术仍可复用。"
|
||||
---
|
||||
|
||||
# 远程驱动交互式 Claude Code（ssh + tmux）
|
||||
|
||||
> **用途**：从控制机（6c6g 大脑线）经 ssh 进远端开发机（Mac/Linux），**双向驱动跑在 tmux 里的交互式 Claude Code**——派活（`send-keys`）+ 读屏（`capture-pane`）。**不走 ACP、不走 `claude -p` headless**，驱动的就是带完整上下文的交互式 TUI，创始人能同时 `attach` 旁观/随时夺键。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: execution-plan-slicing
|
||||
description: "当写或评审多单元执行 plan、或感到「每到下阶段前面阶段的工作都要返工」时使用:辨别横切关注面 vs 纵切成果切片、诊断返工信号、原地换轴重组、「设计 HOW 移交/执行契约必留」判据,及换轴必查七坑。"
|
||||
---
|
||||
|
||||
# 执行 plan 切分轴 —— 横切关注面 vs 纵切成果切片
|
||||
|
||||
> 一份多单元的执行 plan,工作单元按什么轴切,决定它能不能照着走。切错轴,执行时每推进一个单元都要回头补前一个,表现为"每到下个阶段,前面阶段的工作都要重做"。
|
||||
@ -40,7 +45,7 @@
|
||||
- **canonical 唯一性门**:同 topic 至多一份 canonical。换轴**原地重构现有 plan**、不新建第二份;文件名保留(防止引用它的活档死链);旧主轴内容降为对账小节(留痕、不删)。
|
||||
- frontmatter `supersedes` 记"自身旧主轴版",git 留演进痕。
|
||||
|
||||
## 换轴时必查的五坑(双评审 + 执行核查实证)
|
||||
## 换轴时必查的七坑(双评审 + 执行核查实证)
|
||||
|
||||
- **过时口径搬运 → 假前置门**:旧 plan 的某些状态可能已被设计 SoT 推翻(例:plan 写"协议定级待创始人拍",而设计 SoT 已三处明写"定级已冻")。照搬就把已就绪的执行项错挂成"等决策",制造不存在的阻塞。换轴时逐项核对设计 SoT 的**当前**状态,别信旧 plan 的措辞。
|
||||
- **对账表漏面**:横切有几个面,对账表就要覆盖几个(例:声称"八面"却只列六面,漏掉的面在换轴里掉落)。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: feature-design-doc
|
||||
description: "当新功能/跨模块/改用户可见行为/触及外部服务·支付·数据进入设计阶段时使用:产出 WHAT+HOW 合一的功能设计文档——文字+Mermaid 为事实源、SVG/HTML 给人看,含第 0 步 SoT 注册表查证、sot-impact/上级申报、防漂移单源与文档骨架。"
|
||||
---
|
||||
|
||||
# 功能设计文档作业手册（feature-design-doc）
|
||||
|
||||
> 每个有真实复杂度的功能，开工前产出**一份**「功能设计文档」，取代旧的 `-review.md` + `-execution.md` 双档。一份文档同时承载 **WHAT**（意图/目标/边界/验证）与 **HOW**（方案/步骤），并以**一式两份**的表达服务两类读者：**文字 + Mermaid** 给人和 AI（AI 主靠它），**SVG / HTML** 给人（更重要，看图即懂边界与核心思想）。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: game-e2e-cdp-harness
|
||||
description: "为插件库/生成游戏做真浏览器输入级 e2e(触摸轨迹→九门判真玩→四件套证据)时使用:play.cdp.cjs 九门(装载/掌帧/真渲染/接线/输入因果/latch/手感)+ 假绿守卫 + driver 库 + 首局体验门,mini-desktop 上跑,区别于 DOM 走查。"
|
||||
---
|
||||
|
||||
# Canvas 游戏 e2e 证据 harness 配方（CDP on mini-desktop）
|
||||
|
||||
> 适用：插件库/生成游戏的**真浏览器输入级 e2e**（触摸轨迹→状态机推进→四件套证据），区别于 DOM 走查（那个见 [`ui-walkthrough-cdp.md`](./ui-walkthrough-cdp.md)）。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: heritage-game-design
|
||||
description: "当为非遗/传统技艺题材 brief 产设计阶段玩法方案或评审时使用:工序节拍/图样拼合等玩法化范式、节奏数值锚、文化表述红线与可达红线、反贴皮自检、品类 rubric(H1–H5)与成长轴替代申报。"
|
||||
---
|
||||
|
||||
# skill: heritage-game-design —— 非遗品类小游戏「玩法设计」作业手册(给生成 agent 的设计阶段)
|
||||
|
||||
> 定位:这是 **生成 agent 设计阶段造「好玩的非遗主题玩法设计」的唯一作业手册**。它回答 **"设计什么才好玩"**(玩法化路径/机制/进度/数值/美术/音/UI 范式),与 [`littlejs-game-dev.md`](littlejs-game-dev.md)(回答"代码怎么写")配对:**设计阶段产玩法概念 → 代码生成阶段照 littlejs-game-dev 产代码**。体例与分工同 [`sim-business-game-design.md`](sim-business-game-design.md)(经营品类的对应手册)。
|
||||
@ -135,7 +140,7 @@
|
||||
|
||||
## 10. 反"贴皮/无趣"落地清单(design 自检,逐条必过)
|
||||
|
||||
通用 8 条好玩自检(即时反馈/可见成长/下一个解锁/30 秒爽点/数值滚雪球/情感锚/放置回归/音反馈)见 [`sim-business-game-design.md`](sim-business-game-design.md) §10 —— **对所有品类通用,本品类照过**(成长轴按 §1 的申报映射:工艺步骤解锁;情感锚落在器物上,§4)。此外本品类另过 5 条品类扩展(与品类 rubric 同源,见 §11):
|
||||
通用 12 条口径好玩自检(原 8 条即时反馈/可见成长/下一个解锁/30 秒爽点/数值滚雪球/情感锚/放置回归/音反馈,SoT §4 已增补至 12 条)见 [`sim-business-game-design.md`](sim-business-game-design.md) §10 —— **对所有品类通用,本品类照过**(成长轴按 §1 的申报映射:工艺步骤解锁;情感锚落在器物上,§4;第 12 条「核心操作非无脑」落在工序链先后依赖与火候窗口时机——依序推进、正窗出手是真判断/真技巧,判错回炉有代价,非永远可点的无脑点击,见 §11 H1/H2)。此外本品类另过 5 条品类扩展(与品类 rubric 同源,见 §11):
|
||||
|
||||
1. **工序链成立**:玩法是不是围绕一条有名字、有先后的工序链推进?(乱点无序 = 没有"手艺"体感)
|
||||
2. **节律张力**:有没有"在对的时刻出手"的窗口与回报?(永远可点、何时点都一样 = 无手感)
|
||||
@ -147,7 +152,7 @@
|
||||
|
||||
## 11. 品类 rubric(丰富度品类扩展 · 喂 LLM 验证 agent · 非阻塞)
|
||||
|
||||
对齐质量模型 SoT([`游戏质量与爆火能力`](../../docs/architecture/架构/生成引擎/游戏质量与爆火能力.md))§4 计分制:每条 0/1 + 层标,与通用底座 v2(11 条)**分母分开、独立小计**;纯 LLM 评分、不进九门、不进脚手架、不拦发布。机器可读同源文件(评分尺数据,含锚定值)= [`cheap-worker/fixtures/genre-rubrics/heritage.json`](../../cheap-worker/fixtures/genre-rubrics/heritage.json)(2026-07-02 rubric 挂点归一改名并接线,品类键=heritage);金标锚定纪律(≥1 正例 + ≥1 薄反例、评分尺变更须金标复验、单款分组小计漂移 >±1 回退)照 SoT §4 规范三执行。
|
||||
对齐质量模型 SoT([`游戏质量与爆火能力`](../../docs/architecture/架构/生成引擎/游戏质量与爆火能力.md))§4 计分制:每条 0/1 + 层标,与通用底座 v2(12 条)**分母分开、独立小计**;纯 LLM 评分、不进九门、不进脚手架、不拦发布。机器可读同源文件(评分尺数据,含锚定值)= [`cheap-worker/fixtures/genre-rubrics/heritage.json`](../../cheap-worker/fixtures/genre-rubrics/heritage.json)(2026-07-02 rubric 挂点归一改名并接线,品类键=heritage);金标锚定纪律(≥1 正例 + ≥1 薄反例、评分尺变更须金标复验、单款分组小计漂移 >±1 回退)照 SoT §4 规范三执行。
|
||||
|
||||
| # | 层 | 判据(0/1) | 正例 | 反例 |
|
||||
|---|---|---|---|---|
|
||||
@ -157,7 +162,9 @@
|
||||
| H4 | L4 | **作品可展示**:成品进图鉴/结算屏有成品展示画面(可截图的文化炫耀时刻) | 结算屏摆出本局做成的三件器物 + 名字 + 工钱 | 到点只弹一行「得分 120」文字即黑屏 |
|
||||
| H5 | L2 | **文化氛围一致**:主题、工序命名、配色、音效构成一致的传统氛围(通识表述),主题词换成现代词玩法画面即散 | 陶坊主题 + 陶土色系 + 塑形/上釉工序名 + 民乐感音效 | 标题带"非遗"但画面霓虹方块、工序叫 step1/step2 |
|
||||
|
||||
分组小计:品类扩展 L2 ×3(H1/H2/H5)/ L3 ×1(H3)/ L4 ×1(H4),分母 5,与通用底座 11 条分开计。逐条长期不成立 = 本 skill 或品类骨架的改进信号(SoT §4 规范六)。
|
||||
分组小计:品类扩展 L2 ×3(H1/H2/H5)/ L3 ×1(H3)/ L4 ×1(H4),分母 5,与通用底座 12 条分开计。逐条长期不成立 = 本 skill 或品类骨架的改进信号(SoT §4 规范六)。
|
||||
|
||||
金标锚以 `cheap-worker/fixtures/genre-rubrics/heritage.json` 的 `anchors`/`_note` 为准(正例 `_fewshot-feiyi` 10/11·品类 5/5,薄反 `_template-feiyi` 6/11·3/5,2026-07-03 复验零漂移)。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: littlejs-game-dev
|
||||
description: "当生成 agent 要写一款可上线 LittleJS 小游戏的 game-logic.js(接五法、调 11 注入插件、守受控面红线、mmx 产素材)时使用:代码分层结构、写什么 vs 调什么、插件 API 速查与 M3 易犯幻觉、资产放置。轻中档 code 层唯一作业手册。"
|
||||
---
|
||||
|
||||
# skill: littlejs-game-dev —— AI 直接写 LittleJS 游戏代码（调插件 API,不重写实现)
|
||||
|
||||
> 定位:这是 **生成 agent 造一款可上线的高质小游戏的唯一作业手册**。绘境AI 的终态产物 = `src/` 多文件 LittleJS 工程
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: narrative-game-design
|
||||
description: "当为剧情互动/文字冒险/恋爱剧情类 brief 产设计阶段故事方案或评审时使用:分支/属性/多结局范式、文本与分支预算红线、结局 latch 与取证契约、替代成长轴申报(章节+图鉴)、品类 rubric 指针与金标锚点。"
|
||||
---
|
||||
|
||||
# skill: narrative-game-design —— 剧情互动小游戏「玩法设计」作业手册(给生成 agent 的设计阶段)
|
||||
|
||||
> 定位:这是 **生成 agent 设计阶段(AgentScope)造"好玩的剧情互动玩法设计"的唯一作业手册**。它回答 **"设计什么才好玩"**(故事结构/分支/属性/结局/美术/音/UI 范式),与 [`littlejs-game-dev.md`](littlejs-game-dev.md)(回答"代码怎么写")配对:**设计阶段产故事概念 → 代码生成阶段照 littlejs-game-dev 产代码**。体例与 [`sim-business-game-design.md`](sim-business-game-design.md)(经营品类)同构。
|
||||
@ -145,7 +150,7 @@
|
||||
|
||||
**通用 8 条自检**(与 [`sim-business-game-design.md`](sim-business-game-design.md) §10 同一张表,所有品类通用):①即时反馈 ②可见成长 ③下一个解锁 ④30 秒爽点 ⑤数值滚雪球 ⑥情感锚 ⑦放置回归 ⑧音反馈。剧情类的对位:①=选择确认音+粒子;②=属性 HUD 上涨 + 幕数推进;③=图鉴 ??? 与检定"差一点";⑤⑦天然弱(纯叙事无滚雪球/放置,**按上位标准 §7 申报以「章节推进+结局图鉴」为替代轴**,不硬凑)。
|
||||
|
||||
**剧情品类扩展 rubric(5 条,喂 LLM 丰富度验证 agent · 非阻塞)**。规范来源 = 质量模型 SoT §4:每条 0/1 + 层标(L2 内容丰富 / L3 留存结构 / L4 传播钩子),与通用底座 11 条**分母分开、独立小计**;条目形状 =(编号 / 层标 / 一句可判定判据 / 一对正反例),与 `cheap-worker/cheap_verify.py` 的 RICHNESS_CHECKLIST 三元组同形,供品类扩展评分接线时直接注入;**纯 LLM 评分,绝不写成代码校验、不进九门、不进脚手架**(创始人红线):
|
||||
**剧情品类扩展 rubric(5 条,喂 LLM 丰富度验证 agent · 非阻塞)**。规范来源 = 质量模型 SoT §4:每条 0/1 + 层标(L2 内容丰富 / L3 留存结构 / L4 传播钩子),与通用底座 12 条**分母分开、独立小计**(通用底座第 12 条「核心操作非无脑」的剧情对位 = 检定/分流即真实选择代价,选错落 lose 结局);条目形状 =(编号 / 层标 / 一句可判定判据 / 一对正反例),与 `cheap-worker/cheap_verify.py` 的 RICHNESS_CHECKLIST 三元组同形,供品类扩展评分接线时直接注入;**纯 LLM 评分,绝不写成代码校验、不进九门、不进脚手架**(创始人红线):
|
||||
|
||||
五条(选择有重量 / 场景有画面感 / 结局图鉴钩子 / 属性塑造可见 / 结局可炫耀)的机器版 = **单源 [`cheap-worker/fixtures/genre-rubrics/narrative.json`](../../cheap-worker/fixtures/genre-rubrics/narrative.json)**(2026-07-04 迁出,判据与正反例一字不动;改条目只改 fixture,本节不再维护表格副本——评分尺变更的金标复验纪律见下段)。
|
||||
|
||||
|
||||
@ -1,93 +1,107 @@
|
||||
---
|
||||
name: prompt-governance
|
||||
description: "当新增或修改生命周期 prompt、搭建 Prompt Registry 与四道闸 eval 门禁、或对接人在环节点时使用:prompt 即第 8 类契约,contracts/prompts 版本化单一事实源与治理流程(段A版本闸+段B真模型闸 CI 已接)。"
|
||||
---
|
||||
|
||||
# Prompt 工程治理手册（prompt-governance）
|
||||
|
||||
> 蒸馏来源：执行版 [`../../docs/architecture/架构/生成引擎/prompt治理.md`](../../docs/architecture/架构/生成引擎/prompt治理.md)（HJ-PROMPT-GOV-EXEC-001）。
|
||||
> 适用：新增/修改任何生命周期 prompt（意图/代码生成/素材/剧情/锁风/测试/平台转换/运营诊断）、搭建 Prompt Registry 与 eval 门禁、对接人在环（HITL）节点。
|
||||
> 适用：新增/修改任何生命周期 prompt（安全/意图/模板/生成/素材/质量/修复/元信息八阶段，及 tier2 富游戏线）、搭建 Prompt Registry 与 eval 门禁、对接人在环（HITL）节点。
|
||||
> 配套：契约先行见 [`./contract-first-development.md`](./contract-first-development.md)；AI 生成链路见 [`./agentic-amodel-generation.md`](./agentic-amodel-generation.md)；运行时/Cocos 见 [`./runtime-and-multichannel.md`](./runtime-and-multichannel.md)；选型见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1；降级红线见 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md)。
|
||||
>
|
||||
> **⚠️ 引擎上下文纠偏（2026-06-12）**：本手册**核心理念（Prompt 即第 8 契约 / Registry / eval 门禁 / HITL）现行有效不变**；但下文凡以 **Dify / OpenGame** 为注入目标/引擎载体的描述均按现行裁决改读——**Dify/OpenGame=降级远期未部署**（C2/HJ-GEN-001），Tier1 生成主线=**new-api 网关 + agent 写码于插件库**（引擎=LittleJS 增强发行版），agentic 编排基建=**AgentScope 2.x**（HJ-AGI-001）。"模板填充"措辞按模板哲学终裁更新（玩法模板层废除）。Cocos-MCP（Tier2/3）仍现行有效。
|
||||
>
|
||||
> **⚠️ 现行化重写（2026-07-05）**：§1–§3 已按现行 `registry.yaml`（阶段编号目录重构 + 头部消费面三态对账）与 W-PCI 后口径整块重写——目录树、加载器类名（`PromptResourceLoader`）、两条 live 生成线（便宜档 cheap-worker / tier2 AgentScope）形态均改为现行事实，此前散在正文的划线改读不再需要、随句清理。上条 2026-06-12 记的「Cocos-MCP 仍现行有效」本次一并修正：Cocos-MCP 降为 3D 与渠道导出的人在环工具，非 live 生成形态。
|
||||
|
||||
---
|
||||
|
||||
## 核心理念：Prompt 即第 8 类契约资产
|
||||
|
||||
所有 prompt 进 git `contracts/prompts/` **单一事实源**，与 Day-0 七契约同级。每条 prompt 绑定一份完整契约：`输入 Schema + 输出 Schema + 硬约束块 + Golden 样本集 + owner + version`。**运行时按 `id@version` 加载注入，不在引擎/编排内核里内嵌**（~~Dify/OpenGame/Cocos~~→现行=LittleJS 插件库 / AgentScope / Cocos-MCP）——延续"能力增强放壳层、不动内核"的纪律。
|
||||
所有 prompt 进 git `contracts/prompts/` **单一事实源**，与 Day-0 七契约同级，在 `registry.yaml` 按条目登记（id / version / stage / owner / file / desc / eval），各配 Golden eval 集与硬约束。**运行时按注册条目正文加载注入、不在引擎/编排内核里内嵌**——便宜档由 cheap-worker 读、tier2 由 AgentScope gen-worker 读、后端模板策划由 `PromptResourceLoader` 读，延续"能力增强放壳层、不动内核"的纪律。
|
||||
|
||||
> 为什么必须治理：多引擎/多链路使 prompt 数量与形态膨胀；无单一事实源 → 跨链路无法统一治理、改动无法回归验证。（~~原述"双引擎 OpenGame+Cocos-MCP"~~ 中 OpenGame 已退役，见上方纠偏。）
|
||||
> 为什么必须治理：多条生成线（便宜档 / tier2 / 后端模板策划）使 prompt 数量与形态膨胀；无单一事实源 → 跨链路无法统一治理、改动无法回归验证。
|
||||
|
||||
---
|
||||
|
||||
## 1. Registry 目录结构
|
||||
|
||||
Prompt 按生成链路阶段编号归档，`registry.yaml` 作索引（唯一事实源），`eval/` 放各条 Golden 集，同级还摆着三个治理脚本：
|
||||
|
||||
```
|
||||
contracts/prompts/
|
||||
├── registry.yaml # 索引：所有 prompt 的 id/版本/owner/绑定 schema/eval 集
|
||||
├── _schemas/ # 输入/输出 JSON Schema（prompt 的契约）
|
||||
├── intent/ # 意图解析、模板匹配（owner=aigc）
|
||||
├── codegen-opengame/ # Tier1 文生代码（owner=aigc）
|
||||
├── codegen-cocos-mcp/ # Tier2/3 agentic 工具编排（owner=studio）
|
||||
├── asset/ # 素材生成（图/音/角色/特效）+ IP LoRA 约束（owner=aigc）
|
||||
├── narrative/ # 剧情/分支对白/关卡（owner=studio）
|
||||
├── lockstyle/ # 锁风约束（风格-版权一致性，owner=compliance）
|
||||
├── qa/ # 测试用例 + 可玩性脚本（owner=aigc，T-AGC-09）
|
||||
├── convert/ # 打包/平台转换约束（尺寸/资质/违禁词，owner=runtime）
|
||||
└── ops/ # AI 诊断/改版任务（owner=telemetry）
|
||||
├── registry.yaml # 注册表(索引):每条 prompt 的 id / version / stage / owner / file / desc / eval
|
||||
├── README.md # 目录说明 + registry 一致性 CI 门说明
|
||||
├── check_registry.py # CI 门:registry.yaml 各条 version 与对应 .md frontmatter version 对齐
|
||||
├── check_version_bump.py # 段 A 离线版本闸:改正文必升 version(见 §6)
|
||||
├── eval_gate.py # 段 B 真模型闸:对 live 条目跑四道闸、真调 M3(见 §6)
|
||||
├── 01-safety/ # Prompt 安全/注入检测
|
||||
├── 02-intent/ # 意图解析
|
||||
├── 03-template/ # 模板匹配
|
||||
├── 04-config/ # 生成主线:cheap-system(便宜档主 prompt) + 各品类 -designer(模板策划/编码)
|
||||
├── 05-asset/ # 素材生成(ComfyUI 引导)
|
||||
├── 06-quality/ # 质量评估
|
||||
├── 07-fix/ # 失败修复/重生成
|
||||
├── 08-meta/ # 标题/简介/封面文案
|
||||
├── 09-tier2-richgame/ # tier2 富游戏自治生成线的 8 条 prompt(AgentScope 多 agent)
|
||||
└── eval/<id>/ # 每条 prompt 的 Golden eval 集(inputs.jsonl / labels.jsonl / baseline.json / runs/)
|
||||
```
|
||||
|
||||
每条 prompt = frontmatter 契约头 + 模板体：
|
||||
01–08 是按生成链路顺序保留的阶段槽，眼下真正落有条目的是 `01-safety`、`04-config`（生成主线含便宜档）、`06-quality` 与 `07-fix`（agent 闭环批跑遗留），加上 `09-tier2-richgame`（tier2 八条）；其余为规划槽、暂无 prompt。
|
||||
|
||||
每条 prompt 在 `registry.yaml` 登记一条索引，字段固定为 id / version / stage / owner / file / desc / eval，没有 engine / tier——生成线归属由 stage 与消费方代码决定，不写进注册表。摘一条现行 live 条目为例：
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: codegen-opengame.scaffold # 唯一 id（目录.阶段）
|
||||
version: 1.2.0 # 语义化版本
|
||||
owner: WS2/aigc # 唯一负责工位/模块
|
||||
tier: tier1 # tier1 | tier2 | tier3
|
||||
engine: opengame # opengame | cocos-mcp | dify | comfyui | runtime
|
||||
stage: scaffold
|
||||
input_schema: _schemas/codegen-input.json
|
||||
output_schema: _schemas/game-config.json
|
||||
constraints: # 硬约束块（产物必须满足）
|
||||
- 首屏≤2MB, 总包≤10MB
|
||||
- 游戏内零网络请求（CSP connect-src none）
|
||||
eval_set: eval/codegen-opengame.scaffold/
|
||||
guardrails: [injection-detect, schema-validate, asset-ref-check]
|
||||
---
|
||||
{{system_prompt}}
|
||||
... 模板体，带 {{变量槽}} ...
|
||||
- id: safety.prompt-check # 唯一 id = 阶段域.角色
|
||||
version: 1.0.0 # 语义化版本;改正文必升(段 A 版本闸强制)
|
||||
stage: "01-safety" # 阶段编号目录(01-safety…08-meta / 09-tier2-richgame)
|
||||
owner: WS2 # 唯一负责工位
|
||||
file: 01-safety/prompt-safety-check.md # 正文文件(其 frontmatter 至少含 id+version)
|
||||
desc: 创作者 Prompt 安全/注入检测（生成链路第 1 节点）
|
||||
eval: eval/safety.prompt-check/ # Golden eval 集(四道闸:Schema/成功率/回归diff/成本延迟)
|
||||
```
|
||||
|
||||
注册表是索引与对账基准，prompt 正文另存于 `file` 指向的 .md，各带一份 frontmatter（至少 id 与 version，`check_registry.py` 逐条比对两侧 version 防漂移）。有的正文还内嵌 output_schema / hard_constraints（如 safety）或 tier / engine 注记（如 tier2 各条），那是正文自己的元信息，注册表条目只认上述七字段。
|
||||
|
||||
---
|
||||
|
||||
## 2. 加载 / 注入机制
|
||||
|
||||
- **aigc / studio 壳层** 持有 `PromptRegistryLoader`：按 `id@version` 取 prompt 文本并用变量渲染。
|
||||
- ~~**Dify 节点**：prompt 用 `{{registry:intent.parse@1.2.0}}` 引用，壳层调用前注入实际文本。~~（Dify 已退役；现行=壳层/编排器调 new-api 前按 `id@version` 渲染注入。）
|
||||
- ~~OpenGame~~ / Cocos-MCP / ComfyUI：壳层把对应 prompt 作为参数/ system prompt 传入（OpenGame 已退役，Tier1 改 agent 写码于 LittleJS 插件库；Cocos-MCP/素材链不变）。
|
||||
- **DB 镜像（可选）**：只读，仅为运行时热加载提速；写入路径唯一为 git。
|
||||
三条生成线各有自己的加载器，共同纪律是按 `file` 指向的正文加载、best-effort 回落进程内内置原文、绝不因 prompt 读取失败中断生成：
|
||||
|
||||
> 部署时强制校验 registry 版本一致；CI 卡 Schema。改 prompt = 改 git → PR → eval 门禁 → 合入 → 同步运行时。
|
||||
- **后端模板策划 prompt（`04-config` 各品类 `-designer`）** 由 game-module-aigc 的 `PromptResourceLoader` 加载。构建期 maven-resources-plugin 把 contracts 下的 prompt 与 schema 快照进 `classpath:wanxiang-contracts/`（jar 内只是构建时快照，git `contracts/` 仍是唯一事实源）；启动逐模板自检，任一缺失或形态非法即整体 `ready=false` 自禁用，执行器 tick 首检不认领任务、不崩 app。渲染只做 `{{input.xxx}}` 替换加残留占位符检测；version 仅作可追溯日志，不做 registry 对账——那是 CI 四道闸的职责，Java 不复制治理逻辑。配了 `aigc.prompts.dir` / `AIGC_PROMPTS_DIR` 外置目录后每 60s 热取，运营改完 prompt 无需重启即生效，读失败保留上次、classpath 快照永久兜底。
|
||||
- **便宜档 cheap-worker** 由 `cheap_roles.py` 的 `_load_system_prompt()` 运行时读 `04-config/cheap-system.md` 正文，读不到、脏或缺文件即回落进程内 `_SYSTEM_PROMPT`。
|
||||
- **tier2 富游戏 gen-worker** 由 `roles.py` 经 `worker/prompts.py` 的 `prompts.load` 运行时读 `09-tier2-richgame/` 下八条正文，读不到或脏即回落 roles.py 内置原文。
|
||||
|
||||
版本一致性由 `check_registry.py` 守门：逐条比对 registry 的 version 与对应 .md frontmatter 的 version，不一致即拒绝合入（防 `PromptResourceLoader` 构建期快照版本与注册表宣称漂移、审计失真），已挂 pre-commit 与服务端 `contract-gates.yml`。
|
||||
|
||||
> 改 prompt = 改 git 正文加升 version → PR → eval 门禁 → 合入 → 下次构建或热取自动携带新版。
|
||||
|
||||
---
|
||||
|
||||
## 3. 两套 Prompt 形态
|
||||
## 3. 两条 live 生成线的 prompt 形态
|
||||
|
||||
| 维度 | OpenGame prompt（Tier1） | Cocos-MCP prompt（Tier2/3） |
|
||||
现行 runtime 只有两条生成线在跑，prompt 形态、加载器与失败回落各管一摊：
|
||||
|
||||
| 维度 | 便宜档 cheap-worker | tier2 富游戏 AgentScope 多 agent |
|
||||
|---|---|---|
|
||||
| 形态 | 生成式：文本 → 游戏代码 | agentic：驱动 158 个编辑器工具的工具编排 |
|
||||
| 调用 | 单次/6 阶段 pipeline | 多步、有状态、多轮工具调用 |
|
||||
| 归属 | **aigc**（无状态生成原子） | **studio**（有状态创作编排，T-STU-05） |
|
||||
| 失败降级 | 退化为确定性兜底产出（~~模板填充~~，措辞按模板哲学终裁更新） | 退化为 Tier1；MVP 仅探针 |
|
||||
| 主 prompt | 单条 `config.cheap-system` | `tier2.*` 八条（leader + 四工作室专家 + 兜底 `design-system` + 单写 `writer` + 软检 `player`） |
|
||||
| 范式 | A-model 一个 agent 写 LittleJS `src/` 源工程（入口契约 + 插件 + 红线 + 输入契约 + 完成判据） | AgentScope 2.0.2 ReAct 两阶段：阶段 1 工作室多 agent 出设计稿 → 阶段 2 单写 ReAct 写 Phaser 源码 + L3 视觉软检玩家 |
|
||||
| AI 参与深度 | 轻（便宜档，插件库承重、AI 少写） | 重（自治多轮、有状态工具编排） |
|
||||
| 归属目录 | `04-config/cheap-system.md` | `09-tier2-richgame/`（八文件） |
|
||||
| 消费方 | `cheap_roles.py` `_load_system_prompt()` | `roles.py` 经 `worker/prompts.py` `prompts.load` |
|
||||
| 失败回落 | 回落 `cheap_roles._SYSTEM_PROMPT` | 回落 roles.py 内置原文 |
|
||||
|
||||
> 目录分治（`codegen-opengame/` vs `codegen-cocos-mcp/`），加载器按 `engine` 字段分发，不强行统一模板。
|
||||
> **Cocos-MCP 不是 live 生成形态**：它降为 3D 与渠道导出的人在环工具（人工在编辑器里操作），不进 MVP 生成 runtime，也不在本治理的形态对照内。素材生成链（ComfyUI 引导，归 `05-asset/`）另走各自门禁。
|
||||
|
||||
---
|
||||
|
||||
## 4. 新增一条 Prompt（操作步骤）
|
||||
|
||||
1. 在对应阶段目录建 prompt 文件，写全 frontmatter（id/version/owner/tier/engine/stage）。
|
||||
2. 定义或复用 `_schemas/` 下的输入/输出 JSON Schema，frontmatter 绑定。
|
||||
1. 在对应阶段编号目录建 prompt 正文 .md，写 frontmatter（至少 id + version，归属写 owner；stage 与注册表一致）。
|
||||
2. 有输出约束的（如 `04-config` 各品类模板策划）绑定 `contracts/templates/<id>.schema.json`；纯 system prompt（`cheap-system` / tier2 各条）无外置输出 schema。
|
||||
3. 写硬约束块 + guardrails（注入检测/Schema 校验/资源引用校验）。
|
||||
4. 建 Golden eval 集 `eval/<id>/`：`inputs.jsonl`（5–10 条核心样本）+ `expect.yaml`（期望属性/阈值）+ `baseline/`（基线产物快照）。
|
||||
5. 在 `registry.yaml` 登记索引。
|
||||
4. 建 Golden eval 集 `eval/<id>/`：`inputs.jsonl`（核心样本）+ `labels.jsonl`（期望标注）+ `baseline.json`（基线快照，`--update-baseline` 建，闸 3/4 据此判增量）；每次跑的台账 append-only 落 `runs/`。
|
||||
5. 在 `registry.yaml` 登记条目（id/version/stage/owner/file/desc/eval）。
|
||||
6. 提 PR → eval 门禁绿 + 人工抽检 → 合入 → 部署同步。
|
||||
|
||||
## 5. 修改一条 Prompt 并验证效果（操作步骤）
|
||||
@ -107,7 +121,7 @@ guardrails: [injection-detect, schema-validate, asset-ref-check]
|
||||
|---|---|---|
|
||||
| ① Schema 通过率 | 输出符合 output_schema 的比例 ≥ 阈值 | 评审版 §4.4 |
|
||||
| ② 生成成功率 | 可运行 + 质量通过 ≥ **80%** | MVP 验收线 |
|
||||
| ③ Golden 回归 | 与 `baseline/` 关键字段 diff，防退化 | 泛化自 T-AGC-08 |
|
||||
| ③ Golden 回归 | 与 `baseline.json` 关键字段 diff，防退化 | 泛化自 T-AGC-08 |
|
||||
| ④ 成本/延迟 | token/耗时不劣化 | 评审版 §4.4 |
|
||||
|
||||
四闸全绿 → 人工抽检 K 条（主观质量/可玩性）→ 合入。
|
||||
@ -125,7 +139,7 @@ guardrails: [injection-detect, schema-validate, asset-ref-check]
|
||||
|
||||
## 8. 测试脚本生成（T-AGC-09）
|
||||
|
||||
aigc 新增**无状态原子**：输入 GameConfig → 输出可玩性测试脚本（启动/输入响应/边界）；由 **runtime 编译流水线执行**为入库门禁的一环。其 prompt 归 `contracts/prompts/qa/`。不新增模块。
|
||||
aigc 新增**无状态原子**：输入 GameConfig → 输出可玩性测试脚本（启动/输入响应/边界）；由 **runtime 编译流水线执行**为入库门禁的一环。其 prompt 若落地归质量评估阶段 `06-quality/`。（现行可玩性判定实走生成线九门真玩 harness，本条 T-AGC-09 独立测试脚本 prompt 尚未落地。）不新增模块。
|
||||
|
||||
---
|
||||
|
||||
@ -135,7 +149,7 @@ aigc 新增**无状态原子**：输入 GameConfig → 输出可玩性测试脚
|
||||
|---|---|
|
||||
| prompt 加载失败（缺 id/version） | 回退**内置默认 prompt** + 告警，不中断生成 |
|
||||
| LLM 不可用 | 退化为确定性 Fallback 生成器（确定性兜底产出，~~模板填充~~措辞已更新，见 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md) §5.2） |
|
||||
| Cocos-MCP 工具调用失败 | 降级 Tier1 路径（~~OpenGame~~ 已退役）；MVP Tier2/3 仅探针 |
|
||||
| tier2 / 便宜档 prompt 正文热取读到脏或缺失 | 回落进程内内置原文（roles.py 原文 / `cheap_roles._SYSTEM_PROMPT` / classpath 快照），best-effort 绝不中断生成 |
|
||||
| eval CI 跑不通（LLM 限流） | 标记 skip + 人工兜底审，不阻塞紧急修复 |
|
||||
|
||||
---
|
||||
@ -147,7 +161,7 @@ aigc 新增**无状态原子**：输入 GameConfig → 输出可玩性测试脚
|
||||
| 改了 prompt 没 bump version | CI 卡：version 未变拒绝合入（防静默覆盖） |
|
||||
| Golden 集过拟合 | 样本要覆盖典型+边界，bad case 增量补；勿只放"好跑"的样本 |
|
||||
| registry 与运行时不同步 | 部署强制版本校验；DB 镜像只读；改 prompt 必同步 registry.yaml |
|
||||
| Cocos-MCP prompt 当文生代码写 | 它是 agentic 工具编排（多步），不是单次文本；归 studio 编排 |
|
||||
| tier2 多 agent prompt 当单次文生代码写 | 它是 AgentScope ReAct 多步有状态编排（工作室设计→单写→软检）；改一条只改对应 `09-tier2-richgame/*.md` 正文加升 version，不改 Python |
|
||||
| 把 CI 门焊在化石 prompt 上白花钱 | 段 B 真模型闸只焊 live 面；接门前先查 registry 头部消费面三态对账，非 live（fossil/batch-relic）SKIP 豁免、live 无金标 fail-closed；先用代码坐实「谁真被 live 路径喂 LLM」再决定跑不跑 |
|
||||
| 单条模型调用失败当成 prompt 退化拦 | 网关 500/限流是基础设施问题，从判定分母排除 + 建议复跑（多数失败才判人工兜底），别让偶发抖动误判 prompt 质量 |
|
||||
| 运营绕过 eval 直接改 DB | DB 是 git 只读镜像，无写入路径；改 prompt 唯一入口=PR |
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: puzzle-game-design
|
||||
description: "当为解谜/找茬/消除/记忆类 brief 产设计阶段玩法方案或评审时使用:顿悟引擎、可达谜题范式、关卡阶梯与计分锚、「解须在取证面上」「盘面必可解」等品类特有红线、通用+品类自检、金标锚点。"
|
||||
---
|
||||
|
||||
# skill: puzzle-game-design —— 解谜小游戏「玩法设计」作业手册(给生成 agent 的设计阶段)
|
||||
|
||||
> 定位:这是 **生成 agent 设计阶段造"好玩的解谜玩法设计"的唯一作业手册**。它回答 **"设计什么才好玩"**(谜题机制/关卡进度/数值/美术/音/UI 范式),与 [`littlejs-game-dev.md`](littlejs-game-dev.md)(回答"代码怎么写")配对:**设计阶段产玩法概念 → 代码生成阶段照 littlejs-game-dev 产代码**。经营/养成类的对应手册是 [`sim-business-game-design.md`](sim-business-game-design.md);两份体例相同、品类不同。
|
||||
@ -164,10 +169,10 @@
|
||||
| # | 层 | 条目 | 一句判据 | 正例 | 反例 |
|
||||
|---|---|---|---|---|---|
|
||||
| P1 | L2 | 谜题规则递进 | 关卡引入 ≥2 种谜题规则/维度,后关比前关多一层复杂度,不是同一规则换数字重复 | 1–2 关按颜色找、3–4 关按形状找、5 关颜色+形状组合 | 8 关全是"找红色",只是格子变多 |
|
||||
| P2 | L2 | 顿悟距离 | 谜面需观察/比对/推理才能定位解,线索与答案之间有"想一下"的距离,不是看见就点的纯反应 | 线索"数量为 3 的宝石",盘面要数一数 | 目标自己发光闪烁,无脑点亮的 |
|
||||
| P2 | L2 | 顿悟距离 | 谜面需观察/比对/推理才能定位解,线索与答案之间有"想一下"的距离,不是看见就点的纯反应 | 线索"数量为 3 的宝石",盘面要数一数才敢点 | 目标自己发光闪烁,无脑点亮的 |
|
||||
| P3 | L3 | 关卡阶梯可见 | 玩家任意时刻能看到关卡进度(第 N/共 M 关或下一关预告),过关有明确庆祝节点 | HUD 常驻"第 3/8 关"+ 过关全屏庆祝 | 只有分数在涨,玩家不知道自己走到哪 |
|
||||
| P4 | L2 | 卡壳兜底 | 卡住 ≥8–12s 有软提示(高亮/排除/线索重播),卡壳不出局不清零 | 10s 无操作候选格开始脉动 | 卡住只能干等到超时判负 |
|
||||
| P5 | L4 | 成绩可炫耀 | 结算展示可比较成绩(用时/连击/星级/称号,配最佳纪录),不是打完就黑屏 | 结算面板:分数+最高连击+3 星+历史最佳 | 结算只有一行"游戏结束" |
|
||||
| P4 | L2 | 卡壳兜底 | 卡住 ≥8–12s 有软提示(高亮/排除/线索重播),卡壳不出局不清零 | 10s 无正确操作,候选格开始脉动提示 | 卡住只能干等到超时判负 |
|
||||
| P5 | L4 | 成绩可炫耀 | 结算展示可比较成绩(用时/连击/星级/称号,配最佳纪录),不是打完就黑屏 | 结算面板:分数+最高连击+3 星+历史最佳+称号 | 结算只有一行"游戏结束" |
|
||||
|
||||
> 通用 8 条命中越多越好玩;品类 5 条对齐质量模型的档位观测线(便宜档批次:L2 组均分 ≥60%、L3 ≥2/3、L4 ≥1/2,消费于品类小批验收、不拦单款)。**设计阶段就过这两张表,别等做出来才发现无趣。**
|
||||
>
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: runtime-and-multichannel
|
||||
description: "当开发/调试 runtime 编译与包版本化交付、WanxiangGameSDK 注入与降级、iframe 沙箱三容器预加载、或微信/抖音/快手多渠道导出时使用:渲染层 LittleJS 增强发行版、SDK 两层、沙箱安全边界与微信格式导出枢纽。"
|
||||
---
|
||||
|
||||
# 运行时、Game SDK 与多渠道导出手册（runtime-and-multichannel）
|
||||
|
||||
> 蒸馏来源：`docs/architecture/架构/README.md`（§3.4 Game SDK / §4.2 运行时三容器 / §6.6 运行时与导出选型）、`docs/architecture/架构/13模块.md`（runtime 模块 T-RT-* 技术功能）、`docs/architecture/架构/README.md`（§2 模块地图 / §10.4 LayaAir CLI）。
|
||||
@ -8,16 +13,17 @@
|
||||
> - **模板 = LittleJS 能力插件/二次开发件**（玩法模板层废除）；粒子/物理/后处理三插件=引擎能力包装层（裁决①2026-06-12），collision/手感=引擎缺件维持自研。
|
||||
> - **沙箱 / SDK Core 注入 / 三容器预加载 / 多渠道导出枢纽**章节不受影响，仍现行有效。
|
||||
> 单一事实源：[`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1 + `git show 6d2f8789^:docs/agent-specs/_archive/2026-06-11-T1引擎终裁包.md`（已随 _archive 清理删除、git 定位）。下文凡「自研 Canvas<15KB / OpenGame 生成」字样均按本横幅改读。
|
||||
> **⚠️ 纠偏（2026-07-05）**：① 编译输入口径改真——runtime 编译输入 = 上游 **src/ 多文件源工程**，产出 **engineBundle（iife、全局 `__GameBundle` 承重）**；`gameConfig` 降为模板玩法参数占位（`contracts/game-package.schema.json` 可核）。② runtime service 真目录 = `service/build/` `service/pkg/` `service/session/`（旧稿 `service/compiler/`、`service/package/` 已不存在）。③ §6 多渠道代码件系（`service/conversion/`、`WechatAdapter`/`DouyinAdapter`/`KuaishouAdapter.java`）**规划中·未实现**——全仓无此源文件，微信格式枢纽策略叙述仍有效。
|
||||
|
||||
---
|
||||
|
||||
## 目标
|
||||
|
||||
把 GameConfig 编译为**可运行 Web 包**并版本化交付，注入 WanxiangGameSDK，在 iframe 沙箱中安全运行（三容器预加载），并支持向微信/抖音/快手等小游戏渠道**静态导出**。**产出后游戏流可即点即玩、可分发到外部渠道。**
|
||||
把上游 **src/ 多文件源工程**编译为**可运行 Web 包**（engineBundle iife 承重、gameConfig 降为模板玩法参数占位）并版本化交付，注入 WanxiangGameSDK，在 iframe 沙箱中安全运行（三容器预加载），并支持向微信/抖音/快手等小游戏渠道**静态导出**。**产出后游戏流可即点即玩、可分发到外部渠道。**
|
||||
|
||||
## 前置
|
||||
|
||||
- OSS（本地 MinIO）+ CDN 可用。Tier2/3 用 Cocos 官方一键导出微信包；Tier1（~~自研 Canvas~~ → **LittleJS**）渠道 adapter 走 W-CH-α 对比竞标（LittleJS+自研 adapter vs Cocos 导出，HJ-CH-001）（见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1）。
|
||||
- OSS（本地 MinIO）+ CDN 可用。Cocos（仅留 3D / 渠道导出、人在环、非分档轴）官方一键导出微信包；LittleJS 线（~~自研 Canvas~~）渠道 adapter 走 W-CH-α 对比竞标（LittleJS+自研 adapter vs Cocos 导出，HJ-CH-001）（见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1）。
|
||||
- SDK Core 体积达标（< 8KB 压缩）；上游 aigc 产出的 GamePackage 符合 `game-package.schema.json` 契约。
|
||||
|
||||
---
|
||||
@ -26,11 +32,11 @@
|
||||
|
||||
| 职责 | 说明 |
|
||||
|---|---|
|
||||
| GameConfig → 可运行 Web 包编译 | `service/compiler/`：config + logic + assets → web bundle |
|
||||
| src/ 源工程 → 可运行 Web 包编译 | `service/build/`：src/ 源工程 + assets → engineBundle（iife 承重）web bundle |
|
||||
| Manifest 生成 | runtimeVersion / configUrl / assetList / hash / preloadPolicy / bundleSize |
|
||||
| 包存储版本化 | `service/package/`：checksum(sha256) + CDN，路径 `/games/{gameId}/versions/{versionId}/` |
|
||||
| 预览交付端点 | `controller/app/`：按版本返回 manifest + 资源 URL（`GET /app/runtime/preview/:versionId`） |
|
||||
| 多渠道转换 | `service/conversion/`：导出微信小游戏格式包为枢纽 → 抖音(自有接口)/快手(微信格式兼容转换)；Tier2/3 用 Cocos 官方导出、Tier1 渠道 adapter 走 W-CH-α 竞标（见顶部横幅） |
|
||||
| 包存储版本化 | `service/pkg/`：checksum(sha256) + CDN，路径 `/games/{gameId}/versions/{versionId}/` |
|
||||
| 预览交付端点 | `controller/app/runtime/`：按版本返回 manifest + 资源 URL（真路径 `GET /app-api/runtime/package/{versionId}?scene=preview`；预览为 `scene` 参数、无独立 `/preview` 路径） |
|
||||
| 多渠道转换 | `service/conversion/`（**规划中·未实现**）：以导出微信小游戏格式包为枢纽 → 抖音(自有接口)/快手(微信格式兼容转换)；渠道 adapter 走 W-CH-α 竞标（Cocos 仅留 3D / 渠道导出、人在环，见 §6 与顶部横幅） |
|
||||
|
||||
渲染层：~~**自研轻量 Canvas Runtime（< 15KB）**~~ → **LittleJS 增强发行版 + Runner v2**（2026-06-12 终裁，见顶部横幅；15KB 红线废除），iframe sandbox + SDK Core 注入，平台完全控制沙箱（沙箱/SDK 注入语义不变；技术决策版 §6.6 的"自研薄壳"结论已被引擎选型取代）。
|
||||
|
||||
@ -98,7 +104,7 @@ SDK ↔ 宿主 postMessage 协议（消息 `type`）：`init` / `lifecycle` / `t
|
||||
```
|
||||
runtime 编译 GamePackage 时：
|
||||
1. 把 SDK Core 代码内联进游戏 entry.js 头部
|
||||
2. GameConfig 声明所需 Plugin（ad / pay / social / storage）
|
||||
2. 源工程声明所需 Plugin（ad / pay / social / storage）；gameConfig 降为模板玩法参数占位
|
||||
3. manifest.json 记录 SDK 版本号
|
||||
4. 宿主据 manifest 决定加载哪些 Plugin chunk
|
||||
```
|
||||
@ -121,12 +127,12 @@ runtime 编译 GamePackage 时：
|
||||
|
||||
> **快手导出渠道清单不含 LayaAir CLI 路线**：LayaAir 官方平台清单无快手，快手统一走"微信格式包兼容转换"。"统一工具链"实质 = 统一产出微信格式包，再分发抖音/快手。详见 [`../knowledge/tech-decisions.md`](../knowledge/tech-decisions.md) §1.1。
|
||||
|
||||
**导出工具**：Tier2/3 用 **Cocos 官方一键**导出微信包，Tier1（~~自研 Canvas~~ → **LittleJS**）渠道 adapter 走 W-CH-α 竞标（见顶部横幅）。Java（runtime `service/conversion/`）统一以 `ProcessBuilder` 调用对应工具 → 异步等待进程 → 产物上传 OSS。
|
||||
**导出工具**：**Cocos（仅留 3D / 渠道导出、人在环）官方一键**导出微信包，LittleJS 线（~~自研 Canvas~~）渠道 adapter 走 W-CH-α 竞标（见顶部横幅）。Java（runtime `service/conversion/`，**规划中·未实现**）设计上统一以 `ProcessBuilder` 调用对应工具 → 异步等待进程 → 产物上传 OSS。
|
||||
|
||||
渠道适配器（开发团队版 §2.1）各自处理**尺寸 / 资质 / 文案 / 违禁词**：
|
||||
- `WechatAdapter.java` — 微信小游戏适配规则
|
||||
- `DouyinAdapter.java` — 抖音小游戏适配规则
|
||||
- `KuaishouAdapter.java` — 快手适配（微信格式 → 快手兼容转换）
|
||||
渠道适配器（**规划中·未实现**；开发团队版 §2.1 设计，下列 Java 文件全仓尚不存在）各自处理**尺寸 / 资质 / 文案 / 违禁词**：
|
||||
- `WechatAdapter.java`（规划中） — 微信小游戏适配规则
|
||||
- `DouyinAdapter.java`（规划中） — 抖音小游戏适配规则
|
||||
- `KuaishouAdapter.java`（规划中） — 快手适配（微信格式 → 快手兼容转换）
|
||||
|
||||
> 外部进程调用要按 [`../rules/security-and-reliability.md`](../rules/security-and-reliability.md) 处理超时/失败/重试/产物校验。
|
||||
|
||||
|
||||
@ -1,13 +1,18 @@
|
||||
---
|
||||
name: saa-graph-orchestration
|
||||
description: "远期备查:SAA 图编排已降最低优先级、非生成主线(生成已统一 AgentScope)。仅当给 SAA 适配器布线或做远期「框架可换」可插拔验证时照本备查——依赖集/new-api baseUrl 剥 /v1/checkpoint saved_at 三承重坑;切勿据它起新生成主线。"
|
||||
---
|
||||
|
||||
# SAA 图编排 playbook（远期适配备查 · HJ-AGI-002）
|
||||
|
||||
> **status：远期备查（SAA 降最低优先级）。** 生成框架已于 2026-06-25 统一收敛 **AgentScope**（三档按 AI 参与深度分），**SAA（Spring AI Alibaba v1.1.2.2）不再是生成主线**，只留作远期「框架可换」的可插拔适配验证目标。既有 SAA 图代码仍在 `game-cloud/game-module-aigc-server/.../saa/`（`SaaStudioGraph.java` 是唯一布线源、`SaaGraphDispatcher.java` 做生产派发）。给 SAA 适配器布线或做远期「框架可换」验证时照本备查；**不要按它起新的生成主线**。
|
||||
> **status：远期备查（SAA 降最低优先级）。** 生成框架已于 2026-06-25 统一收敛 **AgentScope**（三档按 AI 参与深度分），**SAA（Spring AI Alibaba v1.1.2.2）不再是生成主线**，只留作远期「框架可换」的可插拔适配验证目标。既有 SAA 图代码仍在 `game-cloud/game-module-aigc/game-module-aigc-server/.../saa/`（`SaaStudioGraph.java` 是唯一布线源；`SaaGraphDispatcher.java` 类仍在，但仅 `aigc.executor.dispatcher=saa` opt-in 时才派发、非现行主线——现行生成主派发 = `service/executor/GenerationDispatcher`〔默认 `dispatcher=http`〕经 worker 线投递到 Python worker）。给 SAA 适配器布线或做远期「框架可换」验证时照本备查；**不要按它起新的生成主线**。
|
||||
> 迁移设计（9 步计划/拓扑/坑）见 `git show 6d2f8789^:docs/agent-specs/_archive/2026-06-15-python-to-SAA-migration-design.md`（已随 _archive 清理删除、git 定位）；SAA 能力/API dossier 与编排图说已收敛进 SoT 后删除，见 `git show ce7a4850^:docs/architecture/架构/生成引擎/SAA编排.md`。全量坑与决策见记忆 `saa-agentic-infra-decision`。
|
||||
|
||||
---
|
||||
|
||||
## 保留的承重坑与要点（远期布线仍会撞）
|
||||
|
||||
- **依赖集（最小证成集，别贪"完整推荐集"）**：`game-module-aigc-server/pom.xml` 引 **3 个 BOM**（`spring-ai-bom:1.1.2` / `spring-ai-alibaba-bom:1.1.2.2` / `spring-ai-alibaba-extensions-bom:1.1.2.2`，仅管版本、不引 spring-boot-dependencies）+ **3 个直接依赖**（`spring-ai-alibaba-graph-core`〔图引擎 + `MysqlSaver` + observation 机芯全在此〕/ `spring-ai-alibaba-starter-graph-observation`〔仅 Boot 自动配置层〕/ `spring-ai-starter-model-openai`〔接 new-api〕）。**别引** `agent-framework`（ReactAgent/asNode，与「done 由九门确定性门定、不让 LLM 自评」冲突）、`builtin-nodes`（脱 BOM 钉死 1.1.2.2、拖 tika 全家桶）、SAA 的 Boot BOM（让项目 3.5.14 胜，同 minor 补丁前向兼容）、`RedisSaver`（避 Redisson 3.22↔4.4 冲突）。**铁律**：动 pom 删依赖前先 `dependency:tree` / 读 jar 核类的模块归属（`MysqlSaver`、`GraphObservationLifecycleListener` 都在 `graph-core`）。
|
||||
- **依赖集（最小证成集，别贪"完整推荐集"）**：`game-module-aigc/game-module-aigc-server/pom.xml` 引 **3 个 BOM**（`spring-ai-bom:1.1.2` / `spring-ai-alibaba-bom:1.1.2.2` / `spring-ai-alibaba-extensions-bom:1.1.2.2`，仅管版本、不引 spring-boot-dependencies）+ **3 个直接依赖**（`spring-ai-alibaba-graph-core`〔图引擎 + `MysqlSaver` + observation 机芯全在此〕/ `spring-ai-alibaba-starter-graph-observation`〔仅 Boot 自动配置层〕/ `spring-ai-starter-model-openai`〔接 new-api〕）。**别引** `agent-framework`（ReactAgent/asNode，与「done 由九门确定性门定、不让 LLM 自评」冲突）、`builtin-nodes`（脱 BOM 钉死 1.1.2.2、拖 tika 全家桶）、SAA 的 Boot BOM（让项目 3.5.14 胜，同 minor 补丁前向兼容）、`RedisSaver`（避 Redisson 3.22↔4.4 冲突）。**铁律**：动 pom 删依赖前先 `dependency:tree` / 读 jar 核类的模块归属（`MysqlSaver`、`GraphObservationLifecycleListener` 都在 `graph-core`）。
|
||||
|
||||
- **接 new-api：baseUrl 剥 `/v1` 坑**：Spring AI 自拼 `completionsPath=/v1/chat/completions`，故 `OpenAiApi.baseUrl` 必须是 **host 根、不带 `/v1`**（`http://100.64.0.8:3000`）；`.env` 的 `NEWAPI_BASE_URL` 常带 `/v1`，两侧通用须 Java 侧 `stripV1Suffix` 剥之，否则 404 `/v1/v1/...`。五角色（design/code/fix/player_text/player_vision）共用一个 `OpenAiApi`、仅 `defaultOptions.model/temperature` 异；全走 new-api 单一 key，自动入 `newapi_cost`（logs.quota）计费平面。
|
||||
|
||||
|
||||
@ -1,10 +1,15 @@
|
||||
---
|
||||
name: sim-business-game-design
|
||||
description: "当为经营模拟/放置养成类 brief 产设计阶段玩法方案或评审经营类设计时使用:6 心理引擎、可达范式与决策模式清单、客流/经济数值锚、输出配方、可达性红线、反无趣自检;品类 rubric 单源指 fixture,金标锚点在册。"
|
||||
---
|
||||
|
||||
# skill: sim-business-game-design —— 经营模拟小游戏「玩法设计」作业手册(给生成 agent 的设计阶段)
|
||||
|
||||
> 定位:这是 **生成 agent 设计阶段（AgentScope）造"好玩的经营模拟玩法设计"的唯一作业手册**。它回答 **"设计什么才好玩"**(玩法/机制/进度/数值/美术/音/UI 范式),与 [`littlejs-game-dev.md`](littlejs-game-dev.md)(回答"代码怎么写")配对:**设计阶段产玩法概念 → 代码生成阶段照 littlejs-game-dev 产代码**。
|
||||
>
|
||||
> **铁律(创始人 2026-06-21)**:"好玩 = 上游设计层职责",不在 runtime/插件。插件只让设计**能被 juice 出手感**;**这份 skill 负责让设计本身好玩**。
|
||||
>
|
||||
> **可达性边界**:产出必须落得到 A-model 轻量运行时——**LittleJS 2D 手机竖屏(390×844)、单/少场景、便宜模型可生成的多文件代码、12 插件能力域**。设计再好,落不到这个运行时就是空想——见 §9 红线。
|
||||
> **可达性边界**:产出必须落得到 A-model 轻量运行时——**LittleJS 2D 手机竖屏(390×844)、单/少场景、便宜模型可生成的多文件代码、11 注入插件能力域**。设计再好,落不到这个运行时就是空想——见 §9 红线。
|
||||
>
|
||||
> **证据基**:范式蒸馏自近年微信/抖音「放置经营 / 模拟经营 / 模拟养成」品类的成熟模式(训练知识,非实时榜单);范式稳定可用,具体举例供参照。
|
||||
|
||||
@ -47,6 +52,8 @@
|
||||
- **风险收益**:囤货等大单 vs 现金落袋(稀有客给大单但占双倍时长)——贪多可能砸手里。
|
||||
每种都能填 ⑨ 判定句「玩家在＿＿时要判断＿＿,判错则＿＿」;填不出=退回重选模式。cheap 主 prompt(v1.6.0)的经营路由即指到本清单。
|
||||
|
||||
> 注:SoT §4 已将 prompt 自检第 ⑨ 条升为评分尺第 12 条,本清单编号不变。
|
||||
|
||||
---
|
||||
|
||||
## 2. 关卡 / 进度 / 留存设计
|
||||
@ -142,7 +149,7 @@
|
||||
- ❌ 复杂经济(多资源链/市场波动)→ 双货币 + 简单成长曲线。
|
||||
- ❌ 超过 2 个主机制 → 便宜模型 + 单屏扛不住,聚焦 1 主 + 1 成长轴。
|
||||
- ❌ **核心成单/得分动作做成「先选 A 再选 B」两步**(如"点顾客锁定→再点货架商品"):零-LLM 自动验收 driver 只会单击 `occupied:true` 目标、跟不动两步 → 九门 H 验不到进展 = **好游戏被误判** → ✅ **核心动作单击即成单**(点等待中的顾客 = 自动按库存售卖收钱,casual 友好 + driver 可达);**深度靠进货/库存/解锁/节奏,不靠两步匹配**。若确需多步,则 `_forensicsView().state().targets` 必须**随状态把"下一步该点的"标 occupied:true**(选中顾客后,把该卖的货架商品标 occupied),让 driver 跟着两步推进。
|
||||
- ✅ 留下的:放置产出、合成升级、点击经营、阶段解锁、收集、轻决策、数值滚雪球 —— 全在 12 插件 + 单屏 + 便宜模型可生成范围内。
|
||||
- ✅ 留下的:放置产出、合成升级、点击经营、阶段解锁、收集、轻决策、数值滚雪球 —— 全在 11 注入插件 + 单屏 + 便宜模型可生成范围内。
|
||||
|
||||
---
|
||||
|
||||
@ -159,7 +166,7 @@
|
||||
|
||||
> 8 条命中越多越好玩;命中 ≤3 条 ≈ catch-fruit 那种"能玩但无趣"。**设计阶段就过这张表,别等做出来才发现无趣。**
|
||||
|
||||
> **机检硬门 vs LLM 评分维度(质量轨 2026-07-02 分界裁定)**:这 8 条里原标「4 条可机检」并不同质,`docs/architecture/架构/生成引擎/游戏质量与爆火能力.md` §3.3 拆成两类——纯代码存在性的三条降为 LLM 评分维度(rubric,非阻塞),经真玩校验的断言留作 L1 硬门(机器判定、可拒发):
|
||||
> **机检硬门 vs LLM 评分维度(质量轨 2026-07-02 分界裁定)**:这 8 条里原标「4 条可机检」并不同质,`docs/architecture/架构/生成引擎/游戏质量与爆火能力.md` §3/§4 拆成两类——纯代码存在性的三条降为 LLM 评分维度(rubric,非阻塞),经真玩校验的断言留作 L1 硬门(机器判定、可拒发):
|
||||
> - **①即时反馈**(主操作真调 `particles-juice` 飘字/粒子 + `audioMusic` 音效)、**③下一个解锁**(解锁逻辑 + 阈值常量)、**⑧音反馈**(真调 `audioMusic.playSfx` 或引擎 zzfx):代码里存在调用不等于体验真成立,故交 LLM 验证 agent 评分,不落项目代码、不进九门;
|
||||
> - **②可见成长** = `score`/营收随操作上升,经 H 门 `assertAfterPlay {path:score,op:increased}` 校验,属 L1 机制可玩,保留为阻塞硬断言、不软化;
|
||||
> - **经营/进货品类**再加一条 per-game 运行时断言:买/进货时货币真减 → gatespec 产 `{path:"currency",op:"decreased"}`,同经 H 门 assertAfterPlay 校验,同属 L1 硬断言(**注:通用九门不加品类语义,断言是每局喂的**)。
|
||||
@ -183,6 +190,6 @@
|
||||
|
||||
## 相关
|
||||
|
||||
- 代码层实现 → [`littlejs-game-dev.md`](littlejs-game-dev.md)(12 插件 API / 结构 / 资产-mmx / 工厂契约)
|
||||
- 代码层实现 → [`littlejs-game-dev.md`](littlejs-game-dev.md)(11 注入插件 API / 结构 / 资产-mmx / 工厂契约)
|
||||
- 便宜模型生成 worker / 九门 → [`cheap-model-game-generation.md`](cheap-model-game-generation.md)
|
||||
- 生成 agent 设计阶段接入 → 现行生成主线 = AgentScope 三档统一收敛（SAA 降最低优先级、留作远期适配验证，code 在 `game-cloud/.../saa/`；A-model 改写见 `git show 8ea97234:docs/agent-specs/2026-06-21-saa-amodel-rewrite-review.md`）
|
||||
|
||||
@ -1,6 +1,11 @@
|
||||
---
|
||||
name: staging-ops
|
||||
description: "在 mini-desktop/mini-infra 上做 staging 或内测 dev 的部署运维时使用:机器分工铁律、代码同步(git push→Gitea clone)、后端重部署标准序、构建门/冒烟门、观测栈起容器、生成线环境地图与 executor 接线的实战配方与踩坑。"
|
||||
---
|
||||
|
||||
# staging 运维配方（机器分工 / 代码同步 / 重部署 / 构建门 / 冒烟）
|
||||
|
||||
> staging 全栈在 **mini-desktop（100.64.0.7）**：huijing 单体 :48080 + game-studio :4173 + game-admin :4174 + 隔离 MySQL/Redis 容器；共享基建（Gitea/MySQL/Redis/MinIO/new-api）在 **mini-infra（100.64.0.8）**。
|
||||
> staging 全栈在 **mini-desktop（100.64.0.7）**：huijing 单体 :48080 + game-studio :4173 + game-admin :4174 + 隔离 MySQL/Redis 容器；共享基建（Gitea/MySQL/Redis/MinIO/new-api/Nacos/RocketMQ/观测栈五件 Collector/Tempo/Prometheus/Grafana/Loki）在 **mini-infra（100.64.0.8）**。
|
||||
> 本配方由 2026-06-09~11 多波实战蒸馏（M1 真跑 / 黄金闭环 / UI 走查 / Wave4 集成门）；红线类条目同步收录于 [`../rules/engineering-conventions.md`](../rules/engineering-conventions.md)。真 UI 走查另见 [`ui-walkthrough-cdp.md`](./ui-walkthrough-cdp.md)。
|
||||
|
||||
## 1. 机器分工铁律（四机）
|
||||
@ -8,7 +13,7 @@
|
||||
- **创始人本地工作站 → lili-mac**（M1 Pro / 32G / ARM；**不入 Tailscale 调度**，会休眠合盖）：跑 Claude Code 主会话、本地全栈 dev、本地浏览器/CDP **快走查**、`mvn`/`npm` 快构建迭代。**两条边界**：① ARM≠x86,Mac 产出的 JAR/前端 bundle 架构中立可用,但 **Docker 镜像 + smoke 门必须在 mini-desktop x86 出**（否则镜像架构错、与 prod 不同构=半假门）；② Mac 上 CDP 只算"快走查"加速开发,**e2e 验收门仍只认 mini-desktop 结果**（服务+浏览器同机 localhost,见 [`game-e2e-cdp-harness.md`](./game-e2e-cdp-harness.md)）。
|
||||
- **权威验收 / 重型构建 / 测试 / staging app / 浏览器 e2e 门 → mini-desktop**（15G；java17 + mvn3.8.7 + docker + node22 + chrome146；与 prod 同构）。
|
||||
- **常驻无人值守 → 6c6g**：常开的 agent 编排/Workflow、cron 定时、后台批跑、git 操作（Mac 会休眠故常驻活只能留此）。**禁跑重活**：重型前端构建 OOM、chrome 连续 exit 144。**元规则：同一失败签名第二次出现 → 换机器,不再换启动姿势。**
|
||||
- **共享基建 → mini-infra**（绝不在其上跑项目 app / 重型构建；缺 RocketMQ+Nacos，MVP 未部署）。
|
||||
- **共享基建 → mini-infra**（绝不在其上跑项目 app / 重型构建；Nacos/RocketMQ 已自托管部署，2026-07-01）。
|
||||
|
||||
## 2. 代码同步（分类器约束）
|
||||
|
||||
|
||||
@ -39,7 +39,7 @@ tier2 富游戏线把"本地 CLI 直驱裸 Agent"(`worker/agent_loop/studio.py`
|
||||
|
||||
4. **BYPASS 权限**(建 session 后):tier2 九工具的 `FunctionTool` 默认 `check_permissions` 返回 `ASK`,服务态无人确认。不设 BYPASS,agent 第一次调工具就进 `ToolCallState.ASKING`、等一个永不来的确认事件,chat run 抛 `Agent is waiting for N tool calls ... but received no event`,生成零产出。修法:`PATCH /sessions/{id}?agent_id=<id>` 体 `{permission_mode: "bypass"}`(`PermissionMode.BYPASS` 值是 `"bypass"`)。注意 **PATCH 与 SSE stream 一样要 query 参数 `agent_id`**,不带返 422。等价 CLI `studio.py` 的 `_bypass_state()`。
|
||||
|
||||
5. **设计阶段接进服务路径**(建 agent 前):CLI 线 `run_studio` 先跑工作室设计阶段产出 design_text 再写,服务路径此前整段跳过、writer 拿空 design。修法:bootstrap 在建 agent 前于控制面进程内(有 agentscope + 模型)复用 `studio._design_stage`(工作室星形多 agent 团队 + 失败 degrade 回单 agent)产出 design_text,喂进 `AgentRecord.system_prompt`(`roles.writer_system` 第二参)。best-effort:设计失败返空串、不阻断生成。设计团队默认 240s 超时偏短、常 degrade 回单 agent——仍产出 design_text 可用,要让全团队跑完就调 `generation.yaml` 的 `design_team.timeout_s`(配置外置已兑现)。
|
||||
5. **设计阶段接进服务路径**(建 agent 前):CLI 线 `run_studio` 先跑工作室设计阶段产出 design_text 再写,服务路径此前整段跳过、writer 拿空 design。修法:bootstrap 在建 agent 前于控制面进程内(有 agentscope + 模型)复用 `studio._design_stage`(工作室星形多 agent 团队 + 失败 degrade 回单 agent)产出 design_text,喂进 `AgentRecord.system_prompt`(`roles.writer_system` 第二参)。best-effort:设计失败返空串、不阻断生成。设计团队墙钟超时现为 420s(2026-07-04 由 240s 上调);240s 时代偏短、常 degrade 回单 agent,上调 420 后已缓解——即便 degrade 仍产出 design_text 可用。要调超时改 `tier2/config/generation.yaml` 的 `design_team.timeout_s`(配置外置已兑现)。
|
||||
|
||||
6. **SSE 等待必须有界**(控制面消费 SSE):`create_app` 的 chat 是每回合一次、fire-and-forget,控制面订阅 `GET /sessions/{id}/stream?agent_id=<id>` 读到本回合的 `REPLY_END` / `EXCEED_MAX_ITERS` 才算这轮跑完。**坑**:超时检查不能只写在 `async for line` 的循环体内——SSE 流完全静默时(如服务端 Redis 超时打断了事件发布,既无 data 也无心跳)`aiter_lines` 永久 await,没 line 进来超时检查永不触发,控制面无限挂(实测卡死 60min)。修法:httpx `Timeout(read=idle_timeout_s)`,静默超它即 `ReadTimeout` → 兜住 → 据 on-disk 评门继续。`idle_timeout_s=300s` 远大于 agent 内部 run_gates(chrome ~60s)的正常静默间隙,不误杀正常回合。
|
||||
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: trpg-game-design
|
||||
description: "当为掷骰冒险(TRPG)类 brief 产设计阶段玩法方案或评审时使用:掷骰悬念等 6 引擎、爬塔/事件链可达范式、成功率与升级数值锚、单击即结算红线、通用 12 条+品类 5 条自检、金标锚点与底线四件映射。"
|
||||
---
|
||||
|
||||
# skill: trpg-game-design —— TRPG(掷骰冒险)小游戏「玩法设计」作业手册(给生成 agent 的设计阶段)
|
||||
|
||||
> 定位:这是 **生成 agent 设计阶段造"好玩的掷骰冒险玩法设计"的唯一作业手册**。它回答 **"设计什么才好玩"**(掷骰判定/冒险结构/成长/数值/美术/音/UI 范式),与 [`littlejs-game-dev.md`](littlejs-game-dev.md)(回答"代码怎么写")配对:**设计阶段产玩法概念 → 代码生成阶段照 littlejs-game-dev 产代码**。体例照 [`sim-business-game-design.md`](sim-business-game-design.md)(经营品类范例)。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: ui-walkthrough-cdp
|
||||
description: "用户可见波次收口前在 mini-desktop 用 CDP 做真 UI 走查(studio 创作/试玩/发布、admin 审核台)时使用:逮编排器旁路掩盖的真后端缺陷,含 CDP 七坑、免登录 localStorage 注入只读走查、真实访问 origin 取证红线。"
|
||||
---
|
||||
|
||||
# 真 UI 走查配方（CDP on mini-desktop）
|
||||
|
||||
> **为什么必须真 UI 走查**：编排器/批跑/curl 全绿 ≠ 真人 UI 能用。编排器旁路曾掩盖 2 个真后端发布缺陷（`currentVersionId` 生成后未回写 / `getZones` 空桩），**真 UI 走查是逮这类缺陷的唯一手段**（HJ-FE-WALK-001）。链路①（创作→生成→预览）与链路②（发布→审核→入 feed）均用本配方闭合。
|
||||
@ -26,6 +31,7 @@
|
||||
- 入口 `:4173`；受控 textarea 填值 = **原型 setter + dispatch input 事件**（触发 Vue v-model，直接赋值无效）；
|
||||
- 点按钮用精确文案匹配防子串误中（`includes('满意')` 会误中「不满意,重做」）；
|
||||
- 截图 `cat` 管道拉回本地用 Read 查看；游戏试玩复用 `player_cdp.play()`（批跑必须 `continue_on_demo=False`）。
|
||||
> 这批脚本（`player_cdp.py`/`admin_walk.py` 等）随 orchestrator/ 目录删除，仅存 git（取回：`git show 6d2f8789^:orchestrator/<脚本名>` 落盘后用）；游戏画布试玩取证现行改用在树的 `game-runtime/games/_wg1-gen/_shared/play.cdp.cjs`（见 [`game-e2e-cdp-harness.md`](./game-e2e-cdp-harness.md)）。
|
||||
- **localStorage 注入 token 过 `requiresAuth` 走查（免登录直达受保护页只读走查）——2026-06-16 Lane E G0 实证**：只想**只读核实**一个 `meta.requiresAuth` 的页面（如创作页），不必走完整登录表单。先后端拿一枚有效 token（如免短信登录端点 / `test1` token），再用 CDP 在**目标 origin 下**注入 localStorage 后再导航：
|
||||
```python
|
||||
evaljs("localStorage.setItem('ACCESS_TOKEN', '<token>')") # key 名以前端约定为准(查 utils/auth);有的还需 refreshToken/tenantId
|
||||
@ -43,3 +49,4 @@
|
||||
## 5. 信道探针（回归排查常备）
|
||||
|
||||
宿主↔iframe postMessage 断裂用 `probe_bridge_channel.py` 取证：四锚点 + 判别实验（文档代际/iframe 重建监视/存活代理注入），v-for ref 数组案（host→game 全断）即由它锁凶。修复类波次收口前跑一轮防回归。
|
||||
> 这批脚本（`probe_bridge_channel.py` 等）随 orchestrator/ 目录删除，仅存 git（取回：`git show 6d2f8789^:orchestrator/<脚本名>` 落盘后用）；游戏画布试玩取证现行改用在树的 `game-runtime/games/_wg1-gen/_shared/play.cdp.cjs`（见 [`game-e2e-cdp-harness.md`](./game-e2e-cdp-harness.md)）。
|
||||
|
||||
@ -1,3 +1,8 @@
|
||||
---
|
||||
name: wave-close-checklist
|
||||
description: "当波次收口、里程碑状态变化或裁定类提交(拍板/闸门判定/口径变更)时使用:按序执行总账→作战清单→回填→.agent→蒸馏→索引→编排入库→治理门的八步收口清单,收口铁律唯一可执行入口。"
|
||||
---
|
||||
|
||||
# 波次收口检查单（wave-close checklist）
|
||||
|
||||
> **收口动作的唯一可执行清单**。总账铁律、作战清单回填铁律、`.agents/README.md` 维护规则、协议 §6 均指向本单——收口流程变更只改这里，不再四处散写。
|
||||
|
||||
@ -76,6 +76,10 @@ flowchart TD
|
||||
| 评估是否引入 ClickHouse | 分析 | 全流程 | 第一性原理 + 评审版 spec，结论先行 |
|
||||
| 审查一个支付回调 PR | 评审 | —— | 按严重度列问题；重点幂等/状态机/乐观锁 |
|
||||
|
||||
### 2.3 agentic 设计/评审任务的强制过尺（2026-07-05，创始人拍定）
|
||||
|
||||
凡设计或评审生成运行时的 **agent 席位划分、context 装配、prompt 结构、工具面、多 agent 协作、goal-loop 自治交付、创作者交互面**，必须按 [`../skills/agentic-seat-context-design.md`](../skills/agentic-seat-context-design.md) §8 检查单过尺：设席八问 / 注入五查 / 场景四要素 / "规范进 prompt"先问模板与门。评审此类设计档时，把该检查单当评审尺逐条对；设计档内〔提案〕机制落地前须逐条验证可行性（该 skill 是需求基线，不是架构 SoT）。**全新 agentic 子系统首次设计前，若尚无需求基线，先按该 skill §10 探针方法跑一轮第一人称需求探针产基线再设计**（2026-07-06 立 W-PROBE；默认建议、升强制与否待创始人拍；探针对象排期唯一登记处 = 作战清单 W-PROBE 单）。
|
||||
|
||||
---
|
||||
|
||||
## 3. 证据规则
|
||||
|
||||
8
.claude/skills/agentic-seat-context-design/SKILL.md
Normal file
8
.claude/skills/agentic-seat-context-design/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: agentic-seat-context-design
|
||||
description: 设计或评审生成运行时的 agent 席位划分、context 装配、prompt 结构、工具面、多 agent 协作、goal-loop 自治交付、创作者交互面时使用——需求基线 + 设计检查单(设席八问/注入五查/场景四要素)+ 第一人称需求探针方法(§10);非架构 SoT。
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/agentic-seat-context-design.md` 并照其执行**;评审 agentic 设计时按其 §8 检查单过尺(`ai-development-protocol.md` §2.3 强制)。
|
||||
8
.claude/skills/execution-plan-slicing/SKILL.md
Normal file
8
.claude/skills/execution-plan-slicing/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: execution-plan-slicing
|
||||
description: "当写或评审多单元执行 plan、或感到「每到下阶段前面阶段的工作都要返工」时使用:辨别横切关注面 vs 纵切成果切片、诊断返工信号、原地换轴重组、「设计 HOW 移交/执行契约必留」判据,及换轴必查七坑。"
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/execution-plan-slicing.md` 并照其执行。**
|
||||
8
.claude/skills/feature-design-doc/SKILL.md
Normal file
8
.claude/skills/feature-design-doc/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: feature-design-doc
|
||||
description: "当新功能/跨模块/改用户可见行为/触及外部服务·支付·数据进入设计阶段时使用:产出 WHAT+HOW 合一的功能设计文档——文字+Mermaid 为事实源、SVG/HTML 给人看,含第 0 步 SoT 注册表查证、sot-impact/上级申报、防漂移单源与文档骨架。"
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/feature-design-doc.md` 并照其执行。**
|
||||
8
.claude/skills/game-e2e-cdp-harness/SKILL.md
Normal file
8
.claude/skills/game-e2e-cdp-harness/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: game-e2e-cdp-harness
|
||||
description: "为插件库/生成游戏做真浏览器输入级 e2e(触摸轨迹→九门判真玩→四件套证据)时使用:play.cdp.cjs 九门(装载/掌帧/真渲染/接线/输入因果/latch/手感)+ 假绿守卫 + driver 库 + 首局体验门,mini-desktop 上跑,区别于 DOM 走查。"
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/game-e2e-cdp-harness.md` 并照其执行。**
|
||||
8
.claude/skills/staging-ops/SKILL.md
Normal file
8
.claude/skills/staging-ops/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: staging-ops
|
||||
description: "在 mini-desktop/mini-infra 上做 staging 或内测 dev 的部署运维时使用:机器分工铁律、代码同步(git push→Gitea clone)、后端重部署标准序、构建门/冒烟门、观测栈起容器、生成线环境地图与 executor 接线的实战配方与踩坑。"
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/staging-ops.md` 并照其执行。**
|
||||
8
.claude/skills/ui-walkthrough-cdp/SKILL.md
Normal file
8
.claude/skills/ui-walkthrough-cdp/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: ui-walkthrough-cdp
|
||||
description: "用户可见波次收口前在 mini-desktop 用 CDP 做真 UI 走查(studio 创作/试玩/发布、admin 审核台)时使用:逮编排器旁路掩盖的真后端缺陷,含 CDP 七坑、免登录 localStorage 注入只读走查、真实访问 origin 取证红线。"
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/ui-walkthrough-cdp.md` 并照其执行。**
|
||||
8
.claude/skills/wave-close-checklist/SKILL.md
Normal file
8
.claude/skills/wave-close-checklist/SKILL.md
Normal file
@ -0,0 +1,8 @@
|
||||
---
|
||||
name: wave-close-checklist
|
||||
description: "当波次收口、里程碑状态变化或裁定类提交(拍板/闸门判定/口径变更)时使用:按序执行总账→作战清单→回填→.agent→蒸馏→索引→编排入库→治理门的八步收口清单,收口铁律唯一可执行入口。"
|
||||
---
|
||||
|
||||
本文件是薄壳注册件,正文唯一在项目 SoT(`.agents/README.md` 边界规则,防双写):
|
||||
|
||||
**读取仓库根下 `.agents/skills/wave-close-checklist.md` 并照其执行。**
|
||||
3
.gitignore
vendored
3
.gitignore
vendored
@ -95,6 +95,9 @@ game-runtime/games/amgen-smoke*/
|
||||
game-runtime/games/amgen-avg-*/
|
||||
game-runtime/games/_wg1-gen/avg-*/
|
||||
|
||||
# ── 本机个人配置:localagents.md 自声明"绝不提交、已在 .gitignore 忽略",但此前无对应忽略行(声明未被机器执行);2026-07-06 补真 ──
|
||||
/localagents.md
|
||||
|
||||
# ── AgentScope 源码库(本机开发直读参考,克隆自 github tag v2.0.2 = 已装运行版,2026-07-01)──
|
||||
# clone 到 skill 目录供本机直接读 agentscope 2.0.2 源码(src/ + 已装 .venv 没有的 examples/docs/tests);
|
||||
# 非本仓产物、~17MB、含自带 .git、可随时重克隆,不入库。遵「专一不笼统」:只忽略这一个克隆子目录,
|
||||
|
||||
@ -19,7 +19,7 @@ prompts/
|
||||
```
|
||||
|
||||
## 引用与变更
|
||||
- 引用：Dify/aigc 用 `{{registry:id@ver}}` 引用，PromptRegistryLoader 加载注入。
|
||||
- 引用：aigc 壳层用 `{{registry:id@ver}}` 引用，`PromptResourceLoader` 加载注入（Dify 已降级远期，原 Dify 节点引用方式随之退役）。
|
||||
- 变更：改 prompt **必须升 version**，并过四道闸 CI（Schema 通过率 / 生成成功率≥80% / Golden 回归 diff / 成本延迟）；四闸绿后运营 HITL 抽检 K 条方可合入。
|
||||
|
||||
## Registry 一致性 CI 门（check_registry.py）
|
||||
|
||||
19
docs/agent-specs/.agent
Normal file
19
docs/agent-specs/.agent
Normal file
@ -0,0 +1,19 @@
|
||||
# docs/agent-specs 模块状态
|
||||
|
||||
## 目标
|
||||
|
||||
承载正在评审、待拍板或待执行的设计与计划入口。设计档只做在飞留痕,当前真相仍以 `docs/architecture/README.md` 注册表中的 canonical SoT、`docs/mvp/MVP作战清单.md` 与 `docs/mvp/MVP进度总账.md` 为准。
|
||||
|
||||
## 边界
|
||||
|
||||
- 本目录不沉淀长期真相。收口后必须蒸馏回对应 SoT,并从 `_index.md` 移除。
|
||||
- 新设计必须在 frontmatter 写明 `topic`、`status`、`sot-impact`、`上级`。
|
||||
- 设计稿不直接升级 MVP P0 范围;范围变更必须回写上线主计划或进度总账后才生效。
|
||||
|
||||
## 当前状态
|
||||
|
||||
- `2026-07-05-游戏资产管理范围决策-设计.md` 已获创始人 2026-07-05 批准:`W-ASSET` 拆成源工程长期存储、私有素材库真验、资产市场只读半、资产市场流通半;先做前三项中的 SRC + MAT-VERIFY,且允许 MARKET-READONLY 在支付前先上。
|
||||
|
||||
## TODO
|
||||
|
||||
- 为 `W-ASSET-SRC`、`W-ASSET-MAT-VERIFY`、`W-ASSET-MARKET-READONLY` 分别切执行计划;完成后把长期结论蒸馏回对应 SoT 并从 `_index.md` 移除决策稿。
|
||||
965
docs/agent-specs/2026-07-06-复杂游戏北极星件-设计.md
Normal file
965
docs/agent-specs/2026-07-06-复杂游戏北极星件-设计.md
Normal file
@ -0,0 +1,965 @@
|
||||
---
|
||||
date: 2026-07-06
|
||||
topic: 复杂游戏北极星件
|
||||
status: 终审稿(2026-07-06 fable 终审:走查缺口台账十条全部裁定——九条闭合、一条归属他单〔⑧线上批量迁移归 L2 实装+O-6 前置〕;场景 C 补 schema 后回写为通;20 处合并期裁定全部复核签认。同日在前:八单回填、O-6 挂起、Codex+Opus 双评审 N1–N14 修入)——待创始人拍。
|
||||
sot-impact: 骨架期不新建 canonical topic。本档若获批,将修订 `架构/生成引擎/agentic运行时架构图说`(§5.1 运行时形态与 §六 交互面的席位化演进)并可能新增生成引擎 L4 子档;九类工件 schema 落地时进 `contracts/`(遵 Δ5「无校验器不算契约」,走 contract-first);版本语义建在 A3.5 源工程版本寻址与 W-ASSET-SRC 之上、不与其争主(见 §4);需求基线 = `.agents/skills/agentic-seat-context-design.md`(需求输入、非 SoT,本档 §7 对其〔提案〕件逐条留「采/改/弃」)。不改 55 P0 验收定义,不挤占 16 周主线排期。
|
||||
上级: docs/mvp/MVP作战清单.md
|
||||
关联: .agents/skills/agentic-seat-context-design.md · docs/architecture/架构/生成引擎/agentic运行时架构图说.md(§3 A1-A13/C5/C6 · §4.2 · §5.1-5.3) · .agents/knowledge/agentscope-2.0-facts.md · docs/agent-specs/2026-07-05-游戏资产管理范围决策-设计.md(W-ASSET-SRC) · contracts/play-loop/play-spec.schema.json · contracts/play-loop/verdict-feedback.schema.json · docs/architecture/架构/生成引擎/游戏质量与爆火能力.md · docs/architecture/架构/生成引擎/数据飞轮.md
|
||||
图清单: [Mermaid 两张(图1 席位-工件流 · 图2 切片阶梯);SVG 门面图 TODO 随定稿波按 feature-design-doc house style 补]
|
||||
---
|
||||
|
||||
# 复杂游戏北极星件 · 设计(终审稿)
|
||||
|
||||
现行生成运行时的能力上限,是「一个 agent 一口气写出一款过九门的游戏,外加 A11 两段式改一改」。北极星要回答的是另一个量级的问题:一款肥鹅美食街级的复杂 2D 经营游戏,项目持续数十天、改动数千次、交付多个版本,创作者全程零工程感知——这样的多 agent 游戏工作室长什么样,以及它如何从现有 runtime 生长出来、而不是另起炉灶。
|
||||
|
||||
本档在骨架的六处承重裁决(立哪些席、工件长什么骨、版本语义踩在谁之上、阶梯怎么排)之上,回填了八个填充单的核实与草案:标的规格细化到字段名与曲线锚、六席四层配方成文并附框架默认注入面审计、九类工件 schema 完整化并与既有契约逐字对账、三场景席位-工件流走查逐步推演、切片阶梯落到 16 周主线接缝。走查是证伪测试:场景 A、B 的机制骨架走得通(附条件与前置),场景 C 的立身机制在走查当时的 schema 下走不通、当场标断回终审——终审据此补了 schema(约束性决定 decisions[] 落判定书与升级事件、账本建决策索引、工单加 decisionRefs 铸单时机械对撞),场景 C 回写为通:断点是被修复的,不是被糊掉的。O-6(版本语义源码核实)挂起,等 W-ASSET-SRC 执行计划成文再起。
|
||||
|
||||
## 0. 目标与边界
|
||||
|
||||
目标与作战清单 W-NSTAR 单(2026-07-06 升档版)逐字对齐,产五件:ⓐ 标的游戏规格(§1,全档架构决策的测试用例);ⓑ 席位架构裁决(§2);ⓒ 九类工件 schema 字段级草案(§3);ⓓ 版本语义落到现实接口(§4);ⓔ 倒排切片阶梯与主线接缝(§5)。
|
||||
|
||||
边界,四条硬的:
|
||||
|
||||
- **设计先行,不含实现。** schema 冻结在本档文字 + 示例 JSON;校验器、代码物随实现波次走 contract-first,不在本单。
|
||||
- **不挤占 16 周主线。** 本档只标注接缝(§5),每级切片进主线仍过波次排期;与主线争资源升级回创始人。
|
||||
- **标的只做一款经营品类。** 多品类扩展归 W-TPL 与 W-GENRE;tier2 复杂游戏的「模板」形态由本档 §5 的切片裁决间接约束,但模板产线本身不在此。
|
||||
- **既有 canonical 只引用不重写。** 运行时形态、质量口径、回流环、九门纪律各有其主;本档对它们的每一处引用,冲突即以对方为准并回本档修。
|
||||
|
||||
需求基线(agentic-seat-context-design)是**输入不是结论**:§7 对其全部〔提案〕件逐条留「采/改/弃 + 理由」。
|
||||
|
||||
## 1. 标的游戏规格
|
||||
|
||||
**命题:北极星标的不是产品排期承诺,是架构的测试用例。** 每个席位、每类工件、每条版本机制的取舍,都必须能在下面这款游戏的三个真实场景里走通;走不通的设计,当场作废,不许「留到实现时再看」。选经营品类不是偶然:多系统共享经济状态、数据表密集、生命周期长,是对席位划分与版本语义压力最大的品类——解谜或跑酷类撑不开这套架构的受力面。
|
||||
|
||||
### 1.1 标的:《夜市一条街》(概念名)
|
||||
|
||||
一条可扩张的夜市街,玩家从一个小吃摊起步、逐步盘下整条街的餐饮生意。对标肥鹅美食街的复杂度档位,八个系统共享一套经济状态、彼此的产出互为对方的输入——这正是选经营品类当北极星标的的理由:多系统在同一份存档上耦合,是对席位划分与版本语义压力最大的受力面。八个系统的机制与主要数据表如下,字段名粒度、类型省略,schema 随实现波按 contract-first 补齐。
|
||||
|
||||
**① 服务循环(核心手感所在)。** 顾客进店、点单、等待烹饪、上菜、结账、留下口碑——这条链是整款游戏每一帧都在跑的主循环,也是玩家零阅读就该上手的地方。顾客耐心条是整条循环的节拍器:它的衰减斜率直接决定同屏能塞下多少顾客,也决定玩家在「先服务谁」这个优先级判断上有多少余地(决策模式见 `sim-business-game-design.md:48`)。耐心耗尽即翻台走人、扣口碑;及时上对菜给好评、附带小费。核心动作必须单击可达——点等待中的顾客即按其点单自动出餐结账,不做「先点顾客再点货架」的两步匹配(否则零-LLM 真玩 driver 跟不动、好游戏被九门 H 误判,红线见 `sim-business-game-design.md:151`);深度来自同屏顾客的优先级排序、连击维持与库存节奏,不来自操作步数。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 顾客类型表 customer_type | id / 名称 / 立绘assetId / 耐心基线秒 / 客单价区间 / 出现权重 / 偏好菜品tag[] / 稀有度 / 小费基础系数 |
|
||||
| 菜谱表 recipe | id / 名称 / 图标assetId / 所需食材[{食材id,数量}] / 烹饪时长秒 / 售价 / 成本(食材合计) / 解锁条件ref / 稀有度 / 偏好客群tag[] |
|
||||
|
||||
**② 街区扩张。** 摊位盘成店面、店面连成多店,空间不是背景板而是吞吐上限:一张桌子同时只坐一组客,灶台数量卡住并行出餐的锅数,收银台排长队会连带压垮前面几组的耐心。玩家花金币与声望盘下新地块、摆布桌椅与设备,把「一个摊能服务几人」这条产能曲线一段段抬高。扩张是长线成长轴的骨架——数十天生命周期里,「开第 N 家店」是最外层的阶段目标。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 地块表 plot | id / 类型(摊位/店面) / 坐标 / 解锁价格 / 容纳桌位数 / 解锁条件ref / 状态(未解锁/空置/营业) |
|
||||
| 设备表 equipment | id / 名称 / assetId / 类型(灶台/冰柜/收银台/装饰) / 占地格数 / 吞吐加成 / 价格 / 解锁条件ref |
|
||||
|
||||
**③ 菜谱研发。** 食材两两三三组合解锁新菜,稀有食材配出的菜卖得贵、利润率也更陡——利润梯度是研发这条线的诱饵。玩家攒够声望或食材解锁研发节点,菜单越铺越宽,能接住的客群也越广(某些稀有客只认高阶菜)。研发与街区扩张共用同一棵解锁树,保证「下一个该解锁什么」在任意时刻只露出玩家够得着的那几个锁。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 食材表 ingredient | id / 名称 / 图标assetId / 采购单价 / 稀有度 / 库存上限 / 保鲜时长(可选) / 解锁条件ref |
|
||||
| 解锁树表 unlock_tree | 节点id / 类型(菜谱/地块/设备/食材) / 目标ref / 前置节点[] / 解锁成本{货币,数量} / 触发(声望阈值/任务完成) |
|
||||
|
||||
**④ 员工体系。** 雇人是把玩家的手从重复劳动里解放出来的机制:服务员自动收台、后厨自动出基础菜、收银自动结账。员工有岗位、有效率、有可升级的技能槽,玩家在「多雇一个人 vs 升现有人的技能」之间做投入判断。它替玩家自动化掉一部分服务循环,让玩家的注意力上移到调度与扩张——这是放置品类「不肝」体验在经营壳里的落点。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 员工表 staff | id / 名称 / assetId / 岗位(服务/后厨/收银) / 基础效率 / 雇佣成本 / 日薪 / 技能槽[技能id] / 状态(在岗/休息) |
|
||||
| 技能表 skill | id / 名称 / 适用岗位 / 效果类型(加速/加成/自动化) / 效果数值曲线ref / 升级成本曲线ref / 上限等级 |
|
||||
|
||||
**⑤ 事件与节奏。** 平铺直叙的经营会闷,事件系统负责在时间轴上打节拍:高峰潮汐把客流猛地拉满、美食评论家带来一次高风险高回报的接单、限时活动给一个短期目标,雨天这类天气事件换一整套场景氛围与客流修饰。每个事件都是一组对基线数值的临时修饰(客流倍率、耐心系数、同屏上限、售价加成),叠加在服务循环之上。这个系统也是场景 B「雨天夜市」的宿主——雨天是一个天气类事件条目,连着它自己的场景资产。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 事件表 event | id / 名称 / 类型(潮汐/评论家/限时活动/天气) / 触发条件(时段/日期/概率) / 持续时长 / 效果修饰{客流倍率,耐心系数,同屏上限修饰,售价修饰} / 场景assetId / 奖励ref |
|
||||
|
||||
**⑥ 经济与进度。** 金币、声望、食材三种资源构成经济底盘:金币是循环挣、用于常规升级的软币,声望是解锁高阶内容的稀缺轴,食材是需要进货补货的消耗品。离线收益让玩家回归时有惊喜,每日目标手把手给下一步。这个系统的数值不是散落各表的魔法数,而是集中在一张数值配置表里由曲线管着(见 §1.1.1),让平衡能被仿真器整体扫过、也让「第 1400 次改动」不必翻遍代码找一个常量。存档表是这一切状态的落盘面,带 schema 版本号——它是 §4 兼容检查器认的那个对象。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 数值配置表 economy_curve〔即经营参数的曲线常量表,归为「数值配置表」一类,性质上区别于实体表〕 | 键 / 曲线类型(线性/指数) / 基值 / 增长率 / 卡点位 / 适用对象(升级成本/单位产出/耐心/离线收益) |
|
||||
| 任务表 quest | id / 类型(每日/阶段/引导) / 目标{指标,阈值} / 奖励{货币,数量} / 前置ref / 有效期 |
|
||||
| 存档 schema save_state〔运行时状态、非内容席数据表;承载 §4 saveDataImpact 的独立版本纪律面,缺口④终审定性〕 | schemaVersion / 三资源余额 / 已解锁节点[] / 地块与设备状态[] / 员工状态[] / 每日进度 / 事件历史 / lastOfflineTs |
|
||||
|
||||
**⑦ 变现位。** 双倍收益广告、加速广告、装饰内购位——变现在经营游戏里是包装成福利的自愿点位,不打断爽点。每个位子是一个逻辑槽,触发点(结算/加速/解锁)、奖励倍率、冷却写在表里;真实的广告调用不在游戏里发生,而是经 SDK 抽象到宿主侧(渠道约束见 §1.1.3)。装饰内购位在 MVP 只预留结构、不接支付。这张表的字段刻意与平台广告 API 解耦:游戏只认 adSlotId 逻辑标识,不认平台的 adUnitId。
|
||||
|
||||
| 数据表 | 主要字段 |
|
||||
|---|---|
|
||||
| 变现位表 monetization_slot | id / 类型(激励视频/内购预留) / adSlotId(枚举白名单) / 触发点(结算/加速/解锁) / 奖励{类型,倍率} / 冷却秒 / 兜底奖励(reward_fallback 计入) |
|
||||
|
||||
**⑧ 社交外围(远期档)。** 排行榜与好友串门属长线社会性钩子,MVP 不做——单机联网社交落不到轻量运行时,可达性红线明写要改单机 + 本地最佳分(`sim-business-game-design.md:146`)。此处只登记两张远期占位表、给最小字段,标明不进 MVP、进 L4 传播线后再定。
|
||||
|
||||
| 数据表(远期占位) | 主要字段 |
|
||||
|---|---|
|
||||
| 排行榜条目表 leaderboard_entry(远期) | 玩家id / 指标(声望/营收) / 值 / 榜期 |
|
||||
| 好友串门表 friend_visit(远期) | 主家id / 访客id / 时间 / 互动类型 / 奖励 |
|
||||
|
||||
**数据表清点:** 实体与配置表 12 张(顾客类型/菜谱/地块/设备/食材/解锁树/员工/技能/事件/数值配置/任务/变现位)+ 存档 schema 1 份(save_state——运行时状态、非内容席可填的数据表:其变更走 SpecDelta 登记与实现席代码,校验器是兼容检查器而非 validate_datatable;缺口④终审定性),另加社交外围 2 张远期占位,满足「数据表不得低于 10」;八系统满足「系统数不得低于 8」。save_state 是从原始清单里显式拆出的一份——它承载 §4 版本语义的兼容检查器所依赖的 schema 版本纪律,§4 隐含依赖它、§1 补齐登记,使两节自洽。
|
||||
|
||||
量级估计(架构受力用,非承诺):源文件 30–60 个,数据表 10 张以上,精灵/UI 素材 150–250 件,音效 8–12 条 + BGM 2–3 首;生命周期数十天、改动上千次、版本卡几十张。运行主端是自研 H5(web/iframe 沙箱),标的数十天、千次改动、多版本的完整闭环活在这一端;微信/抖音小游戏平台自动剥离远程代码、禁 JS 解释器,写码富游戏上不了它们的「一壳多游」批量通道,只能作为重点游戏走「单游固化」导出特例——单独一 appid、把代码固化进包提审,人在环、受备案锁与月级审核节奏约束。运行端的架构受力真正有力的是三条:包体分包上限逼资产走按需加载与体积门、触控为主逼输入抽象、云存档逼存档 schema 有版本纪律;具体数值与渠道 API 现状详见 §1.1.3。〔fable 合并期裁定·终审签认 2026-07-06:渠道定位——运行主端 = 自研 H5,微信/抖音 = 单游固化导出特例,不走一壳多游批量通道。〕
|
||||
|
||||
#### 1.1.1 数值曲线骨架(首版)
|
||||
|
||||
数值是这款游戏的受力核心,但它同时是全档里最不该在骨架期拍死的部分——耐心斜率、利润梯度、解锁节奏这三条曲线怎么配才「好玩」,靠的是把游戏快进跑上千局看曲线形状(§1.2 场景 A 的快进仿真器、§5 L3 的仿真器工具、可行性见 §2.C),不是骨架期一次填对。所以这里只钉**形状**与**首版锚点**,每条都标清锚点的来源与「待仿真校准」的部分。
|
||||
|
||||
一处口径必须先说清:sim-business skill 里那套客流锚(清闲期出现间隔 1.8–2.8s、同屏上限 3、耐心 5–7s;高峰期间隔 1.0–1.5s、上限 4;rush 起点 ≥35s)是为**便宜档 60 秒单局**校的(`sim-business-game-design.md:74`)。北极星标的是 tier2 复杂游戏,一个「局」是一个营业日、生命周期跨数十天,不是 60 秒。所以下表把便宜档单局锚当作**营业日内节拍的起点量级**继承过来,而把「拉伸到营业日与跨日成长」的那部分统一标为待仿真校准——这条继承关系本身也是 §2.C 要验证的:营业日节拍能不能直接沿用单局锚,还是需要另一套。
|
||||
|
||||
| 曲线 | 形状 | 首版锚点 | 锚点来源 | 校准状态 |
|
||||
|---|---|---|---|---|
|
||||
| 顾客耐心 | 按稀有度分档的常量基线,受事件修饰临时下调 | 普通客耐心 5–7s、高峰更短;同屏上限 清闲 3 / 高峰 4 | `sim-business-game-design.md:74`(便宜档单局锚) | 营业日尺度下的分布、稀有客耐心梯度 **待仿真校准** |
|
||||
| 客流出现间隔 | 清闲慢、高峰密;高峰不早于营业日中段 | 清闲 1.8–2.8s / 高峰 1.0–1.5s;高峰起点 ≥ 营业日 35%(单局对应 ≥35s/60s) | 同上 `:74` | 营业日曲线与多波次潮汐 **待仿真校准** |
|
||||
| 菜价利润梯度 | 售价随稀有度递增、利润率随解锁深度递增 | 营收三档解锁阈值 22 / 55 / 100(金标烘焙店 serve 的菜单渐次解锁形状) | `sim-business-game-design.md:184`(金标 bake-shop-serve 锚) | 三资源经济下的绝对值与利润率斜率 **待仿真校准** |
|
||||
| 解锁/升级成长 | 成本指数增长,制造「差一点」的卡点、不卡死 | 升级成本 ×1.15/级(默认锚) | 质量 SoT §5「成长曲线 ×1.15/级为默认锚」(`游戏质量与爆火能力.md:78`) | 跨营业日的解锁阶梯步距 **待仿真校准** |
|
||||
| 离线收益 | 每 N 秒基础产出 × 离线时长,设封顶 | 〔首版无锚〕 | —— | 产出率与封顶值 **待仿真校准**;〔来源缺口:仓内无离线收益具体数值锚,待品类件或仿真给出〕 |
|
||||
| 同屏最大顾客数 vs 帧率 | 性能约束曲线,同屏上限随设备档降级 | 低端设备帧率锁 30fps、限制粒子/音频预加载 | `runtime-and-multichannel.md:148`(低端降级) | 高峰同屏上限的性能安全值 **待仿真校准**;此曲线是 §1.2 场景 C「高峰期太卡」的数值宿主——同屏上限既是玩法参数也是性能闸,两重身份必须同表管 |
|
||||
|
||||
首版骨架的自检口径:成长必须有「越来越快」的暴富段而非平淡线性,卡点是诱惑不是墙(`sim-business-game-design.md:72`);经营品类的经济门要求真玩到盈利终态可达、且不制造经济死局(质量 SoT §8 平衡门五裁定),这两条是仿真器校准时的目标函数,不是骨架期的锚。
|
||||
|
||||
#### 1.1.2 资产清单(表格粒度)
|
||||
|
||||
竖屏 390×844、单/少场景(`sim-business-game-design.md:12`),美术一致性靠全资产共用一组风格词(主体 + 风格 + 配色 + 构图,`sim-business-game-design.md:88`),风格基调走 Q 版萌系扁平或治愈暖色(`:80`)。下表把量级估计(精灵/UI 150–250 件、音效 8–12、BGM 2–3)落到类别粒度;总量与体积必须落进运行时体积门(全量 ≤10MB、首屏 ≤2MB,见 §1.1.3),这是资产席 harness 的硬闸(§2 资产席「体积门」)。
|
||||
|
||||
| 类别 | 数量估 | 单件规格 | 格式 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| 顾客立绘 + 状态动画 | 8–12 类型 × 3–4 状态(等待/满意/不满/离店)≈ 30–48 | 128×128 | png / atlas | mmx 生成 |
|
||||
| 菜品图标 | 15–25 | 96×96 | png / atlas | mmx 生成 |
|
||||
| 食材图标 | 12–20 | 64×64 | png / atlas | mmx 生成 |
|
||||
| 摊位/店面地块 | 6–10 | 可变 | png | mmx 生成 |
|
||||
| 设备(灶台/冰柜/收银/装饰) | 10–15 | 可变 | png | mmx 生成 |
|
||||
| 场景背景(含雨天变体) | 3–5 场景 ×(基础 + 天气变体) | 390×844 或平铺底 | webp | mmx 生成 |
|
||||
| UI 组件(HUD/按钮/弹窗/图鉴格/进度条) | 30–50 | 分级圆角、9-patch | 矢量 / png | 程序化 + mmx |
|
||||
| 特效贴图(飘字/连击/解锁光效) | 5–10(主体走 particles-juice 程序化) | 小图 | png | 程序化为主 |
|
||||
| 音效 | 8–12(收钱叮/上菜/升级/合成/点击/解锁/翻台) | 短样本 | 音频 | zzfx 程序化兜底 + mmx |
|
||||
| BGM | 2–3(闲时/高峰/雨天) | 循环 | 音频 | mmx music(instrumental) |
|
||||
|
||||
合计精灵/UI 约 150–200 件(落 150–250 区间)、音效 8–12、BGM 2–3。体积纪律:首屏只加载首营业日首场景的资产(≤2MB),其余走三容器预加载/按需(`runtime-and-multichannel.md:48`);全量顶到 10MB 门前,靠 WebP/AVIF 与音频懒加载压(`runtime-and-multichannel.md:159`)。程序化兜底是硬底线——缺图不许阻塞可玩性(`sim-business-game-design.md:90`)。
|
||||
|
||||
#### 1.1.3 双端渠道约束(核实)
|
||||
|
||||
§1.1 末段预判双端约束里对架构真正有力的三条力,这里逐条核实并给仓内一手出处。核实结论:三条力都成立,但第三条(存档)比预判更重,还有第四条(禁远程代码)预判里没写、却是对标的影响最大的一条。仓内查不到的数字标〔来源缺口〕、不编造;与既有渠道 SoT 冲突处以 SoT 为准。
|
||||
|
||||
先把「双端到底是哪两端」钉清楚:
|
||||
|
||||
- **运行主端 = 自研 H5 流(iframe 沙箱)。** 浏览器不禁动态生成代码,是写码富游戏唯一容身处(渠道发行 SoT :20/:49)。标的数十天、千次改动、多版本的完整闭环活在这一端。
|
||||
- **特例发行端 = 微信/抖音小游戏(单游固化)。** 渠道只接 L1 纯数据一壳多游;tier2 富游戏要上渠道只能作为重点游戏单独一 appid、把代码固化进包提审(渠道发行 SoT :55),受备案锁与月级审核节奏约束。
|
||||
|
||||
**A. 包体与分包。** H5 iframe 全量资源 ≤ 10MB、首屏 ≤ 2MB、超限编译失败(六处契约一致:`架构/README.md:341`、`security-and-reliability.md:65`、`game-package.schema.json:35`、`api-schemas/runtime.yaml:121`、`db-schemas/V3.0.0__create_game_runtime.sql:30`、`runtime-and-multichannel.md:69`);渠道版主包上限 ≤ 4MB(渠道发行 G1 真机门,`渠道发行.md:240`);微信/抖音「主包 + 分包」总上限、单分包上限、分包数量,仓内无出处、〔来源缺口:待外部核实〕。**对架构的力:逼资产按需加载 + 体积门。** 标的资产量级(§1.1.2)在 H5 端就顶着 10MB / 2MB 门,资产席「体积门 harness」是硬闸;渠道单游固化端 4MB 主包连全量精灵都放不下,分包/按需下载是硬需求——这条力不依赖分包上限的具体数字:无论上限多少,标的都必须分包。
|
||||
|
||||
**B. 存档(比预判更重)。** 现行 H5 storage 四道闸:闸①key 只放行 `idle:gameId:versionId` 白名单;闸②value ≤ 4KB(idle 存档实际 <200B);闸③写前 JSON.parse 校验、回读只接受对象形态;闸④落盘加 `wxgame:` 前缀命名空间隔离(`03-产物执行沙箱图说.md:74`、`:217`)。SDK Storage 层做云存档/进度、失败回退 localStorage(`runtime-and-multichannel.md:90`);渠道版存档走 canvas-input-audio-**storage** 四件 adapter 之一(`渠道发行.md:126`)。平台云存档配额(单 key / 总量)仓内无、〔来源缺口:待外部核实〕。**对架构的力:逼存档 schema 有版本纪律,且逼存档面为复杂游戏重新定容。** 现行四闸是为「无离线态模板、存档 <200B」设计的,value ≤ 4KB 对北极星复杂存档(save_state:三资源余额 + 已解锁节点 + 地块设备状态 + 员工状态 + 每日进度 + 事件历史)根本不够,单 key 白名单也容不下结构化多字段存档。这坐实了 §4 挂的「save-progress 现状待核」:现行 L2 KV 存档既无 schema 版本字段、value 又卡 4KB,对标的是**前置增补需求**——存档面要重新定容(放宽 value 上限或改多 key / 结构化)并加 schemaVersion 字段,走 L2 插件库通道(§4 明示不在本单实现)。§4 兼容检查器正是建在这个带版本的存档面上;没有这次定容与加版本,场景 A/B 的存档迁移无处落。
|
||||
|
||||
**C. 输入。** 输入抽象落 canvas-**input**-audio-storage 四件 adapter 之一(`渠道发行.md:126`);触控为主——真机门 G2b「各 3 次真实触摸完成 tycoon 闭环」、真机测试禁状态注入(`渠道发行.md:242`、`:213`);竖屏 390×844(`sim-business-game-design.md:12`)。**对架构的力:触控为主逼输入抽象。** canvas-input adapter 把触摸事件抽象成引擎统一输入,一套玩法逻辑跨三端(H5 pointer / 微信 touch / 抖音 touch)。标的的服务循环「点顾客即成单」本就受此约束——所有交互必须触控单击可达,不能依赖键盘或鼠标 hover(与 `sim-business-game-design.md:151` driver 可达红线同源)。这条力回馈 §1.2 场景 A 的交互设计:创作者说的每个新机制,主设计席产规格时都要落到触控单击可达。
|
||||
|
||||
**D. API 与网络(四重力)。** 禁远程代码:微信/抖音自动剥离远程包代码、明文禁 JS 解释器,渠道 9c 契约禁一切可执行/可解释字符串、禁远程下发 JS/WASM/HTML/脚本化 SVG(`渠道发行.md:20/49/140-146`);iframe CSP `connect-src 'none'`,游戏内零网络请求(`tech-decisions.md:141`、`runtime-and-multichannel.md:67`);广告 API `showRewarded(slotId)` → 平台 `wx/tt.createRewardedVideoAd`,slotId→adUnitId,广告/支付在宿主侧 iframe 外渲染(`渠道发行.md:151`、`runtime-and-multichannel.md:96`);广告红线 `rewarded=true` 只认平台「完整观看」回调,兜底发奖标 `reward_fallback=true`,加载失败必须跳过、游戏继续、绝不卡死(`渠道发行.md:151/153`);官方 weapp-adapter 已不再维护,变现 SDK 各引擎都得手接(`渠道发行.md:188`)。四重力:①**禁远程代码 → 逼标的的渠道路径二选一(H5 主线 / 单游固化),上不了一壳多游**——这是对标的影响最大的一条,渠道里「游戏逻辑必须是数据、不能是代码」(`渠道发行.md:147`)与 tier2「LLM 写真 src/ 多文件代码」根本对立;②iframe 禁网络 → 变现位与云存档经宿主代理,变现位表只认 adSlotId 逻辑标识正是这条力的落点;③广告红线 → 变现位设计的诚实与降级纪律(加载失败静默跳过、兜底标 reward_fallback);④weapp-adapter 弃维护 → 渠道适配层是长期自研维护面(标的走单游固化则其 Phaser 工程的微信/抖音适配要自研 B-CHANNEL-* adapter)。
|
||||
|
||||
**E. 备案与版本节奏。** 备案后不支持改内容/icon/代码,任何实质变更须重新备案,「当日热发新游进渠道」已被收回、渠道线只能非实质参数微调(`渠道发行.md:73/81`);渠道版本节奏是月级「攒一批 → 统一备案 → 整包提审」(`渠道发行.md:53/78/115`)。**对架构的力:逼版本语义分端。** §4 的高频版本语义(版本卡、意图重放、即时热发)只对自研 H5 流成立(H5 无备案锁);渠道侧标的的「数十天/千次改动」节奏落不了地——每次实质变更都要重新备案 + 月级整包提审。这条力已在 §4 末的端别边界落地。
|
||||
|
||||
**尚待外部核实(仓内无权威出处,禁编造):** ① 微信/抖音「主包 + 分包」总体积、单分包、分包数量的具体数字(仓内只有渠道主包 ≤ 4MB);② 平台云存档单 key 与账号总配额(仓内只有 H5 侧 iframe 沙箱的 4KB value 闸,那是自研 storage adapter 的闸、非平台云存档配额);③ 离线收益具体数值锚(§1.1.1 已记同一缺口),存档跨端同步的离线时长上限可能受平台约束,一并待核。
|
||||
|
||||
#### 1.1.4 数据结构对三场景的自洽核对
|
||||
|
||||
- **场景 A(追加宠物系统)**:宠物是上线后的追加需求,不在基础规格里,但基础规格已为它留好 additive 落点——结账环节含小费(顾客类型表的小费基础系数),追加时是在顾客类型表加一列「互动小费加成」、在存档表 save_state 加一个可选宠物子树(旧档缺省视为未解锁宠物、additive 不升存档 schema 版本),正是 §1.2 场景 A 的 SpecDelta 与 saveDataImpact。基础规格不含宠物、但表结构不排斥它,自洽。
|
||||
- **场景 B(雨天夜市回退分叉)**:雨天夜市是事件表里的一个天气类条目(连场景 assetId),V21 加的这条事件独立可回放/可重实现;§1.2 场景 B 说的「菜谱表在 V22 加过字段导致存档不兼容」,对应菜谱表字段可 additive 扩展、且 save_state 带 schemaVersion 供兼容检查器比对,自洽。
|
||||
- **场景 C(第 1400 次改动·高峰太卡)**:高峰潮汐是事件表条目,「同屏最大顾客数 vs 帧率」曲线(§1.1.1)是这次改动的数值宿主——它既是高峰玩法强度旋钮、也是渲染性能闸,决策史「曾为正确性关掉渲染合批」重开会复发的正是这条上的性能约束,自洽。
|
||||
|
||||
### 1.2 三场景走查
|
||||
|
||||
标的的三个真实场景不是产品示例,是架构的证伪测试。每个席位、每类工件、每条版本机制的取舍,都要在下面三条链上逐步走通——哪一步指不出承接它的席位、消费不到需要的工件字段、或缺一道机制把上一步的产物接住,就是设计的断点,当场标出、回终审,不许留到实现时再看。三场景分别压不同的受力面:场景 A 压「一句话新增机制」到多席协作与存档契约变更的全程,场景 B 压版本回退分叉与意图重放,场景 C 压数千次改动后决策史如何在噪音里被精确对撞。走查的每一步都写明:哪个席(限六席)、消费什么工件的哪个字段、产出什么工件、创作者在这一步被不被打扰、若被打扰是三档确认的哪一档。走查暴露的 schema/配方缺口与软依赖逐条收进 §7「走查缺口台账」(下称「缺口①–⑩」「软依赖」),此处只引编号、不在正文展开;台账十条已经 fable 终审逐条裁定(2026-07-06),正文相应处标〔已闭合·终审〕,裁定细节见 §7 终审裁定表。
|
||||
|
||||
#### 场景 A · 追加新功能
|
||||
|
||||
**一句话**:上线三周后创作者说「加一个宠物系统,顾客可以撸猫,撸完小费变多」,这句话要一路走到创作者手上多出一个能玩的预览版,中途不问他一个技术问题。
|
||||
|
||||
**走查推演。** 第一步落在**制作人席**。它消费两样东西:context 配方里的「用户现场快照」块(会话态即时、性质为事实,承载创作者那句原话),与场景注册表(§2.B,harness 层的分诊路由)。制作人席按注册表把这句话匹配到 `sceneId=modify.behavior`(`sceneFamily=修改`、`intentClass=behavior`),路由取 `route.entrySeat=producer`、`route.terminalSeats=[design, impl]`。这里守可信边界铁律——模型自己报的执行 mode 一律不采信,只按 `intentClass` 落路由。制作人席同时识别出这个需求会碰存档(撸猫养成态要落盘)和顾客类型表(撸猫按顾客类型触发),于是 `irreversibleSources` 潜在命中 `saveData`。
|
||||
|
||||
第一步在这里就撞到本场景的第一个承重争议:本节命题期望创作者「只在最后试玩这一步」被打扰,即全程档 1;但场景注册表把 `modify.behavior` 的 `confirmFloor` 记成「saveData 命中即 2」,照字面制作人席此刻就得把确认档顶到 2、先问创作者,档 1 的承诺当场破。调和的唯一走法,是让 `confirmFloor` 对 `saveData` 分两种性质:additive(新增可选字段、旧档缺省仍可读,`SpecDelta.saveDataImpact.migratorNeeded=false`)不顶 2,breaking(改删字段、旧档失效、`migratorNeeded=true`)才顶 2。宠物系统按 §3 的 SpecDelta 示例是 additive(旧档缺省视为未解锁宠物、无需迁移器),因此不顶 2、可走档 1。但这带出一个时序约束:additive 还是 breaking,要等主设计席产出 SpecDelta、`saveDataImpact.migratorNeeded` 落定才知道,而分诊在它之前——所以确认档的**终判不能在分诊这一刻拍死**,得推迟到 SpecDelta 产出之后。这与 `WorkOrder.confirmTier`「铸单时定死」并不矛盾:把分诊后先铸的那张工单(给主设计席、`confirmTier=0`、纯内部设计步骤)与后面碰创作者的工单分开,确认档就落在后者、且落在 SpecDelta 已知之后。〔fable 合并期裁定·终审签认 2026-07-06:confirmFloor 对 additive/breaking 细分、确认档终判推迟到 SpecDelta 已知后——采纳(缺口⑩口径);故场景 A 走档 1 成立。〕
|
||||
|
||||
第二步,制作人席产出一张 `WorkOrder`(工件①),`route.terminalSeats` 先指 `design`。工单字段:`goal="为『顾客撸宠物、撸后小费上浮』设计系统契约与数据 schema 增量"`;`confirmTier=0`(内部步骤,不碰创作者);`budget` 按主设计席额度填 `{rmbSoft, rmbHard, wallClockS, resumeMax}`。此处指认到一个 schema 缺口:这张工单的产出是 SpecDelta(契约/schema 面),可 `scopeWhitelist` 只有 `{files[], tables[]}` 两维,圈不出「只许改这几份契约」——给主设计席的工单无法用写白名单精确约束契约面(缺口②)。走查照实标:填 `scopeWhitelist.tables=["顾客类型表","存档表"]` 只能勉强表达「涉及这两张表的 schema」,不能表达「涉及 source-project 契约的哪一段」。〔已闭合·终审:scopeWhitelist 增 contracts[] 维(契约路径 + JSON Pointer 锚),主设计席工单据此圈契约面,§3①。〕
|
||||
|
||||
第三步落在**主设计席**。它消费上一张 `WorkOrder`(六要素)、context 配方里的「系统契约」块(出处戳＝契约版本号、事实)与「数据 schema」块(顾客类型表、存档表 save_state 的 schema),以及「决策史」块(对撞检查——宠物是纯新增,无历史冲突)。产出 `SpecDelta`(工件④):`contractRef="game://nightmarket/datatables/customer_type.gold.json#/columns"`;`contractVersionBump=minor`;`changes=[{op:add, path:/save/pet, rationale:宠物养成态持久化}, {op:add, path:/datatables/customer_type/columns/petInteraction, rationale:顾客类型表加互动列}]`;`migrationNote="旧档缺省视为未解锁宠物、无需强制迁移器"`;`saveDataImpact={changed:true, migratorNeeded:false, schemaBump:none, saveSchemaVersion:"nightmarket-save/3"}`。主设计席的 harness 铁律是「规格增量必过 schema 校验器才发布」。
|
||||
|
||||
这一步的 `saveDataImpact.saveSchemaVersion` 登记面,压在一个尚不存在的东西上,走查必须如实引用而非写成已就位:§1.1.3 已坐实现行 H5 存档面是四道闸的 KV 存档,`value ≤ 4KB`、单 key 白名单只放行 `idle:gameId:versionId`,且现行 L2 `save-progress` 插件不带 `schemaVersion` 字段。标的的 `save_state`(三资源余额＋已解锁节点＋地块设备状态＋员工状态＋每日进度＋事件历史,再加 pet 子树)早已顶破 4KB、也容不下单 key。因此 `saveDataImpact` 要登记的那个「带版本、能装复杂结构」的存档面,是一个前置增补需求(存档面重新定容＋加 `schemaVersion`),走 L2 插件库通道、明确不在本单实现(§4 已挂「save-progress 现状待核」,O-6 负责落地)。这一步能产出 SpecDelta,但它承诺的存档语义要等存档面增补才真兑现(软依赖)。
|
||||
|
||||
第四步仍在**主设计席**,戴帽消费快进仿真器的输出。§2 已裁数值仿真「先工具后席」,仿真器是门/工具、不是席,v1 由主设计席读它的结果。主设计席据 context 配方里的「仿真结果」块(性质＝推断、出处戳＝仿真跑批 ts＋局数)判断:撸猫小费加成初版若给 +30%,快进千局会不会击穿金币曲线。§3 的 DistillDelta 示例正来自这一役——+30% 快进千局即击穿、赢线提前使后期内容失去意义,于是主设计席把系数压到安全值再回写进 SpecDelta。走查在这一步指认到一处软依赖:快进仿真器可行性已由 §2.C 坐实(路 A 成立)、数值仿真席本身缓立到 v2,仿真器工具落地前,这一步只能退化成主设计席的人工判读,`acceptance` 里那条「经济仿真非劣化」门暂无证据源(`EvidencePackage.simRunRef` 是 optional 占位)。这不是设计漏洞,是已知的缓立项,如实标为软依赖。
|
||||
|
||||
第五步回到**制作人席**,此刻它消费主设计席产的 `SpecDelta`——关键是读到 `saveDataImpact.migratorNeeded=false`,据此把确认档终判为 1(additive、不顶 floor 2)。制作人席铸两张并行 `WorkOrder`,写白名单互不相交:
|
||||
|
||||
- 实现工单:`goal="顾客可与宠物互动,互动后小费系数上浮"`、`scopeWhitelist={files:["src/systems/pet*","src/systems/tipCalc.js","src/scenes/PlayScene.js"], tables:[]}`(新文件走通配前缀、必触碰的既有文件显式列全——缺口⑤终审语义)、`acceptance={gates:["九门"], machineChecks:["经济仿真非劣化"], checks:["撸猫动效可见"]}`、`confirmTier=1`。
|
||||
- 内容工单:`goal="顾客类型表加互动小费加成列并填初值"`、`scopeWhitelist={files:[], tables:["顾客类型表"]}`、`acceptance={gates:[], machineChecks:["validate_datatable"], checks:[]}`、`confirmTier=1`。
|
||||
|
||||
两张白名单一个只碰宠物三文件、一个只碰顾客类型表,`files`/`tables` 维度不相交,满足工单级白名单互斥。这一步又指认到两处缺口。其一(缺口③):`acceptance.gates[]` 的取值域在契约对账里被锁成九门闭集(`A_boot..I_control` ＋ richGame 三门),可上面两张工单的 `gates` 里塞了「经济仿真非劣化」和「validate_datatable」——都不是九门闭集里的门名。这说明 `acceptance` 的「gates＝九门／checks＝人判」二分不够用:非九门的机器门没有干净落点,塞 gates 破闭集、塞 checks 又不是人判。其二(缺口④):存档表 save_state 的 pet 子树是运行时状态 schema、不是内容席能填的静态表(不像顾客类型表有样例行),它的变更由 SpecDelta 登记、由实现席在 pet 系统代码里读写,不进内容席的 `validate_datatable`。所以内容工单的 `tables` 不含 save_state,实现工单的 `files` 含存档读写代码,`scopeWhitelist.tables` 的白名单机制对 save_state 不适用。〔缺口③④均已闭合·终审:acceptance 改三分{gates 九门闭集, machineChecks 非九门机器门, checks 人判},上方两张工单示例已按此写;save_state 定性为运行时存档 schema、白名单增 saveStateSubtrees[] 维承接其子树授权、其校验器 = 兼容检查器而非 validate_datatable,§1.1 清点与 §3① 同步。〕
|
||||
|
||||
第六步是两张工单并行执行。**实现席#pet** 消费实现工单(六要素＋白名单 `src/systems/pet*`)、SpecDelta(据它知道存档加 pet 子树、小费系数改哪)、品类坑清单,产出 `DeliveryPackage`(工件⑤):`commitHash`(必须 `git rev-parse` 得到、反造假)、`filesTouched[]`、`sourceProjectRef`、`selfTestEvidence={cmd, exitCode, summary}`、`journalRef`。这一步撞出本场景最实的一处麻烦(缺口⑤):`DeliveryPackage` 示例把 `filesTouched` 填成 `["src/systems/petSystem.js","src/systems/tipCalc.js","src/scenes/PlayScene.js"]`,可实现工单 `scopeWhitelist.files=["src/systems/pet*"]` 只圈得住 `petSystem.js`——`tipCalc.js`、`PlayScene.js` 落在白名单外。而 §3 明写 `filesTouched` 必须 ⊆ `scopeWhitelist.files`(离场清账的核对面),照此离场清账会当场判这次交付越界。根子在需求本身:「撸完小费变多」这个改动天然跨文件——新增 pet 系统、改既有小费计算 tipCalc、接既有场景 PlayScene——「只圈新文件」的通配前缀白名单圈不住「新增机制必然触碰的既有文件」。要么白名单铸单时就放宽到显式列全三个文件,要么承认新增机制的白名单不能只写通配前缀。〔已闭合·终审:白名单语义钉死为「新文件通配前缀 + 必触碰既有文件显式列全」的并集展开,DeliveryPackage 校验 filesTouched ⊆ 展开集;确需越界不得静默,发升级事件(reason.code=scope_expand)改单再写,§3①⑤⑦ 同步;第五步示例已按此列全。〕
|
||||
|
||||
这一步还连着一个走查判不了、必须核实的点(缺口⑥,潜在硬断点):§2.A 的审计 A4 提到 tier2 的 `LOCKED_PLATFORM_FILES` 平台锁定文件集(含 main.js／game-core.js／layout.js 与 systems 下若干系统文件),实现席的 `write_source` 撞上锁定文件直接拒改。若这里的 `systems/*.js` 是目录级 glob 锁,实现席连自己要写的 `src/systems/petSystem.js`、要改的 `src/systems/tipCalc.js` 都会被平台锁挡住——「实现席写玩法系统」与「平台锁定 systems 目录」直接对撞,场景 A 第六步走不动。走查不能凭记忆断定它是目录锁还是仅特定文件锁(更可能是 game-core.js 结算、main.js 装载这几个特定文件锁,否则实现席无法工作),此处标为必须核实。〔已闭合·终审(源码核实):锁是 10 个显式文件路径的 frozenset 精确匹配(`toolkit.py:34-45` 定义、`:50` 以 `rel in` 判定),systems/ 下只锁 resource/merge/order/reachability 四个具名平台系统文件、非目录 glob——petSystem.js 与 tipCalc.js 均为新文件不在锁内,本步可写,硬断点不成立。另注:现行 mini-fei-e fixture 的分工约定(agent 只写表现层)比锁本身更窄,北极星实现席「写玩法系统文件」需要 fixture-spec 预建分工随 L3 演进——这是分工规格问题、非锁语义问题,归 L3 详设。〕
|
||||
|
||||
同一步里另有两处软依赖,如实标不写成已就位:`journalRef` 要写的「写前意图 journal」是现状缺口(实现席暂无 journal 协议),要等 §5 L1 切片补;`sourceProjectRef` 的寻址锚(`addressingKey`／`versionId`)压在 W-ASSET-SRC 源工程版本寻址上,而 W-ASSET-SRC 首段未排期。
|
||||
|
||||
与实现席并行,**内容席**消费内容工单(`scopeWhitelist.tables=["顾客类型表"]`)、SpecDelta(顾客表加 `petInteraction` 列的 schema)、表 schema＋样例行＋数值曲线锚,只在 `data/*.json` 里给顾客类型表加互动小费加成列、填初值,产出自己的 `DeliveryPackage`,过 `validate_datatable` 校验器(不过不出席)。内容席只写表不写码,与实现席写权限天然互斥,这一步干净。
|
||||
|
||||
第七步,门与工具(非席位)在两份交付产物上跑,产 `EvidencePackage`(工件⑥):`gateRunRef` 指九门 verdict.json、`tracePath` 指本局 trace、`screenshots[]` 是四件套取证图、`costActual={totalRmb:0.42, tokens}`、`simRunRef` 指经济仿真非劣化产物(同样压在仿真器工具落地上)。
|
||||
|
||||
第八步落在**评审席(盲)**。它消费规格(SpecDelta)＋交付包(两份 DeliveryPackage)＋证据包(EvidencePackage),context 配方里刻意致盲——不注入实现会话的存在、不注入前任心路。产出 `Verdict`(工件②,并存形态):`decision` 引 tier2-verdict 的 accept/fix/kill;`perCheck[]` 投影 `layerResults.L1.gateResults`＋`richGameGates`＋`findings`;`ftueNotes` 投影 `humanPlayability`＋play-spec `firstPlay`(玩家席缓立期的 FTUE 权宜项);`evidenceRef` 指 EvidencePackage;若判 fix 才有 `fixFeedbackRef` 指一份 C6 续修载荷。评审席工具面含「快进仿真器(只读)」,它读 `EvidencePackage.simRunRef` 判「经济仿真非劣化」——仿真器工具缺位时这条判不了,同上软依赖。
|
||||
|
||||
第九步回到**制作人席**,消费 `Verdict`(`decision=accept`),产 `VersionCard`(工件③):`versionId`／`baseVersionId`、`baselineStamp={gatesGreen, telemetryNonRegression, qualifiedAt}`、`appliedIntents=[实现工单ref, 内容工单ref]`、`compatStamp={saveSchemaVersion:"nightmarket-save/3", compatibleFrom}`、`thumb`＋`oneLiner="加了宠物,撸猫小费更多"`。`baselineStamp.telemetryNonRegression` 依赖遥测按 `versionId` 切片,O-6 待核(若埋点无 versionId 维度,这一戳暂时打不出,软依赖)。
|
||||
|
||||
第十步,也是创作者在整条链上**唯一**被打扰的一步:制作人席把 `VersionCard`(`thumb`＋`oneLiner`)连同预览版推给创作者,创作者上手玩。这落制作人席「档 1＝做完给试玩,确认的最好形式是玩预览版、不是读计划」。
|
||||
|
||||
**场景 A 结论:通,附一处机制补充条件。** 十步全程可指认承接席与消费/产出工件字段,创作者被打扰点确实收敛到最后试玩一步(档 1)——这个档 1 在「confirmFloor 对 additive/breaking 细分＋确认档终判推迟到 SpecDelta 产出后」这个 fable 合并期已采纳的口径下成立。走查另暴露多处 schema/配方缺口与软依赖,逐条记入 §7 台账——终审已逐条裁定:缺口②③④⑤随 schema 修补闭合,缺口⑥经源码核实闭合(文件级枚举锁、非目录 glob,硬断点不成立)。
|
||||
|
||||
#### 场景 B · 从已发布版回退分叉
|
||||
|
||||
**一句话**:玩家反馈 V23 起变难,创作者说「回到 V19 那个手感,但雨天夜市那个场景(V21 加的)要留着」,这句话要走成一条以 V19 为基线、又带上雨天的新版本 V24,全程创作者只在「碰玩家存档、先问一次」这一处被打扰。
|
||||
|
||||
**走查推演。** 这一场景把 §4 的四条版本机制逐条上受力。第一步落在**制作人席**。它消费「用户现场快照」块承载的原话与场景注册表。这句话是复合意图——回退到 V19 ＋ 保留 V21 的雨天。注册表里回退是 `version.rollback`、保留某功能重实现是 `version.fork`(意图重放);「回 V19 但留雨天」的本质是以 V19 为基线、把 V21 的雨天意图重放上去,落 `sceneId=version.fork`(`route.terminalSeats=[design, impl]`、`defaultConfirmTier=2`、`confirmFloor=2` 因 `irreversibleSources` 含 `saveData`、`producesWorkOrder=true`)。回退碰玩家存档,`confirmFloor=2` 焊死,这一场景注定要先问创作者一次——档 2。走查在此就答出被打扰点:场景 B 与场景 A 的档位差别,正来自「碰玩家持久化数据永远先问」。
|
||||
|
||||
第二步是机制一「版本卡时间线」。**制作人席**用只读的台账查询工具,从「功能台账投影」块(版本线)拉出 `VersionCard[]` 列表(全量列表在制作人席 context 的省略目录里、只给检索句柄)。呈现给创作者的每张卡是 `thumb`(缩略图)＋`oneLiner`(一句人话),不是 git log。创作者据此指认 V19。这一步字段齐(VersionCard.thumb/oneLiner),走得通。
|
||||
|
||||
第三步是机制二「基线资格戳」。**制作人席**消费 V19 那张 `VersionCard.baselineStamp={gatesGreen, telemetryNonRegression, qualifiedAt}`,确认 V19 当年门全绿(`gatesGreen=true`)且线上指标没劣化(`telemetryNonRegression=true`),坐实 V19 是一个合格基线。字段齐,但 `telemetryNonRegression` 依赖遥测能按 `versionId` 切片——O-6 待核,若埋点无 versionId 维度,这一戳的「不劣化」判不出(软依赖,§4 机制二已挂同一待核)。
|
||||
|
||||
第四步是机制三「存档兼容检查器」。检查器是工具、不是席,由**制作人席**在回退前调它。它消费三样:V19 的 `VersionCard.compatStamp={saveSchemaVersion, compatibleFrom}`、当前 V23 存档的 `saveSchemaVersion`、以及历史 SpecDelta 链里 V22 那条的 `saveDataImpact`(菜谱表在 V22 加过字段、`changed=true`)。检查器判出 V23 存档的 schema 版本高于 V19 的 `compatStamp.compatibleFrom`——V23 存档在 V19 打不开。到这里走查撞上本场景第一个 schema 缺口(缺口①):检查器判出「不兼容」后,§4 要求「把选项翻成人话(迁移／重置／放弃)交创作者」,可这三个选项该挂哪个工件?`optionsInProductLanguage[]` 在 §3 里只长在 `EscalationEvent` 上,而 EscalationEvent 的方向是「任一席→制作人席」、`producedBy.actorKind` 必须是席位(seat);检查器是工具、产不了 EscalationEvent;制作人席→创作者这个方向,九类工件里只有 `VersionCard`,而版本卡是「版本结果通知」、不是「回退前请你选」的决策请求。**走查当时的 schema 里,「制作人→创作者决策请求」无处落——档 2 的「先问」缺工件承载。** 走查照实标:逻辑清楚(检查器判不兼容→翻人话→创作者选),但承载「翻人话选项」的工件缺位。〔已闭合·终审:不加第十类工件——升级事件方向扩为「任一席→制作人席;制作人席→创作者(终端升级)」,EscalationEvent 增 presentedTo(producer/creator)与 answer{chosenLabel, answeredAt} 字段:档 2「先问」= 一条 presentedTo=creator 的升级事件,创作者的选择落 answer、status 随之 resolved,进账本可回放。理据:工件承载的是席间与升级链的交接,创作者正是升级链的终端裁决人,§3⑦。〕
|
||||
|
||||
第五步,创作者在档 2 做出选择(迁移／重置／放弃其一),这是场景 B 里创作者被打扰的那一次。走查要答的第三问「玩家存档迁移谁负责」在这一步分两层:创作者自己的开发存档,走 SpecDelta.migrationNote 登记迁移规格(主设计席)＋实现席写迁移器代码,这条链九类工件能表达;但**线上全体玩家的存档**是另一回事——回退把 live 从 V23 切回 V24(≈V19)后,所有还揣着 V23 存档的真实玩家,其存档 schema 版本高于 V24,会集体不兼容。§4 的兼容检查器锚在「创作者回退前比对目标版本与当前存档」,针对的是创作者视角的单份存档,并不覆盖「回退后线上批量玩家存档降级」这个更大的面。**谁负责线上玩家批量存档迁移、用什么机制,§4 与九类工件都没给**(缺口⑧)。走查第三问因此只能部分作答:创作者侧迁移有主、线上批量迁移无主。〔归属已定·终审:定性为开放实装项而非 schema 缺口——v1 兼容检查器只管创作者预览与新进玩家,存量玩家批量迁移是运营窗口的人在环动作,机制随 L2 版本闭环实装另设计;前置事实(存档面定容/versionId 维度)归 O-6 核实,§4.3 已补边界句。〕
|
||||
|
||||
第六步是机制四「意图重放取代 merge」,也是本场景的执行命脉。「保留雨天」不走代码合并,走意图重放:取 V21 那张雨天工单的意图,在 V19 基线上重新实现、过同套验收。**制作人席**从 V21 的 `VersionCard.appliedIntents`(`workOrderRef[]`)里取出雨天事件那张工单的 ref,拉回原始 `WorkOrder` 的 `goal`＋`acceptance`(工单工件已持久化)。雨天在 §1.1 里是事件表 event 的一个天气类条目、连一个场景 assetId,独立可回放。制作人席据此铸新工单,`goal` 沿用 V21 雨天工单的 goal、`deps` 指向 V19 基线,交主设计席(若雨天涉及事件表 schema 增量则产 SpecDelta)＋实现席(重实现雨天逻辑)＋资产席(雨天场景 assetId)。约束守 §4:重放的是意图不是 diff,重实现出的代码与 V21 原实现不同是预期,`acceptance` 门等价才是判据。
|
||||
|
||||
这一步撞上场景 B 的硬前置,走查必须如实引用、绝不写成已就位:意图重放要能「按 versionId 取回 V19 的源工程、装载、在其上重新生成」。取回并重建 V19 源工程这条通道 ＝ A3.5 版本寻址 ＋ W-ASSET-SRC 源工程长期存储／版本寻址,而 `DeliveryPackage.sourceProjectRef` 的源工程寻址也压在同一处(VersionCard 本身只持 versionId,同样经 W-ASSET-SRC 按 versionId 二跳解析回源工程,不自带寻址锚)。§4 自己已挂「session 三加载路径中『加载已有工程』的 workdir 指向机制,与『按 versionId 取回重建再装载』的接缝」交 O-6 核实;而 **W-ASSET-SRC 首段尚未排期**。所以场景 B 的意图重放,逻辑设计完整(取意图→在旧基线重实现→过等价验收),但它的执行通道压在一个未排期的前置上——机制成立、通道未就位。
|
||||
|
||||
第七步,重放的三席(主设计／实现／资产)各产 `DeliveryPackage`,门产 `EvidencePackage`,**评审席(盲)**产 `Verdict`,判据是过 V21 原工单的同套 `acceptance`(验收等价)。这条与场景 A 第六到八步同构,字段齐。
|
||||
|
||||
第八步回到**制作人席**,产出 V24 的 `VersionCard`:`versionId=V24`、`baseVersionId=V19`(基线是 V19、不是 V23——这就是分叉)、`appliedIntents=[V21 雨天工单 ref]`、`compatStamp={saveSchemaVersion, compatibleFrom}`。走查要答的前两问在这一步撞上第二个 schema 缺口(缺口⑦)。「分叉后旧线(V20–V23)怎么标记」——VersionCard 有 `versionId`／`baseVersionId`,能表达「V24 的基线是 V19」这层父子关系,但**没有任何字段表达「这条线是 live／已归档／被分叉废弃」**;创作者回看版本卡时间线,哪张是当前线上版、哪条线已被 V24 取代,工件层看不出来。「live 指针何时切」——§4 定 live 指针＝现行 publish 审核门后的指针切换:V24 过评审 accept 后,制作人席用「版本决策提案」工具提议切指针,走注册表的 `publish` 场景(`producer→review 审核门→指针切`、`confirmFloor=2` 因 `liveState`),审核门过了指针才切到 V24、回退＝指针回切。这条流程能走通,但 live 指针本身是 game-cloud 版本域的状态(§4 映射)、不落在九类工件里,走查当时 VersionCard 也无从表达一张卡属于哪条线。〔已闭合·终审:VersionCard 增 lineId(铸卡时所属版本线,不可变);**线状态与 live 指针刻意不上卡**——卡是通过验收的不可变工件,active/superseded/live 是发布域与账本的可变状态,写进卡则每次切线都得回头改历史工件;创作者看到的时间线视图由账本按 lineId join 线状态呈现(哪条线活跃、哪张卡是 live 一目了然),分叉关系由「新 lineId + baseVersionId=分叉点」表达,§3③/§4.1 同步。〕走查第一、二问的答案就此补齐:切换流程有主(publish 审核门＋版本决策提案),线归属在工件层(lineId)、线状态在账本视图层,各归其位。
|
||||
|
||||
**场景 B 结论:通,带一处硬前置、三处 schema 缺口。** 四条版本机制逐条可指认字段:版本卡时间线(thumb/oneLiner)、基线资格戳(baselineStamp)、兼容检查器(compatStamp＋历史 saveDataImpact)、意图重放(appliedIntents→原工单 goal/acceptance)在 schema 上都接得住。但意图重放的执行通道压在未排期的 W-ASSET-SRC 首段＋O-6 待核的 session workdir 接缝上。走查当时三问因三处缺口不能全答;终审后:缺口①闭合(升级事件扩 presentedTo/answer,「翻人话交创作者」有了载体)、缺口⑦闭合(VersionCard 增 lineId,线状态由账本视图承载)、缺口⑧归属已定(线上批量迁移 = L2 实装期运营机制,O-6 先核前置)。前两问经 schema 修补可答满,第三问的机制设计归 L2 实装期——硬前置(W-ASSET-SRC)不变。
|
||||
|
||||
#### 场景 C · 第 N 千次修改
|
||||
|
||||
**一句话**:第 1400 次改动,创作者一句「高峰期太卡了」,这句话要先被当成一次诊断咨询(只读即答、不动一行代码),等创作者点头要修,再转成一张性能工单——而这张工单在铸造的一瞬间,必须自动撞上「第 300 次改动曾为正确性关掉渲染合批」这条决策史,拦住盲目重开旧优化。
|
||||
|
||||
**走查推演。** 第一步落在**制作人席**。它消费「用户现场快照」块与场景注册表,把这句话匹配到 `sceneId=diagnose.query`(`sceneFamily=诊断咨询`、`route.terminalSeats` 空、`defaultConfirmTier=0`、`confirmFloor=0`、`producesWorkOrder=false`)。`producesWorkOrder=false` 是这一族的定义性字段——诊断咨询只读即答、不铸工单。走得通。
|
||||
|
||||
第二步守制作人席「模糊请求五步」的头一条「现场快照先于追问」。制作人席消费「用户现场快照」块(性质＝事实、出处戳＝会话态即时),读出创作者此刻在玩哪个版本、最近触发了什么事件——「它太卡了」的「它」九成是刚碰过的东西。这里读出的是刚触发过高峰潮汐(§1.1 事件表 event 的潮汐类型)。字段齐。
|
||||
|
||||
第三步是遥测佐证。制作人席用只读遥测查询工具、消费「遥测摘要」块(帧率窗、按版本切片、性质＝推断),坐实高峰掉帧真存在、定位在高峰渲染。这条对应 §1.1.1 那条「同屏最大顾客数 vs 帧率」曲线——它既是高峰玩法强度旋钮、也是渲染性能闸,正是这次改动的数值宿主;量级对齐 §3 LoopbackOrder 示例(帧率 P75@高峰 48fps→31fps)。软依赖同前:帧率按版本切片依赖遥测 versionId 维度(O-6 待核)。
|
||||
|
||||
第四步,制作人席只读即答,把「高峰渲染没分帧、掉帧与你刚触发的潮汐吻合」讲给创作者。走查在这一步撞上一个与缺口①同源的缺位:这份「诊断答复」是制作人→创作者方向、又不是版本卡,九类工件里没有承载它的一类。可论证诊断答复是同步对话、不必留痕成工件;但本节命题要求「数千次改动后 context 装配不被历史噪音淹没(账本投影)」——若诊断也要可回放、可进账本,答复就该留痕。这归入缺口①同一类,走查标出、不在此展开。〔已裁·终审:诊断答复不进工件存储——它是同步只读问答,落 trace(带 traceId)留痕即可回放,账本要引用时经 trace 检索;工件面只承载改变系统状态的交接,只读问答若工件化,账本会被咨询噪音淹没,恰与「投影不被历史噪音淹没」的命题相悖,§2.B 判读要点同步。〕创作者被打扰?此步是创作者主动问、制作人答,档 0,算不上打扰。
|
||||
|
||||
第五步,创作者看完诊断说「那修一下」,制作人席这才转出一张性能工单——这是**第二次分诊**,按注册表判读走 `modify.behavior`(性能优化要改渲染/玩法代码)。诊断咨询只读不铸单的口径在此兑现:工单铸造发生在创作者确认之后的这一步。到这里为止,场景 C 的前半程(诊断→只读→转工单)逐步可指认承接席与字段,走得通。
|
||||
|
||||
第六步是场景 C 的立身之本——决策史对撞——也是走查判定场景 C 断裂的地方。本节命题与场景注册表都明确:对撞发生在「(转出来的这张)工单铸造时」,即**制作人席铸单的一瞬**,要自动撞上「第 300 次改动为正确性关掉渲染合批(renderBatch)、当时有判定书」,拦住「高峰优化最直接手段＝重开合批」这个会复发旧 bug 的走法。走查逐字追这个「自动对撞」怎么在 schema 上发生,撞出两道断点。
|
||||
|
||||
其一,**对撞的时机在 schema 上落不下**。§3 把承载对撞结果的 `decisionHistoryHit`(`{priorVerdictRef, conflict}`)字段只挂在 `EscalationEvent` 上;而 EscalationEvent 场景 C 示例的 `producedBy.actorId` 写的是「实现席#perf」(actorKind=seat)、`reason.code=decision_history_conflict`——也就是把对撞放在**实现席执行到一半、发现要动 renderBatch 才升级上报**,这比命题要求的「制作人席铸单时对撞」晚了一整个执行阶段。而 `WorkOrder`(工件①)自身没有 `decisionHistoryHit` 字段——制作人席铸单那一刻,即使想对撞,也没有字段把「本工单触及 D300 决策」这个结果记进工单。铸单时对撞在 schema 上无落点,只能退化成实现席执行时的兜底升级,与「工单铸造时自动对撞」不符。
|
||||
|
||||
其二,也是更硬的一道——**对撞的数据基础在九类工件里根本不存在**。要在铸单时(或任何时候)自动撞上「D300 为正确性关闭 renderBatch」,系统得能拿着新工单的拟改动面(renderBatch)去查一个结构化的决策史,命中一条「决策＝关闭 renderBatch、受影响面＝renderBatch、理由＝正确性、约束＝不得重开」的条目。这条决策史条目从哪来、长什么样?§3 的 `decisionHistoryHit.priorVerdictRef` 指向「D300 判定书」,即假定决策史＝历史判定书集合。可判定书 `Verdict`(工件②)的字段只有 `decision`(accept/fix/kill)、`perCheck[]`、`ftueNotes`——它**装不下「这次为正确性关闭了 renderBatch 这个可改面、且以后不许重开」这层决策语义**。制作人席 context 配方虽然列了「决策史」块(出处戳＝决策日志条目 ts＋关联工单),但「决策日志条目」的 schema 在九类工件里没有定义,`priorVerdictRef` 指过去的判定书也接不住这层语义。**决策史对撞所依赖的「决策史条目」这类数据,既不是九类工件的任何一类,判定书也承载不了它——场景 C 的核心机制没有数据基础**(缺口⑨,含前一道对撞时机字段落点)。
|
||||
|
||||
走查到此如实定性:场景 C 的前半程(诊断咨询、只读不铸单、二次分诊转工单)走得通、字段可指认;但它区别于普通性能改动、也是它被选为北极星走查场景的**唯一理由**——「决策史在工单铸造时自动对撞、拦住重蹈覆辙」——在走查当时的九类工件 schema 下走不通:对撞的数据(决策史条目)无 schema、对撞的时机(铸单时)在 WorkOrder 上无字段。两道断点按走查纪律标断回终审。
|
||||
|
||||
〔已闭合·终审(缺口⑨,场景 C 据此回写为通):**不加第十类工件——约束性决定以字段形态长在既有工件上,对撞做成 harness 机械动作。**四件套:其一,判定书 Verdict 与升级事件 EscalationEvent 各增可选 `decisions[]:{constraint, scope:{files[],tables[],systems[]}, rationale, standingUntil?}`——约束性决定天然产生在两处,评审判定时(「合批保持关闭」随判定书落档)与升级裁决时(制作人席/创作者拍板的约束随升级事件收口落档),D300 那条即 `Verdict-300#/decisions/0`。其二,账本对全量 decisions[] 按 scope 维护倒排索引(决策索引)——账本本就是机器生成的投影,索引是它的一部分、不是新工件;制作人席 context 配方里的「决策史」块 = 该索引按工单拟改动面的投影。其三,WorkOrder 增 `decisionRefs[]`:铸单时 harness 拿工单 scopeWhitelist 机械检索决策索引、命中即自动注入——对撞是确定性检索,按「判定确定化→做成门」戒律归 harness,不设席、不靠模型自觉;冲突真伪与怎么办的判断留席位。其四,EscalationEvent.decisionHistoryHit(priorDecisionRef 指向 decisions 条目)保留为实现席执行期二道网——铸单对撞漏网(如 scope 声明不全)时,实现中撞上约束仍能升级。时机矛盾就此消解:铸单 = 制作人席 decisionRefs(一道网),执行 = 实现席 decisionHistoryHit(二道网),§3①②⑦ 同步。〕
|
||||
|
||||
补上对撞一步的走查:制作人席铸性能工单,`scopeWhitelist.files=["src/systems/render*"]`;harness 以该 scope 检索决策索引,命中 `Verdict-300#/decisions/0`(constraint="renderBatch 保持关闭"、scope.systems=["render"]、rationale="正确性:合批引发顾客层级显示错误"),自动写入 `WorkOrder.decisionRefs=["Verdict-300#/decisions/0"]`;实现席#perf 拿到工单即见约束,首选方案改为分帧生成顾客;若它仍试图动合批,执行期二道网升级(§3⑦ 示例正是这一幕),制作人席把两个选项翻成人话交创作者(presentedTo=creator)。每步席位、工件、字段可指认,链路闭合。
|
||||
|
||||
**场景 C 结论:通(经终审补 schema)。** 走查当时判断为断——断点二处:对撞数据(决策史条目)无 schema、对撞时机(铸单时)在 WorkOrder 上无字段;终审以「decisions[] 落判定书/升级事件 + 账本决策索引 + WorkOrder.decisionRefs 铸单机械注入 + decisionHistoryHit 执行期二道网」四件套闭合(见上),对撞一步的席位-工件-字段已补入推演。走查末问「context 装配不被历史噪音淹没」随之落地:决策史块 = 决策索引按拟改动面的投影,有了结构化源,投影不再是空话。
|
||||
|
||||
#### 裁决点(本节)
|
||||
|
||||
标的品类＝经营、复杂度锚＝肥鹅美食街级,已随 W-NSTAR 立项定死;概念名与具体系统组合是填肉自由度,O-1 可改,但系统数不得低于 8、数据表不得低于 10,低了撑不开测试用例的受力面。以上骨架期裁决不变。走查在此之上追加三条,均因走查证据触及骨架冻结面,回 fable 终审:
|
||||
|
||||
- **场景 C 判断(已裁·终审 2026-07-06)**:不补「决策史条目」独立工件——约束性决定以 decisions[] 字段长在判定书与升级事件上(决定产生的两处即其落档处),账本建决策索引,WorkOrder.decisionRefs 承载铸单时机械对撞、EscalationEvent.decisionHistoryHit 保留执行期二道网。场景 C 据此回写为通。
|
||||
- **场景 A 确认档口径(已签认·终审 2026-07-06)**:confirmFloor 对 additive/breaking 细分(additive 不顶 2)＋确认档终判推迟到 SpecDelta.saveDataImpact 已知之后——N3 已将其结构化为 confirmFloorRule 字段(§2.B),细分稳,场景 A 走档 1 成立。
|
||||
- **九类工件是否补第十类(已裁·终审 2026-07-06)**:不补第十类,以字段扩展闭合——缺口①升级事件扩 presentedTo/answer(创作者 = 升级链终端裁决人)、缺口⑦版本卡加 lineId(线状态归账本视图)、缺口⑨ decisions[]/decisionRefs 落既有工件;诊断答复(①后半)裁为 trace 留痕、不工件化。九类的「类」不动,冻结面按终审程序扩字段。
|
||||
|
||||
## 2. 席位架构初裁
|
||||
|
||||
**命题:席位分的是结构,不是能力;v1 立 6 席,3 个〔提案〕席缓立,健康自检=席位数从此不随游戏复杂度涨。** 依据分席四判据(context 食谱/写权限互斥/验证独立/生命周期)与两条不设席戒律(判定确定化→门,调度确定化→代码)逐席过尺:
|
||||
|
||||
| 席位 | 裁决 | 理由(命中判据)与认领胚胎 |
|
||||
|---|---|---|
|
||||
| 制作人席 | **立** | 分诊、工单铸造、三档确认、版本决策提案是不可归约判断;唯一面向创作者的常驻责任线。胚胎=A11 `/modify/plan` 两段式(判意图→确认→执行)+ 场景注册表。 |
|
||||
| 主设计席 | **立(瘦版)** | 场景 A 没有它就没人产规格增量与存档 schema 登记——契约变更是复杂游戏区别于模板小游戏的分水岭;且命中验证独立(实现席绝不能自改契约)。瘦版=只管两件:系统契约/数据 schema 的规格增量 + 「模糊词→可调面」映射表。 |
|
||||
| 实现席 ×N | **立** | 胚胎最厚:cheap-worker/tier2 worker + RepairMiddleware + write_whitelist 全在跑。缺口只两条:工单化收窄(白名单从档位级收到工单级)+ journal 写前意图协议。 |
|
||||
| 内容席 | **立** | 经营品类数据表是工作量大头,且「过校验器的数据表」大半机器可判——便宜模型档即可,写权限与实现席天然互斥(只写表不写码)。 |
|
||||
| 资产席 | **立(薄)** | 复用 B-ASSET-mmx provider 生成链;资产 prompt 大半可模板化(风格锚+类型模板),席只留清单执行与元数据登记的薄判断。资产规划(要哪些)归主设计席,不归它。 |
|
||||
| 评审席(盲) | **立** | 胚胎=gate_judge + 九门。北极星增量:九门之上的设计符合性(L2)判读需要 LLM 评审,盲评纪律(不见实现会话)在席位层落地;判定书 schema 见 §3。 |
|
||||
| 数值仿真席 | **缓(v2),快进仿真器先做成工具** | 两条戒律第一条:数值平衡判定大部分可确定化——仿真器快进跑千局出曲线是门/工具,不是席。v1 由主设计席戴帽消费仿真结果;只有「曲线好不好玩」的判断长期留席位。仿真器可行性见 §2.C。 |
|
||||
| 馆长席 | **缓(v2),机器门 + 抽查代位** | 蒸馏守门 v1 量小;docs-gate/rubric-sync-gate 范式已证明查重对账可机器化。回写分道纪律 v1 就立(journal/坑增量只走自己的道),缺的只是守门人,先由 harness 查重门代。 |
|
||||
| 玩家席 | **缓(v2)** | 九门真玩 driver + play-spec 已覆盖「能不能玩」;persona 体验报告的价值在调优期。上线后优先接真实遥测(回流工单),合成玩家排后。权宜:评审席判定书加 FTUE 检查项。 |
|
||||
|
||||
一处必须先划清的边界:**tier2 阶段 1 的 design_team(AgentCreate/TeamSay 星形)不违反「禁自由对话」**。星形账本通信约束的是**席位之间**(跨工单、跨生命周期)的交接;design_team 的 worker-as-tool 是**席内**一次装配的内部结构——worker 生命周期在单 POST 内、不产跨席工件、其结论最终收敛为 leader 的单一产出。席间走工件,席内怎么想是席位自己的事。这条边界让现行 tier2 两阶段范式原样成为主设计席(阶段 1)与实现席(阶段 2)的胚胎,不必推翻。
|
||||
|
||||
每个立席的席位,都是「prompt 宪法 + context 配方 + 工具面 + harness」四层的一个版本化组合,整组落在配置控制面按 POST 现装配;四层各自的取舍是:prompt 只列判断性宪法要点(可门化、可模板化的规范不进这里);context 列承重块清单,每块标出处戳性质,并给省略目录(未推送但可检索的项);工具面列运行时应有的工具全集(即「声称面」),其与框架默认注入面的差额由 §2.A 审计逐席对账;harness 列过程壳。凡标「胚胎」处即 §2 已认领的现有落地物,配方在其上生长,不平地起楼。
|
||||
|
||||
##### 制作人席(常驻,唯一面向创作者)
|
||||
|
||||
- **prompt 宪法要点**:分诊协议——把创作者一句话判成意图类 + 路由 + 风险,只判不执行;可信边界铁律(模型给的 mode 不采信,一律按意图类落路由,胚胎 `cheap_classify.py:121`)。三档确认判据,可逆性替代确认:档 0 静默直做(参数级、一键可撤),档 1 做完给试玩(新功能默认,确认的最好形式是玩预览版不是读计划),档 2 先问再做(仅不可逆/贵/与既往决定冲突三类)。模糊请求五步:现场快照先于追问、模糊词落设计轴、遥测佐证纠偏、收敛按序(试玩变体 > 选择题 > 追问,永不出开放问答)、判读入档。升级协议:范围失控发升级事件,不硬扛;禁技术方案——不产代码、不碰实现细节,越界即角色投影错误。
|
||||
- **context 配方(承重块 + 出处戳)**:功能台账投影(版本线/在飞工单/门态,账本机器生成、禁聊天回放;性质=事实);决策史(为什么某处不能乱动,防第 N 千次改动把第 300 次的深思当垃圾;性质=事实);遥测摘要(漏斗卡点/留存/帧率窗,按版本切片;性质=推断);用户现场快照(在玩哪版哪景 + 最近触发事件;性质=事实)。省略目录:全量版本卡列表、完整 journal、契约与数据 schema 全文——只给检索句柄,不推全文。
|
||||
- **工具面(声称面,白名单)**:台账查询(只读)、遥测查询(只读)、账本决策索引查询(只读;缺口⑨终审件,铸单对撞的检索面)、工单铸造(create_work_order)、版本决策提案;**无任何代码/写工具**(范围失控在根上被断)。胚胎 `cheap_classify.py:26` 已实践该收窄:判意图只喂三个可改面文件,连读全码都不给。运行时对账见 §2.A:制作人席是「框架默认工具与角色冲突最彻底」的一席——Service 路必须封六内建 + 剔 Planning/Team/Schedule,extra 工厂不得注入任何写工具。
|
||||
- **harness**:场景注册表路由(§2.B),分诊按注册表驱动、新场景显式增列;两段式(判意图→前端确认→执行,胚胎 A11,同时绕开 goal-loop 的 input-required 暂停 P0);档 2 事项强制挂决策点(goal-loop 铁律:仅档 2 自动暂停),里程碑产版本卡供异步试玩;铸单时 harness 以工单 scope 机械检索决策索引、命中自动注入 WorkOrder.decisionRefs(缺口⑨终审件——对撞是确定性检索,不靠模型自觉)。
|
||||
|
||||
##### 主设计席(常驻,瘦版)
|
||||
|
||||
- **prompt 宪法要点**:契约变更纪律——凡触碰存档 schema 的规格增量,必登记数据版本(落 SpecDelta.saveDataImpact,§3④);只管两件——系统契约/数据 schema 的规格增量 + 「模糊词→可调面」映射表(数据驱动使「改简单」=参数提案而非代码重写);禁写实现代码(只产规格不落码,是验证独立铁律的上游端——实现席绝不能自改契约,故契约的产与改必须独立成席)。
|
||||
- **context 配方(承重块 + 出处戳)**:系统契约(现行 contract registry,出处戳=契约版本号、事实);数据 schema(schema 版本、事实);决策史(与制作人席共源,防规格与历史决定冲突);仿真结果(只读消费,v1 由本席戴帽消费快进仿真器输出,出处戳=仿真跑批 ts + 局数、推断)。省略目录:实现细节、历史版本规格全文——给检索,不推。
|
||||
- **工具面(声称面,白名单)**:契约注册表读写、schema 校验工具、快进仿真器(只读);无代码写。运行时对账见 §2.A:胚胎 tier2 阶段 1 design_team 是 leader + 四专家 worker-as-tool 的席内结构(席内自由、席间走工件),CLI 纯库路只拿设计 worker 工具、无框架默认工具;Service 化则同样踩 get_toolkit 坑。
|
||||
- **harness**:规格增量必过 schema 校验器才发布(不过不出席);design_team 星形 worker-as-tool(胚胎 `roles.py:66-69`:纯库 import Agent 无 create_app,故星形用 worker-as-tool,leader 是唯一中心、worker 之间不互通)。
|
||||
|
||||
##### 实现席 ×N(工单席,可并行)
|
||||
|
||||
- **prompt 宪法要点**:单系统职责(只在本工单白名单内动,工单级白名单比档位级更窄);诚实红线(commit hash 必须真实可 rev-parse,禁谎报 DONE、禁自评门绿);只改白名单内文件,其余保持不变、需要上下文就读不写(胚胎 `cheap_toolkit.py:75-80` write_whitelist basename 拒 / `tier2 toolkit.py:168` 平台锁定文件拒)。
|
||||
- **context 配方(承重块 + 出处戳)**:单工单六要素 + 白名单文件(出处戳=工单铸造 ts、事实);品类坑清单(知识库版本、事实/经验)。省略目录:非可改面的 plumbing 文件不喂(胚胎 `cheap_classify.py:25`「其余 plumbing 文件不喂」),只给读句柄。出处戳纪律:三天前的构建状态与刚跑完的门结果必须能被区别信任。
|
||||
- **工具面(声称面,白名单)**:便宜档六工具(read_file/list_dir/write_file/check/build/finish,`cheap_toolkit.py:118-121`)或 tier2 九工具(scaffold_init/write_source/validate_datatable/build/headless_check/run_gates/read_verdict/screenshot/query_asset/finish,`tier2 toolkit.py:368-378`);写工具在工具层强制白名单(cheap write_file 校 write_whitelist / tier2 write_source 校 LOCKED_PLATFORM_FILES),build/test 只读产物,契约/门结果查询只读。**运行时对账重点席**(§2.A):CLI 路声称即真拿到,Service 路若不封口,框架内建 Write/Edit/Bash 完全旁路上述白名单(cheap 已双补丁封 / tier2 未封=审计 A4)。
|
||||
- **harness**:RepairMiddleware 续修(on_reasoning 洋葱内拦 finish、注入门失败反馈续跑,胚胎已落);软预算两段式(soft_budget 档位软停不断链、hard 保底);journal 写前意图 + 离场清账——**缺口**:现状实现席无 journal 协议,L1 切片补(§5 L1)。
|
||||
|
||||
##### 内容席(工单席,便宜档模型)
|
||||
|
||||
- **prompt 宪法要点**:数据表纪律——只改表不改码(与实现席写权限天然互斥,这是它独立成席而非并入实现席的判据);表 schema 忠实——按平台锁定的固定 key 消费,自创 schema 会让系统空转(胚胎 `tier2 toolkit.py:191-197` validate_datatable「自创 schema 会让合成系统空转、三联动门全挂」)。
|
||||
- **context 配方(承重块 + 出处戳)**:表 schema + 样例行 + 数值曲线锚(出处戳=schema 版本 + 曲线锚来源、事实/推断)。省略目录:代码文件、其他表全文——不喂。
|
||||
- **工具面(声称面,白名单)**:表编辑(限 data/*.json)+ 校验器(validate_datatable);无码写。运行时对账见 §2.A:内容席是便宜档模型,Service 路封六内建尤其关键——否则内建 Write 可写码文件,「只改表」的互斥被击穿。
|
||||
- **harness**:校验器不过不出席(validate_datatable 门;可达性不变量:合成链非空/DAG/订单可达)。
|
||||
|
||||
##### 资产席(工单席,薄)
|
||||
|
||||
- **prompt 宪法要点**:风格锚忠实、元数据完整;资产规划(要哪些)不归它、归主设计席,本席只做清单执行与元数据登记的薄判断。
|
||||
- **context 配方(承重块 + 出处戳)**:资产清单工单 + 风格锚 + 包体预算(出处戳=工单 ts + 风格锚版本、事实)。省略目录:全量资产库、其他类目——给检索(query_asset 按类目查,不感知底层 provider)。
|
||||
- **工具面(声称面,白名单)**:mmx 生成 + 登记(胚胎 B-ASSET-mmx provider + `tier2 toolkit.py:295-308` query_asset 占位,「只查/取引用,不生成」);无逻辑写。
|
||||
- **harness**:体积门、命名规范门(双端分包上限逼资产走体积门,§1.1.3)。
|
||||
|
||||
##### 评审席(工单席,盲)
|
||||
|
||||
- **prompt 宪法要点**:判定纪律——只认证据,不认自述(run_gates/read_verdict 的 verdict 由 judge 纯代码产出,不采信 agent 上报,胚胎 `tier2 toolkit.py:16`「验收零自评」+ gate_judge 归一契约);刻意致盲——context 配方里不含实现会话的存在(出题的不能是被考的;继承推理等于继承盲区)。
|
||||
- **context 配方(承重块 + 出处戳)**:规格 + 交付包 + 证据包(出处戳=门跑 ts + commit hash、事实);**刻意致盲块**——不注入实现会话、不注入前任心路,修复轮只给「上一版代码 + 门失败证据」;失败必带 phaseNow(游戏此刻卡在哪个 phase,胚胎 `gate_judge.py:121` _latch_phase_now,两条失败支都认)。
|
||||
- **工具面(声称面,白名单)**:只读 + 九门(run_gates/read_verdict)+ 快进仿真器(只读);**零写工具**。运行时对账见 §2.A:评审席是「必须封框架默认工具」理由最硬的一席——它绝不能拿到任何写工具,更不能拿到 Team/AgentCreate(spawn worker 会破盲评隔离、让 worker 看见实现会话);Service 路双补丁对评审席不是可选优化,是致盲纪律在工具层的落地。
|
||||
- **harness**:fresh 会话(异档模型当多样性来源,缓解同源风险);判定书 schema 强制(§3② 并存形态);失败必带 phaseNow。
|
||||
|
||||
> 配方密度镜像原则:便宜模型席位(内容席、部分实现席)零裁量、全铺开;贵模型席位(制作人、主设计、评审)给索引让它自拉。这条随席位模型档位调,不是每席一刀切。
|
||||
|
||||
### 2.A 框架默认注入面审计
|
||||
|
||||
设席八问的第八问——「框架默认注入的能力面审计过、与白名单对账了吗」——骨架期统一记为未过,由本节逐席补。一句话结论:**在 AgentScope Service 路上,一个席位运行时真正拿到的工具面,不等于它配方里声称的那几个工具,而是「声称的 N 工具 + 15 件框架默认工具」;这 15 件里含能写任意路径的内建 Bash/Write,足以旁路任何一席在自己工具层焊死的写白名单。** 对账不做,配方就是一纸空文。
|
||||
|
||||
#### 2.A.1 框架默认注入面从哪来:get_toolkit,不是 build_toolkit
|
||||
|
||||
AgentScope 2.0 有两条把 Python 函数变成 agent 工具的路径,受力面完全不同:
|
||||
|
||||
- **CLI 纯库路**(`Agent(toolkit=...)`,无 create_app):toolkit 就是项目自己 build_toolkit 的产物,agent 拿到的工具 = 显式声明的那几个,一件不多。cheap CLI = 六工具(`cheap_toolkit.py:118-121`),tier2 CLI = 九工具 + 可选 MCP(`tier2 worker/toolkit.py:368-397`)。声称面 = 运行时面,无旁路。凭据:`roles.py:66-68` 明示「本线是纯库 import Agent 跑脚本(无 create_app)」;`ws_builtin_tools_patch.py:10` 明示「CLI 路从来只有六工具」。
|
||||
- **Service 路**(`create_app`,多租户/多会话/REST+SSE):agent 由框架在每个 chat 回合内部装配,装配的唯一入口是 `get_toolkit`(`app/_service/_toolkit.py:27`)。项目的九/六工具只能经 `extra_agent_tools` 工厂合进框架自建 toolkit 的 basic 组(`cheap_service_app.py:459` / `tier2 service/app.py:277`),而框架在合并你的工具之前,已经无条件并入了一整套默认工具。
|
||||
|
||||
`get_toolkit` 无条件并入的清单,逐行坐实(2.0.2 源码,`app/_service/_toolkit.py`):
|
||||
|
||||
| 组 | 工具 | 源码出处(2.0.2) | 条件 |
|
||||
|---|---|---|---|
|
||||
| workspace 内建 ×6 | Bash / Edit / Glob / Grep / Read / Write | `:107` `tools = await workspace.list_tools()`;定义在 `workspace/_local_workspace.py:670-679`(硬编码无开关) | 无条件 |
|
||||
| Planning ×4 | TaskCreate / TaskList / TaskGet / TaskUpdate | `:110`,注释 `:45`「Planning tools — always on」 | 无条件 |
|
||||
| Background ×1 | ToolStop | `:113` `background_task_manager.list_tools(...)` | 无条件 |
|
||||
| Schedule ×4 | ScheduleCreate / View / Delete / List | `:119-142`(schedule_tools 组) | session 配了 chat_model_config 时 |
|
||||
| Team ×4 / ×1 | source≠team:TeamCreate / AgentCreate / TeamSay / TeamDelete;source=team:仅 TeamSay | `:157-168`(按 agent_record.source inline 选) | 无条件(变体) |
|
||||
|
||||
即:一个未封口的 Service 席位,除了自己那几个工具,还平白多出六内建 + 4 Planning + 1 ToolStop + 4 Team = **15 件无条件默认工具**(session 配 chat_model_config 时另加 4 件 Schedule 条件工具组,条件态 19 件)。〔fable 合并期裁定·终审签认 2026-07-06:正名——此无条件并入的主语是框架 `get_toolkit`,不是项目 build_toolkit(后者只显式组装、从不并入内建);Service 路 15 件无条件并入(Schedule 条件注入不计),纯库 CLI 路无此并入。〕
|
||||
|
||||
#### 2.A.2 这些默认工具里,哪些是可击穿平台锁定的默认工具
|
||||
|
||||
不是这些默认工具同样危险,分三档:
|
||||
|
||||
- **可击穿写边界的默认工具(必须封)**:内建 Bash / Write / Edit。它们不经任何一席的写白名单——cheap 的六工具白名单和 tier2 的 LOCKED_PLATFORM_FILES 都焊在各自工具里,而框架内建 Write 是另一个工具、根本不过这道检查;更狠的是内建 Bash 的 cwd 是 Service 工作区、可越 workdir 触仓外(`ws_builtin_tools_patch.py:8`)。这一档直接击穿护城河。
|
||||
- **噪声/行为歪引(应封)**:Planning×4、Team×4、Schedule×4(其中 Schedule×4 仅 session 配 chat_model_config 时条件注入、不计入无条件 15 件,条件态才现)。便宜档是单机单游戏,无团队、无定时任务、不需要 agent 自管任务板;12+ 语义重叠的工具是 M3 flail(反复空转、选错工具)的根因之一(80011 生产实录)。无关工具 schema 既是注意力污染也是行为歪引。
|
||||
- **低风险残留(可留)**:Background ToolStop。它是 harness 过程控制、不碰写边界;cheap 封口后有意保留。审计如实登记它是「配方未声称、运行时拿到」的一件,但不建议改。
|
||||
|
||||
#### 2.A.3 逐席对账:声称 vs 运行时真拿到
|
||||
|
||||
| 席位 | 配方声称工具面 | CLI 路运行时 | Service 路运行时(未封口) | 现状封口 |
|
||||
|---|---|---|---|---|
|
||||
| 制作人 | 台账/遥测查询 + 工单铸造,无写 | 胚胎在 A11(两段式 CLI) | 声称 + 15(含内建 Write/Bash,与「无代码工具」直接冲突) | 未落 Service;落时必须封 |
|
||||
| 主设计 | 契约读写 + schema + 仿真读,无码写 | design_team 纯库、无框架默认(`roles.py:66`) | 声称 + 15(Team 组尤其冲突:主设计不该 spawn 实现 worker) | 未落 Service |
|
||||
| 实现 ×N | 白名单内写 + build/test + 只读查询 | cheap 六 / tier2 九,声称=真拿到 | 声称 + 15,**内建 Write 旁路 write_whitelist / LOCKED_PLATFORM_FILES** | cheap 已封;tier2 未封(A4) |
|
||||
| 内容 | 表编辑 + 校验器,无码写 | 胚胎在 tier2 validate_datatable | 声称 + 15,内建 Write 可写码文件、破「只改表」互斥 | 未落独立 Service |
|
||||
| 资产 | mmx 生成 + 登记,无逻辑写 | 胚胎在 query_asset | 声称 + 15 | 未落独立 Service |
|
||||
| 评审(盲) | 只读 + 九门 + 仿真读,零写 | gate_judge 纯代码 | 声称 + 15,**内建 Write 破零写 + Team/AgentCreate 破盲评隔离** | 未落 fresh Service |
|
||||
|
||||
一处必须点名的:cheap Service 路已用两个进程内 monkeypatch 封口(apply 序见 `cheap_service_app.py:435→443`):`ws_builtin_tools_patch` 把 `LocalWorkspace.list_tools` 换成恒返 `[]`、关掉六内建;`planning_team_tools_patch` 包装 `get_toolkit`、拿到装配好的 Toolkit 后重建干净版,按 .name 剔 Planning×4 + Team×4、丢掉整个 schedule_tools 组。封口后 cheap Service 净工具面 = 六工具 + ToolStop + skills/MCP,与配方声称面基本收敛。这两个补丁都钉 2.0.3、绝不改 venv 本体、版本漂移时响亮告警但仍应用(不应用等于开着白名单旁路,比契约漂移更危险)。
|
||||
|
||||
#### 2.A.4 审计发现 A4:tier2 Service 路未封口,平台锁定被旁路
|
||||
|
||||
证据链:① tier2 service/ 下 grep 不到任何封口补丁(零命中);② `tier2 service/app.py:106-111` 的 `_extract_function_tools` 注释白纸黑字写明有意保留框架工具面(「本壳不想绕过框架自建 toolkit……所以取折中:从 tier2 Toolkit 里取出九个 FunctionTool 实例,交给框架合并」);③ tier2 的 LOCKED_PLATFORM_FILES(10 个平台锁定文件的 frozenset 精确匹配:main.js 装载胶水 / game-core.js 状态机结算 latch / layout.js / tables.js / seeded-random.js / play-runtime.js,及 systems 下 resource·merge·order·reachability 四个具名系统文件——文件级枚举、非目录 glob,`tier2 worker/toolkit.py:34-45` 定义、`:50` 判定;缺口⑥终审据此核实闭合)只在 tier2 自己的 write_source 里强制(`toolkit.py:160-175`),框架内建 Write/Edit/Bash 不经此检查。
|
||||
|
||||
主张:tier2 Service agent 运行时可以用框架内建 Write 直接改写 src/main.js 的装载胶水,旁路 LOCKED_PLATFORM_FILES,复现 cheap 侧已被封的同款写边界击穿。现状 tier2 Service 是 spike(服务态干净复跑未完、CLI 线为主),敞口尚未在生产爆发;但北极星 §5 L3 明确要把 tier2 多席 Service 化,届时每一席都会默认继承这 15 件、每一席的写/致盲护城河都在 Service 路失效。
|
||||
|
||||
〔fable 合并期裁定·终审签认 2026-07-06:采纳——§5 L3 验收门已显式加一条「tier2 Service 各席工具面已对账封口(内建写工具关、Team 组按席致盲)」,否则 L3 的「盲评审 fresh 会话」在工具层是假盲。终审裁定:门保持归 L3(管多席化面);tier2 服务态转正的现网前置由 W-T2LOCK 止血单承担(见下),两不迁就。〕
|
||||
|
||||
tier2 Service 写锁的现网止血已另立 W-T2LOCK 单先行(作战清单 2026-07-06,源出本审计 A4):它不剥工具面,只在框架内建写类工具层对锁定文件写操作 fail-closed,是补丁形态的止血;待 L3 统一「席位工具面白名单」中间件(§2.A.5)落地,W-T2LOCK 并入其中退役。
|
||||
|
||||
#### 2.A.5 收窄该每席重贴补丁,还是框架层统一开关
|
||||
|
||||
现状是「每个 Service 席位各贴各的进程内 monkeypatch」。cheap 用两个补丁封一个便宜档单席;北极星要立六席,若沿现状,等于六套 monkeypatch × 版本漂移复核成本,且每套都依赖对 get_toolkit 未公开内部结构的假设——AgentScope 每升一个补丁版就要逐条复核。
|
||||
|
||||
〔fable 合并期裁定·终审签认 2026-07-06:方向已定——统一「席位工具面白名单」中间件为设计基线:一处声明每席准入工具名单、在 get_toolkit 产出后统一过滤,取代六套散补丁,把「席位=工具面白名单」这条 §0 原则真正焊进一处单源。向 AgentScope 提工具面开关的 upstream PR 可并行推进、但设计不依赖它(PR 是优化,中间件是基线)。终审裁定:中间件落 tier2/gen-worker/service 装配层(get_toolkit 产出后统一过滤),漂移纪律沿 cheap 补丁成例(钉版本、漂移告警仍应用);具体实现随 L3 详设。〕
|
||||
|
||||
### 2.B 场景注册表契约草案
|
||||
|
||||
交互场景清单本身是契约,不是 prompt 里的一段话。制作人席怎么分诊、一句话落到哪个下游席、要不要先问创作者、埋什么点复盘——这四件事一旦写进 prompt,就会随每次改 prompt 悄悄漂移;写成注册表,新场景就得显式增列一行、过一次评审,分诊按表驱动。本节把需求基线的八个场景族展成 contracts 形态:先定信封 schema,再逐场景登记四要素。落 `contracts/agentic-artifacts/scene-registry.schema.json`,与 §3 的九类工件同一子域——场景分诊的产物就是工单(§3①),两者共享席位枚举与 traceId,同域单源省一次跨目录对账。走 contract-first:本草案只冻字段骨架与示例,校验器与正负样本随实现波按 Δ5「无校验器不算契约」补。
|
||||
|
||||
**schema 骨架。** 注册表 = 场景条目数组,每条目是一个分诊路由规则:
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 |
|
||||
|---|---|---|---|
|
||||
| sceneId | string | ✓ | 稳定标识,点分命名空间(如 `modify.behavior`、`version.rollback`);分诊器输出它,遥测按它归类 |
|
||||
| sceneFamily | enum(8) | ✓ | 立项创作 / 修改 / 版本操作 / 目标委托 / 诊断咨询 / 运营变现 / 素材管理 / 打断接管 |
|
||||
| intentClass | string | ✓ | 意图类,全局命名空间→现行 cheap_classify 六类的分层映射(见下 D4);分诊 LLM 判它,可信边界=按 intentClass 落路由、不采信 LLM 自报的执行 mode(`cheap_classify.py:121`) |
|
||||
| route.entrySeat | enum(seat) | ✓ | 入口席,恒 `producer`(制作人席)——唯一面向创作者的常驻线 |
|
||||
| route.terminalSeats | enum(seat)[] | ✓ | 终端承接席,取值域 = 六席(producer/design/impl/content/asset/review);诊断咨询等只读场景为空 |
|
||||
| defaultConfirmTier | 0\|1\|2 | ✓ | 分诊建议的默认确认档;工单铸造(§3① confirmTier)可按 payload 收紧、**不可放松** |
|
||||
| confirmFloorRule | {baseTier, irreversibleSources[], saveDataPolicy:{additive:"no-raise", breaking:"tier2"}} | ✓ | 硬地板规则(不是定值,铸单时求值):baseTier 起判;irreversibleSources[]（money/saveData/liveState/budget）命中 money/liveState 直接把地板顶到 2、saveData 命中按 saveDataPolicy 细分——additive(旧档缺省可读)no-raise 不顶、breaking(migratorNeeded=true)顶到 tier2;确认档终判推迟到 SpecDelta.saveDataImpact 产出后落值 |
|
||||
| producesWorkOrder | bool | ✓ | 是否铸工单;诊断咨询为 false(只读即答),打断接管为 false(控制流) |
|
||||
| controlFlow | bool | | 标记该条目是控制流而非意图(打断接管=true);分诊器据此认得「这是打断信号、不是新需求」 |
|
||||
| telemetryEvent | string | ✓ | 遥测事件名,camelCase,进 events.schema.json 的 eventRegistry;每次分诊落一条、带 traceId |
|
||||
| clarifyOnAmbiguous | bool | ✓ | 意图不明是否回问澄清(对应 cheap_classify 的 unclear→回问,不静默判成可执行改动) |
|
||||
|
||||
一条示例(场景 A,追加宠物系统):
|
||||
|
||||
```json
|
||||
{
|
||||
"sceneId": "modify.behavior",
|
||||
"sceneFamily": "修改",
|
||||
"intentClass": "behavior",
|
||||
"route": { "entrySeat": "producer", "terminalSeats": ["design", "impl"] },
|
||||
"defaultConfirmTier": 1,
|
||||
"confirmFloorRule": {
|
||||
"baseTier": 0,
|
||||
"irreversibleSources": ["saveData"],
|
||||
"saveDataPolicy": { "additive": "no-raise", "breaking": "tier2" }
|
||||
},
|
||||
"producesWorkOrder": true,
|
||||
"telemetryEvent": "sceneModifyBehavior",
|
||||
"clarifyOnAmbiguous": true
|
||||
}
|
||||
```
|
||||
|
||||
宠物系统碰存档 schema(顾客类型表加互动列),故 confirmFloorRule.irreversibleSources 含 saveData;但按 SpecDelta.saveDataImpact 判定这是 additive(旧档缺省视为未解锁宠物、无需迁移器),故 saveDataPolicy 走 no-raise、地板不顶 2、走档 1——只有当存档变更为 breaking(改删字段、旧档失效)才顶 2。这正是「可逆性替代确认」落到字段级的样子:同一场景,additive 走档 1、breaking 走档 2,且确认档终判推迟到 SpecDelta 已知之后。
|
||||
|
||||
**全场景登记表。** 八族逐条展开,terminalSeats 用六席简称(producer 制作人 / design 主设计 / impl 实现 / content 内容 / asset 资产 / review 评审)。「确定性 modify」指现状 cheap_modify 的纯代码执行路(资产/数值/关卡三类可确定化落点,`cheap_classify.py:21` `_DETERMINISTIC_CATEGORIES`),不必经实现席 LLM。
|
||||
|
||||
| sceneId | 族 | intentClass | terminalSeats | defaultTier | floor(不可逆源) | 铸单 | telemetryEvent |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| create.project.fromPrompt | 立项创作 | create | design→impl→content→asset→review | 1 | 0 | ✓(goal-loop) | sceneProjectCreate |
|
||||
| create.project.fromTemplate | 立项创作 | create | impl→content→asset→review | 1 | 0 | ✓ | sceneProjectCreateFromTemplate |
|
||||
| modify.asset | 修改 | asset | asset(或确定性 modify) | 0 | 0 | ✓ | sceneModifyAsset |
|
||||
| modify.config | 修改 | config | content(或确定性 modify) | 0 | 0 | ✓ | sceneModifyConfig |
|
||||
| modify.content | 修改 | level | content | 1 | 0 | ✓ | sceneModifyContent |
|
||||
| modify.behavior | 修改 | behavior | design→impl | 1 | 2(saveData 且 breaking) | ✓ | sceneModifyBehavior |
|
||||
| modify.meta | 修改 | meta(新增) | producer(直改) | 0 | 0 | 视情 | sceneModifyMeta |
|
||||
| version.rollback | 版本操作 | version.rollback | producer(指针+兼容检查器) | 2 | 2(saveData·恒 breaking) | ✓ | sceneVersionRollback |
|
||||
| version.fork | 版本操作 | version.fork | design→impl(意图重放) | 2 | 2(saveData·恒 breaking) | ✓ | sceneVersionFork |
|
||||
| version.browse | 版本操作 | version.browse | —(只读时间线) | 0 | 0 | ✗ | sceneVersionBrowse |
|
||||
| goal.delegate | 目标委托 | goal.delegate | design→impl→content→asset→review | 1 | 2(budget 超阈时) | ✓(goal-loop) | sceneGoalDelegate |
|
||||
| diagnose.query | 诊断咨询 | diagnose.query | —(制作人只读即答) | 0 | 0 | ✗(确认后转工单) | sceneDiagnoseQuery |
|
||||
| monetize.config | 运营变现 | monetize.config | producer(变现位表) | 2 | 2(money) | ✓ | sceneMonetizeConfig |
|
||||
| publish | 运营变现 | publish | producer→review(审核门)→指针切 | 2 | 2(liveState) | ✓ | scenePublish |
|
||||
| asset.manage | 素材管理 | asset.manage | asset | 1 | 0 | ✓ | sceneAssetManage |
|
||||
| control.interrupt | 打断接管 | control.interrupt | —(harness 级,插单重排) | n/a | n/a | ✗(controlFlow=true) | sceneControlInterrupt |
|
||||
|
||||
几处判读要点,不是表格能承载的:
|
||||
|
||||
- **修改族按对象切场景,动词进 payload**。修改族是「对象(资产/数值/内容/机制/meta)× 动词(改/增/删/调/回退)」的矩阵;若每个对象×动词各立一场景,25 格爆炸且无意义——分诊真正要分的是「落到哪个席、哪个可改面」,这由对象决定,不由动词决定。故按对象切五个 modify.* 场景,动词收进工单 payload 的操作类型;唯一例外是「回退」,它不落原对象的可改面、而是整版回退,故单独归版本操作族(version.rollback)。这与现状 cheap_classify 一致——它也只按 category(对象)分类、不按动词。
|
||||
- **修改族对着 cheap_classify 现状长**。asset/config/level 三类命中确定性执行路(纯代码改一处键→值/常量,defaultTier 0、可逆一键撤),behavior 类命中模块重生成(过实现席 LLM 重写玩法文件)。现状分类器已把「危险/大改/改玩法/意图不明一律回问确认」焊死(`cheap_classify.py:122`,创始人 2026-06-28),这条直接落成 clarifyOnAmbiguous=true + behavior 类 defaultTier≥1。
|
||||
- **诊断咨询不铸工单是硬约束**。「为什么高峰期卡」先给现场快照 + 遥测佐证判读,只读即答;创作者看完确认要修,才由制作人转一张性能工单(那是另一次分诊、走 modify.behavior)。producesWorkOrder=false 是它区别于修改族的定义性字段——省掉它,诊断问句会被误铸成工单。诊断答复本身落 trace 留痕、不进工件存储(终审裁定,§1.2 场景 C 第四步)。场景 C 的决策史对撞发生在「转出来的那张工单」铸造时,不在诊断这一步——机制 = 铸单 harness 检索决策索引注入 WorkOrder.decisionRefs(§3①)。
|
||||
- **运营变现与版本回退共享档 2 地板,但不可逆源不同**:变现是 money(碰钱),发布是 liveState(碰线上),回退/分叉是 saveData(碰玩家存档——回退真雷是存档不是代码,§4)。碰钱、碰线上永远先问;碰存档一般按 breaking/additive 细分,但回退/分叉是整版切换、必触 breaking 语义(旧存档在目标基线上打不开),故 version.rollback/fork 恒档 2、无 additive 例外。
|
||||
- **打断接管不是意图、是控制流**。它 producesWorkOrder=false、controlFlow=true、terminalSeats 空、confirmTier n/a——登记它是为了让分诊器认得「这是打断信号,不是新需求」:当前工单跑完或干净中止(journal 收口),插单重排,账本无损恢复(goal-loop 铁律)。它保留在注册表、以 controlFlow 标记与意图类区隔。
|
||||
- **端别边界(v1 范围)**:注册表 v1 只覆盖 H5 运行主端的版本/发布场景;渠道端(微信/抖音)版本操作走人在环单游固化导出,是月级挑版提审、不经分诊路由(§1.1.3 E、§4 端别边界)。故 version.*/publish 各场景默认对 H5 主端成立,渠道端不由分诊器接管。
|
||||
|
||||
**全局意图类 ↔ cheap_classify 现状六类映射。** cheap_classify 现役六类(`cheap_classify.py:22` `_VALID_CATEGORIES`)是修改族的局部命名空间,注册表按下表把它们映射到全局场景意图类;其中确定性三类(asset/config/level)命中纯代码执行路,behavior 过实现席 LLM,末两类不落独立 modify.* 场景:
|
||||
|
||||
| cheap_classify 六类 | 全局映射 | 说明 |
|
||||
|---|---|---|
|
||||
| asset | modify.asset | 确定性执行路(改一处 assets.js 键→值),defaultTier 0 |
|
||||
| config | modify.config | 确定性执行路(改 core.js 常量),defaultTier 0 |
|
||||
| level | modify.content | 确定性执行路(关卡数据),defaultTier 0 |
|
||||
| behavior | modify.behavior | 模块重生成、过实现席 LLM 重写玩法文件,defaultTier ≥1 |
|
||||
| big-change | (无独立场景)→ 升级事件 / 档 2 路径 | 换品类、整体重做、推倒重写、清档重置(`cheap_classify.py:77`)已超出局部调整,不落 modify.*,升级到制作人席按新立项或档 2 不可逆确认处置 |
|
||||
| unclear | (无独立场景)→ clarifyOnAmbiguous 横切开关 | 意图不明、定位不到具体一处(`cheap_classify.py:78`),绝不静默判成可执行改动,由 clarifyOnAmbiguous=true 回问澄清、不铸独立场景 |
|
||||
|
||||
**裁决点(本节)**〔fable 合并期裁定·终审签认 2026-07-06〕:
|
||||
- 〔D1 路由席位双值〕采纳——拆成 route.entrySeat(恒 producer)+ route.terminalSeats[];入口恒是制作人席、真正的路由差异在终端承接席,单值字段无法同时表达「谁先收」和「派给谁」。
|
||||
- 〔D2 confirmTier 从属〕采纳——场景给**不可放松的地板**:defaultConfirmTier 是分诊建议默认、confirmFloorRule 是硬地板规则,工单铸造的 confirmTier 只能升不能降;碰钱/碰线上地板 2,碰存档按 breaking/additive 细分(回退/分叉恒 breaking、恒 2),确认档终判推迟到 SpecDelta 已知后(缺口⑩口径)。
|
||||
- 〔D3 打断接管归属〕采纳——保留在注册表、标 controlFlow=true,分诊器单一入口认它、不误判成新需求。
|
||||
- 〔D4 意图类命名空间〕采纳分层映射——不动现行 cheap_classify 分类器契约:修改族沿用现状六类(asset/config/level/behavior/big-change/unclear)为局部命名空间,其余族用族级前缀(create/version.*/goal.delegate/diagnose.query/monetize.*),注册表做全局意图类→现状六类的映射。终审签认:映射表已覆盖现状六类全量(asset/config/level/behavior/big-change/unclear),完整。
|
||||
|
||||
### 2.C 快进仿真器可行性
|
||||
|
||||
数值平衡判定要回答的是一句很具体的话:一组菜价、耐心、解锁曲线摆下去,顾客流、金币流、解锁节奏会不会击穿——太松则一路躺赢无张力,太紧则开局即劝退。这个判断的绝大部分是确定性的:给定数据表和一套玩家打法,经济曲线是算得出来的,不需要人反复真玩几百局去感觉。所以它先落成工具而非席位(§2 已裁「先工具后席」)。工具走哪条路,归结为一个取舍:是让工具去跑真游戏的逻辑(路 A),还是把数据表抽出来在一个独立仿真器里另算一遍(路 B)。
|
||||
|
||||
**路 A · 工程离屏快进。结论:成立,且是现有 runtime 上增量最小的一条**——两档引擎的逻辑层都已具备「脱引擎、受控时钟、可观测」三件套,tier2 更已有跑通的单局雏形。离屏快进靠三个已经落地的性质:
|
||||
|
||||
其一,**逻辑层与渲染、与真实时间都是解耦的**。轻档 LittleJS 的宿主把「推进一帧」实现成纯同步循环:`stepFrames(n)` 就是 `for` 里调 `n` 次 `stepOneFrame`(`game-runtime/src/host/boot-game-host.js:328-329`),每步先把受控时钟 `mockNowMs` 自增一个固定步长再调 `game.update`,而 `game.render` 只在有可见画布上下文时才走(同文件 `:319`、`:322`)。node 环境下没有可见画布,render 整条被跳过,一帧只剩纯逻辑计算。游戏本体也守同一纪律:`update(dt)` 吃外部传入的 `dt`、与 `render(g)` 分成两个方法(`game-runtime/games/_template-shop/src/game-logic.js:213`、`:226`),局内计时是 `elapsedMs += dt*1000` 累加出来的、不读墙钟。定时器同理——`timer-scheduler` 到期检查读受控时钟、「无帧不推进」是硬保证(`game-runtime/src/plugins/timer-scheduler/impl.js:88`)。喂多大的 `dt`、连着喂多少帧完全由调用方定,一局 60 秒的营业在墙钟上可以零点几毫秒跑完。
|
||||
|
||||
其二,**逻辑是纯的、随机是受控的,所以可复现**。轻档 `core.js` 的顾客生成节奏、耐心衰减、命中判定全是无副作用纯函数,随机经入参 `rng` 注入、零 `Math.random`/`Date.now`(`game-runtime/games/_template-shop/src/core.js:6-7`、`:68-69`),这一层 node 直接单测,实测 8/8 通过。tier2 富档的 `game-core.js` 同样按「零 DOM/canvas/引擎、时间经 `update(dtSeconds)` 注入、随机经受控源」的铁律写(`tier2/fixtures/mini-fei-e/src/game-core.js:18`),它的可达性/无环校验模块更明说「纯数据推演,故能脱离真玩快筛」(`reachability.js:15-16`)。可复现是仿真的前提——同一组表、同一 seed、同一打法跑一千遍结果一致,曲线才可比。
|
||||
|
||||
其三,**输入不用真人合成,自动 driver 读可观测状态自己出招**。游戏经 `_forensicsView().state()` / `readState()` 导出语义状态(轻档 `game-logic.js:247`,富档 `game-core.js:110-147`,后者把棋盘、订单、合成链、交单坐标投影成 driver 契约形状),driver 读它自适应出招而非盲打坐标。tier2 的 `business-sim.driver.js` 就是经营品类的确定性驱动器,赢路径把金币从 20 推到 ≥100、破产路径放任订单流失(`business-sim.driver.js:9-13`);`logic-smoke.mjs` 的 `driveWinLoop` 是同一思路的 node 版纪律玩家。
|
||||
|
||||
把三件套接起来,tier2 侧已经是一个跑通的单局仿真:`logic-smoke.mjs` 无浏览器、`createGameCore` 脱引擎、自动 driver 驱动、赢局(上限 8000 帧)与输局(5000 帧)双路跑到 latch 终态并读经济结果——整个脚本含 node 冷启动实测 `real 0.03s`(node v22.22.3)。墙钟估算(外推):这 30 毫秒里 node 冷启动占大头(可比照 `core.test` 8 个纯函数耗 51 毫秒);在单进程内循环、冷启动只付一次,tier2 mini-肥鹅复杂度跑一千局落在秒级到十秒级;北极星标的系统数更多、单局逻辑更重,即便单局成本涨一到两个数量级,千局仍在分钟级墙钟内。精确值要一次 spike 实测坐实,但量级不构成障碍——这与「反复真玩几百局」的人力墙钟差着好几个数量级,正是「先做成工具」的立论所在。
|
||||
|
||||
**可复用的九门 harness 件,与用不上的那半:** 直接复用逻辑侧全套——`_forensicsView`/`readState` 可观测契约、driver 库(经营品类 `business-sim.driver.js` 现成)、`seeded-random` 受控随机、`timer-scheduler` 受控时钟、latch 终态轮询判定。用不上、也不该拉进来的是浏览器那半:CDP 触摸下发、像素回读、canvas 哈希、起 serve+chrome 的编排(`game-e2e-cdp-harness.md` §1-2 的九门是为「真玩取证」设计的,要证渲染、手感、输入到达画布)。**边界一句话:九门证「这一局真能玩、玩起来对」,快进仿真答「这套数值跑一千局会不会崩」——共享逻辑内核与 driver,分走浏览器与批量两端。**
|
||||
|
||||
**路 B · 抽数值表独立仿真。结论:静态结构判定这一层可行且已存在,应保留作前置门;但动态时序仿真这一层是对现有游戏逻辑的重复实现,注定与工程漂移、且保真度天花板低,不推荐作为主体。** 路 B 的最大顺风,是数据表化的前提已满足:tier2 的权威数据表是 `data/datatable.gold.json`、过机器校验,含开局货币/库存、物品、合成链、订单、赢线输线全套。问题出在抽出表之后:路 B 要「在纯仿真器里跑这张表出经济曲线」,而跑表所需的经济动力学(顾客到达怎么排队、合成怎么消耗库存、订单耐心怎么衰减、金币怎么累积与门控)已经在 `game-core.js` 的三系统(resource/merge/order)里实现了一遍——独立仿真器等于把这套逻辑再抄一份,两份各自演进迟早对不上,正是项目「拒绝孤儿/拼接、单一数据源」红线要防的。保真度天花板也在这里:经营品类里空间摆放是核心系统(桌椅设备摆放影响吞吐,§1.1 街区扩张),独立数值仿真器摆不了桌子,任何「逻辑与空间/表现耦合」的机制它都仿不了。路 B 真正站得住的,是退化到**纯静态结构判定**那一层——`reachability.js` 就是现成实例:从开局食材沿合成链做不动点迭代算可达集,再校验每个订单要的物品都可达、合成链拓扑无环。这类「有没有订单要一个永远合不出来的东西」「解锁树有没有死环」读表就能筛出,极轻、不与动态逻辑重复,该保留,但它答不了「数值是否击穿」。
|
||||
|
||||
| 判据 | 路 A 工程离屏快进 | 路 B 抽表独立仿真 |
|
||||
|---|---|---|
|
||||
| 保真度 | 高——跑真游戏逻辑,唯一近似是「玩家水平」(自动 driver 是纪律最优,曲线偏乐观,可多档策略缓解) | 动态层低——空间摆放/表现耦合的机制仿不了;静态结构层准 |
|
||||
| 速度 | 千局秒级到分钟级墙钟(单局实测锚点 30ms 含冷启动,外推) | 更快(纯算式),但要先重写动力学才能跑动态曲线 |
|
||||
| 实现成本 | 最小——tier2 已有 `logic-smoke` 单局雏形,增量=参数扫描外层 + 曲线聚合;轻档需补一个同形态 node 驱动脚本(机制齐备) | 动态层高且漂移(重写三系统);静态层已存在(`reachability`) |
|
||||
| 与「内容席只写表」亲和 | 天然吻合——游戏逻辑不变、只换数据表跑千次,正是主设计席/数值判定要消费的形态 | 同样吃表,但跑的不是真逻辑,曲线可信度打折 |
|
||||
|
||||
**推荐路 A,并把路 B 的静态判定收编为它的前置门,不作二选一。** 完整形态两段:先用 `reachability` 式静态推演快筛结构性击穿(几毫秒淘汰「订单要不可达物品」这类硬坑),再用离屏快进跑动态经济曲线。路 A 压倒路 B 的核心是它跑真逻辑——数值平衡最怕「仿真器里没崩、真游戏里崩了」,而路 A 与真游戏共享同一份逻辑内核和数据表,不存在第二份会漂移的动力学;路 B 要抽的那张表,正是路 A 换着跑千次的输入轴。
|
||||
|
||||
**前提与保真度边界(如实登记,非阻断):** 离屏快进绑定一条纪律——被测游戏逻辑必须像 `game-core.js`/轻档 `core.js` 那样纯逻辑脱引擎、`update(dt)` 注入时间、经 `readState`/`_forensicsView` 暴露经济状态,这条 3 层架构(L3 逻辑纯净)和 tier2 平台预建已在强制。风险敞口在空间摆放类系统(桌椅设备吞吐最容易把逻辑塞进表现层),一旦耦合就快进不了。第二条边界是自动 driver 的玩家水平:driver 是纪律最优打法,跑出的曲线是「高手上界」、偏乐观;要覆盖真实人群需多档策略 driver(菜鸟/中手/高手)扫、取曲线包络。
|
||||
|
||||
**裁决点(本附节)**〔fable 合并期裁定·终审签认 2026-07-06〕:两路并非都不可行(路 A 成立),故不触发「数值席提前转正」——快进先工具的路线坐实,数值仿真席维持 §2 缓立(v2)。两处保真度边界,创始人 2026-07-06 已拍:
|
||||
- 空间摆放类系统**纳入**快进仿真:L3/L4 切片硬约束「空间吞吐逻辑也走 `update(dt)` 纯逻辑层、不耦进渲染」,以守纪律换全覆盖(加重 L3 系统设计约束,已认这笔账)。
|
||||
- driver 档位:L3 先用**单档最优 driver 跑通闭环**、把多档策略包络列为 L4 增强;L3 阶段的数值判定只保证「上界不崩」,L3 期下沿体验的数值风险如实标注为未覆盖。
|
||||
|
||||
**裁决点(§2 本节)**:①主设计席 v1 立瘦版而非并入制作人——两席 context 食谱确实不同(契约深度 vs 台账广度),合并省一席但会让制作人配方变宽、违反角色投影,不省;②数值仿真「先工具后席」(§2.C 坐实路 A 成立);③馆长与玩家缓立。三条骨架裁决,创始人 §7 已批;本节三附节(§2.A 注入面审计 / §2.B 场景注册表 / §2.C 快进仿真器)各自的合并期裁定见其节内〔fable 合并期裁定〕标记。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[创作者] -->|一句话/试玩反馈| P[制作人席]
|
||||
P -->|工单| D[主设计席·瘦]
|
||||
P -->|工单| I[实现席 ×N]
|
||||
P -->|工单| CT[内容席]
|
||||
P -->|工单| AS[资产席·薄]
|
||||
D -->|规格增量| I
|
||||
D -->|规格增量| CT
|
||||
I -->|交付包| R[评审席·盲]
|
||||
CT -->|交付包| R
|
||||
AS -->|交付包| R
|
||||
G[九门/仿真器/校验器<br/>门与工具,不是席] -->|证据包| R
|
||||
R -->|判定书| P
|
||||
P -->|版本卡| U
|
||||
T[遥测] -->|回流工单| P
|
||||
I -.->|升级事件| P
|
||||
style G fill:#f8fafc,stroke:#94a3b8,stroke-dasharray: 5 5
|
||||
```
|
||||
|
||||
## 3. 九类工件 schema 草案
|
||||
|
||||
**命题:席位间一切通信 = 工件;工件全部带统一信封,信封三件事——谁产的(席位+配方版本)、凭什么(出处三戳)、跟哪局有关(traceId)。** 没有信封的消息不进任何席位的 context。落点:`contracts/agentic-artifacts/`(实现波按 Δ5 配校验器与正负样本,本档只冻字段骨架)。
|
||||
|
||||
统一信封(所有工件共用):
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 |
|
||||
|---|---|---|---|
|
||||
| artifactType | enum(九类) | ✓ | 见下 |
|
||||
| artifactId / schemaVersion | string / int | ✓ | 工件自身可寻址、可演进 |
|
||||
| producedBy | {actorKind(seat/tool/telemetry/harness), actorId, configVersion?} | ✓ | 生产者三元:actorKind 分四类合法生产者(席位/门工具/遥测/harness),actorId 具体标识,configVersion 在 actorKind=seat 时为席位配方版本(配置控制面版本号)、tool/telemetry 可空——坏结果可归因到配方或产它的门/遥测 |
|
||||
| provenance | {source, ts, nature} | ✓ | 出处三戳:来源(commit/门跑/遥测窗)、新鲜度、性质(事实/推断/假设) |
|
||||
| traceId / gameProjectId | string | ✓ | 关联生成 trace 与游戏工程 |
|
||||
|
||||
九类工件逐类给字段;凡既有契约已定的字段一律引用、不重定义,纯新增字段给设计理由(逐字段对账见 §3 附·契约对账)。下列各表不重列信封五字段;示例 JSON 带一段缩略信封以示合法实例。
|
||||
|
||||
**① 工单(WorkOrder)——制作人→各席,一切工作的铸造形态:**
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 |
|
||||
|---|---|---|---|
|
||||
| goal | string | ✓ | 产品语言的目标,一句话 |
|
||||
| scopeWhitelist | {files[], tables[], contracts[], saveStateSubtrees[]} | ✓ | 写白名单,工单级(比档位级更窄);并行工单白名单不相交。files = 「新文件通配前缀 + 必触碰既有文件显式列全」的并集展开,DeliveryPackage.filesTouched ⊆ 展开集、越界须先发升级事件(scope_expand)改单(缺口⑤);contracts[] = 契约路径 + JSON Pointer 锚,圈主设计席工单的契约面(缺口②);saveStateSubtrees[] = 存档 schema 子树授权——save_state 非数据表(缺口④) |
|
||||
| acceptance | {gates[], machineChecks[], checks[]} | ✓ | 三分(缺口③):gates = 九门/富游戏门闭集引用;machineChecks = 非九门机器门(validate_datatable/schema 校验器/经济仿真非劣化/兼容检查器);checks = 少量人判项。编译不出验收门的 goal 不许铸单(goal-loop 铁律) |
|
||||
| budget | {rmbSoft, rmbHard, wallClockS, resumeMax} | ✓ | 两段式预算对齐现行 middleware 语义 |
|
||||
| deps / escalationPolicy | refs[] / enum | ✓ | 依赖工单;何时必须发升级事件 |
|
||||
| confirmTier | 0/1/2 | ✓ | 三档确认档位;铸单时按场景 confirmFloorRule 与 SpecDelta.saveDataImpact 终判落值(场景规则给不可放松的地板,只升不降) |
|
||||
| decisionRefs[] | ref[]〔→ decisions 条目〕 | | 铸单时 harness 按 scopeWhitelist 机械检索账本决策索引、命中自动注入(缺口⑨终审件);实现席据此先知约束,执行期 EscalationEvent.decisionHistoryHit 为二道网 |
|
||||
|
||||
示例(场景 A 实现工单):`goal:"顾客可与宠物互动,互动后小费系数上浮"`,`scopeWhitelist:{files:["src/systems/pet*","src/systems/tipCalc.js","src/scenes/PlayScene.js"],tables:[],saveStateSubtrees:["/save/pet"]}`(新文件通配、必触碰既有文件显式列全;宠物态走 save_state 子树、经 SpecDelta 登记,不新增表,遵 §1.1.4;顾客类型表归并行的内容工单),`acceptance:{gates:["九门"],machineChecks:["经济仿真非劣化"],checks:["撸猫动效可见"]}`,`confirmTier:1`,`decisionRefs:[]`(宠物纯新增,决策索引无命中)。
|
||||
|
||||
**② 判定书(Verdict)——评审→制作人。裁决:并存形态,认领既有胚胎、不另起 schema。**〔fable 合并期裁定·终审签认 2026-07-06〕`verdict-feedback.schema.json`(C6)的 `passed` 为 `const false`、自述「不是终判本身……专门喂回 agent 让它接着修的那份载荷」,失败项 `minItems:1`——一份 accept 判定没有未过门,结构上放不进 C6。故判定书认领的胚胎分两份:**投影终判 `tier2-verdict`** 承 decision/perCheck/ftueNotes,**在 decision=fix 时引用一份 C6 VerdictFeedback** 作续修载荷:
|
||||
|
||||
```
|
||||
判定书 Verdict = 信封
|
||||
+ decision ← 引 tier2-verdict.decision(accept/fix/kill,不重定义)
|
||||
+ perCheck[] ← 投影 tier2-verdict.layerResults.L1.gateResults + richGameGates + findings
|
||||
+ ftueNotes ← 投影 tier2-verdict.humanPlayability + C5 play-spec.firstPlay(玩家席缓立期权宜项)
|
||||
+ evidenceRef ← 指向 EvidencePackage(⑥)
|
||||
+ fixFeedbackRef?← 仅 decision=fix 时,指向一份 C6 VerdictFeedback(保 C6 passed=false 不变量)
|
||||
+ decisions[]? ← 约束性决定{constraint, scope:{files[],tables[],systems[]}, rationale, standingUntil?}(缺口⑨终审件:评审判定随档落约束,如 D300「合批保持关闭」;账本决策索引之源)
|
||||
```
|
||||
|
||||
即判定书对 C6 的关系是引用(fix 分支嵌入续修载荷),对终判 tier2-verdict 的关系是投影其决策与逐项结果;两份既有契约都不改。「不另起 schema、认领胚胎」的骨架裁决实质不变,只是认领对象分两份(终判 + 续修载荷各一)。席内/席间边界佐证:C6 喂的续修 middleware 在实现席 ReAct 循环内(席内),判定书是评审席→制作人席的席间终判——把判定书整体等同 C6,会把「席内续修载荷」错当「席间终判」。
|
||||
|
||||
**③ 版本卡(VersionCard)——制作人→创作者,用户唯一看得见的版本形态:**
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 |
|
||||
|---|---|---|---|
|
||||
| versionId / baseVersionId | string | ✓ | 本版与其基线 |
|
||||
| lineId | string | ✓ | 铸卡时所属版本线(不可变);分叉 = 新 lineId + baseVersionId 指分叉点。线状态(active/superseded)与 live 指针是发布域/账本的可变状态、刻意不上卡(卡不可变),时间线视图由账本按 lineId join 呈现(缺口⑦终审件) |
|
||||
| baselineStamp | {gatesGreen, telemetryNonRegression, qualifiedAt} | ✓ | 基线资格机器戳(§4);「从稳定版继续」解析的对象 |
|
||||
| appliedIntents | workOrderRef[] | ✓ | 本版应用的意图集——意图重放(§4)的原料 |
|
||||
| evidenceRef / compatStamp | ref / {saveSchemaVersion, compatibleFrom} | ✓ | 证据包;存档兼容戳 |
|
||||
| thumb / oneLiner | asset / string | ✓ | 缩略图 + 一句人话变更 |
|
||||
|
||||
**④ 规格增量(SpecDelta)——主设计席→实现席/内容席。** 契约变更是复杂游戏区别于模板小游戏的分水岭;规格增量是主设计席唯一的产出面,把「系统契约/数据 schema 怎么改」钉成可校验、可登记存档影响的工件。
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| contractRef | string(契约路径 + JSON Pointer 锚) | ✓ | 本增量针对哪份契约或数据表 schema | 引用 `contracts/` 现存文件路径 |
|
||||
| contractVersionBump | enum(none/minor/major) | ✓ | 契约语义版本 bump 档:none=新增可选字段不升、minor=向后兼容扩展、major=删改字段或改语义;只管系统契约与数据表 schema 的兼容级别,与存档 schema 版本正交 | 引用 `play-spec.schema.json:13-14`「新增字段不升版本;删改字段或改语义才升版本」+ 版本闸 `contracts/prompts/check_version_bump.py` |
|
||||
| changes[] | {op(add/modify/remove), path, rationale}[] | ✓ | 逐条增量,op 对齐 additive/breaking 判据;每条一句 rationale 供盲评审可判 | 新字段·规格增量须逐条可审 |
|
||||
| migrationNote | string | 条件(contractVersionBump=major 或存档 breaking 必填) | breaking 变更的迁移说明(两端读取方 + CI 一致性怎么跟) | 新字段·承接数据飞轮 §5「升版本要同步两端读取方与 CI」的迁移纪律 |
|
||||
| saveDataImpact | {changed:bool, migratorNeeded:bool, schemaBump(none/bump), saveSchemaVersion?:string} | ✓ | 存档面影响:是否变、要不要迁移器、是否升存档 schema 版本(additive→none 不升、breaking→bump 升)、变后存档版本号;与 contractVersionBump 正交(契约版本 ≠ 存档版本);喂 VersionCard.compatStamp 与兼容检查器 | 新字段(登记面)·锚 §4.3 存档兼容检查器 + L2 save-progress KV 存档;save-progress 现状是否带 schema 版本字段待 O-6 核实 |
|
||||
|
||||
契约语义版本(contractVersionBump)与存档 schema 版本(saveDataImpact.schemaBump)是两根正交的轴,拆开是因为它们各自回答一个不同的问题。前者管系统契约与数据表 schema 的兼容级别,复用 play-spec「新增字段不升、删改改义才升」那套口径;后者只管玩家存档格式要不要升版,additive 扩展(旧档缺省仍可读)不升、breaking(改删字段令旧档失效)才升。一次改动可以只动一根轴——场景 A 给顾客类型表加了一列(contractVersionBump=minor),但存档那头只是加了个可选 pet 子树的 additive 扩展(schemaBump=none),两个版本号各走各的、不互相牵连。
|
||||
|
||||
示例 JSON(场景 A · 追加宠物系统,存档表加可选宠物子树、顾客类型表加互动列):
|
||||
|
||||
```json
|
||||
{
|
||||
"artifactType": "SpecDelta",
|
||||
"artifactId": "spec-pet-001",
|
||||
"schemaVersion": 1,
|
||||
"producedBy": { "actorKind": "seat", "actorId": "主设计席", "configVersion": "designer/1.2" },
|
||||
"provenance": { "source": "workorder:WO-pet-001", "ts": "2026-07-20T10:00:00+08:00", "nature": "推断" },
|
||||
"traceId": "t-nightmkt-1420", "gameProjectId": "nightmarket",
|
||||
"contractRef": "game://nightmarket/datatables/customer_type.gold.json#/columns",
|
||||
"contractVersionBump": "minor",
|
||||
"changes": [
|
||||
{ "op": "add", "path": "/save/pet", "rationale": "宠物养成态需持久化(好感度/皮肤),存档新增 pet 子树" },
|
||||
{ "op": "add", "path": "/datatables/customer_type/columns/petInteraction", "rationale": "顾客类型表加互动列,标记该顾客类型是否触发撸猫" }
|
||||
],
|
||||
"migrationNote": "契约端新增可选列走 minor;存档端新增可选 pet 子树、旧档缺省视为未解锁宠物,属 additive、schemaBump=none 不升存档版本、无需迁移器",
|
||||
"saveDataImpact": { "changed": true, "migratorNeeded": false, "schemaBump": "none", "saveSchemaVersion": "nightmarket-save/3" }
|
||||
}
|
||||
```
|
||||
|
||||
**⑤ 交付包(DeliveryPackage)——实现席/内容席/资产席→评审席。** 交付包是「我做完了、这是产物 + 我自己先查过」的席间交接。它不含终判,只承实现席的自证与可定位的产物锚。反造假是它的第一纪律。
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| commitHash | string(hex) | ✓ | 本工单产物的真实 commit,**必须 git rev-parse 得到、不得自述** | 新字段·反造假一手教训(controller 侧 rev-parse 对账是运行时纪律) |
|
||||
| filesTouched[] | string[] | ✓ | 本工单真实改动的文件,须 ⊆ WorkOrder.scopeWhitelist.files(离场清账核对面) | 引用 WorkOrder.scopeWhitelist(§3①)+ 源工程 files/fileTree(`result_out.py:60-62` / `tier2-source-project.schema.json:18`) |
|
||||
| sourceProjectRef | {addressingKey(contentHash/sourceHash), versionId?} | ✓ | 交付的源工程寻址锚(评审席据此取回被审工程;VersionCard 不加此锚、只持 versionId,源工程寻址由 W-ASSET-SRC 按 versionId 二跳解析) | 引用 `tier2-source-project.schema.json:98`(contentHash)/`:108`(addressing) 与 cheap sourceHash(`result_out.py:37-40,65-72`) |
|
||||
| selfTestEvidence | {cmd, exitCode, summary} | ✓ | 席内自测证据(build/test 输出摘要),只自证已自查、不作终判 | 新字段·实现席 harness「build/test」自测面 |
|
||||
| journalRef | ref(→ journal 记录) | ✓ | 写前意图 journal 指针;改前声明意图、离场时据此清账 | 引用 §2 harness 列 + §5 L1「journal 写前意图 + 离场清账进 harness」 |
|
||||
|
||||
示例 JSON(场景 A · 实现席交付宠物系统源工程):
|
||||
|
||||
```json
|
||||
{
|
||||
"artifactType": "DeliveryPackage",
|
||||
"artifactId": "delivery-pet-001",
|
||||
"schemaVersion": 1,
|
||||
"producedBy": { "actorKind": "seat", "actorId": "实现席#pet", "configVersion": "impl/2.1" },
|
||||
"provenance": { "source": "commit:9f3c1a…", "ts": "2026-07-21T14:30:00+08:00", "nature": "事实" },
|
||||
"traceId": "t-nightmkt-1421", "gameProjectId": "nightmarket",
|
||||
"commitHash": "9f3c1a2b7d0e4f6a8c1b3d5e7f9a1c2b4d6e8f0a",
|
||||
"filesTouched": ["src/systems/petSystem.js", "src/systems/tipCalc.js", "src/scenes/PlayScene.js"],
|
||||
"sourceProjectRef": { "addressingKey": "3a…(contentHash)", "versionId": 24 },
|
||||
"selfTestEvidence": { "cmd": "node --check && esbuild build", "exitCode": 0, "summary": "构建通过,3 文件 node --check 无语法错误" },
|
||||
"journalRef": "journal://nightmarket/WO-pet-001/impl.jsonl"
|
||||
}
|
||||
```
|
||||
|
||||
**⑥ 证据包(EvidencePackage)——门/工具(九门·仿真器·校验器)→评审席。** 证据包是「机器判出来的东西堆在这里,评审席只认它、不认任何 agent 自述」。它的指针段与 C6(verdict-feedback)的 `evidence` 段高度重叠——**故指针字段一律引用 C6.evidence,不另立**;真正新增的只有仿真器产物与真实成本两项。分版落地:瘦版随 L1(仅 gateRunRef/tracePath/screenshots 三指针,即够回放交接序),全量随 L3(补 costActual 与 simRunRef,§5)。
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| gateRunRef | ref(→ verdict.json) | ✓ | 九门/富游戏三门终判落盘指针 | 引用 `verdict-feedback.schema.json:39`(evidence.verdictPath) + 终判本体 `tier2-verdict.schema.json` |
|
||||
| tracePath | ref(→ trace.jsonl) | ✓ | 本局生成轨迹指针 | 引用 `verdict-feedback.schema.json:40`(evidence.tracePath) + `contracts/trace/` |
|
||||
| screenshots[] | string[] | ✓ | 四件套取证图路径 | 引用 `verdict-feedback.schema.json:42`(evidence.screenshotDir) / `tier2-verdict.schema.json:195` |
|
||||
| costActual | {totalRmb, tokens?:{in,out,cached}} | ✓ | 本局真实成本;权威源 new-api 计费行,由 cost.py 按 traceId 关联 best-effort 回填 | 引用 `tier2-trace-event.schema.json:56`(cost.cost_rmb) + `result_out.py:140-142` |
|
||||
| simRunRef | ref(→ 仿真器产物) | 条件(optional) | 快进仿真器跑对照的产物指针(经济仿真非劣化判据的取数来源) | 新字段·锚 §2.C 快进仿真器 |
|
||||
|
||||
> 结构上等价于:EvidencePackage = 信封 + C6.evidence(verdictPath→gateRunRef / tracePath / screenshotDir→screenshots)+ {costActual, simRunRef}。evidence.traceId 由信封 traceId 承载,不重列。〔fable 合并期裁定·终审签认 2026-07-06:§2.C 路 A 成立,simRunRef 本期即冻为 optional 字段(占位),不等仿真器工具落地。〕
|
||||
|
||||
示例 JSON(场景 A · 宠物系统的九门 + 经济仿真非劣化证据):
|
||||
|
||||
```json
|
||||
{
|
||||
"artifactType": "EvidencePackage",
|
||||
"artifactId": "evidence-pet-001",
|
||||
"schemaVersion": 1,
|
||||
"producedBy": { "actorKind": "tool", "actorId": "门/工具(九门·仿真器·校验器)", "configVersion": "harness/play.cdp-9" },
|
||||
"provenance": { "source": "gateRun:2026-07-21T15:02", "ts": "2026-07-21T15:05:00+08:00", "nature": "事实" },
|
||||
"traceId": "t-nightmkt-1421", "gameProjectId": "nightmarket",
|
||||
"gateRunRef": "game://nightmarket/runs/1421/verdict.json",
|
||||
"tracePath": "game://nightmarket/runs/1421/trace.jsonl",
|
||||
"screenshots": ["…/first-paint.png", "…/after-play.png"],
|
||||
"costActual": { "totalRmb": 0.42, "tokens": { "in": 38210, "out": 6740 } },
|
||||
"simRunRef": "game://nightmarket/sim/pet-tip-vs-baseline.json"
|
||||
}
|
||||
```
|
||||
|
||||
**⑦ 升级事件(EscalationEvent)——任一席(多为实现席)→制作人席;制作人席→创作者(终端升级)。** 升级事件是「我这一档判断不了、得往上抛」的出口,升级链的终端裁决人是创作者——档 2「先问」就是一条 presentedTo=creator 的升级事件(缺口①终审件)。红线是发完干净收口、不悬挂——它一定被一个决策(新工单 / 版本决策 / 创作者选择 / 砍功能)接住。
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| reason | {code(enum), detail} | ✓ | 升级原因码 + 人读细节;enum 覆盖 契约变更需主设计 / 决策史对撞 / 预算击穿 / 依赖阻塞 / 熔断 / 白名单越界扩单(scope_expand,缺口⑤) | 新字段·枚举锚 §3① escalationPolicy + 四道熔断(相邻胚胎 `tier2-verdict.schema.json:183` breakerKind: step_cap/budget/stuck/timeout) |
|
||||
| blockedWorkOrder | ref(→ WorkOrder) | ✓ | 被阻塞的工单 | 引用 WorkOrder(§3①)artifactId |
|
||||
| optionsInProductLanguage[] | {label, consequence}[] | ✓ | 翻成人话的选项,交制作人席(再转创作者)裁;禁技术黑话 | 新字段·锚 §4.3「把选项翻成人话」+ §2 制作人席职责 |
|
||||
| decisionHistoryHit | {priorDecisionRef, conflict} | 条件 | 执行期二道网:实现中撞上约束性决定时携带,priorDecisionRef 指向 decisions 条目(如 `Verdict-300#/decisions/0`);铸单时一道网 = WorkOrder.decisionRefs(缺口⑨终审件,§3①) | 新字段·锚 §1.2 场景 C 对撞双道 |
|
||||
| status | enum(open/resolved) | ✓ | 收口态;resolved 时指向接住它的下游工件(不悬挂纪律的机器可判面) | 新字段·锚 §3⑦「发完干净收口不悬挂」 |
|
||||
| presentedTo | enum(producer/creator) | ✓(默认 producer) | 升级呈递对象;creator = 档 2「先问」的用户面——迁移/重置/放弃这类选项经它到创作者(缺口①终审件) | 新字段·锚 §1.2 场景 B 第四步 |
|
||||
| answer | {chosenLabel, answeredAt} | 条件(presentedTo=creator 且已答) | 创作者的选择落档、进账本可回放;落定即 status→resolved | 新字段·同上 |
|
||||
| decisions[] | {constraint, scope, rationale, standingUntil?}[] | 条件 | 升级裁决产生的约束性决定随收口落档(与判定书 decisions[] 同构,缺口⑨终审件) | 新字段·锚 §1.2 场景 C |
|
||||
|
||||
示例 JSON(场景 C · 第 1400 次改动「高峰期太卡了」→ 实现席要重开渲染合批,决策史对撞):
|
||||
|
||||
```json
|
||||
{
|
||||
"artifactType": "EscalationEvent",
|
||||
"artifactId": "escalation-perf-1400",
|
||||
"schemaVersion": 1,
|
||||
"producedBy": { "actorKind": "seat", "actorId": "实现席#perf", "configVersion": "impl/2.1" },
|
||||
"provenance": { "source": "workorder:WO-perf-1400", "ts": "2026-07-25T09:12:00+08:00", "nature": "推断" },
|
||||
"traceId": "t-nightmkt-perf1400", "gameProjectId": "nightmarket",
|
||||
"reason": { "code": "decision_history_conflict", "detail": "高峰渲染优化的最直接手段是重开合批,但决策史显示第 300 次改动为正确性显式关闭了它" },
|
||||
"blockedWorkOrder": "WO-perf-1400",
|
||||
"optionsInProductLanguage": [
|
||||
{ "label": "换一种不碰合批的优化(分帧生成顾客)", "consequence": "改动大一点,但不会让老的显示错误回来" },
|
||||
{ "label": "重开合批并同时修掉当年那个显示错误", "consequence": "见效最快,但要连带把三年前修过的问题一起重做验收" }
|
||||
],
|
||||
"decisionHistoryHit": { "priorDecisionRef": "Verdict-300#/decisions/0", "conflict": "重开 renderBatch 与 D300 约束「合批保持关闭」相斥" },
|
||||
"presentedTo": "producer",
|
||||
"status": "open"
|
||||
}
|
||||
```
|
||||
|
||||
**⑧ 回流工单(LoopbackOrder)——遥测→制作人席。** 回流工单是「线上真数据回头指出一个问题」的工件化。它逐字承接数据飞轮校准单的六段口径(不另造),只是把粒度收到单局单信号、把消费方接到制作人席分诊。
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| telemetrySignal | {metric, window, delta} | ✓ | 触发段:遥测信号;metric ∈ 次留/完玩率/播放量/帧率 P75/累计分账 | 引用数据飞轮 §3.3 触发+输入段;metric 口径对齐 game_telemetry_game_stat + 次留旁路聚合(R6) |
|
||||
| corpusWindowRef | ref | 条件(平台级必填,单局可空) | 输入段:回流语料窗口切片指针 | 引用数据飞轮 §3.3 输入段 |
|
||||
| hypothesis | string | ✓ | 分析段:赢家对照/信号的假设(per-game 轻量对照) | 引用数据飞轮 §3.3 分析段「赢家对照先行、回归其次」 |
|
||||
| suggestedScene | ref(→ 场景注册表) | ✓ | 产出段:建议路由的场景族(制作人席分诊入口);平台级对应物 = 校准单六去向 | 引用 §1.2 场景 + §2.B 场景注册表;六去向见数据飞轮 §3.3 |
|
||||
| governanceNature | enum(观察/直接改/转提案/建议) | ✓ | 治理段:去向性质分级 | 引用数据飞轮 §3.3 治理段三性质 + 六去向表 |
|
||||
| validationWindowRef | ref | 条件 | 验证段:验证窗口指针(对照同品类未更新款) | 引用数据飞轮 §3.3 验证段 |
|
||||
|
||||
〔fable 合并期裁定·终审签认 2026-07-06:回流工单 scope 两粒度——**game-level**(单游戏信号→该游戏制作人席,即本工件的原子单元,场景 C 的性能修复)与 **platform-level**(校准单→质量轨,月度批 + 样本门 + 六去向)。平台级归数据飞轮 SoT,本档只引用其六段口径、不重定义;两粒度共用六段、粒度不同(单张回流工单向上聚合成校准单的语料一行)。〕
|
||||
|
||||
示例 JSON(场景 C 主题 · 遥测发现《夜市一条街》高峰期掉帧 + 次留下滑,game-level):
|
||||
|
||||
```json
|
||||
{
|
||||
"artifactType": "LoopbackOrder",
|
||||
"artifactId": "loopback-perf-2607",
|
||||
"schemaVersion": 1,
|
||||
"producedBy": { "actorKind": "telemetry", "actorId": "遥测(回流入口)", "configVersion": "telemetry-rollup/1.0" },
|
||||
"provenance": { "source": "telemetry-window:2026-07-01..07-31", "ts": "2026-08-01T02:00:00+08:00", "nature": "事实" },
|
||||
"traceId": "t-nightmkt-loopback-2607", "gameProjectId": "nightmarket",
|
||||
"telemetrySignal": { "metric": "帧率P75@高峰", "window": "2026-07 自然月", "delta": "48fps→31fps,跌破 3s 首屏门相邻的卡顿阈" },
|
||||
"hypothesis": "高峰顾客并发峰值下渲染未分帧,卡顿与本月次留 -6% 时间线吻合",
|
||||
"suggestedScene": "diagnose.query",
|
||||
"governanceNature": "观察",
|
||||
"validationWindowRef": null
|
||||
}
|
||||
```
|
||||
|
||||
**⑨ 蒸馏增量(DistillDelta)——各席→馆长席(缓立期由查重门代位)。** 蒸馏增量是「这次踩的坑/学的经验/定的术语,值得沉淀」的工件。它绝不直写知识库——经查重门并入,走分道纪律各归其道。v1 消费口径:缓立期 DistillDelta 仅落工件存储归档留痕,馆长门 v2 接手才做查重并入;它不经 docs-gate(那道门面向 markdown 提交面,与工件存储是两个面)。
|
||||
|
||||
| 字段 | 类型 | 必选 | 说明 | 来源 |
|
||||
|---|---|---|---|---|
|
||||
| kind | enum(坑/经验/术语) | ✓ | 蒸馏物类型 | 引用 §2 馆长席「journal/坑增量只走自己的道」 |
|
||||
| content | string(人读散文) | ✓ | 蒸馏内容,流畅中文、可检索 | 新字段·锚 AGENTS.md §7「全部简体中文、单一主题、可检索」 |
|
||||
| dedupeKey | string | ✓ | 查重键;经查重门比对,命中则更新既有条目而非新增 | 引用 §2 馆长席「查重可机器化」;查重门 = docs-gate.sh 范式 |
|
||||
| targetLane | enum(knowledge/rules/skills/workflows) | ✓ | 回写目标道(kind=坑→rules,经验→knowledge/skills,术语→knowledge) | 引用 AGENTS.md §7 四类 + §2 分道纪律 |
|
||||
|
||||
示例 JSON(场景 A 收尾 · 从宠物小费加成一役蒸馏一条坑):
|
||||
|
||||
```json
|
||||
{
|
||||
"artifactType": "DistillDelta",
|
||||
"artifactId": "distill-pet-econ-001",
|
||||
"schemaVersion": 1,
|
||||
"producedBy": { "actorKind": "seat", "actorId": "主设计席", "configVersion": "designer/1.2" },
|
||||
"provenance": { "source": "workorder:WO-pet-001", "ts": "2026-07-22T18:00:00+08:00", "nature": "推断" },
|
||||
"traceId": "t-nightmkt-1421", "gameProjectId": "nightmarket",
|
||||
"kind": "坑",
|
||||
"content": "凡改动经济系数(小费加成、售价、掉率)的工单,铸单时必须挂经济仿真非劣化门:宠物撸猫小费加成初版 +30% 快进千局即击穿金币曲线,赢线提前到达使后期内容失去意义。系数类改动不是纯内容改动,走仿真对照再交付。",
|
||||
"dedupeKey": "economy-coefficient-change-needs-sim-gate",
|
||||
"targetLane": "rules"
|
||||
}
|
||||
```
|
||||
|
||||
### 3 附 · 契约对账
|
||||
|
||||
凡既有契约已有的字段一律引用、不重定义。逐字段对账:
|
||||
|
||||
| 工件.字段 | 既有契约字段 | 处置 |
|
||||
|---|---|---|
|
||||
| 判定书.decision | `tier2-verdict:23-27` | 引用 |
|
||||
| 判定书.perCheck[] | `tier2-verdict:57`(gateResults)/`:62`(richGameGates)/`:157`(findings) | 投影 |
|
||||
| 判定书.ftueNotes | `tier2-verdict:199,256`(humanPlayability/humanTiming) + `play-spec:136`(firstPlay) | 投影 |
|
||||
| 判定书.fixFeedbackRef | `verdict-feedback.schema.json` 整份(C6) | fix 分支引用 |
|
||||
| 证据包.gateRunRef | `verdict-feedback:39`(evidence.verdictPath) | 引用 |
|
||||
| 证据包.tracePath | `verdict-feedback:40`(evidence.tracePath) + `contracts/trace/` | 引用 |
|
||||
| 证据包.screenshots[] | `verdict-feedback:42`(screenshotDir)/`:111` | 引用 |
|
||||
| 证据包.costActual | `tier2-trace-event:56`(cost.cost_rmb) + `result_out.py:142` | 引用(权威源 new-api 计费行) |
|
||||
| 交付包.filesTouched[] | WorkOrder.scopeWhitelist(§3①)+ `result_out.py:60-62`/`tier2-source-project:18` | 引用(子集约束) |
|
||||
| 交付包.sourceProjectRef | `tier2-source-project:98`(contentHash)/`:108`、`result_out.py:37-40`(sourceHash) | 引用 |
|
||||
| 规格增量.contractVersionBump | `play-spec:13-14`(schemaVersion 约定) + `check_version_bump.py`(版本闸) | 引用(复用口径) |
|
||||
| WorkOrder.acceptance.gates[] | 门名枚举 `verdict-feedback:63-67` / `tier2-verdict:307-309`(A_boot..I_control + richGame 三门) | 引用门名闭集 |
|
||||
| 升级事件.reason.code | `tier2-verdict:183`(breakerKind) | 借鉴枚举,非同字段 |
|
||||
| 回流工单.telemetrySignal.metric | 数据飞轮 §3.3 输入段 + game_telemetry_game_stat(次留待 R6 补) | 引用口径 |
|
||||
|
||||
纯新增字段(既有契约无、已给设计理由):规格增量.changes[]/migrationNote/saveDataImpact;交付包.commitHash/selfTestEvidence/journalRef;证据包.simRunRef;升级事件.optionsInProductLanguage[]/decisionHistoryHit/status/presentedTo/answer/decisions[];回流工单.corpusWindowRef/hypothesis/suggestedScene/governanceNature/validationWindowRef;蒸馏增量.content/dedupeKey/targetLane;工单.decisionRefs[]、scopeWhitelist.contracts[]·saveStateSubtrees[]、acceptance.machineChecks[];判定书.decisions[];版本卡.lineId(此七处为走查缺口①②③④⑤⑦⑨的终审增补,2026-07-06)。〔fable 合并期裁定·终审签认 2026-07-06:六处字段增补(跨五类工件——交付包+sourceProjectRef、证据包+tracePath、升级事件+decisionHistoryHit/status、蒸馏增量+targetLane、规格增量+migrationNote)采纳。〕
|
||||
|
||||
对账中收敛的四处(以既有契约为准、不自改口径):① 判定书整体本不能映射到 C6(passed=const false、装不下 accept)——改为投影 tier2-verdict + fix 分支引用 C6;② decision/perCheck/ftueNotes 真源已在 tier2-verdict——引用不重定义;③ 证据包 gateRunRef/screenshots 与 C6.evidence 重叠——引用 C6.evidence,只新增 simRunRef/costActual;④ 回流工单尺度(平台级校准单 vs 单局→制作人席)——字段对齐六段,尺度按两粒度并存(见 §3⑧ 裁定)。
|
||||
|
||||
**回流工单对齐数据飞轮校准单六段:**
|
||||
|
||||
| 校准单六段(数据飞轮 §3.3) | 回流工单字段 | 说明 |
|
||||
|---|---|---|
|
||||
| 触发(自然月出单 / 累计≥100 提前 / 遥测信号) | telemetrySignal{metric,window,delta} | metric 用既有口径:次留 D1 / 完玩率 / 播放量 / 累计分账(+ 北极星补帧率 P75) |
|
||||
| 输入(回流语料窗口切片) | corpusWindowRef | 平台级必填;单局信号可空(输入=telemetrySignal 本身 + 该局 trace/verdict) |
|
||||
| 分析(赢家对照先行、回归其次) | hypothesis | per-game 轻量对照;平台级承接品类层/全局层分层对照 |
|
||||
| 产出(修订提案,限六去向三性质) | suggestedScene | 单局→制作人席分诊场景;平台级→六去向 |
|
||||
| 治理(按去向分级过门,走 git 版本化) | governanceNature | 观察 / 直接改 / 转提案 / 建议报告 |
|
||||
| 验证(验证窗口 + 同品类未更新款对照) | validationWindowRef | 即时判据下一窗坐实、留存判据可跨窗;劣化即 revert |
|
||||
|
||||
防学偏五条、金标不纳入回流面等纪律属平台级校准单,不落单张回流工单。
|
||||
|
||||
**裁决点(§3 本节)**〔fable 合并期裁定·终审签认 2026-07-06〕:判定书认领既有胚胎——投影终判 tier2-verdict、fix 分支引用 C6 续修载荷(并存形态,§3②);工单/版本卡新立;信封统一。这三条骨架级冻结,创始人 §7 已批;六处字段增补(跨五类工件)合并期已采纳(见上)。字段增删是填肉自由度。九门 MCP 化维持 skill 的「主张非现状」判定:v1 不动现行 harness/middleware 调用形态,工件层只引用其产物。
|
||||
|
||||
## 4. 版本语义
|
||||
|
||||
**命题:版本语义是 W-ASSET-SRC(源工程长期存储/版本寻址)之上的语义层,本档一行存储都不造。** A3.5 与 W-ASSET-SRC 解决「每版源工程可寻址、可取回、可重建」;北极星在其上补四件语义——用户看时间线,模型看基线资格,谁都不看 git log:
|
||||
|
||||
1. **版本卡时间线**:每张卡 = 通过验收的工单产物(schema 见 §3③),卡带 lineId 标线归属;线状态与 live 指针留在账本/发布域,时间线视图按 lineId join 呈现(缺口⑦终审件)。落点:game-cloud 既有版本行为宿主、卡片字段作扩展。〔O-6 待核实:现行版本表字段与 tier2_source_project_version 的落地状态——W-ASSET-SRC 在飞,以其执行计划为准对齐,不双写。〕
|
||||
2. **基线资格机器戳**:「从稳定版继续」解析为「证据全绿且线上指标不劣化的最近版本」。门全绿取证据包;「不劣化」的指标窗口锚 D1 次留旁路聚合(R6 已落)与错误率。〔O-6 待核实:遥测窗口按版本切片的现状——若埋点无 versionId 维度,这是前置缺口,如实报。〕
|
||||
3. **存档兼容检查器**:规格增量的 saveDataImpact 字段(§3④)是登记面;回退/分叉前,检查器比对目标版本与当前存档的 schema 版本,不兼容则把选项翻成人话(迁移/重置/放弃)交创作者——档 2 确认,碰玩家持久化数据永远先问。胚胎:L2 save-progress 插件的 KV 存档。边界(缺口⑧终审裁定):v1 检查器只管创作者预览与新进玩家;回退后存量线上玩家的批量存档迁移是运营窗口的人在环动作,机制随 L2 版本闭环实装另设计。〔O-6 待核实:save-progress 现状是否带 schema 版本字段;§1.1.3 已坐实现行 value ≤ 4KB、无 schemaVersion,故这是走 L2 插件库通道的前置增补需求,不在本单实现。〕
|
||||
4. **意图重放取代 merge**:场景 B 的「保留雨天」= 取 V21 的工单(goal + acceptance),在 V19 基线上重新实现、过同套验收。AI 重做一个功能足够便宜,「合并冲突」这个概念对零技能创作者可以整个不存在。前置:工单工件持久化(§3①)+ A3.5 版本寻址。约束:重放的是**意图**,不是 diff——重放结果与原实现代码不同是预期行为,验收门等价才是判据。
|
||||
|
||||
映射到运行时现实:席位配方的版本化由配置控制面承担(per-POST 现装配,已落);游戏工程版本走 A3.5/W-ASSET-SRC;live 指针 = 现行 publish 审核门后的指针切换(胚胎已在,回退 = 指针回切)。〔O-6 待核实:AgentScope session 三加载路径中「加载已有工程」的 workdir 指向机制,与「按 versionId 取回重建再装载」的接缝——这是场景 B 的执行通道。〕
|
||||
|
||||
**端别边界。**〔fable 合并期裁定·终审签认 2026-07-06〕上面四件版本语义——版本卡时间线、意图重放、即时热发——只对自研 H5 运行主端成立:H5 无备案锁、可高频改(§1.1.3 E)。微信/抖音渠道端受备案锁约束(备案后改内容/代码须重新备案),版本节奏是月级「攒批→统一备案→整包提审」;渠道端没有「千次改动即时热发」,它消费的是 H5 主线里挑出来的里程碑版本——按基线资格戳(机制二:门全绿 + 线上指标不劣化)选一个合格版本,单游固化导出、提审上架。故版本语义分两个节奏面:H5 主线高频、渠道端月级挑版导出。
|
||||
|
||||
**裁决点(§4 本节)**:①版本语义对 W-ASSET-SRC 是消费者不是竞争者,依赖排序上 L2 切片(§5)必须落在 W-ASSET-SRC 首段之后;②「基线资格」的指标窗口与阈值是放量后校准值,骨架期只冻结构不冻数值。
|
||||
|
||||
## 5. 倒排切片阶梯
|
||||
|
||||
**命题:从现有 runtime 到北极星,每级切片独立可验收、且对 16 周主线各有回馈——阶梯不是「远期大楼的施工顺序」,是「每层都住人」。**
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
L0["L0 现状(已落)\n单席生成+九门+RepairMiddleware\n+A11 两段式+配置控制面"] --> L1
|
||||
L1["L1 工件化最小切片\n工单/交付包/判定书三工件+瘦版证据包\n+journal 写前意图+离场清账"] --> L2
|
||||
L2["L2 制作人席+版本闭环\n分诊/三档确认/场景注册表\n+版本卡+基线戳(踩 W-ASSET-SRC)"] --> L3
|
||||
L3["L3 多席协作\n主设计瘦版+内容+资产薄+盲评审\n规格增量/证据包/升级事件上线"] --> L4
|
||||
L4["L4 北极星\n标的游戏全程产出\n数十天/千次改动/多版本"]
|
||||
```
|
||||
|
||||
| 级 | 交付 | 验收门 | 主线接缝(16 周) |
|
||||
|---|---|---|---|
|
||||
| L1 | 三工件 + 瘦版 EvidencePackage(仅 gateRunRef/tracePath/screenshots)的 schema + 校验器;现行 tier2/cheap 链路的隐式交接钉成显式工件;journal 写前意图 + 离场清账进 harness | 一局 tier2 生成全程工件可回放(操作定义:给定 traceId,能从工件存储枚举该局全部工件、按 producedBy + 时间戳重放交接序);trace 含装配记录 | 复用波⑤ T5-8 记 context 装配、兑现验收门②「trace 含装配记录」;验收门①「工件可回放」为 L1 三工件 schema 自建、T5-8 不覆盖(除非 L1 把三工件也建模成装配注入块)。C5/C6 已立零新造;修复质量与 W-REPAIR-CTX 相邻互不越界(物理文件 middleware.py 可能同住,错峰隔离) |
|
||||
| L2 | 制作人席配方 v1(分诊/三档确认/场景注册表进 contracts)+ 版本卡 + 基线资格戳 | 场景 B 真跑:一次回退 + 一次意图重放,全程工件留痕 | 硬依赖 W-ASSET-SRC 首段——其执行计划尚未成文,L2 起点被此未定档前置卡住,非可紧随;版本卡语义可回馈 A11 产品面 |
|
||||
| L3 | 主设计瘦版 + 内容席 + 资产薄席 + 评审席 fresh 会话化;规格增量/证据包/升级事件三工件;快进仿真器工具(已有 tier2 logic-smoke 单局雏形,增量=参数扫描 + 曲线聚合) | 场景 A 真跑:宠物系统级需求端到端,含存档 schema 变更登记;**tier2 Service 各席工具面已对账封口**(内建写工具关、Team 组按席致盲,见 §2.A)〔fable 合并期裁定·终审签认 2026-07-06〕 | 内容席校验器范式可反哺 W-TPL 模板产线;资产席接 W-ASSET-MAT-VERIFY |
|
||||
| L4 | 标的游戏《夜市一条街》全程产出;数值仿真/馆长按需转正;回流工单接通 | 标的 3 场景全真跑 + 复杂度指标(系统 ≥8、改动 ≥1000、版本卡 ≥20) | 北极星本体;为 tier2 商业化档位提供能力上限证据 |
|
||||
|
||||
红线:L2 起每级碰生产窗口,按 staging-ops 排;任何一级与主线波次争资源,升级回创始人,阶梯让路。
|
||||
|
||||
**裁决点(§5 本节)**:L1 先于制作人席——先把工件钉成契约、再立消费它的席位,顺序不可倒(先立席位会让席位间用自由文本交接,工件永远补不上);L2 对 W-ASSET-SRC 的硬依赖如实标注,不并行抢跑。
|
||||
|
||||
### 5.1 阶梯与 16 周主线接缝对账
|
||||
|
||||
先说一条总纪律:**北极星阶梯整体不在 16 周产品主线的关键路径上**。主线的验收定义是那条 create→…→revenue 全链路闭环加 55 P0,而 L1–L4 补的是 tier2 复杂游戏「多 agent 工作室」的能力上限,属于生成运行时的纵深、不是 55 P0 里的任何一项产品功能。所以每一级的现实窗口不是「占用某个主线波次」,而是「搭在主线已铺好的接缝或空档上」,且都排在 7 月中旬内测冲刺让路之后——冲刺期工程侧全力压的是生成成功率 ≥80% 放量、五链路真机 e2e、A11 计费三条命门,北极星让路,与 §5 红线同向。时间锚:W1≈6/9 起跑,阶段一 W1–4 ≈ 6/9–7/6、阶段二 W5–8 ≈ 7/7–8/3、阶段三 W9–12 ≈ 8/4–8/31、阶段四 W13–16 ≈ 9/1–9/28,内测硬里程碑 = 7 月中旬;当前 2026-07-06 处阶段一收尾 / 阶段二初。
|
||||
|
||||
| 级 | 现实起点窗口 | 相邻 / 依赖的在飞工单 | 触碰 55 P0 判定 |
|
||||
|---|---|---|---|
|
||||
| L1 | 契约与 harness 部分(三工件 schema + 校验器 + journal 写前意图 + 离场清账)是 contract-first、不碰生产,内测让路后任意生成线空档可起;trace 装配记录部分挂阶段四观测线的波⑤ T5-8 节奏(波⑤ 依赖 ②③④) | 复用 = 波⑤ T5-8「context 装配可观测」;C5/C6 已落 `contracts/play-loop/`;相邻 = W-REPAIR-CTX | **不碰**。三工件、journal、装配 trace 全在生成运行时内,非 55 P0 产品功能 |
|
||||
| L2 | 不早于 W-ASSET-SRC 首段落地;而 W-ASSET-SRC 执行计划尚未成文,时点未定,现实落到内测之后、阶段三段更实;本级起碰生产窗口(版本卡落 game-cloud,按 staging-ops 排) | 硬依赖 = W-ASSET-SRC(§4 裁决点①、§5 裁决点);可回馈对象 = A11,已收尾 | **不碰验收口径,additive 触边**。版本卡建在 game-cloud 既有版本行为上作字段扩展,project 5 P0 含「版本」,L2 是其上的语义层、不改 project 版本 P0 的验收定义 |
|
||||
| L3 | 阶梯串行在 L2 之后,更远期;多席落地碰生产窗口 | 内容席校验器范式反哺 = W-TPL(2026-07-06 立项、opus 填肉在飞);资产席接 = W-ASSET-MAT-VERIFY | **不碰**。主设计 / 内容 / 资产 / 盲评审四席均为生成运行时席位,非 55 P0 产品出口 |
|
||||
| L4 | 不在 16 周内,最远期 | 北极星本体;为 tier2 富游戏商业化档位提供能力上限证据 | **不碰**。标的《夜市一条街》全程产出是能力验证,不进 MVP 上线验收 |
|
||||
|
||||
三处需要把话说透的判断:
|
||||
|
||||
**L1 的两条验收门分属两个来源,不是一个。** 验收门写的是「一局 tier2 生成全程工件可回放;trace 含装配记录」。后半句「trace 含装配记录」精确对应波⑤ T5-8 的产出——T5-8 记的是「这局装配了什么」:prompt / 配方版本、注入块清单(块名 + 版本/哈希 + 字节数)。前半句「工件可回放」T5-8 不提供:T5-8 的粒度是 context 装配块,不是 §3 定义的九类工件流转,谁产的工单被谁消费成什么交付包这条线,得靠 L1 自己交付的三工件 schema + 校验器落进 trace。所以「复用波⑤ T5-8」这句在验收门②上是实的,在验收门①上是 L1 自建、T5-8 不覆盖——除非 L1 把三工件也建模成 context 装配的注入块,让 T5-8 顺带记下它们的块名与字节。
|
||||
|
||||
**L2 的硬依赖是真的硬,但被依赖方还没排期。** W-ASSET-SRC 是 2026-07-05 已拍板的拆线首段、标注「优先」,可它的执行计划才切、尚未成文,O-6 的依赖项也写着「W-ASSET-SRC 执行计划成文」。这意味着 L2 的现实起点被一个自身未定档的前置卡住:接缝表标「硬依赖」没有错,但必须如实带上「首段本身未排期」这个不确定性,不能读成「W-ASSET-SRC 马上就位、L2 可紧随」。
|
||||
|
||||
**L1 与 W-REPAIR-CTX 语义互不越界成立,物理文件可能撞车。** W-REPAIR-CTX 只做两件小的——剩余修复次数 + 预算态格式化进注入 content、tier2 移植 `_game_log_brief`,边界红线明写「截图引用与上版 diff 不在本单」;它改的是 RepairMiddleware 续修反馈的信息量(`on_reasoning` 注入 content),碰 `tier2/gen-worker/worker/middleware.py:833-835`。L1 加的是实现席的 journal 写前意图协议 + 离场清账。一个改注入文本、一个加写前声明,职责不重叠;但两者都落在续修 / 实现席 harness 这条线上,journal 写前意图很可能与 W-REPAIR-CTX 同住 `middleware.py`,这是 lane 层面的接触点(见冲突项 C-2)。
|
||||
|
||||
**冲突项清单(只列不裁,争资源升级创始人):**
|
||||
|
||||
| 编号 | 级 | 冲突对象 | 性质 | 建议让路方向(仅建议) |
|
||||
|---|---|---|---|---|
|
||||
| C-1 | 全阶梯 | 7 月中旬内测冲刺三命门(≥80% 放量 / 五链路真机 e2e / A11 计费) | 人力 + 生成线部署窗口相争:北极星每级都吃 opus/fable 会话与 mini-desktop 窗口,与冲刺命门抢同一批稀缺资源 | 阶梯整体让路,北极星任何一级不进内测冲刺窗口 |
|
||||
| C-2 | L1 | W-REPAIR-CTX(在飞小单) | 文件 lane 接触:L1 的 journal 写前意图协议与 W-REPAIR-CTX 的注入 content 补强可能同住 `middleware.py` | W-REPAIR-CTX 是已定界的先行小单、L1 随阶梯后置,L1 让路并在其落地后接其上;两单错峰、worktree 隔离 |
|
||||
| C-3 | L2 | W-ASSET-SRC | 依赖排序 + 后端生产窗口相争:L2 版本卡 / 基线戳落 game-cloud 版本域,与 W-ASSET-SRC 源工程存储同占后端版本域与部署窗口 | L2 硬让 W-ASSET-SRC 首段先行(§5 裁决点已定此向),L2 只在其后消费、不与之抢窗 |
|
||||
| C-4 | L3 | W-TPL(在飞,与 W-NSTAR 同级) | 生成线 lane 交叉:内容席校验器范式与 W-TPL 模板产线机器门都动 cheap-worker 的校验器 / rubric 面(性质偏协同:L3 产出「反哺」W-TPL) | 以协同为先——L3 内容席范式作为 W-TPL 产线输入交接,不同期对同一校验器面并行改写;真撞窗口时 L3 让路 |
|
||||
| C-5 | L2 / L3 / L4 | 主线生产部署窗口(阶段二真机验收批次、阶段四观测波②⑤ 生产上线、W-ASSET 各段部署) | 生产窗口稀缺相争:L2 起每级碰生产,与主线部署批次共抢 mini-desktop 错峰窗口 | 北极星碰生产各级一律排在主线部署批次之后的低峰空档,按 staging-ops 排队,不与主线同窗 |
|
||||
| C-6 | L3 | W-T2LOCK(在飞止血单) | 协同非争抢:W-T2LOCK 先给 tier2 Service 写锁现网止血,L3 的「席位工具面白名单」统一中间件是其收敛终点(§2.A.4/2.A.5) | W-T2LOCK 先落止血、L3 统一中间件落地后并入退役,两单同向、不抢同一改写面 |
|
||||
|
||||
## 6. 填充工单清单(回填状态)
|
||||
|
||||
八单(O-1..O-5/O-7/O-8/O-9)已回填,回填产物入 §1–§5;O-6 挂起,等 W-ASSET-SRC 执行计划成文再起。各单答不出的问题一律标〔fable 合并期裁定〕或〔走查断点〕回终审,未自行拍板。
|
||||
|
||||
| 单号 | 目标 | 范围白名单 | 验收 | 依赖 | 状态 |
|
||||
|---|---|---|---|---|---|
|
||||
| O-1 | §1 标的规格填肉:系统清单细化、数值曲线骨架首版、资产清单到表格粒度 | §1;质量 SoT、sim-business skill | 系统 ≥8/表 ≥10;三场景细节自洽 | 无 | ✅ 回填完成(§1.1/1.1.1/1.1.2/1.1.4) |
|
||||
| O-2 | 双端渠道约束核实:微信/抖音小游戏包体/存档/API 真实限制 | §1.1.3;runtime-and-multichannel skill、渠道 SoT | 每条约束带权威出处;对架构的力标注 | 无 | ✅ 回填完成(§1.1.3);渠道定位 + 端别边界 fable 已裁 |
|
||||
| O-3 | §2 六席配方完整化 + 每席框架默认注入面审计 | §2;tier2/gen-worker、cheap-worker 源码 | 每席四层配方成文;审计给源码出处 | 无 | ✅ 回填完成(§2 六席 + §2.A);A4/D1 fable 已裁 |
|
||||
| O-4 | 快进仿真器可行性调研 | 新增 §2.C;引擎工程与九门 harness | 两路各给可行性结论 + 依据;推荐一路 | 无 | ✅ 回填完成(§2.C,推荐路 A);两保真度边界创始人已拍 |
|
||||
| O-5 | §3 九工件 schema 完整化 + 每类示例 JSON + 与 C5/C6/trace 契约对账 | §3;contracts/play-loop、contracts/trace | 九类字段表齐;对账表零冲突 | 无 | ✅ 回填完成(§3 完整化 + 契约对账);六增补字段 fable 已采 |
|
||||
| O-6 | §4 版本语义映射核实:版本表现状、tier2_source_project_version、save-progress schema 字段、session workdir 接缝、遥测 versionId 维度 | §4;game-cloud 版本域、W-ASSET-SRC 决策稿、L2 插件源码 | 五处待核实全部落地为「现状 + 出处 + 缺口」 | W-ASSET-SRC 执行计划成文 | ⏸ 挂起——等 W-ASSET-SRC 执行计划 |
|
||||
| O-7 | 场景注册表契约草案:场景族 × 四要素成 contracts 形态 | 新增 §2.B;agentic-seat-context-design §6 | 场景族全覆盖;每场景四要素齐 | O-3 | ✅ 回填完成(§2.B);D1–D4 fable 已裁 |
|
||||
| O-8 | 三场景走查初稿:按 §1.2 写完整席位-工件流文字推演 | §1.2 扩写 | 三场景每步可指认工件 schema 字段 | O-3/O-5 | ✅ 回填完成(§1.2);场景 C 走查时判「断」,终审补 schema 后回写为通;缺口台账十条已裁(§7) |
|
||||
| O-9 | 阶梯与 16 周主线接缝对账 | §5;16 周主计划、作战清单 | 接缝表成文;冲突项清单 | 无 | ✅ 回填完成(§5.1);五冲突项列 |
|
||||
|
||||
## 7. 检查单过尺留痕 + 需求基线〔提案〕件裁决总表
|
||||
|
||||
> **创始人 2026-07-06 拍定**:骨架六裁决点(主设计席立瘦版/数值仿真先工具后席/馆长·玩家席缓立/判定书并 C6 不另起/L1 工件化先于立席/L2 硬依赖 W-ASSET-SRC 的排序)全部按骨架裁定通过。填肉阶段用走查证据挑战的项,已在合并期由 fable 逐条裁定;终审(2026-07-06)对全部合并期裁定逐处复核签认(各节标记已更新为〔fable 合并期裁定·终审签认 2026-07-06〕),并对走查缺口台账十条逐条裁定(见本节末终审裁定表)。
|
||||
|
||||
**设席八问(v1 六席)**:六席的存在理由、致盲对象、回写道、产出工件已在 §2/§3 落位;三件套配方 §2 已完整;进配置控制面版本化=全部(席位=配方组合,天然进);胚胎认领=逐席标注;**第八问(框架默认注入面审计)已由 §2.A 补完**——审计坐实 Service 路 get_toolkit 无条件并入 15 件框架默认工具,cheap 已双补丁封口、tier2 未封(审计 A4,fable 已裁为 §5 L3 验收门一条);收窄方向 fable 已定为「席位工具面白名单」中间件(§2.A.5)。第八问从「未过」转「已审计、有裁定、终审签认(2026-07-06)」。
|
||||
|
||||
**注入五查/场景四要素**:属 L2/L3 详设的过尺点。场景四要素已在 §2.B 场景注册表落地(意图类/路由双值/确认档地板/遥测埋点);注入五查(制作人席 context 投影、评审席致盲配方)骨架期记应过项,L2/L3 详设逐条过。
|
||||
|
||||
**需求基线〔提案〕件裁决总表**:
|
||||
|
||||
| 〔提案〕件 | 裁决 | 理由 |
|
||||
|---|---|---|
|
||||
| 主设计席 | **采(瘦版)** | 契约变更需独立责任线;瘦到规格增量 + 词表两件 |
|
||||
| 数值仿真席 | **改** | 先工具(快进仿真器)后席;判定确定化优先 |
|
||||
| 馆长席 | **缓** | 机器门 + 抽查代位;v2 按蒸馏量转正 |
|
||||
| 玩家席 | **缓** | 真实遥测回流优先于合成玩家;FTUE 权宜进判定书 |
|
||||
| 九类工件 schema | **采** | 判定书并 C6(不另起);工单/版本卡新立;统一信封 |
|
||||
| 版本卡/基线资格戳 | **采** | 踩 A3.5/W-ASSET-SRC,本档只做语义层 |
|
||||
| 兼容检查器 | **采** | 锚存档 schema 登记(SpecDelta.saveDataImpact);save-progress 现状待核 |
|
||||
| 意图重放 | **采** | 取代 merge;重放意图不重放 diff,验收等价为判据 |
|
||||
| 星形账本通信/禁自由对话 | **采(边界澄清)** | 席间工件、席内自由(design_team 是席内结构,见 §2) |
|
||||
| 九门 MCP 化 | **弃(v1)** | 维持 harness/middleware 现状调用形态;工件层只引用产物 |
|
||||
|
||||
### 走查缺口台账(fable 终审 2026-07-06 已逐条裁定)
|
||||
|
||||
§1.2 三场景走查作为证伪测试,暴露以下 schema/配方缺口与软依赖;下表保留走查时的发现原貌(证伪记录不改写),逐条裁定见表后「终审裁定表」——九条闭合、一条归属他单,场景 C 据缺口⑨的闭合回写为通。
|
||||
|
||||
**A. schema/配方缺口(需补字段/工件/机制,触及冻结面):**
|
||||
|
||||
| # | 缺口 | 暴露场景 | 现状 | 影响 | 建议方向(不自拍板) |
|
||||
|---|---|---|---|---|---|
|
||||
| ① | 制作人↔创作者「决策请求/诊断答复」工件缺位 | B 第四步、C 第四步 | optionsInProductLanguage[] 只长在 EscalationEvent(席→制作人);制作人→创作者只有 VersionCard(版本结果通知) | 档 2「先问」(B 迁移/重置/放弃)与诊断答复(C)无工件承载、不可回放进账本 | 补一类「制作人→创作者 ConfirmRequest/DiagnoseReply」工件,承 optionsInProductLanguage |
|
||||
| ② | WorkOrder.scopeWhitelist 缺契约/schema 维度 | A 第二步 | scopeWhitelist={files[],tables[]} 两维 | 给主设计席铸的工单圈不出「只许改这几份契约」 | scopeWhitelist 增 contracts[]/schemas[] 维 |
|
||||
| ③ | acceptance.gates[] 取值域二义 | A 第五步 | 契约对账锁九门闭集,但示例含「经济仿真非劣化/validate_datatable」等非九门机器门 | 「gates=九门/checks=人判」二分装不下非九门机器门 | acceptance 三分:九门 gates/非九门机器门 machineChecks/人判 checks |
|
||||
| ④ | save_state 分类 | A 第五步 | §1.1 列为第 13 张「数据表」,实为运行时状态 schema | scopeWhitelist.tables 白名单 + 内容席 validate_datatable 对它不适用 | 明确 save_state 变更走 SpecDelta 登记 + 实现席代码,不进内容席表面 |
|
||||
| ⑤ | filesTouched ⊄ scopeWhitelist.files | A 第六步 | 白名单 `["src/systems/pet*"]` 通配前缀,示例 filesTouched 含 tipCalc.js/PlayScene.js | 新增机制天然跨既有文件,离场清账误判越界 | 铸单时白名单显式列全触碰文件,不用「只圈新文件」的通配 |
|
||||
| ⑥ | LOCKED_PLATFORM_FILES 目录锁 vs 文件锁(潜在硬断点) | A 第六步 | §2.A 审计 A4 记 11 锁定文件含「systems/*.js 等」,未给全清单 | 若 systems/ 目录级锁,实现席写不了玩法系统文件、场景 A 断在写码 | 补全 11 文件清单,判定 systems 是目录锁还是特定文件锁 |
|
||||
| ⑦ | VersionCard 缺「线状态/live」字段 | B 第八步 | 有 versionId/baseVersionId,无 live/archived/forked-away | 分叉后旧线标记、live 指针在工件层不可见 | VersionCard 增 lineStatus/isLive 字段 |
|
||||
| ⑧ | 线上玩家批量存档迁移无主 | B 第五步 | §4 兼容检查器只覆盖创作者单份开发存档 | 回退降级后全体线上玩家存档不兼容,谁负责、什么机制未定 | 明确线上批量迁移责任方(产品/审核台轨?)与降级迁移机制 |
|
||||
| ⑨ | WorkOrder 缺 decisionHistoryHit + 决策史条目 schema 缺位(场景 C 断点核心) | C 第六步 | decisionHistoryHit 只在 EscalationEvent(执行时);决策史条目无 schema,判定书 Verdict 装不下决策语义 | 场景 C 立身机制「铸单时自动对撞」无数据基础、无字段落点 | 补「决策史条目」工件或扩判定书「决策语义」段;WorkOrder 加 decisionHistoryHit(铸单时)+ EscalationEvent 兜底两道 |
|
||||
| ⑩ | confirmFloor additive/breaking 细分 + 确认档时序 | A 第一/五步 | 场景注册表原记「saveData 命中即 floor 2」,不分性质、且分诊时拍死 | 与 §1.2 场景 A 档 1 冲突;additive 变更被误升档 2 | confirmFloor 分 additive(不顶 2)/breaking(顶 2);确认档终判推迟到 SpecDelta 已知后(**§2.B 已采纳此方向**,终审已签认——见裁定表⑩) |
|
||||
|
||||
**终审裁定表(2026-07-06,fable):**
|
||||
|
||||
| # | 裁定 | 落位 |
|
||||
|---|---|---|
|
||||
| ① | 闭合——不加第十类:升级事件方向扩「制作人席→创作者(终端升级)」,增 presentedTo/answer 字段,档 2「先问」= presentedTo=creator 的升级事件;诊断答复裁为 trace 留痕、不工件化(只读问答工件化会让账本被咨询噪音淹没) | §3⑦ 表 + §1.2 B 第四步/C 第四步 + §2.B 判读要点 |
|
||||
| ② | 闭合——scopeWhitelist 增 contracts[]〔契约路径 + JSON Pointer 锚〕 | §3① 表 + §1.2 A 第二步 |
|
||||
| ③ | 闭合——acceptance 三分{gates 九门闭集 / machineChecks 非九门机器门 / checks 人判} | §3① 表 + §1.2 A 两张工单示例 |
|
||||
| ④ | 闭合——save_state 定性为运行时存档 schema(§1.1 清点改「12 表 + 1 存档 schema」),白名单增 saveStateSubtrees[] 维,其校验器 = 兼容检查器 | §1.1 清点/表行 + §3① 表 |
|
||||
| ⑤ | 闭合——白名单语义 = 「新文件通配前缀 + 必触碰既有文件显式列全」并集展开,filesTouched ⊆ 展开集,越界发升级事件 scope_expand 改单、禁静默 | §3①⑤⑦ + §1.2 A 第五/六步示例 |
|
||||
| ⑥ | 闭合(源码核实)——锁 = 10 个显式文件路径 frozenset 精确匹配(`toolkit.py:34-45`/`:50`),systems/ 只锁四个具名平台系统文件、非目录 glob,场景 A 可写、硬断点不成立;fixture 分工约定(agent 只写表现层)比锁窄,实现席写玩法系统文件归 L3 分工规格演进;§2.A.4 计数订正(11→10) | §1.2 A 第六步 + §2.A.4 |
|
||||
| ⑦ | 闭合——VersionCard 增 lineId(不可变);线状态/live 刻意不上卡(卡不可变,可变状态归账本/发布域,视图 join 呈现) | §3③ 表 + §4.1 + §1.2 B 第八步 |
|
||||
| ⑧ | 归属他单——定性为开放实装项:v1 检查器只管创作者预览与新进玩家,存量玩家批量迁移 = 运营窗口人在环、机制随 L2 版本闭环实装另设计;前置事实归 O-6 | §4.3 边界句 + §1.2 B 第五步 |
|
||||
| ⑨ | 闭合——不加第十类:decisions[]{constraint, scope, rationale, standingUntil?} 落判定书 + 升级事件、账本建决策索引、WorkOrder.decisionRefs 铸单机械注入(一道网)、decisionHistoryHit(priorDecisionRef)执行期二道网;场景 C 回写为通 | §3①②⑦ + §1.2 C 第六步 + §2 制作人席配方 |
|
||||
| ⑩ | 闭合(随 N3)——confirmFloorRule 结构化{baseTier, irreversibleSources, saveDataPolicy},additive 不顶/breaking 顶 2,终判推迟到 SpecDelta 已知后 | §2.B 字段表 + §3① confirmTier |
|
||||
|
||||
**B. 软依赖(已知前置/他单负责,如实引用不写成已就位,非本档缺陷):**
|
||||
|
||||
| 依赖 | 暴露场景 | 现状引用 | 归属 |
|
||||
|---|---|---|---|
|
||||
| 快进仿真器工具落地 | A 第四/七/八步 | 数值仿真席缓立 v2、可行性 §2.C 坐实路 A 成立;工具未落地时「数值影响判定」退化人工判读、EvidencePackage.simRunRef optional 占位 | §2.C/§5 L3 |
|
||||
| 实现席 journal 写前意图协议缺 | A 第六步 | §2 明标现状实现席无 journal 协议、DeliveryPackage.journalRef 依赖 §5 L1 切片补 | §5 L1 |
|
||||
| 源工程版本寻址/取回通道 | A 第六步、B 第六步 | sourceProjectRef 寻址锚、意图重放「按 versionId 取回 V19 重建装载」压 W-ASSET-SRC 源工程存储 + session「加载已有工程」workdir 接缝;W-ASSET-SRC 首段未排期、接缝 O-6 待核 | W-ASSET-SRC / O-6 |
|
||||
| 存档面定容 + schemaVersion | A 第三步、B 第四/五步 | §1.1.3 坐实现行 H5 存档 value≤4KB、单 key 白名单、L2 save-progress 无 schemaVersion;saveDataImpact.saveSchemaVersion 依赖存档面重新定容 + 加版本,走 L2 插件库通道、不在本档 | L2 插件库 / O-6 |
|
||||
| 遥测 versionId 切片维度 | A 第九步、B 第三步、C 第三步 | baselineStamp.telemetryNonRegression、帧率按版本切片依赖埋点带 versionId 维度;现状 O-6 待核 | O-6 |
|
||||
|
||||
---
|
||||
|
||||
**评审与后续**:八单(O-1..O-5/O-7/O-8/O-9)已回填、O-6 挂起等 W-ASSET-SRC 执行计划成文;Codex+Opus 双评审 N1–N14 已修入;fable 终审已毕(2026-07-06:台账十条裁定、场景 C 补 schema 回写为通、20 处合并期裁定签认)。下一步 = 创始人拍;获批后按 frontmatter sot-impact 申报收口,SVG 门面图(席位-工件流 + 切片阶梯两张)随定稿波按 feature-design-doc house style 补,当前以 Mermaid 为事实源。
|
||||
132
docs/agent-specs/2026-07-06-生成侧过程蒸馏回路-设计.md
Normal file
132
docs/agent-specs/2026-07-06-生成侧过程蒸馏回路-设计.md
Normal file
@ -0,0 +1,132 @@
|
||||
---
|
||||
date: 2026-07-06
|
||||
topic: 生成侧过程蒸馏回路
|
||||
status: 骨架(fable 主笔 2026-07-06,W-GENLOG 第一步)——机制承重裁决已定(过程校准单六段同构/出口四级/防学偏姊妹条),原料字段核实、统计脚本规格与首单 runbook 留给 opus 填肉(工单见 §6);填肉后过 Codex+Opus 双评审 + fable 终审,再交创始人拍。
|
||||
sot-impact: 不新建 canonical topic。本环是数据飞轮 SoT(`架构/生成引擎/数据飞轮.md`)§3.3 回流半环的姊妹半环:锚从「留存/收益」换成「过门率/成本/轮数/修复空转」,六段机制、治理词汇与防学偏纪律逐条对齐其原文,不重写不冲突;定稿后以姊妹节收口进该 SoT(G-5),本档转执行留痕。不改校准单六去向治理,不改质量 SoT 评分口径,不动九门与验收基准;全部出口走目标资产既有过门通道(W-TPL 模板产线 / 各机器门 / 品类 skill 过门 / prompt 四道闸),本环不新增任何落库权。运行时图说「改动六·进化语料萃取」的成功面萃取并入本环产出面(见 §4),该处回写一笔随 G-5,不另立第二条萃取线。
|
||||
上级: docs/mvp/MVP作战清单.md
|
||||
关联: docs/architecture/架构/生成引擎/数据飞轮.md §3.3(校准单六段/六去向三性质/防学偏五条/并发时序纪律) · docs/architecture/架构/生成引擎/游戏质量与爆火能力.md(质量口径,只引用) · docs/architecture/架构/生成引擎/agentic运行时架构图说.md(改动六·进化语料萃取立位) · docs/agent-specs/2026-07-06-黄金模板规格件-设计.md(W-TPL 出口承接) · docs/agent-specs/2026-07-06-复杂游戏北极星件-设计.md(蒸馏增量工件/馆长门=席位化终态) · .agents/skills/gen-path-parity-harness.md · .agents/skills/prompt-governance.md · game-runtime/games/amgen-c2v-4/trace.jsonl(在仓样本) · game-runtime/games/_wg1-gen/breakout/evidence/verdict.json(在仓样本)
|
||||
图清单: [骨架期 Mermaid 两张(图1 两半环关系 · 图2 过程校准单六段流);SVG 门面图随定稿按 architecture-diagram-atlas 补]
|
||||
---
|
||||
|
||||
# 生成侧过程蒸馏回路 · 设计(骨架)
|
||||
|
||||
生成过程日志里躺着高频问题、错误与弯路,这件事不需要论证——它已经被人工挖矿反复证明:15 个插件签名的母语化,起点是失败日志里反复出现的同一类摩擦;`save.get` 幻觉、latch 终态口径、泛型声明误杀存档游戏,全是人读 trace 读出来的;reskin 数据点靠人工对照三路生成的 AI 写量 diff 才成立。每一条都最终蒸馏进了模板、门或 skill,每一条也都依赖"恰好有人有空读日志"。矿有金,没有产线——覆盖率是随机的,节奏是被动的,放量后日志量涨一个量级,人工读法直接失效。
|
||||
|
||||
本档立这条产线。它与已批准的数据飞轮回流环(SoT §3.3)是同一个飞轮的两个半环:回流环拿线上结果(留存/收益)校准"生成**什么**",本环拿生成过程(过门/成本/轮数/空转)校准"**怎么**生成"。回流环被两个连接键与放量前置卡着,原料要等;本环的原料已经在盘上,即刻可跑。
|
||||
|
||||
## 0. 目标与边界
|
||||
|
||||
**命题:过程蒸馏不是新机制,是校准单机制换一个锚的第二次实例化。**凡是回流环已经想清楚的——六段闭环、人审治理、验证窗口、防 Goodhart——本环逐条继承;本档只写差异面:锚、输入粒度、分析方法、出口通道。两环共用治理词汇,不各立一套,审的人只需要学一次规矩。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
T["生成过程日志(在盘)<br/>trace.jsonl · verdict.json<br/>game-log.json · repairs · cost"] -->|"本环 · 过程校准单<br/>锚:过门率/成本/轮数/空转<br/>节奏:即刻可跑"| A["资产改进<br/>模板/脚手架 · 门/工具<br/>skill · prompt"]
|
||||
R["线上结果(待放量)<br/>留存 · 收益 · 完玩"] -->|"回流环 · 校准单(SoT §3.3)<br/>锚:留存/收益<br/>前置:join 键 + 放量"| A
|
||||
A -->|"验证窗口<br/>非劣化才算数"| T
|
||||
```
|
||||
|
||||
边界,五条硬的:
|
||||
|
||||
1. **不动回流环机制。**校准单六段、六去向三性质、防学偏五条、三条并发时序纪律,SoT §3.3 原文有效;本环是姊妹实例,冲突即以 SoT 为准回修本档。
|
||||
2. **离线批分析,不进生成热路径。**不加运行时钩子、不改 worker 代码,原料一律是已落盘产物;分析节奏与生成吞吐零耦合。
|
||||
3. **不碰结果锚。**留存/收益/完玩归回流环;本环指标止于生成完成线(门、成本、轮次、空转)。同一资产两环同窗都想改时,按 §3 并发纪律排窗。
|
||||
4. **金标 play-spec 与验收基准不纳入蒸馏面。**与回流环同一条红线:基准随数据漂移,跨窗可比性与防 Goodhart 的锚就没了;发现"门口径可能误判"时,产出的是门修正工单、走门自己的修订治理,不是本环直改。
|
||||
5. **蒸馏永不直写。**每条产出是带证据的提案/工单,落库全走目标资产既有门;本环自身没有对任何资产的写权。
|
||||
|
||||
## 1. 原料盘点(命题级;字段与批量的精确核实归 G-1)
|
||||
|
||||
**命题:本环零采集——只消费已存在的落盘物,一件新埋点都不加。**
|
||||
|
||||
每局生成现有四类过程记录,全部已在产:
|
||||
|
||||
- **trace.jsonl**:统一轨迹核心五字段(`traceId/step/cost/verdict/timestamp`)+ `ext.raw` 事件流(ReplyStart / ReasoningPhase / ModelCall / 工具调用等,在仓样本 `amgen-c2v-4/trace.jsonl` 331 行实读)。工具调用序列、轮数、token/成本、修复边界都在这一条流里;
|
||||
- **verdict.json**:九门逐门结果带测量值(在仓样本 `_wg1-gen/breakout/evidence/verdict.json`:`guards.{A_boot,C_frame.delta,I_control.results[],D_render.bright,E_live.distinctStates,B_uncaught,F_wiring.callCount}`)——失败模式的结构化半成品,门×品类矩阵直接从它聚合;
|
||||
- **game-log.json**:运行时日志(ctx.log + 插件自带 + smokeBoot 捕获),失败局的现场;
|
||||
- **库侧**:`game_aigc_task.trace_json`(九门轨迹账本)与 `readiness_score`,数据飞轮 SoT §1 已核实在库。
|
||||
|
||||
历史批的现状要说实话:**在仓即刻可读的是小头**(trace.jsonl 9 局、verdict.json 33 局、amgen-* 18 目录、_wg1-gen 38 子目录,2026-07-06 实数),bake-off / parity / m3 的大批产物散在 mini-desktop 产物区与库表 `trace_json` 里,首单窗口的完整盘点与拉取是 G-1 的活。两条已定的演进关系:T5-8(context 装配记录进 trace,波⑤默认关)落地后,"这局装配了什么配方"进入原料面,LLM 判读层从此可以归因"喂错了还是模型不行";统一 trace 契约(`contracts/trace/`,随控制面 phase-1)落地后,本环消费面迁移到契约形态、不双写——先用现存散落形态起步,与回流环"复用统一 trace、不另造管线"是同一句承诺。
|
||||
|
||||
## 2. 过程校准单(承重章)
|
||||
|
||||
**命题:六段一一对应回流环校准单,逐段只换内容不换结构;段名与治理语义以 SoT §3.3 原文为准。**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
X["触发<br/>批量阈值/波次收口"] --> I["输入<br/>窗口全量过程切片"] --> AN["分析<br/>代码统计 + LLM 判读"] --> P["产出<br/>高频模式榜(提案)"] --> G["治理<br/>四级出口各过既有门"] --> V["验证<br/>下窗口同指标非劣化"]
|
||||
```
|
||||
|
||||
| 段 | 回流环校准单(SoT §3.3 原文要义) | 过程校准单(本环) |
|
||||
|---|---|---|
|
||||
| 触发 | 放量后按自然月;窗口累计 ≥100 款可提前;低产量期出观察单 | 批量阈值:窗口累计新增 ≥N 局即可出单(N 待首单后定标,见 §7);或波次收口顺带出一张。放量前不需要月度网格——有批就能挖 |
|
||||
| 输入 | 归档语料窗口切片(生成特征 + 结果标签) | 窗口内全量 trace.jsonl + verdict.json + game-log.json + repairs/成本切片——过程事件粒度,不是聚合特征 |
|
||||
| 分析 | 赢家对照先行、回归其次,品类层/全局层样本门槛 | 两层:代码统计层(确定性)先行全量,LLM 判读层(语义)只读统计筛出的子集,见下 |
|
||||
| 产出 | 修订提案,逐条证据,绝不直改 | **高频模式榜**:每条 = 模式描述 + 频次 + 代表局证据指针(traceId/文件:行)+ 建议出口级(§3 四级之一);绝不直改 |
|
||||
| 治理 | 六去向三性质分级过门 | 四级出口各走目标资产既有门(§3);「同一窗口同一品类只动一类去向」纪律沿用且跨环计数 |
|
||||
| 验证 | 验证窗口对照非劣化,劣化 revert 记因 | 下一窗口同指标(过门率/成本均值/轮数分布/空转率)对同品类非劣化;劣化 revert 并在下一张单记因 |
|
||||
|
||||
**分析两层,是架构红线的执行面**(项目代码只做机械确定性的事;凡需判断/语义的归 LLM,绝不写成代码):
|
||||
|
||||
- **代码统计层**(零依赖脚本,规格归 G-2):门×品类失败矩阵(哪道门在哪个品类高频挂)、成本/轮数/token 离群局清单(分位法)、**盲修空转率**(修复轮未改善门结果的占比——护城河线挂账的头号观测,本环给它常设产出位)、幻觉 API 频次表(check/形状门拦截事件聚合)、重试与熔断事件计数。全量跑,产出是数字和局清单,不产结论。
|
||||
- **LLM 判读层**(判读维度与 prompt 归 G-3):只读统计层筛出的失败局与离群局 trace 全文及 game-log,判弯路模式(读了不该读的文件、重写本可复用的循环、churn 探针式瞎试)、prompt 误导迹象(多局在同一指引处犯同一错)、运行时异常模式。判读输出逐条挂代表局证据指针,无出处的归纳不进榜——这与九门"产模型辩不过的事实"是同一纪律。
|
||||
|
||||
统计先行、判读聚焦的次序不可倒:LLM 通读全量既贵又稀释注意力;统计层的职责就是把"值得人和模型细看的局"从大盘里筛出来。
|
||||
|
||||
## 3. 出口四级与防学偏姊妹条
|
||||
|
||||
**命题:出口优先级 = 注入铁律(模板承载 > 门强制 > prompt 提醒)的回路执行面——每条模式先问能不能烤进模板,再问能不能做成门,最后才许进 skill/prompt 当提醒。**
|
||||
|
||||
| 级 | 出口 | 承接通道(既有门,本环不另立) | 已被人工实证的同类先例 |
|
||||
|---|---|---|---|
|
||||
| 1 | 模板/脚手架变更工单 | W-TPL 模板产线(规格十件 + 四道准入门) | reskin 数据点→经营黄金脚手架;L1 自适应缩放修复 |
|
||||
| 2 | 门/校验器/工具签名修正工单 | 各机器门修订 + L2 插件通道(littlejs-game-dev 受控面) | latch 终态口径修;泛型声明门正则修;15 签名母语化 |
|
||||
| 3 | skill 补密度(few-shot 指路、易犯幻觉清单、品类坑条目) | W-GENRE 品类 skill 与 littlejs-game-dev 既有过门 | `save.get` 幻觉;插件数口径锚 |
|
||||
| 4 | prompt 修正(最后选择) | prompt 四道闸(版本闸 + 真模型闸,W-PCI 已接线) | 双源同改纪律下的指引修正 |
|
||||
|
||||
与回流环六去向的关系要划清:回流环去向①②③(few-shot/skill 数值锚/脚手架)与本环出口 1/3 落在**同一批资产**上,只是证据来源不同(结果证据 vs 过程证据)。因此「同一窗口对同一品类只动一类去向」的并发纪律**跨环计数**——两环同窗改同一品类的同类资产,验证窗口就归因不了功过。本环出口 2(门/工具)与 4(prompt)是回流环没有的新通道,各自的既有治理(机器门修订评审、prompt 四道闸)就是它们的门,本环不为它们另立验收。
|
||||
|
||||
**防学偏姊妹条**(回流环五条原文继承;以下四条补过程侧特有的风险面):
|
||||
|
||||
1. **清单膨胀与条数递减铁律的反向张力,用出口升级强制解。**易犯幻觉清单、品类坑条目是 skill/prompt 注入物,天然只增不减;而注入铁律要求 prompt 里的规范条数单调递减。强制机制:每条 3/4 级出口提案必须先回答"为什么不能升 1/2 级"(能烤进模板或做成门的,不许赖在清单里);清单条目带命中频次戳,连续两个窗口零命中即列退役候选——**清单是缓冲区,不是终点站**。
|
||||
2. **蒸馏永不改验收基准**(§0 边界 4 的回路面重申):统计层发现门口径疑似误判,产出是门修正工单走门的治理,榜单无权直改任何阈值与判据。
|
||||
3. **统计口径变更必须记因并双跑一窗。**过门率/空转率/离群分位的计算口径一旦变更,当窗新旧口径并示、校准单记因——否则"指标游走"能伪装成"持续改进"。
|
||||
4. **两环撞窗,结果锚优先。**同一资产回流环与本环同窗都出了提案,回流环先落、本环顺延一窗——过程优化最终服务于结果,结果证据的效力高于过程证据。〔此条为骨架裁定,可在填肉与评审中用反例挑战,回 fable 终审〕
|
||||
|
||||
## 4. 与既有件的关系对照
|
||||
|
||||
| | 本环(过程蒸馏) | 回流环(SoT §3.3) | 改动六·进化语料萃取(运行时图说) | W-NSTAR 蒸馏增量/馆长门 |
|
||||
|---|---|---|---|---|
|
||||
| 锚 | 过门率/成本/轮数/空转 | 留存/收益(完玩) | 成功产物 → Template/Debug Skill | 席位化承载(不另立锚) |
|
||||
| 输入粒度 | 过程事件流(trace 全文) | 归档特征 + 结果标签 | 成功产物工件 | 各席回写的蒸馏增量工件 |
|
||||
| 节奏与前置 | 即刻可跑(原料在盘) | 等 join 键(W4/留存口径)+ 放量 | 立位存在、未落地 | 随北极星 L3+ 切片 |
|
||||
| 本档裁决 | —— | 姊妹半环,治理同源 | **成功面萃取并入本环产出面**(榜单含正模式:高过门低成本局的可复制特征),不另落第二条萃取线;图说改动六处回写一笔随 G-5〔上抛确认〕 | 本环离线批分析 = 蒸馏增量/馆长门的胚胎;席位化后,统计层进馆长门、判读层成席内工序 |
|
||||
|
||||
## 5. 首单实证定义
|
||||
|
||||
**命题:首单不是建平台,是用一张真校准单证明"产线挖得出人工挖不到的东西"。**
|
||||
|
||||
- **窗口**:现存历史批全量(在仓 amgen-*/_wg1-gen + mini-desktop 产物区 + 库表 trace_json,盘点归 G-1);零新增采集。
|
||||
- **两条判据**:① 榜上至少一条高频模式是人工未登记过的(对照 `.agents/` 现有 skill/knowledge 坑清单逐条查重后仍成立);② 至少一条产出走完出口通道真落库(四级任一,含其既有门全绿)。两条都成立,产线成立,节奏与阈值 N 才有资格定;否则如实记"矿贫于预期"并停,不为回路而回路。
|
||||
- **工具形态**:一个零依赖统计脚本(标准库单文件,风格对齐 rubric-sync-gate 栈;落点与是否挂常设入口归 G-2)+ 一个 LLM 判读 prompt(G-3)。不建平台、不建看板、不起服务。
|
||||
- **产出物**:一份过程校准单 markdown,落 `docs/agent-specs/` 留痕层,格式即 §2 六段。
|
||||
|
||||
## 6. opus 填充工单(六要素齐;答不出的问题一律标〔裁决点〕上抛,禁自行拍板)
|
||||
|
||||
| 单号 | 目标 | 范围白名单 | 验收 | 预算 | 依赖 | 升级策略 |
|
||||
|---|---|---|---|---|---|---|
|
||||
| G-1 | 原料字段与批量核实:实读 trace.jsonl/verdict/game-log 各 ≥3 样本出字段表;盘点在仓 + mini-desktop + 库表三处历史批的局数与完整度(有 trace 无 verdict 之类的残缺态如实分类) | 产物目录只读、DB 只读查询、本档 §1 回填 | 字段表每行带样本出处;数据量表按批次×完整度分格 | opus 0.5 会话 | mini-desktop 可达 | 样本缺失/字段与骨架描述不符→如实改 §1 并列不符项 |
|
||||
| G-2 | 统计脚本设计规格:§2 统计层五类指标的输入/算法/输出/复跑口径,离群分位与空转率的判定定义;只设计不实现 | 新增 §2 附节;读 gen-path-parity-harness、rubric-sync-gate.py(栈风格参照) | 每指标可按规格独立实现;复跑同窗结果一致的口径写明 | opus 0.5 会话 | G-1 | 指标需新增采集才能算→标〔违背零采集边界〕上抛,不得扩采集 |
|
||||
| G-3 | LLM 判读维度与 prompt 草案:判读维度表、输出 schema(模式/频次/证据指针/建议出口级)、子集筛选与成本预估 | 新增 §2 附节;读真实失败局样本 | prompt 草案对 ≥2 个真实失败局试判,输出合 schema 且证据指针真实 | opus 0.5 会话 | G-1 | 判读 prompt 治理归属(入不入 registry)→〔裁决点〕 |
|
||||
| G-4 | 首单执行 runbook:窗口界定、脚本跑法、判读派发、过程校准单模板、两判据判定法、查重对照面清单 | 新增 §5 附节 | runbook 可被一个 opus 会话照跑;查重面覆盖 .agents 全部坑类条目 | opus 0.5 会话 | G-1/2/3 | 首单判据不成立→如实报,不降判据 |
|
||||
| G-5 | 数据飞轮 SoT §3.3 姊妹节收口文案草案 + 运行时图说改动六处回写一笔的草案(均不直改,随定稿终审落) | 草案附于本档尾 | 与 SoT 原文零冲突;改动六归并表述与 §4 一致 | opus 0.5 会话 | 本档定稿 | SoT 措辞冲突→以 SoT 为准回修本档 |
|
||||
|
||||
## 7. 裁决点汇总
|
||||
|
||||
1. **触发阈值 N 与常规节奏**:首单跑完按"矿的密度"定标(单/百局?随波次?),骨架不预设数字——上抛,随首单证据回来一起拍。
|
||||
2. **两环撞窗优先序**:§3 姊妹条 4 已裁"结果锚优先",留挑战口。
|
||||
3. **判读 prompt 是否入 prompt registry 治理**:它是内部分析工具、非生成线 live prompt,四道闸的成本闸与金标回归对它意义存疑;倾向不入 registry、按 G-3 输出 schema 试判即验,但 prompt 治理边界归 prompt-governance 口径,上抛。
|
||||
4. **改动六归并确认**:§4 已裁"成功面萃取并入本环、不另落第二条萃取线",牵动运行时图说一处回写——**创始人 2026-07-06 已拍:归并**(回写草案随 G-5,落笔随定稿终审)。
|
||||
5. **首单执行时机**:原料在盘、随时可派,但当前 W-NSTAR/W-TPL 双单在飞、内测冲刺临近——**创始人 2026-07-06 已拍:首单实证排内测冲刺后、与 W-NSTAR L1 错峰**;填肉(纯设计工作)不受此限,可先行。
|
||||
|
||||
---
|
||||
|
||||
**评审与后续**:骨架先发 §6 五张工单给 opus 填肉(G-1 先行,G-2/3 可并行,G-4 随后,G-5 等定稿);全部回填后过 Codex+Opus 双评审 + fable 终审(收口裁决:阈值 N、四级出口边界、与回流环姊妹节的合文),再交创始人拍。SVG 门面图(两半环关系 + 六段流两张)随定稿按 atlas house style 补,骨架期以 Mermaid 为事实源。
|
||||
311
docs/agent-specs/2026-07-06-黄金模板规格件-设计.md
Normal file
311
docs/agent-specs/2026-07-06-黄金模板规格件-设计.md
Normal file
@ -0,0 +1,311 @@
|
||||
---
|
||||
date: 2026-07-06
|
||||
topic: 黄金模板规格件
|
||||
status: 定稿候选(fable 主笔 2026-07-06;§7 六裁决点创始人同日全按提案拍定,D6=敏捷点击/genre 键 reflex)——§6 对照验证 ✅(§1 表清零+§8 缺口 G1–G10)、Codex+Opus 双评审 ✅(REVISE 8 + ACCEPT-WITH-FIXES 8,合并去重 16 条全修入)、fable 定稿轻读 ✅(2026-07-06);待创始人批终稿(D2 执行形态修正——维持落点+前置三件清 gamedef 化石——一并过目)。
|
||||
sot-impact: 不新建 canonical topic。本档把 plan① 效率策略「黄金模板先行」与 W-GENRE 品类四件套既有实践编译成可对账的资产类规格,不改质量 SoT(游戏质量与爆火能力)的评分口径——rubric 治理沿用其 §4 规范(canonical 现行 rubric 章,设计留痕旧称 §3.3)与金标复验纪律。落点由 D2 拍定维持 contracts/templates/,但该目录当前被 13 份 gamedef 世代品类 schema 占用(git 停 046c061d),执行前置须先归档退役旧 schema、解绑 contracts/prompts 的 registry 与 eval 化石引用,再落新规格;新增契约类目按 contracts/README 现行类目序 additive(game-host.d.ts 已占第 9 类),届时走 contract-first 另行申报。本档不动 55 P0 验收定义。
|
||||
上级: docs/plans/2026-06-25-生成引擎统一执行计划-AgentScope三档-plan.md
|
||||
关联:
|
||||
- docs/mvp/MVP作战清单.md(W-TPL 立项单 2026-07-06)
|
||||
- docs/agent-specs/2026-06-29-便宜档降AI参与-减摩擦与扩模板覆盖-设计.md(reskin 数据点与创始人推翻记录 · 丰富两步 M1 达标)
|
||||
- cheap-worker/cheap_genre_route.py(品类路由词表)· cheap-worker/cheap_verify.py(GENRE_BY_TEMPLATE / 品类 rubric 装载)
|
||||
- cheap-worker/fixtures/genre-rubrics/ · cheap-worker/fixtures/golden-specs/ · cheap-worker/fixtures/golden-samples/
|
||||
- game-runtime/games/_template-shop/(经营黄金骨架,解剖对象)· .agents/skills/littlejs-game-dev.md(单工程代码结构 SoT)
|
||||
- .agents/tools/rubric-sync-gate.py(机器门范式)· .agents/skills/gen-path-parity-harness.md(金标 play-spec 公平性与达标门)
|
||||
- docs/architecture/架构/生成引擎/游戏质量与爆火能力.md(质量口径,只引用)
|
||||
图清单: [图1 模板资产类十件与四路消费方 · 图2 新模板准入产线]
|
||||
---
|
||||
|
||||
# 黄金模板规格件 · 设计(模板的模板)
|
||||
|
||||
便宜档的模板已经是事实上的产能地基:仓里躺着六个黄金骨架(`_template` 通用 + 经营/非遗/解谜/剧情/TRPG 五品类)、五份品类设计 skill、五份品类 rubric、六份金标 play-spec、两个 few-shot 正例工程,生产 create 路的品类路由(`cheap_genre_route.py`)把用户 brief 确定性地分发到这些骨架上。MVP 主指标「AI 生成成功率 ≥80% 基于 3–5 个模板」踩的就是这套资产。
|
||||
|
||||
问题在于:这套资产是几波工单各自堆出来的手工艺品,「一个合格的黄金模板必须有什么」从没写下来过。后果已经在仓里可见——`_template-shop` 和 `_template-feiyi` 的 `assets/manifest.json` 至今写着 `"game": "_template"`、注释讲的还是点圆得分(拷贝残留没人对账);few-shot 正例有的品类有、有的没有、形态还不一致;准入证据(骨架自己过没过九门、丰富度基线是多少、一款生成多少钱)散落在各波 plan 文档里,谁也说不出「下一个新品类模板做到什么程度算入库」。批产 3–5 个 MVP 模板之前,先把规格立起来,让模板生产从手工艺变成有验收门的流水活——这是注入铁律「模板承载 > 门强制 > prompt 提醒」的执行臂:规范能烤进模板的就不该赖在 prompt 里,而模板本身的完备性得有门看着。
|
||||
|
||||
## 0. 目标与边界
|
||||
|
||||
**目标**:定义「黄金模板」这个资产类——必备件清单(§2)、准入过门标准与机器门(§3)、规格落点(§4)、选型三轴(§5),并给出拿 `_template-shop` 对照验证规格的 opus 工单(§6)。规格从仓里真实资产逆向,每一件都有在仓先例或明确缺口,不发明仓里不存在的东西。
|
||||
|
||||
**边界**:只覆盖便宜档模板产线——品类黄金骨架、路由、评分尺、金标、few-shot、锁写机制这一整套;tier2 复杂游戏的「模板」形态(脚手架+席位配方)归 W-NSTAR 裁决,防两单口径互渗。本档不改 cheap-worker 任何代码,对照验证发现的机制缺口出工单不顺手改;金标 play-spec 与 rubric 的**定义权**分别在 gen-path-parity-harness 口径与质量 SoT §4(rubric 体系),规格只规定「必须带、必须对账」,不重定义其内容标准。
|
||||
|
||||
**一个立项前提要先修正**。W-TPL 立项单沿用了「reskin 锁循环 −51%/¥0.34 = 成本主线」的记忆,但仓里的决策史不是这样:2026-06-29 创始人明确推翻了 reskin 作为策略——「便宜 = LLM 低参与度,不是游戏低质量;锁死薄循环换皮 = 砍复杂度,违背 2D 丰富游戏底线」(2026-06-29 设计档 §数据点,¥0.34 数据留痕、策略已废)。随后落地的修正路线是:品类骨架当**轻起点**(锁 plumbing、不锁玩法),接品类设计 skill 让 agent 先设计丰富玩法再实现,配非阻塞丰富度评分,M1 达标门三品类各 5/5 过九门坐实。生产 create 路今天就是这么跑的:路由选骨架、`write_whitelist=None` 不收窄(`cheap_service_driver.py:242`),agent 在骨架上自由富化;锁写机制(`write_whitelist={"game-logic.js"}`)真实存在且承重,但活在 **modify 路**(`cheap_modify.py:419`,A11 调整回路的写边界)而不是 create 量产路。所以本规格把模板定位成「丰富度正路的品类起点资产」,不是「换皮量产母版」;立项单里 ¥0.34×1.2 的成本验收锚骑在已废策略上,修正锚已随 §7 D1 拍定(n=3–5 均值 ≤¥1.0/款)。
|
||||
|
||||
## 1. 现状逆向:六骨架资产盘点
|
||||
|
||||
按 §2 规格十件对六个模板逐项对账,先摆事实(✅ 在位 / ⚠️ 有但有伤 / ✗ 缺):
|
||||
|
||||
| 规格件 | _template | shop | feiyi | puzzle | story | trpg |
|
||||
|---|---|---|---|---|---|---|
|
||||
| 1 骨架工程(L1+L3+test+README) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| 2 多样性参数空间锚块 | ✅ | ✅(core.js 顶部) | ✅(core.js:24) | ✅(core.js:25) | ✅(core.js:25) | ✅(core.js:25) |
|
||||
| 3 取证契约(_forensicsView) | ✅ | ✅(game-logic.js:243 键名钉死) | ✅(gl.js:265) | ✅(gl.js:303) | ✅(gl.js:234) | ✅(gl.js:298) |
|
||||
| 4 品类设计 skill | —(通用不适用) | ✅ sim-business | ✅ heritage | ✅ puzzle | ✅ narrative | ✅ trpg |
|
||||
| 5 品类 rubric fixture | —(通用底座 12 条) | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| 6 金标 play-spec | ✅ click-score/whack-mole | ✅ shop-serve | ✅ heritage-craft | ✅ puzzle | ✅ story-branch | ✅ trpg |
|
||||
| 7 few-shot 正例 | — | ⚠️ golden-samples 代位 | ⚠️ 仅 README+src | ✅ _fewshot-puzzle 完整 | ⚠️ golden-samples 代位 | ✗ 无 |
|
||||
| 8 路由登记(词表+GENRE_BY_TEMPLATE) | ✅(无命中回退) | ✅ | ✅ | ✅ | ✅ | ✅ |
|
||||
| 9 准入证据包(固化) | ✗ 散落 | ⚠️ golden-samples 有部分(bake-shop-serve-1 含 n=3 丰富度) | ✗ 散落 | ✗ 散落 | ⚠️ golden-samples 有部分 | ✗ 散落 |
|
||||
| 10 资产规范件(manifest 身份) | ✅ | **✗ 写着 _template** | **✗ 写着 _template** | ✅ | ✅ | ✅ |
|
||||
|
||||
表内「待对照」项已由 §6 opus 工单逐格对照落实(2026-07-06):件 2 参数空间锚块在 feiyi/puzzle/story/trpg 四骨架的 `core.js` 顶部均有「多样性参数空间」显式锚注释,件 3 取证契约在四骨架的 `game-logic.js` 均导出 `_forensicsView().state()` 且返回 `targets`(含 `occupied`)与 `score` 两键——证据行号入表。对照顺带核出几处规格与表述需修正的地方(逐条进 §8 缺口清单),几条承重发现先摆:
|
||||
|
||||
**L1 今天零漂移,但只是运气。** 六个模板各自带一份 L1 拷贝,实为**五件**而非四件——`index.html` / `entry.js` / `src/host-config.js`(全 11 插件注入)/ `src/game.js`(薄 wrapper)/ `src/main.js`(宿主引导薄包装),md5 实测五件均六份完全一致(`src/main.js` 也逐字节同源,`__gameHost`/`__gameForensics` 取证全局的挂载点就在它里面;§2 件 1 原清单只列四件、漏了 `src/main.js`,已在缺口清单登记补正)——说明拷贝纪律目前守住了。但没有任何门守着它:下次谁修 index.html 的自适应缩放(这文件修过一轮,littlejs-game-dev §7 红线 7 就是那次教训),漏改哪个模板就漂移哪个,而 L1 漂移的症状(某品类生成款桌面裁屏)要到真人试玩才暴露。这是 template-spec-gate 最便宜也最必要的一检(§3)。
|
||||
|
||||
**manifest 拷贝残留坐实「无规格则必腐」。** `_template-shop`、`_template-feiyi` 的 `manifest.json` `game` 字段都还是 `"_template"`(两处违例);但 gen-ledger 标题只有 shop 还挂着「_template『点圆得分』」,feiyi 的 gen-ledger 已单独改对为「_template-feiyi『工序节拍』」。这个不对称本身更能说明问题:同一批拷贝残留,有人想起修 gen-ledger 却没回头修 manifest,身份登记各错各的、修一半反而更难发现。这几处今天无害(经营/非遗骨架均无外采素材,表是空的),但它证明:没有机器对账的约定,连「文件抬头写对自己名字」都守不住;等模板真带美术资产时,登记表指错工程就不是无害了。
|
||||
|
||||
**few-shot 正例参差,形态未定。** 非遗、解谜走 `games/_fewshot-<genre>/` 工程形态(prompt 里 `cheap_roles.py:54-55` 按品类指路 read);剧情、经营走 `cheap-worker/fixtures/golden-samples/<genre>/<id>/`(src+evidence 固化,rubric 金标锚用);TRPG 两头都没有。两种形态各有用途(前者喂生成、后者锚评分),规格得把「哪个必备、放哪、谁消费」钉死,否则每加一个品类就发明一种放法。
|
||||
|
||||
**准入证据没有家。** `_template-shop` 独立过九门、五店 reskin n=5 收敛、M1 三品类 bake-off 各 5/5——这些证据都真实存在,但全躺在 plan/设计档的叙述里。新模板入库时「拿什么证明合格」没有固化落点,达标史无法机器对账,门就立不起来。
|
||||
|
||||
**评分尺治理是唯一已经工业化的一件。** rubric fixture 单源 + skill 内联/指针对账 + `rubric-sync-gate.py` 挂 pre-commit 与 CI + 金标复验纪律(漂移 >±1 回退)——这套是现成的成功范式,§3 的 template-spec-gate 直接仿它,§2 的其余九件要的就是把这种治理密度铺到全资产类。
|
||||
|
||||
**规格要落的目标目录不是空地,已被上一代资产占住。** §4 推荐的落点 `contracts/templates/` 今天实存 13 份 gamedef 世代的品类 schema:clicker/match/merge/idle/runner/dodge/tycoon/generic 八份旧模板,加经营/剧情/解谜/TRPG/非遗五品类,git 最后一次改动停在 `046c061d`(2026-06-18,reframe 废除 gamedef 之前)。它们没被删,是因为还有引用挂着——`contracts/prompts/registry.yaml` 的 clicker/merge/idle/tycoon 四个 designer 条目以 `config 受 contracts/templates/<x>.schema.json 约束` 指向它们,`contracts/prompts/eval/config.{clicker,merge,idle,tycoon}-designer/` 四套 Golden 目录也以它们为据。但这批 prompt 早已是化石:W-PCI 步骤 0(2026-07-04 消费面三态对账,用一手代码坐实非凭注释)判定 clicker/merge/idle/tycoon 四策划模板均为 fossil——`AigcTemplateConstants.SUPPORTED_TEMPLATE_IDS` 已把旧四模板整体下架(现行白名单 = generic + 5 品类),提交抛 `AIGC_TEMPLATE_NOT_EXISTS`、执行判 `no_template_match` 不烧 LLM,产物还是已废的 gamedef 形态 GameConfig。所以落点不是「有没有位置」的问题,是「先把化石清出去」的问题——执行前置三件见 §4。
|
||||
|
||||
## 2. 模板规格契约草案(承重章)
|
||||
|
||||
一个合格的黄金模板 = 以下十件齐备且对账一致。每件给定义、判定方式、落点形态;「机器可判」的进 template-spec-gate(§3),「须真跑」的进准入验收(§3 质量门/成本门)。
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
subgraph T["模板资产类(十件)"]
|
||||
A1["1 骨架工程<br/>games/_template-<genre>/"]
|
||||
A2["2 参数空间锚块(core.js)"]
|
||||
A3["3 取证契约(_forensicsView)"]
|
||||
A4["4 品类设计 skill"]
|
||||
A5["5 品类 rubric fixture"]
|
||||
A6["6 金标 play-spec"]
|
||||
A7["7 few-shot 正例"]
|
||||
A8["8 路由登记(双表)"]
|
||||
A9["9 准入证据包"]
|
||||
A10["10 资产规范件(manifest)"]
|
||||
end
|
||||
G["生成路<br/>scaffold + kick + 按需 read"] --> A1
|
||||
G --> A2
|
||||
G --> A4
|
||||
G --> A7
|
||||
V["评分路<br/>cheap_verify LLM judge"] --> A5
|
||||
Q["验收路<br/>九门 / 达标门 / auto-vs-golden"] --> A3
|
||||
Q --> A6
|
||||
Q --> A9
|
||||
R["路由路<br/>brief → genre 确定性分发"] --> A8
|
||||
```
|
||||
|
||||
**件 1 · 骨架工程** `game-runtime/games/_template-<genre>/`
|
||||
定义:一个**独立可玩的完整品类游戏**(不是半成品填空题),目录与 `_template` 同构——L1 固定五件(`index.html`/`entry.js`/`src/host-config.js` 全 11 插件注入/`src/game.js` 薄 wrapper/`src/main.js` 宿主引导薄包装,后者挂 `__gameHost`/`__gameForensics` 取证全局)+ L3 四件(`src/game-logic.js` 完整品类循环/`src/core.js` 纯逻辑/`src/render.js`/`src/assets.js`)+ `test/`(core 纯逻辑 node 测试 + headless-boot)+ `README.md`(富化边界指南:改哪、别动哪、锁 plumbing 不锁玩法,照 `_template-shop/README.md` 的成熟形态)。「完整可玩」是硬定义:骨架必须自己独立过九门,因为它是失配 brief 的兜底产物(路由无命中走 `_template` 的同理)——兜底件不可玩,兜底就是假的。
|
||||
判定:结构门(目录清单对账)+ L1 同构门(五件与权威副本逐字节对账,见 §3)+ `node --test` 绿 + 骨架自身九门证据(件 9)。L1 逐字节同构成立有个前提:全品类今天共享同一份 11 插件注入集(L2 全量注入),所以五件才能逐字节相等;将来若某品类要差异插件集,不是开豁免、是走规格修订把 host-config 分层(L1 核 + 品类注入段),门前提见 §3①。
|
||||
落点:目录约定如上;单工程代码红线以 littlejs-game-dev §1/§7 为 SoT,本规格不复述。
|
||||
|
||||
**件 2 · 多样性参数空间**
|
||||
定义:`core.js` 顶部以显式锚注释圈出的常量区(`_template-shop/src/core.js` 的「多样性参数空间」块是范本):主题菜单、节奏、难度、布局比例——每个常量带「改它调什么」的一句注释。这是「同品类多款不雷同」的机制载体:agent 按 brief 改这里就换了身份,循环结构不必碰。
|
||||
判定:机器查锚块存在(锚字符串「多样性参数空间」)+ 常量带注释;「参数空间够不够宽」是设计判断,归准入评审人查,不归机器。
|
||||
落点:core.js 顶部,锚注释格式入规格。
|
||||
|
||||
**件 3 · 取证契约**
|
||||
定义:`_forensicsView().state()` 暴露 `targets`(可操作目标列表,含 `occupied` 语义)与 `score`(随真实进展单调上升)。这是自动验收的驱动接口:判卷驱动器按 state 有无 `targets` 键选驱动器族,九门 H 进展门靠 `score` 判真有进展(`_template-shop/src/game-logic.js:242-245` 把键名与语义钉死并写明「改坏=H 门挂」)。README 与 game-logic 头注必须向 agent 明示这条红线。
|
||||
判定:headless-boot 测试断言 state 含 `targets`/`score` 两键;语义(occupied 可点、score 单调)由骨架自身九门证据背书。**交叉标注**:shop 现状恰是反例——其 headless-boot 断言仍读旧契约(`target` 单数 / `pendingTimers`),而 `game-logic.js` 已导出 `targets`/`currency`/`served`,断言与被测代码脱节(实测 2/3 fail,见 §8 G9),这正说明结构门只查「test/ 文件在不在」不够、质量门必须真跑 `node --test`。
|
||||
落点:game-logic.js + test/headless-boot;驱动器族登记随件 6。
|
||||
|
||||
**件 4 · 品类设计 skill** `.agents/skills/<genre>-game-design.md`
|
||||
定义:「设计什么才好玩」的品类范式——玩法范式、数值经济、文化/文本红线、反无趣自检,与 littlejs-game-dev(怎么写代码)配对。生成路真消费它:`cheap_roles.py` 按品类指路 read,这是 06-29 修正路线「先设计丰富玩法再实现」的落点。§10(或 §11)品类 rubric 节与件 5 fixture 对账(内联副本或纯指针,两形态都受 rubric-sync-gate 管)。
|
||||
判定:文件存在 + rubric-sync-gate 绿 + `cheap_roles.py` 有对应品类指路行(机器可 grep)。
|
||||
落点:既有约定不变。
|
||||
|
||||
**件 5 · 品类 rubric fixture** `cheap-worker/fixtures/genre-rubrics/<genre>.json`
|
||||
定义:喂 LLM 验证 agent 的品类丰富度评分尺,≥4 条品类特有维度,`items` 形状 `{name,layer,meaning,positive,negative}`,分母与通用底座 12 条独立小计;`_note` 记金标锚(正例/薄反例)与复验史。治理规范(单源、纯 LLM 非阻塞不进九门、金标复验纪律)全部沿用质量 SoT §4,此处不半复述其阈值口径,只登记为必备件。
|
||||
判定:fixture 存在 + rubric-sync-gate 绿 + `GENRE_BY_TEMPLATE` 有映射(件 8)。
|
||||
落点:既有约定不变。
|
||||
|
||||
**件 6 · 金标 play-spec** `cheap-worker/fixtures/golden-specs/<name>.play-spec.json`
|
||||
定义:人工手写的品类金标驱动 spec,喂达标门(bake-off)与 auto-vs-golden 门。必须登记**驱动器族**:tap-targets 族(从 `targets` 读坐标再点)一份金标可公平通吃同品类各款;key-cycle 族(硬编码按键)对独立生成款不公平,须先立输入键契约才能入对照(gen-path-parity-harness §「金标 spec 只对一部分驱动器家族公平」)。新品类选型时族成熟度直接进「生成良率」轴(§5)。
|
||||
判定:文件存在 + `_genre` 经「金标名→品类键」登记表对账(要点:`_genre` 记的是**金标名**如 `heritage-craft`/`shop-serve`/`story-branch`,不是品类键,不能直接与 `GENRE_BY_TEMPLATE` 的品类值相等比对——`cheap_verify.py:70` 只有一条注释解释 `heritage-craft→heritage` 这一例、并无金标名映射表,所以对账真源落在下方登记表,由 template-spec-gate 读它逐条比对)+ 族由 `driver.type` 承载登记;spec 内容质量由达标门真跑背书。现状七份金标(五品类 + 通用 click-score/whack-mole)`driver.type` 全为 `tap-targets`(从 `targets` 读坐标再点,对独立生成款公平),仓里尚无 `key-cycle` 族金标;规格只要求「族可查」,不强制新增独立 `family` 字段。
|
||||
落点:既有约定不变,族以 `driver.type` 承载(现状全 tap-targets;未来若引入 key-cycle 族,须先立输入键契约再入对照)。
|
||||
|
||||
**金标名 → 品类键登记表(template-spec-gate 对账真源)**:金标 spec 的 `_genre` 是金标名、`GENRE_BY_TEMPLATE` 的值是品类键、模板目录是资产名,三者需一张显式表钉住对应关系,不能靠字面相等推断;该表由本规格维护,门读它对账。
|
||||
|
||||
| 金标名(`_genre`) | 品类键 | 模板目录 | 登记状态 |
|
||||
|---|---|---|---|
|
||||
| `shop-serve` | sim-business | `_template-shop` | 在位 |
|
||||
| `story-branch` | narrative | `_template-story` | 在位 |
|
||||
| `heritage-craft` | heritage | `_template-feiyi` | 在位 |
|
||||
| `puzzle` | puzzle | `_template-puzzle` | 在位 |
|
||||
| `trpg` | trpg | `_template-trpg` | 在位 |
|
||||
| `click-score` | 通用 | `_template` | 在位(无命中回退,不绑品类键) |
|
||||
| `whack-mole` | reflex | `_template-reflex` | 随试产落(D6;现暂挂通用 `_template`) |
|
||||
|
||||
**件 7 · few-shot 正例**
|
||||
定义:该品类一款**过九门且丰富度达基线**的完整生成款,双用途,对应两条硬必备条件:(a) **评分路金标正例锚**——rubric 复验的固定参照,落 `golden-samples/<genre>/<id>/`(src+evidence 齐、天然带九门/丰富度证据);(b) **生成路参照指针**——prompt 按需 read 到「丰富成什么样」的可抄形态,由 `cheap_roles.py` 或模板 README 给一条到 canonical 正例的可追踪指路。§7 D3 已拍定统一以 golden-samples 固化形态为评分锚基准、定为**硬必备**(缺 = 不入库),`_fewshot-*` 工程作为生成路指路目标保留但退居可选。对照实测两个消费面各自的现状:生成路 `cheap_roles.py` 指路 heritage→`_fewshot-feiyi`(仅 `README`+`src` 四件、无 L1)、puzzle→`_fewshot-puzzle`(完整工程)、narrative→显式 read `game-runtime/games/_template-story/src/game-logic.js`(骨架自身的过门范例)、sim-business→**仅指 `sim-business-game-design.md` skill、无工程范例指路**、trpg→仅指 skill、无 few-shot 指路;评分路 golden-samples 固化正例只有 narrative、sim-business 两品类。按 D3 硬必备,heritage/puzzle/trpg 三品类**缺 golden-samples 固化正例**(D3 明列「随试产波顺带补齐」),逐条登记 §8。
|
||||
判定:两条并校——① 评分锚 `golden-samples/<genre>/<id>/` 存在且 evidence 内九门全绿、丰富度逐条记录;② 生成路指针在 `cheap_roles.py` 品类指路行或模板 README 可追踪到 canonical 正例。门要求两条都过:只有评分锚缺生成指针(如 sim-business 现仅指 skill)则生成 agent 抄不到范例,只有生成指针缺评分锚则 rubric 复验无正例可锚——两种都不合格。
|
||||
落点:评分锚 `cheap-worker/fixtures/golden-samples/<genre>/<id>/`(src + evidence);生成路指针落 `cheap_roles.py` 品类指路行或模板 README。
|
||||
|
||||
**件 8 · 路由登记(双表对账)**
|
||||
定义:模板要在两张表同时登记才真正通电——`cheap_genre_route._GENRE_RULES` 词表(brief→模板,含先验序位置)与 `cheap_verify.GENRE_BY_TEMPLATE`(模板→品类键,评分路透传)。任一缺席的症状都隐蔽:词表缺=该品类 brief 全落通用模板(能出活但丢品类资产加成);映射缺=生成走了品类骨架但丰富度评分退化成纯通用底座(`load_genre_checklist` 静默返 `[]`,绝不抛)。
|
||||
判定:机器对账三方一致——`games/_template-<x>` 目录、词表条目、GENRE_BY_TEMPLATE 键,互差即红。
|
||||
落点:两张表既有位置不变,对账进 template-spec-gate。
|
||||
|
||||
**件 9 · 准入证据包**
|
||||
定义:模板入库资格的固化证据,三样:(a) 骨架自身独立九门全绿的 verdict;(b) 模板路生成款 n=3–5 小批九门通过记录 + 丰富度分组小计(对金标锚);(c) 成本画像(该 n 批的均值/区间,口径 = result_out 的 costRmb)。**对照实测三样都不齐**:(a) 骨架自身九门 verdict 在所有模板目录零固化(`_template*/` 下无任何 `evidence/` 或 `verdict.json`);(b)(c) 只有 narrative(`golden-samples/narrative/p11a-s1`,n=1)与 sim-business(`golden-samples/sim-business/bake-shop-serve-1`,附 n=3 丰富度复采样 `richness-n3.json`)有单款正例证据,是「一款生成正例」而非「n=3–5 小批」,成本也是单款值(narrative ¥1.2475、sim-business ¥1.9953,与 narrative 同精度取自各自 `evidence/run-summary.json` 的 `costRmb`)不是批均值/区间。规格给这三样一个统一的家。
|
||||
判定:证据文件存在 + 字段齐,给一份机器可判的 schema 草案——每个 run:`{gameId, sourcePath, verdictPath, gates(九门逐门), richnessGroups(丰富度分组小计), costRmb, finished, staged, attempts}`;顶层聚合:`{templateId, genre, commit, briefs[], runs[], rawPassRate, convergedPassRate, unconvergedTotal}`(过门率三口径逐字对齐 §3 与 gen-path-parity-harness:convergedPassRate 分母 = 收敛款、rawPassRate 并报、unconvergedTotal 单列)。登记表(§4)据 `templateId`/`genre` 可反查此证据产物目录。数值达标与否归 §3 质量门/成本门判。
|
||||
落点:`cheap-worker/fixtures/golden-samples/<genre>/`(与件 7 合家:正例款即证据款,一处固化两用)+ 模板目录 README 尾注一行指针。
|
||||
|
||||
**件 10 · 资产规范件**
|
||||
定义:`assets/manifest.json`(`game` 字段 = 模板目录名、styleWords、外采资产逐件登记 `{file,role,bytes,sha256,source}`)+ `assets/gen-ledger.md`(mmx 生成台账,标题身份与模板一致)。程序化图形可为空表,但抬头身份必须对——这是件 1 里「资产可复现替换」纪律的登记面。
|
||||
判定:机器查 `manifest.game == 目录名`(现状 shop/feiyi 违例,§7 D5)+ 外采件登记行与 assets/ 实文件对账。
|
||||
落点:既有约定不变,身份检入 template-spec-gate。
|
||||
|
||||
## 3. 入库过门标准与 template-spec-gate
|
||||
|
||||
新模板准入走四道门,前两道机器、后两道真跑:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
N["新品类模板<br/>(按 §2 十件备齐)"] --> G1["① 结构门(机器)<br/>十件在位 · 目录同构"]
|
||||
G1 --> G2["② 一致性门(机器)<br/>L1 逐字节 · 路由双表 · rubric 对账 · manifest 身份"]
|
||||
G2 --> G3["③ 质量门(真跑)<br/>骨架独立九门全绿<br/>+ 生成款 n=3–5 全过 + 丰富度对锚"]
|
||||
G3 --> G4["④ 成本门(真跑)<br/>n 批 costRmb 均值 ≤ 锚(§7 D1)"]
|
||||
G4 --> IN["入库:golden-samples 固化证据<br/>+ 双表登记通电"]
|
||||
```
|
||||
|
||||
**① 结构门 / ② 一致性门 = template-spec-gate 机器门**,完全仿 rubric-sync-gate 的成功形态:零依赖标准库单文件 template-spec-gate.py(拟新增,落 .agents/tools/ 下,与 rubric-sync-gate 同栈同风格),`--root` 支持负向演示副本,exit 0/1,挂 pre-commit(路径触发:`game-runtime/games/_template*` / `cheap_genre_route.py` / `cheap_verify.py` / `fixtures/genre-rubrics|golden-specs|golden-samples`)+ Gitea Actions contract-gates(全量,不可绕)。检查清单:
|
||||
|
||||
1. **L1 同构**:每个 `_template-*` 的 L1 五件(`index.html`/`entry.js`/`src/host-config.js`/`src/game.js`/`src/main.js`)与权威副本(`_template` 那份)逐字节一致;不一致 = 硬失败并打印 diff 文件名。L1 要改就改权威副本再镜像到全体,单模板顺手改 = 被拦——这是舰队规范「禁止顺手升级」的机器化(治理级选择见 §7 D4)。**这条门有个架构前提**:逐字节同构能成立,是因为全品类今天共享同一份 11 插件注入集(L2 全量注入)、`host-config.js` 完全一致——这是架构推论、不是巧合。将来某品类若要差异插件集,不开豁免表:走规格修订把 host-config 分层(L1 核段 + 品类注入段),同构门相应改成「核段逐字节 + 品类注入段登记」两段判,而不是给这个模板记一笔豁免。
|
||||
2. **十件在位**:目录清单、test/ 两测试文件、README、core.js 参数空间锚串、路由双表条目、rubric fixture、金标 spec、golden-samples 证据目录——逐件存在性对账。
|
||||
3. **manifest 身份**:`manifest.game == 目录名`;外采登记行的文件真实存在。
|
||||
4. **委托复用**:rubric 内容对账直接调 rubric-sync-gate(不重复实现),它红本门即红。
|
||||
|
||||
机器门的诚实边界写进门脚本头注:**它验的是完备与一致,不验好玩**。「骨架够不够格当品类范本」「参数空间够不够宽」是 ③④ 真跑门与准入评审人的事,机器门绿 ≠ 模板合格,只是「不合格的方式不会是漏件与漂移」。
|
||||
|
||||
**门分两阶段落地,不建豁免表。** template-spec-gate 立起来时 §8 的 G1–G9 还开着(manifest 身份、headless-boot 断言、准入证据缺口),此刻若直接挂全量硬门,CI 会被这些已知违例常态染红、门反而失去意义。所以 **Phase A = audit-only**:门只输出 G 清单、逐条打印违哪件,不拦提交;等 G1–G9 按 §7 D5 与后续试产/质量门波清账后,切 **Phase B = 硬门全量**,漏件与漂移一律拦死。两阶段之间**不设豁免表**——已知违例走「限期清账」而非「登记豁免」,与 D4 拒豁免表、§3① L1 门拒插件豁免同一治理口径:豁免表是下一个腐烂点,清账才是收敛。
|
||||
|
||||
**③ 质量门(真跑,准入时一次)**:骨架自身独立过九门(兜底资格);以 3–5 个互异 brief 走真实生产路(路由命中→scaffold→生成→九门),过门率逐字对齐 gen-path-parity-harness 既有三口径判——**convergedPassRate = 100%**(分母 = 收敛款,即 `finished=true`、有 verdict 的款;准入门 n 小、要求全过)、**rawPassRate 并报**(含未收敛的原始交付率,贴近用户真实拿到能玩游戏的比例,只作观测不作判据)、**unconvergedTotal 单列**(编排未收敛款归生成稳定性线、不混进质量判定;harness 的硬底线是 `converged==0` 即判 `insufficient`、质量无从判,准入门 n 小、可容忍的未收敛条数随首批定阈值、超阈值同样标 `insufficient`);丰富度分组小计对金标锚沿用质量 SoT §4 复验纪律。n=3–5 的口径对齐创始人「小批收敛非 n≥30」偏好,≥80% 主指标的统计判定仍归 WU-F 达标门、不在准入门重复。
|
||||
|
||||
**④ 成本门(真跑,与 ③ 同批采数)**:该 n 批 `costRmb` 均值 ≤ 成本锚。锚值已随 §7 D1 拍定 = **≤¥1.0/款**;per-gen 硬闸 <¥10(tech-decisions §4)恒在,不属本门。
|
||||
|
||||
## 4. 规格落点裁决(D2 已拍定 contracts/templates/)
|
||||
|
||||
规格契约本体放哪,两个候选权衡如下;**§7 D2 已拍定候选 A**。
|
||||
|
||||
**候选 A(已拍定):`contracts/templates/`,按 contracts/README 现行类目序 additive 新增一类契约。** 编号据实:README:27 的「additive 第 9 类」已给了 `game-runtime/src/core/game-host.d.ts`,其后 play-loop、gate-fixtures 等 additive 契约也已指针登记但未再编号,所以模板契约按现行类目序顺列新增、不硬占某个号(frontmatter 的类目口径同此)。理由三条:其一,先例同构——prompts 作为「第 8 类契约」已经确立「非代码资产入 contracts + 配一致性 CI 门」的范式(`contracts/prompts/` + check_registry.py + contract-gates),模板与 prompt 同属「生成线消费的版本化资产」,治理形态完全同构;其二,模板资产横跨三地(game-runtime 骨架、cheap-worker fixtures、.agents skill),谁都不是它的自然主场,契约层是唯一中立落点;其三,template-spec-gate 挂 contract-gates CI 与 check_registry/rubric-sync-gate 同栈,巡检面统一。形态:`contracts/templates/README.md`(规格正文,§2/§3 定稿后迁入)+ 登记表(每模板一行:目录/品类键/金标 spec/正例 id/准入日期/证据指针)。
|
||||
**候选 B(未取):.agents/rules/ 下新增 template-spec 规则档。** 更轻,但 rules 是「给 agent 的工程红线」,而本规格一半是**给机器门消费的对账清单**与**给运营的资产台账**,塞 rules 里消费方错位;且 contracts 的「变更须升版过 CI」纪律正是模板这种被生产路径消费的资产需要的。
|
||||
|
||||
**执行形态修正(2026-07-06,待创始人过目):维持落点、前置三件。** §1 末尾已摆明——`contracts/templates/` 今天不是空地,被 13 份 gamedef 世代 schema 占着,还挂着 W-PCI 判定的化石 prompt 引用。落点 D2 拍定不变,但落地前必须先腾地,三件按序:
|
||||
|
||||
1. **13 份旧 schema 归档退役**(clicker/match/merge/idle/runner/dodge/tycoon/generic + 五品类 schema)——git 史可回,不做物理销毁,只从 live 目录移出;
|
||||
2. **解绑 `contracts/prompts` 的化石引用**——`registry.yaml` 的 clicker/merge/idle/tycoon 四 designer 条目对 `contracts/templates/<x>.schema.json` 的「`config 受…约束`」指向、`contracts/prompts/eval/config.{clicker,merge,idle,tycoon}-designer/` 四套 Golden 目录,与这批化石 prompt 的清账**同批**处理(它们本就是 W-PCI 段 B SKIP 豁免的死面);
|
||||
3. **新规格落腾空后的目录**——`contracts/templates/README.md` + 登记表落到清干净的 `contracts/templates/`。
|
||||
|
||||
这三件是**执行前置登记**、不在本档动手(不改任何代码/契约);拍定前规格以本档为临时单源,门脚本(随定稿阶段落地)读本档登记的约定。
|
||||
|
||||
## 5. 选型三轴框架(3–5 个 MVP 模板的选型尺)
|
||||
|
||||
三轴评分定义(完整打分是后续「选型材料」阶段的活,本节只立尺 + 给基础盘):
|
||||
|
||||
- **变现**:广告位自然嵌入度(激励视频的「复活/双倍」钩子在该品类是否原生成立)、单局时长与回访结构(限时结算类天然高频短局,利 feed 消费)、付费皮肤/道具的品类亲和。
|
||||
- **传播**:成绩炫耀钩子(分数/图鉴/结局收集的可截图性)、「做同款」冲动(参数空间宽 = 用户改一句话出自己的店/自己的谜题,UGC 亲和度)、题材社交话题性(非遗有政策与话题红利)。
|
||||
- **生成良率**:该品类九门实测过门率(已有:M1 三品类 5/5;narrative/heritage 基线在 rubric _note)、驱动器族成熟度(tap-targets 族成熟稳定;key-cycle 族有输入键契约缺口,准入成本高一档)、品类循环的取证契约友好度(targets/score 语义是否自然)。
|
||||
|
||||
**基础盘(定性,五既有品类)**:经营(变现强·传播中·良率已实证,tap-targets 原生)、解谜(传播强·良率已实证·变现中)、非遗(传播/题材红利强·变现弱·良率已有基线)、剧情(传播中·良率基线偏低——rubric _note 记骨架 3/11,富化依赖重)、TRPG(受众窄但黏性强·few-shot 缺·良率基线可)。**新品类候选(试产池,§7 D6)**:合成/消除(tap-targets 亲和、传播炫耀强)、放置挂机经营(变现与回访结构最强、循环取证契约自然)、敏捷点击(whack-mole 金标 spec 已在仓,准入成本最低)。**§7 D6 已拍定 = 敏捷点击**(定位「首跑验产线」:whack-mole 金标已在仓且属 tap-targets 族、对独立生成款公平,产线首跑风险最小;但十件里除金标外多数尚缺,试产就绪度盘点见 §8 收尾小节)。选型材料阶段对每候选给三轴打分表 + 推荐组合交创始人拍。
|
||||
|
||||
## 6. opus 对照验证工单(六要素)
|
||||
|
||||
> 本单已于 2026-07-06 执行完毕:产出 = §1 表「待对照」清零(证据行号入表)+ §8 缺口清单 G1–G8 + §1/§2 就地修订(L1 五件、`_genre` 金标名口径、件 9 现状等)。原文保留备查:
|
||||
|
||||
- **目标**:拿 `_template-shop`(及其余四品类骨架的「待对照」项)按 §2 十件逐项对照,产缺口清单回修本规格——验的是规格,不只是模板:对照中发现规格定义不可判、落点不合理、漏件的,直接改 §2 提案并标注理由。
|
||||
- **范围白名单**:只读 `game-runtime/games/_template*`、`cheap-worker/`(代码只读)、`.agents/skills/<genre>-game-design.md` 五件、fixtures 三目录;只写本设计档(§1 表「待对照」格改真 + §2 修订 + 新增缺口清单节)。不改任何代码与模板文件——发现的违例(如 manifest 身份)登记进缺口清单,修复归 §7 D5 拍定后的执行单。
|
||||
- **验收**:§1 表无「待对照」残留、每格有一手证据(文件:行);缺口清单逐条给「违哪一件规格/证据/修复归属提案」;docs-gate 绿。
|
||||
- **预算**:opus 1 会话,零真跑成本(纯读档对照;质量门真跑不在本单)。
|
||||
- **依赖**:本档(规格草案)+ 仓内资产,无外部依赖。
|
||||
- **升级策略**:发现「规格与质量 SoT/parity 口径冲突」不得自行改口径,登记冲突回 fable 终审;与 W-NSTAR 边界拿不准的(像「这算不算 tier2 模板形态」)同样上抛。
|
||||
|
||||
## 7. 裁决点(创始人 2026-07-06 全按提案拍定)
|
||||
|
||||
> D1–D6 六项均按下列提案通过;D6 取提案首选 = **敏捷点击**(定位「首跑验产线」)。提案原文照录备查:
|
||||
|
||||
- **D1 成本验收锚改真**:立项单「reskin 成本 ≤¥0.34×1.2」骑在 06-29 已废策略上(§0)。提案:准入成本门 = 模板路生成款 n=3–5 均值 **≤¥1.0/款**(现行丰富度正路实测 ~¥0.6–0.7/款 ×1.5 容忍;reskin ¥0.21–0.38 的数据留作 modify 路参考),per-gen <¥10 硬闸不变。
|
||||
- **D2 规格落点**:§4 已拍定 contracts/templates/(候选 A),按 contracts/README 现行类目序 additive 新增(编号据实——game-host.d.ts 已占第 9 类,本类顺列其后);执行前置三件(腾地 13 份 gamedef 化石 schema + 解绑 prompt/eval 引用 + 新规格落腾空目录)见 §4「执行形态修正」。
|
||||
- **D3 few-shot 必备性**:提案定为硬必备(缺=不入库),统一 golden-samples 固化形态;缺口据实在 heritage/puzzle/trpg 三品类(§8 G6–G8 逐条),随试产波顺带补齐;经营(sim-business)、剧情(narrative)已有 golden-samples 固化正例、无需迁移。
|
||||
- **D4 L1 同构治理级**:提案 = 逐字节 hash 对账硬门(L1 改动必走「改权威副本+镜像全体」的舰队工单);备选 = 允许 per-template 漂移但须登记豁免(更灵活,但豁免表就是下一个腐烂点)。
|
||||
- **D5 违例修复归属(§6 对照后首个执行单,同批不单开)**:身份三处(两行级)= shop/feiyi 两处 `manifest.json` 的 `game` 字段 + shop 一处 `gen-ledger.md` 标题(§8 G1–G3);外加 **G9 headless-boot 断言重写**——`_template-shop/test/headless-boot.test.mjs` 的 :86–167 多处断言从旧点圆得分字段(`target` 单数 / `pendingTimers`)改到现字段(`targets` / `currency` / `served`),这是多处改写、非两行级。两类同批修、不单开工单,均不在本档顺手动。
|
||||
- **D6 试产品类**:§5 新品类候选三选一(合成/消除、放置挂机、敏捷点击)。提案 = 敏捷点击(whack-mole 金标已在仓、准入成本最低,产线首跑风险最小)或合成/消除(传播价值更高、更接近爆款池)——按「首跑验产线」还是「首跑即产爆款候选」定,交创始人。拍定 = 敏捷点击(genre 键 `reflex`);逐项落点工单骨架见 §9,十件就绪度盘点见 §8「四」。
|
||||
|
||||
## 8. 缺口清单(对照实测 · 违例登记不修)
|
||||
|
||||
§6 对照把 §2 十件在六骨架上逐格核过,证据充分的违例与证据缺口列在下面。三类分开摆:身份违例是「文件抬头写错自己名字」的两行级残留,归 §7 D5 首个执行单捎带;准入证据缺口(件 9)与 few-shot 硬必备缺口(件 7)要真跑或补料才能补齐,归后续试产与质量门波,不在本对照单顺手动。规格自身「定义不可判、清单漏件」的修订已就地改进 §1/§2(L1 五件、gen-ledger 精确化、`_genre` 金标名口径、件 9 现状),此表不重复,末尾列指针。
|
||||
|
||||
**一、身份违例(件 10,归 §7 D5)**
|
||||
|
||||
| 编号 | 违哪件 | 证据(文件:行) | 修复归属 |
|
||||
|---|---|---|---|
|
||||
| G1 | 件 10 manifest 身份 | `_template-shop/assets/manifest.json:2` `game=="_template"`(应 `_template-shop`) | §7 D5 首个执行单(一行 JSON) |
|
||||
| G2 | 件 10 manifest 身份 | `_template-feiyi/assets/manifest.json:2` `game=="_template"`(应 `_template-feiyi`) | §7 D5 首个执行单(一行 JSON) |
|
||||
| G3 | 件 10 台账身份 | `_template-shop/assets/gen-ledger.md:1` 标题「_template『点圆得分』」(应经营身份;feiyi 的 gen-ledger 已自行改对为「_template-feiyi『工序节拍』」,无需动) | §7 D5 首个执行单(一处标题) |
|
||||
|
||||
这三处正是 template-spec-gate ③「manifest 身份」检要机器兜住的对象:修完门常驻,身份再错就被拦在 CI,而不是等模板带美术资产后指错工程。
|
||||
|
||||
**一之补 · 骨架自检面失效(件 1 判定,W-NSTAR O-4 交叉发现,归 §7 D5 同批)**
|
||||
|
||||
| 编号 | 违哪件 | 证据 | 修复归属 |
|
||||
|---|---|---|---|
|
||||
| G9 | 件 1 判定「`node --test` 绿」 | `_template-shop/test/headless-boot.test.mjs` 实测 2/3 fail——断言仍读点圆得分旧款字段(`pendingTimers`/`target`),而现 `game-logic.js` 导出 `targets`/`currency`/`served`(W-NSTAR O-4 填肉 2026-07-06 实测;`core.test.mjs` 8/8 绿,失效仅冒烟壳断言漂移,宿主机制不受影响) | §7 D5 首个执行单同批(断言更新到现字段)。这条同时是「结构门只查 test/ 文件存在不够,质量门必须真跑 `node --test`」的直接实证——§3 ①③ 分工按此站住 |
|
||||
|
||||
**二、准入证据缺口(件 9,归质量门真跑波)**
|
||||
|
||||
| 编号 | 违哪件 | 证据 | 修复归属 |
|
||||
|---|---|---|---|
|
||||
| G4 | 件 9(a) 骨架自身九门 verdict | 六骨架 `_template*/` 下无任何 `evidence/` 或 `verdict.json`(对照 find 全空)——兜底件「独立可玩」的资格证据零固化 | §3 质量门真跑(骨架跑九门→固化 verdict),非两行级修 |
|
||||
| G5 | 件 9(b)(c) n=3–5 小批 + 成本画像 | golden-samples 只 narrative(n=1)、sim-business(n=1+丰富度 n=3);均为单款正例非小批,成本是单款值(¥1.2475 / ¥1.9953)非批均值/区间;其余四类(含通用 `_template`)无准入证据 | §3 质量门/成本门真跑波 |
|
||||
|
||||
**三、few-shot 硬必备缺口(件 7,§7 D3 拍定硬必备后触发,归试产波)**
|
||||
|
||||
| 编号 | 违哪件 | 证据 | 修复归属 |
|
||||
|---|---|---|---|
|
||||
| G6 | 件 7 heritage golden-samples 正例 | `golden-samples/` 无 `heritage/`;生成路仅指 `_fewshot-feiyi`(README+src 四件、缺 L1,非完整工程) | D3「随试产波顺带补齐」 |
|
||||
| G7 | 件 7 puzzle golden-samples 正例 | `golden-samples/` 无 `puzzle/`;`_fewshot-puzzle` 是完整工程但非 golden-samples 统一形态(可提级固化) | D3 试产波(`_fewshot-puzzle` 提级) |
|
||||
| G8 | 件 7 trpg few-shot(两头皆无) | `cheap_roles.py` 无 trpg few-shot 指路(仅指 skill)、`golden-samples/` 无 `trpg/`——五品类里 few-shot 最空 | D3 试产波,五品类中最紧 |
|
||||
|
||||
**三之补 · rubric 金标薄反例锚欠账(件 5,归质量 SoT/W-GENRE 线)**
|
||||
|
||||
| 编号 | 违哪件 | 证据 | 修复归属 |
|
||||
|---|---|---|---|
|
||||
| G10 | 件 5 rubric 金标薄反例锚 | puzzle/trpg 两品类的品类薄反例只在 `genre-rubrics/{puzzle,trpg}.json` 的 `_note` 里口头自述——puzzle 记「按各条 negative 面同构的合成薄壳(单规则纯反应/目标自发光/无进度/无提示)」、trpg 记「合成黑箱点卡(直接加钱、无骰无取舍无成长无终点)」,并无入仓的反例工程款可复跑对账 | 质量 SoT §4 / W-GENRE 线的金标锚补料,**非本档修**;template-spec-gate 只校 rubric-sync-gate 绿、不校薄反例是否入仓 |
|
||||
|
||||
这条与身份、few-shot 缺口分属两条线:它归评分尺治理,本规格登记备查、不承接修复。
|
||||
|
||||
**口径确认(无需回 fable)**:件 6「驱动器族」现状由 `driver.type` 承载,七金标全 `tap-targets`、对独立生成款公平,与 gen-path-parity-harness「金标只对一部分驱动器族公平」的口径不冲突——冲突面在 `key-cycle` 族,而仓里尚无此族金标;规格只澄清现状、未改 parity 的族定义,故不回 fable。rubric fixture 形态有一处参差(`heritage.json` 带 `groupMaxes`/`anchors`,余四份无),属质量 SoT §4 治理面,rubric-sync-gate 绿即视为治理接受,本规格不重定义、不登记为缺口。
|
||||
|
||||
**四、敏捷点击(genre 键 `reflex`)试产十件就绪度(§7 D6 收尾盘点)**
|
||||
|
||||
D6 拍定敏捷点击「首跑验产线」,genre 键裁定为 `reflex`(短键、与其余品类键风格一致)。它现状没有独立品类骨架——whack-mole 金标的 `_baseSample=base2` 是通用 `_template` 点圆得分类的生成款,不是敏捷点击的品类资产。按 §2 十件盘,试产前的缺口一目了然:
|
||||
|
||||
| 件 | 现状 | 说明 |
|
||||
|---|---|---|
|
||||
| 1 骨架工程 | ✗ | 无 `_template-reflex` 独立骨架,需新建 |
|
||||
| 2 参数空间锚块 | ✗ | 随骨架 |
|
||||
| 3 取证契约 | ◐ 可继承 | 通用 `_template` 已有 targets/occupied/score;whack-mole 金标只依赖此契约(base2 已验证),新骨架照搬 |
|
||||
| 4 品类设计 skill | ✗ | 无 `reflex-game-design.md` |
|
||||
| 5 品类 rubric fixture | ✗ | 无 `genre-rubrics/reflex.json`;反应类是天然薄品类,rubric 须先过质量 SoT §7 替代丰富轴(连击深度/模式变体等)申报 + 创始人批,再落评分尺 |
|
||||
| 6 金标 play-spec | ✅ | `whack-mole.play-spec.json` 在仓(tap-targets 族、不绑坐标、`expectLatch`、`score increased` 断言齐);whack-mole→reflex 映射登记随试产落(件 6 登记表) |
|
||||
| 7 few-shot 正例 | ✗ | 无 golden-samples 固化(base2 是点圆得分款、非敏捷正例) |
|
||||
| 8 路由登记 | ✗ | `cheap_genre_route` 无敏捷词条、`GENRE_BY_TEMPLATE` 无映射,「打地鼠」类 brief 现落通用 `_template` |
|
||||
| 9 准入证据包 | ✗ | 无 |
|
||||
| 10 资产规范件 | ✗ | 随骨架 |
|
||||
|
||||
十件里在位一件(金标)、可继承一件(取证契约)、缺八件。这恰印证 D6「首跑验产线」的定位:敏捷点击要验的是「从零起一个新品类模板依次走通骨架→skill→rubric→路由→few-shot→双真跑门这条完整工序」,而非摘现成——它便宜只便宜在金标已备且属最公平的 tap-targets 族,达标门与 auto-vs-golden 的考卷不用现造。产线把这一条走通,§3 四道门与 template-spec-gate 才算被一份真实的新资产验证过一遍。
|
||||
|
||||
## 9. D6 试产工单骨架(reflex 逐项落点)
|
||||
|
||||
D6 拍定敏捷点击、genre 键 `reflex`。这一节把「从零起 reflex 模板」的工序拆成逐项精确落点,当试产执行单的骨架——它是**工单登记**,不在本档动手建任何文件。§8「四」已盘出十件缺八、在位一(金标)、可继承一(取证契约);落点按依赖序排,**一条硬前置横在质量门之前**。
|
||||
|
||||
**硬前置(先于一切真跑):rubric 替代丰富轴申报。** 反应类是质量 SoT §7 点名的「天然薄品类」——单机制、循环短,四件底线(成长轴 / 解锁阶梯 ≥3 级 / 第二动机 / 音反馈)里有几件对纯反应循环并不自然。按 §7 其二的申报机制,`reflex` 的 rubric 必须先给出替代丰富轴(连击深度、模式变体、速度档位递增等,对应 §7 明举的「连击深度、模式变体」)、附理由申报创始人批,才能落评分尺;跳过这步直接建 rubric,金标复验会拿一把不合身的尺子量薄品类,把「品类本就该薄」误判成「做得不够丰富」。所以工序上**申报在前、rubric fixture 在后、质量门更在后**。
|
||||
|
||||
逐项落点(依赖序):
|
||||
|
||||
1. **骨架工程** → `game-runtime/games/_template-reflex/`(L1 五件从权威副本 `_template` 逐字节镜像 + L3 四件写反应循环 + `test/` + `README.md`);取证契约照搬通用 `_template` 的 `targets`/`occupied`/`score`,whack-mole 金标只依赖这一契约,新骨架不必另立。
|
||||
2. **品类设计 skill** → `reflex-game-design.md`(落 `.agents/skills/`;反应类「设计什么才好玩」的范式 + §10 品类自检,替代丰富轴段与 rubric 同源、受 rubric-sync-gate 管)。
|
||||
3. **品类 rubric fixture** → `cheap-worker/fixtures/genre-rubrics/reflex.json`(≥4 条品类特有维度,`_note` 记金标锚与替代轴申报批文);**受上面的硬前置约束**。
|
||||
4. **路由登记(双表)** → `cheap_genre_route._GENRE_RULES` 加一条 `("reflex", "_template-reflex", (关键词元组))`(先验序位置随品类词共现面定)+ `cheap_verify.GENRE_BY_TEMPLATE` 加 `"_template-reflex": "reflex"`;两表登记后「打地鼠 / 反应 / 敏捷」类 brief 才从通用 `_template` 转投 reflex 骨架。
|
||||
5. **金标 play-spec** → 沿用在仓的 `whack-mole.play-spec.json`,经件 6 登记表把 `whack-mole → reflex` 落一行(现暂挂通用 `_template`,试产时改挂 reflex);金标不必新造,这正是 reflex 作为「首跑验产线」准入成本最低的原因。
|
||||
6. **few-shot 正例 + 准入证据包** → `cheap-worker/fixtures/golden-samples/reflex/<id>/`(src + evidence:骨架自身九门 verdict + 模板路 n=3–5 小批过门记录 + 丰富度分组小计 + 成本画像)+ `cheap_roles.py` 加一条 reflex 品类指路行、`_template-reflex/README.md` 尾注证据指针(件 7 的两条件——评分锚与生成指针都要落)。
|
||||
7. **资产规范件** → `_template-reflex/assets/manifest.json`(`game == "_template-reflex"`)+ `assets/gen-ledger.md`,身份自建时就写对,别重蹈 shop/feiyi 的拷贝残留(G1–G3)。
|
||||
|
||||
走完这七步,§3 的四道门(结构 / 一致性 / 质量 / 成本)与 template-spec-gate 才第一次被一份真实新资产端到端验过——这正是「首跑验产线」区别于「摘现成爆款」的地方:reflex 的价值不在它自己多能传播,在它逼产线把「新品类从零到入库」的完整工序真跑一遍。
|
||||
|
||||
预算与升级策略(补齐工单六要素):预算 = opus 1–2 会话 + 真跑成本约 n=3–5 × D1 锚(≤¥1.0/款)+ 骨架自身九门一局;升级 = 替代丰富轴申报被否 → 品类回 D6 备选(合成/消除)重议,质量门 `insufficient`(未收敛超阈)→ 归生成稳定性线排查、不降判据,与 W-TPL/质量 SoT 口径冲突 → 回 fable 终审。
|
||||
@ -7,6 +7,10 @@
|
||||
|
||||
| 设计 | 主题 | 状态 |
|
||||
|---|---|---|
|
||||
| [2026-07-06-复杂游戏北极星件-设计](2026-07-06-复杂游戏北极星件-设计.md) | W-NSTAR 北极星件骨架(fable 主笔):标的《夜市一条街》+3 走查场景、v1 立 6 席缓 3、九工件 schema(判定书并 C6)、版本语义踩 W-ASSET-SRC、L1–L4 切片阶梯 | **终审稿 ✅ 待创始人拍**(2026-07-06 全链:八单回填→合并→双评审 N1–N14 修入→fable 终审——台账 10 条全裁定、场景 C 补 schema 回写为通、15 裁定签认;965 行七检绿;O-6 挂起随 W-ASSET-SRC) |
|
||||
| [2026-07-06-黄金模板规格件-设计](2026-07-06-黄金模板规格件-设计.md) | W-TPL 模板的模板(fable 逆向):十件规格+四道准入门(template-spec-gate 仿 rubric-sync-gate)+选型三轴;立项前提修正(reskin 已废→丰富度正路品类起点资产) | **定稿 ✅ 待创始人批终稿**(2026-07-06 全链:对照+双评审 16 条修入+fable 定稿轻读;311 行双门绿;D2 执行形态修正一并过目=维持落点+前置清 gamedef 化石;reflex 试产工单可直接派,档 §9) |
|
||||
| [2026-07-06-生成侧过程蒸馏回路-设计](2026-07-06-生成侧过程蒸馏回路-设计.md) | W-GENLOG 过程校准单(fable 骨架):校准单换锚的二次实例化——生成过程日志挖高频问题/错误/弯路,出口按注入铁律四级(模板>门/工具>skill>prompt),首单用现存批零采集 | 骨架 ✅(2026-07-06)· 待 opus 填肉(档 §6 五单)→ 双评审 → 创始人批;首单执行时机待拍(档 §7⑤) |
|
||||
| [2026-07-05-游戏资产管理范围决策-设计](2026-07-05-游戏资产管理范围决策-设计.md) | W-ASSET 游戏资产管理范围决策:已拆成源工程长期存储、私有素材库真验、资产市场只读半、资产市场流通半 | ✅ 已批准(2026-07-05):先做 SRC + MAT-VERIFY,并允许 MARKET-READONLY 在支付前先上;下一步切执行计划 |
|
||||
| [2026-07-04-SpaceHuggers对照靶-95自主复刻-设计](2026-07-04-SpaceHuggers对照靶-95自主复刻-设计.md) | Space Huggers 作为能力对照靶:原创横版动作射击,机制覆盖度 ≥95% + agentic 自主贡献率 ≥95%,过程补横版动作射击能力包与横屏 feed 承载 | review 草案 · 待创始人确认 95% 口径、多人/手柄范围与 LittleJS 承重墙 |
|
||||
| [2026-07-02-配置控制面阶段二-yudao配置中心-设计](2026-07-02-配置控制面阶段二-yudao配置中心-设计.md) | 配置控制面唯一在飞面:阶段二 yudao 配置中心(版本源 = yudao MySQL 版本行,prompt MEDIUMTEXT 出 Nacos,Nacos 承路 B 小参下发;总设计=[2026-06-30 档](2026-06-30-配置控制面一次性按序实现-设计.md),其阶段〇+一①+一② ✅ 已落地、一② SDD 收口 `526e9b3d`) | ✅ 已拍方向 B · 双评审 11 条全修收口(2026-07-02);**已排期(实施工单=档 §8,2026-07-04)· 即刻可派** |
|
||||
| [2026-07-02-M4广告SDK预接线-设计](2026-07-02-M4广告SDK预接线-设计.md) | M4 广告预接线:三层开关 / 回调验签 fail-closed / 不估算入账(联盟账单为唯一入账源) | 双评审回炉已修(r3-ad-hardening 已 merge 入 dev/2.0.0,`00ebeedc`);剩 SVG 门面图 |
|
||||
|
||||
@ -236,6 +236,10 @@ token 还承担一个长期使命:**做跨端的单一事实源**(single source
|
||||
|
||||
**feed 容器调度的前端责任。** 信息流的核心手势(上滑切下一款)、三容器预加载策略(销毁当前 + 激活预加载好的下一个、N±1 只预取字节不实例化)、以及 manifest 随 feed 清单下发省一次往返,这套运行时调度的"how"归架构域生成引擎子树。但**前端 feed 列表如何维护这三态容器、何时按滚动方向触发上/下预取、切换动画怎么做**,是前端实现问题。这里只钉归属:feed 的滑动手势承载与容器生命周期调度归前端域,装载与渲染的底层机制见架构域,别让它悬空成"两边都以为对方在管"。
|
||||
|
||||
**feed 方向与游戏方向的定义。** "竖屏 feed"定义的是**手机竖握场景下的垂直信息流容器**:玩家以上滑手势切换游戏,前端用三容器预加载承载连续消费体验。它不是"所有游戏画布必须竖屏"的内容约束。游戏本身可以是竖屏、横屏或自适应方向;前端不能把横屏游戏强行挤进竖屏画布,也不能为了维持卡片比例拉伸玩法画面。横屏游戏进入 feed 时,竖屏卡片只负责保留正确宽高比的预览、封面或 letterbox 画面,并给出旋转/进入横屏沉浸播放的清晰入口;真正游玩可以切到沉浸式 play 容器,由宿主按游戏声明的方向、宽高比和控制方案装载。桌面端只是响应式放大的兼容形态,不是 feed 的优先目标。
|
||||
|
||||
这条定义也给入 feed 的放行口径划边界:横屏游戏可以入 feed,但要和竖屏游戏一样过首屏、点开可玩、触控输入和错误观测等移动端验收门;控制方案不能只依赖键盘/手柄,必须有手机触控路径。`orientation / aspectRatio / controlScheme / feedPresentation` 这类字段属于后续 contract-first 待落的 manifest 契约,当前前端域先钉产品与承载口径,具体 schema、装载分支和验收探针仍按架构域生成运行时 SoT 推进。
|
||||
|
||||
**前端可观测性的承载。** 页面在真实用户浏览器里加载多慢、报了什么 JS 错、首屏耗时实测对齐 P75 < 3s——这种前端可观测性,和现有那条"业务遥测(性能/游玩/会话)落 `game_telemetry_event`"的业务数据回路是两回事。它的承载方案是运维域观测体系里那条 **OTel Web SDK**(给 `game-studio` / `game-admin` 接入,采页面性能 / JS 错误 / 前端 trace),权威定义见 [`../运维/观测体系.md`](../运维/观测体系.md)。现状标的是"可选、后期",前端域只引这一句、认下这个承载点:**前端的页面级性能与错误观测走 OTel Web SDK,不在前端另造一套采集。**
|
||||
|
||||
### 9.2 admin(game-admin)第一期承载:审核台四页 + 权限双层
|
||||
@ -285,7 +289,7 @@ C 端这一摊,后端大多已是现行真相,缺的是前端这层面子,逐条
|
||||
|
||||
> contract-first(待落地):Debug 插件要进 SDK 插件库,涉及 SDK 契约(`contracts/sdk/`)新增一个 `debug` 插件声明 + GameConfig 里按需声明该插件的开关(仅开发模式加载),宿主据 manifest 决定是否注入该插件 chunk。当前 SDK 契约只声明了 Ad / Pay / Social / Storage 四插件,Debug 标"待落地"。
|
||||
|
||||
**移动端基本适配集。** 现行前端档把响应式大方向定了(移动沉浸/桌面居中放大),但移动端的几条具体适配约束是空白,捡回补成一个"移动端基本适配集",归前端域:① **安全区适配**——竖屏沉浸式 feed 在真机上必然遇到刘海、底部手势条,要用 `safe-area-inset` 留出安全区;② **软键盘处理**——创作页的一句话输入框、评论输入框在移动端软键盘弹起时会顶布局,要做遮挡处理;③ **横屏游戏在竖屏 feed 的呈现**——生成的游戏可能是横屏体验,塞进竖屏卡片时要给旋转提示或自适应方案,而不是直接挤变形;④ **触觉反馈**——游戏关键节点、互动反馈用 `navigator.vibrate` 做轻量震动,提体感。这四条都是消费级移动 Web 的基本盘,作为一个适配集一并补,file 级细节留实现。
|
||||
**移动端基本适配集。** 现行前端档把响应式大方向定了(移动沉浸/桌面居中放大),但移动端的几条具体适配约束是空白,捡回补成一个"移动端基本适配集",归前端域:① **安全区适配**——竖屏沉浸式 feed 在真机上必然遇到刘海、底部手势条,要用 `safe-area-inset` 留出安全区;② **软键盘处理**——创作页的一句话输入框、评论输入框在移动端软键盘弹起时会顶布局,要做遮挡处理;③ **横屏游戏在竖屏 feed 的呈现**——按 §9.1 的方向定义处理:竖屏 feed 是容器方向,不是游戏画布限制;横屏游戏要保留正确宽高比,给旋转提示、letterbox 预览或进入横屏沉浸 play 的入口,不能直接挤变形;④ **触觉反馈**——游戏关键节点、互动反馈用 `navigator.vibrate` 做轻量震动,提体感。这四条都是消费级移动 Web 的基本盘,作为一个适配集一并补,file 级细节留实现。
|
||||
|
||||
### 9.7 B 端 demo 取包:owner-agnostic 取包端点(卡 B 端现金线)
|
||||
|
||||
|
||||
@ -330,7 +330,7 @@ flowchart TB
|
||||
|
||||
3. **派生深度上限定多少、超限怎么处理?** 本稿建议 depth 上限 10、`depth=min(真实链深,10)`(超限只把 depth 数字截在 10,parent 仍记真实父、origin 仍锚根,不改父子与根的真实指向)。需要确认的是这个上限值、以及"超限后是拒绝同款还是允许但 depth 不再加深"——拒绝更干净但会卡住合理的深层创作,允许但截顶更宽容但 depth 这个数字会失真(虽不影响 parent/origin 的真实性)。
|
||||
|
||||
4. **资产市场的"只读半"在支付接通前能不能先上?** 跨创作者素材货架浏览、自有授权范围内选用(免费)这一半不依赖支付,可以先于支付落地、先把资产沉淀和复用习惯养起来。但这要确认产品上是否接受"能浏览能选用、暂不能买卖"的中间态,还是要等支付齐了一次性推出完整市场。
|
||||
4. **资产市场的"只读半"在支付接通前可以先上(创始人 2026-07-05 已定)。** 跨创作者素材货架浏览、自有授权范围内选用(免费)这一半不依赖支付,先于支付落地,先把资产沉淀和复用习惯养起来。边界也同时拍死:这个中间态只能做"能浏览、能选用、暂不能买卖",不接购买、授权支付和分成;流通半等真实支付收单、trade source=ASSET、采购/授权单和法务口径齐后再启动。
|
||||
|
||||
5. **收益回流语料的归属与使用授权。** 把创作者的生成数据、玩家的留存数据用作训练语料,需要在用户协议层面拿到授权(尤其未来用于自训小模型)。这条是产品/法务口径,工程上随 trace 脱敏规则走,但"能不能用、怎么告知用户"要创始人和律所定。
|
||||
|
||||
|
||||
@ -34,7 +34,15 @@ canonical: true
|
||||
- **决策5「按推荐」**:BUDGET_RMB 效率维 0.15→¥0.6 已落码(`ReadinessScorer`,待外置+下次 jar);**新工单 W-CFG-EXT · D11 就绪评分参数外置进配置中心**(BUDGET_RMB+四维权重现为 `ReadinessScorer` 硬编码 Java 常量,改要动码换 jar=正是配置中心该消灭的反模式;外置后界面改即生效)。
|
||||
- **决策6「进配置集」**:**新工单 W-CFG-KB · 知识件纳入配置集**(rubric fixture/skill/few-shot 金标建模为配置对象+rubric-sync-gate 改单向下发+生效通路另定;设计增量,阶段二档 §7 已记)。
|
||||
- **阶段四观测 reframe(创始人 2026-07-04:要全链路 OTel/Prometheus/Grafana 体系、非只 AgentScope)**:现状=**无全栈观测**——生成线有 OTLP→AgentScope Studio(trace.py/studio_sink.py)、telemetry MQ 聚合(R1)、yudao 原生 ApiAccessLog/ErrorLog、Sentinel 台;**但 game-cloud 微服务未接 Prometheus(monitor starter 在 BOM 未 wire)、无 Grafana、无跨服务分布式追踪、无部署的观测后端(deploy/infra 仅 nacos+rocketmq)**。阶段四须重定义为**平台级全链路观测**(部署 Prometheus+Grafana+OTel Collector/SkyWalking + game-cloud 接 micrometer/actuator + Python worker OTLP 汇同一 collector + 统一看板),先出设计再落=fable 列单。
|
||||
- **W-ASSET · 游戏资产管理(创始人 scope QA 揪出缺位)**:两块 partial——① 生成源工程存储(`store.py` BackendStore=MySQL manifest+MinIO 占位 NotImplementedError,现仅 LocalFsStore;=长生命周期源项目线)② 创作者素材库/资产市场(`game_material` 私有库 sprite/character/music 六类,缺货架+授权+分成=数据飞轮资产层)。**待创始人明确指哪一块(或都要)再排 scope**;先做四项、此单其后。**顺带揪出既存测试债两条(非本线引入,主仓可复现)**:①`AigcControlPlaneTest` 6 err(genTaskProducerProvider null);②`GameConfigSchemaValidatorTest` 的 fixture 源目录(gamedef 时代 spike 档)已删,干净构建必红、现靠 target/ 陈旧产物假绿——**✅ 2026-07-04 已修(`167cedde`,四项之首、主树直修)**:①补 `genTaskProducerProvider` @Mock(字段名同源按名消歧)+setUp 桩 `getIfAvailable()`→null(走生产 producer 缺席软兜底);②从 git 史 `6d2f8789^` 捞回 6 条 accepted clicker 夹具落一等 test 资源 `src/test/resources/wanxiang-test-fixtures/`+删已破 pom `copy-wanxiang-test-fixtures` 执行段。干净 `mvn clean test` 两类 27/0/0、整 aigc-server 模块 363/0/0 Skipped 7 零回归。随排期待你拍(非阻塞,裁前按现范围实施):知识件入不入配置集 = 档 §7 末,已挂人办清单决策6;follow-up(真门窗口验证等)见 plan 尾注。
|
||||
- **W-ASSET · 游戏资产管理(2026-07-05 已拍板拆线)**:决策稿 = [`游戏资产管理范围决策`](../agent-specs/2026-07-05-游戏资产管理范围决策-设计.md)。创始人已确认三项:①同意拆线;②同意先做“源工程长期存储 + 私有素材库真验”;③同意支付接通前先做资产市场只读半。执行拆四段: **W-ASSET-SRC** 源工程长期存储 / 版本寻址 / 取回重建(优先,支撑 A11 与 tier2 第二装载); **W-ASSET-MAT-VERIFY** 私有素材库 staging 真验(上传→登记→浏览→选用→`assetContext` 进入生成上下文); **W-ASSET-MARKET-READONLY** 支付前资产市场只读半(公开货架 + 免费/自有授权选用 + assetRefs 归因,需补 P-MAT 可见范围/授权类型/版权声明); **W-ASSET-MARKET-TRADE** 购买/授权/分成(后置,等真实支付收单 + trade source=ASSET + 法务口径)。既存测试债两条已于 2026-07-04 修复(`167cedde`):`AigcControlPlaneTest` producer mock + `GameConfigSchemaValidatorTest` fixture 自包含化,干净 `mvn clean test` 两类 27/0/0、整 aigc-server 363/0/0 Skipped 7。下一步:分别切 SRC、MAT-VERIFY、MARKET-READONLY 执行计划。
|
||||
|
||||
**★2026-07-05 创始人拍(agentic 需求基线三落位)**:需求基线 = [`agentic-seat-context-design.md`](../../.agents/skills/agentic-seat-context-design.md)(八轮第一人称探索蒸馏;盲评"小修"8 条已修入);**检查单强制化已落** [`ai-development-protocol.md`](../../.agents/workflows/ai-development-protocol.md) §2.3(agentic 设计/评审必按 §8 过尺)。B 类三条落位:① 修复轮注入面 → 新单 W-REPAIR-CTX(下);② context 装配进 trace → 已落 [`阶段四后续波 plan`](../plans/2026-07-05-阶段四观测后续波实施-plan.md) 波⑤ **T5-8**;③ assetContext 前置 = 资产决策稿 §4.3/§5/待拍第 4 条已登记,独立复核坐实(dispatchGeneric 的 job payload 无 assetContext 键、Python 侧零消费、AigcTaskDO 字段 transient),无须新增登记。
|
||||
- [ ] **W-NSTAR · 复杂游戏北极星件(肥鹅美食街级)立项**(创始人 2026-07-05 拍;**2026-07-06 升档定义:fable 主笔骨架 + opus 填肉 + fable 终审,优先级与 W-TPL 同级**)→ 目标 = 以一款高复杂 2D 经营游戏(web + 微信/抖音小游戏)为**真实负载**,产 feature-design 设计档五件:ⓐ 标的游戏规格(玩法循环/数值体系/资产量级/多版本交付 3 走查场景,当全部架构决策的测试用例)ⓑ 席位架构裁决(〔提案〕席立/合并/缓 + 每席 prompt/context/工具面/harness 四层配方 + 认领 skill §2 胚胎对照表)ⓒ 九类工件 schema 字段级 + 示例实例 ⓓ 版本语义(版本卡/基线资格戳/兼容检查器/意图重放)落 AgentScope 2.0.2 + 配置控制面现实接口 ⓔ 倒排切片阶梯(最小切片→北极星,每级带验收门,标注 16 周主线复用接缝);过程 = fable 骨架(1 会话:章命题+裁决点+席位初裁+schema 草案+给 opus 的填充工单)→ opus 填肉(2–3 会话按章并行,每个「现状」论断读源码/契约坐实)→ protocol §2.3 检查单过尺留痕 + Codex+Opus 双评审 + fable 终审(收口裁决:席位数/schema 冻结面/切片阶梯/主线接缝)→ 创始人拍;需求基线 = agentic-seat-context-design(§8 过尺,〔提案〕逐条留「采/改/弃+理由」——基线是输入不是结论);边界 = 设计先行不含实现(schema 冻结在文档+示例 JSON,代码物随实现波次)、不挤占 16 周主线窗口、标的只 1 款经营品类(多品类归 W-TPL/W-GENRE)、既有 canonical(质量 SoT/回流环/运行时图说)只引用不重写、切片阶梯进主线仍过波次排期;验收 = 双评审 + SoT 注册表查册与 `sot-impact` 申报 + 创始人批,**硬判据** = 标的 3 场景(追加新功能/从已发布版回退分叉/第 N 千次修改)走查文档,每场景能直接推出「哪个席位、消费/产出什么工件、人在哪确认」;升级 = 与主线争资源回创始人;预算 = fable 2 会话 + opus 2–3 会话,零运行时成本;**阶段A fable 骨架 ✅ 2026-07-06 落档** = [`复杂游戏北极星件-设计`](../agent-specs/2026-07-06-复杂游戏北极星件-设计.md)(承重裁决:v1 立 6 席缓 3〔数值仿真先工具后席/馆长机器门代位/玩家真实遥测优先〕/判定书并 C6 不另起/统一信封三戳/版本语义踩 W-ASSET-SRC 只做语义层/L1 工件化先于席位、L2 硬依赖 W-ASSET-SRC 首段;骨架裁决点 6 条 ✅ 创始人 2026-07-06 全拍 + **O-4 填肉两裁决点 ✅ 同日拍**(①空间摆放类系统纳入快进仿真——L3/L4 硬约束「空间吞吐逻辑走 `update(dt)` 纯逻辑层不耦渲染」;②driver 档位 = L3 单档最优跑通闭环、L4 增强多档包络,L3 期下沿体验风险如实标注未覆盖)+ 需求基线〔提案〕十条采/改/弃总表见档 §7;**9 张 opus 填充工单**见档 §6:**八单回填 ✅ + 合并 ✅ 2026-07-06**(填肉稿 908 行,O-6 挂起等 W-ASSET-SRC;20 处〔fable 合并期裁定〕入档;**三场景走查 = A 通/B 通带硬前置/C 断**——决策史对撞无 schema 地基,连同 10 条走查缺口台账留 fable 终审);Codex+Opus 双评审 ✅ 同日(Codex REVISE 9 + Opus ACCEPT-WITH-FIXES 10,合并去重 N1–N14 全修入:信封 actorKind 化/L1 瘦证据包/confirmFloorRule 结构化/版本语义拆契约与存档两轴/15 件算式订正等)→ **fable 终审 ✅ 2026-07-06**:台账 10 条全裁定(8 闭合/⑧存量玩家迁移归 O-6+L2 实装/⑩随 N3),**场景 C 补 schema 回写为通**(decisions[] 落判定书+升级事件、账本决策索引、WorkOrder.decisionRefs 铸单机械注入一道网 + decisionHistoryHit 执行期二道网——对撞=确定性检索归 harness、判断留席位),15 处合并期裁定全签认,诊断答复裁 trace 留痕不工件化,VersionCard 增 lineId 而 live 刻意不上卡——**终审稿 965 行、七检绿,待创始人拍**)。
|
||||
- [ ] **W-TPL · 黄金模板体系:模板规格件+产线+选型**(创始人 2026-07-06 拍立项,**优先级与 W-NSTAR 同级**;注入铁律「模板承载>门强制>prompt 提醒」的执行臂,直接锚 MVP 主指标「≥80% 成功率基于 3–5 模板」;**第一步规格草案 ✅ 2026-07-06 落档** = [`黄金模板规格件-设计`](../agent-specs/2026-07-06-黄金模板规格件-设计.md),**并修正一处立项前提**——原单「reskin 产线/成本 ≤¥0.34×1.2」骑在 2026-06-29 已废策略上:创始人当日已推翻 reskin 作成本主线(便宜=低参与非低质量),修正路线=品类骨架轻起点+设计 skill+丰富度评分且 M1 已达标,锁写 write_whitelist 现活在 modify 路、create 路不收窄(证据=06-29 设计档 🔴 节 + `cheap_service_driver.py:54` + `cheap_modify.py:419`,本会话亲验)→ 模板定位改「**丰富度正路的品类起点资产**」)→ 产出三件:ⓐ **模板规格契约**(「模板的模板」十件:骨架工程/参数空间锚块/取证契约/品类 skill/rubric fixture/金标 play-spec/few-shot 正例/路由双表登记/准入证据包/资产规范件)ⓑ **入库过门标准+机器门**(四道门:结构/一致性=template-spec-gate 仿 rubric-sync-gate 挂 pre-commit+CI,质量/成本=真跑 n=3–5)ⓒ **3–5 个 MVP 模板选型材料**(变现×传播×生成良率三轴,交创始人拍);过程 = ✅ fable 逆向规格草案 → opus 对照验证 ✅ 2026-07-06(§1 清零+缺口 G1–G9)→ **双评审 ✅ 同日修入**(Codex REVISE 8 + Opus ACCEPT-WITH-FIXES 8,合并去重 16 条全修、双门绿、307 行;品类键裁定 **reflex**、新增 §9 试产工单骨架、G10 rubric 锚欠账、金标名→品类键登记表、质量门三口径对齐 parity、门两阶段落地;**D2 执行形态修正待创始人过目** = 维持落点 contracts/templates/ + 前置三件清 gamedef 化石〔13 schema 归档+解绑 registry/eval 四 designer 引用+编号按现行类目序〕)→ fable 定稿轻读 ✅ 同日(五处状态改真 + §9 补预算/升级两要素,311 行双门绿)→ **待创始人批终稿** → **试产 1 个新品类模板全程走产线**(不许手工特调,D6 已拍=敏捷点击,落点清单=档 §9)→ 选型拍板后批产工单化(每模板一单,opus 领,不再占 fable);边界 = 只覆盖便宜档模板产线(tier2 模板形态归 W-NSTAR 裁决)、不重构 cheap-worker 生成路(机制缺口出工单不顺手改)、金标/rubric 定义权在质量 SoT 与 parity 口径(规格只规定「必须带」)、选型是创始人决策本单只出材料、不做模板平台化产品功能(创作者上架模板=远期件)、不承诺软脚手架降本(实证已证伪);与 W-GENRE 关系 = 品类件(设计手册+rubric)是产线输入,W-GENRE 批产独立推进;验收 = 规格契约落库 + 机器门真拦(负向演示)+ 试产模板经产线独立过九门(n=3–5 小批)且成本达 D1 锚 + 选型材料交付拍板;**D1–D6 ✅ 创始人 2026-07-06 全按提案拍**(D1 成本锚 = n=3–5 均值 ≤¥1.0/款 / D2 落点 = contracts/templates/ 第 9 类契约 / D3 few-shot 硬必备+统一 golden-samples 形态 / D4 L1 逐字节 hash 硬门 / D5 manifest 修复随对照后首个执行单捎带 / D6 试产 = 敏捷点击);预算 = fable ~2 会话 + opus 2–3 会话 + 真跑 n×成本锚级。
|
||||
- [ ] **W-PROBE · 第一人称需求探针方法固化**(创始人 2026-07-06 拍立项,**主线同步推进**:方法附录即刻固化,首个复用随子系统进设计期)→ 产出两件:ⓐ 方法附录并入 [`agentic-seat-context-design.md`](../../.agents/skills/agentic-seat-context-design.md) **§10**(查重结论:不新建文件)——八轮问题序列模板 + 收敛判据 + 固化格式 + 交接契约(下游设计档逐条消费基线留「采/改/弃」)——**✅ 2026-07-06 已落**(protocol §2.3 同步加条件前置句;强制级别待创始人拍);ⓑ 探针对象排期(唯一登记处=本单,防双写):候选 = 审核台辅助 agent / 玩家 feed 推荐 / 回流环运营席 / 创作者对话席下一代,按「谁先进设计期谁先探」,不自造需求;过程 = 附录固化(✅)→ 首个复用对象真跑全链(创始人驱动 fable 探针会话→基线档→opus 设计档)→ 按真跑发现修订收口;边界 = 探针产出永远是需求基线非架构 SoT、每对象一次 fable 探针会话为限、创始人驱动不可省(轮间方向修正是人的活)、只探已进设计期子系统、不入产品 runtime;验收 = 附录落库+索引同步(✅)+ 首个复用全链走通且设计档逐条引用基线 + 真跑问题回写;预算 = fable 0.5 会话(已用)+ 首次复用 1 探针会话。
|
||||
- [ ] **W-GENLOG · 生成侧过程蒸馏回路**(创始人 2026-07-06 拍立项)→ 目标 = 把「生成过程日志 → 高频问题/错误/弯路识别 → 蒸馏进模板/skill/tools/门」从人工惯例(15 签名母语化/`save.get` 幻觉/latch 口径皆人工挖成)变成常设回路;与数据飞轮回流环构成同一飞轮的两个半环——回流环调「生成什么」(锚留存/收益,等放量与 join 键),本环调「怎么生成」(锚过门率/成本/轮数/盲修空转率,**数据已在盘、即刻可跑**);产出 = ⓐ 设计档(校准单范式姊妹环:六段同构、同一治理门;分析两层守架构红线=机械统计归代码〔门×品类失败矩阵/成本轮数离群/修复空转/幻觉 API 频次〕+ 弯路模式判读归 LLM 分析 agent;出口对齐注入铁律 = 模板/脚手架 > 门/校验器/工具签名 > skill 补密度〔few-shot/易犯幻觉清单〕> prompt,每条出口 = 蒸馏工单人审后走既有过门落库、绝不直写)ⓑ 首单实证 = 拿现存 bake-off/parity/m3 批(数百局 trace/verdict/game-log,零新增采集)跑一张过程校准单,判据 = 挖出人工未登记的高频模式且 ≥1 条转化为已验收蒸馏落库;过程 = fable 骨架(**✅ 2026-07-06 落档** = [`生成侧过程蒸馏回路-设计`](../agent-specs/2026-07-06-生成侧过程蒸馏回路-设计.md),七检绿;裁决点 5 条见档 §7,**④⑤已拍**(2026-07-06 按建议:④改动六成功面萃取归并本环、不另落第二条萃取线;⑤首单实证=内测冲刺后与 W-NSTAR L1 错峰,填肉设计不受限))→ opus 填肉分片(档 §6 五单,G-2/G-3 可并行)→ 双评审 → 创始人批 → 首单实证;边界 = 不动回流环已批机制(共用治理不重写)、离线批分析不进生成热路径、优化锚不碰留存/收益(归回流环)、金标与验收基准不纳入回流面(沿数据飞轮 SoT 红线)、蒸馏落库全走既有门(rubric-sync/template-spec-gate/prompt 四道闸/W-TPL 产线);依赖 = 无硬前置(统一 trace 契约落地后迁数据源,先用现存 trace.jsonl/trace_json);验收 = 设计档双评审+创始人批 + 首单两判据;升级 = 出口与 W-TPL/W-GENRE 撞面以其过门验收为准。
|
||||
- [ ] **W-T2LOCK · tier2 Service 工具面写锁强制**(创始人 2026-07-06 拍立项;源 = W-NSTAR O-3 注入面审计 A4 现网发现)→ 问题 = tier2 Service 路(create_app)经框架 `get_toolkit` 无条件并入 15 件默认工具,平台锁定 `LOCKED_PLATFORM_FILES`(**10** 平台文件,`tier2/gen-worker/worker/toolkit.py:34-45,50` frozenset 精确匹配——W-NSTAR 终审源码核实,原 O-3 报 11 有误)只在自有 `write_source` 强制、**框架内建 Write/Bash 完全旁路**(`service/app.py:106-111` 有意保留框架工具面;cheap Service 已双补丁封口、tier2 未封);目标 = **不剥工具面、在框架内建写工具层强制平台锁**(tier2 设计有意保留 planning/schedule,照搬 cheap 剥除式补丁会破坏其设计意图)——包装/补丁框架内建写类工具,对锁定文件写操作 fail-closed;验收 = 单测(内建 Write/Bash 写锁定文件被拒 + 非锁定文件不受影响)+ 一局 tier2 Service 真生成回归(mini-desktop 窗口)+ 负向演示;边界 = 只动 tier2 service 装配层(补丁模块形态,仿 cheap 双补丁 apply 序),不动 cheap 路、不动 AgentScope 源、不动锁定清单本身;与 W-NSTAR 关系 = 本单是现网止血,O-3-D1「统一席位工具面白名单中间件」是 L3 设计基线,统一件落地后本补丁并入退役;领单 = opus;预算 = 1 会话 + 真生成一局;升级 = 若发现锁定清单本身语义有误(目录锁 vs 文件锁,O-8 走查缺口⑥)先回 fable。
|
||||
- [ ] **W-REPAIR-CTX · 修复轮注入面补强**(2026-07-05 审计定界:两档共用 RepairMiddleware,注入 = 固定前缀 + `judgment.feedback` 单条文本,`tier2/gen-worker/worker/middleware.py:833-835`;cheap 已含测量值 + game-log 摘要,tier2 只有测量值)→ 本单只做两件小的:① 剩余修复次数 + 预算态格式化进注入 content(`on_reasoning` 单点、两档共用;带 ¥ 态则 `__init__` 增收 breaker 引用);② tier2 `verdict_feedback` 移植 `_game_log_brief`(前提核实 tier2 门线真产 game-log.json,不产则如实改单、先落产出)。验收 = 单测断言注入 content 含剩余次数/预算态 + tier2 feedback 含运行时日志摘要段 + 一局真续修对照留证;边界红线 = 截图引用与上版 diff 不在本单(依赖视觉通道/快照基建,记后续观察);风险 = 注入变长影响续修行为——A/B 对照一局留证。
|
||||
- [x] **W-PCI · prompt 四道闸 CI 接线 ✅**(2026-07-04 当日排单当日收口,merge `ec95faaf`)→ 工单 = [`四道闸CI接线工单`](../plans/2026-07-04-prompt治理-四道闸CI接线-工单-plan.md)。交付:**步骤 0 消费面 17 条三态对账**(一手代码证据:live=01-safety+tier2 八条+cheap-system;gamedef 四策划模板+generic-coder STUB=化石,SUPPORTED_TEMPLATE_IDS 已下架坐实;回写 registry 头部总表)+ **段 A 离线版本闸**(`check_version_bump.py` 挂 pre-commit 门5 + contract-gates,改正文不升版即拦)+ **段 B 真模型四闸**(`eval_gate.py` 薄版重建,只焊 live、无金标 fail-closed、cap ¥5 硬编码;`prompt-eval.yml` workflow_dispatch)+ 负向演示三连(砍坏 safety 判定被闸 3 回归 diff 逮住)+ SoT §2/§4/§8 现状改真。fable 终审:5 hash 全真+diff 亲读+段 A 负向亲演(拦→恢复干净)+段 B 亲跑四闸全绿(¥0.0071)。**余账**:live 但无金标的 cheap-system/tier2 八条按 fail-closed 挂账,金标集补齐随品类线走;SoT §3「四策划模板已接 live」句与对账结论相抵 → 归 W-DSGN。
|
||||
- [x] **W-A11 · 切片三收尾 ✅**(2026-07-04 计费真后端 e2e 收官=决策包④ 兑现:/modify/plan 判意图 behavior/regenerate-module/needsConfirm=true → /modify 执行 → 新版 93150、task 201 modify_mode/base_version_id/idempotency_key/D11=90/trace.cost 0.9871 全断言绿;证据=cutover plan §9「A11」节)。
|
||||
- [ ] **W-REAL · 16 周真实化批次**(**R1/R2/R3/R4/R6 ✅ 2026-07-02 全部完成并 merge**;剩 R5 受 feed 内容解锁):
|
||||
|
||||
@ -251,12 +251,16 @@ propagator 接线是纯读 header + 起 span,失败即 best-effort 降级(extrac
|
||||
**T5-7 new-api 通道巡检 + 健康告警**
|
||||
目标:通道可用性有眼睛。输入:new-api 通道配置、key 额度查询。产出:巡检 job + 健康指标 + 告警;冻结阀留 follow-up。验收:关一个通道,健康指标掉、告警送达。依赖:T5-5。风险:job 落点(见 §7 待拍第 3 点);自动冻结阀本期不做、勿顺手加。
|
||||
|
||||
**T5-8 context 装配可观测(投喂进 trace,2026-07-05 创始人拍增)**
|
||||
目标:生成会话的 trace 记录"这局装配了什么"——prompt/配方版本、注入块清单(块名 + 版本/哈希 + 字节数),支撑配方 A/B 与"传导断裂"类投喂归因(需求源 = [`agentic-seat-context-design.md`](../../.agents/skills/agentic-seat-context-design.md) §4 第 6 性质)。输入:cheap/tier2 装配点(genconfig 取值链、middlewares 工厂)、波③ OTLP sink(默认关)+ jsonl 主路。产出:span 属性 + trace.jsonl 同步字段,旗随波③ 同开关。验收:trace.jsonl 与(旗开时)Tempo 的生成 span 见配方版本与块清单;旗关 = 字节不变。依赖:③(已落)。风险:属性膨胀——只记块名/版本/哈希/字节数,不记内容本体。
|
||||
|
||||
### 碰生产 game-cloud 的部署窗口点
|
||||
|
||||
- **game-cloud 手埋(T5-1)**= 改单体代码 = 生产部署窗口(重构建 + 重启)。是否与波② 生产上线合并成一次窗口,交主控拍(见 §7 待拍第 2 点)。
|
||||
- **集中日志(T5-3)**:走 logback 改动则落 game-cloud 生产窗口;走 Collector filelog 抓容器 stdout 则不改单体(见 §7 待拍第 4 点)。
|
||||
- **通道巡检(T5-7)**:落 game-cloud 后台 job 则占生产窗口;落独立小 job(mini-infra)则不碰单体(见 §7 待拍第 3 点)。
|
||||
- **Python 埋点(T5-2)**= 生成线重启窗口。
|
||||
- **context 装配可观测(T5-8)**= 生成线重启窗口(可与 T5-2 并窗);默认旗关、不改生成行为。
|
||||
- **Grafana 看板/告警/webhook(T5-4/T5-5)与 admin 进盘(T5-6)**= 观测栈配置 + 前端发布,不碰 game-cloud 单体。
|
||||
|
||||
### 验收(引设计 §8 全六条 + 第 7 条)
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 28 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
@ -8,9 +8,9 @@
|
||||
},
|
||||
"C_frame": {
|
||||
"pass": true,
|
||||
"f0": 63,
|
||||
"f1": 93,
|
||||
"delta": 30
|
||||
"f0": 58,
|
||||
"f1": 89,
|
||||
"delta": 31
|
||||
},
|
||||
"I_control": {
|
||||
"pass": true,
|
||||
@ -19,24 +19,24 @@
|
||||
{
|
||||
"tapX": 50,
|
||||
"before": 195,
|
||||
"after": 50.00000000000827,
|
||||
"moved": -144.99999999999173,
|
||||
"distToTarget": 8.270717444247566e-12,
|
||||
"after": 50.0000000000465,
|
||||
"moved": -144.9999999999535,
|
||||
"distToTarget": 4.6497916628140956e-11,
|
||||
"pass": true
|
||||
},
|
||||
{
|
||||
"tapX": 340,
|
||||
"before": 50.00000000000827,
|
||||
"after": 339.99180684902717,
|
||||
"moved": 289.9918068490189,
|
||||
"distToTarget": 0.008193150972829244,
|
||||
"before": 50.0000000000465,
|
||||
"after": 338.0622981535271,
|
||||
"moved": 288.0622981534806,
|
||||
"distToTarget": 1.937701846472919,
|
||||
"pass": true
|
||||
}
|
||||
]
|
||||
},
|
||||
"D_render": {
|
||||
"pass": true,
|
||||
"bright": 153107,
|
||||
"bright": 154283,
|
||||
"maxCh": 255
|
||||
},
|
||||
"E_live": {
|
||||
@ -50,7 +50,7 @@
|
||||
},
|
||||
"F_wiring": {
|
||||
"pass": true,
|
||||
"callCount": 24,
|
||||
"callCount": 21,
|
||||
"sample": [
|
||||
"particles.spawnEmitter",
|
||||
"audio.synth.synthSfx",
|
||||
@ -72,10 +72,10 @@
|
||||
},
|
||||
"G_input": {
|
||||
"pass": true,
|
||||
"inputHash": "76bc4bff",
|
||||
"controlHash": "9c76f3b1",
|
||||
"atFrame": 943,
|
||||
"ctrlFrame": 946
|
||||
"inputHash": "e1907e50",
|
||||
"controlHash": "9f4addb3",
|
||||
"atFrame": 816,
|
||||
"ctrlFrame": 820
|
||||
},
|
||||
"H_progress": {
|
||||
"pass": true,
|
||||
@ -102,8 +102,8 @@
|
||||
"progress": 0,
|
||||
"gameoverReason": "",
|
||||
"ball": {
|
||||
"x": 366.33506696425985,
|
||||
"y": 468.3222860673734,
|
||||
"x": 379.66701339285197,
|
||||
"y": 489.07568696625253,
|
||||
"vx": -199.9791964288825,
|
||||
"vy": -311.3010134831855
|
||||
},
|
||||
@ -120,13 +120,13 @@
|
||||
"progress": 0.033333333333333326,
|
||||
"gameoverReason": "ball_lost",
|
||||
"ball": {
|
||||
"x": 377.6776433247279,
|
||||
"y": 838.6239526944314,
|
||||
"vx": -319.341400516327,
|
||||
"vy": 186.87180075193487
|
||||
"x": 146.30569972331975,
|
||||
"y": 838.7991318744353,
|
||||
"vx": 253.283090406036,
|
||||
"vy": 269.71777122460395
|
||||
},
|
||||
"paddle": {
|
||||
"x": 302.3013097991137,
|
||||
"x": 89.5866584777832,
|
||||
"y": 810,
|
||||
"w": 70
|
||||
}
|
||||
@ -138,18 +138,18 @@
|
||||
"firstPlay": {
|
||||
"enabled": true,
|
||||
"categoryDerived": "skill",
|
||||
"playableMs": 61,
|
||||
"playableMs": 46,
|
||||
"playableThresholdMs": 2000,
|
||||
"warmupMs": 24713,
|
||||
"warmupMs": 640,
|
||||
"firstFeedback": true,
|
||||
"firstMove": {
|
||||
"kind": "tap",
|
||||
"x": 198.33298660714803,
|
||||
"x": 308.321544643033,
|
||||
"y": 800
|
||||
},
|
||||
"notes": [
|
||||
"playableMs=预热后 warm 稳态,不覆盖 bundle 首加载退化;warmupMs 记冷启;真机 first-load 阈值校准留 staging(P2)。本门 v0 守得住卡死/装载失败退化,守不住大 bundle/慢首加载退化。",
|
||||
"首反馈[真判] 动画自走类 A/B(control-body-moved)@f85:控制体paddle.x Δ=145(>moveMin25?) → 输入因果成立(控制体被点动/状态变/信号显著),非「球本就在动」的重言式"
|
||||
"首反馈[真判] 动画自走类 A/B(control-body-moved)@f84:控制体paddle.x Δ=145(>moveMin25?) → 输入因果成立(控制体被点动/状态变/信号显著),非「球本就在动」的重言式"
|
||||
],
|
||||
"playableOk": true,
|
||||
"playableScope": "warm",
|
||||
@ -159,12 +159,12 @@
|
||||
"clean": true,
|
||||
"feedback": true,
|
||||
"reason": "control-body-moved",
|
||||
"noise": 1108,
|
||||
"signal": 10681,
|
||||
"ctrlDelta": 144.9999980491333,
|
||||
"noise": 369,
|
||||
"signal": 10668,
|
||||
"ctrlDelta": 144.99999853684997,
|
||||
"ctrlPath": "paddle.x",
|
||||
"ctrlA": 195,
|
||||
"ctrlB": 50.0000019508667,
|
||||
"ctrlB": 50.00000146315002,
|
||||
"moveMin": 25,
|
||||
"stateChanged": false,
|
||||
"bMove": {
|
||||
@ -176,21 +176,21 @@
|
||||
"signalRatio": 3,
|
||||
"minSignal": 200,
|
||||
"noiseCeiling": 6000,
|
||||
"target": 85,
|
||||
"frameA": 85,
|
||||
"frameAp": 85,
|
||||
"frameB": 100,
|
||||
"target": 84,
|
||||
"frameA": 84,
|
||||
"frameAp": 84,
|
||||
"frameB": 106,
|
||||
"fbFrames": 9,
|
||||
"bootFrameA": 45,
|
||||
"bootFrameAp": 45,
|
||||
"bootFrameB": 46,
|
||||
"bootFrameA": 48,
|
||||
"bootFrameAp": 48,
|
||||
"bootFrameB": 48,
|
||||
"phaseA": "playing",
|
||||
"phaseB": "playing",
|
||||
"remainingA": 30,
|
||||
"remainingB": 30
|
||||
},
|
||||
"coreLoopReached": true,
|
||||
"coreLoopElapsedMs": 28323,
|
||||
"coreLoopElapsedMs": 23790,
|
||||
"coreLoopThresholdMs": 60000,
|
||||
"pass": true
|
||||
}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user