更新.gitignore

.gitignore

@@ -1,3 +1,4 @@
 # Godot 4+ specific ignores
 .godot/
 /android/
+/.vscode/

.vscode/settings.json

@@ -1,3 +0,0 @@
-{
-    "godotTools.editorPath.godot4": "d:\\game\\Godot\\Godot_v4.7.1-stable_win64.exe\\Godot_v4.7.1-stable_win64_console.exe"
-}

doc/P1模块拆分.md

@@ -0,0 +1,141 @@
+# P1 模块拆分
+
+P1 目标：种田 → 交货 → 灵石 → 修炼 → 更强的种田 循环跑通。本文档定义 P1 的模块划分、职责、依赖、通信方式与测试方式。详见 `doc/Roadmap.md`、`doc/弟子管理.md`。
+
+## 1. 架构原则：前后端分离
+
+- **后端**：Manager 脚本（持有数据和逻辑），不依赖 UI。
+- **前端**：UI 场景（只管显示），不持有任何游戏状态，所有数据从后端读取。
+- **通信规则**：
+  - UI → 后端：调用公开方法（如 `refine_pill()`）
+  - 后端 → UI：信号推送状态变化（如 `balance_changed`）
+- **好处**：后端可脱离 UI 单独测试；UI 可随意更换；存档只序列化 Manager 状态。
+- **不抽象过度**：Manager 脚本本身就是后端，Godot 信号就是通信机制，不引入额外 Service/Interface 层。
+
+## 2. 文件结构总览
+
+```
+src/
+├── Core/                          # 已有，不改
+│   ├── GameState.gd
+│   ├── TimeSystem.gd
+│   ├── SaveSystem.gd
+│   └── MainGame.gd               # 挂载所有 P1 管理器
+│
+├── Data/
+│   └── Models/                    # 数据模型（纯 RefCounted，无逻辑）
+│       ├── Disciple.gd           # 弟子数据（见 弟子管理.md）
+│       ├── FieldData.gd          # 灵田数据
+│       ├── PillRecipeData.gd     # 丹方数据
+│       └── OrderData.gd          # 订单数据
+│
+├── Character/
+│   ├── DiscipleManager.gd        # 弟子管理器
+│   └── test_disciple.tscn        # 独立测试场景
+│
+├── Production/
+│   ├── FieldManager.gd           # 灵田管理器
+│   ├── AlchemyManager.gd         # 炼丹管理器
+│   ├── test_field.tscn           # 灵田测试
+│   └── test_alchemy.tscn         # 炼丹测试
+│
+├── Sect/
+│   ├── InventoryManager.gd       # 库存管理（灵药/丹药/凡粮）
+│   ├── EconomyManager.gd         # 经济系统（灵石收支）
+│   ├── OrderManager.gd           # 订单管理
+│   ├── FoodManager.gd            # 口粮管理
+│   ├── test_economy.tscn         # 经济测试
+│   ├── test_order.tscn           # 订单测试
+│   └── test_food.tscn            # 口粮测试
+│
+└── UI/
+    └── HUD/
+        └── MainSceneHud.gd       # 已有，P1 加灵石显示（前端接入）
+```
+
+## 3. 模块职责与依赖
+
+| 模块 | 文件 | 职责 | 依赖 | 信号 |
+| --- | --- | --- | --- | --- |
+| 弟子数据 | `Data/Models/Disciple.gd` | 弟子属性（境界/技艺/忠诚/修为） | 无 | — |
+| 灵田数据 | `Data/Models/FieldData.gd` | 内外田、作物、生长周期、品质 | 无 | — |
+| 丹方数据 | `Data/Models/PillRecipeData.gd` | 材料→成品、技艺要求、品质系数 | 无 | — |
+| 订单数据 | `Data/Models/OrderData.gd` | 客户、物品、数量、品质要求、期限、奖励 | 无 | — |
+| 弟子管理 | `Character/DiscipleManager.gd` | CRUD + 修炼结算 | Disciple | `disciple_added/removed/attr_changed` |
+| 灵田管理 | `Production/FieldManager.gd` | 种植/生长/收获 → 库存 | FieldData, InventoryManager | `field_harvested` |
+| 炼丹管理 | `Production/AlchemyManager.gd` | 消耗材料产出丹药 | PillRecipeData, InventoryManager | `pill_refined` |
+| 库存管理 | `Sect/InventoryManager.gd` | 物品存取（灵药/丹药/凡粮） | 无 | `inventory_changed` |
+| 口粮管理 | `Sect/FoodManager.gd` | 凡人弟子口粮消耗 | DiscipleManager, InventoryManager | `food_shortage` |
+| 订单管理 | `Sect/OrderManager.gd` | 订单生成/交货/过期 | OrderData, InventoryManager, EconomyManager | `order_fulfilled/expired` |
+| 经济系统 | `Sect/EconomyManager.gd` | 灵石收支、余额 | 无 | `balance_changed` |
+
+## 4. 信号流（核心循环）
+
+```
+TimeSystem.advance_month()
+  → month_passed
+    → FieldManager.settle_month()     [灵田生长/收获入库存]
+    → DiscipleManager.settle_month()  [修炼消耗灵石、修为增长]
+    → FoodManager.settle_month()      [口粮消耗，凡人弟子数×口粮]
+    → OrderManager.settle_month()     [订单过期检查]
+    → EconomyManager.settle_month()   [香火供奉等固定收入]
+
+玩家操作：
+  FieldManager.plant_field()  → field_harvested (收获灵药) → InventoryManager
+  AlchemyManager.refine()     → pill_refined (炼丹成功)   → InventoryManager
+  OrderManager.fulfill()      → order_fulfilled (交货)    → EconomyManager 加灵石
+```
+
+- 各管理器暴露 `settle_month()`，由 MainGame 连接 `month_passed` 按顺序调用；管理器自身不依赖 TimeSystem autoload，测试时可直接调用。
+
+## 5. 依赖注入方式
+
+管理器不直接引用 autoload，通过 `setup()` 注入依赖：
+
+```gdscript
+# MainGame._ready() 中：
+economy_manager.setup()
+field_manager.setup(inventory_manager)
+alchemy_manager.setup(inventory_manager)
+food_manager.setup(disciple_manager, inventory_manager)
+order_manager.setup(inventory_manager, economy_manager)
+```
+
+好处：测试场景只需注入 Mock 依赖，模块可独立运行。
+
+## 6. 独立测试方式
+
+每个模块对应一个测试场景（`test_xxx.tscn`）：
+
+1. 实例化被测管理器 + 注入 Mock 依赖
+2. `_ready()` 中自动执行用例
+3. 用例覆盖：正常流程、边界条件（余额不足/库存不足/过期）、信号是否正确发出
+4. `print` 输出 PASS/FAIL，编辑器直接 F6 运行该场景验证
+
+## 7. 开发顺序（依赖链自底向上）
+
+| 步骤 | 模块 | 理由 |
+| --- | --- | --- |
+| 1 | 4 个数据模型（Disciple/FieldData/PillRecipeData/OrderData） | 无依赖，纯数据 |
+| 2 | InventoryManager | 无依赖，被 3 个模块使用 |
+| 3 | DiscipleManager + 测试 | 只依赖数据 |
+| 4 | FieldManager + 测试 | 依赖库存 |
+| 5 | AlchemyManager + 测试 | 依赖库存 |
+| 6 | FoodManager + 测试 | 依赖弟子+库存 |
+| 7 | OrderManager + 测试 | 依赖库存+经济 |
+| 8 | EconomyManager + 测试 | 无依赖（独立收支） |
+| 9 | MainGame 集成所有管理器 | 组装 |
+| 10 | HUD 灵石显示（前端接入） | UI 层 |
+
+每完成一步都能单独测试验证，不会出现"全做完才能跑"的情况。
+
+## 8. P1 简化决策
+
+| 完整愿景 | P1 取舍 | 后续 |
+| --- | --- | --- |
+| 忠诚度系统 | 仅存字段，不参与结算 | P2 启用 |
+| 收徒 | 不做，初始弟子固定 | P2 |
+| 随机委托 | 不做 | P2 |
+| 香火供奉 | 简化为每月固定小额收入 | P2 完整化 |
+| 灵田品质 | 收获时按种植者技艺定品质，无随机 | 可加随机 |
+| 炼丹失败 | 材料足够即成功，品质随技艺浮动 | 可加失败率 |

doc/Roadmap.md

@@ -0,0 +1,100 @@
+# 开发路线图（Roadmap）
+
+愿景与世界观见 `doc/WorldDesign.md`。本文档把愿景拆分为里程碑，开发时只看当前里程碑，不做全量实现。
+
+## 1. 开发原则
+
+1. **分层交付**：每个里程碑独立可玩、可测试，P1 完成即验证核心乐趣。
+2. **先简后繁**：复杂系统先做能跑通的最小版本，验证后再加深。
+3. **战斗自动结算**：经营游戏中战斗是结果不是过程，P4/P5 冲突用抽象战力对比自动结算，不做回合制战斗。
+4. **宗主裁决用规则表**：价值/规矩/规模/面子四变量打分，不做复杂 AI。
+5. **天灾复用现有系统**：本质是事件链 + 数值压力，复用委托/订单/忠诚系统实现。
+6. **数值先纸面后调参**：前期用表格跑平衡，UI 只做展示。
+
+## 2. 里程碑总览
+
+| 里程碑 | 内容 | 对应 WorldDesign 章节 | 工作量 | 状态 |
+| --- | --- | --- | --- | --- |
+| P0 框架 | 时间系统、存档系统、主菜单/HUD | — | — | 已完成 |
+| P1 核心循环 | 弟子 + 灵田 + 炼丹 + 灵石收支 + 基础订单 + 口粮 | 1、4、7 | ~35% | 待开发 |
+| P2 经营深度 | 忠诚/抽成、收徒、随机委托、香火 | 4、5、6 | ~15% | 规划中 |
+| P3 外交层 | 大客户名单、订单刷新、附庸三级、宗主裁决 | 3 | ~15% | 规划中 |
+| P4 秘境事件 | 勘探、发掘、走漏、冲突升级链 | 8 | ~20% | 规划中 |
+| P5 终局 | 毕业考、天灾事件链、结局结算 | 9、10 | ~15% | 规划中 |
+
+## 3. P0 框架（已完成）
+
+- 时间系统（TimeSystem）：月推进回合、turn_started / month_passed / year_passed / season_changed 信号
+- 存档系统（SaveSystem）：两级存档 + register_saver 数据注册
+- 主菜单、HUD、设置
+
+## 4. P1 核心循环（下一步）
+
+目标：种田 → 交货 → 灵石 → 修炼 → 更强的种田 循环跑通。
+
+| 模块 | 内容 | 优先级 |
+| --- | --- | --- |
+| 弟子 | 基础属性：境界、种植技艺、炼丹技艺；修炼消耗灵石提升境界 | 必须 |
+| 灵田 | 内外田：外田种凡粮（口粮），内田种灵药（经济作物）；生长周期、品质 | 必须 |
+| 炼丹 | 基础丹方：灵药材料 → 丹药成品；品质受技艺影响 | 必须 |
+| 灵石收支 | 挂 `month_passed` 月度结算：收入（订单/香火）、支出（弟子修炼消耗） | 必须 |
+| 基础订单 | 单一大客户，按季下订单，品质要求，交货结算灵石 | 必须 |
+| 口粮 | 凡人弟子每月消耗口粮，外田产量不足时入不敷出 | 必须 |
+| 忠诚度 | 仅存字段，不影响结算 | 可延后（P2 启用） |
+| 收徒 | 不做，初始弟子固定 | 可延后（P2） |
+| 随机委托 | 不做 | 可延后（P2） |
+| 香火供奉 | 可简化为每月固定小额收入，不做事件 | 可简化 |
+
+P1 完成标准：新档开局 → 种植灵药 → 炼制丹药 → 按季交货 → 收到灵石 → 弟子修炼消耗灵石 → 境界提升后产量/品质提高，循环可持续 10 年不崩盘。
+
+## 5. P2 经营深度
+
+| 模块 | 内容 |
+| --- | --- |
+| 忠诚与抽成 | 弟子抽成率可调政策；抽成过高忠诚下降，低忠诚出走 |
+| 收徒 | 弟子招募：拜师礼一次性收入；新弟子品质随机 |
+| 随机委托 | 村镇除妖、散修代炼、家族看诊，随机刷新，主动风险收入 |
+| 香火 | 完整化：与声望挂钩的低保收入 |
+| 人口压力 | 凡人弟子多 → 口粮压力显现 |
+
+## 6. P3 外交层
+
+| 模块 | 内容 |
+| --- | --- |
+| 大客户名单 | 2~3 个大宗门/商会客户，各有订单偏好与性格（待定） |
+| 订单刷新 | 按季刷新订单池，品质/数量/期限随机 |
+| 附庸三级 | 普通供货商 / 附庸 / 内附，升级条件与权利义务 |
+| 宗主裁决 | 附庸冲突裁决：四变量打分规则表（价值/规矩/规模/面子） |
+| 庇护验证 | 玩家被袭击时宗主按等级实际出兵 |
+| 站队 | 给哪家供货 = 外交立场，影响附庸升级机会 |
+
+## 7. P4 秘境事件
+
+| 模块 | 内容 |
+| --- | --- |
+| 勘探 | 主动勘探后山：消耗人手/时间，概率发现秘境 |
+| 发掘 | 禁制分层解锁；功法有修炼门槛；残缺典籍需修复 |
+| 走漏 | 泄漏概率挂钩忠诚与对外接触；可派警戒/封锁延缓 |
+| 冲突升级 | 阶段 0~4：秘密发掘 → 小规模冲突 → 邻近宗门进攻 → 大宗门试探 → 大宗门下场 |
+| 战斗 | 自动结算：双方战力对比 + 战损/消耗计算 |
+| 试探期操作 | 藏拙 / 立威 / 贿赂 / 结交 事件选项 |
+
+## 8. P5 终局
+
+| 模块 | 内容 |
+| --- | --- |
+| 毕业考 | 大宗门亲自下场：成本收益式胜利（击退数波进攻使对方评估得不偿失）；失败有条件投降 |
+| 天灾 | 首发魔道入侵：先兆 → 主力 分阶段事件链，威胁所有势力，外交关系重启 |
+| 天灾伏笔 | 秘境底层封印松动引发（主线贯穿） |
+| 结局结算 | 宗门传奇度评分 + "宗门史记"结局文本 + 自由沙盒 |
+
+## 9. 全局简化决策（防范围膨胀）
+
+| 完整愿景 | 实现取舍 | 理由 |
+| --- | --- | --- |
+| 回合制战斗 | 自动结算战力对比 | 经营游戏战斗是结果不是过程 |
+| 宗主裁决 AI | 四变量打分规则表 | 裁决本质是利益计算，规则表可表达 |
+| 天灾专属系统 | 事件链 + 复用现有系统 | 天灾 = 数值压力 + 外交重排 |
+| 多种天灾 | 先做魔道入侵一种 | 单一体验打磨深，后续追加 |
+| 一局固定时长 | 暂不定（60~100 年），数值测试后定 | 时长影响全盘平衡，不宜拍脑袋 |
+| 秘境探索玩法 | 概率 + 事件驱动，不做小游戏 | 保持经营主线，探索是节奏器 |

doc/WorldDesign.md

@@ -0,0 +1,257 @@
+# 世界观与经济设计讨论记录
+
+本文档整理游戏设计讨论的过程与结论。结论部分为已共识方向，未敲死的开放问题记录在文末"待定决策"。
+
+## 1. 宗门背景（已定稿）
+
+宗门开局就是一个小宗门，并无显赫出身。家底：
+
+- 一片灵田（种凡粮，供口粮）
+- 一片灵药园（种灵药，经济作物）
+- 一个旧丹炉
+- 初始人手：宗主 + 数名弟子，其中一人擅长种植灵药，同时会炼制基础丹药
+- 前期事件：一名落魄丹师来投，扩充炼丹产能
+
+**中期核心事件**（详见第 8 节）：玩家主动勘探后山，有概率发现上古宗门存放功法的秘境。发掘初期保密，风声走漏后冲突逐步升级，玩家须同时应付"发掘"与"防守"两条线。
+
+核心张力分两阶段：
+
+- **前期**：小作坊，能力单一（种药 + 基础炼丹），现金紧，靠订单吃饭；
+- **中期**：秘境发掘后"知识富"，但兑现需要时间——禁制分层解锁、功法有修炼门槛、典籍残缺需修复。玩家每解锁一层底蕴都应获得成就感。
+
+## 2. 市场与委托来源（无国家的世界）
+
+修仙世界没有国家，但**没有国家 ≠ 没有市场**。委托不是行政任务，而是市场交易。市场参与者：
+
+| 主体 | 委托/交易内容 | 支付方式 |
+| --- | --- | --- |
+| 大型宗门 | 收购灵药、定制丹药、外包采集/押运/除妖 | 灵石（大客户） |
+| 商会/坊市 | 收购丹药灵药、商队护卫、押镖 | 灵石 |
+| 修仙家族 | 上门炼丹、看风水、除家宅妖邪、族内子弟代培 | 灵石/资源 |
+| 凡人村镇 | 除妖驱邪、求雨治病、看护农田 | 灵石少，多以粮食/药材/子弟入宗抵偿 |
+| 散修 | 代炼一炉丹、修复法器、临时组队 | 灵石/以物易物 |
+
+核心洞见：没有国家反而强化了信誉的地位——没有警察和法院，交易全靠口碑背书。这接上了"组织信誉 = 接委托资格"的设定：宗门能接到活，是因为它是可追责、可预期的组织。
+
+## 3. 附庸关系与宗主裁决
+
+### 3.1 三级绑定模型
+
+大宗门的订单只是附庸关系的入场券，庇护才是核心。附庸关系的本质是**双向契约**：附庸交贡赋/专供/兵役，宗主给保护/司法/仲裁。
+
+| 等级 | 大宗门提供 | 宗门义务 | 本质 |
+| --- | --- | --- | --- |
+| 普通供货商 | 订单（按市价） | 按时交货 | 纯商业，无保护 |
+| 附庸 | 订单 + 庇护（被袭击时宗主介入） | 专供权、按比例上贡、情报共享 | 庇护换义务 |
+| 内附/编外堂口 | 庇护 + 功法/资源扶持 | 兵役征调、重大决策受宗主约束 | 深度绑定，近似分部 |
+
+"站队"因此有了重量：不依附 = 无保护但有自由；依附 = 有伞但受制于人。玩家可以在三个等级间进退，本身就是外交玩法。
+
+### 3.2 宗主裁决的反应阶梯
+
+大宗门的裁决**不是公正的，是利益计算的**。附庸都是它的资源，互斗 = 资源内耗 + 秩序受损，"乐见其成"只是特殊情况。
+
+```
+默许坐视 → 口头申斥 → 强制调解 → 直接介入 → 废黜吞并
+```
+
+裁决取决于四个变量：
+
+1. **谁更有价值**——一个是大丹商一个是普通农户，偏袒哪个不言而喻；
+2. **谁坏了规矩**——先动手、先越界的，宗主为维护仲裁威信必须罚，否则庇护就贬值了；
+3. **冲突规模**——小摩擦装看不见，灭门级冲突必须出手；
+4. **宗主的面子**——连附庸都管不住，等于向外界示弱。
+
+**"乐见其成"只在三种情况发生**：附庸欠贡不缴（借刀清除）；双方产品同质（死一个，剩下的更依赖宗主）；宗主想测试双方实力。大宗门嘴上永远是"口头警告"，出不出力调解才是真实态度——**言行之间的落差就是玩家要读的信息**。
+
+### 3.3 玩家策略
+
+- **成为"不可替代的附庸"**：宗门擅长灵药丹药，而丹药是修炼刚需——产量、独有丹方、品质就是玩家在宗主面前的筹码。经济实力 → 政治地位，种田炼丹的基本盘与外交连成一体。
+- **附庸冲突是武器**：挑动竞争对手互斗（借刀杀人）、读宗主心思选时机，比直接打仗便宜得多。
+- **庇护要可验证**：玩家被袭击时宗主真的出兵（数值上触发），附庸等级的选择才是真实的风险决策。
+
+## 4. 早期灵石来源（三层收入结构）
+
+弟子修炼需要灵石，但小宗门没有灵石矿。**灵石矿是中期里程碑，而非开局必需品**。早期收入分三层：
+
+| 层 | 性质 | 内容 |
+| --- | --- | --- |
+| 稳定线（主力） | 大客户订单 | 大型宗门/商会按季下单收购灵药、基础丹药，收入可预期，玩家玩的是排产与品控 |
+| 波动线（机会） | 零散委托 | 村镇除妖、散修代炼、家族看诊，随机刷新 |
+| 低保线（兜底） | 香火供奉 | 山脚村庄定期上供，数量少但稳定，保证玩家什么都不做也不破产 |
+
+**大客户订单模式的设计价值**：
+
+1. **身份清晰**——宗门核心能力 = 种植灵药 + 基础炼丹，是修仙世界的上游原料商。灵田灵药园因此有了"生产设备"的定位。
+2. **订单制**——按季交货，有品质要求（种植技艺影响），收入可规划。
+3. **权力关系**——大客户会压价、拖欠、提苛刻要求，形成"依附大客户 = 有庇护伞，但也受制于人"的张力。给哪家供货 = 站队选择，是外交维度的起点。
+4. **价值链爬升**——卖原料 → 卖基础丹药 → 卖高级丹药 → 秘境功法后自建高端线。经营核心叙事就是**在供应链里往上爬，从供应商变成品牌方**。
+
+其他早期收入：拜师礼（一次）、宗主家底（开局一小笔灵石，只够撑过前几个月，逼迫玩家尽快打开收入）。
+
+## 5. 宗门对弟子的价值（抽成的世界观基础）
+
+弟子为何交抽成？因为宗门提供散修拿不到的东西，抽成 = 学费 + 洞府租金 + 保护费 + 渠道费 的打包价：
+
+1. **功法传承**——修仙世界硬通货。完整功法几乎被宗门垄断，散修只能拿到残缺货。功法库就是宗门最大的卖点。
+2. **修炼设施**——洞府、聚灵阵、丹房、藏经阁（随宗门发展逐步解锁）。
+3. **庇护与身份**——宗门旗号是威慑力；宗门弟子有资格进坊市主街、参加交换会、报名秘境名额。
+4. **指点与护法**——师承指点突破、同门护法防走火入魔，散修突破十死无生。
+5. **资源渠道**——统一采购有渠道价，辅料内部调剂。
+
+对应修仙文学"散修最惨"的设定：散修自由但什么都没有；交抽成是"用灵石换前程"，是当时最优交易。
+
+**机制含义**：抽成率做成玩家可调政策——定低宗门没钱发展，定高弟子不满甚至出走（需要忠诚度系统支撑）。宗门经营过程 = 提升服务价值，服务越好收高抽成越合理。
+
+## 6. 小宗门早期形态
+
+开局宗门几乎没有硬件资源（无藏经阁、无丹房、无灵脉），提供的是**无形资源**：
+
+1. **宗主本人**——唯一的硬资产：一门完整功法、一身修为、随时可请教的师承指点。早期"抽成"本质是拜师费+学费。
+2. **"宗门"名头**——两人抱团即势力，挂宗门旗号下山，强盗要掂量报复代价。早期弟子最需要的是保命。
+3. **身份资格**——正式登记宗门可进坊市、报低阶秘境、接大客户订单。收入门路是宗门带来的。
+4. **宗主人脉**——旧友、故交、情报渠道，早期人脉 = 赚钱门路。
+5. **未来预期**——投奔小宗门是赌未来，相当于加入创业公司拿期权。
+
+**游戏化结论**：早期宗门是"卖人的公司"——宗主拉单（订单/委托），弟子出工出力，灵石进账后抽成。早期循环：接单赚钱 → 攒灵石建设施 → 设施提升宗门价值 → 提高收徒门槛 → 更多灵石。
+
+## 7. 前期经济线
+
+两条收入线并存：
+
+- **种田炼丹**（稳定被动收入）：灵药园种药材 + 旧丹炉炼基础丹药，按大客户订单交货。
+- **零散委托**（主动风险收入）：村镇除妖、散修代炼、家族看诊。
+
+核心玩法张力：**弟子在"修炼"与"生产"之间分配人手**——种药炼丹需要弟子专注，占用修炼时间。
+
+**灵田分级**：灵田种凡粮是浪费，分内外田——外田种凡粮（口粮），内田种灵药（收入）。凡粮半自给时，凡人弟子多则口粮压力显现，形成人口压力系统。
+
+## 8. 秘境事件设计（中期核心事件）
+
+### 8.1 触发
+
+- 玩家主动勘探后山：消耗人手与时间，有一定概率发现上古宗门存放功法的秘境
+- 世界观自洽：后山本就是自家地盘，外人进不来；秘境因封印/禁制松动才可能被勘得
+
+### 8.2 发掘节奏
+
+- 秘境禁制分层，逐层解锁
+- 功法有修炼门槛（境界/悟性），部分典籍残缺需修复
+- "知识富"的兑现过程本身就是中期玩法，避免一次性全给导致中期崩盘
+
+### 8.3 走漏与干预
+
+- 风声走漏概率与弟子忠诚、对外接触频率挂钩（由忠诚度系统支撑）
+- 玩家可派警戒、封锁消息延缓走漏，形成"抢时间窗口"的策略层
+
+### 8.4 冲突升级链
+
+冲突是循序渐进的过程，**升级由"发掘进度"驱动，而非固定时间线**——玩家挖得越深，展露的功法价值越高，引来的人就越强。玩家自己控制危机的升级速度，风险与收益始终绑定，天然自平衡。
+
+```
+阶段0  秘密发掘       风声未漏，玩家抢时间窗口
+阶段1  小规模冲突     散修、小家族：偷挖/渗透/袭扰商队，试探性攻击
+阶段2  邻近宗门进攻   有组织的围攻，真正的军事压力
+阶段3  大宗门试探     使者来访、假借收丹方、弟子切磋——明探暗察
+阶段4  大宗门亲自下场 毕业考：挺过去 = 区域强势宗门，正式进入后期
+```
+
+**阶段 1 分维度打击**而非纯战斗：偷挖（威胁秘境）、渗透（威胁情报）、袭扰商队（断经济）、围攻山门（军事），逼迫玩家防御面面俱到。
+
+**大宗门的态度演进有三重设计价值**：
+
+1. **"不屑一顾"是合理的**——大宗门有自己的完整传承体系，挖出来的基础功法和残篇对它是边角料；谣言满天飞，它要先验证价值再出手。这段"不屑期"就是给玩家消化功法、培养弟子的**缓冲期**，伪装成剧情。
+2. **"派人试探"是玩家操作空间最大的阶段**——探子来"拜访"时，玩家可以藏拙、立威、贿赂、结交，外交操作直接决定试探结果。
+3. **"亲自下场"= 毕业考**，正好卡在玩家发育到有还手之力的时候。
+
+### 8.5 毕业考（大宗门亲自下场）
+
+- **胜利条件：成本收益式**——大宗门退兵不是因为被打败，而是评估"继续付出的代价 > 抢到功法的收益"后收手。玩家击退几波进攻、消耗对手实力、展示宗门战力，让大宗门觉得不值。符合经营游戏逻辑，也避免"小宗门硬吃掉大宗门"的战力膨胀。
+- **失败状态：有条件投降**——战败不死，可选择交出秘境控制权、成为大宗门附庸、割让部分收获，保留翻盘机会。
+
+### 8.6 后遗症
+
+- 打退大宗门后：名声大涨（招募吸引力提升）+ 结怨（外交隐患），正式成为区域强势宗门
+- 为后期更大势力的觊觎与天灾埋线
+
+## 9. 游戏阶段与时间轴
+
+借鉴群星"一局固定时长"的结构：固定时长让每局都有完整弧线，时间成为真正的资源，截止线制造戏剧张力。本游戏已有月推进回合制，事件挂时间轴做平衡容易。
+
+| 阶段 | 时间点 | 事件 | 主轴 |
+| --- | --- | --- | --- |
+| 前期 | 第 1 年起 | 种田炼丹、大客户订单、附庸关系 | 经济 |
+| 中期 | 条件触发（勘探发现） | 秘境发掘、小规模冲突 | 秘密与防御 |
+| 中后期 | 随发掘进度升级 | 邻近宗门围攻、大宗门试探 | 外交与战争 |
+| 后期门槛 | 条件触发 | 大宗门亲自下场（毕业考） | 生存 |
+| 后期 | 毕业考通过后 | 区域强势宗门 | 版图与博弈 |
+| 终局 | 固定年份 + 条件 | 天灾爆发（见第 10 节） | 守护 |
+| 收尾 | 天灾解决后 | 结局结算 + 自由沙盒 | 历史定位 |
+
+- **一局时长暂不定**（群星 300 年对 4X 合适；经营游戏倾向 60~100 年即 720~1200 回合，待数值测试后定）
+- **结算系统**：局末结算**宗门传奇度**——实力、版图、声望、善举综合评分，生成"宗门史记"结局文本。玩家追求的是更好的结局，而不是无限玩下去。结算后进入自由沙盒，可继续经营。
+- **循环闭环**：后期玩家自己成为"宗主"，面对当年大宗门面对过的选择——对附庸冲突是公正裁决还是利益至上？玩家早年对大宗门的怨念，成为后期统治哲学的第一块试金石。
+
+## 10. 终局天灾
+
+### 10.1 借鉴群星天灾系统
+
+1. **天灾威胁所有人，不止玩家**——终局危机爆发后全区域势力都要应对，昔日宿敌被迫合作。把后期"对抗"重构为"生存"。
+2. **强度挂钩实力**——天灾强度随玩家进程变化，始终有威胁性但可存活。
+3. **分阶段爆发**——先兆/初潮（零散入侵）→ 主力入侵，给玩家反应时间。
+4. **危机也是机遇**——趁火打劫、坐收渔利，天灾中依然有策略选择。
+
+### 10.2 类型与实现顺序
+
+**先做一种（魔道大举入侵），后续版本追加**：
+
+| 天灾 | 原型 | 威胁维度 | 玩家角色 |
+| --- | --- | --- | --- |
+| 魔道大举入侵（首发） | 虫群/恶魔 | 军事 + 掠夺 | 抵抗军领袖 |
+| 上古巨凶解封 | 机械天灾觉醒 | 军事 + 地盘沦陷 | 守土者 |
+| 灵气异变/兽潮 | 灵能危机 | 经济 + 生存（灵田枯死、走火入魔潮） | 救济者 |
+| 上界势力插手 | 堕落帝国觉醒 | 外交 + 站队（投靠/抵抗） | 周旋者 |
+
+### 10.3 天灾来源（秘境埋伏笔）
+
+天灾由秘境剧情埋下伏笔：上古宗门当年为什么把功法封存起来？答案是——**它在封印某个东西**。玩家一路发掘，最后发现秘境底层是封印，自己的发掘正在松动它。
+
+由此主线贯穿到底：种田起家 → 发掘遗产 → 引来觊觎 → 觉醒封印 → 天灾降临。前期每一层剧情都为终局服务。
+
+### 10.4 天灾对后期玩法的重构
+
+1. **外交关系重启**——天灾爆发后，此前所有"站队/结怨/附庸"的选择集体结算：帮过你的人来结盟，结过怨的宗门或抵抗或投敌。天灾是对玩家整个前期行为的终极检验。
+2. **角色转型**——玩家从"竞争者"变成"一方守土者/抵抗领袖"，后期目标从扩张变成守护。
+3. **危机即机遇**——投敌或灭门的宗门留下势力真空供吞并；做"救世主"刷爆声望，做"渔翁"闷声发大财。
+4. **收尾**——挺过天灾 = 结局结算（守护一方、重建秩序的历史定位）+ 自由沙盒。
+
+## 11. 待定决策（讨论过程记录，未敲死）
+
+### 11.1 旧版背景（备选方案，已被替代）
+
+远古超大型宗门因经营不善没落，仅剩一名宗主与数名弟子，传承了大量功法，保留灵药园、灵田、丹炉，"知识富、现金穷"。后被"小宗门 + 秘境发掘"方案取代。
+
+原因：旧版需要额外解释两件事——
+
+- **资产为何没被抢走**（原候选：A. 宗主实力背书——资产品质低劣、大宗门看不上；B. 位置偏僻——旧址从未被发现；C. 护山大阵残余——只防蟊贼，为后期修阵留伏笔）
+- **没落原因**（原候选：A. 大劫——大战/内乱/天灾；B. 经营不善——需另补解释资产未被蚕食；C. 两者结合）
+
+新背景通过"秘境封存无人知晓"直接消除了资产保全漏洞，且天然提供中期事件结构。
+
+### 11.2 "卖功法换快钱"道德决策点
+
+宗门穷到揭不开锅时（秘境发掘后尤其相关），卖功法换钱该不该做？候选：
+
+- **A. 纳入**：作为事件，短期获利但损失底蕴、声望、弟子忠诚，提供戏剧性选择。
+- **B. 不纳入**：功法库仅作招聘卖点与抽成底气，不做卖功法选项。
+
+### 11.3 其他待讨论项
+
+- 一局时长（暂不定，待数值测试）
+- 天灾后续类型（首发魔道入侵，其余按优先级追加）
+- 大宗门数量与性格（各具裁决风格）
+- 附庸等级升降机制（降级是否有惩罚期）
+- 秘境勘探的具体概率/人手消耗数值
+- 落魄丹师的入宗条件与剧情
+- 大客户（供货对象）的初始名单与站队影响
+- 毕业考难度平衡（成本收益式的具体数值）

doc/弟子管理.md

@@ -0,0 +1,85 @@
+# 弟子管理模块设计
+
+模块位置：P1 核心循环（见 `doc/Roadmap.md`）。本文档描述弟子数据模型与弟子管理器的设计。
+
+## 1. 结构：数据类 + 管理器
+
+弟子模块拆分为两层：
+
+| 层 | 文件 | 类型 | 职责 |
+| --- | --- | --- | --- |
+| 弟子数据类 | `src/Data/Models/Disciple.gd` | RefCounted | 持有弟子的所有信息，纯数据，无逻辑 |
+| 弟子管理器 | `src/Character/DiscipleManager.gd` | Node | 添加、删除、查询、修改弟子属性 + 领域操作（修炼结算） |
+
+## 2. 设计模式
+
+| 角色 | 模式 | 说明 |
+| --- | --- | --- |
+| 弟子数据类 | 纯数据模型 | RefCounted，运行时可变数据，不依赖场景树，可脱离场景单测 |
+| 弟子管理器 | 仓储模式（Repository） | CRUD + 查询的集中入口，是弟子数据的唯一管理者 |
+| 变化通知 | 观察者模式（Observer） | 管理器发信号，UI/其他系统订阅实时刷新 |
+| 弟子创建 | 工厂方法（Factory） | 初始弟子/收徒的创建逻辑收在管理器内 |
+
+**明确不用的方案**：
+
+- 不用 ECS：弟子属性固定（境界/技艺/忠诚…），无动态组件需求，是过度设计。
+- 不用 Resource/.tres：弟子是运行时可变数据，RefCounted 类最轻量，不走序列化资源。
+- 不把所有逻辑塞进数据类：领域操作归管理器，保证修改只有单一入口，信号好通知，测试好做。
+
+## 3. Disciple 数据类（RefCounted，纯数据）
+
+```gdscript
+var name: String
+var is_mortal: bool               # 凡人弟子
+var realm_level: int = 1          # 境界 1-9
+var cultivation_skill: int = 1    # 种植技艺 1-10
+var alchemy_skill: int = 1        # 炼丹技艺 1-10
+var loyalty: int = 50             # 忠诚 0-100（P1 仅存字段）
+var cultivation_exp: int = 0      # 修为进度
+```
+
+只读派生（不存储，由属性计算）：
+
+- `monthly_cost() -> int`：每月修炼灵石消耗（凡人弟子为 0）
+- `realm_name() -> String`：境界显示名（凡人 / 炼气X层…）
+- `exp_to_next() -> int`：升到下一境界所需修为
+
+## 4. DiscipleManager 管理器（Node，仓储）
+
+```gdscript
+signal disciple_added(disciple)
+signal disciple_removed(disciple)
+signal disciple_attr_changed(disciple, attr_name, old_value, new_value)
+
+func add_disciple(d) -> void
+func remove_disciple(d) -> void
+func get_disciple(id) -> Disciple
+func get_all() -> Array[Disciple]
+func get_by_realm(level) -> Array[Disciple]
+func count_mortals() -> int
+func set_attr(d, attr, value) -> void   # 修改唯一入口，内部发信号
+func settle_month() -> void             # 修炼结算（领域操作）
+func to_dict() -> Dictionary            # 存档网关
+func load_from_dict(d) -> void
+```
+
+## 5. 关键设计决策
+
+1. **修改只走管理器**——`set_attr()` 是唯一变更入口，内部统一发 `disciple_attr_changed`。UI 订阅它实时刷新，也为以后忠诚度/事件系统留监听点。
+2. **查询返回引用**——性能好（P1 规模无碍），但禁止外部直接写属性；要写必须走管理器。
+3. **管理器是 Node，数据类是 RefCounted**——管理器可挂 MainGame/测试场景；数据类脱离场景树也能单测。
+4. **领域操作在管理器**——`settle_month()`（修炼消耗灵石、增加修为、境界提升）归管理器，数据类不碰业务逻辑。
+5. **存档网关（Unit of Work）**——序列化/恢复只经过管理器 `to_dict()/load_from_dict()`，为 SaveSystem 注册预留。
+
+## 6. 测试方式
+
+独立测试场景 `src/Character/test_disciple.tscn`：
+
+1. 实例化 DiscipleManager（不依赖其他模块）
+2. `_ready()` 中自动执行用例：
+   - 添加/删除弟子 → 信号是否正确发出
+   - 查询（get_by_realm / count_mortals）
+   - `set_attr` → 信号带旧值/新值
+   - `settle_month` → 境界提升/灵石消耗正确
+   - `to_dict / load_from_dict` 往返一致
+3. `print` 输出 PASS/FAIL，编辑器直接运行场景验证

src/UI/Panels/SavePannel.gd

@@ -46,7 +46,6 @@ func refresh_groups() -> void:
 		item.group_selected.connect(_on_group_selected)
 		item.delete_requested.connect(_on_group_delete_requested)
 		group_container.add_child(item)
-		print(group['id'])
 	# 校验当前选中组：已被删除则复位并清空右列
 	if _current_profile == 0 or _current_profile not in _get_profile_ids():
 		_current_profile = 0
@@ -70,8 +69,6 @@ func refresh_slots(profile_id: int) -> void:
 		item.load_requested.connect(_on_slot_load_requested)
 		item.delete_requested.connect(_on_slot_delete_requested)
 		slot_list.add_child(item)
-		print("--->");
-	print("---------------------->");
 		
 
 func _on_group_selected(profile_id: int) -> void: