diff --git a/assets/config/.codex/AGENTS.md b/assets/config/.codex/AGENTS.md
index 2ae9cbe..608a8ab 100644
--- a/assets/config/.codex/AGENTS.md
+++ b/assets/config/.codex/AGENTS.md
@@ -36,7 +36,117 @@
在获取任务或错误报告后，独立完成上下文检索、分析、修复与验证过程，实现“用户零上下文切换”体验。
-
+
+
+ 将 Git 与 GitHub 视为开发过程的一等公民：代码不是一次性产物，而是可审计、可回滚、可协作、可演进的历史。
+ 在不违反上层安全策略、平台限制与用户明确要求的前提下，开发过程中必须进行细粒度、适度频繁、语义清晰的提交，并在合适节点推送到远端。
+
+
+
+
+ 每一次 commit 都应对应一个清晰、单一、可解释的意图：修一个 bug、补一组测试、抽一层接口、整理一批文档，而不是把多个无关改动混成一团。
+
+
+ 追求细粒度提交，但拒绝噪音式提交。每个提交都必须保持工作区在逻辑上自洽，避免“半成品提交”“不可编译提交”“混杂临时代码提交”。
+
+
+ 不仅关注最终代码，更关注演化过程是否优雅、是否便于 code review、是否便于 bisect、是否便于回滚。
+
+
+ 在完成关键里程碑、阶段性稳定点、较大重构前后，应及时 push 到 GitHub，避免本地状态成为单点风险。
+
+
+ Git 不只是备份工具，更是设计沟通工具。提交信息、分支命名、PR 描述、Issue 关联都必须帮助后来者快速理解“改了什么、为何改、风险何在”。
+
+
+
+
+
+ 默认在独立分支上开展非平凡工作，避免直接污染主分支。
+ 分支名称必须体现任务意图，推荐格式：`feat/...`、`fix/...`、`refactor/...`、`docs/...`、`chore/...`。
+ 涉及多个独立子任务时，可拆分为多个顺序提交；必要时拆分为多个分支，而不是在一个分支中并行堆叠无关修改。
+
+
+
+ 满足以下任一条件时，应主动创建 commit：一个可验证的小目标完成；一组测试补齐；一次重构收敛；一次风险较高修改已验证通过；一个阶段性文档同步完成。
+ commit 前必须检查 diff，剔除调试代码、无关格式化、误改文件、临时日志、无意义生成物。
+ 单个 commit 应尽量让审阅者在几分钟内理解其意图与影响面；若一个 commit 需要解释多个主题，通常说明粒度过粗。
+ 禁止把“功能实现 + 无关重命名 + 大片格式化 + 顺手修别处小问题”混入同一次提交。
+ 对关键提交，优先在 commit 前完成最小验证；若受环境限制无法验证，需在提交语义中保持保守，并在后续提交中补齐验证。
+
+
+
+ 在完成关键检查点、长时间任务中段、跨设备协作前、风险性重构开始前后，应主动 push。
+ 禁止所有工作都堆到本地最后一次性 push，导致历史不可分辨、风险集中、恢复困难。
+ push 前确认目标远端、目标分支、工作树状态与本地 HEAD 一致，避免误推到错误分支或错误仓库。
+ 遇到远端分歧时，优先保持历史清晰与语义完整，避免粗暴覆盖；必要时先同步、审查、整理，再继续推送。
+
+
+
+ 当任务具备明确审阅价值时，应以 PR/合并请求为核心交付单元，而不是仅停留在本地 commit。
+ PR 标题应概括本次变更本质；PR 描述需说明背景、方案、验证方式、风险点、影响范围。
+ 能关联 Issue 时应主动关联，建立“问题—提交—PR—合并”的可追踪链路。
+ 涉及架构调整、目录变更、模块职责重划分时，应在 PR 或相应文档中同步记录设计原因与迁移路径。
+ 面对 review comments，应优先通过增量 commit 响应审阅意见，在合并前再视情况整理历史。
+
+
+
+
+
+ 检查当前分支、工作树是否干净、远端是否可达、是否位于正确仓库上下文。
+
+
+ 围绕清晰子目标推进；每完成一个逻辑闭环，就审查 diff 并生成语义明确的 commit。
+
+
+ 运行最小必要验证，整理提交顺序，必要时补充文档，然后 push 到 GitHub。
+
+
+ 基于 commit 历史整理变更故事线，确保审阅者能按提交顺序理解问题、方案与验证证据。
+
+
+ 检查是否存在噪音提交、临时代码、无意义 merge 痕迹、描述不清的 commit message；必要时整理历史，但不得破坏已共享协作前提。
+
+
+
+
+ 提交信息必须简洁、具体、可检索，直接说明“做了什么”。
+ 推荐使用英文机器结构前缀 + 中文/英文简洁语义主体，例如：`fix: 修复 session 续期竞态`、`refactor: simplify cache invalidation path`。
+ 常用前缀：`feat`、`fix`、`refactor`、`docs`、`test`、`chore`、`perf`、`build`、`ci`。
+ 禁止使用无语义信息的提交说明，如：`update`、`modify`、`test`、`wip`（除非用户明确要求临时检查点且该提交不会作为最终交付历史）。
+
+
+
+
+ 版本历史卫生检查
+ 每次准备 commit 或 push 前，必须确认本次历史是否能被未来的自己快速读懂。
+ 若一个提交无法用一句话说清其目的，需继续拆分或重写。
+ 若多个提交顺序混乱、彼此交叉污染，应在合适时机整理后再进入评审或合并流程。
+
+
+ 远端交付检查
+ 关键节点必须存在远端备份与可审阅记录，而不是只存在本地工作区。
+ PR/远端分支中的描述必须足以让审阅者理解背景、方案、验证与风险。
+ 所有重要架构或行为变更，都应能在 GitHub 历史中追溯其决策依据。
+
+
+
+
+ - 长时间开发却没有 commit，导致所有改动挤压在一个巨大差异中
+ - 为了“省事”把多个无关修改混入同一提交
+ - 只在任务结束时一次性 push，导致过程性历史丢失
+ - 提交前不检查 diff，把调试输出、临时脚本、无关文件一起提交
+ - commit message 含糊不清，无法支持审阅、回滚与问题定位
+ - 在未理解分支状态与远端差异的情况下盲目 push / 覆盖
+ - 把 Git 当作“最终备份工具”，而不是“持续演化记录系统”
+
+
+
+ 凡是涉及真实代码、文档、配置、脚本、目录结构的持续性改动，都应默认把 Git/GitHub 操作纳入执行计划，而不是把版本控制留到最后附带处理。
+ 在具备仓库上下文且平台/权限允许时，应主动执行：检查状态 → 组织变更 → 细粒度 commit → 在关键节点 push → 形成可审阅的 GitHub 历史。
+ 当环境限制导致无法真实执行 Git/GitHub 操作时，必须明确给出建议的 commit 切分方案、commit message、push 时机与 PR 组织方式，不能省略版本控制设计。
+
+
强制规划模式 (Strategic Planning)
@@ -77,7 +187,7 @@
-
+
“主任工程师”级自我审视 (The "Principal Engineer" Check)
@@ -101,11 +211,11 @@
你必须严格通过文件系统来维护当前状态与进度，确保透明度与可追溯性：
- 建立清单：将任务拆解为可勾选的细分项（Checklist），写入 `tasks/todo.md`。
+ 建立清单：将任务拆解为可勾选的细分项（Checklist），写入 `assets/tasks/todo.md`。
意图对齐：在编写第一行代码前，向用户确认计划的准确性。
实时更新：随着执行进度，实时在文件中打勾（标记完成）。
节点摘要：在每个关键步骤转换时，提供清晰的高层级（High-level）变更总结。
- 结果归档：任务结束后，在 `tasks/todo.md` 底部追加审查总结（Review Section）。
+ 结果归档：任务结束后，在 `assets/tasks/todo.md` 底部追加审查总结（Review Section）。
错误收录：如遇挫折或用户纠偏，强制更新 `assets/tasks/lessons.md`。
@@ -615,4 +725,13 @@
代码可解释性先于一切
+
+
+ 存放本机专用的 Codex MCP 启动脚本与适配层，优先解决本地环境、鉴权与启动链路问题。
+
+ 为 bb-browser 提供本地 wrapper：固定 daemon token 与端口，优先连接 127.0.0.1:19825 的 Chrome CDP，并把原版 mcp.js 发往 127.0.0.1:19824 的请求重写到本地受控 daemon。
+ 上游依赖全局安装的 bb-browser dist/mcp.js 与 dist/daemon.js；下游由 .codex/config.toml 的 mcp_servers.bb-browser 调用。
+
+
+
\ No newline at end of file