coding-agent-harness 1.0.2 → 1.0.5

package/docs-release/guides/migration-playbook.md

@@ -98,17 +98,6 @@ harness migrate-verify /tmp/cah-migration-project/session.json
 
 如果后续继续清理 warning 或补活跃任务合同，第一次 session 只能作为 baseline。最终交付前要重新运行 `migrate-run` 生成新 session/dashboard，或者明确列出 baseline session 与最终检查证据的差异。
 
-4. 用 session 创建 Complex Task preset：
-
-```bash
-harness new-task \
-  --budget complex \
-  --preset legacy-migration \
-  --from-session /tmp/cah-migration-project/session.json
-```
-
-这一步只创建任务骨架和 `evidence/<timestamp>/` 证据包，不会继续运行迁移、改写历史任务、stage 或 commit。生成的任务会写入 `Task Kind`、`Task Preset`、`Preset Version`、`Migration Target Level`、`Migration Achieved Level` 和 `Evidence Bundle`，后续 agent 应在这个 Complex Task 里推进迁移，而不是另起一套流程。
-
 `migrate-verify` 通过不等于 full migration complete。完整迁移还必须满足：
 
 - `migrate-plan` 是 `declared-capability`。
@@ -119,7 +108,7 @@ harness new-task \
 - 任务索引页面能打开并显示全量任务。
 - 至少一轮 subagent 对抗审查 PASS。
 
-5. 按计划继续人工/agent 清理：
+4. 按计划继续人工/agent 清理：
 
 - `MP-01`：确认兼容层和 locale，保证历史文档没有被覆盖。
 - `MP-02`：选择 capability，只声明项目事实已经支持的能力。
@@ -128,14 +117,14 @@ harness new-task \
 - `MP-05`：升级当前 release/architecture/security/data review，不重写所有历史 review。
 - `MP-06`：普通检查 warning 都有 owner/action/status 后，再使用 strict 作为门禁。
 
-6. 普通迁移验证：
+5. 普通迁移验证：
 
 ```bash
 harness check --profile target-project /path/to/project
 harness dashboard --out-dir /tmp/harness-dashboard /path/to/project
 ```
 
-7. 严格切换验证：
+6. 严格切换验证：
 
 ```bash
 harness check --profile target-project --strict /path/to/project
@@ -175,6 +164,16 @@ Baseline 模式下，只有 `current-active` 或 “仍被 SSoT 引用为当前
 
 Status-aware rewrite 模式下，已有 `brief.md`、`execution_strategy.md`、`visual_map.md` 不是自动保留；如果证据显示它们只是旧模板、解析残留、语言错误或不能让人判断当前状态，就重写。历史任务可以只写可读索引卡或 residual，但这个判断必须有证据。
 
+全局表和模块索引迁移不是人工重填。新版本只把任务生命周期汇总生成到 `Harness-Ledger.md`；旧的 `Feature-SSoT.md` 和 `Private-Feature-SSoT.md` 是 legacy 生命周期投影，切换时应先归档，不再重建。模块 `module_plan.md` 的 Steps 表和模块 `visual_map.md` 的拓扑表仍由模块任务文件生成。人看当前状态应优先看 Dashboard，Agent 需要快速定位时用 `task-list` / `task-index` 查询。旧项目切换前，先把旧生命周期表归档，再用生成器从任务文件重建当前索引：
+
+```bash
+harness governance rebuild --dry-run --archive /path/to/project
+harness governance rebuild --archive --apply /path/to/project
+harness task-list --json --search "keyword" /path/to/project
+```
+
+归档目录会保留旧生命周期表快照。确认 Dashboard、`task-list` / `task-index` 查询和新生成 Ledger 都能反映当前任务后，再由项目 owner 决定是否删除旧归档；迁移 agent 不应直接删除历史表证据。Delivery、Regression、Cadence、Closeout、Module Registry 等非任务生命周期治理表不是本步骤的删除对象，除非后续版本提供等价 scanner 和生成器。
+
 Full semantic rewrite 模式下，所有任务都需要 standalone `brief.md`，但不能写空模板。历史任务的 brief 应该是“可读索引卡”：说明任务目标、第一眼应该看什么、证据来自哪里、状态判断和 residual。`visual_map.md` 是图表集合，不是路线图模板；只画能提高理解速度的 phase flow、sequence、architecture、data-flow、state、topology 或 decision map，不能为了过检查生成空图。
 
 如果旧项目属于微服务、多仓、前后端分仓或依赖外部系统，迁移计划还必须询问用户是否有外部资料。不要把外部团队给的几十份文档直接迁入 `03/04/06`。先按 `external-source-intake-standard.md` 建立 `docs/04-DEVELOPMENT/external-source-packs/<source-key>/`，完成 source index 和 digest，再把稳定事实投影到 service profile、external context 和 integration contract。
@@ -286,7 +285,7 @@ Full cutover 的 dashboard smoke 必须验证：
 | --- | --- | --- |
 | Task Contract Worker | `docs/09-PLANNING/TASKS/**/brief.md`、`execution_strategy.md`、`visual_map.md`、同任务 `progress.md` 追加 | 清掉 task contract 缺口；在已确认 rewrite 模式下重写薄弱旧表面。 |
 | Review/Capability Worker | `.harness-capabilities.json`、当前 strict review 文件 | 声明真实 capability，修 release-blocking review schema。 |
-| Legacy Governance Worker | `AGENTS.md`、PR template、`docs/11-REFERENCE/**`、Ledger、Closeout SSoT、Lessons SSoT、walkthrough template | 清掉 legacy checker 聚合错误。 |
+| Legacy Governance Worker | `AGENTS.md`、PR template、`docs/11-REFERENCE/**`、Ledger、Closeout SSoT、lesson candidates/detail docs、walkthrough template | 清掉 legacy checker 聚合错误。 |
 | Brief Coverage Workers | 按日期段或模块划分，写缺失或被点名薄弱的 `brief.md` | 把 dashboard brief coverage 变成 100%，并移除空模板。 |
 | Quality Repair Worker | 只写 reviewer 点名的问题文件 | 修掉自动解析痕迹、空模板、语言不一致和证据薄弱。 |
 

package/docs-release/guides/parent-control-repository-pattern.en-US.md

@@ -16,7 +16,7 @@ Multi-repo projects often run into these failures:
 
 - Frontend, backend, SDK, and services each have their own plans, and no one can tell where the global release is blocked.
 - An agent starts inside a child repository, reads only local `AGENTS.md`, and misses cross-repo architecture constraints.
-- Each repository maintains its own Feature SSoT, and the states conflict.
+- Each repository maintains its own handwritten task lifecycle table, and the states conflict.
 - Review evidence, test evidence, and walkthroughs are scattered across repositories, making it hard to prove that a cross-repo task is complete.
 
 The parent-control pattern solves a control-plane problem. It does not force code back into a monorepo. It moves the harness source of truth into one place.
@@ -62,7 +62,8 @@ It should contain:
 - `docs/03-ARCHITECTURE/repository-topology.md`: repository topology, owners, boundaries, dependency direction.
 - `docs/04-DEVELOPMENT/local-development.md`: cross-repo local startup, integration workflow, dependency setup.
 - `docs/06-INTEGRATIONS/`: cross-service APIs, events, SDKs, databases, permissions, and external contracts.
-- `docs/09-PLANNING/Feature-SSoT.md`: global feature and release state.
+- `docs/Harness-Ledger.md`: generated global task lifecycle index from task files.
+- `docs/09-PLANNING/Delivery-SSoT.md`: cross-repo feature blocks, dependencies, and release orchestration.
 - `docs/09-PLANNING/TASKS/`: cross-repo task contracts.
 - `docs/05-TEST-QA/Regression-SSoT.md`: cross-repo regression gates.
 - `docs/05-TEST-QA/Cadence-Ledger.md`: which changes trigger which checks.
@@ -94,7 +95,7 @@ They should contain:
 - Repository-local reviews or pull requests.
 - Repository-local test evidence.
 
-Child repositories should not independently maintain the global Feature SSoT, and they should not decide whether a cross-repo release is complete.
+Child repositories should not independently maintain global task lifecycle tables, and they should not decide whether a cross-repo release is complete.
 
 A child repository `AGENTS.md` can be short:
 
@@ -228,7 +229,7 @@ The agent does not need to read all docs in 100 repositories at startup. It read
 
 Avoid:
 
-- Each child repository maintaining its own global Feature SSoT.
+- Each child repository maintaining its own global task lifecycle table.
 - A parent repository with only a README and no task, regression, or closeout surface.
 - Child `AGENTS.md` files copying large sections from the parent, causing drift.
 - Starting cross-repo tasks from a child repository and backfilling parent records at the end.
@@ -241,7 +242,8 @@ To adopt the parent-control model, start with:
 
 - Parent `AGENTS.md` states that this is the control repository.
 - `docs/03-ARCHITECTURE/repository-topology.md` lists all child repositories.
-- `docs/09-PLANNING/Feature-SSoT.md` is the global feature source of truth.
+- `docs/Harness-Ledger.md` is generated from task files as the global task lifecycle index.
+- `docs/09-PLANNING/Delivery-SSoT.md` is maintained only when cross-repo release or block orchestration is needed.
 - `docs/05-TEST-QA/Regression-SSoT.md` defines local, contract, integration, and release gates.
 - Each child repository has only a short local `AGENTS.md`.
 - New cross-repo tasks are created only in the parent repository.

package/docs-release/guides/parent-control-repository-pattern.md

@@ -16,7 +16,7 @@ English mirror: `docs-release/guides/parent-control-repository-pattern.en-US.md`
 
 - 前端、后端、SDK、微服务各有自己的计划，没人知道全局 release 到底卡在哪里。
 - Agent 从某个子仓库启动，只看到局部 `AGENTS.md`，忽略了跨仓架构约束。
-- 每个仓库各自维护 Feature SSoT，状态互相冲突。
+- 每个仓库各自维护手写任务生命周期表，状态互相冲突。
 - Review 证据、测试证据、walkthrough 分散在不同仓库，最后无法证明一个跨仓任务真正完成。
 
 主控仓库模式解决的是控制面问题。它不是要求把代码放回单仓，而是把 Harness 的事实源收回一个地方。
@@ -62,7 +62,8 @@ product-control-repo/
 - `docs/03-ARCHITECTURE/repository-topology.md`：仓库拓扑、owner、边界、依赖方向。
 - `docs/04-DEVELOPMENT/local-development.md`：跨仓本地启动、联调、依赖安装。
 - `docs/06-INTEGRATIONS/`：跨服务 API、事件、SDK、数据库、权限、外部系统契约。
-- `docs/09-PLANNING/Feature-SSoT.md`：全局 feature 和 release 状态。
+- `docs/Harness-Ledger.md`：由任务文件生成的全局任务生命周期索引。
+- `docs/09-PLANNING/Delivery-SSoT.md`：跨仓 feature block、依赖和 release 编排。
 - `docs/09-PLANNING/TASKS/`：跨仓任务合同。
 - `docs/05-TEST-QA/Regression-SSoT.md`：跨仓 regression gates。
 - `docs/05-TEST-QA/Cadence-Ledger.md`：哪些变更触发哪些检查。
@@ -94,7 +95,7 @@ node tools/check-harness.mjs
 - 本仓库局部 review 或 PR。
 - 本仓库局部测试证据。
 
-子仓库不应该单独维护全局 Feature SSoT，也不应该自己决定跨仓 release 是否完成。
+子仓库不应该单独维护全局任务生命周期表，也不应该自己决定跨仓 release 是否完成。
 
 一个子仓库 `AGENTS.md` 可以很短：
 
@@ -228,7 +229,7 @@ Agent 不需要在启动时读 100 个仓库的所有文档。它先读父任务
 
 避免这些做法：
 
-- 每个子仓库各自维护全局 Feature SSoT。
+- 每个子仓库各自维护全局任务生命周期表。
 - 父仓库只有 README，没有任务、回归和 closeout。
 - 子仓库 `AGENTS.md` 复制父仓库大段内容，导致漂移。
 - 跨仓任务从子仓库启动，最后再补父仓库记录。
@@ -241,7 +242,8 @@ Agent 不需要在启动时读 100 个仓库的所有文档。它先读父任务
 
 - 父仓库 `AGENTS.md` 写清楚它是 control repo。
 - `docs/03-ARCHITECTURE/repository-topology.md` 列出所有子仓库。
-- `docs/09-PLANNING/Feature-SSoT.md` 成为全局 feature source of truth。
+- `docs/Harness-Ledger.md` 由任务文件生成全局任务生命周期索引。
+- `docs/09-PLANNING/Delivery-SSoT.md` 只在需要跨仓 release / block 编排时维护。
 - `docs/05-TEST-QA/Regression-SSoT.md` 定义局部、契约、集成、发布 gate。
 - 每个子仓库只有短的局部 `AGENTS.md`。
 - 新跨仓任务只在父仓库创建。

package/docs-release/guides/preset-development.md

@@ -0,0 +1,238 @@
+# Preset Development
+
+Harness presets are declarative task method packages. A preset can add task metadata, render Markdown templates, require CLI inputs, generate evidence files, and pre-load shared reference bundles without writing JavaScript.
+
+Use a preset when multiple tasks should start from the same method, evidence contract, or shared context. Do not create a preset for one-off prose. Good presets encode repeatable task behavior: required inputs, task kind, review/evidence expectations, shared references, and a small amount of task-plan guidance that tells the next agent what to read first.
+
+`preset.yaml` uses the Harness manifest subset: nested mappings, scalar strings/numbers/booleans, and inline arrays such as `[standard, complex]`. Do not use block strings or dash-list YAML forms in preset manifests.
+
+## Install Location
+
+Project presets live in:
+
+```text
+<target>/.coding-agent-harness/presets/<preset-id>/
+```
+
+User-installed presets live in:
+
+```text
+~/.coding-agent-harness/presets/<preset-id>/
+```
+
+When a target is supplied, Harness discovers project presets first, then user presets, then bundled presets under the package `presets/` directory. Use project presets when a repository needs to override or pin a task method. Use user presets for personal reusable methods across repositories.
+
+Bundled presets are not only fallback files. `npm install -g coding-agent-harness`
+and `harness install-user` seed them into the user preset root, while
+`harness init` seeds them into the project preset root. Re-run
+`harness preset seed` for the user root or `harness preset seed --project <target>`
+for the project root when a preset root is missing or incomplete.
+
+## Dashboard Management
+
+The Dashboard exposes a Presets view for the target project. Static dashboards
+show a read-only catalog of discovered project, user, and bundled presets,
+including source, purpose, compatible budgets, task kind, manifest path, and
+resource counts.
+
+Use the local dynamic Workbench when you want to manage presets from the web UI:
+
+```bash
+harness dev /path/to/project
+```
+
+In Workbench mode, the Presets view can check presets, install a local preset
+directory, `.zip` archive, or bundled preset id into the project or user scope,
+seed bundled presets into either scope, and uninstall project/user presets.
+Bundled package presets are immutable from the Dashboard: they can be inspected,
+checked, and used as install or seed sources, but not edited or deleted.
+
+The CLI and filesystem remain canonical. The Dashboard calls the same preset
+registry operations as `harness preset ...`; it does not store independent preset
+state.
+
+## Package Layout
+
+```text
+my-preset/
+  preset.yaml
+  templates/
+    task_plan.append.md
+    references/
+      upstream-contract.md
+  resources/
+    service-runbook.md
+```
+
+## Minimal Manifest
+
+```yaml
+id: custom-review
+version: 1
+purpose: Create a review task with preset evidence.
+compatibleBudgets: [standard, complex]
+localeSupport: [en-US, zh-CN]
+task:
+  kind: review-task
+  defaultTaskId: custom-review-task
+entrypoints:
+  newTask:
+    type: template
+    writes: [docs/09-PLANNING/TASKS/**]
+    audit: true
+    templates:
+      taskPlanAppend: templates/task_plan.append.md
+inputs:
+  subject:
+    type: text
+    flag: --subject
+    required: true
+templateValues:
+  subject:
+    from: inputs.subject
+metadata:
+  ReviewSubject:
+    label: Review Subject
+    from: inputs.subject
+evidence:
+  bundleDir: artifacts/preset
+  files:
+    subject:
+      path: subject.txt
+      type: text
+      value: inputs.subject
+audit:
+  manifestRequired: true
+  evidenceFiles: [preset-audit.json, preset-manifest.json, write-scope.json]
+writeScopes:
+  taskDocs:
+    path: docs/09-PLANNING/TASKS/**
+    access: write
+```
+
+## Reference Bundles
+
+Use `resources.references` when a family of tasks shares the same outside context, such as another microservice, API contract, migration packet, reviewer input, or local verification runbook. Harness copies or renders these files into each created task directory, appends `references/INDEX.md` rows, and can add a required-read section to `task_plan.md`.
+
+```yaml
+resources:
+  references:
+    upstreamContract:
+      path: references/upstream-contract.md
+      template: templates/references/upstream-contract.md
+      index:
+        id: REF-001
+        type: code
+        summary: Shared upstream {{service}} contract for every task created by this preset.
+        usedBy: coordinator,worker,reviewer
+    serviceRunbook:
+      path: references/service-runbook.md
+      source: resources/service-runbook.md
+      index:
+        id: REF-002
+        type: runbook
+        summary: Local verification notes for the shared upstream service.
+        usedBy: worker
+context:
+  requiredReads: [REF-001, REF-002]
+```
+
+Use `template` when the file needs `{{valueName}}` substitution. Use `source` when the file should be copied as static Markdown. `path`, `source`, and `template` must stay inside the preset package and generated task directory boundaries.
+
+## Artifact Bundles
+
+Use `resources.artifacts` for preset-provided fixtures, generated input packets, or review material that supports the task but is not a reference source of truth. Harness writes these files into the task's `artifacts/` area and appends `artifacts/INDEX.md`.
+
+```yaml
+resources:
+  artifacts:
+    inputPacket:
+      path: artifacts/input-packet.md
+      source: resources/artifacts/input-packet.md
+      index:
+        id: ART-001
+        type: fixture
+        summary: Shared fixture packet copied by the preset.
+        producedBy: preset
+```
+
+## Template Rendering
+
+Templates use `{{valueName}}` placeholders from `templateValues`. `templateValues` and `metadata` support literal `value`, `default`, and dot-path `from` references such as `inputs.subject` or `task.title`; they do not evaluate arbitrary expressions.
+
+`metadata` entries render first-class task plan lines such as `Review Subject: API contracts`.
+
+```md
+## Custom Review
+
+Subject: {{subject}}
+```
+
+## Inputs
+
+Supported input types:
+
+| Type | Use |
+| --- | --- |
+| `text` | Reads a CLI flag value such as `--subject "API"` |
+| `flag` | Reads a boolean CLI flag |
+| `json-file` | Reads and validates a JSON file such as `--from-session session.json` |
+
+`json-file` inputs can validate `validateOperation`, reject `planOnly`, require a target path, and route the task target from the JSON session.
+
+## Evidence
+
+Evidence files are written under the task directory and must match `writeScopes`.
+
+Supported evidence types:
+
+| Type | Output |
+| --- | --- |
+| `text` | Plain text from a value path |
+| `json` | JSON from a value path |
+| `input-json` | Raw resolved JSON input |
+| `preset-audit` | Manifest audit payload |
+| `preset-manifest` | Manifest snapshot |
+| `write-scope` | Declared write scopes |
+| `migration-verify` | Built-in migrate session verification |
+| `migration-ledger` | Built-in migration phase ledger |
+| `dashboard-hash` | Hash of the migration dashboard snapshot |
+| `target-git-status` | Target Git status from migration session |
+| `target-commit` | Current target commit |
+| `harness-version` | Current package version |
+| `generated-at` | Generation timestamp |
+
+## Commands
+
+```bash
+harness preset check ./my-preset
+harness preset install ./my-preset
+harness preset install ./my-preset.zip
+harness preset install ./my-preset --project /path/to/project
+harness preset install legacy-migration --force
+harness preset seed
+harness preset seed --project /path/to/project
+harness preset list --json /path/to/project
+harness preset inspect custom-review --json /path/to/project
+harness new-task --title "Custom review task" --preset custom-review --subject "API contracts" /path/to/project
+harness preset uninstall custom-review
+```
+
+## Validation Method
+
+For every preset, prove both the manifest and downstream task behavior:
+
+1. Run `harness preset check ./my-preset`.
+2. Install the folder and, if distributing an archive, install the `.zip` into an isolated HOME or disposable environment.
+3. Create at least one task with `harness new-task --preset`.
+4. For reference bundles, create two different tasks from the same preset and verify both contain the same shared `references/` files and independent audit/evidence bundles.
+5. Run `harness status --json`, `harness task-index --json`, and `harness check --profile target-project <target>`.
+6. Inspect `task_plan.md` to confirm required reads are visible before implementation starts.
+
+## Boundaries
+
+- Presets cannot write outside declared `writeScopes`.
+- Presets do not run arbitrary JavaScript during `new-task`.
+- Reference bundles are task-local snapshots. If the shared upstream context changes later, create a new preset version or a follow-up task rather than silently mutating historical tasks.
+- Script and check entrypoints may exist in bundled packages, but the task creation path is YAML + templates + built-in processors.
+- Use a new built-in processor only when multiple presets need the same capability and the behavior can be tested centrally.

package/docs-release/guides/repository-operating-models.en-US.md

@@ -92,7 +92,7 @@ Each repository should document its external boundary in:
 
 The risk is harness fragmentation:
 
-- The frontend Feature SSoT says a task is complete while the backend Regression SSoT is still red.
+- The frontend local task state says a task is complete while the backend Regression SSoT is still red.
 - An SDK breaking change is not projected into the product shell.
 - An agent starts from a child repository, sees only local facts, and incorrectly treats the global task as complete.
 
@@ -124,7 +124,8 @@ product-control-repo/
 The parent repository is the control plane. It owns:
 
 - Overall architecture and repo topology.
-- Cross-repo Feature SSoT.
+- Cross-repo task lifecycle Ledger.
+- Delivery SSoT when release or block orchestration is needed.
 - Task plans, reviews, and walkthroughs.
 - Regression SSoT and cross-repo cadence.
 - Agent entrypoint and reading matrix.
@@ -152,7 +153,7 @@ The parent-control model fixes global truth in one place. Even if there are 100
 
 This avoids:
 
-- Conflicting Feature SSoTs.
+- Conflicting handwritten task lifecycle tables.
 - Each child repo saying "done" while the release still cannot ship.
 - Agents starting from the wrong repository and seeing only local context.
 - Cross-repo review and regression evidence scattered across many places.
@@ -179,7 +180,7 @@ If cross-repo features remain common, create a parent-control repository.
 Migration order:
 
 1. Create the parent `AGENTS.md` and repo topology.
-2. Move global Feature SSoT, Regression SSoT, and walkthrough index into the parent repository.
+2. Move global Harness Ledger, Delivery SSoT, Regression SSoT, and walkthrough index into the parent repository.
 3. Keep local `AGENTS.md` files in child repositories, but point global planning back to the parent.
 4. Create new cross-repo tasks only in the parent repository.
 5. Treat child repository commits as evidence for parent tasks.

package/docs-release/guides/repository-operating-models.md

@@ -92,7 +92,7 @@ sdk-repo/
 
 多仓独立模式的风险是 Harness 分裂：
 
-- 前端 Feature SSoT 认为任务完成，后端 Regression SSoT 仍是红灯。
+- 前端局部任务状态认为任务完成，后端 Regression SSoT 仍是红灯。
 - SDK 的 breaking change 没有投影到产品 shell。
 - Agent 从子仓库启动后，只看到局部事实，误以为全局任务已经结束。
 
@@ -124,7 +124,8 @@ product-control-repo/
 父仓库是 control plane。它管理：
 
 - 总体架构和 repo topology。
-- 跨仓 Feature SSoT。
+- 跨仓任务生命周期 Ledger。
+- Delivery SSoT（需要 release / block 编排时）。
 - 任务计划、review、walkthrough。
 - Regression SSoT 和跨仓 cadence。
 - Agent 启动入口和读文件矩阵。
@@ -152,7 +153,7 @@ product-control-repo/
 
 这能避免：
 
-- 多个 Feature SSoT 互相冲突。
+- 多个手写任务生命周期表互相冲突。
 - 每个子仓库都声称自己已经完成，但 release 仍不能发。
 - Agent 从错误仓库启动，只看到局部上下文。
 - 跨仓 review 和 regression 证据散落在不同地方。
@@ -179,7 +180,7 @@ product-control-repo/
 迁移顺序：
 
 1. 创建父仓库 `AGENTS.md` 和 repo topology。
-2. 把全局 Feature SSoT、Regression SSoT、walkthrough index 收到父仓库。
+2. 把全局 Harness Ledger、Delivery SSoT、Regression SSoT、walkthrough index 收到父仓库。
 3. 子仓库保留局部 `AGENTS.md`，但把全局计划指向父仓库。
 4. 新跨仓任务只在父仓库创建 task。
 5. 子仓库提交只作为父任务的 evidence。