From f32560e2f1b2046f968e30def0919a7fe6bdeccd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=A2=81=E8=96=84=E4=BA=91?= Date: Thu, 6 Aug 2026 20:56:59 +0800 Subject: [PATCH] docs: record EM full-direction phase 01 handoff --- .../phase-01.md | 127 +++++++----------- 1 file changed, 46 insertions(+), 81 deletions(-) diff --git a/docs/superpowers/handoffs/em-full-direction-visualization/phase-01.md b/docs/superpowers/handoffs/em-full-direction-visualization/phase-01.md index 24364a3..ad23e9f 100644 --- a/docs/superpowers/handoffs/em-full-direction-visualization/phase-01.md +++ b/docs/superpowers/handoffs/em-full-direction-visualization/phase-01.md @@ -2,118 +2,83 @@ ## 状态 -阻塞。 +完成（此前阻塞的构造调用传播已获用户明确授权扩展范围）。 -## 执行环境与入口 +## 环境、入口与前置核验 -- 执行时间：2026-08-06T19:59:49.4938469+08:00（Windows / PowerShell，.NET 10.0.302 SDK）。 -- 仓库：`D:\Users\Desktop\项目\prakrobot\ParkingRobot` -- 入口分支：`trajplanner` -- 入口 HEAD：`57ea36b8595c621783aba844e18d9969bccea378`（`docs: plan staged EM full-direction execution`）。 -- 暂存区入口时为空，且在本交接创建前仍为空。 +- 执行时间：2026-08-06T20:56:08.7268822+08:00；Windows / PowerShell / .NET SDK 10.0.302。 +- 入口分支与 HEAD：`trajplanner` / `57ea36b8595c621783aba844e18d9969bccea378`。 +- 恢复交接祖先：`fcf7df17d54d84904278e993104e131afe8e405d`。 +- 以下提交均以 `git merge-base --is-ancestor` 返回 0：`c354f113060a5f95aa3b06c6f2b0be2d0c7d5da1`、`dff223c33a439d545537c803cb3531a673c7f2a3`、`46d5f9762d3d9972daea918c9fb43562ce25ce3b`、`57ea36b8595c621783aba844e18d9969bccea378`、`fcf7df17d54d84904278e993104e131afe8e405d`。 -## 前置祖先核验 +## 实现提交 -以下提交均以 `git merge-base --is-ancestor HEAD` 返回退出码 0： +- Task 1：`f4e89b4b4fe67f4924420ba8b3e06dea1d4ccc8b` — `feat: define full-direction EM planning scope` +- Task 2：`048b4f618e2237cd0cb3d257bf6ee04a1d13670b` — `feat: select complete EM direction segments` -- `c354f113060a5f95aa3b06c6f2b0be2d0c7d5da1` — `docs: design full-direction EM trajectory visualization repair` -- `dff223c33a439d545537c803cb3531a673c7f2a3` — `docs: plan full-direction EM visualization repair` -- `46d5f9762d3d9972daea918c9fb43562ce25ce3b` — `docs: design staged EM full-direction execution` -- `57ea36b8595c621783aba844e18d9969bccea378` — `docs: plan staged EM full-direction execution` +## 接口与实际修改 -## 读取与范围 +- 新增 `EmPlanningScope.RollingHorizon`、`FullDirectionSegment`；request 与 metadata 均保存不可变 scope。 +- 新增 desired speed、优化结点/发布上限、终端位置/yaw 容差、复制和交叉校验；默认值为 1.0/0.5 m/s、0.20 s、0.10 m、401、5001、0.03 m、5°。 +- 新增 `NoProgress`、`TerminalPoseMismatch`、`FullSegmentResourceLimitExceeded` 状态。 +- `PlanningHorizonSelector.Select` 显式接收 scope；full 模式仅接受 Goal/GearSwitch，选择真实方向段末端并使用 `ExactStopAtBoundary`；rolling 分支保持原有窗口/approach/exact 行为。 +- `EmPlanningService` 传递 scope，metadata 与 diagnostics 均携带 scope。 +- 用户随后授权的必需构造调用传播：`TrajectoryObservationPipeline.cs` 及 EM 验证宿主中的 coordinator/executor/trajectory/observation 构造夹具；所有旧调用显式使用 `RollingHorizon`，没有改变 MovementTest 的规划行为。 -已读取执行、TDD 与完成前验证技能；首次遇到 DLL 文件锁和编译异常后也完整读取并使用系统化调试技能。已读取功能设计第 1–6、9–12 节、总计划 Task 1–2、阶段执行设计第 2–11 节及阶段执行计划的全局约束/公共协议/Phase 01。 +实际修改文件为两个实现提交的 `git show --stat` 所列 21 个文件；Task 2 没有修改 `EmTrajectoryAssembler.cs`，因为现有 assembler 已基于 metadata 保留终端边界，完整段选择无需额外 assembly 行为。 -本窗口没有实现或提交 Task 1、Task 2。没有实现阶段 02 的自适应 knot/T_end，也没有修改静止起步、MovementTest、Web 或 Painter。 +## 新鲜 TDD 与回归证据 -## TDD RED 证据 +### Task 1 -先在 `FoundationChecks.cs` 添加了 Task 1 所需的 scope、配置、复制、校验、状态和 rolling/full 兼容性测试，再运行： +RED： ```powershell dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- foundation dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-planning-service ``` -首次输出包含预期的 `CS0246`/`CS0103`：`EmPlanningScope` 不存在；同时包含一次非预期的 `TrajectoryPlanningVisualization.dll` 写入锁（`CS2012`）。按系统化调试协议，随后单独重跑 foundation；文件锁未复现，预期的缺少 `EmPlanningScope` 编译错误稳定复现。因此 DLL 锁判定为瞬时外部构建竞争，不能作为本阶段 RED 或阻塞原因。 +首次失败为缺少 `EmPlanningScope`（CS0246/CS0103）。同次曾出现 `TrajectoryPlanningVisualization.dll` 瞬时写锁；单独复现后锁未持续，已按 systematic-debugging 认定为外部构建竞争，未作为功能 RED。之后完整构造调用传播获授权。 -在仅应用 Task 1 契约/配置/验证的最小实现后，运行： +GREEN：相同两个命令均退出 0，输出：`PASS foundation`、`PASS em-planning-service`。 + +### Task 2 + +RED： ```powershell -dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- foundation +dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- longitudinal-model ``` -退出码为 1。除本次试探性实现中缺少 `System.Math` 引用外，首个有效范围阻塞是： +失败为 `PlanningHorizonSelector.Select` 没有接收新增 scope 参数（CS1501），符合预期。 -```text -ClumsyPilot/ParkrobTrajplanner/tarjplanner_movementtest/TrajectoryObservationPipeline.cs(255,27): -CS7036: EmPlanningRequest(..., EmPlanningScope) 缺少必需 planningScope 参数 - -ClumsyPilot/ParkrobTrajplanner/EMPlanner/Facade/EmPlanningService.cs(104,32): -CS7036: EmTrajectoryMetadata(..., EmPlanningScope) 缺少必需 planningScope 参数 -``` - -## 阻塞原因与已排除项 - -总计划 Task 1 明确要求 `EmPlanningRequest` 与 `EmTrajectoryMetadata` 增加**必填** `EmPlanningScope` 构造参数、更新**每一个**构造调用，并禁止使用隐式默认值。仓库检索还发现未传播的调用位于： - -- `ClumsyPilot/ParkrobTrajplanner/tarjplanner_movementtest/TrajectoryObservationPipeline.cs`（生产调用；阶段 04 文件，明确不属于阶段 01 允许范围）。 -- `ClumsyPilot/tests/EMPlannerVerificationHost/CoordinatorChecks.cs` -- `ClumsyPilot/tests/EMPlannerVerificationHost/ExecutorChecks.cs` -- `ClumsyPilot/tests/EMPlannerVerificationHost/TrajectoryChecks.cs` -- `ClumsyPilot/tests/EMPlannerVerificationHost/TrajectoryObservationChecks.cs` -- `ClumsyPilot/tests/EMPlannerVerificationHost/TrajectoryObservationSegmentChecks.cs` -- `ClumsyPilot/tests/EMPlannerVerificationHost/TrajectoryObservationVisualizationChecks.cs` - -`EmPlanningService.cs` 是总计划 Task 2 的文件，仍在本窗口总体允许文件清单中；但 `TrajectoryObservationPipeline.cs` 既不在阶段 01 允许清单中，也属于后续阶段 04。要继续只能： - -1. 违反“必填且无默认值”的批准接口要求；或 -2. 修改后续阶段/范围外文件。 - -两项均不被批准，因此未继续。未尝试通过默认参数、额外重载或改变接口设计绕过该冲突。 - -## 已撤销的试探性修改与脏工作区保护 - -所有本窗口添加的失败测试和试探性 Task 1 生产代码均已用 `apply_patch` 撤销。以下回退核验返回退出码 0，表示这些文件相对 HEAD 无差异： +GREEN： ```powershell -git diff --quiet -- \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Contracts/EmPlanningRequest.cs \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Contracts/EmPlanningStatus.cs \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Contracts/EmTrajectoryMetadata.cs \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Configuration/SchedulingConfiguration.cs \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Configuration/LongitudinalConfiguration.cs \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Configuration/ValidationConfiguration.cs \ - ClumsyPilot/ParkrobTrajplanner/EMPlanner/Validation/EmPlanningRequestValidator.cs \ - ClumsyPilot/tests/EMPlannerVerificationHost/FoundationChecks.cs +dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- longitudinal-model +dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-planning-service ``` -已在编辑前保存并在回退后重新检查用户既有的 `EmPlannerConfiguration.cs` 完整 diff。它仍只包含： +均退出 0，输出：`PASS longitudinal-model`、`PASS em-planning-service`。测试覆盖 10 m/投影 3 m/legacy 1 m 的 full 真实末端、rolling 4 m 截断及 GearSwitch 边界；服务测试覆盖 scope metadata 和发布起止边界。 -- `TimeHorizonSeconds = 6d` 后的中文说明； -- `DistanceHorizonMeters` 从 `5d` 改为 `500d` 及中文说明。 +阶段回归： -这两行未暂存、未提交、未改写。`MovementTest.TrajectoryObservationTest.cs` 的用户既有修改未编辑、未暂存。整个既有脏工作区保持原状；没有使用 `git stash`、`git reset --hard`、`git checkout --`、`git add .` 或 `git add -A`。 +```powershell +dotnet run --project ClumsyPilot/tests/EMPlannerVerificationHost/EMPlannerVerificationHost.csproj -- em-core-all +``` -## 提交与验证状态 +退出 0，完整摘要：`PASS longitudinal-model`、`PASS longitudinal-integration`、`PASS trajectory`、`PASS em-planning-service`。首次回归时 `TrajectoryChecks` 的速度夹具受批准的硬上限变更影响，先触发加速度而非速度；夹具改为 1.10 m/s 以继续隔离速度上限，之后回归通过。 -- Task 1 实现提交：无（阻塞前未创建）。 -- Task 2 实现提交：无（未开始）。 -- GREEN、`longitudinal-model`、`em-planning-service` GREEN、`em-core-all`：均未运行成功；原因是批准的必填构造参数无法在阶段 01 允许范围内传播。 -- 本交接创建前暂存区为空。 +## 脏工作区与范围保护 -## 安全与兼容性影响 +- `EmPlannerConfiguration.cs` 的用户 `DistanceHorizonMeters = 500d` 和两条中文注释先保存 diff、始终未暂存；提交前以 index-only staging 核验其不在两个实现提交中。 +- `MovementTest.TrajectoryObservationTest.cs` 未编辑、未暂存、未提交。 +- 既有大量脏修改/未跟踪项均未清理；暂存区在本交接创建前为空。 +- 未使用 `git stash`、`git reset --hard`、`git checkout --`、`git add .` 或 `git add -A`。 +- `git diff --check 57ea36b8595c621783aba844e18d9969bccea378..048b4f618e2237cd0cb3d257bf6ee04a1d13670b` 通过。 -当前分支保持原行为，没有发布任何部分 scope 实现或改变 MovementTest。若强行采用默认 scope，会使旧调用静默选择行为，违反设计中“显式范围、禁止隐式混用”的兼容与安全边界。若修改 `TrajectoryObservationPipeline.cs`，会越过阶段 01 并提前触及阶段 04。 +## 未执行内容与阶段 02 输入 -## 精确恢复范围 +阶段 02–09 均未实现。尤其没有实现自适应 knot/T_end、静止起步、NoProgress 发布门禁、终端世界位姿门禁、MovementTest one-shot、Web 或 Painter。 -恢复窗口只能处理这一范围矛盾。开始前必须再次核验入口提交、现有交接提交、脏工作区和暂存区；重新阅读功能设计、总计划 Task 1–2、阶段执行设计与本交接。 - -在用户明确批准以下任一项之前，不得实现阶段 01： - -1. 扩大阶段 01 允许文件，至少包括所有必需的 `EmPlanningRequest`/`EmTrajectoryMetadata` 构造调用传播文件，特别是 `TrajectoryObservationPipeline.cs`；或 -2. 修订批准接口，使调用兼容方式不再要求阶段外文件变更。 - -批准后从 Task 1 的失败测试重新开始，重新收集 RED 证据；不要沿用任何已撤销的试探性实现。阶段 02 仍未实现，且在阶段 01 完成前不得开始。 +阶段 02 从 `048b4f618e2237cd0cb3d257bf6ee04a1d13670b` 开始，消费本阶段的 scope/configuration。只允许总计划 Task 3 列出的 Longitudinal 文件、`EmPlanningService.cs`、`LongitudinalModelChecks.cs`、`LongitudinalIntegrationChecks.cs` 和 `phase-02.md`；不得触及静止起步、终端位姿或任何 MovementTest/UI。先运行 Task 3 RED `longitudinal-model`，再运行 `longitudinal-model` 与 `longitudinal-integration` GREEN，提交 `feat: derive adaptive full-segment ST schedule`，运行 `em-core-all`，最后单独提交 `phase-02.md`。