frontend-project-context 1.0.0

package/docs/12-KNOWLEDGE-MAINTENANCE-CLOSURE-ROADMAP.md

@@ -0,0 +1,350 @@
+# 0.7.0 Knowledge Maintenance Closure 冻结设计与实现记录
+
+> 权威说明：本文记录 `0.7.0` 的目标、冻结设计、分阶段执行边界与本地实现结果。产品身份、内核和永久边界仍以 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 为准。
+>
+> 状态：`0.7.0-implemented-local-verified; A-01-through-A-30-and-CLI-passed`
+>
+> 目标版本：`0.7.0`
+>
+> 后续兼容说明：本文的 renderer 2 是 `0.7.0` 实现记录；当前 `0.9.0` 使用 renderer 3，renderer 1/2 仍可读并在显式 owned publish 时升级。当前事实以 `PROJECT_STATE.json` 和 04 为准。
+
+## 1. 决定
+
+`0.6.1` 已完成来源注册、scoped item authoring、显式批准、Context Bundle 和投影闭环，也能检测并阻断来源、合同与投影漂移。
+
+`0.6.1` 基线暴露出的下一项通用问题是：一个已登记来源发生合理变化后，维护者可以看到 `source-changed`，但当时的稳定 CLI 不能在不直接编辑内部 JSON 的情况下完成来源复核、已有 item 修订或废弃、重新批准和重新发布。
+
+`0.7.0` 只补齐 **Knowledge Maintenance Closure**：把“发现知识过期”推进到“人工审查后安全接受、修订或退役”。该范围已经实现，属于现有来源追溯、人工合同治理和漂移检查内核，没有改变产品定义。
+
+## 2. 用户闭环
+
+目标流程：
+
+```text
+check 发现 source-changed / verification finding
+→ 只读查看旧值、新值和受影响 approved items
+→ 人工选择接受来源变化、修订 item 或废弃 item
+→ 显式重新批准
+→ 原子更新 contract/source lock
+→ 受管投影明确变为 stale
+→ 显式 publish
+→ check 通过
+```
+
+整个流程不得自动接受新 digest、自动修改 approved value、自动批准或自动修复投影。
+
+## 3. 分阶段执行
+
+### 阶段 0：固定 `0.6.1` 基线（已完成）
+
+- 该阶段基线提交：`b78d82c`（`0.6.1版本`）；
+- A-01 至 A-20、B0-01、B0-02 和 CLI 测试共 24 项通过；
+- `0.7.0` 路线文档不混入该基线实现提交。
+
+阶段 0 停止条件已经满足；其后的阶段 1 也只增加设计、验收与状态文档变更，没有混入产品实现。
+
+### 阶段 1：实现前设计（已完成）
+
+本阶段已基于 `0.6.1` 源码、24 项现有测试和现行文档完成，只做了证据驱动审查和设计，没有修改产品代码。
+
+设计必须冻结：
+
+1. 复用或新增 CLI 命令的准确合同；
+2. 来源变更影响集和重新批准规则；
+3. 已有 item 的修订、同 ID 替换和废弃语义；
+4. contract/source lock/projection lock 的写入、所有权、快照和失败恢复；
+5. 稳定错误类别和退出码；
+6. schema、renderer 和 `0.6.1` 项目的迁移兼容性；
+7. A-21 起的验收合同；
+8. 实现文件清单、唯一范围和停止条件。
+
+命令、数据模型、安全规则、兼容路径、验收和实现文件已经在第 4 至第 12 节冻结。设计直接复用现有 `approve`、checker、schema、scope compiler 和 fail-closed store，不推倒重写。
+
+该阶段停止条件已满足：形成可直接实现、范围封闭的设计，同步 RTK/PROJECT_STATE/README/文档索引，不修改产品代码；随后取得了单独实现授权并进入阶段 2。
+
+### 阶段 2：独立实现（已完成）
+
+用户已于 `2026-09-07` 明确要求在额度恢复后直接开工，因此阶段 2 的一次性实现授权已经具备。目标版本为 `0.7.0`，因为新增了向后兼容的用户能力，不作为 `0.6.x` 补丁混入。
+
+唯一允许的能力范围：
+
+- 只读解释来源漂移及其影响；
+- 显式接受来源变化；
+- 修订已有合同项并重新批准；
+- 废弃合同项并从后续 bundle 中排除；
+- 多人或多 Worktree 状态变化时 fail closed；
+- 重新发布前明确报告 stale projection。
+
+停止条件已满足：冻结验收 A-21 至 A-30 全部通过，原 24 项不回归，当前共 34 项；README/help 可独立完成一次知识维护闭环。
+
+### 阶段 3：团队验收
+
+只使用一个已授权的现有 fixture 或项目验证预先冻结的闭环：一个来源变化，分别覆盖接受、修订、废弃、重新批准、重新投影和最终 check。
+
+真实项目只作为证据，不产生框架识别器、新 source kind 或任务执行需求。
+
+阶段 3 已于 2026-09-08 经单独授权完成：隔离临时 fixture 按公开 CLI 走通完整闭环，A-28 定向验收与 42 项全量回归通过；本仓库自托管真源复核为 18 sources、18 approved items、0 findings。未访问真实业务项目，也未执行 Git、网络、Provider、依赖安装或发布。
+
+### 阶段 4：发布准备
+
+知识维护闭环稳定后再单独决定：
+
+- 正式 npm 包名与版本发布；
+- 项目级开发依赖安装；
+- `npx`/`pnpm dlx` 初始化入口；
+- CI 漂移检查模板；
+- 最小示例、changelog 和升级说明。
+
+发布层工作不反向改变 Project Contract 语义。
+
+阶段 4 已于 2026-09-08 经单独授权完成本地准备：v1 冻结为 `frontend-project-context@1.0.0` 候选，补齐包白名单、CI 模板、最小示例、changelog、升级说明和 A-39。本阶段没有实际发布、Git 写入、网络、依赖安装或产品能力扩张；剩余外部发布闸门见 docs/14。
+
+## 4. 证据审查与唯一缺口
+
+| 现有能力 | 代码证据 | 设计结论 |
+| --- | --- | --- |
+| 来源漂移 | `checker.mjs` 已比较 contract、source lock 和当前 digest，并稳定报告 `source-changed`/missing/lock mismatch | 复用读取和 finding；只补单来源解释与显式接受入口 |
+| 来源读取 | `source-reader.mjs` 已安全读取 file/path/json-pointer，做 RFC 6901、项目内 realpath 和 digest | 直接复用；不保存来源正文，不新增 source kind |
+| item lifecycle | schema 1 已有 `proposed | approved | deprecated`，renderer/scope compiler 只消费 approved | 足以表达待重新批准和废弃，不升级 contract schema |
+| authoring | `authoring.mjs` 已校验四类 item、三类 scope、source、override 和 verification | 复用参数构造规则；revision 只允许同 ID、同 kind、同 subject |
+| approval | `approver.mjs` 已能按同 ID 替换、写 approval、校验实时来源并做 conflict/override 预检 | 保留 proposal approval；增加批准 contract 内 pending item 的显式模式 |
+| 编译 | `scope-compiler.mjs` 已排除 proposed/deprecated，并对 approved overrides fail closed | 不改 scope 算法；来源接受后把影响集转为 proposed 即可阻断旧知识继续生效 |
+| store | `project-store.mjs` 已有 contract/source-lock 双快照、lock-first 写入和恢复 | 复用并补条件恢复；不增加事务框架或文件锁 |
+| projection | `projection-store.mjs` 已有 marker + lock + content digest 所有权和 lock-first 写入 | 保持 renderer 2；补 contract/projection-lock/目标文件提交前快照与条件恢复 |
+| CLI | 现有命令有命令级参数 allowlist、默认 preview 和稳定退出码 | 只新增 4 个维护命令，并扩展 `approve --pending` |
+| 验收 | A-01 至 A-20、B0-01/B0-02 和 CLI 共 24 项通过 | A-21 至 A-30 只覆盖维护闭环；原 24 项不得弱化或删除 |
+
+因此阶段 1 将当时的唯一缺口冻结为：**没有稳定 CLI 把已检测到的本地来源变化转换为人工确认的 source checkpoint，并确定性地使所有受影响 approved item 进入待重新批准状态；也没有无需手改 JSON 的同 ID revision、deprecation 和 pending approval 入口。**该缺口已由本文件记录的 `0.7.0` 实现关闭。
+
+projection 的并发快照与条件恢复是实现该闭环在多人/多 Worktree 下 fail closed 所需的安全补强，不是新产品能力。
+
+## 5. 固定 CLI 合同
+
+所有新增命令沿用现有 `--project PATH`、`--json`、默认 preview、命令级参数 allowlist 和退出码。不存在 `--yes`、环境变量授权、自动接受或自动批准。
+
+### 5.1 `review-source`
+
+```text
+project-context review-source --project PATH --id SOURCE_ID [--json]
+```
+
+- 永远只读，不接受 `--write`。
+- 只适用于 `file`、`path`、`json-pointer`；human-decision/external-reference 返回 `source-review-unsupported`。
+- 稳定结果包含 source ID/kind/locator、contract digest、locked digest、当前 digest、`unchanged | changed | missing | unreadable`、完整 reapproval impact set、fallback item、直接受影响 projection、以及接受后必然 stale 的全部受管 projection path。
+- 不输出文件正文或 JSON pointer 的值；“旧/新值”固定指旧 checkpoint digest 与当前 digest，避免把可能敏感的来源内容复制到日志。
+- `changed`、`missing`、`unreadable` 是 drift finding，退出 1；`unchanged` 退出 0。
+
+### 5.2 `accept-source-change`
+
+```text
+project-context accept-source-change --project PATH --id SOURCE_ID
+  --expected-digest SHA256 [--affected-items ITEM_ID...] [--write] [--json]
+```
+
+- 仅接受可读取且状态为 `changed` 的本地来源；不接受 missing/unreadable、未变化来源或不可验证来源。
+- `--expected-digest` 必须等于本次提交前再次读取的当前 digest，且必须不同于旧 checkpoint。
+- 当 impact set 非空时，`--affected-items` 必须提供且集合必须与工具计算结果完全相同；为空时省略。digest + 完整 item 集合 + 本命令自己的 `--write` 构成人工确认，不能被历史授权替代。
+- preview 返回完整 next source 和 item 状态但零写入。
+- `--write` 原子地把 contract source digest 与 source lock 更新为新 digest，并把 impact set 中每个 approved item 改为 `proposed`、移除其旧 approval。它不改 item 内容、不批准 item、不写 projection lock、不发布文件。
+- 接受后 `check` 以 `item-approval-pending` 阻断 context/publish；所有已有 projection 因 contract digest 变化确定报告 stale。
+
+### 5.3 `revise`
+
+```text
+project-context revise --project PATH --id ITEM_ID [--expected-item-digest SHA256]
+  --kind KIND --subject SUBJECT (--value TEXT | --value-json JSON)
+  --statement TEXT --sources SOURCE_ID...
+  --scope project|path-prefix|file [--scope-path PATH]
+  [--overrides ITEM_ID...]
+  [--verification KIND] [--verification-source SOURCE_ID]
+  [--verification-expected-json JSON]
+  [--write] [--json]
+```
+
+- 使用 `propose` 的完整 item 参数与校验，不新增编辑 DSL；所有字段均给出完整 replacement，避免“省略”与“清空”歧义。
+- ID 必须已存在，且 `kind`、`subject` 必须与现有 item 相同；改变知识身份时必须 deprecate 旧 ID，再用现有 `propose` 创建新 ID。
+- 不允许复活 deprecated item。approved 或 proposed item 均可 revision。
+- preview 返回 current item digest 和完整 proposed replacement；`--write` 必须同时提供 `--expected-item-digest`，且它必须仍匹配当前 canonical item。
+- `--write` 只把同 ID replacement 写入 contract，状态固定为 `proposed` 且无 approval；不写 source lock/projection lock，不生成或批准 proposal 文件。
+- revision 后必须通过 `approve --pending` 明确重新批准，才能重新进入 Context Bundle。
+
+### 5.4 `deprecate`
+
+```text
+project-context deprecate --project PATH --id ITEM_ID
+  [--expected-item-digest SHA256] --by NAME --rationale TEXT [--write] [--json]
+```
+
+- ID 必须存在且不是 deprecated；preview 可省略 digest，`--write` 必须提供并匹配当前 canonical item。
+- preview 展示完整旧 item、deprecated next item、override dependents 和可能重新生效的 fallback items。
+- `--write` 把 item 状态改为 `deprecated`，保留 ID、内容、scope、sources、overrides，并用本次 `by/at/rationale` 替换 approval 作为废弃审计理由。
+- 写前对剩余 approved item 执行完整 override/conflict 预检；若仍有 approved item 依赖该 ID，失败并要求先 revise/deprecate 依赖项。
+- deprecated item 不进入 bundle 或新 projection，不自动删除来源。
+
+### 5.5 `approve --pending`
+
+```text
+project-context approve --project PATH --pending --ids ID...
+  --by NAME [--rationale TEXT] [--write] [--json]
+```
+
+- `--pending` 与 `--proposal FILE` 必须且只能选择一个；既有 proposal approval 合同不变。
+- 只批准 contract 中命令明确列出的 proposed item；approved/deprecated/不存在 ID 均失败。
+- 多个 ID 作为一个 next contract 预检和提交，使 override 基项与依赖项可以一次重新批准。
+- 写前再次读取所有相关本地 source digest，并要求 contract source digest、source lock 和实际 digest 三者一致；然后执行 schema、override、conflict 和项目快照检查。
+- preview 零写入；`--write` 只更新 contract approval。未列出的 pending item 保持 pending，`check` 继续失败。
+
+## 6. 数据模型与影响集
+
+### 6.1 schema 与状态转换
+
+- `contract.json.schemaVersion = 1`、proposal schema 1、两个 lock schema 1 全部保持不变；renderer 保持 version 2。
+- 不增加 store 文件、history ledger、source status 或 approval history 数组。
+- 维护期唯一新增语义是：contract 内的 `proposed` item 是明确的 pending approval；`check` 报告 `item-approval-pending`，context/publish 将其作为阻断 finding。
+- `approved → proposed` 只由显式 source acceptance 或 `revise --write` 发生；`proposed → approved` 只由 `approve --pending --write` 发生；`approved|proposed → deprecated` 只由 `deprecate --write` 发生。
+- deprecated 的 approval 表示废弃决定。设计有意只保留当前治理决定，不新增事件日志；需要完整历史时使用宿主仓库已有版本控制，而本产品不管理 Git。
+
+### 6.2 reapproval impact set
+
+对单个 changed source，影响集按以下纯函数、稳定排序计算：
+
+1. `direct`：所有 `approved` item 中，`sources` 包含该 source ID，或 `verification.source` 等于该 ID 的项；
+2. `override-dependent`：递归加入所有仍为 approved 且 `overrides` 直接或间接指向已在集合中的项；
+3. 不加入 proposed/deprecated item；不因 subject、路径或 source 内容猜测影响；
+4. `fallbackItems` 单独列出受影响 item 所 override、但不在影响集中的 approved item，帮助人识别 revision/deprecation 后可能重新生效的上层规则；
+5. `directProjectionPaths` 是 lock `itemIds` 与影响集相交的投影；由于 source digest 属于 contract digest，接受后 `staleProjectionPaths` 是当前 lock 中全部 projection。
+
+`accept-source-change` 对完整影响集统一撤销旧 approval，不能选择只保留部分旧批准。后续可以对每项分别 revise/deprecate，但只有所有 contract proposed item 都解决后 context/publish 才解除阻断。
+
+## 7. 人工权限与安全顺序
+
+```text
+review-source（只读，取得 new digest + impact IDs）
+→ accept-source-change preview
+→ accept-source-change --expected-digest ... --affected-items ... --write
+→ revise/deprecate preview
+→ revise/deprecate --expected-item-digest ... --write
+→ approve --pending --ids ... --by ... --write
+→ check（projection-stale）
+→ publish --write
+→ check（零 finding）
+```
+
+- `--write` 只授权当前命令列出的持久变化；review 结果、之前命令、文件存在或 CI 环境都不构成授权。
+- source acceptance 不能保留受影响 item 的旧 approval；revision 不能自行批准；deprecation 必须署名并给出非空理由；publish 继续要求受管所有权。
+- 命令不认证真实身份，`--by` 与现有 approve 一样只记录调用者明确提供的责任标识。
+
+## 8. 原子性、快照与失败恢复
+
+1. `loadProject` 在现有 contract/source-lock digest 外增加 projection-lock digest；维护 preview 同时记录目标 source/item canonical digest。
+2. 所有写命令在第一次写前重读并比较自己依赖的 store；变化返回 `project-state-changed` 或 `projection-state-changed`，不覆盖并发结果。
+3. accept 复用双文件提交：完整构造并验证 next source lock + contract，先写 source lock，后写 contract。第二步失败时仅当当前 source lock 仍等于本命令写入值才恢复旧 lock；否则不覆盖并发状态，并在错误 details 标记 recovery skipped。
+4. revise/deprecate/pending approval 只写 contract，使用同目录唯一临时文件、`wx` 和 atomic rename；item digest 与项目快照都必须在写前匹配。
+5. knowledge 命令永不写 projection lock。contract digest 变化自然使旧 projection stale；显式 publish 才进入 projection 写路径。
+6. publish 在写前重新核对 contract、projection lock 和目标文件 bytes。仍使用 lock-first；文件写失败时仅在 lock 仍等于本命令 next lock 时恢复，绝不盲目覆盖另一进程的新 lock。
+7. 不承诺跨进程多文件事务，不新增 OS 文件锁、任务锁或 retry。极端竞态必须留下 checker 可识别的 source-lock mismatch、projection missing/stale/ownership conflict，而不能留下静默可编译的部分批准。
+
+## 9. 稳定错误类别与退出码
+
+顶层退出码保持 0–4：
+
+| 退出码 | 新增例子 | 含义 |
+| --- | --- | --- |
+| 0 | unchanged review、preview、accept/revise/deprecate/approve success | 成功且无 finding |
+| 1 | `source-changed`、`source-accept-digest-mismatch`、`source-impact-changed`、`item-approval-pending`、`item-baseline-changed`、`project-state-changed`、`projection-state-changed` | 漂移、待人工处理或并发状态变化 |
+| 2 | `source-review-unsupported`、`source-not-changed`、`item-not-found`、`item-identity-change`、`item-already-deprecated`、参数/schema 错误 | 输入无效或状态不支持该动作 |
+| 3 | 既有 managed/projection ownership conflict | 受管投影所有权冲突 |
+| 4 | `internal-error` | 非预期内部失败 |
+
+JSON 错误继续为 `{ code, message, details? }`。maintenance details 必须包含相关 source/item/path、expected/actual digest 或当前 impact IDs，以及安全的人工下一步；不得包含来源正文、凭据或自动覆盖建议。
+
+## 10. `0.6.1` 兼容与迁移
+
+- 现有 `0.6.1` 项目无需迁移文件；首次用 0.7.0 写入仍保持 contract/source/projection lock schema 1 和 renderer 2。
+- 现有 proposal schema 1、discover、register、propose、`approve --proposal`、context、publish、check 的参数和行为保持兼容。
+- renderer 1/2 的既有兼容规则不变；本版本不升 renderer，因为 bundle 格式没有变化。
+- contract 内原有 proposed item 在 0.7.0 起会确定报告 `item-approval-pending`；用户需用 `revise` + `approve --pending` 或 `deprecate` 解决，不自动迁移或删除。
+- 维护进行中降级回 0.6.1 不受支持：旧二进制虽能读取 schema 1 并继续排除 proposed item，但不会报告新的 pending finding，也没有维护命令。完成全部 reapproval/deprecation 和 republish 后，数据仍可由 0.6.1 读取。
+- 不新增 `migrate` 命令，不自动重发 projection，不备份或复制项目文件；失败恢复只使用命令开始时已读取的受管 store bytes。
+
+## 11. 冻结验收 A-21 至 A-30
+
+以下编号和行为已冻结；具体 test 文件可拆分，但不得合并掉安全断言：
+
+- **A-21 来源审查只读与稳定**：changed/unchanged/missing/unreadable 分类、旧/新 digest、direct/override-dependent/fallback、projection 集合排序稳定；命令前后所有 bytes 相同；不可验证来源退出 2。
+- **A-22 显式接受与 TOCTOU**：无 `--write`、缺 digest、digest 不匹配、来源二次变化、impact IDs 缺失/多余均零写入；准确 digest + 完整影响集才可写。
+- **A-23 影响集与 approval 失效**：覆盖 direct source、verification source、反向 override 传递闭包、sibling 不误伤和 fallback 揭示；接受后全体变 proposed、approval 移除，并出现 pending finding。
+- **A-24 同 ID revision 与重新批准**：四类 item、三类 scope 可完整 replacement；ID/kind/subject 不可偷换；baseline 变化失败；revision 不进 bundle；`approve --pending` 明确 IDs 后才重新进入。
+- **A-25 deprecation**：approved/pending item 可预览和显式署名废弃；依赖 override 未处理时预检失败；deprecated 保留审计理由但不进入 bundle/AGENTS/Ruler。
+- **A-26 store 并发与恢复**：contract/source/projection lock 或 item/source/目标文件任一快照变化均在相关写前失败；模拟第二步失败、恢复失败和恢复期间并发变化，最终必须被 check 阻断且不得覆盖并发值。
+- **A-27 projection stale 与所有权**：accept/revise/deprecate/approve 后旧投影稳定 stale；knowledge 命令不改 projection lock/file；显式 owned publish 后通过；人工改动仍退出 3。
+- **A-28 独立 CLI 维护闭环**：仅依据 README/help，在临时 fixture 完成 change → review → accept → revise/reapprove 与 deprecate → check stale → publish → check clean，全程不手改三个 store JSON。
+- **A-29 `0.6.1` 兼容**：schema 1 contract/proposal/locks 和 renderer 1/2 均可读；原命令不变；无迁移写；维护完成数据可由旧 schema reader 读取；pending downgrade 风险有稳定文档与 finding。
+- **A-30 永久边界回归**：原 24 项全部继续通过；静态和动态写入记录证明零 Provider、网络、dependency install、child process、shell/Git、业务代码修改、真实项目访问，并拒绝无关 CLI 参数。
+
+实现 Gate 已满足：A-01 至 A-30、B0-01/B0-02 和 CLI 测试共 34 项全部通过。
+
+## 12. 唯一实现范围与停止条件
+
+获得单独实现授权后，只允许以下修改：
+
+| 文件/模块 | 唯一允许变化 |
+| --- | --- |
+| `src/project-context/maintenance.mjs` | 新增纯影响集、source review/accept preview、revision/deprecation 构造与预检 |
+| `src/project-context/cli.mjs` | 四个新命令、`approve --pending`、help/allowlist/稳定输出 |
+| `src/project-context/approver.mjs` | 复用 approval/preflight，新增 contract pending item approval |
+| `src/project-context/checker.mjs` | `item-approval-pending` finding；复用 maintenance 影响结果所需的只读 helper |
+| `src/project-context/project-store.mjs` / `io.mjs` | projection lock snapshot、条件恢复/快照 helper；不引入锁或事务依赖 |
+| `src/project-context/projection-store.mjs` | 提交前快照复核和条件恢复；既有 ownership/lock-first 顺序不变 |
+| `contract-schema.mjs` / `authoring.mjs` / `source-reader.mjs` / `scope-compiler.mjs` | 仅暴露或复用必要 validator/纯函数；不改枚举、schema 或编译语义 |
+| `test/project-context/` | A-21 至 A-30 与 CLI 维护闭环；现有测试不得删除或弱化 |
+| package/help/README/04/05/08/12/RTK/PROJECT_STATE | 实现完成后同步真实版本、命令、兼容和验收结果 |
+
+`discovery.mjs`、renderer 内容、source kind、item kind、scope kind、projection target 和安装模型不需要变化。
+
+阶段 2 实现顺序固定为：纯 impact/review → source accept 与 pending finding → revise/deprecate/pending approval → store/projection 并发补强 → A-21 至 A-30/CLI/help/docs。达到全部验收后停止，不进入真实项目、Git 或发布。
+
+本地实现已严格按该顺序完成，未修改 discovery、renderer 内容、source/item/scope kind 或 projection target，也未访问真实项目、网络、Provider、Git 或发布系统。
+
+## 13. 永久不做与本阶段不做
+
+本路线不授权：
+
+- 多任务代码调度、文件锁、自动合并或任务状态系统；
+- Git branch、Worktree、commit、merge、push 或 PR 管理；
+- Codex 或其他 Agent 的会话调度；
+- Provider、Agent Runtime、自动开发或自动验证；
+- 自动接受来源变化、自动批准或自动修复；
+- Vue、React、uni-app、配置文件名或业务语义识别器；
+- 新 source kind、projection target、MCP、IDE 或桌面应用；
+- 第三个真实项目 B0 或 B1。
+
+多人任务的代码隔离继续由 Codex Worktree/Git 等现有工具负责；本产品只保证多人任务消费的长期项目知识经过统一治理。
+
+## 14. 授权与停止规则
+
+用户已批准把本文目标归档为下一版本方向，并授权后续按阶段推进。该批准不等于一次性授权所有实现和外部操作：
+
+- 已完成并消耗：路线归档与实现前设计授权；
+- 已完成并消耗：按第 12 节冻结范围进行的一次 `0.7.0` 产品代码实现；
+- 已完成并消耗：按 `docs/13` 冻结范围进行的一次 `0.8.0` 只读治理看板实现；
+- 已完成并消耗：一次隔离 fixture 的团队维护验收授权；
+- 仍需单独授权：Git 写入、真实项目访问、后续产品实现和正式发布；
+- 永不由本文授权：Provider、网络、依赖安装、任务执行、Git 管理或范围扩张。
+
+任何阶段达到自身停止条件后必须停止，先同步证据和状态，再等待下一阶段明确授权。
+
+## 15. `0.7.0` 后续停止点与看板候选
+
+`0.7.0` 已实现并达到停止条件；本仓库自托管 Project Contract 已初始化；只读治理看板已按冻结范围完成 `0.8.0` 本地实现和验证；团队维护验收也已完成。当前不得继续进入 Git、其他真实项目、后续实现或发布。
+
+`0.7.0` 完成后登记的独立候选 **Read-only Governance Dashboard** 已完成实现，详见 [13-READ-ONLY-GOVERNANCE-DASHBOARD-DESIGN.md](./13-READ-ONLY-GOVERNANCE-DASHBOARD-DESIGN.md)。它只从 `contract.json`、两个 lock、checker 和现有纯函数派生，直观展示健康度、真源层级、source 状态、approved/pending/deprecated、scope tree、provenance 链路、影响集和 stale projection；不成为第二真源，也不自动接受、批准、发布或访问网络。
+
+看板实施前置顺序固定为：
+
+1. 完成并停止 `0.7.0`（已满足）；
+2. 单独授权后为本仓库初始化自身 Project Contract，登记宪法、PROJECT_STATE、RTK、设计与证据层级（初始化时已满足；本次设计收录完成后为 18 sources、18 approved items、`check` 零 finding）；
+3. 基于真实 Contract 数据完成看板实现前设计（已满足）；
+4. 再单独决定静态本地 HTML 看板实现（已授权并完成）。
+
+看板实现已经单独授权并完成；未新增 projection target，未改变永久边界。