feat: redesign leadership operations dashboard

2026-09-01 19:52:56 +08:00
1 parent 08725b2de9
commit 823d1cb630
@@ -0,0 +1,65 @@
+# Task: Redesign leadership operations dashboard
+
+## Identity
+
+- Task ID: 20260901-leadership-dashboard-c4b9e1
+- Mode: Feature
+- Branch: main
+- Worktree: /Users/inmanx/Documents/lwltAPI
+- Base commit: 08725b2de9af2b927772689610e2b538c5a4ff2a
+- Owner: codex
+- Status: Ready for integration
+
+## Scope
+
+- Reframe `/operations-dashboard` from an audit/history-oriented view into an executive platform-operations dashboard.
+- Make task volume, people, original input, final output, time, business type, and completion state the primary dimensions.
+- Preserve leadership-only read access and clickable drill-through without exposing task mutation or technical debugging context.
+- Keep the existing stack and ERP/business execution behavior unchanged.
+
+## Intent And Constraints
+
+- The dashboard is for leaders, not engineers. Visible copy must not include parser/plugin/ERP internals, codes, JSON, stack traces, record identifiers, or technical failure strings.
+- Every summary dimension should lead to a filtered task view, and each task should show who acted, when, the task type, original instruction, and final business-facing outcome.
+- Reuse the existing leadership projection and authorization boundary where possible; narrow its result language if technical text can leak into the executive view.
+- Do not add organization concepts, change task authorization, access ERP, or send data externally.
+
+## Outcome
+
+- Renamed the leadership surface to “平台运行看板” and rebuilt it around an executive “平台运行全景” rather than audit/history terminology.
+- Added an aggregate-first layout with task volume, completion rate, active work, follow-up work, unfinished work, participating people, time trend, ranked task types, people performance, and a task flow from original input to final output.
+- Preserved and clarified drill-through: status cards, dates, task types, people, pagination, keyword/date filters, and individual task rows all lead to a narrower business-facing view.
+- Replaced technical/history-oriented task rows with who/time/type plus original-input and final-output columns. Internal record identifiers are no longer rendered.
+- Rebuilt task detail as a read-only leadership drawer showing person, task type, time, progress, original input turns, submitted business materials, and final business outcome.
+- Added leadership-safe input and result projections in both the control-plane service and browser presentation. Technical payloads, parser/plugin/ERP terms, internal codes, and historical machine JSON are replaced by concise business-readable explanations in this dashboard only.
+- Kept the existing `admin`/`team_lead` access gate, manual-task scope, task authorization, normal task ownership, audit administration, and ERP execution behavior unchanged.
+- The current static operator page reads the updated source immediately from the existing 8786 service. No service restart, database migration, ERP access, external send, or runtime task mutation was performed.
+
+## Verification
+
+- `node --check LianSyn-platform/app.js`: passed using the bundled Node runtime.
+- Focused account/leadership regression: 8/8 passed.
+- `node --run check:repo`: 10/10 passed.
+- `node --run check`: passed.
+- `node --run test:control-plane`: 153/153 passed.
+- `node --run test:legacy`: 256/256 passed.
+- `node --run build`: passed.
+- `git diff --check`: passed.
+- Authenticated browser verification on `http://127.0.0.1:8786/operations-dashboard` loaded 359 current tasks, 8 active dates, 19 task-type buckets, 1 participating account, and 50 paginated task rows with no dashboard-visible technical result text.
+- Browser drill-through verification: a date selected `2026-08-11` and narrowed the view to 174 tasks; the top task type narrowed the view to 306 tasks; unfinished status narrowed to 94 tasks; a task drawer showed person, time, type, original input, submitted material, and final business-facing result.
+- Browser content checks found zero code-like input blocks and zero plugin/ERP/internal-code output blocks across the loaded page after the leadership presentation filters were applied.
+
+## Follow-ups
+
+- The standard database still has only one administrator account, so the people-performance area currently contains one person. Create team-lead and ordinary-user accounts through the existing administrator workflow to make cross-person comparison meaningful.
+- The control-plane TypeScript projection will be picked up on the next separately authorized service restart; the browser presentation layer already enforces the same leadership-safe wording on the running page.
+
+## Promotion Candidates
+
+- Target: `AUTH-001`, `.project-docs/20-architecture/data-flow.md`, `.project-docs/20-architecture/system-overview.md`, and `.project-docs/40-domain/business-rules.md` during a later Integration Gate.
+- Proposal: define the leadership dashboard as an aggregate-first platform-operations view for leaders, not an audit log or debugging surface. Its primary dimensions are task, person, original input, final output, time, task type, and business completion state; every aggregate may drill into the same business-facing task projection.
+- Proposal: raw technical result strings and historical machine-shaped inputs are never shown on the leadership surface. They remain available only through appropriate engineering/audit diagnostics, while the leadership dashboard renders a bounded business explanation.
+- Evidence: `LianSyn-platform/index.html`, `LianSyn-platform/app.js`, `LianSyn-platform/styles.css`, `control-plane/src/task-service.ts`, `control-plane/test/account-authorization.test.ts`, the full test suite, and authenticated browser verification summarized above.
+- Future impact: dashboard acceptance criteria, operations API projections, visual hierarchy, error copy, and browser regression tests should start from audience and decision questions before implementation details.
+- Semantic conflict: this narrows and clarifies the prior “who/instruction/result history” implementation; it does not change the accepted read-only leadership authorization boundary.
+- Human confirmation required: received in this task through the explicit correction that the dashboard is for leadership and must not expose technical language.
@@ -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.