project-tiny-context-harness 0.6.1 → 0.6.2

package/README.md

@@ -137,7 +137,7 @@ npm ci
 npm run smoke:quickstart
 npm run preview:pack
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.6.1.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.6.2.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -199,7 +199,7 @@ An explicit Long-Task uses its existing Requirement, Control, Assertion, `ui_bro
 
 Use `/source-plan-authoring` for an explicitly requested initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. It accepts either one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments; a short instruction identifying their roles, the goal, reference authority and desired elaboration is sufficient.
 
-It produces one self-contained Markdown document with a complete input inventory, preserved direct requirements, traceable necessary derivations and explicitly delegated low-impact/reversible product choices. Unsupported high-impact choices remain `DEC`/`decision_required`. Interactive products are expanded through every in-scope surface to material control level, including placement, behavior, validation, navigation, loading/empty/success/failure/recovery/permission feedback and accessibility. The plan retains semantic Outcome boundaries, stable keys/anchors, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
+It produces one self-contained Markdown document with a complete input inventory, preserved direct requirements and traceable necessary derivations. Before comparative research or a material product, technical, architecture or provider selection, it asks a concise targeted question when an unknown user priority such as quality versus cost, speed, reliability, privacy, lock-in or operational burden could change the research scope, candidate set or recommendation; there is no fixed questionnaire and known preferences are not re-asked. Once that preference envelope is clear, it decides what research is needed and uses current authoritative or primary sources for external capability, price, quota, license, compatibility, region, security or support claims. A request to synthesize, refine, complete or use judgment then delegates plan-level authoring: each supported recommendation is recorded as `delegated` with its instruction, preference/evidence basis and exact meaning instead of triggering approval, including high-impact plan semantics. Real payment, contracting, production release, destructive production mutation, permission grants, sensitive-data transmission and required legal/security/human approval remain `EXT`; only conflicts, user-reserved choices, missing material preferences or cases with no defensible recommendation remain `DEC`/`decision_required`. Interactive products are expanded through every in-scope surface to material control level, including placement, behavior, validation, navigation, loading/empty/success/failure/recovery/permission feedback and accessibility. The plan retains semantic Outcome boundaries, stable keys/anchors, Runtime-exact Fact/Affected-Outcome `RISK` items, distinct `OBL`/`HINT` items and one observable scenario per `AC` with explicit accepted `REQ`/`CTRL`/`OBL`/`NCOMP` keys. Risk names are the ten Contract facts: use `data_migration`, split critical-path weak observability into `critical_user_path` plus `weak_observability`, and preserve `multi_repository_change` for Compiler rejection.
 
 It does not update Context, bind a repository, generate Delivery Contract YAML, execute implementation, create workflow state or claim completion. `HINT` is not a Material Source Item, and the Skill emits no `ty-source-item` markers. A Source Plan is Source, not a Contract Draft. The structure is optional; ordinary prose remains valid Long-Task Source.
 
@@ -207,7 +207,7 @@ It does not update Context, bind a repository, generate Delivery Contract YAML,
 
 The explicit Long-Task Workflow uses one platform-native Goal, one user-selected repository/workspace, one complete `long-task-delivery-v2` Contract and one Final Gate. Outcomes are independently decidable acceptance units; Delivery Set orchestration and top-level Contract splitting inside one selected delivery are retired.
 
-Contract authoring preserves stable Source keys/anchors where practical. A product choice already recorded in Source under explicit user delegation remains ordinary Source meaning, but Contract authoring cannot extend that delegation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while any other new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
+Contract authoring preserves stable Source keys/anchors where practical. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once the decision criteria are clear, a defensible recommended plan choice is recorded in real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never added only in YAML. Plan delegation does not authorize a real high-risk external action, which remains an explicit external confirmation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue, while conflicting, user-reserved, missing-preference or unsupported new product semantics require `decision_required`. Missing recommended Source Plan structure alone never blocks authoring.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` revises the same Draft across repository/Context reads and Preflight repairs; a complete Contract need not fit one response. Integrated authoring keeps repository evidence and findings attached to the same object and avoids a second handoff, plan, authority or Receipt. There is no standalone Contract Draft Skill or Authoring State.
 
@@ -307,7 +307,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-The synchronized local preview tarball is named `project-tiny-context-harness-0.6.1.tgz`.
+The synchronized local preview tarball is named `project-tiny-context-harness-0.6.2.tgz`.
 
 ## Community And Further Reading
 

package/assets/README.md

@@ -137,7 +137,7 @@ The smoke packs the local workspace, installs it into a disposable repo and vali
 
 ```sh
 cd /path/to/your/test-repo
-npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.6.1.tgz
+npm install -D /path/to/project-tiny-context-harness/tmp/ty-context/source-preview/package/project-tiny-context-harness-0.6.2.tgz
 npx --no-install ty-context init --adopt
 make validate-context
 ```
@@ -218,14 +218,15 @@ An explicit Long-Task expresses material visual expectations through the existin
 
 ### Optional Source Plan Authoring
 
-Use `/source-plan-authoring` when explicitly asking for an initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. The input may be one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments. A short request that identifies the artifact roles, product goal, reference authority and desired elaboration is enough; no intake questionnaire or pre-normalized outline is required.
+Use `/source-plan-authoring` when explicitly asking for an initial plan, Source Plan, source draft, or synthesis/refinement/audit of later implementation or Contract-authoring Source. The input may be one substantially complete plan or a sparse goal plus mixed notes, product/technical documents, screenshots, diagrams and other attachments. A short request that identifies the artifact roles, product goal, reference authority and desired elaboration is enough; no fixed intake questionnaire or pre-normalized outline is required.
 
 It outputs one self-contained Markdown Source Plan that:
 
 - inventories every supplied artifact, inspects all material pages/frames/screens and records coverage gaps instead of silently sampling;
 - preserves direct requirements and their qualifiers;
 - marks necessary derivations and cites what they derive from;
-- when the user delegates synthesis or elaboration, makes traceable low-impact, reversible product choices marked `delegated`, while keeping permissions, destructive behavior, pricing, retention, security policy and other high-impact choices as `DEC`/`decision_required`;
+- before comparative research or a material product, technical, architecture or provider selection, asks a concise targeted question when an unknown user priority such as quality versus cost, speed, reliability, privacy, lock-in or operational burden could change the research scope, candidate set or recommendation; it does not re-ask known preferences or interrupt minor reversible choices;
+- after the preference envelope is clear, decides what research is needed, uses current authoritative or primary sources for external capability/pricing/quota/license/compatibility/region/security/support claims, and treats a request to synthesize, refine, complete or use judgment as plan-level delegation: one supported recommendation is recorded as `delegated` with its instruction, preference/evidence basis and exact meaning instead of asking for approval, including high-impact plan semantics; real payment, contracting, production release, destructive production mutation, permission grants, sensitive-data transmission and required legal/security/human approval remain `EXT`, while only conflicts, user-reserved choices, missing material preferences or cases with no defensible recommendation remain `DEC`/`decision_required`;
 - splits Outcomes only by independently decidable observable results;
 - uses stable semantic keys and explicit anchors for important Source items;
 - separates mandatory `OBL` obligations from advisory `HINT` suggestions;
@@ -250,7 +251,7 @@ Use `/long-task-workflow` only when explicitly requested or when the current wor
 - a complete Final Gate on one current snapshot;
 - a Stop Hook that rejects stale completion.
 
-Long-Task Contract authoring preserves stable Source keys and anchors where practical. A product choice already recorded in Source under explicit user delegation remains ordinary Source meaning, but Contract authoring cannot extend that delegation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; any other new business rule, default, recovery behavior, permission or scope becomes `decision_required` instead of being silently added. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
+Long-Task Contract authoring preserves stable Source keys and anchors where practical. If an unknown preference could materially change comparative research or selection, it asks before proceeding. Once the decision criteria are clear, a defensible recommended plan choice is written into real Source with its delegation, preference/evidence basis and exact meaning before Contract mapping; it is never hidden only in YAML. That plan delegation does not authorize a real high-risk external action, which remains an explicit external confirmation. Meaning-preserving structural decomposition and evidence-backed repository binding may continue; conflicting, user-reserved, missing-preference or unsupported new product semantics remain `decision_required`. Missing recommended Source Plan structure never blocks authoring, but the marker-only Material Source Item enumeration required for activation does.
 
 Before the first successful formal Compile, `delivery-contract.yaml` is one non-authoritative Contract Draft. `/long-task-workflow` keeps revising that same Draft across repository/Context reads and Preflight repair rounds; it does not require one response to produce a complete Contract. Draft authoring is integrated because repository bindings and verification inputs need real evidence, Preflight findings must feed back into the same object, and a separate handoff would risk lost meaning or a second plan/authority. No standalone Contract Draft Skill, Draft Receipt or Authoring State exists.
 
@@ -452,7 +453,7 @@ make validate-harness
 
 The modularity gate is `ty-context check-modularity`. Scoped waivers require `owner`, `introduced_at`, `reason`, `tracking_issue` and `expiry_condition`.
 
-`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.6.1.tgz` under the preview output directory.
+`npm run preview:pack` produces a local preview named `project-tiny-context-harness-0.6.2.tgz` under the preview output directory.
 
 ## Community And Further Reading
 

package/assets/README.zh-CN.md

@@ -101,31 +101,32 @@ Context: no durable fact change
 
 只有新长期模块/能力、公共 API/Schema/data/persistence、source of truth/state ownership、dependency direction、跨 area、migration/security/recovery 或可复用抽象才触发架构 Gate；小修复不支付这项成本。Gate 要明确 owner、唯一事实源、依赖方向、接口/状态生命周期、失败/恢复/兼容、禁止绕过路径和项目自己的可执行架构检查。
 
-Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
-
-### 视觉交付指导
-
-对设计系统、重设计、高保真实现或 visual polish，`context_uiux_design` 在任务内部维护一个风险比例化的 Visual Coverage Set，覆盖生产 surface/component、viewport、theme/mode、state、content stress 与 accessibility/motion 条件。它只是内部计划，不是必需 matrix 或新权威。耐久 surface/interaction 事实仍属于 `project_context/**`，耐久视觉语义与理由属于 `DESIGN.md`；项目只声明一个精确 token 手工事实源和一个生成方向。`context_development_engineer` 把这些意图绑定到生产组件/真实 route，只报告真正渲染和检查过的组合，静态 kit 或 mock 不能替代产品 UI 证据。
-
-显式 Long-Task 仍通过现有 Requirement、Control、Assertion、`ui_browser`、verification input 与 `external_confirmation` 表达视觉要求。影响验收的截图 baseline 是冻结的 verifier input，生成截图/diff 只是 review artifact，主观设计或新 baseline 批准保持外部确认。这项指导不新增视觉 Schema、risk level、lifecycle state、Gate 或必需 artifact，也不修改默认 Workflow Contract。
-
-### 可选 Source Plan Authoring
-
-用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求综合、细化、审计后续实现与 Contract Authoring 的 Source 时，使用 `/source-plan-authoring`。输入既可以是一份接近完成的方案，也可以只是目标，加上零散笔记、产品/技术文档、截图、图表等混合附件。用户只需说明附件角色、产品目标、参考资料是精确目标还是灵感，以及希望 Skill 细化即可；不需要先填问卷或整理统一大纲。
+Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨语言通用架构分析器。`check-modularity` 的语句数/分支风险会定位到最高风险函数和行号。
+
+### 视觉交付指导
+
+对设计系统、重设计、高保真实现或 visual polish，`context_uiux_design` 在任务内部维护一个风险比例化的 Visual Coverage Set，覆盖生产 surface/component、viewport、theme/mode、state、content stress 与 accessibility/motion 条件。它只是内部计划，不是必需 matrix 或新权威。耐久 surface/interaction 事实仍属于 `project_context/**`，耐久视觉语义与理由属于 `DESIGN.md`；项目只声明一个精确 token 手工事实源和一个生成方向。`context_development_engineer` 把这些意图绑定到生产组件/真实 route，只报告真正渲染和检查过的组合，静态 kit 或 mock 不能替代产品 UI 证据。
+
+显式 Long-Task 仍通过现有 Requirement、Control、Assertion、`ui_browser`、verification input 与 `external_confirmation` 表达视觉要求。影响验收的截图 baseline 是冻结的 verifier input，生成截图/diff 只是 review artifact，主观设计或新 baseline 批准保持外部确认。这项指导不新增视觉 Schema、risk level、lifecycle state、Gate 或必需 artifact，也不修改默认 Workflow Contract。
+
+### 可选 Source Plan Authoring
+
+用户明确要求初版方案、源方案、方案源稿、Source Plan，或要求综合、细化、审计后续实现与 Contract Authoring 的 Source 时，使用 `/source-plan-authoring`。输入既可以是一份接近完成的方案，也可以只是目标，加上零散笔记、产品/技术文档、截图、图表等混合附件。用户只需说明附件角色、产品目标、参考资料是精确目标还是灵感，以及希望 Skill 细化即可；不需要先填固定问卷或整理统一大纲。
 
 它输出一份自包含 Markdown Source Plan：
 
-- 为每份附件建立 Input Inventory，完整检查有实质含义的页面、画面与屏幕，未读内容或覆盖缺口必须显式报告，不能静默抽样；
-- 保留直接要求及其限定条件；
-- 必要推导必须标记并写明 `Derived From`；
-- 用户明确委托综合或细化时，可以自主作出低影响、可逆的产品选择，但必须标记为 `delegated` 并记录委托语句与依据；权限、破坏性行为、付费、数据保留、安全策略等高影响选择仍进入 `DEC`/`decision_required`；
+- 为每份附件建立 Input Inventory，完整检查有实质含义的页面、画面与屏幕，未读内容或覆盖缺口必须显式报告，不能静默抽样；
+- 保留直接要求及其限定条件；
+- 必要推导必须标记并写明 `Derived From`；
+- 在对比调研或实质性的产品、技术、架构、供应商选型前，先判断哪些用户取舍会改变调研范围、候选集或推荐；如果质量与性价比、交付速度、可靠性、隐私、供应商锁定、运维成本等关键偏好不明确，就先用简短、有针对性的问题询问用户，不重复询问已有偏好，也不打断推荐不会改变的局部可逆选择；
+- 偏好边界明确后，再决定是否以及如何调研；外部能力、价格、额度、许可、兼容性、区域、安全与支持等时效性事实使用当前权威或一手来源。用户要求综合、细化、补全或自行判断时，默认委托方案层决策：形成有依据的合理推荐后，直接标记为 `delegated` 并记录委托语句、偏好/证据依据和准确含义，高影响方案语义本身不再触发批准；真实付款/签约、生产发布、生产数据破坏性修改、实际授权、敏感数据外发及必要法务/安全/人工审批仍保留为 `EXT`，只有输入冲突、用户明确保留、关键偏好仍缺失或无法形成可靠推荐时才进入 `DEC`/`decision_required`；
 - Outcome 只按可独立判断的可观察结果拆分；
 - 重要 Source 项使用稳定语义 Key 与显式 Anchor；
 - 强制技术义务使用 `OBL`，非强制实现建议使用 `HINT`；
-- 对交互产品，先穷举范围内的 surface，再细化到每个实质控件，分别记录页面/区域/类型/文案、位置、任务、可见与可用条件、触发/输入/校验/默认值、交互/跳转，以及 Loading、Empty、Success、Failure、Recovery、Permission、Feedback 和 Accessibility；
+- 对交互产品，先穷举范围内的 surface，再细化到每个实质控件，分别记录页面/区域/类型/文案、位置、任务、可见与可用条件、触发/输入/校验/默认值、交互/跳转，以及 Loading、Empty、Success、Failure、Recovery、Permission、Feedback 和 Accessibility；
 - 明确“不算完成”的 Source 含义使用 `NCOMP`；
 - 每个 `RISK` 明确 Fact、单个 Affected Outcome、Basis 与 Consequence，无法确定时进入 `DEC`；Fact 精确使用 Runtime 的十个名称：`public_api_or_schema_change`、`persistent_data_change`、`data_migration`、`security_boundary_change`、`permission_boundary_change`、`irreversible_external_effect`、`critical_user_path`、`full_population_operation`、`multi_repository_change`、`weak_observability`；
-- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，不能首次偷渡新需求，并在文末报告是否已可交给 Contract Authoring。
+- 每个 AC 只代表一个 Given/When/Then 可观察场景，显式列出对应 `REQ`/`CTRL`/`OBL`/`NCOMP` Key，不能首次偷渡新需求，并在文末报告是否已可交给 Contract Authoring。
 
 它不更新项目 Context，不绑定真实仓库 owner/path/runner，不生成 Delivery Contract YAML，不执行实现，不创建工作流状态，也不声明完成。`HINT` 不是 Material Source Item；Source Plan Skill 不输出 `ty-source-item` Marker，Marker 由后续 repository-aware Long-Task Authoring 插入。Source Plan 是 Source，不是 Contract Draft。推荐结构只是 Authoring Fast Path；普通 prose/Source Plan 或普通文本方案仍可直接作为 Long-Task Source。
 
@@ -143,7 +144,7 @@ Harness 只路由仓库原生 lint/AST/dependency/contract check，不实现跨
 - Final Gate 在一个当前快照上重跑全部 Check；
 - Stop Hook 在结果 stale 时阻止完成。
 
-Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。已经在 Source Plan 中依据用户显式委托记录的产品选择属于普通 Source 含义，但 Contract Authoring 不能扩大这份委托。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；除此之外新增业务规则、默认值、恢复行为、权限或范围必须进入 `decision_required`，不能静默加入。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
+Long-Task Contract Authoring 会尽量保留 Source 中已有的稳定 Key 与 Anchor。若未知偏好会实质改变对比调研或选型，必须先询问用户；决策标准明确后，有依据的推荐方案再把委托、偏好/证据依据和准确含义写入真实 Source，然后映射到 Contract，不能只藏在 YAML 中。这份方案委托不授权任何真实高危外部动作，高危动作继续作为显式 external confirmation。保持产品含义的结构分解和有真实证据的仓库绑定可以继续；输入冲突、用户明确保留、关键偏好缺失或没有可靠推荐的新产品语义仍进入 `decision_required`。缺少推荐 Source Plan 结构不构成阻塞，但激活前必须完成只插入标记、不改写原文的 Material Source Item 枚举。
 
 第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`/long-task-workflow` 可以跨多轮仓库/Context 读取和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
 

package/assets/context_templates/architecture.md

@@ -14,11 +14,11 @@ This is the restrained architecture context. Keep only facts that help a fresh a
 
 - Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
 
-## Design Rationale
-
-- Record architecture-level choices, rejected alternatives and tradeoffs that still constrain future work; leave this empty when no stable architecture reason exists.
-- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, debug history, agent reasoning or reasons inferred only from current code shape.
-- Architecture boundary changes should be captured here before implementation alignment.
+## Design Rationale
+
+- Record architecture-level choices, rejected alternatives and tradeoffs that still constrain future work; leave this empty when no stable architecture reason exists.
+- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, debug history, agent reasoning or reasons inferred only from current code shape.
+- Architecture boundary changes should be captured here before implementation alignment.
 
 ## Constraints And Tradeoffs
 

package/assets/context_templates/area.md

@@ -15,11 +15,11 @@
 
 ## Module Design Capsule
 
-- Principles: stable execution constraints that should affect future module work.
-- Design Logic: the minimum logic for choosing, rejecting, degrading or composing module behavior.
-- Design Rationale: only durable reasons, rejected alternatives and tradeoffs that change later implementation or verification decisions; leave it empty when no stable reason exists.
-- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
-- Current standards, thresholds and commands belong in the relevant contract or verification Context, not as permanent principles.
+- Principles: stable execution constraints that should affect future module work.
+- Design Logic: the minimum logic for choosing, rejecting, degrading or composing module behavior.
+- Design Rationale: only durable reasons, rejected alternatives and tradeoffs that change later implementation or verification decisions; leave it empty when no stable reason exists.
+- Do not invent rationale or store implementation summaries, PR notes, command output, test result claims, screenshot review notes, debug history, agent reasoning or reasons inferred only from current code shape.
+- Current standards, thresholds and commands belong in the relevant contract or verification Context, not as permanent principles.
 
 ## Key Constraints
 

package/assets/context_templates/product-surface-contract.md

@@ -18,9 +18,9 @@ Write only project-specific facts that should guide future implementation. Do no
 - Main Surface Allows:
 - Main Surface Forbids:
 - Drilldown Ownership:
-- Long Task State Requirement:
-- Design Rationale:
-- Empty / Loading / Stale / Unavailable:
+- Long Task State Requirement:
+- Design Rationale:
+- Empty / Loading / Stale / Unavailable:
 - Security / Redaction:
 - Verification:
 
@@ -48,16 +48,16 @@ Update this Context when:
 
 - A surface responsibility changes.
 - Main/drilldown ownership changes.
-- A durable long-task state contract is introduced.
-- A durable main/drilldown/diagnostic ownership rationale, rejected alternative or tradeoff will guide future changes.
-- A repeated UI/product rule becomes reusable.
-- A platform-specific interaction rule becomes stable.
+- A durable long-task state contract is introduced.
+- A durable main/drilldown/diagnostic ownership rationale, rejected alternative or tradeoff will guide future changes.
+- A repeated UI/product rule becomes reusable.
+- A platform-specific interaction rule becomes stable.
 
 Do not update this Context for:
 
 - CSS-only fixes.
 - One-off screenshot observations.
-- Temporary audit notes.
-- Test logs.
-- Local implementation summaries.
-- PR notes, command output, screenshot review notes, debug history, agent reasoning or rationale inferred only from current code shape.
+- Temporary audit notes.
+- Test logs.
+- Local implementation summaries.
+- PR notes, command output, screenshot review notes, debug history, agent reasoning or rationale inferred only from current code shape.

package/assets/github/harness.yml

@@ -22,10 +22,10 @@ jobs:
   harness:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
         with:
           fetch-depth: 0
-      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
+      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
         with:
           node-version: "24"
       - name: Prepare source workspace CLI

package/assets/skills/context_development_engineer/SKILL.md

@@ -61,28 +61,28 @@ When an active `/long-task-workflow` binding exists, that Skill owns lifecycle,
 
 sample provider / interface / page 证据不能替代 all-provider / all-interface / all-platform 或全量完成。来源要求全量而当前只能交付框架/样本时标记 `scope_conflict_requires_decision`；权威范围未收窄前不得声称完成。
 
-## Product Surface
+## Product Surface
 
 涉及 Web/移动/桌面/游戏 UI、CLI/TUI、表单、配置、输入、选择、搜索、筛选、调度、预算/配额/限流或状态反馈时：
 
 - 对照已有 Product Surface / Surface Contract、页面职责和控件任务，而不是只确认字段已暴露；
 - 内部保持 Surface Contract Hit、main allows/forbids、drilldown ownership、long-task state requirement、implementation drift 和 verification；
-- 缺失 durable surface responsibility 时设置 `Context Delta: required`，先用 `context_surface_contract` 或 owning Context 建立职责；
-- 收尾用简短 `Contract Conformance` 说明命中的 Context、实现满足方式、未满足项和验证入口。
-
-## Visual Delivery Implementation / 视觉交付实现
-
-When controlling Context, `DESIGN.md` or explicit Source declares material visual work, carry that intent into the real implementation without creating another workflow:
-
-- identify the production token source, its generation direction, the owning components/routes and any project-local UI/UX Skill before choosing implementation values;
-- reuse production components and real product routes for states/specimens instead of building a detached static imitation as the acceptance target;
-- preserve approved semantic tokens and component APIs; do not bypass them with undeclared raw color, spacing, typography or motion values merely to match one screenshot;
-- implement the declared Visual Coverage Set across the applicable viewport, theme/mode, state, content-stress and accessibility/motion combinations, while avoiding an unrequested full Cartesian expansion;
-- run project-owned rendered/component/browser verification and report only the combinations actually checked. Static analysis, generated kits and screenshot artifacts are supporting review material rather than proof of every visual or behavioral claim.
-
-If an active Long-Task applies, express material visual expectations through its existing Requirement, Control, Assertion, Check and external-confirmation mechanisms. Do not introduce a second visual plan, acceptance document or lifecycle.
-
-## Modularity Check
+- 缺失 durable surface responsibility 时设置 `Context Delta: required`，先用 `context_surface_contract` 或 owning Context 建立职责；
+- 收尾用简短 `Contract Conformance` 说明命中的 Context、实现满足方式、未满足项和验证入口。
+
+## Visual Delivery Implementation / 视觉交付实现
+
+When controlling Context, `DESIGN.md` or explicit Source declares material visual work, carry that intent into the real implementation without creating another workflow:
+
+- identify the production token source, its generation direction, the owning components/routes and any project-local UI/UX Skill before choosing implementation values;
+- reuse production components and real product routes for states/specimens instead of building a detached static imitation as the acceptance target;
+- preserve approved semantic tokens and component APIs; do not bypass them with undeclared raw color, spacing, typography or motion values merely to match one screenshot;
+- implement the declared Visual Coverage Set across the applicable viewport, theme/mode, state, content-stress and accessibility/motion combinations, while avoiding an unrequested full Cartesian expansion;
+- run project-owned rendered/component/browser verification and report only the combinations actually checked. Static analysis, generated kits and screenshot artifacts are supporting review material rather than proof of every visual or behavioral claim.
+
+If an active Long-Task applies, express material visual expectations through its existing Requirement, Control, Assertion, Check and external-confirmation mechanisms. Do not introduce a second visual plan, acceptance document or lifecycle.
+
+## Modularity Check
 
 新实现、重构、重复逻辑、模块边界或影响面控制需要内部记录 `Modularity Check: none|required|exception`。
 

package/assets/skills/context_full_project_export/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: context_full_project_export
-description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, 项目整体上下文, full project context export, export full project context, project context export, project overall context, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
+name: context_full_project_export
+description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, 项目整体上下文, full project context export, export full project context, project context export, project overall context, Source Pack export, source-pack export, code index export, task context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
 ---
 
 # Context Full Project Export
@@ -13,55 +13,55 @@ This Skill creates a temporary export artifact only. It does not author durable
 
 ## Purpose
 
-When the user needs a full project context export, project overall context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
-
-When the user needs a code-level implementation export, create one temporary Markdown snapshot of current source and engineering configuration files for upload to Web GPT or another external model.
-
-## Workflow
-
-1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files total under `tmp/ty-context/context-exports/latest/` and removes old timestamped export rounds:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`
-2. Use `--code-index` when implementation navigation is enough and full source bodies are not needed:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`
-3. Use `--task-context <name>` for focused handoff, preferably with a profile or explicit include selectors:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --profile <profile-id>`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --include-context project_context/areas/main.md --include-code 'src/example/**'`
-4. Use legacy `--all` when the user explicitly wants both old temporary artifacts in one command. Do not hand-write tracked export documents:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all`
-5. Use legacy `--full` when only the project Context bundle is needed:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full`
-6. Use legacy `--code` when only the full code-level implementation snapshot is needed. It generates one Markdown file by default and is the full fallback when Source Pack bundles are not enough:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code`
-7. Custom output paths are allowed only for legacy single-artifact modes and must stay under the temporary export directory. `--all` and Source Pack modes do not accept `--output`:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --output tmp/ty-context/context-exports/my-export.md`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --output tmp/ty-context/context-exports/my-code-export.md`
-8. Use dry-run mode to inspect planned sources before writing:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --check`
-9. After exporting, report artifact paths, source counts, recommended upload sets and warnings to the user. Do not summarize export contents back into Context.
+When the user needs a full project context export, project overall context export or external LLM handoff, create temporary export artifacts that collect project Context, key agent guidance, architecture/module facts, code navigation and bounded source support for copying into an external tool or one-off discussion.
+
+When the user needs a code-level implementation export, create one temporary Markdown snapshot of current source and engineering configuration files for upload to Web GPT or another external model.
+
+## Workflow
+
+1. Prefer the bounded Source Pack for external LLM / Web GPT planning. It writes at most 5 files total under `tmp/ty-context/context-exports/latest/` and removes old timestamped export rounds:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack`
+2. Use `--code-index` when implementation navigation is enough and full source bodies are not needed:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index`
+3. Use `--task-context <name>` for focused handoff, preferably with a profile or explicit include selectors:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --profile <profile-id>`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --include-context project_context/areas/main.md --include-code 'src/example/**'`
+4. Use legacy `--all` when the user explicitly wants both old temporary artifacts in one command. Do not hand-write tracked export documents:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all`
+5. Use legacy `--full` when only the project Context bundle is needed:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full`
+6. Use legacy `--code` when only the full code-level implementation snapshot is needed. It generates one Markdown file by default and is the full fallback when Source Pack bundles are not enough:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code`
+7. Custom output paths are allowed only for legacy single-artifact modes and must stay under the temporary export directory. `--all` and Source Pack modes do not accept `--output`:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --output tmp/ty-context/context-exports/my-export.md`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --output tmp/ty-context/context-exports/my-code-export.md`
+8. Use dry-run mode to inspect planned sources before writing:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --source-pack --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code-index --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --task-context <name> --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --all --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --full --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context export-context --code --check`
+9. After exporting, report artifact paths, source counts, recommended upload sets and warnings to the user. Do not summarize export contents back into Context.
 
 ## Output Boundaries
 
-- Export artifacts must remain temporary export artifacts, not Context.
-- `--source-pack` defaults to `tmp/ty-context/context-exports/latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
-- `--source-pack` and `--task-context` are capped at 5 output files. `--max-pack-files` cannot exceed 5.
-- `--code-index` creates a navigation index and manifest without complete source bodies.
-- `--task-context <name>` creates `task-contexts/task-context-<name>.md` plus optional support bundle; profile verification entries are listed, not executed.
-- `--full` defaults to `tmp/ty-context/context-exports/full-project-context-<timestamp>.md`.
-- `--code` defaults to `tmp/ty-context/context-exports/code-level-implementation-<timestamp>/code-level-implementation.md`.
+- Export artifacts must remain temporary export artifacts, not Context.
+- `--source-pack` defaults to `tmp/ty-context/context-exports/latest/`, with `source-pack-manifest.json`, `full-project-context.md`, `code-index.md` and optional `code-bundle-core.md` / `code-bundle-extended.md`.
+- `--source-pack` and `--task-context` are capped at 5 output files. `--max-pack-files` cannot exceed 5.
+- `--code-index` creates a navigation index and manifest without complete source bodies.
+- `--task-context <name>` creates `task-contexts/task-context-<name>.md` plus optional support bundle; profile verification entries are listed, not executed.
+- `--full` defaults to `tmp/ty-context/context-exports/full-project-context-<timestamp>.md`.
+- `--code` defaults to `tmp/ty-context/context-exports/code-level-implementation-<timestamp>/code-level-implementation.md`.
 - `--all` generates both default artifacts with the same timestamp.
 - `--all` does not accept `--output`; custom filenames are supported only for `--full` or `--code`.
 - `--code` creates one Markdown file, not shards or `all.md`.
 - Do not output to `project_context/**`.
 - Do not modify `project_context/context.toml`.
 - Do not register export artifacts as `[[context]]`, `implementation-index` or any Context graph node.
-- Do not write tracked docs; if the user asks for an ordinary docs path, redirect to `tmp/ty-context/context-exports/**`.
-- Export contents may include redaction warnings; do not bypass secret/token/cookie/password/api_key/credential/bearer/authorization filtering. Use `--redaction-strict` when the user wants the command to fail if any redaction occurred.
-- Profiles under `<harnessRoot>/config.yaml` are export selectors only. They must not become durable Context facts or execute verification commands.
+- Do not write tracked docs; if the user asks for an ordinary docs path, redirect to `tmp/ty-context/context-exports/**`.
+- Export contents may include redaction warnings; do not bypass secret/token/cookie/password/api_key/credential/bearer/authorization filtering. Use `--redaction-strict` when the user wants the command to fail if any redaction occurred.
+- Profiles under `<harnessRoot>/config.yaml` are export selectors only. They must not become durable Context facts or execute verification commands.
 
 ## Handoff
 

package/assets/skills/context_product_plan/SKILL.md

@@ -25,7 +25,7 @@ Project-specific product planning rules belong in a separate project-local Skill
 4. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件任务框架”重新理解用户任务和产品反馈；这只是通用判断框架，不是业务处方库。
 5. 当一个产品对象、能力或接口的增删改需要跨多个页面、模块、Context 或产品域同步调整时，将该影响范围视为产品边界复核信号；先判断它是否应沉淀为独立能力、subdomain 或 area，并明确对外契约、所有权和消费方边界，避免通过手工清单长期维护各消费面的重复映射。
 6. 产品意图、模块职责、边界和验收口径以 `project_context/**` 为准；代码和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码揭示“现在是什么”，代码不能静默重定义 Context。
-7. 输出产品判断或第一处实现编辑前，先给出唯一长期事实判断 `Context Delta: none|required`。若输入包含产品、架构、技术或验收来源，在 agent 内部逐项判断 delivery-significant constraint 已被 Context 覆盖、需要先更新 Context、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
+7. 输出产品判断或第一处实现编辑前，先给出唯一长期事实判断 `Context Delta: none|required`。若输入包含产品、架构、技术或验收来源，在 agent 内部逐项判断 delivery-significant constraint 已被 Context 覆盖、需要先更新 Context、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
 8. 普通 bug fix、局部样式、局部实现漂移、测试修复或探索性 spike 不更新 Context；如果过程中形成长期产品结论，应在继续对齐或交付前回写 Context。不要把 Context 机械补成代码改动摘要。
 9. 如果代码与 Context 冲突，显式标记为实现漂移、缺失工作或 Context 过期。
 10. 输出产品判断时保持短而具体，避免长篇 PRD 模板。
@@ -39,14 +39,14 @@ Project-specific product planning rules belong in a separate project-local Skill
 13. Verification / Deployment Role Context 只记录长期可复用的重复执行路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id 或 raw payload。
 14. 收尾时做 `Contract Conformance` 和 Context drift check，只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和验证入口；一次性证据、测试日志、截图结果、任务契约和实现摘要不写入 Context。
 
-## 内部执行约束与 Conformance
-
-- `Context Delta` 只能是 `none` 或 `required`。`required` 先把足以指导实现的长期事实写入 owning Context；`none` 直接按现有 Context 工作，不制造 Context 噪音。
-- Agent 内部计划应保持目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标、验收信号和验证入口清晰。触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership 和 long-task state requirement 清晰。
-- 外部来源的每项重要约束都在内部分类为 Context 已覆盖、Context 已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
-- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
-- `Contract Conformance` 直接检查 controlling Context 是否到达正确产品域、surface、API、状态与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新 Context 再重新对齐。
-- small code task、普通 bug fix、局部样式、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
+## 内部执行约束与 Conformance
+
+- `Context Delta` 只能是 `none` 或 `required`。`required` 先把足以指导实现的长期事实写入 owning Context；`none` 直接按现有 Context 工作，不制造 Context 噪音。
+- Agent 内部计划应保持目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标、验收信号和验证入口清晰。触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership 和 long-task state requirement 清晰。
+- 外部来源的每项重要约束都在内部分类为 Context 已覆盖、Context 已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
+- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
+- `Contract Conformance` 直接检查 controlling Context 是否到达正确产品域、surface、API、状态与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新 Context 再重新对齐。
+- small code task、普通 bug fix、局部样式、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
 
 ## 产品体验校准
 

package/assets/skills/context_surface_contract/SKILL.md

@@ -72,7 +72,7 @@ Output:
 - `context.toml` candidate registration with `role = "contract"` when durable registration is needed.
 - `global.md#Context Index` candidate entry when a new Context file is added.
 - Verification candidate for repeatable surface checks.
-- Internal source classification when an external product, architecture, technical or acceptance source changes durable surface responsibility; do not create a Markdown coverage table.
+- Internal source classification when an external product, architecture, technical or acceptance source changes durable surface responsibility; do not create a Markdown coverage table.
 - Repo-local Skill task-block candidate when the user wants project-specific enforcement.
 
 Do not assume business responsibilities from current code shape alone. Ask for confirmation if the candidate would silently choose between competing product or information-architecture meanings.
@@ -106,7 +106,7 @@ Use after implementation or during review.
 Output:
 
 - Surface Contract Conformance.
-- External-source constraint classification and implementation alignment status.
+- External-source constraint classification and implementation alignment status.
 - Remaining Drift.
 - Missing Context.
 - Implementation Drift.
@@ -148,7 +148,7 @@ For any task touching user-facing surfaces, information placement, forms, filter
 - Long Task State Requirement: `<run id, progress, retry, recovery, import, history, or none>`
 - Context Delta: `<none | required>`
 - Verification: `<view-model test / component test / browser smoke / CLI smoke / manual check>`
-```
+```
 
 Do not add this task block to package-managed default Skills as a universal gate. Projects opt in through separate project-local Skills.
 
@@ -164,7 +164,7 @@ When implementation is also requested, align code with the Product Surface Contr
 
 Final handoff should include concise `Surface Contract Conformance`: contract source, implementation alignment, remaining drift and verification status.
 
-Conformance must internally confirm that every important external-source constraint is covered by Context, updated into Context, task-local, explicitly out of scope or awaiting a genuine user decision, and that controlling surface facts reached the correct implementation. Unresolved constraints or non-aligned surface implementation mean the work cannot be described as fully aligned; component, modal, viewmodel or unit evidence alone cannot prove main-surface ownership. Do not create a fixed `plan.md`, Task Contract file or Markdown mapping tables for this check.
+Conformance must internally confirm that every important external-source constraint is covered by Context, updated into Context, task-local, explicitly out of scope or awaiting a genuine user decision, and that controlling surface facts reached the correct implementation. Unresolved constraints or non-aligned surface implementation mean the work cannot be described as fully aligned; component, modal, viewmodel or unit evidence alone cannot prove main-surface ownership. Do not create a fixed `plan.md`, Task Contract file or Markdown mapping tables for this check.
 
 ## Output Boundaries
 
@@ -172,5 +172,5 @@ Conformance must internally confirm that every important external-source constra
 - Do not update Context for ordinary CSS tweaks, copy edits or one-off UI bug fixes unless durable surface responsibility changes.
 - Do not treat current backend fields, enums, JSON, screenshots or terminal output as product intent.
 - Do not invent rationale; rejected alternatives or tradeoffs belong in Context only when they are stable enough to affect future surface decisions.
-- Do not add a surface-specific validator, edit-order gate, plan-contract validator or package-level mandatory Surface Contract gate.
+- Do not add a surface-specific validator, edit-order gate, plan-contract validator or package-level mandatory Surface Contract gate.
 - Do not include business-domain examples in this package-managed Skill.

package/assets/skills/context_uiux_design/SKILL.md

@@ -25,7 +25,7 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
    - 若缺失且本任务改变 durable surface responsibility，输出 `Surface Contract Delta: required`，把界面职责写入 `project_context/**`；视觉 token、颜色、字体、间距、圆角和视觉 rationale 仍写入 `DESIGN.md`。
 5. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件交互框架”检查控件语义、反馈状态、校验、错误预防、可供性和信息密度；这只是通用判断框架，不是固定控件处方。
 6. 界面职责、流程归属和长期交互契约以 `project_context/**` 为准；`DESIGN.md` 负责视觉 token 和视觉 rationale；代码、截图和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码和截图揭示“现在是什么”，代码不能静默重定义 Context。
-7. 设计判断或第一处实现编辑前，先给出唯一长期事实判断 `Context Delta: none|required`。若输入包含产品、架构、技术、界面或验收来源，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
+7. 设计判断或第一处实现编辑前，先给出唯一长期事实判断 `Context Delta: none|required`。若输入包含产品、架构、技术、界面或验收来源，在 agent 内部逐项判断 durable surface / IA / interaction / verification constraint 已被 Context / `DESIGN.md` 覆盖、需要先更新、仅属 task-local、显式 out-of-scope 或需要真实用户决策；不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
 8. 普通 UI bug、局部样式或 CSS 修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期交互或视觉结论，继续对齐或交付前必须回写 Context 或 `DESIGN.md`。不要把 Context 机械补成代码改动摘要。
 9. 如果二者冲突，显式标记为实现漂移、缺失工作或 Context 过期。
 10. 如果涉及已有 UI，优先结合代码入口、运行截图或用户提供的参考图来描述差异。
@@ -40,15 +40,15 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 14. Verification / Deployment Role Context 只记录长期可复用的设计验证、smoke、部署或运行初始化路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id、raw payload 或完整截图报告。
 15. 收尾时做 `Contract Conformance` 和 Context drift check，只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和截图 / 手动检查入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
 
-## 内部执行约束与 Conformance
-
-- `Context Delta` 只能是 `none` 或 `required`。`required` 先更新 owning Context 或 `DESIGN.md`；`none` 按现有事实工作，不制造 Context 噪音。
-- Agent 内部计划应保持页面 / 组件任务、用户判断、主辅信息归属、动作层级、输入语义、loading / empty / no-results / stale / error / degraded / success 状态、布局稳定性、非目标与验收入口清晰。
-- 触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification 清晰；字段、枚举、JSON 和截图仅是实现证据。
-- 外部来源的重要约束在内部分类为 Context / `DESIGN.md` 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
-- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
-- `Contract Conformance` 直接检查 controlling Context / `DESIGN.md` 是否到达正确 surface、状态、交互与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新长期事实再对齐。
-- small code task、普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
+## 内部执行约束与 Conformance
+
+- `Context Delta` 只能是 `none` 或 `required`。`required` 先更新 owning Context 或 `DESIGN.md`；`none` 按现有事实工作，不制造 Context 噪音。
+- Agent 内部计划应保持页面 / 组件任务、用户判断、主辅信息归属、动作层级、输入语义、loading / empty / no-results / stale / error / degraded / success 状态、布局稳定性、非目标与验收入口清晰。
+- 触及 Product Surface 时，同时保持 surface platform、primary user question、main allows/forbids、drilldown ownership、long-task state requirement 和 verification 清晰；字段、枚举、JSON 和截图仅是实现证据。
+- 外部来源的重要约束在内部分类为 Context / `DESIGN.md` 已覆盖、已更新、task-local、显式 out-of-scope 或需要用户决策；存在未处理项时不能声称全量完成。
+- 默认流程不要求或验证固定 `plan.md`、Task Contract 文件、Source-to-Context 表、Context-to-Implementation 表、matrix、verdict 或 evidence ledger；可选 scratch 没有固定名称或权威。
+- `Contract Conformance` 直接检查 controlling Context / `DESIGN.md` 是否到达正确 surface、状态、交互与验证路径并避开 forbidden shortcut。实现偏差修实现；缺少长期事实则返回 `Context Delta: required`，先更新长期事实再对齐。
+- small code task、普通 UI bug、局部 CSS 修复、小重构、测试修复或探索性 spike 不创建额外流程 artifact。
 
 ## 信息呈现校准
 
@@ -72,7 +72,7 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 - 自由输入不是禁用项，但要和错误成本匹配：当格式固定、错误代价高或反馈复杂时，应考虑更明确的约束、选择机制或校验反馈。
 - 不把本框架读成固定控件清单：搜索是否自动触发、时间是否用 picker、预算是否用 stepper，都应由数据规模、API 成本、用户任务、错误成本和项目组件体系决定。
 
-## 视觉质量校准
+## 视觉质量校准
 
 - 先判断界面 register：品牌页、营销页、作品集等让设计承载表达；产品工具、后台、dashboard、表单等让设计服务任务。品牌界面可以更强烈地使用图像、色彩和编排；产品界面优先可扫读、稳定组件、熟悉交互和任务效率。
 - 已有 UI 优先保持身份连续性：先找现有 token、组件库、全局 CSS、Tailwind config、截图或代表性页面；除非用户明确要求重设计，不要推翻已建立的字体、颜色、组件语言。
@@ -80,19 +80,19 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 - 做设计方案或视觉规范时，显式检查：文字对比度、65-75ch 正文行长、清晰字号层级、响应式边界、44px 触控目标、焦点态、hover/active/disabled/loading/error/success 状态、空态/错误态/长文本、reduced motion 和文本不溢出。
 - 避免常见 AI 视觉反模式：嵌套卡片、无意义玻璃拟态、紫蓝渐变或渐变文字、灰字压在彩色背景上、默认米色/奶油色大背景、过度圆角、边框加大模糊阴影的幽灵卡片、每段一个圆角 icon tile、每节重复小号全大写 eyebrow 或 `01 / 02 / 03` 标记、bounce/elastic easing、空泛营销 buzzword。
 - 视觉审查时先分清问题类型：a11y / responsive / theming / interaction / copy / performance / anti-pattern。把真正影响用户理解、操作或品牌信任的问题列为高优先级；少量纯审美偏好不要淹没关键问题。
-- Harness 默认携带 Impeccable CLI 能力；做设计稿、重做设计、视觉设计方案、设计系统方案、frontend redesign、visual polish 或既有 UI 视觉审查时，默认尝试运行 `npx impeccable detect <target>` 作为辅助证据，不必等待用户点名。其输出只能作为设计缺陷线索，不是 Harness gate，也不能替代人工截图检查、项目测试或 `validate-context`。
-
-## Visual Delivery Coverage / 视觉交付覆盖
-
-For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. It is internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
-
-- Select risk-proportional representative combinations across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not expand the full Cartesian product unless Source explicitly requires full combination coverage, and never claim an unchecked combination.
-- Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
-- Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
-- Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
-- Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
-
-## 输出边界
+- Harness 默认携带 Impeccable CLI 能力；做设计稿、重做设计、视觉设计方案、设计系统方案、frontend redesign、visual polish 或既有 UI 视觉审查时，默认尝试运行 `npx impeccable detect <target>` 作为辅助证据，不必等待用户点名。其输出只能作为设计缺陷线索，不是 Harness gate，也不能替代人工截图检查、项目测试或 `validate-context`。
+
+## Visual Delivery Coverage / 视觉交付覆盖
+
+For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. It is internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
+
+- Select risk-proportional representative combinations across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not expand the full Cartesian product unless Source explicitly requires full combination coverage, and never claim an unchecked combination.
+- Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
+- Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
+- Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
+- Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
+
+## 输出边界
 
 - 不默认创建 `.work_products/**`、UI/UX 独立文档、handoff matrix、review/test/release 文档。
 - 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。