aodw-skill 0.7.3

package/.aodw/03-standards/stacks/react-typescript/ai-coding-rules-frontend.md

@@ -0,0 +1,291 @@
+# AI Coding Rules - Frontend Development
+
+> **注意**：本文件是 `.aodw/03-standards/ai-coding-rules.md` 的子规范文件。  
+> 请先阅读主文件了解通用编码原则，再阅读本文件了解前端特定规范。
+
+**适用场景**：
+- 前端开发（React + TypeScript + Vite）
+- UI 组件开发
+- 前端工具配置
+
+**必须与以下规范配合使用**：
+- `.aodw/03-standards/ai-coding-rules.md`（主文件，包含通用原则）
+- `.aodw/03-standards/ai-coding-rules-common.md`（通用编码规范）
+- `.aodw/05-tooling/ai-tools-init-rules.md`（工具初始化规则，如果通过 AI 方式初始化工具）
+
+**⚠️ 强制要求**：所有前端开发必须严格遵守 `docs/frontend-guidelines.md` 中的规范。
+
+---
+
+## 1. 技术栈确认
+
+适用项目技术栈：
+- 框架：React 18/19 + TypeScript + Vite
+- UI：Tailwind CSS + Radix UI + 自定义组件库
+- 状态：Zustand
+- 工具：ESLint + Prettier
+
+---
+
+## 2. 工具初始化检查（必须）
+
+> **⚠️ 重要**：所有前端开发必须使用工具强制执行规范，不能只靠自觉。  
+> 本项目的后端规范通过 **工具自动化质量体系** 实现：
+> - ✅ 编辑器即时提示 → Git 提交前阻断 → CI 自动失败 → AI 自动服从
+
+在开始任何前端开发前，AI 必须检查工具初始化状态：
+
+### 2.1 工具初始化状态检查
+
+**AI 必须检查**：
+- [ ] 是否已运行工具初始化？
+- [ ] `.aodw/tools-status.yaml` 中 `initialized: true` 且前端工具状态为 `configured: true`？
+
+**检查方法**：
+1. 读取 `.aodw/tools-status.yaml` 文件
+2. 检查 `tools_init.initialized` 是否为 `true`
+3. 检查 `tools_init.frontend.eslint.configured` 是否为 `true`
+4. 检查 `tools_init.frontend.prettier.configured` 是否为 `true`
+5. 检查 `tools_init.frontend.typescript_path_alias.configured` 是否为 `true`
+
+### 2.2 工具要求
+
+**前端开发必须使用以下工具**：
+- **ESLint**：代码质量检查（语法错误、未使用变量、import 排序、复杂度检查）
+- **Prettier**：代码格式化（统一代码风格）
+- **TypeScript Path Alias**：模块路径别名（@app、@pages、@features、@shared）
+
+**工具作用**：
+- ESLint：自动拦截怪物函数、复杂代码、未使用变量等
+- Prettier：自动统一代码格式，避免风格争议
+- TypeScript Path Alias：支持模块路径别名，便于代码组织
+
+### 2.3 工具未初始化时的处理
+
+**如果工具未初始化或未配置**：
+1. **AI 必须立即停止编码**
+2. **AI 必须提示用户运行工具初始化**：
+   - **CLI 方式**：运行 `aodw` 选择"工具初始化"，或运行 `aodw init-tools`
+   - **AI 方式**：说"初始化工具"或"设置开发工具"
+3. **AI 必须说明**：工具初始化会引导用户完成工具的安装和配置
+4. **在工具初始化完成前，不能开始编码**
+
+### 2.4 工具配置参考
+
+**配置模板位置**：`.aodw/templates/tools-config/frontend/`
+- ESLint 配置模板：`eslint.config.template.json`
+- Prettier 配置模板：`prettier.config.template.json`
+- TypeScript Path Alias 模板：`tsconfig.paths.template.json`
+
+**如果工具已初始化**：
+- 配置应已符合 AODW 规范
+- 配置文件应已生成或合并
+- 工具应已正确安装和配置
+
+**如果需要对配置进行调整**：
+- 可以再次运行工具初始化
+- 或参考配置模板手动调整
+
+---
+
+## 3. 目录结构规范
+
+### 3.1 顶层结构
+
+```
+frontend/
+  src/
+    app/                 # 应用入口、路由、全局 Provider
+    pages/               # 页面级（路由入口）
+    features/            # 可复用业务模块（跨页面）
+    shared/              # 跨业务通用：组件/工具/类型
+    config/              # 配置、环境相关
+    styles/              # 全局样式
+    assets/              # 静态资源
+```
+
+### 3.2 详细结构说明
+
+- `app/`：应用入口、路由、全局 Provider
+  - `router/`：路由定义
+  - `providers/`：全局 Provider（主题、QueryClient 等）
+  - `layout/`：顶层布局（如 AppShell）
+- `pages/`：按路由拆目录，每个页面一个文件夹
+  - `ProjectEditorPage/`
+    - `index.tsx`：页面入口（路由组件）
+    - `Header.tsx`, `Sidebar.tsx`, `Canvas.tsx` 等子组件
+    - `modals/`：页面专用模态框
+    - `hooks/`：页面专用 hooks
+    - `store/`：页面专用 store
+- `features/`：按业务域拆目录（project、user、auth…）
+  - `project/`
+    - `components/`：项目相关可复用组件
+    - `hooks/`：项目相关可复用 hooks
+    - `store/`：项目相关 store（全局/跨页面）
+    - `api/`：与项目相关的 API 封装
+- `shared/`：跨业务通用
+  - `components/`：通用组件（Button、Card、Table、Dialog 等）
+  - `hooks/`：通用 hooks（useDebounce、useResizeObserver 等）
+  - `store/`：通用全局状态
+  - `utils/`：工具函数（日期、格式化、日志）
+  - `types/`：通用类型/接口声明
+
+### 3.3 依赖关系规则
+
+- `pages/`：可以依赖 `features/` 和 `shared/`
+- `features/`：可以依赖 `shared/`，但尽量不要彼此深度耦合
+- `shared/`：只能依赖 `shared` 自身，不依赖 `pages` 或 `features`
+
+---
+
+## 4. 命名规范
+
+### 4.1 文件命名
+
+- React 组件文件：PascalCase（如 `ProjectEditorPage/index.tsx`、`Header.tsx`）
+- hooks 文件：`useXxx.ts`（如 `useProjectEditorData.ts`）
+- Zustand store：`xxx.store.ts`（如 `projectEditor.store.ts`）
+- 类型声明：`xxx.types.ts` 或集中放在 `shared/types` 中
+- 工具函数：`xxx.utils.ts` 或放在 `shared/utils` 下
+
+### 4.2 组件和变量命名
+
+- 组件：PascalCase
+- 变量/函数：camelCase
+- 常量：SCREAMING_SNAKE_CASE
+- hooks：以 `use` 开头，返回 `[state, actions]` 或对象
+
+---
+
+## 5. TypeScript 规范
+
+- 启用严格模式：`"strict": true`
+- 禁止滥用 `any`：使用 `unknown` + 类型收窄 或 合理定义接口
+- API 层优先使用：
+  - DTO 类型（请求）
+  - Response 类型（响应）
+- 类型命名：
+  - 接口/类型：`Project`, `ProjectDetail`, `UserProfile`
+  - 不建议 `IProject` 这种前缀
+
+---
+
+## 6. React 编码规范
+
+### 6.1 组件类型
+
+- 优先使用函数组件 + Hooks
+- 不使用 class 组件
+- 每个文件聚焦一个主要组件
+- 如果一个文件内存在多个复杂组件 → 拆文件
+
+### 6.2 状态管理策略
+
+- 页面局部状态：`useState` / `useReducer`
+- 页面内复杂状态：页面专用 `hooks/` + `store/`（Zustand）
+- 跨页面共享业务状态：放在 `features/*/store`
+- 全局通用状态：放在 `shared/store`
+- **原则**：能局部就不全局，能 hook 就不 store
+
+### 6.3 副作用 & 数据请求
+
+- 所有数据请求封装在：
+  - `features/*/api`
+  - 或页面专用 hooks：`pages/*/hooks`
+- **禁止**在组件中直接调用 `fetch/axios`
+- 统一用 `apiClient` / 封装方法
+
+---
+
+## 7. Tailwind & Radix 使用规范
+
+### 7.1 Tailwind
+
+- 使用 `className` 写原子类，尽量保持每个组件的 `className` 长度可读
+- 复杂样式组合抽离到：
+  - `cn()` 帮助函数结合条件类
+  - 或封装为组件，例如 `<PrimaryButton />`
+- 不在逻辑代码里到处写硬编码颜色，优先用设计系统中的 token（在 Tailwind config 中定义）
+
+### 7.2 Radix UI
+
+- Radix 组件作为"基础交互组件"，在 `shared/components` 中封装
+- 例如 Dialog、Popover、DropdownMenu 封装为：
+  - `SharedDialog.tsx`
+  - `DropdownMenu.tsx`
+- 页面或业务组件不直接大量拼 Radix 基础元素，而是复用封装后的组件
+
+---
+
+## 8. AI 实现流程约束（强制要求）
+
+AI 在编写前端代码时必须遵守以下流程：
+
+### 8.1 第一步：输出目录与文件拆分方案（必须）
+
+- 必须先给出目录和文件拆分方案
+- 解释每个文件的职责
+- 确保符合文件大小限制：
+  - 页面入口组件（index.tsx）≤ 300 行（推荐 ≤ 250 行）
+  - 普通组件 / hooks / store 文件 ≤ 200 行
+  - 单个函数 ≤ 60 行
+  - 复杂度控制：complexity ≤ 10
+- **等待用户确认拆分方案**
+
+### 8.2 第二步：按文件逐步实现
+
+- 每次只实现一个文件
+- 每次只输出一个文件的完整代码
+- 确保每个文件符合规范
+
+### 8.3 第三步：重构大文件
+
+- 在已有大文件重构时，优先拆分成多个小文件
+- 不要继续追加代码到已有大文件
+
+### 8.4 禁止行为
+
+- ❌ 禁止一次性生成巨型文件
+- ❌ 禁止把所有代码都写在一个目录或一个文件里
+- ❌ 禁止在未输出拆分方案前就开始编码
+- ❌ 禁止在用户未确认拆分方案前就开始编码
+- ❌ 禁止在工具配置未完成前就开始编码
+
+---
+
+## 9. 前端代码提交前检查清单
+
+在提交前端代码前，必须完成以下检查：
+
+- [ ] **工具初始化检查**（参考 `.aodw/03-standards/stacks/react-typescript/ai-coding-rules-frontend.md` 第 2 节）：
+  - [ ] 工具是否已初始化？（检查 `.aodw/tools-status.yaml`）
+  - [ ] ESLint 是否已安装并配置？
+  - [ ] Prettier 是否已安装并配置？
+  - [ ] TypeScript path alias 是否已配置？
+- [ ] **目录结构检查**：
+  - [ ] 新页面是否放在 `src/pages/<PageName>/` 下？
+  - [ ] 可复用业务逻辑是否放在 `src/features/<domain>/` 下？
+  - [ ] 通用组件/hooks/工具是否放在 `src/shared/` 下？
+  - [ ] 依赖关系是否符合规范（pages → features/shared, features → shared）？
+- [ ] **文件大小检查**（参考 `.aodw/03-standards/ai-coding-rules-common.md`）：
+  - [ ] 页面入口组件（index.tsx）是否 ≤ 300 行？
+  - [ ] 普通组件/hooks/store 文件是否 ≤ 200 行？
+  - [ ] 单个函数是否 ≤ 60 行？
+  - [ ] 复杂度是否 ≤ 10？
+- [ ] **命名规范检查**：
+  - [ ] React 组件文件是否使用 PascalCase？
+  - [ ] hooks 文件是否以 `use` 开头？
+  - [ ] Zustand store 是否使用 `xxx.store.ts` 命名？
+  - [ ] 组件是否使用 PascalCase，变量/函数是否使用 camelCase？
+- [ ] **TypeScript 规范检查**：
+  - [ ] 是否启用严格模式？
+  - [ ] 是否避免使用 any？
+  - [ ] API 层是否使用 DTO 类型和 Response 类型？
+- [ ] **React 编码规范检查**：
+  - [ ] 是否使用函数组件 + Hooks？
+  - [ ] 数据请求是否封装在 features/*/api 或页面专用 hooks？
+  - [ ] 是否不在组件中直接调用 fetch/axios？
+- [ ] **Tailwind & Radix 使用规范检查**：
+  - [ ] 是否使用 className 写原子类？
+  - [ ] 复杂样式是否抽离到 cn() 或封装为组件？
+  - [ ] Radix UI 是否在 shared/components 中封装？

package/.aodw/03-standards/stacks/vue2/ai-coding-rules-frontend.md

@@ -0,0 +1,97 @@
+# AI Coding Rules - Frontend Development
+
+> **注意**：本文件是 `.aodw/03-standards/ai-coding-rules.md` 的子规范文件。  
+> 请先阅读主文件了解通用编码原则，再阅读本文件了解前端特定规范。
+
+**适用场景**：
+- 前端开发（Vue 2.6 + Webpack 4 + Element-UI）
+- UI 组件开发
+- 前端工具配置
+
+---
+
+## 1. 技术栈确认
+
+适用项目技术栈：
+- **框架**：Vue 2.6.14 (Option API)
+- **UI 组件库**：Element-UI 2.15.7
+- **工程化**：Webpack 4 + Babel
+- **状态管理**：Vuex (如有) 或 Vue.observable
+- **网络请求**：Axios (0.18.1)
+- **样式**：SASS/SCSS + PostCSS
+
+---
+
+## 2. 工具配置检查
+
+在开始编码前，AI 应检查以下配置：
+- **ESLint**: 检查 `.eslintrc.js` 确保适用于 Vue 2。
+- **Prettier**: 确保配置符合项目风格。
+- **PostCSS**: 检查兼容性配置。
+
+---
+
+## 3. 目录结构规范
+
+### 3.1 核心目录
+```
+frontend/
+  src/
+    api/              # 接口请求定义
+    assets/           # 静态资源 (图片、字体、全局样式)
+    components/       # 通用业务组件
+    directive/        # 自定义指令
+    filters/          # 全局过滤器
+    layout/           # 页面布局
+    router/           # 路由定义
+    store/            # Vuex 状态管理
+    utils/            # 工具函数
+    views/            # 页面组件
+    App.vue           # 根组件
+    main.js           # 入口文件
+```
+
+### 3.2 依赖规则
+- **views**: 依赖组件、API、Store。
+- **components**: 依赖 API、Utils，不建议依赖 views。
+- **api**: 仅负责数据请求。
+
+---
+
+## 4. 命名规范
+
+- **组件文件**: PascalCase (如 `ProjectList.vue`)。
+- **目录名**: kebab-case 或 camelCase。
+- **变量/函数**: camelCase。
+- **生命周期钩子**: 严格按照 Vue 2 官方推荐顺序排列。
+
+---
+
+## 5. Vue 2 编码规范
+
+### 5.1 组件定义
+- 必须包含 `name` 属性，便于调试。
+- `data` 必须是一个函数。
+- `props` 必须定义类型、默认值或是否必传。
+
+### 5.2 样式约定
+- 组件样式建议使用 `scoped`，避免污染全局。
+- 优先使用项目定义的 SASS 变量。
+
+### 5.3 跨组件通信
+- 父子组件：Props & Emit。
+- 跨级组件：Provide / Inject 或 Vuex。
+- 兄弟组件：EventBus (谨慎使用) 或 Vuex。
+
+---
+
+## 6. AI 实现流程约束
+
+### 6.1 文件拆分原则
+- 单个 `.vue` 文件代码量建议 ≤ 500 行。
+- 复杂的业务逻辑建议拆分到 `src/utils` 或通过 Mixin (慎用) 提取。
+- 超过 300 行的 `template` 应当考虑拆分子组件。
+
+### 6.2 代码生成策略
+- 优先生成符合 Vue 2 语法的代码（Option API）。
+- 确保所有的 `import` 路径正确（使用项目中定义的别名，如 `@`）。

package/.aodw/03-standards/ui-kit/ui-kit.md

@@ -0,0 +1,163 @@
+# UI-Kit: 统一 UI 设计规范
+
+> **设计目标**：看起来像"成熟产品"，而不是"AI Demo"。克制、冷静、耐看，更接近 Linear / Notion / Stripe，而不是 AI 工具官网。
+
+---
+
+## 1. UI 设计系统（Design System）
+
+### 1.1 设计目标
+- 看起来像"成熟产品"，而不是"AI Demo"
+- 克制、冷静、耐看
+- 更接近 Linear / Notion / Stripe，而不是 AI 工具官网
+
+### 1.2 颜色系统（关键）
+
+#### ❌ 严禁使用
+- 蓝紫渐变
+- 紫色主色
+- 霓虹色、高饱和度红/蓝
+- 科技感发光效果
+
+#### ✅ 允许的主色方向（任选其一）
+- 深灰 + 中性蓝
+- 深灰 + 墨绿
+- 深灰 + 暖棕
+- 黑白灰 + 单一低饱和强调色
+
+#### 推荐基础色
+- Text Primary: #111827
+- Text Secondary: #6B7280
+- Border: #E5E7EB
+- Background: #FFFFFF / #F9FAFB
+
+### 1.3 字体与排版
+- 字体风格：中性、无装饰
+- 禁止大号粗体堆砌
+- 所有页面必须有清晰层级
+
+#### 层级示例
+- H1: 20–24px / semibold
+- H2: 16–18px / semibold
+- Body: 14px / regular / line-height ≥ 1.6
+- Meta: 12px / regular
+
+### 1.4 布局与留白
+- 使用 8px spacing system
+- 页面必须有呼吸感
+- 不允许"信息塞满屏幕"
+
+### 1.5 组件风格
+- Card：轻边框 / 无阴影或极弱阴影
+- Button：扁平、低饱和
+- Form：label + helper text 必须存在
+
+### 1.6 整体风格关键词
+> calm / neutral / restrained / professional / human-made
+
+---
+
+## 2. UI 生成提示词（Generation Prompt）
+
+你现在不是 AI 工具展示界面设计师，而是在为一款真实上线的专业产品设计 UI。
+
+### 2.1 必须遵守的规则
+
+1. **禁止任何"AI 感"设计**
+   - 不使用蓝紫渐变
+   - 不使用发光、未来感、科技感
+   - 不出现"AI 官网风格"
+
+2. **设计目标**
+   - 像 Linear / Notion / Stripe Dashboard
+   - 克制、冷静、耐看
+   - 看起来是人类设计师做的
+
+3. **所有 UI 必须**：
+   - 先给出结构与设计说明
+   - 再给代码
+   - 如果不确定好不好看，优先删减而不是增加
+
+4. **UI 必须严格遵循本文件第 1 节（UI 设计系统）中的规范**
+   - 不允许自行发挥审美
+
+---
+
+## 3. 禁止的 AI 风格（Forbidden AI Style）
+
+以下设计一旦出现，视为失败：
+
+- 蓝紫渐变背景
+- 紫色 / 品红色主色
+- 高饱和科技蓝
+- 发光边框
+- 未来 HUD 风格
+- 赛博、量子、AI Lab 视觉语言
+
+**出现以上任意一项，必须重做 UI。**
+
+---
+
+## 4. UI Critic Agent（UI 审查官）
+
+### 4.1 角色定位
+
+你是一个非常挑剔的资深 UI/UX 设计总监。
+
+你的任务不是写代码，而是：
+- 找出界面"像 AI 做的地方"
+- 指出哪里丑、哪里廉价、哪里不成熟
+- 强制要求简化和重构
+
+### 4.2 评判标准
+
+1. 是否有 AI 默认审美特征
+2. 是否像真实产品，而不是 Demo
+3. 是否存在颜色、排版、层级滥用
+4. 是否"用力过猛"
+
+### 4.3 输出要求
+
+你的输出必须包含：
+- **丑点清单**（明确指出）
+- **为什么丑**
+- **如何改**
+- **是否建议整体重做**（是 / 否）
+
+你可以非常严格，不需要安慰。
+
+---
+
+## 5. 快速参考
+
+### 5.1 设计检查清单
+
+- [ ] 是否使用了蓝紫渐变？
+- [ ] 是否使用了紫色/品红色主色？
+- [ ] 是否有发光效果或科技感装饰？
+- [ ] 颜色是否克制、低饱和？
+- [ ] 排版是否有清晰层级？
+- [ ] 留白是否充足？
+- [ ] 是否像真实产品而非 Demo？
+
+### 5.2 设计原则总结
+
+1. **克制优先**：如果不确定好不好看，优先删减而不是增加
+2. **真实产品感**：像 Linear / Notion / Stripe，而不是 AI 工具官网
+3. **人类设计感**：看起来是人类设计师做的，而不是 AI 生成的
+4. **严格遵循规范**：不允许自行发挥审美，必须遵循本文件第 1 节的规范
+
+---
+
+## 6. 文件结构说明
+
+本文件合并了以下 4 个原始文件的内容：
+- `ui_design_system.md` → 第 1 节：UI 设计系统
+- `ui_generation_prompt.md` → 第 2 节：UI 生成提示词
+- `forbidden_ai_style.md` → 第 3 节：禁止的 AI 风格
+- `ui_critic_agent.md` → 第 4 节：UI Critic Agent
+
+**使用建议**：
+- 在 UI 任务时，读取本文件即可获得所有 UI 设计规范
+- 如需引用特定章节，使用章节编号（如"第 1 节：UI 设计系统"）
+