docs(workspace): 记录工作活动日报方案
This commit is contained in:
Script Generator
143
docs/superpowers/plans/2026-06-26-work-activity-daily-report.md
Normal file
143
docs/superpowers/plans/2026-06-26-work-activity-daily-report.md
Normal file
@@ -0,0 +1,143 @@
|
||||
# Work Activity Daily Report Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Add a lightweight work-activity layer and use it to build a more complete personal daily report.
|
||||
|
||||
**Architecture:** Add `WorkActivity` types, a Zustand store persisted through the existing `app_data` document API, and a pure `workspace-daily-report` aggregator that combines activities, legacy worklogs, and current workspace items. Store business actions create activity records at existing operation entry points.
|
||||
|
||||
**Tech Stack:** Next.js app router, Zustand stores, TypeScript pure functions, Node test runner through the existing web test command.
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Activity Types And Daily Report Aggregation
|
||||
|
||||
**Files:**
|
||||
- Create: `apps/web/lib/work-activity.ts`
|
||||
- Modify: `apps/web/lib/workspace-daily-report.ts`
|
||||
- Modify: `apps/web/lib/workspace-daily-report.test.ts`
|
||||
|
||||
- [ ] **Step 1: Write failing tests**
|
||||
|
||||
Add tests that call `getWorkspaceDailyReport` with `activities`, `worklogs`, `workItems`, `userId`, and `date`. Cover activity grouping, user/date filtering, old worklog compatibility, and needs-progress detection for an in-progress item without today's note.
|
||||
|
||||
- [ ] **Step 2: Run focused tests and verify failure**
|
||||
|
||||
Run: `pnpm --filter=web test -- workspace-daily-report`
|
||||
|
||||
Expected: FAIL because `activities` and `needsProgressItems` are not implemented.
|
||||
|
||||
- [ ] **Step 3: Implement minimal types and aggregation**
|
||||
|
||||
Create `WorkActivity` and update `WorkspaceDailyReport` with `groups`, `legacyWorklogs`, and `needsProgressItems`. Keep `items` as a compatibility alias for old worklog-derived rows until the UI is updated.
|
||||
|
||||
- [ ] **Step 4: Run focused tests and verify pass**
|
||||
|
||||
Run: `pnpm --filter=web test -- workspace-daily-report`
|
||||
|
||||
Expected: PASS.
|
||||
|
||||
### Task 2: Activity Persistence Store
|
||||
|
||||
**Files:**
|
||||
- Create: `apps/web/stores/useWorkActivityStore.ts`
|
||||
- Modify: `apps/web/lib/server-data.ts`
|
||||
- Modify: `apps/server/src/modules/data/data-keys.ts`
|
||||
|
||||
- [ ] **Step 1: Write failing persistence/type test**
|
||||
|
||||
Extend an existing data-key or server-data test so `work-activities` is accepted.
|
||||
|
||||
- [ ] **Step 2: Run focused tests and verify failure**
|
||||
|
||||
Run: `pnpm --filter=web test -- workspace-daily-report`
|
||||
|
||||
Expected: FAIL or type-check failure until the new key is registered.
|
||||
|
||||
- [ ] **Step 3: Implement store and data key**
|
||||
|
||||
Add `useWorkActivityStore` with `fetchActivities`, `addActivity`, and `addProgressNote`, persisted through `saveServerData('work-activities', items)`.
|
||||
|
||||
- [ ] **Step 4: Run focused tests**
|
||||
|
||||
Run: `pnpm --filter=web test -- workspace-daily-report`
|
||||
|
||||
Expected: PASS.
|
||||
|
||||
### Task 3: Emit Activities From Business Stores
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/web/stores/useVersionPlanStore.ts`
|
||||
- Modify: `apps/web/stores/useDevTaskStore.ts`
|
||||
- Modify: `apps/web/stores/useBugStore.ts`
|
||||
- Modify if present: `apps/web/stores/useTestCaseStore.ts`
|
||||
|
||||
- [ ] **Step 1: Add tests for action-to-activity mapping where pure helpers exist**
|
||||
|
||||
Cover dev-task start/submitted, plan completion, and bug fixed/closed through helper-level tests or store-light tests if existing patterns allow.
|
||||
|
||||
- [ ] **Step 2: Run tests and verify failure**
|
||||
|
||||
Run: `pnpm --filter=web test -- workspace-daily-report dev-task-workflow bug-workflow version-plan-workflow`
|
||||
|
||||
Expected: FAIL for new activity mapping expectations.
|
||||
|
||||
- [ ] **Step 3: Emit activities in store methods**
|
||||
|
||||
Call `useWorkActivityStore.getState().addActivity(...)` after successful create, status transition, completion, blocked change, transfer, and progress-note actions.
|
||||
|
||||
- [ ] **Step 4: Run tests**
|
||||
|
||||
Run: `pnpm --filter=web test -- workspace-daily-report dev-task-workflow bug-workflow version-plan-workflow`
|
||||
|
||||
Expected: PASS.
|
||||
|
||||
### Task 4: Workspace And Drawer UI
|
||||
|
||||
**Files:**
|
||||
- Modify: `apps/web/app/workspace/page.tsx`
|
||||
- Modify: `apps/web/components/workspace/DailyReportPanel.tsx`
|
||||
- Modify: `apps/web/components/dev-task/DevTaskDetailDrawer.tsx`
|
||||
|
||||
- [ ] **Step 1: Write/update UI-adjacent tests if existing component tests cover the panel**
|
||||
|
||||
Assert grouped labels render from the daily report model when component tests are available.
|
||||
|
||||
- [ ] **Step 2: Wire the workspace page**
|
||||
|
||||
Fetch `work-activities`, pass them into `getWorkspaceDailyReport`, and render grouped sections.
|
||||
|
||||
- [ ] **Step 3: Add progress-note controls in dev-task drawer**
|
||||
|
||||
Expose a compact form for ongoing work that records note, blocker/help/risk metadata through `addProgressNote`.
|
||||
|
||||
- [ ] **Step 4: Run web tests and type-check**
|
||||
|
||||
Run: `pnpm --filter=web test`
|
||||
|
||||
Run: `pnpm --filter=web type-check`
|
||||
|
||||
Expected: PASS.
|
||||
|
||||
### Task 5: Documentation And Final Verification
|
||||
|
||||
**Files:**
|
||||
- Modify: `docs/architecture.md`
|
||||
- Modify: `docs/decisions.md`
|
||||
- Modify: `docs/roadmap.md`
|
||||
|
||||
- [ ] **Step 1: Document the new activity layer**
|
||||
|
||||
Add a short architecture note and decision explaining why this is an activity engine instead of a generic rules engine.
|
||||
|
||||
- [ ] **Step 2: Run full verification**
|
||||
|
||||
Run: `pnpm --filter=web test`
|
||||
|
||||
Run: `pnpm --filter=web type-check`
|
||||
|
||||
Run: `pnpm --filter=server test`
|
||||
|
||||
Run: `git diff --check`
|
||||
|
||||
Expected: all commands exit 0.
|
||||
@@ -0,0 +1,87 @@
|
||||
# Work Activity Daily Report Design
|
||||
|
||||
## Goal
|
||||
|
||||
Build a lightweight activity-record layer so the workspace daily report can show what the current user actually did today, including automatic business actions and manual progress notes.
|
||||
|
||||
## Decision
|
||||
|
||||
Use a `work-activities` event log plus a pure daily-report aggregation function. Do not add a generic rules engine or scheduler for the MVP.
|
||||
|
||||
Automatic events prove that an action happened today. Manual progress notes explain ongoing work that did not change status today.
|
||||
|
||||
## Scope
|
||||
|
||||
In scope:
|
||||
|
||||
- Current `/workspace` daily report remains personal and filters by the logged-in user.
|
||||
- Activity records are stored in the server `app_data` document layer under `work-activities`.
|
||||
- Product plan, dev task, test case, and bug actions can create activity records.
|
||||
- Daily report groups activity into delivery, progress, creation, risk, and progress-note-needed sections.
|
||||
- Multi-day in-progress items without today's manual progress note are shown as needing progress update.
|
||||
|
||||
Out of scope:
|
||||
|
||||
- Project-owner and management summary pages.
|
||||
- Scheduled reminders or fixed daily snapshots.
|
||||
- Generic configurable rule-engine UI.
|
||||
- Backend relational table migration.
|
||||
|
||||
## Data Model
|
||||
|
||||
`WorkActivity` is an append-only event-like record:
|
||||
|
||||
- `id`: stable client-generated id.
|
||||
- `actorId`: current logged-in member display identity.
|
||||
- `date`: local date, `YYYY-MM-DD`.
|
||||
- `occurredAt`: ISO timestamp.
|
||||
- `sourceType`: `version_plan`, `dev_task`, `test_case`, `bug`, or `manual`.
|
||||
- `sourceId`: entity id.
|
||||
- `action`: stable semantic action code.
|
||||
- `title`: snapshot title for display even if entity later changes.
|
||||
- `summary`: readable activity summary.
|
||||
- `category`: `delivery`, `progress`, `creation`, `risk`, or `note`.
|
||||
- `metadata`: optional details such as from/to status, blocker, helper, risk, or note.
|
||||
|
||||
## Capture Points
|
||||
|
||||
Activity creation should happen at business operation entry points, not scattered through page rendering:
|
||||
|
||||
- `useVersionPlanStore`: create plan, start plan, complete plan.
|
||||
- `useDevTaskStore`: create task, change status, set/clear blocked, add progress note.
|
||||
- `useBugStore`: create bug, status transition, transfer bug.
|
||||
- `useTestCaseStore`: create case and status transition when the store already has the action entry.
|
||||
|
||||
This keeps UI components as consumers of store actions and keeps the rules close to existing workflow helpers.
|
||||
|
||||
## Daily Report Rules
|
||||
|
||||
For a user and local date:
|
||||
|
||||
- Delivery: submitted dev tasks, completed plans, fixed/closed bugs, passed tests.
|
||||
- Progress: started work, moved status forward, self-test started, bug fixing started, transfers accepted.
|
||||
- Creation: created plans, dev tasks, test cases, bugs.
|
||||
- Risk: blocked items, delay risk notes, assistance requests.
|
||||
- Manual notes: explicit progress notes written by the owner.
|
||||
- Needs progress: in-progress work owned by the user that started before today and has no activity or manual note today.
|
||||
|
||||
Status changes count as daily evidence. For multi-day work with no status change, the user should add a progress note; otherwise the report flags it as needing an update.
|
||||
|
||||
## UI Behavior
|
||||
|
||||
The daily report panel should show grouped summaries and a compact "needs progress" section. It should not become a management dashboard yet.
|
||||
|
||||
Task detail drawers should expose a small progress-note action for ongoing work:
|
||||
|
||||
- today's progress
|
||||
- blocker or assistance need
|
||||
- delay risk
|
||||
|
||||
## Testing
|
||||
|
||||
Add focused unit tests for:
|
||||
|
||||
- activity filtering by user and date
|
||||
- grouping delivery/progress/risk/note items
|
||||
- automatic needs-progress detection
|
||||
- preserving old worklog compatibility during aggregation
|
||||
Reference in New Issue
Block a user