docs: AGENTS.md 执行约定 + 补全 ROADMAP 的结构性缺口
补三处规划漏洞（自查发现，非用户指出） 1) 缺「执行模型自动能读到的约束」 - 新建 AGENTS.md（216 行）：其他模型不会主动翻 ROADMAP，但大多会自动读 AGENTS.md。把它做成硬约束入口 - 含六条铁律（零依赖/ASCII-only/改模板/改内嵌层/data.json 是承诺/八次回归） - 含禁止事项表（6 条）、交付说明模板、失败升级路径、关键文件地图、 已知陷阱速查（7 条）、当前状态 - 验证过文档里承诺的命令真能跑：铁律 1 的验收命令在 package.json 不存在时 输出 "n/a" 而非报错（原写法会失败） 2) 缺「显式不做」清单 - 新增第四章：8 项不做什么及理由（不引打包器/不做全量像素回归/不做 SSR/ 不做主题商店/不重写 app.js/不改 frameworks 视觉/不做 Storybook/不做单测） - 没有这份清单，执行模型会以为"漏了"，或在不当时机自作主张 3) 缺「未解问题」 - 新增第五章：6 个我无法单方面决策的问题（是否发布 npm/目标用户/设计团队 协作/RTL 必要性/性能预算底线/暗色 iframe 策略），每项附影响面与建议 修正验收命令的 3 处踩坑（自查发现） - P2 的 npm pack 校验：原写法 `npm pack | grep -q site/ && echo FAIL || echo OK` 在 npm 不可用时 grep 也失败 → 误报 OK。改为显式判断 exit code - P4 的 sources 文件计数：目录不存在时错误信息不友好 → 加提示与 exit 1 - 铁律 1 的依赖检查：package.json 不存在时报错 → 改为可容错 章节编号顺延（原「五、验收总纲」→「七」，因新增两章） 回归：100%（961 断言 / 0 失败 / 79 页全通过）
This commit is contained in:
aurora-admin
+119
-9
@@ -9,13 +9,77 @@
|
||||
|
||||
## 〇 · 交接约定（执行模型必读）
|
||||
|
||||
1. **零依赖约束不可破**：不引入 npm 运行时依赖。构建/测试脚本用 Node 内置能力或 PowerShell。
|
||||
### 0.1 铁律（违反即返工）
|
||||
|
||||
1. **零运行时依赖不可破**：不引入 npm 运行时依赖。构建/测试脚本用 Node 内置能力或 PowerShell。`package.json` 的 `dependencies` 必须为空（`devDependencies` 可用）。
|
||||
2. **`build-site.ps1` 必须 ASCII-only**：PS5.1 按 ANSI 读无 BOM 文件，脚本里出现非 ASCII 字面量会被损坏。中文文案放 UTF-8 模板。
|
||||
3. **改结构要改模板**：`tests/<slug>.html` 是生成物，改它没用 —— 改 `tests/_template.html` 后重跑 `run-tests.ps1`。
|
||||
4. **改样式要改内嵌层**：演示页的**内嵌 `<style>`** 才是实际生效的样式（见 v1.4.0 教训）。只改 `frameworks/*.css` 可能不生效。
|
||||
5. **验收以实测为准**：跑本文件给出的命令，把输出贴进交付说明。不要写"已完成"而不给证据。
|
||||
3. **改结构要改模板**：`tests/<slug>.html` 是生成物 —— 改它没用。改 `tests/_template.html` / `tests/_index_template.html` 后重跑 `run-tests.ps1`。
|
||||
4. **改样式要改内嵌层**：演示页的**内嵌 `<style>`** 才是实际生效的样式（v1.4.0 教训：只改 `frameworks/*.css` 可能不生效，因为演示页不一定 link 它）。
|
||||
5. **`data.json` 是 For Agents 的对外承诺**：可以拆 `data.js`，但 `data.json` 必须保持完整（一次请求拿到全部）。破坏它是 breaking change。
|
||||
6. **单次改动后必须跑回归**：`tests/_collect.html` 八次连跑，`100% / 0 失败 / 0 超时` 才算过。
|
||||
|
||||
### 0.2 禁止事项（做过即需回滚）
|
||||
|
||||
| 禁止 | 原因 | 正确做法 |
|
||||
|---|---|---|
|
||||
| 在 `frameworks/` 里直接手工改出"更好看"的样式 | `frameworks/` 是规范原文的忠实实现，改动会破坏契约一致性 | 要改样式先改令牌，或走任务包流程 |
|
||||
| 用 `git reset --hard` / `git checkout .` 清理 | 会丢用户改动 | 用 `git stash` 或定向还原 |
|
||||
| 删除或改写 `CHANGELOG.md` 的历史条目 | 那是变更事实记录 | 只追加 `[Unreleased]` 或新版本段 |
|
||||
| 修改 `tests/report.json` 的数值来"通过"验收 | 报告是生成物，改它等于伪造证据 | 修实际问题后重跑生成 |
|
||||
| 为了通过验收而放宽断言判据 | v1.3.1 曾出现"调松断言刷分"的诱惑 | 断言判据的修正必须附**理由 + 反例** |
|
||||
| 在规划未涉及的领域顺手重构 | 范围蔓延会让验收失焦 | 写成新任务包追加到本文件 |
|
||||
|
||||
### 0.3 环境与工具
|
||||
|
||||
| 项 | 说明 |
|
||||
|---|---|
|
||||
| 操作系统 | Windows（开发）/ Linux（CI）。跨平台写法见下方「跨平台注意」 |
|
||||
| Shell | Git Bash（开发）/ bash（CI） |
|
||||
| Node | ≥ 18（用到 `node:sqlite` 的任务需 ≥ 22） |
|
||||
| 构建 | `powershell -NoProfile -ExecutionPolicy Bypass -File build-site.ps1`（**Windows 专用**） |
|
||||
| 回归 | 浏览器打开 `tests/_collect.html`，或 `node tools/run-regression.mjs`（需 playwright） |
|
||||
| 本地服务 | `node site/dev-server.js`（端口 3311） |
|
||||
|
||||
**跨平台注意**：
|
||||
- 后台启动服务：Windows Git Bash 用 `node site/dev-server.js &`，CI 用 `node site/dev-server.js & sleep 3`。**不要用 `start` 或 `nohup`**。
|
||||
- 路径分隔符：脚本里统一用 POSIX 风格（`/`），Node 的 `path` 模块会处理。
|
||||
- PowerShell 脚本**只能在 Windows 跑**。若 CI 需要构建，改写为 Node 脚本或加 `runs-on: windows-latest`。
|
||||
|
||||
### 0.4 失败升级路径
|
||||
|
||||
执行中遇到阻塞时，按这个顺序处理，**不要停下来等**：
|
||||
|
||||
| 情况 | 处理 |
|
||||
|---|---|
|
||||
| 验收命令本身有错（路径不对、语法不兼容） | 修正命令使其能真实反映目标，**在交付说明里写明修正了什么、为什么** |
|
||||
| 目标不可达（如依赖的服务/网络不可用） | 交付最强替代物 + 写明缺什么。例：无法 `npm pack` 则做本地 `npm pack --dry-run` 的等价检查 |
|
||||
| 发现规划有事实错误（如"某字段占 89%"实际不是） | **以实测为准**，修正规划并在本文件标注「⚠️ 规划修正」 |
|
||||
| 发现规划未覆盖的新缺口 | 写成新任务包追加到本文件，**不在原任务里顺手修** |
|
||||
| 连续两次尝试同一路径都失败 | 换策略而非重试。在交付说明里记录两次失败的原因 |
|
||||
|
||||
### 0.5 交付说明模板（每个任务包完成时提交）
|
||||
|
||||
```markdown
|
||||
## <任务 ID> 完成说明
|
||||
|
||||
**验收输出**（原样粘贴命令输出，不要转述）：
|
||||
```
|
||||
<命令>
|
||||
<输出>
|
||||
```
|
||||
|
||||
**改动文件**：
|
||||
- <路径> — <做了什么>
|
||||
|
||||
**规划偏差**（若有）：
|
||||
- <规划里写的> → <实际的>，原因：<...>
|
||||
|
||||
**发现的新问题**（若有）：
|
||||
- <描述> → 已追加为任务包 <ID>
|
||||
|
||||
**回归**：100%（<总断言>/<通过>）/ 八次连跑一致 / 0 超时
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 一 · 现状基线（全部为实测数据）
|
||||
@@ -206,7 +270,15 @@ test $(ls dist/components/*.css | wc -l) -ge 80 && echo "79 components + index O
|
||||
node -e "const p=require('./package.json'); if(p.dependencies) { console.error('FAIL: 不允许 dependencies'); process.exit(1) } console.log('zero-dep OK')"
|
||||
|
||||
# 3) 分发内容不含开发资产
|
||||
npm pack --dry-run 2>&1 | grep -q "site/" && echo "FAIL: 打包含 site/" || echo "pack contents OK"
|
||||
# 注意：不能用 `npm pack | grep -q site/ && echo FAIL || echo OK` —— npm 不可用时 grep 也失败，会误报 OK
|
||||
if npm pack --dry-run >/tmp/pack.txt 2>&1; then
|
||||
if grep -qE "site/|tests/" /tmp/pack.txt; then
|
||||
echo "FAIL: 打包含开发资产"; grep -E "site/|tests/" /tmp/pack.txt | head -3; exit 1
|
||||
fi
|
||||
echo "pack contents OK"
|
||||
else
|
||||
echo "SKIP: npm 不可用（网络/未安装），此项需在有 npm 的环境补验"
|
||||
fi
|
||||
|
||||
# 4) 产物可用（起本地服务，浏览器打开验证）
|
||||
node -e "const fs=require('fs');const c=fs.readFileSync('dist/components/index.css','utf8');if(!c.includes('--au-color-brand'))process.exit(1);console.log('css usable OK')"
|
||||
@@ -353,9 +425,15 @@ console.log('budget OK');
|
||||
"
|
||||
|
||||
# 2) 源码文件已分离（395 个）
|
||||
# 注意：目录未创建时 ls 会报错到 stderr，这里显式兜底，让输出可读
|
||||
n=$(ls site/sources/*/*.txt 2>/dev/null | wc -l)
|
||||
echo "sources files: $n"
|
||||
test "$n" -eq 395 && echo "split OK"
|
||||
echo "sources files: $n (期望 395)"
|
||||
if [ "$n" -ne 395 ]; then
|
||||
echo "FAIL: 期望 395 个源码文件，实际 $n"
|
||||
echo " 提示：若目录不存在，说明 build-site.ps1 的分离逻辑未执行"
|
||||
exit 1
|
||||
fi
|
||||
echo "split OK"
|
||||
|
||||
# 3) data.json 未缩水（For Agents 承诺不变 —— 硬约束）
|
||||
node -e "
|
||||
@@ -780,7 +858,39 @@ figma export OK
|
||||
|
||||
---
|
||||
|
||||
## 四 · 风险登记
|
||||
## 四 · 显式不做（及理由）
|
||||
|
||||
> 这份清单同样重要 —— 没有它，执行模型会以为"漏了"，或者在错误的时机自作主张。
|
||||
|
||||
| 不做 | 理由 | 什么条件下应该做 |
|
||||
|---|---|---|
|
||||
| **不引入打包器**（Vite / Rollup / esbuild） | 破除零依赖约束的代价远大于收益；本项目的卖点就是"打开 HTML 就能用" | 若未来要发布 ESM/CJS 模块化包，先评估是否需要独立仓库 |
|
||||
| **不做像素级视觉回归**（全量） | 79 组件 × 5 端 = 395 张基准图，维护成本极高且易误报（抗锯齿/字体渲染差异） | P6 已包含「6 个核心组件抽样像素比对」，够用 |
|
||||
| **不做 SSR / SSG** | 文档站是纯静态 SPA，爬虫需求已由 `site/components/*.html` 薄壳 + sitemap 解决 | 若 SEO 成为核心指标，再评估 |
|
||||
| **不做多主题商店**（Ant Design 式） | 已有 6 套预设 + 令牌导出，改色能力已足够；主题商店是运营功能非工程功能 | 产品化阶段（S4 之后） |
|
||||
| **不重写 `app.js`** | 2064 行单文件虽不理想，但功能正确、回归 100%。重构风险 > 收益 | 若某任务包因它受阻（如 P4 代码拆分），**局部**改造而非重写 |
|
||||
| **不改 `frameworks/` 的视觉** | 那是规范原文的忠实实现，改了会破坏契约一致性 | 只有规格原文变更时才同步 |
|
||||
| **不做 Storybook 集成** | 与零依赖冲突，且 Playground（v1.2.0）已覆盖在线试玩需求 | 不考虑 |
|
||||
| **不做 React/Vue 单元测试**（Jest/Vitest） | 与零依赖冲突；跨端一致性靠 P6 的静态比对 + 抽样渲染 | 若组件逻辑复杂化到静态分析无法覆盖 |
|
||||
|
||||
---
|
||||
|
||||
## 五 · 未解问题（需用户或后续规划决策）
|
||||
|
||||
> 这些问题我作为规划师**无法单方面决定**，列出供决策。
|
||||
|
||||
| # | 问题 | 影响面 | 我的建议 |
|
||||
|---|---|---|---|
|
||||
| Q1 | **是否发布到 npm？** 涉及包名占用、发布权、后续维护承诺 | S1-P2 | 建议发。当前无分发渠道是最大阻塞，且 npm 上同名包大概率未被占用 |
|
||||
| Q2 | **目标用户是谁？** 内部团队 / 开源社区 / 商业化产品，三者的优先级与验收标准不同 | 全局 | 建议先按「内部团队 + 开源复用」定位（对应 S1-S2 的优先级） |
|
||||
| Q3 | **是否有设计团队协作？** 若没有，S4-P10 的 Figma 产出无人使用 | S4-P10 | 建议推迟到有设计资源时再做，或降级为「Figma Variables JSON 导出」只做工程侧 |
|
||||
| Q4 | **是否需要 RTL？** 取决于是否有中东/希伯来语市场 | S3-P8 | 若无明确市场，降级为 P2 或推迟。迁移成本高（22 个文件） |
|
||||
| Q5 | **性能预算的底线是多少？** 我定的 300KB 是经验值 | S1-P4b | 建议以「3G 网络首屏可交互 < 3s」反推预算 |
|
||||
| Q6 | **暗色模式下演示 iframe 是否反色？** 两种都有道理 | S2-P5 | 建议反色（用户开暗色就是要整体变暗），但需人工验收视觉 |
|
||||
|
||||
---
|
||||
|
||||
## 六 · 风险登记
|
||||
|
||||
| 风险 | 影响 | 缓解 |
|
||||
|---|---|---|
|
||||
@@ -793,7 +903,7 @@ figma export OK
|
||||
|
||||
---
|
||||
|
||||
## 五 · 验收总纲
|
||||
## 七 · 验收总纲
|
||||
|
||||
任一任务包完成，必须同时满足：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user