specs/011-frontend-speckit-alignment/baseline.md

@@ -0,0 +1,67 @@
+# baseline
+
+## Feature baseline
+
+- Feature: `011-frontend-speckit-alignment`
+- Spec: `specs/011-frontend-speckit-alignment/spec.md`
+- Validation date: `2026-03-24`
+- Validation owner: `water-docs`
+
+## Repository baselines
+
+### water-docs
+
+- Branch: `011-frontend-speckit-alignment`
+- Commit: `7200004`
+- Role: 正式 spec、plan、tasks、baseline、docs-validation、final-verdict 的单一真源
+
+### water-frontend
+
+- Branch baseline: `develop`
+- Commit baseline: `ae6593904544`
+- Role: 前端协作入口、模板规范、样例索引与权限边界说明的实施入口仓
+
+## Verified frontend document scope
+
+本轮纳入正式验证的前端文档范围如下：
+
+- `../water-frontend/AGENTS.md`
+- `../water-frontend/CLAUDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`
+
+## Evidence scope
+
+本轮 evidence 固定覆盖以下结论：
+
+- frontend 启动时如何回指 `../water-docs/specs/<feature>/spec.md`、`plan.md`、`tasks.md`
+- 哪些任务继续留在 `water-frontend` 执行，哪些任务必须回到 `water-docs`
+- 页面模板规则文件与样例索引文件的职责边界
+- 页面样例分类、母板页优先级与一页多模板参考方式
+- 权限来源、权限缓存、菜单路由生成、按钮/角色/数据权限、列可见配置与 BPM 字段权限的证据路径
+
+## Validation command baseline
+
+本 feature 采用 docs-only 最小校验集：
+
+- `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`
+- `make check-links`
+
+## Baseline interpretation
+
+- `AGENTS.md`：前端仓通用代理入口说明，承接 Speckit 回指规则、启动边界与独立规范入口。
+- `CLAUDE.md`：Claude Code 在前端仓的同层入口说明，要求与 `AGENTS.md` 保持相同正式口径。
+- `FRONTEND_PAGE_TEMPLATE_GUIDE.md`：页面模板分类、元模型、命名规则、模板选型规则与权限边界的正式规则文件。
+- `FRONTEND_PAGE_TEMPLATE_INDEX.md`：将 `src/views` 现有页面映射到模板类别的样例索引文件，用于母板页复用和一页多模板参考。
+
+## Scope note
+
+本次 baseline 固定的是“文档与协作说明层”的交付结果，不包含：
+
+- 新增前端业务页面代码
+- 新增前端页面生成器
+- 后端权限模型改造
+- 普通业务表单通用字段权限框架开发

specs/011-frontend-speckit-alignment/checklists/requirements.md

@@ -0,0 +1,37 @@
+# Specification Quality Checklist: 前端 Speckit 协作对齐
+
+**Purpose**: Validate specification completeness and quality before proceeding to planning
+**Created**: 2026-03-24
+**Feature**: [spec.md](../spec.md)
+
+## Content Quality
+
+- [x] No implementation details (languages, frameworks, APIs)
+- [x] Focused on user value and business needs
+- [x] Written for non-technical stakeholders
+- [x] All mandatory sections completed
+
+## Requirement Completeness
+
+- [x] No [NEEDS CLARIFICATION] markers remain
+- [x] Requirements are testable and unambiguous
+- [x] Success criteria are measurable
+- [x] Success criteria are technology-agnostic (no implementation details)
+- [x] All acceptance scenarios are defined
+- [x] Edge cases are identified
+- [x] Scope is clearly bounded
+- [x] Dependencies and assumptions identified
+
+## Feature Readiness
+
+- [x] All functional requirements have clear acceptance criteria
+- [x] User scenarios cover primary flows
+- [x] Feature meets measurable outcomes defined in Success Criteria
+- [x] No implementation details leak into specification
+
+## Notes
+
+- 本规格已完成一次基于前端现状证据的自检。
+- 规格明确了前端样例分类、权限来源、数据权限与字段权限边界，但未在规格中嵌入具体实现方案。
+- 当前证据表明：按钮权限、角色权限、菜单/路由权限、数据权限均有现成基础；此外还存在后端持久化的列表列可见配置能力，以及 BPM 场景专用的字段可编辑/只读/隐藏能力；普通业务表单的通用字段级权限框架仍未发现直接证据。
+- Items marked incomplete require spec updates before `/speckit.clarify` or `/speckit.plan`

specs/011-frontend-speckit-alignment/data-model.md

@@ -0,0 +1,188 @@
+# data-model
+
+## Overview
+
+本 feature 不引入业务数据库实体变更。`data-model.md` 用于描述本轮协作整理涉及的文档实体、页面样例实体、权限边界实体与 evidence 实体，作为 tasks 拆分、实施回写和验收对照的语义模型。
+
+## Entities
+
+### 1. Frontend Collaboration Entry
+
+**Description**
+
+- 前端仓中的入口说明文件，用于约束代理如何引用正式 spec 工件，以及何时留在前端仓、何时回到 `water-docs`。
+
+**Instances in scope**
+
+- `../water-frontend/AGENTS.md`
+- `../water-frontend/CLAUDE.md`
+
+**Fields**
+
+- `repoScope`: 适用仓库范围
+- `sourceOfTruth`: 正式工件来源声明
+- `featurePathRule`: `spec / plan / tasks` 相对路径引用规则
+- `docsPathRule`: `../water-docs/docs/` 的正式文档定位规则
+- `executionBoundary`: frontend 执行任务 vs `water-docs` 执行任务边界
+- `templateGuideEntry`: 模板规则文件入口
+- `templateIndexEntry`: 样例索引文件入口
+- `validationRule`: 最小验证要求
+
+**Validation rules**
+
+- 必须显式声明 `water-docs` 为正式 Speckit 单一来源。
+- 必须包含 `../water-docs/specs/<feature>/` 与 `../water-docs/docs/` 的稳定相对路径规则。
+- 不得要求在 `water-frontend` 新建第二套 `.specify/`。
+
+### 2. Template Guide
+
+**Description**
+
+- 前端页面模板化规则文件，用于定义页面分类、语义角色、命名规则、模板元模型、权限边界与选型规则。
+
+**Instance in scope**
+
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+
+**Fields**
+
+- `templateCategories`: 模板分类清单
+- `semanticRoles`: 页面语义角色定义
+- `namingRules`: 命名与目录约定
+- `metaModels`: 高频模板元模型
+- `permissionBoundaries`: 权限边界定义
+- `generationChecklist`: 页面生成输入清单
+- `selectionRules`: 模板选型决策规则
+- `motherboardSelection`: 母板页选择步骤
+
+**Validation rules**
+
+- 必须覆盖 spec 中要求的主要模板类别。
+- 必须提供必备区块、推荐组件、推荐变量名、推荐 API 命名、推荐权限接入点。
+- 必须区分普通业务表单、列表列可见配置、BPM 字段权限边界。
+- 必须被前端入口文件统一引用。
+
+### 3. Template Index Entry
+
+**Description**
+
+- 将真实 `src/views` 页面映射到模板类型的索引条目，是“规则层”与“实际样例层”的桥接对象。
+
+**Instance in scope**
+
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`
+
+**Fields**
+
+- `templateType`: 模板类型
+- `domain`: 业务域
+- `pageName`: 代表页面名称
+- `pagePath`: 页面路径
+- `companionComponents`: 配套组件 / 子块
+- `classificationEvidence`: 判定依据
+- `motherboardPriority`: `P0 / P1 / P2`
+- `primaryTemplate`: 主模板
+- `secondaryTemplates`: 辅模板列表
+- `reuseAdvice`: 复用建议
+
+**Validation rules**
+
+- 每个高频模板至少有一个可追溯代表页。
+- `P0` 条目应优先对应结构最稳定、复用价值最高的页面。
+- 索引必须支持“一页多模板参考”的表达方式。
+- 索引只做样例映射，不扩写新的权限或架构结论。
+
+### 4. Permission Source
+
+**Description**
+
+- 登录后进入前端状态管理的权限相关数据集合。
+
+**Evidence sources**
+
+- `../water-frontend/src/store/modules/user.ts`
+- `../water-frontend/src/store/modules/permission.ts`
+- `../water-frontend/src/permission.ts`
+
+**Fields**
+
+- `roles`: 角色集合
+- `permissions`: 按钮 / 操作权限集合
+- `menus`: 动态菜单与路由数据
+- `cacheLocation`: 前端缓存位置
+- `routeGeneration`: 动态路由生成入口
+
+**Relationships**
+
+- 被 `Frontend Collaboration Entry` 与 `Template Guide` 用于权限边界说明。
+- 被页面按钮与路由生成逻辑消费。
+
+### 5. Field-level Permission Capability
+
+**Description**
+
+- 用于区分当前前端不同层次字段 / 列级控制能力边界的对象集合。
+
+**Subtypes**
+
+- `ColumnVisibilityConfiguration`
+- `BpmFieldPermission`
+- `GenericBusinessFormFieldPermission`
+
+### 5.1 ColumnVisibilityConfiguration
+
+- `scene`: 列表列显示、打印、顺序、宽度
+- `storageMode`: 后端持久化，必要时可回退到本地存储
+- `apiEntry`: `../water-frontend/src/api/system/userFormConfig.ts`
+- `consumerEntry`: `../water-frontend/src/components/ColumnSetting/hooks/useColumnSettingStorage.ts`
+- `appliesTo`: 列表页列级控制
+
+### 5.2 BpmFieldPermission
+
+- `scene`: BPM 流程表单字段可编辑 / 只读 / 隐藏
+- `scope`: 仅 BPM 场景有效
+- `consumerEntry`: `../water-frontend/src/views/bpm/processInstance/create/ProcessDefinitionDetail.vue`
+- `appliesTo`: 流程发起 / 审批 / 详情页中的流程表单
+
+### 5.3 GenericBusinessFormFieldPermission
+
+- `scene`: 普通业务表单字段级控制
+- `currentState`: 未发现可直接复用的全局通用框架
+- `warning`: 不得把局部页面显隐逻辑误写为平台级字段权限能力
+
+**Validation rules**
+
+- 交付文本不得把三个子类型混写成一个概念。
+- 未证实的普通业务字段权限不得被表述为现成能力。
+
+### 6. Verification Artifact
+
+**Description**
+
+- 固定 baseline、验证结果与最终 verdict 的 evidence 实体。
+
+**Instances in scope**
+
+- `specs/011-frontend-speckit-alignment/baseline.md`
+- `specs/011-frontend-speckit-alignment/docs-validation.md`
+- `specs/011-frontend-speckit-alignment/final-verdict.md`
+
+**Fields**
+
+- `validationDimensions`: 五个必检维度
+- `commandSet`: 最小验证命令集合
+- `governanceDecision`: 是否更新项目进度与任务清单的结论
+- `storyVerdicts`: US1 / US2 / US3 的验收结果
+
+**Validation rules**
+
+- 必须覆盖 relative-path readability、entry-rule consistency、independent-guide discoverability、sample-category mappability、permission-conclusion traceability 五个维度。
+- 必须记录为何本轮 `01_Project_Progress.md` 与 `03_Task_Checklist.md` 保持不变。
+
+## Relationships
+
+- `Frontend Collaboration Entry` 引用 `Template Guide` 与 `Template Index Entry`。
+- `Template Guide` 约束 `Template Index Entry` 的分类规则与母板页选择步骤。
+- `Template Index Entry` 以 `Representative Sample` 形式回扣真实页面。
+- `Permission Source` 与 `Field-level Permission Capability` 共同构成权限边界说明的证据基础。
+- `Verification Artifact` 负责验证以上实体在最终交付中的一致性、可发现性与可追溯性。

specs/011-frontend-speckit-alignment/docs-validation.md

@@ -0,0 +1,146 @@
+# docs-validation
+
+## Validation scope
+
+本次校验覆盖以下正式交付目标：
+
+1. `water-frontend` 入口文件是否能正确回指 `water-docs` 的正式 Speckit 工件。
+2. 页面模板规范是否已经抽离为独立规则文件，且入口说明保持一致。
+3. 是否补充了“实际页面样例到模板类型”的索引文件，并支持一页多模板参考。
+4. 权限边界说明是否保持证据可追溯，不引入新的错误结论。
+5. 本轮 evidence 是否明确记录治理台账不更新的原因。
+
+## Checked documents
+
+### water-frontend
+
+- `../water-frontend/AGENTS.md`
+- `../water-frontend/CLAUDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`
+
+### water-docs
+
+- `specs/011-frontend-speckit-alignment/spec.md`
+- `specs/011-frontend-speckit-alignment/research.md`
+- `specs/011-frontend-speckit-alignment/data-model.md`
+- `specs/011-frontend-speckit-alignment/quickstart.md`
+- `specs/011-frontend-speckit-alignment/baseline.md`
+- `specs/011-frontend-speckit-alignment/docs-validation.md`
+- `specs/011-frontend-speckit-alignment/final-verdict.md`
+
+## Command execution
+
+本轮按计划执行以下最小文档校验命令：
+
+- `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`
+- `make check-links`
+
+## Five required validation dimensions
+
+### 1. Relative-path readability
+
+**Result**: Pass
+
+**Evidence**
+
+- `../water-frontend/AGENTS.md` 明确给出 `../water-docs/specs/<feature>/spec.md`、`plan.md`、`tasks.md` 的读取顺序。
+- `../water-frontend/CLAUDE.md` 明确给出相同的相对路径规则，并补充 `../water-docs/docs/` 为正式设计资料位置。
+- `specs/011-frontend-speckit-alignment/quickstart.md` 明确区分 `water-docs` 与 `water-frontend` 的阅读入口。
+
+**Conclusion**
+
+从 frontend 根目录出发，可以稳定定位 formal `specs/` 与 `docs/`。
+
+### 2. Entry-rule consistency
+
+**Result**: Pass
+
+**Evidence**
+
+- `AGENTS.md` 与 `CLAUDE.md` 都明确要求：正式 Speckit、治理台账、最终验收结论必须回到 `water-docs`。
+- 两个入口文件都明确禁止在 `water-frontend` 新建或维护第二套 `.specify/`。
+- `quickstart.md` 与 `research.md` 对启动边界保持同一口径。
+
+**Conclusion**
+
+frontend 侧不存在平行正式流程入口。
+
+### 3. Independent-guide discoverability
+
+**Result**: Pass
+
+**Evidence**
+
+- `AGENTS.md` 与 `CLAUDE.md` 都把 `FRONTEND_PAGE_TEMPLATE_GUIDE.md`、`FRONTEND_PAGE_TEMPLATE_INDEX.md` 标记为模板规范统一入口。
+- `quickstart.md` 把 guide 与 index 列为 frontend 侧的必读文件。
+- `FRONTEND_PAGE_TEMPLATE_GUIDE.md` 已完整承接分类规则、元模型、命名规则与权限边界。
+
+**Conclusion**
+
+模板规范已经独立可发现，不再依赖入口文件内嵌大段正文。
+
+### 4. Sample-category mappability
+
+**Result**: Pass
+
+**Evidence**
+
+- `FRONTEND_PAGE_TEMPLATE_INDEX.md` 已按模板类型、业务域、代表页面、页面路径、配套组件、母板优先级和复用建议建立映射。
+- 索引已覆盖 spec 要求的主要模式，并额外覆盖详情页、报表容器、登录容器、组合工作台。
+- 索引新增“主模板 / 辅模板”使用方式，能说明一页多模板参考。
+
+**Conclusion**
+
+实现人员可以先选模板类型，再快速定位母板页和辅助样例。
+
+### 5. Permission-conclusion traceability
+
+**Result**: Pass
+
+**Evidence**
+
+- `research.md` 与 `data-model.md` 都显式列出权限证据路径：
+  - 用户信息与权限集合：`src/store/modules/user.ts`
+  - 动态路由：`src/store/modules/permission.ts`、`src/permission.ts`
+  - 按钮 / 角色权限：`src/directives/permission/hasPermi.ts`、`src/directives/permission/hasRole.ts`
+  - 数据权限：`src/api/system/permission/index.ts`、`src/views/system/role/RoleDataPermissionForm.vue`
+  - 列可见配置：`src/api/system/userFormConfig.ts`、`src/components/ColumnSetting/hooks/useColumnSettingStorage.ts`
+  - BPM 字段权限：`src/views/bpm/processInstance/create/ProcessDefinitionDetail.vue`
+- `FRONTEND_PAGE_TEMPLATE_GUIDE.md` 保持“普通业务表单无全局通用字段权限框架”的边界说明。
+
+**Conclusion**
+
+权限结论可回扣到具体代码路径，没有把未证实能力误写为已具备能力。
+
+## Mapping summary
+
+推荐优先复用的母板页如下：
+
+- 标准列表查询页：`src/views/infra/config/index.vue`
+- 左树右表页：`src/views/system/user/index.vue`
+- 左树右详情维护页：`src/views/settings/address/community/index.vue`
+- 弹窗表单页：`src/views/infra/config/ConfigForm.vue`
+- 导入上传页：`src/views/meterRead/meterEnter/components/ImportForm.vue`
+- 配置 / 权限页：`src/views/system/menu/index.vue`
+- BPM / 流程页：`src/views/bpm/model/index.vue`
+- 报表 / 可视化容器页：`src/views/report/goview/index.vue`
+- 登录 / 认证容器页：`src/views/Login/Login.vue`
+- 组合容器 / 工作台页：`src/views/ai/chat/index/index.vue`
+
+## Governance applicability
+
+- `docs/design/00_Management/01_Project_Progress.md`：保持不变
+- `docs/design/00_Management/03_Task_Checklist.md`：保持不变
+
+**Reason**
+
+本轮交付边界限定为 frontend 协作入口、模板规则、样例索引与 feature evidence 收口，不涉及正式主设计文档修订或跨 feature 治理台账变更。
+
+## Follow-up notes
+
+- 当前索引覆盖的是高频样例，不是 `src/views` 的全量页面清单；后续如出现新的高频页面模式，应增量维护。
+- 当前仍未发现“普通业务表单的全局通用字段权限框架”，本结论未被本轮改动推翻。

specs/011-frontend-speckit-alignment/final-verdict.md

@@ -0,0 +1,167 @@
+# final-verdict
+
+## Verdict
+
+**Status: Pass**
+
+`011-frontend-speckit-alignment` 已完成本轮范围内的正式交付：frontend 入口回指规则、独立模板规范、样例索引、权限边界说明与 evidence 闭环均已收口，并与 `tasks.md` 保持一致。
+
+## Delivered outcomes
+
+### 1. 前端仓已具备稳定的 Speckit 回指入口
+
+以下入口文件都已明确把 `water-docs` 作为正式 Speckit 工件单一来源：
+
+- `../water-frontend/AGENTS.md`
+- `../water-frontend/CLAUDE.md`
+
+已落实的关键点：
+
+- 正式 `spec / plan / tasks` 的相对路径引用规则
+- 从 frontend 启动与回 docs 启动的边界
+- 不在前端仓复制 `.specify/` 的约束
+- `../water-docs/docs/` 作为正式设计资料位置的说明
+
+### 2. 页面模板规范已作为独立规则文件固化
+
+以下文件承接正式模板规范职责：
+
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+
+已覆盖的核心内容：
+
+- 页面模板分类
+- 语义化页面规范
+- 命名与目录约定
+- 高频模板元模型
+- 模板选型与母板页选择规则
+- 权限边界与接入建议
+
+### 3. 实际页面样例索引已形成“母板页 + 辅模板”入口
+
+以下文件承接“页面模板到真实样例”的映射职责：
+
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`
+
+已落实的关键点：
+
+- 按模板类型映射真实 `src/views` 页面
+- 标注 `P0 / P1 / P2` 母板优先级
+- 支持一页多模板参考
+- 为后续新增页面提供直接可复用的母板页路径
+
+### 4. 权限能力边界已经按证据路径固定
+
+本轮已经把以下边界固定到正式工件：
+
+- 权限来源来自登录后的用户信息、权限集合与菜单数据加载
+- 按钮权限与角色权限由现有指令消费
+- 菜单 / 路由权限由角色菜单数据生成动态路由
+- 数据权限通过角色数据范围与部门树配置落地
+- 列表列可见配置属于已存在的后端持久化能力
+- BPM 字段权限属于已存在的流程场景能力
+- 普通业务表单未发现全局通用字段权限框架
+
+## Story verdicts
+
+### US1 - 前端仓库可正确回指正式规格
+
+**Result**: Pass
+
+frontend 入口文件已能稳定回指 formal `spec / plan / tasks / docs`，并明确正式流程必须回到 `water-docs`。
+
+### US2 - 前端生成样例形成模板化分类
+
+**Result**: Pass
+
+模板规则文件与样例索引文件已形成双层结构，审阅者可以基于模板类别快速找到代表页面与母板页。
+
+### US3 - 权限能力边界可被准确说明
+
+**Result**: Pass
+
+权限来源、按钮/角色/菜单/数据权限、列可见配置与 BPM 字段权限均已按代码证据写明，未夸大普通业务表单字段权限能力。
+
+## Against feature success criteria
+
+### SC-001
+
+**Result**: Met
+
+从 frontend 入口文件出发，可以直接定位正式 `spec`、`plan`、`tasks`、guide 与 index。
+
+### SC-002
+
+**Result**: Met
+
+当前索引覆盖至少 4 类模板并已扩展到 10+ 类页面模式，每类都给出代表样例。
+
+### SC-003
+
+**Result**: Met
+
+权限来源、按钮/菜单权限接入方式、数据权限、列级控制与 BPM 字段权限边界都能仅凭交付文件回答清楚。
+
+### SC-004
+
+**Result**: Met
+
+frontend 入口说明、独立模板规范与样例索引之间不存在平行事实来源冲突，且都回指 `water-docs`。
+
+### SC-005
+
+**Result**: Met
+
+高频页面类型已具备统一元模型与推荐变量名、API 命名、权限接入点。
+
+### SC-006
+
+**Result**: Met
+
+本轮没有把未证实的权限能力误写为既有能力，仍保持“普通业务表单无全局通用字段权限框架，BPM 与列表列配置属于例外能力”的边界。
+
+## Recommended motherboard pages
+
+建议后续新增页面优先参考以下母板页：
+
+- 标准列表查询页：`src/views/infra/config/index.vue`
+- 左树右表页：`src/views/system/user/index.vue`
+- 左树右详情维护页：`src/views/settings/address/community/index.vue`
+- 弹窗表单页：`src/views/infra/config/ConfigForm.vue`
+- 导入上传页：`src/views/meterRead/meterEnter/components/ImportForm.vue`
+- 配置 / 权限页：`src/views/system/menu/index.vue`
+- BPM / 流程页：`src/views/bpm/model/index.vue`
+- 报表 / 可视化容器页：`src/views/report/goview/index.vue`
+- 登录 / 认证容器页：`src/views/Login/Login.vue`
+- 组合容器 / 工作台页：`src/views/ai/chat/index/index.vue`
+
+## Governance decision
+
+本轮明确保持以下文件不变：
+
+- `docs/design/00_Management/01_Project_Progress.md`
+- `docs/design/00_Management/03_Task_Checklist.md`
+
+**Reason**
+
+本轮交付边界限定为 frontend 协作入口、模板规则、样例索引与 feature evidence 收敛，不涉及正式主设计文档修订，也未触发跨 feature 治理台账更新条件。
+
+## Boundary note
+
+本 verdict 仅确认“前端协作说明与模板规范整理”目标已达成；不代表：
+
+- 已新增页面生成器
+- 已实现普通业务表单字段权限框架
+- 已改造后端权限模型
+- 已触达前端业务页面代码
+
+## Conclusion
+
+本轮实施已经按计划收口：
+
+1. 先固化 frontend 入口规则。
+2. 再把模板规范沉淀为独立 guide。
+3. 再补上页面模板索引，形成“规则 + 样例”双层入口。
+4. 再把权限边界与验证结果回写到 `water-docs/specs/011-frontend-speckit-alignment/`，形成正式 evidence 闭环。
+
+因此，该 feature 可以作为后续前端页面模板化、页面生成和实现协作的稳定基线继续使用。

specs/011-frontend-speckit-alignment/plan.md

@@ -0,0 +1,191 @@
+# Implementation Plan: 前端 Speckit 协作对齐
+
+**Branch**: `[011-frontend-speckit-alignment]` | **Date**: 2026-03-24 | **Spec**: [`spec.md`](./spec.md)
+**Input**: Feature specification from `/specs/011-frontend-speckit-alignment/spec.md`
+
+**Note**: This template is filled in by the `/speckit.plan` command. For this project, planning is document-first and multi-repo aware.
+
+## Summary
+
+本 feature 的目标是在保持 `water-docs` 为正式 Speckit 单一真源的前提下，补齐 `water-frontend` 侧的协作入口、独立模板规范与实际样例索引，使代理和实现人员可以：
+
+- 从前端仓稳定回指 `water-docs/specs/<feature>/spec.md`、`plan.md`、`tasks.md`
+- 基于统一模板规范判断页面语义、目录结构与权限接入边界
+- 基于真实页面样例索引快速选择可复用的母板页
+- 对权限来源、数据权限、列可见配置、BPM 字段权限与普通业务表单字段权限边界形成可追溯结论
+
+本轮计划以文档与证据闭环为主，不新增业务代码生成器，不改造后端权限模型。
+
+## Repository Scope
+
+- **Formal workflow home**: `water-docs`
+- **Target repos in scope**:
+  - `water-docs`: Yes
+  - `water-backend`: No
+  - `water-frontend`: Yes
+- **Primary delivery mode**: Mixed
+
+## Code Baseline
+
+- **Backend baseline**: N/A
+- **Frontend baseline**: `ae6593904544` / `develop`
+- **Baseline capture plan**: 所有页面样例分类、权限来源与字段权限边界结论，统一锚定到 `water-frontend` 基线 `ae6593904544`；正式 evidence 则固定到 `baseline.md`、`docs-validation.md`、`final-verdict.md`。
+
+## Technical Context
+
+**Primary Work Product**: Markdown 协作入口文件、页面模板规范文件、页面样例索引文件、feature evidence 文件
+**Source of Truth Documents**:
+- `specs/011-frontend-speckit-alignment/spec.md`
+- `CLAUDE.md`
+- `docs/design/00_Management/01_Project_Progress.md`
+- `docs/design/00_Management/03_Task_Checklist.md`
+- `../water-frontend/AGENTS.md`
+**Reference Sources**:
+- `../water-frontend/CLAUDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`
+- `../water-frontend/src/views/system/user/index.vue`
+- `../water-frontend/src/views/system/user/UserForm.vue`
+- `../water-frontend/src/views/custData/custCreate/components/ImportForm.vue`
+- `../water-frontend/src/store/modules/user.ts`
+- `../water-frontend/src/store/modules/permission.ts`
+- `../water-frontend/src/permission.ts`
+- `../water-frontend/src/directives/permission/hasPermi.ts`
+- `../water-frontend/src/directives/permission/hasRole.ts`
+- `../water-frontend/src/api/system/permission/index.ts`
+- `../water-frontend/src/views/system/role/RoleDataPermissionForm.vue`
+- `../water-frontend/src/views/system/menu/MenuForm.vue`
+- `../water-frontend/src/api/system/userFormConfig.ts`
+- `../water-frontend/src/components/ColumnSetting/hooks/useColumnSettingStorage.ts`
+- `../water-frontend/src/views/bpm/processInstance/create/ProcessDefinitionDetail.vue`
+**Validation Commands**:
+- 文档读取与差异核对
+- `git -C ../water-frontend status --short -- AGENTS.md CLAUDE.md FRONTEND_PAGE_TEMPLATE_GUIDE.md FRONTEND_PAGE_TEMPLATE_INDEX.md`
+- 如后续仅文档改动：以 evidence 校验为主，不强制执行 frontend build/lint
+**Target Scope**:
+- `specs/011-frontend-speckit-alignment/spec.md`
+- `specs/011-frontend-speckit-alignment/plan.md`
+- `specs/011-frontend-speckit-alignment/research.md`
+- `specs/011-frontend-speckit-alignment/data-model.md`
+- `specs/011-frontend-speckit-alignment/quickstart.md`
+- `specs/011-frontend-speckit-alignment/baseline.md`
+- `specs/011-frontend-speckit-alignment/docs-validation.md`
+- `specs/011-frontend-speckit-alignment/final-verdict.md`
+- `../water-frontend/AGENTS.md`
+- `../water-frontend/CLAUDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+- `../water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`
+**Project Type**: 文档治理仓库 + 多仓实现协作
+**Constraints**:
+- 不在 `water-frontend` 新建第二套 `.specify/`
+- 正式 spec / plan / tasks / evidence 统一回到 `water-docs`
+- 不臆造新的权限能力或业务规则
+- 相对路径引用必须稳定可读
+- 普通业务表单字段权限不得误写为已具备能力
+- 本轮不改造后端权限模型，不开发前端页面生成器
+**Scale/Scope**: 多仓但以前端文档整理为主，验证偏重 evidence 闭环
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+- [x] **主文档归属已确认**：正式 spec / plan / evidence 统一落在 `water-docs/specs/011-frontend-speckit-alignment/`，不新增平行正式稿。
+- [x] **多仓范围已确认**：`water-docs` 与 `water-frontend` 在范围内；`water-backend` 仅作为历史研究证据，不要求代码改动。
+- [x] **代码基线已确认**：frontend 基线已记录为 `ae6593904544 / develop`，docs 当前分支为 `011-frontend-speckit-alignment`。
+- [x] **Archive 使用方式合规**：本 feature 未直接以 Archive 替代正式口径，仅以现有 spec 与代码证据为准。
+- [x] **一致性影响已列出**：已识别 Speckit 单一来源、模板规范入口、页面样例映射、权限边界术语等一致性影响项。
+- [x] **校验与台账动作已规划**：已明确采用 `baseline.md`、`docs-validation.md`、`final-verdict.md` 做 evidence 闭环；根据 spec，本轮不要求更新 `01_Project_Progress.md` / `03_Task_Checklist.md`。
+
+## Project Structure
+
+### Feature Artifacts
+
+```text
+specs/011-frontend-speckit-alignment/
+├── spec.md
+├── plan.md
+├── research.md
+├── data-model.md
+├── quickstart.md
+├── contracts/
+├── tasks.md
+├── baseline.md
+├── docs-validation.md
+└── final-verdict.md
+```
+
+### Repository Touchpoints
+
+```text
+water-docs/
+└── specs/011-frontend-speckit-alignment/
+
+water-frontend/
+├── AGENTS.md
+├── CLAUDE.md
+├── FRONTEND_PAGE_TEMPLATE_GUIDE.md
+└── FRONTEND_PAGE_TEMPLATE_INDEX.md
+```
+
+**Structure Decision**:
+- `water-docs/specs/011-frontend-speckit-alignment/*`：承接正式 spec、plan、research、data-model、quickstart 与验证 evidence。
+- `water-frontend/AGENTS.md`：承接前端通用代理入口与 Speckit 回指规则。
+- `water-frontend/CLAUDE.md`：承接 Claude Code 在前端仓的入口与执行边界。
+- `water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`：承接模板规则层定义。
+- `water-frontend/FRONTEND_PAGE_TEMPLATE_INDEX.md`：承接实际页面样例索引层定义。
+
+## Phase 0: Research & Alignment
+
+### Research Inputs
+
+- 前端仓与 docs 仓的单一事实来源边界如何保持一致
+- 模板规则层与样例索引层如何分工
+- 页面分类按交互结构还是业务域组织更合理
+- 普通业务字段权限、列可见配置、BPM 字段权限如何避免混写
+- 本轮是否需要额外 contract 文件或技术接口描述
+
+### Deliverables
+
+- `research.md`
+- 已有 evidence 工件的范围说明
+
+## Phase 1: Design & Contracts
+
+### Planned Artifacts
+
+- `data-model.md`
+- `contracts/`（保留目录，本 feature 无新增外部接口契约文件）
+- `quickstart.md`
+- `final-verdict.md`（verification-heavy feature，已纳入正式产物）
+
+### Design Decisions
+
+- 采用“`water-docs` 单一正式真源 + `water-frontend` 实施入口”的多仓协作结构。
+- 采用“规则文件（guide） + 样例索引（index）”双层前端模板化设计。
+- 页面分类按交互结构划分，而不是按业务域划分。
+- 权限结论保持证据优先，不对普通业务字段权限做超范围推断。
+- plan 阶段不新增技术接口 contract，只保留 Speckit 标准目录结构。
+
+## Validation Plan
+
+- **Document validation**:
+  - 核对 `spec.md`、`plan.md`、`research.md`、`data-model.md`、`quickstart.md` 之间的口径一致性
+  - 核对 `AGENTS.md` / `CLAUDE.md` / `FRONTEND_PAGE_TEMPLATE_GUIDE.md` / `FRONTEND_PAGE_TEMPLATE_INDEX.md` 的引用链是否闭环
+- **Backend validation**: N/A
+- **Frontend validation**: N/A（当前仅文档协作文件改动，不触发业务代码构建验证）
+- **Evidence output**:
+  - `baseline.md`
+  - `docs-validation.md`
+  - `final-verdict.md`
+
+## Ledger Sync Plan
+
+- **Project progress update required**: No
+- **Task checklist update required**: No
+- **Evidence or verification summary update required**: Yes
+
+## Complexity Tracking
+
+> **Fill ONLY if Constitution Check has violations that must be justified**
+
+当前无需要豁免的 Constitution 违规项。

specs/011-frontend-speckit-alignment/quickstart.md

@@ -0,0 +1,152 @@
+# quickstart
+
+## Goal
+
+在 `011-frontend-speckit-alignment` feature 下，快速判断应该看哪些文件、从哪里启动、如何选母板页，以及页面权限边界应该怎样判断。
+
+## 1. 从哪里启动
+
+### 正式 Speckit / 文档流程
+
+当任务属于以下类型时，从 `water-docs` 根目录启动：
+
+- 写 / 改 `spec.md`
+- 写 / 改 `plan.md`
+- 写 / 改 `tasks.md`
+- 更新 `baseline.md`、`docs-validation.md`、`final-verdict.md`
+- 输出最终验收结论
+- 更新治理台账或正式设计文档
+
+正式 feature 目录：
+
+- `specs/011-frontend-speckit-alignment/`
+
+### 前端实现 / 页面参考
+
+当任务属于以下类型时，从 `water-frontend` 根目录启动：
+
+- 新增页面
+- 修复前端页面问题
+- 对齐页面目录结构
+- 选择页面母板页
+- 判断页面该接入哪种权限方式
+- 查阅真实样例路径并与当前页面做对照
+
+## 2. 先看哪些文件
+
+### 在 `water-docs` 中
+
+优先顺序如下：
+
+1. `specs/011-frontend-speckit-alignment/spec.md`
+2. `specs/011-frontend-speckit-alignment/plan.md`
+3. `specs/011-frontend-speckit-alignment/tasks.md`
+4. `specs/011-frontend-speckit-alignment/research.md`
+5. `specs/011-frontend-speckit-alignment/data-model.md`
+6. `specs/011-frontend-speckit-alignment/docs-validation.md`
+7. `specs/011-frontend-speckit-alignment/final-verdict.md`
+
+如需查正式设计资料，再看：
+
+- `../water-docs/docs/`
+- `../water-docs/docs/design/`
+
+### 在 `water-frontend` 中
+
+1. `AGENTS.md`
+2. `CLAUDE.md`
+3. `FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+4. `FRONTEND_PAGE_TEMPLATE_INDEX.md`
+
+## 3. 如何选页面模板
+
+### 第一步：按交互结构判断主模板
+
+优先判断页面属于：
+
+- 标准列表查询页
+- 左树右表页
+- 左树右详情维护页
+- 弹窗表单页
+- 导入上传页
+- 详情展示页
+- 配置 / 权限页
+- BPM / 流程页
+- 报表 / 可视化容器页
+- 登录 / 认证容器页
+- 组合容器 / 工作台页
+
+### 第二步：到索引表中找母板页
+
+优先找 `P0` 母板页：
+
+- 标准列表：`src/views/infra/config/index.vue`
+- 左树右表：`src/views/system/user/index.vue`
+- 左树右详情维护：`src/views/settings/address/community/index.vue`
+- 弹窗表单：`src/views/infra/config/ConfigForm.vue`
+- 导入上传：`src/views/meterRead/meterEnter/components/ImportForm.vue`
+- 配置 / 权限页：`src/views/system/menu/index.vue`
+- BPM / 流程页：`src/views/bpm/model/index.vue`
+- 报表容器：`src/views/report/goview/index.vue`
+- 登录容器：`src/views/Login/Login.vue`
+- 工作台容器：`src/views/ai/chat/index/index.vue`
+
+### 第三步：如果一页有多种交互，按“主模板 + 辅模板”选样例
+
+常见复合页面判断方式：
+
+- 查询列表 + 新增编辑弹窗：主模板选“标准列表查询页”，辅模板参考“弹窗表单页”
+- 查询列表 + 导入：主模板选“标准列表查询页”，辅模板参考“导入上传页”
+- 左树右表 + 权限配置弹窗：主模板选“左树右表页”，辅模板参考“配置 / 权限页”
+- 流程详情 + 字段权限：主模板选“BPM / 流程页”，不要误套用“普通详情页”
+
+### 第四步：确认权限边界
+
+新增页面前，先确认属于哪一类权限接入：
+
+- 按钮权限
+- 角色权限
+- 菜单 / 路由权限
+- 数据权限
+- 列表列可见配置
+- BPM 字段权限
+
+不要默认假设普通业务表单已经存在全局字段权限框架。
+
+## 4. docs-only 最小验证命令
+
+本 feature 完成后，至少执行以下命令：
+
+```bash
+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
+make check-links
+```
+
+## 5. 本 feature 的交付边界
+
+本 feature 当前包含：
+
+- 前端入口文件 Speckit 回指规则
+- 模板规范独立化
+- 页面模板样例索引
+- 权限边界结论整理
+- `baseline / docs-validation / final-verdict` evidence
+
+本 feature 当前不包含：
+
+- 新的前端页面生成器开发
+- 普通业务表单字段权限框架开发
+- 后端权限模型改造
+- 大规模业务页面重构
+
+## 6. 治理台账边界
+
+本轮不更新以下治理台账：
+
+- `docs/design/00_Management/01_Project_Progress.md`
+- `docs/design/00_Management/03_Task_Checklist.md`
+
+原因：本轮范围限定为 frontend 入口与 feature evidence 收敛，不涉及正式主文档变更或跨 feature 治理项收口。

specs/011-frontend-speckit-alignment/research.md

@@ -0,0 +1,167 @@
+# research
+
+## Research scope
+
+本研究用于支撑 `011-frontend-speckit-alignment` 的实施阶段，聚焦以下问题：
+
+1. 前端仓如何稳定回指 `water-docs` 的正式 Speckit 工件。
+2. 页面模板规范与样例索引如何分层，避免入口文件膨胀。
+3. 实际页面样例如何组织成可复用的模板索引，并支持一页多模板参考。
+4. 当前权限边界在普通页面、列表列配置与 BPM 场景之间应如何准确表述。
+
+## Decision 1: `water-docs` 继续作为正式 Speckit 单一真源
+
+**Decision**
+
+- 正式 `spec / plan / tasks / baseline / docs-validation / final-verdict` 全部继续落在 `water-docs/specs/011-frontend-speckit-alignment/`。
+- `water-frontend` 只承载实现侧入口说明、模板规则与样例索引，不复制 `.specify/`，也不维护第二套正式流程。
+- `AGENTS.md` 与 `CLAUDE.md` 必须把“从 frontend 启动”和“回 docs 启动”的边界写成相同口径。
+
+**Rationale**
+
+- 该工作本质是多仓协作规则整理，不是单独的前端局部优化。
+- `water-docs` 根仓的 `.specify/` 已是唯一正式流程入口，继续复用能避免前端仓和平行 docs 口径分叉。
+- frontend 只保留实施入口，能让实现人员在正确位置读取正式文档，而不把 spec 工件散落到代码仓。
+
+**Alternatives considered**
+
+- 在 `water-frontend` 新建独立 `.specify/`：拒绝，破坏单一事实来源。
+- 将 spec 只保留在前端仓：拒绝，本 feature 同时约束 docs 与 frontend 两边协作方式。
+
+## Decision 2: 模板规范采用“规则文件 + 样例索引文件”双层结构
+
+**Decision**
+
+- `FRONTEND_PAGE_TEMPLATE_GUIDE.md` 作为规则层，承载模板分类、元模型、命名规则、权限边界与选型规则。
+- `FRONTEND_PAGE_TEMPLATE_INDEX.md` 作为样例层，承载 `src/views` 到模板类型的实际映射、母板页优先级、主模板/辅模板关系与复用建议。
+- `AGENTS.md` 与 `CLAUDE.md` 只做入口，不再重复内嵌大段模板分类正文。
+
+**Rationale**
+
+- 仅有规则文件时，实现人员仍需要自己搜索真实样例。
+- 仅有样例索引时，又无法得到统一的命名、目录与权限接入规范。
+- 双层结构既能定义规则，又能快速回扣现有母板页。
+
+**Alternatives considered**
+
+- 把全部内容塞回 `AGENTS.md` / `CLAUDE.md`：拒绝，入口文件会再次膨胀。
+- 只保留 guide，不单独建 index：拒绝，无法满足“可复用样例映射”和“母板页优先级”要求。
+
+## Decision 3: 页面分类按交互结构组织，并允许一页多模板参考
+
+**Decision**
+
+- 页面模板分类维持按交互结构划分，而不是按业务域命名：
+  - 标准列表查询页
+  - 左树右表页
+  - 左树右详情维护页
+  - 弹窗表单页
+  - 导入上传页
+  - 详情展示页
+  - 配置 / 权限页
+  - BPM / 流程页
+  - 报表 / 可视化容器页
+  - 登录 / 认证容器页
+  - 组合容器 / 工作台页
+- 对同时包含查询列表、弹窗表单、导入动作的页面，先确定主模板，再补充辅模板参考，不强行要求单一分类。
+
+**Rationale**
+
+- 同一业务域常同时包含多种页面交互形态。
+- 页面生成与样例复用更依赖交互骨架，而不是模块名称。
+- 允许“一页多模板参考”，能更准确映射 `system/user`、`settings/priceTemplate` 等复合页面。
+
+**Alternatives considered**
+
+- 按业务模块分类：拒绝，不能直接指导页面骨架复用。
+- 按组件技术碎片分类：拒绝，过于细碎，不利于协作入口阅读。
+
+## Decision 4: 权限结论以代码证据为准，不扩写未证实能力
+
+**Decision**
+
+- 计划和后续任务保持以下权限边界：
+  - 角色权限：已存在
+  - 按钮权限：已存在
+  - 菜单 / 路由权限：已存在
+  - 数据权限：已存在
+  - 列表列可见配置：已存在，且为后端持久化能力
+  - BPM 字段权限：已存在，仅限 BPM 场景
+  - 普通业务表单全局字段权限框架：当前未发现通用实现
+
+**Evidence paths**
+
+- 用户信息与权限集合加载：`../water-frontend/src/store/modules/user.ts`
+- 菜单路由缓存与动态路由生成：`../water-frontend/src/store/modules/permission.ts`、`../water-frontend/src/permission.ts`
+- 按钮权限指令：`../water-frontend/src/directives/permission/hasPermi.ts`
+- 角色权限指令：`../water-frontend/src/directives/permission/hasRole.ts`
+- 角色菜单/数据权限 API：`../water-frontend/src/api/system/permission/index.ts`
+- 数据权限页面消费：`../water-frontend/src/views/system/role/RoleDataPermissionForm.vue`
+- 菜单权限与权限标识录入：`../water-frontend/src/views/system/menu/MenuForm.vue`
+- 列可见配置 API 与前端存取：`../water-frontend/src/api/system/userFormConfig.ts`、`../water-frontend/src/components/ColumnSetting/hooks/useColumnSettingStorage.ts`
+- BPM 字段权限消费：`../water-frontend/src/views/bpm/processInstance/create/ProcessDefinitionDetail.vue`
+
+**Rationale**
+
+- spec 已明确要求不能把未证实的能力描述为已具备。
+- 当前工作只需要如实表达边界，不新增权限模型设计。
+
+**Alternatives considered**
+
+- 统一称“字段权限不存在”：拒绝，BPM 字段权限与列表列配置都属于已存在能力。
+- 直接规划普通业务表单字段权限：拒绝，超出本轮 feature 范围。
+
+## Decision 5: `contracts/` 保留目录，但本 feature 不新增外部接口契约
+
+**Decision**
+
+- 本 feature 保留 Speckit 标准 `contracts/` 目录结构，但不新增 API / CLI / 外部系统契约文件。
+- 前端协作入口、模板规范与样例索引约束由 `plan.md`、`quickstart.md` 与前端 Markdown 文件承接。
+
+**Rationale**
+
+- 本轮交付对象是文档规范与协作方式，而不是新增系统接口。
+- 强行编造 OpenAPI 或伪契约不会提升可实施性，反而会引入假细节。
+
+**Alternatives considered**
+
+- 创建伪 API contract：拒绝，与 feature 无关。
+- 完全跳过 `contracts/` 目录：不采用，保留标准目录结构更利于后续延展。
+
+## Decision 6: 验证以文档一致性与 evidence 闭环为主
+
+**Decision**
+
+- 本轮主要验证产物为：
+  - `baseline.md`
+  - `docs-validation.md`
+  - `final-verdict.md`
+- 最小文档校验命令固定为：
+  - `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`
+  - `make check-links`
+- 不强制执行 frontend build / lint，因为本轮未触达 Vue 业务代码。
+
+**Rationale**
+
+- 变更范围仅涉及 Markdown 协作文件与规范文件。
+- spec 已将交付边界限定为前端协作说明、独立规范文件与 evidence 工件。
+
+**Alternatives considered**
+
+- 强制跑前端构建：未采用，与当前改动无直接关联。
+- 不做任何 evidence：拒绝，无法满足 spec 对可追溯验证的要求。
+
+## Research conclusion
+
+本 feature 的实施路径已经明确：
+
+1. 在 `water-docs` 保持正式 `spec / plan / tasks / evidence` 单一真源。
+2. 在 `water-frontend` 形成：
+   - 入口规则：`AGENTS.md`、`CLAUDE.md`
+   - 模板规则文件：`FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+   - 样例索引文件：`FRONTEND_PAGE_TEMPLATE_INDEX.md`
+3. 对权限边界严格按代码证据回写，不把普通业务表单字段权限误写为既有能力。
+4. 用 `baseline.md`、`docs-validation.md`、`final-verdict.md` 固定基线、验证与最终结论，不更新本轮不适用的治理台账。

specs/011-frontend-speckit-alignment/spec.md

@@ -0,0 +1,183 @@
+# Feature Specification: 前端 Speckit 协作对齐
+
+**Feature Branch**: `[011-frontend-speckit-alignment]`
+**Created**: 2026-03-24
+**Status**: Draft
+**Input**: User description: "我需要让前端的 的目录下CLUAD.md 与 AGENT.md 更友好的支持 speckit 可以正确的引用water-docs 里的目录,以及前端的生成应该模板化,你可以先看下前端下面有哪些类似与样例的,可以怎么分类? 以及权限是怎么弄的?权限来自于哪里?有没有字段权限的控制?"
+
+## Document Scope & Sources *(mandatory)*
+
+- **Target documents**:
+  - `specs/011-frontend-speckit-alignment/spec.md`
+  - `../water-frontend/AGENTS.md`
+  - `../water-frontend/CLAUDE.md`
+  - `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+- **Primary source of truth**:
+  - `CLAUDE.md`
+  - `docs/design/00_Management/01_Project_Progress.md`
+  - `docs/design/00_Management/03_Task_Checklist.md`
+  - `../water-frontend/AGENTS.md`
+- **Reference sources**:
+  - `../water-frontend/src/views/system/user/index.vue`
+  - `../water-frontend/src/views/system/user/UserForm.vue`
+  - `../water-frontend/src/views/custData/custCreate/components/ImportForm.vue`
+  - `../water-frontend/src/store/modules/user.ts`
+  - `../water-frontend/src/store/modules/permission.ts`
+  - `../water-frontend/src/permission.ts`
+  - `../water-frontend/src/directives/permission/hasPermi.ts`
+  - `../water-frontend/src/directives/permission/hasRole.ts`
+  - `../water-frontend/src/api/system/permission/index.ts`
+  - `../water-frontend/src/views/system/role/RoleDataPermissionForm.vue`
+  - `../water-frontend/src/views/system/menu/MenuForm.vue`
+  - `../water-frontend/src/api/system/userFormConfig.ts`
+  - `../water-frontend/src/components/ColumnSetting/hooks/useColumnSettingStorage.ts`
+  - `../water-frontend/src/views/bpm/processInstance/create/ProcessDefinitionDetail.vue`
+  - `../water-backend/sw-module-system/sw-module-system-server/src/main/java/cn/com/emsoft/sw/module/system/dal/dataobject/userformconfig/UserFormConfigDO.java`
+  - `../water-backend/sw-module-system/sw-module-system-server/src/main/java/cn/com/emsoft/sw/module/system/controller/admin/userformconfig/vo/UserFormConfigBatchSaveReqVO.java`
+  - `../water-backend/sw-module-bpm/sw-module-bpm-api/src/main/java/cn/com/emsoft/sw/module/bpm/enums/definition/BpmFieldPermissionEnum.java`
+  - `../water-backend/sw-module-bpm/sw-module-bpm-server/src/main/java/cn/com/emsoft/sw/module/bpm/controller/admin/task/vo/instance/BpmApprovalDetailRespVO.java`
+- **Scope decision**: 本需求在范围内，目标是形成前端仓库可直接执行的协作说明与模板化分类依据，使代理从 `water-frontend` 启动时也能正确回指 `water-docs` 的正式规格工件，并对当前权限模型给出可追溯结论。
+
+## Repository Scope *(mandatory)*
+
+- **Target repos**:
+  - `water-docs`: Required
+  - `water-backend`: Not Required
+  - `water-frontend`: Required
+- **Expected delivery type**: Mixed
+- **Out of scope for this round**:
+  - 后端权限模型改造
+  - 前端业务页面代码生成器的实际开发
+  - 新增字段级权限能力
+  - 对既有业务页面的大规模重构
+  - 在 `water-frontend` 新建独立 `.specify/` 流程
+
+## Code Baseline *(mandatory for brownfield work)*
+
+- **Backend baseline**: N/A
+- **Frontend baseline**: `ae6593904544` / `develop`
+- **Baseline capture rule**: 所有关于样例分类、权限来源、数据权限与字段权限结论，均以本次读取到的前端基线代码为准；若后续实施时基线变化，需要在验证工件中重新记录并说明差异。
+
+## Evidence Scope *(mandatory)*
+
+- **Document evidence required**:
+  - 本 feature 的 `spec.md`
+  - 后续 `plan.md`
+  - 后续 `tasks.md`
+  - 前端仓库协作说明改动后的差异说明
+  - 独立页面模板规范文件 `../water-frontend/FRONTEND_PAGE_TEMPLATE_GUIDE.md`
+- **Backend evidence required**: N/A
+- **Frontend evidence required**:
+  - `AGENTS.md` 与 `CLAUDE.md` 中对 `water-docs` 引用规则的落地结果
+  - 前端页面/表单样例分类清单及对应示例路径
+  - 当前权限来源、菜单权限、角色权限、数据权限、字段权限结论的证据回扣
+- **Verification artifacts required**:
+  - `baseline.md`
+  - `docs-validation.md`
+  - `final-verdict.md`
+
+## User Scenarios & Testing *(mandatory)*
+
+### User Story 1 - 前端仓库可正确回指正式规格 (Priority: P1)
+
+作为在 `water-frontend` 仓库中启动代理的实现人员，我需要从仓库入口说明中快速找到 `water-docs` 中的正式规格、计划和任务文件，这样就不会在错误目录中生成流程工件，也不会引用错误的来源资料。
+
+**Why this priority**: 这是后续所有实现、联调和验收工作的前提；如果入口规则不清晰，会直接导致规格引用错误、流程分叉和回写缺失。
+
+**Independent Test**: 仅阅读更新后的前端仓库入口说明，验证审阅者是否能明确回答“正式 spec/plan/tasks 在哪里”“前端实现何时从 frontend 启动、何时必须回到 water-docs 启动”。
+
+**Acceptance Scenarios**:
+
+1. **Given** 代理从 `water-frontend` 根目录启动，**When** 它需要查找正式需求规格，**Then** 它能直接定位到 `../water-docs/specs/<feature>/spec.md`、`plan.md`、`tasks.md` 的引用规则。
+2. **Given** 代理需要执行 Speckit 相关正式流程，**When** 它阅读前端仓库入口说明，**Then** 它会回到 `water-docs` 而不是在前端仓库新建并维护平行流程工件。
+3. **Given** 代理需要判断页面类型、目录结构、命名方式或权限边界，**When** 它读取前端仓库入口说明，**Then** 它会继续读取独立规范文件 `FRONTEND_PAGE_TEMPLATE_GUIDE.md`，而不是依赖分散在多个入口文件中的重复规则。
+
+---
+
+### User Story 2 - 前端生成样例形成模板化分类 (Priority: P2)
+
+作为要扩展前端页面的实现人员，我需要知道当前前端仓库已有的典型页面、表单和导入场景样例如何分类，以及每一类应参考哪些已有页面，这样新增页面时可以优先复用现有模式而不是重新发明结构。
+
+**Why this priority**: 模板化分类可以降低页面实现的不一致性，减少搜索成本，并为后续生成型工作提供稳定的参照类别。
+
+**Independent Test**: 仅根据分类说明，验证审阅者能否把至少一个“列表查询页”、一个“弹窗表单”、一个“导入表单”、一个“权限配置页”映射到现有样例路径。
+
+**Acceptance Scenarios**:
+
+1. **Given** 实现人员需要新增标准后台页面，**When** 它查看样例分类说明，**Then** 它能区分列表查询、弹窗表单、导入表单、树形配置、权限配置等主要类别，并找到每类代表样例。
+2. **Given** 实现人员需要生成新页面，**When** 它根据分类说明选择模板类别，**Then** 它不会把不适合的样例错误地作为基线模式。
+
+---
+
+### User Story 3 - 权限能力边界可被准确说明 (Priority: P3)
+
+作为实现人员或评审人员，我需要在开始页面开发前明确当前前端权限来自哪里、页面按钮权限与数据权限如何生效、是否已有字段级权限控制，这样就不会对现有能力作出超出事实的假设。
+
+**Why this priority**: 权限认知错误会直接影响页面可见性、操作按钮、数据范围和需求评估，属于高风险误判点。
+
+**Independent Test**: 仅根据规格与后续实施说明，验证审阅者能否明确回答权限数据来源、按钮权限的使用方式、数据权限的现状，以及字段级权限是否存在现成控制能力。
+
+**Acceptance Scenarios**:
+
+1. **Given** 实现人员要给页面增加操作按钮，**When** 它查看权限说明，**Then** 它能知道按钮权限由用户权限集合驱动，并通过既有页面模式进行控制。
+2. **Given** 实现人员要判断是否能直接做字段级隐藏或只读控制，**When** 它查看权限说明，**Then** 它能知道当前基线是否已有现成字段权限能力，若没有则不会误判为已支持。
+
+---
+
+### Edge Cases
+
+- 前端仓库根目录当前没有 `CLAUDE.md` 时，协作说明仍需保证代理有单一、稳定的入口规则。
+- 当某个页面同时包含查询列表、弹窗表单和导入动作时，分类规则需要允许“一页多模板参考”，而不是强制归为单一类别。
+- 当菜单权限、按钮权限、数据权限、列表列可见配置和 BPM 字段权限来自不同代码路径时，说明文档需要明确区分来源，避免把它们混为一种能力。
+- 当当前基线未能证明“普通业务表单”的通用字段权限能力时，交付结论必须明确标记其边界；但若 BPM 场景字段权限或列表列可见配置已存在，也必须如实说明，不得一概表述为“字段权限不存在”。
+
+## Requirements *(mandatory)*
+
+### Functional Requirements
+
+- **FR-001**: 规格必须明确前端仓库中用于承接协作规则的目标文件，并将 `water-docs` 明确标注为正式规格、计划、任务的单一权威来源。
+- **FR-002**: 规格必须定义从 `water-frontend` 启动代理时，何种任务留在前端仓库执行，何种任务必须回到 `water-docs` 启动。
+- **FR-003**: 规格必须要求前端仓库说明提供稳定的相对路径引用规则，使代理能够从前端仓库正确定位 `water-docs/specs/` 与 `water-docs/docs/`。
+- **FR-004**: 规格必须要求将页面模板化分类、语义化页面规范、命名约定与权限边界抽离到独立规范文件中，并由 `AGENTS.md` 与 `CLAUDE.md` 统一引用。
+- **FR-005**: 规格必须要求对当前前端页面/表单样例进行模板化分类，并为每个主要类别给出至少一个现有样例路径作为参考。
+- **FR-006**: 规格必须要求模板化分类至少覆盖列表查询页、弹窗表单、导入表单、树形配置或权限配置等当前仓库中已存在的主要模式。
+- **FR-007**: 规格必须要求独立规范文件提供高频页面的模板元模型，包括必备区块、推荐组件、推荐变量名、推荐 API 命名和推荐权限接入点。
+- **FR-008**: 规格必须要求权限说明明确区分角色权限、按钮权限、菜单/路由权限、数据权限、列表列可见配置和 BPM 场景字段权限，不得将不同层级的权限能力混写。
+- **FR-009**: 规格必须记录当前权限来源的代码证据，包括用户信息加载、权限集合缓存、菜单路由生成、页面权限校验、列表列配置保存/读取以及 BPM 字段权限返回与消费的来源路径。
+- **FR-010**: 规格必须明确说明当前基线下字段级控制能力的边界：普通业务表单未见通用字段级权限框架；但 BPM 场景已存在字段可编辑/只读/隐藏能力，列表页已存在后端持久化的列可见配置能力。
+- **FR-011**: 规格必须保持单一事实来源原则，不得要求在 `water-frontend` 仓库复制 `.specify/` 流程或创建第二套正式规格入口。
+- **FR-012**: 规格必须限定本轮不改造后端权限实现、不新增权限能力，只对协作说明、样例分类、模板规范和现状结论进行整理与约束。
+- **FR-013**: 规格必须明确验证范围，至少覆盖相对路径可读性、入口规则一致性、独立规范文件可发现性、样例分类可映射性和权限结论可追溯性。
+- **FR-014**: 规格必须说明本轮不要求更新 `docs/design/00_Management/01_Project_Progress.md` 与 `docs/design/00_Management/03_Task_Checklist.md`，因为交付边界限定为前端仓库协作说明、独立规范文件与 spec 工件。
+
+### Key Entities *(include if feature involves data)*
+
+- **Frontend Collaboration Entry**: 前端仓库中的入口说明文件，用于约束代理在何处读取正式规格、何处执行实现任务。
+- **Reference Path Rule**: 从 `water-frontend` 指向 `water-docs` 的稳定相对路径约定，用于定位 spec、plan、tasks 与正式文档。
+- **Template Category**: 对现有页面/表单样例的归类结果，例如列表查询、弹窗表单、导入表单、树形配置、权限配置。
+- **Representative Sample**: 能代表某一模板类别的现有页面或组件路径，用于后续复用和比对。
+- **Permission Source**: 登录后加载到前端用户态中的角色、权限集合和菜单数据来源。
+- **Data Scope Permission**: 角色层面的数据范围配置能力，例如全部、指定部门、仅本人等范围控制。
+- **Column Visibility Configuration**: 由后端持久化并在前端列表中消费的列显示、打印、排序与宽度配置能力。
+- **BPM Field Permission**: 仅在 BPM 流程表单场景中生效的字段可编辑、只读、隐藏控制能力。
+- **Field-level Permission Capability**: 对页面字段级显示、编辑或只读控制的现成能力；本轮需要区分“普通业务表单的通用能力”与“BPM 场景专用能力”。
+- **Verification Artifact**: 记录基线、校验结果与最终结论的工件，用于回扣本次整理结论。
+
+## Assumptions & Dependencies *(optional)*
+
+- `water-frontend` 与 `water-docs` 将继续以同级目录形式存在，允许通过 `../water-docs/` 进行稳定引用。
+- 当前前端基线下，用户权限与菜单数据通过登录后的用户信息加载流程进入前端缓存和状态管理。
+- 当前基线已存在按钮权限、角色权限和数据权限相关证据；此外还存在后端持久化的列表列可见配置能力，以及 BPM 场景专用的字段可编辑/只读/隐藏能力。
+- 当前未见普通业务表单可直接复用的通用字段级权限框架，因此若要在非 BPM 页面引入字段权限，仍需单独规划其模型和消费方式。
+- 样例分类仅以当前已存在页面和组件为依据，不扩展到尚未存在的业务模式。
+
+## Success Criteria *(mandatory)*
+
+### Measurable Outcomes
+
+- **SC-001**: 从 `water-frontend` 仓库入口说明出发，审阅者可在一次查阅内明确找到正式 `spec`、`plan`、`tasks` 的权威位置，以及独立页面模板规范文件的位置。
+- **SC-002**: 审阅者无需额外口头解释，即可区分至少 4 类前端样例模板，并为每类指出至少 1 个现有代表样例。
+- **SC-003**: 审阅者可仅根据交付说明回答以下三个问题：权限来自哪里、按钮/菜单权限如何接入、当前有哪些字段级或列级控制能力以及它们分别适用于哪些场景。
+- **SC-004**: 前端仓库协作说明、独立模板规范文件与 `water-docs` 的单一事实来源原则之间不存在冲突或平行入口表述。
+- **SC-005**: 高频页面类型具备统一的模板元模型，审阅者可从独立规范文件中直接找到必备区块、推荐变量名、推荐 API 命名和权限接入建议。
+- **SC-006**: 本 feature 的最终结论不会把未在当前基线中证实的权限能力描述为已具备能力。

specs/011-frontend-speckit-alignment/tasks.md

@@ -0,0 +1,163 @@
+# 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.
+
+- [X] 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`
+- [X] T002 Confirm feature scope, user stories, edge cases, and acceptance boundaries in `specs/011-frontend-speckit-alignment/spec.md`
+- [X] T003 Confirm implementation scope, target repos, touchpoints, and constraints in `specs/011-frontend-speckit-alignment/plan.md`
+- [X] T004 [P] Record frontend baseline SHA, branch, and evidence scope in `specs/011-frontend-speckit-alignment/baseline.md`
+- [X] 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.
+
+- [X] T006 Normalize single-source-of-truth wording, multi-repo boundary decisions, and no-parallel-`.specify/` constraints in `specs/011-frontend-speckit-alignment/research.md`
+- [X] T007 Sync collaboration-entry, template, sample-index, permission, and evidence entities in `specs/011-frontend-speckit-alignment/data-model.md`
+- [X] 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
+- [X] 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
+
+- [X] 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`
+- [X] 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
+- [X] 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`
+- [X] 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`
+- [X] 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
+
+- [X] 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`
+- [X] 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`
+- [X] 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`
+- [X] 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`
+- [X] 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
+
+- [X] 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
+- [X] 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
+- [X] T022 [US3] Update permission-boundary onboarding notes and non-BPM field-capability warnings in `specs/011-frontend-speckit-alignment/quickstart.md`
+- [X] 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`
+- [X] 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.
+
+- [X] 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`
+- [X] 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`
+- [X] 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
+- [X] 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.