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