raphael/secs-gem
Public Access
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: refresh stale roadmap status rows (GetVariables shipped, harnesses automated)

Browse Source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Raphael Maenle
2026-06-10 19:34:13 +02:00
parent 1daf120431
commit 83593bb508
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/DAEMON_ROADMAP.md
+5 -5
View File
@@ -25,11 +25,11 @@ host and stays conformant while the tool software restarts/upgrades/crashes.
| `EquipmentRuntime` (engine owner) | ✅ | tested (`test_runtime.cpp`); `secs_server` runs entirely on it (live GEM300 demo passes) |
| `register_default_handlers` (the 56 GEM handlers as a library fn) | ✅ | `src/gem/default_handlers.cpp`; tested (`test_default_handlers.cpp`) |
| gRPC/protobuf toolchain (Dockerfile + CMake codegen) | ✅ | grpc++ 1.51 / protoc 3.21; opt-in `SECSGEM_DAEMON`, graceful skip without grpc |
| `secs_gemd`: `SetVariables` / `FireEvent` / `GetControlState` | ✅ | **format-aware** (converts to each variable's declared SECS-II format) and thread-safe (name/format maps snapshotted at construction; all writes post to the io thread). In-process gRPC tests (`test_daemon_service.cpp`, 16 assertions) |
| `secs_gemd`: `SetVariables` / `FireEvent` / `GetControlState` / `GetVariables` | ✅ | **format-aware** both directions (declared SECS-II formats on write, `from_item` on read) and thread-safe (snapshot maps + posted writes + `read_sync` reads). In-process gRPC tests incl. run_async production mode (`test_daemon_service.cpp`, 61 assertions) |
| Daemon interop vs **secsgem-py** reference host | ✅ | `interop/daemon_interop.py` (via `gemd` compose service): gRPC `SetVariables(ChamberPressure=2.5)` + `FireEvent` → host receives `S6F11 CEID 300` carrying `<F4 2.5>` — value *and declared format* flow gRPC→engine→HSMS→host |
| Daemon interop vs **secs4j** (Java) | ⬜ | mirror the secsgem-py harness against `interop/secs4j` |
| `Subscribe` host→tool command stream | ⬜ | design settled (HCACK-4, see below); not implemented |
| Remaining universal RPCs (`GetVariables`, alarms, `RequestControlState`, `WatchHealth`) | ⬜ | see plan |
| Remaining universal RPCs (alarms, `RequestControlState`, `WatchHealth`) | ⬜ | see plan (Phase A) |
| Python client package (the "beautiful API") | ⬜ | thin wrapper over generated stubs |
## Known issues (found in the 2026-06-10 audit; honest list)
@@ -46,9 +46,9 @@ host and stays conformant while the tool software restarts/upgrades/crashes.
- ⬜ **`pvd_tool` predates the behaviour hook.** It still hard-codes
`if (rcmd=="START") recipe->start(...)` in a router handler. Migrate it to
`commands.set_handler` so the flagship example showcases the intended seam.
- ⬜ **Interop harnesses are manual.** `daemon_interop.py` (and the older
host/server harnesses) run via ad-hoc compose invocations; there is no
`tools/run_interop.sh` or CI lane that runs them. Add one script + CI job.
- ✅ ~~**Interop harnesses are manual.**~~ `tools/run_interop.sh` runs all nine
validation steps with one command (verified green); CI lanes added, pending
first-push verification (Phase 0 item 2).
- ⬜ **TSan lane doesn't cover the daemon.** `secs_gemd_tests` should also be
built/run under `-DSECSGEM_TSAN=ON` once the control-state mirror lands.
- ⚠️ **macOS bind-mount staleness can break Docker builds mid-edit** (a build