feat: redesign leadership operations dashboard

.project-docs/60-reflection/cases/20260901-leadership-dashboard-c4b9e1__leadership-dashboard-boundary.md

@@ -0,0 +1,23 @@
+# Reflection: Leadership dashboard is not an audit log
+
+## Trigger
+
+The first operations-dashboard implementation met the read-only who/instruction/result data contract but organized the page as a searchable instruction history. The user corrected that framing: leaders need an aggregate platform-running view with touchable business dimensions, not technical audit history.
+
+## Lesson
+
+- Start dashboard work by defining the audience, decisions, and primary questions before selecting tables or detail fields.
+- A leadership operations dashboard is aggregate-first: task volume, people, time, type, progress, original input, and final output. Detail exists to explain an aggregate, not to reproduce a task log.
+- Keep engineering/audit diagnostics as a separate surface even when both read the same durable task records.
+- “Original input” does not always mean displaying bytes verbatim. Historical machine-shaped payloads should be replaced by an explicit no-business-instruction placeholder on a leadership surface, while the underlying audit evidence remains unchanged.
+- Use both a server projection and a presentation-layer guard when an already-running deployment may temporarily serve an older projection during a frontend-only rollout.
+
+## Evidence
+
+- User correction on 2026-09-01.
+- Before/after authenticated browser verification of `/operations-dashboard`.
+- Task record `20260901-leadership-dashboard-c4b9e1` and its full regression results.
+
+## Candidate
+
+Add an audience-and-decision-questions checkpoint to future dashboard design acceptance criteria before implementation begins.