docs(workspace): 记录工作活动日报方案

docs/superpowers/specs/2026-06-26-work-activity-daily-report-design.md

@@ -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