Orchestration Runs

Orchestration run tracking ticket. Not the real implementation ticket — this exists only so the live timing table has somewhere to post from step 1 onward. The real backend/mobile/web ticket(s) are created and cross-linked here once the run reaches that step.

Requirement:
"Write comprehensive Jest unit tests for the Care Program module to achieve full code coverage
(target: Stmt 90%+ | Branch 85%+ | Fn 90%+ | Ln 90%+, matching this repo's global coverage thresholds
in jest.config.js).

Scope — cover every layer that exists for the Care Program module:

Service layer: src/services/CareProgramService.ts (or equivalent)
Hooks: src/hooks/careProgram/**
Screens: src/screens/CareProgram/**
Sections/components: src/sections/careProgram/ or src/components/careProgram/
Utils: src/utils/careProgram/**
Redux slice (if present): src/store/slices/careProgramSlice.ts
Storybook stories (if present): src/sections/careProgram//.stories.tsx or
src/components/careProgram//.stories.tsx — verify each exported story renders without crashing
and that its args/controls match the component's prop types
Tracing (if present): src/traces/careProgram.ts — cover every exported span-builder/helper,
asserting span name, attributes, and status are set correctly for success and error paths

For EVERY test, prefix the it()/test() title with a priority tag: @p1, @p2, or @p3.

Priority rubric:

@p1 — Critical path, must-pass-before-merge:
Component/hook renders or initializes without crashing
Empty state / loading state / "no records" rendering
Core CRUD happy paths: create, edit, delete succeed and update state correctly
Primary API success AND failure handling
Required-field validation blocking submit
Status/data mapping logic
Auth/permission gates that block access entirely

@p2 — Important but secondary behavior:
Search, sort, filter interactions and API parameter wiring
Pagination
Dialog open/close/cancel flows
Permission-based UI hiding
Refresh / pull-to-refresh flows
Secondary API error handling
File upload validation
Sequence/code generation logic

@p3 — Edge cases, rare inputs:
null/undefined/boolean coercion
Malformed or partially missing API responses
Invalid date strings / boundary dates
Non-matching selections
Whitespace-only or empty-string search input
Independent toggle states

Requirements:

Use the existing mock boilerplate patterns already established in this repo.
Use these as references:

• src/tests/services/ProcurementsService.test.ts
• src/tests/hooks/procurement/usePurchaseBill.test.ts

Mock ApiClient, AsyncStorage, Logger, and navigation exactly as done in those
reference files. Do not introduce a new mocking approach.

Group tests with describe() blocks by behavior area:

• Core behavior
• Search & sort
• Pagination
• Permissions
• Error handling
• Edge cases

Check the Care Program source files line by line.
Every conditional, ternary, optional chaining fallback, switch/case branch,
validation branch, success path, and error path must be exercised.

Do not use any types in test code.
Do not add skipped/pending tests.
Do not add snapshot tests unless there is no meaningful interactive behavior
to assert.

After writing the Care Program tests, run:

npm run test:coverage --

Iterate on the tests until the required coverage thresholds are met.

Then run:

npm run test:p1 --
npm run test:p2 --
npm run test:p3 --

Confirm that the priority filters correctly select the intended tests and
that all selected tests pass.

For Storybook stories, if Care Program contains .stories.tsx files, create
render tests under:

src/tests/sections/careProgram/.stories.test.tsx

Import every named story export and render it using the same RTL helpers
already used elsewhere in the project.

Tag Storybook tests @p2 unless the story is the only meaningful coverage for a component, in which case use @p1.

For trace helpers, if Care Program contains:

src/traces/careProgram.ts

create:

src/tests/traces/careProgram.test.ts

Mock src/utils/otel.ts exactly as existing trace tests do.

Assert:

• Span name
• Span attributes
• Successful execution
• status=ERROR and error recording on failure

Tag success-path tests @p1 and failure-path tests @p2.

Do not modify production/business logic.
Only add or update the required Jest test files and test configuration
if absolutely necessary for the priority filtering.

Do not create unnecessary documentation.
Focus on implementing and validating the Care Program test coverage.

Output:
One test file per Care Program source file following the existing tests
folder structure.
Storybook test files only when Care Program stories exist.
Trace test file only when Care Program traces exist.
A short summary table showing:
File | P1 Count | P2 Count | P3 Count | Coverage"