mirror of
https://github.com/GeWuYou/GFramework.git
synced 2026-05-08 09:34:30 +08:00
Merge pull request #333 from GeWuYou/refactor/single-context-priority
docs(ai-plan): 归档 single-context-priority 主题
This commit is contained in:
gewuyou
GitHub
commit
2c58d8b69e
@ -12,10 +12,6 @@ help the current worktree land on the right recovery documents without scanning
|
||||
|
||||
## Active Topics
|
||||
|
||||
- `ai-plan-governance`
|
||||
- Purpose: govern the `ai-plan/` directory model, startup index, and archive policy.
|
||||
- Tracking: `ai-plan/public/ai-plan-governance/todos/ai-plan-governance-tracking.md`
|
||||
- Trace: `ai-plan/public/ai-plan-governance/traces/ai-plan-governance-trace.md`
|
||||
- `ai-first-config-system`
|
||||
- Purpose: continue the AI-First config runtime, generator, and consumer DX work for `GFramework.Game`.
|
||||
- Tracking: `ai-plan/public/ai-first-config-system/todos/ai-first-config-system-tracking.md`
|
||||
@ -38,14 +34,6 @@ help the current worktree land on the right recovery documents without scanning
|
||||
- Purpose: continue the data repository persistence hardening plus the settings / serialization follow-up backlog.
|
||||
- Tracking: `ai-plan/public/data-repository-persistence/todos/data-repository-persistence-tracking.md`
|
||||
- Trace: `ai-plan/public/data-repository-persistence/traces/data-repository-persistence-trace.md`
|
||||
- `microsoft-di-container-disposal`
|
||||
- Purpose: track `PR #330` disposal-contract fixes for `MicrosoftDiContainer`, related benchmark cleanup hardening, and review follow-up.
|
||||
- Tracking: `ai-plan/public/microsoft-di-container-disposal/todos/microsoft-di-container-disposal-tracking.md`
|
||||
- Trace: `ai-plan/public/microsoft-di-container-disposal/traces/microsoft-di-container-disposal-trace.md`
|
||||
- `single-context-priority`
|
||||
- Purpose: converge `GameContext` toward a single active architecture context model and tighten related `MicrosoftDiContainer` pre-freeze lookup semantics.
|
||||
- Tracking: `ai-plan/public/single-context-priority/todos/single-context-priority-tracking.md`
|
||||
- Trace: `ai-plan/public/single-context-priority/traces/single-context-priority-trace.md`
|
||||
|
||||
## Worktree To Active Topic Map
|
||||
|
||||
@ -66,7 +54,3 @@ help the current worktree land on the right recovery documents without scanning
|
||||
- Branch: `docs/sdk-update-documentation`
|
||||
- Worktree hint: `GFramework-update-documentation`
|
||||
- Priority 1: `documentation-full-coverage-governance`
|
||||
- Branch: `fix/microsoft-di-container-disposal`
|
||||
- Priority 1: `microsoft-di-container-disposal`
|
||||
- Branch: `refactor/single-context-priority`
|
||||
- Priority 1: `single-context-priority`
|
||||
|
||||
@ -1,82 +0,0 @@
|
||||
# AI-Plan 治理跟踪
|
||||
|
||||
## 目标
|
||||
|
||||
继续收口 `ai-plan/` 的目录语义、启动入口与归档策略，避免多 worktree 并行时的公共恢复文档持续膨胀并拖慢
|
||||
`boot` 的上下文定位。
|
||||
|
||||
- 为 `ai-plan/` 建立明确的目录分层
|
||||
- 区分“可提交共享状态”与“工作树私有状态”
|
||||
- 明确禁止写入敏感数据、绝对路径和机器本地信息
|
||||
- 让 `AGENTS.md`、`ai-plan/README.md` 与 boot skill 使用同一套目录语义
|
||||
- 让 `boot` 能通过公共索引快速定位当前 worktree 的活跃主题
|
||||
- 为阶段完成和主题完成两类归档建立稳定规则
|
||||
|
||||
## 当前恢复点
|
||||
|
||||
- 恢复点编号：`AI-PLAN-GOV-RP-004`
|
||||
- 当前阶段：`Phase 2`
|
||||
- 当前焦点：
|
||||
- 已将共享恢复文档按主题迁移到 `ai-plan/public/<topic>/todos/` 与 `ai-plan/public/<topic>/traces/`
|
||||
- 已为 `boot` 新增 `ai-plan/public/README.md` 公共索引，并绑定当前 worktree 的活跃主题顺序
|
||||
- 已将完成度更高的 `cqrs-cache-docs-hardening` 移入 `ai-plan/public/archive/`
|
||||
- 已同步更新 `.gitignore`、`AGENTS.md`、`ai-plan/README.md`、根 `README.md` 与 `gframework-boot`
|
||||
- 已明确主题内归档与主题级归档的双层规则，避免活动区无限增长
|
||||
- 已将当前 `feat/ai-first-config` worktree 下遗留的 `local-plan/` 收口到新的公共主题目录，并补齐索引映射
|
||||
|
||||
## 已完成
|
||||
|
||||
- `.gitignore` 现允许 `ai-plan/public/**/*.md` 以主题目录与归档目录形式进入版本控制
|
||||
- `AGENTS.md` 已补充：
|
||||
- `public/README.md`、活动主题目录、主题内归档与主题级归档的职责划分
|
||||
- `boot` 默认忽略 `ai-plan/public/archive/**`
|
||||
- worktree 与活跃主题映射变化时，必须同步更新公共索引
|
||||
- `.codex/skills/gframework-boot/SKILL.md` 与其 `references/startup-artifacts.md` 已切换到：
|
||||
- 优先读取 `ai-plan/public/README.md`
|
||||
- 命中映射后优先读取对应主题目录
|
||||
- 未命中映射时再扫描活动主题目录，并排除公共归档区
|
||||
- `ai-plan/README.md` 已补充主题命名、归档触发条件与 `boot` 读取顺序
|
||||
- 根 `README.md` 已改为要求维护公共索引与对应主题目录
|
||||
- 现有共享文档已迁移为：
|
||||
- `ai-plan/public/ai-plan-governance/**`
|
||||
- `ai-plan/public/ai-first-config-system/**`
|
||||
- `ai-plan/public/cqrs-rewrite/**`
|
||||
- `ai-plan/public/archive/cqrs-cache-docs-hardening/**`
|
||||
- 已根据 PR #253 的最新未解决 review thread 清理 `ai-plan/public/ai-plan-governance/traces/ai-plan-governance-trace.md`
|
||||
中重复的 `### 验证` / `### 下一步` 标题，并补充恢复点后缀以消除 MD024 锚点冲突
|
||||
- 已将当前 `feat/ai-first-config` worktree 的 `local-plan/` 文档迁移到 `ai-plan/public/ai-first-config-system/`
|
||||
- 已在 `ai-plan/public/README.md` 为 `feat/ai-first-config` 登记 `ai-first-config-system` 活跃主题映射
|
||||
- 已清洗迁移文档中的 `local-plan` 旧路径、绝对文件系统路径与仅适用于本机的 Git worktree 命令细节
|
||||
|
||||
## 验证
|
||||
|
||||
- `find ai-plan/public -maxdepth 4 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：活动主题、公共索引与归档主题已按新目录语义落位
|
||||
- `rg -n "ai-plan/public/README.md|ai-plan/public/<topic>|ai-plan/public/archive|ai-plan/private/" AGENTS.md .codex/skills/gframework-boot/SKILL.md .codex/skills/gframework-boot/references/startup-artifacts.md ai-plan/README.md README.md .gitignore`
|
||||
- 结果：通过
|
||||
- 备注：新目录语义、索引入口与归档规则已统一到仓库规则与 boot skill
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release --no-restore`
|
||||
- 结果：通过
|
||||
- 备注：本轮规则与文档调整未引入构建问题
|
||||
- `rg -n "^### (验证|下一步)" ai-plan/public/ai-plan-governance/traces/ai-plan-governance-trace.md`
|
||||
- 结果：通过
|
||||
- 备注：同名标题已按恢复点后缀唯一化，不再产生重复锚点
|
||||
- `rg -n "local-plan|D:\\\\|/mnt/|GIT_DIR=" ai-plan/public/ai-first-config-system`
|
||||
- 结果：通过
|
||||
- 备注：迁移后的公共主题文档未保留旧目录入口或机器本地路径
|
||||
- `find ai-plan/public/ai-first-config-system -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：当前 worktree 的 tracking / next / trace 已按主题目录落位
|
||||
- `test ! -e local-plan`
|
||||
- 结果：通过
|
||||
- 备注：旧 worktree 根目录入口已删除，不再与新的公共主题目录并存
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release -p:RestoreFallbackFolders=`
|
||||
- 结果：通过
|
||||
- 备注：默认 `--no-restore` 构建仍会命中旧的宿主 Windows NuGet fallback 配置，本轮通过显式清空 `RestoreFallbackFolders` 完成最小构建验证
|
||||
|
||||
## 下一步
|
||||
|
||||
1. 后续再发现 legacy `local-plan/` 或平铺恢复文档时，先迁入对应 `ai-plan/public/<topic>/`，再补 `public/README.md` 映射
|
||||
2. 阶段完成后优先收入主题内 `archive/`；主题整体完成后，再整目录移入 `ai-plan/public/archive/`
|
||||
3. 若未来再新增 skill 或仓库规则引用 `ai-plan/`，统一按“公共索引 + 活动主题 + 归档主题 + 私有目录”扩展，不再恢复平铺结构
|
||||
@ -1,84 +0,0 @@
|
||||
# AI-Plan 治理追踪
|
||||
|
||||
## 2026-04-19
|
||||
|
||||
### 阶段：遗留 local-plan 收口（RP-004）
|
||||
|
||||
- 建立 `AI-PLAN-GOV-RP-004` 恢复点
|
||||
- 发现当前 worktree `feat/ai-first-config` 仍保留旧 `local-plan/`，说明主题化 `ai-plan/public/<topic>/` 落地后还有遗留入口未收口
|
||||
- 已据此完成本轮治理补齐：
|
||||
- 新增 `ai-plan/public/ai-first-config-system/` 主题目录，并迁入 tracking / next / trace 文档
|
||||
- 在 `ai-plan/public/README.md` 为 `feat/ai-first-config` 绑定 `ai-first-config-system`
|
||||
- 将迁移后的公共文档中的 `local-plan` 旧路径引用更新为新的 `ai-plan/public/...` 路径
|
||||
- 将绝对路径、宿主 NuGet fallback 目录和 `GIT_DIR` / `GIT_WORK_TREE` 命令细节改写为可提交的公共表述
|
||||
|
||||
### 验证（RP-004）
|
||||
|
||||
- `find ai-plan/public/ai-first-config-system -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- `rg -n "local-plan|D:\\\\|/mnt/|GIT_DIR=" ai-plan/public/ai-first-config-system`
|
||||
- 结果：通过
|
||||
- `test ! -e local-plan`
|
||||
- 结果：通过
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release -p:RestoreFallbackFolders=`
|
||||
- 结果：通过
|
||||
|
||||
### 下一步（RP-004）
|
||||
|
||||
1. 后续若发现其他 worktree 仍有旧恢复文档，沿用“主题目录迁移 + 索引登记 + 公共内容清洗”同一流程处理
|
||||
2. 若某个主题后续再分阶段沉淀恢复文档，优先收入该主题自己的 `archive/`，避免活动入口再次膨胀
|
||||
|
||||
### 阶段：目录语义收口（RP-002）
|
||||
|
||||
- 建立 `AI-PLAN-GOV-RP-002` 恢复点
|
||||
- 用户指出当前 `ai-plan/` 存在三个治理问题：
|
||||
- 缺少更细的目录分层，容易随着 worktree 增长持续膨胀
|
||||
- 缺少“不得写入敏感数据、真实路径、机器信息”的明确约束
|
||||
- 目录语义没有区分共享恢复信息与 worktree 私有状态
|
||||
- 已据此完成以下收口：
|
||||
- 将既有共享 tracking / trace 文件迁移到扁平的 `ai-plan/public/` 共享目录
|
||||
- 新增 `ai-plan/private/` 作为工作树私有恢复空间，并通过 `.gitignore` 保持未跟踪
|
||||
- 新增 `ai-plan/README.md` 作为目录语义与内容规范的单点说明
|
||||
- 在 `AGENTS.md` 中补齐 public/private 职责边界，以及敏感信息与绝对路径禁写规则
|
||||
- 在 `gframework-boot` 中同步新的读取顺序：优先 public，按需读取当前 worktree 私有目录
|
||||
|
||||
### 验证（RP-002）
|
||||
|
||||
- `find ai-plan -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- `rg -n "ai-plan/public/|ai-plan/private/" AGENTS.md .codex/skills/gframework-boot/SKILL.md .codex/skills/gframework-boot/references/startup-artifacts.md ai-plan/README.md .gitignore`
|
||||
- 结果：通过
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release`
|
||||
- 结果：通过
|
||||
|
||||
### 下一步（RP-002）
|
||||
|
||||
1. 后续若出现新的 worktree 私有恢复需求，直接在 `ai-plan/private/<branch-or-worktree>/` 下创建，不再向共享目录追加本地临时状态
|
||||
2. 若将来需要进一步限制格式，可再为 `public/**` 与 `private/` 各自补一个模板文件，但本轮先把目录语义和安全边界固定下来
|
||||
|
||||
### 阶段：主题分组与启动索引（RP-003）
|
||||
|
||||
- 建立 `AI-PLAN-GOV-RP-003` 恢复点
|
||||
- 用户进一步指出：即使 public/private 已分层，只要多 worktree 并行，扁平的活动主题集合仍会让 `boot` 随着
|
||||
`ai-plan/public` 增长而退化成大范围扫描
|
||||
- 已据此完成第二轮治理：
|
||||
- 将活动共享文档迁移到 `ai-plan/public/<topic>/todos/` 与 `ai-plan/public/<topic>/traces/`
|
||||
- 新增 `ai-plan/public/README.md` 作为公共启动索引，维护 worktree 到多个活跃主题的映射与优先顺序
|
||||
- 将已完成的 `cqrs-cache-docs-hardening` 整体移入 `ai-plan/public/archive/cqrs-cache-docs-hardening/`
|
||||
- 在 `AGENTS.md`、`ai-plan/README.md`、根 `README.md` 与 `gframework-boot` 中统一“公共索引 + 活动主题 +
|
||||
主题内归档 + 主题级归档”的语义
|
||||
- 将 `.gitignore` 调整为允许 `ai-plan/public/**/*.md` 以新层级进入版本控制
|
||||
|
||||
### 验证（RP-003）
|
||||
|
||||
- `find ai-plan/public -maxdepth 4 -type f | sort`
|
||||
- 结果：通过
|
||||
- `rg -n "ai-plan/public/README.md|ai-plan/public/<topic>|ai-plan/public/archive|ai-plan/private/" AGENTS.md .codex/skills/gframework-boot/SKILL.md .codex/skills/gframework-boot/references/startup-artifacts.md ai-plan/README.md README.md .gitignore`
|
||||
- 结果：通过
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release --no-restore`
|
||||
- 结果：通过
|
||||
|
||||
### 下一步（RP-003）
|
||||
|
||||
1. 未来每次新增或关闭主题，都同步更新 `ai-plan/public/README.md`，不要让 `boot` 回到全量扫描模式
|
||||
2. 若某个活跃主题内部继续积累阶段性完成物，优先收入该主题目录下的 `archive/`
|
||||
@ -1,108 +0,0 @@
|
||||
# AI-Plan 治理跟踪
|
||||
|
||||
## 目标
|
||||
|
||||
继续收口 `ai-plan/` 的目录语义、启动入口与归档策略，避免多 worktree 并行时的公共恢复文档持续膨胀并拖慢
|
||||
`boot` 的上下文定位。
|
||||
|
||||
- 为 `ai-plan/` 建立明确的目录分层
|
||||
- 区分“可提交共享状态”与“工作树私有状态”
|
||||
- 明确禁止写入敏感数据、绝对路径和机器本地信息
|
||||
- 让 `AGENTS.md`、`ai-plan/README.md` 与 boot skill 使用同一套目录语义
|
||||
- 让 `boot` 能通过公共索引快速定位当前 worktree 的活跃主题
|
||||
- 为阶段完成和主题完成两类归档建立稳定规则
|
||||
|
||||
## 当前恢复点
|
||||
|
||||
- 恢复点编号：`AI-PLAN-GOV-RP-005`
|
||||
- 当前阶段：`Phase 3`
|
||||
- 当前焦点：
|
||||
- 继续扫描其他 worktree 是否仍有遗留的 `local-plan` 或其他平铺 durable recovery 目录
|
||||
- 保持 active `todos/` / `traces/` 只保留当前恢复点、活跃事实、活跃风险、下一步与 archive 指针
|
||||
- 确保 `ai-plan/public/README.md` 与各 topic active 文档对 worktree 映射、恢复点和下一步的描述保持同步
|
||||
|
||||
### 已知风险
|
||||
|
||||
- 归档遗漏：已完成且已验证的阶段未及时归档，导致 active 入口文件持续膨胀
|
||||
- 缓解措施：只要某个 active 主题积累了多个已完成且已验证阶段，就在同一变更里将其细节迁入该主题自己的 `archive/`
|
||||
- 入口回膨胀：后续新任务直接追加到 active 入口，而不是先归档历史
|
||||
- 缓解措施：每次变更前先检查当前 active 入口行数，超过合理范围时优先归档已完成内容
|
||||
- 跨文档语义漂移：tracking / trace / README 三个入口对同一主题的状态描述不一致
|
||||
- 缓解措施：修改任一文档时同步检查其他入口，确保恢复点编号、阶段名称和下一步描述保持一致
|
||||
|
||||
## 已完成
|
||||
|
||||
- 已为活跃主题建立并使用主题内归档目录：
|
||||
- `ai-plan/public/ai-plan-governance/archive/todos/`
|
||||
- `ai-plan/public/ai-plan-governance/archive/traces/`
|
||||
- `ai-plan/public/ai-first-config-system/archive/todos/`
|
||||
- `ai-plan/public/ai-first-config-system/archive/traces/`
|
||||
- `ai-plan/public/cqrs-rewrite/archive/todos/`
|
||||
- `ai-plan/public/cqrs-rewrite/archive/traces/`
|
||||
- 已将以下历史内容移出默认 boot 路径：
|
||||
- `ai-plan-governance` 的 RP-002 至 RP-004 历史
|
||||
- `ai-first-config-system` 截至 `2026-04-17` 的详细跟踪与执行 trace
|
||||
- `cqrs-rewrite` 截至 `RP-043` 的详细跟踪与执行 trace
|
||||
- 已将当前工作树遗留的 analyzer warning reduction 恢复文档从 `local-plan/` 迁入：
|
||||
- `ai-plan/public/analyzer-warning-reduction/todos/`
|
||||
- `ai-plan/public/analyzer-warning-reduction/traces/`
|
||||
- `ai-plan/public/analyzer-warning-reduction/archive/todos/`
|
||||
- `ai-plan/public/analyzer-warning-reduction/archive/traces/`
|
||||
- 已将当前工作树遗留的 documentation governance and refresh 恢复文档从 `local-plan/` 迁入：
|
||||
- `ai-plan/public/documentation-governance-and-refresh/todos/`
|
||||
- `ai-plan/public/documentation-governance-and-refresh/traces/`
|
||||
- `ai-plan/public/documentation-governance-and-refresh/archive/todos/`
|
||||
- `ai-plan/public/documentation-governance-and-refresh/archive/traces/`
|
||||
- 已将当前工作树遗留的 coroutine early-plan 恢复文档从 `local-plan/` 迁入：
|
||||
- `ai-plan/public/coroutine-optimization/todos/`
|
||||
- `ai-plan/public/coroutine-optimization/traces/`
|
||||
- `ai-plan/public/coroutine-optimization/archive/todos/`
|
||||
- `ai-plan/public/coroutine-optimization/archive/traces/`
|
||||
- 已将当前工作树遗留的 settings / persistence / serialization 混合恢复文档从 `local-plan/` 迁入：
|
||||
- `ai-plan/public/data-repository-persistence/todos/`
|
||||
- `ai-plan/public/data-repository-persistence/traces/`
|
||||
- `ai-plan/public/data-repository-persistence/archive/todos/`
|
||||
- `ai-plan/public/data-repository-persistence/archive/traces/`
|
||||
- 已同步更新 `ai-plan/public/README.md`，将分支 `fix/analyzer-warning-reduction-batch` 映射到新 topic
|
||||
- 已同步更新 `ai-plan/public/README.md`，将分支 `docs/sdk-update-documentation` 映射到
|
||||
`documentation-governance-and-refresh`
|
||||
- 已同步更新 `ai-plan/public/README.md`，将分支 `feat/coroutine-optimization` 映射到
|
||||
`coroutine-optimization`
|
||||
- 已同步更新 `ai-plan/public/README.md`，将分支 `feat/data-repository-persistence` 映射到
|
||||
`data-repository-persistence`
|
||||
- 已同步更新 `AGENTS.md`、`ai-plan/README.md` 与 `gframework-boot`，明确 active 文档不是追加式日志，已完成且已验证阶段必须归档
|
||||
|
||||
## 验证
|
||||
|
||||
- `find ai-plan/public -maxdepth 5 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：活跃主题、主题内归档文件与主题级归档都已按新目录语义落位
|
||||
- `find ai-plan/public/analyzer-warning-reduction -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：新 topic 已按 `todos/`、`traces/` 与主题内 `archive/` 目录语义落位
|
||||
- `find ai-plan/public/documentation-governance-and-refresh -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：文档治理 topic 已按 `todos/`、`traces/` 与主题内 `archive/` 目录语义落位
|
||||
- `find ai-plan/public/coroutine-optimization -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：更早期、只有 todo 没有 trace 的 coroutine 计划也已按治理规则补齐 active 入口与 archive
|
||||
- `find ai-plan/public/data-repository-persistence -maxdepth 3 -type f | sort`
|
||||
- 结果：通过
|
||||
- 备注：只有单文件且混合承担 todo / trace 的 legacy `local-plan` 也已按治理规则拆分为 active 入口与主题内 archive
|
||||
- `test ! -e local-plan`
|
||||
- 结果：通过
|
||||
- 备注：当前工作树根目录已不再保留 legacy `local-plan/`
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release -p:RestoreFallbackFolders=`
|
||||
- 结果：通过
|
||||
- 备注：`GFramework.Cqrs.Abstractions` 与 `GFramework.Core.Abstractions` 构建通过，`0 warning / 0 error`
|
||||
|
||||
## Archive Index
|
||||
|
||||
- 治理历史跟踪归档：[ai-plan-governance-history-rp002-rp004.md](../archive/todos/ai-plan-governance-history-rp002-rp004.md)
|
||||
- 治理历史 trace 归档：[ai-plan-governance-history-rp002-rp004.md](../archive/traces/ai-plan-governance-history-rp002-rp004.md)
|
||||
|
||||
## 下一步
|
||||
|
||||
1. 继续扫描是否还有遗留的 `local-plan` 或其他非 `ai-plan` 的 durable recovery 文档目录，尤其关注单文件混合 tracking/trace 或只有 todo 没有 trace 的更早期计划
|
||||
2. 后续只要某个 active 主题积累了多个已完成且已验证阶段，就在同一变更里将其细节迁入该主题自己的 `archive/`
|
||||
3. 若某个主题整体完成，再将整个主题目录移入 `ai-plan/public/archive/<topic>/`
|
||||
@ -1,119 +0,0 @@
|
||||
# AI-Plan 治理追踪
|
||||
|
||||
## 2026-04-19
|
||||
|
||||
### 阶段：active 入口归档收口（RP-005）
|
||||
|
||||
- 建立 `AI-PLAN-GOV-RP-005` 恢复点
|
||||
- 复核现有活跃主题后确认：虽然治理规则已提到主题内 `archive/`，但 active `todos/` / `traces/` 仍在持续堆积已完成历史
|
||||
- 已据此完成本轮收口：
|
||||
- 为三个活跃主题补齐并实际使用 `archive/todos/` 与 `archive/traces/`
|
||||
- 将 `ai-first-config-system` 与 `cqrs-rewrite` 的已完成阶段详细历史迁入主题内归档
|
||||
- 将治理主题自身的 RP-002 至 RP-004 历史迁入归档，只保留当前治理入口
|
||||
- 同步更新 `AGENTS.md`、`ai-plan/README.md` 与 `gframework-boot`，明确 active 文档必须保持精简
|
||||
|
||||
### Archive Context
|
||||
|
||||
- 主题治理历史归档：
|
||||
- `ai-plan/public/ai-plan-governance/archive/todos/ai-plan-governance-history-rp002-rp004.md`
|
||||
- `ai-plan/public/ai-plan-governance/archive/traces/ai-plan-governance-history-rp002-rp004.md`
|
||||
- AI-First Config 历史归档：
|
||||
- `ai-plan/public/ai-first-config-system/archive/todos/ai-first-config-system-history-through-2026-04-17.md`
|
||||
- `ai-plan/public/ai-first-config-system/archive/traces/ai-first-config-system-history-through-2026-04-17.md`
|
||||
- CQRS 历史归档：
|
||||
- `ai-plan/public/cqrs-rewrite/archive/todos/cqrs-rewrite-history-through-rp043.md`
|
||||
- `ai-plan/public/cqrs-rewrite/archive/traces/cqrs-rewrite-history-through-rp043.md`
|
||||
|
||||
### 下一步 — 归档收口
|
||||
|
||||
1. 未来若 active 入口再次因为已完成阶段累积而膨胀，直接按同一模式归档，不再保留为追加式历史日志
|
||||
2. 后续新增 topic 时，默认同步创建 `todos/`、`traces/` 与 `archive/` 目录
|
||||
|
||||
### 阶段：遗留 local-plan 迁移验证（RP-005）
|
||||
|
||||
- 复核当前工作树后确认，仍存在未纳入 `ai-plan/` 的遗留恢复目录 `local-plan/`
|
||||
- 将 `local-plan` 中属于 analyzer warning reduction 主题的 tracking / trace 拆分迁入：
|
||||
- `ai-plan/public/analyzer-warning-reduction/todos/`
|
||||
- `ai-plan/public/analyzer-warning-reduction/traces/`
|
||||
- `ai-plan/public/analyzer-warning-reduction/archive/todos/`
|
||||
- `ai-plan/public/analyzer-warning-reduction/archive/traces/`
|
||||
- 为新 topic 补齐 active 入口与 archive 历史，并更新 `ai-plan/public/README.md` 的 active topics 与 worktree 映射
|
||||
- 删除旧 `local-plan` 文件，验证治理规则不仅适用于现有 topic，也适用于从 worktree 遗留目录迁入的新 topic
|
||||
- 额外完成验证：
|
||||
- `find ai-plan/public/analyzer-warning-reduction -maxdepth 3 -type f | sort`
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release -p:RestoreFallbackFolders=`
|
||||
|
||||
### 下一步 — analyzer-warning-reduction 迁移
|
||||
|
||||
1. 后续若再发现 `local-plan` 一类目录，直接按 topic 归属迁入 `ai-plan/public/<topic>/`
|
||||
2. 保持新 topic 的 active 入口精简，避免把迁移动作变成简单目录平移
|
||||
|
||||
### 阶段：文档治理 local-plan 迁移验证（RP-005）
|
||||
|
||||
- 再次复核当前工作树后确认：遗留的 `local-plan/` 内容属于 documentation governance and refresh 主题
|
||||
- 按同一治理规则建立 `ai-plan/public/documentation-governance-and-refresh/`，并补齐：
|
||||
- `todos/`
|
||||
- `traces/`
|
||||
- `archive/todos/`
|
||||
- `archive/traces/`
|
||||
- 将旧 `local-plan` 中详细的文档治理 todo / trace 收入主题内归档，只保留精简版 active 入口
|
||||
- 在 `ai-plan/public/README.md` 中建立
|
||||
`docs/sdk-update-documentation` -> `documentation-governance-and-refresh` 的 worktree 映射
|
||||
- 删除旧 `local-plan` 文件，验证当前工作树已无 legacy 根目录恢复入口
|
||||
- 额外完成验证：
|
||||
- `find ai-plan/public/documentation-governance-and-refresh -maxdepth 3 -type f | sort`
|
||||
- `test ! -e local-plan`
|
||||
|
||||
### 下一步 — 文档治理迁移
|
||||
|
||||
1. 后续若其他 worktree 仍存在 `local-plan` 一类目录，继续按 topic 归属迁入对应 `ai-plan/public/<topic>/`
|
||||
2. 继续保持 topic active 入口精简，避免把迁移后的公共目录重新写成追加式日志
|
||||
|
||||
### 阶段：coroutine early-plan local-plan 迁移验证（RP-005）
|
||||
|
||||
- 复核当前工作树后确认：遗留的 `local-plan/` 内容属于 coroutine 主题，但它比前两次迁移更早，只保留了 `5` 份 todo，
|
||||
没有任何独立 trace
|
||||
- 按同一治理规则建立 `ai-plan/public/coroutine-optimization/`，并补齐：
|
||||
- `todos/`
|
||||
- `traces/`
|
||||
- `archive/todos/`
|
||||
- `archive/traces/`
|
||||
- 将旧 `local-plan` 中分散的五个阶段计划整合进主题内历史跟踪归档，并额外补写一份基于 todo 基线整理出的历史 trace，
|
||||
显式记录"缺少原始 trace，只能恢复稳定结论"的边界
|
||||
- 新建精简版 active tracking / trace 入口，只保留当前恢复点、活跃事实、风险与下一步
|
||||
- 在 `ai-plan/public/README.md` 中建立
|
||||
`feat/coroutine-optimization` -> `coroutine-optimization` 的 worktree 映射，并把 `ai-plan-governance` 作为 secondary topic 保留
|
||||
- 删除旧 `local-plan` 目录，验证当前工作树根目录已不再保留 legacy 私有恢复入口
|
||||
- 额外完成验证：
|
||||
- `find ai-plan/public/coroutine-optimization -maxdepth 3 -type f | sort`
|
||||
- `test ! -e local-plan`
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release -p:RestoreFallbackFolders=`
|
||||
|
||||
### 下一步 — coroutine 早期计划迁移
|
||||
|
||||
1. 后续若再遇到"只有 todo、没有 trace"的更早期计划，继续按同一模式迁入 topic archive，并明确标注推导边界
|
||||
2. 保持新 topic 的 active 入口精简，不把补写 trace 变成伪造逐日执行日志
|
||||
|
||||
### 阶段：单文件 local-plan 迁移验证（RP-005）
|
||||
|
||||
- 复核当前工作树后确认：遗留的 `local-plan/` 只剩一份
|
||||
`settings-persistence-serialization-tracking.md`，它同时承担 todo 与 trace 角色，不符合当前 `ai-plan` 目录语义
|
||||
- 按同一治理规则建立 `ai-plan/public/data-repository-persistence/`，并补齐：
|
||||
- `todos/`
|
||||
- `traces/`
|
||||
- `archive/todos/`
|
||||
- `archive/traces/`
|
||||
- 将旧混合文件拆分为主题内历史跟踪归档与基于同一材料整理的历史 trace，显式保留“原始材料并非独立 trace”的边界
|
||||
- 新建精简版 active tracking / trace 入口，只保留当前恢复点、活跃事实、风险与下一步
|
||||
- 在 `ai-plan/public/README.md` 中建立
|
||||
`feat/data-repository-persistence` -> `data-repository-persistence` 的 worktree 映射
|
||||
- 删除旧 `local-plan` 目录，验证当前工作树根目录已不再保留 legacy 私有恢复入口
|
||||
- 额外完成验证：
|
||||
- `find ai-plan/public/data-repository-persistence -maxdepth 3 -type f | sort`
|
||||
- `test ! -e local-plan`
|
||||
- `dotnet build GFramework.Core.Abstractions/GFramework.Core.Abstractions.csproj -c Release -p:RestoreFallbackFolders=`
|
||||
|
||||
### 下一步 — 单文件计划迁移
|
||||
|
||||
1. 后续若再遇到“单文件同时承担 tracking / trace”的更早期计划，继续按同一模式迁入 topic archive，并显式标注来源边界
|
||||
2. 保持新 topic 的 active 入口精简，避免把拆分后的公共目录重新写回旧式混合日志
|
||||
@ -1,54 +0,0 @@
|
||||
# Microsoft DI Container Disposal 跟踪
|
||||
|
||||
## 目标
|
||||
|
||||
围绕 `PR #330` 收敛 `MicrosoftDiContainer` 的释放契约、并发释放竞态，以及 `GFramework.Cqrs.Benchmarks` 的宿主清理鲁棒性。
|
||||
|
||||
## 当前恢复点
|
||||
|
||||
- 恢复点编号：`MICROSOFT-DI-DISPOSAL-RP-001`
|
||||
- 当前阶段：`Phase 1`
|
||||
- 当前 PR 锚点：`PR #330`
|
||||
- 当前结论：
|
||||
- `$gframework-pr-review` 已确认 latest-head review 仍存在 5 条 open AI thread，其中 `IIocContainer` 文档契约、`MicrosoftDiContainer.Clear()` 的不可达释放逻辑、`Dispose()` 并发竞态，以及 benchmark `Cleanup()` 缺乏异常隔离均已在本地补齐
|
||||
- `CodeRabbit` 关于 `GFramework.Cqrs.Benchmarks` 的 cleanup 问题虽然标在单个文件上，但同类模式实际覆盖 `RequestBenchmarks`、`NotificationBenchmarks`、`RequestPipelineBenchmarks`、`RequestStartupBenchmarks`、`StreamingBenchmarks`、`RequestInvokerBenchmarks`、`StreamInvokerBenchmarks`，当前已通过共享 helper 一次性收敛
|
||||
- `MicrosoftDiContainer.Dispose()` 现会先对外发布 `_disposed` 状态并释放写锁，让等待线程统一抛出容器级 `ObjectDisposedException`；随后仅在锁静默后才销毁底层 `ReaderWriterLockSlim`
|
||||
- 针对剩余的 `greptile` P1，本轮进一步将底层锁销毁收敛为单次执行，避免两个并发 `Dispose()` 调用都进入 `DisposeLockWhenQuiescent()` 时触发双重 `ReaderWriterLockSlim.Dispose()`
|
||||
|
||||
## 当前活跃事实
|
||||
|
||||
- 当前分支：`fix/microsoft-di-container-disposal`
|
||||
- 当前分支对应 `PR #330`，状态为 `OPEN`
|
||||
- 已决定的最小修复面：
|
||||
- `GFramework.Core.Abstractions/Ioc/IIocContainer.cs`
|
||||
- `GFramework.Core/Ioc/MicrosoftDiContainer.cs`
|
||||
- `GFramework.Core.Tests/Ioc/IocContainerLifetimeTests.cs`
|
||||
- `GFramework.Core.Tests/Ioc/MicrosoftDiContainerTests.cs`
|
||||
- `GFramework.Cqrs.Benchmarks/Messaging/*.cs` 的 7 个 benchmark cleanup
|
||||
|
||||
## 当前风险
|
||||
|
||||
- 若极端情况下存在长时间不退出的遗留 waiter，`DisposeLockWhenQuiescent()` 会在有限自旋后跳过底层锁销毁并记录警告，以优先保证 `Dispose()` 不被无限阻塞
|
||||
- 并发释放回归测试依赖对内部 `_lock` 的反射访问，需要保持断言目标明确，避免把实现细节暴露成对外契约
|
||||
|
||||
## 最近权威验证
|
||||
|
||||
- `python3 .agents/skills/gframework-pr-review/scripts/fetch_current_pr_review.py --json-output /tmp/gframework-current-pr-review.json`
|
||||
- 结果：通过
|
||||
- 备注：确认当前分支对应 `PR #330`，open AI review 重点已收敛到释放契约、并发竞态和 benchmark cleanup
|
||||
- `python3 scripts/license-header.py --check`
|
||||
- 结果：通过
|
||||
- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~IocContainerLifetimeTests|FullyQualifiedName~MicrosoftDiContainerTests"`
|
||||
- 结果：通过，`57/57` passed
|
||||
- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release`
|
||||
- 结果：通过，`0 warning / 0 error`
|
||||
|
||||
## 待补最新验证
|
||||
|
||||
- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~IocContainerLifetimeTests"`
|
||||
- `dotnet build GFramework.Core/GFramework.Core.csproj -c Release`
|
||||
|
||||
## 下一推荐步骤
|
||||
|
||||
1. 运行 `IocContainerLifetimeTests` 与 `GFramework.Core` Release build，确认单次锁销毁修复没有引入新的 warning 或回归
|
||||
2. 再次运行 `$gframework-pr-review` 或检查生成的 JSON，确认当前 latest-head open threads 是否只剩待推送的 GitHub 状态差异
|
||||
@ -1,40 +0,0 @@
|
||||
# Microsoft DI Container Disposal 追踪
|
||||
|
||||
## 2026-05-06
|
||||
|
||||
### 阶段：PR #330 review triage 与修复面收敛（MICROSOFT-DI-DISPOSAL-RP-001）
|
||||
|
||||
- 使用 `$gframework-pr-review` 抓取当前分支对应的 `PR #330` latest-head review 后，主线程确认仍有效的 open AI 反馈集中在四类：
|
||||
- `IIocContainer` 缺少显式的释放生命周期文档
|
||||
- `MicrosoftDiContainer.Clear()` 在 `_frozen == false` 路径下仍保留不可达的 `_provider.Dispose()` 调用
|
||||
- `MicrosoftDiContainer.Dispose()` 会让等待中的读写线程泄露 `ReaderWriterLockSlim` 的 `ObjectDisposedException`
|
||||
- 多个 `GFramework.Cqrs.Benchmarks` cleanup 顺序释放资源但缺乏异常隔离，前一个 `Dispose()` 失败会阻断后续资源回收
|
||||
- 本轮决策：
|
||||
- 先补 `ai-plan/public/microsoft-di-container-disposal` 的 tracking / trace，保证该跨模块 PR follow-up 有明确恢复入口
|
||||
- 通过 `EnterReadLockOrThrowDisposed` / `EnterWriteLockOrThrowDisposed` 收口 `MicrosoftDiContainer` 的等待中竞态，而不是零散修补个别 API
|
||||
- 通过共享 `BenchmarkCleanupHelper` 一次性收敛 benchmark 宿主 cleanup 的同类风险
|
||||
- 实现补充：
|
||||
- `IIocContainer` 现已补充释放契约文档，明确 `Dispose()` 幂等性、根 `IServiceProvider` 与同步资源归属，以及释放后的统一异常语义
|
||||
- `MicrosoftDiContainer.Clear()` 已移除未冻结路径下不可达的 `_provider.Dispose()` 调用
|
||||
- `MicrosoftDiContainer.Dispose()` 现先发布 `_disposed`，再等待遗留 waiter 退场后释放底层锁；若锁在有限自旋内未静默，则记录 warning 并跳过锁销毁，避免 `Dispose()` 无限阻塞
|
||||
- `GFramework.Cqrs.Benchmarks` 新增 `BenchmarkCleanupHelper`，并统一接入 7 个 `GlobalCleanup` 入口
|
||||
- 回归验证：
|
||||
- `Dispose_Should_Translate_Waiting_Readers_To_Container_ObjectDisposedException`
|
||||
- `Dispose_Should_Be_Idempotent_When_Called_Concurrently`
|
||||
- `dotnet test GFramework.Core.Tests/GFramework.Core.Tests.csproj -c Release --filter "FullyQualifiedName~IocContainerLifetimeTests|FullyQualifiedName~MicrosoftDiContainerTests"` 通过，`57/57` passed
|
||||
- `dotnet build GFramework.Cqrs.Benchmarks/GFramework.Cqrs.Benchmarks.csproj -c Release` 通过，`0 warning / 0 error`
|
||||
|
||||
### 当前下一步
|
||||
|
||||
1. 推送当前分支后重新运行 `$gframework-pr-review`，确认 latest-head open threads 是否已与本地修复对齐
|
||||
|
||||
### 阶段：收敛剩余并发 Dispose 双重锁销毁竞态（MICROSOFT-DI-DISPOSAL-RP-001）
|
||||
|
||||
- 根据用户补充的 `greptile` P1，重新核对 `MicrosoftDiContainer.Dispose()` 的尾部流程后确认还存在一个更窄的窗口：
|
||||
- 线程 A 与线程 B 都可能通过最外层 `_disposed` 快速路径
|
||||
- 线程 A 完成主释放并退出写锁后，线程 B 仍可能拿到写锁、因为 `_disposed == true` 直接返回，但 `finally` 仍会调用 `DisposeLockWhenQuiescent()`
|
||||
- 这样两个线程都可能执行 `_lock.Dispose()`；第二次调用会抛出 `ObjectDisposedException`
|
||||
- 本轮修复决策：
|
||||
- 在 `DisposeLockWhenQuiescent()` 入口增加 `Interlocked.CompareExchange` 守卫，把底层锁销毁流程收敛为单次执行
|
||||
- 保持现有“先发布 `_disposed`、再等待 waiter 退场”的语义不变，只修复重复销毁底层锁的尾部竞态
|
||||
- 在 `IocContainerLifetimeTests` 增加更直接的回归断言，验证并发 `Dispose()` 后锁销毁启动标记只会变为 `1`
|
||||
Loading…
x
Reference in New Issue
Block a user