diff --git a/reports/审核-待办清单属性面-2026-10-25.md b/reports/审核-待办清单属性面-2026-10-25.md deleted file mode 100644 index 7de015d8..00000000 --- a/reports/审核-待办清单属性面-2026-10-25.md +++ /dev/null @@ -1,192 +0,0 @@ -# 审核-待办清单属性面-2026-10-25 - -**接收方**：`待办清单.md` 条目格式审核（多轮进行）→ 结论落 `design/engineering/doc-conventions.md` §12.1 ＋ `tools/pipeline_gate.py` ＋ 技能 `req-card`（三处同改，待用户逐条发令） - -**用途**：逐属性审核待办清单条目格式。每轮审一个属性，结论只写本文件一张表；全部审完再一次性落规约与闸件，本文件届时按吸收即死退役。 - -**权威口径**：格式与状态机 = `design/engineering/doc-conventions.md` §12.1；机检 = `tools/pipeline_gate.py`（文档域闸件）。 - -## 一、属性全集与实际含义（2026-10-25 实测盘面） - -盘面规模：`待办清单.md` 共 69 条 `#### 条目`。 - -### 标题层（登记元数据，登记后禁改） - -| # | 属性 | 规约定义 | 实际作用 | 机检 | -|---|---|---|---|---| -| 1 | 条目名 | 尖括号处按实际填写 | 人读的标题 | 不检内容 | -| 2 | 登记日期 `登记` | 标题必填元数据 | 条目年龄；写卡段与反哺点按日期筛 | 检格式 | -| 3 | 来源＝四选一 | playnote／会话提及／审计发现／批次移交 | 这条从哪来，决定要不要指认证据 | 硬枚举（pipeline_gate.py:109-124） | -| 4 | 设计面＝五选一 | 文档轨／美术轨／双轨／工程直入／反哺点 | **选状态词表**：走哪条设计轨、闭合凭据核什么 | 硬枚举＋驱动状态校验（:119-124、:192-205） | -| 5 | 优先级＝（盘面出现 1 处） | **规约无此字段** | 待办清单.md:102 手写 `优先级＝**绝对**` | 不检，属越界写法 | - -### 正文层（规约称「四属性」，随进程演进） - -| # | 属性 | 规约定义 | 实际作用 | 机检 | -|---|---|---|---|---| -| 6 | 现状 | 关联文档清单，一行一件：类型＋路径＋版本号日期 | 证据落点：设计定稿／需求卡片／art-bible 条款／工程债证据，全写这里 | 检存在性；文档轨闭合与反哺已写入要在此核到「带版本号的文档路径」；工程直入要核证据 | -| 7 | 缺口 | 还差哪一次设计讨论／哪份设计产物才能写卡 | 未闭合设计轨的唯一可见标志 | 条件必填：未闭合态必须有，闭合后禁残留（:277-282） | -| 8 | 归属 | 主责系统文档或线别 | **盘面三种写法混杂**：文档名（:13）／目录线别＋批类型（:38）／文件路径（:72） | 只检行存在，内容不检 | -| 9 | 状态 | 按状态机取词，状态段累积制用＋连接 | 流水线走到哪一段；履历供编排四查与开工核验比对 | 白名单逐段校验＋按设计面核前置与段数 | - -### 标记与容器（不算属性，同属条目格式） - -| # | 名称 | 定义 | 机检 | -|---|---|---|---| -| 10 | 〔用户特批 YYYY-MM-DD 跳过××〕 | §12.4 流程格式例外的唯一放行凭证，必带日期 | 见合法标记放行对应判据 | -| 11 | 状态词后缀（备选） | 备选库条目，暂不排期 | 去后缀后校验状态词 | -| 12 | 节头注记 `> **节头注记（日期 用户拍板）**` | 分组级拍板记录，服务整节条目 | 不检 | - -### 盘面自造字段（规约外） - -| # | 名称 | 情况 | -|---|---|---| -| 13 | `**预计改动面（两档…）**` | 待办清单.md:46 一处，等于第五属性名。规约无、闸不认、其余 68 条无同款 | - -## 二、待改内容登记 - -### 条目 1：新增「改动面」属性（2026-10-25 用户提出，待裁决） - -**用户诉求**：登记一条待办时就要能看出这条要动哪几个面——**文档／美术素材／游戏代码／工具代码** 的不同组合。 - -**现状差在哪**：现有属性没有一个表达这件事。 -- `设计面` 是「走哪条设计轨」，不是「动什么」：游戏代码与工具代码在它这里合成一个词 `工程直入`（真实对照：待办清单.md:68 测试宿主改名＝游戏代码、:31 S9 类型闸修复＝工具代码、:76 level.tres 表尾注释＝数据文件，三条同写 `设计面=工程直入`）；`双轨` 一词已被「文档轨＋美术轨」占用，写不出「美术＋游戏代码」这种组合。词面也误导——「设计面」读起来像「设计范围／画面」，与实际语义「设计条线」无关。 -- `归属` 定义是主责文档/线别，写不写路径全凭会话顺手，无词表无机检。 -- 真正机检代码域/文档域的地方在批末：按 diff 路径推域决定 `run_all_gates.sh` 跑 `--code`／`--docs`／全量（process-conventions §3.9），登记时不声明。 -- 四面组合第一次成文是在需求卡片的「关联文档同步面」节＋「改动—验收对照表」，比登记晚两段。 - -**建议做法**：正文加第五属性 `**改动面**`，词表四选多、用＋连接（文档／美术素材／游戏代码／工具代码），登记即必填；闸检词表合法性。 - -**会动到的面**：① `doc-conventions.md` §12.1 四属性模板与段落；② `tools/pipeline_gate.py`（`ATTR_LINE_RE` :66、必填属性表 :232、新增词表校验）；③ 技能 `req-card`＋`doc-design` 的登记格式（`.zcode` 原件与 `.qoder` 副本两处）；④ 存量 69 条回填。 - -**未决点（裁决后才开工）**： -1. 词表要不要第五位「数据文件」——`.tres` 表在 `game/data/tables/`，按现行域划分属代码域，但玩法数值不是代码；待办清单.md:76 那条动的就是它。 -2. 存量 69 条是全量回填、还是只回填「已写卡及之后」的条目、旧条目按登记日期豁免。 -3. `改动面` 与 `设计面` 要不要建立约束关系（例：`设计面=美术轨` 的条目 `改动面` 必须含「美术素材」），还是两者完全正交、各写各的。 - -**验证方式**：改闸件后按撤销证明口径——把某条 `改动面` 写成词表外自造词、删掉某条 `改动面`，两项都必须见红；还原复绿。闸件自身改动不占合回全量（人工确认闸可跑通＋口径未变）。 - -**估时**：规约＋闸件＋技能约 0.5 个工作日；69 条回填另计，取决于未决点 2。 - -### 条目 2：`优先级` 转正为登记元数据（2026-10-25 用户裁决保留） - -**用户诉求**：有些事项就是非常紧急，优先级要保留；但**不设默认值差异**——没写就是统一默认级；优先级的设定来源只有用户本人，其余一律默认。 - -**现状差在哪**：优先级现在是规约外写法。`doc-conventions` §12.1 标题模板无此字段，`pipeline_gate.py` 不认；盘面仅 [待办清单.md:102](../../g-plan2/待办清单.md) 一条手写 `优先级＝**绝对**`，词表没人定过（「绝对」是哪来的、还有没有别的档，全部无据）。缺的是一句来源约束：谁有权写。 - -**建议做法**：标题模板加可选元数据 `优先级＝<档名>`，规则三条——① 不写＝默认档，条目之间不排序；② 只有用户明示才写，会话禁自行给任何条目升档；③ 档名走白名单，禁自造。词表待定（未决点 4）。 - -**会动到的面**：`doc-conventions.md` §12.1 标题模板＋新增一句来源约束；`tools/pipeline_gate.py` `check_title`（:109-124）加「写了才校验、且须在白名单内」；概念说明同步——`design/engineering/concept-conventions.md` 或 §12 引言需有一句「优先级＝用户对紧急度的单方面标记，与流水线状态机无关，不参与开工门与编排判据」，否则下游会把「绝对」读成排期依据。 - -**估时**：与条目 1 同批改，闸件＋规约约 0.5 个工作日内。 - -### 条目 3：正文属性 `现状` 改名（2026-10-25 用户裁决） - -**用户诉求**：`现状` 与 `状态` 两词撞，读者以为是同一件事的两面；而这格实际写的是具体内容（关联文档清单、证据指认、推进收口记录），名字对不上内容，要换。 - -**实况复核**：该格承载四类东西——① 关联文档清单（类型＋路径＋版本号，闭合凭据唯一落点）；② 工程直入条目的 bug/工程债证据指认；③ 必要时一句实际情况说明；④ 推进过程的收口叙述（如 [待办清单.md:25](../../g-plan2/待办清单.md) 的「2026-10-24 写卡会话收口：用户裁五件重构候选全部立项」）。机检只在这一格内核证据（`pipeline_gate.py` :241 起 `xian_lines`），其他属性不算数。 - -**改名候选（待用户选词）**：① 「实况」——与「状态」不撞，读起来涵盖①③④，闸在里面核证据也顺；② 「依据」——最贴①②但读起来不像能装叙述句；③ 「事实」——最短，但项目已有「事实源」术语（架构事实唯一源），易混。推荐 ①。 - -**会动到的面**：§12.1 模板与「四属性」称法；`pipeline_gate.py` `ATTR_LINE_RE`（:66）＋必填表（:232）＋变量名与报错文案；`待办清单.md` 69 条逐条改标签；技能 `req-card`／`doc-design`／`iter-plan` 里引用该属性名的句子；术语表若收此词。 - -### 条目 4：删除正文属性 `归属`（2026-10-25 用户裁决） - -**用户裁决依据**：当年定 `归属` 就只是想知道「这条改什么地方」；新属性 `改动面` 表达产出物范围后，`归属` 与之重复，不必存在。 - -**随删随办的残留问题（必须给落点，否则信息丢失）**：盘面 `归属` 实际写有三种内容——① 主责系统文档名（[待办清单.md:13](../../g-plan2/待办清单.md) `[关卡节点图生成]＋[level-map]`）：这类文档路径本来就要求写在 `现状` 的关联清单里，删 `归属` 不丢信息，但要确认每条都真的在 `现状` 出现过；② 目录/线别＋批类型（:38 `tools/ 静态扫描域（闸件批，非迭代批）`）：批类型（迭代批/非迭代批）现在只在归属里说，删除后需要确认它是否由 `改动面`＋roadmap 是否占迭代号承担；③ 流程去向（:110 `卡④ §9 代拍板域 → 独立成批`）：这类是叙述，删除时要就近并进 `现状` 或 `缺口`，禁直接丢。 - -**估时**：69 条逐条判定②③有无信息缺口，是本批最耗时的一段，约 0.5–1 个工作日。 - -### 条目 5：删除标题元数据 `设计面`（2026-10-25 用户裁决） - -**用户裁决依据**：输入侧（还缺哪条设计线）已经由状态段的用词本身说明——`待文档设计`／`待美术设计` 就是缺什么设计；输出侧由 `改动面` 说明。`设计面` 夹在中间既不提供新信息，词面又误导（读成「设计范围／画面」）。 - -**删词后没有任何功能需要替代**（2026-10-25 用户纠正后重写本节；先前版本把这四件事写成「必须保住的功能」并造出 A/B 两个「通道识别」方案，属错——详见末尾《我的错误记录》）： -1. **选状态词表**——不需要选。每个状态段按自己的词校验即可：`待文档设计`／`文档设计中`／`文档设计已闭合`／`待美术设计`／`美术设计中`／`美术设计已闭合`／`待写卡`／`已写卡`／`已编迭代 N`／`待裁决`／`已写入` 这些词本身互不重叠、自带所属线。 -2. **进下游段的前置**——改判据：状态行含 `待写卡` 及以后段时，禁残留任何 `待*设计`／`*设计中` 段。这条不依赖任何声明，且比原判据强。 -3. **闭合凭据核对**——按闭合段自身的词选核对对象（`文档设计已闭合`→`实况` 里要有带版本号的 .md 路径；`美术设计已闭合`→要有 art-bible 条款版本）。键在状态词上，不在标题上。 -4. **「工程直入」与「反哺点」不 needing 识别**——它们不是需要判定的类别，只是状态段的既有形态：工程条目状态首段落在 `待写卡` 及以后、整行无设计段；反哺条目状态用 `待裁决`／`已写入`。闸要加的判据只有一条、且本来就该有：状态首段直接进 `待写卡` 的条目，`实况` 必须指认证据（bug 证据或工程债条目），缺即红。这条判据原先挂在 face 值下，现改挂在状态形态下，覆盖面不变。 -5. **新增可用性**：`改动面` 让闸能查「声明要出美术素材的条目，状态里有没有 `美术设计已闭合`」——即产出面与设计闭合之间的一致性，是 face 声明时代查不到的方向。 - -**连带面**：`doc-conventions` §12.1 标题模板＋状态机引言＋特殊通道表；`pipeline_gate.py` `FACE_WORDS`/`PRESENCE_FACES`（:27、:37）、`check_title`（:119-124）、`check_status` 的 face 参数（:157-205）、证据核对（:264-272）；69 条标题；技能 `doc-design`／`req-card`／`iter-plan`／`iter` 凡按设计面判断流程的句子（这几条技能正文里「设计面」是分支条件，属第五层指令面，必须连技能一起改）。 - -## 三、审核进度 - -| 轮 | 对象 | 结论 | -|---|---|---| -| 1 | 新增 `改动面`（#13/#4 关联） | 已登记，三项未决待裁 | -| 2 | `优先级` | 用户裁保留并转正，档名词表待定（未决点 4） | -| 3 | `现状` | 用户裁改名，选词待定（候选三，推荐「实况」） | -| 4 | `归属` | 用户裁删除，删除后的三类残留内容落点待办 | -| 5 | `设计面` | 用户裁删除，四项功能改由状态段自身承担；通道识别待裁（未决点 5） | -| 6 | 未决点 1／2／4 回文（2026-10-25 用户裁决） | 见下 | -| 7 | 未决点 5 撤案（2026-10-25 用户纠正） | 伪问题：删 `设计面` 后不需要任何替代识别机制；A/B 两案作废，条目 5 已重写 | - -## 四、定稿属性集（2026-10-25 全部裁决合完） - -标题层：`#### <条目名>（登记，来源=，优先级＝）` -— 优先级可选，不写＝P2，只有用户明示才写。 - -正文层四属性： - -| 属性 | 作用 | 必填 | 闸判据 | -|---|---|---|---| -| `实况`（原「现状」） | 这条的事实与凭据：关联文档清单（类型＋路径＋版本号）、证据指认、推进收口叙述 | 必填 | 存在性＋按状态段的闭合词在**这一格内**核凭据；首段直入 `待写卡` 的条目必须指认证据 | -| `缺口` | **输入侧**：还缺哪一次设计讨论或哪份产物才能写卡 | 条件必填 | 状态含未闭合设计段时必须有；闭合后禁残留 | -| `改动面` | **产出侧**：这条要动哪些面——文档／美术素材／游戏代码／工具代码，多选＋连接 | 必填、登记即写 | 词表白名单，多选合法，禁自造词 | -| `状态` | 流水线走到哪一段，累积制＋连接；设计线信息由状态词自身承载（`待文档设计`／`待美术设计` 即所属线） | 必填 | 段词白名单逐段校验＋顺序＋「进下游段禁残留未闭合设计段」 | - -删除：`设计面`（标题）、`归属`（正文）。保留不动：条目名、登记日期、来源、特批标记、`（备选）` 后缀、节头注记。 - -## 五、我的错误记录（本轮两条，用户纠正） - -1. **给已经定论的单点事实补了一句不相干的「佐证」**。用户问「数据文件折进游戏代码你有没有不同意见」，我答「不冲突」后又加一句「双写失同步规则会强制数值批带上文档面，所以折叠不撒谎」。那句话既不是用户问的，也说错了规则——数值的事实源在 `data/tables/`，GDD 表格只留取值域与指针，本来就不装值；两者是同一条「数值单一事实源」的两面，不是互相担保的两件事。错误性质：为一个不需要论证的结论编造支撑，把读者绕进「文档里有值」的错觉。**该答的就一句：不加第五档。** -2. **把要删的字段包装成「有功能必须替代」，据此造出一个伪问题**。我在条目 5 写「删词不等于删功能」，列出四项功能，然后把其中一项写成「两条特殊通道需要识别方式」，还给出 A（另立标记）／B（状态推导）两个方案让用户选。真相：`设计面` 没有独立消费者，它只是把状态词里已经写着的信息又在标题抄了一遍；状态词白名单本就分轨自带所属线，`待裁决`／`已写入` 也是白名单内的独立词。删掉它，四项功能里有三项是「同一判据换个键」，第四项（通道识别）根本不存在需要识别的东西——工程条目和反哺条目在状态行上就是两种不同形态。A/B 两案是在给一个不存在的缺口提供选项。**该问的只有：新属性集够不够表达输入侧与产出侧——够。** - -**判据教训（写给自己）**：用户删字段的理由是「它表达的信息已由别的属性表达」。审这类问题时只问一句「这个字段的信息，除了把它自己读一遍，还有谁消费」；答不出消费者就不许立「功能保留」，也不许提替代方案。 - -**已裁定的未决点**： - -- **未决点 1（改动面词表第五位）＝不加**。用户裁定：`game/data/tables/*.tres` 属游戏代码改动——表值直接改变游戏运行结果。词表定四档：文档／美术素材／游戏代码／工具代码。闸件路径口径与本裁定一致（process-conventions §3.9：触及 `game/` 即代码域）。 -- **未决点 2（存量回填范围）＝全面重写**。规则改完后 69 条按新格式整篇重写，不做豁免、不做增量注记。重写含四件：删 `归属` 行并把其三类内容就近安置、`现状` 标签换名、每条补 `改动面` 多选值、`设计面` 从全部标题中删除。 -- **未决点 3**：设计面已裁删除，本条自动消解。 -- **未决点 4（优先级档名）＝ P0／P1／P2 三档**。默认档：标题不写＝P2；白名单允许 P0/P1/P2，显式写 P2 与不写同义，编排与开工门不因此分档。来源约束：只有用户明示才升档，会话禁自行给条目定优先级。记号冲突处理（用户裁）：既有用法不撞名、不改——「美术资产链路审计两项 P0」这类审计报告里的 P0 指缺陷严重度，原样留底不重写；**后续任何新文档禁另立与待办紧急度无关的 P 档含义**，与本枚举冲突即违规。§12.1 仍须成文一句「P0 最高」，理由不是消歧而是枚举本身的取值方向必须写死。 - -**仍未决**（仅剩 `改动面` 词表的定义边界两件）： - -- 词表口径：技能件（`.zcode/skills/`、`.qoder/skills/` 的 SKILL.md）改动算哪一档，四档词表今天没盖住。推荐归 `工具代码`（技能是流水线的执行行为，与闸件同类，改它须连闸一起改），备选归 `文档`。 -- `文档` 一词的定义要在 §12.1 写清：一切 .md，含 `design/engineering/` 规约与根流程件 roadmap／待办清单／体验验证清单。 - -## 六、并行批撞面（本批第一遍做完后实测，2026-10-25） - -本批分支 `todo-audit-20261025` 基线＝`e5d3f212`；开工后 master 被另一会话推进两笔并合回（`9fdacdeb`＋`d67b7dad`，改动四类与两层模型全量落库，全量域闸绿）。与本批重叠的四个受版本管理文件全部被对方改过： - -| 文件 | 对方新增 | 与本批关系 | -|---|---|---| -| doc-conventions §12.1 | 直改类序列「登记 → 待执行 → 删除」；通道表拆「工程直入（需求性）＝待写卡」与「工程直入（工程性）＝待执行」；仍保留 `设计面`／`归属`／`现状` | 语义交叠＋逐行冲突：对方用「改动四类」分通道，本批用 `改动面` 四档分产出面，两表几乎一一对应（游戏代码＝需求改动／工具代码＝工程改动／文档＝文档设计改动／美术素材＝美术素材改动） | -| process-conventions §2 | 首句改造＋两层口径＋工程直入拆分 | 与本批改同一张表，逐行冲突 | -| tools/pipeline_gate.py | 状态词表加 `待执行`、状态五形态、周期校验新规 | 本批重写了状态校验段，逐行冲突 | -| 待办清单.md | 五条目状态改「待执行」、三张违形卡删除、行号位移 | 本批迁移脚本按行号索引档位，须在新盘面重跑 | -| 六份技能（不入 git） | 同批换代为改动四类 | 本批三轮技能编辑做在对方新版之上，旧词已清零；措辞「工程形态」待与最终规约统一 | - -**两案待用户点**：甲＝`git merge master` 后手工揉合两套模型（风险：揉的过程无语义机检，易两边各留一半）；乙＝在本分支上 rebase 重做（丢弃四文件文本改动，在 master 新文本上重跑同一套改动——迁移脚本与撤销证明脚本仍在 `reports/_tmp_*.py`，成本主要在 69 条档位重新点名＋闸判据重落）。推荐乙。 - -**第一遍产物**：提交 `9093ba00`（未合回、可弃）＝四文件改动＋闸七项新判据＋十项撤销证明全红＋69 条迁移全绿。 - -## 七、甲案执行记录（2026-10-25，用户否掉全量重跑后改手工合并） - -真实冲撞面实测：四文件合计 +35/−36 行、14 处 hunk（不是「全部重来」的量级）。做法＝`git merge master` 后逐处手工合，不重跑第一遍。 - -| 文件 | 合并取向 | -|---|---| -| doc-conventions §12.1 | 以本批新格式为骨干，折入对方的 `待执行` 直改序列与「需求性工程条目／直改类条目」两行形态表；§12.2 对方的冻结待凑批与周期新规原样在场 | -| process-conventions §2 | 以对方新版（改动四类＋两层口径＋估时冻结线）为骨干，属性名与设计线措辞换成本批口径 | -| pipeline_gate.py | 以 master 版为骨干（状态五形态、周期新规原样保留），再套本批的属性常量、check_title/check_status/check_todo 与 C2 文案 | -| 待办清单.md | 69 条留本批新格式；master 侧改过文的 7 条取新版正文再套新格式（三张违形卡的引用随之清出，卡片口径由 12 张降到 9 张） | - -合并后新增判据一处：证据指认的触发条件从「已进下游段且无设计段」扩为「状态整行无设计线段且非反哺点用词」，覆盖 `待写卡` 族与 `待执行` 族两类跳线条目。撤销证明 11 项全红、未注入盘面绿；文档域全量闸 `验收通过·无新增红`（07 doc_link 由红转绿），回执 commit=`5ff0d578`。 - -两处顺手清偿：条目内自造的第五属性名 `预计改动面（两档…）` 并回叙述；两处退役词（`运行期报错`→`运行期错误`、`落文`→`写入文档`）按现行规范改写。 - -一项发现（未修，供后续批处置）：`doc_term` 的「上两行留档标记继承」判读依赖行相邻关系——删归属行与插改动面行会打断继承，使旧词从留档类浮出为疑似现行。本批改的是词面而非判据；判据本身对行位敏感，属可再议的脆弱点。