docs: 更新 agent 规则并新增项目约束文档

.agents/skills/ulthon-rules-manager/SKILL.md

@@ -27,6 +27,21 @@ Rules 可包含以下类型的内容：
 
 **灰色地带处理**：部分内容混合了规则和操作（如 Base/App 架构文档既有铁律又有场景指南），此时保留为 Skill，因为其核心价值在"指导如何操作"。
 
+## PROJECT.md 与子规则的关系
+
+`PROJECT.md` 是项目规则的**精简入口**，只包含两部分：
+
+1. 一段项目概述（服务于谁、解决什么问题、核心能力）——智能体理解业务语境的起点
+2. `project-*` 规则索引（导航到具体业务规则）
+
+稳定的业务约束和模式决策**拆分到 `project-*` 子规则文件**，不在 PROJECT.md 中展开。易变的状态描述（模块清单、依赖列表、技术栈等）**不记录为规则**，让智能体从代码/配置中读取——强行记录只会导致规则与代码脱节。
+
+**必备子规则**：`project-dev-runtime-deploy.md`（记录本项目实际采用的开发/运行/部署模式）。每个项目都应有此文件，因为智能体需要知道"这个项目怎么跑"才能正确执行命令、调试、部署。该文件为**开放式骨架**——不限于框架预设的 stack，WAMP、宝塔、Docker、源码直传等任何实际模式都如实记录。
+
+**可选子规则**：`project-business-constraints.md`（记录不可协商的业务硬约束，如数据一致性、安全强制、合规要求）。仅当项目有此类铁律时才创建。
+
+**模式子规则的灵活性**：默认合并为一个 `project-dev-runtime-deploy.md`（三章节：开发方式 / 运行方式 / 部署方式）。若某一方面内容过于复杂（如部署涉及多套流程、多环境差异），可拆分为独立子规则（如 `project-deploy-detail.md`），并在原文件中引用指向。
+
 ## 目录结构
 
 ```
@@ -84,9 +99,15 @@ Rules 可包含以下类型的内容：
 - 开发过程中发现了可复用的约定，值得记录
 - 用户明确要求"记录这条规则"/"这个模块有约束"
 
+**判断标准——什么适合做规则**：
+- ✅ 适合：稳定的约束、约定、设计决策（选定后很少变化，代码中无直接对应）
+- ❌ 不适合：易变的状态描述（模块清单、依赖列表、技术栈清单等）——这些在代码/配置中已有，智能体需要时自行读取，强行记录只会导致规则与代码脱节
+
 不满足条件时：
 - 如果是全局性规则 → 记录到 `AGENTS.md`（需框架作者身份确认）
-- 如果是项目业务概述 → 记录到 `.agents/PROJECT.md`
+- 如果是项目整体定位 → 记录到 `.agents/PROJECT.md` 的「项目概述」段落（保持精简）
+- 如果是易变的状态描述（模块清单、依赖列表等）→ **不记录为规则**，让智能体从代码/配置中读取
+- 如果是稳定的业务硬约束或模式决策 → 创建 `project-*` 子规则文件，并在 PROJECT.md 的索引中登记
 
 ### 2. 确定命名与来源