88 lines
3.5 KiB
Markdown
88 lines
3.5 KiB
Markdown
# 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
|