clqms-be/.serena/memories/task_completion.md

CLQMS Task Completion Guidelines

When a Task is Completed

1. Run Tests

Always run relevant tests after making changes:

# Run all tests
./vendor/bin/phpunit

# Run specific test file
./vendor/bin/phpunit tests/feature/Patients/PatientCreateTest.php

# Run specific test method
./vendor/bin/phpunit --filter testCreatePatientSuccess tests/feature/Patients/PatientCreateTest.php

2. Verify Code Quality

Check for Syntax Errors

php -l app/Controllers/Patient/PatientController.php

Check Test Results

Ensure:

• All existing tests still pass
• New tests (if any) pass
• No unexpected warnings or errors

3. Code Review Checklist

Controller Changes

• Validation rules are properly defined
• Error handling uses try-catch blocks
• Responses use standardized format with ResponseTrait
• Authentication filter applied where needed
• Input sanitization via validation rules
• Database operations wrapped in transactions (if multi-table)

Model Changes

• Extends BaseModel for UTC handling
• Table name, primary key, allowed fields defined
• Uses checkDbError() for error detection
• Audit logging via AuditService::logData() for data changes
• Soft delete fields configured if using soft deletes
• Nested data properly handled (extracted before filtering)

New Routes

• Added to app/Config/Routes.php
• Follows REST conventions (GET, POST, PATCH, DELETE)
• Grouped appropriately under /api/
• Auth filter applied if needed

New Tests

• Test name follows test<Action><Scenario><ExpectedResult> pattern
• Uses FeatureTestTrait
• Uses Factory::create('id_ID') for Indonesian test data
• Asserts correct status codes (200, 201, 400, 401, 404, 500)
• Tests both success and failure scenarios

4. Common Issues to Check

Database Operations

• Multi-table operations should use transactions
• Use parameterized queries (Query Builder handles this)
• Check for empty/null arrays before processing

Nested Data

• Extract nested arrays before filtering/processing
• Handle empty/null nested data appropriately
• Use transactions for multi-table operations

Date Handling

• All dates stored in UTC
• Use helper('utc') for conversions
• BaseModel extends with automatic UTC conversion

Security

• Input validation rules defined
• SQL injection prevention via parameterized queries
• JWT validation on protected endpoints
• No sensitive data logged or exposed

5. What NOT to Do

• Do NOT commit unless explicitly asked by the user
• Do NOT push to remote repository unless asked
• Do NOT skip running tests
• Do NOT add comments unless specifically requested
• Do NOT modify .env (database credentials, secrets)
• Do NOT include hardcoded secrets in code

6. Common Test Status Codes Reference

Code	Usage	Example
200	GET/PATCH success	->assertStatus(200)
201	POST success (created)	->assertStatus(201)
400	Validation error	->assertStatus(400)
401	Unauthorized	->assertStatus(401)
404	Not found	->assertStatus(404)
500	Server error	->assertStatus(500)

7. After Completing Tasks

Simply inform the user the task is complete. For example:

Task completed. The patient create endpoint now validates the identifier type dynamically.

Or if tests were run:

Task completed. All tests passing:
- testCreatePatientSuccess ✓
- testCreatePatientValidationFail ✓

8. When Something Goes Wrong

If tests fail or errors occur:

1. Check the error message carefully
2. Review the code against the patterns in this guide
3. Check database connection and configuration
4. Verify all required dependencies are installed
5. Review log files in writable/logs/

If unable to resolve, inform the user with details of the issue.