---
id: w8/m5/t003
title: MonthToDate surfaces Database/KeyValue rows with resource kind
worker: worker8
status: todo
estimate: 35m
depends_on: [w8/m5/t002]
---

## Objective

Confirm (or extend) the `MonthToDate` store query so the new Database/KeyValue `usage_hourly` rows appear in the `services[]` output, disambiguated from `App` rows so clients don't mistake a database for a web service.

## Context

- `MonthToDate` currently keys purely on `service_id`, which was always an App id — it should already be generic since `usage_hourly` has no foreign key to `apps`, but this needs verifying against the real query/joins.
- The Usage response shape (`docs/ADR023-usage-metering.md`) has `services: [{serviceId, rows: [...]}]` with no resource-kind field today.

## Steps

1. Verify `MonthToDate`'s SQL doesn't implicitly filter/join against the `apps` table in a way that would drop the new rows.
2. If needed, add a `resourceKind` (or similar) field to the per-service response shape so REST/GraphQL/MCP/UI can distinguish App vs. Database vs. KeyValue.
3. Update the `Summary`/response Go types and any JSON schema docs accordingly.

## Files

- `lego/backend/internal/store/usage.go` (or wherever `MonthToDate` lives)
- `lego/backend/internal/usage/service.go` (`Summary` type)

## Acceptance criteria

- [ ] A `MonthToDate` call for a workspace with a metered Database/KeyValue instance includes its row(s) in `services[]`.
- [ ] The response distinguishes resource kind (field or equivalent), not just a bare id.

## Out of scope

- REST/GraphQL/MCP adapter code changes beyond what's needed to pass through the new field (t004).
