skill-family-engineering-kit 0.20.0 → 0.22.0
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 +41 -0
- package/CHANGELOG.zh-CN.md +41 -0
- package/README.md +65 -17
- package/README.zh-CN.md +65 -17
- package/data/capability-catalog/capability-catalog.en.json +104 -23
- package/data/capability-catalog/capability-catalog.json +66 -21
- package/data/capability-catalog/capability-catalog.zh-CN.json +104 -23
- package/docs/agents/capability-catalog.en.json +104 -23
- package/docs/agents/capability-catalog.json +66 -21
- package/docs/agents/capability-catalog.zh-CN.json +104 -23
- package/docs/architecture/index.html +61 -2
- package/docs/en/architecture/index.html +26 -0
- package/docs/en/help/index.html +83 -1
- package/docs/en/quickstart/index.html +10 -0
- package/docs/en/reference/failure-and-side-effect-matrix/index.html +43 -0
- package/docs/help/index.html +83 -1
- package/docs/integration/audit/version-compatibility/index.html +14 -2
- package/docs/public/status/index.html +3 -3
- package/docs/quickstart/index.html +10 -0
- package/docs/reference/api/contracts/index.html +113 -3
- package/docs/reference/api/engineering-kit/index.html +19 -13
- package/docs/reference/api/harness/index.html +85 -4
- package/docs/reference/failure-and-side-effect-matrix/index.html +44 -1
- package/docs/search/search_index.json +1 -1
- package/docs/setup/index.html +31 -0
- package/package.json +3 -3
- package/release-notes/0.21.0.yaml +21 -0
- package/release-notes/0.22.0.yaml +23 -0
- package/src/check.mjs +191 -1
- package/src/cli.mjs +36 -4
- package/src/engineering-declaration.mjs +108 -0
- package/src/entry-check.mjs +114 -5
- package/src/host-verification.mjs +177 -3
- package/src/index.mjs +14 -2
- package/src/professional-conclusion.mjs +104 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,46 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
<!-- release-skill:changelog:start version=0.22.0 locale=en baseline=sha256:5eeae7aaee659b91fd9d412ff5a0651d49e90fbcb020ffdb335d25845d590ef3 -->
|
|
4
|
+
## [0.22.0] - 2026-09-18
|
|
5
|
+
|
|
6
|
+
Engineering Kit 0.22.0 keeps the four top-level commands and adds declared engineering-declaration checking plus explicit professional-conclusion output inside the existing `check` command.
|
|
7
|
+
|
|
8
|
+
### Added
|
|
9
|
+
|
|
10
|
+
- Adds declared engineering-declaration checking with a declaration version and an entry branch, reading only the version source and physical entry a project explicitly registers and never executing the target.
|
|
11
|
+
- Adds optional professional-conclusion output that only `runCommand('check')` and the entry action may exclusively create, and only when the caller supplies an existing output root and a contained relative path.
|
|
12
|
+
|
|
13
|
+
### Changed
|
|
14
|
+
|
|
15
|
+
- The default `check` diagnosis and the pure `runChecks`/`runEntryContractCheck` functions remain read-only; a missing output root or an existing conclusion entry is rejected instead of created or overwritten.
|
|
16
|
+
- Publishes the 0.22.0 capability catalog with the new `foundation.harness.file-set-recovery` entry projected from Contracts 1.20.0.
|
|
17
|
+
|
|
18
|
+
### Upgrade Notes
|
|
19
|
+
|
|
20
|
+
Pin all three Foundation packages to exactly 0.22.0. Declarative checking proves only that a registered version source and entry agree structurally; it does not prove the target executed, and business interpretation of a conclusion remains outside Foundation.
|
|
21
|
+
<!-- release-skill:changelog:end version=0.22.0 locale=en -->
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
<!-- release-skill:changelog:start version=0.21.0 locale=en baseline=sha256:308114b76ba97466f58479dd0d5e4251ea8efba6ad291afc65236f26170229c5 -->
|
|
25
|
+
## [0.21.0] - 2026-09-11
|
|
26
|
+
|
|
27
|
+
Engineering Kit 0.21.0 adds `prepareHostVerification` for preparing one bounded Cursor invocation and reading its digest-bound private output through the existing host-verification path.
|
|
28
|
+
|
|
29
|
+
### Added
|
|
30
|
+
|
|
31
|
+
- Adds `prepareHostVerification`, which derives the fixed driver request, contained invocation directories, frozen snapshots, and private bindings from caller-owned candidate, workload, Skill, workspace, fixture, prompt, executable, and state-root inputs.
|
|
32
|
+
- Adds `readInvocationStream` to the frozen preparation object so callers can read stdout or stderr only after the result, request, evidence-root binding, stream digest, and byte count match.
|
|
33
|
+
|
|
34
|
+
### Changed
|
|
35
|
+
|
|
36
|
+
- Rechecks bindings and source snapshots before process spawn, then compares the installed Skill closure digest before session creation or probing; drift and post-install digest mismatches fail closed.
|
|
37
|
+
|
|
38
|
+
### Upgrade Notes
|
|
39
|
+
|
|
40
|
+
Pin all three Foundation packages to exactly 0.21.0. The new preparation API supports only one declared Cursor Skill with the packaged `cursor-agent-print-v1` driver; workload meaning, domain assertions, release freshness, and cleanup remain caller responsibilities.
|
|
41
|
+
<!-- release-skill:changelog:end version=0.21.0 locale=en -->
|
|
42
|
+
|
|
43
|
+
|
|
3
44
|
<!-- release-skill:changelog:start version=0.20.0 locale=en baseline=sha256:4ea3064e77b2e33e76d1476f02f7d22920638e872cb87c098e8260f617081313 -->
|
|
4
45
|
## [0.20.0] - 2026-09-10
|
|
5
46
|
|
package/CHANGELOG.zh-CN.md
CHANGED
|
@@ -1,5 +1,46 @@
|
|
|
1
1
|
# 变更日志
|
|
2
2
|
|
|
3
|
+
<!-- release-skill:changelog:start version=0.22.0 locale=zh-CN baseline=sha256:1926982b72cf2756963b204c22c9bfdf2969d690d3b336cf9bdc098fe4d256a0 -->
|
|
4
|
+
## [0.22.0] - 2026-09-18
|
|
5
|
+
|
|
6
|
+
Engineering Kit 0.22.0 保持四个顶层命令不变,在既有 `check` 命令内增加声明式工程检查与显式的专业结论输出。
|
|
7
|
+
|
|
8
|
+
### 新增
|
|
9
|
+
|
|
10
|
+
- 增加不含价格的声明式工程检查,带声明版本与入口分支;只读取项目明确登记的版本来源与物理入口,不执行目标。
|
|
11
|
+
- 增加可选的专业结论输出。只有 `runCommand('check')` 和入口动作可以独占创建,且必须由调用方提供已存在的输出根与受收容的相对路径。
|
|
12
|
+
|
|
13
|
+
### 变更
|
|
14
|
+
|
|
15
|
+
- 默认 `check` 诊断与纯函数 `runChecks`/`runEntryContractCheck` 仍然只读;输出根不存在或结论条目已存在时拒绝,不创建、不覆盖。
|
|
16
|
+
- 随 0.22.0 发布新的能力目录,按 Contracts 1.20.0 投影新增 `foundation.harness.file-set-recovery` 条目。
|
|
17
|
+
|
|
18
|
+
### 升级说明
|
|
19
|
+
|
|
20
|
+
三个 Foundation 包须一起精确锁定到 0.22.0。声明式检查只证明已登记的版本来源与入口在结构上一致,不证明目标已执行;结论的业务解释不属于 Foundation。
|
|
21
|
+
<!-- release-skill:changelog:end version=0.22.0 locale=zh-CN -->
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
<!-- release-skill:changelog:start version=0.21.0 locale=zh-CN baseline=sha256:1f50ac51db5691c5c9dbe1014d0ab43e6cfa4eab1d60eb37a9ca74d30bc75890 -->
|
|
25
|
+
## [0.21.0] - 2026-09-11
|
|
26
|
+
|
|
27
|
+
Engineering Kit 0.21.0 增加 `prepareHostVerification`,在既有宿主验证路径上准备一次受约束的 Cursor 调用,并读取经过摘要绑定的私有输出。
|
|
28
|
+
|
|
29
|
+
### 新增
|
|
30
|
+
|
|
31
|
+
- 增加 `prepareHostVerification`。它从调用方持有的候选、工作负载、Skill、工作区、夹具、提示词、可执行文件和状态根输入派生固定驱动请求、受收容调用目录、冻结快照与私有绑定。
|
|
32
|
+
- 冻结的准备对象增加 `readInvocationStream`。只有结果、请求、证据根绑定、流摘要和字节数一致时,调用方才能读取 stdout 或 stderr。
|
|
33
|
+
|
|
34
|
+
### 变更
|
|
35
|
+
|
|
36
|
+
- 启动进程前重新校验绑定与来源快照;创建会话或探测前比较安装后的 Skill 闭包摘要。发现漂移或摘要不匹配时失败关闭。
|
|
37
|
+
|
|
38
|
+
### 升级说明
|
|
39
|
+
|
|
40
|
+
三个 Foundation 包须一起精确锁定到 0.21.0。新准备接口只支持一个已声明的 Cursor Skill,并固定使用随包 `cursor-agent-print-v1` 驱动;工作负载含义、领域断言、发布新鲜度和清理由调用方负责。
|
|
41
|
+
<!-- release-skill:changelog:end version=0.21.0 locale=zh-CN -->
|
|
42
|
+
|
|
43
|
+
|
|
3
44
|
<!-- release-skill:changelog:start version=0.20.0 locale=zh-CN baseline=sha256:7f7e7f2175429d96720b04bb378afcb796e01f642abc0cdd7114fddf4a808b62 -->
|
|
4
45
|
## [0.20.0] - 2026-09-10
|
|
5
46
|
|
package/README.md
CHANGED
|
@@ -4,29 +4,43 @@
|
|
|
4
4
|
|
|
5
5
|
# skill-family-engineering-kit
|
|
6
6
|
|
|
7
|
-
<!-- release-skill:release-version: 0.
|
|
7
|
+
<!-- release-skill:release-version: 0.22.0 -->
|
|
8
8
|
|
|
9
9
|
An engineering toolkit used in development and CI. There are **exactly four** top-level commands, and no fifth:
|
|
10
10
|
|
|
11
11
|
<!-- release-skill:managed:start id=latest-release -->
|
|
12
|
-
**0.
|
|
12
|
+
**0.22.0** (2026-09-18)
|
|
13
13
|
|
|
14
|
-
Engineering Kit 0.
|
|
14
|
+
Engineering Kit 0.22.0 keeps the four top-level commands and adds declared engineering-declaration checking plus explicit professional-conclusion output inside the existing `check` command.
|
|
15
15
|
|
|
16
16
|
**Added**
|
|
17
17
|
|
|
18
|
-
-
|
|
19
|
-
- Adds
|
|
18
|
+
- Adds declared engineering-declaration checking with a declaration version and an entry branch, reading only the version source and physical entry a project explicitly registers and never executing the target.
|
|
19
|
+
- Adds optional professional-conclusion output that only `runCommand('check')` and the entry action may exclusively create, and only when the caller supplies an existing output root and a contained relative path.
|
|
20
20
|
|
|
21
21
|
**Changed**
|
|
22
22
|
|
|
23
|
-
-
|
|
23
|
+
- The default `check` diagnosis and the pure `runChecks`/`runEntryContractCheck` functions remain read-only; a missing output root or an existing conclusion entry is rejected instead of created or overwritten.
|
|
24
|
+
- Publishes the 0.22.0 capability catalog with the new `foundation.harness.file-set-recovery` entry projected from Contracts 1.20.0.
|
|
24
25
|
|
|
25
26
|
**Upgrade Notes**
|
|
26
27
|
|
|
27
|
-
Pin all three Foundation packages to exactly 0.
|
|
28
|
+
Pin all three Foundation packages to exactly 0.22.0. Declarative checking proves only that a registered version source and entry agree structurally; it does not prove the target executed, and business interpretation of a conclusion remains outside Foundation.
|
|
28
29
|
<!-- release-skill:managed:end id=latest-release -->
|
|
29
30
|
|
|
31
|
+
## Governance Check (0.22.0)
|
|
32
|
+
|
|
33
|
+
Version 0.22.0 adds an explicit `declared` policy under the existing `check` command. Version
|
|
34
|
+
checking reads only the release units and text or JSON version references listed in
|
|
35
|
+
`skill-family.project-manifest.json`; entry checking reads only the listed physical files. Neither branch
|
|
36
|
+
runs target scripts, Skills, hooks, models, or unselected legacy checks.
|
|
37
|
+
|
|
38
|
+
`runChecks` and `runEntryContractCheck` remain read-only. Only the existing `runCommand("check")` and
|
|
39
|
+
`checkEntriesAction` wrappers may create one `professional-conclusion` file, and only when the caller
|
|
40
|
+
provides both an existing output root and a contained relative path. The write is exclusive: parent
|
|
41
|
+
directories are not created and existing entries are not overwritten. This implementation ships with the
|
|
42
|
+
0.22.0 artifact; the earlier published 0.21.0 artifact does not contain it.
|
|
43
|
+
|
|
30
44
|
### Foundation 0.15.0 candidate qualification entries
|
|
31
45
|
|
|
32
46
|
The candidate adds two fixed qualification entries: `foundation.kit.plugin-verification` accepts the Qoder and WorkBuddy native-lifecycle branches, and `foundation.kit.skill-family-directory-verification` accepts the Kimi branch. Qoder and WorkBuddy each use a dedicated production driver with its own argv plan and the same twelve ordered semantic stages; executable identity is re-observed before every spawn. Contracts validates only the closed stage structure, order, and stop propagation.
|
|
@@ -54,7 +68,7 @@ Kit is the "engineering stage" layer, depending on the Harness and Contracts. It
|
|
|
54
68
|
|
|
55
69
|
## Installation and Minimal Example
|
|
56
70
|
|
|
57
|
-
Version 0.
|
|
71
|
+
Version 0.22.0 is the local source candidate. Build all three tarballs into one temporary directory and install those exact files for a candidate check:
|
|
58
72
|
|
|
59
73
|
```sh
|
|
60
74
|
pack_dir="$(mktemp -d)"
|
|
@@ -62,21 +76,21 @@ pack_dir="$(mktemp -d)"
|
|
|
62
76
|
(cd packages/skill-family-harness-node && pnpm pack --pack-destination "$pack_dir")
|
|
63
77
|
(cd packages/skill-family-engineering-kit && pnpm pack --pack-destination "$pack_dir")
|
|
64
78
|
mkdir "$pack_dir/consumer" && (cd "$pack_dir/consumer" && npm init -y)
|
|
65
|
-
(cd "$pack_dir/consumer" && npm install "$pack_dir/skill-family-contracts-0.
|
|
79
|
+
(cd "$pack_dir/consumer" && npm install "$pack_dir/skill-family-contracts-0.22.0.tgz" "$pack_dir/skill-family-harness-node-0.22.0.tgz" "$pack_dir/skill-family-engineering-kit-0.22.0.tgz")
|
|
66
80
|
```
|
|
67
81
|
|
|
68
82
|
After publication, use the registry coordinate:
|
|
69
83
|
|
|
70
84
|
```sh
|
|
71
|
-
npm install --save-dev skill-family-engineering-kit@0.
|
|
72
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
73
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
74
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
75
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
76
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
85
|
+
npm install --save-dev skill-family-engineering-kit@0.22.0
|
|
86
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit --help
|
|
87
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit scaffold --root <empty-dir> --project-id my-project
|
|
88
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit adopt-plan --root <repo> --list-capabilities --all --scope all --locale en --uses ./uses.json
|
|
89
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit projection --root <repo>
|
|
90
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit check --root <repo>
|
|
77
91
|
```
|
|
78
92
|
|
|
79
|
-
The four commands above cover skeleton generation, read-only inventory, managed projection, and diagnostics respectively; a zero-install form is available via `npm exec --package=skill-family-engineering-kit@0.
|
|
93
|
+
The four commands above cover skeleton generation, read-only inventory, managed projection, and diagnostics respectively; a zero-install form is available via `npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit --help`.
|
|
80
94
|
|
|
81
95
|
### Three adoption journeys
|
|
82
96
|
|
|
@@ -170,12 +184,45 @@ The API keeps consumer workload, domain output checks, domain PASS/FAIL, release
|
|
|
170
184
|
|
|
171
185
|
`executableSha256` binds only the bytes observed by the strict preflight read; the actual process is still spawned by pathname, so the caller must exclusively control the executable namespace through probe and invocation. Foundation retains the call's `session-*` directory and never deletes it by pathname. After inspection, the caller cleans its exclusively owned outer `temporaryRoot`.
|
|
172
186
|
|
|
187
|
+
#### 0.21.0 candidate: prepare a Cursor invocation
|
|
188
|
+
|
|
189
|
+
`prepareHostVerification` was published with 0.21.0 and remains available in 0.22.0. It prepares one declared Skill for `cursor`, using the packaged Descriptor and fixed `cursor-agent-print-v1` driver. It accepts no custom driver, arguments, model override, credential handling, or domain validator. The existing seven-driver `runHostVerification` entrypoint remains compatible.
|
|
190
|
+
|
|
191
|
+
The caller supplies the following values; document and fixture content is an opaque UTF-8 string or Buffer. `skillMembers` must include `SKILL.md`; only declared members are installed. All roots must already exist as canonical absolute paths. `sessionRoot` must be empty and exclusively owned, and the workspace must be inside `repositoryRoot` (equality is allowed). The caller authorizes use of the existing user-state root and exclusively controls the executable namespace.
|
|
192
|
+
|
|
193
|
+
```js
|
|
194
|
+
import { prepareHostVerification, runHostVerification } from "skill-family-engineering-kit";
|
|
195
|
+
|
|
196
|
+
const prepared = await prepareHostVerification({
|
|
197
|
+
hostId: "cursor", verificationSetId,
|
|
198
|
+
candidate: { ref: candidateRef, manifest: candidateManifest },
|
|
199
|
+
skill: { root: skillRoot, entrySkill, members: skillMembers },
|
|
200
|
+
workloadDocument, fixtureFiles, // [{ path: "input.json", content: fixtureBytes }]
|
|
201
|
+
workspace: { repositoryRoot, root: workspaceRoot, protectedMembers },
|
|
202
|
+
platformManifest, effectivePrompt,
|
|
203
|
+
executable: { root: executableRoot, relPath: "cursor-agent" },
|
|
204
|
+
existingUserStateRoot, sessionRoot,
|
|
205
|
+
timeoutPolicy: { schemaVersion: 1, kind: "skill-family.timeout-policy", maxSeconds: 60, killGraceSeconds: 1 },
|
|
206
|
+
});
|
|
207
|
+
const result = await runHostVerification(prepared);
|
|
208
|
+
const stdout = result.streams
|
|
209
|
+
? await prepared.readInvocationStream(result, "stdout")
|
|
210
|
+
: null;
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
Preparation copies input bytes, computes digests, freezes the request and private bindings, and creates contained documents and missing `.cursor/skills` parents without spawning a process or installing the Skill. Execution rechecks bindings and compares the installed Skill digest before any probe. Invalid fields, Schema failures, and mechanism failures use `SFC2003`, `SFC1001`, and `SFC2004`, respectively; preparation may leave partial files on a mechanism failure.
|
|
214
|
+
|
|
215
|
+
`readInvocationStream(result, "stdout" | "stderr")` returns a Buffer only after checking the result, request binding, captured evidence root, stream digest, and byte count. It does not parse the answer or decide domain correctness. Missing streams or a read failure mean required business evidence is unavailable, not acceptance. The four states remain `observed`, `rejected`, `failed`, and `indeterminate`; `observed` is not a domain PASS. Only the validated result may enter a public report: the prepared object, raw streams, and error details stay private.
|
|
216
|
+
|
|
217
|
+
The caller owns workload semantics, candidate-to-payload binding, domain assertions, release freshness, and resource cleanup. Keep the outer session and workspace handles before preparation; after a known outcome, read the evidence and confirm no process still uses the directories before cleanup. Preserve an `indeterminate` scene for the required manual actions; do not wrap the call in unconditional cleanup. A retry needs fresh roots and a new prepared object. These local fixture checks do not qualify a real host or prove model-driven Skill discovery.
|
|
218
|
+
|
|
173
219
|
## Typical Use Cases
|
|
174
220
|
|
|
175
221
|
- New project skeleton: `scaffold` (does not overwrite a non-empty existing repo).
|
|
176
222
|
- Existing-repo adoption inventory: `adopt-plan` (strictly read-only, no file writes, no auto-migration).
|
|
177
223
|
- Managed projection: `projection` + Profile (does not overwrite handwritten files).
|
|
178
224
|
- Engineering diagnostics: ordinary `check` is read-only; `check relock` is an explicit controlled write transaction, and `check qualification` may spawn a bound executable after preflight.
|
|
225
|
+
- Declared governance diagnostics: select `policy: "declared"` with version-only checking, or use the declared entry sub-action. The target is inspected statically; an optional conclusion file requires explicit output authorization.
|
|
179
226
|
|
|
180
227
|
## Boundary Mechanisms
|
|
181
228
|
|
|
@@ -183,6 +230,7 @@ The API keeps consumer workload, domain output checks, domain PASS/FAIL, release
|
|
|
183
230
|
- `adopt-plan` is structurally read-only: there is no write call in the implementation, not even a temp file; the plan bytes share the same source as `scaffold` (single source of truth `describeSkeletonFiles`), hence "the plan is the action". By default it may spawn one frozen read-only Git status probe; the CLI `--no-git-spawn` (or API `allowGitSpawn: false`) disables that probe. A dirty repo has zero byte-level change before and after running.
|
|
184
231
|
- `projection` uses two-phase execution: first, for each entry, it performs path classification, containment pre-check, self-projection check, manifest authorization check, hand-written protection, and conflict guard; if any entry violates, the whole is rejected with zero writes. Overwriting an existing file must declare the precise `expect.sha256` precondition; an existing file with identical content is an idempotent no-op. On write failure it best-effort restores the pre-write bytes of already-overwritten files.
|
|
185
232
|
- Ordinary `check` is read-only and has no write calls or `--fix/--apply/--repair` modes (such flags are rejected at the entry point). By default it may spawn one frozen read-only Git status probe; the CLI `--no-git-spawn` (or API `allowGitSpawn: false`) disables that probe. `check relock` is the explicit controlled write transaction; `check qualification` may spawn a bound executable after preflight. Git precondition state uses only filesystem facts plus at most one read-only `git status --porcelain=2` with a frozen parameter vector (`--no-optional-locks` + `GIT_OPTIONAL_LOCKS=0`, no index refresh).
|
|
233
|
+
- In the unreleased declared branch, the two pure check functions remain read-only and do not probe Git. An explicitly requested conclusion is the only added persistent effect and is performed by the two existing wrappers through exclusive creation.
|
|
186
234
|
|
|
187
235
|
## Error Codes and Exit Codes
|
|
188
236
|
|
|
@@ -295,4 +343,4 @@ The candidate `runPluginVerification({ request, bindings, hostsRoot })` preserve
|
|
|
295
343
|
|
|
296
344
|
The separate `runSkillFamilyDirectoryVerification({ request, bindings })` entry fixes the Kimi production argv and narrow environment and rejects caller observation. Its raw parser is exercised through the production process path, but no controlled fixture event is promoted to `observed`; without an official typed mapping, the public result remains `indeterminate` and a manual candidate.
|
|
297
345
|
|
|
298
|
-
|
|
346
|
+
The declared governance branch and conclusion output ship with the 0.22.0 artifact; the earlier published 0.21.0 artifact does not contain them. Remote availability must be established by the corresponding release-skill post-release evidence. Local tests or working-tree tarballs do not prove contract integration, migration completion, or real-host qualification.
|
package/README.zh-CN.md
CHANGED
|
@@ -5,29 +5,41 @@
|
|
|
5
5
|
|
|
6
6
|
# skill-family-engineering-kit
|
|
7
7
|
|
|
8
|
-
<!-- release-skill:release-version: 0.
|
|
8
|
+
<!-- release-skill:release-version: 0.22.0 -->
|
|
9
9
|
|
|
10
10
|
开发与 CI 阶段使用的工程工具包。**恰好四个**顶层命令,没有第五个:
|
|
11
11
|
|
|
12
12
|
<!-- release-skill:managed:start id=latest-release -->
|
|
13
|
-
**0.
|
|
13
|
+
**0.22.0** (2026-09-18)
|
|
14
14
|
|
|
15
|
-
Engineering Kit 0.
|
|
15
|
+
Engineering Kit 0.22.0 保持四个顶层命令不变,在既有 `check` 命令内增加声明式工程检查与显式的专业结论输出。
|
|
16
16
|
|
|
17
17
|
**新增**
|
|
18
18
|
|
|
19
|
-
-
|
|
20
|
-
-
|
|
19
|
+
- 增加不含价格的声明式工程检查,带声明版本与入口分支;只读取项目明确登记的版本来源与物理入口,不执行目标。
|
|
20
|
+
- 增加可选的专业结论输出。只有 `runCommand('check')` 和入口动作可以独占创建,且必须由调用方提供已存在的输出根与受收容的相对路径。
|
|
21
21
|
|
|
22
22
|
**变更**
|
|
23
23
|
|
|
24
|
-
-
|
|
24
|
+
- 默认 `check` 诊断与纯函数 `runChecks`/`runEntryContractCheck` 仍然只读;输出根不存在或结论条目已存在时拒绝,不创建、不覆盖。
|
|
25
|
+
- 随 0.22.0 发布新的能力目录,按 Contracts 1.20.0 投影新增 `foundation.harness.file-set-recovery` 条目。
|
|
25
26
|
|
|
26
27
|
**升级说明**
|
|
27
28
|
|
|
28
|
-
三个 Foundation 包须一起精确锁定到 0.
|
|
29
|
+
三个 Foundation 包须一起精确锁定到 0.22.0。声明式检查只证明已登记的版本来源与入口在结构上一致,不证明目标已执行;结论的业务解释不属于 Foundation。
|
|
29
30
|
<!-- release-skill:managed:end id=latest-release -->
|
|
30
31
|
|
|
32
|
+
## 本地未发布治理检查
|
|
33
|
+
|
|
34
|
+
当前工作树在既有 `check` 命令下增加显式 `declared` 政策。版本检查只读取
|
|
35
|
+
`skill-family.project-manifest.json` 声明的发行单元及其文本或 JSON 版本引用;入口检查只读取
|
|
36
|
+
声明的物理文件。两个分支都不运行目标脚本、Skill、hook、模型,也不先跑未选择的 legacy 检查。
|
|
37
|
+
|
|
38
|
+
`runChecks` 与 `runEntryContractCheck` 仍然只读。只有既有 `runCommand("check")` 和
|
|
39
|
+
`checkEntriesAction` 包装入口可以创建一份 `professional-conclusion` 文件,而且调用方必须同时
|
|
40
|
+
给出已存在输出根与根内相对路径。写入采用独占创建,不建父目录、不覆盖现有条目。这组实现随
|
|
41
|
+
0.22.0 制品发布;此前已发布的 0.21.0 制品不包含它。
|
|
42
|
+
|
|
31
43
|
### Foundation 0.15.0 candidate 资格入口
|
|
32
44
|
|
|
33
45
|
本候选版本增加两个固定资格入口:`foundation.kit.plugin-verification` 接入 Qoder 与 WorkBuddy 的 native-lifecycle 分支,`foundation.kit.skill-family-directory-verification` 接入 Kimi 目录分支。Qoder 与 WorkBuddy 各有一个生产 driver,各自确定 argv 计划,共用十二个有序语义阶段;每次 spawn 前重新观察可执行文件身份。Contracts 只校验闭合阶段结构、顺序与停止传播。
|
|
@@ -55,7 +67,7 @@ Kit 是「工程阶段」层,依赖 Harness 与 Contracts。它只做四件事
|
|
|
55
67
|
|
|
56
68
|
## 安装和最小示例
|
|
57
69
|
|
|
58
|
-
0.
|
|
70
|
+
0.22.0 是本地源码候选。候选验证先把三个包分别打入同一个临时目录,再安装这三个精确 tarball:
|
|
59
71
|
|
|
60
72
|
```sh
|
|
61
73
|
pack_dir="$(mktemp -d)"
|
|
@@ -63,21 +75,21 @@ pack_dir="$(mktemp -d)"
|
|
|
63
75
|
(cd packages/skill-family-harness-node && pnpm pack --pack-destination "$pack_dir")
|
|
64
76
|
(cd packages/skill-family-engineering-kit && pnpm pack --pack-destination "$pack_dir")
|
|
65
77
|
mkdir "$pack_dir/consumer" && (cd "$pack_dir/consumer" && npm init -y)
|
|
66
|
-
(cd "$pack_dir/consumer" && npm install "$pack_dir/skill-family-contracts-0.
|
|
78
|
+
(cd "$pack_dir/consumer" && npm install "$pack_dir/skill-family-contracts-0.22.0.tgz" "$pack_dir/skill-family-harness-node-0.22.0.tgz" "$pack_dir/skill-family-engineering-kit-0.22.0.tgz")
|
|
67
79
|
```
|
|
68
80
|
|
|
69
81
|
发布后再使用 registry 坐标:
|
|
70
82
|
|
|
71
83
|
```sh
|
|
72
|
-
npm install --save-dev skill-family-engineering-kit@0.
|
|
73
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
74
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
75
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
76
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
77
|
-
npm exec --package=skill-family-engineering-kit@0.
|
|
84
|
+
npm install --save-dev skill-family-engineering-kit@0.22.0
|
|
85
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit --help
|
|
86
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit scaffold --root <empty-dir> --project-id my-project
|
|
87
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit adopt-plan --root <repo> --list-capabilities --all --scope all --locale zh-CN --uses ./uses.json
|
|
88
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit projection --root <repo>
|
|
89
|
+
npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit check --root <repo>
|
|
78
90
|
```
|
|
79
91
|
|
|
80
|
-
以上四条命令分别覆盖生成骨架、只读盘点、受管投影与诊断;零安装形式可用 `npm exec --package=skill-family-engineering-kit@0.
|
|
92
|
+
以上四条命令分别覆盖生成骨架、只读盘点、受管投影与诊断;零安装形式可用 `npm exec --package=skill-family-engineering-kit@0.22.0 -- skill-family-kit --help`。
|
|
81
93
|
|
|
82
94
|
### 三条采用旅程
|
|
83
95
|
|
|
@@ -171,12 +183,47 @@ Profile 必须显式提供,Kit 不默认绑定具体宿主。规范宿主 ID
|
|
|
171
183
|
|
|
172
184
|
`executableSha256` 只绑定启动前严格读取的字节,进程仍按路径启动;调用方须在版本观察和执行期间独占可执行文件命名空间。Foundation 保留 `session-*` 目录,调用方检查后清理独占的外层 `temporaryRoot`。
|
|
173
185
|
|
|
186
|
+
#### 0.21.0 候选:准备 Cursor 调用
|
|
187
|
+
|
|
188
|
+
`prepareHostVerification` 已随 0.21.0 发布,并在 0.22.0 中继续可用。它只为 `cursor` 准备单个已声明 Skill,使用随包 Descriptor(宿主描述符)和固定 `cursor-agent-print-v1` 驱动,不接受自定义驱动、参数、模型覆盖、凭据处理或领域验证器。原有七驱动的 `runHostVerification` 入口保持兼容。
|
|
189
|
+
|
|
190
|
+
下例变量由调用方提供,文档和夹具内容为不透明的 UTF-8 字符串或 Buffer。`skillMembers` 必须包含 `SKILL.md`,安装只覆盖声明成员。各根目录须已存在,并使用规范绝对路径;`sessionRoot` 必须为空且由调用方独占,工作区必须位于 `repositoryRoot` 内,也允许两者相等。调用方授权使用现有用户状态根,并独占可执行文件命名空间。
|
|
191
|
+
|
|
192
|
+
```js
|
|
193
|
+
import { prepareHostVerification, runHostVerification } from "skill-family-engineering-kit";
|
|
194
|
+
|
|
195
|
+
const prepared = await prepareHostVerification({
|
|
196
|
+
hostId: "cursor", verificationSetId,
|
|
197
|
+
candidate: { ref: candidateRef, manifest: candidateManifest },
|
|
198
|
+
skill: { root: skillRoot, entrySkill, members: skillMembers },
|
|
199
|
+
workloadDocument, fixtureFiles, // [{ path: "input.json", content: fixtureBytes }]
|
|
200
|
+
workspace: { repositoryRoot, root: workspaceRoot, protectedMembers },
|
|
201
|
+
platformManifest, effectivePrompt,
|
|
202
|
+
executable: { root: executableRoot, relPath: "cursor-agent" },
|
|
203
|
+
existingUserStateRoot, sessionRoot,
|
|
204
|
+
timeoutPolicy: { schemaVersion: 1, kind: "skill-family.timeout-policy", maxSeconds: 60, killGraceSeconds: 1 },
|
|
205
|
+
});
|
|
206
|
+
const result = await runHostVerification(prepared);
|
|
207
|
+
const stdout = result.streams
|
|
208
|
+
? await prepared.readInvocationStream(result, "stdout")
|
|
209
|
+
: null;
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
准备阶段复制输入字节、计算摘要并冻结请求与私有绑定。它在限定目录内写入文档、补齐缺失的 `.cursor/skills` 父目录,不启动进程,也不安装 Skill。执行阶段重新校验绑定,安装后的 Skill 摘要必须在任何探测前通过比较。字段错误、Schema 校验失败和机制失败分别沿用 `SFC2003`、`SFC1001`、`SFC2004`;准备过程的机制失败可能留下部分文件。
|
|
213
|
+
|
|
214
|
+
`readInvocationStream(result, "stdout" | "stderr")` 校验结果、请求绑定、准备时捕获的证据根、流摘要和字节数后返回 Buffer,不解析答案或判断领域正确性。缺少流或读取失败表示必要业务证据尚不可用,不能据此通过验收。
|
|
215
|
+
|
|
216
|
+
原四态仍为 `observed`、`rejected`、`failed`、`indeterminate`,其中 `observed` 不等于领域 PASS。只有经过校验的结果可以进入公共报告;准备对象、原始流及错误细节均须留在私有范围。
|
|
217
|
+
|
|
218
|
+
工作负载语义、候选引用与载荷的绑定、领域断言、发布新鲜度和资源清理由调用方负责。调用方须在准备前持有外层会话目录与工作区的句柄。结果确定后,先读取证据并确认没有进程继续使用目录,再清理现场。`indeterminate` 必须保留现场并完成要求的人工动作,不能用无条件清理包住整次调用。重试须创建新的目录并重新准备。本地夹具检查不构成真实宿主资格,也不证明模型经宿主发现调用了 Skill。
|
|
219
|
+
|
|
174
220
|
## 典型使用场景
|
|
175
221
|
|
|
176
222
|
- 新项目骨架:`scaffold`(不覆盖非空存量仓)。
|
|
177
223
|
- 存量采用盘点:`adopt-plan`(严格只读,不写文件、不自动迁移)。
|
|
178
224
|
- 受管投影:`projection` + Profile(不覆盖 handwritten 文件)。
|
|
179
225
|
- 工程诊断:普通 `check` 只读;`check relock` 执行显式受控写事务,`check qualification` 预检通过后可能启动绑定的 executable。
|
|
226
|
+
- 声明式治理诊断:版本检查显式选择 `policy: "declared"`,入口检查走 declared 子动作。目标只被静态读取;可选结论文件须由调用方明确授权输出位置。
|
|
180
227
|
|
|
181
228
|
## 边界机制
|
|
182
229
|
|
|
@@ -184,6 +231,7 @@ Profile 必须显式提供,Kit 不默认绑定具体宿主。规范宿主 ID
|
|
|
184
231
|
- `adopt-plan` 结构性只读:实现中不存在任何写调用,连临时文件都不产生;计划字节与 `scaffold` 同源(`describeSkeletonFiles` 单一事实源),因此「计划即动作」。默认可能启动一条冻结参数的只读 Git status 探测;CLI 的 `--no-git-spawn`(或 API 的 `allowGitSpawn: false`)可关闭该探测。dirty 仓运行前后字节级零变化。
|
|
185
232
|
- `projection` 采用两阶段执行:先对每个条目做路径分类、收容预检、自投影检查、manifest 授权检查、手写保护与冲突守卫;任一条目违规则整体拒绝、零写入。覆盖既有文件必须声明精确的 `expect.sha256` 前置状态;内容相同的既有文件是幂等 no-op。写入失败时尽力还原已覆盖文件的前置字节。
|
|
186
233
|
- 普通 `check` 只读且无写调用,也没有 `--fix/--apply/--repair` 模式(此类标志在入口处被拒绝)。默认可能启动一条冻结参数的只读 Git status 探测;CLI 的 `--no-git-spawn`(或 API 的 `allowGitSpawn: false`)可关闭该探测。`check relock` 执行显式受控写事务;`check qualification` 预检通过后可能启动绑定的 executable。Git 前置状态仅用文件系统事实加至多一次冻结参数矢量的只读 `git status --porcelain=2`(`--no-optional-locks` + `GIT_OPTIONAL_LOCKS=0`,不刷新索引)。
|
|
234
|
+
- 未发布的 declared 分支中,两个纯检查函数仍只读,也不探测 Git。只有调用方显式要求结论时,两个既有包装入口才通过独占创建产生本轮唯一新增持久副作用。
|
|
187
235
|
|
|
188
236
|
## 错误码与退出码
|
|
189
237
|
|
|
@@ -296,4 +344,4 @@ Foundation 本身不发起网络请求,但绑定的 executable 仍可能联网
|
|
|
296
344
|
|
|
297
345
|
独立入口 `runSkillFamilyDirectoryVerification({ request, bindings })` 固定 Kimi 生产 argv 与窄环境,并拒绝调用方 observation。原始 parser 通过生产进程路径验证,但受控 fixture 事件不会被提升为 `observed`;缺少官方 typed mapping 时,公共结果保持 `indeterminate` 和 manual candidate。
|
|
298
346
|
|
|
299
|
-
0.
|
|
347
|
+
声明式治理分支与结论输出随 0.22.0 制品发布;此前已发布的 0.21.0 制品不包含它们。远端可用性须由对应的 release-skill 发布后证据证明。本地测试或工作树 tarball 不等于契约接入完成、迁移完成或真实宿主资格。
|