新增Leo学习文件夹

- Add wiki/sources/marketing-agentic-search-optimizer.md (Source Page)
- Update wiki/index.md: fix missing source marker → full entry
- Append wiki/log.md entry

Ingest steps 1-9 completed:
1. Read raw/Agent/agency-agents/marketing/marketing-agentic-search-optimizer.md
2. Read wiki/index.md + wiki/overview.md
3. Generate source page (slug: marketing-agentic-search-optimizer)
4. Update index.md
5. overview.md already has [[Marketing Agentic Search Optimizer]] ref (no dup needed)
6. Entity check: no entities ≥2 mentions (Chrome/Edge/Claude/Perplexity each 1×)
7. Concept check: WebMCP concepts described in source page only (W3C draft, conservative)
8. Contradiction check: none found
9. Append log.md

.gitignore

@@ -1 +1,4 @@
-.obsidian/
+.obsidian/
+
+.DS_Store
+**/.DS_Store

.opencode/opencode.json

@@ -0,0 +1,6 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "plugin": [
+    "oh-my-openagent"
+  ]
+}

Archived/My Task.md

@@ -1,96 +1,96 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
-kanban-plugin: board
----
-
-
-
-## Backlog
-
-- [ ] 🔼 Email to Nina about Achmea Pen Testing on EU3, WAF result reported
-- [ ] 🔼 Prepare JATO UX update notification to impacted customers, send to PM for review first
-- [ ] 🔺 Initial an email about WAF rules for OP
-- [ ] ⏫ send email to Alex and Philipp about convince TechM to migrate their FinOps to OP
-- [ ] ⏫ Onspring new evidence for TLS certificate
-- [ ] ⏫ Talk to Ellar about ITOM work utilization data, increase the project percentage for some senior person
-- [ ] 🔺 Check with Remi and Brindusa to add Time spent field in PCS for both Support and Service Request
-- [ ] 🔺 Change people % in Ellar shared spreadsheet
-- [ ] ⏫ Reply to Ken to provide more evidence and also check Onspring system the pending tasks
-- [ ] ⏫ Reply email about new EU farm kick off plan after comments from Mark Peter
-- [ ] Update, please attached the updated evidence to close Onspring requests Master33541 and Master33560 based on what we gave last September 2024.
-- [ ] 🔼 Check EU28 Evonik customer license
-- [ ] ⏫ Check OpsB/NOM customer license expiration date in CT
-- [ ] 🔼 Raise ticket to request Power BI Pro license:
-	  Hello Wei, I have moved the ITOM Cloud Service Workspace to Fabric. You access should be restored.  View access is free. Content creators can request a Power BI Pro license through the software request workflow [https://go.opentext.com/softwarerequest](https://go.opentext.com/softwarerequest%20for%20$100) $100 USD annually.
-	
-	-Garrett
-- [ ] 🔼 Ask team to consolidate all important runbook and check who is the new owership of these runbooks
-- [ ] ⏫  ADAM Q4 Project List
-- [ ] ⏫  create unique DB user instead of smax-admin which can be cross used by OP/OpsB/NOM as tenant admin role
-
-
-## WIP
-
-- [ ] 🔽 Prepare a wiki page to describe 'Troubleshooting as a service'
-- [ ] ⏫ Track incident: IM3660374
-- [ ] 🔺 Offline pods incident follow up
-- [ ] 🔽 Review the Incident Management Meeting (SM9) record to understand detail process on top of it.
-- [ ] 🔺 Prepare SD draft for Premium DR service for SocGen
-- [ ] ⏫ Give a mapping table about time spent on each SaaS offerings so that we can give a consolidated team effort on customer tickets
-
-
-## Done
-
-- [ ] 🔺 Refine the Premium DR service slides
-- [ ] ⏫ Initial discussion about US24 unplanned maintenance which might have 2 hours downtime.
-- [ ] 🔼 Give Wenjun a go command once confirmed Indra is ok with current proposals
-- [ ] ⏫ Prepare the answers to Sales team about how we're going to perform the yearly DR testing
-- [ ] ⏫ Provide Feb PCS, X4X data to Sajith
-- [ ] 🔺 Update 25.1.2 customer notification with official doc link
-- [ ] 🔼 Review ITOM AWS Cost Breakdown detail and reply to Samar and Melissa
-- [ ] ⏫ Check with Wenjun about BI data stop sent since Feb 24
-- [ ] 🔼 Update slides for SMAX/AC VDC readiness meeting
-- [ ] 🔼 Schedule a meeting to discuss OT IT use case about direct access Vertica DB to fetch FinOps data
-- [ ] 🔽 Prepare tomorrow's ESM Cloud Service weekly meeting
-- [ ] ⏫ Prepare upgrade hyper care plan and detail explain what happened for US steel case
-- [ ] 🔼 Check with Danny about how to submit security review request for OT IT vertica DB direct access case
-- [ ] 🔼 Reply Ken's questions in team's chat
-- [ ] ⏫ Send ESM RI plan to OT FinOps team
-- [ ] 🔺 Send email notification to NOM customers for 3/9, 3/16 maintenance window about EKS upgrade
-
-
-## Tracking
-
-- [ ] ⏫ Review patch /upgrade notification content with Dean - Boglarka to drive this
-- [ ] 🔼 Assign task about create Jenkins job to check AWS Supperession list
-- [ ] ⏫ Ask wenjun to follow up Dean's request about include ITOM Aviator in SMAX premium trial tenant provision
-
-
-## Archive
-
-- [ ] ⏫ Update cost estimation about SG
-- [ ] ⏫ Send ITOM ESM Monthly Report - Feb 2025
-- [ ] ⏫ Schedule a meeting with team about Indra switch to OP
-- [ ] 🔼 Update OT SM9 Assignment Group for Ops-ADM_ESM  and Ops-ADM_OpsB to add new team members
-- [ ] 🔼 Refine the on call list in Everbridge
-- [ ] 🔺 Prepare ESM 25.1.2 Patch Notifications
-- [ ] ⏫ Reply Florin's proposal
-
-
-***
-
-## Archive
-
-- [ ] 🔼 Reply to Lihi about non-commercial cloud related efforts
-
-%% kanban:settings
-```
-{"kanban-plugin":"board","list-collapse":[false,false,false,false,false],"full-list-lane-width":true}
-```
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+kanban-plugin: board
+---
+
+
+
+## Backlog
+
+- [ ] 🔼 Email to Nina about Achmea Pen Testing on EU3, WAF result reported
+- [ ] 🔼 Prepare JATO UX update notification to impacted customers, send to PM for review first
+- [ ] 🔺 Initial an email about WAF rules for OP
+- [ ] ⏫ send email to Alex and Philipp about convince TechM to migrate their FinOps to OP
+- [ ] ⏫ Onspring new evidence for TLS certificate
+- [ ] ⏫ Talk to Ellar about ITOM work utilization data, increase the project percentage for some senior person
+- [ ] 🔺 Check with Remi and Brindusa to add Time spent field in PCS for both Support and Service Request
+- [ ] 🔺 Change people % in Ellar shared spreadsheet
+- [ ] ⏫ Reply to Ken to provide more evidence and also check Onspring system the pending tasks
+- [ ] ⏫ Reply email about new EU farm kick off plan after comments from Mark Peter
+- [ ] Update, please attached the updated evidence to close Onspring requests Master33541 and Master33560 based on what we gave last September 2024.
+- [ ] 🔼 Check EU28 Evonik customer license
+- [ ] ⏫ Check OpsB/NOM customer license expiration date in CT
+- [ ] 🔼 Raise ticket to request Power BI Pro license:
+	  Hello Wei, I have moved the ITOM Cloud Service Workspace to Fabric. You access should be restored.  View access is free. Content creators can request a Power BI Pro license through the software request workflow [https://go.opentext.com/softwarerequest](https://go.opentext.com/softwarerequest%20for%20$100) $100 USD annually.
+	
+	-Garrett
+- [ ] 🔼 Ask team to consolidate all important runbook and check who is the new owership of these runbooks
+- [ ] ⏫  ADAM Q4 Project List
+- [ ] ⏫  create unique DB user instead of smax-admin which can be cross used by OP/OpsB/NOM as tenant admin role
+
+
+## WIP
+
+- [ ] 🔽 Prepare a wiki page to describe 'Troubleshooting as a service'
+- [ ] ⏫ Track incident: IM3660374
+- [ ] 🔺 Offline pods incident follow up
+- [ ] 🔽 Review the Incident Management Meeting (SM9) record to understand detail process on top of it.
+- [ ] 🔺 Prepare SD draft for Premium DR service for SocGen
+- [ ] ⏫ Give a mapping table about time spent on each SaaS offerings so that we can give a consolidated team effort on customer tickets
+
+
+## Done
+
+- [ ] 🔺 Refine the Premium DR service slides
+- [ ] ⏫ Initial discussion about US24 unplanned maintenance which might have 2 hours downtime.
+- [ ] 🔼 Give Wenjun a go command once confirmed Indra is ok with current proposals
+- [ ] ⏫ Prepare the answers to Sales team about how we're going to perform the yearly DR testing
+- [ ] ⏫ Provide Feb PCS, X4X data to Sajith
+- [ ] 🔺 Update 25.1.2 customer notification with official doc link
+- [ ] 🔼 Review ITOM AWS Cost Breakdown detail and reply to Samar and Melissa
+- [ ] ⏫ Check with Wenjun about BI data stop sent since Feb 24
+- [ ] 🔼 Update slides for SMAX/AC VDC readiness meeting
+- [ ] 🔼 Schedule a meeting to discuss OT IT use case about direct access Vertica DB to fetch FinOps data
+- [ ] 🔽 Prepare tomorrow's ESM Cloud Service weekly meeting
+- [ ] ⏫ Prepare upgrade hyper care plan and detail explain what happened for US steel case
+- [ ] 🔼 Check with Danny about how to submit security review request for OT IT vertica DB direct access case
+- [ ] 🔼 Reply Ken's questions in team's chat
+- [ ] ⏫ Send ESM RI plan to OT FinOps team
+- [ ] 🔺 Send email notification to NOM customers for 3/9, 3/16 maintenance window about EKS upgrade
+
+
+## Tracking
+
+- [ ] ⏫ Review patch /upgrade notification content with Dean - Boglarka to drive this
+- [ ] 🔼 Assign task about create Jenkins job to check AWS Supperession list
+- [ ] ⏫ Ask wenjun to follow up Dean's request about include ITOM Aviator in SMAX premium trial tenant provision
+
+
+## Archive
+
+- [ ] ⏫ Update cost estimation about SG
+- [ ] ⏫ Send ITOM ESM Monthly Report - Feb 2025
+- [ ] ⏫ Schedule a meeting with team about Indra switch to OP
+- [ ] 🔼 Update OT SM9 Assignment Group for Ops-ADM_ESM  and Ops-ADM_OpsB to add new team members
+- [ ] 🔼 Refine the on call list in Everbridge
+- [ ] 🔺 Prepare ESM 25.1.2 Patch Notifications
+- [ ] ⏫ Reply Florin's proposal
+
+
+***
+
+## Archive
+
+- [ ] 🔼 Reply to Lihi about non-commercial cloud related efforts
+
+%% kanban:settings
+```
+{"kanban-plugin":"board","list-collapse":[false,false,false,false,false],"full-list-lane-width":true}
+```
 %%

Archived/Work/--- 我的任务 ---.md

@@ -1,74 +1,74 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
-kanban-plugin: board
----
-
-
-
-## TikTok Shop Tasks
-
-- [ ] ⏫ 等营业执照下来注册TikTok Shop
-- [ ] ⏫ 学习Ushop使用方法，了解整个订单流程
-- [ ] 🔼 了解一下AMZ123网站
-
-
-## Backlog
-
-- [ ] ⏫ 学习并掌握Scrapy 爬虫工具的使用方法，并结合n8n实现自动化
-- [ ] ⏫ 尝试在本地搭建text to speech 的模型 并且通过API被n8n调用
-- [ ] ⏫ 用pgAdmin连接NAS上postgres数据库
-- [ ] ⏫ 尝试在本地使用n8n来调用comfyUI实现图生图自动化
-- [ ] 🔼 Learn Google Trends Tutorials
-- [ ] 🔼 学习如何使用Google趋势来查看目标国家的热门产品销售数据
-- [ ] 🔼 升级Ubuntu1 Portainer 版本
-- [ ] 🔼 有空时可以搞一下 爬虫爬 OdayDown.com的数据
-- [ ] 🔽 利用ZBook Laptop搭建第二台Ubuntu Server
-- [ ] 🔽 读原子习惯，掌握好习惯 中文版先读， 再读英文版
-- [ ] 🔽 注册并试用kie.ai
-- [ ] N8n调用第三方ApI 进行图片编辑
-- [ ] 了解一下SerpAPI
-
-
-## WIP
-
-- [ ] ⏫ 尝试使用硅基流的 API来实现文生图，并被n8n调用
-
-
-## Done
-
-- [ ] ⏫ 用n8n创建一个workflow可以把internet的图片转存到zipline,并返回图片公共链接
-- [ ] 🔼 了解一下Homarr的具体用法
-- [ ] 🔽 逐步淘汰Cpolar的使用，并删除相关软件
-
-
-## Tracking
-
-- [ ] ⏫ 利用Qwan3-code来生成n8n代码
-
-
-## Archive
-
-- [ ] ⏫ 配置Obsidian使用ishenwei.online 域名的webdav
-- [ ] ⏬ 在购买的RackNerd的VPS上安装n8n （需要额外考虑）
-- [ ] ⏫ 在NAS上搭建一个图床应用
-- [ ] ⏫ 在NAS上部署https://github.com/tt-rss/tt-rss
-
-
-## Idea
-
-- [ ] 🔼 利用Postgres里的RSS article数据来实现 n8n调用并通过AI来分析最新得到的RSS article给一个简报并通过邮件发送
-
-
-
-
-%% kanban:settings
-```
-{"kanban-plugin":"board","list-collapse":[false,false,false,false,false,false,false]}
-```
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+kanban-plugin: board
+---
+
+
+
+## TikTok Shop Tasks
+
+- [ ] ⏫ 等营业执照下来注册TikTok Shop
+- [ ] ⏫ 学习Ushop使用方法，了解整个订单流程
+- [ ] 🔼 了解一下AMZ123网站
+
+
+## Backlog
+
+- [ ] ⏫ 学习并掌握Scrapy 爬虫工具的使用方法，并结合n8n实现自动化
+- [ ] ⏫ 尝试在本地搭建text to speech 的模型 并且通过API被n8n调用
+- [ ] ⏫ 用pgAdmin连接NAS上postgres数据库
+- [ ] ⏫ 尝试在本地使用n8n来调用comfyUI实现图生图自动化
+- [ ] 🔼 Learn Google Trends Tutorials
+- [ ] 🔼 学习如何使用Google趋势来查看目标国家的热门产品销售数据
+- [ ] 🔼 升级Ubuntu1 Portainer 版本
+- [ ] 🔼 有空时可以搞一下 爬虫爬 OdayDown.com的数据
+- [ ] 🔽 利用ZBook Laptop搭建第二台Ubuntu Server
+- [ ] 🔽 读原子习惯，掌握好习惯 中文版先读， 再读英文版
+- [ ] 🔽 注册并试用kie.ai
+- [ ] N8n调用第三方ApI 进行图片编辑
+- [ ] 了解一下SerpAPI
+
+
+## WIP
+
+- [ ] ⏫ 尝试使用硅基流的 API来实现文生图，并被n8n调用
+
+
+## Done
+
+- [ ] ⏫ 用n8n创建一个workflow可以把internet的图片转存到zipline,并返回图片公共链接
+- [ ] 🔼 了解一下Homarr的具体用法
+- [ ] 🔽 逐步淘汰Cpolar的使用，并删除相关软件
+
+
+## Tracking
+
+- [ ] ⏫ 利用Qwan3-code来生成n8n代码
+
+
+## Archive
+
+- [ ] ⏫ 配置Obsidian使用ishenwei.online 域名的webdav
+- [ ] ⏬ 在购买的RackNerd的VPS上安装n8n （需要额外考虑）
+- [ ] ⏫ 在NAS上搭建一个图床应用
+- [ ] ⏫ 在NAS上部署https://github.com/tt-rss/tt-rss
+
+
+## Idea
+
+- [ ] 🔼 利用Postgres里的RSS article数据来实现 n8n调用并通过AI来分析最新得到的RSS article给一个简报并通过邮件发送
+
+
+
+
+%% kanban:settings
+```
+{"kanban-plugin":"board","list-collapse":[false,false,false,false,false,false,false]}
+```
 %%

Archived/Work/2025 ITOM Cloud Knowledge Transfer/ESM Cloud Version Upgrade Procedures.md

@@ -1,25 +1,25 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-## 1. Review Upgrade Procedures Document with R&D team
-## 2. Follow the Upgrade Procedures to perform Dev Farm upgrade validation
-## 3. Send Notification to ESM Cloud Farm Customer about upcoming maintenance window
-## 4. Maintenance Window Procedures
-### 1. Set downtime of APM monitoring 
-### 2. Perform the upgrade change
-### 3. Send notification to customer once all the change was done
-### 4. Update Wiki Page about Version Tracking
-### 5. Update System Health Page - Complete the Maintenance Window
-### 6. Update PCS Product Version and Environment Version
-### 7. Restore the APM monitoring and ensure all checks are good
-
-## 5. Monitoring the farm metrics to ensure everything is working as expected
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+## 1. Review Upgrade Procedures Document with R&D team
+## 2. Follow the Upgrade Procedures to perform Dev Farm upgrade validation
+## 3. Send Notification to ESM Cloud Farm Customer about upcoming maintenance window
+## 4. Maintenance Window Procedures
+### 1. Set downtime of APM monitoring 
+### 2. Perform the upgrade change
+### 3. Send notification to customer once all the change was done
+### 4. Update Wiki Page about Version Tracking
+### 5. Update System Health Page - Complete the Maintenance Window
+### 6. Update PCS Product Version and Environment Version
+### 7. Restore the APM monitoring and ensure all checks are good
+
+## 5. Monitoring the farm metrics to ensure everything is working as expected
+

Archived/Work/2025 ITOM Cloud Knowledge Transfer/ESM SaaS Customer Onboarding Process (Control Tower).md

@@ -1,26 +1,26 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-Control Tower Link: https://backoffice.saas.microfocus.com/home/bl/desktop.html?TENANTID=1#/customers
-
-- Request Access to Control Tower
-- 
-- Customer Order Filter
-	- ESM Product Filter:
-	![Image](http://zipline.ishenwei.online/u/cu2uo8.png)
-	- APM/OpsB/NOM Product Filter
-![Image](http://zipline.ishenwei.online/u/QPUhmO.png)
-
-- SaaS Order In Control Tower
-- CS Ops Fulfill the order and generate license
-- SaaS Ops team download/allocate license and close the deal
-- Control Tower order status change to "Provisioned", close the deal
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+Control Tower Link: https://backoffice.saas.microfocus.com/home/bl/desktop.html?TENANTID=1#/customers
+
+- Request Access to Control Tower
+- 
+- Customer Order Filter
+	- ESM Product Filter:
+	![Image](http://zipline.ishenwei.online/u/cu2uo8.png)
+	- APM/OpsB/NOM Product Filter
+![Image](http://zipline.ishenwei.online/u/QPUhmO.png)
+
+- SaaS Order In Control Tower
+- CS Ops Fulfill the order and generate license
+- SaaS Ops team download/allocate license and close the deal
+- Control Tower order status change to "Provisioned", close the deal
+

Archived/Work/2025 ITOM Cloud Knowledge Transfer/ESM Unplanned Production Change Management.md

@@ -1,25 +1,25 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-Wiki Page:
-https://confluence.opentext.com/display/ICSD/Request+Unplanned+Change+in+Cloud+Production+Environment+Process
-
-R&D SA Approver
-- Gong Yi (SMAX)
-- Danny Tian (SMAX)
-- Spinu Corneliu (SMAX)
-- Moldovan Vlad 
-- Diana Pop (CMS)
-- Bianca Voina (CMS)
-
-CSD  Approver
-- Shen Wei
-- Ting Ye
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+Wiki Page:
+https://confluence.opentext.com/display/ICSD/Request+Unplanned+Change+in+Cloud+Production+Environment+Process
+
+R&D SA Approver
+- Gong Yi (SMAX)
+- Danny Tian (SMAX)
+- Spinu Corneliu (SMAX)
+- Moldovan Vlad 
+- Diana Pop (CMS)
+- Bianca Voina (CMS)
+
+CSD  Approver
+- Shen Wei
+- Ting Ye

Archived/Work/2025 ITOM Cloud Knowledge Transfer/ESM Upgrade Strategy & Plan.md

@@ -1,42 +1,42 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-## Review R&D Major Release Plan & Patch Plan
-- ESM RTE: Mihaela Claudia Chis <mchis@opentext.com>
-	- PI Planning Readout Slides 
-- ESM Patch Release Owner: Tanuj Raja Vunnava <tvunnava@opentext.com>
-	- Patch Release Kick Off email
-- Other requirement about upgrade strategy
-	- Demo/PoC Request
-	- Customer commitment etc.
-## Prepare Cloud Upgrade Plan 
-### Design Tool
-### Plan Strategy
-- US2 Dev Farm Upgrade Validation - 1~2 days prior MR release date
-- Shared Service - ITOM Aviator US30 staging, EU30 production, EU32 production need to be upgraded first before other consume farm upgrade
-- EU3/US7 Trial/PoC Farm Upgrade -  1~ 2 weeks after GA release date, Upgrade on Monday (working day)
-- US2/US24 Opentext Internal Customer Production Farm -  1st Wave Production Farm Upgrade (Maintenance Window)
-- US26 - SalesForce customer need alternative upgrade date this can be negotiated with CSM and customer
-- US26/US6/AP10/CA16 External Customer Production Farm - 2nd Wave Production Farm Upgrade (Maintenance Window)
-- EU8/EU18/EU28/BR14/JP12 External Customer Production Farm - 3nd Wave Production Farm Upgrade (Maintenance Window)
-- If ESM farm enable Operation Platform, need to upgrade Operation Platform first before upgrade ESM farm
-- Considering the 1st patch release, we can consider to adopt patch upgrade direct in the upgrade maintenance window (Need to clarify the dependencies)
-- Try to avoid upgrade window before key teams public holiday. Usually some critical issues will be reported on Monday/Tuesday after version upgrade. Need people standby to support troubleshooting
-
-### Publish and Notify the ESM Cloud Upgrade Plan 
-- ESM Cloud Upgrade Plan Wiki Page: https://confluence.opentext.com/display/ICSD/ESM+Cloud+Ops+Change+Calendar
-- ESM Cloud Ops Change Calendar: https://opentextcorporation.sharepoint.com/sites/MFI-SMAXSaaSDevOps/Lists/ESM%20Cloud%20Calendar/calendar.aspx
-- Internal Communication About ESM Cloud Upgrade Plan (Sample Email)
-### Continuous to adjust the plan according to the changes
-- Cancel/Postpone the upgrade according to critical defects
-
-### Rollback the upgrade 
-
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+## Review R&D Major Release Plan & Patch Plan
+- ESM RTE: Mihaela Claudia Chis <mchis@opentext.com>
+	- PI Planning Readout Slides 
+- ESM Patch Release Owner: Tanuj Raja Vunnava <tvunnava@opentext.com>
+	- Patch Release Kick Off email
+- Other requirement about upgrade strategy
+	- Demo/PoC Request
+	- Customer commitment etc.
+## Prepare Cloud Upgrade Plan 
+### Design Tool
+### Plan Strategy
+- US2 Dev Farm Upgrade Validation - 1~2 days prior MR release date
+- Shared Service - ITOM Aviator US30 staging, EU30 production, EU32 production need to be upgraded first before other consume farm upgrade
+- EU3/US7 Trial/PoC Farm Upgrade -  1~ 2 weeks after GA release date, Upgrade on Monday (working day)
+- US2/US24 Opentext Internal Customer Production Farm -  1st Wave Production Farm Upgrade (Maintenance Window)
+- US26 - SalesForce customer need alternative upgrade date this can be negotiated with CSM and customer
+- US26/US6/AP10/CA16 External Customer Production Farm - 2nd Wave Production Farm Upgrade (Maintenance Window)
+- EU8/EU18/EU28/BR14/JP12 External Customer Production Farm - 3nd Wave Production Farm Upgrade (Maintenance Window)
+- If ESM farm enable Operation Platform, need to upgrade Operation Platform first before upgrade ESM farm
+- Considering the 1st patch release, we can consider to adopt patch upgrade direct in the upgrade maintenance window (Need to clarify the dependencies)
+- Try to avoid upgrade window before key teams public holiday. Usually some critical issues will be reported on Monday/Tuesday after version upgrade. Need people standby to support troubleshooting
+
+### Publish and Notify the ESM Cloud Upgrade Plan 
+- ESM Cloud Upgrade Plan Wiki Page: https://confluence.opentext.com/display/ICSD/ESM+Cloud+Ops+Change+Calendar
+- ESM Cloud Ops Change Calendar: https://opentextcorporation.sharepoint.com/sites/MFI-SMAXSaaSDevOps/Lists/ESM%20Cloud%20Calendar/calendar.aspx
+- Internal Communication About ESM Cloud Upgrade Plan (Sample Email)
+### Continuous to adjust the plan according to the changes
+- Cancel/Postpone the upgrade according to critical defects
+
+### Rollback the upgrade 
+
+

Archived/Work/2025 ITOM Cloud Knowledge Transfer/ITOM Cloud Application List (Version, Capabilities).md

@@ -1,32 +1,32 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-## ESM Cloud 
-- ESM Farm Information: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
-- ESM Capability Introduction
-	- SMAX
-	- UCMDB, Native SACM, SAM
-	- HCMX/DnD
-	- OO
-	- AC
-	- FinOps Classic
-	- FinOps OP
-	- Operation Platform/Optic Data Lake (ODL)
-	- ITOM Aviator
-- ESM Farm Version Tracking: https://confluence.opentext.com/display/ICSD/ITOM+Cloud+Applications+Version+Tracking
-- ESM Customer Tenant Capabilities Enablement BI Report: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3a054e35d20b9d533d81?experience=power-bi
-
-## OpsB/NOM Cloud
-- OpsB/NOM Cloud Deployments & Version Tracking:https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking 
-
-## APM Cloud
-- APM Farm Information: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+## ESM Cloud 
+- ESM Farm Information: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
+- ESM Capability Introduction
+	- SMAX
+	- UCMDB, Native SACM, SAM
+	- HCMX/DnD
+	- OO
+	- AC
+	- FinOps Classic
+	- FinOps OP
+	- Operation Platform/Optic Data Lake (ODL)
+	- ITOM Aviator
+- ESM Farm Version Tracking: https://confluence.opentext.com/display/ICSD/ITOM+Cloud+Applications+Version+Tracking
+- ESM Customer Tenant Capabilities Enablement BI Report: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3a054e35d20b9d533d81?experience=power-bi
+
+## OpsB/NOM Cloud
+- OpsB/NOM Cloud Deployments & Version Tracking:https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking 
+
+## APM Cloud
+- APM Farm Information: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
+

Archived/Work/2025 ITOM Cloud Knowledge Transfer/ITOM Cloud Major Incident Management Process.md

@@ -1,29 +1,29 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-- Major Incident Definition: https://confluence.opentext.com/display/ICSD/Major+Incident+Definition
-- Major Incident Management & Best Practice:
-	- Identification and Detection
-	- Initial Assessment
-	- Incident Logging
-		- Incident in OT SM9
-		- Internal Practice: Create incident in PCS
-	- Communication
-		- Identify Incident Manager
-		- Create team chat group and involve all stakeholders 
-		- Keeping update status
-	- Resolution
----Break---
-	- Oncall/Response
-	- Post Incident Review
-	- Continuous Improvement  (CAPA)
-		- Monitoring & Alerting Enhancements
-		- Documentation & Knowledge base: 
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+- Major Incident Definition: https://confluence.opentext.com/display/ICSD/Major+Incident+Definition
+- Major Incident Management & Best Practice:
+	- Identification and Detection
+	- Initial Assessment
+	- Incident Logging
+		- Incident in OT SM9
+		- Internal Practice: Create incident in PCS
+	- Communication
+		- Identify Incident Manager
+		- Create team chat group and involve all stakeholders 
+		- Keeping update status
+	- Resolution
+---Break---
+	- Oncall/Response
+	- Post Incident Review
+	- Continuous Improvement  (CAPA)
+		- Monitoring & Alerting Enhancements
+		- Documentation & Knowledge base: 
 	

Archived/Work/2025 ITOM Cloud Knowledge Transfer/PCS KPI & Report.md

@@ -1,16 +1,16 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-BI report:
-
-https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1f4989a9-0127-4c6d-9375-f9dd9bda5d84/ReportSection?experience=power-bi
-
-PCS Dahsboard:
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+BI report:
+
+https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1f4989a9-0127-4c6d-9375-f9dd9bda5d84/ReportSection?experience=power-bi
+
+PCS Dahsboard:
 https://pcs.saas.microfocus.com/dashboard

Archived/Work/2025 ITOM Cloud Knowledge Transfer/PCS Service Offerings & Workflow Introduction.md

@@ -1,32 +1,32 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-PCS: https://pcs.saas.microfocus.com/homepage?AUTH=SAML
-
-ITOM Cloud Ops Assignment Group:
-- SD: ESM SaaS Ops
-- SD: OpsB SaaS Ops
-- SD: NOM SaaS Ops
-- SD: DCA SaaS Ops
-
-
-- ITOM Cloud Service Offerings
-- Service Request vs Support Request
-- Entitlement/Environment/Tenant/Product
-- Service/Support Request triage & workflow 
-- Request -> Incident -> Change 
-- Escalations
-
-BI report:
-
-https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1f4989a9-0127-4c6d-9375-f9dd9bda5d84/ReportSection?experience=power-bi
-
-PCS Dahsboard:
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+PCS: https://pcs.saas.microfocus.com/homepage?AUTH=SAML
+
+ITOM Cloud Ops Assignment Group:
+- SD: ESM SaaS Ops
+- SD: OpsB SaaS Ops
+- SD: NOM SaaS Ops
+- SD: DCA SaaS Ops
+
+
+- ITOM Cloud Service Offerings
+- Service Request vs Support Request
+- Entitlement/Environment/Tenant/Product
+- Service/Support Request triage & workflow 
+- Request -> Incident -> Change 
+- Escalations
+
+BI report:
+
+https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1f4989a9-0127-4c6d-9375-f9dd9bda5d84/ReportSection?experience=power-bi
+
+PCS Dahsboard:
 https://pcs.saas.microfocus.com/dashboard

Archived/Work/2025 ITOM Cloud Knowledge Transfer/Personal Transition Plan - Senior Manager of Cloud Service Delivery.md

@@ -1,60 +1,60 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-## Role and Responsibility
-#### Strategic Responsibilities
-- Own the reliability and performance of multiple SaaS Application Services. (APM, BPM, OpsB, NOM, ESM, DCA, SBM, ESM FedRAMP)
-- Drive cloud modernization initiatives (e.g., containerization, EKS, CI/CD automation).
-- Align cloud service delivery with customer SLAs, business growth, and compliance frameworks (e.g., FedRAMP, SBM).
-- Interface with Sales, Product, Security, and Compliance to support new customer onboarding and cloud architecture reviews.
-
-#### Operational Responsibilities
-- Oversee 24x7 operation and monitoring of cloud platforms (AWS-based).
-- Manage escalations, incidents, and root cause analysis.
-- Coordinate patching, upgrades, hotfixes, and maintenance windows.
-- Own service onboarding/offboarding workflows, including tenant provisioning and decommissioning.
-
-#### People Management
-- Performance management and coaching of global team members.
-- Run weekly team syncs, monthly reviews, and ad-hoc cross-regional escalations.
-
-## Cloud Applications and Cloud Services KS Sessions
-
-### Session 1 
-- ITOM Cloud Application AWS Account Owner
-	- https://confluence.opentext.com/display/ICSD/ITOM+Cloud+AWS+Account+Overview
-	- AWS Account Admin ownership
-	- Responsibility of AWS Account Admin
-- ITOM Cloud Application List
-	- ESM/ITOM Aviator/DCA/SBM: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
-	- OpsB/NOM Cloud Application List: https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
-	- APM Cloud Farm List: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
-- ITOM Cloud FinOps
-	- BI Reporting: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1a3fceca-6563-4cc6-8218-d1d27f15e2f1/ReportSection?experience=power-bi
-	- Opentext FinOps Team AWS FinOps Dashboard
-### Session 2
-- ITOM Cloud Application Version Currency
-	- Upgrade Plan 
-		- ESM/FebRAMP Ops Change Calendar
-		- OpsB/NOM Ops Change Calendar
-		- Upgrade Plan Timeline 
-
-### Session 3
-
-### Session 4
-
-### Session 5
-
-### Session 6
-
-### Session 7
-
-### Session 8
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+## Role and Responsibility
+#### Strategic Responsibilities
+- Own the reliability and performance of multiple SaaS Application Services. (APM, BPM, OpsB, NOM, ESM, DCA, SBM, ESM FedRAMP)
+- Drive cloud modernization initiatives (e.g., containerization, EKS, CI/CD automation).
+- Align cloud service delivery with customer SLAs, business growth, and compliance frameworks (e.g., FedRAMP, SBM).
+- Interface with Sales, Product, Security, and Compliance to support new customer onboarding and cloud architecture reviews.
+
+#### Operational Responsibilities
+- Oversee 24x7 operation and monitoring of cloud platforms (AWS-based).
+- Manage escalations, incidents, and root cause analysis.
+- Coordinate patching, upgrades, hotfixes, and maintenance windows.
+- Own service onboarding/offboarding workflows, including tenant provisioning and decommissioning.
+
+#### People Management
+- Performance management and coaching of global team members.
+- Run weekly team syncs, monthly reviews, and ad-hoc cross-regional escalations.
+
+## Cloud Applications and Cloud Services KS Sessions
+
+### Session 1 
+- ITOM Cloud Application AWS Account Owner
+	- https://confluence.opentext.com/display/ICSD/ITOM+Cloud+AWS+Account+Overview
+	- AWS Account Admin ownership
+	- Responsibility of AWS Account Admin
+- ITOM Cloud Application List
+	- ESM/ITOM Aviator/DCA/SBM: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
+	- OpsB/NOM Cloud Application List: https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
+	- APM Cloud Farm List: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
+- ITOM Cloud FinOps
+	- BI Reporting: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1a3fceca-6563-4cc6-8218-d1d27f15e2f1/ReportSection?experience=power-bi
+	- Opentext FinOps Team AWS FinOps Dashboard
+### Session 2
+- ITOM Cloud Application Version Currency
+	- Upgrade Plan 
+		- ESM/FebRAMP Ops Change Calendar
+		- OpsB/NOM Ops Change Calendar
+		- Upgrade Plan Timeline 
+
+### Session 3
+
+### Session 4
+
+### Session 5
+
+### Session 6
+
+### Session 7
+
+### Session 8

Archived/Work/AWS → GCP.md

@@ -1,75 +1,75 @@
----
-title: AWS → GCP
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-# AWS → GCP
-
-To migrate your enterprise-level SaaS application from AWS to Google Cloud, you’ll need to find equivalent Google Cloud services for the AWS services you currently use, while ensuring your architecture remains compatible. Here's a service-by-service breakdown for smooth development:
-
-### 1. **AWS EKS (Elastic Kubernetes Service) → Google Kubernetes Engine (GKE)**
-
-**Google Kubernetes Engine (GKE)** is Google Cloud’s equivalent to AWS EKS. Both manage Kubernetes clusters, offering similar features like autoscaling, security, and networking.
-
-- **Migration Notes**: Kubernetes manifests and Helm charts will be reusable with minimal modification, but you’ll need to handle network and security configurations specific to Google Cloud.
-
-### 2. **AWS RDS (Relational Database Service) → Cloud SQL / Cloud Spanner**
-
-- **Cloud SQL**: Supports MySQL, PostgreSQL, and SQL Server, making it a direct equivalent for most RDS instances.
-- **Cloud Spanner**: If you need horizontally scalable, globally distributed databases with strong consistency, consider Cloud Spanner.
-- **Migration Notes**: Database migration tools like **Database Migration Service** can help with the data migration, ensuring minimal downtime and compatibility.
-
-### 3. **AWS EFS (Elastic File System) → Filestore**
-
-**Google Cloud Filestore** is a fully managed NFS (Network File System) service similar to AWS EFS.
-
-- **Migration Notes**: Ensure your applications are configured to use the Filestore APIs and access paths properly. Performance tiers and network configuration will need review for alignment with your AWS EFS setup.
-
-### 4. **AWS S3 (Simple Storage Service) → Google Cloud Storage**
-
-**Google Cloud Storage** is a direct equivalent to AWS S3 for object storage, supporting multiple classes of storage with similar durability and availability guarantees.
-
-- **Migration Notes**: Google Cloud’s storage APIs differ slightly, so you may need to refactor your code to accommodate the differences. However, bucket management and object lifecycle policies are similar.
-
-### 5. **AWS Lambda (Serverless Compute) → Google Cloud Functions / Cloud Run**
-
-- **Google Cloud Functions**: Equivalent to AWS Lambda for small, event-driven serverless tasks.
-- **Cloud Run**: If you need to run containerized microservices, **Cloud Run** (based on Knative) is a good choice for scaling container workloads.
-- **Migration Notes**: Code migration is generally straightforward, though GCP uses slightly different event triggers and permission models.
-
-### 6. **AWS Parameter Store → Secret Manager / Cloud Key Management Service (KMS)**
-
-- **Secret Manager**: For storing secrets such as passwords, API keys, and tokens.
-- **Cloud KMS**: For managing encryption keys and ensuring data security.
-- **Migration Notes**: Similar management principles apply, but authentication and access policies will need revision to comply with Google Cloud's identity model.
-
-### 7. **AWS SES (Simple Email Service) → SendGrid / Mailgun (Third-party service)**
-
-Google Cloud doesn't have a native email service comparable to SES, so you can leverage third-party services like **SendGrid** or **Mailgun**, which integrate well with Google Cloud.
-
-- **Migration Notes**: Integration through APIs will require code changes, but the overall functionality will remain similar.
-
-### 8. **AWS CloudWatch → Google Cloud Monitoring (formerly Stackdriver)**
-
-**Google Cloud Monitoring** is the equivalent of AWS CloudWatch, providing observability, logging, and alerting for your infrastructure and applications.
-
-- **Migration Notes**: If you are heavily using AWS CloudWatch Logs, consider migrating to **Google Cloud Logging** to keep a similar flow of data.
-
-### Additional Considerations:
-
-- **IAM and Security**: AWS Identity and Access Management (IAM) maps well to Google Cloud IAM, but you'll need to refactor policies and roles.
-- **Networking**: Google Cloud’s VPC is similar to AWS VPC, but you'll need to translate networking configurations (firewalls, routing, etc.) and possibly update load balancing setups, using **Google Cloud Load Balancer** in place of AWS Elastic Load Balancing (ELB).
-
-### Tools for Migration:
-
-- **Google’s Database Migration Service**: To migrate RDS databases to Cloud SQL.
-- **Migrate for Compute Engine**: For VM migrations if you use EC2 instances.
-- **Velostrata**: For handling live migrations of workloads.
-
-Would you like to dive deeper into any particular service, or need assistance on a specific migration tool or process?
-
+---
+title: AWS → GCP
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+# AWS → GCP
+
+To migrate your enterprise-level SaaS application from AWS to Google Cloud, you’ll need to find equivalent Google Cloud services for the AWS services you currently use, while ensuring your architecture remains compatible. Here's a service-by-service breakdown for smooth development:
+
+### 1. **AWS EKS (Elastic Kubernetes Service) → Google Kubernetes Engine (GKE)**
+
+**Google Kubernetes Engine (GKE)** is Google Cloud’s equivalent to AWS EKS. Both manage Kubernetes clusters, offering similar features like autoscaling, security, and networking.
+
+- **Migration Notes**: Kubernetes manifests and Helm charts will be reusable with minimal modification, but you’ll need to handle network and security configurations specific to Google Cloud.
+
+### 2. **AWS RDS (Relational Database Service) → Cloud SQL / Cloud Spanner**
+
+- **Cloud SQL**: Supports MySQL, PostgreSQL, and SQL Server, making it a direct equivalent for most RDS instances.
+- **Cloud Spanner**: If you need horizontally scalable, globally distributed databases with strong consistency, consider Cloud Spanner.
+- **Migration Notes**: Database migration tools like **Database Migration Service** can help with the data migration, ensuring minimal downtime and compatibility.
+
+### 3. **AWS EFS (Elastic File System) → Filestore**
+
+**Google Cloud Filestore** is a fully managed NFS (Network File System) service similar to AWS EFS.
+
+- **Migration Notes**: Ensure your applications are configured to use the Filestore APIs and access paths properly. Performance tiers and network configuration will need review for alignment with your AWS EFS setup.
+
+### 4. **AWS S3 (Simple Storage Service) → Google Cloud Storage**
+
+**Google Cloud Storage** is a direct equivalent to AWS S3 for object storage, supporting multiple classes of storage with similar durability and availability guarantees.
+
+- **Migration Notes**: Google Cloud’s storage APIs differ slightly, so you may need to refactor your code to accommodate the differences. However, bucket management and object lifecycle policies are similar.
+
+### 5. **AWS Lambda (Serverless Compute) → Google Cloud Functions / Cloud Run**
+
+- **Google Cloud Functions**: Equivalent to AWS Lambda for small, event-driven serverless tasks.
+- **Cloud Run**: If you need to run containerized microservices, **Cloud Run** (based on Knative) is a good choice for scaling container workloads.
+- **Migration Notes**: Code migration is generally straightforward, though GCP uses slightly different event triggers and permission models.
+
+### 6. **AWS Parameter Store → Secret Manager / Cloud Key Management Service (KMS)**
+
+- **Secret Manager**: For storing secrets such as passwords, API keys, and tokens.
+- **Cloud KMS**: For managing encryption keys and ensuring data security.
+- **Migration Notes**: Similar management principles apply, but authentication and access policies will need revision to comply with Google Cloud's identity model.
+
+### 7. **AWS SES (Simple Email Service) → SendGrid / Mailgun (Third-party service)**
+
+Google Cloud doesn't have a native email service comparable to SES, so you can leverage third-party services like **SendGrid** or **Mailgun**, which integrate well with Google Cloud.
+
+- **Migration Notes**: Integration through APIs will require code changes, but the overall functionality will remain similar.
+
+### 8. **AWS CloudWatch → Google Cloud Monitoring (formerly Stackdriver)**
+
+**Google Cloud Monitoring** is the equivalent of AWS CloudWatch, providing observability, logging, and alerting for your infrastructure and applications.
+
+- **Migration Notes**: If you are heavily using AWS CloudWatch Logs, consider migrating to **Google Cloud Logging** to keep a similar flow of data.
+
+### Additional Considerations:
+
+- **IAM and Security**: AWS Identity and Access Management (IAM) maps well to Google Cloud IAM, but you'll need to refactor policies and roles.
+- **Networking**: Google Cloud’s VPC is similar to AWS VPC, but you'll need to translate networking configurations (firewalls, routing, etc.) and possibly update load balancing setups, using **Google Cloud Load Balancer** in place of AWS Elastic Load Balancing (ELB).
+
+### Tools for Migration:
+
+- **Google’s Database Migration Service**: To migrate RDS databases to Cloud SQL.
+- **Migrate for Compute Engine**: For VM migrations if you use EC2 instances.
+- **Velostrata**: For handling live migrations of workloads.
+
+Would you like to dive deeper into any particular service, or need assistance on a specific migration tool or process?
+

Archived/Work/Answers from ChatGPT.md

@@ -1,210 +1,210 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-#### Major Incident Management Process
-
-Certainly! Designing a comprehensive Major Incident Management process is crucial for maintaining the reliability and availability of enterprise SaaS applications. Below is a detailed outline of the major incident management process, including procedures for handling service outages:
-
-### Major Incident Management Process
-
-#### 1. **Identification and Detection:**
-
-- **Automated Monitoring:** Utilize robust monitoring tools to detect anomalies, performance issues, and potential outages.
-- **User Reports:** Encourage users to report issues promptly via designated channels.
-
-#### 2. **Incident Logging:**
-
-- **Centralized Logging:** Maintain a centralized incident log that captures all relevant details, timestamps, and initial impact assessment.
-- **Severity Classification:** Categorize incidents based on severity to prioritize response efforts.
-
-#### 3. **Initial Assessment:**
-
-- **Incident Triage:** Quickly assemble a cross-functional incident response team, including representatives from development, operations, and support.
-- **Impact Analysis:** Evaluate the scope and impact of the incident on users, systems, and business operations.
-
-#### 4. **Communication:**
-
-- **Internal Communication:** Establish communication channels for the incident response team, ensuring timely updates and coordination.
-- **External Communication:** Prepare predefined messages for customers and stakeholders, providing transparency about the incident.
-
-#### 5. **Resolution:**
-
-- **Runbooks and Playbooks:** Develop detailed runbooks and playbooks for common incident scenarios, outlining step-by-step resolution procedures.
-- **Escalation Procedures:** Define clear escalation paths for issues that require higher-level expertise or management attention.
-
-#### 6. **Post-Incident Review (PIR):**
-
-- **Root Cause Analysis (RCA):** Conduct a thorough RCA to identify the underlying cause of the incident.
-- **Documentation:** Document the incident resolution process, lessons learned, and preventive measures for future incidents.
-
-#### 7. **Continuous Improvement:**
-
-- **Iterative Updates:** Regularly update incident response procedures based on lessons learned from past incidents.
-- **Training and Drills:** Conduct regular training sessions and simulated drills to ensure the incident response team is well-prepared.
-
-#### 8. **Monitoring and Alerting Enhancements:**
-
-- **Continuous Monitoring:** Implement ongoing improvements to monitoring and alerting systems to proactively detect potential issues.
-- **Automated Remediation:** Integrate automated remediation tools to address common incidents swiftly.
-
-#### 9. **Documentation and Knowledge Sharing:**
-
-- **Knowledge Base:** Maintain a comprehensive knowledge base with troubleshooting guides, FAQs, and resolutions for known issues.
-- **Documentation Accessibility:** Ensure that incident response documentation is easily accessible to all team members.
-
-#### 10. **Review and Audit:**
-
-- **Periodic Audits:** Conduct periodic reviews and audits of the major incident management process to identify areas for improvement.
-- **Compliance Checks:** Ensure that the process aligns with industry best practices and regulatory requirements.
-
-This Major Incident Management process should be regularly reviewed and updated to adapt to evolving technologies and organizational needs. Regular training and communication exercises will help maintain a proactive and efficient incident response capability.
-
-#### What’s the definition of RACI
-
-RACI is an acronym that stands for Responsible, Accountable, Consulted, and Informed. It is a project management and organizational tool used to clarify roles and responsibilities within a team or across different stakeholders for specific tasks, processes, or projects. Each letter in RACI represents a different level of involvement and accountability:
-
-1. Responsible (R): This person or role is responsible for completing the task or carrying out the work. They are the individuals who perform the actual work and ensure it gets done.
-2. Accountable (A): This person is ultimately accountable for the task's success or failure. They are the decision-makers who oversee the work and ensure it aligns with the project's objectives. There should be only one "A" assigned to each task or activity.
-3. Consulted (C): These are individuals or roles that provide input, expertise, or advice on the task. They are consulted for their knowledge or perspective, but they are not responsible for the task's completion.
-4. Informed (I): These individuals or roles need to be kept informed about the task's progress or outcome but do not have active participation in its execution.
-
-RACI matrices and charts are commonly used to document and communicate these roles and responsibilities, helping teams and organizations to reduce confusion, improve accountability, and ensure that work is completed efficiently and effectively.
-
-#### Handling Data Return in Enterprise SaaS Business
-
-Handling data returns in an enterprise SaaS business requires a well-defined process to ensure customer satisfaction and compliance with data privacy regulations. Here's a step-by-step guide to help you prepare a process for when a client requests to return their data:
-
-1. **Understand Data Ownership and Privacy Policies:**
-   - Clearly define data ownership in your terms of service and privacy policy.
-   - Understand and comply with data protection regulations relevant to your industry and geographic location (e.g., GDPR, CCPA).
-2. **Provide Clear Terms in Contracts:**
-   - Include provisions in your contracts that outline the conditions under which clients can request the return of their data.
-   - Specify the format and timeline for data return.
-3. **Implement Data Export Features:**
-   - Build data export features into your SaaS platform to allow clients to easily retrieve their data in a standard and commonly used format (e.g., CSV, JSON).
-   - Ensure that exported data includes all relevant information and maintains data integrity.
-4. **Establish a Request Process:**
-   - Create a formalized process for clients to request the return of their data.
-   - This process could include a dedicated support channel, a web portal, or a specific form.
-5. **Authenticate and Verify Requests:**
-   - Implement a robust authentication process to ensure that only authorized individuals can request data returns.
-   - Verify the identity of the requester through multi-factor authentication or other secure means.
-6. **Document and Track Requests:**
-   - Keep a centralized record of all data return requests.
-   - Track the status of each request, including when it was received, processed, and completed.
-7. **Review and Cleanse Data:**
-   - Before returning data, review it to ensure it doesn’t contain any sensitive information from other users.
-   - Implement a data cleansing process to remove any irrelevant or unnecessary information.
-8. **Secure Data Transmission:**
-   - Use secure channels and encryption protocols to transmit the data back to the client.
-   - Provide the client with instructions on how to securely receive the data.
-9. **Notify Client of Completion:**
-   - Notify the client when their data return request has been processed and the data is available for retrieval.
-   - Provide any relevant documentation or instructions.
-10. **Follow Up for Feedback:**
-
-```other
--   Follow up with the client after the data return to gather feedback on the process and ensure their satisfaction.
--   Use feedback to continuously improve the data return process.
-```
-
-11. **Train Support and Compliance Teams:**
-
-```other
--   Ensure that your support and compliance teams are well-trained on the data return process.
--   Keep them updated on any changes to regulations or internal policies.
-```
-
-12. **Regularly Review and Update Process:**
-
-```other
--   Periodically review and update the data return process to incorporate any changes in regulations, technology, or customer needs.
-```
-
-By implementing a well-structured process, you can efficiently handle data return requests, maintain customer trust, and comply with data protection laws.
-
-#### Routine DR Validation Process
-
-Routine disaster recovery (DR) validation reviews are crucial for ensuring the resilience of your enterprise SaaS business. Here's a step-by-step guide to help you prepare a process for routine disaster recovery validation reviews:
-
-1. **Define Objectives and Scope:**
-   - Clearly define the objectives of the routine disaster recovery validation review.
-   - Specify the scope, including the systems, applications, and data that will be included in the review.
-2. **Establish a Schedule:**
-   - Set a regular schedule for conducting disaster recovery validation reviews. This could be quarterly, semi-annually, or annually based on the criticality of your systems.
-3. **Document the Disaster Recovery Plan (DRP):**
-   - Ensure that you have a comprehensive and up-to-date disaster recovery plan in place.
-   - Document the step-by-step procedures for recovering systems and data in the event of a disaster.
-4. **Identify Key Stakeholders:**
-   - Identify the key stakeholders involved in the disaster recovery validation process.
-   - This may include IT administrators, security personnel, and relevant business unit representatives.
-5. **Select Validation Criteria:**
-   - Define the criteria that will be used to validate the effectiveness of the disaster recovery plan.
-   - Criteria may include recovery time objectives (RTO), recovery point objectives (RPO), and data integrity.
-6. **Simulate Disaster Scenarios:**
-   - Develop a set of realistic disaster scenarios that could impact your systems and data.
-   - Simulate these scenarios to test the effectiveness of your disaster recovery plan.
-7. **Coordinate with Third-Party Vendors:**
-   - If your SaaS business relies on third-party vendors or cloud service providers, coordinate with them to ensure that their disaster recovery plans align with yours.
-   - Validate their processes and capabilities as part of your review.
-8. **Perform Tabletop Exercises:**
-   - Conduct tabletop exercises with key stakeholders to walk through various disaster recovery scenarios.
-   - Use these exercises to identify weaknesses, gaps, and areas for improvement in the plan.
-9. **Automate Testing Where Possible:**
-   - Implement automation tools to simulate and test disaster recovery procedures.
-   - Automation can help streamline the testing process and provide more accurate results.
-10. **Measure and Analyze Results:**
-   - Measure the performance against the defined criteria during each validation review.
-   - Analyze the results to identify trends, patterns, and areas that need improvement.
-11. **Document Findings and Recommendations:**
-   - Document the findings of each disaster recovery validation review.
-   - Provide clear recommendations for improvements and corrective actions.
-12. **Implement Improvements:**
-   - Act on the recommendations and implement improvements to enhance the effectiveness of your disaster recovery plan.
-13. **Review and Update DRP:**
-   - Regularly review and update the disaster recovery plan based on the lessons learned from validation reviews and changes in your IT infrastructure.
-14. **Communicate Results:**
-   - Communicate the results of the disaster recovery validation reviews to relevant stakeholders.
-   - Ensure transparency and provide information on the steps being taken to address any identified issues.
-15. **Continuous Training and Awareness:**
-   - Conduct regular training sessions for your IT and operational teams to ensure they are familiar with the disaster recovery procedures.
-   - Raise awareness among employees about the importance of disaster recovery and their roles in the process.
-
-By following these steps, you can establish a robust process for routine disaster recovery validation reviews, helping to ensure the resilience and continuity of your enterprise SaaS business in the face of potential disasters.
-
-
-
-#### Please help explain what's the SOC2 audit?
-
-Please help me explain what's the SOC2 audit?
-
-SOC 2, which stands for Service Organization Control 2, is a framework for managing and securing data that is crucial for the privacy of user information. It is specifically designed for technology and cloud computing organizations that store customer data in the cloud. Developed by the American Institute of CPAs (AICPA), SOC 2 compliance is not a one-time event but an ongoing process that requires companies to follow certain criteria to ensure the security, availability, processing integrity, confidentiality, and privacy of customer data.
-
-Here are key components of a SOC 2 audit:
-
-1. **Trust Service Criteria:** SOC 2 is built around five "Trust Service Criteria" (TSC) – security, availability, processing integrity, confidentiality, and privacy. These criteria serve as the foundation for evaluating an organization's systems and processes.
-   - **Security:** The system is protected against unauthorized access (both physical and logical).
-   - **Availability:** The system is available for operation and use as committed or agreed.
-   - **Processing Integrity:** System processing is complete, valid, accurate, timely, and authorized.
-   - **Confidentiality:** Information designated as confidential is protected as committed or agreed.
-   - **Privacy:** Personal information is collected, used, retained, disclosed, and disposed of in conformity with the commitments in the entity’s privacy notice.
-2. **SOC 2 Type I and Type II Audits:**
-   - **Type I:** Examines the suitability of the design of controls at a specific point in time.
-   - **Type II:** Examines the operational effectiveness of these controls over a period of time (typically a minimum of six months).
-3. **Scope and Boundary:** The organization defines the scope of the audit, including the systems that are in scope and the boundaries of the environment being evaluated.
-4. **Risk Management and Compliance:** SOC 2 requires organizations to identify and manage risks related to the security, availability, processing integrity, confidentiality, and privacy of information.
-5. **Written Policies and Procedures:** Organizations need to have documented policies and procedures in place to demonstrate how they achieve and maintain compliance with the Trust Service Criteria.
-6. **Third-Party Involvement:** If a company uses third-party service providers, the SOC 2 audit may extend to these providers to ensure that their services also meet the required standards.
-
-Successfully completing a SOC 2 audit provides organizations with a valuable certification that demonstrates their commitment to data security and privacy. It is often seen as a trust-building factor for customers and partners who want assurance that their data is handled with the utmost care and security.
-
-
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+#### Major Incident Management Process
+
+Certainly! Designing a comprehensive Major Incident Management process is crucial for maintaining the reliability and availability of enterprise SaaS applications. Below is a detailed outline of the major incident management process, including procedures for handling service outages:
+
+### Major Incident Management Process
+
+#### 1. **Identification and Detection:**
+
+- **Automated Monitoring:** Utilize robust monitoring tools to detect anomalies, performance issues, and potential outages.
+- **User Reports:** Encourage users to report issues promptly via designated channels.
+
+#### 2. **Incident Logging:**
+
+- **Centralized Logging:** Maintain a centralized incident log that captures all relevant details, timestamps, and initial impact assessment.
+- **Severity Classification:** Categorize incidents based on severity to prioritize response efforts.
+
+#### 3. **Initial Assessment:**
+
+- **Incident Triage:** Quickly assemble a cross-functional incident response team, including representatives from development, operations, and support.
+- **Impact Analysis:** Evaluate the scope and impact of the incident on users, systems, and business operations.
+
+#### 4. **Communication:**
+
+- **Internal Communication:** Establish communication channels for the incident response team, ensuring timely updates and coordination.
+- **External Communication:** Prepare predefined messages for customers and stakeholders, providing transparency about the incident.
+
+#### 5. **Resolution:**
+
+- **Runbooks and Playbooks:** Develop detailed runbooks and playbooks for common incident scenarios, outlining step-by-step resolution procedures.
+- **Escalation Procedures:** Define clear escalation paths for issues that require higher-level expertise or management attention.
+
+#### 6. **Post-Incident Review (PIR):**
+
+- **Root Cause Analysis (RCA):** Conduct a thorough RCA to identify the underlying cause of the incident.
+- **Documentation:** Document the incident resolution process, lessons learned, and preventive measures for future incidents.
+
+#### 7. **Continuous Improvement:**
+
+- **Iterative Updates:** Regularly update incident response procedures based on lessons learned from past incidents.
+- **Training and Drills:** Conduct regular training sessions and simulated drills to ensure the incident response team is well-prepared.
+
+#### 8. **Monitoring and Alerting Enhancements:**
+
+- **Continuous Monitoring:** Implement ongoing improvements to monitoring and alerting systems to proactively detect potential issues.
+- **Automated Remediation:** Integrate automated remediation tools to address common incidents swiftly.
+
+#### 9. **Documentation and Knowledge Sharing:**
+
+- **Knowledge Base:** Maintain a comprehensive knowledge base with troubleshooting guides, FAQs, and resolutions for known issues.
+- **Documentation Accessibility:** Ensure that incident response documentation is easily accessible to all team members.
+
+#### 10. **Review and Audit:**
+
+- **Periodic Audits:** Conduct periodic reviews and audits of the major incident management process to identify areas for improvement.
+- **Compliance Checks:** Ensure that the process aligns with industry best practices and regulatory requirements.
+
+This Major Incident Management process should be regularly reviewed and updated to adapt to evolving technologies and organizational needs. Regular training and communication exercises will help maintain a proactive and efficient incident response capability.
+
+#### What’s the definition of RACI
+
+RACI is an acronym that stands for Responsible, Accountable, Consulted, and Informed. It is a project management and organizational tool used to clarify roles and responsibilities within a team or across different stakeholders for specific tasks, processes, or projects. Each letter in RACI represents a different level of involvement and accountability:
+
+1. Responsible (R): This person or role is responsible for completing the task or carrying out the work. They are the individuals who perform the actual work and ensure it gets done.
+2. Accountable (A): This person is ultimately accountable for the task's success or failure. They are the decision-makers who oversee the work and ensure it aligns with the project's objectives. There should be only one "A" assigned to each task or activity.
+3. Consulted (C): These are individuals or roles that provide input, expertise, or advice on the task. They are consulted for their knowledge or perspective, but they are not responsible for the task's completion.
+4. Informed (I): These individuals or roles need to be kept informed about the task's progress or outcome but do not have active participation in its execution.
+
+RACI matrices and charts are commonly used to document and communicate these roles and responsibilities, helping teams and organizations to reduce confusion, improve accountability, and ensure that work is completed efficiently and effectively.
+
+#### Handling Data Return in Enterprise SaaS Business
+
+Handling data returns in an enterprise SaaS business requires a well-defined process to ensure customer satisfaction and compliance with data privacy regulations. Here's a step-by-step guide to help you prepare a process for when a client requests to return their data:
+
+1. **Understand Data Ownership and Privacy Policies:**
+   - Clearly define data ownership in your terms of service and privacy policy.
+   - Understand and comply with data protection regulations relevant to your industry and geographic location (e.g., GDPR, CCPA).
+2. **Provide Clear Terms in Contracts:**
+   - Include provisions in your contracts that outline the conditions under which clients can request the return of their data.
+   - Specify the format and timeline for data return.
+3. **Implement Data Export Features:**
+   - Build data export features into your SaaS platform to allow clients to easily retrieve their data in a standard and commonly used format (e.g., CSV, JSON).
+   - Ensure that exported data includes all relevant information and maintains data integrity.
+4. **Establish a Request Process:**
+   - Create a formalized process for clients to request the return of their data.
+   - This process could include a dedicated support channel, a web portal, or a specific form.
+5. **Authenticate and Verify Requests:**
+   - Implement a robust authentication process to ensure that only authorized individuals can request data returns.
+   - Verify the identity of the requester through multi-factor authentication or other secure means.
+6. **Document and Track Requests:**
+   - Keep a centralized record of all data return requests.
+   - Track the status of each request, including when it was received, processed, and completed.
+7. **Review and Cleanse Data:**
+   - Before returning data, review it to ensure it doesn’t contain any sensitive information from other users.
+   - Implement a data cleansing process to remove any irrelevant or unnecessary information.
+8. **Secure Data Transmission:**
+   - Use secure channels and encryption protocols to transmit the data back to the client.
+   - Provide the client with instructions on how to securely receive the data.
+9. **Notify Client of Completion:**
+   - Notify the client when their data return request has been processed and the data is available for retrieval.
+   - Provide any relevant documentation or instructions.
+10. **Follow Up for Feedback:**
+
+```other
+-   Follow up with the client after the data return to gather feedback on the process and ensure their satisfaction.
+-   Use feedback to continuously improve the data return process.
+```
+
+11. **Train Support and Compliance Teams:**
+
+```other
+-   Ensure that your support and compliance teams are well-trained on the data return process.
+-   Keep them updated on any changes to regulations or internal policies.
+```
+
+12. **Regularly Review and Update Process:**
+
+```other
+-   Periodically review and update the data return process to incorporate any changes in regulations, technology, or customer needs.
+```
+
+By implementing a well-structured process, you can efficiently handle data return requests, maintain customer trust, and comply with data protection laws.
+
+#### Routine DR Validation Process
+
+Routine disaster recovery (DR) validation reviews are crucial for ensuring the resilience of your enterprise SaaS business. Here's a step-by-step guide to help you prepare a process for routine disaster recovery validation reviews:
+
+1. **Define Objectives and Scope:**
+   - Clearly define the objectives of the routine disaster recovery validation review.
+   - Specify the scope, including the systems, applications, and data that will be included in the review.
+2. **Establish a Schedule:**
+   - Set a regular schedule for conducting disaster recovery validation reviews. This could be quarterly, semi-annually, or annually based on the criticality of your systems.
+3. **Document the Disaster Recovery Plan (DRP):**
+   - Ensure that you have a comprehensive and up-to-date disaster recovery plan in place.
+   - Document the step-by-step procedures for recovering systems and data in the event of a disaster.
+4. **Identify Key Stakeholders:**
+   - Identify the key stakeholders involved in the disaster recovery validation process.
+   - This may include IT administrators, security personnel, and relevant business unit representatives.
+5. **Select Validation Criteria:**
+   - Define the criteria that will be used to validate the effectiveness of the disaster recovery plan.
+   - Criteria may include recovery time objectives (RTO), recovery point objectives (RPO), and data integrity.
+6. **Simulate Disaster Scenarios:**
+   - Develop a set of realistic disaster scenarios that could impact your systems and data.
+   - Simulate these scenarios to test the effectiveness of your disaster recovery plan.
+7. **Coordinate with Third-Party Vendors:**
+   - If your SaaS business relies on third-party vendors or cloud service providers, coordinate with them to ensure that their disaster recovery plans align with yours.
+   - Validate their processes and capabilities as part of your review.
+8. **Perform Tabletop Exercises:**
+   - Conduct tabletop exercises with key stakeholders to walk through various disaster recovery scenarios.
+   - Use these exercises to identify weaknesses, gaps, and areas for improvement in the plan.
+9. **Automate Testing Where Possible:**
+   - Implement automation tools to simulate and test disaster recovery procedures.
+   - Automation can help streamline the testing process and provide more accurate results.
+10. **Measure and Analyze Results:**
+   - Measure the performance against the defined criteria during each validation review.
+   - Analyze the results to identify trends, patterns, and areas that need improvement.
+11. **Document Findings and Recommendations:**
+   - Document the findings of each disaster recovery validation review.
+   - Provide clear recommendations for improvements and corrective actions.
+12. **Implement Improvements:**
+   - Act on the recommendations and implement improvements to enhance the effectiveness of your disaster recovery plan.
+13. **Review and Update DRP:**
+   - Regularly review and update the disaster recovery plan based on the lessons learned from validation reviews and changes in your IT infrastructure.
+14. **Communicate Results:**
+   - Communicate the results of the disaster recovery validation reviews to relevant stakeholders.
+   - Ensure transparency and provide information on the steps being taken to address any identified issues.
+15. **Continuous Training and Awareness:**
+   - Conduct regular training sessions for your IT and operational teams to ensure they are familiar with the disaster recovery procedures.
+   - Raise awareness among employees about the importance of disaster recovery and their roles in the process.
+
+By following these steps, you can establish a robust process for routine disaster recovery validation reviews, helping to ensure the resilience and continuity of your enterprise SaaS business in the face of potential disasters.
+
+
+
+#### Please help explain what's the SOC2 audit?
+
+Please help me explain what's the SOC2 audit?
+
+SOC 2, which stands for Service Organization Control 2, is a framework for managing and securing data that is crucial for the privacy of user information. It is specifically designed for technology and cloud computing organizations that store customer data in the cloud. Developed by the American Institute of CPAs (AICPA), SOC 2 compliance is not a one-time event but an ongoing process that requires companies to follow certain criteria to ensure the security, availability, processing integrity, confidentiality, and privacy of customer data.
+
+Here are key components of a SOC 2 audit:
+
+1. **Trust Service Criteria:** SOC 2 is built around five "Trust Service Criteria" (TSC) – security, availability, processing integrity, confidentiality, and privacy. These criteria serve as the foundation for evaluating an organization's systems and processes.
+   - **Security:** The system is protected against unauthorized access (both physical and logical).
+   - **Availability:** The system is available for operation and use as committed or agreed.
+   - **Processing Integrity:** System processing is complete, valid, accurate, timely, and authorized.
+   - **Confidentiality:** Information designated as confidential is protected as committed or agreed.
+   - **Privacy:** Personal information is collected, used, retained, disclosed, and disposed of in conformity with the commitments in the entity’s privacy notice.
+2. **SOC 2 Type I and Type II Audits:**
+   - **Type I:** Examines the suitability of the design of controls at a specific point in time.
+   - **Type II:** Examines the operational effectiveness of these controls over a period of time (typically a minimum of six months).
+3. **Scope and Boundary:** The organization defines the scope of the audit, including the systems that are in scope and the boundaries of the environment being evaluated.
+4. **Risk Management and Compliance:** SOC 2 requires organizations to identify and manage risks related to the security, availability, processing integrity, confidentiality, and privacy of information.
+5. **Written Policies and Procedures:** Organizations need to have documented policies and procedures in place to demonstrate how they achieve and maintain compliance with the Trust Service Criteria.
+6. **Third-Party Involvement:** If a company uses third-party service providers, the SOC 2 audit may extend to these providers to ensure that their services also meet the required standards.
+
+Successfully completing a SOC 2 audit provides organizations with a valuable certification that demonstrates their commitment to data security and privacy. It is often seen as a trust-building factor for customers and partners who want assurance that their data is handled with the utmost care and security.
+
+
+

Archived/Work/CSD/ESM Cloud Application Troubleshooting as a Service.md

@@ -1,55 +1,55 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-## Introduction
-The main purpose of this document is to help non-Cloud Ops team members better understand the various services and tools currently provided for Cloud Application troubleshooting, so that they can be used flexibly in different scenarios and reduce dependence on Cloud Ops engineers.
-Our goal is also very clear. We hope to provide a more efficient DevOps ecosystem to provide better services to our customers.
-
-**Please note that the various services and tools mentioned below require approval and authorization, and are currently limited to members of the Cloud Ops and R&D CPE teams**
-## Troubleshooting as a Service
-
-### Access Environment as a Service
-#### Access to Customer Tenant 
-We provide a method to enter the customer's tenant so that when doing troubleshooting, you can directly access the customer's environment to check the problem and understand the symptoms of the problem at the first time, so as to make the right judgment.
-
-
-#### Access to ESM Farm BO, IDM, UCMDB JMX console
-We provide a method to apply for temporary user  access to each farm management console
-- BO Suite Admin
-- ESM IDM Admin
-- UCMDB Super Admin to UCMDB JMX Console
-
-### Log Collection as a Service
-We provide a very comprehensive log collection automation tool.
-Collect log information of a specific module within a specific time period. Users can select appropriate filtering conditions to collect logs according to different scenarios, so as to locate problems more accurately and reduce extra effort caused by excessive log size.
-
-
-### Check Configuration
-
-### Monitoring as a Service
-
-#### Unified Monitoring via pre-defined Grafana Dashboard
-We provide a lot of rich implementation monitoring data for various troubleshooting. Currently we use Grafana as the monitoring UI to reflect the monitoring data of farm implementation:
-- AWS Cloud Watch Data Source - Able to have real-time infrastructure monitoring (AWS EKS/EFS/RDS)
-- Prometheus Data Source - Able to check real-time application level metrics exposed by Prometheus 
-- Database query Data Source - Get some key indicators of the application through database query
-- Containerize/K8S - Able to monitor the key monitoring data of the containerize product, container/node/pod etc.
-
-#### Service Availability Health Page
-
-
-### Log Analysis as a Service
-
-### BI Reporting as a Service
-
-### Unplanned Change Request as a Service
-
-### Other Services
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+## Introduction
+The main purpose of this document is to help non-Cloud Ops team members better understand the various services and tools currently provided for Cloud Application troubleshooting, so that they can be used flexibly in different scenarios and reduce dependence on Cloud Ops engineers.
+Our goal is also very clear. We hope to provide a more efficient DevOps ecosystem to provide better services to our customers.
+
+**Please note that the various services and tools mentioned below require approval and authorization, and are currently limited to members of the Cloud Ops and R&D CPE teams**
+## Troubleshooting as a Service
+
+### Access Environment as a Service
+#### Access to Customer Tenant 
+We provide a method to enter the customer's tenant so that when doing troubleshooting, you can directly access the customer's environment to check the problem and understand the symptoms of the problem at the first time, so as to make the right judgment.
+
+
+#### Access to ESM Farm BO, IDM, UCMDB JMX console
+We provide a method to apply for temporary user  access to each farm management console
+- BO Suite Admin
+- ESM IDM Admin
+- UCMDB Super Admin to UCMDB JMX Console
+
+### Log Collection as a Service
+We provide a very comprehensive log collection automation tool.
+Collect log information of a specific module within a specific time period. Users can select appropriate filtering conditions to collect logs according to different scenarios, so as to locate problems more accurately and reduce extra effort caused by excessive log size.
+
+
+### Check Configuration
+
+### Monitoring as a Service
+
+#### Unified Monitoring via pre-defined Grafana Dashboard
+We provide a lot of rich implementation monitoring data for various troubleshooting. Currently we use Grafana as the monitoring UI to reflect the monitoring data of farm implementation:
+- AWS Cloud Watch Data Source - Able to have real-time infrastructure monitoring (AWS EKS/EFS/RDS)
+- Prometheus Data Source - Able to check real-time application level metrics exposed by Prometheus 
+- Database query Data Source - Get some key indicators of the application through database query
+- Containerize/K8S - Able to monitor the key monitoring data of the containerize product, container/node/pod etc.
+
+#### Service Availability Health Page
+
+
+### Log Analysis as a Service
+
+### BI Reporting as a Service
+
+### Unplanned Change Request as a Service
+
+### Other Services

Archived/Work/CSD/ESM Cloud Knowledge Sharing Plan.md

@@ -1,32 +1,32 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-## Product Service
-### ESM Product
-
-### ESM Cloud Trial 
-
-## Customer Service
-### SaaS Customer Support Model
-### Customer Service Offering Runbook
-- Configure SAML authentication
-- Configure custom domain for customer 
-
-
-## DevOps/SRE
-### ESM Cloud GitLab
-### ESM Cloud Operation Automation/Jenkins
-### ESM Cloud Monitoring 
-### ESM Cloud System Health Page
-### ESM Cloud Disaster Recovery
-
-
-
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+## Product Service
+### ESM Product
+
+### ESM Cloud Trial 
+
+## Customer Service
+### SaaS Customer Support Model
+### Customer Service Offering Runbook
+- Configure SAML authentication
+- Configure custom domain for customer 
+
+
+## DevOps/SRE
+### ESM Cloud GitLab
+### ESM Cloud Operation Automation/Jenkins
+### ESM Cloud Monitoring 
+### ESM Cloud System Health Page
+### ESM Cloud Disaster Recovery
+
+
+
+

Archived/Work/CSD/Personal Transition Plan - Senior Manager of Cloud Service Delivery.md

@@ -1,60 +1,60 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-## Role and Responsibility
-#### Strategic Responsibilities
-- Own the reliability and performance of multiple SaaS Application Services. (APM, BPM, OpsB, NOM, ESM, DCA, SBM, ESM FedRAMP)
-- Drive cloud modernization initiatives (e.g., containerization, EKS, CI/CD automation).
-- Align cloud service delivery with customer SLAs, business growth, and compliance frameworks (e.g., FedRAMP, SBM).
-- Interface with Sales, Product, Security, and Compliance to support new customer onboarding and cloud architecture reviews.
-
-#### Operational Responsibilities
-- Oversee 24x7 operation and monitoring of cloud platforms (AWS-based).
-- Manage escalations, incidents, and root cause analysis.
-- Coordinate patching, upgrades, hotfixes, and maintenance windows.
-- Own service onboarding/offboarding workflows, including tenant provisioning and decommissioning.
-
-#### People Management
-- Performance management and coaching of global team members.
-- Run weekly team syncs, monthly reviews, and ad-hoc cross-regional escalations.
-
-## Cloud Applications and Cloud Services KS Sessions
-
-### Session 1 
-- ITOM Cloud Application AWS Account Owner
-	- https://confluence.opentext.com/display/ICSD/ITOM+Cloud+AWS+Account+Overview
-	- AWS Account Admin ownership
-	- Responsibility of AWS Account Admin
-- ITOM Cloud Application List
-	- ESM/ITOM Aviator/DCA/SBM: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
-	- OpsB/NOM Cloud Application List: https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
-	- APM Cloud Farm List: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
-- ITOM Cloud FinOps
-	- BI Reporting: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1a3fceca-6563-4cc6-8218-d1d27f15e2f1/ReportSection?experience=power-bi
-	- Opentext FinOps Team AWS FinOps Dashboard
-### Session 2
-- ITOM Cloud Application Version Currency
-	- Upgrade Plan 
-		- ESM/FebRAMP Ops Change Calendar
-		- OpsB/NOM Ops Change Calendar
-		- Upgrade Plan Timeline 
-
-### Session 3
-
-### Session 4
-
-### Session 5
-
-### Session 6
-
-### Session 7
-
-### Session 8
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+## Role and Responsibility
+#### Strategic Responsibilities
+- Own the reliability and performance of multiple SaaS Application Services. (APM, BPM, OpsB, NOM, ESM, DCA, SBM, ESM FedRAMP)
+- Drive cloud modernization initiatives (e.g., containerization, EKS, CI/CD automation).
+- Align cloud service delivery with customer SLAs, business growth, and compliance frameworks (e.g., FedRAMP, SBM).
+- Interface with Sales, Product, Security, and Compliance to support new customer onboarding and cloud architecture reviews.
+
+#### Operational Responsibilities
+- Oversee 24x7 operation and monitoring of cloud platforms (AWS-based).
+- Manage escalations, incidents, and root cause analysis.
+- Coordinate patching, upgrades, hotfixes, and maintenance windows.
+- Own service onboarding/offboarding workflows, including tenant provisioning and decommissioning.
+
+#### People Management
+- Performance management and coaching of global team members.
+- Run weekly team syncs, monthly reviews, and ad-hoc cross-regional escalations.
+
+## Cloud Applications and Cloud Services KS Sessions
+
+### Session 1 
+- ITOM Cloud Application AWS Account Owner
+	- https://confluence.opentext.com/display/ICSD/ITOM+Cloud+AWS+Account+Overview
+	- AWS Account Admin ownership
+	- Responsibility of AWS Account Admin
+- ITOM Cloud Application List
+	- ESM/ITOM Aviator/DCA/SBM: https://confluence.opentext.com/display/ICSD/ITOM+ESM+Cloud+Farm+Information
+	- OpsB/NOM Cloud Application List: https://confluence.opentext.com/display/ICSD/OpsB+and+NOM+Cloud+Deployments+Version+Tracking
+	- APM Cloud Farm List: https://confluence.opentext.com/display/ICSD/ITOM+APM+AppPluse+Cloud+Farm+Information
+- ITOM Cloud FinOps
+	- BI Reporting: https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/1a3fceca-6563-4cc6-8218-d1d27f15e2f1/ReportSection?experience=power-bi
+	- Opentext FinOps Team AWS FinOps Dashboard
+### Session 2
+- ITOM Cloud Application Version Currency
+	- Upgrade Plan 
+		- ESM/FebRAMP Ops Change Calendar
+		- OpsB/NOM Ops Change Calendar
+		- Upgrade Plan Timeline 
+
+### Session 3
+
+### Session 4
+
+### Session 5
+
+### Session 6
+
+### Session 7
+
+### Session 8

Archived/Work/Cloud Service “Bilities”.md

@@ -1,66 +1,66 @@
----
-title: Cloud Service “Bilities”
-source:
-author: shenwei
-published: 2025-03-01
-created: 2025-03-01
-description:
-tags: []
-link:
----
-
-
-# Cloud Service “Bilities”
-
-**The "bilities"**
-
-In heritage OpenText Architecture we are constantly chasing how to meet what we lovingly call the "bilities".  Here is a list of the "bilities"
-
-Below are the primary capability requirements of any application to be operated by OT Commercial Cloud Service Delivery.  Some are absolute requirements, others add to the stability, performance and customer experience of the service.
-
-These define the “What” not the “How” of either the application or the infrastructure.
-
-**Recoverability** – Capability of an application to recover to a normal processing disposition as soon as a deviation from normal processing is detected either internal to the application or through external monitoring.  Recoverability includes not only restarting but restarting processing where it was last interrupted.
-
-**Usability** – All applications in a processing community are interacted with in a common and predictable manner, both from the administration side and the consumer side.  Standards in usability across applications supports efficient usage across those applications.
-
-**Operability** – Capability of an application component to be started, stopped, updated, diagnosed and deployed in a standard and predictable way.
-
-**Maintainability** – Capability of an application component to be updated, patched or functions changed in a standard and predictable manner.  Maintainability requires backward compatibility through 2 or more releases to enable maintenance activities to occur online.
-
-**Securability** – Capability of an application component to protect its assets and customer payload from unauthorized access.    Additionally, a capability to enforce access control rules based upon approved role.
-
-**Persistability** – Capability of an application to always persist payload data once it has entered the OT processing environment.  That data must exist and be accessible through maintenance, defect, application outage and normal processing.  Persistence should last the entirety of the payloads expected processing lifecycle from entrance to the environment through historical archive expiration. Persistence will accommodate global processing and Disaster Recovery requirements where applicable.
-
-**Mobility** – Capability of an application to survive infrastructure actions to support moving service components through In-center High Availability, Intra-center Geographic relocation and Intra-service Private to Public Cloud relocation.
-
-**Throttleability** – Capability of an application to control the processing rate through each component or service.  This key capability of each application component enables the operators of the service to isolate and maintain control of recovery to normal processing flow.
-
-**Deployability** – Capability of an application component to be maintained without downtime to the solution as a whole.  Maintenance, wherever possible, needs to take place without externally identifiable service interruption.
-
-**Reliability** – Capability of an application component or collection of components to with a high degree of consistency perform its defined function through both normal and abnormal operating conditions.  Reliability requires that the application component be able to perform its defined work through outage.
-
-**Reusability** – Capability of application service to perform for more than one service consumer.  Build once, use many in a common and consistent way.
-
-**Accountability/Billability** – Capability of an application to accurately report its usage by customer tenant for financial accounting purposes.
-
-**Durability**–Capability of an application to survive deviation from normal operating conditions.
-
-**Troubleshootability** – Capability to provide clear output to logging systems about all application components health and disposition during both normal and abnormal operating conditions.
-
-**Defensibility** – Capability and awareness of the application to defend itself against incorrect usage.  Both accidental and purposeful.
-
-**Extensibility** – An upfront design capability that takes into consideration the applications ability to expand its functions automatically in response to dynamic demand prompts.  Extensibility promotes expandability and elasticity.
-
-**Auditability** – An application needs to be deployed with capabilities and structures, and within an infrastructure design, that meet applicable external security and audit standards.
-
-**Application configurability** – All required feature and functional configuration management should be provided through a Web/API enabled interface.  No customer should need administrative access to underlying systems or infrastructure to perform customer available administrative tasks.
-
-**Observability** – Capability of an application to be deployed as an active part of an ecosystem that provides and accurate, timely, and complete indication of functional status and capacity level.
-
-**Visibility** – Provide capability to see detailed monitoring data describing the operating condition or health of the application.
-
-**Affordability** – An application needs to implement and use components and software that achieve P&L objectives and retain that position when scaled.  This includes the full range of administrative, support, and operational costs.
-
-**Adaptability** – An advanced capability of an application to be aware of processing going on around both upstream and downstream.  AI and machine learning are key to this capability.
-
+---
+title: Cloud Service “Bilities”
+source:
+author: shenwei
+published: 2025-03-01
+created: 2025-03-01
+description:
+tags: []
+link:
+---
+
+
+# Cloud Service “Bilities”
+
+**The "bilities"**
+
+In heritage OpenText Architecture we are constantly chasing how to meet what we lovingly call the "bilities".  Here is a list of the "bilities"
+
+Below are the primary capability requirements of any application to be operated by OT Commercial Cloud Service Delivery.  Some are absolute requirements, others add to the stability, performance and customer experience of the service.
+
+These define the “What” not the “How” of either the application or the infrastructure.
+
+**Recoverability** – Capability of an application to recover to a normal processing disposition as soon as a deviation from normal processing is detected either internal to the application or through external monitoring.  Recoverability includes not only restarting but restarting processing where it was last interrupted.
+
+**Usability** – All applications in a processing community are interacted with in a common and predictable manner, both from the administration side and the consumer side.  Standards in usability across applications supports efficient usage across those applications.
+
+**Operability** – Capability of an application component to be started, stopped, updated, diagnosed and deployed in a standard and predictable way.
+
+**Maintainability** – Capability of an application component to be updated, patched or functions changed in a standard and predictable manner.  Maintainability requires backward compatibility through 2 or more releases to enable maintenance activities to occur online.
+
+**Securability** – Capability of an application component to protect its assets and customer payload from unauthorized access.    Additionally, a capability to enforce access control rules based upon approved role.
+
+**Persistability** – Capability of an application to always persist payload data once it has entered the OT processing environment.  That data must exist and be accessible through maintenance, defect, application outage and normal processing.  Persistence should last the entirety of the payloads expected processing lifecycle from entrance to the environment through historical archive expiration. Persistence will accommodate global processing and Disaster Recovery requirements where applicable.
+
+**Mobility** – Capability of an application to survive infrastructure actions to support moving service components through In-center High Availability, Intra-center Geographic relocation and Intra-service Private to Public Cloud relocation.
+
+**Throttleability** – Capability of an application to control the processing rate through each component or service.  This key capability of each application component enables the operators of the service to isolate and maintain control of recovery to normal processing flow.
+
+**Deployability** – Capability of an application component to be maintained without downtime to the solution as a whole.  Maintenance, wherever possible, needs to take place without externally identifiable service interruption.
+
+**Reliability** – Capability of an application component or collection of components to with a high degree of consistency perform its defined function through both normal and abnormal operating conditions.  Reliability requires that the application component be able to perform its defined work through outage.
+
+**Reusability** – Capability of application service to perform for more than one service consumer.  Build once, use many in a common and consistent way.
+
+**Accountability/Billability** – Capability of an application to accurately report its usage by customer tenant for financial accounting purposes.
+
+**Durability**–Capability of an application to survive deviation from normal operating conditions.
+
+**Troubleshootability** – Capability to provide clear output to logging systems about all application components health and disposition during both normal and abnormal operating conditions.
+
+**Defensibility** – Capability and awareness of the application to defend itself against incorrect usage.  Both accidental and purposeful.
+
+**Extensibility** – An upfront design capability that takes into consideration the applications ability to expand its functions automatically in response to dynamic demand prompts.  Extensibility promotes expandability and elasticity.
+
+**Auditability** – An application needs to be deployed with capabilities and structures, and within an infrastructure design, that meet applicable external security and audit standards.
+
+**Application configurability** – All required feature and functional configuration management should be provided through a Web/API enabled interface.  No customer should need administrative access to underlying systems or infrastructure to perform customer available administrative tasks.
+
+**Observability** – Capability of an application to be deployed as an active part of an ecosystem that provides and accurate, timely, and complete indication of functional status and capacity level.
+
+**Visibility** – Provide capability to see detailed monitoring data describing the operating condition or health of the application.
+
+**Affordability** – An application needs to implement and use components and software that achieve P&L objectives and retain that position when scaled.  This includes the full range of administrative, support, and operational costs.
+
+**Adaptability** – An advanced capability of an application to be aware of processing going on around both upstream and downstream.  AI and machine learning are key to this capability.
+

Archived/Work/ITOM Cloud Service Review Meeting.md

@@ -1,56 +1,56 @@
----
-title: ITOM Cloud Service Review Meeting
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-# ITOM Cloud Service Review Meeting
-
-### ESM
-
-- Current Status
-   - Farm #, region,
-   - EU managed
-   - Team size
-      - Major workload
-         - Upgrade maintenance
-         - Customer Cloud Service request → Show trend
-         - Internal Cloud Service - Trial (SMAX, CMS Standalone, HCMX, ITOM Aviator), Unplanned change etc.
-         - Customer driven project - UPN change,
-         - Security
-- Recent Plan and activity
-   - Upgrade/Patch, SMAX helm transformation
-   - New farm plan
-   - ITOM Aviator productionize
-- Issues & Gap
-   - EU Ops engineer resource gap
-   - FedRAMP resource gap
-   - Product quality caused additional operation effort
-
-### Smart Observability
-
-- Current Status
-   - Instances #, customer #
-   - Team size
-      - Major workload
-         - Cloud deployment automation certification
-         - Paid customer cloud instance deployment, initial configuration
-         - Trial Instance deployment
-         - Maintain upgrade, upgrade validation
-         - Customer
-- Recent Plan and activity
-   - 24.2 Upgrade/Patch
-   - Support new product capability - AppO, CNO
-- Issues & Gap
-   - AWS Cost Control
-   - Trial Instance control
-   - NOM Ops resource gap
-   - PCS Support case
-   - RnD request cloud instance
-
-
-
+---
+title: ITOM Cloud Service Review Meeting
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+# ITOM Cloud Service Review Meeting
+
+### ESM
+
+- Current Status
+   - Farm #, region,
+   - EU managed
+   - Team size
+      - Major workload
+         - Upgrade maintenance
+         - Customer Cloud Service request → Show trend
+         - Internal Cloud Service - Trial (SMAX, CMS Standalone, HCMX, ITOM Aviator), Unplanned change etc.
+         - Customer driven project - UPN change,
+         - Security
+- Recent Plan and activity
+   - Upgrade/Patch, SMAX helm transformation
+   - New farm plan
+   - ITOM Aviator productionize
+- Issues & Gap
+   - EU Ops engineer resource gap
+   - FedRAMP resource gap
+   - Product quality caused additional operation effort
+
+### Smart Observability
+
+- Current Status
+   - Instances #, customer #
+   - Team size
+      - Major workload
+         - Cloud deployment automation certification
+         - Paid customer cloud instance deployment, initial configuration
+         - Trial Instance deployment
+         - Maintain upgrade, upgrade validation
+         - Customer
+- Recent Plan and activity
+   - 24.2 Upgrade/Patch
+   - Support new product capability - AppO, CNO
+- Issues & Gap
+   - AWS Cost Control
+   - Trial Instance control
+   - NOM Ops resource gap
+   - PCS Support case
+   - RnD request cloud instance
+
+
+

Archived/Work/Meeting Note/ESM Weekly Meeting Agenda.md

@@ -1,72 +1,72 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-### Mar 19
-- ESM 25.2 upgrade validation plan - Ting Ye 
-- ESM Change Management Process Update - Ting Ye 
-- SG Yearly DR solution to share with team - Shen Wei
-- ITOM Aviator EU32 farm construction status - Liu Yu/Adina
-- ESM US2 dev farm automation pipeline - Sunny
-- Update Incident Management Process -Shen Wei
--
-
-### Mar 13
-- Demo: New Jenkins Job to request temp BO admin user -Wenjun Sun
-- Customer case update 
-- Team Project Update:
-    - ESM Upgrade/Patch/Hotfix - Ting Ye
-    - AWS account migration to new SCP OU hierarchy - Yu Liu
-    - Terraform automation to construct new farm - Sunny Xia
-- Round table
-### Mar 3
-- Patch upgrade rollback strategy update - Shen Wei
-- Heads up about time coverage - Shen Wei
-- Ops Doc review and approve - Shen Wei
-- ESM 25.1.2 + ITOM Aviator 25.1.2 Patch upgrade plan - Shen Wei
-- ITOM Aviator (EU managed farm) budget approved, start project  Yu Liu 
-- OP BVD ILR license generation and documentation Miroslav Shindarov Yun Zhao
-- Operation Excellence Update
-    - Remove BO admin and use temp suite-admin account
-    - Grafana - AWS Cognito authentication status
-    - Terraform for ESM  
-- DevSecOps Qualys/Prisma- Yu Liu
-- New member training status update 
-- Round table
-### Feb 25
-- FedRAMP farm updates - Jeremy Thunker
-- Team project update
-    - ESM Upgrade Ting Ye
-    - AWS account migration to new SCP OU hierarchy - Yu Liu
-    - Grafana to use AWS Cognito - Shen Wei
-    - CCOE AMI adoption - Ting Ye
-    - Cost Optimization - Ling-yan Meng
-- Introduce the process how to handle security scan found issues - Shen Wei
-- Customer exit process
-### Feb 17
-- Welcome to Mericel to join ESM Cloud Ops team
-- ESM 25.1.1 patch upgrade status - Ting Ye
-- ITOM Aviator 25.1.1 upgrade status update - Yu Liu
-- Mega Audit update - Shen Wei
-- New ITOM Aviator farm (EU-managed) preparation - Yu Liu
-- SMAX helm hotfix post deployment actions - Ling-yan Meng
-- Round table update
-### Feb 12
-- ESM Cloud Service meeting schedule introduction
-- ITOM ESM Cloud Service Catalog introduction and new service approval flow
-- New Project:
-    - New ITOM Aviator Farm (EU managed)
-    - Adopt CCOE AMI images
-    - 25.2 upgrade plan
-    - New ITOM Cloud Farm Architecture
-- New member training plan
-
-I will record this meeting to ensure different time zone team member can watch the replay.
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+### Mar 19
+- ESM 25.2 upgrade validation plan - Ting Ye 
+- ESM Change Management Process Update - Ting Ye 
+- SG Yearly DR solution to share with team - Shen Wei
+- ITOM Aviator EU32 farm construction status - Liu Yu/Adina
+- ESM US2 dev farm automation pipeline - Sunny
+- Update Incident Management Process -Shen Wei
+-
+
+### Mar 13
+- Demo: New Jenkins Job to request temp BO admin user -Wenjun Sun
+- Customer case update 
+- Team Project Update:
+    - ESM Upgrade/Patch/Hotfix - Ting Ye
+    - AWS account migration to new SCP OU hierarchy - Yu Liu
+    - Terraform automation to construct new farm - Sunny Xia
+- Round table
+### Mar 3
+- Patch upgrade rollback strategy update - Shen Wei
+- Heads up about time coverage - Shen Wei
+- Ops Doc review and approve - Shen Wei
+- ESM 25.1.2 + ITOM Aviator 25.1.2 Patch upgrade plan - Shen Wei
+- ITOM Aviator (EU managed farm) budget approved, start project  Yu Liu 
+- OP BVD ILR license generation and documentation Miroslav Shindarov Yun Zhao
+- Operation Excellence Update
+    - Remove BO admin and use temp suite-admin account
+    - Grafana - AWS Cognito authentication status
+    - Terraform for ESM  
+- DevSecOps Qualys/Prisma- Yu Liu
+- New member training status update 
+- Round table
+### Feb 25
+- FedRAMP farm updates - Jeremy Thunker
+- Team project update
+    - ESM Upgrade Ting Ye
+    - AWS account migration to new SCP OU hierarchy - Yu Liu
+    - Grafana to use AWS Cognito - Shen Wei
+    - CCOE AMI adoption - Ting Ye
+    - Cost Optimization - Ling-yan Meng
+- Introduce the process how to handle security scan found issues - Shen Wei
+- Customer exit process
+### Feb 17
+- Welcome to Mericel to join ESM Cloud Ops team
+- ESM 25.1.1 patch upgrade status - Ting Ye
+- ITOM Aviator 25.1.1 upgrade status update - Yu Liu
+- Mega Audit update - Shen Wei
+- New ITOM Aviator farm (EU-managed) preparation - Yu Liu
+- SMAX helm hotfix post deployment actions - Ling-yan Meng
+- Round table update
+### Feb 12
+- ESM Cloud Service meeting schedule introduction
+- ITOM ESM Cloud Service Catalog introduction and new service approval flow
+- New Project:
+    - New ITOM Aviator Farm (EU managed)
+    - Adopt CCOE AMI images
+    - 25.2 upgrade plan
+    - New ITOM Cloud Farm Architecture
+- New member training plan
+
+I will record this meeting to ensure different time zone team member can watch the replay.
+

Archived/Work/Monthly Report/ITOM ESM Cloud Service Monthly Report - Feb 2025.md

@@ -1,164 +1,164 @@
-# ITOM ESM Cloud Service Monthly Report - Feb 2025
-
-**2025/2/1 ~ 2025/2/28**
-
-This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
----
-title: **ITOM ESM Cloud Service Monthly Report - Feb 2025**
-author: shenwei
-tags: [Cloud, Customer, Product]
----
----
-title: **ITOM ESM Cloud Service Monthly Report - Feb 2025**
-source:
-author: shenwei
-published:
-created:
-description:
-tags: [Cloud, Customer, Product]
----
-
-# Table of Content:
-- [[#Product Cloud Service|Product Cloud Service]]
-	- [[#Product Cloud Service#Planned Maintenance Window Changes|Planned Maintenance Window Changes]]
-	- [[#Product Cloud Service#Upgrade Plan|Upgrade Plan]]
-	- [[#Product Cloud Service#Unplanned Production Change|Unplanned Production Change]]
-	- [[#Product Cloud Service#Tenant Provision Services|Tenant Provision Services]]
-	- [[#Product Cloud Service#Product Trial Service|Product Trial Service]]
-- [[#Customer Cloud Service|Customer Cloud Service]]
-	- [[#Customer Cloud Service#Customer Cloud Service|Customer Cloud Service]]
-	- [[#Customer Cloud Service#Major Incident & RCA|Major Incident & RCA]]
-	- [[#Customer Cloud Service#Customer Order & Fulfillment Highlights|Customer Order & Fulfillment Highlights]]
-	- [[#Customer Cloud Service#Monthly SLA|Monthly SLA]]
-- [[#Cloud DevOps/SRE|Cloud DevOps/SRE]]
-	- [[#Cloud DevOps/SRE#ITOM Operation Platform 25.1|ITOM Operation Platform 25.1]]
-	- [[#Cloud DevOps/SRE#ESM Cloud Application WAF Enablement|ESM Cloud Application WAF Enablement]]
-	- [[#Cloud DevOps/SRE#ESM GCP onboarding|ESM GCP onboarding]]
-	- [[#Cloud DevOps/SRE#Security & Compliance|Security & Compliance]]
-	- [[#Cloud DevOps/SRE#Cloud BI Reporting|Cloud BI Reporting]]
-
----
-# Product Cloud Service
-
-## Planned Maintenance Window Changes
-
-- **ESM Standard Planned Changes**
-   - There were a total of **49** times of (SMX/CMS/OMT/OO, FedRAMP, DCA, ITOM Aviator) Upgrade/Patch/Hotfix deployments to various farms
-   - All **ESM production farms** (**EU3/US7/US2/US24/US26/US6/EU8/AP10/JP12/BR14/CA16/EU18/EU28**) were upgraded to ESM latest major version **ESM 25.1.1** by the end of Feb, 2025
--  **ITOM Operation Platform** **25.1.1** was upgraded on ESM farm (**EU3/US24/EU18**) by the end of Feb, 2025
--  **ITOM Aviator Service** (**EU30**) was already upgraded to **25.1.1** with some infra change with language model
--  All ESM Farm's **AWS EKS** version were upgraded to **1.30**
--  FedRAMP **AMI Rotation + 24.3 FP4** was done successfully in Feb maintenance window
-
-![Image](http://zipline.ishenwei.online/u/9KyDGW.png)
-![Image](http://zipline.ishenwei.online/u/u3jqNN.png)
-![Image](http://zipline.ishenwei.online/u/UQxkcZ.png)
-![Image](http://zipline.ishenwei.online/u/EA5ruD.png)
-![Image](http://zipline.ishenwei.online/u/hGHxKw.png)
----
-
-## Upgrade Plan
-
-**ESM 25.1 Upgrade Plan -  COMPLETE**
-![Image](http://zipline.ishenwei.online/u/d1OO4K.png)
-**ESM 25.2 Upgrade Plan -  IN PROGRESS**
-![Image](http://zipline.ishenwei.online/u/A4bEnW.png)
----
-## Unplanned Production Change
-
-- Total **17** Unplanned Production Changes deployed to different ESM farms in this month
-- **The number of additional unplanned change requests generated by product quality increased again this month. This needs to be taken seriously by the RnD team and analyzed after the fact to reduce similar problems and additional production changes.::**
-
-![Image](http://zipline.ishenwei.online/u/kGuobh.png)
-![Image](http://zipline.ishenwei.online/u/LnBn4Y.png)
-
-![Image](http://zipline.ishenwei.online/u/9B64zk.png)
----
-
-## Tenant Provision Services
-
-- There were a total of **28** tenant provision request fulfilled in this month.
-![Image](http://zipline.ishenwei.online/u/EJGHvv.png)
-
-![Image](http://zipline.ishenwei.online/u/mzkyBA.png)
----
-
-## Product Trial Service
-
-- There were a total of **370** product trial related service request fulfilled in this month.
-![Image](http://zipline.ishenwei.online/u/1AkGlm.png)
-![Image](http://zipline.ishenwei.online/u/UMP0Y5.png)
-![Image](http://zipline.ishenwei.online/u/j3Ap39.png)
-
-- CT Trial (External Customer SMAX Only Trial)  - **12**
-![Image](http://zipline.ishenwei.online/u/NTkk0s.png)
-
-- Internal SMAX Premium Trial - **50**
-![Image](http://zipline.ishenwei.online/u/GeXoRV.png)
-
-- HCMX Trial - **1**
-![Image](http://zipline.ishenwei.online/u/2sOhvg.png)
-
-- ESM (SMAX/AMX/CMS) Trial - **21**
-![Image](http://zipline.ishenwei.online/u/XqdzLt.png)
-
--  **ITOM Aviator Trial - 20**
-![Image](http://zipline.ishenwei.online/u/FZN250.png)
-# Customer Cloud Service
-
-## Customer Cloud Service
-
-- There were a total of **96** Customer Cloud Service Requests handled by ESM Cloud Service team in PCS
-- **Special thanks to Remi's ESM Cloud RnD team for their cooperation in handling the customer's Cloud Service Request with technical support!**
-![Image](http://zipline.ishenwei.online/u/ccwoCw.png)
-
----
-
-## Major Incident & RCA
-
-#### [2025/02/09 - US6/US2/AP10 - SMAX- Major Function Issue](https://confluence.opentext.com/pages/viewpage.action?pageId=689008569)
-
----
-## Customer Order & Fulfillment Highlights
-![Image](http://zipline.ishenwei.online/u/Wm4ACS.png)
----
-
-## Monthly SLA
-
-- **ESM SMAX has achieved all 100% SLA in Jan, 2024**
-- Data is available through **Jan 2024**, with Feb 2025 SLA data to be released around mid-March.
-
----
-
-# Cloud DevOps/SRE
-
-## ITOM Aviator (EU-Managed) Farm
-- We got final business approval to construct new **ITOM Aviator (EU-managed)** farm.
-- The project has already started and is expected to be delivered in 1 to 2 weeks
-## ITOM Operation Platform 25.1
-
-- We have successfully upgrade Operation Platform 24.4 to **25.1** on **EU3/US24/EU18** farm.
-- We're preparing the Operation Platform 25.2 cloud readiness work include to start support OpsB to use OP 25.2 in ITOM Cloud environment.
-- We are now continuing to work on the OP D2 enablement automation and the relevant operation runbook.
-## ESM Cloud Application WAF Enablement
-
-- A new DevOps project was initiated to enhance WAF rules management & cloud deployment automation
-- After some series of team efforts, it went through several processes of testing, modification, and deployment. We have now reached the criteria of **Enable WAF denied mode** with current WAF version on top of SMAX 25.1.1. 
-- We have enabled **SMAX WAF** in ‘**Denied Mode**’ on **US2** farm this Monday(Feb 24th).
-- In addition, we have enable  ‘**Observation Mode**’ on **US24** & **US26** farms to get more WAF log information to help us determine the effectiveness of blockings.
-## ESM GCP onboarding
-- Based on the business requirements, we started working with Cloud SA group and Product group on GCP onboarding for ESM. Currently, there are two main working threads which require product team support to certify ESM products deployment on GCP, and validation and experimentation for GCP OCF cloud architecture platform led by Cloud SA.
-## Operation Excellence
-- We are actively enhancing the automation of ESM farm construction, covering all configurations based on AWS services, and using OT compliance automation solutions to build cloud automation deployment for ESM Farm
-- We've implemented to use AWS Cognito authentication to control all Cloud Ops tooling. Recently we've enabled AWS Cognito authentication to access **Grafana** monitoring tool 
-## Security & Compliance
-- At the request of Opentext GIS, the ESM Cloud Service Team has installed **Qualys** and **Prisma Defender** on all ESM production farms in order to facilitate security scanning on the Cloud to provide more secure ESM SaaS services. 
-- We recently launched a new project on how to handle various OS-based security issues discovered by Qualys Scan. In conjunction with the upcoming adopt **CCOE AMI** project, we intend to centrally replace and update the existing Cloud Application's EKS worker node OS to meet higher security standards. 
-
-## Cloud Service BI Reporting
-
-- ITOM ESM Farm/Tenant Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3243d84335d863ef318a?experience=power-bi)
-- ITOM Cloud Service Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/363a8aba-6746-4468-9d5c-54e0a463b708/ReportSectionc350f5d544676dc460b4?experience=power-bi)
-
----
-
+# ITOM ESM Cloud Service Monthly Report - Feb 2025
+
+**2025/2/1 ~ 2025/2/28**
+
+This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
+---
+title: **ITOM ESM Cloud Service Monthly Report - Feb 2025**
+author: shenwei
+tags: [Cloud, Customer, Product]
+---
+---
+title: **ITOM ESM Cloud Service Monthly Report - Feb 2025**
+source:
+author: shenwei
+published:
+created:
+description:
+tags: [Cloud, Customer, Product]
+---
+
+# Table of Content:
+- [[#Product Cloud Service|Product Cloud Service]]
+	- [[#Product Cloud Service#Planned Maintenance Window Changes|Planned Maintenance Window Changes]]
+	- [[#Product Cloud Service#Upgrade Plan|Upgrade Plan]]
+	- [[#Product Cloud Service#Unplanned Production Change|Unplanned Production Change]]
+	- [[#Product Cloud Service#Tenant Provision Services|Tenant Provision Services]]
+	- [[#Product Cloud Service#Product Trial Service|Product Trial Service]]
+- [[#Customer Cloud Service|Customer Cloud Service]]
+	- [[#Customer Cloud Service#Customer Cloud Service|Customer Cloud Service]]
+	- [[#Customer Cloud Service#Major Incident & RCA|Major Incident & RCA]]
+	- [[#Customer Cloud Service#Customer Order & Fulfillment Highlights|Customer Order & Fulfillment Highlights]]
+	- [[#Customer Cloud Service#Monthly SLA|Monthly SLA]]
+- [[#Cloud DevOps/SRE|Cloud DevOps/SRE]]
+	- [[#Cloud DevOps/SRE#ITOM Operation Platform 25.1|ITOM Operation Platform 25.1]]
+	- [[#Cloud DevOps/SRE#ESM Cloud Application WAF Enablement|ESM Cloud Application WAF Enablement]]
+	- [[#Cloud DevOps/SRE#ESM GCP onboarding|ESM GCP onboarding]]
+	- [[#Cloud DevOps/SRE#Security & Compliance|Security & Compliance]]
+	- [[#Cloud DevOps/SRE#Cloud BI Reporting|Cloud BI Reporting]]
+
+---
+# Product Cloud Service
+
+## Planned Maintenance Window Changes
+
+- **ESM Standard Planned Changes**
+   - There were a total of **49** times of (SMX/CMS/OMT/OO, FedRAMP, DCA, ITOM Aviator) Upgrade/Patch/Hotfix deployments to various farms
+   - All **ESM production farms** (**EU3/US7/US2/US24/US26/US6/EU8/AP10/JP12/BR14/CA16/EU18/EU28**) were upgraded to ESM latest major version **ESM 25.1.1** by the end of Feb, 2025
+-  **ITOM Operation Platform** **25.1.1** was upgraded on ESM farm (**EU3/US24/EU18**) by the end of Feb, 2025
+-  **ITOM Aviator Service** (**EU30**) was already upgraded to **25.1.1** with some infra change with language model
+-  All ESM Farm's **AWS EKS** version were upgraded to **1.30**
+-  FedRAMP **AMI Rotation + 24.3 FP4** was done successfully in Feb maintenance window
+
+![Image](http://zipline.ishenwei.online/u/9KyDGW.png)
+![Image](http://zipline.ishenwei.online/u/u3jqNN.png)
+![Image](http://zipline.ishenwei.online/u/UQxkcZ.png)
+![Image](http://zipline.ishenwei.online/u/EA5ruD.png)
+![Image](http://zipline.ishenwei.online/u/hGHxKw.png)
+---
+
+## Upgrade Plan
+
+**ESM 25.1 Upgrade Plan -  COMPLETE**
+![Image](http://zipline.ishenwei.online/u/d1OO4K.png)
+**ESM 25.2 Upgrade Plan -  IN PROGRESS**
+![Image](http://zipline.ishenwei.online/u/A4bEnW.png)
+---
+## Unplanned Production Change
+
+- Total **17** Unplanned Production Changes deployed to different ESM farms in this month
+- **The number of additional unplanned change requests generated by product quality increased again this month. This needs to be taken seriously by the RnD team and analyzed after the fact to reduce similar problems and additional production changes.::**
+
+![Image](http://zipline.ishenwei.online/u/kGuobh.png)
+![Image](http://zipline.ishenwei.online/u/LnBn4Y.png)
+
+![Image](http://zipline.ishenwei.online/u/9B64zk.png)
+---
+
+## Tenant Provision Services
+
+- There were a total of **28** tenant provision request fulfilled in this month.
+![Image](http://zipline.ishenwei.online/u/EJGHvv.png)
+
+![Image](http://zipline.ishenwei.online/u/mzkyBA.png)
+---
+
+## Product Trial Service
+
+- There were a total of **370** product trial related service request fulfilled in this month.
+![Image](http://zipline.ishenwei.online/u/1AkGlm.png)
+![Image](http://zipline.ishenwei.online/u/UMP0Y5.png)
+![Image](http://zipline.ishenwei.online/u/j3Ap39.png)
+
+- CT Trial (External Customer SMAX Only Trial)  - **12**
+![Image](http://zipline.ishenwei.online/u/NTkk0s.png)
+
+- Internal SMAX Premium Trial - **50**
+![Image](http://zipline.ishenwei.online/u/GeXoRV.png)
+
+- HCMX Trial - **1**
+![Image](http://zipline.ishenwei.online/u/2sOhvg.png)
+
+- ESM (SMAX/AMX/CMS) Trial - **21**
+![Image](http://zipline.ishenwei.online/u/XqdzLt.png)
+
+-  **ITOM Aviator Trial - 20**
+![Image](http://zipline.ishenwei.online/u/FZN250.png)
+# Customer Cloud Service
+
+## Customer Cloud Service
+
+- There were a total of **96** Customer Cloud Service Requests handled by ESM Cloud Service team in PCS
+- **Special thanks to Remi's ESM Cloud RnD team for their cooperation in handling the customer's Cloud Service Request with technical support!**
+![Image](http://zipline.ishenwei.online/u/ccwoCw.png)
+
+---
+
+## Major Incident & RCA
+
+#### [2025/02/09 - US6/US2/AP10 - SMAX- Major Function Issue](https://confluence.opentext.com/pages/viewpage.action?pageId=689008569)
+
+---
+## Customer Order & Fulfillment Highlights
+![Image](http://zipline.ishenwei.online/u/Wm4ACS.png)
+---
+
+## Monthly SLA
+
+- **ESM SMAX has achieved all 100% SLA in Jan, 2024**
+- Data is available through **Jan 2024**, with Feb 2025 SLA data to be released around mid-March.
+
+---
+
+# Cloud DevOps/SRE
+
+## ITOM Aviator (EU-Managed) Farm
+- We got final business approval to construct new **ITOM Aviator (EU-managed)** farm.
+- The project has already started and is expected to be delivered in 1 to 2 weeks
+## ITOM Operation Platform 25.1
+
+- We have successfully upgrade Operation Platform 24.4 to **25.1** on **EU3/US24/EU18** farm.
+- We're preparing the Operation Platform 25.2 cloud readiness work include to start support OpsB to use OP 25.2 in ITOM Cloud environment.
+- We are now continuing to work on the OP D2 enablement automation and the relevant operation runbook.
+## ESM Cloud Application WAF Enablement
+
+- A new DevOps project was initiated to enhance WAF rules management & cloud deployment automation
+- After some series of team efforts, it went through several processes of testing, modification, and deployment. We have now reached the criteria of **Enable WAF denied mode** with current WAF version on top of SMAX 25.1.1. 
+- We have enabled **SMAX WAF** in ‘**Denied Mode**’ on **US2** farm this Monday(Feb 24th).
+- In addition, we have enable  ‘**Observation Mode**’ on **US24** & **US26** farms to get more WAF log information to help us determine the effectiveness of blockings.
+## ESM GCP onboarding
+- Based on the business requirements, we started working with Cloud SA group and Product group on GCP onboarding for ESM. Currently, there are two main working threads which require product team support to certify ESM products deployment on GCP, and validation and experimentation for GCP OCF cloud architecture platform led by Cloud SA.
+## Operation Excellence
+- We are actively enhancing the automation of ESM farm construction, covering all configurations based on AWS services, and using OT compliance automation solutions to build cloud automation deployment for ESM Farm
+- We've implemented to use AWS Cognito authentication to control all Cloud Ops tooling. Recently we've enabled AWS Cognito authentication to access **Grafana** monitoring tool 
+## Security & Compliance
+- At the request of Opentext GIS, the ESM Cloud Service Team has installed **Qualys** and **Prisma Defender** on all ESM production farms in order to facilitate security scanning on the Cloud to provide more secure ESM SaaS services. 
+- We recently launched a new project on how to handle various OS-based security issues discovered by Qualys Scan. In conjunction with the upcoming adopt **CCOE AMI** project, we intend to centrally replace and update the existing Cloud Application's EKS worker node OS to meet higher security standards. 
+
+## Cloud Service BI Reporting
+
+- ITOM ESM Farm/Tenant Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3243d84335d863ef318a?experience=power-bi)
+- ITOM Cloud Service Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/363a8aba-6746-4468-9d5c-54e0a463b708/ReportSectionc350f5d544676dc460b4?experience=power-bi)
+
+---
+

Archived/Work/Monthly Report/ITOM ESM Cloud Service Monthly Report - Jan 2025.md

@@ -1,200 +1,200 @@
----
-title: ITOM ESM Cloud Service Monthly Report - Jan 2025
-source:
-author: shenwei
-published:
-created: 2025-03-02
-description: This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
-tags:
-  - Cloud
-  - Customer
-  - Product
----
-
-
-# **ITOM ESM Cloud Service Monthly Report - Jan 2025**
-
-**2025/1/1 ~ 2025/1/31**
-
-This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
-
-# Table of Content:
-- [[#Product Cloud Service|Product Cloud Service]]
-	- [[#Product Cloud Service#Planned Maintenance Window Changes|Planned Maintenance Window Changes]]
-	- [[#Product Cloud Service#Upgrade Plan|Upgrade Plan]]
-	- [[#Product Cloud Service#Unplanned Production Change|Unplanned Production Change]]
-	- [[#Product Cloud Service#Tenant Provision Services|Tenant Provision Services]]
-	- [[#Product Cloud Service#Product Trial Service|Product Trial Service]]
-- [[#Customer Cloud Service|Customer Cloud Service]]
-	- [[#Customer Cloud Service#Customer Cloud Service|Customer Cloud Service]]
-	- [[#Customer Cloud Service#Major Incident & RCA|Major Incident & RCA]]
-	- [[#Customer Cloud Service#Customer Order & Fulfillment Highlights|Customer Order & Fulfillment Highlights]]
-	- [[#Customer Cloud Service#Monthly SLA|Monthly SLA]]
-- [[#Cloud DevOps/SRE|Cloud DevOps/SRE]]
-	- [[#Cloud DevOps/SRE#ITOM Operation Platform 25.1|ITOM Operation Platform 25.1]]
-	- [[#Cloud DevOps/SRE#ESM Cloud Application WAF Enablement|ESM Cloud Application WAF Enablement]]
-	- [[#Cloud DevOps/SRE#ESM GCP onboarding|ESM GCP onboarding]]
-	- [[#Cloud DevOps/SRE#Security & Compliance|Security & Compliance]]
-	- [[#Cloud DevOps/SRE#Cloud BI Reporting|Cloud BI Reporting]]
-
----
-
-# Product Cloud Service
-
-## Planned Maintenance Window Changes
-
-- **ESM Standard Planned Changes**
-   - There were a total of **::22::** times of (SMX/CMS/OMT/OO, FedRAMP, DCA, ITOM Aviator) Upgrade/Patch/Hotfix deployments to various farms
-   - **ESM farms** (**::EU3/US7/US2/US24/US26::**) were upgraded to ESM latest major version **::ESM 25.1::** by the end of Jan, 2025
--  **ITOM Operation Platform** **::25.1::** was upgraded on ESM farm (**::EU3/US24::**) by the end of Jan, 2025
--  **ITOM Aviator Service** (**::EU30::**) was already upgraded to **::25.1::**
--  All ESM Farm's **AWS EKS** version were upgraded to **::1.30::**
--  FedRAMP **::AMI Rotation::** + **::RDS 15.4 +EKS Upgrade::** was done successfully in Jan maintenance window
-
-![image.png](http://zipline.ishenwei.online/u/TpWM1Z.png)
-
-![image.png](http://zipline.ishenwei.online/u/iJ088Q.png)
-
-![image.png](http://zipline.ishenwei.online/u/WGaKk4.png)
-
-![image.png](http://zipline.ishenwei.online/u/OYABda.png)
-
----
-
-## Upgrade Plan
-
-**ESM 25.1 Upgrade Plan -  ::IN PROGRESS::**
-
-![image.png](http://zipline.ishenwei.online/u/TgTE2M.png)
-
----
-## Unplanned Production Change
-
-- > Total **::26::** Unplanned Production Changes deployed to different ESM farms in this month
-- > **::The number of additional unplanned change requests generated by product quality increased again this month. This needs to be taken seriously by the RnD team and analyzed after the fact to reduce similar problems and additional production changes.::**
-
-![image.png](http://zipline.ishenwei.online/u/xXKQR1.png)
-
-![image.png](http://zipline.ishenwei.online/u/WLQ91Z.png)
-
-![image.png](http://zipline.ishenwei.online/u/cDcHDT.png)
-
----
-
-## Tenant Provision Services
-
-- > There were a total of **::17::** tenant provision request fulfilled in this month.
-
-![image.png](http://zipline.ishenwei.online/u/Tu7f0F.png)
-
-![image.png](http://zipline.ishenwei.online/u/9dqHZ3.png)
-
----
-
-## Product Trial Service
-
-- > There were a total of **::252::** product trial related service request fulfilled in this month.
-
-![image.png](http://zipline.ishenwei.online/u/S5UkaH.png)
-
-![image.png](http://zipline.ishenwei.online/u/LcnjR3.png)
-
-![image.png](http://zipline.ishenwei.online/u/S0hBGT.png)
-
-- > CT Trial (External Customer SMAX Only Trial)  - 12
-
-![image.png](http://zipline.ishenwei.online/u/DiZRD1.png)
-
-- > Internal SMAX Premium Trial - 58
-
-![image.png](http://zipline.ishenwei.online/u/UBvgzB.png)
-
-- > HCMX Trial - 1
-
-![image.png](http://zipline.ishenwei.online/u/VADMwI.png)
-
-- > ESM (SMAX/AMX/CMS) Trial - 8
-
-![image.png](http://zipline.ishenwei.online/u/2SCiiC.png)
-
-- > **::ITOM Aviator Trial - 14::**
-
-![image.png](http://zipline.ishenwei.online/u/BXkHWQ.png)
-
----
-
-# Customer Cloud Service
-
-## Customer Cloud Service
-
-- > There were a total of **::84::** Customer Cloud Service Requests handled by ESM Cloud Service team in PCS
-- > **::Special thanks to Remi's ESM Cloud RnD team for their cooperation in handling the customer's Cloud Service Request with technical support and staff coverage!::**
-
-
-
-![image.png](http://zipline.ishenwei.online/u/eYDiqG.png)
-
-![image.png](http://zipline.ishenwei.online/u/PPGtAi.png)
-
----
-
-## Major Incident & RCA
-
-> No major incident in Jan, 2025
-
-
-
-
-
-
-
----
-## Customer Order & Fulfillment Highlights
-
-![image.png](http://zipline.ishenwei.online/u/AqlcoY.png)
-
----
-
-## Monthly SLA
-
-- > **::ESM SMAX has achieved all 100% SLA in Dec, 2024::**
-- > Data is available through **Dec, 2024**, with Jan, 2025 SLA data to be released around mid-Feb.
-
-![http://zipline.ishenwei.online/u/HYziL8.png](http://zipline.ishenwei.online/u/HYziL8.png)
-
-![image.png](http://zipline.ishenwei.online/u/CxrtGV.png)
-
----
-
-# Cloud DevOps/SRE
-
-## ITOM Operation Platform 25.1
-
-- > We have successfully upgrade Operation Platform 24.4 to 25.1 on EU3/US24 farm.
-- > We're preparing the Operation Platform 25.2 cloud readiness work include to start support OpsB to use OP 25.2 in ITOM Cloud environment.
-- > We are now continuing to work on the OP D2 enablement automation and the relevant operation runbook.
-## ESM Cloud Application WAF Enablement
-
-- > After some series of team efforts, it went through several processes of testing, modification, and deployment. We have now reached the criteria of Enable WAF denied mode with current WAF version on top of SMAX 24.4.1. 
-We have enabled SMAX WAF in ‘**Denied Mode**’ on **::EU3::** and **::US7::** farm by end of Nov.
-- > In addition, we are gradually turning on ‘**Observation Mode**’ in other farms to get more WAF log information to help us determine the effectiveness of blockings.
-- > A new DevOps project was initiated to enhance WAF rules management & cloud deployment automation
-
-## ESM GCP onboarding
-
-- > Based on the business requirements, we started working with Cloud SA group and Product group on GCP onboarding for ESM. Currently, there are two main working threads which require product team support to certify ESM products deployment on GCP, and validation and experimentation for GCP OCF cloud architecture platform led by Cloud SA.
-
-## Security & Compliance
-
-- > At the request of Opentext GIS, the ESM Cloud Service Team has installed **Prisma Defender** on all ESM production farms in order to facilitate security scanning on the Cloud to provide more secure ESM SaaS services. - **::Done::**
-- > We recently launched a new project on how to handle various OS-based security issues discovered by Qualys Scan. In conjunction with the upcoming adopt CCOE AMI project, we intend to centrally replace and update the existing Cloud Application's EKS worker node OS to meet higher security standards. - **::In Progress::**
-
-## Cloud BI Reporting
-
-- > ITOM ESM Farm/Tenant Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3243d84335d863ef318a?experience=power-bi)
-- > ITOM Cloud Service Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/363a8aba-6746-4468-9d5c-54e0a463b708/ReportSectionc350f5d544676dc460b4?experience=power-bi)
-
-## 
-
----
-
+---
+title: ITOM ESM Cloud Service Monthly Report - Jan 2025
+source:
+author: shenwei
+published:
+created: 2025-03-02
+description: This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
+tags:
+  - Cloud
+  - Customer
+  - Product
+---
+
+
+# **ITOM ESM Cloud Service Monthly Report - Jan 2025**
+
+**2025/1/1 ~ 2025/1/31**
+
+This report contains the main work of the ESM Cloud Service team and shows the load of the team's work in the form of data, and describes some issues and risks for continuous improvement.
+
+# Table of Content:
+- [[#Product Cloud Service|Product Cloud Service]]
+	- [[#Product Cloud Service#Planned Maintenance Window Changes|Planned Maintenance Window Changes]]
+	- [[#Product Cloud Service#Upgrade Plan|Upgrade Plan]]
+	- [[#Product Cloud Service#Unplanned Production Change|Unplanned Production Change]]
+	- [[#Product Cloud Service#Tenant Provision Services|Tenant Provision Services]]
+	- [[#Product Cloud Service#Product Trial Service|Product Trial Service]]
+- [[#Customer Cloud Service|Customer Cloud Service]]
+	- [[#Customer Cloud Service#Customer Cloud Service|Customer Cloud Service]]
+	- [[#Customer Cloud Service#Major Incident & RCA|Major Incident & RCA]]
+	- [[#Customer Cloud Service#Customer Order & Fulfillment Highlights|Customer Order & Fulfillment Highlights]]
+	- [[#Customer Cloud Service#Monthly SLA|Monthly SLA]]
+- [[#Cloud DevOps/SRE|Cloud DevOps/SRE]]
+	- [[#Cloud DevOps/SRE#ITOM Operation Platform 25.1|ITOM Operation Platform 25.1]]
+	- [[#Cloud DevOps/SRE#ESM Cloud Application WAF Enablement|ESM Cloud Application WAF Enablement]]
+	- [[#Cloud DevOps/SRE#ESM GCP onboarding|ESM GCP onboarding]]
+	- [[#Cloud DevOps/SRE#Security & Compliance|Security & Compliance]]
+	- [[#Cloud DevOps/SRE#Cloud BI Reporting|Cloud BI Reporting]]
+
+---
+
+# Product Cloud Service
+
+## Planned Maintenance Window Changes
+
+- **ESM Standard Planned Changes**
+   - There were a total of **::22::** times of (SMX/CMS/OMT/OO, FedRAMP, DCA, ITOM Aviator) Upgrade/Patch/Hotfix deployments to various farms
+   - **ESM farms** (**::EU3/US7/US2/US24/US26::**) were upgraded to ESM latest major version **::ESM 25.1::** by the end of Jan, 2025
+-  **ITOM Operation Platform** **::25.1::** was upgraded on ESM farm (**::EU3/US24::**) by the end of Jan, 2025
+-  **ITOM Aviator Service** (**::EU30::**) was already upgraded to **::25.1::**
+-  All ESM Farm's **AWS EKS** version were upgraded to **::1.30::**
+-  FedRAMP **::AMI Rotation::** + **::RDS 15.4 +EKS Upgrade::** was done successfully in Jan maintenance window
+
+![image.png](http://zipline.ishenwei.online/u/TpWM1Z.png)
+
+![image.png](http://zipline.ishenwei.online/u/iJ088Q.png)
+
+![image.png](http://zipline.ishenwei.online/u/WGaKk4.png)
+
+![image.png](http://zipline.ishenwei.online/u/OYABda.png)
+
+---
+
+## Upgrade Plan
+
+**ESM 25.1 Upgrade Plan -  ::IN PROGRESS::**
+
+![image.png](http://zipline.ishenwei.online/u/TgTE2M.png)
+
+---
+## Unplanned Production Change
+
+- > Total **::26::** Unplanned Production Changes deployed to different ESM farms in this month
+- > **::The number of additional unplanned change requests generated by product quality increased again this month. This needs to be taken seriously by the RnD team and analyzed after the fact to reduce similar problems and additional production changes.::**
+
+![image.png](http://zipline.ishenwei.online/u/xXKQR1.png)
+
+![image.png](http://zipline.ishenwei.online/u/WLQ91Z.png)
+
+![image.png](http://zipline.ishenwei.online/u/cDcHDT.png)
+
+---
+
+## Tenant Provision Services
+
+- > There were a total of **::17::** tenant provision request fulfilled in this month.
+
+![image.png](http://zipline.ishenwei.online/u/Tu7f0F.png)
+
+![image.png](http://zipline.ishenwei.online/u/9dqHZ3.png)
+
+---
+
+## Product Trial Service
+
+- > There were a total of **::252::** product trial related service request fulfilled in this month.
+
+![image.png](http://zipline.ishenwei.online/u/S5UkaH.png)
+
+![image.png](http://zipline.ishenwei.online/u/LcnjR3.png)
+
+![image.png](http://zipline.ishenwei.online/u/S0hBGT.png)
+
+- > CT Trial (External Customer SMAX Only Trial)  - 12
+
+![image.png](http://zipline.ishenwei.online/u/DiZRD1.png)
+
+- > Internal SMAX Premium Trial - 58
+
+![image.png](http://zipline.ishenwei.online/u/UBvgzB.png)
+
+- > HCMX Trial - 1
+
+![image.png](http://zipline.ishenwei.online/u/VADMwI.png)
+
+- > ESM (SMAX/AMX/CMS) Trial - 8
+
+![image.png](http://zipline.ishenwei.online/u/2SCiiC.png)
+
+- > **::ITOM Aviator Trial - 14::**
+
+![image.png](http://zipline.ishenwei.online/u/BXkHWQ.png)
+
+---
+
+# Customer Cloud Service
+
+## Customer Cloud Service
+
+- > There were a total of **::84::** Customer Cloud Service Requests handled by ESM Cloud Service team in PCS
+- > **::Special thanks to Remi's ESM Cloud RnD team for their cooperation in handling the customer's Cloud Service Request with technical support and staff coverage!::**
+
+
+
+![image.png](http://zipline.ishenwei.online/u/eYDiqG.png)
+
+![image.png](http://zipline.ishenwei.online/u/PPGtAi.png)
+
+---
+
+## Major Incident & RCA
+
+> No major incident in Jan, 2025
+
+
+
+
+
+
+
+---
+## Customer Order & Fulfillment Highlights
+
+![image.png](http://zipline.ishenwei.online/u/AqlcoY.png)
+
+---
+
+## Monthly SLA
+
+- > **::ESM SMAX has achieved all 100% SLA in Dec, 2024::**
+- > Data is available through **Dec, 2024**, with Jan, 2025 SLA data to be released around mid-Feb.
+
+![http://zipline.ishenwei.online/u/HYziL8.png](http://zipline.ishenwei.online/u/HYziL8.png)
+
+![image.png](http://zipline.ishenwei.online/u/CxrtGV.png)
+
+---
+
+# Cloud DevOps/SRE
+
+## ITOM Operation Platform 25.1
+
+- > We have successfully upgrade Operation Platform 24.4 to 25.1 on EU3/US24 farm.
+- > We're preparing the Operation Platform 25.2 cloud readiness work include to start support OpsB to use OP 25.2 in ITOM Cloud environment.
+- > We are now continuing to work on the OP D2 enablement automation and the relevant operation runbook.
+## ESM Cloud Application WAF Enablement
+
+- > After some series of team efforts, it went through several processes of testing, modification, and deployment. We have now reached the criteria of Enable WAF denied mode with current WAF version on top of SMAX 24.4.1. 
+We have enabled SMAX WAF in ‘**Denied Mode**’ on **::EU3::** and **::US7::** farm by end of Nov.
+- > In addition, we are gradually turning on ‘**Observation Mode**’ in other farms to get more WAF log information to help us determine the effectiveness of blockings.
+- > A new DevOps project was initiated to enhance WAF rules management & cloud deployment automation
+
+## ESM GCP onboarding
+
+- > Based on the business requirements, we started working with Cloud SA group and Product group on GCP onboarding for ESM. Currently, there are two main working threads which require product team support to certify ESM products deployment on GCP, and validation and experimentation for GCP OCF cloud architecture platform led by Cloud SA.
+
+## Security & Compliance
+
+- > At the request of Opentext GIS, the ESM Cloud Service Team has installed **Prisma Defender** on all ESM production farms in order to facilitate security scanning on the Cloud to provide more secure ESM SaaS services. - **::Done::**
+- > We recently launched a new project on how to handle various OS-based security issues discovered by Qualys Scan. In conjunction with the upcoming adopt CCOE AMI project, we intend to centrally replace and update the existing Cloud Application's EKS worker node OS to meet higher security standards. - **::In Progress::**
+
+## Cloud BI Reporting
+
+- > ITOM ESM Farm/Tenant Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/cf509ffe-325f-4c1b-a507-44b93e6d85ca/ReportSection3243d84335d863ef318a?experience=power-bi)
+- > ITOM Cloud Service Summary - [BI Report Link](https://app.powerbi.com/groups/fac06a69-6340-4715-b8fe-4bdc0ca9af14/reports/363a8aba-6746-4468-9d5c-54e0a463b708/ReportSectionc350f5d544676dc460b4?experience=power-bi)
+
+## 
+
+---
+

Archived/Work/PCS Create New Customer Initial Setup Steps.md

@@ -1,200 +1,200 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-
-
-Entitlement
-
-- Create new company
-    - Customer Type: Customer
-- Add new domain name (remember to add same in PCS dev as well, for dev2prod)
-- Create new entitlement
-
-
-Add new person
-
-- Create in BO and sync back to SMAX
-- Add company
-- Add employee type - external
-- Assign people to relevant entitlement
-- Assign role
-    - Microfocus SaaS entitlement
-    - Self-Service portal app
-    - Self-Service portal user
-
-  
-PCS Administration Training
-
-  
-
-[[PCS Create New Customer Initial Setup Steps]]
-
-
-
-  
-
-KT Session #1
-
-[https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EemsG7iwZ8xCsPm5QygCoZgBIWubxMNMhbCQU4AIhUoA3A](https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EemsG7iwZ8xCsPm5QygCoZgBIWubxMNMhbCQU4AIhUoA3A)
-
-  
-
-KT Session #2
-
-[https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EXRCtXeBAXZPisy27-kVeuMBgZ_MdlyZgi-XmuXRIVseOg](https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EXRCtXeBAXZPisy27-kVeuMBgZ_MdlyZgi-XmuXRIVseOg)
-
-  
-
-**Data Model**
-
-- Data domains
-- Company
-- Entitlement
-    - ENTITY_LINK to Company
-    - ENUM to Data domains
-- Person
-    - ENTITY_LINK to Company
-    - ENTITY_LINK to Entitlement (default)
-    - MANY2MANY to Entitlement (full list)
-
-  
-
-**New Order/customer**
-
-- Validate it is indeed a real customer (have an order ID, can find it in Control Tower)
-    - Special cases for internal "customers": presales, operations, etc
-- Data domain record
-    - Very likely need to use a new "slot", unless the customer already exists
-    - Find the list, take the first entry not in use (with **ZZ-To be assigned** label)
-        - **VERY IMPORTANT: Execute the task in both Dev and Prod tenant. Make sure the Name field (key) is the same in both, otherwise Dev2Prod will have issues**
-        - The Prod tenant should be locked for customizations, you need to unlock it first. Don't forget to go back and lock it again after
-    - In rare cases, the customer may exist already if there is an entitlement for another product, in this case skip this step
-- Company/Vendor record
-    - Add a record
-    - Use the official Display Name from the order/Control Tower
-    - We started using the names in caps, as this is how Sparks had them, let's keep the rule.
-    - For Code, use the first 3-4 letters of the name, or, if the company has an acronym, you can use it
-    - Important: make sure you select **Customer** for the **Company type**.
-    - In rare cases, the customer may exist already if there is an entitlement for another product, in this case skip this step
-- Entitlement record
-    - Add a record
-    - Display label
-        - Is SaaS customer: start by short name of company, followed by product name and SaaS suffix, for example **Decathlon SMAX SaaS**
-        - If it is a "Powered by" partner, add the "Power By" suffix for the name, example **Rigosis SMAX SaaS Powered by**
-        - MF internal: Prefix with Micro Focus, no need to add SaaS suffix (it's implicit), for example **Micro Focus IT SMAX** or **Micro Focus Service Hub SMAX**.
-    - Important to fill in the correct information for the mandatory fields: Entitlement type, Product, Primary Domain, Company. Business rules use this information extensively to filter down what is available in drop down lists, decide what logic to execute
-    - For specific cases, like Achmea, if a NASE is assigned, fill in the info. Any new ticket linked to this entitlement gets automatically assigned to the person listed here
-    - Fill in the CSM info, if available. The user listed will be automatically added as follower to all Support requests and a subset of Service Requests
-    - SAID
-        - Leave empty for regular SaaS customers
-        - Fill in with the "Powered By" string for the Powered by partners
-
-  
-
-**New User**
-
-- Non Micro Focus user (aka DB user)
-    - Triggered when
-        - A new customer is onboarded, and an initial list is received from the CSM
-        - An existing user on an entitlement uses the **Add user to entitlement** offering
-    - Check the user doesn’t already exist
-        - If yes, go to the **Add user to an entitlement** section
-    - Create new record from the Person grid
-    - **VERY IMPORTANT:** Click the **Person type** checkbox, otherwise a contact gets created
-        - If you forgot, you need access to BO to create the user (with same UPN) and force a sync from the Person grid
-    - Upn: Use the email address (automatically populated with the email by default)
-    - Employment type: External
-    - Company: fill in with the relevant value
-    - **IMPORTANT:** Do not populate the **Data domains** and **Primary domain** at this point
-    - If the user is a "regular" customer user, you can fill in the **Default entitlement** value (for example, you may not want to do that if you add a partner)
-    - Once saved, go back in and populate the **Data domains** and **Primary domain**
-    - Entitlements M2M widget
-        - Unlikely to have to use it, unless it is a partner added the first time as part of a customer project. In this case the entitlement doesn't go into the default position.
-- Micro Focus users (automatically added through SAML)
-    - Periodically check if any new users got added. This can happen because someone is supposed to be added to an entitlement or is supposed to work tickets, but in many situations, users get hold of our URL and click on it for curiosity
-    - R&D or Ops teams, people who logged in because they are supposed to work tickets
-        - Check their reporting structure and make sure they are who they say they are.
-        - Configure the following
-            - Company: Micro Focus
-            - Primary domain: Micro Focus
-            - Data domains: Micro Focus
-            - Employment type: blank
-        - You can manually add them to the relevant functional group if you know which one. Alternatively, there is an offering that does that, can be called by the authorized audience (anyone with the "PCS Lead" role)
-    - PS, pre-sales, specific functions
-        - If instructed, configure profile
-            - Company: Micro Focus
-            - Primary domain: Based on the main role
-            - Data domains: Above, plus potentially others, depending on the person responsibilities
-            - Employment type: External
-        - Example, if a PS consultant is asked to work on the MF IT project, the setup will be:
-- Default entitlements/Entitlements
-    - With few exceptions (probably pre-sales), the majority of internal users needing to be added don't have a default entitlement. Add the relevant entitlement to the Entitlements M2M widget, if there is no default entitlement to be configured.
-- All other cases, not known why a user connected
-    - Park the user in a "catch all" profile
-        - Company: Micro Focus
-        - Primary domain: Customer
-        - Data domains: Customer
-        - Employment type: External
-    - If later on, the user is identified as belonging to an actual entitlement or is supposed to be an agent, apply the instructions described above
-- **IMPORTANT:** just because someone in Micro Focus asked for agent access, do not provide it, unless they are assigned to working tickets.
-    - Concrete example on when to **NOT** add someone. The user says he/she is a Premier support person or even a CSM and needs to see the tickets for their customers. The answer is to give them the **Account Viewer** role to have the information available from the portal - no need for agent access!
-
-**Modify existing user profile**
-
-- A user already exists in PCS but needs to be added to an additional entitlement
-- Typically applies to users working for partners (with multiple customers) or internal Micro Focus people (PS, presales, etc)
-- Triggered when
-    - A new customer is onboarded, and an initial list is received from the CSM
-    - An existing user on an entitlement uses the **Add user to entitlement** offering
-- Data domains: append the customer Data domain (as defined in the Entitlement)
-- Entitlements: add the new Entitlement to the M2M widget
-- Exception
-    - An internal user may already exist because they connected before and ended up "parked" in the "Customer" placeholder
-    - Remove the "Customer" Data domains/Primary domains and follow the instructions listed in the "New user" section
-
-**Remove user**
-
-- Needs to be triggered from BO, which will convert the user into a contact
-- Once a contact, change the status from **Inactive** to **Terminated**
-- Clear the **Default entitlement** value and any record from the **Entitlements** section
-
-**User Management offerings**
-
-- **Add user to entitlement** offering
-    - If the email address is not a @microfocus.com domain, follow the instructions for adding a DB user
-        - **IMPORTANT:** If the email address doesn't appear to be the company email address, it is likely the user is a partner and may need to be treated specially, by first adding a new Company record for the partner. Alternatively, we can take the approach of considering this user as part of the customer company, and only model it as belonging to a new company when there is a need to add a second entitlement linked to the user. But, if we do it at a later date, it is important to identify all the users with this email domain and move them under the newly created Company record (see **New order/customer** section for the detailed procedure)
-    - If the email address is a @microfocus.com domain, follow the instructions for configuring a SAML user.
-        - It is possible the user doesn't already exist (never logged in). In this case, ask the requester to notify the user to first login (use the Discussions tab)
-    - Once the user record got created/updated, move the **Add user** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
-    - Exceptionally, if the request is not relevant (the user already exists, the offering incorrectly used, or other reasons), process the request as below:
-        - Edit the Task plan by deleting the **Closure** task, so the request doesn't automatically close when **Add user** task gets actioned
-        - Move the **Add user** task to **Canceled**
-        - Manually add a **Solution** (explain why the request is not relevant) and Completion code (usually **Out of scope**)
-- **Remove user from entitlement** offering
-    - Tip: From the **User** user option, navigate to the Person record.
-    - If the user is part of multiple entitlements (like a partner, PS), just remove the relevant **Entitlement** reference from the Person record
-    - If the user is part of one entitlement (usually for a regular customer user), follow the procedure described in the **Remove user** section
-    - Once the relevant action above is completed, move the **Remove user** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
-- **Reset user password** offering
-    - Tip: From the **User** user option, navigate to the Person record.
-    - Click on the **Reset password** button. Wait for the confirmation message at the top of the screen that the email notification got sent
-    - Once the relevant action above is completed, move the **Reset password** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
-
-**Process**
-
-- Monitor the "admin" Request queue
-    - Go to the Active Admin Cases" view. Make sure you don't make any changes to the view definition. If you like to use a different view, create a private one for yourself
-    - Add more people to the Admin group
-    - Only **Add user to entitlement**, **Remove user from entitlement, Reset user password** require intervention, the others have automated fulfillment (may require approval)
-    - See the **User Management offerings** section for instructions for processing each offering
-- Monitor the Person grid for newly created SAML users
-    
-    - Use the **Users Pending Processing** view. Make sure you don't make any changes to the view definition. If you like to use a different view, create a private one for yourself. Also, don't modify the other public views
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+
+
+Entitlement
+
+- Create new company
+    - Customer Type: Customer
+- Add new domain name (remember to add same in PCS dev as well, for dev2prod)
+- Create new entitlement
+
+
+Add new person
+
+- Create in BO and sync back to SMAX
+- Add company
+- Add employee type - external
+- Assign people to relevant entitlement
+- Assign role
+    - Microfocus SaaS entitlement
+    - Self-Service portal app
+    - Self-Service portal user
+
+  
+PCS Administration Training
+
+  
+
+[[PCS Create New Customer Initial Setup Steps]]
+
+
+
+  
+
+KT Session #1
+
+[https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EemsG7iwZ8xCsPm5QygCoZgBIWubxMNMhbCQU4AIhUoA3A](https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EemsG7iwZ8xCsPm5QygCoZgBIWubxMNMhbCQU4AIhUoA3A)
+
+  
+
+KT Session #2
+
+[https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EXRCtXeBAXZPisy27-kVeuMBgZ_MdlyZgi-XmuXRIVseOg](https://microfocusinternational-my.sharepoint.com/:v:/g/personal/brindusa_kevorkian_microfocus_com/EXRCtXeBAXZPisy27-kVeuMBgZ_MdlyZgi-XmuXRIVseOg)
+
+  
+
+**Data Model**
+
+- Data domains
+- Company
+- Entitlement
+    - ENTITY_LINK to Company
+    - ENUM to Data domains
+- Person
+    - ENTITY_LINK to Company
+    - ENTITY_LINK to Entitlement (default)
+    - MANY2MANY to Entitlement (full list)
+
+  
+
+**New Order/customer**
+
+- Validate it is indeed a real customer (have an order ID, can find it in Control Tower)
+    - Special cases for internal "customers": presales, operations, etc
+- Data domain record
+    - Very likely need to use a new "slot", unless the customer already exists
+    - Find the list, take the first entry not in use (with **ZZ-To be assigned** label)
+        - **VERY IMPORTANT: Execute the task in both Dev and Prod tenant. Make sure the Name field (key) is the same in both, otherwise Dev2Prod will have issues**
+        - The Prod tenant should be locked for customizations, you need to unlock it first. Don't forget to go back and lock it again after
+    - In rare cases, the customer may exist already if there is an entitlement for another product, in this case skip this step
+- Company/Vendor record
+    - Add a record
+    - Use the official Display Name from the order/Control Tower
+    - We started using the names in caps, as this is how Sparks had them, let's keep the rule.
+    - For Code, use the first 3-4 letters of the name, or, if the company has an acronym, you can use it
+    - Important: make sure you select **Customer** for the **Company type**.
+    - In rare cases, the customer may exist already if there is an entitlement for another product, in this case skip this step
+- Entitlement record
+    - Add a record
+    - Display label
+        - Is SaaS customer: start by short name of company, followed by product name and SaaS suffix, for example **Decathlon SMAX SaaS**
+        - If it is a "Powered by" partner, add the "Power By" suffix for the name, example **Rigosis SMAX SaaS Powered by**
+        - MF internal: Prefix with Micro Focus, no need to add SaaS suffix (it's implicit), for example **Micro Focus IT SMAX** or **Micro Focus Service Hub SMAX**.
+    - Important to fill in the correct information for the mandatory fields: Entitlement type, Product, Primary Domain, Company. Business rules use this information extensively to filter down what is available in drop down lists, decide what logic to execute
+    - For specific cases, like Achmea, if a NASE is assigned, fill in the info. Any new ticket linked to this entitlement gets automatically assigned to the person listed here
+    - Fill in the CSM info, if available. The user listed will be automatically added as follower to all Support requests and a subset of Service Requests
+    - SAID
+        - Leave empty for regular SaaS customers
+        - Fill in with the "Powered By" string for the Powered by partners
+
+  
+
+**New User**
+
+- Non Micro Focus user (aka DB user)
+    - Triggered when
+        - A new customer is onboarded, and an initial list is received from the CSM
+        - An existing user on an entitlement uses the **Add user to entitlement** offering
+    - Check the user doesn’t already exist
+        - If yes, go to the **Add user to an entitlement** section
+    - Create new record from the Person grid
+    - **VERY IMPORTANT:** Click the **Person type** checkbox, otherwise a contact gets created
+        - If you forgot, you need access to BO to create the user (with same UPN) and force a sync from the Person grid
+    - Upn: Use the email address (automatically populated with the email by default)
+    - Employment type: External
+    - Company: fill in with the relevant value
+    - **IMPORTANT:** Do not populate the **Data domains** and **Primary domain** at this point
+    - If the user is a "regular" customer user, you can fill in the **Default entitlement** value (for example, you may not want to do that if you add a partner)
+    - Once saved, go back in and populate the **Data domains** and **Primary domain**
+    - Entitlements M2M widget
+        - Unlikely to have to use it, unless it is a partner added the first time as part of a customer project. In this case the entitlement doesn't go into the default position.
+- Micro Focus users (automatically added through SAML)
+    - Periodically check if any new users got added. This can happen because someone is supposed to be added to an entitlement or is supposed to work tickets, but in many situations, users get hold of our URL and click on it for curiosity
+    - R&D or Ops teams, people who logged in because they are supposed to work tickets
+        - Check their reporting structure and make sure they are who they say they are.
+        - Configure the following
+            - Company: Micro Focus
+            - Primary domain: Micro Focus
+            - Data domains: Micro Focus
+            - Employment type: blank
+        - You can manually add them to the relevant functional group if you know which one. Alternatively, there is an offering that does that, can be called by the authorized audience (anyone with the "PCS Lead" role)
+    - PS, pre-sales, specific functions
+        - If instructed, configure profile
+            - Company: Micro Focus
+            - Primary domain: Based on the main role
+            - Data domains: Above, plus potentially others, depending on the person responsibilities
+            - Employment type: External
+        - Example, if a PS consultant is asked to work on the MF IT project, the setup will be:
+- Default entitlements/Entitlements
+    - With few exceptions (probably pre-sales), the majority of internal users needing to be added don't have a default entitlement. Add the relevant entitlement to the Entitlements M2M widget, if there is no default entitlement to be configured.
+- All other cases, not known why a user connected
+    - Park the user in a "catch all" profile
+        - Company: Micro Focus
+        - Primary domain: Customer
+        - Data domains: Customer
+        - Employment type: External
+    - If later on, the user is identified as belonging to an actual entitlement or is supposed to be an agent, apply the instructions described above
+- **IMPORTANT:** just because someone in Micro Focus asked for agent access, do not provide it, unless they are assigned to working tickets.
+    - Concrete example on when to **NOT** add someone. The user says he/she is a Premier support person or even a CSM and needs to see the tickets for their customers. The answer is to give them the **Account Viewer** role to have the information available from the portal - no need for agent access!
+
+**Modify existing user profile**
+
+- A user already exists in PCS but needs to be added to an additional entitlement
+- Typically applies to users working for partners (with multiple customers) or internal Micro Focus people (PS, presales, etc)
+- Triggered when
+    - A new customer is onboarded, and an initial list is received from the CSM
+    - An existing user on an entitlement uses the **Add user to entitlement** offering
+- Data domains: append the customer Data domain (as defined in the Entitlement)
+- Entitlements: add the new Entitlement to the M2M widget
+- Exception
+    - An internal user may already exist because they connected before and ended up "parked" in the "Customer" placeholder
+    - Remove the "Customer" Data domains/Primary domains and follow the instructions listed in the "New user" section
+
+**Remove user**
+
+- Needs to be triggered from BO, which will convert the user into a contact
+- Once a contact, change the status from **Inactive** to **Terminated**
+- Clear the **Default entitlement** value and any record from the **Entitlements** section
+
+**User Management offerings**
+
+- **Add user to entitlement** offering
+    - If the email address is not a @microfocus.com domain, follow the instructions for adding a DB user
+        - **IMPORTANT:** If the email address doesn't appear to be the company email address, it is likely the user is a partner and may need to be treated specially, by first adding a new Company record for the partner. Alternatively, we can take the approach of considering this user as part of the customer company, and only model it as belonging to a new company when there is a need to add a second entitlement linked to the user. But, if we do it at a later date, it is important to identify all the users with this email domain and move them under the newly created Company record (see **New order/customer** section for the detailed procedure)
+    - If the email address is a @microfocus.com domain, follow the instructions for configuring a SAML user.
+        - It is possible the user doesn't already exist (never logged in). In this case, ask the requester to notify the user to first login (use the Discussions tab)
+    - Once the user record got created/updated, move the **Add user** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
+    - Exceptionally, if the request is not relevant (the user already exists, the offering incorrectly used, or other reasons), process the request as below:
+        - Edit the Task plan by deleting the **Closure** task, so the request doesn't automatically close when **Add user** task gets actioned
+        - Move the **Add user** task to **Canceled**
+        - Manually add a **Solution** (explain why the request is not relevant) and Completion code (usually **Out of scope**)
+- **Remove user from entitlement** offering
+    - Tip: From the **User** user option, navigate to the Person record.
+    - If the user is part of multiple entitlements (like a partner, PS), just remove the relevant **Entitlement** reference from the Person record
+    - If the user is part of one entitlement (usually for a regular customer user), follow the procedure described in the **Remove user** section
+    - Once the relevant action above is completed, move the **Remove user** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
+- **Reset user password** offering
+    - Tip: From the **User** user option, navigate to the Person record.
+    - Click on the **Reset password** button. Wait for the confirmation message at the top of the screen that the email notification got sent
+    - Once the relevant action above is completed, move the **Reset password** task to **Validate** phase. The request should automatically close, there is no need for interaction with the requester.
+
+**Process**
+
+- Monitor the "admin" Request queue
+    - Go to the Active Admin Cases" view. Make sure you don't make any changes to the view definition. If you like to use a different view, create a private one for yourself
+    - Add more people to the Admin group
+    - Only **Add user to entitlement**, **Remove user from entitlement, Reset user password** require intervention, the others have automated fulfillment (may require approval)
+    - See the **User Management offerings** section for instructions for processing each offering
+- Monitor the Person grid for newly created SAML users
+    
+    - Use the **Users Pending Processing** view. Make sure you don't make any changes to the view definition. If you like to use a different view, create a private one for yourself. Also, don't modify the other public views
     - Follow the instructions in the **New User** section

Archived/Work/People Manager/FY24 Goals - Shen Wei.md

@@ -1,23 +1,23 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-  
-
-I'm a senior manager responsible for SaaS operations and maintenance for cloud products in a global enterprise software company. I manage a global cloud operations team of 20+ people. The team is a global team covering different time zones. Our team is also responsible for interfacing with the product RnD team to understand requirements and communicate with them. I am designing myself and my team's goals from the below perspective: Leadership Activities, service delivery quality, Process Standardization, Operational Excellence, and Satisfy customers. could you please prepare a draft for me with efforts detail, and measurable KPIs for the above areas.
-
-  
-
-|   |   |   |   |   |
-|---|---|---|---|---|
-|**Leadership Activities**​|• Conduct regular team meetings and one-on-one sessions to provide guidance, support, and alignment.​  <br>•  <br>Act as a liaison between the cloud service team and ITOM organization, ensuring effective communication and collaboration.​  <br>•  <br>Participate in the hiring process for new team members, ensuring the selection of qualified candidates who align with the team's goals and culture.​  <br>•  <br>Foster a positive work environment conducive to productivity, innovation, and growth.​|• Executive Dashboard: Implement an executive monthly report to track and communicate Cloud Service team key metrics and performance indicators.​  <br>•  <br>100% Participation in Team meetings​  <br>•  <br>100% Compliance in accordance with local legislation​|||
-|**Service Delivery Quality**​|• Drive efficiencies and optimizations to deliver services in the most economical manner.​  <br>• Manage resource allocations effectively to meet business demands and maintain service levels.​  <br>• Continue to optimize cost structures across cloud and corporate services while maintaining service quality.​|• On-time Project Completion: 90%​  <br>•  <br>Ensure 100% compliance with local legislation and industry regulations relevant to cloud operations​  <br>•  <br>​|||
-|**Process Standardization**​|• Focus on standardization and modernization of processes, adopting best practices and industry standards such as ITIL.​  <br>•  <br>Support initiatives to consolidate/migrate customers to cloud platforms, with a focus on shared environments where feasible.​  <br>•  <br>Minimize process gaps and ensure zero deviations from defined processes.​  <br>•  <br>Conduct quarterly reviews of documentation to ensure accuracy, relevance, and completeness.​  <br>•  <br>​|• Zero process gaps ​  <br>•  <br>Quarterly review of process documentation​  <br>  <br>​|||
-|**Operational Excellence**​|• Aim for 90% of projects to be completed on time, ensuring timely delivery of services and solutions.​  <br>•  <br>Continuously identify and implement improvements to existing processes and deliverables, enhancing operational efficiency and effectiveness.​  <br>•  <br>Actively participate in the adoption of new features, technologies, and cloud solutions to improve operational capabilities.​  <br>•  <br>Document and analyze lessons learned from project executions, incorporating feedback to drive continuous improvement.​  <br>•  <br>​|​  <br>•  <br>60% of Project Completion within 3 months​  <br>•  <br>100% Security Compliance​  <br>•  <br>Expense Reduction Targets: Meet defined FY targets communicated by FinOps​  <br>•  <br>Adoption of New Technologies: Regularly adopt new features/technologies to enhance operational capabilities​  <br>  <br>​  <br>  <br>​|||
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+  
+
+I'm a senior manager responsible for SaaS operations and maintenance for cloud products in a global enterprise software company. I manage a global cloud operations team of 20+ people. The team is a global team covering different time zones. Our team is also responsible for interfacing with the product RnD team to understand requirements and communicate with them. I am designing myself and my team's goals from the below perspective: Leadership Activities, service delivery quality, Process Standardization, Operational Excellence, and Satisfy customers. could you please prepare a draft for me with efforts detail, and measurable KPIs for the above areas.
+
+  
+
+|   |   |   |   |   |
+|---|---|---|---|---|
+|**Leadership Activities**​|• Conduct regular team meetings and one-on-one sessions to provide guidance, support, and alignment.​  <br>•  <br>Act as a liaison between the cloud service team and ITOM organization, ensuring effective communication and collaboration.​  <br>•  <br>Participate in the hiring process for new team members, ensuring the selection of qualified candidates who align with the team's goals and culture.​  <br>•  <br>Foster a positive work environment conducive to productivity, innovation, and growth.​|• Executive Dashboard: Implement an executive monthly report to track and communicate Cloud Service team key metrics and performance indicators.​  <br>•  <br>100% Participation in Team meetings​  <br>•  <br>100% Compliance in accordance with local legislation​|||
+|**Service Delivery Quality**​|• Drive efficiencies and optimizations to deliver services in the most economical manner.​  <br>• Manage resource allocations effectively to meet business demands and maintain service levels.​  <br>• Continue to optimize cost structures across cloud and corporate services while maintaining service quality.​|• On-time Project Completion: 90%​  <br>•  <br>Ensure 100% compliance with local legislation and industry regulations relevant to cloud operations​  <br>•  <br>​|||
+|**Process Standardization**​|• Focus on standardization and modernization of processes, adopting best practices and industry standards such as ITIL.​  <br>•  <br>Support initiatives to consolidate/migrate customers to cloud platforms, with a focus on shared environments where feasible.​  <br>•  <br>Minimize process gaps and ensure zero deviations from defined processes.​  <br>•  <br>Conduct quarterly reviews of documentation to ensure accuracy, relevance, and completeness.​  <br>•  <br>​|• Zero process gaps ​  <br>•  <br>Quarterly review of process documentation​  <br>  <br>​|||
+|**Operational Excellence**​|• Aim for 90% of projects to be completed on time, ensuring timely delivery of services and solutions.​  <br>•  <br>Continuously identify and implement improvements to existing processes and deliverables, enhancing operational efficiency and effectiveness.​  <br>•  <br>Actively participate in the adoption of new features, technologies, and cloud solutions to improve operational capabilities.​  <br>•  <br>Document and analyze lessons learned from project executions, incorporating feedback to drive continuous improvement.​  <br>•  <br>​|​  <br>•  <br>60% of Project Completion within 3 months​  <br>•  <br>100% Security Compliance​  <br>•  <br>Expense Reduction Targets: Meet defined FY targets communicated by FinOps​  <br>•  <br>Adoption of New Technologies: Regularly adopt new features/technologies to enhance operational capabilities​  <br>  <br>​  <br>  <br>​|||
 |**Satisfy Customers**​|• Be an advocate for customer satisfaction, focusing on delivering value and exceeding customer expectations in every project and interaction.​  <br>•  <br>Collaborate with cross-functional teams and stakeholders to support business goals and initiatives, such as migrations and security compliance efforts.​  <br>•  <br>Ensure documentation of any planned/unplanned change predefined timeframes to maintain transparency and accountability.​  <br>•  <br>Participate in the onboarding of new customers to the cloud business, ensuring smooth transitions and successful deployments.​  <br>•  <br>​|• customer escalations due to cloud service errors <3​|||

Archived/Work/SG Yearly DR Execution Plan (EFS Replication Only).md

@@ -1,66 +1,66 @@
----
-title:
-source:
-author: shenwei
-published:
-created:
-description:
-tags: []
----
-
-## **1. Objective**
-
-Ensure business continuity and data protection by implementing an effective DR strategy for the customer, leveraging EFS replication, RDS PITR, and different failover methods.
-
-## **2. DR Scenarios & Recovery Options**
-
-|                    | **Method**                      | **RDS Recovery** | **EFS Recovery**             | **Failover Steps**                                                                                | **Estimated Downtime (RTO)** | **RPO** | **Cost Impact** |
-| ------------------ | ------------------------------- | ---------------- | ---------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------- | ------- | --------------- |
-| DR Basic Service   | **Cold Backup-Restore**         | Snapshot (6h)    | Backup Restore (6h)          | 1. Restore RDS from snapshot (6h)  <br>2. Restore EFS from snapshot (6h)  <br>3. Recover EKS (4h) | **24 hours**                 | 4 hours | **Base Cost**   |
-| DR Premium Service | **EFS Replica Only (RDS PITR)** | PITR (6h)        | EFS Replica + Restore (0.2h) | 1. RDS recovery from PITR (6h)  <br>2. Stop EFS sync (0.2h)  <br>3. Full EKS recovery             | **6 hours**                  | 15 min  | **+30% Cost**   |
-
----
-
-## **3. Downtime Estimation & RTO Considerations**
-
-- **EFS Replica Only (RDS PITR)**
-    - **6-hour RTO**, significantly reducing downtime compared to cold restore.
-    - **15-minute RPO** ensures minimal data loss.
-
----
-
-## **4. DR Execution Plan**
-
-### **4.1 Pre-DR Readiness Checks**
-
-- Ensure **EFS replication** is active and functioning correctly.
-- Verify **RDS PITR backups** and retention policies.
-- Pre-configure **EKS deployment templates(Velero)** for rapid recovery.
-
-### **4.2 Disaster Recovery Trigger**
-
-- DR activation is **initiated upon a major failure event** in the primary environment.
-- Decision criteria include **regional failure, prolonged service outage, or severe data corruption**.
-
-### **4.3 Execution Steps**
-
-#### **EFS Replica Only (RDS PITR)**
-
-1. **Recover RDS** from PITR (**6 hours**).
-2. **Stop EFS replication sync** (**0.2 hours**).
-3. **Recover EKS cluster** and validate application (**immediate**).
-
-### **4.4 Post-Failover Validation**
-
-- Confirm **data consistency** between DR and primary environments.
-- Validate **application services and connectivity**.
-- Communicate DR activation and service restoration to stakeholders.
-
----
-
-## **5. DR Testing & Cost Estimation**
-
-- **Annual DR validation test** is required, adding an **estimated 2 months of AWS costs**.
-    - **EFS Replica Only (RDS PITR):**
-        - **$20.8K/month** 
-
+---
+title:
+source:
+author: shenwei
+published:
+created:
+description:
+tags: []
+---
+
+## **1. Objective**
+
+Ensure business continuity and data protection by implementing an effective DR strategy for the customer, leveraging EFS replication, RDS PITR, and different failover methods.
+
+## **2. DR Scenarios & Recovery Options**
+
+|                    | **Method**                      | **RDS Recovery** | **EFS Recovery**             | **Failover Steps**                                                                                | **Estimated Downtime (RTO)** | **RPO** | **Cost Impact** |
+| ------------------ | ------------------------------- | ---------------- | ---------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------- | ------- | --------------- |
+| DR Basic Service   | **Cold Backup-Restore**         | Snapshot (6h)    | Backup Restore (6h)          | 1. Restore RDS from snapshot (6h)  <br>2. Restore EFS from snapshot (6h)  <br>3. Recover EKS (4h) | **24 hours**                 | 4 hours | **Base Cost**   |
+| DR Premium Service | **EFS Replica Only (RDS PITR)** | PITR (6h)        | EFS Replica + Restore (0.2h) | 1. RDS recovery from PITR (6h)  <br>2. Stop EFS sync (0.2h)  <br>3. Full EKS recovery             | **6 hours**                  | 15 min  | **+30% Cost**   |
+
+---
+
+## **3. Downtime Estimation & RTO Considerations**
+
+- **EFS Replica Only (RDS PITR)**
+    - **6-hour RTO**, significantly reducing downtime compared to cold restore.
+    - **15-minute RPO** ensures minimal data loss.
+
+---
+
+## **4. DR Execution Plan**
+
+### **4.1 Pre-DR Readiness Checks**
+
+- Ensure **EFS replication** is active and functioning correctly.
+- Verify **RDS PITR backups** and retention policies.
+- Pre-configure **EKS deployment templates(Velero)** for rapid recovery.
+
+### **4.2 Disaster Recovery Trigger**
+
+- DR activation is **initiated upon a major failure event** in the primary environment.
+- Decision criteria include **regional failure, prolonged service outage, or severe data corruption**.
+
+### **4.3 Execution Steps**
+
+#### **EFS Replica Only (RDS PITR)**
+
+1. **Recover RDS** from PITR (**6 hours**).
+2. **Stop EFS replication sync** (**0.2 hours**).
+3. **Recover EKS cluster** and validate application (**immediate**).
+
+### **4.4 Post-Failover Validation**
+
+- Confirm **data consistency** between DR and primary environments.
+- Validate **application services and connectivity**.
+- Communicate DR activation and service restoration to stakeholders.
+
+---
+
+## **5. DR Testing & Cost Estimation**
+
+- **Annual DR validation test** is required, adding an **estimated 2 months of AWS costs**.
+    - **EFS Replica Only (RDS PITR):**
+        - **$20.8K/month** 
+

Hermes/xingzhi/Hermes自定义技能说明.md

@@ -0,0 +1,114 @@
+# Hermes 自定义技能说明
+
+> 创建日期：2026-04-20
+> 更新日期：2026-04-20
+
+---
+
+## 技能总览
+
+| 技能名                               | 用途                                            | 调用方式          |
+| --------------------------------- | --------------------------------------------- | ------------- |
+| `blogwatcher-daily`               | RSS 订阅监控 + 每日笔记生成                             | cronjob       |
+| `claude-code-executor`            | 用 TMUX 启动 Claude Code 并委托任务                   | delegate_task |
+| `claude-code-infographic-prompts` | 调用 Claude Code 的 baoyu-infographic 生成信息图提示词   | 手动调用          |
+| `marker-pdf-to-markdown`          | PDF 转 Markdown（marker_single 单文件 / marker 批量） | terminal      |
+| `whisper-audio-to-text`           | 音频/视频转文字（Whisper）                             | terminal      |
+
+---
+
+## 1. claude-code-executor
+
+**路径**：`~/.hermes/skills/custom/claude-code-executor/SKILL.md`
+
+**用途**：通过 TMUX 启动 Claude Code（bypassPermissions 模式），发送任务指令，监控完成状态。
+
+**触发关键词**：用户说"请用 Claude Code 做 xxx"、"用 Claude Code 执行 xxx"
+
+**核心流程**：
+1. 启动 TMUX session `claude-task`
+2. 等 8 秒后发送 Enter（bypassPermissions 确认）
+3. 发送完整任务指令
+4. 监控 `done:` 输出
+5. 清理 tmux session
+
+**SSH 到 ubuntu2 命令**：`ssh ubuntu2`
+
+---
+
+## 2. claude-code-infographic-build
+
+**路径**：`~/.hermes/skills/custom/claude-code-infographic-build/SKILL.md`
+
+**用途**：调用 Claude Code 的 `baoyu-infographic` 技能，为笔记内容生成信息图提示词，并进一步生成图片添加到原始笔记。
+
+**完整三步流程**：
+1. **步骤①**：baoyu-infographic 生成三部分提示词 → 保存到 Hermes/xingzhi/
+2. **步骤②**：在同一 Claude Code session 中，baoyu-imagine 生成图片 → 保存到 Hermes/xingzhi/
+3. **步骤③**：obsidian skill 将图片引用添加到原始笔记
+
+**三部分提示词格式**：
+1. **系统提示词** — Image Specifications + Core Principles
+2. **风格锁定提示词** — Layout Guidelines + Style Guidelines
+3. **内容结构提示词** — Text Requirements + 具体内容
+
+**布局参考**（`~/.claude/skills/baoyu-infographic/references/layouts/`）：
+- `hub-spoke` — 适合 mind-map（标注了 "Best For: Mind maps"）
+- `circular-flow` — 适合循环流程
+- `venn` — 适合交集关系
+
+**风格参考**（`~/.claude/skills/baoyu-infographic/references/styles/`）：
+- `corporate-memphis` — 商务孟菲斯风格
+- `chalkboard` — 粉笔黑板风格
+- `cyberpunk-neon` — 赛博霓虹风格
+- `warm` / `notion` / `minimal` / `blueprint` / `watercolor` / `elegant`
+
+**文件命名**：`[主题]-infographic-prompts-YYYY-MM-DD.md`
+
+---
+
+## 3. blogwatcher-daily
+
+**路径**：`~/.hermes/skills/custom/blogwatcher-daily/SKILL.md`
+
+**用途**：RSS 订阅监控 + 每日笔记生成。使用 RSSHub + feedparser 抓取 31 个订阅，自动去重并存入 SQLite，新文章追加写入 Markdown 笔记。
+
+---
+
+## 4. marker-pdf-to-markdown
+
+**路径**：`~/.hermes/skills/custom/marker-pdf-to-markdown/SKILL.md`
+
+**用途**：PDF 转 Markdown/HTML/JSON 高精度工具，支持 OCR、表格、公式识别。
+
+**安装位置**：ubuntu2 服务器（`ssh ubuntu2`）
+
+| 命令 | 用途 | 输入 |
+|------|------|------|
+| `marker_single` | 单文件转换，默认输出到 PDF 同目录 | 单个 PDF 文件 |
+| `marker` | 批量转换，需文件夹输入 | 文件夹路径 |
+
+常用选项：`--output_dir`、`--output_format json/markdown/html`、`--no-images`、`--use_llm`、`--page_range`
+
+---
+
+## 5. whisper-audio-to-text
+
+**路径**：`~/.hermes/skills/custom/whisper-audio-to-text/SKILL.md`
+
+**用途**：使用 OpenAI Whisper 将音频/视频转换为文字（转录或翻译）。
+
+**安装位置**：Mac mini（GPU 加速）、ubuntu1、ubuntu2（CPU 模式），均直接可用。
+
+---
+
+## 相关 Claude Code 技能（`~/.claude/skills/`）
+
+| 技能名 | 用途 |
+|--------|------|
+| `baoyu-article-illustrator` | 文章配图（分析文章结构 + 生成配图） |
+| `baoyu-infographic` | 信息图生成 |
+| `baoyu-cover-image` | 封面图生成 |
+| `fireworks-tech-graph` | 技术图生成 |
+
+这些 Claude Code 技能通过 `claude-code-executor` 启动 Claude Code CLI 后调用。

Hermes/xingzhi/chrome-devtools-mcp-infographic-prompts-2026-04-20.md

@@ -0,0 +1,169 @@
+# Chrome DevTools MCP - Infographic Prompts
+
+Generated: 2026-04-20
+Layout: circular-flow
+Style: chalkboard
+Aspect: 16:9
+
+---
+
+## Part 1: System Prompt
+
+```
+Create a professional infographic with the following specifications:
+
+## Image Specifications
+- Type: Infographic
+- Layout: circular-flow (cyclic process showing continuous steps arranged in a circle)
+- Style: chalkboard (chalk on black board aesthetic)
+- Aspect Ratio: 16:9
+- Language: English
+
+## Core Principles
+- Follow the circular-flow layout structure: arrange information nodes in a circle with directional arrows
+- Each section represents a tool category as a node on the circle
+- Use chalk-drawn style: imperfect hand-drawn lines, chalk dust effects, white/yellow/pink/blue chalk colors
+- Black chalkboard background (#1A1A1A)
+- Center can hold the main concept "Chrome DevTools MCP"
+- Maintain authentic chalk texture on all elements
+- Use circular arrangement to show the tool workflow cycle
+- Clear visual hierarchy with color variety
+
+## Text Requirements
+- Main titles prominent and readable in chalk white
+- Key concepts emphasized with chalk yellow/pink
+- Labels clear and appropriately sized
+```
+
+---
+
+## Part 2: Style Locking Prompt
+
+```
+## Style Guidelines - chalkboard
+
+### Background
+- Color: Chalkboard Black (#1A1A1A) or Dark Green-Black (#1C2B1C)
+- Texture: Realistic chalkboard texture with subtle scratches, dust particles
+
+### Typography
+- Hand-drawn chalk lettering with visible chalk texture
+- White or bright colored chalk for emphasis
+
+### Color Palette
+- Background: #1A1A1A (Chalkboard Black)
+- Primary Text: #F5F5F5 (Chalk White)
+- Accent 1: #FFE566 (Chalk Yellow) - highlights, emphasis
+- Accent 2: #FF9999 (Chalk Pink) - secondary highlights
+- Accent 3: #66B3FF (Chalk Blue) - links, connections
+- Accent 4: #90EE90 (Chalk Green) - success indicators
+
+### Visual Elements
+- Hand-drawn chalk illustrations with sketchy, imperfect lines
+- Chalk dust effects around text and key elements
+- Doodles: stars, arrows, underlines, circles
+- Connection lines with hand-drawn feel
+- Directional arrows showing cycle flow
+
+### Do
+- Maintain authentic chalk texture on all elements
+- Use imperfect, hand-drawn quality
+- Add subtle chalk dust and smudge effects
+- Create visual hierarchy with color variety
+- Include playful doodles and annotations
+
+### Don't
+- Use perfect geometric shapes
+- Create clean digital-looking lines
+- Add photorealistic elements
+- Use gradients or glossy effects
+```
+
+---
+
+## Part 3: Content Structure Prompt
+
+```
+## Content Structure - circular-flow
+
+### Center Element
+- "Chrome DevTools MCP" - main concept in center of circle
+
+### Circle Nodes (6 categories, clockwise flow):
+1. INPUT AUTOMATION (9 tools)
+   - click, drag, fill, fill_form, handle_dialog, hover, press_key, type_text, upload_file
+   - Chalk Pink icon/node
+
+2. NAVIGATION AUTOMATION (6 tools)
+   - close_page, list_pages, navigate_page, new_page, select_page, wait_for
+   - Chalk Blue icon/node
+
+3. EMULATION (2 tools)
+   - emulate, resize_page
+   - Chalk Yellow icon/node
+
+4. PERFORMANCE (4 tools)
+   - performance_analyze_insight, performance_start_trace, performance_stop_trace, take_memory_snapshot
+   - Chalk Green icon/node
+
+5. NETWORK (2 tools)
+   - get_network_request, list_network_requests
+   - Chalk Pink icon/node
+
+6. DEBUGGING (6 tools)
+   - evaluate_script, get_console_message, lighthouse_audit, list_console_messages, take_screenshot, take_snapshot
+   - Chalk Blue icon/node
+
+### Supported Clients (around the outer edge):
+- Claude Code, Cline, Cursor, VS Code, Copilot, Codex, Gemini, JetBrains, Kiro, Windsurf, Amp, Antigravity, Command Code, Factory, Mistral, OpenCode, Qoder, Warp
+
+### Configuration Options (bottom section):
+- --headless, --slim, --autoConnect, --browser-url, --channel, --viewport, --isolated, --user-data-dir
+
+### Arrows
+- Curved directional arrows connecting each node in clockwise direction
+- Showing continuous workflow cycle
+
+### Labels in English
+- All text labels in English
+- Use chalk white for main text, chalk yellow for emphasis
+```
+
+---
+
+## Visual Layout Diagram
+
+```
+                    [INPUT]
+                       ↓
+                  ↙       ↘
+        [DEBUGGING] ←   CENTER   → [NAVIGATION]
+                  ↗       ↣
+         ↙                               ↘
+    [NETWORK]  ←─────────────────────→  [EMULATION]
+         ↘                               ↙
+                  ↗       ↣
+        [PERFORMANCE]                   →
+                       ↓
+                    [???]
+
+Actually circular flow (clockwise):
+┌─────────────────────────────────────────┐
+│                                         │
+│   [EMULATION] → [PERFORMANCE]           │
+│      ↗              ↗                  │
+│      │              │                     │
+│ [DEBUGGING]    [NAVIGATION]              │
+│      │              │                     │
+│      ↖              ↘                  │
+│   [NETWORK] ← [INPUT]                  │
+│                                         │
+│   Center: "Chrome DevTools MCP"           │
+└─────────────────────────────────────────┘
+```
+
+---
+
+## Final Prompt Summary
+
+Generate a chalkboard-style infographic showing Chrome DevTools MCP tool categories arranged in a circular flow pattern. The circle has 6 nodes representing the tool categories (Input Automation, Navigation, Emulation, Performance, Network, Debugging). Each node displays the tool count and key tool names in chalk-style lettering. The center shows "Chrome DevTools MCP" as the main concept. Arrows show clockwise flow indicating the continuous nature of browser automation workflow. Use authentic chalkboard aesthetic with black background (#1A1A1A), chalk white text, and colorful chalk accents (yellow, pink, blue, green) for visual hierarchy. Include chalk dust effects and hand-drawn imperfect lines throughout.

Hermes/xingzhi/hermes-skills-infographic-prompt-2026-04-20.md

@@ -0,0 +1,63 @@
+# Hermes Custom Skills - Infographic Image Prompt
+
+## Image Specifications
+- **Type**: Infographic
+- **Layout**: Circular Flow (cyclic process showing continuous recurring steps)
+- **Style**: Chalkboard (black chalkboard background with colorful chalk drawing style)
+- **Aspect Ratio**: 16:9
+- **Language**: English
+
+## Core Principles
+- Follow the circular-flow layout structure precisely for information architecture
+- Apply chalkboard style aesthetics consistently throughout
+- Create stylistically similar alternatives for any specific figures
+- Keep information concise, highlight keywords and core concepts
+- Use ample whitespace for visual clarity
+- Maintain clear visual hierarchy
+
+## Layout Guidelines
+- Circular arrangement with 5 skill nodes evenly spaced around the circle
+- Arrows showing clockwise direction flow
+- No clear start/end (continuous cycle)
+- Center holds main concept: "Hermes Automation Ecosystem"
+- Title at top: "Hermes Custom Skills - Automation Workflows"
+- Step labels at each node with skill names and taglines
+- Brief descriptions near nodes
+
+## Style Guidelines
+- **Background**: Chalkboard Black (#1A1A1A) with realistic chalkboard texture, subtle scratches, dust particles, faint eraser marks
+- **Typography**: Hand-drawn chalk lettering style with visible chalk texture, imperfect baseline, white or bright colored chalk for emphasis
+- **Color Palette**:
+  - Background: #1A1A1A (Chalkboard Black)
+  - Primary Text: #F5F5F5 (Chalk White)
+  - Accent 1: #FFE566 (Chalk Yellow) - for skill names
+  - Accent 2: #FF9999 (Chalk Pink) - for highlights
+  - Accent 3: #66B3FF (Chalk Blue) - for connections
+  - Accent 4: #90EE90 (Chalk Green) - for success indicators
+- **Visual Elements**: Hand-drawn chalk illustrations with sketchy imperfect lines, chalk dust effects, doodles (stars, arrows, circles), stick figures, connection lines with hand-drawn feel
+
+## Content
+
+**Title**: Hermes Custom Skills - Automation Workflows
+
+**Center Concept**: Hermes Automation Ecosystem
+
+**5 Skill Nodes (clockwise from top)**:
+
+1. **blogwatcher-daily** - RSS Subscription Monitor - RSS monitoring + daily note generation - cronjob
+
+2. **claude-code-executor** - Claude Code Task Delegation - Launch Claude Code via TMUX, send tasks, monitor completion - delegate_task
+
+3. **claude-code-infographic-prompts** - Infographic Prompt Generator - Generate 3-part prompts for baoyu-infographic skill - manual
+
+4. **marker-pdf-to-markdown** - PDF to Markdown Converter - High-precision PDF conversion with OCR, table, formula recognition - terminal
+
+5. **whisper-audio-to-text** - Audio/Video Transcription - OpenAI Whisper for speech-to-text - terminal
+
+**Bottom Note**: "5 Custom Skills | Powering Hermes Automation"
+
+**Visual Elements**:
+- Chalk dust particles around text
+- Hand-drawn arrows connecting skills in clockwise cycle
+- Small doodle icons (stars, checkmarks) near each skill
+- Eraser smudge textures as subtle background variation

Hermes/xingzhi/hermes-skills-infographic-prompts-2026-04-20.md

@@ -0,0 +1,119 @@
+# Hermes Custom Skills Infographic Prompts
+
+**Date**: 2026-04-20
+**Layout**: circular-flow
+**Style**: chalkboard
+**Aspect**: 16:9
+
+---
+
+## Part 1: System Prompt (Image Specifications + Core Principles)
+
+**Image Specifications**
+- **Type**: Infographic
+- **Layout**: Circular Flow (cyclic process showing continuous recurring steps)
+- **Style**: Chalkboard (black chalkboard background with colorful chalk drawing style)
+- **Aspect Ratio**: 16:9
+- **Language**: English
+
+**Core Principles**
+- Follow the circular-flow layout structure precisely for information architecture
+- Apply chalkboard style aesthetics consistently throughout
+- Create stylistically similar alternatives for any specific figures
+- Keep information concise, highlight keywords and core concepts
+- Use ample whitespace for visual clarity
+- Maintain clear visual hierarchy
+
+---
+
+## Part 2: Style Locking Prompts (Layout Guidelines + Style Guidelines)
+
+**Layout Guidelines (Circular Flow)**
+- Circular arrangement with steps around the circle
+- Arrows showing direction (clockwise flow)
+- No clear start/end (continuous cycle)
+- Center can hold main concept
+- Steps around the circle: 5 skill nodes evenly spaced
+- Icons per step representing each skill
+- Title at top
+- Step labels at each node
+- Brief descriptions near nodes
+- Center concept: "Hermes Automation Ecosystem"
+
+**Style Guidelines (Chalkboard)**
+- **Background**: Chalkboard Black (#1A1A1A) with realistic chalkboard texture, subtle scratches, dust particles, faint eraser marks
+- **Typography**: Hand-drawn chalk lettering style with visible chalk texture, imperfect baseline, white or bright colored chalk for emphasis
+- **Color Palette**:
+  - Background: #1A1A1A (Chalkboard Black)
+  - Primary Text: #F5F5F5 (Chalk White)
+  - Accent 1: #FFE566 (Chalk Yellow) - for skill names
+  - Accent 2: #FF9999 (Chalk Pink) - for highlights
+  - Accent 3: #66B3FF (Chalk Blue) - for connections
+  - Accent 4: #90EE90 (Chalk Green) - for success indicators
+- **Visual Elements**: Hand-drawn chalk illustrations with sketchy imperfect lines, chalk dust effects, doodles (stars, arrows, circles), stick figures, connection lines with hand-drawn feel
+- **Do**: Maintain authentic chalk texture, use imperfect hand-drawn quality, add chalk dust effects, create visual hierarchy with color variety
+- **Don't**: Use perfect geometric shapes, create clean digital-looking lines, add photorealistic elements, use gradients
+
+---
+
+## Part 3: Content Structure Prompts (Text Requirements + Structured Content)
+
+**Text Requirements**
+- All text must match chalkboard style treatment
+- Main titles should be prominent and readable
+- Key concepts should be visually emphasized
+- Labels should be clear and appropriately sized
+- Use English for all text content
+
+**Structured Content**
+
+**Title**: Hermes Custom Skills - Automation Workflows
+
+**Center Concept**: Hermes Automation Ecosystem (in the middle of the circle)
+
+**5 Skill Nodes (clockwise from top)**:
+
+1. **blogwatcher-daily**
+   - Tagline: RSS Subscription Monitor
+   - Function: RSS monitoring + daily note generation
+   - Call method: cronjob
+   - Icon: RSS feed / newspaper symbol
+
+2. **claude-code-executor**
+   - Tagline: Claude Code Task Delegation
+   - Function: Launch Claude Code via TMUX, send tasks, monitor completion
+   - Call method: delegate_task
+   - Icon: robot / terminal symbol
+
+3. **claude-code-infographic-prompts**
+   - Tagline: Infographic Prompt Generator
+   - Function: Generate 3-part prompts for baoyu-infographic skill
+   - Call method: manual
+   - Icon: palette / image symbol
+
+4. **marker-pdf-to-markdown**
+   - Tagline: PDF to Markdown Converter
+   - Function: High-precision PDF conversion with OCR, table, formula recognition
+   - Call method: terminal
+   - Icon: document conversion symbol
+
+5. **whisper-audio-to-text**
+   - Tagline: Audio/Video Transcription
+   - Function: OpenAI Whisper for speech-to-text
+   - Call method: terminal
+   - Icon: microphone / audio wave symbol
+
+**Connection Arrows**: Clockwise arrows showing continuous workflow between skills
+
+**Bottom Note**: "5 Custom Skills | Powering Hermes Automation"
+
+---
+
+## Visual Elements to Include
+
+- Wooden chalkboard frame border (optional)
+- Chalk dust particles around text
+- Hand-drawn arrows connecting skills in cycle
+- Small doodle icons (stars, checkmarks) near each skill
+- Mathematical/formula-style decorations (fitting the chalkboard theme)
+- Eraser smudge textures as subtle background variation

Hermes/xingzhi/infographic/llm-wiki-sync-circular-flow/analysis.md

@@ -0,0 +1,72 @@
+---
+title: "llm-wiki-sync Circular Flow"
+topic: technical
+data_type: cycle
+complexity: moderate
+point_count: 7
+source_language: zh
+user_language: en
+---
+
+## Main Topic
+A cyclical knowledge management pipeline that transforms raw notes into structured wiki pages through continuous LLM-powered ingestion, extraction, and reuse.
+
+## Learning Objectives
+After viewing this infographic, the viewer will understand:
+1. The continuous circular flow of llm-wiki-sync from raw notes to reusable knowledge
+2. The key extraction outputs: Summary, Claims, Entities, Concepts, Connections
+3. How feedback and reuse complete the cycle back to new raw material
+
+## Target Audience
+- **Knowledge Level**: Intermediate technical audience
+- **Context**: Developers and knowledge workers interested in AI-powered knowledge management
+- **Expectations**: Clear understanding of the llm-wiki-sync pipeline and its cyclical nature
+
+## Content Type Analysis
+- **Data Structure**: Cyclic process with recurring steps
+- **Key Relationships**: Raw → Ingest → Extract → Source Page → Graph/Site → Reuse → Raw (feedback loop)
+- **Visual Opportunities**: Circular flow with nodes for each stage, arrows showing direction, center concept
+
+## Key Data Points (Verbatim)
+
+### Core Pipeline Steps
+1. **Raw Note** - Original document in raw/ folder
+2. **Ingest** - LLM analyzes and extracts structured information
+3. **Extract** - Summary, Claims, Quotes, Entities, Concepts, Connections
+4. **Source Page** - Structured wiki/sources/ page with frontmatter
+5. **Graph & Site** - graph.json and Quartz static site generation
+6. **Reuse** - Synthesize, query, create new content from structured knowledge
+7. **Feedback Loop** - New raw notes created from reused knowledge
+
+### Extraction Outputs
+- **Summary**: 核心主题, 问题域, 方法/机制, 结论/价值
+- **Key Claims**: Verifiable assertions extracted from text
+- **Key Entities**: LaunchDarkly, HP, Christian Dior, etc.
+- **Key Concepts**: RTO, RPO, Feature Flag, Kill Switch, Gradual Rollout
+- **Connections**: depends_on, enables, provides relationships
+
+### Key Quotes
+- "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose."
+- "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users."
+
+## Layout × Style Signals
+- Content type: cycle → circular-flow
+- Tone: technical educational → chalkboard
+- Audience: developers → clear, legible, professional
+- Complexity: moderate → balanced density with clear visual hierarchy
+
+## Design Instructions (from user input)
+- **Layout**: circular-flow (NOT linear - must emphasize recurring cycle)
+- **Style**: chalkboard (dark background, hand-drawn chalk accents)
+- **Aspect**: 16:9 landscape
+- **Language**: English
+- Circular flow showing: raw note -> ingest -> extract -> source page -> graph/static site -> reuse/feedback -> knowledge base
+- Include core extraction outputs as recurring nodes/callouts
+- Keep text concise and legible
+- Dark chalkboard background with hand-drawn chalk accents
+- Avoid clutter, make cycle visually clear and publication-ready
+
+## Recommended Combinations
+1. **circular-flow + chalkboard** (Recommended): Perfect match for cycle/process content with chalkboard aesthetic
+2. **hub-spoke + technical-schematic**: For emphasizing central concepts with technical precision
+3. **bento-grid + craft-handmade**: For multiple topic overview with friendly handmade feel

Hermes/xingzhi/infographic/llm-wiki-sync-circular-flow/prompts/infographic.md

@@ -0,0 +1,158 @@
+Create a professional infographic following these specifications:
+
+## Image Specifications
+
+- **Type**: Infographic
+- **Layout**: circular-flow (Cyclic process showing continuous or recurring steps)
+- **Style**: chalkboard (Black chalkboard background with colorful chalk drawing style)
+- **Aspect Ratio**: 16:9
+- **Language**: English
+
+## Core Principles
+
+- Follow the layout structure precisely for information architecture
+- Apply style aesthetics consistently throughout
+- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
+- Keep information concise, highlight keywords and core concepts
+- Use ample whitespace for visual clarity
+- Maintain clear visual hierarchy
+
+## Text Requirements
+
+- All text must match the specified style treatment
+- Main titles should be prominent and readable
+- Key concepts should be visually emphasized
+- Labels should be clear and appropriately sized
+- Use the specified language for all text content
+
+## Layout Guidelines
+
+- Circular arrangement
+- Steps around the circle
+- Arrows showing direction
+- No clear start/end (continuous)
+- Center can hold main concept
+- Circle or ring shape
+- Directional arrows
+- Step nodes evenly spaced
+- Icons per step
+- Optional center element
+
+## Style Guidelines
+
+- **Background**: Chalkboard Black (#1A1A1A) or Dark Green-Black (#1C2B1C)
+- **Texture**: Realistic chalkboard texture with subtle scratches, dust particles, and faint eraser marks
+- **Typography**: Hand-drawn chalk lettering style with visible chalk texture. Imperfect baseline adds authenticity.
+- **Color Palette**:
+  - Background: Chalkboard Black (#1A1A1A)
+  - Primary Text: Chalk White (#F5F5F5)
+  - Accent 1: Chalk Yellow (#FFE566)
+  - Accent 2: Chalk Pink (#FF9999)
+  - Accent 3: Chalk Blue (#66B3FF)
+  - Accent 4: Chalk Green (#90EE90)
+  - Accent 5: Chalk Orange (#FFB366)
+- **Visual Elements**:
+  - Hand-drawn chalk illustrations with sketchy, imperfect lines
+  - Chalk dust effects around text and key elements
+  - Doodles: stars, arrows, underlines, circles, checkmarks
+  - Eraser smudges and chalk residue textures
+  - Wooden frame border optional
+  - Stick figures and simple icons
+  - Connection lines with hand-drawn feel
+- **Style Rules**:
+  - Maintain authentic chalk texture on all elements
+  - Use imperfect, hand-drawn quality throughout
+  - Add subtle chalk dust and smudge effects
+  - Create visual hierarchy with color variety
+  - Include playful doodles and annotations
+  - DO NOT use perfect geometric shapes
+  - DO NOT create clean digital-looking lines
+
+---
+
+Generate the infographic based on the content below:
+
+# llm-wiki-sync: Turning Scattered Notes into a Reusable Knowledge Base
+
+## Overview
+A cyclical pipeline showing how raw notes are continuously transformed through LLM-powered ingestion into structured wiki pages, then feedback into the knowledge base for reuse.
+
+## The Knowledge Pipeline Cycle (Center Concept)
+The llm-wiki-sync pipeline operates as a continuous cycle, not a linear process.
+7 stages in the cycle: Raw Note → Ingest → Extract → Source Page → Graph/Site → Reuse → Feedback Loop
+
+## Circular Flow Diagram with 7 Stages:
+
+1. **Raw Note** (Stage 1)
+   - Original documents stored in raw/ folder
+   - Contains unprocessed information awaiting structure
+   - Icon: Stack of paper/note icon
+
+2. **Ingest** (Stage 2)
+   - LLM analyzes and extracts structured information
+   - Hermes skill triggers Claude Code for ingestion
+   - Context check against wiki/index.md prevents duplicates
+   - Icon: Brain/processing icon
+
+3. **Extract** (Stage 3)
+   - Six key elements extracted from each document:
+     - Summary (核心主题, 问题域, 方法/机制, 结论/价值)
+     - Key Claims (Verifiable assertions)
+     - Key Quotes (Preserved citations)
+     - Key Entities (LaunchDarkly, HP, etc.)
+     - Key Concepts (RTO, RPO, Feature Flag, etc.)
+     - Connections (depends_on, enables, provides)
+   - Icon: Six circles/callouts
+
+4. **Source Page** (Stage 4)
+   - Written to wiki/sources/<slug>.md
+   - Contains frontmatter and standard sections
+   - Links use [[PageName]] format
+   - Icon: Document/page icon
+
+5. **Graph & Site** (Stage 5)
+   - graph.json: Machine-readable graph structure
+   - graph.html: Interactive visualization
+   - Quartz: Static site generation
+   - Icon: Network/graph icon
+
+6. **Reuse** (Stage 6)
+   - Query, Synthesize, Write, Connect
+   - Icon: Multiple arrows pointing outward
+
+7. **Feedback Loop** (Stage 7)
+   - New insights become new raw notes
+   - Cycle continues indefinitely
+   - Icon: Circular arrow completing the cycle
+
+## Key Quotes (to include as callouts):
+- "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose."
+- "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users."
+
+## Design Requirements:
+- Circular flow with 7 stages evenly spaced around a circle
+- Clockwise arrow direction
+- Center contains: "llm-wiki-sync" as main concept
+- Each stage is a node with icon + label
+- Extraction outputs (6 items) shown as callouts or inner ring
+- Dark chalkboard background with hand-drawn chalk accents
+- Chalk colors for visual hierarchy
+- Imperfect, sketchy lines throughout
+- Publication-ready quality
+- NO clutter - only essential elements
+- Clear hierarchy: title > headlines > labels > descriptions
+
+## Text Labels (in English):
+- Headline: "The Knowledge Pipeline Cycle"
+- Subhead: "How llm-wiki-sync transforms scattered notes into a reusable knowledge base"
+- Stage labels: "Raw Note", "Ingest", "Extract", "Source Page", "Graph & Site", "Reuse", "Feedback"
+- Center: "llm-wiki-sync"
+- Extraction labels: "Summary", "Claims", "Quotes", "Entities", "Concepts", "Connections"
+
+## Key Constraints:
+- 16:9 aspect ratio (landscape)
+- All text in English
+- Chalkboard style (dark background, chalk-like hand-drawn elements)
+- Circular flow layout (NOT linear)
+- Publication-ready, visually clear
+- No clutter or excessive elements

Hermes/xingzhi/infographic/llm-wiki-sync-circular-flow/structured-content.md

@@ -0,0 +1,229 @@
+# llm-wiki-sync: Turning Scattered Notes into a Reusable Knowledge Base
+
+## Overview
+A cyclical pipeline showing how raw notes are continuously transformed through LLM-powered ingestion into structured wiki pages, then feedback into the knowledge base for reuse.
+
+## Learning Objectives
+The viewer will understand:
+1. The continuous circular flow of llm-wiki-sync from raw notes to reusable knowledge
+2. The six key extraction outputs: Summary, Claims, Quotes, Entities, Concepts, Connections
+3. How feedback and reuse complete the cycle back to new raw material
+
+---
+
+## Section 1: The Circular Flow (Center Concept)
+
+**Key Concept**: The llm-wiki-sync pipeline operates as a continuous cycle, not a linear process.
+
+**Content**:
+- 7 stages in the cycle: Raw Note → Ingest → Extract → Source Page → Graph/Site → Reuse → Feedback Loop
+- Each stage feeds into the next, with feedback returning to the beginning
+- The cycle is continuous and self-reinforcing
+
+**Visual Element**:
+- Type: circular flow diagram
+- Subject: 7 stages arranged in a circle with clockwise arrows
+- Center label: "llm-wiki-sync Cycle"
+- Treatment: chalk style with hand-drawn arrows connecting stages
+
+**Text Labels**:
+- Headline: "The Knowledge Pipeline Cycle"
+- Stage labels: "Raw Note", "Ingest", "Extract", "Source Page", "Graph/Site", "Reuse", "Feedback"
+- Center: "llm-wiki-sync"
+
+---
+
+## Section 2: Stage 1 — Raw Note (Input)
+
+**Key Concept**: Raw notes are the starting point of the cycle.
+
+**Content**:
+- Original documents stored in raw/ folder
+- Can be any format: markdown, text, research notes
+- Contains unprocessed information awaiting structure
+
+**Visual Element**:
+- Type: document/note icon
+- Subject: Stack of paper or note icon
+- Treatment: Chalk sketch style
+
+**Text Labels**:
+- Label: "Raw Note"
+- Description: "Original input"
+
+---
+
+## Section 3: Stage 2 — Ingest (LLM Analysis)
+
+**Key Concept**: The LLM analyzes raw notes and extracts structured information.
+
+**Content**:
+- Hermes skill triggers Claude Code for ingestion
+- LLM reads and analyzes the full document
+- Context check against wiki/index.md prevents duplicates
+
+**Visual Element**:
+- Type: brain/processing icon
+- Subject: Brain or gears with chalk lines
+- Treatment: Hand-drawn chalk illustration
+
+**Text Labels**:
+- Label: "Ingest"
+- Description: "LLM Analysis"
+
+---
+
+## Section 4: Stage 3 — Extract (Six Core Outputs)
+
+**Key Concept**: Six key elements are extracted from each document.
+
+**Content**:
+1. **Summary**: 核心主题, 问题域, 方法/机制, 结论/价值
+2. **Key Claims**: Verifiable assertions extracted from text
+3. **Key Quotes**: Preserved citations for reference
+4. **Key Entities**: Named people, companies, products (e.g., LaunchDarkly, HP)
+5. **Key Concepts**: Abstract terms that can be reused (e.g., RTO, RPO, Feature Flag)
+6. **Connections**: Relationships between elements (depends_on, enables, provides)
+
+**Visual Element**:
+- Type: 6 callout nodes around center
+- Subject: Six boxes or bubbles representing extraction outputs
+- Treatment: Chalk circles with icons inside each
+
+**Text Labels**:
+- Headline: "Extraction Outputs"
+- Labels: "Summary", "Claims", "Quotes", "Entities", "Concepts", "Connections"
+
+---
+
+## Section 5: Stage 4 — Source Page (Structured Output)
+
+**Key Concept**: Extracted information is written as a structured wiki source page.
+
+**Content**:
+- Written to wiki/sources/<slug>.md
+- Contains frontmatter (id, title, type, tags, sources, last_updated)
+- Standard sections: Summary, Key Claims, Key Quotes, Key Concepts, Key Entities, Connections, Contradictions
+- Links use [[PageName]] format for interconnections
+
+**Visual Element**:
+- Type: document/page icon
+- Subject: Page with visible structure headers
+- Treatment: Chalk sketch with text lines
+
+**Text Labels**:
+- Label: "Source Page"
+- Description: "wiki/sources/*.md"
+
+---
+
+## Section 6: Stage 5 — Graph & Static Site
+
+**Key Concept**: Structured pages generate knowledge graphs and static websites.
+
+**Content**:
+- graph.json: Machine-readable graph structure
+- graph.html: Interactive visualization
+- Quartz: Static site generation for sharing/export
+- Connections become edges in the knowledge graph
+
+**Visual Element**:
+- Type: network/graph icon
+- Subject: Connected nodes representing knowledge graph
+- Treatment: Chalk diagram with nodes and edges
+
+**Text Labels**:
+- Label: "Graph & Site"
+- Description: "graph.json + Quartz"
+
+---
+
+## Section 7: Stage 6 — Reuse (Knowledge Application)
+
+**Key Concept**: Structured knowledge enables multiple reuse scenarios.
+
+**Content**:
+- Query: Ask questions against the knowledge base
+- Synthesize: Create new content from existing knowledge
+- Write: Generate articles, reports from source material
+- Connect: Link ideas across different source pages
+
+**Visual Element**:
+- Type: multiple arrows pointing outward
+- Subject: Reuse scenarios as icons (question, document, pen)
+- Treatment: Chalk illustration
+
+**Text Labels**:
+- Label: "Reuse"
+- Sub-labels: "Query", "Synthesize", "Write", "Connect"
+
+---
+
+## Section 8: Stage 7 — Feedback Loop (Continuous Cycle)
+
+**Key Concept**: Reuse generates new raw notes, completing the cycle.
+
+**Content**:
+- New insights from synthesis become new raw notes
+- Updated knowledge feeds back to raw/ folder
+- Cycle continues indefinitely
+- Each iteration strengthens the knowledge base
+
+**Visual Element**:
+- Type: circular arrow
+- Subject: Feedback loop arrow returning to Raw Note stage
+- Treatment: Large chalk arrow completing the circle
+
+**Text Labels**:
+- Label: "Feedback Loop"
+- Description: "New notes → Cycle repeats"
+
+---
+
+## Data Points (Verbatim)
+
+### Key Quotes
+- "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose."
+- "Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users."
+
+### Key Entities
+- LaunchDarkly (Feature Flag management platform)
+- HP (example enterprise)
+- Christian Dior (example case)
+
+### Key Concepts
+- RTO (Recovery Time Objective)
+- RPO (Recovery Point Objective)
+- Feature Flag (特性开关)
+- Kill Switch (紧急关闭机制)
+- 渐进式发布 (Gradual Rollout)
+
+---
+
+## Design Instructions
+
+### Layout Preferences
+- Circular flow with 7 stages evenly spaced around a circle
+- Clockwise arrow direction
+- Center contains the main concept "llm-wiki-sync"
+- Each stage is a node with icon + label
+- Extraction outputs (6 items) shown as callouts or inner ring
+
+### Style Preferences
+- Chalkboard: Dark background (#1A1A1A)
+- Hand-drawn chalk style for all elements
+- Chalk colors: white, yellow, pink, blue, green, orange
+- Imperfect, sketchy lines throughout
+- Chalk dust effects for authenticity
+
+### Text Requirements
+- All text in English
+- Legible font sizes (minimum 14pt for labels)
+- Clear hierarchy: title > headlines > labels > descriptions
+- Ample whitespace between stages
+
+### Visual Clarity
+- Avoid clutter - only essential elements
+- Each stage should be clearly distinguishable
+- Arrows should clearly indicate flow direction
+- Publication-ready quality

Hermes/xingzhi/major-incident-infographic-prompts-2026-04-20.md

@@ -1,182 +1,182 @@
-# Major Incident Definition - Infographic Prompts
-# Generated: 2026-04-20
-# Layout: Venn Diagram
-# Style: Cyberpunk Neon
-# Aspect: 16:9
-# Language: English
-
----
-
-## Part 1: System Prompt (Image Specifications + Core Principles)
-
-Create a professional infographic following these specifications:
-
-**Image Specifications**
-
-- **Type**: Infographic
-- **Layout**: Venn Diagram (venn-diagram)
-- **Style**: Cyberpunk Neon
-- **Aspect Ratio**: 16:9
-- **Language**: English
-
-**Core Principles**
-
-- Follow the layout structure precisely for information architecture
-- Apply style aesthetics consistently throughout
-- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
-- Keep information concise, highlight keywords and core concepts
-- Use ample whitespace for visual clarity
-- Maintain clear visual hierarchy
-
-**Text Requirements**
-
-- All text must match the specified style treatment
-- Main titles should be prominent and readable
-- Key concepts should be visually emphasized
-- Labels should be clear and appropriately sized
-- Use English for all text content
-
----
-
-## Part 2: Style Lock Prompt (Layout Guidelines + Style Guidelines)
-
-### Layout Guidelines (Venn Diagram)
-
-**Structure**: Three overlapping circles forming a central intersection area
-
-**Visual Elements**:
-
-- Three large overlapping circles representing different categories of Major Incident
-- Central intersection zone highlighting the combined criteria
-- Each circle contains key concepts specific to its category
-- Outer labels for each circle region
-- Connection lines from concepts to their respective regions
-- Minimal text, emphasize visual grouping
-
-**Composition**:
-
-- Canvas divided into three equal sections for each circle
-- 30-40% overlap area in center for intersection
-- Ample negative space between elements
-- Clear visual boundaries between overlapping regions
-
-### Style Guidelines (Cyberpunk Neon)
-
-**Color Palette**:
-
-- Primary: Neon pink (#FF00FF), cyan (#00FFFF), electric blue
-- Background: Deep black (#0A0A0A), dark purple gradients
-- Accents: Neon glow effects, chrome reflections
-
-**Visual Elements**:
-
-- Glowing neon outlines on all circle boundaries
-- Dark atmospheric backgrounds with subtle grid patterns
-- Digital glitch effects on text
-- Circuit patterns along connection lines
-- Holographic elements in intersection zone
-- Rain and reflections on edges
-
-**Typography**:
-
-- Glowing neon text (cyan for primary labels, pink for emphasis)
-- Digital/tech monospace fonts
-- Subtle flickering effects on key terms
-- Outlined glow letters for main title
-- All caps for section headers
-
-**Effects**:
-
-- Neon glow (2-3px bloom) around all text and shapes
-- Gradient fills with 40-60% opacity
-- Scanline overlay at 10% opacity
-- Chromatic aberration on text edges
-
----
-
-## Part 3: Content Structure Prompt (Text Requirements + Content)
-
-### Main Title
-
-**MAJOR INCIDENT DEFINITION**
-*Highest Severity Level (S1/P1/Critical)*
-
-### Three Venn Circles Content
-
-**Circle 1: Business Impact**
-
-- Total Service Outage
-- Critical Feature Failure
-- Data Corruption/Loss
-- Security Breach
-- Regulatory Compliance Risk
-- High-Impact SLA Breach
-
-**Circle 2: Incident Response**
-
-- Immediate Actions (0-15 min)
-  - Automated Monitoring Alerts
-  - Incident Commander Assigned
-  - Major Incident Bridge
-  - Customer Communication
-- Investigation & Mitigation (15-60 min)
-  - Root Cause Analysis
-  - Rollback/Hotfix
-  - Failover to Backup
-  - Workarounds
-- Recovery & Post-Mortem (1-24h+)
-  - Full Service Restored
-  - RCA Report Published
-  - Long-Term Fixes
-
-**Circle 3: Prevention Measures**
-
-- High Availability Architecture
-- Chaos Engineering & Load Testing
-- Real-Time Monitoring & Alerting
-- Automated Rollbacks
-- Strict Change Management
-- Security Hardening & Compliance
-
-### Central Intersection (All Three Circles)
-
-The intersection represents the critical overlap showing that Major Incidents require:
-
-- Cross-team collaboration
-- Immediate response (15-30 min SLA)
-- Significant business impact
-- Coordinated resolution
-
-### Key Criteria Table (Bottom Section)
-
-| Criteria | Description |
-|----------|-------------|
-| Scope | Multiple tenants/customers, entire platform |
-| Business Criticality | Severe financial/reputational impact |
-| Resolution Time | Immediate, 15-30 min acknowledgment |
-| Workload Impact | Cloud Ops, DevOps, Security, Support |
-| Regulatory Compliance | Legal/security obligations at risk |
-
-### Footer Text
-
-"Requires Swift, Coordinated Response to Minimize Downtime"
-
----
-
-## Visual Composition for 16:9
-
-- **Top Section** (10%): Title with neon glow effect
-- **Middle Section** (70%): Three overlapping circles with content
-- **Bottom Section** (20%): Criteria table in minimalist style
-
-### Color Assignment per Circle
-
-- Circle 1 (Business Impact): Cyan (#00FFFF) neon outline
-- Circle 2 (Incident Response): Neon Pink (#FF00FF) neon outline
-- Circle 3 (Prevention): Electric Blue (#0080FF) neon outline
-- Intersection: White glow with purple tint
-- Background: Deep black (#0A0A0A) with dark purple gradient
-
----
-
+# Major Incident Definition - Infographic Prompts
+# Generated: 2026-04-20
+# Layout: Venn Diagram
+# Style: Cyberpunk Neon
+# Aspect: 16:9
+# Language: English
+
+---
+
+## Part 1: System Prompt (Image Specifications + Core Principles)
+
+Create a professional infographic following these specifications:
+
+**Image Specifications**
+
+- **Type**: Infographic
+- **Layout**: Venn Diagram (venn-diagram)
+- **Style**: Cyberpunk Neon
+- **Aspect Ratio**: 16:9
+- **Language**: English
+
+**Core Principles**
+
+- Follow the layout structure precisely for information architecture
+- Apply style aesthetics consistently throughout
+- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
+- Keep information concise, highlight keywords and core concepts
+- Use ample whitespace for visual clarity
+- Maintain clear visual hierarchy
+
+**Text Requirements**
+
+- All text must match the specified style treatment
+- Main titles should be prominent and readable
+- Key concepts should be visually emphasized
+- Labels should be clear and appropriately sized
+- Use English for all text content
+
+---
+
+## Part 2: Style Lock Prompt (Layout Guidelines + Style Guidelines)
+
+### Layout Guidelines (Venn Diagram)
+
+**Structure**: Three overlapping circles forming a central intersection area
+
+**Visual Elements**:
+
+- Three large overlapping circles representing different categories of Major Incident
+- Central intersection zone highlighting the combined criteria
+- Each circle contains key concepts specific to its category
+- Outer labels for each circle region
+- Connection lines from concepts to their respective regions
+- Minimal text, emphasize visual grouping
+
+**Composition**:
+
+- Canvas divided into three equal sections for each circle
+- 30-40% overlap area in center for intersection
+- Ample negative space between elements
+- Clear visual boundaries between overlapping regions
+
+### Style Guidelines (Cyberpunk Neon)
+
+**Color Palette**:
+
+- Primary: Neon pink (#FF00FF), cyan (#00FFFF), electric blue
+- Background: Deep black (#0A0A0A), dark purple gradients
+- Accents: Neon glow effects, chrome reflections
+
+**Visual Elements**:
+
+- Glowing neon outlines on all circle boundaries
+- Dark atmospheric backgrounds with subtle grid patterns
+- Digital glitch effects on text
+- Circuit patterns along connection lines
+- Holographic elements in intersection zone
+- Rain and reflections on edges
+
+**Typography**:
+
+- Glowing neon text (cyan for primary labels, pink for emphasis)
+- Digital/tech monospace fonts
+- Subtle flickering effects on key terms
+- Outlined glow letters for main title
+- All caps for section headers
+
+**Effects**:
+
+- Neon glow (2-3px bloom) around all text and shapes
+- Gradient fills with 40-60% opacity
+- Scanline overlay at 10% opacity
+- Chromatic aberration on text edges
+
+---
+
+## Part 3: Content Structure Prompt (Text Requirements + Content)
+
+### Main Title
+
+**MAJOR INCIDENT DEFINITION**
+*Highest Severity Level (S1/P1/Critical)*
+
+### Three Venn Circles Content
+
+**Circle 1: Business Impact**
+
+- Total Service Outage
+- Critical Feature Failure
+- Data Corruption/Loss
+- Security Breach
+- Regulatory Compliance Risk
+- High-Impact SLA Breach
+
+**Circle 2: Incident Response**
+
+- Immediate Actions (0-15 min)
+  - Automated Monitoring Alerts
+  - Incident Commander Assigned
+  - Major Incident Bridge
+  - Customer Communication
+- Investigation & Mitigation (15-60 min)
+  - Root Cause Analysis
+  - Rollback/Hotfix
+  - Failover to Backup
+  - Workarounds
+- Recovery & Post-Mortem (1-24h+)
+  - Full Service Restored
+  - RCA Report Published
+  - Long-Term Fixes
+
+**Circle 3: Prevention Measures**
+
+- High Availability Architecture
+- Chaos Engineering & Load Testing
+- Real-Time Monitoring & Alerting
+- Automated Rollbacks
+- Strict Change Management
+- Security Hardening & Compliance
+
+### Central Intersection (All Three Circles)
+
+The intersection represents the critical overlap showing that Major Incidents require:
+
+- Cross-team collaboration
+- Immediate response (15-30 min SLA)
+- Significant business impact
+- Coordinated resolution
+
+### Key Criteria Table (Bottom Section)
+
+| Criteria | Description |
+|----------|-------------|
+| Scope | Multiple tenants/customers, entire platform |
+| Business Criticality | Severe financial/reputational impact |
+| Resolution Time | Immediate, 15-30 min acknowledgment |
+| Workload Impact | Cloud Ops, DevOps, Security, Support |
+| Regulatory Compliance | Legal/security obligations at risk |
+
+### Footer Text
+
+"Requires Swift, Coordinated Response to Minimize Downtime"
+
+---
+
+## Visual Composition for 16:9
+
+- **Top Section** (10%): Title with neon glow effect
+- **Middle Section** (70%): Three overlapping circles with content
+- **Bottom Section** (20%): Criteria table in minimalist style
+
+### Color Assignment per Circle
+
+- Circle 1 (Business Impact): Cyan (#00FFFF) neon outline
+- Circle 2 (Incident Response): Neon Pink (#FF00FF) neon outline
+- Circle 3 (Prevention): Electric Blue (#0080FF) neon outline
+- Intersection: White glow with purple tint
+- Background: Deep black (#0A0A0A) with dark purple gradient
+
+---
+
 **Note**: Do not generate the actual image. Output only the prompt for image generation.

Hermes/xingzhi/musicbrainz_api_test.py

@@ -0,0 +1,25 @@
+import requests
+
+# 获取曲目信息的函数
+
+def get_recording_info(mbid):
+    url = f'https://musicbrainz.org/ws/2/recording/{mbid}?fmt=json'
+    response = requests.get(url)
+    if response.status_code == 200:
+        return response.json()  # 返回曲目信息
+    else:
+        return {'error': 'Not Found', 'status_code': response.status_code}
+
+# 测试 MBID 列表
+mbids = [
+    'a34ecc5d-388e-40fb-a2a2-5354db8fdfaa',  # 示例 MBID
+    'c6f24108-1f3f-4bf7-a52d-818ec956c2de',
+    'cd2d5cc0-7cfa-4f7c-99f5-4fd05b07873c'
+]
+
+# 循环查询每个 MBID
+for mbid in mbids:
+    info = get_recording_info(mbid)
+    print(f'情報for MBID {mbid}:')
+    print(info)
+    print('-' * 40)  # 分隔线

Hermes/xingzhi/wiki-sync-circular-infographic-prompts-2026-04-20.md

@@ -1,256 +1,256 @@
-# Wiki Sync 循环流程信息图 - 提示词
-
-> 日期：2026-04-20
-> 布局：circular-flow
-> 风格：chalkboard
-
----
-
-## 一、系统提示词
-
-```
-Create a professional infographic following these specifications:
-
-## Image Specifications
-
-- **Type**: Infographic
-- **Layout**: circular-flow
-- **Style**: chalkboard
-- **Aspect Ratio**: 16:9 (landscape)
-- **Language**: 中文 (Simplified Chinese)
-
-## Core Principles
-
-- Follow the layout structure precisely for information architecture
-- Apply style aesthetics consistently throughout
-- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
-- Keep information concise, highlight keywords and core concepts
-- Use ample whitespace for visual clarity
-- Maintain clear visual hierarchy
-
-## Text Requirements
-
-- All text must match the specified style treatment
-- Main titles should be prominent and readable
-- Key concepts should be visually emphasized
-- Labels should be clear and appropriately sized
-- Use Chinese for all text content
-
-## Layout Guidelines
-
-### Circular Flow Layout
-- 循环流程：展示持续运行的过程
-- 环形排列：所有节点围绕中心点均布
-- 方向箭头：显示顺时针或逆时针流动方向
-- 无明确起点/终点（持续循环）
-- 中心可放置核心概念或系统名称
-
-### Wiki Sync 循环结构
-1. 9个步骤节点均匀分布在圆环上
-2. 循环箭头连接各步骤
-3. 中心显示 "Wiki Sync" 系统名称
-4. 标题位于圆环上方
-
-## Style Guidelines
-
-### Chalkboard Style
-- 背景：黑板黑 (#1A1A1A) 或深绿黑板色 (#1C2B1C)
-- 纹理：真实黑板质感，伴有划痕、粉尘、橡皮擦痕迹
-- 线条：手绘粉笔质感，不完美的sketchy线条
-- 颜色：仅使用粉笔色板
-- 字体：手绘粉笔字体
-- 装饰：手绘星星、下划线、箭头、圆圈、问号
-```
-
----
-
-## 二、风格锁定提示词
-
-```
-## Style Lock — 必须遵守
-
-本信息图使用 chalkboard（粉笔黑板）风格。
-
-### 背景
-- 颜色：#1C2B1C（深绿黑板）或 #1A1A1A（黑板黑）
-- 纹理：真实黑板纹理，细微划痕、粉尘粒子、橡皮擦痕迹
-- 木质框边（可选）：手绘木纹线条
-
-### 粉笔线条质量
-- 所有线条必须是手绘的、不完美的sketchy风格
-- 轻微抖动和歪斜
-- 不要干净的矢量线条
-
-### 颜色色板（严格使用）
-| 角色 | 颜色 | Hex |
-|-----|------|-----|
-| 主文字/轮廓 | 粉笔白 | #F5F5F5 |
-| 高亮/下划线 | 粉笔黄 | #FFE566 |
-| 次要高亮 | 粉笔粉 | #FF9999 |
-| 技术元素/图表 | 粉笔蓝 | #66B3FF |
-| 成功/自然 | 粉笔绿 | #90EE90 |
-| 警告/能量 | 粉笔橙 | #FFB366 |
-| 木框 | 棕色 | #8B6914 |
-
-### 装饰元素
-- 5-7角手绘星星（不规则）
-- 手绘波浪下划线
-- 手绘箭头（歪斜的笔触 + 箭头）
-- 角落的粉笔问号、圆圈
-- 底部散落的粉笔粉末
-
-### 禁止出现
-- 渐变
-- 完美几何形状
-- 写实元素
-- 扁平数字图标
-
-### 布局规则（circular-flow）
-- 9个节点均布于圆环上
-- 顺时针方向箭头连接各节点
-- 中心放置核心概念
-- 标题在圆环顶部
-
-## Layout Guidelines - Circular Flow
-
-### 环形结构
-- 步骤节点：9个步骤均匀分布在圆周上
-- 方向：顺时针流动的箭头
-- 中心：系统名称 "Wiki Sync"
-- 标题：信息图主标题在顶部
-
-### 节点内容
-每个节点包含：
-- 步骤编号（圆形框）
-- 步骤名称（粉笔白大字）
-- 简要描述（1-2行，较小字体）
-- 对应图标或符号
-
-### 节点顺序（Wiki Sync 流程）
-1. Cron 触发
-2. 加载 skill
-3. 启动 TMUX
-4. 启动 Claude Code
-5. 发送任务指令
-6. 执行 9 步 ingest
-7. 解析 SLUG
-8. 更新 manifest
-9. Telegram 通知
-```
-
----
-
-## 三、具体内容提示词
-
-```
-INFOGRAPHIC: Wiki Sync 系统循环流程
-
-## 主标题
-- 位置：圆环顶部居中
-- 内容："Wiki Sync 自动同步系统"
-- 字体：大型粉笔白（#F5F5F5）手写体
-- 装饰：粉笔黄（#FFE566）双下划线（波浪形手绘）
-- 两侧：粉笔粉（#FF9999）小星星装饰
-
-## 圆环中心
-- 圆形区域放置系统图标或 "WS" 字样
-- 颜色：粉笔蓝（#66B3FF）轮廓
-- 背景：深绿黑板色 #1C2B1C
-
-## 循环节点（顺时针排列）
-
-### 节点 1：Cron 触发
-- 编号圆圈：粉笔黄
-- 步骤名：① Cron 触发
-- 描述：定时器启动，每15分钟
-- 图标：时钟或定时器手绘
-
-### 节点 2：加载 Skill
-- 编号圆圈：粉笔黄
-- 步骤名：② 加载 Skill
-- 描述：加载 llm-wiki-sync
-- 图标：齿轮或技能图标
-
-### 节点 3：检查待摄
-- 编号圆圈：粉笔粉
-- 步骤名：③ 待摄检查
-- 描述：sync.py --check
-- 图标：文档或清单
-
-### 节点 4：启动 TMUX
-- 编号圆圈：粉笔粉
-- 步骤名：④ 启动 TMUX
-- 描述：创建会话
-- 图标：终端图标
-
-### 节点 5：Claude Code
-- 编号圆圈：粉笔蓝
-- 步骤名：⑤ Claude Code
-- 描述：bypassPermissions
-- 图标：AI/机器人
-
-### 节点 6：执行 Ingest
-- 编号圆圈：粉笔蓝
-- 步骤名：执行 Ingest
-- 描述：9步标准流程
-- 图标：输入箭头
-
-### 节点 7：解析 SLUG
-- 编号圆圈：粉笔绿
-- 步骤名：⑦ 解析 SLUG
-- 描述：从输出提取标识符
-- 图标：标签/条形码
-
-### 节点 8：更新 Manifest
-- 编号圆圈：粉笔绿
-- 步骤名：更新 Manifest
-- 描述：写入 JSON 状态
-- 图标：数据保存
-
-### 节点 9：Telegram 通知
-- 编号圆圈：粉笔橙
-- 步骤名： Telegram 通知
-- 描述：发送同步结果
-- 图标：消息气泡
-
-## 循环箭头
-- 颜色：粉笔蓝（#66B3FF）
-- 风格：手绘歪斜箭头
-- 方向：顺时针
-- 每两个节点之间
-
-## 底部装饰
-- 左侧：粉笔粉 "Claude Code Agent"
-- 右侧：粉笔黄 "持续运行 ∞"
-- 底部边缘：散落粉笔粉末痕迹
-- 角落：粉笔问号、圆圈装饰
-
-## 整体效果
-- 深绿黑板背景 (#1C2B1C)
-- 所有文字使用粉笔质感手写体
-- 节点框使用手绘不规则圆形/圆角矩形
-- 箭头使用手绘歪斜线条
-- 保持信息密度，流程清晰
-```
-
----
-
-## 四、使用说明
-
-```
-使用方法：
-
-1. 使用支持 circular-flow 布局 + chalkboard 风格的 AI 图像生成工具
-2. 建议比例：16:9 (landscape)
-3. 语言：中文（简体）
-4. 参考本文件的三部分提示词组合使用
-
-提示词组合优先级：
-1. 第一部分（系统提示词）- 基础规范
-2. 第二部分（风格锁定）- 必须遵守的约束
-3. 具体内容提示词 - 实际图像内容
-```
-
----
-
+# Wiki Sync 循环流程信息图 - 提示词
+
+> 日期：2026-04-20
+> 布局：circular-flow
+> 风格：chalkboard
+
+---
+
+## 一、系统提示词
+
+```
+Create a professional infographic following these specifications:
+
+## Image Specifications
+
+- **Type**: Infographic
+- **Layout**: circular-flow
+- **Style**: chalkboard
+- **Aspect Ratio**: 16:9 (landscape)
+- **Language**: 中文 (Simplified Chinese)
+
+## Core Principles
+
+- Follow the layout structure precisely for information architecture
+- Apply style aesthetics consistently throughout
+- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
+- Keep information concise, highlight keywords and core concepts
+- Use ample whitespace for visual clarity
+- Maintain clear visual hierarchy
+
+## Text Requirements
+
+- All text must match the specified style treatment
+- Main titles should be prominent and readable
+- Key concepts should be visually emphasized
+- Labels should be clear and appropriately sized
+- Use Chinese for all text content
+
+## Layout Guidelines
+
+### Circular Flow Layout
+- 循环流程：展示持续运行的过程
+- 环形排列：所有节点围绕中心点均布
+- 方向箭头：显示顺时针或逆时针流动方向
+- 无明确起点/终点（持续循环）
+- 中心可放置核心概念或系统名称
+
+### Wiki Sync 循环结构
+1. 9个步骤节点均匀分布在圆环上
+2. 循环箭头连接各步骤
+3. 中心显示 "Wiki Sync" 系统名称
+4. 标题位于圆环上方
+
+## Style Guidelines
+
+### Chalkboard Style
+- 背景：黑板黑 (#1A1A1A) 或深绿黑板色 (#1C2B1C)
+- 纹理：真实黑板质感，伴有划痕、粉尘、橡皮擦痕迹
+- 线条：手绘粉笔质感，不完美的sketchy线条
+- 颜色：仅使用粉笔色板
+- 字体：手绘粉笔字体
+- 装饰：手绘星星、下划线、箭头、圆圈、问号
+```
+
+---
+
+## 二、风格锁定提示词
+
+```
+## Style Lock — 必须遵守
+
+本信息图使用 chalkboard（粉笔黑板）风格。
+
+### 背景
+- 颜色：#1C2B1C（深绿黑板）或 #1A1A1A（黑板黑）
+- 纹理：真实黑板纹理，细微划痕、粉尘粒子、橡皮擦痕迹
+- 木质框边（可选）：手绘木纹线条
+
+### 粉笔线条质量
+- 所有线条必须是手绘的、不完美的sketchy风格
+- 轻微抖动和歪斜
+- 不要干净的矢量线条
+
+### 颜色色板（严格使用）
+| 角色 | 颜色 | Hex |
+|-----|------|-----|
+| 主文字/轮廓 | 粉笔白 | #F5F5F5 |
+| 高亮/下划线 | 粉笔黄 | #FFE566 |
+| 次要高亮 | 粉笔粉 | #FF9999 |
+| 技术元素/图表 | 粉笔蓝 | #66B3FF |
+| 成功/自然 | 粉笔绿 | #90EE90 |
+| 警告/能量 | 粉笔橙 | #FFB366 |
+| 木框 | 棕色 | #8B6914 |
+
+### 装饰元素
+- 5-7角手绘星星（不规则）
+- 手绘波浪下划线
+- 手绘箭头（歪斜的笔触 + 箭头）
+- 角落的粉笔问号、圆圈
+- 底部散落的粉笔粉末
+
+### 禁止出现
+- 渐变
+- 完美几何形状
+- 写实元素
+- 扁平数字图标
+
+### 布局规则（circular-flow）
+- 9个节点均布于圆环上
+- 顺时针方向箭头连接各节点
+- 中心放置核心概念
+- 标题在圆环顶部
+
+## Layout Guidelines - Circular Flow
+
+### 环形结构
+- 步骤节点：9个步骤均匀分布在圆周上
+- 方向：顺时针流动的箭头
+- 中心：系统名称 "Wiki Sync"
+- 标题：信息图主标题在顶部
+
+### 节点内容
+每个节点包含：
+- 步骤编号（圆形框）
+- 步骤名称（粉笔白大字）
+- 简要描述（1-2行，较小字体）
+- 对应图标或符号
+
+### 节点顺序（Wiki Sync 流程）
+1. Cron 触发
+2. 加载 skill
+3. 启动 TMUX
+4. 启动 Claude Code
+5. 发送任务指令
+6. 执行 9 步 ingest
+7. 解析 SLUG
+8. 更新 manifest
+9. Telegram 通知
+```
+
+---
+
+## 三、具体内容提示词
+
+```
+INFOGRAPHIC: Wiki Sync 系统循环流程
+
+## 主标题
+- 位置：圆环顶部居中
+- 内容："Wiki Sync 自动同步系统"
+- 字体：大型粉笔白（#F5F5F5）手写体
+- 装饰：粉笔黄（#FFE566）双下划线（波浪形手绘）
+- 两侧：粉笔粉（#FF9999）小星星装饰
+
+## 圆环中心
+- 圆形区域放置系统图标或 "WS" 字样
+- 颜色：粉笔蓝（#66B3FF）轮廓
+- 背景：深绿黑板色 #1C2B1C
+
+## 循环节点（顺时针排列）
+
+### 节点 1：Cron 触发
+- 编号圆圈：粉笔黄
+- 步骤名：① Cron 触发
+- 描述：定时器启动，每15分钟
+- 图标：时钟或定时器手绘
+
+### 节点 2：加载 Skill
+- 编号圆圈：粉笔黄
+- 步骤名：② 加载 Skill
+- 描述：加载 llm-wiki-sync
+- 图标：齿轮或技能图标
+
+### 节点 3：检查待摄
+- 编号圆圈：粉笔粉
+- 步骤名：③ 待摄检查
+- 描述：sync.py --check
+- 图标：文档或清单
+
+### 节点 4：启动 TMUX
+- 编号圆圈：粉笔粉
+- 步骤名：④ 启动 TMUX
+- 描述：创建会话
+- 图标：终端图标
+
+### 节点 5：Claude Code
+- 编号圆圈：粉笔蓝
+- 步骤名：⑤ Claude Code
+- 描述：bypassPermissions
+- 图标：AI/机器人
+
+### 节点 6：执行 Ingest
+- 编号圆圈：粉笔蓝
+- 步骤名：执行 Ingest
+- 描述：9步标准流程
+- 图标：输入箭头
+
+### 节点 7：解析 SLUG
+- 编号圆圈：粉笔绿
+- 步骤名：⑦ 解析 SLUG
+- 描述：从输出提取标识符
+- 图标：标签/条形码
+
+### 节点 8：更新 Manifest
+- 编号圆圈：粉笔绿
+- 步骤名：更新 Manifest
+- 描述：写入 JSON 状态
+- 图标：数据保存
+
+### 节点 9：Telegram 通知
+- 编号圆圈：粉笔橙
+- 步骤名： Telegram 通知
+- 描述：发送同步结果
+- 图标：消息气泡
+
+## 循环箭头
+- 颜色：粉笔蓝（#66B3FF）
+- 风格：手绘歪斜箭头
+- 方向：顺时针
+- 每两个节点之间
+
+## 底部装饰
+- 左侧：粉笔粉 "Claude Code Agent"
+- 右侧：粉笔黄 "持续运行 ∞"
+- 底部边缘：散落粉笔粉末痕迹
+- 角落：粉笔问号、圆圈装饰
+
+## 整体效果
+- 深绿黑板背景 (#1C2B1C)
+- 所有文字使用粉笔质感手写体
+- 节点框使用手绘不规则圆形/圆角矩形
+- 箭头使用手绘歪斜线条
+- 保持信息密度，流程清晰
+```
+
+---
+
+## 四、使用说明
+
+```
+使用方法：
+
+1. 使用支持 circular-flow 布局 + chalkboard 风格的 AI 图像生成工具
+2. 建议比例：16:9 (landscape)
+3. 语言：中文（简体）
+4. 参考本文件的三部分提示词组合使用
+
+提示词组合优先级：
+1. 第一部分（系统提示词）- 基础规范
+2. 第二部分（风格锁定）- 必须遵守的约束
+3. 具体内容提示词 - 实际图像内容
+```
+
+---
+
 *Generated: 2026-04-20*

Hermes/xingzhi/wiki-sync-infographic-prompts-2026-04-20.md

@@ -1,148 +1,148 @@
-# Wiki Sync 系统信息图提示词
-
-> 生成日期：2026-04-20
-> 用途：为 LLM Wiki 自动化同步系统生成信息图
-
----
-
-## 第一部分：系统提示词（System Prompt）
-
-```
-Create a professional infographic following these specifications:
-
-## Image Specifications
-- Type: Infographic
-- Layout: hub-spoke
-- Style: corporate-memphis
-- Aspect Ratio: 16:9
-- Language: 简体中文
-
-## Core Principles
-- Follow the hub-spoke layout structure precisely for information architecture
-- Apply corporate-memphis style aesthetics consistently throughout
-- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
-- Keep information concise, highlight keywords and core concepts
-- Use ample whitespace for visual clarity
-- Maintain clear visual hierarchy
-
-## Text Requirements
-- All text must match the specified style treatment
-- Main titles should be prominent and readable
-- Key concepts should be visually emphasized
-- Labels should be clear and appropriately sized
-- Use simplified Chinese for all text content
-
-## Layout Guidelines
-- Prominent central hub at the center of the canvas
-- Clear spoke lines radiating outward from center
-- Nodes at spoke ends with consistent styling
-- Even distribution of spokes around the hub
-- Icons representing each spoke item
-- Brief labels near each node
-
-## Style Guidelines
-- Flat vector illustration style
-- Bright, saturated colors: purple, orange, teal, yellow
-- White or light pastel background
-- Disproportionate human figures (optional)
-- Abstract geometric shapes and floating elements
-- Solid fills without outlines
-- Clean sans-serif typography with bold headings
-- Professional but friendly appearance
-
----
-
-Generate the infographic based on the content below:
-
-Text labels (in 简体中文):
-```
-
----
-
-## 第二部分：风格锁定提示词（Style Lock Prompt）
-
-```
-## 布局规范（hub-spoke）
-- 中心：突出显示核心主题"Wiki Sync 自动化同步系统"
-- 辐射：6条均匀分布的辐条连接中心与外圈节点
-- 节点：每个辐条末端放置一个组件节点，使用统一的图标风格
-- 连接：辐条使用浅灰色线条，带有标签
-
-## 视觉元素（corporate-memphis）
-- 背景：纯白色或浅奶油色 (#FFF8F0)
-- 主色：明快的紫色 (#8B5CF6)、橙色 (#F97316)、青绿色 (#14B8A6)、黄色 (#FBBF24)
-- 图形：扁平化几何图形填充，无描边
-- 人物：抽象的不成比例人物剪影
-- 装饰：漂浮的几何元素（圆形、方形、三角形）
-- 字体：思源黑体或类似无衬线字体，标题加粗
-
-## 图标风格
-- 简化的线框图标
-- 保持一致的线条粗细（2-3px）
-- 圆角处理
-```
-
----
-
-## 第三部分：具体内容提示词（Content Prompt）
-
-```
-INFOGRAPHIC: Wiki Sync 自动化同步系统
-
-使用 hub-spoke 布局和 corporate-memphis 风格创建信息图。
-
-## 中心主题（Hub）
-- 主标题：Wiki Sync 系统
-- 副标题：LLM Wiki 自动化同步解决方案
-
-## 六个辐条节点（Spokes）
-
-### 1. 核心组件（Core）
-- 图标：齿轮/工具箱
-- 标签：sync.py CLI
-- 描述：manifest 管理、文件追踪
-
-### 2. 工作流（Workflow）
-- 图标：流程图/箭头
-- 标签：llm-wiki-sync
-- 描述：9步标准化执行流程
-
-### 3. 定时任务（Schedule）
-- 图标：时钟/日历
-- 标签：Cron Job
-- 描述：15分钟自动触发
-
-### 4. 状态追踪（Tracking）
-- 图标：清单/勾选
-- 标签：manifest.json
-- 描述：181篇文件状态记录
-
-### 5. 交互模式（Interaction）
-- 图标：终端/命令行
-- 标签：TMUX + Claude
-- 描述：bypassPermissions 启动
-
-### 6. 交付通知（Delivery）
-- 图标：消息/ telegram
-- 标签：Telegram Bot
-- 描述：5038825565 消息推送
-
-## 底部补充信息
-- 当前状态：已摄入 16 篇 / 待摄入 165 篇
-- 关键规则：顺序执行 + SLUG 解析
-```
-
----
-
-## 使用说明
-
-1. 将 **第一部分** 作为系统提示词设置到图像生成模型会话开始时
-2. 将 **第二部分** 作为风格参考添加到提示词中
-3. 将 **第三部分** 作为具体内容提示词发送给图像生成模型
-4. 生成的图像应呈现：
-   - 白色/浅奶油色背景
-   - 中心为"Wiki Sync 系统"标题
-   - 6个均匀分布的辐条节点
-   - 明快的紫、橙、青、黄配色
-   - 扁平化几何图标
+# Wiki Sync 系统信息图提示词
+
+> 生成日期：2026-04-20
+> 用途：为 LLM Wiki 自动化同步系统生成信息图
+
+---
+
+## 第一部分：系统提示词（System Prompt）
+
+```
+Create a professional infographic following these specifications:
+
+## Image Specifications
+- Type: Infographic
+- Layout: hub-spoke
+- Style: corporate-memphis
+- Aspect Ratio: 16:9
+- Language: 简体中文
+
+## Core Principles
+- Follow the hub-spoke layout structure precisely for information architecture
+- Apply corporate-memphis style aesthetics consistently throughout
+- If content involves sensitive or copyrighted figures, create stylistically similar alternatives
+- Keep information concise, highlight keywords and core concepts
+- Use ample whitespace for visual clarity
+- Maintain clear visual hierarchy
+
+## Text Requirements
+- All text must match the specified style treatment
+- Main titles should be prominent and readable
+- Key concepts should be visually emphasized
+- Labels should be clear and appropriately sized
+- Use simplified Chinese for all text content
+
+## Layout Guidelines
+- Prominent central hub at the center of the canvas
+- Clear spoke lines radiating outward from center
+- Nodes at spoke ends with consistent styling
+- Even distribution of spokes around the hub
+- Icons representing each spoke item
+- Brief labels near each node
+
+## Style Guidelines
+- Flat vector illustration style
+- Bright, saturated colors: purple, orange, teal, yellow
+- White or light pastel background
+- Disproportionate human figures (optional)
+- Abstract geometric shapes and floating elements
+- Solid fills without outlines
+- Clean sans-serif typography with bold headings
+- Professional but friendly appearance
+
+---
+
+Generate the infographic based on the content below:
+
+Text labels (in 简体中文):
+```
+
+---
+
+## 第二部分：风格锁定提示词（Style Lock Prompt）
+
+```
+## 布局规范（hub-spoke）
+- 中心：突出显示核心主题"Wiki Sync 自动化同步系统"
+- 辐射：6条均匀分布的辐条连接中心与外圈节点
+- 节点：每个辐条末端放置一个组件节点，使用统一的图标风格
+- 连接：辐条使用浅灰色线条，带有标签
+
+## 视觉元素（corporate-memphis）
+- 背景：纯白色或浅奶油色 (#FFF8F0)
+- 主色：明快的紫色 (#8B5CF6)、橙色 (#F97316)、青绿色 (#14B8A6)、黄色 (#FBBF24)
+- 图形：扁平化几何图形填充，无描边
+- 人物：抽象的不成比例人物剪影
+- 装饰：漂浮的几何元素（圆形、方形、三角形）
+- 字体：思源黑体或类似无衬线字体，标题加粗
+
+## 图标风格
+- 简化的线框图标
+- 保持一致的线条粗细（2-3px）
+- 圆角处理
+```
+
+---
+
+## 第三部分：具体内容提示词（Content Prompt）
+
+```
+INFOGRAPHIC: Wiki Sync 自动化同步系统
+
+使用 hub-spoke 布局和 corporate-memphis 风格创建信息图。
+
+## 中心主题（Hub）
+- 主标题：Wiki Sync 系统
+- 副标题：LLM Wiki 自动化同步解决方案
+
+## 六个辐条节点（Spokes）
+
+### 1. 核心组件（Core）
+- 图标：齿轮/工具箱
+- 标签：sync.py CLI
+- 描述：manifest 管理、文件追踪
+
+### 2. 工作流（Workflow）
+- 图标：流程图/箭头
+- 标签：llm-wiki-sync
+- 描述：9步标准化执行流程
+
+### 3. 定时任务（Schedule）
+- 图标：时钟/日历
+- 标签：Cron Job
+- 描述：15分钟自动触发
+
+### 4. 状态追踪（Tracking）
+- 图标：清单/勾选
+- 标签：manifest.json
+- 描述：181篇文件状态记录
+
+### 5. 交互模式（Interaction）
+- 图标：终端/命令行
+- 标签：TMUX + Claude
+- 描述：bypassPermissions 启动
+
+### 6. 交付通知（Delivery）
+- 图标：消息/ telegram
+- 标签：Telegram Bot
+- 描述：5038825565 消息推送
+
+## 底部补充信息
+- 当前状态：已摄入 16 篇 / 待摄入 165 篇
+- 关键规则：顺序执行 + SLUG 解析
+```
+
+---
+
+## 使用说明
+
+1. 将 **第一部分** 作为系统提示词设置到图像生成模型会话开始时
+2. 将 **第二部分** 作为风格参考添加到提示词中
+3. 将 **第三部分** 作为具体内容提示词发送给图像生成模型
+4. 生成的图像应呈现：
+   - 白色/浅奶油色背景
+   - 中心为"Wiki Sync 系统"标题
+   - 6个均匀分布的辐条节点
+   - 明快的紫、橙、青、黄配色
+   - 扁平化几何图标
    - 思源黑体加粗标题

Hermes/xingzhi/wiki-sync-setup-2026-04-16.md

@@ -1,272 +1,272 @@
-# Wiki Sync 系统搭建完整记录
-
-> 日期：2026-04-16
-> 作者：Hermes Agent
-> 用途：记录 llm-wiki-agent 自动化同步系统的完整搭建过程
-
----
-
-## 背景
-
-用户希望将 Obsidian vault 中的 markdown 文件批量摄入到 LLM Wiki（Karpathy's LLM Wiki）中。原有方案是手动逐篇执行，效率低下。本次目标：搭建自动化系统，实现定时自动摄入。
-
----
-
-## 系统架构
-
-### 架构图
-![Wiki Sync Architecture](IMG-20260418081458052.png)
-
-
-### 同步时序图
-
-![Wiki Sync Sequence Diagram](IMG-20260418081458100.png)
-
-### Ingest 9 步流程图
-![[IMG-20260418081458161.png]]
-
-
-### 核心组件
-
-| 组件 | 位置 | 职责 |
-|------|------|------|
-| **llm-wiki-sync skill** | `~/.hermes/skills/research/llm-wiki-sync/SKILL.md` | 执行模板和工作流定义 |
-| **sync.py** | `/Users/weishen/Git/llm-wiki-agent/tools/sync.py` | manifest 管理、CLI 工具 |
-| **manifest.json** | `/Users/weishen/Git/llm-wiki-agent/tools/manifest.json` | 文件状态追踪（181篇） |
-| **Hermes Cron Job** | 内部调度器 | 每 15 分钟触发一次摄入 |
-
-
-## 一、初始探索（手动执行阶段）
-
-### 1.1 发现 raw 文件
-
-- 路径：`/Users/weishen/Workspace/nexus/raw/`（Obsidian vault）
-- 通过 symlink 挂载到：`/Users/weishen/Git/llm-wiki-agent/raw/`
-- 文件数：182 个 markdown 文件
-
-### 1.2 创建 manifest.json
-
-手动扫描 raw 目录，生成初始 manifest：
-
-```
-# 扫描 raw 目录，提取 frontmatter
-for md in Path("raw").glob("**/*.md"):
-    # 提取 title, ingested, slug 等字段
-    manifest.append({...})
-```
-
-### 1.3 测试 /wiki-ingest
-
-Claude Code 的 `/wiki-ingest` 命令执行 9 步流程：
-读取 source 文档
-读取 wiki/index.md 和 overview.md
-生成 wiki/sources/<slug>.md
-更新 wiki/index.md
-更新 wiki/overview.md
-创建/更新 Entity 页面
-创建/更新 Concept 页面
-检测并记录冲突
-追加 wiki/log.md
-
-##  二、遇到的问题和解决方案
-
-### 问题 1：stdin 交互问题
-
-**现象**：`claude --print` 模式在非交互环境下无法正常工作，stdin 被占用导致命令卡住。
-
-**解决方案**：使用 TMUX 交互模式启动 Claude Code：
-
-```bash
-# 启动 TMUX session
-tmux new-session -d -s wiki-ingest "cd /Users/weishen/Git/llm-wiki-agent && claude --permission-mode bypassPermissions"
-
-# 等待启动完成
-sleep 8 && tmux send-keys -t wiki-ingest Enter
-
-# 发送任务
-tmux send-keys -t wiki-ingest "请执行任务..."
-```
-
-### 问题 2：manifest slug 与实际文件不匹配
-
-**现象**：manifest 中记录的 slug 和 source_path 与 LLM 实际生成的文件名不一致。
-
-**原因**：LLM 根据内容自动生成 slug，而不是简单从文件名转换。
-
-**解决方案**：要求 LLM 在任务完成后输出 `SLUG: xxx`，然后 Hermes 解析并更新 manifest：
-
-```python
-def parse_slug_from_output(output: str) -> str:
-    """从 LLM 输出中解析实际使用的 slug"""
-    match = re.search(r'SLUG:\s*([^\s]+)', output)
-    return match.group(1) if match else None
-```
-
-### 问题 3：170 条 ingest 错误记录
-
-**现象**：manifest 中有 170 条记录标记为 `ingested=true` 但实际未成功。
-
-**原因**：早期测试时使用 `--print` 模式失败但仍标记为成功。
-
-**解决方案**：使用 `sync.py --reset-failed` 清理错误状态。
-
----
-
-## 三、自建组件
-
-### 3.1 sync.py CLI 工具
-
-**位置**：`/Users/weishen/Git/llm-wiki-agent/tools/sync.py`
-
-**功能**：
-- `--pending`：列出待摄取文件
-- `--check`：预览变化
-- `--reset-failed`：重置失败记录
-- `--bootstrap`：从现有 wiki sources 重建 manifest
-
-**核心函数**：
-```python
-def get_pending_files() -> list:
-    """返回所有未摄入的文件"""
-
-def mark_ingested(file_path: str, slug: str):
-    """标记文件为已摄入"""
-
-def reset_failed():
-    """重置所有失败状态"""
-
-def parse_slug_from_output(output: str) -> str:
-    """从 LLM 输出解析 SLUG"""
-```
-
-### 3.2 llm-wiki-sync skill
-
-**位置**：`~/.hermes/skills/research/llm-wiki-sync/SKILL.md`
-
-**版本**：1.4.0
-
-**核心内容**：
-- **角色分工**：Hermes 编排流程 → Claude Code 执行 ingest
-- **关键设计**：TMUX 交互模式、顺序执行、SLUG 输出要求
-- **TMUX 执行流程**：完整的启动、发送任务、监控、清理流程
-- **Ingest Workflow 9 步**：标准化执行步骤
-- **Cron Job 自动化**：使用 Hermes 原生 cron job
-
-### 3.3 Hermes Cron Job
-
-**创建命令**：
-```bash
-cronjob create \
-  --name wiki-sync-15min \
-  --skill llm-wiki-sync \
-  --schedule "*/15 * * * *" \
-  --repeat 999999 \
-  --deliver "telegram:5038825565" \
-  --prompt "使用 llm-wiki-sync 技能执行一次 wiki 文章摄入..."
-```
-
-**配置**：
-- Job ID：`98265b6998c5`
-- Schedule：`*/15 * * * *`（每 15 分钟）
-- 交付方式：Telegram（ID: 5038825565）
-- 技能：llm-wiki-sync
-
----
-
-## 四、执行流程（自动化阶段）
-
-### 4.1 Cron Job 触发
-
-1. 每 15 分钟（00, 15, 30, 45 分）触发
-2. 加载 llm-wiki-sync skill
-3. 执行 skill 中的 prompt
-
-### 4.2 实际执行步骤
-
-```
-1. 加载 llm-wiki-sync 技能
-2. 检查 manifest（python tools/sync.py --pending）
-3. 启动 TMUX session
-4. 启动 Claude Code（bypassPermissions）
-5. 发送任务指令（含 SLUG 输出要求）
-6. 监控任务完成（tmux capture-pane）
-7. 解析 SLUG 并更新 manifest.json
-8. 清理 TMUX session
-9. 输出结果（自动发往 Telegram）
-```
-
-### 4.3 示例输出
-
-```
-## Wiki Sync 完成
-
-| 项目 | 结果 |
-|------|------|
-| 摄入文件 | raw/Home Office/用Docker中安装Navidrome.md |
-| Slug | 用docker中安装navidrome |
-| 状态 | ✅ 已完成 |
-
-新增页面：
-- wiki/sources/用docker中安装navidrome.md
-- wiki/entities/Navidrome.md
-- wiki/concepts/Docker-Compose.md
-
-manifest 已更新：ingested: true
-剩余待摄入：165 篇
-```
-
----
-
-## 五、当前状态
-
-| 指标 | 值 |
-|------|-----|
-| 总文件数 | 181 篇 |
-| 已摄入 | 16 篇 |
-| 待摄入 | 165 篇 |
-| Cron Job 状态 | 运行中 |
-| 下次运行 | 18:15:00 |
-
----
-
-## 六、关键命令速查
-
-```bash
-# 检查待摄取文件
-cd /Users/weishen/Git/llm-wiki-agent && python tools/sync.py --pending
-
-# 预览变化
-python tools/sync.py --check
-
-# 重置失败记录
-python tools/sync.py --reset-failed
-
-# 查看 cron job 状态
-cronjob --list
-
-# 手动触发 cron job
-cronjob --run <job_id>
-```
-
----
-
-## 七、注意事项
-
-1. **必须使用 TMUX**：不能用 subprocess 或 --print 模式
-2. **必须顺序执行**：并发会触发 529 rate limit
-3. **必须解析 SLUG**：LLM 输出的实际 slug 用于更新 manifest
-4. **交付方式**：使用 `telegram:5038825565` 发给用户
-5. **保留 orphan**：不删除任何原始数据
-
----
-
-## 八、扩展方向
-
-- [ ] 添加错误重试机制（529 时等待后重试）
-- [ ] 支持批量摄入（改为每次 3-5 篇）
-- [ ] 添加 webhook 通知（不只是 Telegram）
-- [ ] 统计摄入速率和成功率
-
----
-
+# Wiki Sync 系统搭建完整记录
+
+> 日期：2026-04-16
+> 作者：Hermes Agent
+> 用途：记录 llm-wiki-agent 自动化同步系统的完整搭建过程
+
+---
+
+## 背景
+
+用户希望将 Obsidian vault 中的 markdown 文件批量摄入到 LLM Wiki（Karpathy's LLM Wiki）中。原有方案是手动逐篇执行，效率低下。本次目标：搭建自动化系统，实现定时自动摄入。
+
+---
+
+## 系统架构
+
+### 架构图
+![Wiki Sync Architecture](IMG-20260418081458052.png)
+
+
+### 同步时序图
+
+![Wiki Sync Sequence Diagram](IMG-20260418081458100.png)
+
+### Ingest 9 步流程图
+![[IMG-20260418081458161.png]]
+
+
+### 核心组件
+
+| 组件 | 位置 | 职责 |
+|------|------|------|
+| **llm-wiki-sync skill** | `~/.hermes/skills/research/llm-wiki-sync/SKILL.md` | 执行模板和工作流定义 |
+| **sync.py** | `/Users/weishen/Git/llm-wiki-agent/tools/sync.py` | manifest 管理、CLI 工具 |
+| **manifest.json** | `/Users/weishen/Git/llm-wiki-agent/tools/manifest.json` | 文件状态追踪（181篇） |
+| **Hermes Cron Job** | 内部调度器 | 每 15 分钟触发一次摄入 |
+
+
+## 一、初始探索（手动执行阶段）
+
+### 1.1 发现 raw 文件
+
+- 路径：`/Users/weishen/Workspace/nexus/raw/`（Obsidian vault）
+- 通过 symlink 挂载到：`/Users/weishen/Git/llm-wiki-agent/raw/`
+- 文件数：182 个 markdown 文件
+
+### 1.2 创建 manifest.json
+
+手动扫描 raw 目录，生成初始 manifest：
+
+```
+# 扫描 raw 目录，提取 frontmatter
+for md in Path("raw").glob("**/*.md"):
+    # 提取 title, ingested, slug 等字段
+    manifest.append({...})
+```
+
+### 1.3 测试 /wiki-ingest
+
+Claude Code 的 `/wiki-ingest` 命令执行 9 步流程：
+读取 source 文档
+读取 wiki/index.md 和 overview.md
+生成 wiki/sources/<slug>.md
+更新 wiki/index.md
+更新 wiki/overview.md
+创建/更新 Entity 页面
+创建/更新 Concept 页面
+检测并记录冲突
+追加 wiki/log.md
+
+##  二、遇到的问题和解决方案
+
+### 问题 1：stdin 交互问题
+
+**现象**：`claude --print` 模式在非交互环境下无法正常工作，stdin 被占用导致命令卡住。
+
+**解决方案**：使用 TMUX 交互模式启动 Claude Code：
+
+```bash
+# 启动 TMUX session
+tmux new-session -d -s wiki-ingest "cd /Users/weishen/Git/llm-wiki-agent && claude --permission-mode bypassPermissions"
+
+# 等待启动完成
+sleep 8 && tmux send-keys -t wiki-ingest Enter
+
+# 发送任务
+tmux send-keys -t wiki-ingest "请执行任务..."
+```
+
+### 问题 2：manifest slug 与实际文件不匹配
+
+**现象**：manifest 中记录的 slug 和 source_path 与 LLM 实际生成的文件名不一致。
+
+**原因**：LLM 根据内容自动生成 slug，而不是简单从文件名转换。
+
+**解决方案**：要求 LLM 在任务完成后输出 `SLUG: xxx`，然后 Hermes 解析并更新 manifest：
+
+```python
+def parse_slug_from_output(output: str) -> str:
+    """从 LLM 输出中解析实际使用的 slug"""
+    match = re.search(r'SLUG:\s*([^\s]+)', output)
+    return match.group(1) if match else None
+```
+
+### 问题 3：170 条 ingest 错误记录
+
+**现象**：manifest 中有 170 条记录标记为 `ingested=true` 但实际未成功。
+
+**原因**：早期测试时使用 `--print` 模式失败但仍标记为成功。
+
+**解决方案**：使用 `sync.py --reset-failed` 清理错误状态。
+
+---
+
+## 三、自建组件
+
+### 3.1 sync.py CLI 工具
+
+**位置**：`/Users/weishen/Git/llm-wiki-agent/tools/sync.py`
+
+**功能**：
+- `--pending`：列出待摄取文件
+- `--check`：预览变化
+- `--reset-failed`：重置失败记录
+- `--bootstrap`：从现有 wiki sources 重建 manifest
+
+**核心函数**：
+```python
+def get_pending_files() -> list:
+    """返回所有未摄入的文件"""
+
+def mark_ingested(file_path: str, slug: str):
+    """标记文件为已摄入"""
+
+def reset_failed():
+    """重置所有失败状态"""
+
+def parse_slug_from_output(output: str) -> str:
+    """从 LLM 输出解析 SLUG"""
+```
+
+### 3.2 llm-wiki-sync skill
+
+**位置**：`~/.hermes/skills/research/llm-wiki-sync/SKILL.md`
+
+**版本**：1.4.0
+
+**核心内容**：
+- **角色分工**：Hermes 编排流程 → Claude Code 执行 ingest
+- **关键设计**：TMUX 交互模式、顺序执行、SLUG 输出要求
+- **TMUX 执行流程**：完整的启动、发送任务、监控、清理流程
+- **Ingest Workflow 9 步**：标准化执行步骤
+- **Cron Job 自动化**：使用 Hermes 原生 cron job
+
+### 3.3 Hermes Cron Job
+
+**创建命令**：
+```bash
+cronjob create \
+  --name wiki-sync-15min \
+  --skill llm-wiki-sync \
+  --schedule "*/15 * * * *" \
+  --repeat 999999 \
+  --deliver "telegram:5038825565" \
+  --prompt "使用 llm-wiki-sync 技能执行一次 wiki 文章摄入..."
+```
+
+**配置**：
+- Job ID：`98265b6998c5`
+- Schedule：`*/15 * * * *`（每 15 分钟）
+- 交付方式：Telegram（ID: 5038825565）
+- 技能：llm-wiki-sync
+
+---
+
+## 四、执行流程（自动化阶段）
+
+### 4.1 Cron Job 触发
+
+1. 每 15 分钟（00, 15, 30, 45 分）触发
+2. 加载 llm-wiki-sync skill
+3. 执行 skill 中的 prompt
+
+### 4.2 实际执行步骤
+
+```
+1. 加载 llm-wiki-sync 技能
+2. 检查 manifest（python tools/sync.py --pending）
+3. 启动 TMUX session
+4. 启动 Claude Code（bypassPermissions）
+5. 发送任务指令（含 SLUG 输出要求）
+6. 监控任务完成（tmux capture-pane）
+7. 解析 SLUG 并更新 manifest.json
+8. 清理 TMUX session
+9. 输出结果（自动发往 Telegram）
+```
+
+### 4.3 示例输出
+
+```
+## Wiki Sync 完成
+
+| 项目 | 结果 |
+|------|------|
+| 摄入文件 | raw/Home Office/用Docker中安装Navidrome.md |
+| Slug | 用docker中安装navidrome |
+| 状态 | ✅ 已完成 |
+
+新增页面：
+- wiki/sources/用docker中安装navidrome.md
+- wiki/entities/Navidrome.md
+- wiki/concepts/Docker-Compose.md
+
+manifest 已更新：ingested: true
+剩余待摄入：165 篇
+```
+
+---
+
+## 五、当前状态
+
+| 指标 | 值 |
+|------|-----|
+| 总文件数 | 181 篇 |
+| 已摄入 | 16 篇 |
+| 待摄入 | 165 篇 |
+| Cron Job 状态 | 运行中 |
+| 下次运行 | 18:15:00 |
+
+---
+
+## 六、关键命令速查
+
+```bash
+# 检查待摄取文件
+cd /Users/weishen/Git/llm-wiki-agent && python tools/sync.py --pending
+
+# 预览变化
+python tools/sync.py --check
+
+# 重置失败记录
+python tools/sync.py --reset-failed
+
+# 查看 cron job 状态
+cronjob --list
+
+# 手动触发 cron job
+cronjob --run <job_id>
+```
+
+---
+
+## 七、注意事项
+
+1. **必须使用 TMUX**：不能用 subprocess 或 --print 模式
+2. **必须顺序执行**：并发会触发 529 rate limit
+3. **必须解析 SLUG**：LLM 输出的实际 slug 用于更新 manifest
+4. **交付方式**：使用 `telegram:5038825565` 发给用户
+5. **保留 orphan**：不删除任何原始数据
+
+---
+
+## 八、扩展方向
+
+- [ ] 添加错误重试机制（529 时等待后重试）
+- [ ] 支持批量摄入（改为每次 3-5 篇）
+- [ ] 添加 webhook 通知（不只是 Telegram）
+- [ ] 统计摄入速率和成功率
+
+---
+
 *End of Note*

Hermes/xingzhi/信息图提示词模板.md

@@ -1,263 +1,263 @@
-## SYSTEM PROMPT (Set this once at the start of the Gemini session)
-
-```
-You are an infographic generation assistant. Your job is to create 6 chalkboard-style 
-infographic cards that form a complete visual guide.
-
-== GLOBAL STYLE RULES (apply to EVERY card, no exceptions) ==
-
-Background:
-- Dark green-black chalkboard: #1C2B1C
-- Realistic chalkboard texture with subtle scratches, dust particles, faint eraser smudge marks
-- Wooden frame border on all cards (hand-drawn wood grain lines in chalk brown/tan)
-- NO gradients, NO perfect geometric shapes, NO photorealistic elements
-
-Chalk Lines & Quality:
-- ALL lines must be hand-drawn, imperfect, sketchy — slight wobble and variation
-- Lines should look like real white/colored chalk on a blackboard
-- NO clean digital vectors, NO sharp vector paths
-
-Color Palette (strict — use ONLY these exact hex values):
-- Chalk White:     #F5F5F5  (main text, outlines)
-- Chalk Yellow:    #FFE566  (highlights, emphasis, underlines)
-- Chalk Pink:      #FF9999  (secondary highlights, icons)
-- Chalk Blue:      #66B3FF  (diagrams, technical elements)
-- Chalk Green:     #90EE90  (success, nature, positive)
-- Chalk Orange:    #FFB366  (warnings, energy)
-- Frame Brown:     #8B6914  (wooden frame, hand-drawn)
-
-Doodles & Decorative Elements:
-- Small hand-drawn stars (5-7 points, imperfect)
-- Hand-drawn underlines (slightly wavy)
-- Hand-drawn arrows (sketchy shaft + arrowhead)
-- Hand-drawn circles/ovals around key terms
-- Hand-drawn checkmarks
-- Scattered chalk dust particles near bottom/sides
-
-Typography:
-- All text hand-drawn chalk lettering style
-- Imperfect baseline (letters slightly off horizontal)
-- Mix of uppercase headers and lowercase body text for authenticity
-- Visible chalk texture on letters
-
-== CARD STRUCTURE (identical for all 6 cards) ==
-
-Each card follows this layout:
-┌──────────────────────────────────────────┐
-│  [WOODEN FRAME BORDER]                   │
-│  ┌────────────────────────────────────┐  │
-│  │ CARD TITLE (large, chalk white)    │  │
-│  │ ~~underlined with accent color~~   │  │
-│  ├────────────────────────────────────┤  │
-│  │ [SECTION 1]  │  [SECTION 2 if any] │  │
-│  │ Header color │                     │  │
-│  │ Bullets      │                     │  │
-│  │ Icon         │                     │  │
-│  ├────────────────────────────────────┤  │
-│  │ [Additional sections as needed]    │  │
-│  │ [Decorative doodles in corners]    │  │
-│  └────────────────────────────────────┘  │
-└──────────────────────────────────────────┘
-
-== CONSISTENCY RULES ==
-
-1. Generate Card 1 first, send it to me
-2. For Card 2–6, EXPLICITLY include this instruction:
-   "Follow the exact same chalkboard style as the previous card — 
-   same background #1C2B1C, same chalk dust texture, same hand-drawn 
-   line quality, same color hex values (#F5F5F5, #FFE566, #FF9999, 
-   #66B3FF, #90EE90, #FFB366), same wooden frame border, same doodle 
-   elements. Do NOT deviate from this style."
-3. Aspect ratio: 16:9 for all cards
-4. Each card should visually "belong" to the same set
-
-== HOW TO USE THESE PROMPTS ==
-
-1. Copy the SYSTEM PROMPT above and paste it at the start of your Gemini session
-2. Then copy Prompt 1 and send it to Gemini Image Gen (Card 1)
-3. Once Card 1 is generated, copy Prompt 2 but FIRST include the STYLE LOCK BLOCK
-4. Repeat for all 6 cards, always referencing the previous card's style
-5. Review each generated image: if chalk line quality or colors deviate, 
-   regenerate with stronger style enforcement
-```
-
----
-
-## STYLE LOCK BLOCK (Prepend this to Prompts 2–6)
-
-```
-== STYLE LOCK — MANDATORY ==
-
-This card MUST follow the EXACT same chalkboard style as the previously 
-generated card. Do not deviate.
-
-Checklist — verify these match the previous card BEFORE generating:
-□ Background color: #1C2B1C (dark green-black chalkboard)
-□ Chalk texture: subtle scratches, dust, eraser smudges
-□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
-□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), #FF9999 (pink), 
-  #66B3FF (blue), #90EE90 (green), #FFB366 (orange)
-□ Frame: wooden border with hand-drawn wood grain
-□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
-□ Typography: chalk lettering, imperfect baseline, chalk texture on letters
-
-If ANY element does not match, regenerate with corrections.
-```
-
----
-
-## CARD 1 — Saleable & Security
-
-```
-== STYLE LOCK — MANDATORY ==
-
-This card MUST follow the EXACT same chalkboard style as the previously 
-generated card. Do not deviate.
-
-Checklist — verify these match the previous card BEFORE generating:
-□ Background color: #1C2B1C (dark green-black chalkboard)
-□ Chalk texture: subtle scratches, dust, eraser smudges
-□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
-□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), #FF9999 (pink), 
-  #66B3FF (blue), #90EE90 (green), #FFB366 (orange)
-□ Frame: wooden border with hand-drawn wood grain
-□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
-□ Typography: chalk lettering, imperfect baseline, chalk texture on letters
-
-If ANY element does not match, regenerate with corrections.
-
----
-
-INFOGRAPHIC CARD 1: Saleable & Security
-
-Create a single infographic card in chalkboard style with a dark green-black 
-background (#1C2B1C), realistic chalk dust texture, subtle eraser smudge marks, 
-and a wooden frame border with hand-drawn wood grain lines.
-
-Card is 16:9 aspect ratio. All elements must look hand-drawn with real chalk — 
-imperfect sketchy lines, slight wobble, no clean vectors.
-
-TITLE SECTION:
-- "Saleable & Security" in large hand-drawn chalk white (#F5F5F5) uppercase 
-  lettering, centered at top
-- Double underline in chalk yellow (#FFE566), slightly wavy hand-drawn lines
-- Small hand-drawn star doodles on each side of the title
-
-TWO-COLUMN LAYOUT below title:
-
-LEFT COLUMN — "Saleable" (header in chalk pink #FF9999, hand-drawn rectangle bar):
-  • Complete product definition in Control Tower
-  • SKUs clearly defined
-  • License generation strategy complete
-  Bullet markers: small chalk pink circles
-  Icon: hand-drawn chalk sketch of a product box with a small price tag label, 
-        in chalk yellow on white outline
-
-RIGHT COLUMN — "Security" (header in chalk blue #66B3FF, hand-drawn rectangle bar):
-  • Application self-defensibility capability
-  • WAF rules to protect cloud apps
-  • Defend against incorrect usage (accidental & purposeful)
-  Bullet markers: small chalk blue circles
-  Icon: hand-drawn chalk shield with a simple checkmark inside, outline in 
-        chalk white, fill in semi-transparent chalk blue
-
-FOOTER DECORATION:
-- A hand-drawn chalk dividing line across the card width
-- Two small doodle checkmarks at bottom right in chalk green (#90EE90)
-- Scattered chalk dust particles along the bottom edge
-
-NO gradients, NO sharp geometric shapes, NO flat digital icons.
-```
-
-## ![IMG-20260418172056603.png](app://77d327b60ef00764e25eb25542b49a223773/D:/Workspace/nexus/Asset/Attachment/raw/AI/%E5%A6%82%E4%BD%95%E8%AE%A9AI%E7%94%9F%E6%88%90%E9%A3%8E%E6%A0%BC%E4%B8%80%E8%87%B4%E7%9A%84%E5%9B%BE%E7%89%87/IMG-20260418172056603.png?1776503642747)
-
-## CARD 2 — Cloud Deployment & Configuration
-
-```
-== STYLE LOCK — MANDATORY ==
-
-This card MUST follow the EXACT same chalkboard style as the previously 
-generated card. Do not deviate.
-
-Checklist — verify these match the previous card BEFORE generating:
-□ Background color: #1C2B1C (dark green-black chalkboard)
-□ Chalk texture: subtle scratches, dust, eraser smudges
-□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
-□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), #FF9999 (pink), 
-  #66B3FF (blue), #90EE90 (green), #FFB366 (orange)
-□ Frame: wooden border with hand-drawn wood grain
-□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
-□ Typography: chalk lettering, imperfect baseline, chalk texture on letters
-
-If ANY element does not match, regenerate with corrections.
-
----
-
-INFOGRAPHIC CARD 2: Cloud Deployment & Configuration
-
-Create a single infographic card in chalkboard style with a dark green-black 
-background (#1A1A1A), realistic chalk dust texture, subtle eraser smudge marks, 
-and a wooden frame border with hand-drawn wood grain lines.
-
-Card is 16:9 aspect ratio. All elements must look hand-drawn with real chalk — 
-imperfect sketchy lines, slight wobble, no clean vectors.
-
-TITLE SECTION:
-- "Cloud Deployment & Configuration" in large hand-drawn chalk white (#F5F5F5) 
-  uppercase lettering, centered at top
-- Underline in chalk green (#90EE90), hand-drawn wavy line
-- Small star doodle on left side of title
-
-MAIN CONTENT AREA:
-Header bar: "Deployment Requirements" in chalk blue (#66B3FF) hand-drawn 
-rectangle
-
-Bullet list (chalk white text, chalk yellow bullet markers):
-  ✔ Fully automated cloud platform deployment
-  ✔ Web / API enabled configuration management
-  ✔ All feature & functional configs through API interface
-  ✔ Tenant capability enablement
-
-Sub-section header: "Configuration Management" in chalk pink (#FF9999)
-
-HAND-DRAWN FLOWCHART (center of card):
-Three chalk blue boxes connected by sketchy chalk arrows:
-
-  [Cloud Platform] --arrow--> [API Gateway] --arrow--> [Tenant Config]
-
-Each box: hand-drawn rectangle with slightly wavy edges, white #F5F5F5 outline
-Text inside boxes: chalk white
-Arrows: hand-drawn with slight wobble, chalk blue
-
-ADDITIONAL ELEMENT:
-Hand-drawn stick figure engineer icon (simple, chalk white) on the right side
-holding a small chalk-drawn tablet/device
-
-CORNER DOODLES:
-- Top right: small hand-drawn cloud shape labeled "SaaS" in chalk orange (#FFB366)
-- Bottom left: chalk pink circle with "API" text inside
-- Scattered chalk dust particles near the wooden frame
-
-NO gradients, NO sharp geometry, NO digital-looking elements.
-```
-
-
-## How to Use This File
-
-```
-SEQUENCE:
-1. Gemini session start → paste the SYSTEM PROMPT
-2. Send CARD 1 prompt → receive Card 1 image
-3. Paste CARD 2 prompt (it includes STYLE LOCK BLOCK) → receive Card 2
-4. Repeat for Cards 3–6
-
-VERIFICATION after each card:
-- Does background look like #1C2B1C dark green-black chalkboard? ✓/✗
-- Do all lines look hand-drawn/sketchy? ✓/✗
-- Are colors using the exact hex values? ✓/✗
-- Is there a wooden frame border? ✓/✗
-- Are doodles (stars, underlines, arrows) hand-drawn? ✓/✗
-- Does it match the previous card visually? ✓/✗
-
-If any check fails → regenerate with stronger style enforcement.
+## SYSTEM PROMPT (Set this once at the start of the Gemini session)
+
+```
+You are an infographic generation assistant. Your job is to create 6 chalkboard-style 
+infographic cards that form a complete visual guide.
+
+== GLOBAL STYLE RULES (apply to EVERY card, no exceptions) ==
+
+Background:
+- Dark green-black chalkboard: #1C2B1C
+- Realistic chalkboard texture with subtle scratches, dust particles, faint eraser smudge marks
+- Wooden frame border on all cards (hand-drawn wood grain lines in chalk brown/tan)
+- NO gradients, NO perfect geometric shapes, NO photorealistic elements
+
+Chalk Lines & Quality:
+- ALL lines must be hand-drawn, imperfect, sketchy — slight wobble and variation
+- Lines should look like real white/colored chalk on a blackboard
+- NO clean digital vectors, NO sharp vector paths
+
+Color Palette (strict — use ONLY these exact hex values):
+- Chalk White:     #F5F5F5  (main text, outlines)
+- Chalk Yellow:    #FFE566  (highlights, emphasis, underlines)
+- Chalk Pink:      #FF9999  (secondary highlights, icons)
+- Chalk Blue:      #66B3FF  (diagrams, technical elements)
+- Chalk Green:     #90EE90  (success, nature, positive)
+- Chalk Orange:    #FFB366  (warnings, energy)
+- Frame Brown:     #8B6914  (wooden frame, hand-drawn)
+
+Doodles & Decorative Elements:
+- Small hand-drawn stars (5-7 points, imperfect)
+- Hand-drawn underlines (slightly wavy)
+- Hand-drawn arrows (sketchy shaft + arrowhead)
+- Hand-drawn circles/ovals around key terms
+- Hand-drawn checkmarks
+- Scattered chalk dust particles near bottom/sides
+
+Typography:
+- All text hand-drawn chalk lettering style
+- Imperfect baseline (letters slightly off horizontal)
+- Mix of uppercase headers and lowercase body text for authenticity
+- Visible chalk texture on letters
+
+== CARD STRUCTURE (identical for all 6 cards) ==
+
+Each card follows this layout:
+┌──────────────────────────────────────────┐
+│  [WOODEN FRAME BORDER]                   │
+│  ┌────────────────────────────────────┐  │
+│  │ CARD TITLE (large, chalk white)    │  │
+│  │ ~~underlined with accent color~~   │  │
+│  ├────────────────────────────────────┤  │
+│  │ [SECTION 1]  │  [SECTION 2 if any] │  │
+│  │ Header color │                     │  │
+│  │ Bullets      │                     │  │
+│  │ Icon         │                     │  │
+│  ├────────────────────────────────────┤  │
+│  │ [Additional sections as needed]    │  │
+│  │ [Decorative doodles in corners]    │  │
+│  └────────────────────────────────────┘  │
+└──────────────────────────────────────────┘
+
+== CONSISTENCY RULES ==
+
+1. Generate Card 1 first, send it to me
+2. For Card 2–6, EXPLICITLY include this instruction:
+   "Follow the exact same chalkboard style as the previous card — 
+   same background #1C2B1C, same chalk dust texture, same hand-drawn 
+   line quality, same color hex values (#F5F5F5, #FFE566, #FF9999, 
+   #66B3FF, #90EE90, #FFB366), same wooden frame border, same doodle 
+   elements. Do NOT deviate from this style."
+3. Aspect ratio: 16:9 for all cards
+4. Each card should visually "belong" to the same set
+
+== HOW TO USE THESE PROMPTS ==
+
+1. Copy the SYSTEM PROMPT above and paste it at the start of your Gemini session
+2. Then copy Prompt 1 and send it to Gemini Image Gen (Card 1)
+3. Once Card 1 is generated, copy Prompt 2 but FIRST include the STYLE LOCK BLOCK
+4. Repeat for all 6 cards, always referencing the previous card's style
+5. Review each generated image: if chalk line quality or colors deviate, 
+   regenerate with stronger style enforcement
+```
+
+---
+
+## STYLE LOCK BLOCK (Prepend this to Prompts 2–6)
+
+```
+== STYLE LOCK — MANDATORY ==
+
+This card MUST follow the EXACT same chalkboard style as the previously 
+generated card. Do not deviate.
+
+Checklist — verify these match the previous card BEFORE generating:
+□ Background color: #1C2B1C (dark green-black chalkboard)
+□ Chalk texture: subtle scratches, dust, eraser smudges
+□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
+□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), #FF9999 (pink), 
+  #66B3FF (blue), #90EE90 (green), #FFB366 (orange)
+□ Frame: wooden border with hand-drawn wood grain
+□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
+□ Typography: chalk lettering, imperfect baseline, chalk texture on letters
+
+If ANY element does not match, regenerate with corrections.
+```
+
+---
+
+## CARD 1 — Saleable & Security
+
+```
+== STYLE LOCK — MANDATORY ==
+
+This card MUST follow the EXACT same chalkboard style as the previously 
+generated card. Do not deviate.
+
+Checklist — verify these match the previous card BEFORE generating:
+□ Background color: #1C2B1C (dark green-black chalkboard)
+□ Chalk texture: subtle scratches, dust, eraser smudges
+□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
+□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), #FF9999 (pink), 
+  #66B3FF (blue), #90EE90 (green), #FFB366 (orange)
+□ Frame: wooden border with hand-drawn wood grain
+□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
+□ Typography: chalk lettering, imperfect baseline, chalk texture on letters
+
+If ANY element does not match, regenerate with corrections.
+
+---
+
+INFOGRAPHIC CARD 1: Saleable & Security
+
+Create a single infographic card in chalkboard style with a dark green-black 
+background (#1C2B1C), realistic chalk dust texture, subtle eraser smudge marks, 
+and a wooden frame border with hand-drawn wood grain lines.
+
+Card is 16:9 aspect ratio. All elements must look hand-drawn with real chalk — 
+imperfect sketchy lines, slight wobble, no clean vectors.
+
+TITLE SECTION:
+- "Saleable & Security" in large hand-drawn chalk white (#F5F5F5) uppercase 
+  lettering, centered at top
+- Double underline in chalk yellow (#FFE566), slightly wavy hand-drawn lines
+- Small hand-drawn star doodles on each side of the title
+
+TWO-COLUMN LAYOUT below title:
+
+LEFT COLUMN — "Saleable" (header in chalk pink #FF9999, hand-drawn rectangle bar):
+  • Complete product definition in Control Tower
+  • SKUs clearly defined
+  • License generation strategy complete
+  Bullet markers: small chalk pink circles
+  Icon: hand-drawn chalk sketch of a product box with a small price tag label, 
+        in chalk yellow on white outline
+
+RIGHT COLUMN — "Security" (header in chalk blue #66B3FF, hand-drawn rectangle bar):
+  • Application self-defensibility capability
+  • WAF rules to protect cloud apps
+  • Defend against incorrect usage (accidental & purposeful)
+  Bullet markers: small chalk blue circles
+  Icon: hand-drawn chalk shield with a simple checkmark inside, outline in 
+        chalk white, fill in semi-transparent chalk blue
+
+FOOTER DECORATION:
+- A hand-drawn chalk dividing line across the card width
+- Two small doodle checkmarks at bottom right in chalk green (#90EE90)
+- Scattered chalk dust particles along the bottom edge
+
+NO gradients, NO sharp geometric shapes, NO flat digital icons.
+```
+
+## ![IMG-20260418172056603.png](app://77d327b60ef00764e25eb25542b49a223773/D:/Workspace/nexus/Asset/Attachment/raw/AI/%E5%A6%82%E4%BD%95%E8%AE%A9AI%E7%94%9F%E6%88%90%E9%A3%8E%E6%A0%BC%E4%B8%80%E8%87%B4%E7%9A%84%E5%9B%BE%E7%89%87/IMG-20260418172056603.png?1776503642747)
+
+## CARD 2 — Cloud Deployment & Configuration
+
+```
+== STYLE LOCK — MANDATORY ==
+
+This card MUST follow the EXACT same chalkboard style as the previously 
+generated card. Do not deviate.
+
+Checklist — verify these match the previous card BEFORE generating:
+□ Background color: #1C2B1C (dark green-black chalkboard)
+□ Chalk texture: subtle scratches, dust, eraser smudges
+□ Line quality: hand-drawn, imperfect, sketchy wobble — NO perfect vectors
+□ Color hex values: #F5F5F5 (white), #FFE566 (yellow), #FF9999 (pink), 
+  #66B3FF (blue), #90EE90 (green), #FFB366 (orange)
+□ Frame: wooden border with hand-drawn wood grain
+□ Doodles: stars, underlines, arrows, circles — all chalk-drawn
+□ Typography: chalk lettering, imperfect baseline, chalk texture on letters
+
+If ANY element does not match, regenerate with corrections.
+
+---
+
+INFOGRAPHIC CARD 2: Cloud Deployment & Configuration
+
+Create a single infographic card in chalkboard style with a dark green-black 
+background (#1A1A1A), realistic chalk dust texture, subtle eraser smudge marks, 
+and a wooden frame border with hand-drawn wood grain lines.
+
+Card is 16:9 aspect ratio. All elements must look hand-drawn with real chalk — 
+imperfect sketchy lines, slight wobble, no clean vectors.
+
+TITLE SECTION:
+- "Cloud Deployment & Configuration" in large hand-drawn chalk white (#F5F5F5) 
+  uppercase lettering, centered at top
+- Underline in chalk green (#90EE90), hand-drawn wavy line
+- Small star doodle on left side of title
+
+MAIN CONTENT AREA:
+Header bar: "Deployment Requirements" in chalk blue (#66B3FF) hand-drawn 
+rectangle
+
+Bullet list (chalk white text, chalk yellow bullet markers):
+  ✔ Fully automated cloud platform deployment
+  ✔ Web / API enabled configuration management
+  ✔ All feature & functional configs through API interface
+  ✔ Tenant capability enablement
+
+Sub-section header: "Configuration Management" in chalk pink (#FF9999)
+
+HAND-DRAWN FLOWCHART (center of card):
+Three chalk blue boxes connected by sketchy chalk arrows:
+
+  [Cloud Platform] --arrow--> [API Gateway] --arrow--> [Tenant Config]
+
+Each box: hand-drawn rectangle with slightly wavy edges, white #F5F5F5 outline
+Text inside boxes: chalk white
+Arrows: hand-drawn with slight wobble, chalk blue
+
+ADDITIONAL ELEMENT:
+Hand-drawn stick figure engineer icon (simple, chalk white) on the right side
+holding a small chalk-drawn tablet/device
+
+CORNER DOODLES:
+- Top right: small hand-drawn cloud shape labeled "SaaS" in chalk orange (#FFB366)
+- Bottom left: chalk pink circle with "API" text inside
+- Scattered chalk dust particles near the wooden frame
+
+NO gradients, NO sharp geometry, NO digital-looking elements.
+```
+
+
+## How to Use This File
+
+```
+SEQUENCE:
+1. Gemini session start → paste the SYSTEM PROMPT
+2. Send CARD 1 prompt → receive Card 1 image
+3. Paste CARD 2 prompt (it includes STYLE LOCK BLOCK) → receive Card 2
+4. Repeat for Cards 3–6
+
+VERIFICATION after each card:
+- Does background look like #1C2B1C dark green-black chalkboard? ✓/✗
+- Do all lines look hand-drawn/sketchy? ✓/✗
+- Are colors using the exact hex values? ✓/✗
+- Is there a wooden frame border? ✓/✗
+- Are doodles (stars, underlines, arrows) hand-drawn? ✓/✗
+- Does it match the previous card visually? ✓/✗
+
+If any check fails → regenerate with stronger style enforcement.
 ```

Hermes/xingzhi/养龙虾封面提示词-2026-04-20.md

@@ -0,0 +1,51 @@
+---
+title: 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
+type: metaphor
+palette: warm
+rendering: digital
+text: title-subtitle
+mood: balanced
+---
+
+请为这篇文章生成封面图。
+
+## 视觉概念
+
+以"金鱼记忆"为核心隐喻：一条卡通金鱼游在透明的水缸中，金鱼的大脑位置是一个空白的问号框架，周围漂浮着记忆碎片（文字泡泡、对话气泡、代码片段），碎片正在逐渐消散到缸外。底部有简单的齿轮和调试工具元素，暗示"调试"过程。
+
+## 主视觉元素
+
+- 金鱼：卡通风格，圆形身体，大眼睛，尾巴呈波浪形游动姿态
+- 空白大脑：空心问号形状，位于金鱼头部位置
+- 记忆碎片：5-6个椭圆形气泡，包含模糊的文字轮廓、对话符号、代码片段
+- 水缸：简单几何圆形边框，内部有微妙的涟漪效果
+- 调试工具：底部角落有小型齿轮、螺丝刀、代码括号图标
+
+## 配色方案（warm palette）
+
+- 主色：温暖橙色 #F5A623（用于金鱼身体）
+- 辅色：柔和珊瑚色 #FF8C74（用于记忆碎片）
+- 强调色：深琥珀色 #C47A2B（用于鱼鳍和调试工具）
+- 背景：米白色 #FFF8F0 到浅杏色 #FFE8D6 渐变
+- 文字色：深棕色 #4A3728
+
+## 渲染风格（digital）
+
+- 干净的矢量线条，精确边缘
+- 平滑渐变，无粗糙纹理
+- 轻微阴影创造层次感
+- 像专业UI插图一样现代简洁
+
+## 文字布局
+
+- 标题："养龙虾5天血泪史" 使用大号粗体字（金鱼上方右侧）
+- 副标题："我的AI Agent为什么总失忆？" 使用较小字号（标题下方）
+- 字体：现代无衬线体，清晰易读
+- 文字颜色：深棕色 #4A3728
+
+## 氛围（balanced）
+
+- 中等对比度
+- 正常饱和度
+- 视觉重量平衡
+- 温暖友好但不强烈

Hermes/xingzhi/常用任务指令.md

@@ -0,0 +1,22 @@
+## 信息图任务指令
+
+请用**claude-code-infographic-build** 这个技能为`Hermes/xingzhi/Hermes自定义技能说明` 这篇笔记生成信息图。 
+     - 语言：英文
+     - 布局：circular-flow
+     - 风格：chalkboard
+     - 比例：16:9
+
+
+## 封面图任务指令
+请用**claude-code-executor**技能启动Claude Code 
+使用 **baoyu-cover-image** 技能为以下内容生成封面图提示词：
+
+1. 读取 Hermes/xingzhi/wiki-sync-setup-2026-04-16.md 这篇笔记
+2. 用**baoyu-cover-image** 生成一张封面图  
+	- **类型 (Type)**：`hero`、`conceptual`、`typography`、`metaphor`、`scene`、`minimal`
+	- **配色 (Palette)**：`warm`、`elegant`、`cool`、`dark`、`earth`、`vivid`、`pastel`、`mono`、`retro`
+	- **渲染 (Rendering)**：`flat-vector`、`hand-drawn`、`painterly`、`digital`、`pixel`、`chalk`
+	- **文字 (Text)**：`none`、`title-only`（默认）、`title-subtitle`、`text-rich`
+	- **氛围 (Mood)**：`subtle`、`balanced`（默认）、`bold`
+3. 不要生成图片，只输出提示词
+4. 输出提示词到 Hermes/xingzhi/ 新建一个笔记

Hermes/xingzhi/生成信息图任务指令.md

@@ -1,31 +0,0 @@
-## 信息图任务指令
-
-请用**claude-code-executor**技能启动Claude Code 
-使用 **baoyu-infographic** 技能为以下内容生成信息图提示词：
-
-1. 读取 Hermes/xingzhi/wiki-sync-setup-2026-04-16.md 这篇笔记
-2. 用baoyu-infographic 生成一张信息图  
-     - 语言：英文
-     - 布局：circular-flow
-     - 风格：chalkboard
-     - 比例：16:9
-     - 不要生成图片，只输出提示词
-3. 为了后续图片能保持一致的风格，提示词生成必须输出三部分提示词。
-	 - 系统提示词（Image Specifications + Core Principles）
-     - 风格锁定提示词（Layout Guidelines + Style Guidelines）
-     - 内容结构提示词 （Text Requirements)
-4. 输出提示词到 Hermes/xingzhi/ 新建一个笔记
-
-## 封面图任务指令
-请用**claude-code-executor**技能启动Claude Code 
-使用 **baoyu-cover-image** 技能为以下内容生成封面图提示词：
-
-1. 读取 Hermes/xingzhi/wiki-sync-setup-2026-04-16.md 这篇笔记
-2. 用**baoyu-cover-image** 生成一张封面图  
-	- **类型 (Type)**：`hero`、`conceptual`、`typography`、`metaphor`、`scene`、`minimal`
-	- **配色 (Palette)**：`warm`、`elegant`、`cool`、`dark`、`earth`、`vivid`、`pastel`、`mono`、`retro`
-	- **渲染 (Rendering)**：`flat-vector`、`hand-drawn`、`painterly`、`digital`、`pixel`、`chalk`
-	- **文字 (Text)**：`none`、`title-only`（默认）、`title-subtitle`、`text-rich`
-	- **氛围 (Mood)**：`subtle`、`balanced`（默认）、`bold`
-3. 不要生成图片，只输出提示词
-4. 输出提示词到 Hermes/xingzhi/ 新建一个笔记

Hermes/xingzhi/用 LLM把零散资料变成可复用的知识库 —— llm-wiki-sync 的实现与示例解析.md

@@ -0,0 +1,127 @@
+
+**副标题**：如何把每一份笔记，通过 llm-wiki-sync 自动分析与提炼成结构化的页面、实体与概念，以便长期检索与复用。
+
+---
+
+## 前言与来源说明
+
+本方案借鉴并整合了几条重要线索：
+- Andrej Karpathy 对“LLM Wiki”理念的阐述（将知识以可被大模型直接消费的结构化方式保存）：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
+- 我们的实现基于开源项目 SamurAI 的 llm-wiki-agent（https://github.com/SamurAIGPT/llm-wiki-agent），在其基础上扩展了企业化的 ingest 流程、Cron 调度与 Hermes skill（llm-wiki-sync）。
+- 最终静态化展示使用 Quartz（https://github.com/jackyzha0/quartz），把生成的 wiki 内容导出为可浏览、可分享的静态站点。
+
+下面重点介绍 llm-wiki-sync 如何把一篇笔记做结构化分析与提炼，并用仓库中的实例（wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery）作为逐项说明。
+
+---
+
+## llm-wiki-sync 的目标与核心能力
+
+核心目标：把原始文档（raw/）自动转成结构化的 wiki source 页面，抽取关键要素（Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections），并记录 ingest 日志、差异与审计信息，供后续检索、合成与内容再生产使用。
+
+关键能力：
+- 文本解析与语义压缩：把长文本压缩为 2–4 句高密度 summary。
+- 声明抽取（claim extraction）：识别文中明确的结论与可验证断言。
+- 实体与概念抽取（NER + linking）：识别人名/公司/工具/概念，并把它们标准化为 wiki 实体页（[[Name]]）。
+- 关系发现（connections）：把句子级别的语义关系转成图边（A → depends_on → B）。
+- 模板化输出：固定页面头（frontmatter）+ 标准段落（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。
+- 审计与可回滚：每次 ingest 都写入 wiki/log.md，并可通过 git/checkpoint 回滚变更。
+
+实现技术栈要点：Hermes（skill 调用）、Claude Code / agent（可选）、llm-wiki-agent 基础脚本、以及最终的静态化工具 Quartz。
+
+---
+
+## 从笔记到 Source Page
+
+仓库中的源页面：wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md 
+
+下面逐项展示 llm-wiki-sync 针对该文档所做的提取结果（摘自生成的 source 页面）：
+
+1) Summary（Summary）
+- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
+- 问题域：灾难恢复规划、发布风险管控
+- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
+- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件
+
+说明：Summary 由模型将整篇文章的主旨、问题背景、关键方法与结论压缩为 2–4 条，便于快速检索与索引。
+
+2) Key Claims（断言提取）
+- RTO 衡量系统恢复速度：允许的最大停机时间
+- RPO 衡量数据保护：可接受的最大数据丢失量
+- 传统灾备聚焦硬件故障，现代风险更多来自代码变更（部署 bug、数据库迁移、AI 模型更新等）
+- Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
+- 应用分层策略（Critical / Important / Nice-to-have）对应不同的 RTO/RPO 指标
+
+说明：断言提取用于建立事实层（fact layer），后续可自动化做一致性检查与冲突检测（Contradictions 段）。
+
+3) Key Quotes（关键引用）
+- “RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose.”
+- “Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users.”
+
+说明：保留可引用原句，便于在后续合成（如写作、演讲稿）中引用来源。
+
+4) Key Concepts（概念抽取）
+- RTO（Recovery Time Objective）
+- RPO（Recovery Point Objective）
+- Feature Flag（特性开关）
+- Kill Switch（紧急关闭机制）
+- 渐进式发布（Gradual Rollout）
+
+说明：概念会被标准化为 wiki 的 concept 页面（wiki/concepts/），用于聚合所有提到该概念的 source 页面。
+
+5) Key Entities（实体抽取）
+- LaunchDarkly（Feature Flag 管理平台）
+- HP（示例企业）
+- Christian Dior（示例企业 — 文档中作为案例提及）
+
+说明：实体会被规范化为 wiki/entities/ 下的页面，并且 source 页面会在 sources 列表保留原始链接与引用。
+
+6) Connections（关系构建）
+- RTO ← depends_on ← Feature Flag
+- RPO ← depends_on ← Feature Flag
+- LaunchDarkly → provides → Feature Flag
+- Feature Flag ← enables ← 渐进式发布
+
+说明：Connections 用于图谱构建（graph/graph.json），后续能在可视化页面（graph.html）展示节点与边。
+
+7) Contradictions（冲突检测）
+- 当前文档无明显与现有 wiki 冲突的声明；若检测到冲突，llm-wiki-sync 会把冲突条目列出并标注来源，供人工审查。
+![[IMG-20260420160439552.png|872]]
+![[IMG-20260420160439600.png]]
+---
+
+## llm-wiki-sync 的典型运行步骤（工程视角）
+
+1. 读取 raw/<path>，解析 frontmatter/元数据（若缺失则询回填）。
+2. 检索 wiki/index.md 与 overview.md，获取上下文（避免重复 ingest）。
+3. 用 LLM 生成 Source Page（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。
+4. 将结果写入 wiki/sources/<slug>.md，并更新 wiki/index.md、wiki/overview.md；如有新实体/概念也生成对应页面草稿。 
+5. 记录日志：在 wiki/log.md 追加 ingest 记录（时间、文件、摘要、状态）。
+6. 可选：触发 graph 重建（增量或全量），并把 graph/graph.json、graph.html 更新到站点。 
+7. 通知：完成后通过 Hermes 的通知机制（deliver=origin 或 Telegram 指定 chat）告知负责人。
+
+并发与配额注意：单文件 ingest 优先，批量操作分批（每批 2~3 篇）；对接外部 agent/Claude Code 时避免并发超配额。
+
+审计与回滚：每次 ingest 前执行 git branch 或 checkpoint；如需回滚，可用 git revert 或恢复 checkpoint。
+
+---
+
+## 总结与扩展
+
+- llm-wiki-sync 把 Karpathy 关于 LLM Wiki 的理念落地为可执行的工程流程：把知识以结构化表征保存，使得大模型既是“读者”也是“执行者”。
+- 在 Obsidian 中可以直接通过关系图（graph view）查看笔记间的关联；在 llm-wiki-agent 中可以通过 wiki-graph 构建并在 graph.html / graph/graph.json 中可视化展示。
+- 我们的实现基于 SamurAI 的 llm-wiki-agent，并在其上加入了企业级的同步、审计与 Hermes skill 封装，最终通过 Quartz 静态站把生成的 wiki 内容对外展示与分享。
+
+
+---
+
+## Infographic Asset
+
+![llm-wiki-sync Circular Flow Infographic](IMG-20260420160439662.png)
+
+**Infographic**: The Knowledge Pipeline Cycle — circular flow showing how llm-wiki-sync transforms scattered notes into a reusable knowledge base.
+- Layout: circular-flow (7-stage cycle)
+- Style: chalkboard (dark background, hand-drawn chalk accents)
+- Aspect ratio: 16:9
+- Prompt file: `infographic/llm-wiki-sync-circular-flow/prompts/infographic.md`
+- Image: `llm-wiki-sync-circular-flow-infographic.png`
+

Hermes/xingzhi/自动分析和完善MP3信息.md

@@ -0,0 +1,65 @@
+# 自动分析和完善 MP3 信息的指南
+
+## 1. 提取音频特征和元数据
+使用音频指纹技术（如 **AcoustID**）来获取 MP3 文件的特征和元数据。
+- **安装 Chromaprint**： 通过以下命令安装 Chromaprint。
+  ```bash
+  sudo apt-get install chromaprint
+  ```
+
+- **生成音频指纹**： 使用 `fpcalc` 命令生成 MP3 文件的指纹。
+  ```bash
+  fpcalc yourfile.mp3
+  ```
+
+## 2. 调用 AcoustID API
+使用生成的指纹调用 AcoustID API，获取音频文件的音乐信息。示例请求：
+```bash
+curl -X GET "https://api.acoustid.org/v2/lookup?client=YOUR_ACOUSTID_API_KEY&format=json&duration=DURATION&fingerprint=YOUR_FINGERPRINT"
+```
+
+## 3. 从 AcoustID 获取 MusicBrainz ID
+- AcoustID 的响应将包含与该指纹匹配的 MusicBrainz ID（MBID）、艺术家、专辑等信息。
+
+## 4. 使用 MusicBrainz API 获取详细信息
+使用获取的 MBID 查询详细的音乐信息：
+```bash
+GET https://musicbrainz.org/ws/2/artist/ARTIST_MBID?fmt=json
+```
+
+## 5. 更新 MP3 的元数据
+使用 Python 的 `mutagen` 库更新 MP3 文件的元数据。示例代码如下：
+```python
+from mutagen.mp3 import MP3
+from mutagen.id3 import ID3, TIT2, TPE1, TALB
+
+def update_metadata(file_path, title, artist, album):
+    audio = MP3(file_path, ID3=ID3)
+    audio['TIT2'] = TIT2(encoding=3, text=title)  # 标题
+    audio['TPE1'] = TPE1(encoding=3, text=artist)  # 艺术家
+    audio['TALB'] = TALB(encoding=3, text=album)  # 专辑
+    audio.save()
+
+# 调用示例
+update_metadata('yourfile.mp3', 'Correct Title', 'Correct Artist', 'Correct Album')
+```
+
+## 6. 添加专辑图片信息
+可以使用 `mutagen` 库来在 MP3 文件中添加专辑图片：
+```python
+from mutagen.mp3 import MP3
+from mutagen.id3 import ID3, APIC
+
+def add_album_art(mp3_file, image_file):
+    audio = MP3(mp3_file, ID3=ID3)
+    with open(image_file, 'rb') as img_file:
+        img_data = img_file.read()
+    audio['APIC'] = APIC(encoding=3, mime='image/jpeg', type=3, desc='Cover', data=img_data)
+    audio.save()
+
+# 调用示例
+add_album_art('yourfile.mp3', 'cover_image.jpg')
+```
+
+## 7. 结论
+此方法提供了一种系统化的方式来自动分析 MP3 文件并完善文件的信息，通过音乐指纹识别、使用 API 获取数据以及更新元数据的结合，实现音乐库的维护和信息准确性。

Hermes/yunzhi/CUE+WAV分割与高质量MP3转换.md

@@ -0,0 +1,193 @@
+---
+title: CUE + WAV 分割与高质量 MP3 转换
+date: 2026-05-20
+tags: [audio, cue, wav, mp3, ffmpeg, linux]
+---
+
+# CUE + WAV 分割与高质量 MP3 转换
+
+这篇笔记记录如何在命令行下，把一张专辑常见的 `cue + wav` 形式，切分成单曲，并转换成高质量 MP3。
+
+## 一、基本概念
+
+- `cue`：曲目索引与标签信息，记录每首歌的开始时间、标题、歌手等。
+- `wav`：整张专辑的无损音频文件。
+- 典型场景：一张专辑只有一个大 WAV 文件，加一个 CUE 文件。
+
+目标：
+1. 按 CUE 的时间点切分成单轨。
+2. 转成高质量 MP3。
+3. 尽量保留标题、歌手、专辑等标签。
+
+## 二、推荐工具
+
+在 Ubuntu 上建议安装：
+
+```bash
+sudo apt update
+sudo apt install cuetools shntool lame ffmpeg
+```
+
+说明：
+- `cuetools`：提供 `cuebreakpoints`、`cuetag`
+- `shntool`：负责按断点切分音频
+- `ffmpeg`：负责编码成 MP3
+- `lame`：MP3 编码器，ffmpeg 也会调用到它的能力
+
+## 三、按 CUE 切分 WAV
+
+### 方式 1：先切分，再转码
+
+```bash
+cuebreakpoints "album.cue" | shnsplit -o wav "album.wav"
+```
+
+结果：
+- 生成 `01.wav`、`02.wav`、`03.wav` ……
+- 每个文件对应 CUE 里的一个曲目
+
+### 注意
+
+- `cue` 文件中引用的 wav 文件名，必须和实际文件名一致。
+- 如果文件名不一致，先修正 CUE 里的 `FILE` 行，或把 wav 文件重命名。
+- 中文文件名一般没问题，但终端编码和 shell 引号要保持正确。
+
+## 四、转换为高质量 MP3
+
+### 方案 A：VBR 高质量，推荐
+
+```bash
+for f in *.wav; do
+  ffmpeg -y -i "$f" -codec:a libmp3lame -q:a 0 "${f%.wav}.mp3"
+done
+```
+
+说明：
+- `-q:a 0` 表示最高质量的 VBR 档位之一
+- 一般适合日常听歌和保留尽可能好的音质
+
+### 方案 B：固定 320k
+
+```bash
+for f in *.wav; do
+  ffmpeg -y -i "$f" -codec:a libmp3lame -b:a 320k "${f%.wav}.mp3"
+done
+```
+
+说明：
+- 码率固定，体积更可预测
+- 如果你偏好统一规格，可以选这个
+
+## 五、把 CUE 标签写回 MP3
+
+切分并转码后，可以把 CUE 里的标签批量写进 MP3：
+
+```bash
+cuetag "album.cue" *.mp3
+```
+
+通常会把以下信息写入：
+- 曲名
+- 专辑名
+- 歌手
+- 轨道号
+
+## 六、一键脚本
+
+下面是一个可直接使用的一键脚本：
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+CUE="$1"
+WAV="$2"
+OUTDIR="${3:-output}"
+
+mkdir -p "$OUTDIR"
+cd "$OUTDIR"
+
+cuebreakpoints "$CUE" | shnsplit -o wav "$WAV"
+
+for f in *.wav; do
+  ffmpeg -y -i "$f" -codec:a libmp3lame -q:a 0 "${f%.wav}.mp3"
+done
+
+cuetag "$CUE" *.mp3
+```
+
+用法：
+
+```bash
+chmod +x split_cue_to_mp3.sh
+./split_cue_to_mp3.sh "album.cue" "album.wav"
+```
+
+## 七、实战建议
+
+### 1. 先保留无损源文件
+
+MP3 即使是高质量编码，依然是有损格式。建议保留：
+- 原始 WAV
+- 原始 CUE
+- 转换后的 MP3
+
+### 2. 输出目录独立管理
+
+不要直接在源目录操作，建议每张专辑一个输出目录，便于回溯。
+
+### 3. 中文文件名注意引号
+
+所有路径都用双引号包裹：
+
+```bash
+"我的专辑.cue"
+"我的专辑.wav"
+```
+
+### 4. 出现标签错位时先检查 CUE
+
+如果曲名或分轨偏移不对，先检查：
+- `INDEX 01` 时间点是否正确
+- `FILE` 行是否指向正确的 wav 文件
+- wav 是否已经被裁剪过
+
+## 八、常见问题
+
+### 1. cuebreakpoints 报错找不到文件
+
+说明 CUE 中的文件名和实际文件名不一致。
+
+### 2. shnsplit 生成的文件顺序不对
+
+先检查 CUE 时间轴是否写错，或者原始 WAV 是否有静默开头/结尾。
+
+### 3. ffmpeg 转码失败
+
+检查是否安装了 `ffmpeg` 和 `libmp3lame` 支持。
+
+### 4. cuetag 没有写入标签
+
+确认：
+- CUE 文件语法正确
+- MP3 文件名和轨道对应关系未被破坏
+
+## 九、推荐命令组合
+
+如果只想快速执行，最常用的组合是：
+
+```bash
+cuebreakpoints "album.cue" | shnsplit -o wav "album.wav"
+for f in *.wav; do ffmpeg -y -i "$f" -codec:a libmp3lame -q:a 0 "${f%.wav}.mp3"; done
+cuetag "album.cue" *.mp3
+```
+
+## 十、结论
+
+如果目标是“命令行下稳定地把 cue+wav 专辑切成高质量 mp3”，推荐流程是：
+
+1. `cuebreakpoints + shnsplit` 切轨
+2. `ffmpeg + libmp3lame -q:a 0` 转码
+3. `cuetag` 回写标签
+
+这套组合简单、稳定、可批处理，适合长期使用。

Hermes/yunzhi/技术笔记/django-tenants 完整配置指南.md

@@ -0,0 +1,222 @@
+---
+title: django-tenants 完整配置指南
+created: 2026-04-21
+tags: [django, django-tenants, postgresql, saas, multi-tenant]
+category: 技术笔记
+---
+
+# django-tenants 完整配置指南
+
+## 一、安装依赖
+
+pip install django-tenants psycopg2-binary django-jazzmin
+
+## 二、项目目录结构
+
+myproject/
+├── config/
+│   ├── settings/
+│   │   ├── base.py
+│   │   ├── development.py
+│   │   └── production.py
+│   ├── urls.py
+│   └── wsgi.py
+├── apps/
+│   ├── tenants/
+│   ├── subscription/
+│   ├── accounts/
+│   ├── listings/
+│   ├── clients/
+│   └── showings/
+├── manage.py
+└── requirements.txt
+
+## 三、核心 Model：租户与域名
+
+- Company 继承 TenantMixin
+- Domain 继承 DomainMixin
+- 每一个中介公司 = 一个租户 = 一个独立 PostgreSQL Schema
+- 每个公司可绑定多个域名/子域名
+
+## 四、Settings 完整配置
+
+关键点：
+- SHARED_APPS 放公共 Schema 应用
+- TENANT_APPS 放租户私有应用
+- TENANT_MODEL = "tenants.Company"
+- TENANT_DOMAIN_MODEL = "tenants.Domain"
+- DATABASES 使用 django_tenants.postgresql_backend
+- DATABASE_ROUTERS 使用 TenantSyncRouter
+- TenantMainMiddleware 必须第一个
+- ROOT_URLCONF / PUBLIC_SCHEMA_URLCONF 分离
+- AUTH_USER_MODEL = accounts.User
+
+## 五、URL 路由拆分
+
+- config/urls_public.py：公共域名、官网、注册、登录、超级管理后台
+- config/urls_tenant.py：租户子域名、租户后台、房源/客源/带看/员工模块
+
+## 六、自定义 User Model（跨租户关键）
+
+- User 继承 AbstractUser
+- role 支持平台超管、公司管理员、门店经理、资深经纪人、经纪人、实习经纪人
+- Branch 作为门店模型
+
+## 七、初始化与常用命令
+
+- createdb realestate_saas
+- python manage.py migrate_schemas --shared
+- python manage.py createsuperuser
+- python manage.py shell 创建 Company 与 Domain
+
+示例：
+- schema_name = zuoan
+- domain = zuoan.localhost
+- 访问 http://zuoan.localhost:8000/admin/ 进入专属后台
+
+## 八、本地开发配置（hosts 文件）
+
+- 127.0.0.1 localhost
+- 127.0.0.1 zuoan.localhost
+- 127.0.0.1 lianhe.localhost
+- 127.0.0.1 xincheng.localhost
+
+开发环境要点：
+- ALLOWED_HOSTS 包含 .localhost
+- 本地不用 HTTPS
+
+## 九、数据隔离验证
+
+使用 schema_context 切换 schema，验证 Listing 等数据互相隔离。
+
+## 下一步建议
+
+推荐顺序：
+1. 先做房源/客源/带看完整数据模型
+2. 再做 Django Admin 深度定制（Jazzmin 主题）
+3. 最后补三级权限体系（总部/门店/经纪人）
+
+
+---
+
+# 上海房产中介 SaaS 系统规划
+
+## 一、多租户架构选型
+
+Django 多租户有三种主流方案，针对这个场景推荐独立 Schema 方案，也就是基于 PostgreSQL Schema 隔离的 django-tenants。
+
+| 方案 | 原理 | 优点 | 缺点 | 适用场景 |
+|---|---|---|---|---|
+| 共享 Schema | 每张表加 tenant_id 字段 | 简单，运维成本低 | 数据隔离风险高 | 小规模、低安全需求 |
+| 独立 Schema | PostgreSQL Schema 隔离 | 隔离好，性能佳 | 稍复杂 | 中介 SaaS，推荐 |
+| 独立数据库 | 每租户独立 DB | 最高隔离 | 运维成本极高 | 超高安全需求 |
+
+推荐使用 django-tenants：
+
+pip install django-tenants
+
+## 二、整体系统模块规划
+
+SaaS 平台层：
+- 租户注册
+- 套餐管理
+- 计费
+- 超级后台
+
+各中介公司 Tenant：
+- 房源管理
+- 客源管理
+- 员工 / 权限管理
+- 带看管理
+- 合同管理
+- 报表 / BI 看板
+- 渠道推广
+- 财务佣金
+- 消息 / 通知中心
+
+核心 Django App 拆分：
+- tenants：租户管理（公共 Schema）
+- accounts：用户 / 员工 / 角色权限
+- listings：房源管理（核心）
+- clients：客源 / 客户跟进
+- showings：带看记录
+- contracts：合同管理
+- commissions：佣金 / 财务
+- reports：数据报表
+- notifications：消息通知
+- subscription：套餐订阅（公共 Schema）
+
+## 三、房源模块数据模型（核心）
+
+Listing 关键字段包括：
+- 基础信息：title、listing_type、status
+- 上海地址结构：district、street、community、building、floor、unit
+- 房屋属性：area、inner_area、layout、orientation、decoration、floor_total
+- 价格：price、price_unit
+- 归属：agent、source、exclusive
+- 证件：certificate_no
+- 时间：created_at、updated_at
+
+## 四、技术栈推荐
+
+后端：
+- Django 5.x + DRF
+- django-tenants
+- django-guardian
+- celery + redis
+- django-filter
+- PostgreSQL 15+
+
+前端路径：
+- 路径 A：Django Admin + 定制，最快上手，适合 MVP
+- 路径 B：HTMX + Alpine.js + Tailwind，推荐中期方案
+- 路径 C：Vue3 / React + DRF，长期推荐
+
+建议：先 A，再 B，最后 C。
+
+## 五、租户路由设计
+
+通过子域名区分租户：
+- company-a.yourapp.com
+- company-b.yourapp.com
+- admin.yourapp.com
+
+核心设置：
+- TENANT_MODEL = "tenants.Company"
+- TENANT_DOMAIN_MODEL = "tenants.Domain"
+- SHARED_APPS 放公共应用
+- TENANT_APPS 放租户私有应用
+
+## 六、开发阶段规划
+
+Phase 1（1-2 月）MVP：
+- 租户注册 / 登录
+- 房源 CRUD + 图片上传
+- 客源基础管理
+- Django Admin 后台
+
+Phase 2（2-3 月）核心业务：
+- 带看流程
+- 合同模板 + 生成
+- 员工角色权限
+- 基础报表
+
+Phase 3（3-4 月）增长功能：
+- 佣金结算
+- 渠道推广（链家 / 安居客对接）
+- 微信小程序端
+- BI 数据看板
+
+Phase 4 商业化：
+- 套餐 / 计费系统
+- 多城市扩展
+
+## 七、优先推进建议
+
+如果要最快落地，建议优先顺序：
+1. django-tenants 完整配置
+2. 房源 / 客源 / 带看数据模型
+3. Django Admin 深度定制
+4. 权限系统设计
+5. 前端升级到 HTMX 或 Vue
+

Hermes/yunzhi/技术笔记/django-tenants 完整配置指南.md.bak.2026-04-21-184051

@@ -0,0 +1,98 @@
+---
+title: django-tenants 完整配置指南
+created: 2026-04-21
+tags: [django, django-tenants, postgresql, saas, multi-tenant]
+category: 技术笔记
+---
+
+# django-tenants 完整配置指南
+
+## 一、安装依赖
+
+pip install django-tenants psycopg2-binary django-jazzmin
+
+## 二、项目目录结构
+
+myproject/
+├── config/
+│   ├── settings/
+│   │   ├── base.py
+│   │   ├── development.py
+│   │   └── production.py
+│   ├── urls.py
+│   └── wsgi.py
+├── apps/
+│   ├── tenants/
+│   ├── subscription/
+│   ├── accounts/
+│   ├── listings/
+│   ├── clients/
+│   └── showings/
+├── manage.py
+└── requirements.txt
+
+## 三、核心 Model：租户与域名
+
+- Company 继承 TenantMixin
+- Domain 继承 DomainMixin
+- 每一个中介公司 = 一个租户 = 一个独立 PostgreSQL Schema
+- 每个公司可绑定多个域名/子域名
+
+## 四、Settings 完整配置
+
+关键点：
+- SHARED_APPS 放公共 Schema 应用
+- TENANT_APPS 放租户私有应用
+- TENANT_MODEL = "tenants.Company"
+- TENANT_DOMAIN_MODEL = "tenants.Domain"
+- DATABASES 使用 django_tenants.postgresql_backend
+- DATABASE_ROUTERS 使用 TenantSyncRouter
+- TenantMainMiddleware 必须第一个
+- ROOT_URLCONF / PUBLIC_SCHEMA_URLCONF 分离
+- AUTH_USER_MODEL = accounts.User
+
+## 五、URL 路由拆分
+
+- config/urls_public.py：公共域名、官网、注册、登录、超级管理后台
+- config/urls_tenant.py：租户子域名、租户后台、房源/客源/带看/员工模块
+
+## 六、自定义 User Model（跨租户关键）
+
+- User 继承 AbstractUser
+- role 支持平台超管、公司管理员、门店经理、资深经纪人、经纪人、实习经纪人
+- Branch 作为门店模型
+
+## 七、初始化与常用命令
+
+- createdb realestate_saas
+- python manage.py migrate_schemas --shared
+- python manage.py createsuperuser
+- python manage.py shell 创建 Company 与 Domain
+
+示例：
+- schema_name = zuoan
+- domain = zuoan.localhost
+- 访问 http://zuoan.localhost:8000/admin/ 进入专属后台
+
+## 八、本地开发配置（hosts 文件）
+
+- 127.0.0.1 localhost
+- 127.0.0.1 zuoan.localhost
+- 127.0.0.1 lianhe.localhost
+- 127.0.0.1 xincheng.localhost
+
+开发环境要点：
+- ALLOWED_HOSTS 包含 .localhost
+- 本地不用 HTTPS
+
+## 九、数据隔离验证
+
+使用 schema_context 切换 schema，验证 Listing 等数据互相隔离。
+
+## 下一步建议
+
+推荐顺序：
+1. 先做房源/客源/带看完整数据模型
+2. 再做 Django Admin 深度定制（Jazzmin 主题）
+3. 最后补三级权限体系（总部/门店/经纪人）
+

Leo/科学/Gravity – 以物理为基础的太阳系模拟器.md

@@ -0,0 +1,63 @@
+---
+title: Gravity – 以物理为基础的太阳系模拟器｜如果家里有喜欢问“为什么”的孩子，推荐收藏
+source: https://www.appinn.com/gravity-the-solar-system/
+author:
+  - "[[青小蛙]]"
+published: 2026-06-14
+created: 2026-06-19
+description: Gravity 是一个开源的太阳系模拟器，通过 24 个交互式动画，让小朋友了解整个太阳系，包括什么是引力？引力构建太阳/地球、为什么地球不会掉进太阳？火箭如何发射才不会掉下来等问题。
+tags:
+---
+孩子们总会问一些看似简单、却很难解释的问题：
+
+- 为什么地球不会掉进太阳里？
+- 月亮为什么不会掉到地球上？
+- 太阳那么大，为什么不会把所有行星都吸过去？
+- 火箭为什么能飞上太空？
+- 为什么火箭飞上去之后不会掉下来？
+
+如果干巴巴的直接解释，似乎毫无吸引力。
+
+但如果配合这个可以动的 Gravity：
+
+<iframe src="https://player.bilibili.com/player.html?isOutside=true&amp;aid=116747495672662&amp;bvid=BV11HJw6vEdc&amp;cid=39110510533&amp;p=1&amp;autoplay=0" frameborder="no" framespacing="0" allowfullscreen="true"></iframe>
+
+就很赞了。
+## Gravity：开源太阳系模拟器
+
+![Gravity – 以物理为基础的太阳系模拟器｜如果家里有喜欢问“为什么”的孩子，推荐收藏 1](https://www.appinn.com/wp-content/uploads/2026/06/Copy-of-appinn-homework-2026-06-14T162924.412.jpg)
+
+Gravity – 以物理为基础的太阳系模拟器｜如果家里有喜欢问“为什么”的孩子，推荐收藏 1
+
+Gravity 是一个开源的太阳系模拟器，通过 24 个交互式动画，让小朋友了解整个太阳系，包括什么是引力？引力构建太阳/地球、为什么地球不会掉进太阳？火箭如何发射才不会掉下来等问题。
+
+
+注意：一切都由真实的观测数据驱动；渲染器唯一进行“伪造”的是 **比例** ，使用了 **SpaceX 风格 UI** 。
+
+![Gravity – 以物理为基础的太阳系模拟器｜如果家里有喜欢问“为什么”的孩子，推荐收藏 2](https://www.appinn.com/wp-content/uploads/2026/06/Screenshot-2026-06-14-09.24.57-2x.avif)
+
+Gravity – 以物理为基础的太阳系模拟器｜如果家里有喜欢问“为什么”的孩子，推荐收藏 2
+
+1. **什么是引力？** (`#what-is-gravity`) —— 展示两个质量体及其之间相等且相反的力矢量（牛顿第三定律）；同样的力，产生不等的效应。
+2. **引力构建太阳** (`#birth-of-sun`) —— 尘埃云坍缩并旋转形成太阳（吸积动画）。
+3. **引力构建地球** (`#birth-of-earth`) —— 在剩余的圆盘中发生同样的微观过程；初生的地球在形成时闪烁着熔融的光芒。
+4. **运动的物体保持运动** (`#inertia`) —— 移除太阳；地球以恒定速度沿直线漂移（牛顿第一定律）。纯粹的惯性。
+5. **为什么地球不会掉进太阳** (`#why-no-fall`) —— 速度矢量 + 引力矢量 + 虚线的“无引力直线路径”。引力将直线弯曲成闭合环 —— 轨道就是持续坠落并始终错过。 …（及其他 19 个步骤）
+
+## 真实性说明
+
+- **大小** —— 每个天体都使用其真实的平均半径（太阳 696,340 公里 → 冥王星 1,188 公里）和质量。
+- **轨道** —— 使用来自 JPL/IAU 近似根数表的真实 J2000.0 日心开普勒根数（半长轴、离心率、倾角、升交点黄经、近日点黄经、平黄经）。每帧都会求解开普勒方程。
+- **日期** —— 时钟是真实的：T=0 对应 J2000 历元（2000-01-01 12:00）。
+
+最后，还有一个自由探索功能：
+## 获取
+
+- 直接用： [https://gravity.appinn.com](https://gravity.appinn.com/)
+- 代码在 [GitHub](https://github.com/scavin/Gravity/)
+
+---
+
+原文：https://www.appinn.com/gravity-the-solar-system/
+
+最后，青小蛙和小朋友一起看了这个 Gravity，没想到他居然耐着性子把 24 个问题看完了。

Project/fonrey/ADR.md

@@ -0,0 +1,353 @@
+# Fonrey ADR 动态决策记录（Architecture & Requirement Decision Records）
+
+> 目的：沉淀 Vibe Coding 过程中的**技术决策**与**需求决策**，避免跨会话后方案漂移。  
+> 适用范围：全项目（TECH_STACK / DATA_MODEL / PRD / TEST_CASES / 开发流程）。  
+> 维护原则：新增决策只追加，不覆盖历史；若决策被替代，必须新增 supersede 记录。
+
+---
+
+## 变更历史
+
+| 日期 | 变更人 | 变更内容 |
+|---|---|---|
+| 2026-04-30 | Atlas | 初始化 ADR 动态决策记录；补录当日关键技术与需求决策 |
+| 2026-05-02 | Sisyphus | 新增 ADR-20260502-001：合并系统管理与客户端发布两份 PRD 为统一的『平台管理后台 PRD』，原文件删除 |
+| 2026-05-02 | Sisyphus | 新增 ADR-20260502-003：定义『PRD 与 Tech 文档职责边界』规则（PRD 管 what/why、Tech 管 how）；首次落地于登录管理 PRD v3.0 |
+| 2026-06-04 | Sisyphus | 新增 ADR-20260604-001：列表分页全局采用 Keyset(cursor)，允许 page-based 作过渡兼容；同步修订 `UI_DESIGN/ROUTES.md` 与 `UI_DESIGN/房源管理/房源列表_UI.md` |
+| 2026-06-04 | Sisyphus | 新增 ADR-20260604-002：ROUTES.md 客源条目"重复客源(成交)"与"重复客源(公客)"合并为单条 `/clients/duplicates/?tab=transacted\|public`，客源条目数稳定为 19 |
+
+## 一、记录规范（必须遵守）
+
+### 1.1 决策ID规则
+- 格式：`ADR-YYYYMMDD-XXX`
+- 例：`ADR-20260430-001`
+
+### 1.2 决策类型
+- `TECH`：技术决策（架构、接口、数据、测试、流程规范）
+- `REQ`：需求决策（范围、术语、优先级、验收口径）
+
+### 1.3 状态枚举
+- `accepted`：已生效
+- `superseded`：已被替代（需指向新 ADR）
+- `deprecated`：废弃（不再执行）
+
+### 1.4 最小字段
+每条 ADR 必须包含：
+1. 决策ID
+2. 日期
+3. 模块
+4. 类型（TECH/REQ）
+5. 状态
+6. 背景
+7. 决策内容
+8. 影响范围
+9. 关联文档
+10. 备注（可选）
+
+---
+
+## 二、按日期记录（主索引）
+
+## 2026-04-30
+
+### ADR-20260430-001
+- **类型**：REQ
+- **模块**：测试治理（全局）
+- **状态**：accepted
+- **背景**：测试文档与沟通中存在“业务旅程/测试用例”术语混用，易导致执行偏差。
+- **决策**：全项目统一使用“测试用例”术语，不再以“业务旅程”作为执行口径。
+- **影响范围**：`TECH_STACK/测试规范.md`、`TEST_CASES/*`
+- **关联文档**：`TECH_STACK/测试规范.md`
+
+### ADR-20260430-002
+- **类型**：TECH
+- **模块**：测试治理（全局）
+- **状态**：accepted
+- **背景**：多模块并行时测试编号易重复、不可追溯。
+- **决策**：采用全局唯一测试用例编号：`TC-FON-XXXXXX`，并建立注册表，禁止复用废弃编号。
+- **影响范围**：所有测试用例文档与测试报告系统
+- **关联文档**：
+  - `TEST_CASES/TEST_CASE_ID_SPEC.md`
+  - `TEST_CASES/TEST_CASE_REGISTRY.md`
+
+### ADR-20260430-003
+- **类型**：TECH
+- **模块**：测试执行与报告
+- **状态**：accepted
+- **背景**：失败定位粒度不足，无法快速定位到具体步骤。
+- **决策**：测试报告必须支持 `test_case_id + step_id` 级追踪，并记录 `expected/actual/error_message` 与证据路径。
+- **影响范围**：CI 报告、自动化测试框架
+- **关联文档**：`TECH_STACK/测试规范.md`
+
+### ADR-20260430-004
+- **类型**：REQ
+- **模块**：登录管理
+- **状态**：accepted
+- **背景**：登录 PRD v2.0 与技术方案存在接口命名漂移。
+- **决策**：登录模块接口路径以 PRD v2.0 为唯一权威，技术方案与测试用例全部对齐 PRD 路径。
+- **影响范围**：登录模块 API 设计、自动化测试调用路径
+- **关联文档**：
+  - `PRD/登录管理/用户登录管理模块PRD.md`
+  - `TECH_STACK/登录管理技术方案.md`
+  - `TEST_CASES/TEST_CASES_LOGIN_MODULE.md`
+
+### ADR-20260430-005
+- **类型**：REQ
+- **模块**：登录管理
+- **状态**：accepted
+- **背景**：Story 边界存在历史遗留混淆。
+- **决策**：登录模块范围冻结为：短信验证码登录为 MVP 正式能力；“找回用户名”废弃；微信扫码保留为预留。
+- **影响范围**：实现范围、测试覆盖边界
+- **关联文档**：
+  - `PRD/登录管理/用户登录管理模块PRD.md`
+  - `TECH_STACK/登录管理技术方案.md`
+
+### ADR-20260430-006
+- **类型**：TECH
+- **模块**：客户端发布管理
+- **状态**：accepted
+- **背景**：发布模块缺少可执行技术方案，无法指导实现与测试。
+- **决策**：新增独立技术方案文档，明确 Electron 壳层边界、EV 签名、Heartbeat、自动更新、完整性校验、R2 版本管理、官网分发、便携版策略。
+- **影响范围**：`apps/release` 设计与落地
+- **关联文档**：
+  - `TECH_STACK/客户端发布管理技术方案.md`
+  - `PRD/发布管理/客户端发布管理模块PRD.md`
+
+### ADR-20260430-007
+- **类型**：TECH
+- **模块**：客户端发布管理 / 数据模型
+- **状态**：accepted
+- **背景**：统计口径需支撑跨租户版本分布与活跃安装数。
+- **决策**：以 `public.client_heartbeats` 作为心跳事实表，使用 `(tenant_id, device_id)` 为 Upsert 锚点，活跃定义为最近 24h。
+- **影响范围**：统计接口、看板与聚合查询
+- **关联文档**：`DATA_MODEL/DATA_MODEL_PUBLIC.md`
+
+### ADR-20260430-008
+- **类型**：TECH
+- **模块**：客户端发布管理 / 安全
+- **状态**：accepted
+- **背景**：下载链路存在篡改与损坏风险。
+- **决策**：客户端更新包必须进行 SHA256 完整性校验，校验失败禁止安装并保留当前版本可用。
+- **影响范围**：客户端更新器、发布接口响应字段
+- **关联文档**：
+  - `TECH_STACK/客户端发布管理技术方案.md`
+  - `PRD/发布管理/客户端发布管理模块PRD.md`
+
+### ADR-20260430-009
+- **类型**：TECH
+- **模块**：客户端发布管理 / API
+- **状态**：accepted
+- **背景**：历史文档存在 `/api/client/updates/*` 与 `/api/release/updates/*` 双口径。
+- **决策**：发布模块统一采用 `/api/release/...` 命名空间。
+- **影响范围**：服务端路由、客户端调用、测试用例
+- **关联文档**：
+  - `PRD/发布管理/客户端发布管理模块PRD.md`
+  - `TECH_STACK/TECH_STACK.md`
+  - `TECH_STACK/客户端发布管理技术方案.md`
+
+### ADR-20260430-010
+- **类型**：TECH
+- **模块**：文档治理（全局）
+- **状态**：accepted
+- **背景**：多目录文档缺少统一变更追溯入口。
+- **决策**：`TECH_STACK / DATA_MODEL / TEST_CASES` 下文档统一添加“变更历史”章节，并规范位置：**头部元信息之后、正文主章节（## 一/## 1）之前**。
+- **影响范围**：全量技术文档与测试文档
+- **关联文档**：
+  - `TECH_STACK/*.md`
+  - `DATA_MODEL/*.md`
+  - `TEST_CASES/*.md`
+
+---
+
+## 2026-05-02
+
+### ADR-20260502-001
+- **类型**：REQ
+- **模块**：平台管理后台（PRD 治理）
+- **状态**：accepted
+- **背景**：原 `PRD/系统管理/系统管理模块PRD.md`（v1.3）与 `PRD/发布管理/客户端发布管理模块PRD.md`（v1.2）虽分别归口「系统管理」与「客户端发布」，但二者实际受众均为**平台管理员**（Platform Admin / 运营人员 / 只读审计员），分别描述会导致：① 页面路由与权限矩阵在两份 PRD 中各自演化、容易割裂；② API 操作清单缺乏统一规划；③ 客户端发布 v1.1 已明确归属"平台运营后台"，与系统管理同处一域。
+- **决策**：
+  1. 合并为单一文档 `PRD/平台管理后台/平台管理后台PRD.md`（v1.0），定位「面向平台管理员的统一后台 PRD」；以产品视角统一规划页面清单、访问权限、页面间导航逻辑、业务 API 操作清单（不绑定具体路径）。
+  2. 原两份 PRD 文件**直接删除**，由新文档完全取代；新文档头部声明 supersede 关系。
+  3. 客户端运行时与平台之间的接口（如查询最新版本、上报心跳）维持在 `TECH_STACK/客户端发布管理技术方案.md` 中描述，本 PRD 仅描述平台管理员可执行的业务操作。
+  4. 角色权限矩阵、租户状态机、客户端版本治理（含全平台租户活跃榜）等内容统一并入新 PRD 第 5–7 章。
+- **影响范围**：
+  - PRD：删除 `PRD/系统管理/系统管理模块PRD.md`、`PRD/发布管理/客户端发布管理模块PRD.md`；新增 `PRD/平台管理后台/平台管理后台PRD.md`
+  - README：模块入口索引同步更新，原「系统管理」「客户端发布」入口指向新 PRD（客户端技术方案文档保留）
+  - TECH_STACK：`客户端发布管理技术方案.md` 关联 PRD 的引用需同步指向新 PRD
+- **关联文档**：
+  - `PRD/平台管理后台/平台管理后台PRD.md`
+  - `README.md`
+  - `TECH_STACK/客户端发布管理技术方案.md`
+  - `TECH_STACK/系统设置技术方案.md`
+- **备注**：本决策不改变任何技术口径（API 命名空间、`client_heartbeats` 表结构、SHA256 校验等），仅是 PRD 文档治理层面的合并与归属调整。`ADR-20260430-006/007/008/009` 全部继续生效。
+
+### ADR-20260502-002
+- **类型**：TECH
+- **模块**：平台管理后台（TECH_STACK 治理）
+- **状态**：accepted
+- **背景**：随 `ADR-20260502-001` 完成 PRD 合并后，TECH_STACK 域仍存在两份独立技术方案：`TECH_STACK/客户端发布管理技术方案.md`（v1.0）与 `TECH_STACK/系统管理技术文档.md`（v1.x）。两者受众一致（平台管理员后台），却分别演化路由表、API 命名空间、Mixin 守卫链与错误码，存在以下风险：① 路由守卫与 step-up MFA 协议在两文档中各自定义，易割裂；② API 命名空间（`/admin/...` 后台 vs `/api/release/...` 客户端运行时）缺乏统一约束；③ Celery 队列、Redis Key、错误码族无法横向对齐。
+- **决策**：
+  1. 合并为单一文档 `TECH_STACK/平台管理后台技术方案.md`（v1.0），覆盖 PRD 要求的三维度——**技术选型**（实现路由与 API 的框架）、**页面路由表**（路径定义、动态参数、路由守卫、懒加载）、**API 设计**（RESTful 路径、HTTP 方法、请求/响应、错误码、版本控制、认证方式）。
+  2. 原 `TECH_STACK/客户端发布管理技术方案.md` 与 `TECH_STACK/系统管理技术文档.md` **直接删除**，由新文档完全取代。
+  3. 双 API 命名空间最终落地：`/admin/...`（HTMX Partial，Session+CSRF+TOTP，无路径版本号）、`/admin/api/client-releases/...`（管理端 JSON 写操作）、`/api/release/v1/...`（客户端运行时，路径版本号 `v1`）。
+  4. App 拆分：`apps/admin_console`（租户/备份/导出/升级/审计/管理员/Feature Flag）+ `apps/release`（客户端发布 + 客户端运行时 API），后者仅依赖前者的 `permissions / middleware / services.audit_service`。
+  5. `TECH_STACK/TECH_STACK.md` §8 模块表合并「系统设置」「客户端发布」相关行为单行「平台管理后台」入口；README 模块入口同步指向新文档。
+- **影响范围**：
+  - TECH_STACK：新增 `平台管理后台技术方案.md`；删除 `客户端发布管理技术方案.md`、`系统管理技术文档.md`
+  - TECH_STACK：`TECH_STACK.md` §8 模块表
+  - README：模块入口索引（平台管理后台一行）
+- **关联文档**：
+  - `TECH_STACK/平台管理后台技术方案.md`
+  - `TECH_STACK/TECH_STACK.md`
+  - `PRD/平台管理后台/平台管理后台PRD.md`
+  - `ADR-20260502-001`、`ADR-20260430-006/007/008/009`
+- **备注**：本决策不变更任何技术口径（API 命名空间、`/api/release/v1/...` 版本号、SHA256 校验、`client_heartbeats` Upsert + 24h 活跃口径、审计不可变约束等），仅在 TECH_STACK 文档治理层面执行合并与归属调整。
+
+### ADR-20260502-003
+- **类型**：REQ
+- **模块**：文档治理（全局）
+- **状态**：accepted
+- **背景**：历史 PRD（如 `PRD/登录管理/用户登录管理模块PRD.md` v2.0、`PRD/平台管理后台/平台管理后台PRD.md` v1.0）混杂大量实现细节——具体 API 路径与 HTTP 方法、Redis Key 格式与 TTL、Django 字段类型与中间件类名、Electron API 名、CSS 类名、Cookie 属性等。这导致：① PRD 评审被技术细节淹没，业务边界讨论失焦；② 实现口径出现"PRD 写一份、Tech 写一份"的双源头，长期产生漂移（参见 `ADR-20260430-004` 已为登录模块单独修过一次）；③ 业务变更与技术调整混在同一份文档里，变更范围与责任人难以拆分。
+- **决策**：自本 ADR 起，全项目 PRD 与 Tech 文档严格遵循以下职责边界，任何新建/修订必须自检通过。
+
+  **PRD 应包含（"是什么 / 为什么"）**：
+  1. **页面与导航**：列出页面清单、访问权限（角色矩阵）、用户视角的页面间跳转逻辑、登录态/未登录态分支。✅ "/dashboard 需登录后访问"；✅ "用户点击『详情』后跳转到订单详情页"。
+  2. **业务操作清单**：以业务动词描述用户/角色可执行的能力。✅ "用户可查询自己的订单列表"；✅ "管理员可批量更新商品状态"。
+  3. **业务规则与数据约束**：抽象层面的规则与数值阈值（如『密码连续错误 5 次锁定 30 分钟』『短信验证码有效期 10 分钟』），但仅以业务语言表达，不绑定 Redis Key 或字段名。
+  4. **状态机**：业务状态枚举与合法跃迁。
+  5. **验收标准**：可由产品/QA 验证的用户可见行为。
+
+  **PRD 必须移出（移交 Tech / DATA_MODEL）**：
+  1. ❌ 具体 API 路径（如 `POST /api/auth/login/phone/`）与 HTTP 方法。
+  2. ❌ 请求/响应 JSON Schema、字段名、错误码常量。
+  3. ❌ Redis Key 格式、TTL、缓存策略、消息队列名。
+  4. ❌ 数据库字段名、字段类型（`CharField(30)`、`OneToOneField`）、表名、索引名、中间件类名。
+  5. ❌ 前端框架/库的 API 名（`BrowserWindow.loadURL`、`electron-store`、`HX-Request` 头）、CSS 类名、Cookie 属性（`SameSite=Strict`、`HttpOnly`）。
+  6. ❌ 实现选型与库依赖清单（除非业务上明确强制，如"必须由具备短信资质的服务商发送"）。
+
+  **PRD 引用 Tech 的标准格式**：当业务规则需要技术细节落地时，PRD 用以下任一方式引用：
+  - "（实现细节详见 `TECH_STACK/<模块>技术方案.md` §X.Y）"
+  - "（数据结构见 `DATA_MODEL/<模块>.md`）"
+  - "（端点契约见 `TECH_STACK/API_CONTRACT.md`）"
+
+  **Tech 文档应承接**：上述被移出的全部内容；若 PRD 移出某项时 Tech 文档尚未承接，**必须在同一次提交内同步补齐 Tech**，禁止信息丢失。
+
+  **测试用例不受本 ADR 约束**：测试用例本质上需要可执行的实现细节（路径、字段、错误码），保留细节不动；但其引用 PRD 章节时应同步更新章节号。
+
+- **影响范围**：
+  - PRD：所有 PRD 文档需按本规则审视并修订（首批落地：登录管理 PRD → v3.0；后续模块按需推进）
+  - TECH_STACK：所有 Tech 文档需承接对应实现细节，缺口必须同步补齐
+  - 未来所有新建 PRD：必须自检本规则
+  - CI/Review：建议在 PR Review checklist 增加"PRD 是否含具体 API 路径/Redis Key/字段类型"的反向检查项
+- **关联文档**：
+  - `AGENTS.md` §9.1（ADR 治理联动规则）
+  - `PRD/登录管理/用户登录管理模块PRD.md`（v3.0 首批落地）
+  - `TECH_STACK/登录管理技术方案.md`（同步承接被移出细节）
+  - `ADR-20260430-004`（登录接口路径以 PRD 为准 → 本 ADR 后语义升级为：业务能力以 PRD 为准，具体路径以 Tech 为准；不冲突，互补）
+- **备注**：本 ADR 不更改任何已实现的技术口径，仅约束**文档承载位置**。`ADR-20260430-004` 关于"登录接口最终路径"的权威源仍以两份文档同步为准（PRD 描述业务操作、Tech 描述具体路径），二者不应再次出现漂移。
+
+---
+
+## 2026-06-04
+
+### ADR-20260604-001
+- **类型**：TECH
+- **模块**：列表分页（全局）
+- **状态**：accepted
+- **背景**：`AGENTS.md` §4.5 与 `UI_DESIGN/ROUTES.md` §1 全局约定明文要求"所有列表查询必须使用 Keyset 分页（参数禁止包含 `offset`，统一使用 `cursor`）"。但 `UI_DESIGN/房源管理/房源列表_UI.md` 现存示例（行 97 query params 列表、行 741 HTMX `hx-vals='{"page": N}'`）仍是 page-based 风格，与全局规范冲突。MVP 阶段一次性切到 Keyset 会拖慢前端模板与示例代码改造节奏，且页码 UI（`[1][2][3]...[N]`）已被多份截图与组件清单采用。
+- **决策**：
+  1. **目标口径**：列表分页长期统一为 Keyset(cursor)；新增列表页与新增分页 API 不得使用 page/offset。
+  2. **过渡兼容**：MVP Phase 1 期间，已有 page-based 示例的模块文档与代码可保留 page UI 表现（页码导航 + 跳页），但**数据获取层必须支持 cursor 参数**；后端 API 接受 `cursor` 为主参数，`page` 仅作过渡兼容输入且不得用于 1000 条以上数据集。
+  3. **文档承接**：`UI_DESIGN/ROUTES.md` §1 通用约定新增"过渡兼容"说明；`UI_DESIGN/房源管理/房源列表_UI.md` 示例代码改为 `cursor`，分页 UI 表现保留。
+  4. **退出条件**：MVP GA 后 1 个版本内，所有 page-based 示例必须清理；届时新增 ADR 关闭本过渡条款。
+- **影响范围**：
+  - `UI_DESIGN/ROUTES.md` §1
+  - `UI_DESIGN/房源管理/房源列表_UI.md` §2.1.1、§2.1.3 分页栏
+  - 后续所有列表页 HTMX 模板与 API 视图
+- **关联文档**：
+  - `AGENTS.md` §4.5
+  - `UI_DESIGN/ROUTES.md`
+  - `UI_DESIGN/房源管理/房源列表_UI.md`
+- **备注**：B-04（Keyset 分页规范缺位）由本 ADR 部分关闭；剩余的列表索引矩阵补全留待后续 Major 修订。
+
+### ADR-20260604-002
+- **类型**：REQ
+- **模块**：客源管理（路由汇总）
+- **状态**：accepted
+- **背景**：`UI_DESIGN/ROUTES.md` §5 客源条目数与历史 handoff 口径"客源 19 项"不一致——实际列出 20 行，多出的 1 行来自将"重复客源（成交）"与"重复客源（公客）"拆分为两条独立路由。两者复用同一列表页结构、同一权限范围、同一组件清单，仅业务子集不同，符合 ROUTES.md 全局约定中"Tab 维度统一用 `?tab=` 表达"的模式。
+- **决策**：将两条重复客源路由合并为单条 `/clients/duplicates/`，子集通过 `?tab=transacted|public` 区分；客源条目总数稳定为 19。
+- **影响范围**：
+  - `UI_DESIGN/ROUTES.md` §5（合并 2 行为 1 行）
+- **关联文档**：
+  - `UI_DESIGN/ROUTES.md`
+  - `UI_DESIGN/客源管理/客源列表_UI.md`
+- **备注**：本 ADR 不变更任何业务规则，仅统一 URL 表达形式与条目计数。
+
+---
+
+## 三、按模块分类记录（视图索引）
+
+## 3.1 测试治理（全局）
+- `ADR-20260430-001`：术语统一为“测试用例”（REQ）
+- `ADR-20260430-002`：全局唯一测试编号机制（TECH）
+- `ADR-20260430-003`：报告粒度到 step_id（TECH）
+
+## 3.2 登录管理
+- `ADR-20260430-004`：接口路径以 PRD 为准（REQ）
+- `ADR-20260430-005`：MVP 范围冻结（REQ）
+
+## 3.3 客户端发布管理
+- `ADR-20260430-006`：新增独立技术方案（TECH） *(superseded by `ADR-20260502-002`，技术方案已合并至『平台管理后台技术方案』)*
+- `ADR-20260430-008`：SHA256 完整性校验强制（TECH）
+- `ADR-20260430-009`：API 命名空间统一 `/api/release/...`（TECH）
+
+## 3.4 数据模型（public schema）
+- `ADR-20260430-007`：`client_heartbeats` Upsert + 24h 活跃口径（TECH）
+
+## 3.5 文档治理（全局）
+- `ADR-20260430-010`：变更历史章节统一规则（TECH）
+- `ADR-20260502-003`：PRD 与 Tech 文档职责边界（REQ）
+
+## 3.6 平台管理后台
+- `ADR-20260502-001`：合并系统管理 PRD 与客户端发布 PRD 为统一的『平台管理后台 PRD』（REQ）
+- `ADR-20260502-002`：合并系统管理技术文档与客户端发布技术方案为统一的『平台管理后台技术方案』（TECH）
+
+## 3.7 列表分页（全局）
+- `ADR-20260604-001`：Keyset(cursor) 为目标口径；MVP 期允许 page-based 作过渡兼容（TECH）
+
+## 3.8 客源管理（路由）
+- `ADR-20260604-002`：重复客源合并为单条 `/clients/duplicates/?tab=transacted|public`，客源条目数=19（REQ）
+
+---
+
+## 四、历史记录（Append-Only Log）
+
+> 说明：本节为机器可检索的历史流水，不删改旧记录。
+
+| ADR ID | 日期 | 模块 | 类型 | 状态 | 摘要 | 关联 |
+|---|---|---|---|---|---|---|
+| ADR-20260430-001 | 2026-04-30 | 测试治理 | REQ | accepted | 术语统一为“测试用例” | `TECH_STACK/测试规范.md` |
+| ADR-20260430-002 | 2026-04-30 | 测试治理 | TECH | accepted | 测试编号全局唯一 `TC-FON-XXXXXX` | `TEST_CASES/TEST_CASE_ID_SPEC.md` |
+| ADR-20260430-003 | 2026-04-30 | 测试执行 | TECH | accepted | 报告必须定位到 `test_case_id+step_id` | `TECH_STACK/测试规范.md` |
+| ADR-20260430-004 | 2026-04-30 | 登录管理 | REQ | accepted | 登录接口路径全部按 PRD v2.0 | `TECH_STACK/登录管理技术方案.md` |
+| ADR-20260430-005 | 2026-04-30 | 登录管理 | REQ | accepted | 登录模块范围冻结（含废弃/预留） | `PRD/登录管理/用户登录管理模块PRD.md` |
+| ADR-20260430-006 | 2026-04-30 | 客户端发布 | TECH | accepted | 新建独立技术方案文档 | `TECH_STACK/客户端发布管理技术方案.md` |
+| ADR-20260430-007 | 2026-04-30 | 数据模型 | TECH | accepted | `client_heartbeats` Upsert + 24h 活跃 | `DATA_MODEL/DATA_MODEL_PUBLIC.md` |
+| ADR-20260430-008 | 2026-04-30 | 客户端发布安全 | TECH | accepted | SHA256 校验失败禁止安装 | `TECH_STACK/客户端发布管理技术方案.md` |
+| ADR-20260430-009 | 2026-04-30 | 客户端发布 API | TECH | accepted | 统一 `/api/release/...` 路径 | `TECH_STACK/TECH_STACK.md` |
+| ADR-20260430-010 | 2026-04-30 | 文档治理 | TECH | accepted | 变更历史章节位置统一规范 | `TECH_STACK/*.md` `DATA_MODEL/*.md` `TEST_CASES/*.md` |
+| ADR-20260502-001 | 2026-05-02 | 平台管理后台 | REQ | accepted | 合并系统管理 PRD + 客户端发布 PRD 为『平台管理后台 PRD』，原文件删除 | `PRD/平台管理后台/平台管理后台PRD.md` |
+| ADR-20260502-002 | 2026-05-02 | 平台管理后台 | TECH | accepted | 合并系统管理技术文档 + 客户端发布技术方案为『平台管理后台技术方案』（覆盖技术选型/页面路由表/API 设计三维度），原文件删除 | `TECH_STACK/平台管理后台技术方案.md` |
+| ADR-20260502-003 | 2026-05-02 | 文档治理 | REQ | accepted | PRD 管 what/why、Tech 管 how；PRD 必须移出 API 路径/Redis Key/字段类型/框架 API 等实现细节，由 Tech 与 DATA_MODEL 承接 | `PRD/登录管理/用户登录管理模块PRD.md` v3.0 |
+| ADR-20260604-001 | 2026-06-04 | 列表分页（全局） | TECH | accepted | Keyset(cursor) 为目标口径；MVP 期允许 page-based 作过渡兼容 | `UI_DESIGN/ROUTES.md`、`UI_DESIGN/房源管理/房源列表_UI.md` |
+| ADR-20260604-002 | 2026-06-04 | 客源管理（路由） | REQ | accepted | 重复客源合并为单条 `/clients/duplicates/?tab=transacted\|public`，客源条目数=19 | `UI_DESIGN/ROUTES.md` |
+
+---
+
+## 五、后续维护约定
+
+1. 每当接受新技术或需求决策，**当天必须新增 ADR 条目**。  
+2. 若新决策替代旧决策，在新 ADR 中写明 `supersedes: ADR-xxxx`，并将旧条目标记 `superseded`。  
+3. PRD / TECH_STACK / DATA_MODEL / TEST_CASES 发生关键口径变化时，必须同步更新本文件。  
+4. 本文件是跨 Session 的决策权威输入之一，和 PRD 一起喂给 Agent。

Project/fonrey/AGENTS.md

@@ -0,0 +1,324 @@
+> **For AI assistants**: Read this entire file before writing any code. All decisions here are final. Do not suggest alternatives unless asked. Every new feature or User Story implementation must be accompanied by corresponding tests as defined in this document.
+
+# Fonrey（房睿）— AGENTS.md
+
+**适用对象**：所有 AI Coding Agent（vibe coding 模式）  
+**文档定位**：开发启动前的强制阅读清单，定义架构约定、禁止项和文档导航  
+**最后更新**：2026-04-27
+
+---
+
+## 1. 项目概览
+
+**Fonrey（房睿）房产经纪管理系统** —— 面向房地产经纪公司的 B2B SaaS 平台，解决房源/客源信息散乱、跟进缺失、重复录入等痛点，支撑单租户 89,000+ 房源数据量级下的高效匹配。
+
+- **核心模块**：房源管理、客源管理、楼盘管理、组织人事、权限管理、登录管理、系统设置、客户端发布
+- **目标用户**：一线经纪人（高频）、店长/经理（每日）、运营/行政（每日）、系统管理员（不定期）
+- **形态**：Web 端为主 + Electron 桌面客户端（壳应用）；移动端为 v2 规划
+- **设计哲学**：数据一致性 > 录入/筛选速度 > UI 简洁高效。优先保障多租户数据物理隔离与极速响应。
+
+---
+
+## 2. 核心技术栈
+
+| 层级 | 技术选型 | 说明 |
+|---|---|---|
+| **Frontend** | HTMX + Alpine.js + Tailwind CSS | 无重前端框架；HTMX 局刷、Alpine 管状态、Tailwind 样式 |
+| **Backend** | Django 4.x（ASGI 模式） | 支持异步能力 |
+| **Multi-tenant** | `django-tenants` | PostgreSQL Schema 隔离，租户数据物理安全 |
+| **Database** | PostgreSQL 16 + PgBouncer | 连接池优化，支撑高并发 |
+| **Cache** | Redis | 缓存、限流、Token、权限快照 |
+| **Tasks** | Celery + Celery Beat | 异步导出、智能配房、邮件、图片转码 |
+| **Storage** | Cloudflare R2（S3 兼容） | 房源图片、附件、客户端安装包 |
+| **CDN** | Cloudflare | 静态资源 + 客户端更新包加速 |
+| **Server** | Gunicorn + Uvicorn workers + Nginx | ASGI 服务部署 |
+| **Monitoring** | Sentry + Grafana | 错误追踪 + 指标监控 |
+| **Deployment** | Docker Compose | 容器化部署 |
+| **Desktop Client** | Electron + electron-updater | 壳应用，渲染层复用 Web 技术栈 |
+
+---
+
+## 3. 目录结构
+
+代码库标准目录结构如下，**严格遵循**，不得自行创建新的顶层目录：
+
+```
+fonrey/
+├── apps/
+│   ├── tenant/          # django-tenants 配置（shared_apps）
+│   ├── account/         # 登录认证
+│   ├── permission/      # 权限管理
+│   ├── org/             # 组织人事（org_units, staff）
+│   ├── region/          # 区域管理（districts, business_areas）
+│   ├── complex/         # 楼盘管理（complexes, buildings, schools）
+│   ├── property/        # 房源核心（含 models/services/tasks 三层）
+│   ├── client/          # 客源管理
+│   ├── setting/         # 系统设置（lookup, tags）
+│   └── release/         # 客户端发布管理（shared_apps）
+├── shared/              # 公共 Schema App（public schema 模型）
+└── core/
+    ├── models/base.py   # 抽象基类（所有业务表继承）
+    ├── encryption.py    # PII 加密（AES-256-GCM）
+    └── cache.py         # Redis 工具（含 tenant 前缀）
+```
+
+**Django App 内部分层规范**（以 `property` 为典型，所有 App 参照执行）：
+
+```
+apps/property/
+├── models/         # 一表一文件，禁止全部堆在 models.py
+├── services/       # 业务逻辑（完成度计算、重复检测、匹配等）
+├── tasks.py        # Celery 异步任务
+├── views.py        # HTMX/JSON 视图（薄视图，调 services）
+└── urls.py
+```
+
+---
+
+## 4. 关键开发约定
+
+### 4.1 多租户隔离（最高优先级）
+
+- 所有数据库查询**必须**基于当前租户 Schema；`django-tenants` 中间件已自动切换，不得绕过
+- **严禁**跨租户 SQL 查询（包括 raw SQL 和 ORM 的 `using()` 指定 public schema）
+- `shared_apps` 仅放平台基础数据：`Tenant`、`ClientRelease`、`PermissionDef`、`PlatformAdmin` 等
+- Celery 任务必须在任务参数中传入 `tenant_schema_name`，任务开头调用 `connection.set_schema(schema_name)` 切换到正确 Schema，**不得依赖外部上下文传递**
+
+### 4.2 前端交互约定
+
+- **HTMX** 处理局部 DOM 刷新：分页、筛选、联想搜索、表单提交
+- **Alpine.js** 处理前端状态：弹窗开关、多选状态、字数统计、条件显示
+- **禁止**编写复杂原生 JavaScript；逻辑无法用 HTMX/Alpine 覆盖时，优先提出问题而不是自行引入 JS 库
+- HTMX 请求失败（4xx/5xx）必须触发全局 Toast 提示（通过 `HX-Trigger` 响应头）
+- 所有 HTMX 局部请求后端视图必须校验 `HX-Request` header，防止直接访问返回残缺 HTML
+
+### 4.3 异步任务约定
+
+- 所有耗时 **> 500ms** 的操作**必须**经 Celery 异步执行：Excel 导出、图片处理、智能配房、邮件发送、完成度重算
+- Celery Beat 定时任务：私客自动转公客（每小时）、重复客源检测（每日）
+- 任务状态存 Redis，前端通过轮询 HTMX 端点展示进度
+
+### 4.4 数据模型约定
+
+| 约定 | 规则 |
+|------|------|
+| 主键类型 | `UUID v4`（`gen_random_uuid()`），禁止自增整数 |
+| 软删除 | 所有核心表含 `deleted_at TIMESTAMPTZ`，查询默认加 `WHERE deleted_at IS NULL` |
+| 时间戳 | 全部使用 `TIMESTAMPTZ`（含时区），禁止 naive datetime |
+| 手机号存储 | AES-256-GCM 加密，建立 SHA-256 哈希索引，通过 `core/encryption.py` 操作 |
+| 审计字段 | `created_by UUID`、`updated_by UUID` 全表覆盖 |
+| 枚举值 | 业务枚举用 `VARCHAR + CHECK CONSTRAINT`；不得在代码中硬编码中文枚举值 |
+| 金额 | `NUMERIC(12,2)` 万元精度，禁止 FLOAT |
+| 大文本 | `TEXT` 类型，不设长度限制 |
+| 不可删除记录 | `listing_histories`、`price_changes` 无 `deleted_at`，append-only，禁止物理删除 |
+
+### 4.5 查询性能约定
+
+- 列表查询目标：89,000 条房源 / 200 万条跟进日志下，p95 响应 **< 2 秒**
+- **所有列表查询必须使用 Keyset 分页**（`WHERE id > :last_id ORDER BY id`），禁止 OFFSET 分页用于大数据量场景
+- 新增表必须在 migration 中同步创建必要索引，不得事后补建
+- 高写入表（`follow_logs`、`property_photos`、`permission_change_logs`、`login_attempts`）必须按月分区（`PARTITION BY RANGE`）
+
+### 4.6 安全约定
+
+- 手机号等 PII 数据统一通过 `core/encryption.py` 加密存储，**禁止明文入库**
+- 所有配置（密钥、Bucket 名、外部服务 URL）通过 `.env` 注入，**禁止硬编码**
+- 每个受权限保护的 View 必须覆盖三个测试场景：有权限（200）、无权限（403）、未登录（302）
+- Redis Key 必须携带租户 Schema 前缀，格式：`{tenant_schema}:{module}:{key}`
+
+### 4.7 错误处理约定
+
+- 后端 API 返回标准 JSON 错误格式：`{"error": "...", "code": "SNAKE_CASE_CODE"}`
+- View 层禁止直接抛出异常，必须捕获并返回对应 HTTP 状态码
+- Celery 任务失败必须记录到 Sentry，并更新任务状态表
+
+### 4.8 文件命名约定
+
+- Django App：`snake_case`（如 `property`、`follow_log`）
+- 前端模板组件：`kebab-case`（如 `property-card.html`、`client-form.html`）
+- Migration 文件：不得手动重命名，保留 Django 自动生成的序号
+
+---
+
+## 5. 禁止项（Do NOT — 违反视为 Bug）
+
+- ❌ **React / Vue / Angular** 等重前端框架
+- ❌ 在请求线程中处理耗时 **> 500ms** 的任务（必须用 Celery）
+- ❌ 传统页面全刷方案（除初始页面加载外）
+- ❌ 复杂原生 JavaScript（优先 HTMX/Alpine 指令）
+- ❌ Electron 渲染进程开启 `nodeIntegration: true`
+- ❌ 客户端内嵌业务逻辑或本地数据库（壳应用原则，渲染层只加载 Web URL）
+- ❌ 跨租户 SQL 查询（必须经 `django-tenants` 中间件切换 Schema）
+- ❌ 代码中硬编码密钥、Tenant ID、URL、枚举中文字符串
+- ❌ 使用 OFFSET 分页处理 1000 条以上数据集
+- ❌ 手机号/身份证号明文存储
+- ❌ 使用 Django 原生 `Client()` 做集成测试（必须用 `TenantClient`）
+- ❌ 在 MVP 阶段实现 `PRD_MVP.md §3` 中标注的 Out-of-Scope 功能（移动端、合同、财务、新房、三网发布等）
+
+---
+
+## 6. 测试要求
+
+**核心原则**：每个 P0 User Story 完成后，对应测试必须同步产出，**不允许欠测试债**。
+
+### 测试分层
+
+| 层级 | 工具 | 覆盖目标 | 运行频率 |
+|------|------|---------|---------|
+| **单元测试** | `pytest-django` + `factory_boy` | `core/`、`services/`、`tasks.py` | 每次 push |
+| **集成测试** | `pytest-django` + `TenantClient` | 所有 P0 User Story 的 HTTP 接口 | 每次 push |
+| **E2E 测试** | `playwright` (Python) | 5 条核心用户旅程 | 每日定时 |
+
+### 测试关键约定
+
+- 集成测试**必须**使用 `TenantClient`，禁止使用 Django 原生 `Client()`
+- HTMX 局部请求测试须携带 `HTTP_HX_REQUEST: true` header，验证返回局部 HTML 而非完整页面
+- Celery 任务测试使用 `CELERY_TASK_ALWAYS_EAGER = True` 同步执行
+- 外部服务（R2、Redis、邮件）在测试中全部 Mock，禁止真实调用
+- 权限测试必须覆盖：有权限（200）、无权限（403）、未登录（302）三场景
+
+### 覆盖率基准
+
+| 模块 | 最低目标 |
+|------|---------|
+| `core/` 核心基础模块 | ≥ 90% |
+| `apps/*/services/` 业务逻辑层 | ≥ 80% |
+| `apps/*/views.py` 视图层 | ≥ 70% |
+| E2E 核心用户旅程（5 条） | 100% 通过 |
+
+---
+
+## 7. MVP 范围（Phase 1）
+
+**当前阶段**：MVP Phase 1（P0 功能）
+
+实现任何功能前，先对照 `PRD/PRD_MVP.md` 确认是否在 P0 范围。**P0 范围以外的功能在 MVP 阶段禁止实现**，包括但不限于：
+
+- 移动端适配（v2 规划）
+- 新房模块、合同、财务、三网发布
+- 公客管理（P2）
+- 门店分布地图（P2）
+
+**当前 Phase 1 P0 Task 列表**：见 `PRD/TASK.md §Phase 1`（US-ACCOUNT-001~003、US-COMPLEX-001~003、US-PROPERTY-001~008、US-CLIENT-001~017、US-ORG-001~003、US-PERMISSION-001~005、US-SETTING-001）
+
+---
+
+## 8. 数据模型参考（实现前必读）
+
+所有数据模型的**权威来源**如下，开发前必须阅读对应文档，不得凭印象实现：
+
+| 模块 | 数据模型权威文档 |
+|------|---------------|
+| 总览 & 架构决策 | `DATA_MODEL/DATA_MODEL.md` |
+| 房源管理 | `DATA_MODEL/DATA_MODEL_PROPERTY.md` |
+| 客源管理 | `DATA_MODEL/DATA_MODEL_CLIENT.md` |
+| 楼盘/小区/区域 | `DATA_MODEL/DATA_MODEL_COMPLEX.md` |
+| 组织人事 | `DATA_MODEL/DATA_MODEL_ORG.md` |
+| 权限管理 | `DATA_MODEL/DATA_MODEL_PERMISSION.md` |
+| 登录认证 | `DATA_MODEL/DATA_MODEL_LOGIN.md` |
+| Public Schema（平台运营层） | `DATA_MODEL/DATA_MODEL_PUBLIC.md` |
+| 系统配置（lookup/setting） | `DATA_MODEL/DATA_MODEL_SETTING.md` |
+
+### 核心领域关系速览
+
+```
+[区域/商圈] ──────────────────────────────┐
+     │                                  │
+[学校管理]                               │
+     │                                  ▼
+[楼盘/小区] ── [楼栋] ──────────► [房源] ◄──── [挂牌历史]
+     │                               │
+     │                      ┌────────┼────────┐
+     │                      │        │        │
+     │                 [联系人]  [跟进日志] [维护完成度]
+     │
+[客源] ──── [配对记录] ──── [带看记录]
+     │
+[员工/组织] ──── [权限]
+```
+
+---
+
+## 9. 技术方案文档导航
+
+| 模块 | 技术方案文档 | PRD |
+|------|------------|-----|
+| 总纲 & 禁止项 | `TECH_STACK/TECH_STACK.md` | `PRD/PRD_MVP.md` |
+| 登录认证 | `TECH_STACK/登录管理技术方案.md` | `PRD/登录管理/` |
+| 权限管理 | `TECH_STACK/权限管理系统技术方案.md` | `PRD/权限管理/` |
+| 测试规范 | `TECH_STACK/测试规范.md` | — |
+| 房源管理 | `TECH_STACK/房源管理技术方案.md` | `PRD/房源管理/` |
+| 客源管理 | `TECH_STACK/客源管理技术方案.md` | `PRD/客源管理/` |
+| 楼盘管理 | `TECH_STACK/楼盘管理技术方案.md` | `PRD/房源管理/（含楼盘）` |
+| 组织人事 | `TECH_STACK/组织人事技术方案.md` | `PRD/组织人事管理/` |
+| 系统设置 | `TECH_STACK/系统设置技术方案.md` | `PRD/系统配置/`、`PRD/系统管理/` |
+| 客户端发布 | `TECH_STACK/客户端发布管理技术方案.md` | `PRD/发布管理/客户端发布管理模块PRD.md` |
+| ADR 决策记录 | `ADR.md` | 全局（TECH/REQ） |
+
+**设计 Review 记录**（了解当前已知技术债与阻塞项）：  
+- `REVIEW/REVIEW_全局_2026-04-26.md`（最新）  
+- `REVIEW/REVIEW_全局_2026-04-25.md`
+
+---
+
+### 9.1 ADR 治理联动规则
+
+- 任何跨模块规则、口径或范围边界调整，先记录 `ADR.md`，再改对应 TECH_STACK/PRD/DATA_MODEL/TEST_CASES 文档。
+- 若已有结论被替代，必须在 ADR 中新增 superseded 记录并引用新 ADR ID，禁止直接覆盖历史。
+- 涉及上述变更的 PR/提交说明，必须包含 ADR ID（`ADR-YYYYMMDD-XXX`）。
+
+## 10. 已知待解决问题（编码前必须确认）
+
+以下问题在开始编码前需先确认当前状态，若未解决应在实现对应模块前暂停并上报：
+
+| 编号 | 级别 | 问题描述 | 影响模块 |
+|------|------|---------|---------|
+| **B-01** | 🔴 Blocker | 系统配置 PRD（`PRD/系统配置/系统配置.md`）为空骨架，US-SETTING-001 无法启动 | 系统配置 |
+| **B-02** | 🔴 Blocker | 核心枚举三方不一致（PRD ↔ DDL ↔ TASK AC）：客源 status/grade、房源 status 互相矛盾，需先冻结 `DATA_MODEL/ENUMS.md` | 房源、客源 |
+| **B-03** | 🔴 Blocker | 权限数据范围档位冲突：§3 非目标"三档" vs §5.6"五档"，DataScope 实现方式未统一 | 权限管理 |
+| **B-04** | 🔴 Blocker | Keyset 分页规范完全缺位，89k 房源列表设计错误 | 房源、客源 |
+| **M-02** | 🟠 Major | 主表 `properties`/`clients` 缺乏乐观锁字段 `version` | 房源、客源 |
+| **M-03** | 🟠 Major | 高写入表分区 DDL 未落地（`follow_logs` 等） | 跟进日志 |
+| **M-04** | 🟠 Major | Celery 多租户 schema 切换规范、R2 文件路径前缀规范、查询索引矩阵未补充 | 全局 |
+
+> 详细内容见 `REVIEW/REVIEW_全局_2026-04-26.md`
+
+---
+
+## 11. 文档根目录
+
+所有项目文档位于：`/mnt/d/Workspace/nexus/Project/fonrey/`
+
+```
+fonrey/
+├── AGENTS.md                   # 本文件（AI Agent 开发指南）
+├── PRD/
+│   ├── PRD_MVP.md              # MVP 范围书（必读）
+│   ├── TASK.md                 # 全量 Task Board（US 编号）
+│   ├── 房源管理/
+│   ├── 客源管理/
+│   ├── 楼盘管理/
+│   ├── 组织人事管理/
+│   ├── 权限管理/
+│   ├── 登录管理/
+│   ├── 系统配置/
+│   ├── 系统管理/
+│   └── 发布管理/
+├── DATA_MODEL/
+│   ├── DATA_MODEL.md           # 数据模型总览（必读）
+│   ├── DATA_MODEL_PROPERTY.md
+│   ├── DATA_MODEL_CLIENT.md
+│   ├── DATA_MODEL_COMPLEX.md
+│   ├── DATA_MODEL_ORG.md
+│   ├── DATA_MODEL_PERMISSION.md
+│   ├── DATA_MODEL_LOGIN.md
+│   └── DATA_MODEL_PUBLIC.md
+├── TECH_STACK/
+│   ├── TECH_STACK.md           # 技术栈总纲（必读）
+│   ├── 登录管理技术方案.md
+│   ├── 权限管理系统技术方案.md
+│   └── 测试规范.md
+└── REVIEW/
+    ├── REVIEW_全局_2026-04-26.md  # 最新 Review（含阻塞问题）
+    └── REVIEW_全局_2026-04-25.md
+```

Project/fonrey/DATA_MODEL/DATA_MODEL.md

@@ -0,0 +1,854 @@
+> **For AI assistants**: Read this entire file before writing any code. All decisions here are final. Do not suggest alternatives unless asked.
+# Fonrey 房产经纪管理系统 — DATA MODEL 设计文档
+
+> **作者**: Backend Architect  
+> **版本**: v1.5  
+> **日期**: 2026-04-30（v1.1 修复 S1/S2/S4；v1.2 扩展 public schema；v1.3 §三 DDL 迁至 DATA_MODEL_PUBLIC.md，本文改为索引；v1.4 补充 LOGIN/PERMISSION 子文档引用、领域对象、租户 Schema 章节、Redis 缓存策略；v1.5 新增 ADR 导航与治理联动）  
+> **技术栈**: Django 4.x + PostgreSQL + django-tenants + Redis  
+> **设计目标**: 支撑 89,000+ 房源、多租户隔离、sub-100ms 查询、合规审计
+
+---
+
+## 变更历史
+
+| 日期 | 变更人 | 变更内容 |
+|---|---|---|
+| 2026-04-30 | Atlas | 新增 ADR 导航与治理联动规则（数据模型变更需 ADR 可追溯） |
+| 2026-04-30 | Atlas | 补充“变更历史”章节（文档治理） |
+
+## 一、架构决策总览 (Architecture Decision Records)
+
+### 1.1 多租户策略：Schema-per-Tenant
+
+```
+┌──────────────────────────────────────────────────────────────────────┐
+│  PostgreSQL Instance                                                 │
+│                                                                      │
+│  ┌─────────────────────────┐  ┌──────────────────┐  ┌────────────┐  │
+│  │   public schema         │  │   tenant_abc     │  │ tenant_xyz │  │
+│  │   (平台运营层)            │  │   schema         │  │   schema   │  │
+│  │                         │  │                  │  │            │  │
+│  │ - tenants               │  │ - org_units      │  │ (同左)      │  │
+│  │ - domains               │  │ - staff          │  │            │  │
+│  │ - tenant_status_logs    │  │ - complexes      │  │            │  │
+│  │ - platform_admins       │  │ - properties     │  │            │  │
+│  │ - admin_mfa_devices     │  │ - clients        │  │            │  │
+│  │ - admin_sessions        │  │ - user_accounts  │  │            │  │
+│  │ - ip_whitelist          │  │ - login_attempts │  │            │  │
+│  │ - platform_audit_logs   │  │ - permission_defs│  │            │  │
+│  │ - backup_schedules      │  │ - roles          │  │            │  │
+│  │ - backup_records        │  │ - staff_roles    │  │            │  │
+│  │ - export_tasks          │  │ - lookup_items   │  │            │  │
+│  │ - system_versions       │  │ - ...            │  │            │  │
+│  │ - upgrade_events        │  └──────────────────┘  └────────────┘  │
+│  │ - enum_labels           │                                        │
+│  └─────────────────────────┘                                        │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+**选型理由**：
+- `django-tenants` 的 Schema 隔离提供最强的数据安全边界
+- 房产经纪公司之间数据绝对不能互通（合规要求）
+- 每个 Schema 独立索引，避免全局锁竞争
+- 支持按租户独立备份/恢复
+
+### 1.2 核心领域模型关系图
+
+```
+  [区域/商圈]──────────────────────────────┐
+       │                                  │
+  [学校管理]                               │
+       │                                  ▼
+  [楼盘/小区] ──── [楼栋] ─────────► [房源] ◄──── [挂牌历史]
+       │                                   │
+       │                          ┌────────┼────────┐
+       │                          │        │        │
+       │                     [联系人]  [跟进日志] [维护完成度]
+       │                          │        │
+       │                    ┌─────┘   ┌────┴──────┐
+       │                    │         │           │
+       │               [电话查看]  [钥匙]  [委托] [实勘]
+       │
+  [客源] ──── [配对记录] ──── [带看记录]
+       │
+  [员工/组织] ──── [权限]
+```
+
+### 1.3 关键设计原则
+
+| 原则    | 决策                                     |
+| ----- | -------------------------------------- |
+| 主键类型  | `UUID v4`（跨环境安全，避免枚举攻击）                |
+| 软删除   | 所有核心表含 `deleted_at`（历史可追溯）             |
+| 时间戳   | 全部使用 `TIMESTAMPTZ`（含时区）                |
+| 手机号存储 | AES-256-GCM 加密存储，建立 SHA-256 哈希索引       |
+| 审计字段  | `created_by`, `updated_by` 全表覆盖        |
+| 枚举值   | 业务枚举用 `VARCHAR` + CHECK，系统枚举用 lookup 表 |
+| 大文本   | `TEXT` 类型，不设长度（PG 内部优化）                |
+| 金额    | `NUMERIC(12,2)` 万元精度，避免浮点误差            |
+
+---
+
+## 二、领域概览（Domain Overview）
+
+本节用业务语言描述系统的核心领域对象及其关系，作为各子模块数据模型的导读。
+
+### 核心领域对象
+
+#### Public Schema（平台运营层）
+
+| 领域对象 | 表 | 业务说明 |
+|----------|-----|----------|
+| **Tenant（租户）** | `public.tenants` | 每家房产经纪公司一条记录，含状态机（creating/active/suspended/pending_delete/deleted）、套餐、联系人 |
+| **Domain（域名）** | `public.domains` | 子域名↔租户映射，支持多域名绑定，子域名创建后不可修改 |
+| **TenantStatusLog** | `public.tenant_status_logs` | 租户状态变更不可变审计（append-only） |
+| **PlatformAdmin** | `public.platform_admins` | 平台管理员账号，3 种角色：超级管理员/运营人员/只读审计员 |
+| **AdminMfaDevice** | `public.admin_mfa_devices` | 管理员 TOTP 设备（强制启用） |
+| **AdminSession** | `public.admin_sessions` | 登录会话（30 分钟超时，支持强制登出） |
+| **IpWhitelist** | `public.ip_whitelist` | 管理控制台 CIDR 白名单 |
+| **PlatformAuditLog** | `public.platform_audit_logs` | 所有写操作+高危操作审计（append-only，建议月度分区） |
+| **BackupSchedule** | `public.backup_schedules` | 全局/租户级定时备份计划（频率/保留数/存储目标） |
+| **BackupRecord** | `public.backup_records` | 备份任务执行记录（自动/手动/升级前/恢复前） |
+| **ExportTask** | `public.export_tasks` | 数据导出异步任务（CSV/JSON/SQL Dump，24h 下载链接） |
+| **SystemVersion** | `public.system_versions` | 平台版本历史，唯一 current 版本约束 |
+| **UpgradeEvent** | `public.upgrade_events` | 升级/回滚事件，含灰度租户维度进度快照 |
+| **EnumLabel** | `public.enum_labels` | 固定枚举字典（英文 Key → 中文标签），所有租户共享，供前端下拉渲染、导出报表中文标签、日志快照使用 |
+
+#### Tenant Schema（租户业务层）
+
+| 领域对象 | 表/子文档 | 业务说明 |
+|----------|-----------|----------|
+| **OrgUnit（组织架构）** | `org_units` → [DATA_MODEL_ORG.md](./DATA_MODEL_ORG.md) | 树形组织架构（总部/区域/城市/大区/分公司/门店/团队/虚拟团队），物化路径存储，支持权限继承 |
+| **Staff（员工）** | `staff` → [DATA_MODEL_ORG.md](./DATA_MODEL_ORG.md) | 经纪人/店长/经理，绑定组织节点，手机号加密存储，与账号（登录）分离 |
+| **District（城区）** | `districts` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 行政区划，如「静安区」，是区域体系的顶层节点 |
+| **BusinessArea（商圈）** | `business_areas` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 商圈/板块，从属于城区，一个楼盘可归属多个商圈 |
+| **School（学校）** | `schools` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 对口学校数据库，是买家购房决策的核心参考，与楼盘多对多关联 |
+| **Complex（楼盘/小区）** | `complexes` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 房源录入的基础底座，维护楼盘标准名称/坐标/锁定状态/别名等 |
+| **Building（楼栋/单元）** | `buildings` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 楼盘下的物理楼栋，区分标准结构与非标结构 |
+| **RoomUnit（房号）** | `room_units` → [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 楼层+房间号，房源定位的最细粒度 |
+| **Property（房源）** | `properties` → [DATA_MODEL_PROPERTY.md](./DATA_MODEL_PROPERTY.md) | 系统核心表，每套二手房源的完整档案，支持出售/出租/出售兼出租三态 |
+| **Client（客源）** | `clients` → [DATA_MODEL_CLIENT.md](./DATA_MODEL_CLIENT.md) | 买家/租客档案，分私客/公客/成交客，含活跃度评分与自动公客转换机制 |
+| **Viewing（带看）** | `client_viewings` → [DATA_MODEL_CLIENT.md](./DATA_MODEL_CLIENT.md) | 经纪人带客户看房的完整记录 |
+| **Match（配对）** | `client_property_matches` → [DATA_MODEL_CLIENT.md](./DATA_MODEL_CLIENT.md) | 系统/人工推荐的客源↔房源配对 |
+| **UserAccount（用户账号）** | `user_accounts` → [DATA_MODEL_LOGIN.md](./DATA_MODEL_LOGIN.md) | 系统登录主体，与员工档案 1:1 绑定，含账号锁定/密码历史/登录审计 |
+| **PermissionDef（权限定义）** | `permission_defs` → [DATA_MODEL_PERMISSION.md](./DATA_MODEL_PERMISSION.md) | 权限目录（约 300 条），驱动 Hybrid RBAC + Override 权限模型 |
+| **Role（业务角色）** | `roles` → [DATA_MODEL_PERMISSION.md](./DATA_MODEL_PERMISSION.md) | 权限模板，含 4 大类别（置业顾问/店管/总经/运营/自定义） |
+
+### 领域关系快速导航
+
+```
+District (城区)
+  └─ BusinessArea (商圈)
+       └─ Complex (楼盘) ─── School (对口学校)
+            ├─ Building (楼栋)
+            │    └─ RoomUnit (房号)
+            └─ Property (房源)
+                  ├─ PropertyContact (联系人/委托方)
+                  ├─ FollowLog (跟进日志)
+                  ├─ Viewing (带看记录) ──── Client (客源)
+                  └─ Match (配对记录) ──────┘
+
+OrgUnit (组织架构)
+  └─ Staff (员工/经纪人) ─── Property / Client / Viewing / Match
+```
+
+### 子文档索引
+
+| 子文档 | 覆盖模块 | 状态 |
+|--------|----------|------|
+| [DATA_MODEL_PUBLIC.md](./DATA_MODEL_PUBLIC.md) | Public schema 平台运营层（tenants, domains, platform_admins, admin_sessions, audit_logs, backup, export, upgrade 共 13 张表） | ✅ 完成 |
+| [DATA_MODEL_ORG.md](./DATA_MODEL_ORG.md) | 组织人事（org_units, staff, 异动/奖惩/教育/家庭等） | ✅ 完成 |
+| [DATA_MODEL_COMPLEX.md](./DATA_MODEL_COMPLEX.md) | 楼盘/区域（districts, business_areas, complexes, buildings, room_units, schools 等） | ✅ 完成 |
+| [DATA_MODEL_CLIENT.md](./DATA_MODEL_CLIENT.md) | 客源管理（clients, requirements, follow_logs, viewings, matches 等） | ✅ 完成 |
+| [DATA_MODEL_PROPERTY.md](./DATA_MODEL_PROPERTY.md) | 房源管理（properties 及配套 22 张表，含跟进/钥匙/委托/实勘/营销/产证/完成度/标签/收藏/保护/号码方审批等） | ✅ 完成 |
+| [DATA_MODEL_LOGIN.md](./DATA_MODEL_LOGIN.md) | 登录与账号认证（user_accounts, login_attempts, password_reset_tokens, password_histories + Redis 登录缓存） | ✅ 完成 |
+| [DATA_MODEL_PERMISSION.md](./DATA_MODEL_PERMISSION.md) | 权限管理（permission_defs, roles, role_permissions, staff_roles, staff_permission_overrides, staff_data_scopes, permission_change_logs + Redis 权限缓存） | ✅ 完成 |
+| [ENUMS.md](./ENUMS.md) | 枚举字典（`public.enum_labels` 表设计 + 所有模块枚举定义 + 种子数据 SQL） | ✅ 完成 |
+| [ADR.md](../ADR.md) | 架构与需求决策记录（按日期/按模块/历史流水，append-only） | ✅ 完成 |
+
+---
+
+## 三、公共 Schema（Shared / Public）
+
+> **权威源**：完整 DDL 已迁至 [`DATA_MODEL_PUBLIC.md`](./DATA_MODEL_PUBLIC.md)，本节仅保留摘要索引。  
+> **覆盖范围**：`public` schema 存储平台运营层数据——租户注册、管理员账号、审计日志、备份/导出任务、版本升级记录（共 13 张表）。  
+> **设计依据**：系统管理模块 PRD（`PRD/系统管理/系统管理模块PRD.md`）。
+
+### 表清单（开发以 DATA_MODEL_PUBLIC.md 为准）
+
+| 表名 | 说明 | 节 |
+|------|------|----|
+| `public.tenants` | 租户主表（django-tenants 核心，状态机 6 态） | §2.1 |
+| `public.domains` | 域名↔租户映射（支持多域名，子域名不可修改） | §2.1 |
+| `public.tenant_status_logs` | 租户状态变更不可变审计日志（append-only） | §2.1 |
+| `public.platform_admins` | 平台管理员账号（super_admin/ops_operator/read_only_auditor） | §2.2 |
+| `public.admin_mfa_devices` | 管理员 TOTP MFA 设备（强制启用） | §2.2 |
+| `public.admin_sessions` | 管理员登录会话（30 min 滚动超时，支持强制登出） | §2.2 |
+| `public.ip_whitelist` | 管理控制台 CIDR 白名单 | §2.2 |
+| `public.platform_audit_logs` | 所有写操作+高危操作审计（append-only，建议月度分区） | §2.3 |
+| `public.backup_schedules` | 全局/租户级定时备份计划（NULL tenant_id = 全局默认） | §2.4 |
+| `public.backup_records` | 备份任务执行记录（auto/manual/pre_upgrade/pre_restore） | §2.4 |
+| `public.export_tasks` | 数据导出异步任务（CSV/JSON/SQL Dump，24h 下载链接） | §2.4 |
+| `public.system_versions` | 平台版本历史，部分唯一索引保证唯一 current | §2.5 |
+| `public.upgrade_events` | 升级/回滚事件，`tenant_progress` JSONB 快照各租户状态 | §2.5 |
+| `public.enum_labels` | 固定枚举字典（英文 Key → 中文标签），所有租户共享 | §2.6 |
+
+**关键约束提示**：
+- `tenant_status_logs` / `platform_audit_logs` **无 deleted_at**，禁止 UPDATE/DELETE，append-only
+- `public.tenants.schema_name` 创建后**不可修改**
+- `public.tenants` 不再使用 `is_active` boolean，改用 6 态 `status` 枚举
+- `platform_admins` 与租户 `staff` **完全独立**，不共享 auth 系统
+- `system_versions` 通过部分唯一索引确保全局只有一个 `status='current'`
+
+---
+
+<!-- §三 DDL 已迁至 DATA_MODEL_PUBLIC.md v1.0（2026-04-24） -->
+
+
+
+## 四、租户 Schema（Tenant Schema）
+
+以下所有表均在每个租户的独立 Schema 内创建。
+
+---
+
+### 3.1 组织人事模块（Organization & HR）
+
+> **详细模型** → 见 [`DATA_MODEL_ORG.md`](./DATA_MODEL_ORG.md)  
+> 该文件为权威定义，包含完整字段、枚举、查询模式和禁止操作。
+
+**核心表概览**（开发时以 DATA_MODEL_ORG.md 为准）：
+
+| 表名 | 说明 |
+|------|------|
+| `org_units` | 组织树节点（公司/事业部/大区/区域/片区/门店/店组/职能），物化路径树 |
+| `staff` | 员工主表，含加密手机号、角色、在职状态、Django auth 绑定 |
+| `staff_personal_info` | 员工个人信息扩展（证件、学历、婚育等，1:1） |
+| `staff_transfer_logs` | 人事异动不可变审计日志（入职/调动/离职/复职等） |
+| `staff_reward_punish` | 奖惩记录 |
+| `staff_work_experiences` | 工作经历 |
+| `staff_educations` | 教育经历 |
+| `staff_trainings` | 培训经历 |
+| `staff_family_members` | 家庭成员 |
+| `staff_accounts` | 第三方平台账号绑定（58安居客/中国网络经纪人等） |
+
+**关键约束提示**：
+- `staff.phone_enc` AES-256-GCM 加密，`staff.phone_hash` SHA-256 用于唯一索引
+- `staff_transfer_logs` **无 deleted_at**，不可删除
+- `org_units` 路径查询：`WHERE path LIKE '/root/{target_id}/%'`
+- 员工离职：`status = 'resigned'` + `deleted_at` 软删除，记录永久保留
+
+---
+
+### 3.2 区域与楼盘模块（Region & Complex Management）
+
+> **详细模型** → 见 [`DATA_MODEL_COMPLEX.md`](./DATA_MODEL_COMPLEX.md)  
+> 本节仅作概览，开发时以 DATA_MODEL_COMPLEX.md 为权威定义。
+
+**核心表概览**（开发时以 DATA_MODEL_COMPLEX.md 为准）：
+
+| 表名 | 说明 | 关键字段 |
+|------|------|----------|
+| `districts` | 城区/行政区 | `city`, `name`, `short_name`, `sort_order` |
+| `business_areas` | 商圈/板块（从属于城区） | `district_id`, `name`, `latitude`, `longitude` |
+| `metro_lines` | 地铁线路 | `city`, `name`, `color` |
+| `metro_stations` | 地铁站点 | `metro_line_id`, `name`, `latitude`, `longitude` |
+| `schools` | 学校（对口学区） | `district_id`, `name`, `type`, `nature`, `level` |
+| `complexes` | 楼盘/小区（房源底座） | `name`, `district_id`, `address`, `latitude/longitude`, `lock_*`, `search_vector` |
+| `complex_aliases` | 楼盘别名（含系统别名/用户自定义别名） | `complex_id`, `alias`, `is_system` |
+| `complex_business_areas` | 楼盘↔商圈多对多（含主商圈标识） | `complex_id`, `business_area_id`, `is_primary` |
+| `complex_schools` | 楼盘↔学校关联（含学区类型） | `complex_id`, `school_id`, `zone_type` |
+| `complex_metro_stations` | 楼盘↔地铁站关联（含步行距离） | `complex_id`, `station_id`, `distance_meters` |
+| `buildings` | 楼栋/单元 | `complex_id`, `name`, `is_standard`, `total_floors` |
+| `room_units` | 房号/结构单元（楼层+房间号） | `building_id`, `floor`, `room_no`, `is_standard` |
+| `complex_photos` | 楼盘照片（楼盘图/户型图/VR） | `complex_id`, `category`, `file_key`, `is_cover` |
+| `complex_attachments` | 楼盘附件 | `complex_id`, `file_key`, `file_name` |
+| `complex_price_trends` | 楼盘价格走势（月度） | `complex_id`, `record_month`, `avg_unit_price` |
+
+---
+
+### 3.3 房源模块（Property Management）
+
+> **详细模型** → 见 [`DATA_MODEL_PROPERTY.md`](./DATA_MODEL_PROPERTY.md)  
+> 本节仅作概览，开发时以 DATA_MODEL_PROPERTY.md 为权威定义。
+
+**核心表概览**（开发时以 DATA_MODEL_PROPERTY.md 为准）：
+
+| 表名                        | 说明                       | 关键字段                                                                                                                       |
+| ------------------------- | ------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
+| `properties`              | 房源主表（系统核心，89,000+ 数据量）   | `status`, `attribute`, `property_type`, `complex_id`, `sale_price`, `area`, `grade`, `completeness_score`, `search_vector` |
+| `property_contacts`       | 业主/联系人（手机号 AES 加密+哈希索引）  | `property_id`, `phone_enc`, `phone_hash`, `identity`, `is_number_holder`                                                   |
+| `listing_histories`       | 挂牌历史快照（不可删除）             | `property_id`, `listing_type`, `status`, `sale_price`, `seller_agent_snapshot`                                             |
+| `price_changes`           | 调价记录（不可删除）               | `property_id`, `old_sale_price`, `new_sale_price`, `change_reason`, `changed_by`                                           |
+| `follow_logs`             | 跟进日志（6种类型，最高写入频率）        | `property_id`, `log_type`, `content`, `is_deletable`, `operator_id`                                                        |
+| `follow_log_attachments`  | 跟进附件（图片）                 | `follow_log_id`, `file_key`, `file_type`                                                                                   |
+| `follow_log_recordings`   | 跟进录音                     | `follow_log_id`, `file_key`, `duration_seconds`                                                                            |
+| `property_keys`           | 钥匙管理（机械钥匙/密码）            | `property_id`, `key_type`, `holder_id`, `is_active`                                                                        |
+| `key_attachments`         | 钥匙附件                     | `key_id`, `file_key`                                                                                                       |
+| `commissions`             | 委托管理（独家/非独家）             | `property_id`, `commission_type`, `period_start`, `status`                                                                 |
+| `commission_attachments`  | 委托附件（身份证/产证/委托书）         | `commission_id`, `category`, `file_key`                                                                                    |
+| `field_surveys`           | 实勘管理（GPS 打卡）             | `property_id`, `status`, `gps_latitude`, `gps_longitude`, `created_by`                                                     |
+| `survey_photos`           | 实勘照片（按空间分类）              | `survey_id`, `category`, `file_key`, `is_vr_screenshot`                                                                    |
+| `property_photos`         | 房源图片（经纪人管理，封面唯一约束）       | `property_id`, `category`, `is_cover`, `file_key`                                                                          |
+| `property_attachments`    | 房源附件                     | `property_id`, `category`, `file_key`                                                                                      |
+| `property_marketing`      | 营销信息（1:1，卖点/业主心态/介绍）     | `property_id`, `marketing_title`, `core_selling_points`                                                                    |
+| `property_certificates`   | 产证信息（1:1）                | `property_id`, `cert_no`, `owner_name`, `land_nature`                                                                      |
+| `property_completeness`   | 维护完成度快照（1:1，Celery 异步计算） | `property_id`, `total_score`, `score_survey`, `score_commission`, ...                                                      |
+| `property_tags`           | 标签字典（系统预置+运营自定义）         | `name`, `color`, `is_system`                                                                                               |
+| `property_tag_relations`  | 房源↔标签多对多                 | `property_id`, `tag_id`                                                                                                    |
+| `property_favorites`      | 经纪人收藏房源                  | `staff_id`, `property_id`                                                                                                  |
+| `property_protections`    | 保护房设置（1:1）               | `property_id`, `is_protected`, `start_at`, `end_at`                                                                        |
+| `number_holder_approvals` | 号码方变更审批                  | `property_id`, `applicant_id`, `status`                                                                                    |
+
+**关键约束提示**：
+- `property_contacts.phone_hash` 是重复房源检测的主要依据，录入前必须查重
+- `listing_histories` / `price_changes` **无 deleted_at**，不可删除
+- `follow_logs` 中 `is_deletable=FALSE`（`sensitive_view` 类型）不可软删
+- `completeness_score` 只由 Celery 任务写入，Application 层禁止直接更新
+- `last_followed_at` 由触发器 `trg_update_last_followed` 自动维护
+- `property_photos.is_cover` 唯一约束：每套房源仅一张封面
+
+---
+
+### 3.4 登录与账号认证（Login & Account）
+
+> **详细模型** → 见 [`DATA_MODEL_LOGIN.md`](./DATA_MODEL_LOGIN.md)  
+> 该文件为权威定义，包含完整字段、状态机、Redis 缓存结构和禁止操作。
+
+**核心表概览**（开发时以 DATA_MODEL_LOGIN.md 为准）：
+
+| 表名 | 说明 |
+|------|------|
+| `user_accounts` | 账号主表（1:1 绑定 `org.Staff`），含加密手机号/哈希、状态机（active/locked/disabled）、初始密码标识 |
+| `login_attempts` | 登录审计日志（append-only，成功/失败均记录，无 FK 冗余存 username 保证历史完整） |
+| `password_reset_tokens` | 密码重置 Token（有效期 30 分钟，使用后立即标记 `is_used`） |
+| `password_histories` | 历史密码记录（保留最近 3 条，含初始密码，防止重复使用） |
+
+**关键约束提示**：
+- `user_accounts` 主键用 `BIGSERIAL`（非 UUID），登录审计场景 BigInt 更高效
+- `user_accounts.phone_enc` AES-256-GCM 加密，`phone_hash` SHA-256 用于唯一索引
+- **禁止物理删除** `user_accounts`，离职员工只能 `status=disabled`
+- 账号锁定（5 次密码错误）→ `status=locked`，`locked_until=NOW()+30min`；Redis 仅计数，实际锁定以 DB 为准
+- Tenant Admin 的 `staff_id` 可为空（可无员工档案）；普通员工 `staff_id` 必填且关联 active Staff
+- 员工离职（`org.Staff.status→resigned`）→ 应用层 Service 调用触发账号 `status→disabled`，**禁止循环 FK**
+- `password_reset_tokens` / `login_attempts` **无 deleted_at**，不可修改/删除
+
+**Redis 辅助状态**（非持久化）：
+
+| Key 格式 | TTL | 说明 |
+|----------|-----|------|
+| `captcha_token:{uuid}` | 3 分钟 | 滑块验证会话 Token |
+| `captcha_pass:{uuid}` | 3 分钟 | 一次性通过凭证（验证后立即删除） |
+| `login_fail:{tenant_id}:{username}` | 30 分钟 | 连续密码错误计数；≥5 触发锁定 |
+| `recover_email:{email}` | 1 小时 | 找回邮件发送次数上限 3 次 |
+| `tenant_verify_ip:{ip}` | 1 分钟 | Tenant 验证接口 IP 限流；≥10 次拒绝 |
+
+---
+
+### 3.5 权限管理（Permission & RBAC）
+
+> **详细模型** → 见 [`DATA_MODEL_PERMISSION.md`](./DATA_MODEL_PERMISSION.md)  
+> 该文件为权威定义，包含完整字段、权限解析算法、`ScopeQueryBuilder` 实现和禁止操作。
+
+**权限模型概述**：Hybrid RBAC + Individual Override，支持 `BOOLEAN / SCOPE / INTEGER` 三类权限值，多角色合并规则 OR / MAX。
+
+**核心表概览**（开发时以 DATA_MODEL_PERMISSION.md 为准）：
+
+| 表名 | 说明 |
+|------|------|
+| `permission_defs` | 权限目录（约 300 条，`PUBLIC Schema` 中 `shared_apps` 存储，所有租户共享），含模块/分组/值类型/默认值/上限类别 |
+| `roles` | 业务角色（每租户独立），5 种类别：`agent/store_manager/director/operator/custom`，含系统内置标识 |
+| `role_permissions` | 角色↔权限值（稀疏存储，仅存与 default_value 不同的项） |
+| `staff_roles` | 员工↔角色分配（N:M，含主角色标识 `is_primary`、有效期） |
+| `staff_permission_overrides` | 员工个人权限覆盖（稀疏存储，仅存与角色合并值不同的项），3 种 override_mode：REPLACE / RESTRICT / GRANT |
+| `staff_data_scopes` | 员工数据范围扩展（补充 SCOPE 权限之外的额外可读范围，如特殊跨门店授权） |
+| `permission_change_logs` | 权限变更不可变审计日志（append-only，禁止 UPDATE/DELETE） |
+
+**关键约束提示**：
+- `permission_defs` 位于 **Public Schema**（`shared_apps`），所有租户共享；`roles` 及其余表属租户 Schema
+- **禁止硬删除** `permission_defs`，改用 `is_active=FALSE` 下线；`code` 字段不可修改
+- **禁止直接构造 Q 对象绕过 `ScopeQueryBuilder`**，会导致越权漏洞
+- `permission_change_logs` **无 deleted_at**，禁止 UPDATE/DELETE
+- 员工权限解析：`is_system_admin=TRUE` → 短路返回全权限；否则多角色 OR/MAX 合并后叠加 Override
+- `StaffPermissionOverride` 保存前必须做差异对比，**禁止存与角色合并值相同的冗余记录**（稀疏存储）
+- `staff_roles.is_primary` 唯一约束通过 Signal 维护，**禁止绕过**
+
+**权限解析缓存**：
+
+| Cache Key | TTL | 失效触发 |
+|-----------|-----|---------|
+| `perm:v{VER}:{schema}:{staff_id}` | 3600s | Override / StaffRole 变更 |
+| `perm:v{VER}:{schema}:role:{role_id}:staff_ids` | 3600s | 角色权限变更 → Pipeline 批量失效 |
+| `perm:inconsistent:{schema}:{staff_id}` | 300s | 同上 |
+| `perm:defs:{schema}` | 86400s | PermissionDef 变更（低频） |
+| `perm:role_applied_count:{schema}:{role_id}` | 600s | StaffRole 变更 |
+
+> **版本号机制**：`CACHE_VERSION` 在 Django settings 中，升级 PermissionDef 结构时 bump，一键全局失效。
+
+---
+
+### 3.17 客源管理（Client Management）
+
+> **详细模型** → 见 [`DATA_MODEL_CLIENT.md`](./DATA_MODEL_CLIENT.md)  
+> 该文件为权威定义，包含完整字段、枚举、状态机、查询模式和禁止操作。
+
+**核心表概览**（开发时以 DATA_MODEL_CLIENT.md 为准）：
+
+| 表名 | 说明 |
+|------|------|
+| `clients` | 客源主表（私客/公客/成交客），含加密手机号哈希、活跃度、归属人 |
+| `client_contacts` | 联系人（1:N），手机号加密+哈希，支持多联系人 |
+| `client_requirements` | 需求信息（可多类型：二手/新房/租房），含预算/面积/商圈/朝向等偏好 |
+| `client_follow_logs` | 跟进日志（高写入频率，5种类型，敏感查看类型不可删） |
+| `client_follow_log_attachments` | 跟进附件（图片/录音，最大20MB） |
+| `client_viewings` | 带看/预约记录（1:N，含陪看人/合作带看人） |
+| `client_property_matches` | 智能配房结果（录客配房/系统配房，匹配度评分） |
+| `client_status_logs` | 状态变更不可变审计日志（改状态/改等级/转公/转成交/转无效等） |
+| `client_favorite_folders` | 私客收藏夹（经纪人自定义分组） |
+| `client_folder_items` | 收藏夹与客源的多对多关联 |
+| `client_school_preferences` | 意向学校（拆表，支持精确查询） |
+
+**关键约束提示**：
+- `client_contacts.phone_hash` 是重复客源检测的唯一依据，录入前必须查重
+- `client_status_logs` **无 deleted_at**，不可删除
+- 私客超时（配置天数内无跟进）→ Celery 自动转公（`transfer_to_public_type = 'auto'`）
+- 活跃度 `activity_level` 由 Celery 每日凌晨批量计算，不实时更新
+
+---
+
+### 3.18 系统设置（System Settings）
+
+> **归属说明**：
+> - `lookup_categories` / `lookup_items` / `saved_filters` 为**跨模块**系统表，权威定义在本节。
+> - `property_tags` / `property_tag_relations` / `property_favorites` / `property_protections` / `number_holder_approvals` 属房源模块配套表，**权威定义已迁至** [`DATA_MODEL_PROPERTY.md §4.19-§4.22`](./DATA_MODEL_PROPERTY.md)，本节不再重复 DDL（修复 S1/S2）。
+
+```sql
+-- ============================================================
+-- 枚举/选项管理：跟进目的、标签、来源渠道 等运营维护的枚举值
+-- ============================================================
+
+CREATE TABLE lookup_categories (
+    id      UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    code    VARCHAR(50) UNIQUE NOT NULL,       -- 如：follow_purpose, property_source
+    name    VARCHAR(100) NOT NULL,
+    module  VARCHAR(30) NOT NULL              -- property/client/system
+);
+
+CREATE TABLE lookup_items (
+    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    category_id     UUID NOT NULL REFERENCES lookup_categories(id) ON DELETE CASCADE,
+    value           VARCHAR(100) NOT NULL,
+    label           VARCHAR(100) NOT NULL,     -- 显示文本
+    sort_order      INTEGER NOT NULL DEFAULT 0,
+    is_active       BOOLEAN NOT NULL DEFAULT TRUE,
+    metadata        JSONB NOT NULL DEFAULT '{}',  -- 扩展属性
+    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_lookup_items_category ON lookup_items(category_id)
+    WHERE is_active = TRUE;
+CREATE UNIQUE INDEX idx_lookup_items_value ON lookup_items(category_id, value);
+
+-- 筛选方案（保存的搜索条件，跨模块通用）
+CREATE TABLE saved_filters (
+    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    staff_id        UUID NOT NULL REFERENCES staff(id) ON DELETE CASCADE,
+    name            VARCHAR(100) NOT NULL,
+    module          VARCHAR(20) NOT NULL DEFAULT 'property',
+    filter_params   JSONB NOT NULL,            -- 完整筛选参数 JSON
+    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
+    updated_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_saved_filters_staff ON saved_filters(staff_id, module);
+```
+
+**已迁出本节的表**（权威源见子文档）：
+
+| 表名 | 权威定义位置 |
+|------|-------------|
+| `property_tags` | [`DATA_MODEL_PROPERTY.md §4.19`](./DATA_MODEL_PROPERTY.md) |
+| `property_tag_relations` | [`DATA_MODEL_PROPERTY.md §4.19`](./DATA_MODEL_PROPERTY.md) |
+| `property_favorites` | [`DATA_MODEL_PROPERTY.md §4.20`](./DATA_MODEL_PROPERTY.md) |
+| `property_protections` | [`DATA_MODEL_PROPERTY.md §4.21`](./DATA_MODEL_PROPERTY.md) |
+| `number_holder_approvals` | [`DATA_MODEL_PROPERTY.md §4.22`](./DATA_MODEL_PROPERTY.md) |
+
+---
+
+### 3.19 枚举字典（Enum Labels）
+
+> **权威定义** → 见 [`DATA_MODEL/ENUMS.md`](./ENUMS.md)  
+> 本节为概览，开发时以 ENUMS.md 为准。
+
+#### 表归属
+
+`enum_labels` 位于 **Public Schema**（`shared_apps`），所有租户共享，**不属于任何租户 Schema**。
+
+#### 核心表设计
+
+```sql
+CREATE TABLE enum_labels (
+    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
+    domain      VARCHAR(60)  NOT NULL,  -- 枚举域，格式：{模块}.{字段}，如 client.status
+    value       VARCHAR(60)  NOT NULL,  -- 英文 Key（与数据库 CHECK 约束一致）
+    label_zh    VARCHAR(60)  NOT NULL,  -- 中文标签（前端展示用）
+    sort_order  SMALLINT     NOT NULL DEFAULT 0,
+    is_active   BOOLEAN      NOT NULL DEFAULT TRUE,
+    remark      TEXT,
+    created_at  TIMESTAMPTZ  NOT NULL DEFAULT NOW(),
+    updated_at  TIMESTAMPTZ  NOT NULL DEFAULT NOW()
+);
+
+CREATE UNIQUE INDEX idx_enum_labels_domain_value ON enum_labels(domain, value);
+CREATE INDEX idx_enum_labels_domain ON enum_labels(domain, sort_order);
+```
+
+#### 覆盖的枚举域（domain 清单）
+
+| domain | 说明 | 对应表字段 |
+|--------|------|-----------|
+| `client.status` | 客源状态（8 态） | `clients.status` |
+| `client.grade` | 客源等级（5 档 + E） | `clients.grade` |
+| `client.requirement_type` | 需求类型（旧：`client.purpose_type`） | `client_requirements.requirement_type` |
+| `client.property_usage` | 房源用途偏好（旧：`client.usage`） | `client_requirements.property_usage` |
+| `client.orientation` | 朝向偏好 | `client_requirements.orientation` |
+| `client.payment_method` | 付款方式 | `clients.payment_method` |
+| `property.status` | 房源状态 | `properties.status` |
+| `property.attribute` | 房源属性（公/私/保护） | `properties.attribute` |
+| `property.property_type` | 房源类型（旧：`property.usage`） | `properties.property_type` |
+| `property.grade` | 房源等级（5 档） | `properties.grade` |
+| `property.listing_history.listing_type` | 挂牌类型（旧：`property.listing_type`） | `listing_histories.listing_type` |
+| `property.decoration` | 装修程度 | `properties.decoration` |
+| `property.orientation` | 朝向 | `properties.orientation` |
+| `property.commission.status` | 委托状态（旧：`commission.type`） | `commissions.status` |
+| `field_survey.status` | 实勘状态 | `field_surveys.status` |
+| `follow_log.log_type` | 跟进日志类型 | `follow_logs.log_type` |
+
+#### 重要约定
+
+- `enum_labels.value` 必须与对应表的 `CHECK` 约束完全一致，**两者必须同步修改**
+- 新增枚举值流程：① 修改 DDL `CHECK` 约束 → ② 插入 `enum_labels` 种子数据 → ③ 更新 `ENUMS.md`
+- `is_active = FALSE` 仅停用前端展示，**不得修改或删除已有 `value`**（历史数据引用不可破坏）
+- 前端下拉渲染**统一从 `enum_labels` 读取**，禁止在前端代码中硬编码中文标签
+
+#### 与 `lookup_items` 的区别
+
+| 对比维度 | `enum_labels` | `lookup_items` |
+|---------|---------------|----------------|
+| 用途 | 固定枚举的中文标签映射 | 运营可配置的动态选项（如跟进目的、来源渠道） |
+| 修改权限 | 仅开发/DBA | 运营人员后台配置 |
+| Schema 位置 | Public Schema（共享） | Tenant Schema（每租户独立） |
+| 典型示例 | 客源状态、房源等级 | 跟进目的、客户来源渠道 |
+
+---
+
+## 五、关键索引汇总与查询优化策略
+
+### 4.1 房源列表页核心查询分析
+
+```sql
+-- 典型查询：出售状态 + 公盘 + 特定区域 + 价格区间 + 户型筛选 + 按挂牌日期排序
+-- 优化方案：复合索引覆盖最高频维度组合
+
+-- 高频组合索引（status + attribute，覆盖 90% 的列表查询）
+CREATE INDEX idx_properties_list_composite ON properties
+    (status, attribute, complex_id, sale_price DESC NULLS LAST)
+    WHERE deleted_at IS NULL;
+
+-- 与我相关查询（经纪人个人仪表板）
+CREATE INDEX idx_properties_my_properties ON properties
+    (seller_agent_id, status, listed_at DESC NULLS LAST)
+    WHERE deleted_at IS NULL;
+```
+
+### 4.2 全文搜索触发器（自动维护 search_vector）
+
+```sql
+-- 房源全文检索向量更新触发器
+CREATE OR REPLACE FUNCTION update_property_search_vector()
+RETURNS TRIGGER AS $$
+BEGIN
+    NEW.search_vector :=
+        setweight(to_tsvector('simple', COALESCE(NEW.block_no, '') ||
+                              ' ' || COALESCE(NEW.unit_no, '') ||
+                              ' ' || COALESCE(NEW.room_no, '')), 'A') ||
+        setweight(to_tsvector('simple', COALESCE(NEW.remarks, '')), 'C');
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_property_search_vector
+    BEFORE INSERT OR UPDATE OF block_no, unit_no, room_no, remarks
+    ON properties
+    FOR EACH ROW EXECUTE FUNCTION update_property_search_vector();
+
+-- 楼盘全文检索向量（含别名，提升模糊搜索精度）
+CREATE OR REPLACE FUNCTION update_complex_search_vector()
+RETURNS TRIGGER AS $$
+BEGIN
+    NEW.search_vector :=
+        setweight(to_tsvector('simple', COALESCE(NEW.name, '')), 'A') ||
+        setweight(to_tsvector('simple', COALESCE(NEW.alias, '')), 'B') ||
+        setweight(to_tsvector('simple', COALESCE(NEW.address, '')), 'C');
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_complex_search_vector
+    BEFORE INSERT OR UPDATE OF name, alias, address
+    ON complexes
+    FOR EACH ROW EXECUTE FUNCTION update_complex_search_vector();
+```
+
+### 4.3 last_followed_at 自动维护触发器
+
+```sql
+-- 每次写入跟进日志时，自动更新 properties.last_followed_at
+CREATE OR REPLACE FUNCTION update_property_last_followed()
+RETURNS TRIGGER AS $$
+BEGIN
+    IF NEW.log_type = 'written' THEN
+        UPDATE properties
+        SET last_followed_at = NEW.created_at,
+            updated_at = NOW()
+        WHERE id = NEW.property_id;
+    END IF;
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_update_last_followed
+    AFTER INSERT ON follow_logs
+    FOR EACH ROW EXECUTE FUNCTION update_property_last_followed();
+```
+
+---
+
+## 六、Redis 缓存策略
+
+### 5.1 缓存 Key 规范
+
+```
+# 格式：{tenant_schema}:{module}:{entity}:{id}:{field}
+# TTL 单位：秒
+
+# 房源详情（高频读取）
+{schema}:prop:detail:{property_id}              TTL: 300  (5分钟)
+
+# 房源联系人（含解密号码，敏感，TTL 短）
+{schema}:prop:contacts:{property_id}            TTL: 60   (1分钟)
+
+# 楼盘基础信息（低变更频率）
+{schema}:complex:base:{complex_id}              TTL: 3600 (1小时)
+
+# 楼盘名称自动补全候选列表（联想搜索）
+{schema}:complex:autocomplete:{prefix}          TTL: 600  (10分钟)
+
+# 员工信息（用于日志快照）
+{schema}:staff:base:{staff_id}                  TTL: 1800 (30分钟)
+
+# 枚举值/lookup（几乎不变）
+{schema}:lookup:{category_code}                 TTL: 86400 (24小时)
+
+# 登录模块（详见 DATA_MODEL_LOGIN.md §四）
+captcha_token:{uuid}                            TTL: 180   (3分钟)
+captcha_pass:{uuid}                             TTL: 180   (3分钟)
+login_fail:{tenant_id}:{username}               TTL: 1800  (30分钟，连续失败计数)
+recover_email:{email}                           TTL: 3600  (1小时，发送次数限流)
+recover_reset:{account_id}                      TTL: 3600  (1小时，Token 生成次数限流)
+tenant_verify_ip:{ip}                           TTL: 60    (1分钟，IP 限流)
+
+# 权限模块（详见 DATA_MODEL_PERMISSION.md §六）
+perm:v{VER}:{schema}:{staff_id}                 TTL: 3600  (员工完整权限快照)
+perm:v{VER}:{schema}:role:{role_id}:staff_ids   TTL: 3600  (角色→员工 ID 列表，批量失效用)
+perm:inconsistent:{schema}:{staff_id}           TTL: 300   (权限不一致标记)
+perm:defs:{schema}                              TTL: 86400 (权限定义全量缓存)
+perm:role_applied_count:{schema}:{role_id}      TTL: 600   (角色应用人数)
+
+# 标签列表
+{schema}:tags:property                          TTL: 3600
+
+# 维护完成度（Celery 计算后写入，详情页直接读 Redis）
+{schema}:prop:completeness:{property_id}        TTL: 600
+
+# 房源列表计数（筛选后总条数，避免 COUNT(*) 全扫）
+{schema}:prop:count:{filter_hash}               TTL: 30   (短TTL，保证准确性)
+```
+
+### 5.2 缓存失效策略
+
+```python
+# Django Signal 驱动的缓存失效（在 models.py 中注册）
+
+# 房源更新 → 失效详情缓存 + 完成度缓存
+# 跟进日志新增 → 失效 last_followed_at 缓存
+# 联系人更新 → 失效联系人缓存（立即）
+# 楼盘更新 → 失效楼盘缓存 + 相关房源缓存（批量）
+# 枚举更新 → 失效对应 lookup 缓存
+```
+
+---
+
+## 七、Django Model 层设计要点
+
+### 6.1 抽象基类
+
+```python
+# models/base.py
+
+import uuid
+from django.db import models
+
+class UUIDPrimaryKeyModel(models.Model):
+    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
+    class Meta:
+        abstract = True
+
+class TimeStampedModel(UUIDPrimaryKeyModel):
+    created_at = models.DateTimeField(auto_now_add=True, db_index=False)
+    updated_at = models.DateTimeField(auto_now=True)
+    class Meta:
+        abstract = True
+
+class SoftDeleteModel(TimeStampedModel):
+    deleted_at = models.DateTimeField(null=True, blank=True, db_index=False)
+
+    class Meta:
+        abstract = True
+
+    def soft_delete(self, deleted_by=None):
+        from django.utils import timezone
+        self.deleted_at = timezone.now()
+        self.save(update_fields=['deleted_at', 'updated_at'])
+
+class AuditedModel(SoftDeleteModel):
+    created_by = models.ForeignKey(
+        'staff.Staff', null=True, on_delete=models.SET_NULL,
+        related_name='+', db_column='created_by'
+    )
+    updated_by = models.ForeignKey(
+        'staff.Staff', null=True, on_delete=models.SET_NULL,
+        related_name='+', db_column='updated_by'
+    )
+    class Meta:
+        abstract = True
+```
+
+### 6.2 加密字段 Mixin
+
+```python
+# utils/encryption.py
+# 手机号加密：AES-256-GCM + SHA-256 哈希索引
+
+class EncryptedPhoneField:
+    """
+    存储时：phone → AES加密 → phone_enc (BYTEA)
+              phone → SHA256  → phone_hash (VARCHAR 64)
+    查询时：phone_hash 走索引，phone_enc 解密展示
+    打码展示：前3位明文 + ******* + 后3位
+    """
+    pass
+```
+
+### 6.3 Manager 过滤软删除
+
+```python
+class ActiveManager(models.Manager):
+    def get_queryset(self):
+        return super().get_queryset().filter(deleted_at__isnull=True)
+
+class PropertyManager(ActiveManager):
+    def public(self):
+        return self.get_queryset().filter(attribute='public')
+
+    def mine(self, staff_id):
+        return self.get_queryset().filter(seller_agent_id=staff_id)
+```
+
+---
+
+## 八、数据量与性能预测
+
+| 表名 | 预估行数 | 增长速度 | 分区策略 |
+|------|---------|---------|---------| 
+| `properties` | 89,000+ | 中速 | 暂不分区，建议 500k 后按 `created_at` RANGE 分区 |
+| `follow_logs` | 200万+ | 高速（最高频写入） | ✅ `PARTITION BY RANGE (created_at)` 月度分区 |
+| `property_photos` | 500万+ | 高速 | ✅ `PARTITION BY RANGE (created_at)` 月度分区 |
+| `permission_change_logs` | 100万+ | 中高速 | ✅ `PARTITION BY RANGE (operated_at)` 月度分区 |
+| `login_attempts` | 500万+ | 高速（每次登录一条） | ✅ `PARTITION BY RANGE (attempted_at)` 月度分区 |
+| `platform_audit_logs` | 10万+ | 低中速 | ✅ `PARTITION BY RANGE (created_at)` 月度分区 |
+| `price_changes` | 50万 | 中速 | 无需分区 |
+| `listing_histories` | 20万 | 低速 | 无需分区 |
+| `clients` | 10万+ | 中速 | 暂不分区 |
+| `viewings` | 100万 | 中速 | 无需分区 |
+
+### 8.1 分区维护策略（partition_maintenance_task）
+
+所有月度分区表统一由 **Celery Beat 定时任务** `partition_maintenance_task` 维护，每月 1 日凌晨 01:00（UTC+8）自动执行：
+
+```python
+# apps/property/tasks.py（及 permission/login/shared 各 App 对应任务）
+@app.task(name="partition_maintenance_task")
+def partition_maintenance_task():
+    """
+    为下一个月预建所有分区表的分区。
+    - 检查是否已存在目标分区，幂等执行
+    - 失败时发送 Sentry 告警
+    """
+    tables = [
+        ("follow_logs",              "created_at"),
+        ("property_photos",          "created_at"),
+        ("permission_change_logs",   "operated_at"),
+        ("login_attempts",           "attempted_at"),
+        ("public.platform_audit_logs", "created_at"),
+    ]
+    next_month = date.today().replace(day=1) + relativedelta(months=1)
+    month_start = next_month
+    month_end   = next_month + relativedelta(months=1)
+
+    for table, _key in tables:
+        suffix     = month_start.strftime("%Y_%m")
+        part_name  = f"{table.replace('.', '_')}_{suffix}"
+        sql = f"""
+            CREATE TABLE IF NOT EXISTS {part_name}
+            PARTITION OF {table}
+            FOR VALUES FROM ('{month_start}') TO ('{month_end}');
+        """
+        with connection.cursor() as cursor:
+            cursor.execute(sql)
+```
+
+**Celery Beat 配置**（`celery.py`）：
+```python
+app.conf.beat_schedule["partition_maintenance_task"] = {
+    "task":     "partition_maintenance_task",
+    "schedule": crontab(day_of_month=1, hour=1, minute=0),  # 每月1日 01:00 UTC+8
+}
+```
+
+> ⚠️ **注意**：每张分区表均保留一个 `_default` 默认分区作为兜底，防止任务失败时写入报错。`_default` 分区数据应在运维 SOP 中周期性检查（有数据则说明提前建分区失败）。
+
+---
+
+## 九、必须在开发启动前明确的数据架构决策
+
+| 决策项 | 推荐方案 | 风险 |
+|-------|---------|------|
+| 小区数据来源 | 预导入基础数据（安居客/链家 API）+ 支持手动新增兜底 | 高：影响录入体验 |
+| 私盘可见范围 | 录入人所在门店可见（综合业务需求） | 需与权限模块约定 |
+| 号码查看权限 | 角色级控制：经纪人限查自己相关房源，店长无限制 | 需合规确认 |
+| 重复房源主键 | 主键：手机号 hash；辅助：（小区+楼栋+单元+房号）组合 | 需双重校验 |
+| 跟进目的枚举 | 存 lookup_items 表，运营可维护 | 初始化数据需提前收集 |
+| 手机号加密算法 | AES-256-GCM，密钥存 Django settings（生产用 Vault） | 密钥管理需单独规划 |
+
+## 十、文档治理与 ADR 联动规则
+
+- 任何会影响数据模型边界的变更（新增/删除表、关键约束变更、索引策略调整、枚举口径变更）必须先在 `ADR.md` 记录为 `accepted`，再修改本文件与子文档。
+- 若既有数据决策被替代，必须在 `ADR.md` 增加 `superseded` 记录并指向新 ADR，禁止直接覆盖旧结论。
+- 提交 PR 时，凡涉及 `DATA_MODEL/*` 结构性变更，PR 描述必须包含 ADR ID（格式：`ADR-YYYYMMDD-XXX`）。
+- `DATA_MODEL.md` 只维护全局索引与规则；表级 DDL 以各子文档为权威源，避免双写漂移。
+
+---
+
+*本文档为 Fonrey 系统 DATA MODEL v1.5，随 PRD 与 ADR 迭代同步更新。*
+*下一步建议：API 接口规范（URL 设计 + Request/Response Schema）*

Project/fonrey/DATA_MODEL/DATA_MODEL_CLIENT.md

@@ -0,0 +1,581 @@
+> **For AI assistants**: Read this entire file before writing any code. All decisions here are final. Do not suggest alternatives unless asked.
+# Fonrey — 客源管理数据模型（DATA_MODEL_CLIENT）
+
+> **所属系统**: Fonrey 房产经纪管理系统  
+> **版本**: v1.0  
+> **日期**: 2026-04-24  
+> **关联模块**: `apps/client/` — 私客、公客、成交客、跟进记录、带看、智能配房
+
+---
+
+## 变更历史
+
+| 日期 | 变更人 | 变更内容 |
+|---|---|---|
+| 2026-04-30 | Atlas | 补充“变更历史”章节（文档治理） |
+
+## 一、领域概览（Domain Overview）
+
+### 核心概念
+
+- **Client（客源）**：有购房/租房意向或历史成交记录的客户。核心实体，与房源（Property）是系统业务闭环的两端。
+- **客源类型**：
+  - **私客（private）**：经纪人独占跟进的意向客户，是本期核心。
+  - **公客（public）**：私客超时未跟进或手动转公后，进入全公司共享客源池。
+  - **成交客（transacted）**：已完成购房/租房成交的客户，用于复购/转介绍跟进。
+- **ClientContact（联系人）**：一个客源可有多个联系人，每个联系人有独立手机号。手机号加密存储，用于重复检测（「私客与成交客重复」）。
+- **ClientRequirement（需求信息）**：购房/租房的详细偏好。一个客源可同时有「二手」「新房」「租房」三种需求类型（分别对应独立的需求记录）。
+- **ClientFollowLog（跟进日志）**：经纪人与客户每次沟通的书面记录，是客源活跃度计算的数据来源。
+- **Viewing（带看记录）**：与 Property 模块共享此表，记录经纪人带客户看房的过程。见主 DATA_MODEL.md 3.17 节。
+- **ClientPropertyMatch（智能配房）**：系统按需求自动匹配的房源列表，分「录客配房」和「系统配房」两种来源。
+- **ClientFavoriteFolder（收藏夹）**：经纪人自定义的客源分组收藏夹。
+
+### 关键业务规则
+
+1. **私客手机号唯一性**：录入联系人手机号时，系统通过 `phone_hash` 检测是否与现有私客/成交客/公客重复，并在列表顶部提示重复数量。
+2. **活跃度计算**：系统根据「最后跟进日期」自动计算客源活跃度，分为：新配偶（新建）/ 7日活跃 / 30日活跃 / 90日活跃 / 即将过期 / 无效。具体阈值由运营配置。
+3. **私客自动转公规则**：超过配置天数（如 30 天）无跟进记录，系统自动将私客标记为公客（`transfer_to_public_type = 'auto'`）。
+4. **状态机**：客源状态有严格流转规则（见第四章），不可跳过转台。
+5. **跟进目的枚举**：由 `lookup_items` 表维护，运营可配置，当前已知 23 项（见 Story 8）。
+6. **号码查看审计**：查看联系人明文号码需记录 `client_follow_logs`（`log_type = 'sensitive_view'`），不可删除。
+7. **需求类型独立存储**：同一客源可同时有「二手购房」「租房」两类需求，分别存储在独立需求记录中，由 `client_requirements.requirement_type` 区分。
+
+---
+
+## 二、实体关系
+
+```
+Client (客源主表)
+  │
+  ├── 1:N ── ClientContact       (联系人，多个号码)
+  ├── 1:N ── ClientRequirement   (需求信息，可多类型)
+  ├── 1:N ── ClientFollowLog     (跟进日志，高写入频率)
+  ├── 1:N ── ClientViewing       (带看预约)
+  ├── 1:N ── ClientPropertyMatch (智能配房结果)
+  ├── 1:1 ── ClientActivityCache (活跃度缓存，异步计算)
+  ├── N:M ── ClientFavoriteFolder (通过 client_folder_items 关联)
+  └── 1:N ── ClientStatusLog     (状态变更日志，不可删)
+
+ClientFavoriteFolder
+  └── 1:N ── ClientFolderItem    (收藏夹中的客源)
+
+Staff (员工)
+  ├── first_recorder_id → Client (首录人)
+  └── owner_id → Client         (归属人)
+```
+
+---
+
+## 三、Schema 定义
+
+### 3.1 clients — 客源主表
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_no | VARCHAR(30) | UNIQUE, NOT NULL | 系统生成的客源编号，格式由运营配置（如 KY20260424001） |
+| client_type | VARCHAR(20) | NOT NULL DEFAULT 'private' | `private`=私客 / `public`=公客 / `transacted`=成交客 |
+| status | VARCHAR(20) | NOT NULL DEFAULT 'buying' | 见下方枚举 |
+| grade | VARCHAR(5) | NOT NULL DEFAULT 'C' | `A`=A急迫 / `B`=较强 / `C`=一般 / `D`=较弱 / `E`=暂不关注 |
+| property_usage | VARCHAR(30) | NOT NULL DEFAULT 'residential' | `residential`=住宅 / `villa`=别墅 / `commercial_residential`=商住 / `shop`=商铺 / `office`=写字楼 / `other`=其他 |
+| buying_purpose | VARCHAR(20)[] | | 购房目的多选：`rigid`=刚需 / `investment`=投资 / `school_district`=学区 / `upgrade`=改善 / `commercial`=商用 / `other`=其他 |
+| payment_method | VARCHAR(30) | | `full`=全额 / `mortgage`=商业贷款 / `mortgage_fund`=商贷+公积金 / `fund`=公积金 |
+| properties_owned | VARCHAR(20) | | `none`=无 / `local_none`=本地无外地有 / `local_has`=本地有 |
+| has_loan_record | BOOLEAN | | 有无贷款记录 |
+| id_type | VARCHAR(20) | | 证件类型：`id_card` / `passport` / `hk_macao` / `other` |
+| id_number_enc | BYTEA | | 证件号码（AES 加密） |
+| source | VARCHAR(50) | | 客户来源（lookup_items 维护） |
+| remarks | TEXT | | 备注，最多200字 |
+| is_starred | BOOLEAN | NOT NULL DEFAULT FALSE | 是否收藏（快速标记，详细收藏夹用 client_folder_items） |
+| is_pinned | BOOLEAN | NOT NULL DEFAULT FALSE | 是否置顶（列表顶部置顶） |
+| is_big_value | BOOLEAN | NOT NULL DEFAULT FALSE | 是否大价值客户（影响筛选展示） |
+| is_protected | BOOLEAN | NOT NULL DEFAULT FALSE | 是否保护客（影响转公逻辑） |
+| prefers_new_house | BOOLEAN | | 偏好新房（用于筛选） |
+| transfer_to_public_type | VARCHAR(20) | | 转公客方式：`manual`=手动转公 / `auto`=自动转公（超时） / `marketing_jump`=营销客跳公 / `resource_public`=资料客素公 |
+| transferred_public_at | TIMESTAMPTZ | | 进入公客池时间 |
+| invalid_reason | VARCHAR(30) | | 无效原因：`invalid_phone`=号码无效 / `peer_agent`=同行 / `ad`=广告推销 / `no_intent`=无意向 / `other` |
+| invalidated_at | TIMESTAMPTZ | | 标记无效时间 |
+| transacted_at | DATE | | 成交日期 |
+| transacted_property_id | UUID | FK→properties, SET NULL | 成交关联的房源 |
+| transacted_price | NUMERIC(12,2) | | 成交价格（万元） |
+| transacted_type | VARCHAR(20) | | 成交类型：`bought`=我购 / `rented`=我租 |
+| transacted_property_type | VARCHAR(20) | | 成交房源类型：`second_hand`=二手 / `new_house`=新房 |
+| first_recorder_id | UUID | FK→staff, SET NULL | 首录人 |
+| owner_id | UUID | FK→staff, SET NULL | 归属人（私客独占跟进人） |
+| org_unit_id | UUID | FK→org_units, SET NULL | 归属部门（冗余，加速筛选） |
+| activity_level | VARCHAR(20) | | `new_matched`=新配偶 / `active_7d` / `active_30d` / `active_90d` / `expiring` / `frozen` / `invalid`（异步计算）|
+| last_active_at | TIMESTAMPTZ | | 最后有效跟进时间（触发器维护） |
+| last_follow_at | TIMESTAMPTZ | | 最后跟进时间（冗余，列表排序用） |
+| commission_date | DATE | | 委托日期 |
+| entrust_count | SMALLINT | NOT NULL DEFAULT 1 | 委托次数（成交后再委托则累加） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+| deleted_at | TIMESTAMPTZ | | 软删除时间戳；NULL=未删除，非NULL=已软删除 |
+| created_by | UUID | FK→staff, SET NULL | 创建人（操作员工） |
+| updated_by | UUID | FK→staff, SET NULL | 最后修改人（操作员工） |
+| version | INTEGER | NOT NULL DEFAULT 1 | 乐观锁版本号；每次 UPDATE +1；应用层检测 0 行受影响时抛 ConflictError |
+
+**关键索引**：
+```sql
+CREATE UNIQUE INDEX idx_clients_client_no ON clients(client_no) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clients_type_status ON clients(client_type, status) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clients_owner ON clients(owner_id) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clients_org_unit ON clients(org_unit_id) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clients_activity ON clients(activity_level, last_active_at DESC) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clients_grade ON clients(grade) WHERE deleted_at IS NULL;
+CREATE INDEX idx_clients_transferred_at ON clients(transferred_public_at DESC) WHERE client_type = 'public';
+CREATE INDEX idx_clients_last_follow ON clients(last_follow_at DESC NULLS LAST) WHERE deleted_at IS NULL;
+```
+
+---
+
+### 3.2 client_contacts — 联系人表
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_id | UUID | NOT NULL, FK→clients, CASCADE | 所属客源（关联 clients 表，联系人随客源级联删除） |
+| sort_order | SMALLINT | NOT NULL DEFAULT 0 | 联系人1为主联系人（sort_order=0） |
+| name | VARCHAR(50) | NOT NULL | 联系人姓名 |
+| gender | VARCHAR(10) | NOT NULL DEFAULT 'male' | `male`=先生 / `female`=女士 |
+| phone_enc | BYTEA | NOT NULL | AES-256-GCM 加密手机号（电话1） |
+| phone_hash | VARCHAR(64) | NOT NULL | SHA-256 哈希（重复检测） |
+| phone_country_code | VARCHAR(10) | NOT NULL DEFAULT '+86' | 国际区号 |
+| phone_is_invalid | BOOLEAN | NOT NULL DEFAULT FALSE | 是否被标记为无效号码 |
+| phone2_enc | BYTEA | | 备用电话2 |
+| phone2_hash | VARCHAR(64) | | 备用电话2哈希（SHA-256，用于重复检测） |
+| wechat | VARCHAR(100) | | 微信号 |
+| qq | VARCHAR(20) | | QQ号 |
+| remarks | VARCHAR(200) | | 联系人备注，最多200字 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+| deleted_at | TIMESTAMPTZ | | 软删除时间戳；NULL=未删除（不影响客源本身） |
+| created_by | UUID | FK→staff, SET NULL | 创建人（操作员工） |
+
+**关键索引**：
+```sql
+-- 关键：手机号哈希全局唯一索引（用于重复客源检测）
+CREATE INDEX idx_client_contacts_phone_hash ON client_contacts(phone_hash) WHERE deleted_at IS NULL;
+CREATE INDEX idx_client_contacts_phone2_hash ON client_contacts(phone2_hash) WHERE phone2_hash IS NOT NULL AND deleted_at IS NULL;
+CREATE INDEX idx_client_contacts_client ON client_contacts(client_id) WHERE deleted_at IS NULL;
+```
+
+**业务注意**：
+- `sort_order = 0` 的联系人为主联系人，姓名用于客源姓名显示
+- 手机号标记无效（`phone_is_invalid = TRUE`）时，不影响记录存在，但该号码不再参与重复检测
+- 联系人软删除后客源仍保留，但若所有联系人均被删则客源实际上无有效号码
+
+---
+
+### 3.3 client_requirements — 需求信息表
+
+一个客源可同时有多类需求（二手购房、新房、租房），每类需求独立一条记录。
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_id | UUID | NOT NULL, FK→clients, CASCADE | 所属客源（关联 clients 表，需求随客源级联删除） |
+| requirement_type | VARCHAR(20) | NOT NULL | `second_hand`=二手 / `new_house`=新房 / `rental`=租房 |
+| is_primary | BOOLEAN | NOT NULL DEFAULT TRUE | 是否为主需求（用于列表展示） |
+| budget_min | NUMERIC(12,2) | | 最低预算（万元/元，依据需求类型） |
+| budget_max | NUMERIC(12,2) | | 最高预算 |
+| area_min | NUMERIC(8,2) | | 最小面积（㎡） |
+| area_max | NUMERIC(8,2) | | 最大面积 |
+| bedroom_counts | SMALLINT[] | | 可接受卧室数：如 [2,3]（多选） |
+| floor_preferences | VARCHAR(20)[] | | 楼层偏好多选：`no_first`=不要一层 / `low`=低楼层 / `mid`=中楼层 / `high`=高楼层 / `no_top`=不要顶层 |
+| orientations | VARCHAR(10)[] | | 朝向多选：`east`/`south`/`west`/`north` |
+| decorations | VARCHAR(10)[] | | 装修偏好多选（枚举同 properties.decoration） |
+| building_age_ranges | VARCHAR(20)[] | | 楼龄多选：`within_5y`/`5_10y`/`10_15y`/`15_20y`/`over_20y` |
+| intent_district_ids | UUID[] | | 意向行政区 ID 数组 |
+| intent_business_area_ids | UUID[] | | 意向商圈 ID 数组 |
+| intent_complex_names | TEXT | | 意向小区（文本，逗号分隔，最多500字） |
+| transportation | VARCHAR(50) | | 交通要求（最多50字） |
+| intent_school_names | TEXT | | 意向学校（文本，逗号分隔） |
+| school_enrollment_date | DATE | | 入学时间（月份精度，取该月1日存储） |
+| traffic_preference | TEXT | | 交通备注 |
+| requirement_notes | VARCHAR(200) | | 需求备注（最多200字） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+
+**关键索引**：
+```sql
+CREATE INDEX idx_client_requirements_client ON client_requirements(client_id);
+CREATE INDEX idx_client_requirements_type ON client_requirements(requirement_type, client_id);
+-- 智能配房时按预算/面积范围查询
+CREATE INDEX idx_client_requirements_budget ON client_requirements(budget_min, budget_max);
+CREATE INDEX idx_client_requirements_area ON client_requirements(area_min, area_max);
+```
+
+---
+
+### 3.4 client_follow_logs — 客源跟进日志
+
+> 与 `follow_logs`（房源跟进）结构类似，独立存储以避免跨模块混淆。
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_id | UUID | NOT NULL, FK→clients, CASCADE | 所属客源（关联 clients 表，跟进日志随客源级联删除） |
+| log_type | VARCHAR(30) | NOT NULL | 见下方枚举 |
+| purpose | VARCHAR(50) | | 跟进目的（lookup_items 维护，23项） |
+| content | TEXT | | 跟进内容（最少6字，最多500字） |
+| log_tag | VARCHAR(50) | | 跟进标签：`has_recording`=有录音 / `has_photo`=有图片 / `not_satisfied`=对房源不满意 / `still_considering`=还在考虑 / `ready_to_deposit`=可交定金 |
+| change_detail | JSONB | | 修改跟进专用，格式：`{"field": "grade", "old": "C", "new": "B", "label": "等级"}` |
+| is_public | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=仅本人及上级可见 |
+| is_deletable | BOOLEAN | NOT NULL DEFAULT TRUE | 敏感信息查看类型为 FALSE，不可删除 |
+| operator_id | UUID | FK→staff, SET NULL | 操作人 |
+| operator_snapshot | JSONB | | `{name, store_group, role}`（防止人员调动后显示异常） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| deleted_at | TIMESTAMPTZ | | 软删除时间戳；仅 is_deletable=TRUE 时可软删 |
+
+**log_type 枚举**：
+```
+written       = 写入跟进（经纪人主动写）
+modified      = 修改跟进（字段变更自动生成）
+sensitive_view= 敏感信息查看（查看号码等，不可删）
+other         = 其他跟进（系统自动：新增私客/状态变更等）
+system        = 系统日志
+```
+
+**关键索引**：
+```sql
+CREATE INDEX idx_client_follow_logs_client_time ON client_follow_logs(client_id, created_at DESC) WHERE deleted_at IS NULL;
+CREATE INDEX idx_client_follow_logs_type ON client_follow_logs(client_id, log_type, created_at DESC) WHERE deleted_at IS NULL;
+CREATE INDEX idx_client_follow_logs_operator ON client_follow_logs(operator_id, created_at DESC) WHERE deleted_at IS NULL;
+-- 不可删记录（合规审计）
+CREATE INDEX idx_client_follow_sensitive ON client_follow_logs(client_id, created_at DESC) WHERE log_type = 'sensitive_view';
+```
+
+---
+
+### 3.5 client_follow_log_attachments — 跟进附件
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| follow_log_id | UUID | NOT NULL, FK→client_follow_logs, CASCADE | 所属跟进日志（附件随日志级联删除） |
+| file_key | TEXT | NOT NULL | R2/S3 存储路径 |
+| file_name | VARCHAR(255) | NOT NULL | 原始文件名（用于展示和下载） |
+| file_size | INTEGER | NOT NULL | bytes，最大 20MB |
+| file_type | VARCHAR(10) | CHECK | `bmp`/`jpg`/`png`/`gif` |
+| has_location | BOOLEAN | NOT NULL DEFAULT FALSE | 是否含 GPS 位置信息 |
+| sort_order | SMALLINT | NOT NULL DEFAULT 0 | 附件排序顺序 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+
+---
+
+### 3.6 client_viewings — 带看记录（客源侧视图）
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_id | UUID | NOT NULL, FK→clients, RESTRICT | 所属客源（带看记录仅软删除，不随客源删除） |
+| property_id | UUID | NOT NULL, FK→properties, RESTRICT | 带看房源（房源删除时保留带看记录） |
+| viewing_type | VARCHAR(20) | NOT NULL DEFAULT 'viewing' | `appointment`=预约 / `viewing`=带看 / `revisit`=复看 / `empty`=空看 |
+| agent_id | UUID | FK→staff, SET NULL | 主带看经纪人 |
+| companion_ids | UUID[] | | 陪看人员 ID 数组（最多5人） |
+| cooperator_ids | UUID[] | | 合作带看人 ID 数组（最多5人） |
+| scheduled_at | TIMESTAMPTZ | | 预约时间 |
+| viewing_start_at | TIMESTAMPTZ | | 实际带看开始时间 |
+| viewing_end_at | TIMESTAMPTZ | | 结束时间 |
+| situation | TEXT | | 带看情况（必填，≥6字） |
+| client_intent | VARCHAR(20) | | 客户意向：`interested`=感兴趣 / `not_interested`=不感兴趣 / `negotiating`=谈判中 / `cancelled`=取消 |
+| viewing_progress | SMALLINT | | 带看进度（1=一看，2=二看...，冗余字段，触发器维护） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| deleted_at | TIMESTAMPTZ | | 软删除时间戳；带看记录可软删除 |
+| created_by | UUID | FK→staff, SET NULL | 创建人（操作员工） |
+
+**关键索引**：
+```sql
+CREATE INDEX idx_client_viewings_client ON client_viewings(client_id, viewing_start_at DESC) WHERE deleted_at IS NULL;
+CREATE INDEX idx_client_viewings_property ON client_viewings(property_id) WHERE deleted_at IS NULL;
+CREATE INDEX idx_client_viewings_agent ON client_viewings(agent_id) WHERE deleted_at IS NULL;
+```
+
+---
+
+### 3.7 client_property_matches — 智能配房
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_id | UUID | NOT NULL, FK→clients, CASCADE | 所属客源 |
+| property_id | UUID | NOT NULL, FK→properties, CASCADE | 匹配的房源 |
+| match_source | VARCHAR(20) | NOT NULL DEFAULT 'recorded' | `recorded`=录客配房（基于录入需求） / `system`=系统配房（算法推荐） |
+| match_group | VARCHAR(30) | | 分组：`quality_layout`=优质户型 / `price_reduced`=降价 / `hot`=热门 / `newly_listed`=新上 |
+| match_score | NUMERIC(5,2) | | 匹配度评分（0-100） |
+| match_reasons | JSONB | | 匹配原因详情，格式：`[{"key": "budget", "match": true}, ...]` |
+| status | VARCHAR(20) | NOT NULL DEFAULT 'suggested' | `suggested`=待推送 / `shared`=已分享 / `rejected`=已反馈不合适 / `viewed`=客户已查看 |
+| shared_at | TIMESTAMPTZ | | 分享时间 |
+| feedback | VARCHAR(50) | | 反馈原因（lookup_items 维护） |
+| calculated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 配房计算时间 |
+| created_by | UUID | FK→staff, SET NULL | 触发配房操作的员工（录客配房时记录，系统配房可为NULL） |
+
+**关键索引**：
+```sql
+CREATE UNIQUE INDEX idx_client_matches_pair ON client_property_matches(client_id, property_id);
+CREATE INDEX idx_client_matches_client ON client_property_matches(client_id, match_source, match_group);
+CREATE INDEX idx_client_matches_status ON client_property_matches(client_id, status) WHERE status != 'rejected';
+```
+
+---
+
+### 3.8 client_status_logs — 状态变更日志（不可删）
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| client_id | UUID | NOT NULL, FK→clients, RESTRICT | 所属客源（状态日志永久保留，RESTRICT 防止删除客源） |
+| change_type | VARCHAR(30) | NOT NULL | `status_change`=改状态 / `grade_change`=改等级 / `to_public`=转公客 / `to_transacted`=转成交 / `to_invalid`=转无效 / `owner_change`=改归属人 / `source_change`=改来源 |
+| old_value | JSONB | | 变更前快照，格式：`{"status": "buying", "label": "求购"}` |
+| new_value | JSONB | | 变更后快照 |
+| reason | TEXT | | 变更理由（改状态必填，最多200字） |
+| operator_id | UUID | NOT NULL, FK→staff, RESTRICT | 操作人（必填，状态变更审计用） |
+| operated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 操作时间（系统自动记录） |
+| ⚠️ 无 deleted_at | — | — | 此表记录**不可删除** |
+
+**关键索引**：
+```sql
+CREATE INDEX idx_client_status_logs_client ON client_status_logs(client_id, operated_at DESC);
+CREATE INDEX idx_client_status_logs_type ON client_status_logs(change_type, operated_at DESC);
+```
+
+---
+
+### 3.9 client_favorite_folders — 私客收藏夹
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| staff_id | UUID | NOT NULL, FK→staff, CASCADE | 收藏夹所属经纪人 |
+| name | VARCHAR(10) | NOT NULL | 收藏夹名称，最多10字 |
+| is_default | BOOLEAN | NOT NULL DEFAULT FALSE | 系统默认收藏夹 |
+| sort_order | INTEGER | NOT NULL DEFAULT 0 | 收藏夹显示顺序（升序） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| deleted_at | TIMESTAMPTZ | | 软删除时间戳；NULL=未删除 |
+
+```sql
+CREATE INDEX idx_favorite_folders_staff ON client_favorite_folders(staff_id) WHERE deleted_at IS NULL;
+-- 每个经纪人只能有一个默认收藏夹
+CREATE UNIQUE INDEX idx_favorite_folders_default ON client_favorite_folders(staff_id) WHERE is_default = TRUE AND deleted_at IS NULL;
+```
+
+---
+
+### 3.10 client_folder_items — 收藏夹中的客源
+
+| 字段          | 类型                     | 约束                                            | 业务说明 |
+| ----------- | ---------------------- | --------------------------------------------- | ---- |
+| folder_id   | UUID                   | NOT NULL, FK→client_favorite_folders, CASCADE | 所属收藏夹 |
+| client_id   | UUID                   | NOT NULL, FK→clients, CASCADE                 | 被收藏的客源 |
+| added_at    | TIMESTAMPTZ            | NOT NULL DEFAULT NOW()                        | 加入收藏夹时间 |
+| PRIMARY KEY | (folder_id, client_id) |                                               | 联合主键（同一客源在同一收藏夹只能出现一次） |
+
+```sql
+CREATE INDEX idx_folder_items_client ON client_folder_items(client_id);
+```
+
+---
+
+### 3.11 client_school_preferences — 意向学校（多对多）
+
+> 单独拆表便于学校搜索，避免文本字段模糊查询。
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| requirement_id | UUID | NOT NULL, FK→client_requirements, CASCADE | 所属需求（意向学校随需求级联删除） |
+| school_id | UUID | FK→schools, SET NULL | 从学校表选择，允许为 NULL（自由输入） |
+| school_name | VARCHAR(100) | NOT NULL | 学校名称（当 school_id 为 NULL 时为手动输入） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+
+```sql
+CREATE INDEX idx_school_prefs_requirement ON client_school_preferences(requirement_id);
+```
+
+---
+
+## 四、枚举常量
+
+### clients.status（客源状态）
+
+```
+buying         = 求购（私客活跃态）
+renting        = 求租（私客活跃态）
+buy_or_rent    = 租购（私客活跃态）
+suspended      = 暂缓（暂时无需求，不计入活跃统计）
+bought         = 已购（成交客：我购）
+rented_done    = 已租（成交客：我租）
+public         = 公客（已转入公客池）
+invalid        = 无效（号码无效/无意向等）
+```
+
+**状态流转规则**：
+```
+buying/renting/buy_or_rent
+  → suspended    （改状态操作，可逆）
+  → public       （手动转公 or 超时自动转公，不可逆）
+  → bought/rented_done （转成交，不可逆）
+  → invalid      （转无效，需经理审批后可恢复）
+```
+
+### clients.grade（等级）
+
+```
+A         = A(急迫)
+B         = B(较强)
+C         = C(一般，默认值)
+D         = D(较弱)
+E         = E(暂不关注)
+```
+
+### client_status_logs.change_type（变更类型）
+
+```
+status_change     = 改状态（含改等级时同时改状态的情况）
+grade_change      = 改等级
+to_public         = 转公客（manual=手动 or auto=自动）
+to_transacted     = 转成交（记录成交信息）
+to_invalid        = 转无效（含无效原因）
+owner_change      = 改归属人
+source_change     = 改来源
+merge             = 合并客源（被合并的记录保留日志）
+```
+
+### clients.activity_level（活跃度分层，系统计算）
+
+| 值             | 含义     | 触发条件（示例，以运营配置为准）   |
+| ------------- | ------ | ------------------ |
+| `new_matched` | 新匹配    | 录入后 3 天内           |
+| `active_7d`   | 7日活跃   | 最后跟进在 7 天内         |
+| `active_30d`  | 30日活跃  | 最后跟进在 30 天内        |
+| `active_90d`  | 90日活跃  | 最后跟进在 90 天内        |
+| `expiring`    | 即将过期   | 距自动转公还有 N 天        |
+| `frozen`      | 冻结（暂缓） | status = suspended |
+| `invalid`     | 无效     | status = invalid   |
+
+---
+
+## 五、查询模式
+
+### 5.1 私客列表页（求购 Tab）核心查询
+
+```sql
+-- 典型：当前经纪人名下 + 求购状态 + 等级筛选 + 按最后跟进排序
+SELECT c.id, c.status, c.grade, c.activity_level,
+       c.last_follow_at, c.commission_date, c.buying_purpose,
+       cc.name AS contact_name,   -- JOIN 主联系人
+       s.name AS owner_name, ou.name AS org_unit_name,
+       COUNT(cpm.id) AS match_count   -- 智能配房数量
+FROM clients c
+JOIN client_contacts cc ON cc.client_id = c.id AND cc.sort_order = 0 AND cc.deleted_at IS NULL
+JOIN staff s ON s.id = c.owner_id
+JOIN org_units ou ON ou.id = c.org_unit_id
+LEFT JOIN client_property_matches cpm ON cpm.client_id = c.id AND cpm.status != 'rejected'
+WHERE c.client_type = 'private'
+  AND c.owner_id = :current_staff_id       -- 与我相关
+  AND c.status IN ('buying', 'buy_or_rent')
+  AND c.deleted_at IS NULL
+GROUP BY c.id, cc.name, s.name, ou.name
+ORDER BY c.last_follow_at DESC NULLS LAST
+LIMIT 20 OFFSET :offset;
+```
+
+### 5.2 重复客源检测（录入/编辑时触发）
+
+```sql
+-- 手机号哈希碰撞检测（私客、成交客、公客三池同时检查）
+SELECT c.id, c.client_type, c.status, c.client_no,
+       cc.name AS contact_name
+FROM client_contacts cc
+JOIN clients c ON cc.client_id = c.id
+WHERE cc.phone_hash = :new_phone_hash
+  AND cc.deleted_at IS NULL
+  AND c.deleted_at IS NULL
+  AND c.status != 'invalid';
+```
+
+### 5.3 活跃度批量更新（Celery 定时任务，每日凌晨执行）
+
+```sql
+-- 更新活跃度（以7日活跃为例）
+UPDATE clients
+SET activity_level = 'active_7d',
+    updated_at = NOW()
+WHERE client_type = 'private'
+  AND status NOT IN ('invalid', 'public', 'bought', 'rented_done')
+  AND last_follow_at >= NOW() - INTERVAL '7 days'
+  AND deleted_at IS NULL;
+```
+
+### 5.4 私客自动转公（超时无跟进，Celery 定时任务）
+
+```sql
+-- 查询应自动转公的私客（阈值由运营配置，假设30天）
+SELECT id FROM clients
+WHERE client_type = 'private'
+  AND status IN ('buying', 'renting', 'buy_or_rent')
+  AND last_follow_at < NOW() - INTERVAL '30 days'
+  AND is_protected = FALSE
+  AND deleted_at IS NULL;
+-- 后续在 Application 层批量更新 client_type='public', transfer_to_public_type='auto'
+```
+
+---
+
+## 六、触发器
+
+### 6.1 last_follow_at 自动维护
+
+```sql
+-- 每次写入跟进日志时，自动更新 clients.last_follow_at
+CREATE OR REPLACE FUNCTION update_client_last_follow()
+RETURNS TRIGGER AS $$
+BEGIN
+    IF NEW.log_type = 'written' THEN
+        UPDATE clients
+        SET last_follow_at = NEW.created_at,
+            last_active_at = NEW.created_at,
+            updated_at = NOW()
+        WHERE id = NEW.client_id;
+    END IF;
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_client_last_follow
+    AFTER INSERT ON client_follow_logs
+    FOR EACH ROW EXECUTE FUNCTION update_client_last_follow();
+```
+
+### 6.2 viewing_progress 自动维护
+
+```sql
+-- 每次新增带看记录时，自动更新 clients 的带看进度冗余字段
+CREATE OR REPLACE FUNCTION update_client_viewing_progress()
+RETURNS TRIGGER AS $$
+BEGIN
+    UPDATE clients
+    SET updated_at = NOW()
+    WHERE id = NEW.client_id;
+    -- Application 层根据 COUNT(viewings) 计算具体进度
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_client_viewing_progress
+    AFTER INSERT ON client_viewings
+    FOR EACH ROW EXECUTE FUNCTION update_client_viewing_progress();
+```
+
+---
+
+## 七、禁止操作
+
+- ❌ **严禁硬删除 clients 记录**：无效/转公客/成交客均通过 status 和 soft delete 处理，历史跟进/带看依赖外键
+- ❌ **严禁删除 client_status_logs**：状态变更为不可变审计日志
+- ❌ **严禁删除 log_type='sensitive_view' 的跟进记录**：必须通过 `is_deletable=FALSE` 约束在应用层拦截
+- ❌ **严禁明文存储联系人手机号**：必须走 `EncryptedPhoneField`，`phone_hash` 用于索引和重复检测
+- ❌ **严禁跳过状态机流转**：如私客不可直接跳过「求购」变为「无效」而不生成 status log
+- ❌ **严禁在没有 `client_type` 过滤的情况下查询客源列表**：私客/公客/成交客数据量均较大，必须按类型隔离查询
+- ❌ **严禁查询 clients 时不带 `deleted_at IS NULL`**：软删除过滤必须存在

Project/fonrey/DATA_MODEL/DATA_MODEL_COMPLEX.md

@@ -0,0 +1,555 @@
+> **For AI assistants**: Read this entire file before writing any code. All decisions here are final. Do not suggest alternatives unless asked.
+# Fonrey — 楼盘与区域数据模型（DATA_MODEL_COMPLEX）
+
+> **所属系统**: Fonrey 房产经纪管理系统  
+> **版本**: v1.0  
+> **日期**: 2026-04-24  
+> **关联模块**: `apps/complex/` — 楼盘/小区、楼栋、结构（楼层+房号）、区域、学校
+
+---
+
+## 变更历史
+
+| 日期 | 变更人 | 变更内容 |
+|---|---|---|
+| 2026-04-30 | Atlas | 补充“变更历史”章节（文档治理） |
+
+## 一、领域概览（Domain Overview）
+
+### 核心概念
+
+- **Complex（楼盘/小区）**：房源录入的基础底座。每套房源必须归属于某一楼盘。楼盘数据由运营/数据管理员集中维护，质量直接影响房源录入效率和搜索精度。
+- **Building（楼栋/单元）**：楼盘下的物理楼栋，是组织房源位置的第二级。一个楼盘可有多个楼栋（如「1号楼」「2栋2单元」）。
+- **RoomUnit（房号/结构单元）**：楼栋内特定楼层的某个房间标识，是房源定位的最细粒度。支持「标准结构」（经运营标准化）和「非标结构」（未归一化）两类。
+- **District（城区/行政区）**：行政区划，如静安区、闵行区。
+- **BusinessArea（商圈/板块）**：商圈是区域内的细分市场区域，如「南京西路商圈」，一个楼盘可跨多个商圈。
+- **School（学校）**：楼盘对口学校，是买家购房决策的核心关注点。一个楼盘可关联多所学校，一所学校可对口多个楼盘。
+- **MetroLine / MetroStation（地铁线路/站点）**：楼盘与最近地铁站的距离关系，用于通勤筛选。
+
+### 关键业务规则
+
+1. **楼盘名称不可在编辑页修改**：楼盘名称（`name`）变更须通过「合并楼盘」或「申请流程」处理，防止经纪人随意改名造成数据混乱。
+2. **数据锁定机制**：楼盘有 4 类锁（楼栋锁/房号锁/信息锁/标准房号锁），锁定后对应数据只有管理员可解锁修改。
+3. **非标结构处理**：未与标准结构关联的房号为「非标」，系统记录非标数量，引导运营逐步消除。
+4. **搜索依赖全文检索**：楼盘名称、别名、地址需维护 `search_vector`（`tsvector`）以支持模糊搜索和联想补全。
+5. **地理坐标优先级**：楼盘坐标是区域聚合展示（地图找房）的核心数据，完整度目标 ≥ 90%。
+6. **学校关联影响房源**：从楼盘详情删除对口学校，会级联删除该楼盘下所有房源的对应学区标注。
+
+---
+
+## 二、实体关系
+
+```
+District (城区/行政区)
+  └── 1:N ── BusinessArea (商圈/板块)
+                └── N:M ── Complex (through complex_business_areas)
+
+Complex (楼盘)
+  ├── N:M ── BusinessArea     (through complex_business_areas)
+  ├── N:M ── School           (through complex_schools)
+  ├── N:M ── MetroStation     (through complex_metro_stations, 附带距离)
+  ├── 1:N ── Building         (楼栋/单元)
+  │             └── 1:N ── RoomUnit (楼层+房号)
+  ├── 1:N ── ComplexPhoto     (楼盘照片：楼盘图/户型图/VR)
+  ├── 1:N ── ComplexAttachment(附件)
+  ├── 1:N ── ComplexPriceTrend(价格走势，月度)
+  └── 1:N ── ComplexAlias     (别名)
+
+MetroLine (地铁线路)
+  └── 1:N ── MetroStation (站点)
+```
+
+---
+
+## 三、Schema 定义
+
+### 3.1 districts — 城区/行政区
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| city | VARCHAR(50) | NOT NULL | 所属城市（支持多城市扩展，如「上海」「北京」） |
+| name | VARCHAR(50) | NOT NULL | 行政区名称，如「静安区」 |
+| short_name | VARCHAR(20) | | 简称，如「静安」 |
+| sort_order | INTEGER | NOT NULL DEFAULT 0 | 列表展示排序 |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用（不在筛选项中展示） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+
+```sql
+CREATE UNIQUE INDEX idx_districts_city_name ON districts(city, name) WHERE is_active = TRUE;
+```
+
+---
+
+### 3.2 business_areas — 商圈/板块
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| district_id | UUID | NOT NULL, FK→districts, RESTRICT | 所属城区 |
+| name | VARCHAR(100) | NOT NULL | 商圈名称 |
+| sort_order | INTEGER | NOT NULL DEFAULT 0 | 列表展示排序 |
+| latitude | NUMERIC(10,7) | | 商圈中心坐标（纬度） |
+| longitude | NUMERIC(10,7) | | 商圈中心坐标（经度） |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用（不在筛选项中展示） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+
+```sql
+CREATE INDEX idx_business_areas_district ON business_areas(district_id) WHERE is_active = TRUE;
+CREATE UNIQUE INDEX idx_business_areas_name ON business_areas(district_id, name);
+```
+
+---
+
+### 3.3 metro_lines — 地铁线路
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| city | VARCHAR(50) | NOT NULL | 所属城市 |
+| name | VARCHAR(50) | NOT NULL | 线路名，如「1号线」 |
+| color | VARCHAR(7) | | 线路颜色 HEX（如 `#E3002B`） |
+| sort_order | INTEGER | NOT NULL DEFAULT 0 | 列表展示排序 |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用（不在筛选项中展示） |
+
+---
+
+### 3.4 metro_stations — 地铁站点
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| metro_line_id | UUID | NOT NULL, FK→metro_lines, CASCADE | 所属线路 |
+| name | VARCHAR(50) | NOT NULL | 站名 |
+| latitude | NUMERIC(10,7) | | 站点坐标 |
+| longitude | NUMERIC(10,7) | | 站点坐标（经度） |
+| sort_order | INTEGER | NOT NULL DEFAULT 0 | 沿线排序 |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用（不在筛选项中展示） |
+
+```sql
+CREATE INDEX idx_metro_stations_line ON metro_stations(metro_line_id) WHERE is_active = TRUE;
+```
+
+---
+
+### 3.5 schools — 学校
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| district_id | UUID | FK→districts, SET NULL | 所属城区 |
+| name | VARCHAR(100) | NOT NULL | 学校名称 |
+| type | VARCHAR(20) | | 学校类型：`primary`=小学 / `middle`=初中 / `high`=高中 / `k9`=九年一贯制 / `k12`=十二年一贯制 |
+| nature | VARCHAR(20) | | 学校性质：`public`=公立 / `private`=私立 / `international`=国际学校 |
+| level | VARCHAR(20) | | 学校等级：`normal`=普通 / `key`=重点 / `top`=名校 |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用（不在筛选项中展示） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+
+```sql
+CREATE INDEX idx_schools_district ON schools(district_id) WHERE is_active = TRUE;
+CREATE INDEX idx_schools_name_trgm ON schools USING gin(name gin_trgm_ops);
+```
+
+---
+
+### 3.6 complexes — 楼盘/小区（核心基础表）
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| name | VARCHAR(200) | NOT NULL | 标准楼盘名称，**不可在编辑页修改**（需走合并/申请流程） |
+| district_id | UUID | FK→districts, SET NULL | 所属城区 |
+| address | VARCHAR(500) | | 详细地址（不可在编辑页修改，需走纠错流程） |
+| address_summary | VARCHAR(100) | | 概要地址（如「海波路1000弄」，可编辑） |
+| latitude | NUMERIC(10,7) | | 楼盘坐标（纬度），完整度目标 ≥ 90% |
+| longitude | NUMERIC(10,7) | | 地铁站经度坐标（WGS84） |
+| **物业属性** | | | |
+| property_usage_types | VARCHAR(20)[] | | 物业类型多选：`residential`/`villa`/`commercial_residential`/`commercial`/`office`/`other` |
+| building_structure | VARCHAR(30) | | 楼栋结构枚举（运营维护）：`unit_room`=单元-房号 / `other`=其他 |
+| building_type | VARCHAR(20) | | 建筑类型：`slab`=板楼 / `tower`=塔楼 / `slab_tower`=板塔结合 |
+| land_use_years | VARCHAR(30) | | 土地使用年限，如「70年」 |
+| built_year | SMALLINT | | 竣工年份（可多选，存最早竣工年） |
+| built_years | SMALLINT[] | | 竣工年份多值（楼盘分期竣工） |
+| ownership_category | VARCHAR(30)[] | | 权属类别多选（运营维护枚举） |
+| total_units | INTEGER | | 单元总数 |
+| total_households | INTEGER | | 总户数 |
+| **建设信息** | | | |
+| total_floor_area | NUMERIC(12,2) | | 小区总建筑面积（m²） |
+| plot_area | NUMERIC(12,2) | | 小区占地面积（m²） |
+| plot_ratio | NUMERIC(5,2) | | 容积率 |
+| green_rate | NUMERIC(5,2) | | 绿化率（%） |
+| developer | VARCHAR(200) | | 开发商 |
+| **物业信息** | | | |
+| property_company | VARCHAR(200) | | 物业公司 |
+| property_fee | NUMERIC(8,2) | | 物业费（元/m²/月） |
+| property_phone | VARCHAR(30) | | 物业电话 |
+| **停车** | | | |
+| parking_total | INTEGER | | 车位总数 |
+| parking_underground | INTEGER | | 地下车位数 |
+| parking_ratio | VARCHAR(20) | | 停车位配比，如「100:63」 |
+| **配套** | | | |
+| water_type | VARCHAR(10) | | `civil`=民水 / `commercial`=商水 |
+| electricity_type | VARCHAR(10) | | `civil`=民电 / `commercial`=商电 |
+| has_central_heating | BOOLEAN | | 是否统一供暖 |
+| has_gas | BOOLEAN | | 是否有燃气 |
+| remarks | TEXT | | 备注 |
+| **锁定状态** | | | |
+| lock_building | BOOLEAN | NOT NULL DEFAULT FALSE | 楼栋锁（锁定后不可增删楼栋） |
+| lock_room | BOOLEAN | NOT NULL DEFAULT FALSE | 房号锁 |
+| lock_info | BOOLEAN | NOT NULL DEFAULT FALSE | 信息锁（锁定后基本信息只读） |
+| lock_standard_room | BOOLEAN | NOT NULL DEFAULT FALSE | 标准房号锁 |
+| **全文检索** | | | |
+| search_vector | TSVECTOR | | 由触发器自动维护（name + alias + address） |
+| **状态** | | | |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用楼盘 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+| deleted_at | TIMESTAMPTZ | | 软删除时间戳；NULL=未删除，非NULL=已软删除 |
+| created_by | UUID | FK→staff, SET NULL | 创建人（操作员工） |
+| updated_by | UUID | FK→staff, SET NULL | 最后更新人（操作员工） |
+| version | INTEGER | NOT NULL DEFAULT 1 | 乐观锁版本号；每次 UPDATE +1；应用层检测 0 行受影响时抛 ConflictError |
+
+**关键索引**：
+```sql
+CREATE INDEX idx_complexes_district ON complexes(district_id) WHERE deleted_at IS NULL;
+CREATE INDEX idx_complexes_name_trgm ON complexes USING gin(name gin_trgm_ops);  -- 模糊搜索
+CREATE INDEX idx_complexes_search ON complexes USING gin(search_vector);           -- 全文搜索
+CREATE INDEX idx_complexes_geo ON complexes(latitude, longitude) WHERE deleted_at IS NULL AND latitude IS NOT NULL;
+CREATE INDEX idx_complexes_active ON complexes(is_active) WHERE deleted_at IS NULL;
+```
+
+---
+
+### 3.7 complex_aliases — 楼盘别名
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘（别名随楼盘级联删除） |
+| alias | VARCHAR(200) | NOT NULL | 别名（最多20字/条，多别名多行存储） |
+| is_system | BOOLEAN | NOT NULL DEFAULT FALSE | TRUE=系统/标准别名（只读），FALSE=用户自定义 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| created_by | UUID | FK→staff, SET NULL | 创建人（操作员工） |
+
+```sql
+CREATE INDEX idx_complex_aliases_complex ON complex_aliases(complex_id);
+CREATE INDEX idx_complex_aliases_alias_trgm ON complex_aliases USING gin(alias gin_trgm_ops);
+```
+
+---
+
+### 3.8 complex_business_areas — 楼盘与商圈多对多
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| business_area_id | UUID | NOT NULL, FK→business_areas, CASCADE | 关联商圈 |
+| is_primary | BOOLEAN | NOT NULL DEFAULT FALSE | 主商圈（唯一）用于列表显示 |
+| PRIMARY KEY | (complex_id, business_area_id) | | 联合主键（楼盘与商圈多对多） |
+
+```sql
+-- 主商圈只能有一个
+CREATE UNIQUE INDEX idx_complex_biz_area_primary ON complex_business_areas(complex_id) WHERE is_primary = TRUE;
+```
+
+---
+
+### 3.9 complex_schools — 楼盘与学校关联
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| school_id | UUID | NOT NULL, FK→schools, CASCADE | 对口学校 |
+| zone_type | VARCHAR(30) | | 学区类型：`guaranteed`=对口 / `reference`=参考 / `lottery`=摇号 |
+| PRIMARY KEY | (complex_id, school_id) | | 联合主键（楼盘与学校多对多） |
+
+```sql
+CREATE INDEX idx_complex_schools_school ON complex_schools(school_id);
+```
+
+**业务注意**：删除此关联记录时，需同步清理对应房源的学区标注（Application 层事务处理）
+
+---
+
+### 3.10 complex_metro_stations — 楼盘与地铁站关联
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| station_id | UUID | NOT NULL, FK→metro_stations, CASCADE | 关联地铁站 |
+| distance_meters | INTEGER | | 步行距离（米） |
+| PRIMARY KEY | (complex_id, station_id) | | 联合主键（楼盘与地铁站多对多） |
+
+```sql
+CREATE INDEX idx_complex_metro_complex ON complex_metro_stations(complex_id);
+CREATE INDEX idx_complex_metro_station ON complex_metro_stations(station_id);
+```
+
+---
+
+### 3.11 buildings — 楼栋/单元
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| name | VARCHAR(50) | NOT NULL | 楼栋名，如「1号楼」「A栋2单元」 |
+| is_standard | BOOLEAN | NOT NULL DEFAULT FALSE | TRUE=标准结构（经运营核准） |
+| property_usage_type | VARCHAR(20) | | 物业类型（可与楼盘不同，如商住楼盘内有纯商铺楼栋） |
+| built_year | SMALLINT | | 竣工年份 |
+| total_floors | SMALLINT | | 总层数 |
+| land_use_years | VARCHAR(30) | | 土地使用年限 |
+| has_elevator | BOOLEAN | | 是否有电梯 |
+| school_id | UUID | FK→schools, SET NULL | 关联对口学校（楼栋级别的学区差异） |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已停用（楼栋被删除或合并） |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+| created_by | UUID | FK→staff, SET NULL | 创建人（操作员工） |
+
+```sql
+CREATE INDEX idx_buildings_complex ON buildings(complex_id) WHERE is_active = TRUE;
+CREATE UNIQUE INDEX idx_buildings_name ON buildings(complex_id, name) WHERE is_active = TRUE;
+```
+
+---
+
+### 3.12 room_units — 房号/结构单元（楼层+房间号）
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| building_id | UUID | NOT NULL, FK→buildings, CASCADE | 所属楼栋 |
+| floor | SMALLINT | NOT NULL | 楼层（实际层数，地下为负数） |
+| floor_name | VARCHAR(20) | | 楼层名称展示，如「1层」「B1层」 |
+| room_no | VARCHAR(30) | NOT NULL | 房号，如「01」「101」 |
+| display_no | VARCHAR(50) | | 展示用完整房号，如「3-1-101」 |
+| is_standard | BOOLEAN | NOT NULL DEFAULT FALSE | TRUE=已归一化为标准结构 |
+| is_active | BOOLEAN | NOT NULL DEFAULT TRUE | FALSE=已拆除/不存在 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| updated_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录最后更新时间（系统自动） |
+
+```sql
+CREATE INDEX idx_room_units_building ON room_units(building_id) WHERE is_active = TRUE;
+CREATE UNIQUE INDEX idx_room_units_unique ON room_units(building_id, floor, room_no) WHERE is_active = TRUE;
+```
+
+---
+
+### 3.13 complex_photos — 楼盘照片
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| category | VARCHAR(20) | NOT NULL | `complex`=楼盘图 / `layout`=户型图 / `vr`=VR全景 / `other`=其他 |
+| file_key | TEXT | NOT NULL | R2/S3 路径 |
+| thumbnail_key | TEXT | | 缩略图路径 |
+| file_name | VARCHAR(255) | | 原始文件名 |
+| file_size | INTEGER | | 文件大小（bytes） |
+| width | INTEGER | | 图片宽度（px） |
+| height | INTEGER | | 图片高度（px） |
+| is_cover | BOOLEAN | NOT NULL DEFAULT FALSE | 楼盘封面图 |
+| sort_order | SMALLINT | NOT NULL DEFAULT 0 | 同类别内的排序顺序 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| created_by | UUID | FK→staff, SET NULL | 上传人（操作员工） |
+
+```sql
+CREATE INDEX idx_complex_photos_complex ON complex_photos(complex_id);
+CREATE INDEX idx_complex_photos_category ON complex_photos(complex_id, category);
+CREATE UNIQUE INDEX idx_complex_photos_cover ON complex_photos(complex_id) WHERE is_cover = TRUE;
+```
+
+---
+
+### 3.14 complex_attachments — 楼盘附件
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| file_key | TEXT | NOT NULL | R2/S3 存储路径 |
+| file_name | VARCHAR(255) | NOT NULL | 原始文件名 |
+| file_size | INTEGER | | 文件大小（bytes） |
+| file_type | VARCHAR(50) | | MIME type |
+| sort_order | SMALLINT | NOT NULL DEFAULT 0 | 同类别内的排序顺序 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+| created_by | UUID | FK→staff, SET NULL | 上传人（操作员工） |
+
+---
+
+### 3.15 complex_price_trends — 楼盘价格走势（月度）
+
+| 字段 | 类型 | 约束 | 业务说明 |
+|------|------|------|----------|
+| id | UUID | PK | 主键（系统生成，业务无关） |
+| complex_id | UUID | NOT NULL, FK→complexes, CASCADE | 所属楼盘 |
+| record_month | DATE | NOT NULL | 月份（统一存为该月1日，如 2026-04-01） |
+| avg_sale_price | NUMERIC(12,2) | | 月均售价（万元/套） |
+| avg_unit_price | NUMERIC(10,2) | | 月均单价（元/m²） |
+| transaction_count | INTEGER | | 成交套数 |
+| listing_count | INTEGER | | 当月挂牌套数 |
+| created_at | TIMESTAMPTZ | NOT NULL DEFAULT NOW() | 记录创建时间（系统自动） |
+
+```sql
+CREATE UNIQUE INDEX idx_complex_price_trend_month ON complex_price_trends(complex_id, record_month);
+CREATE INDEX idx_complex_price_trend_complex ON complex_price_trends(complex_id, record_month DESC);
+```
+
+---
+
+## 四、枚举常量
+
+### complexes.building_type（建筑类型）
+
+```
+slab          = 板楼
+tower         = 塔楼
+slab_tower    = 板塔结合
+```
+
+### complexes.water_type / electricity_type
+
+```
+civil         = 民水/民电（住宅水电费率）
+commercial    = 商水/商电（商业水电费率，费用较高，影响买家决策）
+```
+
+### complex_schools.zone_type（学区类型）
+
+```
+guaranteed    = 对口（直升）
+reference     = 参考（可能入读）
+lottery       = 摇号（通过摇号入学）
+```
+
+### buildings.is_standard / room_units.is_standard
+
+```
+TRUE  = 已标准化（楼栋/房号已经运营核准，可用于精准房源定位）
+FALSE = 非标（用户自输入，未核准，存在歧义风险）
+```
+
+---
+
+## 五、查询模式
+
+### 5.1 楼盘名称联想搜索（录入房源时的自动补全）
+
+```sql
+-- 使用全文检索向量，支持中文分词近似匹配
+SELECT id, name, address_summary, district_id
+FROM complexes
+WHERE search_vector @@ plainto_tsquery('simple', :keyword)
+   OR name ILIKE :keyword_prefix  -- 前缀精确匹配优先
+  AND deleted_at IS NULL
+  AND is_active = TRUE
+ORDER BY
+  ts_rank(search_vector, plainto_tsquery('simple', :keyword)) DESC,
+  name
+LIMIT 20;
+```
+
+### 5.2 楼盘列表（含房源数量统计）
+
+```sql
+SELECT
+    c.id, c.name, c.address, c.latitude, c.longitude,
+    d.name AS district_name,
+    ba.name AS primary_business_area,
+    COUNT(DISTINCT b.id) AS building_count,
+    COUNT(DISTINCT p.id) FILTER (WHERE p.status IN ('for_sale','for_sale_rent')) AS sale_count,
+    COUNT(DISTINCT p.id) FILTER (WHERE p.status IN ('for_rent','for_sale_rent')) AS rent_count
+FROM complexes c
+LEFT JOIN districts d ON d.id = c.district_id
+LEFT JOIN complex_business_areas cba ON cba.complex_id = c.id AND cba.is_primary = TRUE
+LEFT JOIN business_areas ba ON ba.id = cba.business_area_id
+LEFT JOIN buildings b ON b.complex_id = c.id AND b.is_active = TRUE
+LEFT JOIN properties p ON p.complex_id = c.id AND p.deleted_at IS NULL
+WHERE c.deleted_at IS NULL
+  AND c.district_id = ANY(:district_ids)  -- 区域筛选
+GROUP BY c.id, d.name, ba.name
+ORDER BY c.name
+LIMIT 20 OFFSET :offset;
+```
+
+### 5.3 查询楼盘下的楼层-房号矩阵（结构管理）
+
+```sql
+-- 选中单元后，加载楼层×房号矩阵
+SELECT
+    ru.floor,
+    ru.floor_name,
+    ru.room_no,
+    ru.display_no,
+    ru.is_standard,
+    p.id AS property_id,       -- 如果该房号已有房源，关联显示
+    p.status AS property_status
+FROM room_units ru
+LEFT JOIN properties p ON p.building_id = ru.building_id
+    AND p.room_no = ru.room_no
+    AND p.floor = ru.floor
+    AND p.deleted_at IS NULL
+WHERE ru.building_id = :building_id
+  AND ru.is_active = TRUE
+ORDER BY ru.floor DESC, ru.room_no;
+```
+
+---
+
+## 六、触发器
+
+### 6.1 楼盘全文检索向量（含别名）
+
+```sql
+CREATE OR REPLACE FUNCTION update_complex_search_vector()
+RETURNS TRIGGER AS $$
+BEGIN
+    NEW.search_vector :=
+        setweight(to_tsvector('simple', COALESCE(NEW.name, '')), 'A') ||
+        setweight(to_tsvector('simple', COALESCE(NEW.address_summary, '')), 'B') ||
+        setweight(to_tsvector('simple', COALESCE(NEW.address, '')), 'C');
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_complex_search_vector
+    BEFORE INSERT OR UPDATE OF name, address_summary, address
+    ON complexes
+    FOR EACH ROW EXECUTE FUNCTION update_complex_search_vector();
+
+-- 别名变更时同步更新楼盘 search_vector
+CREATE OR REPLACE FUNCTION update_complex_search_on_alias()
+RETURNS TRIGGER AS $$
+BEGIN
+    UPDATE complexes
+    SET search_vector = (
+        setweight(to_tsvector('simple', COALESCE(name, '')), 'A') ||
+        setweight(to_tsvector('simple',
+            COALESCE((SELECT string_agg(alias, ' ') FROM complex_aliases WHERE complex_id = complexes.id), '')), 'B') ||
+        setweight(to_tsvector('simple', COALESCE(address_summary, '')), 'C') ||
+        setweight(to_tsvector('simple', COALESCE(address, '')), 'D')
+    ),
+    updated_at = NOW()
+    WHERE id = COALESCE(NEW.complex_id, OLD.complex_id);
+    RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+CREATE TRIGGER trg_complex_alias_search
+    AFTER INSERT OR UPDATE OR DELETE ON complex_aliases
+    FOR EACH ROW EXECUTE FUNCTION update_complex_search_on_alias();
+```
+
+---
+
+## 七、禁止操作
+
+- ❌ **严禁直接修改 complexes.name**：楼盘名称变更必须走「楼盘合并」流程或「管理员申请」，通过 Application 层拦截任何直接 UPDATE `name` 字段的操作
+- ❌ **严禁硬删除 complexes 记录**：有房源关联的楼盘不可删除（`RESTRICT` 外键），已有房源的楼盘软删除后房源仍可正常访问
+- ❌ **严禁删除 complex_schools 关联而不清理房源学区标注**：必须在同一事务中清理对应 `property.school_ids` 数据
+- ❌ **严禁在楼盘坐标为 NULL 时将其用于地图聚合**：坐标为空时不参与地图展示，过滤条件：`WHERE latitude IS NOT NULL`
+- ❌ **严禁在 lock_info=TRUE 时绕过 Application 层直接修改楼盘信息字段**：锁定状态必须在服务层检查，不依赖数据库约束
+- ❌ **严禁在没有 deleted_at IS NULL 过滤的情况下查询 complexes**：楼盘软删除过滤必须存在

Project/fonrey/DATA_MODEL/DATA_MODEL_LOGIN.md

@@ -0,0 +1,526 @@
+# Fonrey — 登录与账号认证数据模型（DATA_MODEL_LOGIN）
+
+> **所属系统**: Fonrey 房产经纪管理系统  
+> **版本**: v1.0  
+> **日期**: 2026-04-24  
+> **关联模块**: `apps/accounts/` — 账号认证、登录安全、密码管理  
+> **关联 PRD**: `Project/fonrey/PRD/登录管理/用户登录管理模块PRD.md` (v2.0)  
+> **关联技术方案**: `Project/fonrey/TECH_STACK/登录管理技术方案.md`
+
+---
+
+## 变更历史
+
+| 日期 | 变更人 | 变更内容 |
+|---|---|---|
+| 2026-04-30 | Atlas | 补充“变更历史”章节（文档治理） |
+
+## 一、领域概览（Domain Overview）
+
+### 核心概念
+
+- **UserAccount（用户账号）**：系统登录主体，必须与员工档案（`org.Staff`）1:1 绑定。分为 Tenant Admin（超级管理账号，每租户唯一，username 固定为联系人手机号）和普通员工账号（username 固定为员工手机号）。
+- **LoginAttempt（登录尝试记录）**：记录每次登录行为（成功/失败），用于安全审计和账号锁定判断，保留 ≥ 90 天。
+- **PasswordResetToken（密码重置令牌）**：~~通过邮件找回密码时生成的一次性令牌~~ 已废弃，详见 `SmsOtpRecord`。
+- **SmsOtpRecord（短信验证码记录）**：找回密码和手机验证码登录时向用户手机号发送的 6 位一次性验证码。用 `scene` 字段区分场景（`password_reset` / `login`），有效期按场景不同（找回密码 10 分钟，验证码登录 5 分钟）；找回密码验证通过后颁发 `sms_reset_token`（有效期 15 分钟），验证码登录验证通过后直接颁发 Session Token；使用后立即作废。
+- **PasswordHistory（历史密码记录）**：保存最近 3 次密码哈希，用于防止重复使用历史密码。
+
+### 关键业务规则
+
+1. **账号与员工强绑定**：每个登录账号 **必须** 与 `org.Staff` 中的员工档案 1:1 绑定（Tenant Admin 例外，可不绑定）。
+2. **用户名规则统一为手机号**：
+   - Tenant Admin：**固定为该租户联系人的手机号**（11 位数字），来源于 `public.tenants.contact_phone`，全局唯一，创建后不可更改
+   - 普通员工：**固定为员工手机号**（11 位数字），同租户内唯一，创建后不可变更
+3. **初始密码强制修改**：新账号及密码重置后，`is_initial_password = True`，首次登录必须修改密码，不可跳过。
+4. **账号锁定机制**：同一账号连续密码错误 ≥ 5 次，状态置为 `locked`，30 分钟后自动恢复；Tenant Admin 可提前手动解锁。
+5. **员工离职联动**：员工离职时，对应账号的 `status` 自动置为 `disabled`，不可登录，历史操作记录保留。
+6. **不支持自助注册**：所有账号由有权限的管理角色创建，普通员工账号在新增员工时由系统自动生成。
+
+---
+
+## 二、实体关系
+
+```
+UserAccount
+    │
+    ├── 1:1 ── org.Staff       (实名绑定，普通员工必须)
+    ├── 1:N ── LoginAttempt    (登录审计记录)
+    ├── 1:N ── SmsOtpRecord      (短信验证码记录，找回密码用)
+    ├── 1:N ── PasswordHistory    (历史密码记录)
+    └── M:1 ── UserAccount.created_by (创建人自引用)
+```
+
+### Schema 归属
+
+| 表 | Schema 位置 | 说明 |
+|----|------------|------|
+| `user_accounts` | 租户 Schema | 账号数据按租户隔离，username 唯一性在 Schema 维度生效 |
+| `login_attempts` | 租户 Schema | 审计记录属于租户，跨租户不可见 |
+| `sms_otp_records` | 租户 Schema | 短信验证码记录，找回密码用 |
+| `password_histories` | 租户 Schema | 历史密码与账号绑定 |
+
+> **注意**：Tenant Code 验证相关逻辑在 **Public Schema**（`shared_apps`），使用 `django-tenants` 的 `TenantModel`，不在本文档范围内，详见 `DATA_MODEL.md` §四（公共 Schema）。
+
+---
+
+## 三、Schema 定义
+
+### 3.1 `user_accounts` — 账号主表（租户 Schema）
+
+**表说明**：系统登录主体，每个租户内独立隔离，`username` 唯一性约束在 Schema 维度生效。
+
+#### 字段定义
+
+| 字段名 | 类型 | 约束 | 默认值 | 说明 |
+|--------|------|------|--------|------|
+| `id` | `BIGSERIAL` | `PRIMARY KEY` | — | 自增主键（审计场景下 BigInt 更直观；跨环境引用使用 UUID 扩展字段见下） |
+| `username` | `VARCHAR(30)` | `NOT NULL` | — | 登录名；普通员工为手机号（11 位数字）；Tenant Admin 为自定义字符串；创建后不可更改 |
+| `password` | `VARCHAR(128)` | `NOT NULL` | — | PBKDF2+SHA256 哈希存储，使用 Django `make_password` |
+| `email` | `VARCHAR(254)` | `NULL` | `NULL` | 绑定邮箱；完全可选，在本系统无任何必须业务用途；若填写则在同租户内唯一 |
+| `phone_enc` | `TEXT` | `NULL` | `NULL` | 手机号 AES-256-GCM 加密密文（`core.encryption`）；普通员工必填 |
+| `phone_hash` | `VARCHAR(64)` | `NULL` | `NULL` | 手机号 SHA-256 哈希；用于唯一性校验和查询；不可反推原文 |
+| `staff_id` | `BIGINT` | `FK → org_staff.id`, `NULL`, `UNIQUE` | `NULL` | 员工档案绑定（1:1）；普通员工必须有值；Tenant Admin 可为空 |
+| `is_tenant_admin` | `BOOLEAN` | `NOT NULL` | `FALSE` | 是否为该租户的超级管理账号；每个租户最多 1 个（应用层约束） |
+| `status` | `VARCHAR(10)` | `NOT NULL`, `CHECK(status IN ('active','disabled','locked'))` | `'active'` | 账号状态；`locked` 为密码错误锁定，30 分钟自动恢复 |
+| `is_initial_password` | `BOOLEAN` | `NOT NULL` | `TRUE` | 初始密码标记；True 时登录成功后强制跳转修改密码页，不可跳过 |
+| `last_login` | `TIMESTAMPTZ` | `NULL` | `NULL` | 最后登录时间 |
+| `locked_until` | `TIMESTAMPTZ` | `NULL` | `NULL` | 锁定到期时间；到期后应用层将 status 恢复 active |
+| `created_at` | `TIMESTAMPTZ` | `NOT NULL` | `NOW()` | 账号创建时间 |
+| `updated_at` | `TIMESTAMPTZ` | `NOT NULL` | `NOW()` | 最后更新时间（触发器维护） |
+| `created_by` | `BIGINT` | `FK → user_accounts.id`, `NULL` | `NULL` | 创建人；普通员工由 Tenant Admin 创建；Tenant Admin 由平台运营创建（可为 NULL） |
+
+#### 唯一性约束
+
+```sql
+UNIQUE (username)             -- Schema 内唯一，跨租户不冲突（django-tenants 机制保障）
+UNIQUE (email)                -- 同租户内邮箱唯一（可为 NULL，NULL 不参与唯一性校验）
+UNIQUE (phone_hash)           -- 同租户内手机号唯一（通过 hash 实现，不暴露原文）
+UNIQUE (staff_id)             -- 员工档案 1:1 绑定
+```
+
+#### 索引
+
+```sql
+CREATE UNIQUE INDEX uq_user_accounts_username ON user_accounts (username);
+CREATE UNIQUE INDEX uq_user_accounts_email    ON user_accounts (email) WHERE email IS NOT NULL;
+CREATE UNIQUE INDEX uq_user_accounts_phone    ON user_accounts (phone_hash) WHERE phone_hash IS NOT NULL;
+CREATE INDEX        idx_user_accounts_status  ON user_accounts (status);
+CREATE INDEX        idx_user_accounts_staff   ON user_accounts (staff_id);
+```
+
+#### Django Model 定义
+
+```python
+# apps/accounts/models.py
+from django.contrib.auth.models import AbstractBaseUser, BaseUserManager
+from django.db import models
+
+
+class UserAccountManager(BaseUserManager):
+    def create_user(self, username, password, **extra_fields):
+        if not username:
+            raise ValueError("username 不能为空")
+        user = self.model(username=username, **extra_fields)
+        user.set_password(password)
+        user.save(using=self._db)
+        return user
+
+
+class UserAccount(AbstractBaseUser):
+    """
+    租户级用户账号。
+    - 普通员工：username 固定为员工手机号（11 位数字）
+    - Tenant Admin：username 固定为该租户联系人手机号（来源于 public.tenants.contact_phone）
+    注意：此表位于租户 Schema，username 唯一性约束在 Schema 维度生效。
+    """
+    username             = models.CharField(max_length=30)
+    email                = models.EmailField(null=True, blank=True)
+    phone_enc            = models.TextField(null=True, blank=True)    # AES-256-GCM 加密密文
+    phone_hash           = models.CharField(max_length=64, null=True, blank=True)  # SHA-256 哈希索引
+    staff                = models.OneToOneField(
+                               'org.Staff',
+                               null=True, blank=True,
+                               on_delete=models.SET_NULL,
+                               related_name='account',
+                           )
+    is_tenant_admin      = models.BooleanField(default=False)
+    status               = models.CharField(
+                               max_length=10,
+                               choices=[('active', 'Active'), ('disabled', 'Disabled'), ('locked', 'Locked')],
+                               default='active',
+                           )
+    is_initial_password  = models.BooleanField(default=True)
+    last_login           = models.DateTimeField(null=True, blank=True)
+    locked_until         = models.DateTimeField(null=True, blank=True)
+    created_at           = models.DateTimeField(auto_now_add=True)
+    updated_at           = models.DateTimeField(auto_now=True)
+    created_by           = models.ForeignKey(
+                               'self',
+                               null=True, blank=True,
+                               on_delete=models.SET_NULL,
+                               related_name='created_accounts',
+                           )
+
+    USERNAME_FIELD = 'username'
+    REQUIRED_FIELDS = []
+
+    objects = UserAccountManager()
+
+    class Meta:
+        db_table = 'user_accounts'
+        # Schema 内唯一约束
+        constraints = [
+            models.UniqueConstraint(fields=['username'], name='uq_user_accounts_username'),
+        ]
+
+    def __str__(self):
+        return f"{self.username} ({'admin' if self.is_tenant_admin else 'staff'})"
+
+    def is_locked(self) -> bool:
+        """检查账号是否处于锁定状态（含自动过期判断）"""
+        from django.utils import timezone
+        if self.status == 'locked':
+            if self.locked_until and timezone.now() >= self.locked_until:
+                # 锁定已到期，应用层自动恢复（实际由 service 层处理）
+                return False
+            return True
+        return False
+```
+
+---
+
+### 3.2 `login_attempts` — 登录尝试审计表（租户 Schema）
+
+**表说明**：记录每次登录请求（成功/失败），用于安全审计和锁定判断。数据保留 ≥ 90 天，不得提前清理。
+
+#### 字段定义
+
+| 字段名 | 类型 | 约束 | 默认值 | 说明 |
+|--------|------|------|--------|------|
+| `id` | `BIGSERIAL` | `NOT NULL` | — | 自增主键（与 attempted_at 组成复合 PK） |
+| `attempted_at` | `TIMESTAMPTZ` | `NOT NULL` | `NOW()` | 尝试时间（分区键，必须在复合主键中） |
+| `username` | `VARCHAR(30)` | `NOT NULL` | — | 尝试登录的用户名（冗余存储，即使账号不存在也记录） |
+| `ip_address` | `INET` | `NOT NULL` | — | 来源 IP 地址（支持 IPv4/IPv6） |
+| `user_agent` | `TEXT` | `NULL` | `NULL` | 客户端 User-Agent（Electron 版本信息） |
+| `success` | `BOOLEAN` | `NOT NULL` | — | 是否登录成功 |
+| `failure_reason` | `VARCHAR(30)` | `NULL` | `NULL` | 失败原因；可选值见下方枚举 |
+
+> ⚠️ **分区说明**：`login_attempts` 为高写入审计表，采用 `PARTITION BY RANGE (attempted_at)` 按月分区。主键为 `(id, attempted_at)` 复合主键（分区表规范：主键必须包含分区键）。
+
+**DDL**：
+```sql
+CREATE TABLE login_attempts (
+    id              BIGSERIAL NOT NULL,
+    attempted_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),   -- 分区键
+    username        VARCHAR(30) NOT NULL,
+    ip_address      INET NOT NULL,
+    user_agent      TEXT,
+    success         BOOLEAN NOT NULL,
+    failure_reason  VARCHAR(30)
+                    CHECK (failure_reason IS NULL OR failure_reason IN (
+                        'wrong_password','wrong_captcha','account_locked',
+                        'account_disabled','tenant_not_found',
+                        'wrong_otp','otp_expired'
+                    )),
+    PRIMARY KEY (id, attempted_at)                        -- 分区表主键必须包含分区键
+) PARTITION BY RANGE (attempted_at);
+
+CREATE TABLE login_attempts_2026_04 PARTITION OF login_attempts
+    FOR VALUES FROM ('2026-04-01') TO ('2026-05-01');
+CREATE TABLE login_attempts_2026_05 PARTITION OF login_attempts
+    FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');
+CREATE TABLE login_attempts_default PARTITION OF login_attempts DEFAULT;
+```
+
+**`failure_reason` 枚举值**：
+
+| 值 | 含义 |
+|----|------|
+| `wrong_password` | 用户名或密码错误 |
+| `wrong_captcha` | 行为验证码失败 |
+| `account_locked` | 账号已锁定 |
+| `account_disabled` | 账号已停用 |
+| `tenant_not_found` | 租户不存在（理论上不应出现，防御性记录） |
+| `wrong_otp` | 短信验证码错误 |
+| `otp_expired` | 短信验证码已过期 |
+
+#### 索引
+
+```sql
+CREATE INDEX idx_login_attempts_username   ON login_attempts (username);
+CREATE INDEX idx_login_attempts_ip         ON login_attempts (ip_address);
+CREATE INDEX idx_login_attempts_time       ON login_attempts (attempted_at DESC);
+-- 复合索引：按账号查询最近失败记录（锁定判断场景）
+CREATE INDEX idx_login_attempts_fail_check ON login_attempts (username, success, attempted_at DESC);
+```
+
+#### Django Model 定义
+
+```python
+class LoginAttempt(models.Model):
+    """
+    登录尝试审计记录。
+    - 合规保留周期：≥ 90 天
+    - 注意：failure_reason 不得存储密码明文（含错误密码）
+    """
+    FAILURE_REASONS = [
+        ('wrong_password',   '用户名或密码错误'),
+        ('wrong_captcha',    '行为验证码失败'),
+        ('account_locked',   '账号已锁定'),
+        ('account_disabled', '账号已停用'),
+        ('tenant_not_found', '租户不存在'),
+        ('wrong_otp',        '短信验证码错误'),
+        ('otp_expired',      '短信验证码已过期'),
+    ]
+
+    username       = models.CharField(max_length=30)
+    ip_address     = models.GenericIPAddressField()
+    user_agent     = models.TextField(null=True, blank=True)
+    success        = models.BooleanField()
+    failure_reason = models.CharField(max_length=30, null=True, blank=True, choices=FAILURE_REASONS)
+    attempted_at   = models.DateTimeField(auto_now_add=True)
+
+    class Meta:
+        db_table = 'login_attempts'
+        indexes = [
+            models.Index(fields=['username']),
+            models.Index(fields=['ip_address']),
+            models.Index(fields=['-attempted_at']),
+            models.Index(fields=['username', 'success', '-attempted_at'],
+                         name='idx_login_attempts_fail_check'),
+        ]
+
+    def __str__(self):
+        return f"{self.username} @ {self.attempted_at} - {'OK' if self.success else self.failure_reason}"
+```
+
+---
+
+### 3.3 `sms_otp_records` — 短信验证码记录表（租户 Schema）
+
+**表说明**：记录找回密码和手机验证码登录两个场景中，向用户手机号发送的短信验证码及其状态。用 `scene` 字段区分场景（`password_reset` / `login`），有效期和发送频率上限按场景独立控制。原 `password_reset_tokens`（邮件令牌）已废弃，由本表替代。
+
+#### 字段定义
+
+| 字段名 | 类型 | 约束 | 默认值 | 说明 |
+|--------|------|------|--------|------|
+| `id` | `BIGSERIAL` | `PRIMARY KEY` | — | 自增主键 |
+| `user_id` | `BIGINT` | `FK → user_accounts.id`, `NOT NULL` | — | 关联账号 |
+| `phone_hash` | `VARCHAR(64)` | `NOT NULL` | — | 收码手机号 SHA-256 哈希（与账号的 `phone_hash` 一致，冗余存储便于限频查询） |
+| `scene` | `VARCHAR(20)` | `NOT NULL` | — | 使用场景：`password_reset`（找回密码）或 `login`（验证码登录） |
+| `otp_hash` | `VARCHAR(128)` | `NOT NULL` | — | 验证码 PBKDF2 哈希（禁止明文存储，服务端校验时重新哈希比对） |
+| `expires_at` | `TIMESTAMPTZ` | `NOT NULL` | — | 过期时间（`password_reset`：`created_at + 10 分钟`；`login`：`created_at + 5 分钟`） |
+| `is_used` | `BOOLEAN` | `NOT NULL` | `FALSE` | 是否已验证通过；通过后立即置 True，防止重放攻击 |
+| `verify_attempts` | `SMALLINT` | `NOT NULL` | `0` | 已尝试验证次数；≥ 5 次后本条记录强制作废（`is_used = TRUE`） |
+| `created_at` | `TIMESTAMPTZ` | `NOT NULL` | `NOW()` | 创建时间 |
+
+#### 索引
+
+```sql
+CREATE INDEX idx_sms_otp_user      ON sms_otp_records (user_id, created_at DESC);
+CREATE INDEX idx_sms_otp_phone     ON sms_otp_records (phone_hash, created_at DESC);
+CREATE INDEX idx_sms_otp_active    ON sms_otp_records (user_id, expires_at) WHERE is_used = FALSE;
+```
+
+#### Django Model 定义
+
+```python
+class SmsOtpRecord(models.Model):
+    """
+    短信验证码记录（找回密码 + 验证码登录共用）。
+    安全约束：
+    - OTP 明文仅在发送短信时生成，不持久化；仅存 PBKDF2 哈希
+    - 单条记录验证次数 ≥ 5 次后强制作废（is_used=True）
+    - 同一手机号 1 小时内按 scene 独立限频（password_reset ≤ 5 次，login ≤ 10 次）
+    """
+    SCENE_CHOICES = [
+        ('password_reset', '找回密码'),
+        ('login',          '验证码登录'),
+    ]
+
+    user            = models.ForeignKey(UserAccount, on_delete=models.CASCADE, related_name='sms_otp_records')
+    phone_hash      = models.CharField(max_length=64)          # SHA-256 哈希，不暴露手机号原文
+    scene           = models.CharField(max_length=20, choices=SCENE_CHOICES)  # 区分场景
+    otp_hash        = models.CharField(max_length=128)         # PBKDF2 哈希，禁止明文存储
+    expires_at      = models.DateTimeField()                   # password_reset: +10min; login: +5min
+    is_used         = models.BooleanField(default=False)
+    verify_attempts = models.SmallIntegerField(default=0)
+    created_at      = models.DateTimeField(auto_now_add=True)
+
+    class Meta:
+        db_table = 'sms_otp_records'
+        indexes = [
+            models.Index(fields=['user', '-created_at']),
+            models.Index(fields=['phone_hash', '-created_at']),
+        ]
+
+    def is_valid(self) -> bool:
+        from django.utils import timezone
+        return not self.is_used and self.verify_attempts < 5 and timezone.now() < self.expires_at
+
+    def mark_used(self):
+        self.is_used = True
+        self.save(update_fields=['is_used'])
+```
+
+---
+
+### 3.4 `password_histories` — 历史密码记录表（租户 Schema）
+
+**表说明**：保存账号最近 3 次密码哈希，用于防止重复使用历史密码（含初始密码）。
+
+#### 字段定义
+
+| 字段名 | 类型 | 约束 | 默认值 | 说明 |
+|--------|------|------|--------|------|
+| `id` | `BIGSERIAL` | `PRIMARY KEY` | — | 自增主键 |
+| `user_id` | `BIGINT` | `FK → user_accounts.id`, `NOT NULL` | — | 关联账号 |
+| `password_hash` | `VARCHAR(128)` | `NOT NULL` | — | PBKDF2+SHA256 哈希值 |
+| `created_at` | `TIMESTAMPTZ` | `NOT NULL` | `NOW()` | 记录时间（密码修改时间） |
+
+#### 索引
+
+```sql
+CREATE INDEX idx_password_histories_user ON password_histories (user_id, created_at DESC);
+```
+
+#### Django Model 定义
+
+```python
+class PasswordHistory(models.Model):
+    """
+    历史密码记录，每个账号保留最近 N 条（默认 3 条）。
+    新密码不得与最近 3 条历史记录相同（含系统初始密码 Fonrey@2025）。
+    """
+    user          = models.ForeignKey(UserAccount, on_delete=models.CASCADE, related_name='password_histories')
+    password_hash = models.CharField(max_length=128)
+    created_at    = models.DateTimeField(auto_now_add=True)
+
+    class Meta:
+        db_table = 'password_histories'
+        ordering = ['-created_at']
+        indexes = [
+            models.Index(fields=['user', '-created_at']),
+        ]
+```
+
+---
+
+## 四、Redis 缓存结构（辅助状态，非持久化）
+
+以下 Redis Key 不存入 PostgreSQL，属于运行时状态，需与数据库状态保持最终一致：
+
+| Key 格式 | 类型 | TTL | 说明 |
+|----------|------|-----|------|
+| `captcha_token:{uuid}` | STRING | 3 分钟 | 滑块验证会话 Token；验证通过后生成 `captcha_pass_token` |
+| `captcha_pass:{uuid}` | STRING | 3 分钟 | 一次性通过凭证；登录提交时校验后立即删除 |
+| `login_fail:{tenant_id}:{username}` | STRING（计数） | 30 分钟 | 连续密码错误次数；≥ 5 触发锁定；TTL 30 分钟自动清零 |
+| `sms_limit:password_reset:{phone}` | STRING（计数） | 1 小时 | 找回密码场景：同一手机号短信发送次数；上限 **5 次**/小时 |
+| `sms_limit:login:{phone}` | STRING（计数） | 1 小时 | 验证码登录场景：同一手机号短信发送次数；上限 **10 次**/小时 |
+| `sms_reset_token:{token}` | STRING（user_id） | 15 分钟 | 验证码通过后颁发的一次性重置凭证；用于步骤三提交新密码；使用后立即删除 |
+| `tenant_verify_ip:{ip}` | STRING（计数） | 1 分钟 | Tenant 验证接口 IP 限流；≥ 10 次拒绝请求 |
+
+> **一致性说明**：账号锁定状态由 `user_accounts.status` 持久化，Redis 仅做计数触发器。当 Redis 数据丢失（如 Redis 重启），应用层通过 `locked_until` 字段恢复锁定状态判断。
+
+---
+
+## 五、账号创建流程与状态机
+
+### 5.1 账号状态机
+
+```
+                ┌─────────────────────────────────────┐
+                │          账号生命周期状态机              │
+                └─────────────────────────────────────┘
+
+  [创建账号]
+      │ is_initial_password=True, status=active
+      ▼
+  [初始密码态]  ─── 使用初始密码登录成功 ───►  [强制修改密码页]
+      │                                            │ 修改成功
+      │                                            ▼
+      │                                      [正常使用态]
+      │                                       status=active
+      │                                    is_initial_password=False
+      │
+      ├── 密码错误 ≥ 5 次 ──────────────────►  [锁定态]
+      │                                        status=locked
+      │                                        locked_until = now+30min
+      │                                            │
+      │                           ┌───────────────┤
+      │                           │ 30分钟到期     │ 管理员手动解锁
+      │                           ▼               ▼
+      │                         [正常使用态] ◄─── [管理员操作]
+      │
+      └── 员工离职 / 管理员停用 ──►  [停用态]
+                                      status=disabled
+                                          │
+                                    员工复职/管理员恢复
+                                          │
+                                          ▼
+                                    [正常使用态]
+```
+
+### 5.2 账号创建触发时机
+
+| 账号类型 | 触发时机 | 创建者 | username 规则 | 初始密码 |
+|----------|----------|--------|--------------|---------| 
+| Tenant Admin | 平台运营在系统后台开通租户时 | 平台运营 | **固定为该租户联系人手机号**（11 位数字，来源于 `public.tenants.contact_phone`） | **系统统一固定初始密码**（如 `Fonrey@2025`，由平台部署配置设定） |
+| 普通员工 | Tenant Admin 在「新增员工」时系统自动生成 | 系统（Tenant Admin 触发） | 固定为员工手机号（11 位） | 系统统一初始密码（部署配置） |
+
+---
+
+## 六、关联约束与数据完整性
+
+### 6.1 与 `org.Staff` 的关联规则
+
+```
+org_staff (1) ──── (0..1) user_accounts
+```
+
+- 普通员工账号：`staff_id` **必须**有值，且在 `org.Staff` 中对应记录的 `status` 为 active
+- Tenant Admin：`staff_id` **可为空**（平台运营账号可不绑定实名档案）
+- 员工离职时（`org.Staff.status` → `resigned`），触发账号 `status` → `disabled`（由 `org` App Service 层调用 `accounts` 服务执行，避免循环依赖）
+- 账号删除：**不允许物理删除**，仅允许 `status=disabled`，审计记录永久保留
+
+### 6.2 跨 App 依赖方向
+
+```
+accounts ──► org (单向依赖：accounts.UserAccount.staff_id → org.Staff)
+org ──► accounts (反向触发，通过 Service 层调用，不通过 FK 反查)
+```
+
+> **设计原则**：避免循环 FK 依赖，跨 App 的状态联动通过 Service 层的显式调用完成，不在 Model 层建立反向 FK。
+
+---
+
+## 七、迁移说明（Django Migrations）
+
+### 初始迁移顺序
+
+```
+0001_initial_user_accounts.py        # UserAccount 表（依赖 org.Staff 表已存在）
+0002_login_attempts.py               # LoginAttempt 表
+0003_sms_otp_records.py              # SmsOtpRecord 表（替代原 password_reset_tokens）
+0004_password_histories.py           # PasswordHistory 表
+```
+
+### 注意事项
+
+- `accounts` App 的迁移依赖 `org` App（`org.Staff` 表须先创建），需在 `INSTALLED_APPS` 中确保 `org` 在 `accounts` 之前
+- 所有迁移均在**租户 Schema** 下执行（`django-tenants` 的 `migrate_schemas` 命令）
+- 不得为 `email` 字段设置 `NOT NULL` 约束（允许为空，是否绑定邮箱属于用户选择）
+
+---
+
+## 八、设计决策说明（ADR）
+
+| 决策 | 选择 | 理由 |
+|------|------|------|
+| 主键类型 | `BIGSERIAL` (BigInt) | 登录审计场景下 BigInt 主键更简洁高效；跨环境引用场景少，无需 UUID 的随机性 |
+| `phone` 字段拆分为 `phone_enc` + `phone_hash` | 是 | 与 `org.Staff` 保持一致；`phone_enc` 保存原文用于展示，`phone_hash` 用于唯一性校验和快速查询，避免加密字段全表扫描 |
+| 不扩展 Django `User` | 使用 `AbstractBaseUser` | 避免 `django.contrib.auth.User` 的全局唯一性限制（多租户下同一 username 在不同租户是允许的） |
+| `LoginAttempt` 不设外键到 `UserAccount` | 是（冗余存储 username） | 即使账号被删除（停用），审计记录仍需保留；使用 username 字符串字段保证审计完整性 |
+| 找回密码机制 | 短信验证码（`SmsOtpRecord`） | 经纪人普遍无邮箱；手机号是本系统唯一已知联系方式，短信核验更直接；废弃邮件找回路径，减少外部依赖（SMTP） |
+| 历史密码单独建表 | `PasswordHistory` 独立表 | 而非在 `UserAccount` 中存 JSON 数组，便于查询和维护，支持未来扩展保留次数 |
+| 锁定到期时间持久化 | `locked_until` 字段 | Redis 可能重启丢失数据，持久化 `locked_until` 保证 Redis 故障时锁定状态不丢失 |