frontend-project-context 1.9.1 → 1.10.0

package/docs/36-PRODUCT-VALUE-AND-USABILITY-REVIEW.md

@@ -0,0 +1,158 @@
+# 全产品价值与可用性审查
+
+日期：2026-09-30。范围：当前自研仓库；先修复五类已复现的交接缺陷，再审查默认使用链路、治理内核、上下文交付、知识维护与生命周期。本文是审查结果和改进建议，不是新的长期 Contract、冻结的下一版本设计或发布事实。
+
+## 1. 结论
+
+当前产品已经能可靠管理“哪些项目规则经过批准、适用于哪里、来源是否变化”，但日常入口尚未充分回答开发人员最关心的三个问题：**这次修改有什么特有约束、能直接复用什么、为什么需要我作这个决定。** 默认流程让 Host 承担较多协议编排，却经常只交付通用工程事实和就绪状态。因此，用户感到使用生硬、装进真实项目后没有明显帮助，有可核对的产品原因。
+
+五类缺陷已经修复，交接可靠性得到改善；这些修复不能代替产品体验与真实业务价值验收。继续增加治理命令或单元测试，不能单独证明开发更准确、更省解释或跨窗口更容易继续。
+
+这个项目应当带来的意义是：让项目中**容易忘、容易误解、跨任务重复使用**的规则有明确来源，并在真正相关的开发任务中出现；让新窗口接得上已有需求、决定和进度；让依据发生变化时，明确指出会影响哪一步。若某项目只有技术栈、目录和脚本等低区分度知识，已有人工入口已表达得很好，维护成本可能大于新增收益，应诚实说明当前覆盖不足。
+
+## 2. 本次已经修复的缺陷
+
+| 问题 | 修复后的行为 | 回归覆盖 |
+| --- | --- | --- |
+| 同 ID 的 inline/external 证据更新后，旧消费声明仍可就绪；另一任务可复用声明 | 消费声明绑定 `taskId` 和当前 `requirementsDigest`；当前意图的需求、决定、证据、范围和有效合同内容变化时需重新消费 | 更新 inline/external 证据、跨任务复用、旧格式声明 |
+| 只有 design 需求也能进入 implement | implement 必须存在适用于 implement 的需求 | 设计需求不能充当实施依据 |
+| 仅供 implement 的证据缺失也阻断 design | 按 requirement/decision 的 `appliesTo` 选择当前证据；未被引用的证据仍作为共享任务上下文 | 未来意图证据缺失/变化不阻断设计，实施仍检查它 |
+| `./src/new.ts`、反斜杠路径与标准路径行为不同 | 校验规范化后的路径，并在交接执行视图、消费声明和进度匹配中一致使用；原始记录摘要保持对应原文 | create 豁免、进度别名、消费别名、规范化后重复路径 |
+| 目录 read target 触发 EISDIR，或永远等待文件摘要 | required 目录目标明确返回 `read-target-needs-file-scope` 与 `narrow-directory-targets-to-files`；收窄到具体文件后恢复 | 无声明/有声明均得到有限恢复动作，不自动扫描目录 |
+
+修改集中在 `task-handoff.mjs`、`task-handoff-schema.mjs`、公开 input schema 与交接测试。新增 6 项回归；`npm run check` 从 248 项增加至 **254 项，全部通过**。
+
+### 消费声明兼容说明
+
+公开 input schema 保留版本 1，新增两个可选属性。旧声明仍能解析，但缺少绑定时返回 `consumption-task-mismatch` / `requirements-not-consumed`，不能继承 ready。没有消费声明的首次调用仍返回待读清单。
+
+Host 必须先取得当前结果、实际阅读，再提交：
+
+```json
+{
+  "consumption": {
+    "taskId": "从当前结果的 taskIdentity.taskId 取得",
+    "requirementsDigest": "从当前结果取得当前 sha256 摘要",
+    "contextBundleDigest": "从当前结果取得当前 sha256 摘要",
+    "consumerRunId": "与本次 input 相同",
+    "readTargets": [],
+    "evidenceIds": [],
+    "conditional": []
+  }
+}
+```
+
+这是字段来源示意，不是可直接运行的完整输入；数组必须按实际清单填入阅读摘要、证据消费和 conditional 判断。不能仅复制摘要冒充已读。新字段需要本次修复后的 runtime；未修复的旧 runtime 不认识它们。进度更新不改变需求摘要；输出文件变化仍按进度及阅读摘要核查。
+
+## 3. 整个项目的审查覆盖与证据边界
+
+审查采用入口与关键执行路径源码检查、公开 schema/测试核对、当前 CLI 输出，以及仓库内既有真实项目观察；不是对每行源码或所有外部平台的穷尽证明。
+
+| 子系统 | 核对对象 | 判断 |
+| --- | --- | --- |
+| 产品身份与日常入口 | 宪法、RTK、PROJECT_STATE、README、初始化/操作手册、`ai-entry`、CLI | 产品身份清楚；机器流程与开发者体验之间有明显落差 |
+| 初始化与发现 | `initialization-instruction`、`discovery`、`project-store` | 有本地入口、目标根与来源边界；发现工程事实不会自动得到业务语义 |
+| Contract 与作用域 | `authoring`、`approver`、`scope-compiler`、`checker`、`source-reader`、`path-policy` | 来源、审批、作用域和隔离值得保留；clean 不证明业务覆盖完整 |
+| Context 与任务交接 | `context-bundle`、`task-handoff`、`adaptive-context`、相关测试/schema | 能确定选择和验证；默认消费存在重复编排与信息转译不足 |
+| 维护与安全写入 | `maintenance`、`project-store`、`io`、`projection-store`、入口所有权 | 来源接受会撤回受影响批准；写前核对摘要及恢复机制存在，不能为省步骤跳过 |
+| AI 交换与升级 | `exchange`、`upgrade`、capabilities 和全套测试 | 预检呈现 current/proposed 与 blocker；迁移复用既有受管写入，不执行业务任务 |
+| 阶段与环境流转 | `task-context` 相关入口/测试、`truth-reconciliation` | 核查 Host 提供的证据；不会自行观察 Git、CI 或线上事实 |
+| 可视化与反馈 | `dashboard-model`、`dashboard-renderer`、`evidence`、`a130-evaluation` | Dashboard 有知识卡片与治理数据，但未承载默认任务体验；A130 是外部结果评估器 |
+
+本轮未操作真实 PC/mobile 仓库、启动其他 Agent、调用 Provider 或执行发布。本轮未证明真实 Host 必定遵守交接门禁，也未完成 CF-14；仓库历史观察不能冒充今天目标项目的状态。
+
+当前 HEAD `cdf64de` 的提交标题写“1.10.1版本”，但 `package.json` 和 runtime 实际版本均为 **1.10.0**。本报告针对该提交后的本地修复，不把标题视作版本发布证据；未更改版本号或发布包。
+
+## 4. 优先处理的产品问题
+
+### V-01 / P1：项目概览没有交付项目知识
+
+代码依据：`src/project-context/task-handoff.mjs:54–89` 的 `buildProjectBrief` 由 status 与任务文件枚举生成；没有把有效 Contract 的 statement/value 组成开发者概览。`src/project-context/cli.mjs:382–391` 的人类输出主要是项目 ID、健康、任务数量和动作枚举。
+
+本仓库实际输出包括“治理 clean”“已发现 1 条任务记录”“确认是否继续 handoff-repair-and-product-audit”，最后给出 `select-task-by-id-or-describe-new-task`。开发人员仍看不出项目有什么值得使用的知识。这与宪法 7.3、已批准 docs/32 第 3 节的项目卡片目标有距离。
+
+建议：保持 `project-brief` 只读，从已批准 Contract 中呈现少量开发相关事实/规则及覆盖缺口；显示任务标题、已有进度和自然语言起步方式。缺少业务域知识时直接说明，不能把 healthy 包装成“已理解整个项目”。不要创造无任务记录，也不要根据技术栈自动推断业务规则。
+
+### V-02 / P1：任务交接交付状态，缺少直接指导开发的内容
+
+代码依据：`src/project-context/task-handoff.mjs:127–144、235–242` 内部编译 Context，却主要返回 item IDs、read target 路径、证据状态、摘要和 gate；没有把已选 Contract 内容或任务依据正文一并交付。`src/project-context/cli.mjs:406–410` 直接呈现意图、状态、gap code 和 nextAction。
+
+Context 本身已经包含语义，问题是 Host 需要另外取得并消费它，再把 handoff 与记录关联起来。`src/project-context/ai-entry.mjs:21–31` 先安排 status / locate / targeted context / 报告元数据，再安排任务选择、handoff 和消费声明；handoff 内部又检查 status、编译 Context。协议可执行，但默认交接路径分散，对 Host 的编排稳定性要求高。
+
+建议：把项目、任务和当前 Context 组成同一可追溯的交接交付，复用现有选择语义。人类首先看到“此次相关规则、依据、下一步、唯一真正需要确认的问题”；详细 ID/摘要/coverage 仍可审计。Host 承担记录与消费编排，开发者以自然语言描述任务；不能要求开发者手写机器工件，也不能用自动声明代替实际阅读。
+
+### V-03 / P1：知识内容区分度不足，下一次任务缺少增量收益
+
+代码依据：`discovery.mjs` 从依赖、脚本、配置、目录和规则文件产生候选，不生成接口字段语义、组件调用关系或业务差异。这是能力边界。长期内容不足时，作用域选择再正确也只能交付通用事实。
+
+历史真实证据：docs/29 第 4–5 节记录两个不同机票 Vue 任务获得近似通用 Bundle，缺少 props/events、调用方、接口与字段映射、业务差异及具体复用/验证入口。它是 1.8.0 的历史观察，不是今天目标仓库的重新测量；目前用户的新反馈与该风险一致，但没有证明每个真实项目均如此。
+
+docs/32 第 5 节已要求真实开发产生简短的“建议纳入长期 Contract”清单。当前入口最后停在 progress 维护，默认完成流程没有明确连接这一步。低价值工程候选易进入初始化，高价值业务知识却继续散落在 Host 调查和会话里。
+
+建议：首批只治理 5–10 条最容易重复解释、误解的稳定规则；完成任务时给出 0–3 条有证据的长期知识候选，说明适用范围和预期复用场景。临时接口调查留在任务证据；跨任务有效的内容才提议进入 Contract，人工批准后生效。无需把全部业务源码注册，也无需写死框架或行业知识。
+
+### V-04 / P2：全局维护会抢占当前任务
+
+代码依据：`project-status.mjs` 调用全局 sync；`assist.mjs:335` 起复核所有活动来源；`task-handoff.mjs:135–137` 在全局 health 不为 clean 时整体 hold。入口第 3 步也要求先处理 attention。无关来源漂移因此可能成为当前任务的前置负担。
+
+已有 `adaptive-context.mjs:438–482` 区分相关来源审计、taskHealth 和 globalHealth，`truth-reconciliation` 也有按任务影响分类。该能力尚未成为日常任务入口的一致体验。
+
+建议：先在交付层明确区分“影响本任务的阻断”和“维护者待处理项”，显示原因和责任人，避免每次任务反复解释全部维护历史。若要改变现行全局阻断语义，必须单独冻结兼容和安全合同；本次没有放宽 fail-closed，不能静默绕过身份、审批、所有权、快照或适用规则冲突。
+
+### V-05 / P2：公开入门与真实交接之间缺少可复制路径
+
+README 的快速开始主要解释初始化和治理原语，新 brief/handoff 出现在能力与命令说明中；正常需求如何形成记录、第一次取得清单、读取后提交声明、继续旧任务，缺少一条紧凑的完整示例。最小任务 JSON 的维护仍依赖 Host 自行正确组装。
+
+建议：一份当前版本的日常工作示例，按“新任务 / 继续 / 只调查”组织，不让新用户浏览历史协议寻找组合方式。进一步实现时考虑纯模板或确定性输入帮助，复用已有校验；不新增 Provider、Agent loop、自动批准或第二长期真源。
+
+### V-06 / P1：验收没有闭合“维护成本换来了什么”
+
+254 项测试证明当前自动化场景通过；它不能证明用户少纠正一次、任务开始更快或换窗口更顺。docs/32 第 7 节已明确要求真实 Host 与真实任务，当前状态保留 CF-14 pending 是正确的。已有 A130 可评估外部结果，但没有运行 Provider，也不能替代这次真实产品体验验收。
+
+产品分享指南第 7 节已有“2–3 个真实任务，对比首轮质量、纠正次数与上下文成本”的方向。应把它变成下一次改进的停止标准，而不是继续扩大内部协议覆盖后再寻找使用理由。
+
+## 5. 可感知的使用目标
+
+下面是目标体验示例，均需要对应项目的实际证据，不是对真实 PC/mobile 项目的事实声明。
+
+| 时点 | 开发者应该得到什么 | 可感知收益 |
+| --- | --- | --- |
+| 打开项目 | 几条已批准的关键规则、哪些领域仍未知、可以直接开始哪些动作 | 知道这个项目的上下文到底能帮什么 |
+| 请求修改 | 当前适用规则与依据，例如状态是否应消费服务字段、已有哪处实现可复用、验证入口是什么 | 少重复解释、少改错业务语义 |
+| 只授权调查/设计 | 继续调查具体文件，仅在业务决定缺失时提一个明确问题 | 不被未来实施证据拖住，也不擅自实现 |
+| 新窗口继续 | 原始需求、已确认决定、完成/剩余项及当前变化 | 不重述需求，不继承旧 ready |
+| 依据变化 | 哪条依据变了、影响哪一步、需读什么或请谁决定 | 提醒与当前工作有关 |
+| 完成任务 | 实际结果、验证边界，以及少量值得长期复用的知识候选 | 下一次任务比这一次更省解释 |
+
+“无感”应该指常规情况下用户不承担协议操作；发生真正的业务歧义、依据变化或审批需求时，产品清楚出现。若一直安静且交付没有任何改善，那是价值未兑现。
+
+## 6. 唯一建议的下一步及收口条件
+
+建议下一步集中完成**一条日常任务交接链路**，复用现有内核，不并行扩展新平台、调度器、hooks 或另一套任务协议：
+
+1. 项目概览显示已批准知识与覆盖缺口，支持自然语言起步。
+2. 新需求/继续任务共用一次一致的交接交付：当前 Context 内容、任务依据、精确阅读清单与下一动作相互绑定；Host 编排细节不占据普通用户输出。
+3. 完成后保留准确进度，并给出有限的稳定知识候选，人工批准后供下次使用。
+
+实施前只需冻结这条链路的字段、兼容方式和以下验收，不再重开整个产品身份。本审查不授权自动改写长期 Contract，也不宣称以上已实现。
+
+| 验收 | 证据与通过条件 |
+| --- | --- |
+| 无任务入口 | 给无历史消费者项目入口；拿到来源可追溯的关键知识和真实覆盖缺口，无伪任务 |
+| 新任务 | 已有真实需求/设计被消费；用户看到具体规则与下一步；只问无法自行调查解决的决定 |
+| 继续任务 | 不凭分支或更新时间猜选；复用实际需求/决定/进度；新消费者重读依据，变化时只提示相应缺口 |
+| 知识增量 | 第一任务发现一条经人工批准的稳定规则；第二个相关任务能命中它并影响实际判断 |
+| 维护成本 | 与相同原始资料、相同 Host 配置下原有工作流比较，记录准备/维护时间、额外调用与阅读量、人工解释/纠正次数及首轮结果 |
+| 安全回归 | 当前 254 项通过；相关规则/身份/快照/所有权冲突仍阻断；无自动批准和业务执行 |
+
+选择 2–3 个真实任务即可形成首轮有用证据，至少包含一个依赖业务约束的修改和一次跨窗口继续。不要为验证而捏造收益：差异不显著、任务本来不需额外规则，或净成本更高时，记录未证明价值。只有实际行为改善且收益覆盖准备与维护成本，才能宣称日常链路有效。
+
+## 7. 本次 Context 与完成记录
+
+本次审查以同一最小任务记录交接，intent=`investigate`；随审查范围补齐后使用 40 个具体目标路径重新编译 Context，命中 28 个 item。代码与 docs 为 scoped；README、package、PROJECT_STATE、input schema 和测试为 project-only，未把它们误称为业务语义完整。消费当前 required，历史 conditional 按本轮当前源码审查范围判断为不适用；未重读 provenance-only。调查阶段交接 `ready-for-read-only`、`gate=proceed`、无 gaps；完成后任务归档为 completed，不保存可复用的 ready。
+
+实际 item IDs：`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 覆盖人工入口、宪法、RTK、PROJECT_STATE、docs/32 和 docs/35、当前公开入门/操作说明、历史真实观察 docs/29、修复文件和上表关键模块；具体目标在任务记录 scope 中，消费工件为本次本地临时证据，不作为长期真源。任务记录为 `.project-context-tasks/handoff-repair-and-product-audit.json`；本报告保留为审查材料，不自动注册或批准为长期规范。
+
+完成核对：自托管 `health=clean`、`contractReadiness=contract-ready`、AI Entry current；`git diff --check` 通过。这些结果证明本地治理与修复收口，不证明真实业务收益。

package/docs/37-EVERYDAY-HANDOFF-FLOW-DESIGN.md

@@ -0,0 +1,271 @@
+# 日常交接链路必要设计
+
+日期：2026-09-30。状态：设计完成，待实施授权；尚未实现、发布或纳入长期 Contract。
+
+依据：产品宪法、已批准的 docs/32 产品方向、docs/35 交接合同、docs/36 全产品审查，以及本轮用户要求“集中打通日常链路，用真实任务验证收益和维护成本，先进行必要设计”。本设计收敛这条链路的可开发范围，不重新定义产品身份。
+
+## 1. 目标与范围
+
+开发者用自然语言提出需求或说“继续”，Host 能从项目入口取得同一份可追溯的任务交付：本次规则、需求依据、已有决定、进度、缺口和下一步。常规协议操作由 Host 完成；用户只处理无法从已授权调查中得到的业务决定。
+
+本轮实施范围固定为三个相连的部分：
+
+1. **打开项目**：知道项目已有哪些可用规则，哪些覆盖尚未声明，可以怎样开始。
+2. **新任务与继续**：一次一致的交接交付包含当前 Context 和任务依据；当前消费者实际阅读后再复查 gate。
+3. **完成任务**：保留准确进度；给出 0–3 条有依据、可跨任务复用的知识建议；长期批准单独处理。
+
+复用现有命令、scope compiler、Context Bundle、任务记录、来源/审批/所有权校验和 Action Plan / preflight。此次不增加任务写入服务、Provider、Agent Runtime、工具拦截、平台适配矩阵、调度器或全量业务扫描。
+
+## 2. 开发者实际看到的流程
+
+```mermaid
+flowchart TD
+  A[从现有 AGENTS 入口进入] --> B{有明确任务吗}
+  B -->|没有| C[项目知识、覆盖提示、自然语言起步]
+  B -->|有| D[Host 选择或建立任务记录]
+  D --> E[交付当前规则、任务依据、进度和阅读清单]
+  E --> F[Host 实际阅读并提交本次消费声明]
+  F --> G{当前动作是否就绪}
+  G -->|缺证据| H[Host 调查或指出具体缺口]
+  G -->|缺决定| I[向用户提出必要的问题]
+  G -->|就绪| J[Host 核对用户授权并继续当前任务]
+  H -->|有新事实| E
+  I -->|得到决定| E
+  J --> K[结果与验证边界、准确进度]
+  K --> L[少量长期知识建议，批准后复用]
+```
+
+图中的“继续任务”由已有 Host 执行，CLI 只交付上下文和状态。没有新事实时不重跑缺口调查；不把门禁通过当作授权。
+
+| 场景 | 用户可见交付 | Host 内部动作 |
+| --- | --- | --- |
+| 没有需求 | 关键已批准知识、覆盖提示、可直接描述需求的起步方式 | 读取工作视图，消费项目范围依据；不创建任务 |
+| 新需求、路径已知 | 目标、适用规则与依据、下一步或关键问题 | 保存用户原话，形成最小记录，交接→阅读→复查 |
+| 新需求、路径未知 | 当前已知规则；下一步会定位什么 | 先取得 locate Context，限定在 targetRoot 调查，再以完整最小文件集合重新交接 |
+| 继续 | 任务标题、原始目标、已完成/剩余项、当前变化 | 明确选择记录，读取当前依据；不继承旧 ready |
+| 仅调查或设计 | 调查/设计结论及剩余问题 | 使用当前 intent；不要求未来实施证据，不升级成实现 |
+| 完成 | 实际结果、验证边界；有价值时附少量知识建议 | 更新 progress/lifecycle；人工批准前不改长期 Contract |
+
+示例仅表达目标体验，内容必须来自实际证据：
+
+> 这次修改采用项目已批准的状态字段规则，并参考现有相邻实现。当前设计和目标文件已核对，接下来按你的授权修改并检查该交互。还有一个缺失的默认行为需要你决定：……
+
+找不到设计或相邻实现时必须说“尚未找到”，不能补造上面的叙述。
+
+## 3. 一个工作视图，保留旧接口
+
+沿用两个只读命令，新增显式选项 `--view work`：
+
+```text
+project-context project-brief --project PATH --view work [--json]
+project-context task-handoff --project PATH --input FILE_OR_DASH --view work [--json]
+```
+
+未传 `--view` 的调用保持现有输出合同和退出含义。新 AI Entry 使用工作视图；已有消费者继续使用 legacy。未知 view 返回明确参数错误，不能静默忽略。选项不增加任何写入权限。
+
+工作视图的 JSON 保留核验信息及完整交付；人类输出展示任务相关内容。它们共用同一结果对象，不能一边 blocked、一边说可以开工。
+
+### 3.1 project-brief 工作输出：schema 2
+
+当前源码有 schema 1 返回值，但尚无独立 `project-brief.schema.json`。实施时新增公开 schema，明确 legacy=1 / work=2；补上 legacy 字段校验，不能追溯性改变旧输出。
+
+保留既有 project/package/connection/projectHealth/contractReadiness/tasks/taskStatus/nextAction/authorityGranted 字段，增加：
+
+| 字段 | 确定语义 |
+| --- | --- |
+| `context` | 可安全编译时的完整 project-scope Context Bundle schema 1；不可安全交付时 null |
+| `overview.items` | 从该项目的 approved item 中生成最多 5 条展示卡片，含 id/kind/subject/statement/value/scope/sourceIds；这是预览，不是完整任务规则 |
+| `overview.scopeSummary` | approved item 的 project/path-prefix/file 数量及声明的路径范围；只能说明已声明覆盖，不能推断已理解某业务域 |
+| `overview.limitations` | Context 与 coverage 中的实际提示；无覆盖声明时明确说未声明；不凭目录名创造业务缺口 |
+| `tasks[].progressSummary` | 已保存的 completed/remaining/nextAction 与 revision；标明 Host 记录，不冒充实际运行验证 |
+| `presentation` | 下文的确定性人类输出结构 |
+| `delivery` | ready / withheld、reasonCodes、序列化字节数和上限；仅指内容是否交付 |
+
+展示卡片按 policy → validation-description → fact → reference，再按 id 稳定排序。摘要上限只限制人类预览；完整 project-scope 规则仍在 context 中，不能因排序隐藏必需规则。path/file 内容只作带范围标识的知识目录，不能作为当前未知任务的指令。
+
+partial/invalid/身份或所有权冲突时不加载无效合同；attention 时保持 needs-governance，不呈现“规则当前可安全使用”。无任务仍为 taskStatus=none。任务候选只显示真实记录；completed/cancelled 与 active 分开，不能因存在历史文件就要求用户选任务。
+
+### 3.2 task-handoff 工作输出：schema 2
+
+保留现有结果全部字段和状态优先级，增加四个字段，不另建 selector：
+
+| 字段 | 确定语义 |
+| --- | --- |
+| `context` | 本次 `buildContextBundle` 生成的完整 schema 1 对象；其中 bundleDigest 必须等于外层 contextBundleDigest |
+| `taskSnapshot` | 本次规范化执行视图中的 origin、scope、适用 requirement/decision/evidence，以及 progress；不包括不适用的未来阶段正文 |
+| `presentation` | 由已核对数据形成的目标、规则、依据、进度、缺口、问题和下一动作；每条可追溯 |
+| `delivery` | ready / withheld、reasonCodes、字节数与上限；与 gate、taskStatus 分开 |
+
+`taskSnapshot.evidence`：local 只带定位、摘要、身份及当前状态，正文仍按 required 清单阅读；inline/external 携带已声明的可移交正文，外部仍标 host-asserted。源码实现事实与来源语义不得混成一类；progress 是 Host 记录，已实现输出的摘要核验仍沿用现行规则。
+
+项目不可用或治理阻断时 `context=null`，保留可安全读取的任务信息和明确原因，不伪造 Bundle。completed/cancelled 的交付展示历史与待核查进度，gate=not-applicable，不能自动恢复执行。
+
+任务 records/input 继续 schema 1。消费声明继续绑定 taskId、requirementsDigest、contextBundleDigest、consumerRunId 和实际阅读摘要；taskSnapshot/overview/presentation 本身不产生消费证明。提供 Context 内容消除了另取同一 Bundle 的编排，但没有免除 required 阅读。
+
+### 3.3 内容大小与摘要
+
+工作 JSON 采用确定性序列化，整个工作输出上限 **1 MiB**；输入 512 KiB、记录 256 KiB、任务枚举最多 100 条沿用现有上限。输出字节数按实际 stdout 的 UTF-8 计量；若 bytes 字段影响长度，按已有稳定计算方式收敛，测试须校验实际值。
+
+超限以小于上限的精简 withholding 结果返回 `work-view-budget-exceeded` 与收窄具体目标/任务证据的动作，不能先输出超限正文。精简结果不携带省略的 Context 或规则正文，并明确标记缺失的交付；不得截断必需规则后输出 ready。工作内容 withheld 时 gate=hold，活动任务为 needs-evidence。规则集合本身过大、收窄仍无效时明确报告，停在原缺口，不无限切任务重试。没有任务的概览仍为 none，退出码 1 表示交付不完整；任务枚举交付超限时要求明确 taskId，以精确 handoff 读取，不静默选取部分候选。
+
+不添加第二份语义摘要。contextBundleDigest/requirementsDigest 沿用现行算法；新增展示不进入它们。recordDigest 仍对应原始记录；progress 更新不使未变需求失效。工作视图不缓存或持久化 ready。
+
+## 4. 人类输出与 Host 输出职责
+
+`presentation` 固定为以下结构：
+
+- `headline`：当前项目/任务及当前动作，明确是否仅调查/设计。
+- `constraints[]`：来自 approved Context 的规则，绑定 itemIds；预览未展开时保留“还有 N 条，请消费完整 Context”提示。
+- `basis[]`：任务需求/决定/证据，绑定 requirementIds/decisionIds/evidenceIds 或 path/digest。
+- `progress`：已完成与剩余，注明记录身份。
+- `issues[]`：code、受影响对象、中文 explanation、actor、nextStep；未映射的 code 保留原码并显示对象，不隐藏错误。
+- `questions[]`：仅当前需要人决定的问题，保留 decisionId；完整未来未决点仍可在旧 questions 审计字段中查看。
+- `nextStep`：明确动作、执行者与 gate 限制。
+
+CLI 只使用确定性模板和已有内容，不能通过模型补写业务含义。Host 可把这些内容组织成自然语言，但业务判断必须追溯到实际 Context 或短期证据。缺口示例：
+
+| 原因 | 人类解释与处理者 |
+| --- | --- |
+| required-not-read | “还需读取 X 后核对”；Host 读取，通常不问用户 |
+| evidence-missing/changed | “依据 X 缺失/摘要变化，影响 Y”；Host 先调查；只有语义决定变化才请人确认 |
+| decision-open | 使用任务中的真实问题；用户/对应业务负责人决定，不猜负责人姓名 |
+| consumption-task-mismatch / requirements-not-consumed | “声明不属于当前任务/当前依据”；Host 重新消费，不要求用户重述未变需求 |
+| read-target-needs-file-scope | “请把 X 目录收窄成实际文件”；Host 有限定位 |
+| project-needs-governance | “项目来源/审批/入口存在问题”；展示实际维护项及责任，保持既有 hold |
+
+人类摘要最多展示 5 条规则、3 条当前依据摘要；完整数据始终保留在 JSON。省略必须明确标识。多个阻断决定先处理能推进工作的最关键一组，其他未决项可见；不得反复询问已有有效确认。ID、digest、coverage 用于审计，不要求普通用户理解协议枚举。
+
+## 5. AI Entry 与阅读流程
+
+实施时 AI Entry renderer 从 6 升到 **7**，同一 marker 区显式更新，保护周边人工内容。新启动路由如下：
+
+1. 使用已安装本地 CLI；无明确任务或需要消除任务选择歧义时，调用 project-brief 工作视图。它已包含 status，不先重复调用 status/context。
+2. 有明确记录及目标时，直接 task-handoff 工作视图；内部完成项目状态与 Context 检查。没有记录的新需求由 Host 按 schema 1 模板组装，用户原话足以支撑的简单修改不强制新建设计文件。
+3. 未知路径时，scope 暂空，以 handoff 的 locate Context 消费项目范围规则，再在 targetRoot 内有限定位；不得把目录作为已阅读文件。定位后用完整最小路径集合更新记录并交接。
+4. 按工作结果阅读 required、判断 conditional、核对当前 evidence；提交本次消费声明后复查。正常已知路径任务为两次 handoff 调用：取得交付、验证消费；不另取同一份 Context。
+5. gate=proceed 后仍核对用户授权。新增影响路径、关键依据变化或治理变化时，下一批相关修改前重新交接；不每次工具调用都跑完整流程。
+6. 同一消费者可复用仍匹配当前摘要的实际阅读结果，只补读变化/新增部分；新窗口消费者必须重新阅读，不能复制旧消费声明。
+7. 完成或阶段交接时更新准确 progress；真正完成才置 completed。按第 6 节交付少量知识建议。
+
+所有初始化/partial/invalid/attention、审批、所有权和结束前 clean 规则保留。工作视图把重复的入口检查合并到已有命令，不改变治理判定。新 renderer 的明确记录任务路径替代“先 status/context，再 task-handoff”的重复编排。
+
+“继续”只确定路由，不是第四种 intent。用户明确点名 taskId/标题时使用该记录；仅说继续且与一条 active 记录的目标一致时，展示所选标题并按已有授权续接。多条候选、目标不匹配或生命周期已结束时询问一次精确选择，不按时间或分支猜测。不继承旧消费者的已读状态。
+
+当前全局漂移的 hold 语义保持不变。将来是否按相关范围放行属于独立安全设计，本次只让维护原因更清楚，不把它混入日常链路的成功条件。
+
+## 6. 完成后的知识建议：有限、可审批、可再次命中
+
+本轮不新增 knowledge-candidate schema 或专用写入命令。Host 在正常结果之后给出 0–3 条简短建议：稳定陈述、类型与范围、当前依据及摘要、跨任务复用场景、为何当前 Contract 还未覆盖。没有可靠候选就省略这一段，不为完成流程凑数量。
+
+筛选规则：必须有可复核来源；在下一类相关任务中会改变判断；不是本次临时决定、未确认 API 约定或一次性实现细节；已有相同 subject/scope 的内容不重复提议，冲突说明后走 revise。不能从刚修改完的代码自动推断这就是长期业务规范。
+
+开发结果与知识治理分开：拒绝或暂不处理建议不会把已完成的开发任务退回 blocked。用户对本次业务修改的授权不等于批准长期知识。
+
+用户选择处理具体建议后，Host 复用现有 authoring / Action Plan schema 2 / preflight：
+
+1. 来源已注册且当前时，生成 propose-item 或 revise-item 的精确计划和预检；人看到 current/proposed、scope、source、影响与 baseline，再决定长期语义。
+2. 来源未注册时先展示注册所需的精确来源动作。完成授权的注册后重读新 baseline，再生成 item 计划；不假设只读 preflight 会执行前一个 action，不能用一个虚假的成功计划掩盖未注册来源。
+3. 人明确批准精确内容后才复用细粒度写入、approve/reapproval、sync/check/status。建议、计划和 Review 都不自带批准，baseline 变化后重新预检。
+
+长期规则优先引用稳定文档、明确人工决定或合适的细粒度来源；不要把会不断改 progress 的任务记录整体注册成长期开源事实。默认建议只在完成报告中呈现，任务中的可复核证据仍可续接；需要持久 proposal 时按现有显式写入路径和权限处理。
+
+本次最小闭环的真实验收必须包括：第一任务发现一条值得长期保留的内容，人明确批准；第二个相关任务由新消费者从 Contract 命中并据此做出正确判断。只展示一条建议不算知识增量已经兑现。
+
+## 7. 兼容与实施清单
+
+| 对象 | 决定 |
+| --- | --- |
+| task-context-record / handoff-input | schema 1 不变；保留本地五类修复及消费绑定；不迁移现有记录 |
+| task-handoff-result | legacy 仍写 schema 1；`--view work` 写 schema 2，嵌套 Context 仍为 schema 1 |
+| project-brief | 保留 legacy schema 1，新增明确的公开 work schema 2 与运行时校验 |
+| capabilities | 升至 schema 11；声明两个命令的 legacy/work 支持与输出版本，新入口只使用已声明工作能力 |
+| AI Entry | renderer 7；旧 6 可读但按已有规则标 stale，必须显式受管重发，不静默改写入口 |
+| Contract、source/projection lock、scope、Action Plan/Review、Exchange Protocol | 本轮不改语义或版本；Exchange Protocol 保持 9；capabilities 与入口变化按现有升级框架处理 |
+| 旧 runtime | 不认识 `--view work` 时明确提示升级或使用原有手动 Context 流程；不能把 legacy 当作满足新体验验收 |
+| 包版本/发布 | 本设计不升版本，不宣称 1.10.1 已存在；实施及发布分别取得明确授权 |
+
+capabilities schema 11 的 `schemas.taskHandoffResult` 保持默认 legacy 的 1，新增 `schemas.projectBrief=1`；新 `views` 字段明确两个命令各自 `default=legacy`、`legacy.schemaVersion=1`、`work.schemaVersion=2`。不得只把现有默认版本改成 2，让旧客户端误判默认输出。新公开输出 schema 的读合同支持 1/2，writer 按 view 分支；其余版本数字保持现值。
+
+必要修改位置：`task-handoff.mjs`（项目概览与工作交付）、`task-handoff-schema.mjs`（输出校验）、`cli.mjs`（view 参数与人类呈现）、`ai-entry.mjs`（路由与有限知识建议）、`capabilities.mjs` / `exchange-schema.mjs` / 对应公开 schema、升级 manifest、README 与包内日常使用示例、交接/CLI/升级测试。已有 Context compiler 原则上不改选择算法，新增纯输出 renderer 可独立成小模块，避免继续把展示堆入交接判定。
+
+实施顺序固定：工作 JSON 与绑定 → 人类输出和新入口 → 日常示例及知识建议流程 → 本地兼容与安全验收 → 获授权后真实任务观察。不得在本地 L 通过时宣称真实收益已通过。
+
+## 8. 本地验收合同
+
+保留当前 254 项，追加有行为差异的验收，不按字段数量凑测试：
+
+| ID | 通过条件 |
+| --- | --- |
+| WF-01 | 无任务工作概览展示 approved 知识和真实覆盖声明；不创造任务/业务理解；候选标题与生命周期准确 |
+| WF-02 | 工作交接内嵌 Context 与外层摘要一致，包含当前适用需求/决定/证据；未来阶段证据不阻断当前设计 |
+| WF-03 | 首次 hold，实际消费后按原 gate 继续；跨任务、关键证据变化及新消费者误用声明仍不能继承 ready |
+| WF-04 | 已知路径不重复编译另一个独立 Context 结果；未知路径经 locate→精确文件集合，路径安全与 planned-output 行为保持 |
+| WF-05 | 新窗口获得需求、有效决定和进度；completed 不自动恢复；progress 更新不重新要求未变业务确认 |
+| WF-06 | 人类输出与 JSON gate 一致；错误说明带对象和恢复动作；required 未读由 Host 处理而不是泛问用户 |
+| WF-07 | 输出超限 withholding，不截断必需内容后就绪；上限、实际 stdout 字节数与有限恢复明确 |
+| WF-08 | legacy 调用保持 schema/退出码；work schema 2 严格校验；新能力、旧入口 stale、受管升级及所有权冲突兼容 |
+| WF-09 | 完成报告的知识建议有 source/scope/reuse，0 条合法；无自动批准；未注册来源分步复核，拒绝建议不阻断已完成任务 |
+| WF-10 | 全局治理阻断、身份/审批/作用域/摘要/所有权安全规则保持；不发生 Provider、Git、网络或业务执行 |
+
+WF-09 的自动测试验证机械部分和批准边界；“建议值得复用”、Host 是否实际遵循、自然语言是否有帮助必须由下节真实验收判断。
+
+## 9. 真实任务收益与维护成本验收
+
+### 9.1 只做一轮小规模比较
+
+选择 **2 个真实业务任务加 1 次跨窗口续接**：任务 A 明确依赖一条容易误解的项目规则，任务 B 能复用 A 中经人工批准的知识，续接使用无历史窗口。这是一次首轮验收，不能当作统计意义上的普遍效果证明。
+
+由真实项目窗口在其授权范围内执行；本产品窗口只消费提供的输出证据。选题、原始需求、代码/资料快照、Host/模型配置、验收规则和消费入口在执行前记录。不自动操作真实仓库，不用合成例子、安装成功或测试数冒充真实 Host 验收。
+
+比较两种流程：原有人工 AGENTS + 同样原始需求/设计/源码资料；加入本设计工作链路。固定资料与评价规则；Project Context 可以改变组织和及时交付，但不能靠独占额外业务答案赢得比较。A 产生的可复用知识，基线 B 也获得同等原始信息。
+
+可安全重复的任务采用同一基线的独立工作副本和无历史消费者，避免第一次执行学到答案再用于第二次；工作副本和窗口由人/现有 Host 在已授权条件下准备，产品不管理 Git 或启动 Agent。不同任务交替比较顺序。无法得到可比较基线时标为观察结果，不通过成本对比验收。
+
+### 9.2 每次记录这些数据
+
+| 数据 | 定义与证据 |
+| --- | --- |
+| 首轮质量 | 用预先固定的业务/边界/复用/验证 rubric 审核首次结果；关键错误逐项记录，不事后调整评分 |
+| 人工解释与纠正 | 完整交付同等原始需求后，重复解释规则/上下文与纠正业务语义的次数；正常需求变更另记 |
+| 开始任务的负担 | Context/交接调用数、额外 required 阅读次数、实际交付 UTF-8 字节数、阅读与记录准备时间 |
+| 一次性准备 | 初始接入与首批规则选择、核对、批准的主动耗时；既有准备成本不可得时明确缺测 |
+| 日常维护 | 来源变化、记录维护、知识复核/审批、解决漂移的主动耗时及涉及人数 |
+| 任务工作量 | 完成同等验收的调查、实施、解释/纠正、验证主动耗时；新增协议工作计入，不能只比较写代码时间 |
+| 续接质量 | 新消费者是否找对任务并重读依据；是否需用户重述原需求/有效决定；到可继续的主动耗时 |
+| 安全与反馈 | 是否漏设计、越权实现、继承旧 ready、伪造业务含义或忽略真实阻断；失败归类为产品/项目数据/Host/环境 |
+
+不采集完整聊天、推理、凭据或源码正文进入产品。指标由外部 Host/人工用既有输出、精简事件记录和文件摘要提供；CLI 不加入计时后台或遥测。主动耗时统一按工作区间记录，双方用相同方法处理非任务中断；工具/模型等待另外记录，不隐藏环境成本。
+
+首轮成本比较采用固定的 2 个任务总量：
+
+```text
+基线成本 = 基线准备 + A/B 的任务主动耗时 + 相关维护
+工作链路成本 = 接入/规则准备 + A/B 的任务主动耗时 + 相关维护
+净节省 = 基线成本 - 工作链路成本
+```
+
+任务耗时已包括解释/纠正/验证/上下文处理，不再重复相加。续接成本单独对比并展示；收益估算不能替代实测。如果一次性准备未收回，可以附保本任务数估计，但不能把预计未来复用算成当前已通过。
+
+### 9.3 明确通过与停止标准
+
+真实验收通过需同时满足：
+
+1. A/B 均无新增关键业务或授权错误，首次结果质量不低于同资料基线。
+2. 至少一个业务任务人工重复解释/纠正减少，或在同质量下任务主动耗时减少；指出具体哪条规则或依据影响了判断。
+3. A 的一条知识经人批准，B 的新消费者实际命中并正确使用；只有 item ID 出现不算消费有效。
+4. 新窗口无需重述未变需求/决定即可续接，实际重读当前依据；未复用旧 ready。
+5. 初始准备、任务与维护数据完整，固定首轮总量的净节省为正。缺测、基线不公平或净成本更高时不宣称价值已通过。
+
+同一轮只允许一次有新证据的产品缺陷修复和对应复查；无复现时分类记录，不能再加 hooks/Runtime 或开无限设计循环。关键安全错误立即停止相关实施。收益未证明时把结果记为未通过/证据不足，集中处理最大的一个原因；不得扩大样本数量直到出现好看的结论。
+
+本轮仅设计这些验收；未启动真实任务或其他 Agent，既有 CF-14 仍未通过。后续实际使用证据可以同时满足原有交接验收，但必须逐项映射，不能替换要求。
+
+## 10. 本轮设计收口与下一步
+
+已明确：用户流程、两命令的工作视图、完整内容与摘要绑定、阅读及继续规则、有限知识建议、兼容版本、本地验收和真实成本判定。没有需要重新选择产品身份的开放问题。
+
+本轮只新增本文和设计任务记录，补充 PROJECT_STATE 的设计阶段事实；保留上一轮未提交修复。未改业务实现、公共 schema、包版本、受管入口或长期 Contract。下一步是取得本设计范围的本地实施授权；真实项目执行和发布按各自范围另行授权。
+
+设计任务 `.project-context-tasks/everyday-handoff-flow-design.json`；intent=design，交接在实际消费后为 ready-for-read-only / proceed，无 gaps。docs 和 src 命中 scoped，schema/PROJECT_STATE 为 project-only；不宣称全项目业务覆盖。required 为人工入口、宪法、RTK、当前状态、docs/32/35/36、交接/Context/CLI/交换相关实现及对应 schema；历史 conditional 本次不扩展其能力，判断为不适用；未重读 provenance-only。
+
+本轮命中 28 个实际 item IDs：`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`。历史发布/授权声明按其已记录范围理解，本轮以当前用户的设计请求为准。

package/docs/38-EVERYDAY-HANDOFF-OPERATION.md

@@ -0,0 +1,147 @@
+# 日常使用：从一个需求到下一次继续
+
+`1.10.0` 的日常链路使用显式工作视图。实现依据是 [日常链路设计](./37-EVERYDAY-HANDOFF-FLOW-DESIGN.md)，产品问题见 [价值与可用性审查](./36-PRODUCT-VALUE-AND-USABILITY-REVIEW.md)。本例说明 Host 在已授权的目标项目内如何使用；不是让本工具自动修改业务代码，也不改变唯一初始化流程。
+
+## 先看已有知识
+
+没有任务时，只运行：
+
+```bash
+npm exec --offline -- project-context project-brief --project . --view work --json
+```
+
+Host 消费 `overview.items` 的知识内容和适用范围、`overview.scopeSummary` 的注册声明、项目范围 `context`、活动任务及 `progressSummary`。给用户简短说明已有规则、哪里只有项目规则、有哪些尚未完成的任务。概览不代表某个业务域已经理解，也不自动挑选最新任务。多个任务可能对应“继续”时，核对一次具体标题和 taskId。
+
+不加 `--view` 或使用 `--view legacy` 保持旧 schema 1。新工作视图 schema 2 是显式选择；可先从 `capabilities --project . --json` 核对 `views`。
+
+## 用一个具体需求开始
+
+示例原话：“把 src/app.ts 的默认版本从 V1 改为 V2，其他行为保持。”假设 Host 已在 targetRoot 内核对该路径，项目已接入且为 clean。这类明确的简单修改可直接引用用户原话；不能为了流程补造设计或决定。复杂业务仍须读取已有设计和关键决定。
+
+Host 组装 `.project-context-tasks/default-version.json`，核对真实项目 ID 后按 task-context-record schema 1 保存。下面两个摘要须实际计算，不能原样使用占位符：inline evidence 为 `digestJson(用户原话)`，文件为其原始字节 SHA-256。可用包内 `canonical-json.mjs` 的 `digestJson`；此处原话是字符串，标准 `JSON.stringify(text)` 的 SHA-256 等价。
+
+```json
+{
+  "schemaVersion": 1,
+  "kind": "task-context-record",
+  "projectId": "实际项目ID",
+  "taskId": "default-version",
+  "title": "调整默认版本",
+  "revision": 1,
+  "previousDigest": null,
+  "origin": { "text": "把 src/app.ts 的默认版本从 V1 改为 V2，其他行为保持。" },
+  "lifecycle": "active",
+  "scope": {
+    "readPaths": ["src/app.ts"],
+    "writeTargets": [{ "path": "src/app.ts", "operation": "modify" }]
+  },
+  "requirements": [{
+    "id": "default-version", "text": "默认版本改为 V2，其他行为保持",
+    "source": "current-user-request", "appliesTo": ["implement"],
+    "blocking": true, "evidenceIds": ["user-request"]
+  }],
+  "evidence": [{
+    "id": "user-request", "purpose": "requirement", "kind": "inline",
+    "text": "把 src/app.ts 的默认版本从 V1 改为 V2，其他行为保持。",
+    "digest": "替换为 digestJson(text)", "identity": "user-statement"
+  }],
+  "decisions": [],
+  "progress": {
+    "completed": [], "remaining": ["修改并验证默认版本"],
+    "implementation": [], "nextAction": "读取当前代码和项目规则"
+  }
+}
+```
+
+记录是 Host 的任务材料；CLI 不自动生成或写回。任务变更递增 revision，previousDigest 绑定上一份完整记录的 `digestJson`。需求依据或范围变化后重新交接；仅记录正常进展不要求用户重复确认。
+
+## 同一份交接，读完后继续
+
+第一次输入以下 schema 1 对象，通过 stdin 传入，无需在项目内留下输入文件：
+
+```json
+{
+  "schemaVersion": 1,
+  "kind": "task-handoff-input",
+  "recordPath": ".project-context-tasks/default-version.json",
+  "intent": "implement",
+  "consumerRunId": "本次消费者唯一标识"
+}
+```
+
+```bash
+npm exec --offline -- project-context task-handoff --project . --input - --view work --json
+```
+
+输出的 `context` 是完整原 Context Bundle，不另运行独立 `status/context` 来获取同一份内容。`context.bundleDigest` 与外层 `contextBundleDigest` 一致。`taskSnapshot` 提供当前意图的需求、决定、证据和进度；外部文字仍是 host-asserted，local 证据仍需实际读取。`presentation` 是短预览，不能替代完整内容。
+
+首次缺少消费声明会 hold，这是 Host 的阅读工作。Host 实际读取所有 `requiredTargets`；按当前需求判断每个 `conditionalTargets`，适用则读取，不适用则写具体理由；provenance-only 不重读。核对本意图证据后，向同一输入追加：
+
+```json
+{
+  "consumption": {
+    "contextBundleDigest": "复制当前输出摘要",
+    "taskId": "default-version",
+    "requirementsDigest": "复制当前需求摘要",
+    "consumerRunId": "与输入一致的本次消费者标识",
+    "readTargets": [{ "path": "实际 required 路径", "digest": "实际读取原始字节摘要" }],
+    "evidenceIds": ["user-request"],
+    "conditional": [{
+      "path": "实际 conditional 路径", "decision": "not-applicable",
+      "reason": "针对本需求的具体不适用理由"
+    }]
+  }
+}
+```
+
+以上是追加字段示意，必须覆盖全部实际清单。适用 conditional 使用 `decision=read`，附当前文件 digest 和阅读理由。第二次交接按原门禁复查。`gate=proceed` 后 Host 核对用户的实施授权再修改和验证；只授权设计就保持 design，不推断实施授权。
+
+目标未知时先用空目标获取 locate Context，只在 targetRoot 内有限定位，再将完整最小文件集合写回 scope 重新交接。目录不能冒充已读文件。新建目标无需读取尚不存在的文件；输出完成后记录其 operation/status/digest，续接会检查实际产物。
+
+## 换窗口、完成与积累
+
+换窗口读取该记录，从工作交接获得用户需求、有效决定、已完成和剩余工作。新消费者使用新的 consumerRunId，实际读取当前依据，提交自己的声明；不能继承上一窗口 ready。同一消费者只可复用当前摘要仍匹配的读取。completed/cancelled 仅作历史，不自动重新实施。
+
+完成后 Host 记录实际修改、验证结果、产物摘要和下一步，将 lifecycle 置为 completed。恢复项目治理 clean；仍有阻断项时准确说明。普通结果报告可给出 0–3 条可靠知识建议，每条包括：稳定事实、类型、适用范围、具体来源及摘要、复用场景和当前 Contract 缺口。没有可靠候选就省略，不凑数。
+
+例如某次真实任务确认了“某页面的默认版本必须由服务字段提供”，建议应链接实际设计/服务契约和页面范围，说明后续同类修改如何复用。这里只展示建议格式，不声称本项目已经确认该业务事实。
+
+用户拒绝建议不阻断任务完成。用户选择具体候选后，复用已有 authoring / ActionPlan / preflight：未注册来源先单独注册，再根据最新基线准备 item plan；批准仍需精确 item 内容、ID 和摘要，不把选择等同长期批准，不自动写入 Contract。
+
+## 缺口如何处理
+
+| 输出 | 当前动作 |
+|---|---|
+| required 未读或摘要已变 | Host 读取对应文件并重新声明，不泛问用户 |
+| 业务决定未确认 | 展示原问题和具体选项，等待明确决定 |
+| 全局治理 attention / 身份不符 | 处理 sync 维护项或准确身份，保持阻断 |
+| `delivery=withheld` | 完整内容未交付，不开工；有限收窄目标/证据，无新事实不重试 |
+| 工作 JSON 超过 1 MiB | 返回小型 withholding 结果；不截断规则后宣布 ready |
+| 概览超过 100 个任务 | 指定准确 taskId；不猜选最新任务 |
+
+`delivery.bytes` 对应完整 pretty JSON 的 UTF-8 stdout 字节数（包含末尾换行），不是短人类呈现的字节数。终端不加 `--json` 会显示简短中文说明；自动消费必须读取 JSON。record/input 上限仍为 256/512 KiB。
+
+## 用真实任务决定是否值得保留
+
+本地 WF-01–WF-10 验证交付、兼容和安全行为，不证明用户收益。按设计用两个真实业务任务，加一次无历史窗口续接，记录以下事实；不在本窗口自动操作真实项目或启动 Agent。
+
+| 记录项 | 无工作视图基线 | 工作视图 | 证据 |
+|---|---:|---:|---|
+| 准备/录入上下文时间 | 待实测 | 待实测 | 原始文档、任务与 Host 配置保持一致 |
+| 读取与定位时间、读取范围 | 待实测 | 待实测 | 当前命中 IDs、paths、实际读取记录 |
+| 用户澄清次数、续接恢复时间 | 待实测 | 待实测 | 区分新业务决定与重复询问 |
+| 需求遗漏、规则违反、返工 | 待实测 | 待实测 | 同一验收清单 |
+| 来源维护、候选审查成本 | 待实测 | 待实测 | 包括 source review/reapprove 和拒绝候选时间 |
+| 总时间与净收益 | 待实测 | 待实测 | 节省时间扣除准备、维护和返工成本 |
+
+两条任务都按真实结果判断是否继续。治理 clean、测试通过、安装成功都不能替代这个结论；如收益不覆盖维护成本，收窄需要治理的知识和记录，按设计停止扩展。
+
+## 本次本地实施证据
+
+`2026-09-30`：264 项检查通过、0 失败，包括十个新增行为用例覆盖 WF-01–WF-10。自托管来源通过 review-source → accept → 精确 revise/reapprove 更新，受管入口显式发布为 renderer 7；check 无 findings，status 为 clean / contract-ready。包版本仍为 1.10.0，本轮没有发布、真实项目操作或独立 Agent 验收。
+
+实施记录见 `.project-context-tasks/everyday-handoff-flow-implementation.json`。最终 targeted Context 命中 29 个 item；34 个目标中 15 个 scoped、19 个 project-only，只有 `project-scope-only` 覆盖提示，不宣称业务语义完整。required 36 个，包含当前目标文件、人工入口、宪法和 docs/35；conditional 中实际消费 docs/11、16、17、32 与 package.json，其余历史设计未扩展相关能力，判断不适用，provenance-only 不重读。消费声明按本次消费者绑定任务、需求和 Context 摘要，不复用上一设计任务的 ready。
+
+实际命中 IDs：`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`、`startup.summary`、`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`。
+
+本任务没有新增业务知识候选。日常入口及修复状态已通过现有来源维护记录，不再为同一事实创建重复条目。真实任务的知识建议是否有复用价值，留给上节实际验收。