Active scenario
Sprint 6 · replayed with secops-policy@v3.2
Sprint 6 actually ran under v3.1. This pilot re-routes its 14 tickets through the current policy to estimate the delta. No commits, no merges — comparison only.
Pilot configuration
Source
Sprint 6 · 14 tickets · Apr 13–26
Applies
secops-policy@v3.2
HEAD
Override
+ Pending T4 backup-approver rule
Outcome diffactual vs simulated
Actual
→
Simulated
Tickets shipped
11 / 14
+2
13 / 14
MTTR · all sevs
21h
−18%
17h 12m
Critical SLA breaches
1
−1
0
Tokens used
118k
±0%
119k
Tickets routed differently5 of 14
SEC-1729crit
SQL injection in order-service · spring-sql-injection@2.3 · would now auto-merge under T1 (uses now ≥ 10)
T2 · human merge→T1 · auto-merge
SEC-1722med
SHA-1 in billing hashing · sha256-migration@1.4 · qualifies for T1 with current policy
T2 · human merge→T1 · auto-merge
SEC-1718high
Multi-file XSS in billing · 5 same-vuln findings → trips complexity escalation rule, would route to eng epic
DEV · auto-fixed→Eng epic · 2 sprints
SEC-1714crit
Crypto change · @alice was OOO 3 days · backup-approver rule would route to @bob, closing SLA breach
@alice · 4d wait→@bob · same day
SEC-1720high
Path traversal in file-service · second approver auto-assigned to @bob instead of waiting on Alice
@alice · 2d wait→@bob · 4h
Looks good?
Promote pending backup-approver rule to secops-policy@v3.3
Active pilots · 3
Sprint 6 @ v3.2 + backup-approver
Running
Currently viewing · started 4 minutes ago by @alice
Shadow T1 promotion · spring-csrf
Done
Ran spring-csrf@1.2 as if it were T1 against last 30 days · 5 of 5 would have auto-merged cleanly. Ready to graduate.
Sprint 5 @ v3.0 (regression check)
Queued
Verify rolling back to v3.0 wouldn't break already-shipped fixes. Scheduled to run before any future policy rollback.