frontend-project-context 1.8.0 → 1.10.0

package/CHANGELOG.md

@@ -1,6 +1,34 @@
 # Changelog
 
-## 1.8.0 - Unreleased
+## 1.10.0 - 2026-10-02
+
+- Add read-only `project-brief` and `task-handoff` commands, schema-1 task records, current-consumer evidence checks, and instructional context gates. No Agent Runtime, hooks, or business-code writer is added.
+- Add opt-in `--view work` schema 2 to both commands, delivering the complete compiled Context, current task evidence, progress, and concise human output in one handoff. Omitted/legacy views retain schema 1 and their exit behavior.
+- Advance capabilities schema to 11 and AI Entry renderer to 7. Existing Contract, Context Bundle, Coverage Audit, Exchange Protocol, task record and input formats remain readable; owned AI Entry updates remain explicit.
+- Repair two bounded handoff errors: incomplete governance now routes to onboarding, and a missing task record returns a specific error instead of an internal error.
+- Bind consumption to the current task and requirement evidence; reject implementation without an applicable requirement, ignore future-intent-only evidence, normalize path identities, and require finite directory-to-file narrowing.
+- Withhold oversized work output above 1 MiB without truncating required rules into readiness; expose progress and optional knowledge suggestions without automatic Contract adoption.
+- Repair upgrade assessments that incorrectly required file locks for human-decision and external-reference sources; local missing-lock checks remain blocking.
+- Pass 265 local checks, including WF-01–WF-10 and all earlier handoff regressions. Real-project Agent compliance, net task benefit, and maintenance cost remain pending and are not claimed by this release.
+
+## 1.9.1 - 2026-09-23
+
+- Repair Context Bundle read-target identity so task targets and local Contract sources merge by normalized path without duplicate output.
+- Preserve complete, stable unions of item IDs, source IDs, reasons, and every JSON Pointer, including the RFC 6901 root pointer.
+- Share one strict coverage profile parser and selector between Context Bundle and Coverage Audit; invalid v1/v2 profiles now fail closed consistently.
+- Add HC-01 through HC-14 while retaining TC-01 through TC-16 and every prior regression; public schemas, Exchange Protocol 9, and AI Entry renderer 5 remain unchanged.
+- Adopt schema-3 consumption, outside-owned AI Entry digest mode, and bounded coverage v2 in this repository.
+- Pass read-only real-Host revalidation in `dtg-tmc-mobile` and `dtg-tmc-pc` with the same frozen source candidate; both end clean, same-path task/source aggregation stays unique, and undeclared target coverage is reported as a Contract data gap. The release tarball is a separate artifact and does not claim byte identity with that earlier source snapshot.
+
+## 1.9.0 - Unreleased
+
+- Add deterministic `context --locate --task` followed by exact, order-independent multi-path targeted Context.
+- Publish Context Bundle schema 1 with structured items, scope coverage, typed read targets, gaps, authority handoff, compatibility `content`, and a canonical digest.
+- Add Contract schema 3 `consumption` roles and `outside-owned-ai-entry` source digest mode while preserving schema-1/2 read-only bytes.
+- Add coverage profile v2 / Coverage Audit schema 2, Initialization Instruction schema 2, capabilities / Exchange Protocol 9, and AI Entry renderer 5.
+- Add TC-01 through TC-16 without Provider, Agent Runtime, Git, network, dependency installation, business-code execution, or a new persistent store.
+
+## 1.8.0 - 2026-09-15
 
 - Add the package-owned `docs/AI-PROJECT-INITIALIZATION.md` as the only normative Host initialization procedure and expose it through read-only `instructions --json|--prompt` plus capabilities discovery.
 - Resolve and freeze `targetRoot`, forbid parent-project truth discovery and outside symlink evidence, and keep Provider, Agent Runtime, Git, network, package mutation, business-code writes, automatic approval, and publication outside the runtime.

package/README.md

@@ -22,6 +22,8 @@ AI coding tools often read only part of a repository. Important conventions may
 
 It does **not** call an AI provider, edit business code, manage Git, install dependencies automatically, or approve rules on its own.
 
+Version `1.10.0` adds the local L phase of the approved [context-first handoff](./docs/35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md): a project brief, a minimal task record, a read-only handoff result, and instructional context gates. Real-project Agent acceptance remains pending; this release does not claim that a Host will always follow the gates.
+
 ### Requirements
 
 - Node.js 18 or newer
@@ -32,12 +34,12 @@ It does **not** call an AI provider, edit business code, manage Git, install dep
 Pin it as a development dependency so local users and CI run the same version:
 
 ```bash
-npm install --save-dev frontend-project-context@1.8.0
+npm install --save-dev --save-exact frontend-project-context@1.10.0
 ```
 
 The package has zero runtime dependencies.
 
-`1.8.0` is the Real Project Onboarding Closure release. It adds one package-owned Host initialization instruction, capabilities schema / Exchange Protocol 8, project-status schema 2 with independent Contract readiness, and AI Entry renderer 4. Local O-01 through O-12, the complete regression suite, and an isolated real-project memoryless Host acceptance form its release gate.
+`1.10.0` retains the `1.9.1` Context integrity repairs and adds `project-brief` and `task-handoff`, including opt-in work views. Capabilities schema advances to 11 and AI Entry renderer to 7; Context Bundle schema 1, Coverage Audit schema 2, Contract schema 3, and Exchange Protocol 9 remain readable. Install the exact version before updating an existing project's owned AI Entry.
 
 ### Quick start
 
@@ -58,7 +60,7 @@ All `npm exec --offline -- project-context` commands below require the exact dev
 npm exec --offline -- project-context publish-entry --project . --output AGENTS.md --write --json
 ```
 
-The `1.8.0` AI Entry renderer 4 requires every clean-state real task to compile task/path context and consume actual Contract item IDs, scopes, and read targets before source development. Existing renderer-1/2/3 entries remain readable but become stale and require an explicit owned republish; no entry is rewritten automatically.
+The current local source uses AI Entry renderer 7: it routes through opt-in work views, delivering the same full Context alongside current task evidence and progress; unknown paths still require locate-then-targeted consumption. Existing renderer-1/2/3/4/5/6 entries remain readable but stale until an explicit owned republish.
 
 Use `remove-entry` with the same output to remove only a trusted managed region. Plans and previews never include `--write`; human approval of the exact path remains required.
 
@@ -211,7 +213,7 @@ npm exec --offline -- project-context upgrade-apply --project . --plan .project-
 
 `upgrade-check` and `upgrade-plan` are permanently read-only. `upgrade-apply` previews by default and can write only the single compiled, product-owned unit shown in that exact plan. Re-run check and plan after every unit. Even `coreMigration: complete` still requires the Host to verify dependency/lockfile pins, project tests or CI, and an independent new window. The product does not run a package manager, Git, network, project tests, business writes, automatic approval, rollback, or publication.
 
-The package publishes twenty machine schemas, including capabilities 7, project status, projection lock 1/2, Migration Manifest 2, Upgrade Assessment/Migration Plan/Upgrade Result Bundle 1, Evidence Input/Bundle, Assist/Action/Review bundles, the four staged-context schemas, Context Query/Adaptive Context Bundle/Routing Index 2, and Coverage Audit 1.
+The package publishes twenty machine schemas, including capabilities 9, project status, projection lock 1/2, Migration Manifest 2, Upgrade Assessment/Migration Plan/Upgrade Result Bundle 1, Evidence Input/Bundle, Assist/Action/Review bundles, the four staged-context schemas, Context Query/Adaptive Context Bundle/Routing Index 2, and Coverage Audit 2.
 
 Generate the read-only governance dashboard:
 
@@ -265,6 +267,8 @@ All commands are read-only unless that command explicitly includes `--write`. So
 | `propose` | Author a fact, policy, reference, or validation description |
 | `approve` | Explicitly approve selected proposal IDs |
 | `context` | Compile approved context for one or more paths |
+| `project-brief` | Read project health and discover bounded local task records without selecting one |
+| `task-handoff` | Compile current task evidence, read targets, gaps, and an instructional gate |
 | `context-query` | Compile adaptive review JSON or its compact model-facing `--prompt` projection with complete-context fallback |
 | `coverage-audit` | Audit declared registration coverage without claiming all project truth |
 | `index-context` | Preview or explicitly persist a disposable routing index |
@@ -317,6 +321,8 @@ AI 编程工具通常只读取仓库的一部分，而项目约定分散在文
 
 它**不会**调用大模型、修改业务代码、管理 Git、自动安装依赖，也不会替人批准规则。
 
+`1.10.0` 按[上下文优先交接设计](./docs/35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md)提供本地 L 阶段：项目概览、最小任务记录、只读交接结果和指令式上下文门禁。真实项目中的 Agent 遵循情况尚未验收；本版本不宣称 Host 必然遵守门禁。扩展提醒和环境生命周期仍是后续范围。
+
 ### 环境要求
 
 - Node.js 18 或更高版本
@@ -327,12 +333,12 @@ AI 编程工具通常只读取仓库的一部分，而项目约定分散在文
 建议固定为开发依赖，让本地与 CI 使用同一版本：
 
 ```bash
-npm install --save-dev frontend-project-context@1.8.0
+npm install --save-dev --save-exact frontend-project-context@1.10.0
 ```
 
 本包没有运行时第三方依赖。
 
-`1.8.0` 是 Real Project Onboarding Closure 正式版本：新增包内唯一 Host 初始化指令、capabilities schema / Exchange Protocol 8、带独立 Contract readiness 的 project-status schema 2，以及 AI Entry renderer 4。本地 O-01 至 O-12、完整回归与隔离真实项目的无历史 Host 接管共同构成发布门。
+`1.10.0` 保留 `1.9.1` 的 Context 完整性修复，新增 `project-brief`、`task-handoff` 及显式工作视图。Capabilities schema 升至 11、AI Entry renderer 升至 7；Context Bundle schema 1、Coverage Audit schema 2、Contract schema 3 和 Exchange Protocol 9 保持可读。先安装精确版本，再显式更新现有项目受管的 AI Entry。
 
 ### 快速开始
 
@@ -353,7 +359,7 @@ npm exec --offline -- project-context status --project . --json
 npm exec --offline -- project-context publish-entry --project . --output AGENTS.md --write --json
 ```
 
-`1.8.0` 的 AI Entry renderer 4 要求 clean 状态下的真实任务先编译 task/path context，消费实际命中的 Contract item IDs、scope 和 read targets，之后才能进入源码。既有 renderer 1/2/3 入口仍可读取但会标记 stale，只有显式受管 republish 才会升级，不会自动重写。
+当前本地源码使用 AI Entry renderer 7：通过显式 work 视图直接交付项目概览、完整 Context、任务依据和进度；未知路径仍需 locate → 精确文件集合，实际消费与指令式门禁保持。既有 renderer 1/2/3/4/5/6 可读但会标记 stale，只有显式受管 republish 才升级。
 
 使用相同 output 的 `remove-entry` 只移除可信受管区域。计划与 preview 都不含 `--write`，仍需人对精确路径授权。
 
@@ -561,6 +567,8 @@ npm exec --offline -- project-context dashboard --project . > project-context-da
 | `propose` | 创建 fact、policy、reference 或 validation-description |
 | `approve` | 显式批准选中的 proposal ID |
 | `context` | 为一个或多个路径编译已批准上下文 |
+| `project-brief` | 只读展示项目健康与可选的本地任务记录；不自动选任务 |
+| `task-handoff` | 只读编译本次任务证据、待读项和指令式门禁；`--input -` 可从 stdin 接收输入 |
 | `context-query` | 编译自适应审查 JSON，或生成带完整上下文回退的紧凑 `--prompt` 模型投影 |
 | `coverage-audit` | 审计声明范围内的来源登记覆盖，不宣称发现全部项目真源 |
 | `index-context` | 预览或显式保存可删除的派生路由索引 |
@@ -602,3 +610,14 @@ npm exec --offline -- project-context dashboard --project . > project-context-da
 Apache License 2.0 · `Copyright 2026 Fushan`
 
 See [LICENSE](./LICENSE) and [NOTICE](./NOTICE).
+
+## 日常交接工作视图
+
+[日常使用示例](./docs/38-EVERYDAY-HANDOFF-OPERATION.md) 将项目概览、任务交接、继续和完成后的知识建议连成同一条路径。明确添加 `--view work` 会输出 schema 2；不加参数或 `--view legacy` 保持 schema 1 与原退出码。工作视图交付同一编译器的完整 Context，实际阅读与当前消费者声明仍是必要步骤；输出超过 1 MiB 时明确 withheld，不以截断内容放行。
+
+```bash
+npm exec --offline -- project-context project-brief --project . --view work --json
+npm exec --offline -- project-context task-handoff --project . --input - --view work --json
+```
+
+真实收益验收包括两个业务任务和一次无历史续接，记录准备、读取、定位、返工和维护时间。安装与本地测试通过不能替代这些实际结果。

package/UPGRADING.md

@@ -1,5 +1,23 @@
 # 升级说明
 
+## `1.9.1 → 1.10.0`
+
+先在目标项目中由其现有 Host 将开发依赖与 lockfile 精确固定为 `frontend-project-context@1.10.0`。新版本增加只读 `project-brief`、`task-handoff` 和 schema 1 任务记录；记录由 Host 在当前用户授权下维护，不自动生成、选择或批准长期 Contract。`task-handoff` 的 `gate=proceed` 仅说明已声明的上下文满足本次意图，不授予业务代码写入权限。
+
+Capabilities schema 升至 11，AI Entry renderer 升至 7；Contract schema 3、Context Bundle schema 1、Coverage Audit schema 2 和 Exchange Protocol 9 保持兼容。原有 store 不自动迁移；已拥有的旧 AI Entry 会显示 stale，需由目标项目 Host 审查后显式 `publish-entry --write`。短生命周期 Context 与消费声明应按当前任务重新生成，不继承旧窗口的 ready。迁移清单将 `1.9.1 → 1.10.0` 分类为 `package-only`，并列出显式 AI Entry republish 单元。
+
+本版本完成本地 L 实现；真实项目 Agent 是否读到关键设计并遵守门禁，仍须在后续真实任务中观察，不因安装或 `clean/contract-ready` 自动视为通过。目标项目更新和验收在其独立窗口执行。
+
+## `1.8.0 / 1.9.0 → 1.9.1`
+
+`1.9.1` 是对未发布 `1.9.0` Context 消费语义的补丁：read target 改为按规范化 path 唯一聚合，同路径多 JSON Pointer 完整保留，Context Bundle 与 Coverage Audit 共用一份严格 coverage profile parser/selector。Context Bundle schema 1、Coverage Audit schema 2、Contract schema 3、capabilities / Exchange Protocol 9 和 AI Entry renderer 5 均不升级。
+
+从已发布 `1.8.0` 或本地 `1.9.0` 进入 `1.9.1` 均是 `package-only`；不会自动迁移目标项目 Contract。两个真实项目曾在同一冻结源码候选上完成只读 Host 复验；目标项目实际安装本包并执行任务仍需各自授权与核验。
+
+## `1.8.0 → 1.9.0`
+
+`1.9.0` 增加 Context Bundle schema 1、`context --locate`、稳定多路径 targeted Context、Contract schema 3 的可选消费职责与受管区域外摘要、Coverage Audit schema 2、Initialization Instruction schema 2、capabilities / Exchange Protocol 9 和 AI Entry renderer 5。Contract schema 1/2 继续只读兼容；只有显式使用 `consumption` 或 `digestMode` 的治理写入才升级为 schema 3。短生命周期 Context/Coverage/Instruction 工件应重新生成，AI Entry 需要显式 republish；不自动改写 store 或人工入口。
+
 ## `1.7.0 → 1.8.0`
 
 `1.8.0` 新增只读 `instructions` 和唯一包内规范 `docs/AI-PROJECT-INITIALIZATION.md`；capabilities / Exchange Protocol 升至 8，新增 initialization-instruction schema 1；project-status 升至 schema 2，以 `contractReadiness` 独立区分 `not-initialized`、`contract-incomplete` 与 `contract-ready`；AI Entry 升至 renderer 4，clean 状态也必须先运行 task/path context 并消费实际 Contract。
@@ -137,3 +155,9 @@ Action Plan 和 Review Bundle 都不是 store、Contract 或 approval receipt。
 5. 来源搬迁或永久退役时，先登记替代来源并修订/重新批准所有当前引用，再 preview `deprecate-source`，最后用 preview 返回的 source object digest 显式写入并重新发布投影。
 
 旧 `1.0.0` RC reader 不支持 Contract schema 2，因此成功废弃来源后不能用旧 reader 继续维护该项目。升级不会自动迁移、接受来源变化、修改 item、批准知识、覆盖非受管文件或执行 Git。
+
+### 1.10.0 日常链路工作视图
+
+显式 `--view work` 为 `project-brief` / `task-handoff` 输出 schema 2，默认 legacy 仍为 1；capabilities schema 11 的 `views` 声明这两个分支。AI Entry renderer 7 直接消费工作视图，renderer 1–6 可读但 stale，只有显式 `publish-entry --write` 才更新。受管区域外的人工内容及其摘要规则保持。Contract、Context Bundle、Exchange Protocol 和 task record/input 均不迁移。
+
+[日常使用示例](./docs/38-EVERYDAY-HANDOFF-OPERATION.md) 说明新消费者读取、超限恢复和完成后的知识候选。安装后核对 capabilities 的 views、包版本和受管入口 renderer；安装成功仍需实际任务验收。

package/docs/00-PRODUCT-CONSTITUTION.md

@@ -1,10 +1,10 @@
 # Frontend Project Context — 产品宪法
 
-> 宪法版本：`1.2.0`
+> 宪法版本：`1.3.0`
 >
 > 状态：`frozen`
 >
-> 生效日期：`2026-09-09`
+> 生效日期：`2026-09-29`
 
 ## 1. 文档权威
 
@@ -23,36 +23,40 @@
 
 ## 2. 唯一产品定义
 
-Frontend Project Context 是一个**落在项目中的、位于项目与 AI 编程工具之间的模型无关双向上下文治理与交换层**。
+Frontend Project Context 是一个**落在项目中的、位于项目、开发人员与 AI 编程工具之间的模型无关上下文治理、交互与交换层**。
 
-它把项目明确提供的事实、规则和来源治理为一份人工批准的 `Project Contract`，再针对目录和任务生成最小、可追溯的 `Context Bundle`，投影给已有 AI 编程工具，并把 AI 返回的建议收敛为可预检、可集中审查的短生命周期 action，最后在人明确批准后复用现有安全写入原语。
+它把项目明确提供的事实、规则和来源治理为一份人工批准的 `Project Contract`，再向开发人员提供可追溯的项目概览、任务证据与就绪交接、相关变化提醒；针对目录和任务生成最小 `Context Bundle`，投影给已有 AI 编程工具，并把 AI 返回的建议收敛为可预检、可集中审查的短生命周期 action，最后在人明确批准后复用现有安全写入原语。Host 负责把这些结果以自然语言与开发人员交流，产品不冒充已理解未提供的项目语义。
 
 ```text
 项目显式来源 + 人工规则
 → 候选项
 → 人工批准的 Project Contract
-→ 按目录/任务编译的 Context Bundle
-→ AGENTS.md / Ruler / 其他 AI 工具
+→ 单一项目入口与开发人员可读的项目概览
+→ 任务证据、就绪交接与按目录/任务编译的 Context Bundle
+→ AGENTS.md / Ruler / 其他 AI 工具与开发人员对话
+→ 阶段、集成、生产证据及相关变化提醒
 → AI Action Plan
 → 确定性预检与人工集中审查
 → 已授权的细粒度写入
 → 来源、合同与投影漂移检查
 ```
 
-本产品治理“项目希望 AI 知道什么”和“AI 建议如何在人工授权前被安全表达与预检”，不负责“AI 如何完成开发任务”。
+本产品治理“项目希望 AI 与开发人员知道什么”“当前任务何时具备已声明的上下文证据”和“AI 建议如何在人工授权前被安全表达与预检”，不负责执行开发任务。项目健康、任务就绪、环境事实和实施权限是不同结论，不能互相替代。
 
 ## 3. 固定用户问题
 
-同一项目的知识分散在设计资料、文档、配置、代码和团队约定中，不同 AI 工具会获得不完整、重复或互相冲突的指导，并且规则变化难以追溯。
+同一项目的知识分散在设计资料、文档、配置、代码和团队约定中，不同 AI 工具会获得不完整、重复或互相冲突的指导，并且规则变化难以追溯。开发人员安装产品后也需要知道项目当前掌握了什么、如何开始或继续任务、关键需求何时过期，以及分支和环境变化对当前工作有什么影响。
 
-本产品提供的稳定价值只有四点：
+本产品提供的稳定价值为：
 
 1. 一份有人批准、保留来源的项目合同；
 2. 针对目录和任务的确定性上下文编译；
 3. 同一合同面向多个 AI 消费者的一致投影和漂移检查。
 4. 项目与不同 AI 编程工具之间一份双向、模型无关、可预检且不扩张人工权限的交换协议。
+5. 从同一项目入口给开发人员可追溯的项目概览、任务就绪交接和必要的澄清问题；
+6. 根据明确的任务、来源与环境证据，在相关时点提醒过期、冲突和待确认事项。
 
-如果某项能力不能直接服务这四点，它默认不属于内核。
+如果某项能力不能直接服务这些价值，它默认不属于内核。
 
 ## 4. 固定内核
 
@@ -65,6 +69,7 @@ Frontend Project Context 是一个**落在项目中的、位于项目与 AI 编
 5. **Projection Boundary**：把同一合同投影为受管 Markdown、AGENTS 或 Ruler 输入，不重建完整工具适配矩阵；
 6. **Conflict and Drift Check**：报告来源、合同和受管投影变化，不自动修复或静默提升规则。
 7. **AI Exchange Boundary**：以公开、带版本的机器合同向外部 AI 输出 Context/Assist Bundle，并把 AI 建议收敛为无权限的 Action Plan 与只读 Review Bundle；所有持久动作仍需人对精确 action、ID 和路径明确批准。
+8. **Developer Interaction & Lifecycle Boundary**：从现有 Contract 与显式任务、来源、环境证据生成项目概览、任务就绪状态、最小跨会话任务记录和相关提醒；通过现有单一入口向 Host 提供当前任务的上下文门禁。Host 遵循门禁和当前用户授权；产品不拦截工具、不执行或批准开发任务。
 
 自动 discovery 只是帮助项目首次接入的可选辅助，不是内核完整性的衡量标准。它可以保守地提出候选，但不承担理解所有前端技术和业务语义的责任。
 
@@ -79,7 +84,9 @@ Frontend Project Context 是一个**落在项目中的、位于项目与 AI 编
 - 自动安装依赖、访问网络或修改外部系统；
 - 重建 Kiro、Spec Kit、OpenSpec、Ruler、Rulesync 或成熟 Coding Agent 的完整能力；
 - 为每个框架、路由、状态库、UI 库、构建器、租户或发布平台维护不断增长的识别白名单；
-- 保存 candidate、DecisionRecord、DeliveryRecord 或形成自动修复循环。
+- 保存完整聊天、模型推理、全量 diff 或形成自动修复循环；最小任务记录只保存交接与提醒所必需的结构化依据，不是第二份长期项目规范；
+- 在没有另行选择的外部调度与通知机制时，声称关闭会话后仍能主动定时提醒；
+- 声称仅凭任务交接结果就能技术上强制阻止任意 Host 的业务代码写入。
 
 Vue、React、uni-app、Vuex、Element UI、路由、租户和发布方式等都是项目内容。内核不认识它们时，项目应通过通用来源与 authoring 能力表达，而不是要求内核新增专用逻辑。
 
@@ -92,10 +99,13 @@ Vue、React、uni-app、Vuex、Element UI、路由、租户和发布方式等都
 5. 临时任务约束不能反向改写长期合同。
 6. 默认只读；持久写入必须由当前命令的显式写入选项触发。
 7. 只能覆盖本产品创建且所有权未发生冲突的受管投影。
-8. 未知项目语义是待录入的项目数据，不自动成为产品缺陷。
+8. 未知项目语义是待录入的项目数据；产品若把关键未知项隐藏在成功状态下、未给出补齐路径或错误宣称任务可实施，则属于产品交接缺陷。
 9. 真实项目只能验证预先定义的能力，不能直接产生内核需求。
 10. 新技术、新文件名或单个项目差异不能成为扩大 discovery 的充分理由。
 11. AI 产生的 Action Plan、Review Bundle、推理或建议都不是 Project Contract、approval 或持久执行权限；必须通过 schema、baseline、impact 和人工精确授权边界。
+12. 项目 `clean`、Contract 可用、Context 生成成功与当前任务可实施是不同状态；任何任务就绪结论必须绑定任务目标、证据、范围、快照和未决问题。
+13. 短期任务记录、需求决定、分支候选和环境快照不能自动改写 Project Contract；“计划上线”“已合并”“已上线”必须由不同的实际证据支持。
+14. 过期和提醒必须指向明确的日期、来源变化、取代关系或环境事件；未知时报告未知，不能虚构期限或重复骚扰无关任务。
 
 ## 7. v1 完成定义
 
@@ -131,6 +141,20 @@ v1 只有在以下闭环同时成立时才算产品完成：
 
 完整实现合同以 [17-AI-EXCHANGE-BOUNDARY-DESIGN.md](./17-AI-EXCHANGE-BOUNDARY-DESIGN.md) 为准。
 
+### 7.3 面向开发人员的交互与生命周期完成条件
+
+本节是 `2026-09-29` 获批的新产品方向完成条件，不改写旧版 v1 和 `1.2.0` 的历史完成事实。新方向只有在以下闭环同时成立时才能声称完成：
+
+1. 接入后的用户即使没有开发需求，也能从单一项目入口获得准确的项目概览、已知缺口和自然语言起步方式；仅安装依赖不得被称为完成接管。
+2. 新任务和已有任务都能从当前需求、设计、代码与工作区证据进入可追溯交接；关键证据或决定缺失时，不得输出可实施状态。
+3. 开发人员能直接用自然语言询问项目当前依据、未决点与下一动作；会影响实施的陈述可追溯到批准的 Contract 或标明身份的短期证据。
+4. 跨窗口任务记录只保留必要结构化依据；需求过期、来源变化与环境事件按相关范围提醒，不自动批准长期规则。
+5. 主分支、集成、预发、生产与回滚的结论使用真实外部证据，严格区分候选、已合并和实际运行；产品不执行 Git、CI 或发布。
+6. 入口和交接结果明确当前意图、证据缺口、停止与继续条件；通过独立真实 Agent 的实际消费验证其遵循情况，不承诺全通道技术强制。
+7. 独立真实 Host 在曾失败的移动端任务上证明：缺失设计时停在缺口处理，依据补齐后能继续开发；内部测试、`clean` 或只读 Context 查询均不得替代该验收。
+
+产品方向见 [32-PROJECT-TO-TASK-INTERACTION-PROPOSAL.md](./32-PROJECT-TO-TASK-INTERACTION-PROPOSAL.md)；当前上下文交接实现和验收顺序见 [35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md](./35-CONTEXT-FIRST-TASK-HANDOFF-DESIGN.md)。
+
 ## 8. 真实项目与实验规则
 
 `dtg-tmc-mobile` 和 `dtg-tmc-pc` 已经完成 B0。它们证明核心机制和首轮安全修补可以落在真实仓库结构中。
@@ -144,6 +168,8 @@ v1 只有在以下闭环同时成立时才算产品完成：
 - 只有先写出固定、可证伪的产品假设，真实项目才可以再次用于验证该假设；
 - 验证失败先判断是内核不变量失败、项目数据缺失还是适配器问题，后两者不得进入内核修补循环。
 
+真实项目的数据缺失本身不要求内核理解业务；产品漏报显式缺口、错误输出任务就绪或生成不可消费的交接时，按第 7.3 节判断产品交接失败。Host 已收到正确门禁却未遵循时单列 Host 行为，不因此强制新增保护器。
+
 ## 9. 需求分类与拒绝规则
 
 任何新增建议必须先归入且只能归入一类：
@@ -196,3 +222,9 @@ v1 只有在以下闭环同时成立时才算产品完成：
 5. 第 7.2 节新增 `1.2.0` 双向交换完成条件；
 6. Provider、Agent Runtime、开发任务执行、Git、网络、自动批准、业务代码修改和框架识别白名单仍在永久边界外；
 7. 本次授权只包含宪法修订、`1.1.0` 完整性修正和 `docs/17` 设计落盘，不自动授权 `1.2.0` 产品代码、真实项目、Git 写入或发布。
+
+## 14. `1.3.0` 开发人员交互与生命周期修订记录
+
+用户在移动端真实开发中确认：`AGENTS.md` 与 CLI 已被调用，但机票首页关键设计未进入有效任务上下文，工具仍给出成功结果，Host 继续实施；随后明确要求安装后的无需求引导、开发人员与项目直接对话、已有工作接续、任务与环境变化提醒，并于 `2026-09-29` 批准整体产品方向改造与设计落档、要求等待下一步执行。
+
+本次修订改变第 2 至第 5 节的产品承诺、稳定价值、内核和边界说明，细化第 6 节的不变量，并在第 7.3 节增加新方向完成条件。现有包 `frontend-project-context@1.9.1` 的已发布事实不受改写；现有公开协议不因本次文档修订自动升级。实现、目标项目改造、Git、Provider、网络、打包与发布均未由此次设计授权触发。

package/docs/08-INSTALLATION-AND-DISTRIBUTION.md

@@ -2,7 +2,7 @@
 
 > 权威说明：本文是支持性设计文档；当前唯一规范真源是 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md)。
 
-状态：`frontend-project-context@1.7.0` 已发布到 public npm，registry 工件逐字节匹配并完成全新项目回装初始化；195/195、真实 PC 初始化与 A-130 有界 Host/Provider 终验均通过
+状态：本文记录安装与分发原则及历史发布证据；当前版本与发布事实以 `package.json` 和 `PROJECT_STATE.json` 为准。
 适用项目：`dtg-frontend-delivery-agent`  
 本文记录产品如何交付、安装、共享、升级和验证；它不自行授权打包、registry、Git 或发布操作。
 
@@ -43,10 +43,10 @@ CI 安装项目锁定的依赖版本并执行只读检查。CI 不依赖机器
 持久初始化前，先把精确版本安装为项目开发依赖：
 
 ```bash
-npm install --save-dev frontend-project-context@1.8.0
+npm install --save-dev --save-exact frontend-project-context@1.10.0
 ```
 
-包名冻结为 `frontend-project-context`，可执行文件名为 `project-context`。安装必须先于任何持久初始化写入，使 discovery 登记的 `package.json` digest 已包含正式依赖，避免补装工具后立即产生 `source-changed`。`1.8.0` 已通过本地 O-01 至 O-12、完整回归与隔离真实项目的无历史 Host 发布阻断验收。
+包名冻结为 `frontend-project-context`，可执行文件名为 `project-context`。安装必须先于任何持久初始化写入，使 discovery 登记的 `package.json` digest 已包含正式依赖，避免补装工具后立即产生 `source-changed`。`1.10.0` 增加本地 L 阶段的任务交接能力；真实项目更新及具体任务的 Agent 行为须在目标项目窗口另行观察，不因安装或本地检查自动视为通过。
 
 选择项目内安装而不是全局安装，原因是：
 
@@ -281,3 +281,9 @@ IDE 插件可以在未来提供状态提示、冲突解释和可视化配置，
 6. check 无 findings，status 为 `clean/ready-for-task`，正常中文任务 context 成功生成。
 
 发布工件、Git 与回装证据全部闭合，本次 release 权限已经消费。
+
+## 19. `1.8.0` Real Project Onboarding Closure 正式发布
+
+`frontend-project-context@1.8.0` 于 `2026-09-15T09:41:29.644Z` 由 `fushanyx1` 发布到官方 public npm，`latest` 指向 `1.8.0`。发布包包含 104 个文件，压缩大小 378437 bytes、解包大小 1352711 bytes；SHA-1 为 `0146a54dd7b0fab80aa877efd5d09056eacede01`，SHA-256 为 `0153d84761e13c6c7b4d84e66bc802402db7cea71c50ff387374cc57adf56a5b`，integrity 为 `sha512-6EoGqyM2YucdgN49l/3Pm9Gid7zd6mmtHr9pMFb2lnxHiN7V/VVp6tJJiPPQ1SKNIPD1C46wzoGGjvb2HFYmag==`。
+
+官方 registry 重下载包与冻结候选逐字节一致。全新消费者从该包离线安装后通过 package version、help、capabilities schema 8、uninitialized status 和唯一初始化指令 digest 冒烟。实现前置门为 O-01 至 O-12 与完整回归 207/207，真实 Host 前置门已在真实项目隔离副本通过。最终授权只完成官方 public npm 发布、registry 核验和本地事实归档；没有继续推送私有 Git 远端，后续发布仍需重新授权。

package/docs/14-FORMAL-RELEASE-READINESS.md

@@ -130,3 +130,17 @@ registry/可见性决策、发布者认证、A-39/pack、release commit、`v1.0.
 7. 从 registry 重新下载的 tarball 与候选逐字节一致，随后在全新目录从 registry 安装，version/help/capabilities/status/init/publish-entry/clean-check 全部通过。
 
 该授权不包含真实目标项目升级、Phase D 其余适配器、Provider/Agent Runtime、自动批准或新产品能力。本次实现与发布授权均已消耗。
+
+## 13. `1.8.0` Real Project Onboarding Closure 正式发布
+
+用户于 `2026-09-15` 在 O-01 至 O-12、207/207 本地回归和隔离真实项目无历史 Host 验收通过后，明确授权 `1.8.0` 发布到官方 public npm。冻结候选对应本地 release commit `5f997106d195506afcb6a991400045e973365548` 与本地 annotated tag `v1.8.0`；最终 public-registry-only 范围未继续推送私有 Git 远端。
+
+发布验证记录：
+
+1. tarball 包含 104 个文件，压缩大小 378437 bytes、解包大小 1352711 bytes，不包含测试、自托管 `.project-context/`、`PROJECT_STATE.json`、`RTK.md` 或 tarball；
+2. SHA-1 为 `0146a54dd7b0fab80aa877efd5d09056eacede01`，SHA-256 为 `0153d84761e13c6c7b4d84e66bc802402db7cea71c50ff387374cc57adf56a5b`，integrity 为 `sha512-6EoGqyM2YucdgN49l/3Pm9Gid7zd6mmtHr9pMFb2lnxHiN7V/VVp6tJJiPPQ1SKNIPD1C46wzoGGjvb2HFYmag==`；
+3. `fushanyx1` 于 `2026-09-15T09:41:29.644Z` 发布 `frontend-project-context@1.8.0`，官方 registry 的 `latest` 指向该版本；
+4. registry 重下载 tarball 与冻结候选逐字节一致；
+5. 全新消费者离线安装后通过 package version、help、capabilities schema / Exchange Protocol 8、uninitialized status 与初始化指令 digest 冒烟。
+
+本次发布与核验授权已经消费。Provider、A-144、Sidecar、真实目标写入、业务代码修改、私有 Git 远端推送和后续版本发布仍需分别授权。

package/docs/28-REAL-PROJECT-ONBOARDING-CLOSURE-DESIGN.md

@@ -532,3 +532,13 @@ renderer 3 的 clean 分支原文语义是“继续遵守本文件其余仓库
 - fresh Host 全程留在 targetRoot，未继承初始化讨论，未写文件，未执行 Git、网络、Provider、构建、安装、发布或业务代码修改。
 
 据此，第 9.2 节真实 Host 发布阻断验收通过。该授权已经消费；用户已于同日另行授权 `1.8.0` 发布，发布结果将在完成后继续归档。Provider、A-144、Sidecar、真实目标写入与业务代码修改继续后置。
+
+## 15. `1.8.0` public npm 发布事实归档
+
+`2026-09-15T09:41:29.644Z`，`fushanyx1` 将 `frontend-project-context@1.8.0` 发布到官方 `https://registry.npmjs.org/`，访问级别为 public，`latest` 已指向 `1.8.0`。本地 release commit 为 `5f997106d195506afcb6a991400045e973365548`，本地 annotated tag 为 `v1.8.0`；最终 public-registry-only 范围内没有继续推送私有 Git 远端。
+
+冻结发布包共 104 个文件，压缩大小 378437 bytes、解包大小 1352711 bytes；SHA-1 为 `0146a54dd7b0fab80aa877efd5d09056eacede01`，SHA-256 为 `0153d84761e13c6c7b4d84e66bc802402db7cea71c50ff387374cc57adf56a5b`，integrity 为 `sha512-6EoGqyM2YucdgN49l/3Pm9Gid7zd6mmtHr9pMFb2lnxHiN7V/VVp6tJJiPPQ1SKNIPD1C46wzoGGjvb2HFYmag==`。从官方 registry 重新下载的 tarball 与冻结候选 `cmp` 逐字节一致。
+
+全新临时消费者只安装 registry 下载包，并以离线 CLI 完成以下冒烟：安装版本为 `1.8.0`；help 可用；capabilities schema / Exchange Protocol 为 8；status 正确报告 `uninitialized`；唯一初始化指令 ID/version/digest 为 `ai-project-initialization` / `1` / `sha256:8ec3bbf0202c3893514325db3f48d23adbcf18d7668b9731ac4f10e2a3be4d9e`。CLI 不提供顶层 `--version`，因此版本由已安装 package metadata 与 capabilities 双重确认。
+
+至此，本地 O-01 至 O-12、207/207 回归、隔离真实项目完整初始化、无历史 Host 接管、官方 public npm 发布、registry 逐字节复验和新消费者冒烟全部闭合。发布授权已经消费；Provider、A-144、Sidecar、真实目标写入、业务代码修改、私有 Git 远端推送和任何后续发布均未由本归档授权。

package/docs/29-REAL-PROJECT-1.8.0-INITIALIZATION-OBSERVATIONS.md

@@ -0,0 +1,228 @@
+# 1.8.0 真实项目初始化与上下文观察记录
+
+> 状态：`observation-only / discussion-only / draft`
+>
+> 日期：`2026-09-16`
+>
+> 目标项目：`/Users/fushan/开发/tmc/dtg-tmc-pc`
+>
+> 目标分支：`dev_agent20160904`
+>
+> 安装版本：`frontend-project-context@1.8.0`
+
+## 1. 记录目的与边界
+
+本文只归档 `frontend-project-context@1.8.0` 在真实项目中的正式初始化过程、任务 Context 实测和新 Host 审查结果，供后续集中整理问题时使用。
+
+本文不是产品设计、路线图、缺陷裁定、Project Contract、实现授权、发布授权或真实项目业务代码修改授权。文中“已确认”“观察风险”“待真实任务验证”必须保持区分；不得因为单次真实项目现象直接扩大 discovery、修改内核或形成新版本实现。
+
+本轮观察者不替代真实 Host 执行初始化，不修改目标项目业务代码，不提交或推送任何仓库。
+
+## 2. 正式初始化结果
+
+真实 Host 严格使用目标项目本地安装的 `frontend-project-context@1.8.0` 和包内唯一指令 `ai-project-initialization@1` 执行初始化。
+
+初始化指令摘要：
+
+```text
+sha256:8ec3bbf0202c3893514325db3f48d23adbcf18d7668b9731ac4f10e2a3be4d9e
+```
+
+人工集中审查绑定：
+
+- 12 个来源；
+- 16 个 Contract item；
+- proposal 摘要 `sha256:5fa3c7a974adae911fe448505a765fce4d64e80f6908c34eaccc104908466e36`；
+- `AGENTS.md` 人工区域不修改；
+- 只追加 renderer 4 受管 AI Entry；
+- reviewer 为 `fushan`。
+
+机械应用和 Phase E 完成后的结果：
+
+- `health=clean`；
+- `contractReadiness=contract-ready`；
+- `check` 无 findings；
+- AI Entry renderer 4，状态 `current`；
+- 12 个 active source；
+- 16 个 approved item；
+- Contract 摘要 `sha256:144eb00d0a5ef1c6f6c531ca3147d179d500b6ecedd6008adf4e62ba1dc96fd1`；
+- `setup.proposal.json` 与 `initialization.proposal.json` 已删除；
+- 无本轮 Action Plan、Review Bundle、receipt、日志或初始化缓存残留；
+- 未修改业务代码。
+
+代表性 Context 验证覆盖 project、`src` path-prefix、router/http/store/build file scope，文件级 sibling isolation 成立。
+
+## 3. 生成文件的实际职责
+
+| 文件 | 本轮确认的职责 |
+| --- | --- |
+| `.project-context/contract.json` | 保存人工批准的长期事实、规则、引用和验证描述，是 Context Bundle 的语义来源 |
+| `.project-context/sources.lock.json` | 锁定来源摘要，用于发现来源漂移 |
+| `.project-context/projections.lock.json` | 记录 `AGENTS.md` 受管区域所有权和 renderer 状态 |
+| `AGENTS.md` 受管区域 | 让新 Host 先检查 Project Context 状态并按目标路径编译任务 Context |
+
+三份 store 和 AI Entry 共同建立治理、来源、作用域、所有权和漂移检查闭环；它们不自动形成组件调用图、接口字段语义或业务任务实现知识。
+
+## 4. 普通 Vue 任务 Context 实测
+
+本轮对以下两个不同目标和任务执行了实际 Context 编译：
+
+1. `src/views/flight/list/index.vue`：修改航班列表页面的行李信息展示；
+2. `src/components/flight/non-whitelist-confirm.vue`：调整非白名单航班确认弹窗的行李信息展示。
+
+两份 Bundle 除任务文字和目标路径外，命中内容基本相同：
+
+- 项目技术栈；
+- 可用 scripts；
+- 授权边界；
+- 格式化与提交钩子；
+- 工作流选择；
+- 用户工作区保护；
+- `src` 级国际化规则；
+- `src` 级源码复用原则；
+- 项目入口与 OpenSpec 引用；
+- 风险验证描述。
+
+两份 Bundle 均未直接提供：
+
+- Vue 组件 props、events 和实际数据结构；
+- 调用方与被调用方；
+- 对应接口、字段映射和请求链路；
+- 行李展示的稳定业务规则；
+- 往返、多程、国内、国际等业务差异；
+- 可直接复用的相邻实现；
+- 本次任务的精确验证路径。
+
+因此，当前 Contract 对普通 Vue 文件的新增价值主要是项目治理、安全边界、通用开发规则和来源可追溯性；具体功能实现仍需要 Host 动态调查目标文件、调用方、接口和相邻实现。
+
+## 5. 已确认问题
+
+### O-01 普通业务文件的 Context 区分度不足
+
+两个不同机票 Vue 目标实际获得了近似相同的通用 Bundle。当前 scope compiler 工作正常，但 Contract 没有提供机票域或组件级稳定语义，因此不能仅凭 Bundle 明显提高具体业务修改的准确度。
+
+这不等于应该把所有业务源码注册为长期真源。后续需要通过真实任务判断哪些稳定业务边界值得进入 Contract，哪些应继续由 Host 动态调查。
+
+### O-02 未知目标路径时存在启动歧义
+
+AI Entry 要求根据真实任务确定路径后编译 Context；仓库人工规则又要求先全仓定位。对于只有现象、尚不知道文件位置的任务，Host 可能在“先定位源码”和“先编译精确 Context”之间发生循环。
+
+候选收口方向是粗粒度定位 Context 与精确多路径 Context 两阶段，但本文不冻结具体协议。
+
+### O-03 单路径示例不足以表达多文件任务
+
+CLI 可以表达多个目标路径，但 AI Entry 示例只展示一个 `<RELATIVE_PATH>`。真实任务同时涉及页面、组件、API、store、router 或构建文件时，只传主文件会遗漏其他文件的精确 scope policy。
+
+### O-04 `read targets` 要求缺少结构化输出支持
+
+AI Entry 要求 Host 报告必要 read targets；实际 `context --json` 只返回一个 Markdown `content` 字段，Bundle 中只有 Source index，没有结构化区分：
+
+- required read targets；
+- conditional read targets；
+- provenance-only sources；
+- 已被 Contract statement 充分替代的来源。
+
+Source index 不能直接等同于全部必读文件，否则普通 Vue 任务会重新读取 `vue.config.js`、`.husky/pre-commit`、`openspec/config.yaml` 等不一定相关的来源。
+
+### O-05 `AGENTS.md` 与 Contract 重复较多
+
+当前人工 `AGENTS.md` 已包含技术栈、目录、命令、格式、路由、HTTP、Vuex、国际化、构建和授权规则；Context Bundle 又重新输出其中一部分。
+
+实际链路可能变成：
+
+```text
+自动读取完整 AGENTS
+→ 编译 Context
+→ 再收到 AGENTS 规则摘要
+→ Source index 再次指向 AGENTS/docs
+```
+
+这降低了最小读取和按 scope 分发的增量价值。Contract 语义覆盖充分以前，不应直接删除 AGENTS 人工规则。
+
+### O-06 `source.entry` 将人工真源与受管投影绑定在同一摘要中
+
+多个 Contract item 使用整个 `AGENTS.md` 作为 `source.entry`，而该文件同时包含 Project Context 自己维护的 marker 区。未来 renderer 升级或 AI Entry 文案变化可能造成产品自身引起的 source drift，并牵连并未变化的人工事实。
+
+可能方向包括只摘要人工区域或把长期规则迁入独立人工真源；本文不选择实现方案。
+
+### O-07 关键域处置没有形成可供后续 Host 查询的持久 coverage 结论
+
+初始化集中审查曾逐项说明关键开发域已纳入、排除或动态调查；但后续 `coverage-audit` 仍显示 `registrationCoverage=not-declared`，具体排除和动态调查结论没有以清晰持久结构提供给新 Host。
+
+`contract-ready` 当前只能证明 Contract 结构、来源、审批和作用域编译有效，不能被解释为所有业务语义覆盖完整。
+
+### O-08 产品能力边界与 Host 开发权限的交接不够明确
+
+`status` 中的 `businessCodeWrites=false` 和 `taskExecution=false` 表示 Project Context 产品自身不执行开发任务；新 Host 可能误解为当前开发请求也禁止修改代码。AI Entry 尚未明确说明 Context 编译完成后如何回到人工规则和当前用户请求判断 Host 的任务权限。
+
+## 6. 观察风险，尚未裁定为产品缺陷
+
+### R-01 `attention` 可能抢占无关真实任务
+
+AI Entry 要求在 `attention` 时执行 `sync` 返回的维护工作单元，但没有在入口中明确区分与当前目标相关和无关的漂移。需要真实分支和日常开发观察后再判断是否会阻断无关任务。
+
+### R-02 宿主的外部 memory 仍可能进入推理链
+
+新的审查 Host 在读取当前项目前访问了 `/Users/fushan/.codex/memories/MEMORY.md`。因此该窗口不能作为仅凭初始化后目标项目完成接管的无历史证明。
+
+这首先属于 Host/平台偏离和外部条件：Project Context 可以声明外部记忆不是项目真源，但未必能阻止更高优先级的平台机制读取它。后续验收必须显式区分“读取过外部 memory”和“是否把外部 memory 当成项目事实”。
+
+### R-03 新 Host 最终报告存在 item 数量误差
+
+新 Host 报告当前 Contract 有 14 个 approved item；实际为 16 个。可能遗漏了两个 reference item：
+
+- `reference.openspec-workflow`；
+- `reference.project-guidance`。
+
+该问题属于 Host 报告质量，不直接证明 Contract 错误。
+
+## 7. 当前合理且应保留的能力
+
+- 项目本地精确版本和 `npm exec --offline` 阻止隐式版本漂移；
+- 人工 Project Contract、稳定 ID、来源和显式审批成立；
+- AI Entry 只拥有 marker 区，人工区域所有权清晰；
+- `status`、`sync` 和 `context` 默认只读；
+- Contract、source lock、projection lock 当前一致；
+- 文件级 scope 与 sibling isolation 实际生效；
+- router、HTTP、store、build policy 不会污染普通业务页；
+- Contract 不自动扩张业务代码、提交、推送、发布或外部副作用权限；
+- 模板 README、生成物、历史任务实例和虚构测试能力没有被提升为长期真相。
+
+## 8. 尚不能得出的结论
+
+本轮不能证明：
+
+- 当前 Contract 已包含所有业务语义；
+- 普通 Vue 任务仅靠 Context Bundle 就能完成正确修改；
+- 每个 Source index 都应由 Host 读取；
+- 外部 memory 已被 Project Context 隔离；
+- `attention` 一定会阻断无关开发；
+- 任一观察项已经获得产品修复、设计或下一版本授权。
+
+## 9. 后续真实开发的观察清单
+
+下一次在同一分支使用无历史 Host 执行真实业务需求时，重点记录：
+
+1. Host 是否只从目标项目入口发现并消费 Project Context；
+2. 目标路径未知时如何完成首次定位；
+3. 是否在识别多个受影响文件后重新编译多路径 Context；
+4. 实际报告的 item IDs、scope 和 read targets 是否准确；
+5. Source index 是否引发不必要的重复读取；
+6. 通用 Contract 是否减少错误命令、越权、全仓格式化或危险构建；
+7. 缺少业务域语义是否导致漏读调用方、接口或相邻实现；
+8. Context 不足时 Host 是否明确报告 gap，而不是猜测；
+9. 真实修改完成后 Project Context 是否仍为 `clean`；
+10. 哪些缺口属于产品协议、目标项目 Contract 数据、Host 偏离或外部平台条件。
+
+## 10. 后续整合原则
+
+在真实开发链路完成前，保持目标项目安装的 `1.8.0` 不变，不边走边修改产品或目标项目内部 store。观察项应先按以下类型归类：
+
+- 产品协议缺口；
+- 目标项目 Contract 数据缺口；
+- AI Entry/消费者适配问题；
+- Host 行为偏离；
+- 外部平台条件；
+- 尚未证实的风险。
+
+完成至少一个真实业务任务后，再基于本记录和新证据集中决定哪些问题需要进入设计。任何设计、Contract 修订、产品实现、Git 操作和发布仍需单独授权。