# 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