.spec

Imported from zhuanggenhua/BoardGame (.spec/AGENTS.md). Install upstream with npx skills add zhuanggenhua/BoardGame --skill .spec. Copyright stays with the author.

BoardGame — 中心文档

BoardGame 是多桌游 Web / 移动平台。.spec/ 是 AI 规范唯一真相源；产品规格、提案和产品任务归 openspec/。

知识导航（knowledge/README.md）与硬红线（rules/system.md）是本规范核心：Claude Code 由 CLAUDE.md 强制载入；其它宿主读完本文件后继续读取这两份。沉淀或同步能力用 spec-steward。

项目是什么

• 前端：React / TypeScript / Vite，多游戏运行时。
• 后端：Node 服务、在线房间、反馈与资源发布链路。
• 业务边界：游戏规则、素材、测试证据和 AI workflow 必须在仓内可回查；外部系统只作为事实来源或发布目标。

规范术语范围

• 在本仓库任务里，用户说“规范 / 更新规范 / 项目规范 / 通用规范 / 全局规范”时，默认指 BoardGame 项目 Agent 知识体系里适用于全项目、多游戏和多人协作的规则；不是 DiceThrone 或其它单游戏专项规范，也不是 Codex 系统层，除非用户明确限定。
• 修改项目规范前必须先用 spec-steward 判断落点：项目入口和共享边界放本文件，跨游戏做法放 knowledge/standards/，项目 workflow 放 .spec/skills/，单游戏特例只能放对应专项或任务记录。

调度核心

子 Agent 名册（权威是各 .agent.md）：

• 主 loop 负责理解目标、选择 skill、执行或调度、验证和收口；子 Agent 只执行被派发的审查职责。
• 改代码、配置、规则数据、测试、正式文档或交付前，用 before-you-code 判断读取深度。
• 规则 bug、UI、资源录入、发布、反馈、合并、看图等专项工作，从 knowledge/README.md 找标准，再读对应 skills/<name>/SKILL.md。
• 用户要求接入或排查可选能力、操作日志、撤回、音效等游戏支撑能力时，用 support-capability-integration 作为项目 workflow，再回到底层标准执行；“可选能力 / 可选都接 / 把可选接上”默认是跨游戏支撑能力语义，不是某个单游戏规则分支或当前任务文档待办。
• 任务路由只由本文件和 knowledge/README.md 承担中心职责；workflow / skill 不维护平行规范清单。新增或迁移标准时，默认只登记到 knowledge/README.md；只有具体执行分卷直接消费该标准时，才保留一条指向主源的链接。
• 修改 .spec/ 结构、规则落点、skill、知识文档或文档去噪时，用 spec-steward。

编码约定

• 设计先查规范：新增业务功能、拆职责、选设计模式、审查 SOLID / 反模式 / 防护性架构时，先读 code-design。
• 先锁定本轮问题对象、真相来源、目标入口 / 环境和验收口径；缺证据时继续定位，不直接改。
• 只做当前目标要求的改动，不顺手重构、不新增平行真相源。
• 新功能、修 bug 或改关键逻辑时按项目测试标准留验证证据；纯文档结构调整至少跑 npm run spec:lint。
• 交付说明包含改动清单、验证命令与关键结果、剩余风险，以及是否需要知识沉淀。

宿主差异

框架自身的决策与校验

• 结构决策记录在 decisions/；功能设计记录放 knowledge/features/。
• 结构一致性由 npm run spec:lint 校验；宿主链接必须指向 .spec/agents 或 .spec/skills。
• .spec/tools/spec-lint.mjs 的头部注释是 lint 校验项清单的单一权威。