SuruchBoss / SuruchBoss/Cwork

CW-041 · Draft the manager's half of a review

Open
#40 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

assistant P3 phase-4
Dominant language
TypeScript
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Priority P3 · Area assistant · performance · Estimate M · Phase 4

A manager writing a review has already recorded the evidence — KPI scores, weights and check-ins are in the system. Assembling that into prose is the part they put off.

This one carries a real risk and it is accepted deliberately: drafted reviews tend towards sameness, and a manager who accepts a draft unedited has outsourced a judgement that is theirs to make. The guardrails below are the reason it is worth doing anyway, and they are not optional.

Scope

  • A tool taking a review id, not an employee id, refusing unless the caller is that review's reviewerEmployeeId. A review binds reviewer to subject already, so this does not widen the caller's reach.
  • It returns only what the manager themselves recorded: KPI goals, weights, scores, their own check-in notes. No attendance, no leave, no salary — those are not review evidence, and hoovering them in is how this feature would become something nobody asked for.
  • Output is a draft in an editable field, labelled as a draft, never saved directly as the review.
  • The review cannot be submitted unedited: if the text still matches the draft byte for byte, submission is refused with an explanation.
  • The final rating is the manager's. The model never proposes a score.

Acceptance

  • A manager can draft, edit and submit; submitting an unedited draft is refused.
  • The tool refuses a review the caller does not own.
  • The draft cites only KPI and check-in data, proven by a test that puts distinctive attendance and salary values in the fixture and asserts they never appear.
  • With the assistant disabled, review writing works exactly as it does today.

Files backend/src/modules/assistant/, backend/src/modules/performance/, web/src/features/performance/


Gated on #37. Phase 4 rather than 3: it is the least certain of the three, and the pilot will have said something about how the assistant is actually used by then.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by checking the dependency on issue #37, then inspect backend/src/modules/assistant/, backend/src/modules/performance/, and web/src/features/performance/. Trace the existing review-writing flow and identify where ownership, editable drafts, and submission checks belong. Done means the listed acceptance cases pass, including exclusion of attendance and salary data and unchanged behavior when the assistant is disabled.

Written by the indexing model from the issue text.

Assessment

Tech stack
postgresql, react, typescript
Domain
authorization, backend, frontend, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.