feat/int-base

Stale MAKE_SEEDS comment falsely states solis has no IntegrationManifest

packages/database/src/seed-metrics-catalog.ts:62

Lines 62–64 comment: 'Solis intentionally has no matching IntegrationManifest registered today — the wizard surfaces a "not available yet" state when the user picks it.' This is no longer true: solis IS in INTEGRATION_SEEDS and solisManifest is fully registered in manifests/index.ts. Any UI code or future developer reading this comment as authoritative will incorrectly treat solis as unavailable. Remove or replace with the accurate status.

Victron externalVariableId 'solarGeneration' camelCase — forward-compat risk for brand branch

packages/integration-manifests/src/manifests/victron.ts:42

victron.ts sets externalVariableId: 'solarGeneration' (camelCase). This is intentional per the prod registry snapshot. The risk is that the brand-branch worker may normalize to snake_case and mismatch. The test locks this value, so a normalization bug in the worker would be silent at manifest level. The brand branch must verify the exact VRM API response field casing.

APsystems header comment documents legacy key as 'solarGeneration' (camelCase) vs actual key 'solar_generation'

packages/integration-manifests/src/manifests/apsystems.ts:13

The header comment documents the legacy mapping as 'solarGeneration→produced'. The actual manifest variable key is 'solar_generation'. The externalVariableId 'produced' is correct. Documentation-only inconsistency but could mislead brand-branch developer looking up the legacy channel.

powerradar seed has credentialFields: [] but manifest has no credentialFields property — absent vs empty inconsistency

packages/database/src/seed-metrics-catalog.ts:259

The powerradar seed stores credentialFields: [] while the manifest declares no credentialFields property. Any FE code guarding on credentialFields !== undefined vs credentialFields.length > 0 will behave differently for powerradar vs other requiresAuth:false manifests. Verify the wizard handles both representations.

solis key_id marked secret: false — HMAC credential-pair ID should be secret

packages/integration-manifests/src/manifests/solis.ts:42

SolisCloud HMAC auth uses (KeyID, KeySecret). The KeyID is not a public identifier — it's the credential's username equivalent, sufficient to enumerate the Batu account's integration. Marking secret: false stores it unredacted in JSONB and renders it in cleartext in the FE wizard. Same classification question applies to Fronius AccessKeyId. Recommendation: mark both secret: true.

Fronius AccessKeyId marked secret: false — same HMAC-pair argument as solis

packages/integration-manifests/src/manifests/fronius.ts:39

Solar.web AccessKeyId is the public half of a (AccessKeyId, AccessKeyValue) pair. Like Solis's KeyID, it is not a public registry value and could be used to enumerate the integration owner. Stored unredacted in integration.metadata JSONB and shown in cleartext in the wizard.

dotenv config() silently no-ops when POSTGRES_URL already set — missing error surfaces as cryptic DB failure

packages/database/src/seed-metrics-catalog.ts:25

Guard `if (!process.env.POSTGRES_URL) { config(...) }` skips dotenv when POSTGRES_URL is set, even if .env.local is missing other required vars. dotenv's error is also swallowed (config() returns error without throwing). Add `const result = config(...); if (result.error) throw result.error;` for actionable failures.

Seed↔manifest credentialFields drift is an operational security risk

packages/database/src/seed-metrics-catalog.ts:151

If a manifest's credentialFields are updated (e.g. adding a field, flipping secret: true) without re-running the seed against each environment, the FE wizard renders the old classification. A field intended to be secret:true could be shown in cleartext until the seed is redeployed.

Redundant side-effect import in test file

packages/integration-manifests/src/__tests__/device-integrations.test.ts:27

Line 27 does `import '../manifests'` as an explicit side-effect import, but lines 11-24 already import named exports from the same module. A named import triggers top-level side effects (the registerManifest() calls). The bare import on line 27 is redundant and implies the named imports are insufficient — which is false. Remove it.

shelly-cloud.ts secret path says 'portal' but integration id is 'shelly-cloud' — D2 copier mismatch risk

packages/integration-manifests/src/manifests/shelly-cloud.ts:21

The JSDoc Auth section documents the legacy secret path as `{env}/shelly/portal/oid={oid}`. The word 'portal' mirrors Growatt convention but the integration id is 'shelly-cloud', not 'shelly-portal'. The D2 secret copier must map '/shelly/portal/oid=' → '/shelly/cloud/oid='. This mismatch should be explicitly called out in the comment so the brand branch doesn't silently copy to the wrong path.

ABB consumption/demand variable semantic mismatch: MetricType is W/mean but source is kWh-interval

packages/integration-manifests/src/manifests/abb.ts:44

The ABB manifest JSDoc states both channels 'derive from the meter's ActiveEnergy series' (cumulative kWh). The granularities ['15m', '1h'] are consistent with interval-energy, not demand polling. But MetricType.unit is 'W' and aggregator is 'mean'. The brand branch must clarify whether the ABB worker emits converted W or raw kWh, and add a note explaining the derivation — otherwise the ingest layer will mis-aggregate.

Inline variable comments describe what, not why

packages/integration-manifests/src/manifests/shelly-cloud.ts:43

Comments like '// Grid import — the meter's forward energy channel (vendor 'consumption').' restate what's visible from externalVariableId. Same pattern in huawei-portal.ts and abb.ts. Comments should carry the why — e.g. for Shelly, note that 'consumption' is Shelly Cloud's API field name for forward energy (not the eGauge convention), and 'reversed' is their field for export without a sign convention.

All supportedMakes values and export constant names conform to conventions

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

Positive: every manifest's supportedMakes contains the hardware brand name (plain, no access-path suffix); export constants follow {BRAND}_INTEGRATION_ID; battery/load MetricType seeds use unit:'W' and aggregator:'mean'; INTEGRATION_SEEDS names match manifest ids exactly.

No test enforcing seed↔manifest credentialFields mirror invariant

packages/integration-manifests/src/__tests__/device-integrations.test.ts

The seed manually duplicates each manifest's credentialFields (12 brands; enphase has 5 fields, abb has 3, fronius has non-obvious casing 'AccessKeyId'/'AccessKeyValue'). No test asserts seed.metadata.credentialFields deep-equals manifest.credentialFields. A mismatch would silently give the credential wizard a wrong field set. Add a cross-package test or seed-package test that imports both the seed data and the manifests package.

powerradar sourceConfigSchema shape not fully verified

packages/integration-manifests/src/__tests__/device-integrations.test.ts:166

Test asserts `sourceConfigSchema?.required` contains 'powerradarChannel' but doesn't verify the properties shape (type: 'string'), schema type ('object'), or that no extra required fields crept in. Compare with egauge.test.ts which checks schema.properties.egaugeColumn.type. Since powerradarChannel is the only channel mapping, a schema regression would cause silent intake failures.

externalVariableId spot-checks missing for abb, enphase grid channels, fronius grid channels

packages/integration-manifests/src/__tests__/device-integrations.test.ts:128

The spot-check test has gaps: (1) abb — neither demand nor consumption externalVariableId is checked; (2) enphase — only solar_generation is tested; (3) fronius — only solar_generation; (4) sma grid_import ('gridConsumption') is missing from both the main spot-check and the battery test block.

toBeGreaterThan(0) assertions on variable count and credentialFields count are too loose

packages/integration-manifests/src/__tests__/device-integrations.test.ts:104

Line 104 asserts fields.length > 0 and line 113 asserts entries.length > 0. Enphase dropping 3 of 5 credential fields or sma losing battery_charge would pass. Asserting exact per-brand counts would catch silent regressions.

egauge.test.ts confirms 15m granularity fix is in place

packages/integration-manifests/src/__tests__/egauge.test.ts:32

Pre-existing egauge test asserts granularities: ['5m', '15m']. The fix from SG-1 is correctly in place. egauge.test.ts is a good benchmark for assertion depth that the newer brand-specific tests should match.

credentialFields duplicated in seed — import or factory would prevent drift

packages/database/src/seed-metrics-catalog.ts:151

The seed could import @batu/integration-manifests and derive credentialFields from manifest.credentialFields ?? [] directly, making the copy structurally impossible. The 'DB package stays free of that dep' constraint should be re-evaluated against the maintenance cost of 12 hand-kept mirrors. A shared zero-dep sub-path export would serve as a middle ground.

CATALOG_VARIABLES in test is a hand-enumerated copy of METRIC_TYPE_SEEDS

packages/integration-manifests/src/__tests__/device-integrations.test.ts:49

Lines 49–58 define a local CATALOG_VARIABLES set identical to METRIC_TYPE_SEEDS.variable values. A future branch adding a new MetricType must update both places or tests fail unexpectedly. Export a CATALOG_VARIABLE_NAMES constant from the seed or a shared types location.

Spot-check test is a flat list — a data table would make additions a one-liner

packages/integration-manifests/src/__tests__/device-integrations.test.ts:128

The 22 individual expect() calls in 'carries the legacy vendor channel ids' have no structure. A CHANNEL_SPOT_CHECKS data table iterated with a single for-loop would make brand-branch additions a one-liner and surface the full channel registry at a glance.