Description
One developer session in five is a PII probe (PII_PROBE_PERCENT=20), so the guard-deny alert and panels look mechanical and a large share of sessions are near-identical support-ticket prompts. The demo still needs the pii_gate deny guard and the al-guard-deny alert to fire on their own during a presentation.
Acceptance Criteria
- #1 PII probes arrive in occasional bursts from one developer with a configurable mean interval, with a low baseline otherwise
- #2 The PII probe prompts are varied and embedded in otherwise ordinary tasks
- #3 In a running demo the al-guard-deny alert fires at least once within two hours of traffic starting
Definition of Done
- #1 just check
Implementation Plan
- Replace PII_PROBE_PERCENT with bursts from one developer at a configurable mean interval plus a low baseline, early first burst so al-guard-deny fires within 2h. 2. Varied PII prompts embedded in ordinary tasks.
Implementation Notes
Live: traffic started 10:31 UTC; sam.okafor’s pii-ticket-triage-ni was blocked (guard_blocked true) in slot 0 and al-guard-deny went Alerting at 10:33 UTC. Anchor rules (main thread + CodeRabbit): cleared while traffic is disabled, kept across a single container restart. Left open by choice: per-container anchors can skew by the sign-in stagger (minutes vs 120-minute slots).
Final Summary
PII probes are occasional bursts from one developer per PII_BURST_MEAN_MINUTES slot on a 2% baseline, with 10 varied probes embedded in ordinary tasks; the first burst lands within an hour, and al-guard-deny fired 2 minutes after traffic started on the live demo.