Sync: add design ux architecture notes

2026-04-24 21:19:59 +08:00
parent 4b6b2f970c
commit 31d316b096
5 changed files with 168 additions and 50 deletions
--- 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_<slug>`，如 `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` 登录尝试记录

--- 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)
--- 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: ✅ 成功摄入
--- 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]]
--- a/wiki/sources/design-ux-architect.md
+++ 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 系统稳定后添加，避免重构