project-tiny-context-harness 0.7.4 → 0.7.5

package/assets/skills/context_development_engineer/SKILL.md

@@ -1,72 +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、页面职责和控件任务，而不是只确认字段已暴露；
-- 内部保持 Surface Contract Hit、main allows/forbids、drilldown ownership、long-task state requirement、implementation drift 和 verification；
+- 对 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；
 - 缺失 durable surface responsibility 时设置 `Context Delta: required`，先用 `context_surface_contract` 或 owning Context 建立职责；
 - 收尾用简短 `Contract Conformance` 说明命中的 Context、实现满足方式、未满足项和验证入口。
 
@@ -81,30 +82,31 @@ For material production UI, first confirm Design Authority readiness; then carry
 - 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.
+- For each applicable material control, preserve region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics. An omitted field is not permission to invent durable product behavior; resolve it through UI Authority Closure.
 - never promote the implementation's own generated screenshot/diff into its target; exact targets and acceptance-affecting baselines are selected Source/verifier inputs before comparison.
 
-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.
+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/**`。

package/assets/skills/context_full_project_export/SKILL.md

@@ -1,70 +1,70 @@
----
-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
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context 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, 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`.
-- `--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.
-
-## 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/ty-context/context-exports/<name>.md`.
-- Context drift check should be `Context: no durable project facts changed` unless the task also changes Harness rules.
+---
+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
+
+## Package-Managed Boundary
+
+This Skill is generated by `ty-context 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, 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`.
+- `--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.
+
+## 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/ty-context/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_harness_upgrade/SKILL.md

@@ -1,60 +1,60 @@
----
-name: context_harness_upgrade
-description: Use when the user asks to upgrade Tiny Context, update Tiny Context, use the Tiny Context upgrade skill to upgrade this project, upgrade project-tiny-context-harness, run ty-context upgrade, run make ty-context-upgrade, Project Tiny Context Harness upgrade, 用 Tiny Context upgrade skill 升级这个项目, 升级 tiny context, 升级tiny context, or 更新 project-tiny-context-harness in a Minimal Context Harness project.
----
-
-# Context Harness Upgrade
-
-## Package-Managed Boundary
-
-This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_harness_upgrade` Skill directly.
-
-This Skill handles Harness package upgrade and migration orchestration only. It does not author product facts, refactor business code, replace project tests or prove application quality.
-
-## Purpose
-
-When the user asks to upgrade Tiny Context / Project Tiny Context Harness in an existing project, run the canonical `upgrade` path, handle only migration-scoped follow-up, and leave durable project semantics to the project Context and user-owned code. A `sync-only` release means no new migration is expected; it does not change the default upgrade entry for explicit upgrade requests.
-
-## Workflow
-
-1. Read the project routing and Context entry points before changing files:
-   - `AGENTS.md`
-   - `project_context/global.md`
-   - `project_context/architecture.md`
-   - `project_context/context.toml`
-2. Inspect the working tree with `git status --short`. Do not revert unrelated user changes.
-3. Prefer project wrappers when present:
-   - `make ty-context-sync`
-   - `make ty-context-upgrade`
-   - `make ty-context-doctor`
-   - `make validate-context`
-4. If no wrapper exists, use the package CLI explicitly:
-   - `npx --yes --package project-tiny-context-harness@latest ty-context sync`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade`
-   - `npx --yes --package project-tiny-context-harness@latest ty-context doctor`
-5. Run `upgrade --check` when useful, then run `upgrade`. This remains the default after package updates and for explicit upgrade requests because it plans migrations, applies safe migrations, refreshes managed assets and runs diagnostics.
-6. Do not run standalone `sync` before `upgrade` for explicit upgrade requests. A direct `sync` is only a shortcut for releases explicitly marked `sync-only` when the user asks for managed-asset refresh instead of upgrade diagnostics.
-7. Do not run standalone `sync` after a successful `upgrade` unless the project wrapper did not run sync or the user explicitly asks for another managed-asset refresh.
-8. If `upgrade --check` or `upgrade` reports only `safe_pending` items and the command succeeds, do not invent additional manual cleanup.
-9. If the report includes `manual_required` or `blocked`, handle only the listed migration scope. Use `project_context/context.toml`, role placement scan and the existing area graph to decide placement. Do not guess product or business semantics.
-10. If the report includes `blocked`, treat it as a write preflight failure: resolve the blocked migration scope and rerun `upgrade` before expecting safe migrations or managed asset sync to have been applied.
-11. Run diagnostics after migration-scoped follow-up:
-   - `make ty-context-doctor` or the CLI `doctor`
-   - `make validate-context`
-12. Report commands run, migration status, diagnostics, files changed and any remaining manual items. Use `Context: no durable project facts changed` unless the upgrade exposed or required a real long-term project fact change.
-
-## Manual Handling Rules
-
-- `manual_required` means the Harness detected a migration-scoped item but cannot safely choose the project meaning. Fix it only when the existing Context or file structure proves the intended placement.
-- `blocked` means the safe target already exists or another conflict prevents a mechanical write. Do not overwrite. Compare source and target, preserve user content and ask for direction if the conflict cannot be resolved from project facts.
-- Deprecated override Skills under `ty-context-managed/override_skills/**` should be migrated to standalone project-local Skills only when their content is still relevant. Do not merge them into package-managed default Skills.
-- Ambiguous Context roles should not be guessed from filenames like `api.md`, `notes.md` or `main.md` alone. Register a role only when the manifest, path convention or durable content makes it clear.
-- If `upgrade` creates default `project_context/areas/main.md` or `project_context/areas/main/verification.md` but `project_context/context.toml` already declares real project areas and does not register `main`, remove those generated defaults instead of preserving them as durable project facts. If `main` is registered or contains user-authored facts, do not delete it automatically.
-
-## Boundaries
-
-- Do not restore legacy stage workflow, sprint documents or phase gates.
-- Do not modify application code, product behavior, deployment settings or tests unless the user explicitly asks or a migration report points to a Harness-owned file in that scope.
-- Do not write one-off command output, release logs, diagnostics or temporary migration notes into `project_context/**`.
-- Do not edit package-managed generated surfaces directly in a consumer project unless the change is part of a migration conflict that cannot be resolved another way. Prefer rerunning `upgrade` / `sync` from the package source.
+---
+name: context_harness_upgrade
+description: Use when the user asks to upgrade Tiny Context, update Tiny Context, use the Tiny Context upgrade skill to upgrade this project, upgrade project-tiny-context-harness, run ty-context upgrade, run make ty-context-upgrade, Project Tiny Context Harness upgrade, 用 Tiny Context upgrade skill 升级这个项目, 升级 tiny context, 升级tiny context, or 更新 project-tiny-context-harness in a Minimal Context Harness project.
+---
+
+# Context Harness Upgrade
+
+## Package-Managed Boundary
+
+This Skill is generated by `ty-context sync` and owned by the Harness package. Do not edit the generated `context_harness_upgrade` Skill directly.
+
+This Skill handles Harness package upgrade and migration orchestration only. It does not author product facts, refactor business code, replace project tests or prove application quality.
+
+## Purpose
+
+When the user asks to upgrade Tiny Context / Project Tiny Context Harness in an existing project, run the canonical `upgrade` path, handle only migration-scoped follow-up, and leave durable project semantics to the project Context and user-owned code. A `sync-only` release means no new migration is expected; it does not change the default upgrade entry for explicit upgrade requests.
+
+## Workflow
+
+1. Read the project routing and Context entry points before changing files:
+   - `AGENTS.md`
+   - `project_context/global.md`
+   - `project_context/architecture.md`
+   - `project_context/context.toml`
+2. Inspect the working tree with `git status --short`. Do not revert unrelated user changes.
+3. Prefer project wrappers when present:
+   - `make ty-context-sync`
+   - `make ty-context-upgrade`
+   - `make ty-context-doctor`
+   - `make validate-context`
+4. If no wrapper exists, use the package CLI explicitly:
+   - `npx --yes --package project-tiny-context-harness@latest ty-context sync`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade --check`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context upgrade`
+   - `npx --yes --package project-tiny-context-harness@latest ty-context doctor`
+5. Run `upgrade --check` when useful, then run `upgrade`. This remains the default after package updates and for explicit upgrade requests because it plans migrations, applies safe migrations, refreshes managed assets and runs diagnostics.
+6. Do not run standalone `sync` before `upgrade` for explicit upgrade requests. A direct `sync` is only a shortcut for releases explicitly marked `sync-only` when the user asks for managed-asset refresh instead of upgrade diagnostics.
+7. Do not run standalone `sync` after a successful `upgrade` unless the project wrapper did not run sync or the user explicitly asks for another managed-asset refresh.
+8. If `upgrade --check` or `upgrade` reports only `safe_pending` items and the command succeeds, do not invent additional manual cleanup.
+9. If the report includes `manual_required` or `blocked`, handle only the listed migration scope. Use `project_context/context.toml`, role placement scan and the existing area graph to decide placement. Do not guess product or business semantics.
+10. If the report includes `blocked`, treat it as a write preflight failure: resolve the blocked migration scope and rerun `upgrade` before expecting safe migrations or managed asset sync to have been applied.
+11. Run diagnostics after migration-scoped follow-up:
+   - `make ty-context-doctor` or the CLI `doctor`
+   - `make validate-context`
+12. Report commands run, migration status, diagnostics, files changed and any remaining manual items. Use `Context: no durable project facts changed` unless the upgrade exposed or required a real long-term project fact change.
+
+## Manual Handling Rules
+
+- `manual_required` means the Harness detected a migration-scoped item but cannot safely choose the project meaning. Fix it only when the existing Context or file structure proves the intended placement.
+- `blocked` means the safe target already exists or another conflict prevents a mechanical write. Do not overwrite. Compare source and target, preserve user content and ask for direction if the conflict cannot be resolved from project facts.
+- Deprecated override Skills under `ty-context-managed/override_skills/**` should be migrated to standalone project-local Skills only when their content is still relevant. Do not merge them into package-managed default Skills.
+- Ambiguous Context roles should not be guessed from filenames like `api.md`, `notes.md` or `main.md` alone. Register a role only when the manifest, path convention or durable content makes it clear.
+- If `upgrade` creates default `project_context/areas/main.md` or `project_context/areas/main/verification.md` but `project_context/context.toml` already declares real project areas and does not register `main`, remove those generated defaults instead of preserving them as durable project facts. If `main` is registered or contains user-authored facts, do not delete it automatically.
+
+## Boundaries
+
+- Do not restore legacy stage workflow, sprint documents or phase gates.
+- Do not modify application code, product behavior, deployment settings or tests unless the user explicitly asks or a migration report points to a Harness-owned file in that scope.
+- Do not write one-off command output, release logs, diagnostics or temporary migration notes into `project_context/**`.
+- Do not edit package-managed generated surfaces directly in a consumer project unless the change is part of a migration conflict that cannot be resolved another way. Prefer rerunning `upgrade` / `sync` from the package source.