> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Build a Windows Go V2 application that safely reads one local RTSP stream, performs ONNX Pose and fall-event processing off the UI thread, visibly alerts once per confirmed event, persists evidence, and can be assembled into a self-contained release folder.
**Architecture:**`internal/config` resolves a credential-free JSON configuration and the RTSP URL only from an environment variable. `internal/source` owns FFprobe/FFmpeg subprocesses, reconnection and a one-slot latest-frame channel. `internal/monitor` owns ONNX Pose and the existing fall engine; it publishes completed render frames and events. `internal/render` and `internal/alert` draw/persist evidence on worker goroutines. `internal/ui` is a Walk-only observer and command surface; it receives already-computed state via `Synchronize` and never opens a stream or runs inference.
**Tech Stack:** Go 1.24, `github.com/yalue/onnxruntime_go` v1.31.0, ONNX Runtime CPU DLL, FFmpeg/FFprobe, `github.com/lxn/walk`, Windows `MessageBeep`, standard-library JSON/PNG/SHA-256, existing `internal/pose` and `internal/fall`.
---
## Scope and acceptance boundary
- One Windows camera stream only. The public configuration stores an environment-variable name, never an RTSP URL, user name or password.
- The target scene remains a fixed, downward-viewing hall/corridor with most of a body visible. `demo/1.mp4` remains a documented out-of-scope false-negative risk sample, not a T-304 success test.
- The user manually closed T-303. This plan must not describe that as a new positive-video or event-latency validation result.
- Release dependencies are copied from explicit operator-supplied paths and their hashes are written into the generated release manifest. No DLL, FFmpeg binary, ONNX file, customer video, credential or event artifact is committed.
| `v2/internal/config/config.go` | Parse/validate JSON, resolve RTSP URL from environment, calculate a non-secret configuration version, and validate hashes/paths. |
| `v2/internal/source/stream.go` | Probe source metadata, launch/relaunch FFmpeg, expose status and a latest-frame channel, and hide subprocess details that could contain a URL. |
| `v2/internal/monitor/monitor.go` | Compose source, reusable ONNX Runtime, Pose parse and the existing fall engine; publish display-ready results. |
| `v2/internal/render/overlay.go` | Convert BGR to RGBA and draw box, 17-point skeleton, state/ID/time and red confirmed border. |
// Decode into a private raw type, reject raw source.url/host/user/password,
// resolve only os.LookupEnv(raw.Source.RTSPURLEnv), and hash canonical
// non-secret source/model/event values as cfg-<sha256>.
}
```
Validate all required files and 64-hex model hash before monitoring starts. Return generic path/configuration errors; do not include the resolved URL in errors. Document the V2 field meanings and unchanged `FallEvent` fields in `docs/api.md`.
// ffprobe JSON obtains width/height/FPS once per connection; ffmpeg emits
// bgr24 rawvideo. ReadFull exactly W*H*3 bytes, time-stamp with time.Since
// (monotonic), publish only the newest frame, and retry 1/2/4/8 seconds.
}
```
Use `-rtsp_transport`, `-rw_timeout`, low-latency FFmpeg input flags when configured, and `-f rawvideo -pix_fmt bgr24 -` output. Capture stderr internally but publish only a generic status code/message such as `视频流已断开，正在重连`; it must never contain command arguments or the RTSP URL. Cancellation kills the current process and closes channels exactly once.
Draw a 17-point COCO skeleton, box and ASCII `track/state/time` label in the image. Normal/SUSPECT/RETRYING use green/amber/slate respectively; only `CONFIRMED` draws critical red skeleton and a six-pixel image border. Create `YYYYMMDD/FALL-*.png` and append one UTF-8 JSONL line with the V1-compatible public event fields plus source ID, UTC time and relative screenshot path. The dispatcher holds a seen-event-ID set before writing so retried UI messages cannot overwrite an image or replay an alert. Its notifier interface only reports a one-shot notification request; it does not own UI controls.
Create/open one ONNX Runtime instance before consuming frames and close it only when monitoring stops. Treat Pose/preprocess errors as non-fall status updates and continue/reconnect according to source state; do not terminate the Walk message loop. Only completed rendered frames enter the one-slot `Updates` channel, so a slow UI never queues stale video frames.
Use a 1120×720 default / 960×640 minimum window with a standard top `TabWidget` named “监控” and “设置”. Monitor tab: `ImageViewModeZoom`, source/status/event cards, a clearly labeled Start/Stop button and recent-event summary. Settings tab: read-only source environment-variable readiness, model hash prefix, runtime dependency readiness and the effective event values; do not present editable credentials or a resolved URL in T-304. Apply semantic brushes from the documented light palette (`#EAF1F8` base, white surfaces, blue focus/action); state text and labels always accompany color. Use standard controls so Tab/Shift+Tab/Enter/Space/Escape behavior is inherited. `Present` must use `MainWindow.Synchronize`, dispose the previous bitmap after `ImageView.SetImage`, and show exactly one modal `walk.MsgBox` with “我已知晓” semantics per dispatcher record. Call `win.MessageBeep` when the record reaches the UI; no normal, suspect or reconnect path may beep or show a critical dialog.
- [ ]**Step 2: Verify it fails before adding the command package**
Run: `Set-Location v2; go test ./cmd/silver-pose -run TestValidateStartup -v`
Expected: FAIL because the command package is absent.
- [ ]**Step 3: Implement preflight, lifecycle and release assembly**
```go
funcmain(){
cfg:=mustLoadConfig(flagConfig)
mustValidateStartup(cfg)
window:=mustNewWindow(cfg,commands)
goconsumeMonitorUpdates(window,monitor)
window.Run()
}
```
`build-v2-release.ps1` must require `-OnnxPath`, `-OrtDllPath`, `-FfmpegPath`, `-FfprobePath` and `-OutputDirectory`; it must reject a non-empty target directory, build `silver-pose.exe` with CGO/MinGW, copy the four explicit binaries plus `config.example.json`, write `runtime-manifest.json` with SHA-256 and tool version output, and fail when a required input is missing. The runbook must document a local ignored `config.local.json`, setting the RTSP environment variable outside the repository, normal/reconnect/confirmed demonstrations, where event evidence is written, a 1–3 second stated target, and the fixed-view scope limitation.
- [ ]**Step 4: Run automated and release-folder smoke verification**
Run: `Set-Location v2; $env:CGO_ENABLED='1'; go test ./...; go build ./cmd/silver-pose`
Expected: `silver-pose.exe`, all runtime files, public config and hash manifest present; no RTSP URL, video or event artifact appears in the folder.
- [ ]**Step 5: Run the task acceptance sequence and update facts**
Run: `./init.ps1`
Expected: V1 baseline passes.
Run: `Set-Location v2; $env:CGO_ENABLED='1'; go test ./...; go build ./cmd/silver-pose`
Expected: PASS.
Run: launch the release executable with a local configuration and approved live RTSP stream.
Expected: live frame and skeleton/ID; disconnect causes reconnect text without fall alert; one approved fall produces red overlay, one sound, one acknowledgment popup, one PNG and one JSONL line; normal activity does not create a confirmed event.
gitcommit-m"feat(v2): deliver realtime demo and release tooling"
```
## Plan self-review
- Coverage: Tasks 1–2 implement secure RTSP configuration and reconnect; Tasks 3–4 add Pose/event-to-evidence flow; Task 5 provides the light, accessible operator UI and one-shot alert; Task 6 builds the release directory, documents operation and verifies the complete T-304 acceptance path.
- Boundary checks: release binaries and local credentials/videos remain untracked; alerts are event-ID idempotent; red is exclusive to `CONFIRMED`; source failures never enter the fall engine; UI thread only observes completed updates.
- Deliberate gap: actual camera/fall acceptance requires the local camera, credentials and safe on-site action. The application and release can be built/tested without those assets, but T-304 must remain `DOING` until the runbook's final live sequence is observed and recorded.
