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 Billing 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 Billing module:

• Service layer: src/services/BillingService.ts (or equivalent)
• Hooks: src/hooks/billing/**
• Screens: src/screens/Billing/**
• Sections/components: src/sections/billing/** or src/components/billing/**
• Utils: src/utils/billing/**
• Redux slice (if present): src/store/slices/billingSlice.ts
• Storybook stories (if present): src/sections/billing//*.stories.tsx or
  src/components/billing//*.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/billing.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:

1. 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

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

3. Group tests with describe() blocks by behavior area:

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

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

5. 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.

6. After writing the Billing tests, run:

   npm run test:coverage --

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

7. 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.

8. For Storybook stories, if Billing contains .stories.tsx files, create render
   tests under:

   src/tests/sections/billing/.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.

9. For trace helpers, if Billing contains:

   src/traces/billing.ts

   create:

   src/tests/traces/billing.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.

10. 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.

11. Do not create unnecessary documentation.
    Focus on implementing and validating the Billing test coverage.

Output:

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