SG/Sentinel MVP — Testing Manual (sg sentinel *)
Summary
How to exercise every sg sentinel command across the three targets — the source of every command on the try-it page. It documents the rules/local/logs/blocks/deploy/status surfaces, the offline stack with the CF-env simulation as default, the live AWS flow with its mutation gate and teardown discipline, and the test suite with its opt-in docker and live legs. It also records how far the MVP grew past the dev brief: Textual operator TUIs over every surface, a structured TUI API, a read-only LLM chat grounded in live state (Bedrock Nova, read actions only), and the traffic generator + httpget echo origin whose bare-origin-versus-fronted contrast is the impact measurement.
Key concepts
- The command surface — every sg sentinel command, with --json everywhere and mutation-gated deploys
- The offline stack — real L1 + real L2 + local sink; curl the CF-env sim directly and get the signal back
- The TUIs and the read-only chat — operator screens, the TUI API, and an LLM that can inspect everything and change nothing
- Impact measurement — the labelled corpus against a bare origin vs a Sentinel-fronted one
Key ideas
- Source IPs are hashed in the stored record by default; blocks why understands both the raw IP and its hashed form.
- The chat stays honest by construction: only read actions are exposed, every answer shows its tool calls and cost.
- gen latency is harness cost, not CloudFront runtime — real edge latency needs a live distribution.
On this site
Rendered nearly whole as the try-it page; the TUI/chat/traffic sections update the roadmap's built list.