第一年功能模块打磨总纲 v1 · 玩法设计

文档状态：working_outline / owner_review_pending 基线日期：2026-07-27 范围：开业元年 Day 1-360 的可玩闭环、表现闭环和验收闭环。定位：整理现状、缺口、优先级和验收，不替代剧情月本、运行时数据、施工卡或控制面。执行计划：docs/plans/active/2026-07-27-Year1产品体验打磨执行计划-v1.md

0. 先定结论

Year 1 当前已经不是“内容没做完”，而是“主体已可玩，最后一公里尚未统一验收”。下一阶段不应继续扩事件数量或新建系统，而应把玩家从开业到跨年的一条链打磨完整：

到达剧情锚点
-> 看懂场景与冲突
-> 做出选择
-> 立即看见经营、人情和方向反馈
-> 选择被存档并影响后续回响
-> 月末与阶段节点说明进展
-> 第 360 天先完成跨年落款
-> 再进入唯一胜利或失败结算
-> 玩家知道本年发生了什么，以及下一步能做什么

本轮总目标：

让玩家在不查看攻略和内部字段的前提下，能完成 Year 1，理解关键选择的即时结果与后续意义，并在第 360 天得到顺序正确、可恢复、可复盘的年度收官。

0.1 完成定义

同时满足以下条件，才能把 Year 1 记为“打磨收口”：

76/76 canonical 事件与 162/162 稳定选项保持唯一真源，关键锚点不会被随机事件抢占或永久错过。
精选选择都有即时经营反馈和一句玩家可读的人情账；第 355 天三种来年方针均有可见确认。
32/32 精选节点都有正式可解码场景，不依赖 CSS fallback 作为默认表现。
pending、刷新、错过、旧存档恢复和 Day 360 时间钳制行为一致，不重复结算。
正常 GameApp 严格执行“跨年剧情 -> year1Closed -> 年终胜负判断 -> 唯一终局”。
自动测试、桌面与竖屏关键路径、资产清单和 Git 纳管状态分别有证据，不能互相替代。

1. 当前真值快照

1.1 状态口径

| 状态 | 含义 | | --- | --- | | verified | 实现、自动门和要求的真实运行态验收都有证据 | | engineering_verified | 代码或资产结构已落地，自动测试通过，但真实浏览器或完整玩家路径仍欠证据 | | implemented | live workspace 已有实现，尚未形成完整验收包 | | documented | 只有设计、清单或施工卡，不代表实现 | | gap | 玩家闭环仍缺能力或正式资源 |

1.2 2026-07-27 实测基线

| 项目 | 当前真值 | 结论 | | --- | --- | --- | | 主线数据 | 76 个 canonical 事件、162 个稳定选项 | engineering_verified | | 精选演出 | 12 个月共 32 个精选节点 | engineering_verified | | 结果反馈 | 第 355 天三项来年方针与 5 条短人情账已在 live code 落地 | engineering_verified / browser_pending | | 场景资源 | 月 1 有 4 张；月 2-10 新增 24 张；合计 28/32 | implemented / 4 scenes missing | | 月 11-12 场景 | Day 330、350、355、360 四张运行时图缺失 | gap | | Day 360 顺序门 | year1CloseoutCompleted 已进入终局判断和 controller 输入 | engineering_verified / GameApp browser_pending | | Year 1 自动门 | npm.cmd run test:year1 为 64/64 | verified | | W29 回归 | npm.cmd run test:w29 为 47/47 | verified | | 类型检查 | npm.cmd run lint 通过 | verified | | 生产构建 | npm.cmd run build 通过，保留既有静态路径和 chunk-size 警告 | verified with warnings | | 经营模拟 | 三种模式均到达 Day 360，剧情选项量级不扰乱全年经济曲线 | directional evidence |

1.3 状态漂移警告

以下三张 2026-07-27 施工卡仍写着 ready_to_dispatch / not_started，但对应实现或资源已经出现在 live workspace：

docs/handoff/tasks/2026-07-27-year1-day360-endgame-order-v1.md
docs/handoff/tasks/2026-07-27-year1-showcase-result-feedback-v1.md
docs/handoff/tasks/2026-07-27-year1-month02-10-scene-integration-v1.md

因此后续调度必须先读 live code、测试和产物，再决定是吸收、补验收还是重派。不得仅凭任务卡头部状态重复施工。

2. 功能模块地图

| ID | 模块 | 玩家价值 | 当前状态 | 下一步 | | --- | --- | --- | --- | --- | | Y1-01 | 年线触发与时间推进 | 关键剧情按时出现，不被随机抽丢 | engineering_verified | 只补真实长链 smoke，不重写事件引擎 | | Y1-02 | 对白播放与选择交互 | 场景可读、选择可控、回应不重复 | implemented / self_tested | 在关键锚点做桌面与竖屏验收 | | Y1-03 | 选择结算与结果反馈 | 玩家知道“我做了什么、发生了什么” | engineering_verified / browser_pending | 验 Day 355 A/B/C 与短人情账 | | Y1-04 | 经营成长与年度节奏 | 剧情选择与经营压力互相解释 | partial | 审核未拍板 effect manifest，不猜填 | | Y1-05 | 角色、羁绊与前账回响 | 选择在后续人物关系中被记住 | engineering_verified | 抽验跨季度回响和错过分支 | | Y1-06 | 场景、角色与音效表现 | 关键节点有辨识度和录制价值 | 28/32 scenes | 补月 11-12 四景并做真实 DOM 验收 | | Y1-07 | 阶段追踪与年度复盘 | 玩家知道当前阶段、目标和年度成果 | tracking implemented / annual ledger undecided | 先评估现有终局是否已够用 | | Y1-08 | 存档、pending 与恢复 | 刷新或离线后不丢选择、不重复结算 | engineering_verified | 补真实刷新与切槽路径 | | Y1-09 | Day 360 收官与续玩 | 剧情先落款，随后唯一胜负结算 | engineering_verified / browser_pending | 正常 GameApp 验胜利与失败两条路径 | | Y1-10 | 验证与发布卫生 | 本地可玩结果能稳定进入版本 | partial | 补浏览器证据、Git 纳管和发布前清单 |

3. 模块打磨要求

Y1-01 年线触发与时间推进

当前基础：

76 个 canonical 事件按日、时段、经营阶段和前置条件触发。
主线锚点使用确定性优先级，普通随机事件不能抢占关键日。
completed / missed / pending / flags / year1Closed 已进入 Year 1 进度。
第 360 天未关闭前会钳制时间，pending 事件可恢复。

打磨重点：

用真实存档抽验 Day 1、63、100、155、215、275、330、355、360。
覆盖正常到达、错过窗口、pending 刷新、前置缺失 fallback 四类路径。
只修复可复现缺陷，不因验收顺手改事件日期或新增节点。

验收信号：关键锚点只出现一次；错过被明确记录；没有死锁；Day 360 前不会越年。

Y1-02 对白播放与选择交互

当前基础：

剧情事件逐句播放，开场结束前不提前显示选项。
支持前进、后退、跳至选择和选择后回应。
选择完成 claim 有重复提交防护，普通随机事件仍保留原有一次性展示。

打磨重点：

控制单段对白长度、人物轮次和移动端按钮密度。
保证每个选项的回应包含即时反应、可见变化和后续钩子。
玩家文案继续禁止内部 ID、snake_case 和开发者字段。

验收信号：玩家不需要猜何时能选；重复点击不重复结算；390x844 无遮挡或横向溢出。

Y1-03 选择结算与结果反馈

当前基础：

精选结果卡可显示资源、员工、羁绊、物件和人情账。
Day 355 A/B/C 已分别显示“扩张经营 / 稳健经营 / 人情优先”。
5 条过长人情账已改为显式短句，默认结果仍沿用通用 fallback。

打磨重点：

在 ?record=year1&node=day355 分别重放三种选择。
桌面 1440x900 与竖屏 390x844 各验三条路径。
A 保留既有名声与物件；B/C 不伪造数值奖励；任何路径都不显示内部 flag。

验收信号：每个选择都能回答“即时发生了什么”和“这件事被如何记住”。

Y1-04 经营成长与年度节奏

年度节奏按六段验收，不按 12 个月平均用力：

| 阶段 | 日程 | 玩家问题 | 必须讲清的反馈 | | --- | --- | --- | --- | | 开张教学 | 1-30 | 客栈如何活下来 | 接待、后厨、账房、巡夜和首轮总结 | | 街坊与风险 | 31-90 | 谁加入、第一轮危机如何处理 | 招募、食安、治安和季末落账 | | 扩建爬坡 | 91-180 | 花钱扩建是否值得 | 桌位、厨房、商队、半年结算 | | 羁绊与预热 | 181-240 | 团队为何愿意留下 | 两百日、羁绊抉择、挂红绸 | | 擂台高潮 | 241-300 | 全年积累如何进入高光 | 报名、决擂、余波、三百日总结 | | 岁末收束 | 301-360 | 这一年最终留下什么 | 盘点、团圆饭、来年方针、跨年落款 |

现有 360 天模拟证明精选数值量级不会打乱全年现金曲线，但它是方向性模型，不等于真实 GameApp 长跑。设计母本记录的 122/162 非零后果与 39 个待批准 effect 项应重新从 live data 生成清单后再拍板。

约束：

明确零后果可以保留，但必须有玩家可读的关系或方针反馈。
未获批准的数值、掉落、员工变化和羁绊变化不得猜填。
不为“每个选项都要有数字”制造无意义奖励。

Y1-05 角色、羁绊与前账回响

当前基础：月 1 选择能回响到后续精选节点，半年与年终摘要可读取跨月选择；员工变化和羁绊变化使用现有结算与边界钳制。

打磨重点：

每季度至少抽验一条跨节点回响。
已选、未选、错过三种状态不能使用同一句总结。
角色口吻服务经营与关系推进，避免只播梗或复述数值。
旧账补卷只补充线索，不重复演出同一 canonical 场景。

验收信号：玩家能从后续对白认出自己的选择，但不会看到技术字段或被长段旧对白重复轰炸。

Y1-06 场景、角色与音效表现

当前资源面：

月 1：4 张正式 1600x900 RGB PNG 已接入并完成桌面、竖屏验证。
月 2-10：24 张正式 1600x900 RGB PNG 已落盘，映射、尺寸、hash、HTTP 字节和 bundle 路径已核对。
月 11-12：Day 330、350、355、360 四景仍缺。
角色沿用现有项目素材；CSS 大堂仅作图片失败 fallback。
隔离 MP3 不进入 runtime；现有程序化 SFX 可继续使用。

打磨重点：

先补四张岁末正式场景，使精选视觉达到 32/32。
用真实 DOM 检查 <img> 完成加载、naturalWidth > 0、路径正确且未回退 CSS。
至少覆盖每个阶段一个锚点，另对 Day 330/350/355/360 全验。
音频只补有明确语义和授权边界的提示，不扩成全年 BGM 制作项目。

验收信号：桌面和竖屏都能识别场景焦点，标题、人物、对白和选择不互相遮挡。

Y1-07 阶段追踪与年度复盘

当前 StoryTrackingCard 与 year1Plan 已能展示阶段、关键节点、支撑项和当前验收提示；玩家可见字段已做净化。

下一步先做产品判断，而不是直接开发“元年故事账”：

若终局页已经清楚展示经营成绩、关系快照、名声定格、阅历折算和关键选择，则不新增第二个年度页面。
若玩家仍无法回答“我这一年做过哪些关键决定”，再设计最小故事账，只列 6 个阶段、6-10 条关键选择与对应回响。
故事账不得复制 76 个事件全文，不得暴露 completed / flags / eventId，也不得新增存档 schema。

验收信号：终局信息一屏内先回答“结果”，次级入口再回答“过程”，不把复盘做成开发者日志。

Y1-08 存档、pending 与恢复

自动回归已覆盖 pending、窗口过期、旧 ID 归一化、生日恢复、实时存档与周目槽同步。剩余重点是正常玩家路径：

弹窗打开后刷新，仍回到同一事件和同一未完成选择。
完成选择后刷新，不再次发奖或重复写人情账。
Day 360 closeout 未完成时，时间停在第一年；完成后只结算一次。
切换存档槽时，Year 1 进度不串槽。

验收信号：刷新、继续经营、切槽和离线回来都不改变玩家已经做过的事实。

Y1-09 Day 360 收官与续玩

唯一合法顺序：

Day 360 night
-> 跨年之夜逐句对白
-> 玩家完成唯一落款选择
-> storyProgress.year1Closed = true
-> 复用现有四维 AND 规则判断胜利或失败
-> 只打开一个终局入口

当前代码已加入 year1CloseoutCompleted 门，自动回归覆盖未落款不胜利、不写岁末失败、existing failure 优先和已落款后单次结算。仍需正常 GameApp 证据：

胜利路径：四维满足，先剧情后胜利结算。
失败路径：四维不满足，先剧情后败局复盘。
pending 路径：未落款时不出现胜利或岁末失败。
刷新路径：落款状态恢复后不重复终局记录。

不在本模块消费 Day 355 来年方针，也不接 Year 2 内容。

Y1-10 验证与发布卫生

需要保留四层证据：

| 层 | 证明什么 | 不能替代什么 | | --- | --- | --- | | 自动回归 | 数据、逻辑和合同没有回归 | 真实 UI 是否可读 | | 资产结构 | 文件存在、尺寸/hash/路径正确 | 浏览器是否真实解码 | | 浏览器验收 | 玩家路径、布局和交互真实可用 | Git 是否纳管、版本是否发布 | | Git/发布 | 文件进入明确版本与交付物 | 玩家设备上的最终安装状态 |

当前 public/story/year1/**、部分 Year 1 源码和验证产物仍处于 dirty/untracked 状态。后续收口必须单独检查：

运行时所需 32 张场景是否全部纳入目标提交。
生成源图、contact sheet、验证截图是否按仓库策略纳管或明确排除。
任务卡状态、控制面结论、live code 和验收证据是否一致。
本地绿灯不能直接写成已提交、已推送、已发布或 Owner 已验收。

4. 推荐施工顺序

P0-A 当前实现状态吸收

目标：对 Day 360、精选结果反馈、月 2-10 场景三项做一次只读归属审计，更新后续调度依据，避免重复派工。

完成信号：live diff、任务卡、验证报告和最终状态一致；未验证项保留 browser_pending。

P0-B Day 360 正常 GameApp 验收

目标：不改代码先跑胜利、失败、pending、刷新四条路径；只有复现缺陷才开最小修复卡。

完成信号：跨年剧情永远先于终局；胜利和失败互斥；记录不重复。

P0-C 岁末四景补齐

目标：补 Day 330、350、355、360 四张正式场景，并完成 32/32 真实 DOM 解码验收。

完成信号：32 个精选节点全部加载正式图；桌面与竖屏不依赖 CSS fallback。

P1-A Day 355 结果反馈验收

目标：验证三种来年方针和短人情账在桌面、竖屏的真实表现。

完成信号：六条视觉路径通过，内部 flag 不可见，原有数值和物件反馈不丢。

P1-B Year 1 effect manifest 收束

目标：从 live 162 个选项重新生成效果盘点，把“明确零后果”和“缺少批准效果”分开。

完成信号：每个待处理项都有 keep_zero / approved_effect / blocked_on_owner 三选一结论；只实现已批准项。

P1-C 全年关键路径 smoke

目标：用正常 GameApp 覆盖六阶段锚点、pending 恢复、切槽和跨年结算。

完成信号：至少一条从新档进入 Year 1、跨六阶段并完成 Day 360 的可复现实验记录；加速或测试存档必须标明，不伪装自然 360 天游玩。

P2-A 年度故事账判断

目标：先用现有终局页做玩家理解测试，再决定是否需要最小年度故事账。

完成信号：有明确的“无需新增”或“最小字段与页面位置”结论；未拍板前不写代码。

5. 每轮打磨的最小模板

后续每次继续打磨 Year 1，只选择一个玩家问题：

目标：玩家当前看不懂、做不到或无法恢复的一个问题
当前真值：live code、测试、资产和浏览器证据分别是什么
缺口：哪一个结果仍无法被证明
最小改动：限定一个模块和明确文件围栏
验收：正例、反例、刷新/重复、桌面/竖屏、工程门
非目标：本轮明确不扩的系统、内容和数据
回退：能独立撤回的最小单位

如果某项不能直接改善目标、不能保持 Year 1 边界，或不能在当前仓库中验证，就不进入本轮。

6. 明确不做

不新增 Year 2 月份、事件池或来年方针消费逻辑。
不扩大 76 个 canonical 事件和 32 个精选节点的数量。
不新建第二套事件引擎、popup、choice handler 或终局系统。
不为了复盘新增存档 schema、独立 localStorage key 或开发者字段 UI。
不重做现有角色外观，不把角色图作为新场景生成输入。
不把全年音频、联机、装备扩容、匿名统计或 App/controller 重构并入 Year 1 收口。
不把录制模式当正常 GameApp 终局顺序证据。
不把文件存在、测试通过、本地构建或任务卡完成互相等同。

7. 关联真值入口

剧情与触发合同：docs/design/active/第一年剧情对白玩法与触发规则-v1.md
年度对白总纲：docs/story/第一年主线剧情对白总纲-v1.md
年度计划快照：src/data/year1Plan.ts
canonical 事件表：src/data/eventTables/storyline-year1.ts
Year 1 进度：src/data/storyEvents/year1Progress.ts
精选演出：src/data/storyEvents/year1Showcase/
结果派生：src/utils/storyEvents/year1ShowcaseLogic.ts
对白与恢复逻辑：src/utils/storyEvents/year1DialogueLogic.ts
Day 360 结果判断：src/utils/endgame/failureOutcome.ts
月 2-10 场景接收：docs/art/2026-07-27-year1-month02-10-scene-intake-v1.md
360 天经营模拟：docs/economy-sim/2026-07-24-year1-360day-balance-report-v1.md
玩家故事：docs/design/active/玩家故事UseCase集-v1.md

8. Owner 审阅点

只需拍板以下三件事：

是否同意“先验收收口、暂不扩 Year 1 内容数量”的总方向。
39 个历史待定 effect 项是逐项补效果，还是允许部分明确保持零数值、只给叙事反馈。
是否先用现有终局页验收玩家理解，再决定要不要做最小“元年故事账”。

建议默认答案：同意先收口；effect 逐项批准且允许合理零后果；故事账暂不开发，先验证现有终局信息是否足够。