feat: use telemetry in guardrails
This commit is contained in:
@@ -210,7 +210,7 @@ Definition of Done:
|
||||
|
||||
## TASK-014 — Integrate telemetry with guardrails
|
||||
|
||||
Status: Todo
|
||||
Status: Done
|
||||
|
||||
Goal:
|
||||
Use structured telemetry data in guardrail analysis.
|
||||
@@ -221,8 +221,16 @@ Guardrails currently rely on heuristics and markdown files rather than actual ac
|
||||
|
||||
Acceptance Criteria:
|
||||
|
||||
- Read telemetry events
|
||||
- Detect repeated commands
|
||||
- Detect repeated reads when available
|
||||
- Fall back gracefully when telemetry is absent
|
||||
- Add/update tests
|
||||
- Read telemetry events ✓
|
||||
- Detect repeated commands ✓
|
||||
- Detect repeated reads when available ✓
|
||||
- Fall back gracefully when telemetry is absent ✓
|
||||
- Add/update tests ✓
|
||||
|
||||
Result:
|
||||
|
||||
Two new guardrail checks added:
|
||||
- `check_repeated_commands_telemetry` — uses session-log.jsonl to detect repeated CLI commands (>3x)
|
||||
- `check_repeated_reads_telemetry` — uses session-log.jsonl to detect repeated file reads (>3x)
|
||||
Both integrate into `run_all_guardrails` alongside existing heuristic checks.
|
||||
When telemetry data is absent, both return `"ok"` with an informative fallback message instead of failing.
|
||||
|
||||
Reference in New Issue
Block a user