tangweijie/fujian_water_biz_doc
1
0
Fork 0
Code Issues Pull Requests 12 Actions Packages Projects Releases 1 Wiki Activity
fujian_water_biz_doc/specs/011-frontend-speckit-alignment/tasks.md

13 KiB
Raw Blame History

Tasks: 前端 Speckit 协作对齐

Input: Design documents from /specs/011-frontend-speckit-alignment/ Prerequisites: plan.md (required), spec.md (required), research.md, data-model.md, contracts/, quickstart.md

Validation: 本 feature 以文档一致性、相对路径可读性与 evidence 闭环为主。必须完成 baseline.md、docs-validation.md、final-verdict.md 的更新；不强制执行 frontend build / lint，但仍必须执行与正式文档改动范围匹配的最小文档校验命令。

Organization: Tasks are grouped by user story so each slice can be completed, reviewed, and validated independently.

Format: [ID] [P?] [Story] Description

  • [P]: Can run in parallel (different files, no dependencies on incomplete tasks)
  • [Story]: Which user story this task belongs to ([US1], [US2], [US3])
  • Every task includes the exact target file path(s)

Phase 1: Scope, Baseline & Source Confirmation

Purpose: Confirm the formal source-of-truth set, repo boundary, and validation baseline before editing frontend collaboration docs.

  • T001 Read governance prerequisites in docs/design/00_Management/01_Project_Progress.md, docs/design/00_Management/02_Delivery_Standards.md, and docs/design/00_Management/03_Task_Checklist.md, then confirm the direct target artifacts in specs/011-frontend-speckit-alignment/spec.md and specs/011-frontend-speckit-alignment/plan.md
  • T002 Confirm feature scope, user stories, edge cases, and acceptance boundaries in specs/011-frontend-speckit-alignment/spec.md
  • T003 Confirm implementation scope, target repos, touchpoints, and constraints in specs/011-frontend-speckit-alignment/plan.md
  • T004 [P] Record frontend baseline SHA, branch, and evidence scope in specs/011-frontend-speckit-alignment/baseline.md
  • T005 [P] Confirm the docs-only validation command set in specs/011-frontend-speckit-alignment/quickstart.md, including make validate-file FILE=specs/011-frontend-speckit-alignment/quickstart.md, make validate-file FILE=specs/011-frontend-speckit-alignment/data-model.md, make validate-file FILE=specs/011-frontend-speckit-alignment/research.md, make validate-file FILE=specs/011-frontend-speckit-alignment/docs-validation.md, and make check-links when relative links change

Phase 2: Shared Foundation

Purpose: Establish shared wording, evidence targets, explicit validation dimensions, and governance handling that all user stories depend on.

  • T006 Normalize single-source-of-truth wording, multi-repo boundary decisions, and no-parallel-.specify/ constraints in specs/011-frontend-speckit-alignment/research.md
  • T007 Sync collaboration-entry, template, sample-index, permission, and evidence entities in specs/011-frontend-speckit-alignment/data-model.md
  • T008 Prepare the five required validation dimensions in specs/011-frontend-speckit-alignment/docs-validation.md: relative-path readability, entry-rule consistency, independent-guide discoverability, sample-category mappability, and permission-conclusion traceability
  • T009 Record the governance decision that docs/design/00_Management/01_Project_Progress.md and docs/design/00_Management/03_Task_Checklist.md remain unchanged for this feature, with rationale captured in specs/011-frontend-speckit-alignment/final-verdict.md

Phase 3: User Story 1 - 前端仓库可正确回指正式规格 (Priority: P1) 🎯 MVP

Goal: 让从 water-frontend 根目录启动的代理或实现人员，能够稳定回指 water-docs 中的正式 spec / plan / tasks / docs，并清楚区分何时留在前端仓执行、何时必须回到文档仓执行正式流程。

Independent Test: 仅阅读更新后的 ../water-frontend/AGENTS.md 与 ../water-frontend/CLAUDE.md，审阅者就能回答正式 spec.md、plan.md、tasks.md 与 water-docs/docs/ 的位置，以及哪些任务必须从 water-docs 根目录启动。

Implementation for User Story 1

  • T010 [US1] Update Speckit source-of-truth, relative path rules to ../water-docs/specs/ and ../water-docs/docs/, and no-second-.specify/ boundary in ../water-frontend/AGENTS.md
  • T011 [US1] Update the same startup boundary, formal workflow rules, and docs-path guidance in ../water-frontend/CLAUDE.md; if ../water-frontend/CLAUDE.md is missing, create an equivalent frontend entry file at the same path instead of introducing a parallel Speckit entry
  • T012 [P] [US1] Sync frontend-start vs docs-start onboarding guidance and water-docs/specs/ / water-docs/docs/ lookup rules in specs/011-frontend-speckit-alignment/quickstart.md
  • T013 [P] [US1] Run make validate-file FILE=specs/011-frontend-speckit-alignment/quickstart.md and capture entry-file path readability, startup-rule consistency, and no-parallel-.specify/ checks in specs/011-frontend-speckit-alignment/docs-validation.md
  • T014 [US1] Record User Story 1 acceptance result in specs/011-frontend-speckit-alignment/final-verdict.md

Checkpoint: User Story 1 is independently reviewable once the frontend entry files reliably point back to the formal water-docs artifacts.

Phase 4: User Story 2 - 前端生成样例形成模板化分类 (Priority: P2)

Goal: 形成“规则文件 + 样例索引”双层模板体系，使实现人员可以先判断页面交互类型，再快速找到最合适的母板页和复用样例。

Independent Test: 审阅者仅根据 ../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md 与 ../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md，即可把至少 4 类页面模式映射到现有 src/views 样例路径，并理解复合页面的一页多模板参考方式。

Implementation for User Story 2

  • T015 [US2] Update template taxonomy, semantic page roles, naming rules, and template meta-model fields (required blocks, recommended components, recommended variable names, recommended API names, recommended permission entry points) in ../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md
  • T016 [US2] Create or refine representative sample mappings, motherboard priorities, and one-page-multi-template reference rules in ../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md
  • T017 [P] [US2] Sync template entity definitions, reuse workflow, and motherboard selection steps in specs/011-frontend-speckit-alignment/data-model.md and specs/011-frontend-speckit-alignment/quickstart.md
  • T018 [P] [US2] Run make validate-file FILE=specs/011-frontend-speckit-alignment/data-model.md and capture independent-guide discoverability, sample coverage, category mapping, motherboard priority, and multi-template-reference validation in specs/011-frontend-speckit-alignment/docs-validation.md
  • T019 [US2] Record User Story 2 acceptance result and recommended motherboard pages in specs/011-frontend-speckit-alignment/final-verdict.md

Checkpoint: User Story 2 is independently reviewable once the guide defines the rules and the index provides stable, reusable examples.

Phase 5: User Story 3 - 权限能力边界可被准确说明 (Priority: P3)

Goal: 明确当前权限来源、按钮/菜单权限接入方式、数据权限、列表列可见配置与 BPM 字段权限边界，避免把未证实的普通业务表单字段权限误写为既有能力。

Independent Test: 审阅者仅根据交付文件即可明确回答权限数据来自哪里、按钮权限如何接入、有哪些列级/字段级能力，以及这些能力分别适用于哪些场景。

Implementation for User Story 3

  • T020 [US3] Update permission-source and boundary guidance in ../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md, explicitly distinguishing roles, buttons, menus/routes, data scope, column visibility, BPM field permission, and generic business-form field capability
  • T021 [P] [US3] Sync permission conclusions in specs/011-frontend-speckit-alignment/research.md and specs/011-frontend-speckit-alignment/data-model.md, explicitly covering user-info loading, permission cache, menu-route generation, page permission checks, column-visibility save/load, and BPM field-permission return/consume evidence paths
  • T022 [US3] Update permission-boundary onboarding notes and non-BPM field-capability warnings in specs/011-frontend-speckit-alignment/quickstart.md
  • T023 [P] [US3] Run make validate-file FILE=specs/011-frontend-speckit-alignment/research.md and make validate-file FILE=specs/011-frontend-speckit-alignment/docs-validation.md, then capture permission-source traceability and field/column boundary checks in specs/011-frontend-speckit-alignment/docs-validation.md
  • T024 [US3] Record User Story 3 acceptance result in specs/011-frontend-speckit-alignment/final-verdict.md

Checkpoint: User Story 3 is independently reviewable once the permission conclusions remain evidence-based and do not overstate unsupported capabilities.

Final Phase: Verification & Closure

Purpose: Re-check cross-file consistency, validation evidence, governance applicability, and final acceptance output for the whole feature.

  • T025 [P] Re-check cross-repo relative paths and startup rules in ../water-frontend/AGENTS.md, ../water-frontend/CLAUDE.md, and specs/011-frontend-speckit-alignment/quickstart.md, then run make check-links if any relative link changed in specs/011-frontend-speckit-alignment/*.md
  • T026 [P] Re-check template taxonomy, template meta-model fields, multi-template sample mapping, and permission wording across ../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md, ../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md, and specs/011-frontend-speckit-alignment/data-model.md
  • T027 [P] Re-run docs-only verification and update specs/011-frontend-speckit-alignment/baseline.md and specs/011-frontend-speckit-alignment/docs-validation.md for all five required validation dimensions
  • T028 Prepare the final acceptance summary and pass/fail verdict in specs/011-frontend-speckit-alignment/final-verdict.md, explicitly recording why docs/design/00_Management/01_Project_Progress.md and docs/design/00_Management/03_Task_Checklist.md remain unchanged this round

Dependencies & Execution Order

Phase Dependencies

  • Phase 1: No dependencies; must finish before content edits begin.
  • Phase 2: Depends on Phase 1; establishes shared wording, explicit validation dimensions, and governance handling for all stories.
  • US1: Depends on Phase 2; should complete first because all later work relies on correct frontend entry guidance.
  • US2: Depends on US1; uses the agreed startup rules and writes the template system referenced by frontend entry files.
  • US3: Depends on US2; reuses the same guide and evidence files, so sequencing after US2 avoids conflicting edits.
  • Final Phase: Depends on all selected user stories being complete.

Story Completion Order

US1 → US2 → US3

Within Each User Story

  • Update the primary frontend/document files before syncing spec artifacts.
  • Complete content edits before running the minimum document validation commands.
  • Capture story-specific evidence before marking the story verdict complete.
  • Keep water-docs as the only formal workflow home; frontend files only point to it.

Parallel Opportunities

US1

  • T012 and T013 can run in parallel after T010 and T011 are complete because quickstart.md and docs-validation.md are separate files.

US2

  • T017 and T018 can run in parallel after T015 and T016 are complete because one syncs feature artifacts while the other records validation evidence.

US3

  • T021 and T023 can run in parallel after T020 is complete because research.md / data-model.md and docs-validation.md are independent outputs.

Final Phase

  • T025, T026, and T027 can run in parallel before T028 consolidates the final verdict.

Implementation Strategy

MVP First (User Story 1 only)

  1. Complete Phase 1 and Phase 2.
  2. Deliver US1 so every frontend-side agent can correctly locate the formal water-docs artifacts.
  3. Validate the startup-rule loop with minimum document validation plus docs-validation.md and final-verdict.md.

Incremental Delivery

  1. Add US2 to provide the reusable template guide/index system.
  2. Add US3 to lock down the permission boundary wording and supporting evidence.
  3. Finish with the final verification phase to ensure cross-repo consistency and a stable acceptance verdict.

Notes

  • This feature is document-first and multi-repo aware; it does not introduce frontend business-code generation or backend permission-model changes.
  • contracts/ remains part of the standard Speckit structure, but no external API/interface contract file is required for this feature.
  • docs/design/00_Management/01_Project_Progress.md and docs/design/00_Management/03_Task_Checklist.md are intentionally left unchanged in implementation scope, but that non-applicability must still be recorded explicitly in final-verdict.md.
  • Every task preserves the single-source-of-truth model in water-docs and treats water-frontend as the implementation-side entry surface.