frontend-project-context 1.0.0

package/docs/09-B0-DTG-TMC-MOBILE.md

@@ -0,0 +1,173 @@
+# 09 — dtg-tmc-mobile 真实项目 B0 证据
+
+> 权威说明：本文只保留验证证据；历史下一步不再产生产品需求，当前决定以 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 为准。
+
+> 状态：`generic-remediation-passed; B1 deferred`
+>
+> 日期：`2026-09-04`
+
+> 阅读说明：第 2 至第 6 节记录首次 B0 的原始结果；第 7 节记录获得单独授权后的通用修补与同项目回归，并取代首次 `partial-pass; block-b1` 判定。当前交接结论见第 8 节。
+
+## 1. 验证边界
+
+目标项目：`dtg-tmc-mobile`。
+
+本轮只验证真实项目发现、人工批准边界、作用域编译、投影所有权和漂移检查：
+
+- 不调用模型或 Provider；
+- 不运行目标项目脚本、构建、测试、签名或上传；
+- 不修改目标项目；
+- 排除 `.git`、`node_modules`、`unpackage`、本机配置、环境文件和私钥后，在一次性临时副本中执行写入型验证；
+- 人工补充的 scope item 只用于验证编译器，不代表目标项目正式治理批准。
+
+目标项目验证前后均不存在 `.project-context/` 或 `.ruler/`；抽查 `AGENTS.md`、`package.json` 和 `.prettierrc` 的摘要保持一致。
+
+## 2. 发现结果
+
+两次 `discover` 输出字节一致，共生成：
+
+- 5 个来源；
+- 16 个 proposal；
+- 10 条 package script 事实；
+- 2 条依赖事实；
+- 2 条配置文件存在事实；
+- 2 条 Agent 规则来源引用。
+
+已发现内容都能追溯到 `package.json`、`.prettierrc`、`vite.config.js`、`AGENTS.md` 或 `CLAUDE.md`，没有自动生成 approved policy。
+
+## 3. 通过项
+
+### 3.1 确定性与人工治理
+
+- 相同项目连续发现结果一致；
+- `approve` 只批准显式指定的 3 条自动发现项；
+- 后续两条目录 reference 由评估者显式加入 proposal 并批准；
+- 未批准项没有进入合同或 Context Bundle。
+
+### 3.2 真实目录作用域
+
+在临时合同中增加同 subject、不同 sibling scope 的两条 reference：
+
+- `pages/train`；
+- `pages/hotel`。
+
+为 `pages/train/book` 生成的 Bundle 只包含 train reference，为 `pages/hotel/book` 生成的 Bundle 只包含 hotel reference，没有 sibling 泄漏。
+
+### 3.3 临时任务隔离
+
+分别生成 train 和 hotel 任务 Context 后，合同文件摘要保持不变，说明 task constraint 没有写回长期合同。
+
+### 3.4 投影所有权
+
+- 尝试向目标已有的非受管 `AGENTS.md` 写入时返回退出码 3 和 `managed-file-ownership-conflict`；
+- `AGENTS.md` 摘要保持不变；
+- 新建 `.ruler/project-context.md` 成功，随后 `check` 无 finding。
+
+### 3.5 漂移阻断
+
+- 修改已批准来源 `.prettierrc` 后，`check` 报告 `source-changed`；
+- 来源漂移存在时，`context` 返回 `context-blocked`；
+- 恢复来源后人工修改受管 Ruler 投影，`check` 返回退出码 3 和 `projection-ownership-conflict`。
+
+## 4. 首次 B0 暴露的缺口
+
+### 4.1 没有发现一级目录结构（已修复）
+
+程序设计要求发现一级目录结构和已声明 scope 的目标路径，但本次输出没有任何目录 proposal。这是设计与实现之间的直接缺口。
+
+### 4.2 没有形成足够的项目核心事实（等待独立项目证据）
+
+真实项目明确存在以下重要事实，但发现结果没有覆盖：
+
+- uni-app、Vue 3 和 Vuex；
+- `pages.json` 路由及主包、分包结构；
+- H5、微信小程序、Android App、iOS App 多端边界；
+- DTG、CRC、GAT 多租户来源与生成文件关系；
+- HBuilderX 为主要运行与发行入口；
+- 构建、签名、语言刷新和资源上传脚本具有副作用；
+- `openspec/config.yaml` 已提供结构化项目上下文。
+
+当前 discovery 只证明“文件、依赖或脚本存在”，还不足以自动形成可直接交给模型的项目理解。
+
+### 4.3 Agent 规则只生成引用（别名已修复，内容编译暂缓）
+
+`AGENTS.md` 包含大量高价值项目约束，但 discovery 只生成“Review AGENTS.md”引用，不提取可审查的 fact/policy proposal。对于能自行读取仓库的 Agent，这个引用仍有作用；对于只接收粘贴 Bundle 的模型，信息不足。
+
+首次发现时，只有 `@AGENTS.md` 的 `CLAUDE.md` 被当作独立规则来源，形成低价值重复引用；第 7 节回归已经关闭该问题。
+
+### 4.4 Scope 编译依赖人工编辑 JSON（暂缓）
+
+真实目录隔离能力已经通过，但两条目录 reference 必须由评估者手工编辑 proposal 才能建立。自动发现到 scoped context 的产品闭环尚未形成。
+
+### 4.5 已有 AGENTS 的共存路径不完整（已验证嵌套共存）
+
+拒绝覆盖目标项目已有 `AGENTS.md` 是正确的安全行为。首次 B0 只验证了 Ruler 出口，没有验证 AGENTS 原生加载下的共存路径；第 7 节随后验证了受管嵌套 `AGENTS.md`。
+
+## 5. 首次 B0 结论（已由第 7 节更新）
+
+本轮判定为：`partial-pass; block-b1`。
+
+- Contract、approve、scope compiler、Context renderer、projection ownership 和 drift checker 已在真实项目结构上成立；
+- discovery 的准确性尚可，但覆盖率和上下文可用性不足；
+- 当前不能证明比目标项目已有的手写 `AGENTS.md + OpenSpec` 提供额外净价值；
+- 暂不进入 B1 Provider 或双 Agent 对照。
+
+## 6. 首次 B0 建议（执行状态见第 7 节）
+
+按优先级处理后重新执行 B0：
+
+1. 补齐一级目录和已声明 scope 发现，满足现有程序设计；
+2. 为 `manifest.json`、`pages.json` 和常见 uni-app 项目事实增加确定性、非 LLM 提取；
+3. 识别只包含 include 指令的 Agent 别名文件，避免重复来源；
+4. 明确已有 `AGENTS.md` 与受管投影的共存方式；
+5. 评估是否把 `openspec/config.yaml` 作为可选结构化来源，而不接管 OpenSpec lifecycle；
+6. 重跑同一项目 B0，只有 Context Bundle 足以减少人工解释时才申请 B1。
+
+本报告只记录证据，不授权修改产品实现、目标项目或调用模型。
+
+## 7. 通用修补与同项目回归
+
+2026-09-04 获得单独实现授权后，只修补第一个真实项目能够证明的通用缺口，没有加入 uni-app、Vuex、多租户、HBuilderX 或 OpenSpec 专用解析器。
+
+### 7.1 已实现
+
+- 新增 `path` source：只记录路径存在及文件/目录类型，避免目录内普通代码变化导致无意义 drift；
+- discovery 为一级非隐藏目录生成 path-scoped proposed fact；
+- 单行 Agent 规则别名链最终落到具体规则文件时去重；循环或未解析别名仍保留；
+- ownership conflict 提示明确建议使用嵌套 `AGENTS.md` 或 Ruler；
+- 新增 B0-01、B0-02 回归场景。
+
+### 7.2 同项目回归结果
+
+在新的受限临时副本中，两次 discovery 仍然字节一致：
+
+- 来源从 5 个变为 17 个；
+- proposal 从 16 个变为 28 个；
+- 识别出 `app_build`、`common`、`components`、`docs`、`harmony-configs`、`locale`、`nativeplugins`、`openspec`、`pages`、`static`、`store`、`uni_modules`、`wxcomponents` 共 13 个一级目录；
+- `CLAUDE.md → AGENTS.md` 正确去重，只保留 `AGENTS.md` 规则来源；
+- 在根 `AGENTS.md` 不变的情况下成功创建受管 `pages/train/AGENTS.md`，随后 check 无 finding；
+- 在 `pages/train` 内加入普通文件后 check 仍无 finding，证明目录 identity 不会随日常代码变化漂移。
+
+### 7.3 修补后判断
+
+首次 B0 的“一级目录缺失”“规则别名重复”和“已有 AGENTS 无共存路径”已经关闭。核心实现与现有程序设计重新一致。
+
+以下内容保留为跨项目假设，不进入本轮实现：
+
+- 是否需要 uni-app、`manifest.json`、`pages.json` 专用发现；
+- 是否需要识别多端、多租户和构建副作用；
+- 是否应把 `openspec/config.yaml` 作为上游结构化来源；
+- 是否需要比直接编辑 proposal/contract 更高层的 scope authoring 界面；
+- 对无仓库读取能力的模型，是否需要内联经批准的来源摘要。
+
+这些能力至少需要第二个独立项目重复出现，或证明为明确的跨框架需求，才允许进入下一版设计。B1 继续暂缓，避免用模型效果掩盖合同内容仍需人工治理的事实。
+
+## 8. 当前交接结论
+
+- 当前版本：`0.5.0`；
+- 当前状态：第一个真实项目的通用修补已通过同项目回归；
+- 当前自动化验证：A-01 至 A-14、B0-01、B0-02 和 CLI 测试共 18 项通过；
+- 当前未决内容：只保留第 7.3 节列出的跨项目假设；
+- 下一步：选择技术栈不同的第二个真实前端项目，仅执行独立 B0；
+- 停止条件：第二个项目没有重复出现的缺口，不新增通用功能；只在单一项目出现的能力继续留在项目合同或下游工具中；
+- B1、Provider、目标项目写入、Git 写操作和新一轮产品实现都需要单独授权。

package/docs/10-B0-DTG-TMC-PC.md

@@ -0,0 +1,118 @@
+# 10 — dtg-tmc-pc 第二个真实项目 B0 证据
+
+> 权威说明：本文只保留验证证据；跨项目观察已经按 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 分类，不能直接产生内核需求。
+
+> 状态：`core-pass; repeated-gaps-confirmed; B1 deferred`
+>
+> 日期：`2026-09-04`
+
+## 1. 验证边界
+
+目标项目：`~/开发/tmc/dtg-tmc-pc`。
+
+这是第二个真实项目 B0，只验证 Project Context 在另一种真实前端结构中的发现、人工批准、作用域编译、投影共存和漂移检查：
+
+- 不调用模型或 Provider；
+- 不安装依赖，不访问网络；
+- 不运行目标项目的开发、构建、测试、签名、上传或其他脚本；
+- 不修改目标项目，不执行 Git 写操作；
+- 排除 `.git`、`node_modules`、`output`、环境文件、密钥/证书、本机工具目录和压缩产物后，在一次性临时副本中执行写入型验证；
+- 人工补充的 train/hotel scope item 只用于验证编译器，不代表目标项目正式治理批准。
+
+目标仓库约 950 MB；受限副本约 12 MB。验证前后抽查原项目 `AGENTS.md`、`package.json`、`.prettierrc` 的 SHA-256 完全一致，原项目没有新增 `.project-context/`、`.ruler/` 或嵌套 `AGENTS.md`。
+
+## 2. 项目特征与安全判断
+
+目标是传统 PC Web 工程，与首个 uni-app 移动项目的运行时明显不同：
+
+- Vue 2.6、Vue Router 3、Vuex 3、axios、Element UI；
+- Vue CLI 3、Babel、Less、Prettier；
+- 主要业务目录为 `src/views/`，包括 train、hotel、flight、order 等模块；
+- 根 `AGENTS.md` 和 `openspec/config.yaml` 都包含较完整的项目上下文；
+- `CLAUDE.md` 只是 `@AGENTS.md` 单行别名；
+- 构建命令可能写入 `output`、上传产物或写入相邻仓库，因此本轮没有执行任何项目脚本。
+
+项目自身 `README.md` 仍列出通用的 `build/test/lint` 命令，但 `package.json` 实际没有这些脚本。这是 PC 项目特有的文档与可执行事实冲突，也说明来源优先级和冲突报告有实际价值。
+
+## 3. 自动发现结果
+
+使用正确的写入参数生成两份 proposal 后，两个文件逐字节一致。每份包含 10 个来源和 19 个候选项：
+
+- 8 条 package script 事实；
+- 2 条依赖事实：Vue、Prettier；
+- 1 条配置存在事实：`.prettierrc`；
+- 7 条一级非隐藏目录事实：`config`、`docs`、`locales`、`openspec`、`public`、`src`、`upload`；
+- 1 条 `AGENTS.md` 规则来源引用。
+
+`CLAUDE.md → AGENTS.md` 被正确识别为别名，没有形成重复规则来源。所有自动发现内容都保持 `proposed`，没有自动批准 policy。
+
+发现准确但仍然偏稀疏：`vue.config.js` 没有作为配置来源出现；Vue Router、Vuex、axios、Element UI、Less 和 Vue CLI 没有成为技术事实；`AGENTS.md` 仍只形成引用而不形成可移植的已批准内容。
+
+## 4. 核心链路结果
+
+### 4.1 人工批准
+
+评估者只批准 `.prettierrc`、Vue、`src` 目录和 `AGENTS.md` 引用四条代表性自动发现项。其他候选没有进入合同。
+
+### 4.2 目录作用域与任务隔离
+
+评估者另行加入同 subject、不同 sibling scope 的两条临时 reference：
+
+- `src/views/train`；
+- `src/views/hotel`。
+
+为 `src/views/train/book` 生成的 Bundle 只包含 train reference；为 `src/views/hotel` 生成的 Bundle 只包含 hotel reference，没有 sibling 泄漏。task constraint 只出现在本次 Bundle 中，没有写回合同。
+
+这再次证明 scope compiler 正确，也再次证明真实目录 scope 目前需要人工编辑 proposal 才能建立。
+
+### 4.3 投影共存与所有权
+
+在保留根 `AGENTS.md` 的情况下，成功创建受管 `src/views/train/AGENTS.md`。合同更新后可以安全更新该受管文件，最终 `check` 无 finding。
+
+人工修改受管投影后，`check` 报告 `projection-ownership-conflict`；恢复后重新发布成功。根 `AGENTS.md` 摘要始终不变。
+
+### 4.4 来源与目录漂移
+
+- 修改已批准来源 `.prettierrc` 后，`check` 报告 `source-changed`；
+- 来源漂移存在时，`context` 以 `context-blocked` 拒绝生成；
+- 恢复来源后，修改 `src/views/train` 内普通 CSS 文件，`check` 仍无 finding；
+- 最终恢复全部故障注入并重新检查，findings 为空。
+
+## 5. 两个真实项目对比
+
+| 观察 | dtg-tmc-mobile | dtg-tmc-pc | 判断 |
+|---|---|---|---|
+| 技术运行时 | uni-app / Vue 3、多端 | Vue 2 / Vue CLI、PC Web | 技术结构不同 |
+| 确定性发现、人工批准、漂移阻断 | 通过 | 通过 | 核心机制重复通过 |
+| 一级目录 path identity | 修补后通过 | 通过 | 首轮通用修补有效 |
+| `CLAUDE.md → AGENTS.md` 去重 | 修补后通过 | 通过 | 首轮通用修补有效 |
+| 根规则与嵌套受管 AGENTS 共存 | 通过 | 通过 | 首轮通用修补有效 |
+| `vue.config.js` 未发现 | 是 | 是 | 重复的通用发现缺口 |
+| 规则正文只作为引用 | 是 | 是 | 重复的上下文可移植性缺口 |
+| 真实 sibling scope 需人工造项 | 是 | 是 | 重复的 authoring 缺口 |
+| `openspec/config.yaml` 存在但未使用 | 是 | 是 | 重复现象，但样本治理相关 |
+| 构建/上传副作用只在人工规则中说明 | 是 | 是 | 重复风险，不宜靠命令字符串猜测 |
+
+以下仍然只是单项目特征，不应进入通用内核：
+
+- mobile 的 uni-app、`pages.json`、多端、多租户和 HBuilderX；
+- PC 的 Vue 2、Element UI、Less、Vue CLI 3，以及 README/script 冲突的具体内容。
+
+Vuex 在两个项目的人类规则中都很重要，但只有 PC 的 `package.json` 明确声明它。当前证据说明固定依赖白名单可能漏掉重要事实，不足以证明应继续扩充一个无限增长的框架依赖列表。
+
+## 6. 结论与门禁
+
+第二个项目判定为：`core-pass; repeated-gaps-confirmed; B1 deferred`。
+
+核心合同机制已经在两个技术运行时不同的真实项目上重复通过，没有出现无限修复迹象。第一轮三个通用修补也全部在 PC 项目自然复现并通过。
+
+同时，这两个项目属于同一 TMC 产品族，并共享相似的 `AGENTS.md + OpenSpec` 治理方式。因此它们是技术上不同、治理上相关的样本，不能当作完整的外部独立验证。
+
+本轮只把以下内容提升为“可进入下一次设计审查”的重复缺口，不自动实现：
+
+1. 常见项目配置来源缺失，已明确重复的是 `vue.config.js`；
+2. 已批准规则内容只保留路径引用，离线/粘贴式消费者拿不到必要正文；
+3. scoped contract authoring 仍依赖直接编辑 JSON；
+4. OpenSpec 上游复用和构建副作用表达在两个项目都出现，但因治理样本相关，仍需谨慎设计。
+
+下一步不是 B1，也不是继续现场修目标项目。应先单独授权一次跨项目设计审查，确定是否做窄范围 v0.6 修补；如果目标是证明跨团队通用性，则选择一个非 TMC、最好非 Vue 的第三个项目再做 B0。Provider、目标项目写入和 Git 写操作仍需单独授权。

package/docs/11-V1-AUTHORING-CLOSURE-DESIGN.md

@@ -0,0 +1,312 @@
+# 11 — v1 authoring closure 实现前设计
+
+> 权威说明：本文是 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 第 7、10 节的实现前细化，不改变产品定义。发生冲突时以产品宪法为准。
+>
+> 状态：`implemented-local; 0.6.1 audit hardening verified`
+>
+> 设计基线：`0.5.0`，A-01 至 A-14、B0-01、B0-02 和 CLI 测试共 18 项通过。authoring closure 于 `0.6.0` 完成；审查修补后的当前版本为 `0.6.1`，共 24 项通过。
+>
+> 后续兼容说明：本文的 renderer 2 和 proposal 同 ID 合并描述是当时实现记录；当前 `0.9.0` 使用 renderer 3，且 `approve --proposal` 只创建新 ID，同 ID 变化必须走 `revise`。当前事实以 `PROJECT_STATE.json` 和 04 为准。
+
+## 1. 结论
+
+v1 authoring closure 不需要重写内核，也不需要扩大 discovery。现有 schema、来源读取、scope compiler、approval 合并、drift check 和 projection ownership 已经能表达并执行目标语义。
+
+唯一实现范围是：
+
+1. 新增 `register` 命令，把用户明确指定的来源安全登记到现有 Project Contract；
+2. 新增 `propose` 命令，从已登记来源创建现有 schema 的单个 proposed item；
+3. 继续使用现有 `approve --proposal ... --ids ...` 作为唯一显式批准入口，并在写入前补齐完整合同冲突预检；
+4. Context Bundle 输出 item 的 canonical `value`，使 AI 获得被批准的准确内容；
+5. renderer version 从 1 升到 2，并为已有 v1 受管投影提供只读兼容和显式重发路径；
+6. 增加 A-15 至 A-20 authoring 验收，保持现有 18 项全部通过。
+
+`contract.json`、proposal 和 lock 的 `schemaVersion` 均保持 `1`。不新增持久配置文件，不新增依赖，不引入迁移命令。
+
+## 2. 证据驱动的现状审查
+
+| 能力 | 现有证据 | 结论 |
+| --- | --- | --- |
+| Source 数据模型 | `contract-schema.mjs` 已支持 `file`、`path`、`json-pointer`、`human-decision`、`external-reference` | 直接复用，不新增 source kind |
+| 本地来源安全与指纹 | `path-policy.mjs`、`source-reader.mjs` 已做项目内路径、realpath、防越界、file/path/json-pointer digest | 直接复用；CLI 不允许用户手填 digest |
+| Item 数据模型 | schema 已支持 fact、policy、reference、validation-description、三种 scope、overrides、approval、verification | 直接复用，不升级 contract schema |
+| 显式批准 | `approver.mjs` 已只批准 `--ids` 指定项，写入 `approval.by/at/rationale`，并阻断 stale proposal source | 继续作为唯一批准路径；补写入前 scope/conflict 预检 |
+| Scope 编译 | `scope-compiler.mjs` 已实现 project/path-prefix/file、sibling 隔离、显式 overrides 和冲突失败 | 直接复用，不新增 glob 或框架语义 |
+| Context Bundle | `renderer.mjs` 已输出 statement、item/source ID、scope 和来源索引 | 唯一内容缺口：没有输出 item `value` |
+| 写入与所有权 | `io.mjs` 已做同目录临时文件 + rename；projection 有 marker + lock 所有权检查 | 复用单文件原子写；为 contract/source lock 固定失败封闭顺序和并发快照检查 |
+| CLI | 当前只有 init/discover/approve/context/publish/check；人工来源和 scoped item 只能手改 JSON | 唯一接口缺口：新增 register/propose |
+| 验收 | 2026-09-04 本地 `npm test` 18/18 通过 | 新验收只覆盖 authoring，不改写既有验收含义 |
+
+因此，不进入以下方向：框架识别器、第三个项目、Provider、Agent loop、GUI、完整规则分发矩阵或 schema 重构。
+
+## 3. 用户闭环
+
+```text
+init
+→ register（登记来源；未产生 AI 指导）
+→ propose（创建 proposed item；仍不进入 bundle）
+→ approve（用户明确选择 ID 并署名）
+→ context / publish（只编译 approved item，输出准确 value + statement + provenance）
+→ check（检查来源、合同、scope 和投影漂移）
+```
+
+来源登记不是规范批准。未被 approved item 引用的来源不会进入 Context Bundle；proposed item 也不会进入 Context Bundle。
+
+## 4. 固定 CLI 合同
+
+### 4.1 `register`
+
+```text
+project-context register --project PATH --id SOURCE_ID --kind KIND
+  [--path RELATIVE_PATH]
+  [--pointer RFC6901_POINTER]
+  [--reference TEXT]
+  [--write] [--json]
+```
+
+`KIND` 沿用现有枚举：
+
+| kind | 必需参数 | 禁止参数 | 行为 |
+| --- | --- | --- | --- |
+| `file` | `--path` | `--pointer`、`--reference` | 读取项目内文件或目录内容并计算现有 file digest |
+| `path` | `--path` | `--pointer`、`--reference` | 只记录项目内路径的 file/directory identity digest |
+| `json-pointer` | `--path`、`--pointer` | `--reference` | 解析本地 JSON，以 RFC 6901 指向值的 canonical JSON 计算 digest |
+| `human-decision` | `--reference` | `--path`、`--pointer` | 记录明确的人工作用来源；不伪造 digest，不写 source lock |
+| `external-reference` | `--reference` | `--path`、`--pointer` | 只登记标识或 URL；不访问网络，不写 source lock |
+
+固定行为：
+
+- 默认 preview；只有本次命令含 `--write` 才修改 `contract.json`，本地可验证来源同时更新 `sources.lock.json`。
+- `SOURCE_ID` 必须满足现有 stable ID 规则；路径、pointer、reference 和 digest 全部由现有 schema 再验证。
+- 不提供 `--digest`。本地 digest 只能由程序从当前项目读取。
+- 新 ID + 新 locator 的 action 为 `create`。
+- 同一 ID 且 canonical source 完全相同的 action 为 `unchanged`；不同则 `source-id-conflict`。
+- 已由另一 ID 登记的相同 kind + locator 返回 `source-location-conflict`，不静默制造 provenance 别名。
+- 本地来源在 preview 后、提交前再次读取；发生变化返回 `source-changed-during-register`，退出码 1，不写文件。
+- 本命令不创建 item，不批准任何内容，不修改 proposal、projection 或业务文件。
+
+`external-reference` 和 `json-pointer` 只是暴露现有 schema，不能触发网络或新增语义解析；v1 完成必测主路径仍是 file、path、human-decision。
+
+### 4.2 `propose`
+
+```text
+project-context propose --project PATH
+  --id ITEM_ID
+  --kind fact|policy|reference|validation-description
+  --subject SUBJECT
+  (--value TEXT | --value-json JSON)
+  --statement TEXT
+  --sources SOURCE_ID...
+  --scope project|path-prefix|file
+  [--scope-path RELATIVE_PATH]
+  [--overrides ITEM_ID...]
+  [--verification none|file-exists|json-value|path-digest]
+  [--verification-source SOURCE_ID]
+  [--verification-expected-json JSON]
+  [--output FILE --write]
+  [--json]
+```
+
+固定解析规则：
+
+- `--value` 总是 JSON string；`--value-json` 必须被 `JSON.parse` 接受，可表达 boolean、number、null、array 或 object。两者必须且只能出现一个。
+- `--scope project` 禁止 `--scope-path`；另外两种 scope 必须提供 `--scope-path`。路径使用现有规范化规则，不引入 glob。
+- `--sources` 中每个 ID 必须已经存在于当前 contract。proposal 复制这些 source 的 canonical snapshot，因此现有 approve 可以继续检查来源在提案后是否变化。
+- `--overrides` 默认为空；若提供，目标必须是当前 contract 中已批准、subject 相同且 scope 不窄于新 item 的项。
+- verification 未提供时省略该字段；`none` 禁止 source/expected，`file-exists` 要求 source 且禁止 expected，`json-value` 要求 source 和 expected，`path-digest` 要求 source、expected 可省略并回落到 source digest。
+- 输出始终是现有 `{ schemaVersion: 1, projectId, sources, items }` proposal，且只包含一个 `status: proposed` item，不包含 approval。
+- 默认向 stdout 输出，不修改 contract。`--output` 只有与 `--write` 同时出现才保存；`--write` 没有 `--output` 返回参数错误。
+- 保存位置必须是 `.project-context/` 内非三个保留 store 文件的 `.json` 文件。不存在时原子创建；已存在且字节相同返回 `unchanged`，内容不同返回 `proposal-output-conflict`，不覆盖。
+- 每次 `propose` 只创建一个 item。多个 item 使用多个 proposal 和多次明确 approval；v1 不新增交互式编辑器、批量 DSL 或隐式批准。
+
+### 4.3 `approve`
+
+现有合同保持不变：
+
+```text
+project-context approve --project PATH --proposal FILE --ids ID... --by NAME
+  [--rationale TEXT] [--write] [--json]
+```
+
+authoring closure 不增加 `--approve-all`、`--yes`、环境变量授权或 `propose --approve` 快捷方式。
+
+除现有行为外，批准写入前必须以“全部 selected items 已视为 approved”的 next contract 执行：
+
+1. 完整 schema 验证；
+2. source snapshot 与当前 contract/source bytes 一致性检查；
+3. ID 和同 subject + 同 scope 冲突检查；
+4. `validateOverrides(nextContract.items)`；
+5. `findConflicts(nextContract.items)`；
+6. contract 和 source lock 的并发快照检查。
+
+任一失败都不得先写入。未列入 `--ids` 的 item 保持未批准，也不会被导入 contract。
+
+### 4.4 `context` 和 `publish`
+
+命令参数不变。renderer v2 对每个 effective approved item 稳定输出：
+
+- item ID 和 kind section；
+- `statement` 原文；
+- `subject`；
+- canonical JSON `value`，使用足够长的 Markdown fence，不能因 backtick 或换行破坏结构；
+- effective scope；
+- source IDs，且 Source index 继续输出 source kind 与 path/reference；
+- 仅在存在时输出 `overrides` ID，帮助解释显式收窄。
+
+approval 的人、时间和 rationale 保留在合同审计数据中，不默认加入 AI bundle；机器 `verification` 也继续由 `check` 消费。AI 所需的长期验证指导应通过 approved `validation-description` item 的 statement + value 表达。
+
+## 5. 数据模型与版本
+
+### 5.1 不变部分
+
+- `contract.json.schemaVersion = 1`；
+- `sources.lock.json.schemaVersion = 1`；
+- `projections.lock.json.schemaVersion = 1`；
+- proposal `schemaVersion = 1`；
+- Source、Contract Item、Scope、Approval、Verification 字段均不变；
+- `.project-context/` 仍只有三个必需持久 store 文件，proposal 仍是可选中间文件；
+- proposed item 不成为另一份真源，也不参与 compile。
+
+### 5.2 renderer version 2
+
+投影内容因新增 approved `value` 而发生有意变化，必须把 marker 和新 lock entry 的 `rendererVersion` 升为 `2`，不能继续冒充 renderer 1。
+
+兼容规则：
+
+- lock schema 1 的读取器接受 `rendererVersion: 1 | 2`；
+- marker parser 接受受管 renderer 1 和 2；
+- `check` 对所有权和 content digest 正常的 v1 投影报告 `projection-renderer-stale`，退出码 1；
+- `publish --write` 只有在原 marker、lock 和 content digest 三者证明所有权时，才可把 v1 投影原子替换为 v2；
+- v1 投影被人工修改时仍返回 ownership conflict，绝不借升级覆盖；
+- 不自动重发投影，不新增 `migrate` 命令。
+
+## 6. 写入、所有权与原子性
+
+### 6.1 可写目标
+
+| 命令 | 可写目标 |
+| --- | --- |
+| `register --write` | `.project-context/contract.json`；本地来源时还包括 `sources.lock.json` |
+| `propose --output ... --write` | 用户明确指定的 `.project-context/*.json` proposal，排除三个 store 文件 |
+| `approve --write` | `contract.json` 和必要时 `sources.lock.json` |
+| 其他命令 | 沿用 04 的既有边界 |
+
+业务源码、目标项目其他配置、Git、外部系统和非明确 proposal path 永远不写。
+
+### 6.2 Store 所有权
+
+- 只有 `init` 创建、且三个文件均能通过现有 schema 加载的 `.project-context/` 才被视为可写 store。
+- 写命令不得“修复”损坏 JSON、未知字段、缺失 store 或 unsupported schema；先失败并要求人工审查。
+- proposal 不是受管真源。新 `propose` 只创建或确认字节完全相同的输出，不覆盖不同内容。
+- projection ownership 规则保持原样；renderer 升级不能绕过 marker + lock + digest。
+
+### 6.3 单文件与双文件提交
+
+- 每个文件继续使用同目录唯一临时文件、`wx` 创建和 atomic rename；失败清理临时文件。
+- `loadProject` 增加 source lock canonical digest 快照。任何 contract/source lock 写入前都重新读取并比对两个快照；变化返回 `project-state-changed`，退出码 1。
+- 双文件更新先构造并验证完整 next contract + next source lock，不允许边算边写。
+- 提交顺序固定为 source lock 后 contract。若第二步失败，立即用调用前内容原子恢复 source lock。
+- 恢复也失败时返回原错误并附带 recovery detail；留下的 orphan/mismatch 必须被现有 `check` 以 `source-*` finding 确定阻断 context/publish。
+- 不承诺跨进程多文件事务；并行写同一 store 不受支持。快照检查负责拒绝已观察到的并发变化，任何极端竞态也必须落入可检查的 fail-closed 状态，不能产生静默可编译的部分批准。
+
+## 7. 错误类别
+
+沿用退出码 0–4，不增加新的顶层类别：
+
+| 退出码 | authoring 例子 | 含义 |
+| --- | --- | --- |
+| 0 | create / unchanged / preview / approve success | 成功，无 finding |
+| 1 | `source-changed-during-register`、`proposal-source-changed`、`project-state-changed`、`approval-preflight-failed`、`projection-renderer-stale` | 来源、并发状态、合同或漂移需要人工处理 |
+| 2 | `argument-conflict`、`schema-invalid-*`、`source-id-conflict`、`source-location-conflict`、`source-reference-missing`、`proposal-output-conflict`、非法 scope/verification 组合 | 输入无效或项目状态不支持 |
+| 3 | `managed-file-ownership-conflict`、`projection-ownership-conflict` | 仅用于受管 projection 所有权冲突 |
+| 4 | `internal-error` | 非预期内部失败 |
+
+所有 JSON 错误继续输出 `{ code, message, details? }`。details 至少包含相关 source/item/path 和安全的人工下一步，不输出文件内容或凭据。
+
+## 8. 实现映射
+
+禁止推倒重写。获得单独实现授权后，仅允许以下修改：
+
+| 文件/模块 | 允许的变化 |
+| --- | --- |
+| `src/project-context/authoring.mjs` | 新模块：构造/登记 source、构造单 item proposal、参数组合验证 |
+| `cli.mjs` | 增加 register/propose help、参数解析和分发；现有命令合同保持兼容 |
+| `approver.mjs` | 复用现有 merge，增加完整 next-contract scope/conflict 预检和双快照提交 |
+| `project-store.mjs` / `io.mjs` | 暴露 source lock digest、create-or-identical proposal 写入、失败封闭双文件 helper（如需） |
+| `renderer.mjs` | 输出 canonical value/可选 overrides；renderer version 2 |
+| `contract-schema.mjs` / `checker.mjs` | 兼容 renderer 1/2；报告 v1 renderer stale |
+| `test/project-context/` | 增加 A-15 至 A-20；现有测试不得删除或弱化 |
+| help、README、04、05、08、RTK、PROJECT_STATE | 实现完成后同步真实命令、版本、验收和独立使用步骤 |
+
+`discovery.mjs`、scope 算法、source kind、item kind、projection target 和安装模型不需要改动。
+
+## 9. 新增验收合同
+
+### A-15 通用来源登记
+
+- preview 零写入；`--write` 只修改允许的 store。
+- file digest、path identity、human-decision 无 digest 行为准确；同时覆盖现有 json-pointer/external-reference 的无扩张暴露。
+- 越界、symlink escape、错误 pointer、重复 ID/locator、读取中变化全部失败且零部分写入。
+- 未被 item 引用的已登记 source 不进入 bundle。
+
+### A-16 四类 item 与三类 scope authoring
+
+- 不手改 JSON，分别创建 fact、policy、reference、validation-description。
+- project、path-prefix、file scope 和 overrides 可由参数准确表达。
+- string 与 typed JSON value 都保持类型和值。
+- 输出 proposal schema 1、item 必为 proposed、source snapshot 完整；contract 保持不变。
+- proposal output 只能 create/unchanged，不能覆盖保留 store 或不同内容。
+
+### A-17 显式批准与失败封闭
+
+- approve 只接纳 `--ids` 列出的 proposed item，并记录 by/at/rationale。
+- 无写入 flag 只 preview；不存在任何 approve-all 或隐式批准路径。
+- stale source、ID/subject/scope 冲突、非法 override、未解决 conflict 在写前失败。
+- contract 或 source lock 快照变化时失败；模拟第二次 rename 失败后恢复旧状态，恢复失败时 `check` 阻断 compile。
+- 旧 discover proposal 的 approve 流程保持通过。
+
+### A-18 AI 可理解的 Context Bundle
+
+- 四类 approved item 的 statement 和 canonical value 都进入 Context Bundle、AGENTS 和 Ruler v2 投影。
+- 输出仍包含 item ID、scope、source ID 与 source path/reference；可选 overrides 可追溯。
+- proposed/deprecated item 不进入；sibling scope 不泄漏；多目标 section 保持隔离。
+- object key 顺序不同的等价 value 生成字节稳定输出。
+
+### A-19 renderer 迁移兼容
+
+- 现有 schema 1 contract、source lock、proposal 无迁移即可读取和批准。
+- 未修改的 renderer 1 投影被识别为 stale，可由显式 publish 升到 2。
+- 被人工修改的 renderer 1 投影不能被升级覆盖。
+- renderer 2 重发确定、lock/marker/content digest 一致。
+
+### A-20 独立 CLI 闭环与边界回归
+
+- 仅依据 README/help，在临时 fixture 完成 init → register file/path/human → propose 四类 item/三类 scope → approve → context → publish → check。
+- 全流程不读取第三个真实项目，不访问网络，不调用 Provider、shell、Git 或项目命令，不修改业务源码。
+- 原 18 项测试全部继续通过；新增 authoring 测试全部通过；`npm run check` 通过。
+
+## 10. 明确不做
+
+- 不新增 Vue、React、uni-app、OpenSpec、配置文件名、依赖、路由、构建副作用或业务语义识别器；
+- 不改变 discovery 白名单或尝试理解任意框架；
+- 不新增 GUI、交互式 wizard、批量 DSL、MCP、Provider 或 Agent Runtime；
+- 不新增 projection target，不实现 Ruler/Rulesync 安装或调用；
+- 不修改目标业务项目，不读取第三个真实项目，不重新运行 B0，不进入 B1；
+- 不访问网络，不安装依赖，不执行 Git；
+- 不新增 candidate、DecisionRecord、DeliveryRecord、自动修复、retry 或任务执行；
+- authoring closure 完成后不继续新增功能；新的产品变化必须重新获得明确授权。
+
+## 11. 实现入口与停止条件
+
+本次获得产品代码实现授权后，已按以下顺序完成：
+
+1. `authoring.mjs` 的纯构造与 source 登记 preview；
+2. CLI register/propose；
+3. approver 预检与双快照安全提交；
+4. renderer v2 与兼容 check；
+5. A-15 至 A-20、help 和使用文档；
+6. 全量 `npm test`、`npm run check` 和 Markdown/JSON diff 审查。
+
+`0.6.0` 已完成本文限定实现，`0.6.1` 已修补 verification 阻断、projection 失败封闭、RFC 6901 和 CLI 参数合同，并通过 A-01 至 A-20。实现结果已同步到 04、05、README、RTK 和 PROJECT_STATE。
+
+产品宪法第 7 节已成立，原 18 项保持通过，A-15 至 A-20 通过，文档已给出独立本地闭环。因此 v1 状态为完成；按宪法第 10 节停止功能扩张，等待新的明确产品变更授权。