Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Should an IN_PROGRESS case still receive automated outreach? (the two readers left on OPEN-only by #551)

Closed
  • Is something wrong?
#552 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
typescript
Domain
backend

Research direction

Start with backend-ts/src/case/outreach-campaign.ts and backend-ts/src/mcp/tools.ts, then read docs/DATA_MODEL_CONTRACTS.md §4 and the context from #551. Resolve whether IN_PROGRESS cases should receive outreach and be attached to compliance answers, including the future-appointment option if considered. Done means the product decision is implemented consistently and recorded in §4.

Written by the indexing model from the issue text.

Description

backend owner-ops question

The question

Should a case an operator has already picked up (IN_PROGRESS) still be targeted by automated outreach, and still be the case attached to an MCP compliance answer?

This is a product decision, not a bug. It is filed so the inconsistency is tracked rather than left in a journal entry.

Why it comes up now

#551 widened the open-case readers to ACTIVE_CASE_STATUSES (OPEN + IN_PROGRESS), because the work list, its CSV export and the MCP list tools disagreed with each other: a case moved to IN_PROGRESS stayed on screen and vanished from the CSV taken off that screen.

Two readers were deliberately left on OPEN only, because neither is the work list and widening them would change behaviour nobody asked for:

  • backend-ts/src/case/outreach-campaign.ts — campaign targeting
  • backend-ts/src/mcp/tools.ts — the open case attached to a get_compliance_status answer

Recorded in docs/DATA_MODEL_CONTRACTS.md §4.

The two readings

Leave as-is (OPEN only). Someone has already started work on the case — a scheduled appointment is the usual reason it is IN_PROGRESS. Sending an automated letter on top of that is duplicate contact, and the patient hears from the practice twice about the same gap.

Widen to ACTIVE. ACTIVE_CASE_STATUSES is the contract's own definition of an active case, and every other surface now uses it. A case sitting IN_PROGRESS for six weeks because an appointment was booked and missed receives nothing at all under the current behaviour.

A third option: widen, but exclude cases with a future appointment — which is a real distinction the appointment store can already answer, and more work than either of the above.

Deciding it

Whichever way it goes, the outcome belongs in DATA_MODEL_CONTRACTS §4 next to the note that records the current split, so the next person to widen a status set knows these two were considered rather than missed.

Context: #551, docs/JOURNAL.md 2026-09-12.

Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
3h 36m
Merged PRs (30d)
117

Getting set up

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.

More from Taleef7/workwell

All issues in Taleef7/workwell

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.