@nathan33/nao-skill 0.21.0 → 0.21.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -22,6 +22,9 @@ description: 发版说明写作规范（面向用户、说人话；写 / 验收
|
|
|
22
22
|
4. **口径与落盘一致**：`docs/releases/<version>.md` 是权威落盘；`gh release create --notes-file <该文件>` 与之一同源，禁止两处各写各的。
|
|
23
23
|
5. **Release 标题 = 裸版本号 `vX.Y.Z`**（仅版本号，可带预发布后缀如 `-beta.1`；不得含描述性文本 / `—`、`·`、`：` 副题 / 编号 / 日期）。
|
|
24
24
|
- 标题**不用构思**：一句话概括等描述性内容**一律置于正文首段「本次更新」**（见 §二.1）；`--title` 只写 `<tag>` 本身。
|
|
25
|
+
6. **状态行禁止在 npm 核验前写「已核验」。** 发布说明顶部「状态」行只能写「**待核验**」；顺序固定 = 先「待核验」→ 发布后按**唯一判据**核验（`dist-tags.latest` = 该版本 + `dist.integrity` 与本地 `npm pack` tarball **逐字节一致**）→ 再回填实测值（`latest` + integrity 全文 + tarball 字节数）。
|
|
26
|
+
- 理由：未核验就写「已核验」在写下那一刻即**假陈述**（v0.20.4 实测：QA 复核时 registry 仍是 0.20.3）。
|
|
27
|
+
- 与 §一.2 不冲突：**状态行属元数据行，不受「内部信息下沉技术细节」禁令约束** —— `dist.integrity` 全文 + tarball 字节数必须在该行置顶可见，不得下沉。
|
|
25
28
|
|
|
26
29
|
## 二、建议结构（顺序固定，用不上的段可省）
|
|
27
30
|
|
|
@@ -32,6 +35,7 @@ description: 发版说明写作规范（面向用户、说人话；写 / 验收
|
|
|
32
35
|
5. **📦 更小更快** —— 体积 / 性能 / 启动等可感知收益。
|
|
33
36
|
6. **技术细节（可略过）** —— 编号 / 哈希 / 依赖版本 / 门禁数字 / 文档链接。
|
|
34
37
|
|
|
38
|
+
- **状态行（骨架：标题下第一行）**：`- 状态：已发布（…）· 更新：YYYY-MM-DD · Owner：<角色>`；npm 未核验前**一律写「待核验」**，核验后再回填实测值（`latest` + integrity 全文 + tarball 字节数），口径见 §一.6。
|
|
35
39
|
- **已知问题出口**：会影响用户 ⇒ 写入「⚠️ 请留意」；否则下沉「技术细节（可略过）」。
|
|
36
40
|
- **纯内部仓**（无面向用户交付）可省略第 2–5 段的「面向用户」写法，但**结构保留**（仍按「概括 → 变化 → 技术细节」分层）。
|
|
37
41
|
- **排版**：本文件与其他文档同受 @.agents/checklists/deliverable-docs.md 「默认不使用表格」约束 —— release notes 正文尤其不要用表格。
|
|
@@ -46,17 +50,19 @@ description: 发版说明写作规范（面向用户、说人话；写 / 验收
|
|
|
46
50
|
## 四、发布前核对
|
|
47
51
|
|
|
48
52
|
- [ ] 正文最前有面向用户的**「本次更新」**段（用户看得懂）。
|
|
49
|
-
- [ ] 正文**无**编号 / 哈希 / 文件名 / 函数名 / 内部属性名 / 测试例数 / 守卫名 /
|
|
53
|
+
- [ ] 正文**无**编号 / 哈希 / 文件名 / 函数名 / 内部属性名 / 测试例数 / 守卫名 / 内部模块名（状态行除外，见 §一.6）。
|
|
50
54
|
- [ ] 行为变更写了**用户视角的后果**（不是内部机制）。
|
|
51
55
|
- [ ] 结构完整（一句话 → 变化 → 技术细节）；内部信息集中在「技术细节」段。
|
|
52
56
|
- [ ] 正文**未使用表格**（改用有序 / 无序列表；见 @.agents/checklists/deliverable-docs.md）。
|
|
53
57
|
- [ ] `docs/releases/<version>.md` 与 GitHub Release 正文同源。
|
|
54
58
|
- [ ] Release 标题是**裸 `vX.Y.Z`**（无描述性文本 / 副题；见 §一.5）。
|
|
59
|
+
- [ ] 状态行是「**待核验**」而非「已核验」（npm 未核验前；核验后已回填实测值 —— 口径见 §一.6）。
|
|
55
60
|
|
|
56
61
|
## 五、红线
|
|
57
62
|
|
|
58
63
|
- [ ] 只写内部机制、用户看不懂？
|
|
59
|
-
- [ ] 正文里直接出现编号 / 哈希 / 类名 / 属性名 /
|
|
64
|
+
- [ ] 正文里直接出现编号 / 哈希 / 类名 / 属性名 / 测试例数（状态行除外，见 §一.6）？
|
|
60
65
|
- [ ] 没有面向用户的「本次更新」段，或它不在最前？
|
|
61
66
|
- [ ] 盘上 release notes 与 Release 正文两处不一致？
|
|
62
67
|
- [ ] Release 标题带了描述性文本 / 分隔副题（应为裸 `vX.Y.Z`）？
|
|
68
|
+
- [ ] **发布说明状态行在 npm 核验前写「已核验」**（即视为违规；依据 v0.20.4 假陈述 · QA P1，口径见 §一.6）？
|
|
@@ -1654,10 +1654,10 @@ cmd_status() {
|
|
|
1654
1654
|
while IFS= read -r rl; do [[ -n "$rl" ]] && roots_blob+="$rl"$'\n'; done < <(repo_anchor_roots)
|
|
1655
1655
|
local -A pane_cwds=() roster_cwds=()
|
|
1656
1656
|
local pn pname pcwd rn rcwd prev
|
|
1657
|
-
#
|
|
1658
|
-
#
|
|
1659
|
-
#
|
|
1660
|
-
while IFS=$'\t' read -r pn
|
|
1657
|
+
# M20261101：pane_cwd_snapshot 字段序 = `会话名<TAB>pane_id<TAB>cwd` ⇒ 必须按**会话名**建键
|
|
1658
|
+
# （与下面 pane_cwds["$dname"] 的查询口径一致）。此前误读成 `pane_id<TAB>…`，键成了 pane_id
|
|
1659
|
+
# ⇒ 查询恒空、「pane cwd 优先」层从未生效。同名多 pane（分屏）仍拼接多行后再判定（BR5）。
|
|
1660
|
+
while IFS=$'\t' read -r pname pn pcwd; do
|
|
1661
1661
|
[[ -n "$pname" ]] || continue
|
|
1662
1662
|
prev="${pane_cwds[$pname]:-}"
|
|
1663
1663
|
pane_cwds["$pname"]="$prev$pcwd"$'\n'
|
|
@@ -69,6 +69,7 @@ PM 在**立项 / 终签 / 发布**时读取；RD 在**起分支 / 开 PR / 合
|
|
|
69
69
|
- 门禁：AC 全过 + 验收闭环 + main 门禁全绿 + 工作区干净 + PR 已合并。
|
|
70
70
|
- **发布前置（严格闸门 · 双环境）**：若仓库提供 `test:t4:full:dual` 脚本，发布前须先 `npm run test:t4:full:dual` **rc=0**（**两组**= `$TMUX_PANE` 已设 / `env -u TMUX_PANE`；判据 = **两组 SKIP 计数与 DEGRADE 计数均为 0，且非白名单 NOTE 计数为 0**，`SKIP`/`DEGRADE`/非白名单 `NOTE` 即 FAIL）。仅有 `test:t4:full`（单环境）的仓库退用 `npm run test:t4:full` rc=0；双环境 gate 误红时可临时回落单环境并记台账。
|
|
71
71
|
- **优先 `gh`**：`gh release create <tag> --title "vX.Y.Z" --notes-file docs/releases/<version>.md`（**标题口径（强约束）：@.agents/common/release-notes.md** —— 标题仅裸版本号，描述进正文首段）。
|
|
72
|
+
- **`gh release create <tag> --target <短 sha>` 不可用（两次实测：v0.21.0 / v0.21.1）**：会报 `tag_name is not a valid tag` / `target_commitish is invalid`。正确路径 = 先 `git tag -a <tag> -m "<说明>"` → `git push origin <tag>` → `gh release create <tag> --title <裸版本号> --notes-file <file> --verify-tag`（**不要**用 `--target` 指向未 push 的短 sha）。
|
|
72
73
|
- 探测：`gh auth status` 按 **exit code** 判定（`keyring` 警告但 exit 0 **仍可用**，可 `gh api user` 复核）；**不自动 `gh auth login`**（涉用户凭证）。
|
|
73
74
|
- release notes 落盘 `docs/releases/<version>.md`（**写作规范（强约束）：@.agents/common/release-notes.md** —— 面向用户「本次更新」置顶、内部编号 / 文件名 / 属性名一律下沉「技术细节」、正文不用表格；骨架见 @.agents/templates/release-notes.md.example）。
|
|
74
75
|
- 回滚：未 push → `git tag -d`；已 push → **不删远端 tag**，改发下一个 PATCH 修正（用户明确要求才删）。
|