@amaster.ai/pi-lark 0.1.4 → 0.1.6

package/skills/lark-drive/references/lark-drive-workflow-knowledge-organize-planning.md

@@ -0,0 +1,336 @@
+# 知识整理工作流：Planning
+
+Loaded by states: `PLAN_GENERATION`, `EXEC_CONFIRM`.
+
+This file owns plan generation, plan revision, user-facing pagination, and execution confirmation. It MUST NOT perform write operations.
+
+## Required Context
+
+Before executing rules in this file:
+
+1. `resource_items`, `classification_rules`, and `target_tree` MUST already exist.
+2. Follow command syntax, scope requirements, and confirmation behavior from referenced shortcut docs.
+3. Follow `Non-goals` from the main workflow entry. Do not execute excluded operations from this file.
+
+## State: PLAN_GENERATION
+
+Entry: `target_tree` exists after the user confirmed the organization approach.
+
+MUST:
+
+1. Generate complete internal `plan_items`.
+2. Build `DisplayItem` only for user-facing pages.
+3. Apply `Plan Generation`.
+4. Apply `Plan Pagination`.
+5. Set `active_plan_items` to the latest complete plan.
+6. Keep complete plan internally even if only one page is displayed.
+7. Apply `Plan Generation Progress Reporting`.
+8. Output `Target Tree And Plan Overview` or requested plan page, then wait.
+
+### Plan Generation
+
+| Condition | Agent MUST Do |
+|-----------|---------------|
+| Target path appears in any plan item | Ensure the path exists in `target_tree` |
+| Source parent and descendants share same target subtree | Move parent only; mark descendants `covered_by_parent_move=true` |
+| A child target differs from parent target | Move divergent child before parent; order by `source_depth` from deep to shallow |
+| Target directory / node does not exist | Add `create_folder` / `create_node` before move |
+| Resource is root-level and target path differs from current path | Add a `move` plan item; do not leave root-level resources in place by default |
+| Resource has `needs_review=true` because classification evidence is insufficient | Set `target_path` to manual confirmation target, set `action=move`, and preserve `needs_review_reason` |
+| Top-level folder / Wiki node has descendants that share the same target subtree | Move the parent folder / node only; descendants are covered by parent move |
+| Top-level folder / Wiki node has descendants with divergent target subtrees | Move divergent descendants first; then move the parent only if it still has a target path or needs manual confirmation |
+| Source container is reused as a target container | Keep the container in place; do not move it as source-container cleanup |
+| Non-reused source container has descendants moved elsewhere | Add an explicit folder / node move plan item after descendant moves; target defaults to the source-container cleanup target |
+| Source container handling is ambiguous | Move it to the manual confirmation target or mark `needs_review=true`; do not leave it in the root by default |
+| Target parent token unresolved | Keep plan item but block execution until token is resolved |
+| Resource title is poor or inconsistent | Report the naming issue only; do not create rename or title-patch plan items |
+
+### Plan Generation Progress Reporting
+
+Plan generation can be long-running when `resource_items` is large or source-container parent / child move ordering is complex.
+
+Rules:
+
+1. If plan generation starts with more than 500 `resource_items`, output one concise start notice with the resource count and that no write operation is being executed.
+2. If plan generation runs longer than about 60 seconds, output progress about every 60 seconds.
+3. Progress reports SHOULD include only fields currently known: processed resource count, generated plan item count, create count, move count, source-container move count, review count, and current step.
+4. Do not display unpaginated plan details as progress. Complete `plan_items` remain internal until the normal paginated output.
+5. Do not ask the user to continue during plan generation unless auth, permission, API, target scope, or environment blockers occur.
+6. Do not output filler such as "still running" without current counts or current step.
+
+Example:
+
+```text
+计划生成进度：已处理 <processed_count>/<resource_count> 项资源，生成 <plan_item_count> 项计划，其中创建 <create_count> 项、移动 <move_count> 项。继续计算父子目录移动顺序，不会执行创建或移动。
+```
+
+## PlanItem
+
+`PlanItem` is for internal execution. It may contain tokens and internal enums.
+
+| Field | Meaning |
+|-------|---------|
+| `plan_id` | Stable unique ID for plan / verification, such as `P001` |
+| `source_path` | Current path |
+| `title` | Resource title |
+| `type` | Resource type |
+| `source_token` | Drive token or normal resource token |
+| `source_node_token` | Wiki node token; empty for non-Wiki resources |
+| `source_parent_token` | Current parent folder token or parent Wiki node token |
+| `source_depth` | Original depth in source tree |
+| `target_path` | Target path |
+| `target_parent_path` | Target parent path |
+| `target_parent_token` | Target parent token; may be empty during planning, MUST be resolved before execution |
+| `action` | Internal enum: `keep` / `create_folder` / `create_node` / `move` |
+| `covered_by_parent_move` | Whether an ancestor move already covers this item |
+| `reason` | Classification reason |
+| `evidence_paths` | Evidence paths |
+| `evidence_count` | Evidence count or hit count |
+| `confidence` | Internal enum: `high` / `medium` / `low` |
+| `needs_review` | Whether human review is required |
+| `needs_review_reason` | Reason requiring human review |
+| `rollback_origin_kind` | Internal recovery origin marker: `drive_folder` / `drive_root` / `wiki_node` / `wiki_space_root` / `unknown` |
+| `rollback_origin_token` | Original parent token when applicable; empty for root markers |
+| `rollback_origin_space_id` | Original Wiki space ID when `rollback_origin_kind=wiki_space_root` |
+| `rollback_supported` | Whether this move item can be restored automatically if recovery is requested |
+| `rollback_blocker` | Internal reason when `rollback_supported=false` |
+
+### Rollback Origin Readiness
+
+This is an internal execution-safety rule. Do not expose rollback readiness on the normal user-facing execution confirmation path.
+
+Rules:
+
+1. `action=move` items entering execution SHOULD have `rollback_origin_kind`.
+2. `rollback_origin_kind` can be:
+   - `drive_folder`: original Drive parent folder token is known.
+   - `drive_root`: original location is the Drive root.
+   - `wiki_node`: original Wiki parent node token is known.
+   - `wiki_space_root`: original location is the Wiki space root and `rollback_origin_space_id` is known.
+3. If `rollback_origin_kind` is missing or `unknown`, the agent MUST try to resolve it before execution from `ResourceItem.parent_token`, traversal context, `source_path`, `space_id`, or `wiki +node-get` for Wiki resources.
+4. If the origin is still unresolved, set `rollback_supported=false` and `rollback_blocker`, but do not block the entire execution solely because recovery is unsupported.
+5. Target resolution remains mandatory: a move item with unresolved `target_parent_token` MUST NOT execute.
+6. Internal recovery metadata MUST NOT change `DisplayItem` output on the normal successful path.
+
+## DisplayItem
+
+`DisplayItem` is for user-facing output. It MUST NOT expose raw internal enum values.
+
+| Display Field | Source |
+|---------------|--------|
+| `序号` | Page-local row number |
+| `当前位置` | `source_path` |
+| `标题` | `title` |
+| `类型` | Human-readable `type` when possible; raw type is acceptable only when there is no clearer label |
+| `目标位置` | `target_path` |
+| `动作` | Convert from `action` using action display map |
+| `原因` | `reason` |
+| `置信度` | Convert from `confidence` using confidence display map |
+| `待确认原因` | `needs_review_reason` |
+
+Action display map:
+
+| Internal Enum | User-Facing Label |
+|---------------|-------------------|
+| `keep` | 保持不变 |
+| `create_folder` | 创建文件夹 |
+| `create_node` | 创建知识库节点 |
+| `move` | 移动到目标目录 |
+
+`needs_review=true` is a review state, not an action. A review item MUST still use `action=move` when its target is the manual confirmation target.
+
+### Manual Confirmation Target
+
+Resources with insufficient classification evidence MUST be moved to the manual confirmation target after the user confirms execution.
+
+Rules:
+
+1. The target tree MUST include `待人工确认` or an equivalent user-specified manual confirmation path.
+2. For Drive scopes, the manual confirmation target is a Drive folder.
+3. For Wiki scopes, the manual confirmation target is a Wiki node.
+4. Plan items for these resources MUST set `needs_review=true`, preserve `needs_review_reason`, set `target_path` to the manual confirmation target, and set `action=move`.
+5. Do not leave these items in their original location by default.
+
+Confidence display map:
+
+| Internal Enum | User-Facing Label |
+|---------------|-------------------|
+| `high` | 高，证据明确 |
+| `medium` | 中，有依据但建议确认 |
+| `low` | 低，需要人工确认 |
+
+### Plan Pagination
+
+| Output Area | Rule |
+|-------------|------|
+| Plan details | Show at most 20 plan items per page |
+| Plan item count > 20 | MUST paginate; do not output all details at once |
+| Plan item count > 500 | First response MUST show overview and filters only; no detail rows until user asks |
+| Pagination | Affects display only; complete `plan_items` MUST remain internal |
+
+### Target Tree And Plan Overview
+
+```text
+建议目标目录结构
+
+<target_tree>
+
+移动 / 创建计划总览
+
+本次计划共 <total_count> 项：
+- 创建目录 / 节点：<create_count> 项
+- 移动资源：<move_count> 项（其中来源目录本体：<source_container_move_count> 项）
+- 保持不变：<keep_count> 项
+- 待人工确认：<review_count> 项
+- 高置信度：<high_count> 项
+- 中置信度：<medium_count> 项
+- 低置信度：<low_count> 项
+
+你可以选择：
+1. 查看第 1 页明细
+2. 只看将创建的目录 / 节点
+3. 只看待人工确认项
+4. 只看高置信度移动项
+5. 进入下一步：确认执行计划
+```
+
+If `total_count > 500`, say:
+
+```text
+计划较大，我先只展示总览。
+```
+
+### Plan Revision Protocol
+
+When the user corrects or adjusts the plan in `PLAN_GENERATION` or `EXEC_CONFIRM`, the agent MUST treat it as a full-plan revision unless the user explicitly asks to execute only the corrected items.
+
+Revision triggers include:
+
+- Adjusting classification rules.
+- Adjusting target folder / Wiki node structure.
+- Changing one or more resources' target paths.
+- Excluding resources from movement.
+- Restricting execution to high-confidence items.
+- Moving a whole category to another target.
+- Changing manual confirmation handling.
+- Changing source container cleanup or retention handling.
+
+Internal rules:
+
+1. Record the user correction in `last_user_correction`.
+2. Mark the previous `plan_items` as stale.
+3. Recompute `classification_rules`, `target_tree`, and complete `plan_items` when needed.
+4. Increment `plan_version`.
+5. Set `active_plan_items` to the complete revised plan.
+6. Append a short internal summary to `plan_revision_history`.
+7. Do not execute stale `plan_items`.
+8. Do not execute only the delta unless the user explicitly asks for partial execution.
+
+User-facing output:
+
+```text
+已按你的修改重新生成完整计划。
+
+已应用的修改：
+- <correction item 1>
+- <correction item 2>
+
+当前完整计划：
+- 创建目录 / 节点：<create_count> 项
+- 移动资源：<move_count> 项
+- 保持不变：<keep_count> 项
+- 待人工确认：<review_count> 项
+
+说明：后续执行默认基于这份完整修正版计划，不是只执行刚才的修正项。
+
+你可以选择：
+1. 查看修正版计划总览
+2. 查看本次修改涉及的资源
+3. 进入下一步：确认执行计划
+4. 继续调整
+```
+
+If the user explicitly asks to execute only the corrected items, ask for confirmation before execution:
+
+```text
+你明确要求只执行本次修改涉及的 <count> 项。其余计划项不会执行。
+请确认是否只执行这些项？
+```
+
+### Plan Detail Page
+
+```text
+移动 / 创建计划，第 <page>/<total_pages> 页，每页 20 项
+
+| 序号 | 当前位置 | 标题 | 类型 | 目标位置 | 动作 | 原因 | 置信度 | 待确认原因 |
+|------|----------|------|------|----------|------|------|--------|------------|
+
+还有 <remaining_pages> 页未展示。
+
+你可以回复：
+1. 继续看下一页
+2. 只看待人工确认项
+3. 只看低置信度项
+4. 进入下一步：确认执行计划
+```
+
+## State: EXEC_CONFIRM
+
+Entry: user asks to view execution confirmation or continue toward execution.
+
+MUST:
+
+1. Show write-operation summary:
+   - 将创建哪些目录 / 节点
+   - 将移动哪些资源
+   - 将移动哪些来源目录本体（如有）
+   - 哪些资源仍需人工确认
+   - 预计影响范围
+2. Use `active_plan_items` from the latest complete plan.
+3. Show `Permission Inheritance Notice`.
+4. Ask for execution scope using `Execution Confirmation`.
+5. Reference `Non-goals` for operations excluded from this workflow.
+6. Wait for explicit confirmation.
+
+### Permission Inheritance Notice
+
+Before execution confirmation, MUST show this notice:
+
+```text
+权限提示：移动资源后，资源权限可能随目标位置变化，可见范围或协作权限可能变化。本 workflow 不会自动修改权限。
+```
+
+### Execution Confirmation
+
+When the user wants execution, ask for execution scope:
+
+Execution confirmation options MUST be numbered by currently available choices. Do not show disabled choices, and do not ask the user to reply with skipped numbers.
+
+If a plan detail page is currently active:
+
+```text
+请确认执行范围：
+
+1. 执行完整计划：<total_count> 项
+2. 只执行当前页：<current_page_count> 项
+3. 只执行高置信度项：<high_confidence_count> 项
+4. 暂不执行，只保留方案
+
+本 workflow 只执行已确认范围内的创建、移动和必要的单资源权限申请；不会重命名任何资源。
+```
+
+If no plan detail page is currently active:
+
+```text
+请确认执行范围：
+
+1. 执行完整计划：<total_count> 项
+2. 只执行高置信度项：<high_confidence_count> 项
+3. 暂不执行，只保留方案
+
+如需只执行某一页，请先查看计划明细页。
+
+本 workflow 只执行已确认范围内的创建、移动和必要的单资源权限申请；不会重命名任何资源。
+```
+
+If there is no pagination, still state the total number of plan items covered by confirmation.

package/skills/lark-drive/references/lark-drive-workflow-knowledge-organize-rollback.md

@@ -0,0 +1,308 @@
+# 知识整理工作流：Rollback
+
+Loaded by states: `ROLLBACK_CONFIRM`, `ROLLBACK`, `ROLLBACK_VERIFY`, `ROLLBACK_CLEANUP_CONFIRM`, `ROLLBACK_CLEANUP`, `ROLLBACK_CLEANUP_VERIFY`.
+
+This file owns recovery plan generation, recovery confirmation, recovery execution, recovery verification, cleanup confirmation, cleanup execution, and cleanup verification. It also defines the internal `rollback_snapshot` and `execution_journal` contracts.
+
+It MUST NOT generate organization plans, revise classification rules, execute unconfirmed deletes, rename resources, modify permissions, or use `wiki +move` docs-to-wiki mode.
+
+User-facing language should use "恢复到整理前的位置" / "恢复". Internal state and field names may use `rollback`.
+
+## Required Context
+
+Before executing rules in this file:
+
+1. `active_plan_items`, `execution_scope`, `target_scope`, and `path_token_map` MUST already exist.
+2. `rollback_snapshot` MUST have been built before the first write operation in `EXECUTE`.
+3. `execution_journal` MUST contain write-operation results from `EXECUTE`.
+4. Follow command syntax and risk behavior from referenced shortcut docs.
+5. Follow `Non-goals` from the main workflow entry.
+
+## Normal Path Visibility
+
+Do not mention rollback, recovery readiness, snapshot, or journal on the normal successful execution path.
+
+Load this file only after:
+
+1. Execution failed after one or more successful moves and the user chose to try restoring.
+2. Verification found serious mismatches and the user chose to try restoring.
+3. The user explicitly asks to rollback / recover the previous organization run.
+
+## Internal State Contracts
+
+### RollbackSnapshot
+
+`rollback_snapshot` records original locations before any write command.
+
+Fields:
+
+| Field | Meaning |
+|-------|---------|
+| `plan_id` | Matching `PlanItem.plan_id` |
+| `source_kind` | `drive` / `wiki` |
+| `title` | Resource title |
+| `type` | Resource type used by move commands |
+| `original_token` | Original Drive token when applicable |
+| `original_node_token` | Original Wiki node token when applicable |
+| `original_parent_kind` | `drive_folder` / `drive_root` / `wiki_node` / `wiki_space_root` / `unknown` |
+| `original_parent_token` | Original parent token; empty for root markers |
+| `original_space_id` | Original Wiki space ID when restoring to Wiki space root |
+| `original_path` | Original path before organization |
+| `planned_target_parent_token` | Planned target parent token |
+| `planned_target_path` | Planned target path |
+| `rollback_supported` | Whether this item can be restored automatically |
+| `rollback_blocker` | Reason when `rollback_supported=false` |
+
+Rules:
+
+1. Store compact fields only. Do not store full API responses.
+2. `drive_root` and `wiki_space_root` are valid origins; do not treat empty parent token as missing when the root marker is known.
+3. Items without reliable origin can still execute, but MUST be marked `rollback_supported=false`.
+
+### ExecutionJournal
+
+`execution_journal` records every write attempt.
+
+Fields:
+
+| Field | Meaning |
+|-------|---------|
+| `journal_id` | Stable journal row ID |
+| `plan_id` | Matching `PlanItem.plan_id` when applicable |
+| `operation` | `create_folder` / `create_node` / `move_drive` / `move_wiki_node` / `delete_created_folder` / `delete_created_node` |
+| `status` | `success` / `failed` / `pending` |
+| `input_token` | Token supplied to the command |
+| `input_node_token` | Wiki node token supplied to the command |
+| `input_parent_token` | Source parent token when known |
+| `target_parent_token` | Target parent token supplied to the command |
+| `returned_token` | Token returned by the command |
+| `returned_node_token` | Wiki node token returned by the command |
+| `returned_parent_token` | Parent token returned by the command |
+| `task_id` | Async task ID when returned |
+| `next_command` | Async continuation command when returned |
+| `error` | Error summary when failed |
+| `created_by_workflow` | Whether the resource was created by this workflow run |
+| `rollback_eligible` | Whether this successful operation can be included in `rollback_plan` |
+
+Rules:
+
+1. Append a journal entry immediately after each write attempt.
+2. `create_folder` and `create_node` entries MUST set `created_by_workflow=true`.
+3. Successful `move_drive` and `move_wiki_node` entries may set `rollback_eligible=true` only when matching snapshot origin is supported.
+4. Failed or pending moves MUST NOT enter automatic recovery execution.
+5. Async operations are `pending` until `drive +task_result` proves completion.
+
+## State: ROLLBACK_CONFIRM
+
+Entry: user chose to try restoring after execution failure / verification mismatch, or explicitly asked to rollback.
+
+MUST:
+
+1. Generate `rollback_plan` from successful eligible move journal entries.
+2. Use `execution_journal` current token / current node token as the recovery source.
+3. Use `rollback_snapshot` original origin as the recovery target.
+4. Generate recovery items in reverse successful move order.
+5. Exclude failed, pending, and unsupported items from executable recovery.
+6. Do not include delete actions in `rollback_plan`.
+7. Ask for explicit restore execution confirmation.
+
+Confirmation output:
+
+```text
+可恢复范围如下：
+
+| 项目 | 数量 |
+|------|------|
+| 可尝试恢复到原位置 | <recoverable_move_count> |
+| 无法安全自动恢复 | <unsupported_count> |
+| 未完成 / 等待中的移动 | <pending_count> |
+| 本次新建目录 / 节点 | <created_container_count> |
+
+恢复操作只会尝试把已成功移动的资源移回原位置，不会删除、重命名或修改权限。是否执行恢复？
+```
+
+If no move can be restored automatically, report that no automatic restore is available and move to `DONE`.
+
+## Recovery Command Rules
+
+Use only these command forms:
+
+```bash
+# Drive resource back to original parent folder
+lark-cli drive +move \
+  --file-token <current_token> \
+  --type <type> \
+  --folder-token <original_parent_token>
+
+# Drive resource back to root
+lark-cli drive +move \
+  --file-token <current_token> \
+  --type <type>
+
+# Wiki node back to original parent node
+lark-cli wiki +move \
+  --node-token <current_node_token> \
+  --target-parent-token <original_parent_token>
+
+# Wiki node back to original space root
+lark-cli wiki +move \
+  --node-token <current_node_token> \
+  --target-space-id <original_space_id>
+```
+
+MUST NOT:
+
+- Use `wiki +move` docs-to-wiki mode.
+- Move using path strings.
+- Recover failed or pending moves as if they succeeded.
+- Delete created folders / nodes in `ROLLBACK`.
+
+## State: ROLLBACK
+
+Entry: user explicitly confirmed restore execution.
+
+MUST:
+
+1. Execute only confirmed `rollback_plan` items.
+2. Execute reverse moves in reverse successful move order.
+3. Continue async move tasks with `drive +task_result` when needed.
+4. Record recovery success / failure per rollback item.
+5. Stop on blockers that make following recovery items unsafe.
+
+Progress output should stay concise:
+
+```text
+恢复进度：已尝试 <done>/<total> 项，失败 <failed_count> 项。
+```
+
+## State: ROLLBACK_VERIFY
+
+Entry: recovery execution finished.
+
+MUST:
+
+1. Rescan the relevant Drive folder / Wiki nodes.
+2. Compare each rollback item with its original origin.
+3. Mark status per item.
+4. If cleanup candidates clearly remain from this workflow run, transition to `ROLLBACK_CLEANUP_CONFIRM`.
+5. Do not ask for deletion confirmation in this state.
+
+Verification table:
+
+| plan_id | 标题 | 原位置 | 当前实际位置 | 状态 | 失败原因 |
+|---------|------|--------|--------------|------|----------|
+
+Status values:
+
+| Status | Meaning |
+|--------|---------|
+| `rollback_success` | Resource is back under the original parent / root |
+| `rollback_failed` | Resource is still outside the original origin |
+| `missing` | Resource cannot be found |
+| `needs_manual_review` | Actual state is ambiguous or affected by external changes |
+
+Do not delete anything from this state.
+
+## State: ROLLBACK_CLEANUP_CONFIRM
+
+Entry: cleanup candidates exist after recovery, or user asks to view / perform cleanup after recovery.
+
+Cleanup is optional and separate from recovery. It may delete resources, so it requires separate confirmation.
+
+Candidate rules:
+
+1. Candidate MUST have `created_by_workflow=true` in `execution_journal`.
+2. Candidate MUST be a Drive folder or Wiki node created by this workflow run.
+3. Candidate MUST currently be empty, or contain only workflow-created cleanup candidates that are themselves safe to delete.
+4. Candidate MUST NOT contain original resources, unknown resources, rollback-failed resources, or user-created resources.
+5. If child origin is uncertain, mark the candidate `cleanup_blocked`.
+
+Generate `rollback_cleanup_plan` with:
+
+| Field | Meaning |
+|-------|---------|
+| `cleanup_id` | Stable cleanup row ID |
+| `type` | `drive_folder` / `wiki_node` |
+| `path` | Current path |
+| `token` | Folder token or node token |
+| `depth` | Current path depth |
+| `safe_to_delete` | Whether deletion is allowed after confirmation |
+| `blocker` | Reason when deletion is blocked |
+
+Confirmation output:
+
+```text
+恢复已完成。本次整理新建的部分空目录 / 节点如下，是否需要删除？
+
+| 项目 | 数量 |
+|------|------|
+| 可删除的新建空目录 / 节点 | <safe_count> |
+| 不可删除，需人工确认 | <blocked_count> |
+
+注：删除只会作用于本次 workflow 新建且当前可安全清理的空目录 / 节点。
+```
+
+If the user wants details, paginate cleanup items at 20 rows per page.
+
+## State: ROLLBACK_CLEANUP
+
+Entry: user explicitly confirmed cleanup deletion.
+
+MUST:
+
+1. Delete only `safe_to_delete=true` cleanup items.
+2. Delete deepest paths first.
+3. Record delete results in `rollback_cleanup_results`.
+4. Continue async delete tasks with `drive +task_result` when needed.
+
+Command forms:
+
+```bash
+# Delete workflow-created Drive folder
+lark-cli drive +delete \
+  --file-token <folder_token> \
+  --type folder \
+  --yes
+
+# Delete workflow-created Wiki node
+lark-cli wiki +node-delete \
+  --node-token <node_token> \
+  --obj-type wiki \
+  --include-children=true \
+  --yes
+```
+
+`--yes` is allowed only after the user explicitly confirmed cleanup deletion.
+
+MUST NOT:
+
+- Delete original resources.
+- Delete unknown resources.
+- Delete rollback-failed resources.
+- Delete non-empty folders / nodes that contain anything outside cleanup candidates.
+- Delete a knowledge space.
+
+## State: ROLLBACK_CLEANUP_VERIFY
+
+Entry: cleanup deletion finished.
+
+MUST:
+
+1. Verify each confirmed cleanup target is gone.
+2. Report failed or pending deletes.
+3. Stop after reporting cleanup results.
+
+Verification table:
+
+| 类型 | 路径 | token | 状态 | 失败原因 |
+|------|------|-------|------|----------|
+
+Status values:
+
+| Status | Meaning |
+|--------|---------|
+| `deleted` | Cleanup target was deleted |
+| `delete_pending` | Async deletion is still pending |
+| `delete_failed` | Delete command failed |
+| `still_exists` | Target still exists after deletion attempt |
+| `skipped` | Target was not safe to delete or user did not confirm it |