v0.12.25 · SECURITY MONITORING FOUNDATION

Important security events should become visible alerts—not disappear into a log.

This release turns privileged staff-security evidence into durable triage alerts, detects repeated denied privileged actions, and requires exact permission plus recent strong authentication before an alert can be acknowledged or resolved.

TEST NOWApply migration 0024. Schema and self-test results now show a large green PASS or red FAIL first; technical JSON stays tucked under Details.

PRODUCTION LATERAdd scheduled monitor execution, real notification/on-call channels, provider/server event ingestion, retention policy, and a rehearsed incident-response process. Staging evidence does not fake those gates.

SCHEMA + ATTACK PATHS

Automated monitoring checks

Confirms schema v24, threshold detection, idempotent sweeps, strong-auth alert closure and immutable evidence.

NOT RUNSchema check has not run yet.

NOT RUNSelf-test has not run yet.

VISIBLE QA FLOW

Trigger → detect → triage

Use an isolated QA Security Admin to generate three denied privileged actions, detect the resulting high-severity alert, prove that triage is blocked before step-up, then acknowledge/resolve it after strong authentication.

READYStart with a QA Security Admin session.

ACTIVE QA ALERTS

Security alert triage

Before step-up: click Acknowledge and expect a red BLOCKED result. After enrolling and stepping up, Acknowledge and Resolve should turn green.

No QA Security Admin dashboard loaded yet.

PRODUCTION GATE — DO NOT FAKE

Production monitoring evidence

These remain open until ClaraWide is genuinely operating them in production.

Recent monitoring QA runs

No QA runs recorded yet.

Evidence tools

Clearing browser QA evidence does not rewrite server-owned alert history or staff-security evidence.