Reposition FlowEngine as a simulation-driven framework + regression/scaffolding for follow-up work

[Copilot]

Project direction is refocused: no real-vehicle work (no automotive mass production, ECU/CAN, hard real-time, or safety certification). The two mainlines are software-framework quality and simulation. This PR reframes the positioning and lays down interfaces + a simulation-as-testing harness so remaining plan items can be filled in incrementally — including by less-capable contributors who only need to supply implementations.

Repositioning (remove 实车 semantics)

• README.md, docs/EVOLUTION_ROADMAP.md, docs/PROJECT_REVIEW.md: identity changed from "middleware kernel prototype / production ADAS framework" to "simulation-driven middleware framework + reproducible experiment platform". Phase 10 clarified as multi-process simulation deployment; learning loop reworded as in-sim shadow inference (never actuated).

Simulation-as-testing (acceptance criterion #1)

• tools/scenario_regression.py: one command runs the scenario matrix → scores each → diffs against a baseline (regression ⇒ FAIL). Extension points are data-only: add scenarios or tune gates in scenarios/suite.json.
• tools/demo_evaluator.py: two composable flags — --scenario (temporarily overrides sim_world.scenario_file, restored on exit) and --json-out (machine-readable result). Also fixes scenario loading that read nodes while the launcher schema uses processes.
• scenarios/suite.json + three declarative scenario templates (unprotected intersection, congestion follow, ghost pedestrian).

python3 tools/scenario_regression.py --update-baseline   # record baseline
python3 tools/scenario_regression.py --baseline          # fail on regression

Interface scaffolding (contract now, implementation later)

• include/topic_bridge.h: cross-process topic-bridge contract for A3 (PUB/SUB/BIDIR, per-topic stats). Header-only, syntax-checked in C and C++; implementation intentionally deferred.
• docs/IMPLEMENTATION_GUIDE.md: maps every remaining plan item (A1–B4) to 目标 / 现状 / interface-already-defined / 待实现 / 验收 task cards, pointing at exact files and functions, with a re-prioritized schedule.

Docs wiring

• docs/README.md index + docs/SIMULATION_GUIDE.md usage section updated for the guide and regression harness.

No C sources or build config were modified; changes are documentation, declarative JSON, a header-only interface, and Python tooling that shells out to the existing evaluator.

[caixuf]

评估一下是否需要接入地图模块

[caixuf]

@copilot 评估一下是否需要接入地图模块

[caixuf]

让行行人后不会动的问题修复下 @copilot

[Copilot]

@copilot 评估一下是否需要接入地图模块

结论：现阶段不需要接入"地图模块"（HD-Map/OpenDRIVE/Lanelet2 + 地图定位）；建议只在需要更高场景保真度时，补一层"纯数据的车道几何契约"，归入 B1。

现状（地图是隐式硬编码的）

• 参考路径在 planning_node.c::update_reference_path() 里写死为直线 y=-1.75（ref_y = -1.75），Frenet 只在这条直线上做横向偏移。
• 车道信息靠 control_node.c 的 lane_width / road_center_limit 参数近似，没有真正的车道拓扑。
• 场景契约 scenario_loader.h（ScenarioEgo/ScenarioActor/ScenarioCriteria）只有 ego + actors + 判据，没有任何道路/车道几何。所以连 intersection_unprotected.json 也只是"直路 + 横向来车"，并没有真正的路口拓扑。

为什么不做重量级地图模块

• 违反定位红线：HD-Map 栈、地图匹配定位是实车/量产方向的东西，与"仿真驱动框架、无实车、不引入重依赖"相悖。
• 收益/成本不划算：当前所有场景都是直路，重地图带来的能力现在用不上。

什么时候才值得做（真实缺口）
一旦要表达弯道 / 真实路口 / 多车道拓扑 / 路由，硬编码 y=-1.75 就不够用了。那时的正确做法不是引地图库，而是沿用本项目"接口先行、纯数据扩展"的思路：

1. 在 scenario_loader.h 增加一个轻量 road/lanes/reference_path 结构（折线点集 + 车道宽/中心线），scenario_load() 解析；
2. planning_node.c 从场景读几何替换写死的 ref_y，control_node.c 的 lane_width/road_center_limit 也改为读场景；
3. 新增几何后加场景只改 JSON、不改 C，与现有 B1 扩展点一致。

建议：作为 B1 下的一张任务卡"轻量车道几何契约（数据驱动，非地图库）"，优先级 P2/P3，等直路场景不够用时再落地。如果你希望，我可以先把这层 scenario_loader.h 的接口契约和 IMPLEMENTATION_GUIDE 卡片补上（只定义接口、不写实现），保持和 topic_bridge.h 一样的"契约先行"风格。

[caixuf]

@copilot 作为 B1 下的一张任务卡"轻量车道几何契约（数据驱动，非地图库）"，优先级 P2/P3，等直路场景不够用时再落地。如果你希望，我可以先把这层 scenario_loader.h 的接口契约和 IMPLEMENTATION_GUIDE 卡片补上（只定义接口、不写实现），保持和 topic_bridge.h 一样的"契约先行"风格。

[caixuf]

挺完善的