diff --git a/Project/fonrey/PRD/登录管理/用户登录管理模块PRD.md b/Project/fonrey/PRD/登录管理/用户登录管理模块PRD.md index 8908470e..e9d11846 100644 --- a/Project/fonrey/PRD/登录管理/用户登录管理模块PRD.md +++ b/Project/fonrey/PRD/登录管理/用户登录管理模块PRD.md @@ -2,8 +2,8 @@ **状态**: Draft **作者**: 产品经理 -**最后更新**: 2026-04-24（v1.1 验证码方式由图形字符验证码更新为滑块拼图行为验证码） -**版本**: 1.1 +**最后更新**: 2026-04-24（v1.3 明确账号创建权限层级：Tenant Admin 可自定义用户名/密码；普通员工账号由 Tenant Admin 在新增员工时创建，用户名为手机号，初始密码固定，首次登录强制修改） +**版本**: 1.3 **所属系统**: Fonrey 房产经纪管理系统 **关联模块**: 组织人事管理、权限管理、系统管理 @@ -246,7 +246,7 @@ POST /api/auth/wechat/callback/ # 微信扫码确认后回调，换取系 | Logo | Fonrey 产品 Logo，居中显示 | | 标题 | 「欢迎使用 Fonrey 房睿」 | | 副标题 | 「请输入您公司的专属识别码以继续」 | -| Tenant ID 输入框 | 单行文本，最大长度 64 字符，支持粘贴 | +| Tenant ID 输入框 | 单行数字输入，固定 12 位，支持粘贴；非数字字符自动过滤，超出 12 位截断 | | 输入框 Label | 「公司识别码（Tenant ID）」 | | 确认按钮 | 主色调按钮，文字「确认」 | | 错误提示 | 输入框下方红色文字，固定区域占位（不影响布局抖动） | @@ -254,10 +254,11 @@ POST /api/auth/wechat/callback/ # 微信扫码确认后回调，换取系 #### 5.1.3 Tenant ID 格式规范 -- Tenant ID 由系统管理模块生成（每个租户在开通时由平台运营分配） -- 格式建议：`tenant_`，如 `tenant_fonrey_demo`，仅包含字母、数字、下划线，不区分大小写 -- 长度：6 ~ 64 字符 -- 客户端存储位置：Electron `app.getPath('userData')` 目录下的配置文件（加密存储，防止明文读取） +- **格式**：固定 **12 位纯数字**，如 `202500010001` +- **生成规则**（建议）：由平台运营在系统管理后台开通租户时自动生成，不允许手动指定，确保全局唯一性；可采用时间戳前缀 + 随机后缀的方式生成（如 `YYYYMM` + 6 位随机数） +- **前端校验**：输入框仅接受数字字符（非数字自动过滤），输入满 12 位后自动触发格式完成状态；少于 12 位时点击「确认」弹出提示「识别码须为 12 位数字」 +- **唯一性**：全局唯一（公共 Schema 层面），同一 Tenant ID 不可分配给多个租户 +- **客户端存储**：Electron `app.getPath('userData')` 目录下的配置文件（加密存储，防止明文读取） #### 5.1.4 服务端 Tenant 验证接口规范 @@ -266,7 +267,7 @@ POST /api/auth/tenant/verify/ Request Body: { - "tenant_id": "tenant_fonrey_demo" + "tenant_id": "202500010001" } Response 200 (成功): @@ -346,29 +347,67 @@ Response 200 (失败): #### 5.3.1 绑定原则 -- 每个系统登录账号（username）必须与「组织人事管理」模块中的一条**员工档案（Staff）**绑定 -- 员工档案包含：姓名、工号、手机号（可选，未来用于手机登录）、邮箱（用于找回密码）、所属门店/组别 +- 每个系统登录账号必须与「组织人事管理」模块中的一条**员工档案（Staff）**绑定 - 账号与员工是 **1:1 关系**，一个员工对应一个账号，一个账号只能绑定一个员工 -- 账号创建流程：**由系统管理员在「组织人事管理 → 员工列表」中为员工开通账号**，不支持用户自行注册 -- 账号禁用：员工离职或被停用时，对应账号自动禁用；禁用账号无法登录，但历史操作记录保留 +- **不支持用户自行注册**，所有账号均由有权限的管理角色创建 -#### 5.3.2 账号字段规范 +#### 5.3.2 账号创建权限分层 -| 字段 | 规格 | 说明 | -|------|------|------| -| 用户名（username） | 英文字母开头，仅包含字母/数字/下划线，6~30 字符，同租户内唯一 | 登录 ID，不可更改 | -| 密码（password） | 8~32 位，含字母+数字，建议含特殊字符 | 使用 `PBKDF2+SHA256` 哈希存储 | -| 邮箱（email） | 标准邮箱格式，同租户内唯一（可选，但若空则无法自助找回密码） | 用于找回账号/密码 | -| 手机号（phone） | 中国大陆 11 位手机号，加密存储，同租户内唯一（可选） | 预留，v2 用于手机登录 | -| 员工档案关联（staff_id） | 外键关联 `org.Staff` 模型 | 实名绑定 | -| 账号状态（status） | `active` / `disabled` / `locked` | locked 为密码错误锁定，30 分钟自动恢复 | -| 初始密码 | 由管理员创建账号时设置或系统随机生成 | 建议首次登录强制修改密码 | +系统内共有两类账号创建场景，权限和规则各不相同： -#### 5.3.3 首次登录强制修改密码 +**① Tenant Admin 账号（每个租户唯一的超级管理账号）** -- 管理员新建账号或重置密码后，账号处于「初始密码」状态 -- 持有「初始密码」的账号登录成功后，系统自动弹出「请修改初始密码」强制页面，**不可跳过** -- 修改成功后，账号状态更新为正常，进入系统首页 +| 项目 | 规格 | +|------|------| +| 创建时机 | 平台运营在系统管理后台开通租户时，同步创建第一个 Tenant Admin 账号 | +| 用户名 | **由平台运营自定义设置**，格式：英文字母开头，仅含字母/数字/下划线，6~30 字符，同租户内唯一 | +| 初始密码 | **由平台运营自定义设置**，须符合密码复杂度规则（8~32 位，含字母+数字） | +| 首次登录 | 强制修改初始密码，不可跳过 | +| 权限范围 | 拥有该租户内最高权限，可管理员工账号、角色、系统设置等 | +| 数量限制 | 每个租户仅限 1 个 Tenant Admin 账号（后续可扩展为多管理员，v2 规划） | + +**② 普通员工账号（经纪人、店长、行政等）** + +| 项目 | 规格 | +|------|------| +| 创建时机 | Tenant Admin 在「组织人事管理 → 新增员工」时，系统自动为该员工创建登录账号 | +| 用户名 | **固定为该员工的手机号**（11 位数字），同租户内唯一，创建后不可更改 | +| 初始密码 | **系统统一固定初始密码**（由平台在部署配置中设定，如 `Fonrey@2025`），所有新员工账号均使用同一初始密码 | +| 首次登录 | 强制修改初始密码，**不可跳过**（详见 5.3.4） | +| 密码重置 | Tenant Admin 可在员工管理界面对任意员工账号执行「重置密码」，重置后恢复为固定初始密码，触发首次登录强制修改流程 | +| 账号禁用 | 员工离职或被停用时，对应账号自动禁用；禁用账号无法登录，历史操作记录保留 | + +#### 5.3.3 账号字段规范 + +| 字段 | 类型 | Tenant Admin | 普通员工账号 | 说明 | +|------|------|-------------|-------------|------| +| 用户名（username） | CharField(30) | 平台运营自定义，字母开头，含字母/数字/下划线，6~30 字符 | **固定为员工手机号**（11 位数字） | 登录 ID，创建后不可更改 | +| 密码（password） | CharField | 平台运营自定义初始密码 | **系统统一固定初始密码** | PBKDF2+SHA256 哈希存储 | +| 手机号（phone） | CharField(11) | 选填，加密存储 | **必填，同时作为用户名**，加密存储，同租户内唯一 | 当前阶段为登录 ID；v2 启用手机验证码登录后复用此字段 | +| 邮箱（email） | EmailField | 选填，同租户唯一 | 选填，同租户唯一 | 用于找回密码；若为空则无法自助找回 | +| 员工档案关联（staff_id） | OneToOneField → `org.Staff` | 可选关联（平台运营账号） | 必须关联 | 实名绑定 | +| 账号状态（status） | CharField | `active` / `disabled` / `locked` | `active` / `disabled` / `locked` | locked 为密码错误锁定，30 分钟自动恢复 | +| 初始密码标记（is_initial_password） | BooleanField | True（首次登录前） | True（首次登录前） | True 时登录成功后强制跳转修改密码页 | +| 创建人（created_by） | ForeignKey → self | 平台运营（系统管理后台） | Tenant Admin | 审计追溯 | + +#### 5.3.4 首次登录强制修改密码 + +- 新员工账号创建后，`is_initial_password = True`，账号处于「初始密码」状态 +- 员工使用手机号（用户名）+ 固定初始密码登录成功后，系统**立即跳转**至「修改初始密码」强制页面，**不可关闭、不可跳过**，任何其他系统功能页面均不可访问 +- Tenant Admin 对员工账号执行「重置密码」后，`is_initial_password` 重置为 True，该员工下次登录时再次触发强制修改流程 +- 修改成功后，`is_initial_password` 更新为 False，原 Session 保持有效，直接进入系统首页 + +**强制修改密码页面规范**： + +| 元素 | 规格 | +|------|------| +| 页面标题 | 「欢迎使用 Fonrey，请先设置您的登录密码」 | +| 提示文案 | 「您当前使用的是初始密码，为保障账号安全，请立即设置新密码后开始使用」 | +| 新密码输入框 | 密文显示，右侧「显示/隐藏」切换 | +| 确认新密码输入框 | 密文显示，与新密码一致性实时校验 | +| 密码强度提示 | 逐条实时显示规则达标状态（✓/✗）：长度 ≥ 8 位 / 包含字母 / 包含数字 | +| 提交按钮 | 「确认并进入系统」 | +| 不可操作项 | 无「跳过」按钮；顶部导航栏、侧边菜单、关闭按钮均禁用 | --- @@ -376,21 +415,30 @@ Response 200 (失败): #### 5.4.1 找回用户名流程 +> **说明**：由于普通员工的用户名即为其**手机号**，通常无需「找回用户名」功能。登录界面的「忘记用户名」入口保留，但仅对 Tenant Admin 账号有意义（其用户名为自定义字符串）。 + ``` 用户点击「忘记用户名」 │ - ├─ 输入邮箱地址 - │ │ - │ 服务端查询该邮箱是否绑定账号（不向前端返回查询结果，防止枚举） - │ │ - │ 统一响应「如该邮箱已绑定账号，您将收到邮件」 - │ │ - │ 后台：若邮箱存在 → 发送邮件（包含用户名） - │ 若邮箱不存在 → 静默处理，不发送 + ├─ 普通员工：提示「您的登录账号为您的手机号，请直接使用手机号登录」 + │ 提供「返回登录」按钮 │ - └─ 用户查收邮件，获取用户名 → 返回登录 + └─ Tenant Admin（用户名非手机号格式）： + │ + ├─ 输入绑定邮箱 + │ │ + │ 服务端查询（不向前端返回查询结果，防止枚举） + │ │ + │ 统一响应「如该邮箱已绑定账号，您将收到邮件」 + │ │ + │ 后台：邮箱存在 → 发送邮件（包含用户名） + │ 邮箱不存在 → 静默处理 + │ + └─ 用户查收邮件，获取用户名 → 返回登录 ``` +> **前端识别逻辑**：用户在「忘记用户名」页面输入邮箱提交后，服务端根据是否匹配到 Tenant Admin 账号决定处理路径，前端无需区分，统一展示「如该邮箱已绑定账号，您将收到邮件」。 + **邮件模板（找回用户名）**： ``` @@ -413,13 +461,16 @@ Response 200 (失败): ``` 用户点击「忘记密码」 │ -步骤1：输入用户名 + 邮箱 +步骤1：身份验证 │ - ├─ 服务端校验（用户名 + 邮箱匹配） + ├─ 输入手机号（即用户名）+ 绑定邮箱 + │ （Tenant Admin 则输入自定义用户名 + 绑定邮箱） │ │ - │ 统一响应「如信息匹配，重置链接将发送至您的邮箱」 + │ 服务端校验用户名与邮箱是否匹配 │ │ - │ 后台：匹配成功 → 生成加密 Token（含过期时间 30min）→ 发送邮件 + │ 统一响应「如信息匹配，重置链接将发送至您的邮箱」（防止枚举） + │ │ + │ 后台：匹配成功 → 生成加密 Token（有效期 30min）→ 异步发送邮件 │ 不匹配 → 静默处理 │ 步骤2：用户点击邮件中的重置链接 @@ -428,16 +479,20 @@ Response 200 (失败): │ │ │ 有效 → 展示「重置密码」表单 │ │ - │ 无效/过期 → 提示「链接已过期，请重新申请」 + │ 无效/过期 → 提示「链接已过期，请重新申请」，提供「重新申请」按钮 │ 步骤3：用户输入并提交新密码 │ - ├─ 密码复杂度校验 - ├─ 与历史密码对比校验（最近 3 次） + ├─ 密码复杂度校验（≥ 8 位，含字母+数字） + ├─ 与历史密码对比校验（最近 3 次，含固定初始密码） │ - └─ 校验通过 → 更新密码 → 清除所有 Session → 跳转登录界面 + └─ 校验通过 → 更新密码，is_initial_password = False + → 清除该账号所有有效 Session（强制重新登录） + → 跳转登录界面，提示「密码已重置，请重新登录」 ``` +> **注意**：找回密码流程依赖员工账号绑定了邮箱。若员工未绑定邮箱，无法自助找回，需联系 Tenant Admin 在管理界面执行「重置密码」操作，将密码恢复为固定初始密码。 + **邮件模板（重置密码）**： ``` @@ -482,16 +537,17 @@ apps/ | 字段 | 类型 | 说明 | |------|------|------| | `id` | BigAutoField | 主键 | -| `username` | CharField(30) | 登录名，同租户唯一，不可变更 | +| `username` | CharField(30) | 登录名，同租户唯一，不可变更；普通员工账号固定为手机号（11位数字），Tenant Admin 为自定义字符串 | | `password` | CharField | PBKDF2+SHA256 哈希，使用 Django `make_password` | -| `email` | EmailField | 绑定邮箱，同租户唯一，选填 | -| `phone` | CharField(11) | 绑定手机号，加密存储（`core.encryption`），选填 | -| `staff` | OneToOneField → `org.Staff` | 员工档案绑定，必须 | +| `email` | EmailField | 绑定邮箱，同租户唯一，选填；为空时无法自助找回密码 | +| `phone` | CharField(11) | 绑定手机号，加密存储（`core.encryption`）；普通员工必填（同时作为 username 来源），Tenant Admin 选填 | +| `staff` | OneToOneField → `org.Staff` | 员工档案绑定；普通员工必须，Tenant Admin 可为空 | +| `is_tenant_admin` | BooleanField | 标记是否为该租户的 Tenant Admin 账号，默认 False | | `status` | CharField | `active` / `disabled` / `locked` | -| `is_initial_password` | BooleanField | True 时登录后强制修改密码 | +| `is_initial_password` | BooleanField | True 时登录成功后强制跳转修改密码页，不可跳过 | | `last_login` | DateTimeField | 最后登录时间 | | `created_at` | DateTimeField | 账号创建时间 | -| `created_by` | ForeignKey → self | 创建人（管理员） | +| `created_by` | ForeignKey → self | 创建人（普通员工由 Tenant Admin 创建；Tenant Admin 由平台运营创建） | #### 5.5.3 `LoginAttempt` 登录尝试记录 diff --git a/wiki/index.md b/wiki/index.md index 22e6feb8..36dc3bc4 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,6 +4,7 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-24] [ArchitectUX Agent Personality](sources/design-ux-architect.md) - [2026-04-24] [Contributing to The Agency](sources/contributing.md) - [2026-04-24] [为 The Agency 贡献代码](sources/contributing_zh-cn.md) - [2026-04-24] [CTP Topic 12 Using SES SMTP service terraform module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) @@ -413,7 +414,6 @@ - [2026-04-20] [design-brand-guardian](sources/design-brand-guardian.md) — (expected: wiki/sources/design-brand-guardian.md — source missing) - [2026-04-20] [design-ux-researcher](sources/design-ux-researcher.md) — (expected: wiki/sources/design-ux-researcher.md — source missing) - [2026-04-20] [design-whimsy-injector](sources/design-whimsy-injector.md) — (expected: wiki/sources/design-whimsy-injector.md — source missing) -- [2026-04-20] [design-ux-architect](sources/design-ux-architect.md) — (expected: wiki/sources/design-ux-architect.md — source missing) - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing) diff --git a/wiki/log.md b/wiki/log.md index ccb40d04..0da80ade 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -28,6 +28,15 @@ - Notes: index.md 已替换占位符条目（日期 2026-04-14）；overview.md 已新增独立段落（Terraform 段落末尾，置于 RDS via Terraform 和 Topic 21 之间）；VPC-Endpoint/DKIM-Email-Authentication/SES-Sandbox-Mode 为新创建 Concept 页面；Secrets-Management 已存在，已建立 wikilink；无其他 Entity 需创建 - Conflicts: 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异——SendGrid 被选定为新标准云邮件服务，SES 则服务现有应用通过 SMTP 协议平滑迁移上云，两者互补而非互斥 +## [2026-05-05] ingest | design-ux-architect +- Source file: Agent/agency-agents/design/design-ux-architect.md +- Status: ✅ 成功摄入 +- Summary: ArchitectUX 智能体角色定义——为 LuxuryDeveloper 提供坚实的技术架构和 UX 基础。核心交付物：CSS 设计系统（颜色/排版/间距令牌，light/dark/system 三模式）、响应式布局框架（Grid/Flexbox/mobile-first）、ThemeManager JS 类、信息架构规范。核心原则：Foundation-First 和消除开发者架构决策疲劳。所有新站点强制要求主题切换功能。 +- Concepts linked: none（CSS 设计系统/ThemeManager 等属单一来源概念，以 wikilink 形式记录于 Source page，不足建 Concept 页阈值） +- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]] +- Source page: wiki/sources/design-ux-architect.md +- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 multi-agent-system-reliability 之前）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建 Entity 页阈值）；无实质内容冲突 + ## [2026-05-05] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md - Status: ✅ 成功摄入 diff --git a/wiki/overview.md b/wiki/overview.md index afd182d6..e1734664 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -31,6 +31,8 @@ The wiki covers two major multi-agent frameworks: **The Agency** (agency-agents) **Recursive Self-Optimizing Generative Systems**（[[a-formalization-of-recursive-self-optimizing-generative-systems]]）：递归自我优化生成系统的形式化理论模型——将 [[养虾日记2]] 中 Self-Improving 的实践经验抽象为严格数学框架：系统目标不是直接产出最优输出，而是通过迭代自我修改构建稳定的生成能力 $G^*$。定义生成器空间 $\mathcal{G}$ → 优化算子 $O$ → 元生成算子 $M$ → 自映射 $\Phi$ → 稳定不动点 $G^*$，最终用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现：**递归自我优化自然涌现不动点结构**——当 $\Phi$ 满足收缩性条件时，$G^* = \lim_{n \to \infty} \Phi^n(G_0)$。该框架为 [[Self-Improving-Skill]] 和所有自我改进 AI 架构提供了原则性理论基础。 +**[[design-ux-architect]]**（ArchitectUX）：The Agency 设计部门的 UX 架构专家智能体——在 LuxuryDeveloper 实施前为其提供坚实的技术基础，包括 CSS 设计系统（变量令牌/排版层级/间距体系）、响应式布局框架（Grid/Flexbox/mobile-first）和 ThemeManager 三模式切换（light/dark/system）。核心原则：**Foundation-First**——在动手实现前先建立可扩展 CSS 架构，消除开发者架构决策疲劳；**默认强制要求**——所有新站点必须包含主题切换功能。ArchitectUX 作为 [[The Agency]] 设计部门智能体之一，承接 [[ProjectManager]] 任务列表并添加技术基础层，为 [[LuxuryDeveloper]] 输出清晰的交接规范。与 [[design-ui-designer]]（视觉细节）和 [[design-ux-researcher]]（用户研究）协同，遵循 [[Multi-Agent-System-Reliability]] 的交接协议模式。 + **[[multi-agent-system-reliability]]**（Alex Ewerlöf）：多智能体系统可靠性的架构模式理论——反对拟人化LLM，主张将LLM视为分布式系统中不可靠的组件。核心4模式：[[Hierarchy-Agent-Pattern]]（主管→工作→验证链）、[[Consensus-Voting-Pattern]]（N个LLM多数票消除幻觉）、[[Adversarial-Debate-Pattern]]（Generator→Critic→Judge对抗辩论）、[[Knock-out-Pattern]]（适者生存淘汰制）。核心洞察：不应要求模型"小心"，而应**强制**其正确——通过架构约束而非提示词约束。与 [[Designing for Agentic AI]] 互补（架构 vs 用户体验），与 [[Recursive Self-Optimization]] 共享自引用结构思想。与 [[Genetic-Algorithm]]（遗传算法）有关联——Knock-out/Tree of Thoughts 是 GA 的精简实现。 Key concepts: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Referential Computation]], [[Fixed-Point Semantics]], [[Y-Combinator]], [[Self-Improving AI]], [[Automated Prompt Engineering]], [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]], [[Cron Job]], [[Multi-Agent Coordination]], [[Multi-Tool Integration]], [[MCP Tool Interface Design]], [[Workflow Architecture]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]], [[Topic-Based Routing]], [[Voice Interface]], [[Telephony Integration]], [[Voice Notification Channel]], [[Two-Way Voice Conversation]], [[Call-Worthy Threshold]], [[PSTN Calling]], [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]], [[Dynamic-Dashboard]], [[Alerting]], [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]], [[Unified-Inbox]], [[Intent-Classification]], [[Human-Handoff]], [[Test-Mode]], [[Business-Knowledge-Base]], [[Language-Detection]], [[AI-Auto-Response]], [[Heartbeat-Monitoring]], [[Self-Improving-Skill]], [[双层记忆架构]], [[每日复盘机制]], [[Pattern-Key]], [[Recurrence-Count]], [[Self-Improvement-Log]], [[AI-Agent思维方式]], [[批次任务拆分]], [[精确去重]], [[小文件清理]], [[安全删除策略]], [[Telegram通知]], [[Context-Window]], [[Model-Fallback]], [[Compaction]], [[Agent-Routing-Rules]], [[Error-Surface-vs-Root-Cause]], [[Layered-Configuration]], [[Log-Driven-Debugging]], [[Hidden-Failure-Paths]], [[Large Language Model]], [[RAG]], [[AI Agent]], [[ReAct Pattern]], [[Hierarchy-Agent-Pattern]], [[Consensus-Voting-Pattern]], [[Adversarial-Debate-Pattern]], [[Knock-out-Pattern]], [[Tree-of-Thoughts]], [[Genetic-Algorithm]], [[Reliability-Engineering]] diff --git a/wiki/sources/design-ux-architect.md b/wiki/sources/design-ux-architect.md new file mode 100644 index 00000000..fea74ba0 --- /dev/null +++ b/wiki/sources/design-ux-architect.md @@ -0,0 +1,51 @@ +--- +title: "ArchitectUX Agent Personality" +type: source +tags: [agent, design, ux, css, frontend, the-agency] +date: 2026-04-20 +--- + +## Source File +- [[Agent/agency-agents/design/design-ux-architect.md]] + +## Summary（用中文描述） +- 核心主题：ArchitectUX 智能体的角色定义——为开发者提供坚实的技术架构和 UX 基础，消除架构决策疲劳 +- 问题域：Web 项目中 CSS 系统混乱、响应式策略缺失、主题切换缺失等开发者痛点 +- 方法/机制：通过 CSS 设计系统（变量/排版/间距/颜色令牌）、布局框架（Grid/Flexbox）、信息架构、ThemeManager JS 类实现 +- 结论/价值：ArchitectUX 作为 [[The Agency]] 设计部门的多智能体之一，负责在 LuxuryDeveloper 实施前建立可扩展的技术基础 + +## Key Claims（用中文描述） +- **ArchitectUX** ← 创建 → **CSS 设计系统基础**：通过 CSS 变量令牌体系（颜色/排版/间距/容器）实现跨项目可维护的样式架构，消除硬编码值 +- **主题切换** ← 强制要求 → **所有新站点必须包含**：light/dark/system 三模式切换，preserves 用户偏好，支持 WCAG 合规 +- **架构优先** ← 预防 → **CSS 冲突**：在实施前先设计组件层级和命名规范，防止样式冲突和技术债务 +- **系统架构领导力** ← 负责 → **仓库拓扑/数据契约/API规范**：确保跨系统一致性和 Schema 合规 +- **开发者生产力** ← 通过 → **消除架构决策疲劳**：提供清晰可实施的规范，减少返工和重复决策 + +## Key Quotes +> "Create scalable CSS architecture before implementation begins" — Foundation-First Approach 原则，要求在动手前先建立系统 +> "Eliminate architectural decision fatigue for developers" — Developer Productivity Focus 核心理念，ArchitectUX 存在的核心价值主张 + +## Key Concepts +- **CSS 设计系统（CSS Design System）**：由 CSS 变量令牌（颜色/排版/间距/组件）构成的标准化样式体系，支持 light/dark/system 主题切换 +- **布局框架（Layout Framework）**：基于现代 CSS Grid/Flexbox 的容器系统和响应式断点策略（mobile-first） +- **ThemeManager**：管理 light/dark/system 三种主题状态切换的 JavaScript 类，持久化用户偏好至 localStorage +- **信息架构（Information Architecture）**：页面层级结构、导航策略、内容权重系统（H1 > H2 > H3） +- **可访问性基础（Accessibility Foundation）**：WCAG 2.1 AA 合规标准，键盘导航、屏幕阅读器支持 +- **组件层级（Component Hierarchy）**：Layout Components → Content Components → Interactive Components → Utility Components 四层架构 +- **交接文档（Developer Handoff Documentation）**：包含优先级顺序、文件结构、实现笔记的完整交付模板 + +## Key Entities +- **ArchitectUX**：Technical Architecture and UX Foundation Specialist Agent，紫色主题，📐 emoji，为 [[LuxuryDeveloper]] 提供可实施的技术基础 +- **LuxuryDeveloper**：The Agency 开发智能体，接收 ArchitectUX 的 CSS 系统和架构规范进行具体实现 +- **ProjectManager**：The Agency 项目管理智能体，提供任务列表，ArchitectUX 在其基础上添加技术基础层 + +## Connections +- [[design-ui-designer]] ← extends ← [[design-ux-architect]]：UI 设计师在 ArchitectUX 建立的基础层上添加视觉设计细节 +- [[design-ux-researcher]] ← depends_on ← [[design-ux-architect]]：UX 研究员的原型和交互规范依赖 ArchitectUX 的技术框架实现 +- [[design-brand-guardian]] ← coordinates ← [[design-ux-architect]]：品牌规范约束 ArchitectUX 的 CSS 颜色令牌和排版系统 +- [[design-whimsy-injector]] ← adds_on ← [[design-ux-architect]]：趣味元素注入者在基础架构完成后添加动效和个性风格 +- [[The Agency]] ← contains ← [[design-ux-architect]]：ArchitectUX 是 The Agency 12 大部门之一 Design 部门的重要智能体 +- [[Multi-Agent-System-Reliability]] ← provides_pattern ← [[design-ux-architect]]：多智能体可靠性模式（如 Handoff Protocol）指导 ArchitectUX 的交接文档规范 + +## Contradictions +- 与 [[design-ui-designer]] 在实现优先级上可能存在张力：ArchitectUX 主张"先基础后视觉"，UI 设计师可能倾向视觉优先。**当前观点**：基础优先，视觉细节在 CSS 系统稳定后添加，避免重构