dsh-completion-guard 0.5.3 → 0.6.1

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 CHANGED
@@ -2,6 +2,338 @@
2
2
 
3
3
  All notable changes to this project are documented here. The project is pre-1.0; release versions track the plugin lifecycle, not stabilised API promises.
4
4
 
5
+ ## 0.6.1 (2026-09-15)
6
+
7
+ Repairs attachment handling, conservative request interpretation, discovery pagination and evidence guidance after the Windows 0.6.0 review.
8
+
9
+ - **Attachments can be answered without inventing an execution action (W060-01).** Each asset needs an explicit `context_guard_interpret` record and a completed answer from the interpreting turn. This also lets a later turn handle an old attachment. Replay checks the item, revision, asset identity and call/result turn pair. Contradictions corrupt the projection; missing turn association records nothing. Asset receipts cannot carry clause partition fields. The record is the model's interpretation declaration, not independent proof of visual accuracy.
10
+ - **Unknown requests stay pending (W060-02).** Unrecognized clauses no longer default to execution. Explanation and mixed requests can use `context_guard_interpret` with `information_spans` and `unknown_spans`. The tool checks bounds and overlap; replay requires the receipt to match the submitted partition. Information children close with that turn's answer. Unknown and undeclared regions stay pending. Semantic classification remains the model's responsibility. Root clarification, confirmed rebind and clear remain available. Ordinary acknowledgments such as “当然。” are conversation, not obligations.
11
+ - **Discovery is paginated (W060-03).** `context_guard_prepare` lists eight items per page in stable order, with a revision-bound cursor and an explicit `semantic_action` filter. Follow `next_cursor` to traverse the applicable current-unit set; restart discovery when the revision changes. Historical items remain accessible by ID.
12
+ - **Read-only checks require one effect-role fact (W060-04).** Prepare and diagnosis now agree with the certifier. Stateful work still requires resolution, effect and state evidence; a read-only check no longer reports a missing historical prestate.
13
+ - **Unattributable shell effects remain uncertified (W060-05).** A matching command-head signal produces `execution_unattributable`, asking for read-only inspection without asserting that the action ran or did not run. Compound text is not scanned for proof. Guarded push, pull and fetch refuse an already-applied ref state before invoking the runner, reporting `action_already_applied` rather than minting replacement evidence. Ordinary work does not require additional Guard approval.
14
+
15
+ ### Compatibility and validation scope
16
+
17
+ The new interpretation records and reasons are additive. Attachment capture text retains its 0.6.0 bytes; an old log without interpretation records keeps pending attachments. Source checks, CI, frozen-artifact acceptance and native Web/Headless acceptance are separate results recorded in [LOCAL_ACCEPTANCE](docs/LOCAL_ACCEPTANCE.md). The local test-host cleanup now disposes persistence hosts explicitly to prevent FileHandle garbage-collection errors. No platform or publication result is implied by this changelog.
18
+
19
+ ## 0.6.0 third repair round after targeted review (2026-09-14)
20
+
21
+ Two findings from the targeted review of `fcc3813`, both fixed.
22
+
23
+ - **A certificate minted after adoption can no longer ratify the adoption.** The
24
+ closure check compared the certificate's revision with the revision frozen at
25
+ adoption, which a later log entry could satisfy: adopting a contract that
26
+ named a certificate that did not exist yet, then producing that certificate
27
+ afterwards, was granted. The adoption now resolves and freezes the closure
28
+ certificate's IDENTITY (its certification digest, epoch and revision) at the
29
+ adoption watermark, and the gate requires exactly that certificate. An
30
+ unresolvable reference is recorded as unresolved rather than left open for a
31
+ future entry to satisfy. A later release obligation still does not invalidate
32
+ the frozen candidate closure. The frozen certificate must also match the
33
+ candidate revision at adoption; a certificate already stale before adoption
34
+ is refused.
35
+ - **Invalid adoption input no longer poisons a valid contract.** A root
36
+ `/context-guard release adopt` with a malformed payload was treated as damaged
37
+ persisted state, so one typo permanently blocked every later publication. A
38
+ root command the user typed badly is a usage diagnostic; only an unreadable
39
+ persisted reservation, settlement or contract record marks the release state
40
+ damaged. A malformed plugin-notice record still fails closed.
41
+
42
+ New regression cases: a certificate minted after adoption is refused (with the
43
+ projection still valid), a certificate that existed at adoption is frozen by
44
+ identity and survives a later obligation,
45
+ and invalid/mistyped adopt input leaves a valid contract usable.
46
+
47
+ ## 0.6.0 second repair round after follow-up review (2026-09-14)
48
+
49
+ A follow-up review of the repair commit found five remaining defects in the new
50
+ wiring. All five reproduced and are fixed. The reviewer's counterexamples are
51
+ kept as permanent regression cases in the suites they belong to.
52
+
53
+ ### Fixed
54
+
55
+ - **Adding the v5 boundary no longer answers a pre-v5 question.** Deliveries were
56
+ only gated by the watermark of their own turn; appending the boundary at the
57
+ end of a v4 log therefore made an old turn's answer retroactively close an
58
+ obligation the old rules had left open. A delivery now counts only when its
59
+ turn ended AFTER the boundary, and only obligations captured after the
60
+ boundary can be closed by one.
61
+ - **The real publish producer now observes everything the contract names.** The
62
+ trusted reader fills the registry from the canonicalized resolution (it was
63
+ simply missing, so any contract naming a registry could never be granted), and
64
+ the ref is resolved by the runtime from the ADOPTED CONTRACT with the audited
65
+ git executable — a closed, reachable path, instead of a command-manifest field
66
+ the publish manifest schema rejects. A ref that resolves to a commit different
67
+ from the artifact's embedded `gitHead` is refused.
68
+ - **A new release instruction no longer invalidates the certificate it needs.**
69
+ The closure check demanded the CURRENT contract revision, so capturing the
70
+ publish obligation invalidated the very certificate the release was about to
71
+ use, and certifying afterwards required the publish to be complete first. The
72
+ contract now freezes the candidate scope's revision at adoption and requires
73
+ the closure certificate to be the one that certified exactly that revision.
74
+ A later obligation does not re-validate a moved candidate, and a certificate
75
+ minted after adoption is still refused.
76
+ - **Read-only release queries no longer poison the release state.** `release
77
+ status` (and an omitted verb) is a read-only command; an unknown verb is a
78
+ usage diagnostic. Only an unreadable persisted record marks the release state
79
+ damaged, so a plain query can no longer block every future publication
80
+ irreversibly.
81
+ - **There is now a callable trusted recovery entry.** `context_guard_release`
82
+ reads the release state and, for `reconcile`, reads the external identity
83
+ through the same audited registry adapter the publish path uses and settles
84
+ the reservation only when the readback names the bytes the contract — or the
85
+ reservation's recorded SRI — froze. It never re-sends a release, and it works
86
+ after a restart and for a revoked-but-in-flight attempt, because revocation
87
+ withdraws future authority rather than the duty to reconcile an effect that
88
+ may already have happened. A contract that froze only the byte SHA-256 stays
89
+ reconcilable and can still DETECT a mismatched readback.
90
+ - **A presented proof is now part of the persisted contract.** The checkpoint
91
+ call records its `proof` manifest, and the replay re-binds it at that call's
92
+ own watermark and requires the recorded proof state to match what the log
93
+ implies. A tampered or omitted proof — with a result that still claims it was
94
+ bound — now fails closed with `proof_replay_mismatch` instead of restoring a
95
+ valid certificate. Signing, persistence and replay use the same call argument,
96
+ and the Goal gate consumes only a certificate whose proof still binds.
97
+
98
+ ### Verification
99
+
100
+ - The reviewer's five follow-up counterexamples pass and remain as regression
101
+ cases: pre-v5 delivery, read-only status, the frozen candidate closure, the
102
+ observed registry, and persisted proof tampering.
103
+ - New: `tests/tools/v060-release-chain.test.ts` — the acceptance the review asked
104
+ for. One test drives a real root publish instruction, a real certified
105
+ preparation closure, a real contract adoption, a real tgz and resolution
106
+ through the registered evidence tool, and then the registered action tool
107
+ consulting the RUNTIME's own release gate: it reserves, executes once, leaves
108
+ the attempt in flight, reconciles it through the registered recovery tool, and
109
+ refuses the replay as a consumed ticket. Only the npm executor and the
110
+ registry HTTP client are replaced; the authorization gate, records, producers
111
+ and replay are production code. Two further cases cover the revoked-but-in-
112
+ flight restart recovery and a mismatching readback.
113
+ - The proof suite gained the missing-proof, Goal-consumption and
114
+ accurate-evidence-boundary cases.
115
+
116
+ ### Evidence boundary
117
+
118
+ The release chain test pins the audited host cohort through an explicit
119
+ `RuntimeExecutorSeams.hostLock` acceptance seam, because the host-lock
120
+ migration revalidation reads real filesystem roots. That replaces ONLY the
121
+ host-lock evaluation; the release gate, the reservation and settlement records,
122
+ the evidence producers and the replay are the production ones, and the host lock
123
+ keeps its own suites and native acceptance.
124
+
125
+ ## 0.6.0 repairs after concentrated review (2026-09-14)
126
+
127
+ A concentrated review of the `0dce898` candidate produced fifteen targeted
128
+ counterexamples; all fifteen reproduced a real defect. This section records the
129
+ repair. The stable finding numbers (`F01`–`F08`, `R1`–`R15`) are the reviewer's.
130
+
131
+ ### Fixed
132
+
133
+ - **F01 certificate replay was timing-dependent.** Deliveries were applied after
134
+ the whole log was replayed, so a checkpoint recorded in a later turn was
135
+ re-verified while the delivered answer still looked open, and the v5 rule set
136
+ was applied to the whole log rather than from the boundary onwards. Delivery
137
+ is now applied at the watermark of the turn that produced it and the rule mode
138
+ switches at the boundary event, which makes a projection equal to the
139
+ projection of its own prefix. Certificate comparison is also field-semantic
140
+ now: identical certificates replay identically regardless of JSON property
141
+ order, while an extra, missing, or tampered field still fails.
142
+ - **F02 delivery accepted late and non-final answers.** The final answer must
143
+ appear before the turn's own `turn/end`, must sit in the highest step the host
144
+ actually entered, and the turn must have exactly one completed end and a
145
+ recorded start. Late text, an intermediate step, a repeated or abnormal end,
146
+ and an aborted turn all deliver nothing.
147
+ - **F03 the switch test ignored descendants, and an item reference crashed.**
148
+ The handover test now uses the same closure as the certificate, so a parent
149
+ with a pending delegated child is not treated as finished, and the item-ID
150
+ pattern is a global capture that distinguishes live lineage references from
151
+ unknown or historical IDs.
152
+ - **F04 release identity was not really bound.** A candidate now has separate,
153
+ named identities — commit, ref, repository, package, version, artifact
154
+ SHA-256, npm SRI, registry — and each is compared with its own observed value
155
+ read from a trusted producer (the exact tgz bytes and the local repository),
156
+ never with a model-supplied string. Readiness and closure references must
157
+ resolve to real certified facts, the resolved target must be the artifact the
158
+ contract names, and a contract that names no artifact digest is refused
159
+ outright so omitting one cannot be a bypass. A registry readback that names
160
+ different bytes is not a settlement.
161
+ - **F05 an unknown effect could be re-sent, and a late readback was discarded.**
162
+ Outcomes are distinguished: `not_effected` is a proven pre-effect refusal and
163
+ releases the one-shot lock, while `failed`/`unknown`/`unconfirmed` keep it and
164
+ refuse a re-send. Settlements are reconciled rather than de-duplicated, so a
165
+ trusted readback settles an earlier unconfirmed attempt, and a settled release
166
+ is never downgraded. Damaged release state now blocks release operations
167
+ (`release_state_damaged`) without touching ordinary work.
168
+ - **F06 adoption reported an error and revocation did not exist.** The public
169
+ command validates and reports exactly what the durable root command adopts,
170
+ and `/context-guard release revoke <contract_id>` records a durable revocation
171
+ that keeps the audit trail, denies the next effect, and still shows an
172
+ in-flight reservation whose readback is owed.
173
+ - **F07 proof could be satisfied about the wrong subject.** Binding now runs the
174
+ whole chain: the item's own frozen subject and scope, the fact's qualification
175
+ under the ordinary evidence rules, the declared source, the declared operation
176
+ for every kind, the order of an input check before the effect, and the real
177
+ coverage set behind a declared scope digest. A manifest and a fact that agree
178
+ with each other but not with the user's obligation are rejected.
179
+ - **F08 the proof entry was not reachable from production.** The v2 binder is now
180
+ wired into `context_guard_checkpoint` (an optional `proof` manifest is bound
181
+ before any certificate and its state is reported), the v2 fixture evaluates
182
+ each release probe at its own point in the log, mints real closure
183
+ certificates, and carries a real read fact for S09, and a dedicated
184
+ production-chain suite drives producer → persisted log → derive → checkpoint →
185
+ replay.
186
+
187
+ ### Scope rulings (coordinator, 2026-09-14)
188
+
189
+ Two scope facts were decided once, and both are recorded as fact rather than as
190
+ a general parity claim:
191
+
192
+ 1. **The v2 shared fixture stays a DSH-authored candidate and cross-language
193
+ parity stays open.** The upstream repository has not frozen a v2
194
+ specification, so there is nothing to mirror. The plan's shared gate is
195
+ therefore recorded as a cross-repository pending item owned by the upstream.
196
+ 2. **The release profile's protectable surface is `npm_publish` only.** The
197
+ `git_tag` and GitHub Release routes are NOT claimed to be blocked by the
198
+ host: the plugin reports them as `release_operation_unrouted` with
199
+ `attribution: scope_reduction`, because building the Guard-owned route is the
200
+ work that would make them protectable. Only a composite runner is reported as
201
+ an opaque host boundary. The coverage table is machine-readable so this
202
+ distinction cannot be lost in prose.
203
+
204
+ The plugin therefore does not claim "C01–C12 core alignment" with Codex Context
205
+ Guard, and it does not claim a complete release coverage surface.
206
+
207
+ ### Verification
208
+
209
+ The reviewer's fifteen counterexamples are kept as
210
+ `tests/domain/review-counterexamples.test.ts` and now pass; the expectations
211
+ that the repair deliberately changed are marked in place with the reason. New
212
+ coverage: `tests/domain/v060-proof-production-chain.test.ts` (the proof entry
213
+ through real tool registration), the rewritten release/migration suite (26
214
+ cases, including a real certified closure and every identity refusal), and the
215
+ extended v2 fixture (S09 proof binding, per-timeline release probes, and the
216
+ scope-attribution table).
217
+
218
+ ## 0.6.0 - 2026-09-14
219
+
220
+ This release makes ordinary DSH work enter, execute, deliver, and resume under
221
+ one set of rules. It also closes the substantive gaps against the shared
222
+ Context Guard semantics. Everything before the new protocol boundary keeps its
223
+ old meaning; nothing is re-read or re-labelled.
224
+
225
+ ### Added
226
+
227
+ - **Answer delivery is tracked separately from execution certification.** A
228
+ question or explanation is closed only by the host's own evidence: an
229
+ `assistant/message` in the turn's final step, with no interrupted marker,
230
+ followed by `turn/end` with `reason.kind: "completed"`. A status summary, a
231
+ draft, an intermediate reply, another turn's answer, a subagent's answer, or
232
+ an aborted turn never closes anything. `answered` means "the answer was
233
+ handed over" — never that it was right, complete, or executed.
234
+ - **Work units with a required-descendant closure.** Tasks are grouped into
235
+ derived units. A delegation-marked instruction opens a child unit whose open
236
+ work is required by the parent's closure, so delegating a sub-task can never
237
+ drop the parent's own work; an ordinary task switch opens a sibling that does
238
+ not block the newer task. A subagent's result is bounded evidence: it is
239
+ recorded and visible, and it never closes a parent obligation.
240
+ - **Ancestor constraints stay in force.** A prohibition or an unsatisfied
241
+ condition the root declared in an earlier unit continues to govern the same
242
+ action and target in a later one, and the certifier refuses those bindings
243
+ before examining evidence.
244
+ - **Proof v2 with a real capability matrix.** Five new proof kinds — input
245
+ asset check, output visual readback, object/URL readback, execution fact, and
246
+ external fact — each bind a current subject, a declared source, and a real
247
+ operation. A successful tool call is only ever an execution fact: a browser
248
+ call that merely returned cannot prove an image was looked at, an input asset
249
+ check must be a prior-state fact, and a delegated subagent result is never a
250
+ proof source. When the installed host exposes no producer, the result is
251
+ `unavailable`, never a silent pass. The old three-kind manifest and its digest
252
+ domain are unchanged and remain readable.
253
+ - **Explicit release tickets.** A release contract is adopted only by an
254
+ explicit root command. Once adopted, each operation spends one reservation,
255
+ written before the effect and settled afterwards from a trusted readback.
256
+ Wrong candidate SHA, ref, artifact digest or version, an expired or
257
+ unevaluable ticket, a consumed ticket, a replay, an operation that is already
258
+ in flight, an unresolved target, and an opaque runner are all refused before
259
+ any effect. A "release" keyword, a loaded Skill, or an installation never
260
+ adopts a contract.
261
+ - **A strict proof tier.** On top of the default `standard` tier, a visual or
262
+ complete-scope verification the user explicitly asked for must be discharged
263
+ by a real readback fact. Strict adds no approval step to ordinary actions, and
264
+ installing never enters the `release` tier.
265
+ - **One diagnosis language.** Every incomplete item now reports one of seven
266
+ classes — parameter missing, source insufficient, condition unmet, producer
267
+ capability unavailable, historical gap, integrity failure, policy boundary —
268
+ next to its exact reason code. `/context-guard migration` reports which rule
269
+ set is in force, which obligations keep their pre-0.6.0 rules, and what a
270
+ rollback requires.
271
+ - **A host-neutral v2 conformance fixture** covering S01–S12 through the real
272
+ derive/delivery/closure/Goal chains. Every expectation is compared against a
273
+ value computed from the events and the production projection alone; the runner
274
+ never reads an expectation to decide an actual result.
275
+
276
+ ### Changed
277
+
278
+ - A document "update" or "modify" is decided by the object, not by the verb:
279
+ a recognized document noun becomes a bounded `modify` the assistant may
280
+ resolve to an exact file inside the captured scope and type, while an
281
+ unrecognized object keeps its honest unresolved reading instead of being
282
+ forced into an action.
283
+ - A trusted answer from the host's own question tool now narrows where a
284
+ bounded file choice may land, and is recorded separately from sandbox
285
+ approvals. Pasted or restated answer text forms nothing.
286
+ - A later root instruction that contains a pending generic obligation verbatim
287
+ supersedes it atomically, keeping both revisions. Explanations, prohibitions
288
+ and waits never delete an obligation by similar wording.
289
+ - `/context-guard status` reports the active policy tier, the reason-class
290
+ histogram, the migration facts, and the release state.
291
+
292
+ ### Fixed
293
+
294
+ - The first step of a session now sees the input persisted in that same step,
295
+ and a failed durability flush reports an explicit unavailability instead of
296
+ serving a stale projection.
297
+ - The v2 conformance runner computes `interpreted`, `closure`, `delivery`,
298
+ `turn_bound` and the correction decision from production state instead of from
299
+ the fixture's own expectations.
300
+ - A malformed release record is reported as a bounded diagnostic and never
301
+ marks the whole session corrupt, so damaged release state cannot block
302
+ unrelated ordinary work.
303
+
304
+ ### Migration and rollback
305
+
306
+ - The 0.6.0 semantics start at the new `Context Guard protocol boundary:
307
+ v5.0.0` notice, written at the first real root-input step of a new session.
308
+ An older binary ignores that notice, so a rollback fails closed instead of
309
+ misreading new records.
310
+ - A session that never wrote the boundary keeps the previous whole-session
311
+ contract, version-1 certificates, and its old digest domains.
312
+ - A session that wrote it keeps pre-boundary obligations under their birth
313
+ rules while new work uses units, delivery and version-2 certificates.
314
+ - Rolling back to 0.5.x requires restoring a 0.5.x state snapshot. Replaying a
315
+ 0.6.0 log with 0.5.x fails closed with `certificate_replay_mismatch`; never
316
+ migrate new-schema data down by hand.
317
+
318
+ ### Not yet established
319
+
320
+ - **Cross-language parity and the canonical mirror are not done.** The
321
+ upstream `codex-context-guard` repository has not landed a frozen v2 fixture,
322
+ so the v2 file here is explicitly a DSH-authored *candidate*
323
+ (`2.0.0-candidate.1`, `status: "dsh-candidate"`). `UPSTREAM_PIN.json` still
324
+ pins the unchanged v1 mirrors and is not refreshed by this release.
325
+ - The `release` tier protects only surfaces Guard itself routes. Publishing an
326
+ npm artifact through the Guard-owned action tool is protected; `git tag`, the
327
+ GitHub Release operations, and any composite runner have no interception
328
+ point in this host and are refused before effect rather than pretended to be
329
+ covered. A trusted in-process caller that bypasses Guard entirely is a host
330
+ trust boundary, documented rather than denied.
331
+ - After a publish, the settlement stays `unconfirmed` unless the registry
332
+ readback producer answers; an unconfirmed operation is never re-sent.
333
+ - Deterministic tests, CI, native macOS/Windows acceptance, publication and
334
+ installation are separate evidence scopes. This release records source and
335
+ deterministic evidence; native acceptance and publication follow separately.
336
+
5
337
  ## 0.5.3 - 2026-09-14
6
338
 
7
339
  ### Fixed
@@ -2,6 +2,122 @@
2
2
 
3
3
  本项目的重要变化记录在这里。项目仍处于 1.0 之前;版本号跟踪插件生命周期,不代表 API 已稳定。
4
4
 
5
+ ## 0.6.1(2026-09-15)
6
+
7
+ 修复 Windows 0.6.0 复核发现的附件处理、保守解释、发现分页和证据诊断问题。
8
+
9
+ - **附件可以通过解释与回答关闭,无需改绑执行动作(W060-01)。** 每项附件需要 `context_guard_interpret` 解释记录,以及解释所在 turn 的正常回答;旧附件也可由后续 turn 处理。重放核对条目、revision、资产身份与调用/结果 turn 对。身份或 turn 矛盾使 projection 无效,缺失 turn 关联则不记录。资产回执不得带子句划分字段。解释记录是模型的声明,不是视觉准确性的独立证明。
10
+ - **无法解析的请求保持 pending(W060-02)。** 未知子句不再默认可执行。解释和混合请求可通过 `context_guard_interpret` 提交 `information_spans` 与 `unknown_spans`;工具检查范围和重叠,重放要求回执与调用划分一致。信息子项由解释 turn 的回答关闭,未知与未申报区域继续保留。划分的语义正确性仍由模型负责。根用户澄清、确认重绑定与 clear 通路保留;“当然。”等普通应答属于会话内容,不形成义务。
11
+ - **发现结果支持完整分页(W060-03)。** `context_guard_prepare` 按稳定顺序每页列出八项,提供绑定 revision 的 cursor 和明确的 `semantic_action` 筛选。沿 `next_cursor` 遍历当前单元适用集合;revision 改变时重新发现。历史项仍可按 ID 查询。
12
+ - **只读验证只需一条 effect 角色事实(W060-04)。** prepare、诊断与认证器保持一致。状态变更仍需 resolution、effect、state 证据;只读检查不再被误报为缺少历史前态。
13
+ - **无法归属的 shell 执行保持未认证(W060-05)。** 匹配的命令头信号触发 `execution_unattributable`,要求先只读核实现状,不断言动作已发生或未发生。复合命令文本不作为执行证明。受保护的 push、pull、fetch 在引用状态已满足时拒绝调用 runner,报告 `action_already_applied`,不通过重做补造证据。普通工作不需要额外 Guard 审批。
14
+
15
+ ### 兼容与验证范围
16
+
17
+ 解释记录和原因码为增量。附件捕获文本保持 0.6.0 字节;旧日志没有解释记录时,附件继续 pending。源码检查、CI、冻结制品和原生 Web/Headless 验收分别记录在[验收记录](docs/LOCAL_ACCEPTANCE.md)。测试宿主清理现在显式释放持久化宿主,避免 FileHandle 被垃圾回收时报错。本节不代表任何平台验收或发布已经完成。
18
+
19
+ ## 0.6.0 定向复核后的第三轮修复(2026-09-14)
20
+
21
+ 针对 `fcc3813` 定向复核的两项发现,均已修复。
22
+
23
+ - **采用之后签发的证书不再能追认该次采用。** 闭包检查只比较证书 revision 与采用时冻结的 revision,而后续日志条目可以满足它:先采用一个引用了尚不存在证书的契约,事后再产生那张证书,会被放行。现在采用在**采用水位**解析并冻结闭包证书的**身份**(certification digest、epoch、revision),门要求必须正是那一张;无法解析的引用被记为未解析,而不是留给未来条目补齐。后续发布义务仍不会使冻结的候选闭包失效。冻结证书还必须匹配采用时的候选 revision;采用前已经过期的证书会被拒绝。
24
+ - **无效的采用输入不再毒化有效契约。** 根命令 `/context-guard release adopt` 载荷畸形时被当作损坏的持久状态,一次笔误即永久阻断后续所有发布。用户手输的根命令错误属于用法诊断;只有**无法读取的持久**预约/结算/契约记录才标记发布状态损坏。畸形的 plugin notice 记录仍 fail-closed。
25
+
26
+ 新增回归:采用后签发 → 拒绝(投影仍 valid);采用时已存在的证书按身份冻结,且后续新增义务不会使其失效;无效/错字段 adopt 输入不影响有效契约可用。
27
+
28
+ ## 0.6.0 跟进复核后的第二轮修复(2026-09-14)
29
+
30
+ 对修复提交的跟进复核在新接线中发现 5 个残留缺陷,全部复现并已修复。复核者的反例按归属保留为常驻回归用例。
31
+
32
+ ### 修复
33
+
34
+ - **追加 v5 边界不再回答 v5 之前的问题。** 交付此前只受自身 turn 水位约束;在 v4 日志末尾追加边界,会让旧 turn 的回答追溯性关闭旧规则下仍开放的义务。现在只有 turn 在边界**之后**结束的交付才算数,且只有边界之后捕获的义务才可能被交付关闭。
35
+ - **真实发布生产者补齐合同声明的全部身份。** 可信读取器现在从规范化后的 resolution 填充 registry(此前完全缺失,凡声明 registry 的合同都无法被授权);ref 改由运行时依据**已采用契约**用审计过的 git 可执行程序解析——这是一条闭合且可达的路径,而不是发布 manifest schema 会拒绝的 command-manifest 字段。解析出的提交与制品内嵌 `gitHead` 不一致时拒绝。
36
+ - **新的发布指令不再使它自己需要的证书失效。** 闭包检查原本要求**当前**合同 revision,因此捕获发布义务会使发布即将使用的证书失效,而"先签后发"又要求发布已经完成。现在契约在采用时**冻结候选范围 revision**,并要求闭包证书正是认证该 revision 的那一张。后续义务不会为已变化的候选重新背书,采用之后签发的证书仍被拒绝。
37
+ - **只读发布查询不再毒化发布状态。** `release status`(以及省略动词)是只读命令;未知动词只是用法诊断。只有**无法读取的持久记录**才标记发布状态损坏,因此一次普通查询不再不可逆地阻断后续所有发布。
38
+ - **新增可调用的可信恢复入口。** `context_guard_release` 读取发布状态;`reconcile` 通过与发布路径相同的审计 registry 适配器读取外部身份,并且只在回读指向合同(或预约记录中的 SRI)所冻结的字节时才结算。它绝不重发发布,且在重启后、以及对**已撤销但仍在执行中**的尝试都可用——撤销收回的是后续授权,而不是对可能已发生效果的核对义务。仅冻结字节 SHA-256 的合同仍可被核对,并且仍能**检测**回读不一致。
39
+ - **递交的证明现在属于持久合同。** checkpoint 调用会记录其 `proof` manifest,重放在该调用自身水位处重新绑定,并要求记录中的证明状态与日志蕴含的一致。被篡改或被省略、而结果仍声称已绑定的证明,现在以 `proof_replay_mismatch` fail-closed,而不是恢复出一张有效证书。签发、落盘与重放使用同一份调用参数,Goal 门也只消费证明仍能绑定的证书。
40
+
41
+ ### 验证
42
+
43
+ - 复核者的 5 个跟进反例全部通过,并按归属保留为回归用例:pre-v5 交付、只读 status、冻结的候选闭包、观测到的 registry、持久证明篡改。
44
+ - 新增 `tests/tools/v060-release-chain.test.ts`——复核要求的验收:同一个测试串起真实 root 发布指令、真实已认证准备闭包、真实契约采用、经注册取证工具产生的真实 tgz 与 resolution,随后由注册的动作工具调用**运行时自身的发布门**:写入预约、执行一次、保持 in-flight、经注册恢复工具结算,并把重放作为已消费票据拒绝。只替换 npm 执行器与 registry HTTP 客户端;授权门、记录、生产者与重放都是生产代码。另有两例覆盖"已撤销但在执行中"的重启恢复与回读不一致。
45
+ - 证明套件新增遗漏证明、Goal 消费,以及准确的证据边界说明。
46
+
47
+ ### 证据边界
48
+
49
+ 发布链路测试通过显式的 `RuntimeExecutorSeams.hostLock` 验收接缝固定审计队列,因为宿主锁迁移复核会读取真实文件系统根。该接缝**只**替换宿主锁求值;发布门、预约与结算记录、证据生产者与重放仍是生产代码,宿主锁也有自己的套件与原生验收。
50
+
51
+ ## 0.6.0 集中复核后的修复(2026-09-14)
52
+
53
+ 针对 `0dce898` 候选的集中复核给出 15 个定向反例,15 个全部复现出真实缺陷。本节记录修复。编号(`F01`–`F08`、`R1`–`R15`)沿用复核者原编号。
54
+
55
+ ### 修复
56
+
57
+ - **F01 证书重放依赖时间点。** 交付原本在整个日志重放后统一应用,因此后续 turn 记录下来的证书在重放时,已交付的回答仍显示为未决;v5 规则也按整段日志生效,而不是从边界开始。现在交付在其所属 turn 的结束水位处应用,规则档在边界事件处切换,投影因此等于自身前缀的投影。证书比较改为按字段语义:字段顺序不同的同一证书重放结果一致,而多字段、少字段或被篡改仍然失败。
58
+ - **F02 交付接纳迟到与中间回答。** 最终回答必须出现在该 turn 自己的 `turn/end` 之前、位于宿主实际进入的最高 step,且该 turn 只能有一个 completed 结束并有 start 记录。迟到文本、中间 step、重复或异常结束、被中止的 turn 都不产生交付。
59
+ - **F03 切换判断漏掉后代,条目引用会抛异常。** 交接判断现在使用与证书相同的闭包:父项自身完成但委派子项仍未完成时不再被当作已完成;条目 ID 正则改为全局捕获,并区分仍在世系中的活条目与不存在或历史条目。
60
+ - **F04 发布身份未真正绑定。** 候选现在拆成独立命名的身份——commit、ref、repository、包名、版本、制品 SHA-256、npm SRI、registry——每一项都与可信生产者(精确 tgz 字节与本地仓库)实际观测到的同名值比较,绝不与模型提供的字符串比较。readiness/closure 引用必须解析到真实的已认证事实;解析出的目标必须就是契约所指制品;未绑定任何制品摘要的契约直接被拒绝,因此"省略摘要"不构成绕过。回读若指向不同字节,不构成结算。
61
+ - **F05 未知效果可能重发,迟到的回读被丢弃。** 结果状态被区分:`not_effected` 是效果前被证实的拒绝,释放一次性锁;`failed`/`unknown`/`unconfirmed` 保留锁并拒绝重发。结算改为"归并"而非按 callId 去重,因此可信回读可以把此前的 unconfirmed 尝试结算为 settled,而 settled 永不被降级。损坏的发布状态现在只封锁发布操作(`release_state_damaged`),不影响普通工作。
62
+ - **F06 采用命令报错,撤销不存在。** 公开命令现在校验并如实报告持久根命令实际采用的内容;`/context-guard release revoke <contract_id>` 记录持久撤销,保留审计、拒绝下一次效果,并继续显示仍欠回读的 in-flight 预约。
63
+ - **F07 证明可能被错误主体满足。** 绑定改为完整链路:条目自身冻结的主体与范围、事实按普通证据资格规则校验、声明的来源、每一类声明的操作、输入检查相对效果的先后、以及范围摘要背后真实的覆盖集合。manifest 与事实互相自洽但与用户义务不符时一律拒绝。
64
+ - **F08 证明入口未接入生产。** v2 绑定器已接入 `context_guard_checkpoint`(可选 `proof` manifest 在签发任何证书之前绑定并报告状态);v2 fixture 在每个 release 探针自己的时间点求值、铸造真实闭包证书、为 S09 携带真实读事实;并新增专职生产链路测试:producer → 持久日志 → derive → checkpoint → 重放。
65
+
66
+ ### 范围裁定(协调者,2026-09-14)
67
+
68
+ 两项范围事实一次裁定,均按事实记录,而不是作为整体 parity 声明:
69
+
70
+ 1. **v2 共享 fixture 保持 DSH 产出的候选身份,跨语言 parity 保持待办。** 上游尚未冻结 v2 规范,因此没有可镜像的对象;计划中的共享门因此记录为归上游所有的跨仓库待办项。
71
+ 2. **发布档可保护表面仅 `npm_publish`。** `git_tag` 与 GitHub Release 路由**不**声称被宿主阻断:插件把它们报告为 `release_operation_unrouted` 且 `attribution: scope_reduction`,因为补建 Guard 自有路由才是让它们可保护的工作。只有复合 runner 报告为不透明宿主边界。覆盖面表是机器可读的,这一区分不会在文字中丢失。
72
+
73
+ 因此本插件不宣称与 Codex Context Guard "C01–C12 核心对齐",也不宣称完整的发布覆盖面。
74
+
75
+ ### 验证
76
+
77
+ 复核者的 15 个反例保留为 `tests/domain/review-counterexamples.test.ts`,现已全部通过;本次修复刻意改动的期望在原位标注了原因。新增覆盖:`tests/domain/v060-proof-production-chain.test.ts`(经真实工具注册的证明入口)、重写的发布/迁移套件(26 例,含真实已认证闭包与逐项身份拒绝)、以及扩展后的 v2 fixture(S09 证明绑定、逐时间点 release 探针、范围归因表)。
78
+
79
+ ## 0.6.0 - 2026-09-14
80
+
81
+ 本版让普通 DSH 任务在进入、执行、交付与恢复时遵循同一套规则,并补齐与共享 Context Guard 语义之间的实质差距。新协议边界之前的一切保持原有含义,既不重解释也不重新贴标签。
82
+
83
+ ### 新增
84
+
85
+ - **回答交付与执行认证分开记录。** 问答或讲解只由宿主的自身事实关闭:同一 turn 最大 step 的 `assistant/message`、无 interrupted 标记,且其后存在 `reason.kind: "completed"` 的 `turn/end`。状态汇报、草稿、中间回复、其它 turn 的回答、子代理回答和中止的 turn 都不会关闭任何条目。`answered` 只表示"回答已交付",不表示正确、完整或已执行。
86
+ - **工作单元与必需后代闭包。** 任务被归入派生的单元。带委派标记的指令会开启一个子单元,其未完成义务进入父单元闭包,因此委派子任务绝不会丢掉父任务自身的工作;普通任务切换开启的是同级单元,不阻塞更新的任务。子代理结果是**有界证据**:记录并可见,但永远不能关闭父项。
87
+ - **祖先约束持续生效。** 根用户在前一单元声明的禁止项或未满足条件,对后续单元中同一动作与目标的义务继续生效;认证器在检查证据之前就拒绝这类绑定。
88
+ - **证明 v2 与真实能力矩阵。** 新增输入资产检查、生成结果视觉回读、对象/URL 回读、执行事实、外部事实五类证明,每类都绑定当前主体、声明的来源和真实操作。工具调用成功只构成执行事实:一次仅仅返回的浏览器调用不能证明看过图,输入资产检查必须是前置状态事实,子代理结果不能作为证明来源。已安装宿主没有对应生产者时结论是 `unavailable`,绝不静默通过。原有三类 manifest 及其摘要域不变,仍可读取。
89
+ - **显式发布票据。** 发布契约只能由用户显式根命令采用。采用后每个操作消耗一次预约记录:效果前写入,效果后依据可信回读结算。错候选 SHA、错 ref、错制品摘要或版本、过期或无法评估的有效期、已消费票据、重放、已在执行中的操作、未解析目标和不透明 runner 都在任何副作用之前被拒绝。"release" 关键词、加载 Skill 或安装不会采用契约。
90
+ - **strict 证明档位。** 在默认 `standard` 之上,用户明确要求的视觉或完整范围验证必须由真实回读事实兑现。strict 不为普通动作新增审批,安装也绝不隐式进入 `release` 档。
91
+ - **统一诊断语言。** 每个未完成条目在精确原因码之外,还会给出七类标签之一:参数缺失、来源不足、条件未满足、生产者能力缺失、历史缺口、完整性失败、策略边界。`/context-guard migration` 报告当前生效的规则集、仍按 0.6.0 之前规则保留的义务,以及回滚所需的动作。
92
+ - **宿主中立的 v2 一致性 fixture**,覆盖 S01–S12,且全部经过真实 derive/交付/闭包/Goal 链路。每条期望都只与"由事件和生产投影独立算出"的实际值比较;runner 绝不读取期望来决定实际值。
93
+
94
+ ### 变化
95
+
96
+ - 文档"更新/修改"由对象决定,而不由动词决定:可识别的文档名词变成 `modify`,助手可在捕获的范围与类型内解析到具体文件;无法识别的对象保持诚实的未决读法,而不是被强行归为某个动作。
97
+ - 宿主自身问答工具返回的可信答案现在会收窄有界文件选择的落点,并与沙箱审批分开记录。转贴或复述的回答文本不构成任何东西。
98
+ - 后续根指令逐字包含某条未决通用义务时,会原子替换它并保留新旧 revision;解释、禁止和等待绝不因相似措辞删除义务。
99
+ - `/context-guard status` 报告当前策略档、原因类直方图、迁移事实与发布状态。
100
+
101
+ ### 修复
102
+
103
+ - 会话首步现在能看到同步持久化的输入;flush 失败会明确报告不可用,而不是返回陈旧投影。
104
+ - v2 一致性 runner 的 `interpreted`、`closure`、`delivery`、`turn_bound` 与纠正判断改为从生产状态计算,不再取自 fixture 自身的期望。
105
+ - 损坏的发布记录只产生一条有界诊断,不再把整个会话标为 corrupt,因此损坏的发布状态不会阻塞无关的普通工作。
106
+
107
+ ### 迁移与回滚
108
+
109
+ - 0.6.0 语义从新的 `Context Guard protocol boundary: v5.0.0` notice 开始,写在新会话首个真实根输入步之前。旧二进制会忽略该 notice,因此回滚方向是 fail-closed,而不是误读新记录。
110
+ - 从未写过该边界的会话继续沿用整会话契约、版本 1 证书与旧摘要域。
111
+ - 写过该边界的会话中,边界之前的义务保留出生规则,新工作使用工作单元、交付与版本 2 证书。
112
+ - 回滚到 0.5.x 必须恢复 0.5.x 的状态快照。用 0.5.x 重放 0.6.0 日志会以 `certificate_replay_mismatch` fail-closed;切勿手工把新 schema 数据降级。
113
+
114
+ ### 尚未成立
115
+
116
+ - **跨语言 parity 与正式镜像尚未完成。** 上游 `codex-context-guard` 尚未落地冻结的 v2 fixture,因此本仓库的 v2 文件明确是 DSH 产出的**候选**(`2.0.0-candidate.1`、`status: "dsh-candidate"`)。`UPSTREAM_PIN.json` 仍绑定未变的 v1 镜像,本次发布不刷新它。
117
+ - `release` 档只保护 Guard 自身路由的表面:经 Guard 自有动作工具发布 npm 制品受保护;`git tag`、GitHub Release 各操作和复合 runner 在本宿主没有拦截点,会在效果前拒绝,而不是假装已覆盖。完全绕过 Guard 的可信进程内调用属于宿主信任边界,只能披露,不能否认。
118
+ - 发布后若 registry 回读生产者没有回应,结算保持 `unconfirmed`;未确认的操作绝不重发。
119
+ - 确定性测试、CI、macOS/Windows 原生验收、发布与安装是相互独立的证据范围。本次记录源码与确定性证据;原生验收与发布另行进行。
120
+
5
121
  ## 0.5.3 - 2026-09-14
6
122
 
7
123
  ### 修复