frontend-project-context 1.8.0 → 1.10.0

package/docs/33-BOUNDED-TASK-HANDOFF-REDESIGN.md

@@ -0,0 +1,207 @@
+# 33 — 基于 1.9.1 实现的有界任务交接审查与重新设计
+
+> 后续设计已由 [docs/35](./35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md) 取代：用户明确产品以管理上下文、提供执行门禁为主，不要求钩子。本文 BR 修复记录保留；A0、BA-13 及硬保护前提不再作为新设计主线门槛。
+
+> 日期：2026-09-29。
+> 状态：本轮代码审查与局部修复完成；以下新能力是待审阅的实施设计，不是已实现能力或长期 Contract 批准。
+> 任务授权：用户要求“重新根据目前实现的做审查，再重新设计一份设计，发现漏洞可以做修复”。允许本地审查、设计和已复现漏洞修补；不包含真实目标项目操作、Git、Provider、网络、打包或发布。
+> 与 docs/32 的关系：保留已获批的产品方向与宪法 1.3.0；本文提出阶段 A 的可执行替代方案。未经人工采纳，不把它写成已批准的 Contract，也不自动进入 A—D 全量实施。
+
+> A0 后记：用户随后单独授权 A0；[docs/34](./34-A0-CODEX-HOST-FEASIBILITY.md) 将实际 Codex Host 的保护可行性判为 `blocked`。依本设计第 4、10 节停止，A1/A2 未启动；本文的候选实施步骤不能直接越过该结论。
+
+## 1. 结论与审查范围
+
+不重建现有内核。下一次新能力实施应从“一个真实 Host 的保护可行性 + 一份固定失败案例”开始，再用已有完整 Context 编译器构建任务交接。最小任务记录、事件提醒、环境流转和更多 Host 不进入阶段 A。
+
+本次阅读当前 CLI、项目状态、初始化指令、AI Entry、Context Bundle、自适应查询、阶段 Context、路径保护和 truth reconciliation 的有关实现及测试；运行整个本地检查。未访问移动端/PC 仓库、未读取其他任务对话、未调用实际 Host 进行业务开发，也未进行全仓安全审计。因此本报告只能证明下列本地缺陷与实现事实，不能确认真实移动端失败的全部根因。
+
+源码仓库 package.json 的 bin 指向 `bin/project-context.mjs`，且没有外部运行依赖。仓库没有 node_modules；指定 npm exec 启动方式此前触发缓存 EPERM。本次仅在这个产品源码仓库使用 `node bin/project-context.mjs` 复核自身，不安装包，不把此方式推广为消费项目的任意回退。自托管初始健康为 clean。
+
+## 2. 当前能力核对
+
+| 能力 | 当前实现依据 | 可复用范围与限制 |
+| --- | --- | --- |
+| 项目健康、入口与 Contract 状态 | `src/project-context/project-status.mjs::buildProjectStatus` | 已分 health、entry、contractReadiness；clean 不等于任务就绪。docs/32 把问题概括为“产品混在一起”不够准确：实际缺口主要在消费与交接层。 |
+| 接入与人工批准 | `initialization-instruction.mjs`、`docs/AI-PROJECT-INITIALIZATION.md`、CLI setup/approve/publish-entry | 已有集中语义审查、基线、所有权保护和原子 proposal 审批；没有单一全流程接入事务。保留 Host 引导，不能再创建自动批准执行器。 |
+| 完整任务上下文 | `context-bundle.mjs::buildContextBundle`、`scope-compiler.mjs::effectiveItems` | 已有 locate/targeted、路径去重、完整适用内容、读取职责、gap 和明确的 semanticCompleteness=not-claimed；没有任务证据消费回执或业务就绪判断。 |
+| 自适应查询 | `adaptive-context.mjs::buildAdaptiveContextBundle` | 已有快照、来源校验、一次 expanded 上限、预算阻断、withheld 与 complete 回退。ready 是声明范围的交付状态；不是业务需求完整性证明。 |
+| 阶段交接 | `task-context.mjs::buildStageContextBundle` | 已有 Plan/Receipt 绑定、依赖、作用域、预算与错误状态。本轮恢复 schema 1 的完整作用域语义；不为普通短任务强制生成多阶段 Plan。 |
+| 漂移与环境对账 | `truth-reconciliation.mjs::resolutionOutcomes`、`buildTruthReconciliationReview` | 已有按根因恢复、defer、task/global health 区分和外部证据消费；不需要为了阶段 A 重做环境协议。 |
+| Host 保护与自然语言对话 | `ai-entry.mjs::renderAiEntry` | 当前只是指令文本，没有可强制覆盖 Host 写入通道的执行钩子。自然语言由 Host 组织；包不调用模型。 |
+
+普通 context、adaptive context、stage context 的返回结构和读目标语义并不完全相同。共享作用域真源不代表三个输出可以无损互换。阶段 A 只以完整 Context Bundle 为依据，不将旧 adaptive/stage 的 ready 直接翻译为 ready-to-implement，也不顺带升级所有旧协议。
+
+## 3. 本轮确认的漏洞与修复
+
+### BR-F1：任务路径可经符号链接逃出项目根
+
+- 触发：`src/escape` 指向项目外目录，查询 `src/escape/existing.ts` 或尚未存在的 `src/escape/new.ts`；也覆盖直接文件链接和悬空链接。
+- 修复前：context 仅做字面相对路径校验；adaptive 的 targetStates 用 access 判断存在。未注册为 source 的目标绕过来源路径检查，context 返回成功，adaptive 可以返回 ready；changedPaths 也可能成为不安全 read target。
+- 影响：向 Host 交付仓库外读取目标。测试未证明发生外部正文泄漏或外部写入，不能把“交付错误目标”夸大为已经发生这些后果。
+- 修复：新增共享 `path-policy.mjs::inspectContextTarget`，现存目标检查真实路径；不存在目标检查最近现存父目录与符号链接。context 验证每个 task path；adaptive 在检索前验证 task paths 和 changedPaths。只读，不创建父目录。
+- 兼容：仓库内链接、根目录、合法新建/已删除路径继续可用；错误使用既有 path-outside-project/output-symlink 类别，不新增公共 schema。
+- 局限：这是编译时路径检查，不是 OS 沙箱；不能防止编译后另一个进程替换链接。未来保护器必须在实际写入时再次验证目标。
+
+### BR-F2：schema 1 阶段 Context 静默遗漏 fact/reference
+
+- 触发：作用域内同时存在 policy、普通 fact 和 reference，且 fact/reference 没有被 mandatory dependency 额外带入。
+- 修复前：`selectedItems` 向 selectAdaptiveItems 传入 null 索引；matchReasons 无术语索引可匹配，普通事实和引用被漏掉，阶段仍可 ready。原有阶段测试主要使用 policy，未覆盖此情况。
+- 依据：`docs/23` 第 11.1 节明确要求 stage-context 的 schema 1 输入保留完整语义。
+- 修复：schema 1 阶段 Context 恢复 effectiveItems 的完整作用域选择；保留 sibling 隔离、显式覆盖、冲突、来源校验和原有预算阻断。预算不足时不静默丢掉事实。
+- 兼容风险：包含 fact/reference 的旧 bundle digest 会变化；旧 Receipt 对应输入重建不一致时应拒绝，重新生成本地阶段工件，不重写历史 Receipt。该变化恢复既定完整语义，不升级 schema 或包版本。
+- 归因限制：此缺陷可能造成任务依据遗漏，但本轮没有真实移动端 Host 的调用链证据，不能声称它就是原失败的根因。
+
+本轮只修以上两个有失败测试的现存缺陷，不把尚未实现的项目卡片、任务状态机或 Host hook 当成补丁塞入 1.9.1。
+
+## 4. 阶段 A 的固定交付边界
+
+阶段 A 分成 A0、A1、A2 三个停止点。整体产品方向仍是 docs/32 的 A—D；本文只细化 A，不将 A1 的本地完成冒充宪法 7.3 的整体完成。
+
+| 停止点 | 交付 | 明确不做 |
+| --- | --- | --- |
+| A0：真实案例与保护可行性 | 一份固定案例清单；一个具体 Host/版本/写入接口的探针证据；结论 feasible 或 blocked | 不写通用 Agent Runtime；不为多个 Host 同时适配；不开始 A1 全量实现 |
+| A1：本地最小交接 | project-brief、task-handoff、同一入口指引、确定性状态与完整 Context 复用；通过下列本地验收 | 不自动治理 Contract；不加任务数据库、提醒、环境状态机或 adaptive 新检索 |
+| A2：首个真实 Host 验收 | 在获准的隔离目标副本中，缺失设计不写入、补齐依据可实施、无关变化不重复打扰 | 不用内部测试或文档承诺代替真实拦截；不自动发布或开始 B |
+
+### A0 的有限可行性工作
+
+首个候选限定为此前移动端失败任务实际使用的 Host，不能随意换成自制脚本再声称已解决用户问题。本仓库现有证据未固定该 Host 的准确版本、钩子接口与全部写入通道；这是明确的外部验收输入缺口。
+
+A0 只允许完成一次接口能力核对和一组隔离探针：直接编辑/patch、shell 文件写入、子任务写入、恢复旧交接后的写入。记录每个可写通道是被保护、被禁用还是未覆盖；存在未覆盖通道时不得标记 enforced。钩子报错、超时、旧快照和无交接时均应拒绝受保护业务写入。
+
+若实际 Host 不能拦截全部允许的写入通道，A0 结束为 blocked，并给出“哪个通道无法保护”的证据。指导模式仍是允许的输出，但不得用它通过强制保护验收；不自动改选 Host、开发 Runtime 或修改宪法。只有用户重新选择支持范围后才恢复。这是失败终态，不是无限修复入口。
+
+真实案例清单必须包含原始需求、项目基线、可定位设计与摘要、目标路径、明确必需字段/决定、允许修改范围和每个场景的预期结果。只给“机票首页”四个字不是已冻结用例。编制清单需要独立授权的真实项目资料；当前不补造。
+
+## 5. 最小接口设计（尚未实现）
+
+### 5.1 项目卡片
+
+新增只读命令：`project-context project-brief --project PATH [--json]`。
+
+组合现有 project status 与 locate 结果；无任务时 taskStatus=none，不制造 Plan。未初始化/部分状态也应给结构化卡片；无法加载 Contract 时不强行编译。卡片固定显示：连接状态、批准依据、已知缺口、可以开始的动作。未知业务域只显示为未声明，不承诺自动盘点全仓。
+
+“接入本项目”仍是 Host 的一个自然语言动作，复用包内初始化指令和集中审批，不新增通用 connect 执行器；CLI 调用与恢复细节由 Host 隐藏，不能隐藏人的精确语义批准。后续若要新增自动事务命令，另行设计，不塞入 A。
+
+### 5.2 任务交接
+
+新增只读命令：`project-context task-handoff --project PATH --input FILE [--json]`。
+
+input 是 Host 提供的短期、schemaVersion=1、kind=task-handoff-input 工件。输出为 schemaVersion=1、kind=task-handoff-result。无默认 store、无后台状态、无自动补写；短期输入文件由 Host 在任务临时目录持有，传入文件仍须在 targetRoot 内并通过既有路径策略。未知字段、重复 ID、悬空引用、未知版本按现有 fail-closed 风格拒绝。
+
+| 输入部分 | 必需语义 |
+| --- | --- |
+| task | 稳定 ID、用户原话或可信引用、intent（investigate/design/implement/continue）、完整最小目标路径、验收条目；continue 另行声明本轮 intent |
+| requirements | 每条有 ID、内容、来源身份、blocking、关联验收和证据 IDs；记录 Host 核对用户显式资料与目标后生成的清单，不得用空数组绕过实现交接 |
+| evidence | ID、用途（requirement/design/decision/reference/implementation）、路径或外部引用、摘要；本地依据重算摘要，外部依据标记 host-asserted，不冒充本地验证 |
+| consumption | 对当前 Context bundle digest、required read targets 和本次必需 evidence 的读取回执；声明者身份与读取摘要。conditional 必须给出读取结果或本次不适用理由 |
+| decisions | 问题 ID、blocking、已确认值及用户确认的可信引用；Host 推断单独标记，不得满足需人工确认的决定 |
+| prior | 可选上一份结果与其摘要，仅用于比较进展；输入/任务 lineage 不符则不复用；不把旧 ready 当批准 |
+
+输出固定携带 projectHealth、connection、intent、taskStatus、contextBundleDigest、scopeCoverage、实际 item IDs、required/conditional targets、evidenceResults、gaps、questions、nextAction、progressKey、semanticCompleteness=not-claimed、authorityGranted=false。读取回执只证明 Host 的声明和摘要绑定，不证明模型内在理解；哈希也不是身份认证。
+
+保护能力由可信 Host 适配层报告，不能因为任务输入自填 enforcement=enforced 就声称硬保护。核心仅提供交接检查结论；Host 还必须检查当前用户实施权限。
+
+### 5.3 判定顺序与退出结果
+
+1. 非法输入、跨根路径、项目身份不匹配、所有权冲突：blocked，不输出实施就绪。
+2. 未锁定目标：discovering，返回一个有具体目标的调查动作；无任务由 project-brief 返回 none。
+3. 必需证据缺失/变更、required 未消费、已声明验收未绑定依据：needs-evidence。
+4. 关键人工决定缺失或依据互相冲突：needs-decision；完整输出其他 gap，不因只显示一种状态而丢失问题。
+5. 上述条件满足且 intent=implement：ready-to-implement。只读调查/设计完成输出同一 taskStatus=none 并显式 outcome=read-only-complete，implementationReady=false；不得要求用户先授权写代码才能完成调查。
+
+task-handoff 的退出码：0 表示本次交接 ready 或 read-only-complete；1 表示 discovering/needs-evidence/needs-decision；2 表示 blocked/非法输入。输出结构化结果和错误策略应在 CLI/schema 测试固定。project-brief 的退出成功只证明卡片生成，taskStatus 始终 none。
+
+普通 context 的 exit 0 继续表示编译成功，不修改旧接口兼容性；stage/adaptive 的 ready 含义也保持原协议。只有新 task-handoff 明确提供当前任务的实施交接结论。
+
+## 6. 什么叫“证据足够”
+
+核心只能验证显式任务声明的完整性，不能发现从未提供的隐藏业务真相。
+
+- 用户提供的设计/验收和 Contract 明确要求的材料自动成为检查候选；Host 必须记录逐项核对结果。
+- 每项验收至少绑定一个有效依据或明确的无需额外资料理由；无理由的空 requirements 不能 ready。
+- 不是所有任务都必须另有设计文档；简单样式或已确认字段接线可以由用户原话、当前源码和适用规则构成足够依据。无需为已有明确授权再问一次。
+- 没有已声明的必需设计时，不以文件扩展名/框架白名单猜测存在某份秘密设计；未知语义必须在输出中说明。
+- 真实机票用例必须包含“设计应当被找到/显式提出缺口”的可观察信号。Host 如果忽略该信号属于 Host/交接失败；若基准把所有信号藏起来，却期待核心猜中，则基准无效，先停止修复。
+
+## 7. 防止重复调查与自我失效
+
+progressKey 由 task 目标/验收、完整路径集合、当前相关 Contract 内容、必需证据摘要、决定及读取回执确定性计算；不包含时间戳、生成次数和与本任务无关的文本。相同有效输入必须得到相同 gap IDs、下一动作和 progressKey。
+
+每次进入缺口处理最多进行一次定位调查和一次基于新证据的复查。没有新增证据、决定或范围变化，Host 停在当前 needs-evidence/needs-decision；不得只改任务 ID、重置计数或重复调用来解除限制。有新的外部事实时可继续，不用固定终身重试次数阻止正常开发。
+
+区分两种变化：
+
+- 依据变化：需求、设计、已确认决定、实际适用 Contract 或目标范围变化，必须重新交接。
+- 实现进展：在已授权目标范围内修改实现文件，只更新实现快照和验收记录，不自动宣告需求/设计过期。若同一文件也被声明为不可变需求依据或正式 Contract source，按依据变化处理。
+
+原始 Contract/lock 快照变化时仍按现有规则重编译；若重新计算后的适用内容与必需依据相同，可复用仍有效的消费声明，不要求用户再次确认相同业务决定。治理阻断照常报告，阶段 A 不顺便改变旧 context 的全局漂移策略。
+
+旧 ready 不能跨任务或跨范围复用。实际写入前检查目标仍在允许范围、路径未逃逸、依据仍有效，并检查 Host 的人工授权；这些检查由保护适配层调用，产品不执行写入。
+
+## 8. 实现位置与兼容策略
+
+- 新增 project-brief 与 task-handoff 的小型编译/校验模块、输入/输出 schema、CLI 路由和针对性测试。
+- 复用 buildProjectStatus、buildContextBundle、effectiveItems、路径策略和 canonical digest；不复制 selector，不重写已有 source/approval/projection store。
+- AI Entry 只新增无任务→项目卡片、有任务→交接的消费步骤；renderer/capabilities 的版本升级在 A1 实现时按现有惯例统一处理，本轮不预先升版。
+- 阶段 A 默认完整 Context，超预算明确停下并给出缩小任务或显式调整预算动作，不自动扩大预算或开启第二套 adaptive 协议。
+- 不删除现有 CLI，不迁移旧 store，不把短期 evidence/consumption 当成 Project Contract；用户不需手写机器工件。
+- 普通开发只显示“已确认、待核实、需要决定、下一步”，机器字段只供展开核验；技术状态不能覆盖用户任务事实。
+
+## 9. 固定验收与失败归属
+
+### 本轮补丁验收
+
+| ID | 预期 |
+| --- | --- |
+| BR-01 | context 拒绝外部目录/文件链接、外部新建路径及悬空链接，不输出成功 Bundle |
+| BR-02 | context 支持根、内部链接和合法新路径；编译不创建目录或文件 |
+| BR-03 | adaptive 的 task paths 与 changedPaths 都拒绝逃逸；CLI prompt 不输出实施内容 |
+| BR-04 | adaptive 内部别名、prospective/deleted 状态继续可用，无文件写入 |
+| BR-05 | schema 1 stage 保留适用 fact/reference、排除 sibling；超预算 blocked 且不丢内容 |
+
+### 后续阶段 A 固定清单
+
+| ID | 场景与通过标准 |
+| --- | --- |
+| BA-01 | 无任务：新/已有项目准确显示连接与缺口，taskStatus=none，无伪造 Plan |
+| BA-02 | 接入：人工入口和现有改动保留，精确审批与已存在 store 恢复规则仍生效 |
+| BA-03 | 固定机票案例缺设计：needs-evidence，有定位/补齐动作；受支持 Host 写入被拒绝 |
+| BA-04 | 设计有但未读或摘要过期：仍非就绪；已有 context exit 0 不能绕过 |
+| BA-05 | 缺关键默认值决定：needs-decision，不自行推导业务语义 |
+| BA-06 | 相同案例补齐设计、消费和决定：ready；有外部权限的 Host 可完成限定改动 |
+| BA-07 | 同输入重复：相同 progressKey 和缺口，Host 不重复调查/提问；新证据允许继续 |
+| BA-08 | 新影响路径：重新编译完整范围；合法范围内实现进展不会自动造成需求过期 |
+| BA-09 | 不相关变化：依据相同则不重复要求业务确认；真正相关漂移仍阻断 |
+| BA-10 | 只读调查/设计能正常结束，无虚假 implementationReady |
+| BA-11 | project-only 或无独立设计文档的简单任务，在显式依据充分时可就绪，不一刀切阻断 |
+| BA-12 | 外部来源仅 host-asserted；伪造/缺失声明、旧 baseline、跨任务和未知 schema 失败封闭 |
+| BA-13 | 所有允许写入通道受保护；保护器故障、换路径/链接、子任务和旧 ready 不能绕过 |
+| BA-14 | 独立无历史 Host 在同一固定基线上实际完成 BA-03→BA-06；记录实际看见的证据和代码行为 |
+
+BA-03/06/13/14 的真实证据不能用单元测试替代。其余可本地验证的部分先以固定 fixture 证明。本轮 BR 测试成功不能计为 BA 或真实 Host 验收成功。
+
+失败必须先归入一类：既定产品合同缺陷、项目数据缺失、Host 适配缺陷、外部环境阻断、基准无效。没有证据时标记归因未定并停止自动修复。只有第一类进入核心修补；适配缺陷只改对应适配层；数据/环境/基准问题不追加核心功能。
+
+## 10. 实施收敛与明确停止
+
+- A0 一次能力核对加一组探针后必须交付 feasible/blocked；不能把“不知道如何拦截”留给 A1 边写边猜。
+- A1/A2 使用冻结的 BA 清单和基线；每个停止点最多两轮修复后复验。第二轮仍未通过，保存失败证据与最小阻断，停止本阶段，不自动开启第三轮，也不降低验收标准。
+- 改修复内容不改原验收预期；新需求放入 B/C/D 或候选，不能变成本轮追加门槛。新发现的安全阻断须明确报告，不能为按时收口而忽略。
+- 固定清单通过即停止；A1 只能称“本地交接实现通过”，A2 才能称“该 Host/该范围真实验收通过”，整体新方向仍要满足宪法 7.3。
+- 发布、升级真实项目、Git、Provider 和网络仍单独授权。上一版发布事实不等于本地补丁已发布。
+
+## 11. 本次验证记录与交付状态
+
+- 修改前 `npm run check`：237/237 通过。
+- 先添加 BR-01/BR-03：原实现各自失败；内部链接/合法新路径对照测试通过。
+- BR-05：原实现只返回两个 policy，遗漏预期 fact-version/reference-design，断言失败。
+- 修复后 BR-01 至 BR-05 全部通过；最终全量结果见 PROJECT_STATE.json 的 localReview 字段。
+- 包版本仍为 1.9.1，公共 schema、Exchange Protocol、AI Entry renderer 和长期 Contract 未改变；两个修复仅在本地源码中，未打包/发布。
+- 本文是本轮提供的重新设计候选。下一次授权应明确采用本文，并先执行 A0；不应继续把 docs/32 整个阶段 A 当成一个无界实施任务。
+
+### 自托管 Context 消费记录
+
+实际命中 `task.context.human-centered-lifecycle`、`task.context.consumption-closure`、`task.context.integrity-repair`、`task.context.branch-aware-staged-handoff`、`task.context.adaptive-bounded`、`implementation.runtime`、`governance.authority`、`work.current-authority`、`validation.acceptance` 等项。源码与 docs 为 scoped；三个测试文件及 PROJECT_STATE.json 为 project-only，并明确报告相应 gap；这不证明测试语义已由 Contract 覆盖，测试本身已直接读取并执行。
+
+required 读取：根 AGENTS、宪法、RTK、docs/32、PROJECT_STATE 指定部分和本次目标源码/测试。conditional 按任务读取 docs/23 的 selector/兼容条款、包内初始化指令及 package scripts；未遍历 provenance-only 历史。新设计作为本次短期交付存在，没有冒充已批准长期规则。当前 Contract 与 lock 摘要不因这份候选设计自动改变。

package/docs/34-A0-CODEX-HOST-FEASIBILITY.md

@@ -0,0 +1,61 @@
+# 34 — A0：Codex Host 实施前保护可行性与移动端失败案例
+
+> 适用范围更正：用户随后明确以“上下文管理 + 指令门禁”为产品定位。本文仅记录此前硬保护调查的结果，不再阻断上下文主线。新的设计和实施顺序见 [docs/35](./35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md)；下文历史 A0 结论不代表通用交接不可实现。
+
+> 日期：2026-09-29。结论：**blocked**。本文件是 docs/33 所定义的一次性 A0 证据，不是 A1 实现、长期 Contract 批准或真实 Host 强制保护验收。
+
+## 1. 固定案例与证据边界
+
+实际失败任务是本机 Codex 任务 `01a0ebef-9e38-78f3-8d68-b51761cb07a2`，标题“实现机票首页 AB 与底部菜单”，工作目录 `/Users/fushan/开发/tmc/dtg-tmc-mobile`。任务原文要求先核对真实 Git 分支、仓库 Project Context、版本配置字段和缺省/失败行为；字段不存在或规则不明时停止业务写入。V1/V2 同页互斥，先做底部菜单首片；设计资料原在 Vault `工作/项目/_工作记录/用户体验_机票首页优化-前端需求梳理`，当时并非自动纳入目标项目 Contract。
+
+任务对话的可核事实：初次离线 CLI 状态因项目本地依赖缺失而失败，之后按用户指示安装了 `frontend-project-context@1.9.1`。后续 Host 得到 `clean / contract-ready` 并调用 Context，但未自动取得机票首页设计。该任务后来明确承认：Contract 无该需求专属条目，`context --locate` 不返回设计；手工指定 `docs/flight-home-v2-design.md` 才列为 required，覆盖仍为 `project-only`。期间 Host 已写过首页拆分代码，用户指出设计/上下文接管问题。这个链条证明“运行 CLI”与“读到任务关键依据”不同；不单凭对话断定产品内核是唯一根因。
+
+当前目标仓库已有后补的 `AGENTS.md` 手工交接路由、`docs/flight-home-v2-design.md` 和 `docs/task-context/flight-home-v2.plan.json`，不能伪称它仍是首次失败现场。只读核对时实际分支为 `dev_flight_home_opt20260924`；原任务里的该名称首先是 Vault 记录，当前分支结果不能倒推当时状态。当前设计仍说明机票首页版本字段、取值及空值/错误规则未知，V2 未开放，V1 平台运行回归未完成。
+
+为防止后续把材料混作同一快照，当前目标仓库的只读 SHA-256 固定如下；它们标识 **A0 阅读时** 的文件，不是失败前基线：
+
+| 路径 | SHA-256 |
+| --- | --- |
+| `AGENTS.md` | `4bcec3bf9fa60699eba01be7ee74faf36fff0ac7fb470acad9b915ae52ff1218` |
+| `docs/flight-home-v2-design.md` | `b6eddc8332dad8719f7720ff5d68b9280e317a132870fa7b79c741df91b18f96` |
+| `docs/task-context/flight-home-v2.plan.json` | `966ce390a72616fa05465f3479d65ccca4954a7b1de47ca4817be43b4711c4b0` |
+| `pages/flight/index.vue` | `21cf880dc304c755a5aa62f7033e627da4dd32db715bb5e76ea442ee5b34e2a4` |
+| `pages/flight/home-v1.vue` | `f0052d7bbbe6b35f63167030f3e3b9a419793f80cd176fff1619d04c2b233737` |
+| `pages/flight/home-v2.vue` | `fd2c56baacae11148440242ab67f4ace432f0218ebb1782666a967ce6fb5d1e0` |
+
+## 2. 冻结的验收输入和预期
+
+| 场景 | 输入或前置条件 | A1/A2 将来必须观察到的结果 |
+| --- | --- | --- |
+| F-01 关键设计未交接 | 原任务原话指向 Vault 设计；目标 Contract 不含机票首页专属项；尚无可信短期交接引用 | Host 在写首页代码前提出具体缺口并停止。`clean` 或普通 Context 成功不得充当可实施结论。 |
+| F-02 必需业务决定未知 | 版本配置字段来源、值域、空值和错误规则尚未确认 | 不新增字段、不自行设 V1/V2 默认业务规则，不写版本选择业务实现。 |
+| F-03 依据补齐 | 用户确认的设计、字段与规则，绑定当前路径/摘要，且 required 目标已读 | 重新计算同一任务交接；只在当前用户授权及目标范围内允许实施。 |
+| F-04 旧交接恢复 | 旧 ready 摘要、已变化的设计或目标路径 | 写入前重新核对并拒绝过期或跨任务交接；不能复用旧 ready。 |
+
+目标代码范围以原任务 `pages/flight/index.vue`、`pages/flight/home-v1.vue`、`pages/flight/home-v2.vue` 及所需底栏组件为候选；真实允许写入路径须在未来独立验收前由当前任务确认，不能由本文件概括授权。原始 Vault 设计正文、失败前 Git 工作区快照和当时桌面 Host 版本未在 A0 中取得，因此 F-03 不是“已准备好的实施用例”，也不补造摘要或确认值。
+
+## 3. 一次 Host 能力核对与隔离探针
+
+本机可执行的 Codex CLI 报告 `codex-cli 0.146.0`，`codex features list` 报 hooks 为 stable。它不能证明历史移动端任务或当前桌面 Host 使用完全相同的二进制版本。官方 [Hooks 文档](https://learn.chatgpt.com/docs/hooks)说明 `PreToolUse` 支持 Bash/unified exec、`apply_patch`、MCP 和其他本地函数工具，`spawn_agent` 可按 `Agent` 匹配；同时明确存在可绕开默认 hook 路径的专用工具，hooks 是 guardrail 而非完整 enforcement boundary。`write_stdin` 给已放行的命令送入数据时不再次触发 `PreToolUse`。
+
+| 写入通道/情形 | 接口事实 | A0 判定 |
+| --- | --- | --- |
+| 直接编辑/patch | 常规 `apply_patch` 有 `PreToolUse`；专用工具路径可能绕开默认 hook | **未获完整覆盖证明**，不能标记 enforced |
+| shell 写入 | Bash/unified exec 有 `PreToolUse`；已启动会话的 `write_stdin` 不重新预检 | **未获逐次写入保护证明**；可在初次命令前检查，但不能把 hook 等同 OS 写入边界 |
+| 子任务写入 | `spawn_agent` 可匹配 `Agent`；子任务工具原则上可匹配常规本地路径；`SubagentStart` 的 `continue:false` 不阻止启动 | **未获全通道覆盖证明**；不能用启动提示代替禁止写入 |
+| 恢复旧交接后写入 | 可在支持的工具前重算摘要，但仍依赖 hook 持续启用及覆盖 | **未获 fail-closed 证明** |
+| hook 出错、缺席或超时 | 官方文档说明 MCP hook 出错/服务器缺失不阻断；不受支持的 `PreToolUse` 输出字段会使 hook 失败而工具继续；非托管 hook 需信任且可由配置关闭 | **不满足** docs/33 的“故障拒绝写入”标准 |
+
+隔离探针组限定在本地 Mac 沙箱帮助/启动检查，不调用 Provider，也不改真实项目：执行 `codex sandbox macos --help` 即返回 `sandbox-exec: sandbox_apply: Operation not permitted`（退出 71）。因此未能进入四类写入的实际动态探针，不能把这个系统限制当成“写入已被阻断”的成功测试，也不能说已经复现 hook 绕过。官方 [Agent approvals & security](https://learn.chatgpt.com/docs/agent-approvals-security)另有 read-only 沙箱配置，但它禁止一般写入；把它变成任务就绪后可写的可信受控启动器，是另一种 Host 运行模式，不是本次普通 Codex 桌面任务已接入的保护。
+
+## 4. A0 停止结论
+
+**blocked。** 按 docs/33，任何未覆盖的允许写入通道，或 hook 故障不能 fail closed，都不能宣称 `enforced`。本次官方接口已经给出两类决定性限制：专用工具可能绕过 hook，且 hook 错误路径可继续工具调用；本地隔离探针又因嵌套沙箱无法补足实际 Host 覆盖证据。故 A1 的 `task-handoff` 本地编译器即使可写，也不能在此 Host 范围承诺“未就绪时强制阻止所有业务写入”。
+
+指导模式可以提供项目卡片、交接缺口和自然语言提醒，但不得以它通过宪法 7.3 的强制保护验收。这里按 A0 停止规则收口：不自动换 Host、不开发 Agent Runtime、不开始 A1/A2、不修改宪法，也不再开启修复探针轮次。若将来重新选定受支持的受控 Host/写入范围，需要先有单独范围决定，再用该范围的真实写入接口与 F-01 至 F-04 验收；本文件不预授该决定。
+
+## 5. Project Context 与授权记录
+
+本产品仓库以源码 `node bin/project-context.mjs` 运行自托管查询（本仓库没有 `node_modules`，未临时下载包）。A0 前后状态均为 `clean / contract-ready`。最终针对 `docs/33`、本文件和 `PROJECT_STATE.json` 的 Context 命中 `discovery.role`、`documentation.hierarchy`、`governance.authority`、`governance.human-approval`、`policy.registration-coverage`、`product.identity`、`product.kernel`、`product.permanent-boundaries`、`product.promise`、`projection.ownership`、`release.readiness`、`source.truth.real-project-maintenance`、`validation.acceptance`、`work.current-authority`、`work.next-candidates`。两份 docs 为 `scoped`，`PROJECT_STATE.json` 为 `project-only`，并有 `project-scope-only` gap；后者没有额外业务语义覆盖保证。required 为根 `AGENTS.md`、宪法、`docs/33`、本文件、`PROJECT_STATE.json`、`RTK.md`；本次按需另读 conditional 的 `docs/32` 方向与停止约束，没有遍历无关 conditional/provenance-only 文档。关键外部 gap 是历史桌面版本、失败前项目快照和原 Vault 设计摘要不可核；这些不得由当前文件代替。
+
+用户授权仅为 A0。目标仓库只读；未安装依赖、未调用模型 Provider、未运行目标构建、未改目标代码、未执行 Git 写入或发布。官方文档查询是本次 Host 能力核对的只读网络访问。

package/docs/35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md

@@ -0,0 +1,248 @@
+# 35 — 上下文管理与跨 Agent 任务交接设计
+
+> 日期：2026-09-29。状态：本地 L 已按本文在 1.10.0 实现；H 的真实 Agent 验收尚未完成，发布事实以当前 registry 和 `PROJECT_STATE.json` 为准。本次复审结论和 H 执行界限见第 13 节。下文第 2、9、10、12 节中标明“本轮”“实现时”的叙述是原 D 设计冻结时的记录，不表示当前仍未实现。
+> 用户已明确定位：“主要管理上下文，至于执行无非在上下文中给出明确的管控门禁”。原 D 阶段只授权设计；后来用户另行授权 L 实现及 H 下一步执行。当前真实项目的设计内容和版本默认规则仍不能由该授权推定。
+> 本文取代 docs/33 的后续实施方案；docs/33 的 BR 修复事实保留，docs/34 只保留 Host 钩子调查事实。A0 的硬拦截阻断不再是本设计前置条件。长期规范采纳与旧文档同步清单见第 11 节，不能把本文冒充已批准 Project Contract。
+
+## 1. 产品职责与成功标准
+
+Project Context 管理项目和任务上下文，向 Agent 提供来源明确、状态准确、可以直接遵循的执行门禁。Agent 读取入口、取得当前任务依据、遵守门禁并执行用户授权的工作。产品不拦截工具、不接管 Agent Runtime、不调用模型、不替人授予实施权限。
+
+入口继续是项目 `AGENTS.md`。其内容是稳定路由与操作规则，不堆积每项需求正文。项目长期真源仍是人工批准的 Contract；任务记录只保存本需求的依据、决定、进度和待办。切换 Agent 时读取同一组文件、调用同一组本地命令；不依赖上一段聊天、某款 Agent 的钩子或专属会话 API。
+
+成功标准是：新 Agent 能找到正确任务，指出依据和缺口；在缺少实施依据或当前仅允许设计时遵守停止规则；补齐依据后继续原任务，不反复重建计划。这里承诺可核对的上下文与执行规则，不承诺任何 Agent 都不可能违反规则。
+
+## 2. 基于当前实现的重新审查
+
+基线为本地源码 1.9.1，包含上一轮 BR-01 至 BR-05 对应的两个未发布修复。本轮未改运行代码，也未将历史 242 项测试结果冒充新功能验收。
+
+| 审查点 | 当前证据 | 本设计处理 |
+| --- | --- | --- |
+| 项目状态已有独立语义 | `project-status.mjs::buildProjectStatus` 分别给出 health、entry、contractReadiness | 复用；修正 docs/32 将问题概括为“内核混合状态”的说法。缺的是任务消费与交接。 |
+| Context 不是业务设计搜索器 | `context-bundle.mjs::buildContextBundle` 按显式路径和已批准 scope 选项；locate 仅给 project scope | 需求明确引用的设计必须由 Host 定位并列入任务依据；不能期待 CLI 猜到 Vault 资料。 |
+| Context 成功不等于任务可实施 | 当前 gaps 含覆盖及读取缺口，`semanticCompleteness=not-claimed` | 保留旧命令兼容性；新交接结果明确 gate 和本次意图。 |
+| required 不等于全部文件必须已经存在 | `consumptionRecords` 把任务目标列为 required，目标可能是待新建文件 | 交接层区分已有读取目标、必需依据与计划产出；新文件不存在不是需求缺失。 |
+| 旧阶段协议有用但不适合成为所有任务的模板 | `task-context.mjs` 验证 Plan/Receipt/阶段依赖及快照 | 多阶段既有流程继续使用；新协议不要求普通任务额外造 Plan/Receipt，不把旧 ready 转成业务就绪。 |
+| AI Entry 当前只要求报告 gap | `ai-entry.mjs::ENTRY_LINES` 未提供完整任务选择、业务缺口门禁与恢复步骤 | 同一入口增加本设计的消费流程；不添加 Host 钩子。 |
+| docs/33 的临时目录无法可靠支持换窗口 | 原方案无固定任务发现位置 | 引入一个最小持久任务文件；先解决查找和续接，不引入任务数据库。 |
+| 旧读取声明不能证明新 Agent 已读 | 原方案未充分区分需求证据与消费者读取状态 | 持久化事实和决定；本次读取声明单独提交，换消费者后重新消费。 |
+| 只做设计也可能有任务和未知项 | 原方案将只读完成表示为 taskStatus=none | 改为按 intent 判断当前门禁；设计允许保留后续实施问题。 |
+| 原子替换不等于多写者协调 | `io.mjs::atomicWriteFile` 是临时文件加 rename，没有任务记录事务锁 | 首版明确单任务单写者，不宣称自动合并并发；发现变动先重读、停止覆盖。 |
+| 主线被 Host 硬保护绑住 | docs/33 BA-13、docs/34 A0 | 删除这一主线门槛。执行偏离归入 Host 行为，不能因此持续扩张上下文内核。 |
+
+本轮确认的是这些设计问题，没有新增已复现的运行时漏洞。保留已有路径保护和完整 scope 修复，不借重新设计重写治理内核。
+
+## 3. 首个版本的固定范围
+
+本次实施只包含两项只读能力和一个入口流程：
+
+1. `project-brief`：项目概览、治理缺口、可发现的任务候选；没有开发需求时不创建任务。
+2. `task-handoff`：读取显式任务记录，复用完整 Context，给出当前依据、缺口、门禁和下一动作。
+3. AI Entry：项目概览 → 选择任务 → 定位/消费依据 → 遵循门禁 → 保存交接事实。
+
+最小任务记录及换消费者重新读取属于首版必要范围。自动任务编排、并发协作管理、提醒调度器、环境状态机、Git 操作、业务执行器、工具拦截、网络拉取、批量改造不同 Agent 配置均不进入首版。钩子不列为必做后续阶段；只有另有明确需求时才独立讨论。
+
+## 4. 真源、保存与选择
+
+### 4.1 文件职责
+
+| 位置 | 内容和所有者 |
+| --- | --- |
+| `.project-context/` | 既有人工批准的长期 Contract、来源与投影锁；沿用已有治理命令 |
+| `.project-context-tasks/<taskId>.json` | Host 在获准记录上下文时保存的单任务事实；不注册成 Contract source，不存长期规则 |
+| `.project-context-tasks/.requests/` | 可选的本次交接输入文件；不参与任务发现，不作为跨会话真源 |
+| 现有需求/设计文件 | 保留原位置；任务记录只引用，不复制第二份可编辑设计 |
+| 根 `AGENTS.md` | 指向本地 CLI 与上述位置；既有人工内容继续保留 |
+
+产品的两个新命令都不写文件。Host 用已有文件编辑工具维护任务记录；这是任务上下文维护，不是批准长期 Contract。只读请求没有文件写入权限时，Host 可在响应中输出待保存记录，明确 `persisted=false`，不能声称新窗口会自动续接。不得为每次只读问答强制落文件。
+
+首版不支持两个 Agent 同时写同一 taskId；不同任务用不同文件。更新前 Host 重读现有 revision/digest，与开始编辑时不符就停止覆盖并展示差异；revision 增一且记录 previousDigest。该检查是操作规则，不宣称对不遵循规则的并发写者提供原子 CAS。损坏 JSON、重复 ID、项目不符均阻断该记录，不静默重建。完成任务改 lifecycle，不自动删除；无后台清理。
+
+### 4.2 如何找到当前任务
+
+`project-brief` 只枚举 `.project-context-tasks/` 顶层普通 `.json` 文件，按 taskId 稳定排序，不跟随符号链接；展示 ID、标题、lifecycle、目标路径摘要和未决点数量，不输出全量正文。没有目录视为空，不创建目录。单文件超过 256 KiB 或候选超过 100 个时返回明确的 `task-discovery-budget-exceeded` 与“提供 taskId”动作，不按时间静默截断选择。
+
+用户明确给出 taskId/文件路径时精确读取；“继续”且只有一个 active 候选时展示身份并核对本次目标，确认相符才续接。多个候选或目标不符时问一次具体选择问题，状态为 discovering。不能以最新修改时间、当前分支名或上一个 Agent 的会话 ID 自动决定任务。零候选则报告无可续接记录，定位用户明确提供的设计/当前改动；不得制造“已恢复”。
+
+存档任务只在显式选择时读取；恢复须由用户当前意图支持。复制到其他工作区的记录需核验 projectId、目标范围及可选 workspaceLabel；标签是 Host 提供的线索，不证明 Git 分支。不同 Agent 或机器得到文件的方式由用户现有工作区同步决定，产品不负责传输。
+
+## 5. 数据合同（首版 schemaVersion=1）
+
+实现时 JSON Schema 与运行时校验必须同时覆盖以下字段；未知版本、未知字段、重复 ID、悬空引用、非法路径都返回明确错误，不静默丢弃。
+
+### 5.1 持久任务记录：kind=task-context-record
+
+| 字段 | 最小语义 |
+| --- | --- |
+| `projectId, taskId, title` | 项目绑定；taskId 使用安全文件名字符，不允许路径分隔符；文件名必须匹配 taskId |
+| `revision, previousDigest` | 从 1 开始；首版 previousDigest 为 null，后续引用上版内容摘要；可追溯提示，不是防篡改证明 |
+| `origin` | 用户任务原文或可读取的任务依据；仅有某个 Agent 的私有会话链接不算可移交正文 |
+| `lifecycle` | active / completed / cancelled；与当前任务就绪状态分开 |
+| `scope` | readPaths 是待读相对路径；writeTargets 为 `{path, operation}` 条目，operation=create/modify/delete，表达候选修改范围而不授予权限；可选 workspaceLabel |
+| `requirements[]` | ID、内容、来源引用、appliesTo（investigate/design/implement）、blocking、evidenceIds；实现任务至少有一条明确要求，不能用空数组获得 ready |
+| `evidence[]` | ID、用途 requirement/design/decision/implementation/reference、定位方式、内容摘要和证据身份 |
+| `decisions[]` | ID、问题、appliesTo、blocking、状态 open/confirmed、确认值与来源；Host 推断不得标 confirmed |
+| `progress` | 已完成条目及依据、未完成项、已知实现文件、下一动作；完成声明须区分静态检查与实际运行 |
+
+scope 为空只允许 discovering；implement 必须明确目标和范围。简单样式/字段连接可直接使用用户原话和源码作为证据，不要求另造设计文档。设计/规则来自文件内容，不能从文件名或框架白名单生成。
+
+本地 evidence 使用项目内相对路径，摘要由 CLI 重算；明确用户原话可以 inline 保存并以 canonical JSON 求摘要，来源注明 user-statement。外部资料由 Host 在其已有权限内读取，记录来源与可移交摘录，身份为 host-asserted；CLI 不联网验证它。只有 URL/文件标题、没有可消费内容时仍是 missing。外部资料“当前有效”的判断保留其确认来源，不能冒充本地摘要校验结果。
+
+任务记录不是安全策略源：其中要求不能覆盖用户当前指令、人工项目规则和长期 Contract；相冲突时输出冲突与需确认项。它不保存凭据、完整聊天、推理或全量 diff。
+
+### 5.2 本次输入：kind=task-handoff-input
+
+`recordPath` 或 `record` 必须且只能给一个：前者定位已保存记录，后者支持不落盘的只读任务。另含 `intent`（investigate/design/implement）、`consumerRunId`、可选 `consumption`。continue 表示选择旧记录，随后必须确定这次的实际 intent，不作为第四种执行权限。
+
+Host 为每次新消费者运行生成 consumerRunId，无需绑定厂商会话 API。consumption 只包含本次 Context digest、消费者 ID、实际读取项的 path/摘要或 inline evidence ID、conditional 的读取结果或不适用原因。首次调用可不含 consumption，输出待读清单；Host 读取后再提交复查。声明只证明 Host 报告了消费，不能证明模型内部理解。
+
+历史记录不保存可复用的 ready 或当前读取声明。新消费者必须重读适用 required 依据；同一消费者仅补读变化/新增部分。旧 confirmed 决定在来源未变时仍有效，不要求用户重复确认。任务记录必须被新消费者读过，但不把记录全文摘要作为其自身 evidence，以免每次更新 progress 都使需求失效。
+
+### 5.3 输出：kind=task-handoff-result
+
+固定包含 projectHealth、taskIdentity、intent、taskStatus、gate、contextBundleDigest、recordDigest、requirementsDigest、progressKey、实际 itemIds、scopeCoverage、required/conditional targets、evidenceResults、gaps、questions、nextAction、`authorityGranted=false`、`semanticCompleteness=not-claimed`。
+
+gate 固定含 `mode=instructional`、`currentAction=read-only|implementation`、`status=hold|proceed|not-applicable`、reasonIds、Host 应遵循的短指令。proceed 仅表示已声明上下文满足当前动作，不表示用户已授权执行；不能增加 `enforced=true` 或“所有写入已被保护”。
+
+## 6. 两个只读命令和状态判定
+
+```text
+project-context project-brief --project PATH [--json]
+project-context task-handoff --project PATH --input FILE_OR_DASH [--json]
+```
+
+默认输出面向人的“已确认、待核实、需要决定、下一步”；JSON 保留完整核验信息。`--input -` 从 stdin 接收本次 JSON，允许只读任务通过 inline record 使用交接而不先写临时文件；文件输入必须位于项目内。本次输入最大 512 KiB，记录最大 256 KiB，超限返回明确错误，不截断。project-brief 复用 status 和 locate：未初始化时给出包内初始化入口，不自动 setup；partial/invalid 不加载无效 Contract。任务输入、记录、证据和计划新路径均复用项目内路径与符号链接校验；外部证据由显式声明表达，不允许任意文件系统路径逃逸。
+
+task-handoff 复用完整 buildContextBundle；从 scope.readPaths、writeTargets 的 path 和本地必需 evidence 组成完整最小目标集合。不再新增 selector，不把 adaptive/stage.ready 转成 taskStatus。
+
+| 判定优先级 | taskStatus | 当前 gate / 下一动作 |
+| --- | --- | --- |
+| 输入非法、项目不符、路径逃逸、记录损坏、治理无法安全提供 Context | blocked | hold；报告精确修复动作，不自动治理 |
+| 任务/目标未锁定，或多个任务未选择 | discovering | hold；一次定位或一次选择 |
+| 当前动作所需证据缺失/过期、required 未消费 | needs-evidence | hold；列出具体资料及待读项 |
+| 当前动作所需人工决定未知或冲突 | needs-decision | hold；列出具体问题 |
+| investigate/design 所需依据齐备 | ready-for-read-only | proceed/read-only；可完成当前调查或设计，不得升级成实施 |
+| implement 所需依据齐备 | ready-to-implement | proceed/implementation；Host 另外核对当前授权后执行 |
+| 显式读取 completed/cancelled 且未请求恢复 | inactive | not-applicable；展示交接，不能自动开工 |
+
+所有 gap 均返回，优先级只决定主状态。无任务的 project-brief 使用 taskStatus=none。任务完成与否由 lifecycle/progress 表达，不用 none 冒充设计任务完成。
+
+退出码：0＝概览可用或本次动作上下文就绪/任务 inactive；1＝needs-governance、discovering、needs-evidence、needs-decision；2＝blocked/非法输入。旧 status/context/stage 的退出含义不变。
+
+例外必须显式处理：operation=create 且目标不存在时，输出 `planned-output` 并检查父目录/适用规则，不伪造“已读取”；目标初次核验就存在则报告操作冲突，先重新核对。若本任务已创建该文件且 progress 记录了对应产出及摘要，续接时把它作为现有实现读取，不报创建冲突，也不重复创建。modify/delete 的待处理目标须存在并读取；已由本任务完成删除且有进度依据的目标仅作为完成事实，不重复删除。尚未归属的创建/删除仍报告待核对。writeTargets 保留任务范围，完成状态由 progress 表达，不为每次进展改写需求范围。不存在的必需设计不能借 planned-output 豁免。project-only 是覆盖提示，不能自动判业务缺失；Host 用用户原话和源码补足短期依据，并保留覆盖声明。治理漂移沿用既有停止规则，不在本轮偷偷改成局部放行。
+
+## 7. 入口门禁与跨 Agent 流程
+
+AI Entry 在既有启动流程之后交付以下规则：
+
+1. 没有任务先显示项目概览。有任务优先选择/建立明确任务记录，列出用户显式给出的需求和设计，不能只凭项目 clean 开工。
+2. 编译当前目标 Context，消费 required；conditional 给出本次是否适用的判断。设计、接口或关键决定缺失时，按本次 intent 判断门禁。
+3. 当前仅授权调查/设计时，完成对应产出并记录后续问题；当前要实施而 gate=hold 时，停止受阻业务修改，允许获准的定位和补齐依据。
+4. gate=proceed 后仍遵守当前用户授权及允许范围。发现新增目标、设计/决定变化或来源漂移时，在下一批相关修改前重算交接；不要求每次工具调用都运行 CLI。
+5. 阶段结束或需要交接时，记录实际完成、验证边界、未决点和下一动作。换 Agent 后重新消费，而非复用旧 ready。
+
+支持 AGENTS.md 的 Agent 从原入口读取；不支持的 Agent 可通过其已有指令入口显式引用同一文件和本地命令。首版只输出接入说明，不批量写各厂商配置、不维护复制的第二套任务规则。入口是否实际被该 Agent 读取要用实际运行验证；不能宣称所有 Agent 自动兼容。缺少本地执行/读文件能力时，报告消费限制，不隐藏为已接管。
+
+## 8. 变化、去重和有限收敛
+
+requirementsDigest 只包含任务身份/意图相关需求、范围、依据摘要、适用 Contract 语义和已确认决定；不包含更新时间、progress 文案、当前消费者 ID或交接次数。recordDigest 表达整份记录版本，不能代替 requirementsDigest。progressKey 在前者基础上包含稳定 gap ID、当前消费完成集合与下一动作；相同事实和消费情况必得相同结果。
+
+合法范围内实现代码变化更新实现事实，不能自动判需求过期；如该文件同时是必需需求依据则按依据变化处理。源码变化需要读最新实现，但不重新询问未变的业务决定。Contract 快照变化仍重新编译，适用内容未变则沿用有效决定，不能跳过既有来源维护门禁。
+
+每个不变缺口最多一次定位调查、一次有新资料的复查；没有新事实就停在原状态，不以新 taskId、新消费者 ID 或重写文件解除。新 Agent 仍须读取当前依据，但读取后应沿用同一未决问题，不把已知失败调查再跑一遍。新的用户决定/资料/范围变化允许继续。已读但无答案与未读文件必须区分。
+
+事实不足归项目数据；入口未读/读后违背明确门禁归 Host 行为；错误 ready、漏报显式缺口或错误失效归产品缺陷；工具不可用归环境；基线/预期缺失归验收准备。只有有复现的产品缺陷进入内核修补。Host 偶发违背不自动产生钩子、沙箱或新 Runtime 需求。
+
+## 9. 实现落点与兼容
+
+原设计要求增加 project-brief、task-handoff 两个命令及相应 schema/验证模块。当前实现将两个命令的核心逻辑合并放在 `src/project-context/task-handoff.mjs`，任务枚举、记录加载和摘要计算属于该模块内部；没有新增写入服务。它复用 project-status、context-bundle、scope compiler、canonical JSON 和 path-policy。
+
+修改 `ai-entry.mjs` 的受管内容、包内初始化指引、capabilities 和命令说明以提供新入口。新记录/input/result 均 schema 1；旧 Context、Plan、Receipt、Contract/store schema 不变。新增能力所需 capabilities/renderer 升版按已有兼容惯例在实现时一次完成，旧入口仍能读取，不在本设计阶段先升包版本。
+
+已有 stage Plan、Receipt 和任意项目设计不自动迁移。Host 可以依据它们创建有来源的简短任务记录，但不能把旧 stage.ready 当成本次已读。既有业务设计文件保留；任务记录引用之，不改其项目语义。没有任务目录的旧项目正常显示“尚无记录”。
+
+## 10. 固定验收与实施停止点
+
+以下 CF 清单是本设计唯一首版验收集合，不能在实施中不断追加产品方向。
+
+| ID | 固定场景与预期 | 证据 |
+| --- | --- | --- |
+| CF-01 | 无任务/无记录：概览准确，不造任务、不写文件；未初始化与异常治理状态有明确恢复入口 | CLI fixture |
+| CF-02 | 简单已确认改动：无独立设计文件、project-only 仍可在短期依据充分后 ready | 单元/CLI |
+| CF-03 | 用户明确引用设计但不可取得：needs-evidence，不输出实施就绪，提示具体缺口 | CLI + Host |
+| CF-04 | 同一任务缺版本字段/默认值：implement=needs-decision；design 可记录未知项完成设计 | CLI + Host |
+| CF-05 | 补齐设计、确认值和本次读取后 ready；普通 context exit 0 不能代替这一过程 | CLI + Host |
+| CF-06 | 计划新文件不存在不阻断，自己已创建/删除且记录进展的文件可续接，不重复操作；必需设计不存在仍阻断；目录/文件链接越界被拒绝 | 单元/CLI |
+| CF-07 | 换消费者读取同一记录，旧消费无效；未变确认值保留；无旧聊天也能解释下一步 | CLI + 新会话 |
+| CF-08 | 多 active 任务不猜选；项目不符、存档、记录损坏、枚举超预算均有确定结果 | CLI |
+| CF-09 | 重复同输入产生同 gap/progressKey；无新事实不重复调查/问答；新证据可恢复 | 单元 + Host |
+| CF-10 | 需求/范围变化重算，普通实现进展不让需求自我失效；不相关变化不重复业务确认 | 单元/CLI |
+| CF-11 | 非法 schema/重复 ID/悬空引用/跨任务消费/外部仅有 URL 不得 ready；外部 Host 声明不伪称验证 | 单元/CLI |
+| CF-12 | 只读命令不写 store/任务文件；Host 只读模式明确未保存；记录冲突不宣称自动合并 | CLI + Host |
+| CF-13 | 更新入口保留人工字节和已有所有权检查；旧 context/stage/初始化流程继续通过原回归 | 回归 |
+| CF-14 | 两个不同 Agent 产品各自经真实入口消费同一案例，行为遵循门禁；无钩子依赖 | 实际 Agent 记录 |
+
+实施顺序只有三个停止点：
+
+1. **D：设计交付（本轮）**。完成本文、审查问题及精确规范采纳清单。A0 不再阻断。源码无新功能修改。
+2. **L：本地最小闭环**。在用户授权实现后，同步第 11 节规范与治理来源，完成两个命令、记录读取、入口指引和 CF-01 至 CF-13 的可本地验证部分。最多两轮修复复验；通过后停止，称“本地上下文交接通过”。不为了等待另一个 Agent 扩张实现。
+3. **H：实际消费验证**。事先固定案例目录、输入文件摘要、操作预期及两个 Agent 的名称/版本/入口方式；不用当前设计讨论作为隐藏提示。验证缺设计停止、补齐后继续、换 Agent 接续及重复缺口不循环。无钩子要求。按第 13 节分别记录重建样例的跨 Agent 机制证据和真实移动端业务证据；任一必要证据缺失，CF-14 总结论为 pending/partial，不冒称通过。
+
+移动端案例沿用 docs/34 记录的失败信号：明确引用设计、版本字段及默认规则未知。原失败前快照缺失不是编译器无法实现的理由：本地使用明确标为“重建回归 fixture”的最小样例；真实验收另用获准的隔离副本，固定当前基线和已确认验收，不能称作历史现场重放。当前缺真实企业字段不妨碍验证停止行为；正向用例使用明确标为测试数据的值，不把它写成真实接口决定。
+
+各停止点最多两轮修复，仍失败则保留最小复现与归属，不自动第三轮；新需求进入候选。测试数量、状态 clean 或记录文件存在都不是 H 的完成证明。打包、发布、真实目标升级和 B/C 环境能力不随 L/H 自动开启。
+
+## 11. 规范采纳清单与当前文档权威
+
+用户已明确否定“必须钩子”的主线前提；本设计据此完成。为避免设计批准与长期 Contract 批准混淆，本轮保留宪法/已批准 Contract 的历史原文；以下是进入实现时必须一次同步的精确语义，不需要再研究 Host 钩子：
+
+| 现有位置 | 要同步的具体内容 |
+| --- | --- |
+| 宪法第 4.8 项 | 将“受支持 Host 的实施前保护”改为“向 Host 提供当前任务的上下文门禁；Host 遵循门禁，产品不拦截工具或执行任务” |
+| 宪法第 7.3.6 项 | 改为“入口和交接结果明确当前意图、缺口、停止与继续条件；通过真实 Agent 验证遵循情况，不承诺全通道技术强制” |
+| 宪法第 8 节末段 | 产品失败判据为显式缺口漏报/错误就绪/交接不可消费；Host 不遵循正确门禁单列归因，不强制新增保护器 |
+| docs/32 第 6、7、12 节及来源引用 | 上下文门禁替代实施拦截；最小跨消费者记录提前纳入 L；更广生命周期仍分期 |
+| docs/33 第 4、9、10 节 | 后续方案由本文取代；BR 代码修复证据不改写 |
+| docs/34 | A0 历史结论保留，明确不再作为上下文交接前置 gate |
+| PROJECT_STATE 的 next/planning/executionAuthority、RTK、文档索引 | 统一指向本文的 L 停止点和实际授权，消除旧“等待 A0 Host 选择”路由；实现与发布状态仍如实区分 |
+| Project Contract 的受影响来源及 items | 用 review-source → 精确接受变更 → revise/人工批准 → sync/check/status 的既有流程采纳；不得直接编辑 store 或只改索引而保留矛盾规范 |
+
+本轮在 PROJECT_STATE.localReview 记录最新设计和用户定位，旧 `/next` 与长期 Contract 仍代表此前已批准阶段计划，不能据此启动旧 A0 或跨越当前用户授权。L 的第一项工作必须消除这一过渡状态，然后才实现新命令。本文细则未自动批准为长期规范；这是一项有限的采纳工作，不是新的产品研究阶段。
+
+## 12. 本轮审查与验证记录
+
+离线 npm exec 启动因 npm 缓存 EPERM 失败；按本产品源码仓库先前已采用的方式，用 `node bin/project-context.mjs` 核对，未下载或安装包。初始自托管状态 clean/contract-ready。
+
+本轮 Context 命中 28 项：`ai.exchange.boundary`、`dashboard.design`、`discovery.role`、`documentation.hierarchy`、`governance.authority`、`governance.human-approval`、`guided.onboarding.ai-reconciliation`、`implementation.runtime`、`implementation.status`、`implementation.version`、`knowledge.maintenance`、`policy.registration-coverage`、`product.identity`、`product.kernel`、`product.permanent-boundaries`、`product.promise`、`projection.ownership`、`release.readiness`、`source.lifecycle.closure`、`source.truth.real-project-maintenance`、`task.context.adaptive-bounded`、`task.context.branch-aware-staged-handoff`、`task.context.consumption-closure`、`task.context.human-centered-lifecycle`、`task.context.integrity-repair`、`validation.acceptance`、`work.current-authority`、`work.next-candidates`。
+
+required 消费了 AGENTS、RTK、宪法、docs/32—35、PROJECT_STATE 有关字段及本轮四个目标模块。docs 和源码目标为 scoped；PROJECT_STATE 为 project-only，保留 `project-scope-only` gap。conditional 按任务读取 package scripts；额外核对 io 写入原语，没有遍历历史 provenance-only。上述事实只能支持本设计，不证明新命令已实现或跨 Agent 验收已通过。
+
+交付前核对：PROJECT_STATE JSON 可解析，最新设计路径存在，CF-01 至 CF-14 无重复/缺号，`git diff --check` 通过，自托管仍为 clean/contract-ready。本轮仅修改设计及状态记录，没有运行新功能测试或启动真实 Agent 验收。
+
+## 13. 实施后复审与 H 阶段执行判定（2026-09-29）
+
+### 13.1 当前实现与未完成证据
+
+复审时本地源码为尚未发布的 `1.10.0`，`project-brief`、`task-handoff`、schema 1 任务记录和 AI Entry renderer 6 已存在；当时本地回归为 248 项通过，自托管为 `clean/contract-ready`。这些证明 L 的本地行为，不证明两个真实 Agent 已读入口、遵守门禁或理解移动端业务。第 2、12 节的 1.9.1/242 项和“功能尚未实现”是 D 阶段历史快照，后续动态状态以 `PROJECT_STATE.json` 为准。
+
+用户已授权 H 下一步执行，毋须重复请求授权；但原失败前快照、Vault 设计正文的当前可消费路径、版本字段和值域、空值/失败默认规则尚未固定。不能把 docs/34 的 A0 文件摘要当成当前真实项目依据，不能用测试值替用户确认业务规则。缺这些输入时，可以完成明确标记的重建样例机制验证；真实移动端正向实施验收保持 pending，并在一次定位后停止等待新事实，不反复重试。
+
+### 13.2 H 预检、运行和证据等级
+
+每个 H 案例先固定：隔离目录的规范化真实路径、当前源基线和允许读写范围、任务原话、任务记录及输入摘要、预期门禁与可观察动作、两个不同 Agent 产品的名称/版本/启动入口、是否需要其原生入口文件。CLI 与依赖必须使用本地已存在版本；工具、身份或路径校验失败归环境/验收准备，修正后才可计入 Agent 运行。不得修改真实目标项目或把失败前现场伪装成当前副本。预检失败不算 Agent 行为失败。
+
+两次 Agent 运行都只给固定案例任务和正常入口，不塞入本设计的预期答案或前一 Agent 聊天。若某 Agent 不自动读取 `AGENTS.md`，允许在隔离目录加入一个仅指向根入口的原生适配文件；固定其内容和摘要，并把“通过显式适配入口”写进结论，不能声称它原生支持 AGENTS。记录实际入口读取、CLI 调用、本次 required/conditional 消费、gate、文件变化和最终答复；Agent 未读入口或读后违背 gate 归 Host 行为。样例或安装包若含本设计/测试期望，须核对运行日志；Agent 读到隐藏期望的运行不得计入盲验。
+
+证据分两级：**H-S 重建样例**用清楚标为测试数据的设计/字段/默认规则，验证两个真实 Agent 在同一任务的缺口停止、补证续接、换消费者重读与相同缺口不循环；通过只能证明跨 Agent 交接机制。**H-R 真实移动端**在获准隔离副本、当前设计与业务决定均可消费后，以真实项目来源复验同一行为及允许范围；历史失败前快照缺失时称“当前基线复验”，不称“历史重放”。CF-14 总体通过需要 H-S 与 H-R 都有合格的实际 Agent 记录；H-S 通过而 H-R 缺输入时明确记为 `partial:mechanism-passed-real-business-pending`。
+
+同一缺口无新事实时至多定位一次、补证后复查一次；每个可复现的产品缺陷最多两轮修复复验。超出后保存最小复现、归属和剩余缺口，停止 H，不转向钩子、Runtime 或新产品阶段。环境路径准备失败可修正，但不能算作两个 Agent 已运行；只读 CLI、248 项回归或 `clean/contract-ready` 均不得单独关闭 CF-14。
+
+### 13.3 当前执行安排（用户后续决定）
+
+用户决定目前不做 H 验证，等待真实项目中的任务来检验交接行为，发现实际缺陷后再回到本产品修复。因此不启动已准备的重建样例，也不为凑齐第二种 Agent 工具而安装、替换或调用其他工具。第 13.2 节保留为未来判读证据的方法，不是当前执行清单；H-S 不再是当前必跑前置步骤。真实项目出现可观察案例时，先固定当时的项目基线、任务、设计/决定来源、Agent 入口和实际读写记录，再按事实区分产品缺陷、Host 行为、项目数据及环境问题。没有可用的第二种 Agent 时，跨 Agent 的 CF-14 仍标为未验证，不借单 Agent 或本地回归宣称通过。
+
+当前停止点是“等待真实项目证据”。没有新案例就不重复构造 fixture、运行 Agent 或开启修复轮次；后续只对实际复现且属于产品的缺陷执行原有最多两轮修复复验规则。此安排不改变 L 的已实现范围，也不授权目标项目写入、发布或新产品能力。
+
+### 13.4 发布与真实项目接入的独立顺序（用户后续决定）
+
+用户随后要求先正式发布 `1.10.0`，再由真实项目窗口把开发依赖精确更新到该版本；本窗口在项目开始使用后只监听其 Host 输出，不直接运行目标项目命令。发布授权只使本地 L 能力成为可安装工件，不解除第 13.3 节暂停的模拟 H 验证，也不把安装成功当成 CF-14 或真实业务交接通过。目标项目更新及其 Git/构建动作由该项目窗口按自身授权执行；观察到实际产品缺陷后再回到本仓库限轮修复。