From d70991b0adbc952c993b4a16a5474836d4a0c0ab Mon Sep 17 00:00:00 2001
From: XingfenD <xingfen.fendy@outlook.com>
Date: Sun, 4 Oct 2026 04:14:09 +0800
Subject: [PATCH] docs: book P15-B as delivered (wrapper 0.3.9, ROADMAP ledger
 section)

P15-B merged to crearte master as 7f91fa3 (0.27.0, merge-base f823195, thirteen
commits across two fix-forward rounds). P15 is now fully landed.

Three things this entry records that a routine booking would omit.

The whole-branch review blocked the batch - the second time it has done so after
P11 - and its critical finding was in the guard layer rather than the product:
maskSourceComments() compared a two-character slice against the four-character
'<!--', so its HTML-comment branch never ran, producing two false greens and
three false reds and making two already-committed claims false. Product code
needed no change; one added line and one changed comparison closed it.

The second round was executed by the controller rather than the dispatched
subagent, which ran 1h25s and failed with no output, leaving nothing to salvage.
The controller produced one false green of its own on the way - a mutation round
whose anchor failed to match was scored as meeting an expectation that happened
to be an empty list, the same defect the reviewer had caught in itself.

The e2e suite carries a pre-existing flaky leg at roughly one run in three
(core.spec.ts's worker leg: helpers.ts reads an async-postMessage attribute with
a bare getAttribute and no retry). Every file involved has zero diff against the
batch base and all four legs this batch added were green in all three review
runs. Recorded so the next red CI run is not attributed to this release.

ROADMAP also gains a standing ledger section, which the roadmap never had: the
cross-batch items accumulated by P15's two review rounds and the branch review,
each with its measured basis rather than an aspirational note. It includes the
revival of feat/submission-preview - the inline play-test preview for the submit
form and the review page, which the user asked about and which turns out to be
delivered work sitting unmerged in two paired remote branches (crearte a3cb5e3,
crearte-server 6b072d6, 27 tests, zero residue on master), together with the two
hard collisions that make reviving it a real batch rather than a rebase.
---
 docs/CHANGELOG.md | 25 +++++++++++++++++++++++++
 docs/ROADMAP.md   | 27 +++++++++++++++++++++++++--
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md
index 063ffd4..98bbf3d 100644
--- a/docs/CHANGELOG.md
+++ b/docs/CHANGELOG.md
@@ -6,6 +6,31 @@ All notable changes to this repository should be documented in this file.
 The format loosely follows Keep a Changelog and can be adapted to the team's habits.
 本文档参考了 Keep a Changelog 的思路，也可以根据团队习惯调整。
 
+## [0.3.9] - 2026-10-04
+
+### Done / 完成
+
+- P15-B lands in crearte (0.27.0, merge `7f91fa3`, merge-base `f823195`, 13 commits): the game loading screen now follows the theme, closing the last white-flash surface — a pre-paint script in `<head>` reads hash, then `prefers-color-scheme`, then light (one level fewer than the main app, because games run on a separate subdomain where browser storage is origin-isolated), and the parent passes the theme as an optional ninth hash key while `GameHost` injects a non-reactive `effectiveTheme()` snapshot so switching theme cannot reload a game in progress. Also pinned `AA_PAIRS` with `['ink','surface']` (62 `.vue` sites, 58 of them inheriting `text-ink` from `body`, contrast 18.4225 light / 14.8468 dark) and deleted the dead `--color-info` token (`REQUIRED_KEYS` 12→11, `LEGACY_KEYS` 9 untouched, usage-side `var(--color-*)` unchanged at 75 — a movement there would have meant something referenced it, contradicting the dead-token premise).
+- P15-B 在 crearte 落地（0.27.0，merge `7f91fa3`，merge-base `f823195`，13 个 commit）：游戏加载屏现在跟随主题，消除了最后一处白闪面——`<head>` 内的 pre-paint 脚本按 hash → `prefers-color-scheme` → light 判定（比主应用少一级，因为游戏跑在独立子域、浏览器存储按源隔离），父侧把主题作为可选的第九个 hash 键传下去，而 `GameHost` 注入的是非响应式的 `effectiveTheme()` 快照，故切主题不会重载正在进行的游戏。同时给 `AA_PAIRS` 补钉 `['ink','surface']`（62 处 `.vue`，其中 58 处靠 `body` 继承 `text-ink`，对比度亮色 18.4225 / 暗色 14.8468），并删掉死令牌 `--color-info`（`REQUIRED_KEYS` 12→11、`LEGACY_KEYS` 9 不动、usage 侧 `var(--color-*)` 保持 75——它若变了反倒说明有东西在引用该令牌，与死令牌前提矛盾）。
+
+- **The whole-branch review blocked this batch — the second time it has done so, after P11 — and the critical finding was in the guard layer, not the product.** All four gates were green, every boundary held, and the product code needed no change at all. What failed was the mechanism the batch exists to deliver: `maskSourceComments()` took a 2-character slice and compared it against the 4-character `'<!--'`, so its HTML-comment branch never ran while the `//` and `/* */` branches worked. Measured on the shipped guard: two false greens (a fake `:root` palette block hidden in an HTML comment let a real light-theme fork and a real dark-theme WCAG violation at 2.5519 pass; the same block in a CSS comment reddened leg 7) and three false reds (an explanatory example in a comment reddened leg 8; **merely rewording a comment to mention `<style>` and `<body>` reddened legs 1–4 while the e2e suite stayed 9/9 green, so what reddened was the guard, not the implementation**). One added line plus one changed comparison closes all of it.
+- **全分支终审拦下了这批——继 P11 之后第二次——而 critical 发现在守卫层、不在产品里。** 四门全绿、每条边界都守住、产品代码一行都不用改。出问题的是这批存在的目的本身：`maskSourceComments()` 取 2 字符切片去和 4 字符的 `'<!--'` 比较，于是它的 HTML 注释分支从未执行，而 `//` 与 `/* */` 两个分支正常。在交付守卫上的实测：两处假绿（藏在 HTML 注释里的假 `:root` 调色板块让一次真实的亮色分叉与一次对比度 2.5519 的真实暗色 WCAG 违规通过；同款块放 CSS 注释里则让腿 7 变红）、三处假红（注释里一句说明性示例让腿 8 变红；**仅仅把注释措辞改成提到 `<style>` 与 `<body>` 就让腿 1–4 变红，而 e2e 套件 9/9 全绿——所以红的是守卫，不是实现**）。一行新增加一处比较对象改动就闭合了全部。
+
+- It also overturned two claims already committed to the spec and the adjudication: that the guard "does not depend on the implementer's wording discipline", and that an earlier critical fix was safe because comment masking had neutralised a trap comment. The second was true of that file, but only because the trap comment happened to use `//` — the fix's *direction* was right and it did catch the variants it was written for, while the *argument* for its safety rested on a generalisation that held for one carrier. That is the same shape P14's branch review found (the hole in the first round's own fix), now recurring. Two more universal/causal claims fell: "the only discriminating grid" (a real decision-order defect reddens two legs, and the phrase survived re-pin in four places — one of them written by the same child that had declared it would not use the word "only"), and a causal claim about what `snap.url === src` pins (renaming the parent's hash key `theme`→`t` leaves it green because both sides change together; it pins that the child stayed at the url the parent computed, which legs 1/2 catch for key names).
+- 它还推翻了两处已写进 spec 与裁定的声称：「本守卫不依赖实现侧的措辞自律」，以及上一轮某个 critical 修法之所以安全是「因为注释屏蔽已中和了陷阱注释」。第二句对那个文件是真的，但成立原因只是陷阱注释恰好用的是 `//`——修法的**方向**是对的、也确实抓到了它要抓的那些变体，而它的**安全论证**依赖一个只对一种载体成立的泛化。这与 P14 全分支终审发现的形态相同（洞在第一轮修复自身里），现在再次复现。另有两处全称/因果声称倒下：「唯一鉴别格」（一次真实的判定序缺陷会让两条腿变红，而这个措辞在 re-pin 后仍残留在四处——其中一处出自那个声称自己不会用「唯一」这个词的子代理），以及关于 `snap.url === src` 钉什么的因果声称（把父侧 hash 键名 `theme` 改成 `t` 时它仍绿，因为两侧同步变化；它钉的是子文档停在父侧算出的那个 url，而键名一致性由腿 1/2 覆盖）。
+
+- **The second round was executed by the controller, and that deviation is recorded rather than smoothed over.** The dispatched child ran 1h25s and failed with no output; a full wreckage inventory found nothing to salvage — no edits landed (HEAD unchanged, worktree clean, commit count still eleven), no report, no new evidence files, no working copy, no listening ports, no orphan stacks, and its transcript showed it never left preflight. With the review having supplied a literal diff already measured at 700 passed / 0 failed, the remaining work was mechanical, so the controller applied it and did the verification itself: four gates, eleven mutation rounds including the G series the reviewer had not run under the fix (all ten matching expectation, with a printed self-check that nine rounds actually mutated), a runtime probe inlining the shipped helper verbatim into a `.ts` file, and a 75-check acceptance harness. The controller produced one false green on the way — a round whose mutation anchor failed to match was scored as "meets expectation" because that expectation happened to be an empty list — the same defect the reviewer had caught in itself, fixed by scoring any errored round as a failure.
+- **第二轮由控制者本人执行，这个偏离被如实记录而不是抹平。** 派出的子代理跑了 1h25s 后 failed 且零输出；完整的 wreckage 盘点发现无物可救——没有任何编辑落地（HEAD 未变、工作树干净、commit 数仍是 11）、没有报告、没有新证据文件、没有工作副本、没有监听端口、没有残留栈，而它的会话记录显示它从未离开 preflight 阶段。由于终审已给出逐字 diff 并实测过它 700 通过 / 0 失败，剩余工作是机械的，故控制者直接应用并自己做验证：四门、十一轮 mutation（含终审在修法下没跑过的 G 系列；十轮全部符合期望，并打印「九轮确实造成了变异」作为自证）、一个把交付守卫函数逐字内联进 `.ts` 的运行时探针、以及一个 75 条断言的验收 harness。控制者途中也产出过一次假绿——某轮的 mutation 锚点没匹配上，却因为它的期望恰好是空列表而被算成「符合期望」——正是终审在自己身上抓到过的同一缺陷；修法是把任何 error 轮一律判失败。
+
+- ⚠️ **The e2e suite carries a pre-existing flaky leg at a 1-in-3 rate, and this batch is not its cause.** Across four runs (three by the branch review, one by the controller) `e2e/core.spec.ts:14 › worker 与 importScripts 可加载` failed once; the controller's own run was 111 green and **all four legs this batch added were green in all three review runs**. Root cause predates the batch: `helpers.ts`'s `frameDataset()` reads an attribute that a worker's asynchronous `postMessage` sets, using a bare `getAttribute` with no auto-retry, while `openGame()` only waits for the synchronous `data-ready`. Every file involved has zero diff against the batch base. `helpers.ts` is on the do-not-touch list, so the fix is ledgered: switch to `expect(locator).toHaveAttribute(...)`, which retries. **Written down so the next red CI run is not misattributed to P15-B.**
+- ⚠️ **e2e 套件有一条既有 flaky 腿，概率约 1/3，而本批不是它的成因。** 在四次跑批里（终审三次、控制者一次）`e2e/core.spec.ts:14 › worker 与 importScripts 可加载` 失败过一次；控制者自己那次是 111 全绿，且**本批新增的四条腿在终审的三轮里全部绿**。根因早于本批：`helpers.ts` 的 `frameDataset()` 用**裸 `getAttribute`（无自动重试）**去读一个由 worker 异步 `postMessage` 落地的属性，而 `openGame()` 只等同步的 `data-ready`。涉及的每个文件对批次 base 的 diff 都是 0 行。`helpers.ts` 在禁触清单上，故修法挂账：改用自带重试的 `expect(locator).toHaveAttribute(...)`。**写下来是为了下次 CI 变红时不被误归因给 P15-B。**
+
+- Spec and adjudication work landed in `51bed55` (eleven corrections closing the review's document-side findings: the leg-8 cell now describes the implemented attribute-extraction approach and deliberately carries **no regex literal**, because escaping an alternation bar inside a markdown table cell turns it into a literal bar in the regex — the controller's re-pinned version failed 4 of 7 attribute forms, worse than the 2 of 7 in the ruling it was copied from, and it had checked pipe counts per row without checking that the escaped code was still the code it came from; plus leg 9's un-re-pinned threshold, two uniqueness claims, the boundary table's missing e2e file, a count without its tree stated, D-G's imprecise "aligns verbatim", and two claims limited to their actual scope) and two new disciplines: every evidence file a report cites must be `ls`-checked before delivery (this caught the fixer's own fabricated evidence and the controller's fake-rigour artifact, both times by checking whether the file existed rather than whether the conclusion was right — and both conclusions happened to be right), and executable details in a spec must be grepped from the code entity or recomputed, never hand-written or transcribed unverified (three instances this batch, one of them a contrast figure quoted twice by two documents and recomputed by nobody: 3.0269 cited, 2.5519 actual, which no grey background produces).
+- spec 与裁定的修正落在 `51bed55`（十一处，闭合终审的文档侧 findings）：腿 8 那一格现在描述已实现的属性值提取法，并**刻意不含正则字面量**——因为在 markdown 表格单元格里转义竖线会让它在正则中变成字面量竖线，控制者 re-pin 的那版在 7 种属性形态里失配 4 种，比它所抄的那份裁定的 2/7 更差，而控制者检查了每行竖线数与表头相同、却没检查转义后的代码是否还是原来那段代码；另有腿 9 从未 re-pin 的阈值、两处唯一性声称、边界表漏列的 e2e 文件、一个没说明取哪棵树的计数、D-G 不精确的「逐字对齐」，以及两处被限定到实际适用范围的声称。并新增两条纪律：报告引用的每一份证据文件，交付前须逐个 `ls` 核在盘上（这条两次生效——抓到 fixer 自己的假取证与控制者的假严谨工件，两次都是靠核「文件在不在」而非「结论对不对」，而两个结论恰好都是对的）；spec 里的可执行细节必须从代码实体 grep 出来或自己复算，不得手写或直接转录未经核实的数字（本批三例，其中一例是被两份文档各引用一次而无人复算的对比度：引用 3.0269、实为 2.5519，没有任何灰底能得出被引用的那个值）。
+
+- Ledger entries added: the `frameDataset` retry fix above; leg 3 and leg 5 are both two-sided-imprecise literal pins and should be made semantic together (leg 5 misses five type-legal harmful forms that the behaviour leg catches — bracket access, `unref`, an unconditional read inside `adapters.ts` which it does not scan, provide/inject, and rewriting the url after the call site keeps its literal — while false-reddening two harmless ones); two `expect.poll` timeouts of 20s should drop to 10s so the end-to-end leg's worst path fits the 45s budget; the service worker's self-healing reinstall path drops the `theme` key (`RuntimeMeta` has no such field; 8 hash keys rebuilt versus the adapter's 9); three dead utility rules in the bundle whose values are ellipsis characters rather than hex, originating from placeholder literals inside a comment in the very guard that forbids hardcoded colours; the masker's `/*` branch can swallow string literals containing `/*` (no scanned file currently has that form); a second inline script now needs a CSP nonce, which belongs to the deployment repo's pending reverse-proxy work; and the `GameHost` colour clash as a design decision.
+- 挂账新增：上述 `frameDataset` 的重试修法；腿 3 与腿 5 都是双向都不精确的字面量钉桩，应当一并语义化（腿 5 漏掉五类类型合法的有害形态、由行为腿兜住——方括号取值、`unref`、`adapters.ts` 内的无条件求值（它不扫该文件）、provide/inject、以及在调用点保留字面量之后改写 url——同时误红两类无害形态）；两个 20s 的 `expect.poll` 超时应降到 10s，好让端到端腿的最坏路径落进 45s 预算；service worker 的自愈重装路径丢掉 `theme` 键（`RuntimeMeta` 没有该字段；重建 8 个 hash 键而适配器是 9 个）；产物里三条死 utility 规则，其值是省略号字符而非 hex，来源是那个禁止硬编码颜色的守卫自己注释里的占位符字面量；屏蔽器的 `/*` 分支会吃掉含 `/*` 的字符串字面量（当前被扫的四个文件都无此形态）；现在第二处内联脚本需要 CSP nonce，它属于部署仓待办的反向代理工作；以及作为设计决策的 `GameHost` 撞色。
+
 ## [0.3.8] - 2026-10-04
 
 ### Done / 完成
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
index 7f9c03b..5871da8 100644
--- a/docs/ROADMAP.md
+++ b/docs/ROADMAP.md
@@ -42,7 +42,30 @@
 | P13 | 暗色模式 | 两态主题（light ↔ dark）全站落地：首次访问跟随 `prefers-color-scheme`，显式点击后持久化到 `localStorage['crearte.theme.v1']` 并从此压过系统偏好（**无第三态**——有意不做）。每主题 **12 个设计令牌**；暗色在 `html[data-theme="dark"]`（特异性 (0,1,1)，无 `!important`/`@apply`）下整体覆盖亮色 `@theme` 块 = **方案 B**，故只需 **3 处 usage 迁移**（方案 A 需 32+ 处）。`index.html` 内联 **pre-paint 脚本**（IIFE + 仅 `var`，在任何 CSS 与 Vue module 之前）设 `data-theme` 防闪白，判定优先级与 `useTheme.effectiveTheme()` 逐字一致；页头 32px 开关（登出态可用）同步翻转 `data-theme` + `theme-color` meta + localStorage；`color-scheme` 由 `data-theme` 驱动使原生控件跟随。五个 `--shadow-hard*` 改 `var()` 传导；新增 `--color-skeleton` 与 `--color-scrim`（**两主题同值不翻转**——暗色 `color-mix(…ink 60%)` 实测 `oklab(L=0.962)` 近白会毁遮罩）。**零生产逻辑变更** | **完成**（2026-10-03 合并推送：crearte `983e7c4` 0.26.0（merge-base `e59a171`；记账 commit `4cfabdd`+`d1aa8c0`）。**一仓一写者**：T1–T5 交一个实现者子代理（同动 crearte 单一工作树），守卫任务 TDD 先行看红。任务级审查 **PASS with notes**（自设 10 条 mutation 挖出 5 条 findings）+ 全分支终审 **APPROVE with notes**（零关键 / 2 重要 / 5 次要 / 3 建议），10 条 note 合并前逐条裁定：4 条 fix-forward（`2433ec7`/`481574c`/`6ec6170`）+ 4 条（`bb2cb42`）+ 5 条 spec 文档纠正 + 1 条 pre-existing 延后 + 2 条 accepted-with-reason。**本批最重要事件：审查阶梯抓出控制者自己写错两次的守卫**——scrim 分离断言两次反转：spec 原文「`ink vs scrim ≥3` 两主题」会让亮色腿误红（亮色实测仅 1.07，两个深色互不分离）；控制者第一次改成 `max(填充侧,边框侧) ≥3` **数学恒真**（两侧互补 → 下界 = √cr(paper,ink) = **4.0621 > 3**，50653 采样暴力验证），故把亮色 scrim 改纯白（正是该令牌要防的泛白）时填充侧 1.1165 而 max() 读 18.42、守卫仍绿（任务级审查 M1 抓到）；交付形态改为**按主题钉实际分离侧**（亮=填充侧 paper、暗=边框侧 ink），mutation 现能变红。**两条教训入 spec**：① `max(a,b) ≥ k` 是恒真断言高发区（互补时下界非平凡），且**修守卫必须两方向都验**（对合法值不误红 + mutation 下不误绿）——同一错误在 alpha 兜底分支重演（只对当前 Chromium 输出验，漏了 CSS Color 4 百分比/指数 alpha 被解析成 80/1）；② **Tailwind v4 扫描全部源文件含 `.test.ts`/`.spec.ts`**——测试注释里的类名字面量会被当候选、烧死 utility 进产物（实现者用拼接修对一处，控制者八分钟后在自己裁定 commit 里重新引入，靠重建抓出 → spec §8-5b）。**终审另暴露一处 pre-existing 缺陷并延后不忽视**：`runtime/host/GameHost.vue:39` 降级外链徽标（`bg-accent text-paper`，11px bold）实测**亮色 `paper on accent` = 3.2590 < 4.5 FAIL**（暗色 7.1218 过），根因是 spike-0 的 grep 与 `noHardcodedColor` 守卫都只覆盖 `app/`、**漏了与 `app` 同级的 `runtime/`**；该违规自 P9-B 就在、P13 未使其变差且不属 P13 范围 → 三方面处置（守卫扫描根已含 `runtime/`、spec §3.2「accent 全仓唯一/纯非文本令牌」的假声明已纠正、违规本身登记可访问性打磨批）。守卫体系：`contrast.test.ts` **重构为按主题分块解析**（旧单 Map 解析器逐字保留为 `legacySingleMapParse` **反面钉桩**，防后人「简化」回去——旧解析器在暗色块存在后会把九个旧键静默解析成暗色值而断言标签仍写 light palette = 守卫悄悄变只守暗色）+ 新增 `noHardcodedColor.test.ts`（沿用 P12 `tableOverflow` 屏蔽范式，扫 `app/`+`runtime/`，含 2 positive + 1 negative control 防「扫 0 文件也报 0 违规」的假信心）+ `themeBootstrap.test.ts`（钉双写：同键名、两侧 stored 白名单、判定序、IIFE+var、theme-color、color-scheme meta）+ `dark.spec.ts` **10 腿**（含 pre-paint 归因腿：拦 JS 包后 `data-theme` 仍 dark，证明是内联脚本而非挂载后设置；反方向 stored 压过 system 腿；垃圾 stored 被忽略腿——后两条是 finding #2/N2 的行为解药，因文本位置守卫不鉴别语义重排）。验收：crearte vitest **688/79**（基线 635/74）/ vue-tsc 零错 / build+build-runtime OK / 主 e2e **102+1skip**（基线 92+1skip，P12 的 12 条 responsive 腿未动全绿）/ noauth 4——控制者与两位审查者各自独立复跑；产物 `main-C7966Gm-.css`：`var(--color-*)`=75、内联 `#141414`=2、暗色块在位、死 utility 双双归零、`--tw-shadow` 含 `var(--color-ink)`。挂账新增：第三态「恢复跟随系统」（spike 3 证明 header 在 @320px 最坏格无像素容纳带标签控件）、CSP 落地时内联 pre-paint 脚本需 `nonce`、死令牌 `--color-info`（`bg-info`/`text-info` 零实例）、SFC `<style>` 块内硬编码 hex（守卫不覆盖，accepted——`app/` 无 `<style>` 块）、GameHost 亮色徽标 WCAG 3.26——**修时须避开与「加载失败」状态点撞色**（亮色 `accent` vs `accent-ink` 仅 **1.4943**，徽标与状态点同屏共存于展柜标题栏，改成 `bg-accent-ink` 会把「已降级外链」与「加载失败」两个语义压成一个视觉信号），属**设计决策**而非一行改（已实测证伪显而易见修法）。CSP / TLS+HSTS / OG 卡片 / 播放计数 / D4 nav 换行 挂账待启动） |
 | P14 | 拆分 ContentService god object | `internal/service/content.go` 从 **856 行**、承载五条互不相干职责线（目录读 / 反应 / 上传 / 投稿 CRUD / 审核发布）的单一 `ContentService`，拆成五个子 service 文件 + 一个组合根：`catalog.go`(110) · `reaction.go`(102) · `upload.go`(99) · `submission.go`(291) · `moderation.go`(298)，`content.go` 缩到 **82** 行（只留组合根与真正被两三条线共用的 11 个声明）。五个 handler 各改为声明**消费方定义的窄接口**（可见方法 22 → **4/5/2/5/6**，审计确认**零过声明**、零孤儿）；`cmd/catalog.go` 不再为 god object 交税（**依赖槽 4→2**、`nil` bundle 占位消失、不再构造从不读取的 `PostgresUserStore`）；顺手删掉死字段 `ContentService.now`（构造器赋 `time.Now` 而包内零读取、无 test seam）。**纯结构重构、零行为变更** | **完成**（2026-10-03 合并推送：crearte-server `fe810dd` 0.18.0，merge-base `dbf7fe5`；记账 commit `e50d08e`；spec 两次 re-pin 在 wrapper `11fa1e2`+`33c2d8d`）。**一仓一写者**：T1–T3 交一个实现者子代理（同动 crearte-server 单一工作树），守卫任务 TDD 先行看红。任务级审查 **PASS with notes**（1 important + 6 advisory，自设 10 条 mutation）+ 全分支终审 **APPROVE with notes**（零关键 / 1 重要 / 2 次要 / 3 建议，16 轮 mutation/spike 全在 HEAD 导出副本上跑、以 140 个 blob hash 证明与 HEAD 一致），13 条 note 合并前逐条裁定：3 条 fix-forward（`e195be0`）+ 1 条 fix-forward（`e04694b`）+ 5 条 accepted-with-reason + 2 条 spec 措辞纠正 + 1 条挂账 + 1 条「审查者对我错」。**本批最重要事件：审查阶梯两轮都抓到了控制者自己的错误**——① 任务级审查发现 spec D-J 自述的守卫目的「防方法迁回组合根」**没有任何断言覆盖**（组合根新增方法后三断言 PASS + build/vet 绿 + **全量 11 包测试全绿** → god object 可静默回潮），并发现 **spec 里 mutation (a) 这个 positive control 自身有绕行路径**（它红是因为把方法从子 service 拿走，不是侦测到组合根多出方法；改成「复制」即遮蔽形态就会误绿）；② 全分支终审在**第一轮修复自身**里找到洞：源码扫描正则把接收者名写成**必需**分组，而 Go 允许省略不用的接收者名——遮蔽体恰好常不需要它（`func (*ContentService) CoverURL(k string) string`），该形态下 build/vet/**七断言全绿**而遮蔽**确实生效**（经组合根调用返被接管值、直调子 service 返原值）。**一个 token 修好**：接收者名改可选分组 `(?:\w+\s+)?`。③ 终审另**推翻我两处已入库的全称声明**（「断言 5 是唯一能抓遮蔽的手段」在修前为假；「F4 两层覆盖完整」被孤儿私有方法反例推翻）——两条我都独立复现成立后才动手，均已 re-pin 进 spec 并写明范围。**控制者 spike 否决了审查者建议的两条修法**（终审在真仓复核，两条驳回都正确）：断言值类型 `NumMethod()==0` **不可满足**（嵌入 `*T` 使方法进值+指针两个方法集，合法树上已是 **22** → **恒假断言**，正是 P13 恒真断言的镜像形态）；比 `Method.Func` 同一性**无法侦测遮蔽**（提升方法是 forwarding wrapper，真仓实测合法 `9683808≠9511104`、遮蔽 `9515680≠9511104`，两侧都不等）。**两条教训入 spec**：① 恒假与恒真同样无价值，且**恒假更容易被当成「守卫很严」而通过审查**；② 写「唯一手段」这类全称声明时必须先**枚举形态**（有名/匿名接收者、值/指针、导出/未导出），否则它成为下一个审查者的反例靶子。守卫终态：`architecture_test.go` **253 行 / 七条 reflect 断言**（组合根形态 · 各线导出方法名集 · 无 `now` 字段 · 组合根指针方法集=五线之并 22 · **源码不得声明组合根方法** · 各线字段名集=依赖面 · 构造器不漏装），经**两轮审查驱动补强**、对 **14 条 mutation 双向验证**（合法树 7/7 绿、每条 mutation 精确红且非编译红）。**副产品发现**：`reflect.Type.NumMethod()` 只暴露导出方法 → 断言 4 看不见**未导出**的组合根方法，那部分**只有源码扫描能抓**（四轮仅变方法名大小写的诊断坐实），故断言 5 的作用比原设计更宽。**Route C 两条 spec 未记的性质已入 §7**：组合根**零具名字段** → `s.store`/`s.objects` 等在其上是 ambiguous selector（实测编译红 `ambiguous selector s.objects`），这是比守卫更早的编译期屏障，也解释了为何字段数断言是防「加具体字段」的唯一防线（加具体字段在 Go 里合法）；`go vet` **不报告**遮蔽（实测 `vet_exit=0`）。验收：`wc -l` 口径 `content.go` **856→82**、六文件最大 **298**（`moderation.go`）、`service/` 内 >400 行生产文件 **1→0**、handler 里 `service.ContentService` **10→0**、`catalog.go` nil 占位与 `NewPostgresUserStore` **→0**、组合根自身方法 **25→0**、`cmd/serve.go` diff **0 行**、**既有 `*_test.go` 修改数 0**（`--diff-filter=M` 空，唯一新增 `architecture_test.go`）；字节级保真 base 39 声明 → **37 逐字一致 + 恰 2 处刻意变更**（struct 五具体字段→五嵌入指针、ctor 体改组装而**4 参数签名逐字不变**）+ 0 缺失 + 零重复声明、接收者分布 4/6/2/7/6/0 匹配归属映射；四门 `-count=1` 禁缓存全绿 **11 包 ok**（api ~11s 真库集成、service ~3.7s）+ 七断言 `-v` 全 PASS——控制者与两位审查者各自独立复跑。13 文件 src diff +1239/−805（含记账 14 文件 +1283/−805）。挂账新增：`Approve` **169 行**（`moderation.go:47-215`，7 阶段边界已测绘；拆分后行号已重新定位，base 树的 606–772 作废）、`memory_content.go` 814 行测试替身规模、handler 错误映射去重（92 处 `WriteError` 但仅 2 处 `errors.Is`，重复度不足以证明收益）、`AccountService`/`CleanupService` 的 `now` 字段使用复核（本批只确证 `ContentService.now` 死）、断言 6 只钉字段**名**不钉类型（低危，有编译器/既有测试兜底）、断言 5 词法扫描对块注释内部行**过严**（刻意保留：假红比静默遮蔽便宜）、孤儿私有方法归属无守卫（产物只能是死代码，accepted）。CSP / TLS+HSTS / OG 卡片 / 播放计数 / D4 nav 换行 / GameHost 撞色 / 第三态恢复跟随系统 / `--color-info` 死令牌 / bootstrap 加载屏暗色白闪 挂账待启动） |
 | P15-A | 拆分 Approve 七阶段 | `internal/service/moderation.go` 的 `Approve` 从 **169 行**函数体拆成 **24 行**编排体 + 八个具名 helper（`loadApprovePlan` 47 / `precheckApprove` 17 / `copyApprovalObjects` 22 / `applyApprovalInTx` 27 + 三个 kind 分支 22/22/24 / `cleanupApprovalUploads` 7）。唯一验收判据是**零行为变更**，用语句级证据支撑（162 条中 149 逐字 / 13 有登记理由 / 0 缺失 / 0 乱序）。事务边界一行未动。两个新守卫：函数长度（阈值 100 有 78 函数普查依据）+ 阶段独立性（钉住乐观预检与事务内悲观重检不合并，那是长度守卫结构上看不见的性质）。 | **完成**（server `e70e99b` 0.19.0 / wrapper `0.3.8`；任务级审查 PASS with notes + 全分支终审 APPROVE with notes，11 条 findings 全部合并前裁定） |
-| P15-B | bootstrap 暗色 + 守卫补钉 + 死令牌清理 | 游戏加载屏跟随主题（hash → 系统偏好 → light 的判定序，pre-paint 脚本在 `<head>` 内任何样式表之前），消除暗色用户启动游戏时的白闪；`AA_PAIRS` 补 `ink/surface`；删死令牌 `--color-info`（`REQUIRED_KEYS` 12→11、`LEGACY_KEYS` 9 不动、usage 侧 75 不变）。源码守卫 10 腿 + e2e 9 腿（含 `snap.url === 父侧 src` 因果链闭合与切主题不重载的行为腿）。 | **进行中**（全分支终审裁 🔴 需修复后合并：`maskSourceComments()` 的 HTML 注释分支是死代码，2 字符切片与 4 字符 `<!--` 比较 → 恒 false，造成 2 处假绿 + 3 处假红；第二轮 fix-forward 进行中，合并后记 wrapper 0.3.9） |
+| P15-B | bootstrap 暗色 + 守卫补钉 + 死令牌清理 | 游戏加载屏跟随主题（hash → 系统偏好 → light 的判定序，pre-paint 脚本在 `<head>` 内任何样式表之前），消除暗色用户启动游戏时的白闪；`AA_PAIRS` 补 `ink/surface`；删死令牌 `--color-info`（`REQUIRED_KEYS` 12→11、`LEGACY_KEYS` 9 不动、usage 侧 75 不变）。源码守卫 10 腿 + e2e 9 腿（含 `snap.url === 父侧 src` 因果链闭合与切主题不重载的行为腿）。 | **完成**（crearte `7f91fa3` 0.27.0 / wrapper `0.3.9`；全分支终审曾裁 🔴 需修复后合并：`maskSourceComments()` 的 HTML 注释分支是死代码，2 字符切片与 4 字符 `<!--` 比较 → 恒 false，造成 2 处假绿 + 3 处假红；第二轮 fix 由控制者直接执行——子代理 1h25s failed 零产出、wreckage 盘点无物可救；十一轮验牙全对 + 四门全绿后合并） |
+
+## 挂账（跨批累积，随时可插队）
+
+P15 两轮审查与终审累积的、不阻塞已交付批次的条目。每条都给了实测依据，不做愿望式登记。
+
+| 条目 | 依据与修法 | 来源 |
+|------|-----------|------|
+| `helpers.ts` 的 `frameDataset()` 改用 `expect(locator).toHaveAttribute(...)` | 它用裸 `getAttribute`（无自动重试）读 worker 异步 `postMessage` 落地的属性，而 `openGame()` 只等同步的 `data-ready` → e2e 有 **1/3 级别的既有 flaky**（`core.spec.ts:14 worker` 腿）。相关文件对 P15-B base **0 行 diff**，故与本批无关 | P15-B 终审 §8.1 |
+| 腿3 与腿5 **一并**改成语义化断言 | 两者都是**双向都不精确的字面量钉桩**：腿5 漏 5 类类型合法的有害形态（方括号取值 / `unref` / 跨文件 `adapters.ts` / provide-inject / 事后改写 url，均由 e2e 行为腿兜住）、误红 2 类无害形态；腿3 对语义等价的换序与 `.includes()` 改写假红。**两处必须同步**，否则风格永远分叉 | P15-B 终审 §2 + §5.2 |
+| 两个 `expect.poll` 的 timeout 20s → 10s | 端到端腿最坏路径 = poll(20s) + domcontentloaded + poll(20s) + waitForTimeout(8s) = **48s+ > `playwright.config.ts` 的 45s**；实测正常路径 <1s，10s 已极宽松 | P15-B 终审 §8.5 |
+| SW 自愈重装路径补 `theme` 键 | `RuntimeMeta` 无该字段；`bootstrapRedirect` 重建 8 键而 `adapters.ts` 是 9 键 → 缓存回收后自愈时，显式选择与系统偏好相反的用户会看到一次错误主题的加载屏。修法：`RuntimeMeta` 加 `theme?`、`writeMeta` 带入、`bootstrapRedirect` 条件 `hash.set` | P15-B 终审 F-10 |
+| `noHardcodedColor.test.ts:7` 的三条死 utility（另开 `chore/` 批） | 产物里 `.bg-\[\#…\]` / `.text-\[\#…\]` / `.border-\[\#…\]` 各 1 条，值是省略号 U+2026 而非真 hex（浏览器不生效，约 100 B）。**讽刺点**：该文件 `:17-21` 自己写着「本文件里的注释不得写出完整的硬编码色 utility 字面量」而 `:7` 正犯着。修它会变产物哈希 → 与「三次构建哈希相同」证据链冲突，故须独立批 | P15-B 终审 F-11 |
+| `maskSourceComments()` 的 `/*` 分支会吃掉含 `/*` 的字符串字面量 | 实测 `const marker = "/*"` 会让后续真代码被误屏蔽（P14 审查者第一版脚本的同族假阳性面）。**当前四个被扫文件都无此形态** → 潜在风险而非现存缺陷 | P15-B 终审 §1.2 |
+| CSP 落地需先定反向代理落点（**独立设计批**） | `crearte-deploy` 现有安全头/CSP/HSTS 命中 **0**、**没有 nginx/traefik/caddy 配置文件**（只有 `docker-compose.yml` 与 `.github/workflows/validate.yml`）。需要 nonce 的内联脚本**共 2 处**（`src/index.html` 1 + P15-B 新增的 `src/bootstrap/index.html` 1） | P11 判定 + P15-B 取证 |
+| 六个 >60 行的 Go 函数 | `deleteAccountLocked` 83 · `UpdateSubmission` 76 · `ValidateWorkFields` 75 · `ImportDir` 70 · `CleanupService.Run` 70 · `checkSubmissionRules` 66 | P15-A 终审 §10 |
+| 长度守卫阈值 100 的盲区 + 三条同族 | ①「≤100 行的任何合并形态」不红（合并阶段四与阶段六实测 91 行）② `TestApproveIsSmall` 的镜像盲区（内联一个阶段时所有守卫全绿）③ 任意长度的非 `func` 形态逃逸（125 行的包级闭包通过全部四门与三条长度守卫，现由 `TestNoPackageLevelFuncClosures` 部分覆盖，但**空格缩进与分行 var 条目**仍逃逸、靠 gofmt 门兜）④ 三个守卫常量的自证钉挡不住「同步改值 + 同步改钉」（固有上限，靠 review 兜） | P15-A 终审 §10 |
+| P14 断言五被**类型别名接收者**绕过 | `type X = ContentService` + `*X` 上的方法 → 遮蔽确实经组合根生效，而与既有断言逐字相同的正则报零命中、十条守卫加 vet 与 build 全绿。最小修法一条正则 `^type\s+\w+\s*=\s*\*?ContentService\b`；更强修法改 `go/ast`，一次性解决 F2/F5/F7 三条词法根因。**HEAD 上此类别名 0 处**，故洞未被利用 | P15-A 终审 F5 |
+| CG3 名字级检测被包级函数值别名绕过 | `var f = applyApprovalInTx` 再委托 → 5 条守卫全绿，但全量套件 **10 个测试 FAIL** 兜底（非静默逃逸）。与上一条同族根因：**词法级扫描看不见语义别名**，宜一并处理 | P15-A 终审 M1 |
+| 合并前验证清单须含 **DB-enabled 对照** | spec 点名的 5 个真库守卫（含 2 个并发/TOCTOU 测试）在实现者、任务级审查者、fix-forward 与控制者的**所有**跑批里全部 SKIP（无人设 `TEST_DATABASE_URL`），而被报成「含真库集成」的 `internal/api ~11s` 其实是 mock 路径。全仓受该变量门控的 Test 函数 **11 个**（cmd 2 / api 4 / repository 2 / service 3） | P15-A 终审 §5 |
+| `crearte-server/AGENTS.md:8` 的 gofmt 配方仍是退出码盲形态 | 该行写 `run gofmt -l ., go vet ./..., ...`，而 `gofmt -l` **列出未格式化文件时仍 exit 0** → 应改为 `test -z "$(gofmt -l .)"`。inner repo 改 AGENTS.md 须开 `chore/` 分支（约定类改动按仓内先例 `4f9de39` 不带 CHANGELOG）。workspace 级 AGENTS.md 已补 | P15-A 终审 F3 |
+| wrapper `docs/CHANGELOG.md` 的历史版本乱序 | `0.3.0`(行 69) 排在 `0.3.1`(行 76) 之前，由 `d6e08e1` / `3eec675` 引入，在 re-pin 前的 `82f0a6d` 上已存在 = **pre-existing**。头部 6 项仍降序，不影响新条目插入 | P15-A 记账期实测 |
+| `memory_content.go` 814 行测试替身 · handler 错误映射去重（重复度不足）· `AccountService`/`CleanupService` 的 `now` 字段复核 · D4 nav 换行 · OG 卡片 · 播放计数（server 侧 `play_count`/`og:` 均 0 命中 = 全新功能非改造）· 第三态「恢复跟随系统」（spike 3 已证伪：header 在 @320px 无像素容纳带标签控件） | 各自的前轮挂账，未变 | P12–P14 |
+| 🔴 **复活 `feat/submission-preview`（用户 2026-10-04 问起，已实测取证）** | 提交表单侧与审核侧的**内联试玩预览**，两仓成对：crearte `a3cb5e3`（19 文件 +680/−36，落后 master 87 commit）· crearte-server `6b072d6`（17 文件 +727/−17，落后 47）。含 `SubmissionPreview.vue`（复用 `GameHost` 全链路）、`content/preview.ts`、两条带鉴权路由 `/api/uploads/:id/bundle` 与 `/bundle-key`（仅 owner/admin，越权一律 404，响应形状与公开端点一致 → SW 解密逻辑零改动）、**27 个测试**（server 6+5、前端 3+9+4 e2e）。**master 上零残留**（`RouteUploadBundle` 命中 0）。**复活不是 rebase**：① 撞 P14 的 `TestNoContentServiceMethodDeclarations`（分支给 `ContentService` 加了 3 个方法，须迁到 upload 职责线）② 会复现 P15-B 刚修的白闪（分支 `preview.ts` 里 `theme` 命中 0，且它改了 `adapters.ts` +89/−26 与 `GameHost.vue` 的 props，正压在 D-B 陷阱上）。冲突面：crearte 8 文件双向（9 标记）、server 8 文件（8 标记），**分支独有新增 11+9 个不冲突** | 用户提问 + 控制者实测 |
 
 ## 排序理由
 
@@ -77,4 +100,4 @@
 | P13 暗色模式 | `docs/specs/2026-10-03-p13-dark-mode-design.md` | `docs/plans/2026-10-03-p13-dark-mode.md`（已执行，2026-10-03：crearte 0.26.0） |
 | P14 拆分 ContentService god object | `docs/specs/2026-10-03-p14-content-service-split-design.md` | `docs/plans/2026-10-03-p14-content-service-split.md`（已执行，2026-10-03：crearte-server `fe810dd` 0.18.0） |
 | P15-A 拆分 Approve 七阶段 | `docs/specs/2026-10-03-p15a-approve-phases-design.md` | `docs/plans/2026-10-03-p15a-approve-phases.md`（已执行，2026-10-04：crearte-server 0.19.0，merge `e70e99b`） |
-| P15-B bootstrap 暗色 + 守卫补钉 + 死令牌清理 | `docs/specs/2026-10-03-p15b-bootstrap-dark-design.md` | `docs/plans/2026-10-03-p15b-bootstrap-dark.md`（进行中，2026-10-03：crearte） |
+| P15-B bootstrap 暗色 + 守卫补钉 + 死令牌清理 | `docs/specs/2026-10-03-p15b-bootstrap-dark-design.md` | `docs/plans/2026-10-03-p15b-bootstrap-dark.md`（已执行，2026-10-04：crearte 0.27.0，merge `7f91fa3`；经**两轮** fix-forward，第二轮由控制者直接执行） |