feat/int-base

5m 'our transform' cell describes consumer kWh formula, not worker passthrough-W output

services/metrics/integrations/sma/INFRA_DESIGN.md

The new Granularity tiers table lists '5m our transform' as 'Σ W×300/3.6e6' — that is the kWh energy integral a downstream consumer (SiteMetrics read path) computes, not what the SMA worker emits. The worker's actual 5m transform is passthrough W (no scaling), as stated in points-to-batu.ts and CLAUDE.md ('Legacy 5m values are instantaneous W — passthrough, no scaling'). The faithful? column then validates per-day kWh figures derived by the consumer, not emitted by the worker. The footnote partially clarifies this (explaining ×300/3.6e6 ≡ legacy /12000) but the primary cell label is misleading for any reader who stops there. Suggest: '5m: passthrough W (consumer computes Σ W×300/3.6e6 for kWh)'.

BILLING_TIER.md deletion is clean — no dangling references remain

services/metrics/integrations/sma/BILLING_TIER.md

The file was deleted and all references in manifest JSDoc and translation JSDoc were updated in the same commit. Search for 'BILLING_TIER' across the repo returns zero results. Consolidation into INFRA_DESIGN.md § Granularity tiers is clean.

Real customer plant ID and facility name committed to docs

services/metrics/integrations/sma/INFRA_DESIGN.md

Plant ID 6862260 and facility name 'PINELLI' (a real production device) appear in the newly-added section, in the file header, and in the probe endpoint URL (GET /v2/plants/6862260/measurements/sets/...). Combined with the org ID (oid=25) and internal site key (/25/18/2) also present in this branch, an attacker with the SMA API could probe that plant's live data. Risk is low now (private repo) but the ID is permanently in git history — if the repo ever becomes public or a token leaks, this becomes a real vector. Recommend substituting a placeholder (e.g. <plantId>) in the doc and keeping the actual ID in secrets/config. The commit message notes this was explicitly accepted, so flagged here for the reviewer to ratify rather than treating it as a blocker.

Production DynamoDB table name in docs

services/metrics/integrations/sma/INFRA_DESIGN.md

The probe provenance note references 'prod-ddb-batu-metrics'. This name already appears in CLAUDE.md (lines 466, 516) so this commit does not introduce new exposure. Consider abstracting to '{env}-ddb-batu-metrics' in new doc sections for consistency.

Cross-package JSDoc reference uses repo-root-relative path (non-standard, non-navigable by IDE)

packages/integration-manifests/src/manifests/sma.ts

The JSDoc references 'services/metrics/integrations/sma/INFRA_DESIGN.md' as a bare repo-root-relative path. An IDE following relative links would not resolve it. Other manifests in this package use the same convention (e.g. growatt.ts). Functional and consistent with existing practice; no action required unless tooling support for clickable doc links is wanted.

1h tier marked UNVERIFIED in docs but test suite does not surface the pending live-check gap

services/metrics/integrations/sma/INFRA_DESIGN.md

INFRA_DESIGN.md correctly marks 1h as 'UNVERIFIED — transform trivially loss-free, but 1h is not provisioned for PINELLI and the Week set was vendor-down at probe time.' The points-to-batu.test.ts 1h suite verifies transform mechanics but cannot prove vendor parity. A future maintainer provisioning 1h for a new plant has no in-test signal to run a live spot-check first. Recommend adding a it.todo or @pending-live-verification comment in the 1h describe block, mirroring the pattern hoymiles uses for its cadence mismatch. Low operational risk since 1h is not provisioned on any fleet plant yet, but the gap should close before 1h goes live.

5m algebraic equivalence claim (×300/3.6e6 ≡ /12000) has no pinning unit test

services/metrics/integrations/sma/INFRA_DESIGN.md

The table asserts '×300/3.6e6 ≡ legacy /12000 by construction'. This is algebraically trivial (300/3,600,000 = 1/12,000) and since 5m is a passthrough the claim is about read-side accumulation, not a worker transform. No test pins this with a concrete numeric triple. Very low risk since the equivalence is definitional, but a single assertion would make the documented parity reproducibly auditable.

Live probe value cited in 1d table row is not reproduced as a regression test

services/metrics/integrations/sma/INFRA_DESIGN.md

The table documents '07-08: 1_762_178 Wh → 73_424.083 W → 1762.178000 kWh' as live evidence for 1d faithfulness. The existing test suite exercises the transform with different values (1,856,293 Wh / 24 h) and DST edges. Adding a single test case with the exact probe triple would pin the live measurement as a reproducible regression baseline.