给 AI 协作项目的开发流程地基：npx bosscoding init 一条命令装好规则文件、8 项守卫、CI 质检口、决策档案与技能，任何 coding agent 通吃。纯 Node ESM，运行时零第三方依赖。
包 https://www.npmjs.com/package/bosscoding ｜ 仓库 https://github.com/KKKKhazix/BossCoding （公开，MIT）
线上是哪个版本跑 npm view bosscoding version 看——版本号是会变的状态，不写死在本文件里。
本文件是唯一的规则真身；CLAUDE.md 只是指过来的门牌，改规则只改本文件。
机器守卫：npm run preflight（单测＋node bin/bosscoding.mjs check）。
老板是产品经理，不是程序员。所有解释按下面写——这是硬规则，不许省略、不许「这次简单就从简」：
- 术语零假设：任何老板可能没听过的词，第一次出现就必须解释，哪怕之前的对话里解释过。
- 解释复杂方案先立一个贯穿全文的比喻，所有术语落进同一个比喻，中途不换。
- 每个方案必答四问：改什么 → 为什么现在这样是错的 → 改完什么效果 → 有什么风险。
- 数字换算成老板能判断的单位；汇报顺序：影响 → 结论与行动 → 需要老板决定的 → 技术细节。
- 结尾收敛成一个问题，明确写清「你只需要回哪一句」。
- 不贴大段代码、日志、堆栈；不用没展开过的英文缩写。
- 一个任务一个 PR，默认 Draft；push 前跑
npm run preflight；禁止直推 main。 - 转 Ready 前确认没有别的 PR 在排队——并行干活，串行合并。
- CI 红了默认响应是撤销或修复，不是加新检查。
- 发版本：改
package.json版本号走 PR 合并，老板确认后gh workflow run publish.yml触发。走可信发布，不用令牌也不用验证码；本机npm publish只是应急退路。 - 合并不等于已发布：版本号进了 main 而没人触发 publish，npm 上就一直是旧版。发包是红线不能自动，所以改版本号的 PR 正文必须写明谁来触发；
npm view bosscoding version是唯一真实状态。
| 想知道什么 | 去哪 |
|---|---|
| 机器允不允许这么写 | node bin/bosscoding.mjs check 与 node --test——规则真身是守卫和测试 |
| 当初为什么这么定 | docs/decisions/——只追加、不修改 |
| 现在实际什么状态 | 跑命令看真实输出，不要读文档猜 |
写作纪律：想往本文件加规则，先问三遍——能写成守卫吗？是一条裁决吗？是跑命令能看到的吗？三个都不是就别写。
- 发包（触发 publish workflow 或本机
npm publish）、仓库转公开、以老板名义对外发布任何内容——这三件是本项目的「上线」，一律先确认。 - 任何花钱的操作；动权限、密钥、账号设置。
- 密钥、token 永不进代码，只放
.env（守卫盯着）。 - 违反后伤到谁：框架的用户是拿它当地基的小白，一次坏发布会同时伤到所有装了它的项目——发布纪律比功能进度重要。
- 运行时零第三方依赖：筹备队必须在任意网络环境一条命令跑通，依赖树越深失败面越大。
npx boss update与任何更新机制永不改写用户的 AGENTS.md／CLAUDE.md——规则是老板的规则。- 新增守卫的前提：挂着一次真实事故，且误报经实测收敛。误报多的守卫会被用户关掉，比没有更糟。
- 模板与文案改动同样走 PR 与守卫；本仓库必须永远能被自己的
boss check检查通过（吃自己的狗粮）。