@haiyangbg/buildbeat 4.2.1 → 4.2.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.
- package/CHANGELOG.md +6 -0
- package/README.en.md +80 -11
- package/README.md +81 -12
- package/docs/CAPABILITY-MATRIX.md +1 -1
- package/docs/RELEASING.md +1 -1
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -2,8 +2,14 @@
|
|
|
2
2
|
|
|
3
3
|
> 本项目吃自己的狗粮(红线④:必更 CHANGELOG)。格式循 Keep a Changelog,倒序。
|
|
4
4
|
|
|
5
|
+
## v4.2.2 — 2026-10-07（补丁：README 重新设计）
|
|
6
|
+
|
|
7
|
+
- README (zh/en) redesigned for reading: a hero picture, the name's meaning (every step is a note the agent plays; the played score stays in Git), a delivery-loop diagram in light and dark with a stacked layout for phones, the three promises as short sections, a real `status` excerpt at the merge decision, and which records travel with Git and which stay on this machine. Pictures live in `docs/assets/readme/` (the loop diagram is drawn by `diagrams.mjs`) and are linked through raw URLs so the npm page shows them too; `check:docs` now requires every README picture to exist, carry alt text and stay under 600 KB.
|
|
8
|
+
|
|
5
9
|
## v4.2.1 — 2026-10-07（补丁：审查没交报告当场停；成本按去向分开等待）
|
|
6
10
|
|
|
11
|
+
> **发布状态**：`@haiyangbg/buildbeat@4.2.1` 已于 2026-10-07 从 `main`（release PR #79，merge commit `8d2625b`，tag `v4.2.1`）经 OIDC Trusted Publishing 发布到 dist-tag **`latest`**（run 37626818833，publish 与 verify 双 job 一次 success；所有者授权「推送并发 4.2.1」）。独立回读（直连 npmjs.org）：`latest` = 4.2.1、`dist.integrity` 与本地用 Node 24 + npm 11.19.0 打的候选逐字一致、注册表 tarball 解压后与候选逐字节相同、SLSA v1 provenance、隔离安装 `--version` = 4.2.1、裸调用零写入、`npm audit signatures` 通过；GitHub Release v4.2.1 标 Latest，仓库 About 同日更新；证据见 [`docs/releases/V4.2.1-RELEASE-EVIDENCE-2026-10-07.md`](docs/releases/V4.2.1-RELEASE-EVIDENCE-2026-10-07.md)。`next` 仍为 4.2.0。
|
|
12
|
+
|
|
7
13
|
- A review step that exits 0 without writing a report to `$BUILDBEAT_OUTPUT` now stops as `invalid-output` (an infrastructure failure: no fixer, no charge, `resume-review` waits for a person) instead of passing with no evidence until the merge approval refused it. The stop reason says where the report belongs and, when the reviewer printed something, how many bytes went to stdout. Found in a replay of real runs, where a reviewer's 3 P1, 6 P2 and 4 P3 findings reached stdout only.
|
|
8
14
|
- The cost line splits human waits by how they ended: `human waits N (decided … · superseded … · stopped … · open …)`, listing only kinds that occurred; a request repeated before any decision continues the same wait, so overlapping time is not counted twice; JSON carries `cost.waits` with `{count, ms}` per kind and run-records keep it. In the same replay one work showed 32 minutes of decided waits while 11 hours passed on a request a new run superseded.
|
|
9
15
|
- README (zh/en) describes the 4.x product: the three promises now name the mechanisms behind them (one `work.md` driven by `buildbeat run` and `status --all-repos`; evidence read back from Git and infrastructure stops instead of code fixes; merge approvals bound to the candidate and repairs at the merge decision), the cost line's waits, taking part without the runtime and the release readback.
|
package/README.en.md
CHANGED
|
@@ -1,18 +1,51 @@
|
|
|
1
|
-
|
|
1
|
+
<p align="center">
|
|
2
|
+
<img src="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/hero.jpg" width="100%" alt="Five notes on a musical staff, build, verify, review, fix and decide, joined by a pulse line that ends in a stack of written sheet music">
|
|
3
|
+
</p>
|
|
2
4
|
|
|
3
|
-
|
|
5
|
+
<h1 align="center">BuildBeat</h1>
|
|
4
6
|
|
|
5
|
-
|
|
7
|
+
<p align="center"><strong>Switch sessions. Keep building.</strong></p>
|
|
8
|
+
|
|
9
|
+
<p align="center">
|
|
10
|
+
<a href="https://www.npmjs.com/package/@haiyangbg/buildbeat"><img alt="npm version" src="https://img.shields.io/npm/v/@haiyangbg/buildbeat?color=d97706&label=npm"></a>
|
|
11
|
+
<a href="https://github.com/HaiYangBG1/BuildBeat/actions/workflows/ci.yml"><img alt="CI status" src="https://github.com/HaiYangBG1/BuildBeat/actions/workflows/ci.yml/badge.svg"></a>
|
|
12
|
+
<a href="LICENSE"><img alt="MIT license" src="https://img.shields.io/badge/license-MIT-e5534b"></a>
|
|
13
|
+
</p>
|
|
14
|
+
|
|
15
|
+
<p align="center"><a href="README.md">中文</a> · English</p>
|
|
16
|
+
|
|
17
|
+
> **Why the name**: every step is a note, and the agent plays them beat by beat; the score it has played (context, decisions and outcomes) stays in Git, ready to read again.
|
|
18
|
+
|
|
19
|
+
BuildBeat is for humans and AI sessions: the work description, decisions and each run's outcome stay in project files and Git; implementation, verification, review and repair move forward outside the session and can always resume; the candidate waits with its evidence for your merge decision.
|
|
20
|
+
|
|
21
|
+
## At a glance
|
|
22
|
+
|
|
23
|
+
<picture>
|
|
24
|
+
<source media="(max-width: 600px) and (prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-en-dark-narrow.png">
|
|
25
|
+
<source media="(max-width: 600px)" srcset="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-en-light-narrow.png">
|
|
26
|
+
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-en-dark.png">
|
|
27
|
+
<img src="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-en-light.png" width="100%" alt="The delivery loop: after work.md come build, verify and review; findings go to fix, verify and review again; then the run stops for you to decide; work.md, decisions, findings and each run's final record stay in Git">
|
|
28
|
+
</picture>
|
|
29
|
+
|
|
30
|
+
Each work gets one `work.md`. Once you accept it, `buildbeat run` moves it forward beat by beat in an isolated worktree: build, run the project's own verification commands, an independent read-only review, and on findings fix, verify and review again. It stops when a person is really needed: the merge decision, an infrastructure failure, an exhausted budget, a review that does not converge. The work description, decisions, review findings and each run's final record go into Git, so a new session, another tool or another person continues from the same record; the live ledger and raw logs stay on this machine (see Records and handoffs below).
|
|
6
31
|
|
|
7
32
|
## Three promises
|
|
8
33
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
34
|
+
### Walk away
|
|
35
|
+
|
|
36
|
+
**Close the session, switch AI tools or hand over, and the work carries on.** The work description and the run ledger live in the project, and `buildbeat run` resumes from them; in a main repository with several code repositories, `buildbeat status --repo . --all-repos` shows what is pending everywhere.
|
|
37
|
+
|
|
38
|
+
### Come back to facts
|
|
39
|
+
|
|
40
|
+
**What you find is evidence, not what an AI says about itself.** Verification runs the project's real commands and the runtime reads results back from Git and the ledger; review is independent and read-only; missing tools, an unavailable backend or a review that hands in no report stop as infrastructure failures instead of being "fixed" as code.
|
|
41
|
+
|
|
42
|
+
### Decide with confidence
|
|
12
43
|
|
|
13
|
-
|
|
44
|
+
**What you approve is the version you reviewed.** A merge approval is bound to the candidate (`--candidate`); a small problem spotted at the merge decision can be fixed and handed over (`run --adopt`) or sent back to the fixer in one line (`decide --action fix`); merge, push, release and deployment stay with people.
|
|
14
45
|
|
|
15
|
-
|
|
46
|
+
## Start in five minutes
|
|
47
|
+
|
|
48
|
+
The runtime needs Node ≥ 20. Before upgrading from 3.x, finish or cancel runs still in progress with their original 3.x runtime (see [Migration](docs/MIGRATION.md)). Read [SKILL.md](SKILL.md) and the [quickstart](docs/v2/guide/01-quickstart.en.md): put the templates in your project, write a `work.md`, and fill in the real AI tool and verification commands in the run config.
|
|
16
49
|
|
|
17
50
|
```bash
|
|
18
51
|
npm view @haiyangbg/buildbeat@latest version
|
|
@@ -26,11 +59,38 @@ buildbeat run --config delivery/work/WORK-X/run-config.yaml
|
|
|
26
59
|
buildbeat status --repo . --work WORK-X
|
|
27
60
|
```
|
|
28
61
|
|
|
62
|
+
## What it looks like
|
|
63
|
+
|
|
64
|
+
The first review round of a work found one problem; the fixer repaired it, verify ran again, the second review passed, and the run now waits for your merge decision. An excerpt of real output (`…` marks omissions):
|
|
65
|
+
|
|
66
|
+
```text
|
|
67
|
+
$ buildbeat status --repo . --work WORK-CSV-EXPORT
|
|
68
|
+
WORK-CSV-EXPORT MERGE_DECISION
|
|
69
|
+
[P1 0b5e258117cb5602] (accept) csv: quote fields that contain commas
|
|
70
|
+
work.md ✓ · runs 1
|
|
71
|
+
cost: review rounds 2 · findings 1 · human waits 1 (open 33s) · worker 2s
|
|
72
|
+
work WORK-CSV-EXPORT:
|
|
73
|
+
RUN-CSV-EXPORT-01 [final-decision] enter-wait-merge — waiting 33s
|
|
74
|
+
candidate: ede20b668cb04ae30cba1676b5e031930e711c8d
|
|
75
|
+
next: buildbeat decide --action approve … --candidate ede20b6… --by <you>
|
|
76
|
+
next: buildbeat decide --action reject … --reason <why> --by <you>
|
|
77
|
+
next: buildbeat run … --adopt <sha> --by <you> # commit a manual repair in the run worktree …
|
|
78
|
+
next: buildbeat decide … --action fix --reason <what to repair> --by <you>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
The cost line shows how many review rounds ran, how many problems were found, how long people waited and where those waits went. The decision card offers four choices: approve (bound to this candidate), reject, hand over your own fix, or send it back to the fixer.
|
|
82
|
+
|
|
29
83
|
## Records and handoffs
|
|
30
84
|
|
|
31
|
-
End-to-end work packages
|
|
85
|
+
End-to-end work packages keep the whole story of a work in the repository:
|
|
86
|
+
|
|
87
|
+
- `delivery/work/<ID>/` **travels with Git**: work.md, run config, decisions, review findings, each run's terminal record (outcome, cost, evidence digests and references)
|
|
88
|
+
- `.buildbeat/runtime/` **stays on this machine**: the run ledger, logs, screenshots and other raw evidence
|
|
89
|
+
- `.buildbeat/worktrees/` **stays on this machine**: the isolated worktrees that hold candidates
|
|
32
90
|
|
|
33
|
-
|
|
91
|
+
Save missing facts before switching sessions; active runs do not migrate through Git clone. People and tools without the runtime can still read status and write work descriptions.
|
|
92
|
+
|
|
93
|
+
[Session handoff](docs/v2/guide/11-session-handoff.en.md) · [Recovery](docs/v2/guide/10-recovery.en.md) · [Without the runtime](docs/v2/guide/12-without-runtime.en.md)
|
|
34
94
|
|
|
35
95
|
## Boundaries
|
|
36
96
|
|
|
@@ -48,4 +108,13 @@ The plugin supplies Skill, templates and docs; the runtime is installed separate
|
|
|
48
108
|
/buildbeat:buildbeat
|
|
49
109
|
```
|
|
50
110
|
|
|
51
|
-
|
|
111
|
+
## Read more
|
|
112
|
+
|
|
113
|
+
| To do this | Read |
|
|
114
|
+
|---|---|
|
|
115
|
+
| Set up a project for the first time | [Quickstart](docs/v2/guide/01-quickstart.en.md) |
|
|
116
|
+
| Talk to a session day to day | [How to talk](docs/v2/guide/00-how-to-talk.en.md) |
|
|
117
|
+
| Understand the fixed flow and the run config | [Workflow and configuration](docs/v2/guide/02-workflow-guide.en.md) |
|
|
118
|
+
| Approve, reject, read evidence | [Decisions and evidence](docs/v2/guide/07-approval-guide.en.md) |
|
|
119
|
+
| Hand over across sessions and people | [Session handoff](docs/v2/guide/11-session-handoff.en.md) |
|
|
120
|
+
| Contribute | [Contributing](CONTRIBUTING.md) · [MIT license](LICENSE) |
|
package/README.md
CHANGED
|
@@ -1,18 +1,51 @@
|
|
|
1
|
-
|
|
1
|
+
<p align="center">
|
|
2
|
+
<img src="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/hero.jpg" width="100%" alt="五线谱上依次排着实现、验证、审查、修复、拍板五个音符，一条脉搏线把它们连起来，末端收进一叠写满音符的乐谱">
|
|
3
|
+
</p>
|
|
2
4
|
|
|
3
|
-
|
|
5
|
+
<h1 align="center">BuildBeat</h1>
|
|
4
6
|
|
|
5
|
-
|
|
7
|
+
<p align="center"><strong>会话随时换，项目接着干。</strong></p>
|
|
8
|
+
|
|
9
|
+
<p align="center">
|
|
10
|
+
<a href="https://www.npmjs.com/package/@haiyangbg/buildbeat"><img alt="npm 版本" src="https://img.shields.io/npm/v/@haiyangbg/buildbeat?color=d97706&label=npm"></a>
|
|
11
|
+
<a href="https://github.com/HaiYangBG1/BuildBeat/actions/workflows/ci.yml"><img alt="CI 状态" src="https://github.com/HaiYangBG1/BuildBeat/actions/workflows/ci.yml/badge.svg"></a>
|
|
12
|
+
<a href="LICENSE"><img alt="MIT 许可证" src="https://img.shields.io/badge/license-MIT-e5534b"></a>
|
|
13
|
+
</p>
|
|
14
|
+
|
|
15
|
+
<p align="center">中文 · <a href="README.en.md">English</a></p>
|
|
16
|
+
|
|
17
|
+
> **名字的由来**：每一步是一个音符，Agent 按节拍把它们演奏出来；演奏过的乐谱——上下文、决定和结论——留在 Git 里，随时翻阅。
|
|
18
|
+
|
|
19
|
+
BuildBeat 面向人和 AI 会话：工作说明、决定和每轮结论留在项目文件与 Git 里，实现、验证、审查和修复在会话之外自动推进、随时可恢复，候选带着证据停在你的合并决定前。
|
|
20
|
+
|
|
21
|
+
## 一眼看懂
|
|
22
|
+
|
|
23
|
+
<picture>
|
|
24
|
+
<source media="(max-width: 600px) and (prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-zh-dark-narrow.png">
|
|
25
|
+
<source media="(max-width: 600px)" srcset="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-zh-light-narrow.png">
|
|
26
|
+
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-zh-dark.png">
|
|
27
|
+
<img src="https://raw.githubusercontent.com/HaiYangBG1/BuildBeat/main/docs/assets/readme/loop-zh-light.png" width="100%" alt="交付循环：work.md 之后依次是实现、验证、审查，审查有问题就修复、重验、再审，最后停下等你拍板；work.md、决定、审查问题和每轮运行的终态记录留在 Git 里">
|
|
28
|
+
</picture>
|
|
29
|
+
|
|
30
|
+
一项工作写一份 `work.md`。你接受之后，`buildbeat run` 在隔离的工作树里按节拍推进：实现、跑项目自己的验证命令、独立只读审查，有问题就修复、重验、再审。真正需要人的时候它会停下：合并拍板、环境故障、预算到顶、审查不收敛。工作说明、决定、审查问题和每轮运行的终态记录都进 Git，换会话、换工具、换人都从同一份记录接着干；运行中的台账和原始日志留在本机（见下文「记录与接续」）。
|
|
6
31
|
|
|
7
32
|
## 三个承诺
|
|
8
33
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
34
|
+
### 走得开
|
|
35
|
+
|
|
36
|
+
**关掉会话、换 AI 工具、换人，工作照样接着干。** 工作说明和运行台账都在项目里，`buildbeat run` 从记录恢复；主仓带多个代码仓时，`buildbeat status --repo . --all-repos` 一条命令看全所有仓的待办。
|
|
37
|
+
|
|
38
|
+
### 回来能信
|
|
39
|
+
|
|
40
|
+
**回来看到的是事实，不是 AI 的自述。** 验证跑项目真实命令，结果由运行时从 Git 和台账回读；审查独立、只读；缺工具、后端不可用、审查没交报告都按环境故障停下，不会当成代码问题去修。
|
|
41
|
+
|
|
42
|
+
### 敢拍板
|
|
12
43
|
|
|
13
|
-
|
|
44
|
+
**你批准的就是你看过的那一版。** 合并批准绑定候选（`--candidate`）；合并决定点发现小问题，可以自己修好交回（`run --adopt`），或一句话退回给修复者（`decide --action fix`）；合并、推送、发布、部署始终由人决定。
|
|
14
45
|
|
|
15
|
-
|
|
46
|
+
## 五分钟开始
|
|
47
|
+
|
|
48
|
+
运行时需要 Node ≥ 20。从 3.x 升级前，先用原来的 3.x 运行时完成或取消仍在进行的 Run（见[迁移说明](docs/MIGRATION.md)）。先读 [SKILL.md](SKILL.md) 与[快速开始](docs/v2/guide/01-quickstart.md)：把模板放进项目，写一份 `work.md`，在 run 配置里填好真实的 AI 工具和验证命令。
|
|
16
49
|
|
|
17
50
|
```bash
|
|
18
51
|
npm view @haiyangbg/buildbeat@latest version
|
|
@@ -26,17 +59,44 @@ buildbeat run --config delivery/work/WORK-X/run-config.yaml
|
|
|
26
59
|
buildbeat status --repo . --work WORK-X
|
|
27
60
|
```
|
|
28
61
|
|
|
62
|
+
## 跑起来是什么样
|
|
63
|
+
|
|
64
|
+
一项工作在第 1 轮审查里被挑出一个问题，修复者修好、重验，第 2 轮审查通过，然后停在你的合并决定前。下面是真实输出的节选（`…` 处有省略）：
|
|
65
|
+
|
|
66
|
+
```text
|
|
67
|
+
$ buildbeat status --repo . --work WORK-CSV-EXPORT
|
|
68
|
+
WORK-CSV-EXPORT MERGE_DECISION
|
|
69
|
+
[P1 0b5e258117cb5602] (accept) csv: quote fields that contain commas
|
|
70
|
+
work.md ✓ · runs 1
|
|
71
|
+
cost: review rounds 2 · findings 1 · human waits 1 (open 33s) · worker 2s
|
|
72
|
+
work WORK-CSV-EXPORT:
|
|
73
|
+
RUN-CSV-EXPORT-01 [final-decision] enter-wait-merge — waiting 33s
|
|
74
|
+
candidate: ede20b668cb04ae30cba1676b5e031930e711c8d
|
|
75
|
+
next: buildbeat decide --action approve … --candidate ede20b6… --by <you>
|
|
76
|
+
next: buildbeat decide --action reject … --reason <why> --by <you>
|
|
77
|
+
next: buildbeat run … --adopt <sha> --by <you> # commit a manual repair in the run worktree …
|
|
78
|
+
next: buildbeat decide … --action fix --reason <what to repair> --by <you>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
成本行告诉你审查了几轮、发现了几个问题、人等了多久，以及这些等待的去向。决定卡给出四种选择：批准（绑定这一版候选）、拒绝、自己修好交回、退回给修复者。
|
|
82
|
+
|
|
29
83
|
## 记录与接续
|
|
30
84
|
|
|
31
|
-
|
|
85
|
+
端到端工作包把一项工作的来龙去脉留在仓库里：
|
|
86
|
+
|
|
87
|
+
- `delivery/work/<ID>/` **随 Git 走**：work.md、run 配置、决定、审查问题、每轮终态记录（结果、成本、证据摘要与引用）
|
|
88
|
+
- `.buildbeat/runtime/` **只在本机**：运行台账、日志、截图等原始证据
|
|
89
|
+
- `.buildbeat/worktrees/` **只在本机**：候选所在的隔离工作树
|
|
32
90
|
|
|
33
|
-
|
|
91
|
+
换会话前补齐未落盘事实；Git clone 不迁移活动进程和现场。没装运行时的人和工具也能读状态、写工作说明。
|
|
92
|
+
|
|
93
|
+
[跨会话接续](docs/v2/guide/11-session-handoff.md) · [中断恢复](docs/v2/guide/10-recovery.md) · [没有运行时也能参与](docs/v2/guide/12-without-runtime.md)
|
|
34
94
|
|
|
35
95
|
## 能力边界
|
|
36
96
|
|
|
37
97
|
BuildBeat 不提供多人账号、角色/权限系统，不采集或上传项目使用数据，没有遥测采集。模型和鉴权由配置的 AI 工具提供。合并、推送、部署、发布分别由获授权的外部操作完成；上线后可用 `buildbeat release` 记录项目自己的回读，回读通过才关窗。生产巡检和任意工作流/规则语言不在产品范围内。
|
|
38
98
|
|
|
39
|
-
[
|
|
99
|
+
[能力矩阵](docs/CAPABILITY-MATRIX.md) · [安全边界](docs/v2/guide/09-security-boundaries.md) · [迁移说明](docs/MIGRATION.md)
|
|
40
100
|
|
|
41
101
|
## Claude Code 插件
|
|
42
102
|
|
|
@@ -48,4 +108,13 @@ BuildBeat 不提供多人账号、角色/权限系统，不采集或上传项目
|
|
|
48
108
|
/buildbeat:buildbeat
|
|
49
109
|
```
|
|
50
110
|
|
|
51
|
-
|
|
111
|
+
## 继续阅读
|
|
112
|
+
|
|
113
|
+
| 想做什么 | 看哪里 |
|
|
114
|
+
|---|---|
|
|
115
|
+
| 第一次接入一个项目 | [快速开始](docs/v2/guide/01-quickstart.md) |
|
|
116
|
+
| 平时怎么和会话说 | [怎么和会话说话](docs/v2/guide/00-how-to-talk.md) |
|
|
117
|
+
| 理解固定流程和 run 配置 | [流程与配置](docs/v2/guide/02-workflow-guide.md) |
|
|
118
|
+
| 批准、拒绝、证据 | [决定与证据](docs/v2/guide/07-approval-guide.md) |
|
|
119
|
+
| 换会话、换人接手 | [跨会话接续](docs/v2/guide/11-session-handoff.md) |
|
|
120
|
+
| 参与贡献 | [贡献指南](CONTRIBUTING.md) · [MIT 许可证](LICENSE) |
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# BuildBeat capability matrix / 能力矩阵
|
|
2
2
|
|
|
3
|
-
Current release: 4.2.
|
|
3
|
+
Current release: 4.2.2. One product path: Skill → local runtime →
|
|
4
4
|
project records. The Claude Code plugin distributes the Skill and references;
|
|
5
5
|
install the runtime separately. Files remain readable without the runtime, but
|
|
6
6
|
manual work has no automatic loop, isolation, budget or approval enforcement;
|
package/docs/RELEASING.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
This runbook governs BuildBeat's public npm distribution. The canonical package is `@haiyangbg/buildbeat` in `HaiYangBG1/BuildBeat`; the only executable is `buildbeat`. No other package name or executable alias receives publications.
|
|
4
4
|
|
|
5
|
-
Release evidence at source package version `@haiyangbg/buildbeat@4.2.
|
|
5
|
+
Release evidence at source package version `@haiyangbg/buildbeat@4.2.2`; latest independently verified BuildBeat npm distribution `@haiyangbg/buildbeat@4.2.1` (dist-tag `latest`; `next` stays on `4.2.0` until the owner moves it with npm 2FA), anchored by annotated tag `v4.2.1` at commit `8d2625b`, workflow run [37626818833](https://github.com/HaiYangBG1/BuildBeat/actions/runs/37626818833), and archived in [`V4.2.1-RELEASE-EVIDENCE-2026-10-07.md`](releases/V4.2.1-RELEASE-EVIDENCE-2026-10-07.md). The 4.2.0 chain (`latest` on 2026-10-07 until 4.2.1 took over the same day; the owner moved `next` from `4.0.0` to `4.2.0` with npm 2FA that day) stays archived in [`V4.2.0-RELEASE-EVIDENCE-2026-10-07.md`](releases/V4.2.0-RELEASE-EVIDENCE-2026-10-07.md). The 4.1.0 chain (`latest` on 2026-10-07 until 4.2.0 took over the same day) stays archived in [`V4.1.0-RELEASE-EVIDENCE-2026-10-07.md`](releases/V4.1.0-RELEASE-EVIDENCE-2026-10-07.md). The 4.0.0 chain (`latest` from 2026-10-05 until 4.1.0 took over on 2026-10-07; the owner moved `next` from `3.3.1` to `4.0.0` with npm 2FA on 2026-10-05) stays archived in [`V4.0.0-RELEASE-EVIDENCE-2026-10-05.md`](releases/V4.0.0-RELEASE-EVIDENCE-2026-10-05.md). The 3.3.1 chain (`latest` from 2026-10-02 until 4.0.0 took over on 2026-10-05; the owner moved `next` from `3.3.0` to `3.3.1` with npm 2FA on 2026-10-02) stays archived in [`V3.3.1-RELEASE-EVIDENCE-2026-10-02.md`](releases/V3.3.1-RELEASE-EVIDENCE-2026-10-02.md). The 3.3.0 chain (`latest` on 2026-10-02 until 3.3.1 took over the same day; the owner moved `next` from `3.2.1` to `3.3.0` with npm 2FA that day) stays archived in [`V3.3.0-RELEASE-EVIDENCE-2026-10-02.md`](releases/V3.3.0-RELEASE-EVIDENCE-2026-10-02.md). The 3.2.1 chain (`latest` from 2026-09-26 until 3.3.0 took over on 2026-10-02; the owner moved `next` from `3.0.1` to `3.2.1` with npm 2FA on 2026-09-26) stays archived in [`V3.2.1-RELEASE-EVIDENCE-2026-09-26.md`](releases/V3.2.1-RELEASE-EVIDENCE-2026-09-26.md). The 3.2.0 chain (`latest` on 2026-09-26 until 3.2.1 took over the same day) stays archived in [`V3.2.0-RELEASE-EVIDENCE-2026-09-26.md`](releases/V3.2.0-RELEASE-EVIDENCE-2026-09-26.md). The 3.1.0 chain (`latest` on 2026-09-26 until 3.2.0 took over the same day) stays archived in [`V3.1.0-RELEASE-EVIDENCE-2026-09-26.md`](releases/V3.1.0-RELEASE-EVIDENCE-2026-09-26.md). The 3.0.1 chain (`latest` from 2026-09-09 until 3.1.0 took over on 2026-09-26) stays archived in [`V3.0.1-RELEASE-EVIDENCE-2026-09-09.md`](releases/V3.0.1-RELEASE-EVIDENCE-2026-09-09.md). The 3.0.0 chain (`latest` from 2026-09-09 until 3.0.1 took over the same day; the first version without the removed generation) stays archived in [`V3.0.0-RELEASE-EVIDENCE-2026-09-09.md`](releases/V3.0.0-RELEASE-EVIDENCE-2026-09-09.md). The 2.0.2 chain (`latest` from 2026-09-09 until 3.0.0 took over the same day; the last version carrying the removed generation) stays archived in [`V2.0.2-RELEASE-EVIDENCE-2026-09-09.md`](releases/V2.0.2-RELEASE-EVIDENCE-2026-09-09.md). The 2.0.1 chain (`latest` from 2026-09-06 until 2.0.2 took over on 2026-09-09) stays archived in [`V2.0.1-RELEASE-EVIDENCE-2026-09-06.md`](releases/V2.0.1-RELEASE-EVIDENCE-2026-09-06.md). The 2.0.0 chain (`latest` from 2026-09-05 until 2.0.1 took over on 2026-09-06) stays archived in [`V2.0.0-RELEASE-EVIDENCE-2026-09-05.md`](releases/V2.0.0-RELEASE-EVIDENCE-2026-09-05.md). The beta.5 chain stays archived in [`V2.0.0-BETA.5-RELEASE-EVIDENCE-2026-09-05.md`](releases/V2.0.0-BETA.5-RELEASE-EVIDENCE-2026-09-05.md). The beta.4 chain stays archived in [`V2.0.0-BETA.4-RELEASE-EVIDENCE-2026-09-03.md`](releases/V2.0.0-BETA.4-RELEASE-EVIDENCE-2026-09-03.md); the beta.3 chain in [`V2.0.0-BETA.3-RELEASE-EVIDENCE-2026-09-01.md`](releases/V2.0.0-BETA.3-RELEASE-EVIDENCE-2026-09-01.md). The beta.2 chain stays archived in [`V2.0.0-BETA.2-RELEASE-EVIDENCE-2026-08-28.md`](releases/V2.0.0-BETA.2-RELEASE-EVIDENCE-2026-08-28.md); the beta.1 chain stays archived in [`V2.0.0-BETA.1-RELEASE-EVIDENCE-2026-08-28.md`](releases/V2.0.0-BETA.1-RELEASE-EVIDENCE-2026-08-28.md). Earlier distributions and the retired legacy package name are archived in the dated evidence files under `docs/releases/`.
|
|
6
6
|
|
|
7
7
|
## Channels and branches
|
|
8
8
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@haiyangbg/buildbeat",
|
|
3
|
-
"version": "4.2.
|
|
3
|
+
"version": "4.2.2",
|
|
4
4
|
"description": "BuildBeat: Git-based AI delivery across models, tools, sessions, and people, with context in project files, build-test-review-fix loops, and human decisions.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|