[DO NOT MERGE] - Example endpoint implemented by a custom AI agent

[whabanks]

Summary | Résumé

This PR is a simple example of the rest-endpoint-builder agent adding a new API endpoint /service/<id>/billing/sms-cost which tallies up the fragment_count and total_cost for a service within a given date range.

Example output:

Promp & chat

Add a GET endpoint to the billing module that returns the total SMS cost for a service in a given date range. 
It should accept start_date and end_date as query parameters and return the total cost and fragment count.

I have a good understanding of the existing patterns. Let me check the FactBilling model to understand the columns available for the SMS cost query, and also read definitions.py for shared definitions.

Now I have full context. The FactBilling model has service_id, bst_date, notification_type, billable_units, rate_multiplier, rate, and billing_total columns.

I'll add:

1. A validation schema for the query params
2. A DAO function to query SMS cost by date range
3. A GET route in the billing rest.py
4. Test stubs
5. Let me implement all the changes:

Now let me add test stubs. Let me check how the existing tests import and structure things:

Now I'll append tests for the new endpoint at the end of the test file:

The import ordering in rest.py needs fixing — from datetime import date should come before Flask imports per standard Python import ordering (stdlib before third-party).

All changes are complete. Here's a summary of what was added:

Edited files:

• billing_schemas.py — added get_sms_cost_for_service_schema requiring start_date and end_date string properties with "format": "date"
• fact_billing_dao.py — added dao_fetch_sms_cost_for_service_in_range(service_id, start_date, end_date) that queries FactBilling for SMS-type rows, returning total fragment_count (billable_units × rate_multiplier) and total_cost (fragments × rate)
• rest.py — added GET /service/uuid:service_id/billing/sms-cost?start_date=YYYY-MM-DD&end_date=YYYY-MM-DD route that validates params, checks start < end, calls the DAO, and returns {start_date, end_date, fragment_count, total_cost}
• test_billing.py — added TestGetSmsCostForService class with 4 tests: happy path with data, zero-result case, missing dates (400), and start_date after end_date (400)

Checklist:

• billing_schemas.py — edited (added get_sms_cost_for_service_schema)
• fact_billing_dao.py — edited (added dao_fetch_sms_cost_for_service_in_range)
• rest.py — edited (added new route + updated imports)
• test_billing.py — edited (added test class)
• No __init__.py change needed — the billing_blueprint is already registered

Test instructions | Instructions pour tester la modification

TODO: Fill in test instructions for the reviewer.

Release Instructions | Instructions pour le déploiement

None.

Reviewer checklist | Liste de vérification du réviseur

• This PR does not break existing functionality.
• This PR does not violate GCNotify's privacy policies.
• This PR does not raise new security concerns. Refer to our GC Notify Risk Register document on our Google drive.
• This PR does not significantly alter performance.
• Additional required documentation resulting of these changes is covered (such as the README, setup instructions, a related ADR or the technical documentation).

⚠ If boxes cannot be checked off before merging the PR, they should be moved to the "Release Instructions" section with appropriate steps required to verify before release. For example, changes to celery code may require tests on staging to verify that performance has not been affected.