project-tiny-context-harness 0.2.39

package/assets/agents/AGENTS_CORE.md

@@ -0,0 +1,58 @@
+# Minimal Context Harness Protocol
+
+本项目使用 Minimal Context Harness。Harness 只维护上下文质量，不替项目证明产品质量。
+
+## AGENTS.md 定位
+
+- `AGENTS.md` 是 agent 启动路由器和硬边界，只放事实源入口、不可违反规则、关键触发器和最短验证入口。
+- 长设计理由默认压缩进 `project_context/**`；若项目已有明确的本地 spec / design 文档，可按项目约定使用。角色流程 / checklist 放 Skills，人类使用说明放 README；新增 AGENTS 规则前优先压缩或替换旧规则，不默认追加。
+- 建议把 AGENTS 主路径保持在约 40-70 行；这是软预算，不是 validator 或 CI gate。
+
+## Context 优先级阶梯
+
+1. 先读 `project_context/global.md`、`project_context/architecture.md` 和 `project_context/context.toml`，再按 graph 读取相关 area / context unit。
+2. 若任务涉及 Web 页面、前端布局、UI/UX、产品模块边界或信息放置，先做页面产品定位检查，再完成变更分类；若 UI 改动涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态，按产品/UIUX Skill 的控件任务框架做轻量检查。
+3. 若任务新增、迁移或整理 Context 文件，先做 role placement scan：area 只代表产品域归属；contract / foundation / subdomain / verification / deployment / implementation-index / decision-rationale 等按读取目的拆成 role Context。
+4. 对产品方案、UI/UX、系统设计、架构边界、API / Schema、状态或运行语义、验证设计等任务，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 声明是否改变长期事实，再写本次 Task Contract。
+5. `Context Delta: required` 则 context-first；普通 bug fix、局部样式、局部漂移修复、测试修复或 spike 默认 code-first，但一旦产生长期结论必须回写 Context。
+6. 收尾做 Contract Conformance 和 Context drift check，只报告 `Context: 已更新 ...` 或 `Context: 本次无长期事实变化`；不要把一次性证据、任务契约或实现摘要写入 Context。
+
+## 事实源
+
+- 项目全局上下文：`project_context/global.md`
+- 架构上下文：`project_context/architecture.md`（克制、最小，只记录系统边界、组件关系和长期约束）
+- Context 图谱：`project_context/context.toml`（Schema v4 默认事实源；声明产品域 area/context_unit、role、触发条件和按需读取策略）
+- 产品域 / context unit 上下文：`project_context/areas/**/*.md`
+- 产品质量事实：项目自己的代码、测试、smoke、CI、hidden probe 或人工验收
+
+## 工作规则
+
+1. 新会话或继续工作时，先读取 `project_context/global.md`、`project_context/architecture.md` 和 `project_context/context.toml`；按其中 default area 和触发条件读取相关 context。
+2. 第一处代码编辑前先做轻量变更分类，不按固定时长计时。若任务涉及 Web 页面、前端布局、UI/UX、产品模块边界或信息应该放在哪个页面 / 模块，先做页面产品定位检查，再完成变更分类：用户在这个页面要完成什么判断，产品必须提供哪些信息 / 动作 / 反馈，哪些信息不应常驻，哪些属于下游消费层 / 运维层 / 详情层 / 其他页面，当前布局和信息密度是否匹配页面任务。若 UI 改动涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态，按产品/UIUX Skill 的控件任务框架做轻量检查，识别既有 Context 是否适用以及是否缺少长期页面/控件契约。多页面或多模块归属不清时，先审查全站或相关页面的信息架构，再收窄到代码模块实现。该检查是判断是否需要 context-first 的输入，不等于必须更新 Context，也不要求独立文档或新的 gate。
+3. 对产品方案、UI/UX、系统设计、架构边界、API / Schema、状态机或运行语义、验证设计等任务，第一处代码编辑前先编译当前任务契约：用 `Context Delta: none|required` 作为唯一正式长期事实判断点，再写本次 Task Contract（目标、边界、状态、反馈、非目标和验收信号）。普通 bug fix、局部样式、小重构、局部漂移修复、测试修复或 spike 不强制编译任务契约。
+4. 当新增、迁移或整理 `project_context/areas/**` 时，做 role placement scan（软约束，不做 gate）：`area` / `domain` 保留产品域归属，`subdomain` 用于产品域内较小 ownership，`contract` 用于 API / schema / event / 跨域接口语义，`foundation` 用于稳定理论 / 词汇 / 背景材料，`verification` / `deployment` 用于可复用执行路径，`implementation-index` 只做代码导航索引，`decision-rationale` 记录稳定设计原因，`archive` 用于非默认读取的历史或外部材料。
+5. 若任务契约声明 `Context Delta: required`，默认走 context-first：第一处代码编辑前先更新相关 `project_context/**`，写入必要且足以指导实现的长期结论，再按 Context 和 Task Contract 对齐实现、验证和收尾。
+6. 普通 bug fix、局部样式、局部实现漂移修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期结论，继续对齐或交付前必须回写 `project_context/**`。
+7. `project_context/**` 是项目意图、产品域职责、架构边界、集成方向、允许/禁止依赖、验证关键路径和部署关键路径的权威事实源；代码是当前实现状态的权威事实源。
+8. 当代码形态、搜索结果或相邻实现与 Context 声明冲突时，把差异视为实现漂移、缺失工作或 Context 过期并显式说明；不要用当前代码形态或关键词搜索结果覆盖 Context 已声明的职责、归属或集成意图。
+9. 每个有意义的方案或实现变更收尾时做 Contract Conformance 和 Context drift check：对照 Task Contract 区分实现偏差、契约遗漏或长期事实缺失；实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context。交付说明只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`；Conformance 证据属于本次交付，不写入 `project_context/**`。
+10. 长期事实只写入 `project_context/**`；不要默认创建 PRD、tech plan、ADR、implementation doc、review/test/release 文档。
+11. 用户明确要求“产品方案 / 产品经理 / 产品专家”、“设计稿 / UI/UX 设计方案 / 视觉专家”或“开发工程师 / 技术方案 / 开发方案 / 实现 / 实现方案 / 实施计划 / 技术专家 / 多开agent / subagent”这类角色或强产物名时，使用对应 Context authoring Skill，把长期结论写回 `project_context/**`。
+12. 用户明确要求“导出尽可能详细的项目全量上下文 / 全量上下文导出 / full project context export / 当前项目代码实现 / 代码级实现导出”时，使用 `context_full_project_export` Skill；默认优先运行 `sdlc-harness export-context --all` 同时生成项目级 Context 汇总和代码级实现快照；只需要单份产物时再用 `--full` 或 `--code`；导出产物只放 `tmp/sdlc/context-exports/**`，不得放入或注册到 `project_context/**` / `project_context/context.toml`。
+13. 当任务涉及设计稿、重做设计、视觉方案、设计系统、visual polish、frontend redesign 或 frontend styling，且存在可扫描的 UI 代码、页面文件、构建产物目录或本地/远程 URL 时，默认运行 `npx impeccable detect <target>` 做 Impeccable 视觉审查；没有可扫描目标、命令不可用或扫描失败时，说明原因并继续。Impeccable 不是 `validate-context` gate，也不替代截图检查、项目测试或人工判断。
+14. SDLC / Harness managed surfaces 是生成资产：`AGENTS.md` managed block、`.agent/pjsdlc_managed/**`、`.agent/skills/context_product_plan/**`、`.agent/skills/context_uiux_design/**`、`.agent/skills/context_development_engineer/**` 和 `.agent/skills/context_full_project_export/**` 禁止承载项目特定规则；直接编辑会在 `sync` 时被覆盖或产生漂移。项目本地产品 / UIUX / 开发规则必须新建独立 Skill，例如 `.agent/skills/product_plan/SKILL.md`、`.agent/skills/uiux_design/SKILL.md` 或 `.agent/skills/development_engineer/SKILL.md`；当项目本地 Skill 与默认 Skill 同时适用时，优先使用更具体的项目本地 Skill。项目本地 Skill 的 front matter `description` 触发词应与本文件中的角色触发规则和对应默认 `context_*` Skill 保持一致；新增或收窄关键词时，同步更新本地 Skill 描述和项目级 agent 指引，避免 Skill 触发条件与 SDLC 工作规则漂移。
+15. ADR 降级为 Context 中的 `Design Rationale`；实现说明优先写成代码注释、测试名或模块 Context 中的关键约束。
+16. Harness workflow gate 只运行 `validate-context`，用于检查上下文是否可恢复；不检查 context/code 修改顺序。自动化最多提示 context-first 风险，不做阻断。
+17. 产品质量由项目自己的验证入口证明；Context 只能声明验证 / 部署关键路径，不能伪造“测试已通过”或“部署已成功”。
+18. Verification / Deployment Role Context 规则：area 是产品域归属；`verification` 和 `deployment` 是 area-owned 的按需读取角色，用来提高关键测试、smoke、CI、部署、云端初始化或运行拓扑路径的重复执行效率。Context 不记录一次性测试日志、完整命令输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id 或 raw payload；只记录特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。跨产品域路径可放 project-level role Context，普通产品域路径放 owning area 下的 role Context。
+19. `sync` 只刷新 managed guidance、默认 Skill 和工具；不会合并 Skill override，也不会覆盖用户新建的独立项目本地 Skill。
+20. 普通项目默认只有一个 `main` area 和一个 `areas/main/verification.md`；monorepo 或 product-family 项目可在 `context.toml` 中增加多个产品域 `area` / `context_unit`，并用 `context_role` 或 manifest role 区分 `area`、`subdomain`、`contract`、`foundation`、`verification`、`deployment`、`archive`、`implementation-index` 和 `decision-rationale` 等不同 Context 类型。
+
+## 常用命令
+
+- `make validate-context`：检查 `project_context/**` 是否足够支持 agent 恢复上下文。
+- `make sdlc-sync`：刷新 managed guidance、Context template、默认 Skill 和工具。
+- `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --all`：同时导出临时项目级 Context 汇总和代码级实现 Markdown 到 `tmp/sdlc/context-exports/**`。
+- `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --full`：导出临时项目级 Context 汇总 Markdown 到 `tmp/sdlc/context-exports/**`。
+- `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --code`：导出临时代码级实现 Markdown 到 `tmp/sdlc/context-exports/**`。
+- `npx --yes --package project-tiny-context-harness@latest sdlc-harness doctor`：临时诊断 canonical SDLC CLI；避免裸 `npx sdlc-harness` 解析到旧包名或旧本地缓存。

package/assets/context_templates/architecture.md

@@ -0,0 +1,31 @@
+# Architecture Context
+
+This is the restrained architecture context. Keep only facts that help a fresh agent recover system shape, boundaries and durable constraints quickly.
+
+## System Boundary
+
+- Describe what is inside this project and what external systems, providers or runtime assumptions sit outside it.
+
+## Component Map
+
+- List the smallest useful set of components, areas or context units and how they relate.
+
+## Data / Control Flow
+
+- Summarize only the durable request, event, state or data flow that is hard to infer from code alone.
+
+## Design Rationale
+
+- Record architecture-level choices that still constrain future work; architecture boundary changes should be captured here before implementation alignment.
+
+## Constraints And Tradeoffs
+
+- Capture performance, safety, integration, deployment or maintainability constraints that matter for future changes.
+
+## Verification Implications
+
+- List project-specific verification entry points affected by architectural changes; do not claim tests already passed.
+
+## Open Risks
+
+- List unresolved architectural risks or unknowns.

package/assets/context_templates/area.md

@@ -0,0 +1,31 @@
+# Area Context: main
+
+## Responsibility
+
+- Describe this product/domain area or context unit's responsibility.
+
+## User / System Contract
+
+- Describe the external behavior, API, CLI, UI, screen state, interaction or data contract. Contract changes should be captured here before implementation alignment.
+- For UI/page areas, name the page responsibility, core user judgment, persistent information/actions/feedback, non-persistent information, and what belongs in downstream consumption, ops, detail or other surfaces when those facts are durable.
+
+## Core Data / API / State
+
+- Summarize important data structures, APIs, state transitions or rules.
+
+## Key Constraints
+
+- List constraints that are not obvious from code alone, including product rules, responsive/a11y needs or visual boundaries.
+
+## Code Entry Points
+
+- `src/` or the concrete file/function entry points.
+
+## Related Role Context
+
+- Verification paths live in this area's `verification` role Context, such as `project_context/areas/main/verification.md`.
+- Deployment/runtime/bootstrap paths live in this area's optional `deployment` role Context when those facts exist.
+
+## Open Risks
+
+- List unresolved risks or blockers.

package/assets/context_templates/context.toml

@@ -0,0 +1,27 @@
+# Schema v4 Minimal Context graph manifest.
+# Keep the default product/domain area for ordinary projects. Role context nodes
+# are read-purpose slices owned by an area or, only when cross-domain, by the project root.
+# When migrating deep files under project_context/areas/**, refine obvious
+# contract/foundation/subdomain/verification/deployment/implementation-index/
+# decision-rationale/archive files into [[context]] entries instead of keeping
+# every Markdown file as an [[areas]] product owner.
+
+[[areas]]
+id = "main"
+root = "."
+context = "project_context/areas/main.md"
+kind = "app"
+default = true
+
+[[context]]
+path = "project_context/areas/main/verification.md"
+role = "verification"
+read_policy = "default"
+triggers = ["test", "verify", "verification", "smoke", "ci"]
+
+# Example optional node:
+# [[context]]
+# path = "project_context/areas/main/deployment.md"
+# role = "deployment"
+# read_policy = "on-demand"
+# triggers = ["deploy", "deployment", "runtime", "cloud", "docker"]

package/assets/context_templates/deployment.md

@@ -0,0 +1,35 @@
+# Deployment Context: main
+
+This optional role Context records critical repeat-execution paths for deploy, runtime bootstrap, cloud initialization and operational recovery. Keep it minimal and durable.
+
+## Owner
+
+- Owning area: `main`.
+
+## Runtime Topology
+
+- List durable service distribution only when it matters for rerunning deploy or bootstrap, such as Web/API/worker/Redis/DB/Docker/cloud instance boundaries.
+
+## Deployment Paths
+
+- List the shortest deploy, CI/CD, bootstrap, migration, health-check or rollback/degradation command/path.
+
+## Required Preparation
+
+- List only durable setup such as cloud resources, env files, compose profiles, secret mounting names or database initialization steps. Do not store secret values.
+
+## Expected Signals
+
+- Name health checks, status transitions, URLs, queues, containers or logs-at-a-glance that show the path reached the intended stage.
+
+## Acceptable Warnings
+
+- List known benign warnings or slow-start states.
+
+## Excluded Dead Ends
+
+- List previously ruled-out deploy/bootstrap paths only when remembering them prevents repeated wasted work.
+
+## Forbidden Content
+
+- Do not record one-off logs, full command output, CI artifacts, release ledgers, secrets, tokens, cookies, device ids, raw payloads or claims that deployment already succeeded.

package/assets/context_templates/global.md

@@ -0,0 +1,53 @@
+# Project / Delivery Context
+
+## Project Goal
+
+- Describe the user-visible goal this project is trying to achieve.
+
+## Non-goals / Boundaries
+
+- List what this project intentionally does not do.
+
+## Background
+
+- Capture the minimum background a fresh agent needs before changing code.
+
+## Design Rationale
+
+- Record durable choices that are hard to infer from code or tests. Classify changes before implementation; if a change alters product ownership/plans, module responsibilities, information architecture, API/Schema, state/scheduler semantics, cross-area boundaries, verification role paths or deployment role paths, update Context before code with enough durable context to guide implementation.
+
+## Architecture Context
+
+- Link to `project_context/architecture.md`; keep architecture notes minimal and focused on boundaries, components and constraints that are not obvious from code.
+
+## Context Graph
+
+- Link to `project_context/context.toml` and keep its default area, role, trigger, read policy and boundary metadata aligned with this Context.
+- When adding or reorganizing files under `project_context/areas/**`, run a soft role placement scan before registering every Markdown file as an area: product ownership stays in `area` / `domain` / `subdomain`; contracts, foundations, verification, deployment, implementation indexes, decision rationale and archives should use role Context when that better fits the reading purpose.
+
+## Product / Delivery Brief
+
+- Capture durable product goals, users, core flows, acceptance signals and non-goals.
+
+## UX / Screen Brief
+
+- Capture durable screen, flow, interaction, responsive and accessibility facts. Use `DESIGN.md` for visual identity and design tokens when needed.
+- For web/front-end surfaces, record durable page responsibilities, core user judgments, persistent information boundaries and cross-page or cross-layer ownership when they guide future changes.
+
+## Verification Entry Points
+
+- Point to the default verification context for repeatable test, smoke, CI or validation paths.
+- Project-level cross-domain verification may live here only as a short index; execution details belong in `verification` role Context.
+
+## Current State
+
+- Summarize what is implemented, blocked or risky right now.
+
+## Next Safe Action
+
+- State the safest next step for a fresh agent, including whether the next change should update Context before code.
+
+## Context Index
+
+- [main](areas/main.md)
+- [main verification](areas/main/verification.md)

package/assets/context_templates/verification.md

@@ -0,0 +1,31 @@
+# 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.
+
+## 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

@@ -0,0 +1 @@
+

package/assets/github/harness.yml

@@ -0,0 +1,37 @@
+# pjsdlc:sdlc-harness: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-harness
+
+jobs:
+  harness:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "24"
+      - name: Prepare source workspace CLI
+        if: ${{ hashFiles('packages/sdlc-harness/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-context' }}
+# pjsdlc:sdlc-harness:github-workflow:end

package/assets/make/.gitkeep

@@ -0,0 +1 @@
+

package/assets/make/sdlc-harness.mk

@@ -0,0 +1,39 @@
+PYTHON ?= python3
+SDLC_HARNESS ?= $(if $(wildcard packages/sdlc-harness/dist/cli.js),node packages/sdlc-harness/dist/cli.js,npx --yes --package project-tiny-context-harness@latest sdlc-harness)
+
+.PHONY: help sdlc-doctor sdlc-sync sdlc-upgrade validate-context validate-harness lint test-current-domain test-all build
+
+help:
+	@echo "Minimal Context Harness commands"
+	@echo "  make sdlc-doctor         Diagnose Harness root, core package and schema version"
+	@echo "  make sdlc-sync           Refresh managed guidance, Context templates, default Skills and tools"
+	@echo "  make sdlc-upgrade        Run safe upgrade migrations and refresh managed assets"
+	@echo "  make validate-context    Check whether project_context/** supports context recovery"
+	@echo "  make validate-harness    Compatibility alias for validate-context"
+	@echo "  make test-all            Run the project regression suite after replacing this placeholder"
+
+sdlc-doctor:
+	$(SDLC_HARNESS) doctor
+
+sdlc-sync:
+	$(SDLC_HARNESS) sync
+
+sdlc-upgrade:
+	$(SDLC_HARNESS) upgrade
+
+validate-context:
+	$(SDLC_HARNESS) validate-context
+
+validate-harness: validate-context
+
+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

@@ -0,0 +1,86 @@
+---
+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 Skill is generated by `sdlc-harness sync` and owned by the Harness package. Do not edit the generated `context_development_engineer` Skill directly.
+
+Project-specific engineering rules belong in a separate project-local Skill under `<harnessRoot>/skills/development_engineer/SKILL.md`. When a project-local Skill and this package-managed Skill both apply, use the more specific project-local Skill as the primary instruction source while keeping durable conclusions in `project_context/**`. Keep the project-local Skill front matter `description` trigger keywords aligned with this package-managed Skill and the project `AGENTS.md` role-trigger rule; if the project adds or narrows trigger terms, update both places together so agent activation and SDLC guidance do not drift apart.
+
+## 目标
+
+帮助 agent 以开发工程师 / 技术专家视角完成实现判断，并把长期工程事实压缩进可恢复的 Minimal Context。
+
+## 工作方式
+
+1. 先读取 `project_context/global.md`、`project_context/architecture.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
+2. 先确认用户目标、约束、成功标准、影响产品域、现有验证 / 部署关键路径和风险；能从代码或 Context 发现的事实不要反复询问用户。
+3. `project_context/**` 决定“应该是什么”：模块职责、归属、架构边界、接口方向、契约语义和禁止依赖；代码决定“现在实现到了哪里”。代码不能静默重定义 Context。
+4. 第一处代码编辑前，若任务涉及系统设计、技术方案、架构边界、产品域职责、跨域依赖、API / Schema、数据契约、状态机或运行语义、验证关键路径或部署关键路径，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`。
+5. 普通 bug fix、局部样式、局部实现漂移修复、测试修复或探索性 spike 不更新 Context，可先改代码；一旦形成长期工程结论，继续对齐或交付前必须回写 Context。不要把 Context 机械补成代码改动摘要。
+6. 如果代码、搜索结果或相邻实现与 Context 冲突，显式标记为实现漂移、缺失工作或 Context 过期，不要用当前代码形态反推模块归属。
+7. 涉及已有 Context 的实现判断，先做轻量对齐：
+   - Context expectation
+   - Current code evidence
+   - Gap
+   - Proposed change
+8. 涉及 UI surface、表单/配置、输入、选择、搜索、筛选、调度/时间、预算/配额/限流或状态反馈的实现方案时，检查当前代码是否只是暴露字段，还是满足了已有 Context、页面职责和控件任务框架；实现收尾要能给出简短 Context Conformance 证据。
+9. 实现时保持精准修改，优先遵循仓库现有框架、接口、测试和代码风格。
+10. 当用户明确要求 / 允许“多开agent”或使用 subagent，且当前会话存在可用 subagent 工具时，积极把可并行的探索、审查或实现拆分交给 subagent；使用前先复用已有相关 agent，没有合适 agent 或并行度不足时再新开。`wait_agent` 只表示取得结果，不释放资源；subagent 完成、空闲或不再需要时必须调用 `close_agent`，收尾前清理已完成 / 空闲 / 不再需要的 subagent，避免占满后续资源。
+11. 当任务涉及新实现、重构、重复逻辑、模块边界或影响面控制时，先做轻量 abstraction / decomposition scan：
+   - 查找相似实现、重复逻辑、紧耦合模块或影响面异常扩散点。
+   - 将候选项分为局部重构与长期边界变化，后者按既有 Context-first 规则处理。
+   - 对候选点说明当前重复 / 耦合证据、抽象后的边界、收益、风险和是否值得现在做。
+   - 默认只实施高收益、低风险、语义稳定的候选项。
+   - 不为一次性代码、不稳定语义或纯粹好看的架构做抽象。
+12. 需要沉淀长期事实时，只更新 `project_context/**`：
+   - 全局工程取舍、跨产品域索引或当前状态写入 `global.md`。
+   - 产品域 API、数据契约、关键约束、入口和风险写入对应 area / subdomain Context。
+   - 跨域接口语义写入 `context_role: contract` 或 manifest role 为 `contract` 的 Context；关键重复验证路径写入 `verification`；关键部署、运行拓扑或云端初始化路径写入 `deployment`；代码入口索引用 `implementation-index`；底层理论源用 `foundation`；历史归档索引用 `archive`。
+   - 新 context unit 可新增 `project_context/areas/<unit>.md`，并更新 `global.md#Context Index`；复杂项目同时更新 `project_context/context.toml`。
+   - 如果 `upgrade` 自动把深层 `.md` 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。
+13. 实现收尾时做 `Contract Conformance` 和 Context drift check：确认代码没有引入未沉淀的长期事实，且 Context 没有退化成普通实现摘要；交付说明只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和验证入口；一次性证据、截图结果、测试日志、任务契约和实现摘要不写入 Context。
+14. Context 只能声明验证 / 部署关键路径或验收信号，不能伪造“测试已通过”或“部署已成功”。
+15. Verification / Deployment Role Context 只记录长期可复用的重复执行路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id 或 raw payload。
+
+## UI 实现对齐
+
+- UI 实现方案不只检查字段是否接上，还要检查控件是否支持用户任务、输入语义、反馈状态、错误恢复和已有页面/控件契约。
+- 当 current code evidence 显示后端字段、枚举或自由输入直接暴露给用户时，不默认把它当作产品意图；先对照 Context、产品/UIUX Skill 的控件任务框架和项目组件体系判断是否是实现漂移或缺失契约。
+- Contract Conformance 证据应短而具体：命中的已有 Context / 页面契约或 Task Contract、实现如何满足、未满足或延期项、验证入口或手动检查。它属于交付说明，不属于 `project_context/**`。
+
+## 任务契约编译
+
+- 任务契约是当前工程任务的编译产物，不是事实源、tech plan、ADR、implementation doc 或长期 Context；默认留在方案、交付说明或 PR 文本中。
+- `Context Delta` 必须先出现，取值为 `none` 或 `required`：
+  - `none`：本次只是按既有 Context / 架构原则落地，不新增长期事实。
+  - `required`：说明长期事实类型、应写入的 Context / role、需要沉淀的事实，以及明确不写入 Context 的一次性内容。
+- `Task Contract` 用短列表说明 capability、owner、upstream / downstream、allowed / forbidden dependency、input / output / state / persistence、failure / retry / timeout / degraded / recovery、observability、performance、security、non-goals 和 verification path。
+- 对长任务、多模块、多 agent、容易发生 `Context Delta` 调头或多轮验证的任务，可以用 `plan.md` 或等价临时计划面暂存 `Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
+- `plan.md` 中出现的长期工程事实必须提炼回 `project_context/**`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
+- `Context Delta: required` 时先更新 `project_context/**`，再继续实现；`none` 时直接按 Task Contract 实现。
+- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context。
+- 不为普通代码修改、bug fix、小重构、package/release 处理、测试修复或探索性 spike 强制编译任务契约。
+
+## 输出边界
+
+- 不默认创建 `.work_products/**`、tech plan、ADR、implementation doc、review/test/release 文档。
+- 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
+- 如果用户明确要求独立开发方案、技术方案或实现说明，可以临时生成；长期事实仍要提炼回 `project_context/**`。
+- 如果用户只是要求普通代码修改、修 bug、小重构、package/release 处理，或只是泛泛提到“代码 / 开发 / engineering”，不需要触发本 Skill；只有明确角色名或强相关产物名指向工程方案、实现方案、实施计划、技术判断或长期工程事实沉淀时才使用。
+
+## 建议沉淀位置
+
+- `global.md#Design Rationale`：跨模块工程取舍。
+- `global.md#Current State`：影响后续恢复的实现状态。
+- `areas/*.md#User / System Contract`：模块可见行为、API、CLI、UI 或数据契约。
+- `areas/*.md#Core Data / API / State`：关键数据结构、接口、状态流或规则。
+- `areas/*.md#Key Constraints`：性能、安全、兼容、集成或维护约束。
+- `areas/*.md#Code Entry Points`：未来 agent 需要快速定位的代码入口。
+- `areas/*/verification.md` 或 role=`verification` Context：关键测试、smoke、CI、probe 或验证重复执行路径。
+- `areas/*/deployment.md` 或 role=`deployment` Context：关键部署、云端初始化、运行拓扑、健康检查或回滚重复执行路径。
+- `project_context/context.toml`：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。

package/assets/skills/context_full_project_export/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: context_full_project_export
+description: Use when the user explicitly asks to 导出尽可能详细的项目全量上下文, 全量上下文导出, 项目上下文全量导出, full project context export, export full project context, project context export, 当前项目代码实现, 代码级实现导出, or code-level implementation export in a Minimal Context Harness project.
+---
+
+# Context Full Project Export
+
+## Package-Managed Boundary
+
+This Skill is generated by `sdlc-harness sync` and owned by the Harness package. Do not edit the generated `context_full_project_export` Skill directly.
+
+This Skill creates a temporary export artifact only. It does not author durable Context and does not change `project_context/context.toml`.
+
+## Purpose
+
+When the user needs a full project context export, create a temporary Markdown bundle that collects project Context, key agent guidance, architecture/module facts and useful entry points 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 package CLI to generate both temporary artifacts in one command. Do not hand-write tracked export documents:
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --all`
+2. Use `--full` when only the project Context bundle is needed:
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --full`
+3. Use `--code` when only the code-level implementation snapshot is needed. It generates one Markdown file by default:
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --code`
+4. Custom output paths are allowed only for single-artifact modes and must stay under the temporary export directory. `--all` does not accept `--output`:
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --full --output tmp/sdlc/context-exports/my-export.md`
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --code --output tmp/sdlc/context-exports/my-code-export.md`
+5. Use dry-run mode to inspect planned sources before writing:
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --all --check`
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --full --check`
+   - `npx --yes --package project-tiny-context-harness@latest sdlc-harness export-context --code --check`
+6. After exporting, report artifact paths, source counts and warnings to the user. Do not summarize export contents back into Context.
+
+## Output Boundaries
+
+- Export artifacts must remain temporary export artifacts, not Context.
+- `--full` defaults to `tmp/sdlc/context-exports/full-project-context-<timestamp>.md`.
+- `--code` defaults to `tmp/sdlc/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/sdlc/context-exports/**`.
+- Export contents may include redaction warnings; do not bypass secret/token/cookie/password/api_key filtering.
+
+## Handoff
+
+- Report `Export: generated <path>` or `Export: check completed; no files written`.
+- If the CLI rejects an output path, explain that this prevents temporary exports from polluting durable fact sources and suggest `tmp/sdlc/context-exports/<name>.md`.
+- Context drift check should be `Context: no durable project facts changed` unless the task also changes Harness rules.

package/assets/skills/context_product_plan/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: context_product_plan
+description: Use when the user explicitly asks for 产品方案, 产品经理, 产品专家, 需求方案, 功能方案, 业务规则方案, 用户故事方案, 验收标准方案, 产品规划方案, product plan, product manager, product expert, product spec, or PM spec in a Minimal Context Harness project. Do not trigger for ordinary coding, debugging, package work, or generic mentions of 产品, product, or requirements.
+---
+
+# Context Product Plan
+
+## Package-Managed Boundary
+
+This Skill is generated by `sdlc-harness sync` and owned by the Harness package. Do not edit the generated `context_product_plan` Skill directly.
+
+Project-specific product planning rules belong in a separate project-local Skill under `<harnessRoot>/skills/product_plan/SKILL.md`. When a project-local Skill and this package-managed Skill both apply, use the more specific project-local Skill as the primary instruction source while keeping durable conclusions in `project_context/**`. Keep the project-local Skill front matter `description` trigger keywords aligned with this package-managed Skill and the project `AGENTS.md` role-trigger rule; if the project adds or narrows trigger terms, update both places together so agent activation and SDLC guidance do not drift apart.
+
+## 目标
+
+帮助 agent 把产品方案收敛成可恢复的 Minimal Context。
+
+## 工作方式
+
+1. 先读取 `project_context/global.md` 和 `project_context/context.toml`，按 default area、triggers、read_when 选择相关 context。
+2. 和用户澄清或整理：目标用户、产品/页面定位、核心问题、用户需要什么、产品需要提供的内容/能力/反馈、主要流程、验收信号、非目标、约束、风险和受影响模块。
+3. 涉及 Web 页面、前端布局、UI/UX、产品模块边界或信息放置时，把页面产品定位检查作为前置动作：用户在页面要完成的判断、产品必须提供的信息/动作/反馈、不应常驻的信息、下游消费层/运维层/详情层/其他页面归属、布局和信息密度是否匹配页面任务。多页面或多模块归属不清时，先读取相关 Context 并搜索页面入口，做全站或相关页面的信息架构 sweep，再收窄到具体实现。该检查是下一步变更分类的输入；只有形成长期产品归属、页面职责、信息架构或模块边界结论时才更新 Context。
+4. 涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或加载/空态/错误态等 UI 控件时，用“控件任务框架”重新理解用户任务和产品反馈；这只是通用判断框架，不是业务处方库。
+5. 产品意图、模块职责、边界和验收口径以 `project_context/**` 为准；代码和搜索结果只说明当前实现状态。Context 决定“应该是什么”，代码揭示“现在是什么”，代码不能静默重定义 Context。
+6. 输出产品判断或第一处实现编辑前，若任务涉及产品方案、页面/模块边界、信息架构、API / Schema、验收口径、跨域契约、状态或调度语义，先编译当前任务契约；契约第一段用 `Context Delta: none|required` 完成唯一正式长期事实判断，再写本次 `Task Contract`。
+7. 普通 bug fix、局部样式、局部实现漂移、测试修复或探索性 spike 不更新 Context；如果过程中形成长期产品结论，应在继续对齐或交付前回写 Context。不要把 Context 机械补成代码改动摘要。
+8. 如果代码与 Context 冲突，显式标记为实现漂移、缺失工作或 Context 过期。
+9. 输出产品判断时保持短而具体，避免长篇 PRD 模板。
+10. 需要沉淀长期事实时，只更新 `project_context/**`：
+   - 全局产品目标、边界、背景写入 `global.md`。
+   - 产品域用户/系统契约、规则、风险写入对应 area / subdomain Context。
+   - 跨域契约写入 `context_role: contract` 或 manifest role 为 `contract` 的 Context；底层理论源写入 `foundation`，关键重复验证路径写入 `verification`，关键部署/运行初始化路径写入 `deployment`，历史索引写入 `archive`，不要伪装成 area。
+   - 新 context unit 可新增 `project_context/areas/<unit>.md`，并更新 `global.md#Context Index`；复杂项目同时更新 `project_context/context.toml`。
+   - 如果 `upgrade` 自动把深层 `.md` 注册成 area，但语义上更像 foundation / contract / archive，后续应显式调整 manifest role；不要依赖自动迁移判断语义。
+11. Context 只能声明验证 / 部署关键路径或验收信号，不能伪造“测试已通过”或“部署已成功”。
+12. Verification / Deployment Role Context 只记录长期可复用的重复执行路径事实：特殊准备、最短命令或路径、预期阶段 / 信号、可接受 warning、已排除的重复探索点。不要记录一次性测试日志、完整输出、临时 JSON、CI artifact、测试报告、release ledger、secret、token、cookie、device id 或 raw payload。
+13. 收尾时做 `Contract Conformance` 和 Context drift check，只报告轻量状态：`Context: 已更新 ...` 或 `Context: 本次无长期事实变化`。Conformance 说明本次契约满足情况、未满足或延期项和验证入口；一次性证据、测试日志、截图结果、任务契约和实现摘要不写入 Context。
+
+## 任务契约编译
+
+- 任务契约是当前任务的编译产物，不是事实源、PRD、ADR 或长期文档；默认留在方案、交付说明或 PR 文本中。
+- `Context Delta` 必须先出现，取值为 `none` 或 `required`：
+  - `none`：本次只是按既有 Context / 原则落地，不新增长期事实。
+  - `required`：说明长期事实类型、应写入的 Context / role、需要沉淀的事实，以及明确不写入 Context 的一次性内容。
+- `Task Contract` 用短列表说明本次产品实现必须满足的目标、用户任务、信息 / 动作 / 状态 / 反馈、边界、非目标和验收信号。
+- 对长任务、多模块、多 agent、容易发生 `Context Delta` 调头或多轮验证的任务，可以用 `plan.md` 或等价临时计划面暂存 `Context Delta`、`Task Contract`、`Implementation Steps` 和 `Contract Conformance`；它只是临时执行缓存。
+- `plan.md` 中出现的长期事实必须提炼回 `project_context/**`；否则不要把临时计划当作事实源、交付产物或后续引用依据。
+- `Context Delta: required` 时先更新 `project_context/**`，再继续实现；`none` 时直接按 Task Contract 实现。
+- `Contract Conformance` 是交付前的软检查：实现偏差修实现，契约遗漏回 Task Contract，长期事实缺失回 `Context Delta` 并先更新 Context。
+- 不为普通 bug fix、局部样式、小重构、局部实现漂移、测试修复或探索性 spike 强制编译任务契约。
+
+## 产品体验校准
+
+- 做页面、模块或入口规划时，先回答产品或页面定位是什么、要解决什么问题、需要提供什么给用户；再回答放什么、放哪里、为什么。这是页面变更前置判断，不是实现后的视觉润色。优先保留能帮助目标用户判断状态、采取行动、定位下一步或理解风险的信息。
+- 信息归属按使用场景决定：高频且跨页面的动作优先考虑系统级区域；模块动作放模块内部；运维、连接、缓存、后台任务等内部状态只有在影响用户判断或行动时才进入主界面，否则放运维/详情区域；低频解释放 Context、文档、帮助或详情，不默认占据主界面。
+- 首页、总览或入口页应服务产品定位下的核心使用路径和核心判断，不要为了证明系统层级完整而重复导航、堆叠入口、保留空指标槽或展示实现来源说明。
+- 产品文案面向真实用户，直白、行动优先；除产品名、协议、字段名、ID、调试 JSON 等必要专有名词外，普通按钮、筛选、状态、空态、警告和说明优先使用用户熟悉的语言。
+- 空态和数据要求真实：没有数据就显示真正空态，筛选无结果与系统无数据要区分，API/连接失败用用户能理解的状态表达，技术细节放到运维或详情里。
+
+## 控件任务框架
+
+- 当产品界面涉及输入、选择、搜索、筛选、表单/配置、调度/时间窗口、预算/配额/限流或状态反馈时，先把控件还原成用户任务：用户要判断什么、选择什么、提交什么或规避什么风险。
+- 先判断数据语义，再选交互：自由文本、枚举、实体选择、时间/区间、数量/预算、规则配置和内部开关对应不同的理解成本、错误成本和验证需求。
+- 明确用户确认自己“选对了/填对了/可以继续”的反馈：加载中、无结果、无数据、连接失败、校验失败、保存成功和风险提示要能被用户区分。
+- 对数量、预算、配额、限流、调度和时间类字段，判断是否需要单位、范围、默认值、示例、推荐值、成本/风险/影响说明；只记录稳定业务结论，不把一次性解释写进 Context。
+- 检查用户可见语言是否面向任务，而不是后端字段名、数据库列或内部枚举直出；必要技术细节放到详情、帮助、运维或调试视图。
+- 如果选择自由输入，必须判断错误成本、校验反馈和恢复路径是否可接受；如果不可接受，应形成更明确的输入约束或控件契约。
+- 这些问题是通用产品判断，不是固定控件处方。业务特定答案进入项目 Context 或项目本地 Skill；本次实现如何满足既有约束只写在交付说明。
+
+## 输出边界
+
+- 不默认创建 `.work_products/**`、PRD、tech plan、ADR、implementation doc、review/test/release 文档。
+- 不要求 lifecycle phase、plan task、phase gate 或阶段 Skill。
+- 如果用户明确要求独立方案文档，可以临时生成；长期事实仍要提炼回 `project_context/**`。
+- 如果用户只是要求实现功能、修 bug、调整代码、处理 package/release，或只是泛泛提到“产品 / product / requirements”，不需要触发本 Skill；只有明确角色名或强相关产物名指向产品判断、需求整理、验收口径或长期产品事实沉淀时才使用。
+
+## 建议沉淀位置
+
+- `global.md#Product / Delivery Brief`：项目级产品目标、用户、核心流程和非目标。
+- `global.md#Design Rationale`：长期产品取舍。
+- `areas/*.md#User / System Contract`：产品域可见行为、API、CLI、UI 或数据契约。
+- `areas/*.md#Key Constraints`：业务规则、边界、风险和不易从代码看出的约束。
+- `areas/*/verification.md` 或 role=`verification` Context：关键测试、smoke、CI、probe 或验证重复执行路径。
+- `areas/*/deployment.md` 或 role=`deployment` Context：关键部署、云端初始化、运行拓扑、健康检查或回滚重复执行路径。
+- `project_context/context.toml`：复杂项目的产品域 area/context_unit、role、触发词、按需读取策略和可选边界规则。