@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-design/skills/workflow-backend-tech-spec/assets/adr-template.md

@@ -0,0 +1,57 @@
+# ADR-{序号}: {决策主题}
+
+## 状态
+
+[已确认 / 待定 / 已废弃]
+
+## 上下文
+
+{当时面临的问题和约束。描述你试图解决的问题，以及什么因素限制了你。
+
+示例：
+> 订单审批功能需要在现有 OrderService 上扩展。但 OrderService 当前有 3 个调用方（订单创建、退款处理、批量查询），每个调用方依赖不同的方法。如果在 OrderService 上新增 approval 方法，会使其接口膨胀到 12 个公开方法，且 approval 逻辑与现有方法无共享代码。}
+
+## 被否决的方案
+
+{列出至少一个认真考虑过的替代方案，以及为什么被否决。
+
+示例：
+> **方案 B：扩展 OrderService**
+> - 在 OrderService 上新增 `ProcessApproval()` 方法
+> - 优点：代码复用（跟 Order 相关的逻辑在一起）
+> - 缺点：OrderService 的公开方法从 9 个增加到 12 个，接口变得更浅
+>   - Deletion Test 失败：删除 OrderService 时，approval 逻辑不会消失，而是分散到各调用方
+>   - 现有 3 个调用方理论上依赖整个 OrderService，修改风险增加}
+
+## 决策
+
+{最终选择的方案及理由。
+
+示例：
+> **方案 A：新建 OrderWorkflow 模块**
+> - 新建 `internal/workflow/order_workflow.go`
+> - 只暴露一个入口：`Process(orderId string, action Action) (OrderStatus, error)`
+> - 内部封装：权限校验 → 状态机转换 → 通知 → 审计日志
+> - 理由：符合 Deep Module 原则（小接口大实现），调用方只需要知道一个方法}
+
+## 后果
+
+{列出这个决策的正面和负面后果。
+
+示例：
+> - 正面：OrderService 保持稳定，新增功能不影响现有调用方
+> - 负面：多一个模块，增加项目复杂度
+> - 兼容性：无影响。旧功能继续使用 OrderService，新功能使用 OrderWorkflow
+> - 迁移路径：后续可考虑将 OrderService 中与状态机相关的逻辑逐步迁移到 OrderWorkflow}
+
+---
+
+## ADR 创建检查清单
+
+创建前确认：
+
+- [ ] **难逆转**：改主意代价大（是 → 才需要 ADR）
+- [ ] **无上下文会困惑**：后人会问"为什么"（是 → 才需要 ADR）
+- [ ] **有真实权衡**：存在替代方案（是 → 才需要 ADR）
+
+不满足任意一条 → 不要创建 ADR，把决策直接写在方案文档中即可。

package/plugins/devflow-design/skills/workflow-backend-tech-spec/assets/backend-spec-template.md

@@ -0,0 +1,205 @@
+# 后端技术方案：{{功能名称}}
+
+## 一、功能概述
+
+{{简要描述功能目的和业务背景，2-3 句话}}
+
+### 1.1 当前执行切片
+
+- **Slice ID**：{{SL-001}}
+- **切片名称**：{{切片名称}}
+- **纳入范围**：{{FP/BR/BC 列表}}
+- **后置范围**：{{SL-002 等，仅作上下文}}
+- **切片门禁**：{{本切片通过标准}}
+
+## 二、功能要点
+
+1. **功能点1**：描述
+2. **功能点2**：描述
+3. **功能点3**：描述
+
+## 三、需求基线衔接
+
+### 3.1 需求来源与功能点映射
+
+| 基线对象 | 名称/摘要 | 后端处理方式 |
+|----------|-----------|--------------|
+| FP-001 | {{功能点名称}} | {{新增/修改/影响/不涉及后端}} |
+| BR-001 | {{业务规则}} | {{后端规则承接方式}} |
+| BC-001 | {{边界场景}} | {{后端边界承接方式}} |
+
+### 3.2 反向审视与用户拍板承接
+
+| CR ID | 维度 | 用户决策/状态 | 对后端方案的影响 |
+|-------|------|---------------|------------------|
+| CR-001 | {{冲突/复用/历史/过度工程/替代方案}} | {{已确认/待确认/不适用}} | {{方案如何承接；待确认则说明阻塞点}} |
+
+### 3.3 历史/里程碑依据
+
+| 来源 | 结论 | 对本方案的影响 |
+|------|------|----------------|
+| `.planning/milestones/...` | {{结论}} | {{影响}} |
+| `.planning/requirements/...` | {{结论}} | {{影响}} |
+| `.planning/lessons/...` | {{结论}} | {{影响}} |
+
+## 四、现有功能说明
+
+### 4.1 {{现有功能A}}流程（现状）
+
+```mermaid
+flowchart TD
+    A[步骤1] --> B[步骤2]
+    B --> C[步骤3]
+```
+
+**现有字段/配置说明：**
+| 字段/配置 | 类型 | 说明 |
+|-----------|------|------|
+| field_a | string | 现有字段说明 |
+
+**现有逻辑说明：**
+- 如有 SQL，展示关键 SQL
+- 如有 Job，说明调度频率
+- 如有枚举值，列出现有枚举
+
+### 4.2 {{现有功能B}}（现状）
+
+{{如有多个被影响的现有功能，分小节描述}}
+
+## 五、新增功能流程
+
+### 5.1 {{新功能A}}流程
+
+```mermaid
+flowchart TD
+    A[开始] --> B{判断条件}
+    B -->|是| C[处理1]
+    B -->|否| D[处理2]
+```
+
+### 5.2 {{新功能B}}流程（如涉及对现有功能的扩展）
+
+```mermaid
+flowchart TD
+    subgraph 数据采集
+        A1[原有数据] --> C[数据表]
+        A2[新增数据] --> C
+    end
+    subgraph 处理逻辑
+        D[Job/Service] --> E[处理]
+        E --> F[输出]
+    end
+```
+
+## 六、影响范围
+
+### 6.1 受影响的现有功能
+
+| 功能模块 | 影响点 | 影响程度 |
+|----------|--------|----------|
+| 功能A | 需要新增字段/修改逻辑 | 高/中/低 |
+
+### 6.2 受影响的代码层级
+
+| 层级 | 文件 | 影响点 |
+|------|------|--------|
+| {{领域/模型/服务/持久化/接口/任务/集成/配置/其他}} | {{项目实际路径}} | {{新增/修改/影响点}} |
+
+### 6.3 受影响的接口
+
+| 接口 | 方法 | 影响点 |
+|------|------|--------|
+| /api/xxx | GET | 响应新增字段 |
+| /api/yyy | POST | 请求新增参数 |
+
+## 七、库表设计
+
+### 7.1 新增表
+
+```sql
+CREATE TABLE `表名` (
+  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',
+  `字段1` varchar(64) NOT NULL DEFAULT '' COMMENT '说明',
+  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
+  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
+  PRIMARY KEY (`id`),
+  KEY `idx_字段1` (`字段1`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='表说明';
+```
+
+### 7.2 表变更
+
+```sql
+ALTER TABLE `表名` ADD COLUMN `新字段` int NOT NULL DEFAULT 0 COMMENT '说明';
+```
+
+### 7.3 ER 关系图
+
+```mermaid
+erDiagram
+    TABLE_A ||--o{ TABLE_B : "1对多关系说明"
+    TABLE_A {
+        bigint id PK
+        varchar name
+    }
+    TABLE_B {
+        bigint id PK
+        bigint table_a_id FK
+        int status
+    }
+```
+
+## 八、风险点
+
+| 风险点 | 说明 | 应对措施 |
+|--------|------|----------|
+| 数据迁移 | 现有数据需要处理 | 编写迁移脚本，分批执行 |
+| 性能影响 | 新增查询可能影响 | 添加索引，控制查询范围 |
+| 兼容性 | 老版本客户端 | 接口保持向后兼容 |
+
+## 九、后端规范影响
+
+### 9.1 已读取规则来源
+
+| 规则来源 | 是否存在 | 影响说明 |
+|----------|----------|----------|
+| `.planning/rules/INDEX.md` | {{是/否}} | {{说明}} |
+| `.planning/execution-contract.md` | {{是/否}} | {{说明}} |
+| `.planning/toolchain.md` | {{是/否}} | {{说明}} |
+| `.planning/lessons/README.md` | {{是/否}} | {{说明}} |
+| `.context/spec/backend/index.md` | {{是/否}} | {{说明}} |
+| `.context/workflow/` | {{是/否}} | {{说明}} |
+| `.context/lessons/README.md` | {{是/否}} | {{说明}} |
+| `AGENTS.md` / `CLAUDE.md` | {{是/否}} | {{说明}} |
+
+### 9.2 适用规范
+
+| 层级/场景 | 适用规范 | 对本功能的约束 |
+|-----------|----------|----------------|
+| {{Domain/DAO/Repository/Service/Handler/Job/其他}} | {{规范文件或章节}} | {{命名/签名/错误/日志/事务/分页/权限等约束}} |
+
+### 9.3 相关经验教训
+
+| 教训ID/来源 | 内容摘要 | 本功能规避方式 |
+|-------------|----------|----------------|
+| {{L001/文档路径}} | {{摘要}} | {{如何避免}} |
+
+### 9.4 工具链与生成物
+
+| 类型 | 命令/生成物 | 触发条件 |
+|------|-------------|----------|
+| {{mock/codegen/di/build/test/migration}} | {{命令或文件}} | {{何时执行}} |
+
+### 9.5 测试与审查门禁
+
+| 门禁 | 要求 | 通过标准 |
+|------|------|----------|
+| 单元测试 | {{要求}} | {{通过标准}} |
+| 集成测试 | {{要求}} | {{通过标准}} |
+| 构建检查 | {{要求}} | {{通过标准}} |
+| 规范审查 | {{要求}} | {{通过标准}} |
+
+## 十、待确认事项
+
+1. [ ] 问题1
+2. [ ] 问题2

package/plugins/devflow-design/skills/workflow-backend-tech-spec/references/affected-module-exploration.md

@@ -0,0 +1,59 @@
+# 被影响方探索指引
+
+在完成主功能方（需求直接对应的模块）的代码探索后，**必须**对需求基线中"关联历史功能/模块"表格（baseline 第8.2节）列出的每个受影响模块，执行以下探索。探索产出直接填入输出文档的"现有功能说明"（第四章）和"影响范围"（第六章）章节。
+
+## 核心原则
+
+- **先读懂现状，再分析影响**：不读代码就写"影响点"是在猜，不是在分析。
+- **被影响方和主功能方同等重要**：支付服务、外部回调、已有抽奖服务等被影响方的代码必须和盲盒模块一样被完整阅读。
+- **探索产出必须来自代码**：现状流程图、字段表、方法签名必须来自实际读取的文件。
+
+## 探索清单
+
+对于 baseline 8.2 节列出的每个关联历史模块，按以下步骤执行：
+
+### 步骤1：定位关键文件
+
+优先使用 `.planning/code-index/` 定位候选 symbol、entrypoint、calls、reads/writes 和 tested_by 关系；然后回读 `evidence_path:evidence_line` 附近源码。code-index 不存在或过期时，再按下表的目录约定和 `rg` 兜底。
+
+| 层级 | 定位方式 | 最少读取 |
+|------|----------|----------|
+| Domain | 按模块名搜索 `internal/domain/{module}.go` 或相关命名 | 结构体定义、枚举常量、接口定义 |
+| DAO Model | `internal/repository/dao/model/{module}.go` | 表结构体、字段 tag、TableName |
+| Service | `internal/service/{module}_svc.go` | **完整读完 Interface 定义**（所有方法签名） |
+| Repository | `internal/repository/{module}_repo.go` | Interface 定义和构造函数 |
+| Handler | `internal/web/{module}_handler.go` | 路由注册部分（RegisterRoutes）和构造函数 |
+| 外部集成 | `pkg/{client}/` 或 `ioc/{client}.go` | 客户端构造函数、可用方法 |
+| DI 装配 | `wire.go` 中的对应 wire.Set | 已注册的依赖链 |
+
+**底线**：每个被影响模块至少读取 3 个文件（核心模型/领域对象 + 服务/用例接口或实现 + 入口层），不能仅靠 baseline、navigation 或 code-index 摘要推断。
+
+### 步骤2：回答三个问题
+
+| 问题 | 产出 | 填入模板章节 |
+|------|------|-------------|
+| 现有流程是什么？ | mermaid 流程图（描述当前行为，不是新行为） | 第四章"现有功能说明" |
+| 现有字段/方法/枚举有哪些？ | 表格列出关键字段名、类型、含义 | 第四章"现有功能说明" |
+| 集成点在哪里？ | 列出现有接口路径、注册的回调路由、依赖注入链 | 第六章"影响范围" |
+
+### 步骤3：判断复用/扩展/新增边界
+
+对每个被影响模块，明确以下决策并记录：
+
+| 决策类型 | 说明 | 示例 |
+|----------|------|------|
+| 可复用 | 现有方法/字段/接口可直接用或仅需传新参数 | 复用现有 `ExecuteDrawLotteryTransaction` 事务方法 |
+| 需扩展 | 现有方法签名不变，但内部需要新增分支/字段 | `BlindBoxPlan` 新增字段，但 CreatePlan 流程不变 |
+| 需新增 | 现有模块没有对应能力，需要新建方法/文件 | 新增 `BlindBoxPayOrderRepository` 接口和实现 |
+| 需修改规则 | 现有校验/约束需要放宽或调整 | 移除组织时间冲突校验 |
+
+## 探索产出检查（Phase 2 完成前必须全部通过）
+
+- [ ] 是否对 baseline 8.2 节列出的**每个**关联模块都执行了步骤1~3？
+- [ ] 是否至少有一张基于现有代码绘制的现状流程图？
+- [ ] 是否有现有字段/方法/枚举的结构化表格（不是从 PRD 复制）？
+- [ ] 是否明确了每个模块是"复用"、"扩展"还是"新增"？
+- [ ] 是否实际读取了代码文件（不是仅靠文件名推断）？
+- [ ] 若 `.planning/code-index/` 存在，是否记录了用于定位的 symbol/relation evidence？
+
+**此检查不通过，不得进入 Phase 3（生成文档）。**

package/plugins/devflow-design/skills/workflow-backend-tech-spec/references/backend-conventions.md

@@ -0,0 +1,30 @@
+# 后端技术方案编写规范
+
+## 模板结构要求
+
+每次生成必须包含以下章节：
+1. 功能概述
+2. 功能要点
+3. 需求基线衔接
+4. 现有功能说明（影响分析）
+5. 新增功能流程
+6. 影响范围（项目实际层级 + 接口/消费者）
+7. 库表设计（仅当涉及数据持久化）
+8. 风险点
+9. 后端规范影响
+10. 待确认事项
+
+## 描述规则
+
+- 代码文件路径使用相对于项目根目录的路径
+- 表名、接口路径、枚举、错误码等命名以项目规则包为准；缺少项目规则时采用保守、可读、兼容的命名
+- 流程图使用 Mermaid 语法
+
+## 质量要求
+
+- 涉及新增表时必须有完整建表或迁移说明
+- 涉及表变更时必须有 ALTER/迁移说明和兼容性风险
+- 影响范围必须标注项目实际层级（如 API/业务逻辑/持久化/任务/集成/配置）
+- 风险点必须有应对措施
+- 被影响的现有功能必须先描述现状再描述变更
+- 已确认的 `CR-*` 决策必须在方案中承接；未确认项必须列为阻塞或待确认，不能自行转成技术方案

package/plugins/devflow-design/skills/workflow-backend-tech-spec/references/code-explore-guide.md

@@ -0,0 +1,40 @@
+# 后端代码探索指引
+
+Use this guide to explore the target backend without assuming outbound-call's Go directory layout. Project navigation and local rule packages are authoritative.
+
+## Exploration Order
+
+1. Read `.planning/navigation/INDEX.md` → filter backend/service-type codebases → load their `{name}.md` navigation files to identify root, framework, entry points, layers, persistence, jobs, integrations, config, and commands.
+2. Read the project rule package via `references/project-rule-contract.md`.
+3. Start from baseline `FP-*`, `BR-*`, `BC-*`, and confirmed `CR-*` decisions.
+4. Search only the relevant modules first; expand outward only when the call chain or data flow requires it.
+
+## Conceptual Layers
+
+Map the project-specific files into these conceptual areas. Names vary by language and framework.
+
+| Area | What To Find | Typical Examples |
+|------|--------------|------------------|
+| Entry/API | routes, controllers, handlers, resolvers, RPC endpoints | `routes/`, `controllers/`, `handlers/`, `api/`, `web/` |
+| Business Logic | services, use cases, application layer, domain operations | `service/`, `usecase/`, `application/`, `domain/` |
+| Data/Persistence | models, repositories, DAO, ORM mappings, migrations | `model/`, `repository/`, `dao/`, `migrations/`, `schema/` |
+| Async/Jobs | scheduled jobs, queue producers/consumers, workers | `jobs/`, `worker/`, `queue/`, `cron/` |
+| Integration | external clients, SDK wrappers, adapters | `client/`, `integration/`, `pkg/`, `adapter/` |
+| Config/Auth | configuration, permissions, tenant/data-scope rules | `config/`, `auth/`, `permission/`, `middleware/` |
+
+Use actual paths from navigation and code search. Do not invent these folders when the project uses different names.
+
+## Search Tactics
+
+- Start from known identifiers in the requirement: entity names, API paths, field names, status names, permission keys, job names, integration names.
+- For data changes, trace from schema/model/migration to business logic and outward to consumers.
+- For behavior changes, trace from entry/API or user-facing trigger to business logic, persistence, async jobs, and integrations.
+- For statistics/reporting, find source data, aggregation timing, cache/materialized tables, and downstream consumers.
+- For compatibility, find old clients, response contracts, existing data, config defaults, and feature flags.
+
+## Reading Focus
+
+- Current behavior and invariants before proposing changes.
+- Reuse candidates across business capability, installed dependencies, and project patterns.
+- Conflicts with confirmed baseline decisions or project rules.
+- Required toolchain steps such as schema generation, mocks, DI, API client generation, migrations, build, lint, and tests.

package/plugins/devflow-design/skills/workflow-backend-tech-spec/references/project-rule-contract.md

@@ -0,0 +1,66 @@
+# Project Rule Package Contract
+
+Use this contract when generating backend technical plans. A project rule package is the project-specific source of truth for how backend work should be designed, implemented, tested, and reviewed.
+
+## Discovery Order
+
+Look for rule sources in the target project, in this order:
+
+1. `.planning/rules/INDEX.md`
+2. `.planning/execution-contract.md`
+3. `.planning/toolchain.md`
+4. `.planning/lessons/README.md`
+5. `.planning/milestones/`
+6. `.planning/requirements/`
+7. `.context/spec/index.md`
+8. matching `.context/spec/stacks/{stack_key}.md`
+9. matching `.context/spec/backend/{codebase}.md`
+10. `.context/spec/backend/index.md`
+11. `.context/spec/backend/`
+12. `.planning/code-index/` when source-level relation facts are needed
+13. `.context/workflow/tdd.md`
+14. `.context/workflow/verification.md`
+15. `.context/workflow/checklist.md`
+16. `.context/lessons/README.md`
+17. root `AGENTS.md`, `CLAUDE.md`, or equivalent project instruction files
+
+If none exist, explicitly write `未发现项目规则包` and continue with code exploration and conservative assumptions.
+
+History rule:
+
+- Use `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and phase `CONTEXT.md` files as the primary history model.
+- Treat `.context/lessons/` and `features/` as compatible legacy/project-rule evidence only when present in the target project.
+- Do not require outbound-call style history files.
+
+## What To Extract
+
+Extract only backend-relevant rules:
+
+- Technology stack and framework.
+- Matching stack spec and codebase spec from `.context/spec/index.md` when available.
+- Code-index symbols/relations for affected entrypoints, callers, callees, data/resource reads and writes, tests, and external integrations when `.planning/code-index/` exists.
+- Layer model and dependency direction.
+- Naming, function signature, validation, error handling, logging, transaction, pagination, permission, and data access rules.
+- Required code generation, mock generation, dependency injection, migration, or build commands.
+- Unit test, integration test, and end-to-end verification expectations.
+- Review checklist and historical lessons that apply to this feature.
+- Confirmed requirement challenge decisions from baseline `反向审视与用户拍板`.
+- Pending baseline decisions that block backend planning.
+
+Do not copy the entire rule source. Summarize the rules that affect the current feature.
+
+## Backend Plan Output
+
+The backend technical plan must include a `后端规范影响` section with:
+
+- Rule sources read.
+- Baseline challenge decisions consumed and pending blockers.
+- Affected layers.
+- Code-index evidence used or the reason it was unavailable.
+- Applicable rules.
+- Related lessons.
+- Toolchain and generated artifact requirements.
+- Test strategy contract.
+- Review gates.
+
+If a rule conflicts with the requested behavior or existing code, record it as a risk or pending question. Do not silently choose between conflicting rules.

package/plugins/devflow-design/skills/workflow-design-rule-pack/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: workflow-design-rule-pack
+description: Use when workflow-ui-spec or workflow-frontend-tech-spec needs a reusable UI/UX design rule package, ui-ux-pro-max recommendations, or project installation of .context/spec/design across repositories.
+---
+
+# Workflow Design Rule Pack
+
+This skill provides the reusable source for the project design rule package consumed by `workflow-ui-spec` and `workflow-frontend-tech-spec`.
+
+## When to Use
+
+Use this skill when:
+
+- A project lacks `.context/spec/design/index.md`.
+- UI workflow steps need the shared UI/UX recommendation pack.
+- `ui-ux-pro-max` should be available in a project without copying it by hand.
+- The same design rules need to be reused across repositories.
+
+`workflow-project-context` is the default lifecycle owner for frontend projects: it invokes this installer after the code index is ready, records the result in the initialization manifest, and owns `.context/spec/design/index.md`. Call this skill directly only to repair or deliberately refresh the shared recommendation assets.
+
+Do not use this skill as a replacement for `workflow-ui-spec` or `workflow-frontend-tech-spec`. It only installs and documents shared references; workflow skills still decide how to apply them.
+
+## Install Into Current Project
+
+Run from the target repository root:
+
+```text
+devflow_design_rule(args=[])
+```
+
+Default behavior:
+
+- Copies `assets/design/` into `.context/spec/design/`.
+- Creates missing directories.
+- Does not overwrite existing project files.
+- Keeps project-specific confirmed tokens in the target project.
+
+To overwrite shared recommendation files intentionally:
+
+```text
+devflow_design_rule(args=["--overwrite"])
+```
+
+When project initialization owns the design index, install only assets and tools:
+
+```text
+devflow_design_rule(args=["--without-index"])
+```
+
+To install into another repository:
+
+```text
+devflow_design_rule(args=["--target", "/path/to/repo"])
+```
+
+## Executable Self-Check
+
+Run this after a normal installation from the target repository root:
+
+```bash
+for path in \
+  index.md \
+  tokens/project-tokens.md \
+  recommendations/accessibility.md \
+  recommendations/component-library.md \
+  tools/ui-ux-pro-max/SKILL.md; do
+  test -s ".context/spec/design/$path"
+done
+```
+
+For an installation using `--without-index`, run the same command without `index.md`.
+
+Pass only when every expected file exists and is non-empty. A missing file, a zero-byte file, or an installation target other than the intended repository root is a failure: rerun the installer with the correct `--target`, and use `--overwrite` only when replacement is deliberate.
+
+## Source of Truth
+
+- Skill source: `skill://workflow-design-rule-pack/assets/design/`
+- Project installed copy: `.context/spec/design/`
+
+Workflow skills must read the installed project copy. The project copy is the place where local overrides and confirmed project tokens live.
+
+## Boundary
+
+Design conclusion priority remains:
+
+1. User decisions, design artifacts, confirmed requirement baseline
+2. Existing code, component library, current project tokens
+3. `.context/spec/design/tokens/project-tokens.md`
+4. `.context/spec/design/recommendations/` and `ui-ux-pro-max` query results
+
+Recommendation sources are never authoritative project facts unless the user or project rules explicitly confirm them.

package/plugins/devflow-design/skills/workflow-design-rule-pack/assets/design/index.md

@@ -0,0 +1,71 @@
+# Design Spec Index
+
+本目录提供项目级 UI/UX 规则入口。workflow skill 读取设计规则时，先读本文件，再按当前任务读取对应章节。
+
+## 读取顺序
+
+1. 先读取本项目已确认规范：
+   - `tokens/project-tokens.md`
+2. 再读取通用推荐规则：
+   - `recommendations/design-systems.md`
+   - `recommendations/component-library.md`
+   - `recommendations/responsive-grid.md`
+   - `recommendations/ux-patterns.md`
+   - `recommendations/accessibility.md`
+   - `recommendations/stack-guidelines.md`
+3. 如需要按产品类型、行业、风格或技术栈动态补充，调用：
+   - `tools/ui-ux-pro-max/scripts/search.py`
+
+## 优先级
+
+设计相关结论必须按以下优先级合并：
+
+1. 用户拍板、设计稿事实、已确认需求基线
+2. 现有代码、现有组件库、现有项目 token
+3. `tokens/project-tokens.md` 中的项目级已确认设计 token
+4. `recommendations/` 与 `ui-ux-pro-max` 动态查询结果
+
+推荐规则只能补充缺口，不得覆盖已确认事实。若推荐值与设计稿、代码或用户拍板冲突，写入待确认事项或风险，不得自行改判。
+
+## ui-ux-pro-max 动态查询
+
+工具位置：
+
+```bash
+python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "<query>" --design-system -p "<Project Name>"
+python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "<query>" --domain ux
+python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "<query>" --stack react
+```
+
+常用域：
+
+| Domain | 用途 |
+|--------|------|
+| `product` | 产品类型与 UI 模式推荐 |
+| `style` | 视觉风格、效果、实现关键词 |
+| `color` | 产品类型对应配色建议 |
+| `typography` | 字体组合建议 |
+| `landing` | 落地页结构与 CTA |
+| `ux` | 可用性、交互、状态、动效、可访问性 |
+| `chart` | 图表类型与可访问性 |
+| `react` | React/Next 性能与实现建议 |
+| `web` | Web 表单、语义、focus、键盘等规则 |
+
+常用技术栈：
+
+`html-tailwind`, `react`, `nextjs`, `vue`, `svelte`, `swiftui`, `react-native`, `flutter`, `shadcn`, `jetpack-compose`
+
+## Workflow 接入点
+
+### workflow-ui-spec
+
+在“理解产品上下文”之后、“设计解析”之前读取本文件。若设计稿缺失或设计稿未覆盖配色、字体、布局、状态、响应式等细节，可调用 `ui-ux-pro-max` 生成推荐，并在 UI-SPEC 中分开输出：
+
+- 设计稿事实
+- 现有项目规范
+- 推荐方案（待拍板）
+- 待确认事项
+
+### workflow-frontend-tech-spec
+
+在“理解需求”和“探索现有前端代码”之后读取本文件。前端技术方案只能把已确认 token 和项目规则作为实现依据；推荐规则用于补充实现注意点、风险、测试门禁和待确认事项。

package/plugins/devflow-design/skills/workflow-design-rule-pack/assets/design/recommendations/accessibility.md

@@ -0,0 +1,31 @@
+# Accessibility Recommendations
+
+本文件提供可访问性参考。项目已有 a11y 规范优先。
+
+## 基础门禁
+
+- 正文文本对比度不低于 4.5:1，较大文本不低于 3:1。
+- 交互元素必须有清晰 focus 状态。
+- 图标按钮、仅图标链接必须有可访问名称。
+- 表单输入必须有关联 label 或等效语义。
+- 键盘 Tab 顺序应符合视觉和业务顺序。
+- 颜色不能作为唯一状态表达。
+- 图片按语义区分：有意义图片写 alt，装饰图可空 alt。
+- 弹窗打开后焦点进入弹窗，关闭后焦点回到触发元素。
+
+## 前端技术方案输出
+
+前端技术方案必须在状态与交互门禁中写明：
+
+- Focus 验证方式
+- 表单 label 验证方式
+- 键盘操作覆盖范围
+- 色彩对比验证方式
+- 图标按钮可访问名称检查
+
+## 查询辅助
+
+```bash
+python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "accessibility aria focus keyboard form labels color contrast" --domain ux
+python3 .context/spec/design/tools/ui-ux-pro-max/scripts/search.py "aria focus keyboard semantic form" --domain web
+```