project-tiny-context-harness 0.7.5 → 0.7.7

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

@@ -1,29 +1,29 @@
-# Product Surface Contract
-
-## Purpose
-
-This Context records durable responsibilities for user-facing Product Surfaces in this project or product domain.
-
-Write only project-specific facts that should guide future implementation. Do not copy generic platform rules, one-off audit notes, screenshots, test logs, implementation summaries, visual tokens or secrets into this file.
-
-## Surfaces
-
-### `<surface name>`
-
-- Surface:
-- Surface Platform:
-- Owning Product Domain:
-- Primary User Question:
-- Surface Type:
-- Main Surface Allows:
-- Main Surface Forbids:
-- Drilldown Ownership:
-- Long Task State Requirement:
-- Design Rationale:
-- Empty / Loading / Stale / Unavailable:
-- Security / Redaction:
-- Verification:
-
+# Product Surface Contract
+
+## Purpose
+
+This Context records durable responsibilities for user-facing Product Surfaces in this project or product domain.
+
+Write only project-specific facts that should guide future implementation. Do not copy generic platform rules, one-off audit notes, screenshots, test logs, implementation summaries, visual tokens or secrets into this file.
+
+## Surfaces
+
+### `<surface name>`
+
+- Surface:
+- Surface Platform:
+- Owning Product Domain:
+- Primary User Question:
+- Surface Type:
+- Main Surface Allows:
+- Main Surface Forbids:
+- Drilldown Ownership:
+- Long Task State Requirement:
+- Design Rationale:
+- Empty / Loading / Stale / Unavailable:
+- Security / Redaction:
+- Verification:
+
 ## Cross-Surface Rules
 
 - `<durable project-specific rule>`
@@ -33,38 +33,38 @@ Write only project-specific facts that should guide future implementation. Do no
 Keep this file at cross-surface responsibility depth. When one material screen needs durable entry/exit/shared-state, information hierarchy, semantic region order, fixed/scroll/overlay ownership, navigation, variants, material controls or design-target references, create an on-demand Screen Contract from `screen-contract.md` using an existing area/subdomain role (or `contract` only for a true cross-area interface).
 
 Link by stable surface/control/target keys. Do not duplicate the Screen Contract here, copy exact visual tokens from `DESIGN.md`, or embed authored target binaries and test evidence.
-
-## Registration Example
-
-Use the existing `contract` role for cross-surface or cross-area contracts:
-
-```toml
-[[context]]
-path = "project_context/areas/product-surface-contracts.md"
-role = "contract"
-triggers = ["surface", "screen", "ui", "ux", "web", "app", "mobile", "desktop", "game", "cli", "tui", "页面", "界面", "屏幕", "产品接触面", "信息架构", "页面职责", "界面职责", "product surface"]
-read_policy = "on-demand"
-```
-
-If using front matter in a Context Markdown file, use `context_role: contract`; do not use `role = "contract"` in Markdown front matter.
-
-## Maintenance Rules
-
-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.
+
+## Registration Example
+
+Use the existing `contract` role for cross-surface or cross-area contracts:
+
+```toml
+[[context]]
+path = "project_context/areas/product-surface-contracts.md"
+role = "contract"
+triggers = ["surface", "screen", "ui", "ux", "web", "app", "mobile", "desktop", "game", "cli", "tui", "页面", "界面", "屏幕", "产品接触面", "信息架构", "页面职责", "界面职责", "product surface"]
+read_policy = "on-demand"
+```
+
+If using front matter in a Context Markdown file, use `context_role: contract`; do not use `role = "contract"` in Markdown front matter.
+
+## Maintenance Rules
+
+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.
 - Cross-surface ownership changes which Screen Contract owns a detail.
-
-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.
+
+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.

package/assets/context_templates/verification.md

@@ -1,32 +1,32 @@
-# Verification Context: main
-
-This role Context records critical repeat-execution paths for the owning area. Keep it minimal: enough for a future agent to rerun verification without rediscovering setup, not a test report.
-
-## Owner
-
-- Owning area: `main`.
-
-## Verification Paths
-
-- `npm test` or the shortest project-specific test, smoke, CI, probe or validation command.
-- Verification paths are reusable execution instances, not independent definitions of the verification target. For capability, metric or acceptance claims, first use the owning module's design Context to decide what claim should be proven, then choose the command or probe.
-
-## Required Preparation
-
-- List only durable setup such as services, env files, fixtures, local runtimes or external dependencies needed before rerun.
-
-## Expected Signals
-
-- Name the stage, health check, status, artifact shape or observable signal that means the path reached the intended point.
-
-## Acceptable Warnings
-
-- List warnings that are expected and should not trigger repeated investigation.
-
-## Excluded Dead Ends
-
-- List previously ruled-out commands, providers, endpoints or setup paths only when remembering them prevents repeated wasted work.
-
-## Forbidden Content
-
-- Do not record one-off logs, full command output, temporary JSON, CI artifacts, test reports, secrets, tokens, cookies, device ids, raw payloads or pass/fail claims.
+# Verification Context: main
+
+This role Context records critical repeat-execution paths for the owning area. Keep it minimal: enough for a future agent to rerun verification without rediscovering setup, not a test report.
+
+## Owner
+
+- Owning area: `main`.
+
+## Verification Paths
+
+- `npm test` or the shortest project-specific test, smoke, CI, probe or validation command.
+- Verification paths are reusable execution instances, not independent definitions of the verification target. For capability, metric or acceptance claims, first use the owning module's design Context to decide what claim should be proven, then choose the command or probe.
+
+## Required Preparation
+
+- List only durable setup such as services, env files, fixtures, local runtimes or external dependencies needed before rerun.
+
+## Expected Signals
+
+- Name the stage, health check, status, artifact shape or observable signal that means the path reached the intended point.
+
+## Acceptable Warnings
+
+- List warnings that are expected and should not trigger repeated investigation.
+
+## Excluded Dead Ends
+
+- List previously ruled-out commands, providers, endpoints or setup paths only when remembering them prevents repeated wasted work.
+
+## Forbidden Content
+
+- Do not record one-off logs, full command output, temporary JSON, CI artifacts, test reports, secrets, tokens, cookies, device ids, raw payloads or pass/fail claims.

package/assets/github/.gitkeep

@@ -1 +1 @@
-
+

package/assets/github/harness.yml

@@ -1,41 +1,41 @@
-# ty-context:github-workflow:begin
-name: Harness Gates
-
-on:
-  pull_request:
-  push:
-    branches:
-      - main
-  workflow_dispatch:
-    inputs:
-      gate:
-        description: "Make target to run"
-        required: true
-        default: "validate-context"
-        type: choice
-        options:
-          - validate-context
-          - validate-code-modularity
-          - validate-harness
-
-jobs:
-  harness:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
-        with:
-          fetch-depth: 0
-      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
-        with:
-          node-version: "24"
-      - name: Prepare source workspace CLI
-        if: ${{ hashFiles('packages/ty-context/package.json') != '' }}
-        run: |
-          npm ci
-          npm run build --workspace project-tiny-context-harness
-      - name: Run harness gate
-        run: make "${HARNESS_GATE}"
-        env:
-          HARNESS_GATE: ${{ github.event.inputs.gate || 'validate-harness' }}
-          TY_CONTEXT_MODULARITY_BASE: ${{ github.event_name == 'pull_request' && format('origin/{0}', github.base_ref) || github.event.before || '' }}
-# ty-context:github-workflow:end
+# ty-context:github-workflow:begin
+name: Harness Gates
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+  workflow_dispatch:
+    inputs:
+      gate:
+        description: "Make target to run"
+        required: true
+        default: "validate-context"
+        type: choice
+        options:
+          - validate-context
+          - validate-code-modularity
+          - validate-harness
+
+jobs:
+  harness:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
+        with:
+          node-version: "24"
+      - name: Prepare source workspace CLI
+        if: ${{ hashFiles('packages/ty-context/package.json') != '' }}
+        run: |
+          npm ci
+          npm run build --workspace project-tiny-context-harness
+      - name: Run harness gate
+        run: make "${HARNESS_GATE}"
+        env:
+          HARNESS_GATE: ${{ github.event.inputs.gate || 'validate-harness' }}
+          TY_CONTEXT_MODULARITY_BASE: ${{ github.event_name == 'pull_request' && format('origin/{0}', github.base_ref) || github.event.before || '' }}
+# ty-context:github-workflow:end

package/assets/make/.gitkeep

@@ -1 +1 @@
-
+

package/assets/make/ty-context.mk

@@ -1,48 +1,48 @@
-PYTHON ?= python3
-TY_CONTEXT ?= $(if $(wildcard packages/ty-context/dist/cli.js),node packages/ty-context/dist/cli.js,npx --yes --package project-tiny-context-harness@latest ty-context)
-TY_CONTEXT_MODULARITY_SCOPE = $(if $(TY_CONTEXT_MODULARITY_BASE),--base $(TY_CONTEXT_MODULARITY_BASE),--touched)
-
-.PHONY: help ty-context-doctor ty-context-sync ty-context-upgrade ty-context-check-modularity validate-context validate-code-modularity validate-harness lint test-current-domain test-all build
-
-help:
-	@echo "Minimal Context Harness commands"
-	@echo "  make ty-context-doctor         Diagnose Harness root, core package and schema version"
-	@echo "  make ty-context-sync           Refresh managed assets; does not run migrations"
-	@echo "  make ty-context-upgrade        Run safe upgrade migrations, sync managed assets and doctor"
-	@echo "  make ty-context-check-modularity  Warn on oversized touched handwritten source files"
-	@echo "  make validate-context    Check whether project_context/** supports context recovery"
-	@echo "  make validate-code-modularity  Fail on oversized touched handwritten source files"
-	@echo "  make validate-harness    Run validate-context and validate-code-modularity"
-	@echo "  make test-all            Run the project regression suite after replacing this placeholder"
-
-ty-context-doctor:
-	$(TY_CONTEXT) doctor
-
-ty-context-sync:
-	$(TY_CONTEXT) sync
-
-ty-context-upgrade:
-	$(TY_CONTEXT) upgrade
-
-ty-context-check-modularity:
-	$(TY_CONTEXT) check-modularity $(TY_CONTEXT_MODULARITY_SCOPE)
-
-validate-context:
-	$(TY_CONTEXT) validate-context
-
-validate-code-modularity:
-	$(TY_CONTEXT) check-modularity $(TY_CONTEXT_MODULARITY_SCOPE) --fail-on-warning
-
-validate-harness: validate-context validate-code-modularity
-
-lint:
-	@echo "No project lint command configured yet. Replace this target with your stack-specific lint command."
-
-test-current-domain:
-	@echo "No domain test command configured yet. Replace this target with focused tests for the current change."
-
-test-all:
-	@echo "No full test command configured yet. Replace this target with the project regression suite."
-
-build:
-	@echo "No build command configured yet. Replace this target with the project build/package command."
+PYTHON ?= python3
+TY_CONTEXT ?= $(if $(wildcard packages/ty-context/dist/cli.js),node packages/ty-context/dist/cli.js,npx --yes --package project-tiny-context-harness@latest ty-context)
+TY_CONTEXT_MODULARITY_SCOPE = $(if $(TY_CONTEXT_MODULARITY_BASE),--base $(TY_CONTEXT_MODULARITY_BASE),--touched)
+
+.PHONY: help ty-context-doctor ty-context-sync ty-context-upgrade ty-context-check-modularity validate-context validate-code-modularity validate-harness lint test-current-domain test-all build
+
+help:
+	@echo "Minimal Context Harness commands"
+	@echo "  make ty-context-doctor         Diagnose Harness root, core package and schema version"
+	@echo "  make ty-context-sync           Refresh managed assets; does not run migrations"
+	@echo "  make ty-context-upgrade        Run safe upgrade migrations, sync managed assets and doctor"
+	@echo "  make ty-context-check-modularity  Warn on oversized touched handwritten source files"
+	@echo "  make validate-context    Check whether project_context/** supports context recovery"
+	@echo "  make validate-code-modularity  Fail on oversized touched handwritten source files"
+	@echo "  make validate-harness    Run validate-context and validate-code-modularity"
+	@echo "  make test-all            Run the project regression suite after replacing this placeholder"
+
+ty-context-doctor:
+	$(TY_CONTEXT) doctor
+
+ty-context-sync:
+	$(TY_CONTEXT) sync
+
+ty-context-upgrade:
+	$(TY_CONTEXT) upgrade
+
+ty-context-check-modularity:
+	$(TY_CONTEXT) check-modularity $(TY_CONTEXT_MODULARITY_SCOPE)
+
+validate-context:
+	$(TY_CONTEXT) validate-context
+
+validate-code-modularity:
+	$(TY_CONTEXT) check-modularity $(TY_CONTEXT_MODULARITY_SCOPE) --fail-on-warning
+
+validate-harness: validate-context validate-code-modularity
+
+lint:
+	@echo "No project lint command configured yet. Replace this target with your stack-specific lint command."
+
+test-current-domain:
+	@echo "No domain test command configured yet. Replace this target with focused tests for the current change."
+
+test-all:
+	@echo "No full test command configured yet. Replace this target with the project regression suite."
+
+build:
+	@echo "No build command configured yet. Replace this target with the project build/package command."

package/assets/skills/context_development_engineer/SKILL.md

@@ -1,73 +1,73 @@
----
-name: context_development_engineer
-description: Use when the user explicitly asks for 开发工程师, 软件工程师, 研发工程师, 开发专家, 工程专家, 技术专家, 开发方案, 研发方案, 工程方案, 技术方案, 实现, 实现方案, 实施计划, 多开agent, subagent, software engineer, senior engineer, engineering expert, development plan, engineering plan, or technical implementation plan in a Minimal Context Harness project. Do not trigger for routine coding, bug fixes, small refactors, package/release work, or generic mentions of code, development, or engineering.
----
-
-# Context Development Engineer
-
-## Package-Managed Boundary
-
-This generated Skill provides portable engineering judgment. Project-specific rules belong in `<harnessRoot>/skills/development_engineer/SKILL.md`; the repo-local Skill is more specific while durable conclusions still belong in `project_context/**`.
-
-When an active `/long-task-workflow` binding exists, that Skill owns lifecycle, one-workspace, no-proactive-subagent and Final Gate boundaries. This Skill contributes architecture and implementation judgment only; it must not create a second plan, agent scheduler or acceptance path.
-
-## 目标
-
-以开发工程师 / 技术专家视角完成实现判断，保护可维护架构，并把真正长期的工程事实压缩进可恢复的 Minimal Context，而不是增加流程文档。
-
-## 默认工作方式
-
-1. 读取 `project_context/global.md`、`project_context/architecture.md`、`project_context/context.toml`、default area root，并按 triggers/read policy 收集相关 on-demand Context 候选。
-2. 在判断 `Context Delta` 前，用任务中明确的 area/module/API/Schema/state/security/verification/deployment 等少量高信号词，对 `project_context/**` 做一次 bounded text search；把命中的 Context 与 manifest 候选合并，只读取真正相关文件。搜索只补充语义判断，不创建索引、缓存或第二权威。
-3. 确认目标、约束、成功标准、影响域、验证/部署路径和风险。能从代码或 Context 得到的事实不要重复询问。
-4. Context 决定“应该是什么”；代码说明“现在是什么”；测试和运行证据证明行为。冲突是实现漂移、缺失工作或 stale Context，不能由代码静默重定义归属。
-5. 第一处编辑前决定唯一 `Context Delta: none|required`。影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff 时为 `required`，先更新 owning Context。不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
-6. 用 Agent 内部计划保持 goal、non-goals、owner、boundaries、implementation surfaces、risk 和 verification 清晰。默认流程不要求或验证固定 `plan.md`、matrix、verdict 或 evidence ledger。
-7. 普通 bug fix、局部样式/实现漂移、小重构、package/release、测试修复或探索性 spike 不支付架构仪式成本；它们是 small code task，除非过程中形成了新的长期工程事实。
-8. 实现后运行 project-owned verification，做 `Contract Conformance` 和 Context drift check，只报告 `Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。
-
-## 风险触发 Architecture Gate
-
-仅在下列任一情况触发；这是内部判断，不是新 artifact、validator 或 delta：
-
-- 新长期模块/能力/公共抽象；
-- 公共 API、Schema、data contract、持久化或迁移；
-- source of truth、state ownership、runtime lifecycle 或 recovery 改变；
-- 跨 area/domain 修改或新的 dependency direction；
-- security/permission、兼容性、降级、重试、并发或不可逆边界；
-- 一个变化异常扩散到多个不相关模块，或现有扩展点无法承载。
-
-内部保持：
-
-- `Architecture Context Hit`：哪个现有 Context 控制本次架构判断；
-- `Decision Rationale Hit: existing|required|none`：是否存在会改变未来选择的稳定原因；
-- owner 和唯一 source of truth；
-- 正确 dependency direction 与禁止 bypass；
-- interface、input/output、state、persistence 和 lifecycle；
-- failure/retry/timeout/degraded/recovery、compatibility/migration；
-- 应复用的 extension point，或新抽象为何确有净收益；
-- 哪个 project-owned lint/AST/dependency/contract test 能证明边界。
-
-持久结论进入最小 owning Context；实现细节留在代码。不要把“代码更优雅”当作架构要求，也不要让 Harness 变成跨语言通用 dependency analyzer。
-
-## Capability-First Delivery Boundary
-
-对外部来源中的产品/架构/实现/验收约束做内部分类：Context 已覆盖、需要更新、task-local、显式 out-of-scope 或需要真实用户决策。对 delivery / acceptance scope 使用 capability-first delivery boundary，区分：
-
-- `system_capability_build`：形成可复用系统能力；
-- `representative_sample_validation`：仅验证代表性样本；
-- `full_population_operation`：权威范围内全量对象完成；
-- `full_population_not_required`：AC 明确不要求全量。
-
-sample provider / interface / page 证据不能替代 all-provider / all-interface / all-platform 或全量完成。来源要求全量而当前只能交付框架/样本时标记 `scope_conflict_requires_decision`；权威范围未收窄前不得声称完成。
-
+---
+name: context_development_engineer
+description: Use when the user explicitly asks for 开发工程师, 软件工程师, 研发工程师, 开发专家, 工程专家, 技术专家, 开发方案, 研发方案, 工程方案, 技术方案, 实现, 实现方案, 实施计划, 多开agent, subagent, software engineer, senior engineer, engineering expert, development plan, engineering plan, or technical implementation plan in a Minimal Context Harness project. Do not trigger for routine coding, bug fixes, small refactors, package/release work, or generic mentions of code, development, or engineering.
+---
+
+# Context Development Engineer
+
+## Package-Managed Boundary
+
+This generated Skill provides portable engineering judgment. Project-specific rules belong in `<harnessRoot>/skills/development_engineer/SKILL.md`; the repo-local Skill is more specific while durable conclusions still belong in `project_context/**`.
+
+When an active `/long-task-workflow` binding exists, that Skill owns lifecycle, one-workspace, no-proactive-subagent and Final Gate boundaries. This Skill contributes architecture and implementation judgment only; it must not create a second plan, agent scheduler or acceptance path.
+
+## 目标
+
+以开发工程师 / 技术专家视角完成实现判断，保护可维护架构，并把真正长期的工程事实压缩进可恢复的 Minimal Context，而不是增加流程文档。
+
+## 默认工作方式
+
+1. 读取 `project_context/global.md`、`project_context/architecture.md`、`project_context/context.toml`、default area root，并按 triggers/read policy 收集相关 on-demand Context 候选。
+2. 在判断 `Context Delta` 前，用任务中明确的 area/module/API/Schema/state/security/verification/deployment 等少量高信号词，对 `project_context/**` 做一次 bounded text search；把命中的 Context 与 manifest 候选合并，只读取真正相关文件。搜索只补充语义判断，不创建索引、缓存或第二权威。
+3. 确认目标、约束、成功标准、影响域、验证/部署路径和风险。能从代码或 Context 得到的事实不要重复询问。
+4. Context 决定“应该是什么”；代码说明“现在是什么”；测试和运行证据证明行为。冲突是实现漂移、缺失工作或 stale Context，不能由代码静默重定义归属。
+5. 第一处编辑前决定唯一 `Context Delta: none|required`。影响 durable architecture boundary、module ownership、API / Schema / data contract、state / runtime semantics、dependency direction、verification / deployment semantics 或 durable rationale / tradeoff 时为 `required`，先更新 owning Context。不要创建 `plan.md`、Task Contract 文件或 Markdown 映射表。
+6. 用 Agent 内部计划保持 goal、non-goals、owner、boundaries、implementation surfaces、risk 和 verification 清晰。默认流程不要求或验证固定 `plan.md`、matrix、verdict 或 evidence ledger。
+7. 普通 bug fix、局部样式/实现漂移、小重构、package/release、测试修复或探索性 spike 不支付架构仪式成本；它们是 small code task，除非过程中形成了新的长期工程事实。
+8. 实现后运行 project-owned verification，做 `Contract Conformance` 和 Context drift check，只报告 `Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。
+
+## 风险触发 Architecture Gate
+
+仅在下列任一情况触发；这是内部判断，不是新 artifact、validator 或 delta：
+
+- 新长期模块/能力/公共抽象；
+- 公共 API、Schema、data contract、持久化或迁移；
+- source of truth、state ownership、runtime lifecycle 或 recovery 改变；
+- 跨 area/domain 修改或新的 dependency direction；
+- security/permission、兼容性、降级、重试、并发或不可逆边界；
+- 一个变化异常扩散到多个不相关模块，或现有扩展点无法承载。
+
+内部保持：
+
+- `Architecture Context Hit`：哪个现有 Context 控制本次架构判断；
+- `Decision Rationale Hit: existing|required|none`：是否存在会改变未来选择的稳定原因；
+- owner 和唯一 source of truth；
+- 正确 dependency direction 与禁止 bypass；
+- interface、input/output、state、persistence 和 lifecycle；
+- failure/retry/timeout/degraded/recovery、compatibility/migration；
+- 应复用的 extension point，或新抽象为何确有净收益；
+- 哪个 project-owned lint/AST/dependency/contract test 能证明边界。
+
+持久结论进入最小 owning Context；实现细节留在代码。不要把“代码更优雅”当作架构要求，也不要让 Harness 变成跨语言通用 dependency analyzer。
+
+## Capability-First Delivery Boundary
+
+对外部来源中的产品/架构/实现/验收约束做内部分类：Context 已覆盖、需要更新、task-local、显式 out-of-scope 或需要真实用户决策。对 delivery / acceptance scope 使用 capability-first delivery boundary，区分：
+
+- `system_capability_build`：形成可复用系统能力；
+- `representative_sample_validation`：仅验证代表性样本；
+- `full_population_operation`：权威范围内全量对象完成；
+- `full_population_not_required`：AC 明确不要求全量。
+
+sample provider / interface / page 证据不能替代 all-provider / all-interface / all-platform 或全量完成。来源要求全量而当前只能交付框架/样本时标记 `scope_conflict_requires_decision`；权威范围未收窄前不得声称完成。
+
 ## Product Surface
-
-涉及 Web/移动/桌面/游戏 UI、CLI/TUI、表单、配置、输入、选择、搜索、筛选、调度、预算/配额/限流或状态反馈时：
-
+
+涉及 Web/移动/桌面/游戏 UI、CLI/TUI、表单、配置、输入、选择、搜索、筛选、调度、预算/配额/限流或状态反馈时：
+
 - 对照已有 Product Surface / Surface Contract、页面职责和控件任务，而不是只确认字段已暴露；
 - 对 material screen 同时读取 owning Screen/interaction Context（若存在），并用稳定 surface/control/target key 绑定真实 route/component、设计 target 和测试；产品方案只有粗粒度时，把缺失字段路由到 Context update、task-local Source 或 genuine decision，不能在代码里形成唯一隐藏事实源；
-- 内部保持 Surface Contract Hit、main allows/forbids、drilldown ownership、long-task state requirement、implementation drift 和 verification；
+- 内部保持 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、实现满足方式、未满足项和验证入口。
 
@@ -88,25 +88,25 @@ For material production UI, first confirm Design Authority readiness; then carry
 If an active Long-Task applies, express material visual expectations through its existing Requirement, full Control projection, Assertion, Check, Stage, Binding and external-confirmation mechanisms. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Source/registry authority and an adopted protected revision first. Do not introduce a second visual plan, acceptance document or lifecycle.
 
 ## Modularity Check
-
-新实现、重构、重复逻辑、模块边界或影响面控制需要内部记录 `Modularity Check: none|required|exception`。
-
-- 可用 `ty-context check-modularity --file <path> --limit 300` 做计划编辑审计，用 `make validate-code-modularity` 或 `ty-context check-modularity --touched --limit 300 --fail-on-warning` 做交付前硬审计；项目本地 Skill 的 limit 优先。
-- 同时检查物理行数、单函数语句数、分支复杂度、导出数、状态转换和职责；压成一行不能规避。
-- 风险点按 product surface、hook、model、adapter、component、service / facade 或 verification helper 等稳定边界判断，优先复用现有 extension point。
-- 只实施高收益、低风险、语义稳定的抽象；不为一次性代码、不稳定语义或视觉整洁做抽象。
-- `exception` 必须由 `<harnessRoot>/config.yaml` 中 lifecycle-complete waiver 授权，至少包含收窄的 `path`/`category`、`owner`、`introduced_at`、`reason`、`tracking_issue`、`expiry_condition`。交付说明不是机器豁免，已有债务不得继续接收新职责。
-
-## 自动化机会
-
-人工流程重复、确定、易漏步骤或顺序影响正确性时，评估 repo-local tool/script。脚本放在 owning module 的工具目录并有测试；可恢复入口、参数约束和适用边界写入 verification/deployment Context。不要把模块命令、provider id、artifact 路径或一次性结果写进本 Skill。
-
-## Context 写入边界
-
-- area/domain/subdomain：产品或包责任；contract：API/schema/event/workflow/interface；foundation：稳定概念；verification/deployment：可重复路径；implementation-index：导航；decision-rationale：会影响未来选择的稳定原因。
-- 模块 Context 只保留 principles、design logic、rejected alternative/tradeoff 和长期约束；不编造 rationale，不复制实现摘要、命令输出、debug 过程、截图、日志、临时 JSON、raw payload、测试报告或 secrets。
-- `Context Delta: none|required` 是唯一长期事实结果；`Architecture Context Hit`、`Decision Rationale Hit` 与 `Modularity Check` 仍只是内部路由问题。
-
-## 输出边界
-
-不默认创建 `.work_products/**`、tech plan、ADR、implementation doc、review/test/release 文档或 lifecycle phases。用户明确要求独立开发/技术方案时可以临时生成；稳定结论仍提炼回 `project_context/**`。
+
+新实现、重构、重复逻辑、模块边界或影响面控制需要内部记录 `Modularity Check: none|required|exception`。
+
+- 可用 `ty-context check-modularity --file <path> --limit 300` 做计划编辑审计，用 `make validate-code-modularity` 或 `ty-context check-modularity --touched --limit 300 --fail-on-warning` 做交付前硬审计；项目本地 Skill 的 limit 优先。
+- 同时检查物理行数、单函数语句数、分支复杂度、导出数、状态转换和职责；压成一行不能规避。
+- 风险点按 product surface、hook、model、adapter、component、service / facade 或 verification helper 等稳定边界判断，优先复用现有 extension point。
+- 只实施高收益、低风险、语义稳定的抽象；不为一次性代码、不稳定语义或视觉整洁做抽象。
+- `exception` 必须由 `<harnessRoot>/config.yaml` 中 lifecycle-complete waiver 授权，至少包含收窄的 `path`/`category`、`owner`、`introduced_at`、`reason`、`tracking_issue`、`expiry_condition`。交付说明不是机器豁免，已有债务不得继续接收新职责。
+
+## 自动化机会
+
+人工流程重复、确定、易漏步骤或顺序影响正确性时，评估 repo-local tool/script。脚本放在 owning module 的工具目录并有测试；可恢复入口、参数约束和适用边界写入 verification/deployment Context。不要把模块命令、provider id、artifact 路径或一次性结果写进本 Skill。
+
+## Context 写入边界
+
+- area/domain/subdomain：产品或包责任；contract：API/schema/event/workflow/interface；foundation：稳定概念；verification/deployment：可重复路径；implementation-index：导航；decision-rationale：会影响未来选择的稳定原因。
+- 模块 Context 只保留 principles、design logic、rejected alternative/tradeoff 和长期约束；不编造 rationale，不复制实现摘要、命令输出、debug 过程、截图、日志、临时 JSON、raw payload、测试报告或 secrets。
+- `Context Delta: none|required` 是唯一长期事实结果；`Architecture Context Hit`、`Decision Rationale Hit` 与 `Modularity Check` 仍只是内部路由问题。
+
+## 输出边界
+
+不默认创建 `.work_products/**`、tech plan、ADR、implementation doc、review/test/release 文档或 lifecycle phases。用户明确要求独立开发/技术方案时可以临时生成；稳定结论仍提炼回 `project_context/**`。