@harmonyos-arkts/d2h 0.1.11 → 0.1.13

package/skills/d2h-page-spec-generate/SKILL.md

@@ -1,206 +1,206 @@
----
-name: d2h-page-spec-generate
-description: Generate an AI-authored pages.json plan and page-scoped Android-to-HarmonyOS spec.md files from migration Facts, `.migration/utg/page.json`, source code, and existing HarmonyOS implementation, then build batch_report.md with the bundled renderer. Use when pages, dialogs, sheets, or page modes need evidence-backed development specifications and ordered execution records without copied UI artifacts.
----
-
-# Page Spec generation
-
-Generate one implementation-ready `spec.md` for every Android page, dialog, sheet, and behaviorally distinct page mode. The AI determines page boundaries, evidence mapping, dependencies, and development order by reading the actual migration workspace and source code.
-
-Do not invoke task-planning, graph-generation, migration, or page-validation scripts. Do not modify Android source, HarmonyOS source, `.migration/spec/`, `.migration/utg/`, `.migration/tasks/`, or the migration report.
-
-## Inputs
-
-Resolve these paths before writing:
-
-- `migration_root`: workspace containing `.migration/`.
-- `spec_root`: `<migration_root>/.migration/spec`; require `index.json` and `facts/`.
-- `page_plan`: require `<migration_root>/.migration/utg/page.json`; this is the source-derived page and navigation plan produced by the UTG stage.
-- `android_root`: `.migration/config.json.androidProject`, unless explicitly supplied.
-- `harmony_root`: `.migration/config.json.harmonyProject`, resolved relative to `migration_root` when not absolute, unless explicitly supplied.
-- `legacy_tasks_root`: optional `<migration_root>/.migration/tasks`; use existing briefs, core facts, source context, and acceptance files only as read-only evidence from an older flow.
-- `output_root`: default `<migration_root>/.migration/page-specs`.
-
-Facts and legacy Task artifacts are indexes, not substitutes for Android source. Existing HarmonyOS files and tests are implementation evidence, not proof that a behavior is complete.
-
-## Output contract
-
-Each page unit contains only `spec.md`. `pages.json` and `batch_report.md` live at the output root:
-
-```text
-.migration/page-specs/
-├── pages.json
-├── batch_report.md
-├── page_0001_<name>-<id>/
-│   └── spec.md
-├── page_0002_<name>-<id>/
-│   └── spec.md
-└── ...
-```
-
-Directory names encode the AI-selected development order. Use a four-digit sequence and a stable unique suffix derived from the strongest page identity already present in Facts or `page.json`. Re-running against unchanged evidence must preserve existing directory names and order unless the evidence proves the previous boundary or dependency order was wrong.
-
-## Workflow
-
-### 1. Read the complete evidence index
-
-1. Read `.migration/spec/index.json`, `facts/app.json`, all `facts/pages/*.json`, `facts/interactions.json`, and `facts/unresolved.json`.
-2. Read `.migration/utg/page.json` completely. Use `pages[]` as the page/navigation index and consume each node's `node_id`, `kind`, `label`, `declared_at`, `required_state`, `expected`, `reachable`, `depth`, `ui_sequence`, `path_text`, `steps`, and `skip_reason` when present.
-3. Treat `page.json.source.utg` and `page.json.source.click_paths` as provenance links. Read those referenced UTG artifacts only when page boundaries, transitions, guards, or selectors need clarification.
-4. If legacy `.migration/tasks/` exists, read its package briefs and associated `core-facts.json`, `source-context.json`, and `acceptance.json` only to recover behavior refs and source closure. Never inherit its package boundary blindly and never execute its task commands.
-5. Read the current migration report to understand existing mappings and unresolved items, without treating report status as proof of implementation.
-6. Inspect HarmonyOS route registration, `.ets`/`.ts` components, shared state, resources, and tests to distinguish existing implementation from planned work.
-
-### 2. Determine page units with AI reasoning
-
-1. Start from `page.json.pages[]`, then join each page node to Facts surfaces, entries, controls, and interactions by stable ref, declared source, transition, and source behavior.
-2. Treat independently reachable pages, dialogs, sheets, and behaviorally distinct add/edit or selection modes as separate units when they have their own user-visible lifecycle or acceptance flow.
-3. Prefer exact ref or normalized identity matches between `page.json.pages[].node_id` and Facts surfaces. Then use labels, `declared_at`, parent relations, navigation steps, source symbols, controls, and Android source behavior.
-4. Never assign behavior from name similarity alone. Record ambiguous mappings in the owning Spec under “未决项与平台差异”.
-5. `capture=false`, an empty `expected`, or a `skip_reason` does not remove a source-proven page. Use those fields as evidence limitations and verify the page through Facts and Android source.
-6. Do not create a fake page for background-only capabilities. Assign startup, notification, widget, receiver, persistence, or other shared responsibilities to the earliest real page that requires them and list downstream consumers.
-7. Legacy page work packages may contain many unrelated surfaces. Split them by actual page lifecycle and behavior ownership rather than retaining the old aggregate.
-
-### 3. Decide development order
-
-Rate each dimension using an integer from 0 to 5, then calculate the score using the following formula:
-
-`page_score = enablement × 9 + ordinary_reachability × 6 + shallowness × 5`（满分 100，分数越高越优先）。
-
-- **Enablement (45%)** — use the highest evidence-backed enablement rating among the page's REQs. `5`: difficult to mock or bound, ambiguous in data ownership, and correctness-relevant across many features. `3`: reused across several features but cleanly isolatable. `1`: page-local. Repeated persistence keys, storage operations, data-flow hops, and consumers are evidence; a feature name is not.
-- **Ordinary reachability (30%)** — `5`: reachable in normal app state. `3`: needs a common business state such as existing data, login, or permission. `0`: first-launch only or reachable only after clearing/resetting app-global state. Use intermediate ratings where evidence supports them.
-- **Shallowness (25%)** — `5`: launch/main page; `4`: one page navigation; `3`: two; `2`: three; `1`: four or more. Derive depth from page boundaries in `page-path`, not click count. `__shared_capability__` uses neutral `3`.
-
-When ordering, first satisfy evidence-backed prerequisites so that data or state providers precede their consumers. Sort all remaining pages by page_score in descending order, breaking ties by the normalized stable page_id in ascending order. Finally, assign consecutive order values starting from 1. Prerequisites may override score-based ordering; no other arbitrary reordering is allowed.
-
-Write the ordered decisions to `<output_root>/pages.json` before creating page directories. Also write the ordinal, dependencies, and concise rationale into each Spec.
-
-Use schema `d2h-page-plan/v1`. Every `pages[]` item must contain:
-
-- consecutive one-based `order`;
-- stable `page_id`, `kind`, `package`, and `page_path`;
-- `spec_refs` and `req_refs` backed by Facts/source evidence;
-- integer `page_score`;
-- `decision_ledger.enablement.rating`, `ordinary_reachability.rating`, and `shallowness.rating`, with evidence and a concise calculation/rationale.
-
-`package` must exactly match `page_NNNN_<name>-<id>`. Every `page.json` node must be represented by a page item or by an explicit exclusion/unmatched entry with a reason. The AI authors and checks this plan; do not use it as a substitute for reading source.
-
-### 4. Verify source before writing
-
-1. Open every cited Android `sourceEvidence.file` at the cited symbol or line.
-2. Follow handlers, repositories, state transitions, navigation, persistence, error paths, and platform side effects far enough to establish the observable result.
-3. Use `page.json` navigation steps, selectors, guards, expected-arrival rules, required state, and depth to reconstruct the semantic arrival path. Source-derived reachability is planning evidence, not runtime confirmation.
-4. Translate selectors into semantic control names only when Facts, resources, or Android source support the mapping. Keep missing or ambiguous selectors explicitly unresolved.
-5. Verify every listed Android path exists under `android_root`. Verify every HarmonyOS path marked `existing` exists under `harmony_root`; otherwise mark it `planned`.
-
-### 5. Write only `spec.md`
-
-Use these headings in every page Spec:
-
-```markdown
-# <页面名称> 迁移 Spec
-
-## 页面范围
-
-- 页面标识：<稳定标识>
-- 页面类型：<page | dialog | sheet | mode | other>
-- Android 到达路径：<从真实入口开始的语义路径>
-- 负责范围：<本 Spec 负责的状态和行为>
-- 排除范围：<相邻但属于其他 Spec 的责任>
-
-## 开发顺序
-
-- 顺序：<NNNN>
-- 前置依赖：<无或其他页面标识/共享能力>
-- 排序理由：<基于前置依赖和页面评分的说明>
-
-## 页面功能
-
-- F-001：<用户动作及其可观察结果。>
-
-## UI 操作与验收
-
-### F-001
-
-1. <从真实应用入口进入当前页面。>
-2. <定位并操作具有语义名称的控件。>
-3. <断言可见状态、导航、数据效果或错误结果。>
-
-## Android 证据
-
-| 证据 | 路径 / Ref | 支持的结论 |
-|---|---|---|
-| Facts | <surface/entry/control/interaction ref> | <范围或行为> |
-| Android 源码 | <android_root 相对路径及符号/行> | <触发、分支和结果> |
-| UTG Page | `.migration/utg/page.json` 中的 <node_id> | <到达路径、深度、前置状态、导航步骤与证据限制> |
-
-## HarmonyOS 实现范围
-
-| 路径 | 状态 | 预期职责 / 校验点 |
-|---|---|---|
-| <harmony_root 相对路径> | existing 或 planned | <页面实现、共享影响和验收点> |
-
-## 未决项与平台差异
-
-- <没有时明确写“无”。>
-```
-
-When a page has no independent interaction, write one display/reachability feature and acceptance sequence instead of leaving the feature sections empty.
-
-### 6. Generate `batch_report.md`
-
-After all page Specs are complete, generate `<output_root>/batch_report.md` from `pages.json` with the bundled renderer:
-
-```bash
-python scripts/build_batch_report.py \
-  --pages-plan <output_root>/pages.json \
-  --output-root <output_root>
-```
-
-The script requires every planned package to contain `spec.md`, never requires `ui-design.md`, and refuses to overwrite an existing report.
-
-The report must contain:
-
-- the source `pages.json` path and SHA-256;
-- generation timestamp and ordered page count;
-- one queue row per page with stable task ID `PAGE-NNNN`, page identity, relative `spec.md` link, development status, build status, validation status, and blocker;
-- one detail section per task with dependencies, implementation files, test files, implementation commit or source snapshot, build evidence, test evidence, last update, blocker, and chronological execution notes;
-- summary counts that exactly match the queue and detail sections.
-
-Use these status values:
-
-- development: `pending | in_progress | implemented | blocked`;
-- build: `not_run | passed | failed | blocked`;
-- validation: `not_run | passed | failed | blocked`.
-
-Initial generation uses `pending`, `not_run`, and `not_run`, with empty implementation, test, evidence, commit/snapshot, timestamp, and blocker fields. Do not infer completion from existing HarmonyOS files or local test artifacts.
-
-Once development has started, never rerun the renderer or overwrite `batch_report.md`. Update the existing queue row, detail section, counts, and notes in place while preserving execution history. If `pages.json`, the Spec set, or order no longer matches an existing report, stop and report the mismatch for AI reconciliation instead of silently resetting statuses.
-
-## Quality gates
-
-- Every known source-proven page, dialog, sheet, and behaviorally distinct mode has exactly one `spec.md`, or its ownership is explicitly assigned to another Spec.
-- Every distinct interaction has a unique `F-xxx`, and feature IDs match UI operation/acceptance sections one-to-one.
-- Each feature states a user action and observable result, not an implementation instruction.
-- Navigation, state changes, persistence, destructive confirmation, external intents, cancellation, dismissal, and error behavior remain explicit.
-- Facts refs, `page.json` node IDs, Android source paths, and HarmonyOS paths are real and correctly classified.
-- Existing HarmonyOS code or tests never cause a feature to be marked complete without current build and executed test evidence.
-- Uncertainty remains explicit. Do not invent control names, outcomes, source mappings, runtime captures, or implementation status.
-- Each `page_NNNN_<name>-<id>/` directory contains exactly one file named `spec.md`.
-- `output_root` contains only `pages.json`, `batch_report.md`, and page directories; it contains no copied UI evidence, UI design, or generated validation artifact.
-- Every page directory has exactly one queue row and one detail section in `batch_report.md`; task IDs, order, links, statuses, and counts agree.
-- A task is complete only when development is `implemented` and both build and validation are `passed` with current evidence.
-
-## Result
-
-Return:
-
-- the ordered page directory list and ordering rationale;
-- the number of generated, updated, and unchanged Specs;
-- the absolute `pages.json` path;
-- unreachable pages, capture-disabled nodes, and pages with incomplete arrival rules in `page.json`;
-- ambiguous mappings and unmatched Facts;
-- unresolved selector steps;
-- legacy aggregate packages that were split;
-- the absolute `batch_report.md` path;
-- the absolute `output_root`.
+---
+name: d2h-page-spec-generate
+description: Generate an AI-authored pages.json plan and page-scoped Android-to-HarmonyOS spec.md files from migration Facts, `.migration/utg/page.json`, source code, and existing HarmonyOS implementation, then build batch_report.md with the bundled renderer. Use when pages, dialogs, sheets, or page modes need evidence-backed development specifications and ordered execution records without copied UI artifacts.
+---
+
+# Page Spec generation
+
+Generate one implementation-ready `spec.md` for every Android page, dialog, sheet, and behaviorally distinct page mode. The AI determines page boundaries, evidence mapping, dependencies, and development order by reading the actual migration workspace and source code.
+
+Do not invoke task-planning, graph-generation, migration, or page-validation scripts. Do not modify Android source, HarmonyOS source, `.migration/spec/`, `.migration/utg/`, `.migration/tasks/`, or the migration report.
+
+## Inputs
+
+Resolve these paths before writing:
+
+- `migration_root`: workspace containing `.migration/`.
+- `spec_root`: `<migration_root>/.migration/spec`; require `index.json` and `facts/`.
+- `page_plan`: require `<migration_root>/.migration/utg/page.json`; this is the source-derived page and navigation plan produced by the UTG stage.
+- `android_root`: `.migration/config.json.androidProject`, unless explicitly supplied.
+- `harmony_root`: `.migration/config.json.harmonyProject`, resolved relative to `migration_root` when not absolute, unless explicitly supplied.
+- `legacy_tasks_root`: optional `<migration_root>/.migration/tasks`; use existing briefs, core facts, source context, and acceptance files only as read-only evidence from an older flow.
+- `output_root`: default `<migration_root>/.migration/page-specs`.
+
+Facts and legacy Task artifacts are indexes, not substitutes for Android source. Existing HarmonyOS files and tests are implementation evidence, not proof that a behavior is complete.
+
+## Output contract
+
+Each page unit contains only `spec.md`. `pages.json` and `batch_report.md` live at the output root:
+
+```text
+.migration/page-specs/
+├── pages.json
+├── batch_report.md
+├── page_0001_<name>-<id>/
+│   └── spec.md
+├── page_0002_<name>-<id>/
+│   └── spec.md
+└── ...
+```
+
+Directory names encode the AI-selected development order. Use a four-digit sequence and a stable unique suffix derived from the strongest page identity already present in Facts or `page.json`. Re-running against unchanged evidence must preserve existing directory names and order unless the evidence proves the previous boundary or dependency order was wrong.
+
+## Workflow
+
+### 1. Read the complete evidence index
+
+1. Read `.migration/spec/index.json`, `facts/app.json`, all `facts/pages/*.json`, `facts/interactions.json`, and `facts/unresolved.json`.
+2. Read `.migration/utg/page.json` completely. Use `pages[]` as the page/navigation index and consume each node's `node_id`, `kind`, `label`, `declared_at`, `required_state`, `expected`, `reachable`, `depth`, `ui_sequence`, `path_text`, `steps`, and `skip_reason` when present.
+3. Treat `page.json.source.utg` and `page.json.source.click_paths` as provenance links. Read those referenced UTG artifacts only when page boundaries, transitions, guards, or selectors need clarification.
+4. If legacy `.migration/tasks/` exists, read its package briefs and associated `core-facts.json`, `source-context.json`, and `acceptance.json` only to recover behavior refs and source closure. Never inherit its package boundary blindly and never execute its task commands.
+5. Read the current migration report to understand existing mappings and unresolved items, without treating report status as proof of implementation.
+6. Inspect HarmonyOS route registration, `.ets`/`.ts` components, shared state, resources, and tests to distinguish existing implementation from planned work.
+
+### 2. Determine page units with AI reasoning
+
+1. Start from `page.json.pages[]`, then join each page node to Facts surfaces, entries, controls, and interactions by stable ref, declared source, transition, and source behavior.
+2. Treat independently reachable pages, dialogs, sheets, and behaviorally distinct add/edit or selection modes as separate units when they have their own user-visible lifecycle or acceptance flow.
+3. Prefer exact ref or normalized identity matches between `page.json.pages[].node_id` and Facts surfaces. Then use labels, `declared_at`, parent relations, navigation steps, source symbols, controls, and Android source behavior.
+4. Never assign behavior from name similarity alone. Record ambiguous mappings in the owning Spec under “未决项与平台差异”.
+5. `capture=false`, an empty `expected`, or a `skip_reason` does not remove a source-proven page. Use those fields as evidence limitations and verify the page through Facts and Android source.
+6. Do not create a fake page for background-only capabilities. Assign startup, notification, widget, receiver, persistence, or other shared responsibilities to the earliest real page that requires them and list downstream consumers.
+7. Legacy page work packages may contain many unrelated surfaces. Split them by actual page lifecycle and behavior ownership rather than retaining the old aggregate.
+
+### 3. Decide development order
+
+Rate each dimension using an integer from 0 to 5, then calculate the score using the following formula:
+
+`page_score = enablement × 9 + ordinary_reachability × 6 + shallowness × 5`（满分 100，分数越高越优先）。
+
+- **Enablement (45%)** — use the highest evidence-backed enablement rating among the page's REQs. `5`: difficult to mock or bound, ambiguous in data ownership, and correctness-relevant across many features. `3`: reused across several features but cleanly isolatable. `1`: page-local. Repeated persistence keys, storage operations, data-flow hops, and consumers are evidence; a feature name is not.
+- **Ordinary reachability (30%)** — `5`: reachable in normal app state. `3`: needs a common business state such as existing data, login, or permission. `0`: first-launch only or reachable only after clearing/resetting app-global state. Use intermediate ratings where evidence supports them.
+- **Shallowness (25%)** — `5`: launch/main page; `4`: one page navigation; `3`: two; `2`: three; `1`: four or more. Derive depth from page boundaries in `page-path`, not click count. `__shared_capability__` uses neutral `3`.
+
+When ordering, first satisfy evidence-backed prerequisites so that data or state providers precede their consumers. Sort all remaining pages by page_score in descending order, breaking ties by the normalized stable page_id in ascending order. Finally, assign consecutive order values starting from 1. Prerequisites may override score-based ordering; no other arbitrary reordering is allowed.
+
+Write the ordered decisions to `<output_root>/pages.json` before creating page directories. Also write the ordinal, dependencies, and concise rationale into each Spec.
+
+Use schema `d2h-page-plan/v1`. Every `pages[]` item must contain:
+
+- consecutive one-based `order`;
+- stable `page_id`, `kind`, `package`, and `page_path`;
+- `spec_refs` and `req_refs` backed by Facts/source evidence;
+- integer `page_score`;
+- `decision_ledger.enablement.rating`, `ordinary_reachability.rating`, and `shallowness.rating`, with evidence and a concise calculation/rationale.
+
+`package` must exactly match `page_NNNN_<name>-<id>`. Every `page.json` node must be represented by a page item or by an explicit exclusion/unmatched entry with a reason. The AI authors and checks this plan; do not use it as a substitute for reading source.
+
+### 4. Verify source before writing
+
+1. Open every cited Android `sourceEvidence.file` at the cited symbol or line.
+2. Follow handlers, repositories, state transitions, navigation, persistence, error paths, and platform side effects far enough to establish the observable result.
+3. Use `page.json` navigation steps, selectors, guards, expected-arrival rules, required state, and depth to reconstruct the semantic arrival path. Source-derived reachability is planning evidence, not runtime confirmation.
+4. Translate selectors into semantic control names only when Facts, resources, or Android source support the mapping. Keep missing or ambiguous selectors explicitly unresolved.
+5. Verify every listed Android path exists under `android_root`. Verify every HarmonyOS path marked `existing` exists under `harmony_root`; otherwise mark it `planned`.
+
+### 5. Write only `spec.md`
+
+Use these headings in every page Spec:
+
+```markdown
+# <页面名称> 迁移 Spec
+
+## 页面范围
+
+- 页面标识：<稳定标识>
+- 页面类型：<page | dialog | sheet | mode | other>
+- Android 到达路径：<从真实入口开始的语义路径>
+- 负责范围：<本 Spec 负责的状态和行为>
+- 排除范围：<相邻但属于其他 Spec 的责任>
+
+## 开发顺序
+
+- 顺序：<NNNN>
+- 前置依赖：<无或其他页面标识/共享能力>
+- 排序理由：<基于前置依赖和页面评分的说明>
+
+## 页面功能
+
+- F-001：<用户动作及其可观察结果。>
+
+## UI 操作与验收
+
+### F-001
+
+1. <从真实应用入口进入当前页面。>
+2. <定位并操作具有语义名称的控件。>
+3. <断言可见状态、导航、数据效果或错误结果。>
+
+## Android 证据
+
+| 证据 | 路径 / Ref | 支持的结论 |
+|---|---|---|
+| Facts | <surface/entry/control/interaction ref> | <范围或行为> |
+| Android 源码 | <android_root 相对路径及符号/行> | <触发、分支和结果> |
+| UTG Page | `.migration/utg/page.json` 中的 <node_id> | <到达路径、深度、前置状态、导航步骤与证据限制> |
+
+## HarmonyOS 实现范围
+
+| 路径 | 状态 | 预期职责 / 校验点 |
+|---|---|---|
+| <harmony_root 相对路径> | existing 或 planned | <页面实现、共享影响和验收点> |
+
+## 未决项与平台差异
+
+- <没有时明确写“无”。>
+```
+
+When a page has no independent interaction, write one display/reachability feature and acceptance sequence instead of leaving the feature sections empty.
+
+### 6. Generate `batch_report.md`
+
+After all page Specs are complete, generate `<output_root>/batch_report.md` from `pages.json` with the bundled renderer:
+
+```bash
+python scripts/build_batch_report.py \
+  --pages-plan <output_root>/pages.json \
+  --output-root <output_root>
+```
+
+The script requires every planned package to contain `spec.md`, never requires `ui-design.md`, and refuses to overwrite an existing report.
+
+The report must contain:
+
+- the source `pages.json` path and SHA-256;
+- generation timestamp and ordered page count;
+- one queue row per page with stable task ID `PAGE-NNNN`, page identity, relative `spec.md` link, development status, build status, validation status, and blocker;
+- one detail section per task with dependencies, implementation files, test files, implementation commit or source snapshot, build evidence, test evidence, last update, blocker, and chronological execution notes;
+- summary counts that exactly match the queue and detail sections.
+
+Use these status values:
+
+- development: `pending | in_progress | implemented | blocked`;
+- build: `not_run | passed | failed | blocked`;
+- validation: `not_run | passed | failed | blocked`.
+
+Initial generation uses `pending`, `not_run`, and `not_run`, with empty implementation, test, evidence, commit/snapshot, timestamp, and blocker fields. Do not infer completion from existing HarmonyOS files or local test artifacts.
+
+Once development has started, never rerun the renderer or overwrite `batch_report.md`. Update the existing queue row, detail section, counts, and notes in place while preserving execution history. If `pages.json`, the Spec set, or order no longer matches an existing report, stop and report the mismatch for AI reconciliation instead of silently resetting statuses.
+
+## Quality gates
+
+- Every known source-proven page, dialog, sheet, and behaviorally distinct mode has exactly one `spec.md`, or its ownership is explicitly assigned to another Spec.
+- Every distinct interaction has a unique `F-xxx`, and feature IDs match UI operation/acceptance sections one-to-one.
+- Each feature states a user action and observable result, not an implementation instruction.
+- Navigation, state changes, persistence, destructive confirmation, external intents, cancellation, dismissal, and error behavior remain explicit.
+- Facts refs, `page.json` node IDs, Android source paths, and HarmonyOS paths are real and correctly classified.
+- Existing HarmonyOS code or tests never cause a feature to be marked complete without current build and executed test evidence.
+- Uncertainty remains explicit. Do not invent control names, outcomes, source mappings, runtime captures, or implementation status.
+- Each `page_NNNN_<name>-<id>/` directory contains exactly one file named `spec.md`.
+- `output_root` contains only `pages.json`, `batch_report.md`, and page directories; it contains no copied UI evidence, UI design, or generated validation artifact.
+- Every page directory has exactly one queue row and one detail section in `batch_report.md`; task IDs, order, links, statuses, and counts agree.
+- A task is complete only when development is `implemented` and both build and validation are `passed` with current evidence.
+
+## Result
+
+Return:
+
+- the ordered page directory list and ordering rationale;
+- the number of generated, updated, and unchanged Specs;
+- the absolute `pages.json` path;
+- unreachable pages, capture-disabled nodes, and pages with incomplete arrival rules in `page.json`;
+- ambiguous mappings and unmatched Facts;
+- unresolved selector steps;
+- legacy aggregate packages that were split;
+- the absolute `batch_report.md` path;
+- the absolute `output_root`.