6.1 KiB
6.1 KiB
Task: Redesign leadership operations dashboard
Identity
- Task ID: 20260901-leadership-dashboard-c4b9e1
- Mode: Feature
- Branch: main
- Worktree: /Users/inmanx/Documents/lwltAPI
- Base commit:
08725b2de9 - Owner: codex
- Status: Ready for integration
Scope
- Reframe
/operations-dashboardfrom 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_leadaccess 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-dashboardloaded 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-11and 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.mdduring 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.