feat: Enforce queue-based workflow for all volunteer actions

Feature Summary

Volunteer actions like recording vitals, prescriptions, and verification are currently accessible directly from the dashboard, bypassing the queue system. This leads to broken workflow where patient data does not move correctly between stages. As a result, patient status is marked as completed even though the process is incomplete. To fix this, all actions should be restricted to be performed only through their respective queues. This ensures proper patient flow, accurate status updates, and overall data consistency in the system.

Problem Statement

Currently, volunteer actions such as Record Vitals, Know Your Patient, Verify Medicines, Prescriptions, Counseling, and Medicines can be accessed directly from the dashboard without going through queues.

This causes: Patient data not propagating correctly across workflow stages Patient not moving to the next queue after completing a step Status being incorrectly marked as completed despite broken flow

This issue affects volunteers during patient handling and leads to inconsistent data tracking.

Proposed Solution

Remove direct access to all patient-related actions from the dashboard
Enforce that all actions must be performed only via their respective queues
Ensure each action is tied to a valid patient selected from a queue
Automatically move patients to the next queue after completing a step

Test-Driven Development

Acceptance Criteria (Given-When-Then)

Primary User Flow

Scenario 1: Queue-based action execution

Given user is on the volunteer dashboard
And patient exists in a queue
When user selects a patient from the queue and performs an action
Then action should be completed successfully
Patient should move to the next queue
status should update correctly

Scenario 2: Direct access blocked

Given user is on the dashboard
When user attempts to access an action directly without queue
Then access should be blocked
user should be redirected to the relevant queue

Components/Functions to Create:

File Path	Component/Function	Test Coverage Required
`src/components/...`		Render, interactions, state changes
`src/hooks/...`		All hook return values and callbacks
`src/utils/...`		All utility function outputs
`src/pages/...`		Page render, data fetching, routing

Test Assertions Required:

Technical Specification

Files to Create/Modify

File Path	Action	Purpose
`src/components/NewComponent.tsx`	Create	Main component
`src/components/NewComponent.test.tsx`	Create	Unit tests
`src/pages/FeaturePage.tsx`	Modify	Add feature route
`src/types/api.ts`	Modify	Add new API types
`src/lib/constants.ts`	Modify	Add new constants

API Requirements

API Types to Add:

// Add to src/types/api.ts
interface NewFeatureData {
  // Define types here
}

UI/UX Specification

Design Requirements

Accessibility Requirements

Semantic HTML elements used
ARIA labels for interactive elements
Keyboard navigation supported
Focus states visible
Screen reader compatible
Color contrast meets WCAG standards
Error messages linked to inputs

Definition of Done

Development

All acceptance criteria (Given-When-Then) pass
All test cases (TC-FEAT-*) executed and passing
Unit tests written with minimum 80% coverage
Integration tests written (if applicable)
Code follows project conventions
No TypeScript errors or any types
No ESLint/Prettier errors
No console.log() or debugger statements

Testing

Manual testing completed on all browsers
Responsive testing on mobile, tablet, desktop
Accessibility testing completed
Performance testing (no significant slowdowns)
Cross-browser testing (Chrome, Firefox, Safari, Edge)