协作规则

英文版本 为准，本文供参考；遵循用户最新明确任务范围。

授权与 worktree

• 仅在用户授权范围内工作；Fieldnotes 个人站、独立日志站、测试和 CI/CD 配置已获授权；用户另已授权本地集成至 main 并提交，仍须经过提交前确认。远端发布须另行授权。
• 需求不清、冲突或需要用户决策时，暂停依赖该决定的工作并询问；沉默不等于批准。
• 用户要求在本地 main 首次提交仅文档基线，仍须通过下述提交检查点；不推送。
• 此后每个 PR/变更（包括文档）都从最新 main 在独立同级 ../<feature-name> worktree 使用独立分支；主 main/ 仅用于集成/检查。
• 禁止直推 main，必需检查通过后经 PR 合并，流水线实现后自动部署；CI/CD 已在源码配置，远程强制规则和生产启用仍待完成。

审查选择与质量

• 每个新功能/独立变更编写需求或实现之前，询问需求、计划、执行、验收四轮中哪些要做。用户已明确本任务选择时无需重复询问，记录一次即可；不擅自设默认值，也不把本次省略沿用到下次。只读调研可先进行。
• 保持需求 → 计划 → 执行 → 验收顺序；只运行用户选中的独立子 Agent 关卡，并在跨过对应关卡前完成。省略的关卡记为用户豁免，不能记为通过。
• 每次选中的审查都要检查正确性，并从第一性原理质疑复杂度：每一部分由什么需求要求、是否有足够简单的替代、能否复用已有机制、维护成本是否值得；按任务检查测试价值、文档价值和隐私。
• 解决阻断并在已选择的审查中核实修复后再前进，除非用户明确改变该关卡。审查者必须独立于作者；审查通过不授权未要求的工作或提交。

依赖与工具版本

• 引入或升级直接依赖及构建/部署工具时，从官方 registry 或发布页面核实最新稳定版，排除 alpha、beta、RC 和 canary。在变更日志记录选定版本、核实日期及来源链接；兼容性要求使用旧版时询问用户，不擅自降级。
• 所有直接依赖（含开发/可选依赖）及实际使用的 Node.js、pnpm、Hugo、Go、Wrangler 等工具都固定精确版本。禁用版本范围（^、~、*、不等式）及 latest 等浮动标签；Git 依赖与 CI Actions 固定到选定稳定版对应的完整 commit SHA，并注明发布版本。
• 提交生成的锁文件以固定传递依赖解析，不脱离上游兼容约束强制把每个传递依赖独立升至最新版。pnpm 保存精确依赖，CI 使用 pnpm install --frozen-lockfile；版本在明确的升级 PR 之间保持固定。
• 当前固定版本及用户批准的 TypeScript 兼容例外记录于变更 0003；未来每次依赖升级重新核实官方发布。

文档与公开信息

• 网站界面/内容、README、长期开发文档、PR log 均英文为主、简体中文参考；临时本地验收手册按下文仅写中文。提交信息只用英文。
• 每项变更在 logs/changes/<id>/ 只保留 index.md / index.zh.md 一对文章，选中的审查紧邻相应阶段。合并前迭代沿用该记录，后续 PR 新建关联记录，有真实 PR 后关联信息。
• 日志保留有效需求、重要技术选择及被拒备选、实质问题和可复现验收证据。省略提示词回顾、道歉、Agent 误解/纠正、文书性审查反复及重复进度叙述；影响交付结果的缺陷或限制不能隐去。
• 复用指南放 docs/，仅为必要支撑材料添加 evidence/，不归档已丢弃的过程噪声。使用真实版本及准确审查范围，不将通过结论沿用到已改内容，不虚构测试/批准。普通变更不强制阶段分文件、manifest 或全仓库摘要机制。
• 文件链接和路径（含日志/附件）使用仓库相对路径，外部公开来源可用 HTTPS。不得公开个人隐私、本地绝对路径、凭据、私有服务地址或原始会话；发布前最小化/脱敏证据，并准确标明脱敏副本，不在公开归档保留敏感原文。
• 执行与变更相称的检查；应用变更需要有效测试；使用文档所列验证命令，并区分本地结果与外部部署检查。

验收手册与迁移

• 每次变更（包括仅文档工作）交付前都必须在功能 worktree 的 .local/acceptance/<change-id>.md 编写或更新仅中文的开发者验收手册；豁免审查不能省略。目录加入 gitignore，不提交（也不 force-add）、不发布，并保持在 Hugo mount 之外。最终交接附本地文件链接，公开 Markdown 不链接该文件。
• 按顺序提供可复现步骤：起始版本与前提；环境/依赖/配置设置；适用的服务启动/停止命令和 URL；手动检查及自动命令，并逐项写明预期结果。实际结果与未验证项分开记录。按变更规模编写，不适用的步骤须说明原因。
• 明确评估相对上一基线的迁移：依赖、配置、内容/数据、路由及部署受哪些影响。需要迁移时，写明有序命令/操作、备份要求、迁移后检查及回滚/恢复步骤，包括不可逆限制；不需要时明确写“无需迁移”及原因。迁移决策未明确或涉及破坏性操作时先询问。
• 每次的详细操作写入本地手册；简明实际结果、关键验证命令、重要迁移决策及长期必需的升级/回滚操作，保留在现有公开 EN/ZH 日志或相应长期指南。通用环境设置放 docs/development.md，不把临时清单复制进公开文档。本地手册不随 Git 同步，删除 worktree 前完成验收或另行保存；选中的验收审查检查可复现性及上述存放边界。

提交检查点

• 使用英文 Conventional Commit：type(scope): imperative subject（scope 可省略），按内容选 docs、feat、fix、test、ci、chore 等类型。
• 多项实质改动必须有英文 bullet-point 正文。
• 每次提交前检查暂存差异、展示准确路径和完整信息，等待用户确认；内容或信息改变后重新预览，只提交已确认内容，远程操作另需相应授权。